From: Parav Pandit <parav@nvidia.com>
To: Cornelia Huck <cohuck@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>
Cc: Eugenio Perez Martin <eperezma@redhat.com>,
"virtio-comment@lists.oasis-open.org"
<virtio-comment@lists.oasis-open.org>,
"hengqi@linux.alibaba.com" <hengqi@linux.alibaba.com>,
"xuanzhuo@linux.alibaba.com" <xuanzhuo@linux.alibaba.com>,
Shahaf Shuler <shahafs@nvidia.com>
Subject: RE: [virtio-comment] RE: [PATCH v3 2/2] content: Support enabling virtqueue after DRIVER_OK stage
Date: Fri, 27 Oct 2023 11:55:51 +0000 [thread overview]
Message-ID: <PH0PR12MB5481CEA539D310BEAF04BBC8DCDCA@PH0PR12MB5481.namprd12.prod.outlook.com> (raw)
In-Reply-To: <87jzr8s2yn.fsf@redhat.com>
> From: Cornelia Huck <cohuck@redhat.com>
> Sent: Friday, October 27, 2023 5:16 PM
> "config registers" are transport specific. If they aren't an efficient method, then
> the transport needs to come up with something else -- but it's the task of the
> *transport* to provide something useful. The device should not need to do
> anything beyond specifying that it can support adding vqs dynamically, and
> exposing the upper boundary to the number of queues.
>
You are welcome to propose to PCI-SIG such enhancements. :)
We cannot keep blind eye to transport and say, virtio will expand infinity registers without caring about underlying transport limitations and efficiencies.
There have been many discussions in past across many device + cpu vendors in various virtio and non virtio forums.
I would like to share that the industry does not prefer to put things as infinite set of registers unless its most fundamental thing needed to bootstrap the device.
> >
> > Out of 19 devices, 6 devices already has cvq.
> > Out of remaining 13 devices, 12 devices have fixed number of queues as they
> small enough in functionality that won't need a scale and dynamism either.
> > So for dynamic resource management reusing the existing cvq is more
> efficient for the devices.
>
> They have a device-specific cvq, which is used in a device-specific way for
> device-specific purposes. I don't see how turning them into frankencvqs is
> "efficient".
Sure, they are device specific, but we can define generic set of commands in basic facilities, which each device type can send via their cvq.
It is only matter of drafting it.
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 prev parent reply other threads:[~2023-10-27 11:55 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-02 5:15 [virtio-comment] [PATCH v3 0/2] Support enabling virtqueue after DRIVER_OK Parav Pandit
2023-10-02 5:16 ` [virtio-comment] [PATCH v3 1/2] conformance: Add missing virtqueue reset conformance references Parav Pandit
2023-10-05 16:53 ` Eugenio Perez Martin
2023-10-02 5:16 ` [virtio-comment] [PATCH v3 2/2] content: Support enabling virtqueue after DRIVER_OK stage Parav Pandit
2023-10-05 16:53 ` Eugenio Perez Martin
2023-10-12 6:39 ` [virtio-comment] " Xuan Zhuo
2023-10-17 12:25 ` Cornelia Huck
2023-10-17 12:48 ` [virtio-comment] " Parav Pandit
2023-10-18 10:25 ` Cornelia Huck
2023-10-18 10:28 ` Michael S. Tsirkin
2023-10-18 11:03 ` Cornelia Huck
2023-10-18 11:12 ` Michael S. Tsirkin
2023-10-18 11:12 ` Parav Pandit
2023-10-19 13:57 ` Parav Pandit
2023-10-23 13:29 ` Parav Pandit
2023-10-23 13:57 ` Cornelia Huck
2023-10-23 14:00 ` Parav Pandit
2023-10-23 14:27 ` Cornelia Huck
2023-10-23 14:53 ` Parav Pandit
2023-10-23 15:01 ` Cornelia Huck
2023-10-23 15:21 ` Parav Pandit
2023-10-25 9:55 ` Parav Pandit
2023-10-25 10:18 ` Cornelia Huck
2023-10-25 10:20 ` Parav Pandit
2023-10-25 10:24 ` Michael S. Tsirkin
2023-10-26 3:30 ` Parav Pandit
2023-10-26 5:39 ` Michael S. Tsirkin
2023-10-26 6:02 ` Parav Pandit
2023-10-26 6:24 ` Michael S. Tsirkin
2023-10-26 6:47 ` Parav Pandit
2023-10-26 8:27 ` Eugenio Perez Martin
2023-10-26 8:38 ` Parav Pandit
2023-10-26 9:15 ` Michael S. Tsirkin
2023-10-26 9:24 ` Parav Pandit
2023-10-26 9:27 ` Michael S. Tsirkin
2023-10-26 9:45 ` Parav Pandit
2023-10-27 10:13 ` Cornelia Huck
2023-10-27 10:28 ` Parav Pandit
2023-10-27 11:46 ` Cornelia Huck
2023-10-27 11:55 ` Parav Pandit [this message]
2023-10-26 9:18 ` Michael S. Tsirkin
2023-10-26 9:22 ` Parav Pandit
2023-10-26 9:26 ` Michael S. Tsirkin
2023-10-02 5:20 ` [virtio-comment] RE: [PATCH v3 0/2] Support enabling virtqueue after DRIVER_OK Parav Pandit
2023-10-10 4:57 ` Parav Pandit
2023-10-16 16:30 ` Parav Pandit
2023-10-17 11:58 ` Cornelia Huck
2023-10-17 12:50 ` 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=PH0PR12MB5481CEA539D310BEAF04BBC8DCDCA@PH0PR12MB5481.namprd12.prod.outlook.com \
--to=parav@nvidia.com \
--cc=cohuck@redhat.com \
--cc=eperezma@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).