From: Jiri Pirko <jiri@resnulli.us>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Heng Qi <hengqi@linux.alibaba.com>,
jasowang@redhat.com, xuanzhuo@linux.alibaba.com,
eperezma@redhat.com, parav@nvidia.com, feliu@nvidia.com,
virtualization@lists.linux.dev
Subject: Re: [PATCH virtio 0/8] virtio_pci_modern: allow parallel admin queue commands execution
Date: Mon, 24 Jun 2024 17:10:36 +0200 [thread overview]
Message-ID: <ZnmMbPA--SyTF-6R@nanopsycho.orion> (raw)
In-Reply-To: <20240624070832-mutt-send-email-mst@kernel.org>
Mon, Jun 24, 2024 at 01:23:01PM CEST, mst@redhat.com wrote:
>On Mon, Jun 24, 2024 at 05:53:52PM +0800, Heng Qi wrote:
>> On Mon, 24 Jun 2024 11:04:43 +0200, Jiri Pirko <jiri@resnulli.us> wrote:
>> > From: Jiri Pirko <jiri@nvidia.com>
>> >
>> > Currently the admin queue command execution is serialized by a lock.
>> > This patchsets lifts this limitation allowing to execute admin queue
>> > commands in parallel. To do that, admin queue processing needs to be
>> > converted from polling to interrupt based completion.
>> >
>> > Patches #1-#6 are preparations, making things a bit smoother as well.
>> > Patch #7 implements interrupt based completion for admin queue.
>>
>> Hi, Jiri
>>
>> Before this set, I pushed the cvq irq set [1], and the discussion focused on the
>> fact that the newly added irq vector may cause the IO queue to fall back to
>> shared interrupt mode.
>> But it is true that devices implemented according to the specification should
>> not encounter this problem. So what do you think?
>>
>> [1] https://lore.kernel.org/all/20240619171708-mutt-send-email-mst@kernel.org/
>
>It's true - this can cause guest to run out of vectors for a variety of
>reasons.
>
>First we have guest irqs - I am guessing avq could use IRQF_SHARED ?
>I am not sure why we don't allow IRQF_SHARED for the config
>interrupt though. So I think addressing this part can be deferred.
>
>Second, we might not have enough msix vectors on the device. Here sharing
>with e.g. cvq and further with config interrupt would make sense.
>
>Jiri do you think you can help Heng Qi hammer out a solution for cvq?
>I feel this will work will then benefit in a similar way,
>and having us poll aggressively for cvq but not admin commands
>does not make much sense, right?
How about to enhance existing fallback in vp_find_vqs() to something
like this:
/* Try MSI-X with one vector per queue. */
err = vp_find_vqs_msix(vdev, nvqs, vqs, callbacks, names, ONE_FOR_EACH_VQ, ctx, desc);
if (!err)
return 0;
/* Try MSI-X with one vector per data queue, share one for the
* rest of the queues and config. */
err = vp_find_vqs_msix(vdev, nvqs, vqs, callbacks, names, ONE_FOR_EACH_DATA_VQ_ONE_FOR_REST, ctx, desc);
if (!err)
return 0;
/* Fallback: MSI-X with one vector for config, one shared for queues. */
err = vp_find_vqs_msix(vdev, nvqs, vqs, callbacks, names, ONE_DATA_VQS_ONE_FOR_REST, ctx, desc);
if (!err)
return 0;
I can implement this for admin queue, control queue can benefit from
this eventually.
>
>> > Patch #8 finally removes the admin queue serialization lock.
>> >
>> > Jiri Pirko (8):
>> > virtio_pci: push out single vq find code to vp_find_one_vq_msix()
>> > virtio_pci_modern: treat vp_dev->admin_vq.info.vq pointer as static
>> > virtio: push out code to vp_avq_index()
>> > virtio: create admin queues alongside other virtqueues
>> > virtio_pci_modern: create admin queue of queried size
>> > virtio_pci_modern: pass cmd as an identification token
>> > virtio_pci_modern: use completion instead of busy loop to wait on
>> > admin cmd result
>> > virtio_pci_modern: remove admin queue serialization lock
>> >
>> > drivers/virtio/virtio.c | 28 +----
>> > drivers/virtio/virtio_pci_common.c | 109 ++++++++++++++------
>> > drivers/virtio/virtio_pci_common.h | 9 +-
>> > drivers/virtio/virtio_pci_modern.c | 160 ++++++++++++-----------------
>> > include/linux/virtio.h | 2 +
>> > include/linux/virtio_config.h | 2 -
>> > 6 files changed, 150 insertions(+), 160 deletions(-)
>> >
>> > --
>> > 2.45.1
>> >
>> >
>
next prev parent reply other threads:[~2024-06-24 15:10 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-24 9:04 [PATCH virtio 0/8] virtio_pci_modern: allow parallel admin queue commands execution Jiri Pirko
2024-06-24 9:04 ` [PATCH virtio 1/8] virtio_pci: push out single vq find code to vp_find_one_vq_msix() Jiri Pirko
2024-06-24 10:52 ` Heng Qi
2024-06-24 13:11 ` Jiri Pirko
2024-06-24 9:04 ` [PATCH virtio 2/8] virtio_pci_modern: treat vp_dev->admin_vq.info.vq pointer as static Jiri Pirko
2024-06-24 9:04 ` [PATCH virtio 3/8] virtio: push out code to vp_avq_index() Jiri Pirko
2024-06-24 9:04 ` [PATCH virtio 4/8] virtio: create admin queues alongside other virtqueues Jiri Pirko
2024-06-24 9:04 ` [PATCH virtio 5/8] virtio_pci_modern: create admin queue of queried size Jiri Pirko
2024-06-24 9:04 ` [PATCH virtio 6/8] virtio_pci_modern: pass cmd as an identification token Jiri Pirko
2024-06-24 9:04 ` [PATCH virtio 7/8] virtio_pci_modern: use completion instead of busy loop to wait on admin cmd result Jiri Pirko
2024-06-24 11:30 ` Michael S. Tsirkin
2024-06-24 13:10 ` Jiri Pirko
2024-06-25 11:07 ` Jiri Pirko
2024-06-25 12:53 ` Parav Pandit
2024-06-25 14:29 ` Jiri Pirko
2024-06-24 11:34 ` Michael S. Tsirkin
2024-06-24 13:10 ` Jiri Pirko
2024-06-24 9:04 ` [PATCH virtio 8/8] virtio_pci_modern: remove admin queue serialization lock Jiri Pirko
2024-06-24 9:53 ` [PATCH virtio 0/8] virtio_pci_modern: allow parallel admin queue commands execution Heng Qi
2024-06-24 11:23 ` Michael S. Tsirkin
2024-06-24 13:46 ` Jiri Pirko
2024-06-24 13:55 ` Michael S. Tsirkin
2024-06-24 14:51 ` Jiri Pirko
2024-06-24 15:16 ` Michael S. Tsirkin
2024-06-25 2:11 ` Heng Qi
2024-06-25 6:38 ` Jiri Pirko
2024-06-25 6:41 ` Parav Pandit
2024-06-25 7:29 ` Michael S. Tsirkin
2024-06-25 8:01 ` Jiri Pirko
2024-06-25 7:20 ` Michael S. Tsirkin
2024-06-25 7:25 ` Parav Pandit
2024-06-24 15:10 ` Jiri Pirko [this message]
2024-06-24 15:23 ` Michael S. Tsirkin
2024-06-24 15:45 ` Jiri Pirko
2024-06-24 11:07 ` Michael S. Tsirkin
2024-06-24 13:09 ` Jiri Pirko
2024-06-24 13:16 ` Michael S. Tsirkin
2024-06-24 13:36 ` Jiri Pirko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZnmMbPA--SyTF-6R@nanopsycho.orion \
--to=jiri@resnulli.us \
--cc=eperezma@redhat.com \
--cc=feliu@nvidia.com \
--cc=hengqi@linux.alibaba.com \
--cc=jasowang@redhat.com \
--cc=mst@redhat.com \
--cc=parav@nvidia.com \
--cc=virtualization@lists.linux.dev \
--cc=xuanzhuo@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).