[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4 1/5] virtio-pci: add virtio_pci_optimal_num_queues() helpe
From: |
Stefan Hajnoczi |
Subject: |
Re: [PATCH v4 1/5] virtio-pci: add virtio_pci_optimal_num_queues() helper |
Date: |
Mon, 6 Jul 2020 14:25:20 +0100 |
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.
Stefan
signature.asc
Description: PGP signature
- Re: [PATCH v4 1/5] virtio-pci: add virtio_pci_optimal_num_queues() helper,
Stefan Hajnoczi <=