Re: virtio-blk: should num_vqs be limited by num_possible_cpus()?
flat view
From: Jason Wang <hidden>
Date: 2019-03-18 07:47:26
On 2019/3/15 下午8:41, Cornelia Huck wrote:
On Fri, 15 Mar 2019 12:50:11 +0800 Jason Wang [off-list ref] wrote:quoted
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.
Exactly and it was what the above series tried to do by providing hints of e.g which queues want to share a notification. Thanks _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization