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

[Jason Wang]

On 2019/3/15 äå8:41, Cornelia Huck wrote:
> On Fri, 15 Mar 2019 12:50:11 +0800
> Jason Wang <jasowang@xxxxxxxxxx> 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.


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