From: Parav Pandit <parav@nvidia.com>
To: <virtio-comment@lists.oasis-open.org>, <mst@redhat.com>,
<cohuck@redhat.com>
Cc: <hengqi@linux.alibaba.com>, <xuanzhuo@linux.alibaba.com>,
<shahafs@nvidia.com>, Parav Pandit <parav@nvidia.com>
Subject: [virtio-comment] [PATCH v1 0/2] Support enabling virtqueue after DRIVER_OK
Date: Wed, 13 Sep 2023 16:55:05 +0300 [thread overview]
Message-ID: <20230913135507.560540-1-parav@nvidia.com> (raw)
Summary:
========
This patch enables driver to create virtqueues after DRIVER_OK
status bit is set.
This patch take the inspiration from the thread [2] with credits to
Eugenio PÃrez.
Details:
========
Currently, a virtqueue must be enabled before driver has set the
DRIVER_OK status bit.
spec citation to section "Driver Requirements: Device Initialization"
"Perform device-specific setup, including discovery of virtqueues
for the device, optional per-bus setup, reading and possibly writing
the device’s virtio configuration space, and population of virtqueues."
This implies that a virtqueue must be enabled before reaching the
DRIVER_OK stage. There was no explicit mention about ability to
enable the virtqueue after DRIVER_OK stage.
In following usecases, creating a virtqueue after DRIVER_OK phase is
desired.
Use cases:
=========
1. Dynamically create aq when administrative commands to be used.
2. Dynamically create the net device tx/rxq when device is
opened when deploying for a container.
In a container, number of virtqueues to be used may be <= max queues.
3. Dynamically create flow filter queues of netdevice when
ARFS or ethtool filters are enabled as listed in [1].
4. Dynamically create rtc functionality related read virtqueue only
when net device when timestamping to be used.
5. When XDP program is set, one can create additional XDP specific
queues without affecting existing queues.
Hence, This patch introduces an existing queue enable and disable
(aka reset) facility and a new feature bit to explicitly indicate such
support by the device.
With this feature, drivers can skip optional queues creation during
driver init time. For example, a Linux net device driver
can create/destroy the transmit and receive queues when net device's
ndo_open() and ndo_stop() callbacks are invoked respectively.
As side effect, it also enables driver to not consume MSI-X vectors for
the PCI device at driver load time and utilize(enable) individual vector
when needed. This further helps on some cpus at high scale where a
interrupt line may not be available from the platform.
[1] https://lists.oasis-open.org/archives/virtio-comment/202308/msg00263.html
[2] https://lists.oasis-open.org/archives/virtio-comment/202306/msg00097.html
Patch summary:
==============
patch-1 fixes to add virtqueue reset conformance references
patch-2 adds VIRTIO_F_RING_DYNAMIC feature bit, requirements
Please review.
---
changelog:
v0->v1:
- fixed comments from Xuan
- removed blank lines
- fixed wrong requirement link to device in driver section
Parav Pandit (2):
conformance: Add missing virtqueue reset conformance references
content: Support enabling virtqueue after DRIVER_OK stage
conformance.tex | 4 ++++
content.tex | 53 ++++++++++++++++++++++++++++++++++++++++++++++---
2 files changed, 54 insertions(+), 3 deletions(-)
--
2.34.1
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
next reply other threads:[~2023-09-13 13:55 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-13 13:55 Parav Pandit [this message]
2023-09-13 13:55 ` [virtio-comment] [PATCH v1 1/2] conformance: Add missing virtqueue reset conformance references Parav Pandit
2023-09-13 14:52 ` Eugenio Perez Martin
2023-09-13 13:55 ` [virtio-comment] [PATCH v1 2/2] content: Support enabling virtqueue after DRIVER_OK stage Parav Pandit
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=20230913135507.560540-1-parav@nvidia.com \
--to=parav@nvidia.com \
--cc=cohuck@redhat.com \
--cc=hengqi@linux.alibaba.com \
--cc=mst@redhat.com \
--cc=shahafs@nvidia.com \
--cc=virtio-comment@lists.oasis-open.org \
--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 read-only IMAP folder(s) and NNTP newsgroup(s).