Thread (2 messages) 2 messages, 2 authors, 2019-03-18

Re: virtio-blk: should num_vqs be limited by num_possible_cpus()?

flat view

From: Cornelia Huck <cohuck@redhat.com>
Date: 2019-03-15 12:41:19
Also in: linux-block, lkml

On Fri, 15 Mar 2019 12:50:11 +0800
Jason Wang [off-list ref] wrote:
Or something like I proposed several years ago? 
https://do-db2.lkml.org/lkml/2014/12/25/169

Btw, for virtio-net, I think we actually want to go for having a maximum 
number of supported queues like what hardware did. This would be useful 
for e.g cpu hotplug or XDP (requires per cpu TX queue). But the current 
vector allocation doesn't support this which will results all virtqueues 
to share a single vector. We may indeed need more flexible policy here.
I think it should be possible for the driver to give the transport
hints how to set up their queues/interrupt structures. (The driver
probably knows best about its requirements.) Perhaps whether a queue is
high or low frequency, or whether it should be low latency, or even
whether two queues could share a notification mechanism without
drawbacks. It's up to the transport to make use of that information, if
possible.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help