Re: [PATCH v4 1/5] virtio-pci: add virtio_pci_optimal_num_queues() helper

[Cornelia Huck]

On Mon, 6 Jul 2020 14:25:20 +0100
Stefan Hajnoczi <stefanha@redhat.com> wrote:

> On Thu, May 28, 2020 at 05:35:55PM +0200, Cornelia Huck wrote:
> > On Wed, 27 May 2020 11:29:21 +0100
> > Stefan Hajnoczi <stefanha@redhat.com> wrote:
> >   
> > > Multi-queue devices achieve the best performance when each vCPU has a
> > > dedicated queue. This ensures that virtqueue used notifications are
> > > handled on the same vCPU that submitted virtqueue buffers.  When another
> > > vCPU handles the the notification an IPI will be necessary to wake the
> > > submission vCPU and this incurs a performance overhead.
> > > 
> > > Provide a helper function that virtio-pci devices will use in later
> > > patches to automatically select the optimal number of queues.
> > > 
> > > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> > > ---
> > >  hw/virtio/virtio-pci.h | 9 +++++++++
> > >  hw/virtio/virtio-pci.c | 7 +++++++
> > >  2 files changed, 16 insertions(+)  
> > 
> > That looks like a good idea, since the policy can be easily tweaked in
> > one place later.
> > 
> > For ccw, I don't see a good way to arrive at an optimal number of
> > queues. Is there something we should do for mmio? If yes, should this
> > be a callback in VirtioBusClass?  
> 
> I looked at this but virtio-pci devices need to do num_queues ->
> num_vectors -> .realize() in that order. It's hard to introduce a
> meaningful VirtioBusClass method. (The problem is that some devices
> automatically calculate the number of PCI MSI-X vectors based on the
> number of queues, but that needs to happen before .realize() and
> involves PCI-specific qdev properties.)
> 
> Trying to go through a common interface for all transports doesn't
> simplify things here.

That makes sense, thanks for checking.

pgpTZWCFSAYlT.pgp
Description: OpenPGP digital signature