From: Cornelia Huck <cohuck@redhat.com>
To: Halil Pasic <pasic@linux.ibm.com>, Parav Pandit <parav@nvidia.com>
Cc: mst@redhat.com, virtio-dev@lists.oasis-open.org,
sgarzare@redhat.com, virtio-comment@lists.oasis-open.org,
shahafs@nvidia.com, Halil Pasic <pasic@linux.ibm.com>
Subject: Re: [virtio-dev] [PATCH v10 0/8] Rename queue index to queue number
Date: Fri, 31 Mar 2023 10:13:51 +0200 [thread overview]
Message-ID: <87jzyxcp8g.fsf@redhat.com> (raw)
In-Reply-To: <20230330191114.77acd860.pasic@linux.ibm.com>
On Thu, Mar 30 2023, Halil Pasic <pasic@linux.ibm.com> wrote:
> On Thu, 30 Mar 2023 00:23:33 +0300
> Parav Pandit <parav@nvidia.com> wrote:
>
>> 1. Currently, virtqueue is identified between driver and device
>> interchangeably using either number or index terminology.
>>
>> 2. Between PCI and MMIO transport the queue size (depth) is
>> defined as queue_size and QueueNum respectively.
>>
>> To avoid confusion and to have consistency, unify them to use Number.
>>
>> Solution:
>> a. Use virtqueue number description, and rename MMIO register as QueueSize.
>
> I'm in favor of replacing number with size where appropriate.
>
>> b. Replace virtqueue index with virtqueue number
>
> I don't see the benefit of replacing virtqueue index with virtqueue
> number.
>
> Currently virtqueue number is only used in the parts that describe
> notifications (Guest->Host), the rest of the spec uses virtqueue index.
>
> I argue that using a different term in that context than in the rest
> of the specification makes sense, because in the context of notifications
> the virtqueue isn't always identified by its index.
>
> More precisely: if VIRTIO_F_NOTIF_CONFIG_DATA has been negotiated in the
> context of notifications the virtqueue is identified by the
> so called "queue_notify_data"; if VIRTIO_F_NOTIF_CONFIG_DATA has been
> negotiated in the context of notifications the virtqueue is identified by
> the virtqueue index (as usual, for example in queue_select, or in
> the ccws).
>
> As I've pointed out in my comment to patch 2, I believe replacing
> virtqueue index with virtqueue number is detrimental to clarity.
>
> Thus please find a counter-proposal below. If there is interest
> I can make a series out of it, and prettify it. If I can't convince
> you guys, then I will have to get used to vqn and virtqueue number.
I would generally prefer "index" as well, but there seemed to be a
strong sentiment that we should go with "number"... so, what *is* the
actual general sentiment? It's hard to say, but maybe most people are
fine with either?
>
> AFAIR the other problem with index was the RSS for virtio-net. But there
> we are currently heading down a direction of introducing a new
> abstraction. This approach avoids confusion around the term 'virtqueue
> index' as much as it avoids confusion around the term 'virtqueue nuber'.
>
>
>> c. RSS area of virtio net has inherited some logic, describe it
>> using abstract rss_rq_id.
>
> -------------------------8<--------------------------------------
> From: Halil Pasic <pasic@linux.ibm.com>
> Date: Thu, 30 Mar 2023 17:57:53 +0200
> Subject: [PATCH 1/1] content: clarify how virtques are identified
>
> Clarify how virtqueues are identified in the context of
> available notifications and in the context of RSS for
> virtio-net .
>
> Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
> ---
> content.tex | 15 ++++++++++-----
> device-types/net/description.tex | 30 ++++++++++++++++++++++--------
> transport-ccw.tex | 2 +-
> transport-pci.tex | 7 ++++---
> 4 files changed, 37 insertions(+), 17 deletions(-)
(...)
> +struct rss_rq_id {
> + le16 value; /* virtqueue index divided by two */
> +};
> +
> struct virtio_net_rss_config {
> le32 hash_types;
> le16 indirection_table_mask;
> - le16 unclassified_queue;
> - le16 indirection_table[indirection_table_length];
> + struct rss_rq_id unclassified_queue;
> + struct rss_rq_id indirection_table[indirection_table_length];
> le16 max_tx_vq;
> u8 hash_key_length;
> u8 hash_key_data[hash_key_length];
> };
> \end{lstlisting}
> +
> +The type struct rss\_rq\_id is introduced to better distinguish receive queue
> +ids form other integral fields.
> +
> +A receive queue id is only defined for receive queues, as the virtqueue index
> +of the receive virtqueue divided by two (the virtqueue index of a receive
> +queue is always even). For example receiveq4 is identified by the virtqueue
> +index 6 and the receive queue id 3.
FWIW, I think this is much easier to understand.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next prev parent reply other threads:[~2023-03-31 8:13 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-29 21:23 [virtio-dev] [PATCH v10 0/8] Rename queue index to queue number Parav Pandit
2023-03-29 21:23 ` [virtio-dev] [PATCH v10 1/8] content: Add vq number text Parav Pandit
2023-03-30 7:44 ` [virtio-dev] " Cornelia Huck
2023-03-29 21:23 ` [virtio-dev] [PATCH v10 2/8] transport-pci: Refer to the vq by its number Parav Pandit
2023-03-30 17:10 ` [virtio-dev] Re: [virtio-comment] " Halil Pasic
2023-03-30 19:00 ` [virtio-dev] " Parav Pandit
2023-03-29 21:23 ` [virtio-dev] [PATCH v10 3/8] transport-mmio: Rename QueueNum register Parav Pandit
2023-03-29 21:23 ` [virtio-dev] [PATCH v10 4/8] transport-mmio: Refer to the vq by its number Parav Pandit
2023-03-29 21:23 ` [virtio-dev] [PATCH v10 5/8] transport-ccw: Rename queue depth/size to other transports Parav Pandit
2023-03-29 21:23 ` [virtio-dev] [PATCH v10 6/8] transport-ccw: Refer to the vq by its number Parav Pandit
2023-03-30 7:48 ` [virtio-dev] " Cornelia Huck
2023-03-29 21:23 ` [virtio-dev] [PATCH v10 7/8] virtio-net: Avoid duplicate receive queue example Parav Pandit
2023-03-30 7:53 ` [virtio-dev] " Cornelia Huck
2023-03-29 21:23 ` [virtio-dev] [PATCH v10 8/8] virtio-net: Describe RSS using rss rq id Parav Pandit
2023-03-30 9:17 ` [virtio-dev] " Cornelia Huck
2023-04-03 22:29 ` [virtio-dev] " Parav Pandit
2023-04-04 8:15 ` [virtio-dev] Re: [virtio-comment] " Cornelia Huck
2023-04-04 16:11 ` [virtio-dev] " Parav Pandit
2023-03-30 17:11 ` [virtio-dev] [PATCH v10 0/8] Rename queue index to queue number Halil Pasic
2023-03-30 19:13 ` Parav Pandit
2023-04-04 1:36 ` Halil Pasic
2023-04-04 2:57 ` Parav Pandit
2023-04-04 6:33 ` Michael S. Tsirkin
2023-04-04 16:44 ` [virtio-dev] Re: [virtio-comment] " Halil Pasic
2023-04-04 7:07 ` Michael S. Tsirkin
2023-04-04 15:55 ` Halil Pasic
2023-04-04 16:08 ` [virtio-dev] Re: [virtio-comment] " Cornelia Huck
2023-04-04 7:13 ` Michael S. Tsirkin
2023-03-31 8:13 ` Cornelia Huck [this message]
2023-04-04 6:34 ` Michael S. Tsirkin
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=87jzyxcp8g.fsf@redhat.com \
--to=cohuck@redhat.com \
--cc=mst@redhat.com \
--cc=parav@nvidia.com \
--cc=pasic@linux.ibm.com \
--cc=sgarzare@redhat.com \
--cc=shahafs@nvidia.com \
--cc=virtio-comment@lists.oasis-open.org \
--cc=virtio-dev@lists.oasis-open.org \
/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