From: Halil Pasic <pasic@linux.ibm.com>
To: Parav Pandit <parav@nvidia.com>
Cc: "mst@redhat.com" <mst@redhat.com>,
"virtio-dev@lists.oasis-open.org"
<virtio-dev@lists.oasis-open.org>,
"cohuck@redhat.com" <cohuck@redhat.com>,
"sgarzare@redhat.com" <sgarzare@redhat.com>,
"virtio-comment@lists.oasis-open.org"
<virtio-comment@lists.oasis-open.org>,
Shahaf Shuler <shahafs@nvidia.com>,
Halil Pasic <pasic@linux.ibm.com>
Subject: [virtio-comment] Re: [virtio-dev] [PATCH v10 0/8] Rename queue index to queue number
Date: Tue, 4 Apr 2023 03:36:22 +0200 [thread overview]
Message-ID: <20230404033622.4b749f89.pasic@linux.ibm.com> (raw)
In-Reply-To: <PH0PR12MB548165C4B11375F8C7EE7AD1DC8E9@PH0PR12MB5481.namprd12.prod.outlook.com>
On Thu, 30 Mar 2023 19:13:47 +0000
Parav Pandit <parav@nvidia.com> wrote:
> > From: Halil Pasic <pasic@linux.ibm.com>
> > Sent: Thursday, March 30, 2023 1:11 PM
>
> > 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.
> Using single term as number is possible, so lets use single term.
>
I don't understand. In my opinion we should use a single term for
a particular thing, but we should avoid using the same term for
two different things.
One thing is the zero based index of the virtqueue, for that
unfortunately we currently have multiple terms: virtqueue index
and virtqueue nubmer. To remove ourselves from the index vs number
discussion let us call it "X".
Another thing is the what you below propose to call vq_identifier, but
for the same reason as above let us briefly call it Y. "Y" may hold
an "X" or a "vq_notification_data" to use your term -- we both agree
on that so, I believe we should both agree that "X" and "Y" are distinct
things an need distinct and easy to distinguish names.
What we currently have is:
* when we mean "Y" we write "virtqueue number" or "vqn",
* and when we mean "X" we write either "virtqueue index" or "virtqueue
number"
Now let me pull the historic argument for consolidation on "virtqueue
index" rather than "virtqueue number".
Most of the occurrences of "virtqueue number" were introduced by
commit 4ca1311 ("VIRTIO_F_NOTIFICATION_DATA: extra data to devices"
and commit 2ff0d5c ("virtio-net: Add support for the flexible driver
notification structure.")
And I argue most of them stand where we mean "Y". Some of them
don't and that is bad.
Please have a look at the v1.0 version of the specification:
http://docs.oasis-open.org/virtio/virtio/v1.0/cs04/virtio-v1.0-cs04.html#x1-370007
and search for "queue number" and "queue index". For "queue number"
you should get 1 hit and for "queue index" 8. All of them mean "X",
because "Y" was introduced later.
I argue, it is more sane to assume that the single "queue number"
occurrence is a back then quite harmless mistake (all we had is "X", so
we didn't have the "queue number" means "Y"), that to say the 8
occurrences of "queue index" are all mistakes.
Your approach to resolving the problem is:
* change all concurrences of "queue index" (all stand for "X") to
"queue number"
* change the occurrences of "queue number" that stand for "Y" (that
is most of them) to "vq_identifier"
* keep the occurrences of "queue number" that stand for "X" as is
Yes that way we can reach an in itself consistent state.
I argue that the following approach is better:
* keep all occurrences of "queue index" as is (all stand for "X")
* change he occurrences of "queue number" that stand for "X"
to "virtqueue index"
* if we can find a name for "Y" better than "queue number"
replace all remaining occurrences of "queue number" with
that new name (I agree "queue number" is not a very good
name for "Y")
Both solutions are equally consistent in themselves, but I
argue the latter is better because:
* it is more consistent with historic usage
* in my subjective opinion "queue index" is a better
name for "X" compared to "queue number"
* it requires fewer changes.
@Michael: Do you agree? Disagree?
Parav, your work is very much appreciated. I know, the messy
current state is not your fault at all. In fact it is to a certain
degree my fault.
> >
> > 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
>
> You missed "not" before negotiation. :)
Right.
Regard,
Halil
>
> > 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.
[..]
> > @@ -413,7 +416,9 @@ \section{Driver Notifications} \label{sec:Basic Facilities
> > of a Virtio Device / the following information:
> >
> > \begin{description}
> > -\item [vqn] VQ number to be notified.
> > +\item [vqn] Identifies the virtqueueue to be notified. If
> > VIRTIO_F_NOTIF_CONFIG_DATA has been
> > + negotiateted, the value of \field{vqn} is the notify data suplied by the
> > device
> There is still vqn here. So no better than vq number.
> To be truly clear, it should be renamed to vq_identifier, that either contains vqn or vq_notification_data.
>
> As I replied I can take up that cleanup at later point if we find some motivation for CONFIG_DATA use.
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/
WARNING: multiple messages have this Message-ID (diff)
From: Halil Pasic <pasic@linux.ibm.com>
To: Parav Pandit <parav@nvidia.com>
Cc: "mst@redhat.com" <mst@redhat.com>,
"virtio-dev@lists.oasis-open.org"
<virtio-dev@lists.oasis-open.org>,
"cohuck@redhat.com" <cohuck@redhat.com>,
"sgarzare@redhat.com" <sgarzare@redhat.com>,
"virtio-comment@lists.oasis-open.org"
<virtio-comment@lists.oasis-open.org>,
Shahaf Shuler <shahafs@nvidia.com>,
Halil Pasic <pasic@linux.ibm.com>
Subject: Re: [virtio-dev] [PATCH v10 0/8] Rename queue index to queue number
Date: Tue, 4 Apr 2023 03:36:22 +0200 [thread overview]
Message-ID: <20230404033622.4b749f89.pasic@linux.ibm.com> (raw)
In-Reply-To: <PH0PR12MB548165C4B11375F8C7EE7AD1DC8E9@PH0PR12MB5481.namprd12.prod.outlook.com>
On Thu, 30 Mar 2023 19:13:47 +0000
Parav Pandit <parav@nvidia.com> wrote:
> > From: Halil Pasic <pasic@linux.ibm.com>
> > Sent: Thursday, March 30, 2023 1:11 PM
>
> > 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.
> Using single term as number is possible, so lets use single term.
>
I don't understand. In my opinion we should use a single term for
a particular thing, but we should avoid using the same term for
two different things.
One thing is the zero based index of the virtqueue, for that
unfortunately we currently have multiple terms: virtqueue index
and virtqueue nubmer. To remove ourselves from the index vs number
discussion let us call it "X".
Another thing is the what you below propose to call vq_identifier, but
for the same reason as above let us briefly call it Y. "Y" may hold
an "X" or a "vq_notification_data" to use your term -- we both agree
on that so, I believe we should both agree that "X" and "Y" are distinct
things an need distinct and easy to distinguish names.
What we currently have is:
* when we mean "Y" we write "virtqueue number" or "vqn",
* and when we mean "X" we write either "virtqueue index" or "virtqueue
number"
Now let me pull the historic argument for consolidation on "virtqueue
index" rather than "virtqueue number".
Most of the occurrences of "virtqueue number" were introduced by
commit 4ca1311 ("VIRTIO_F_NOTIFICATION_DATA: extra data to devices"
and commit 2ff0d5c ("virtio-net: Add support for the flexible driver
notification structure.")
And I argue most of them stand where we mean "Y". Some of them
don't and that is bad.
Please have a look at the v1.0 version of the specification:
http://docs.oasis-open.org/virtio/virtio/v1.0/cs04/virtio-v1.0-cs04.html#x1-370007
and search for "queue number" and "queue index". For "queue number"
you should get 1 hit and for "queue index" 8. All of them mean "X",
because "Y" was introduced later.
I argue, it is more sane to assume that the single "queue number"
occurrence is a back then quite harmless mistake (all we had is "X", so
we didn't have the "queue number" means "Y"), that to say the 8
occurrences of "queue index" are all mistakes.
Your approach to resolving the problem is:
* change all concurrences of "queue index" (all stand for "X") to
"queue number"
* change the occurrences of "queue number" that stand for "Y" (that
is most of them) to "vq_identifier"
* keep the occurrences of "queue number" that stand for "X" as is
Yes that way we can reach an in itself consistent state.
I argue that the following approach is better:
* keep all occurrences of "queue index" as is (all stand for "X")
* change he occurrences of "queue number" that stand for "X"
to "virtqueue index"
* if we can find a name for "Y" better than "queue number"
replace all remaining occurrences of "queue number" with
that new name (I agree "queue number" is not a very good
name for "Y")
Both solutions are equally consistent in themselves, but I
argue the latter is better because:
* it is more consistent with historic usage
* in my subjective opinion "queue index" is a better
name for "X" compared to "queue number"
* it requires fewer changes.
@Michael: Do you agree? Disagree?
Parav, your work is very much appreciated. I know, the messy
current state is not your fault at all. In fact it is to a certain
degree my fault.
> >
> > 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
>
> You missed "not" before negotiation. :)
Right.
Regard,
Halil
>
> > 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.
[..]
> > @@ -413,7 +416,9 @@ \section{Driver Notifications} \label{sec:Basic Facilities
> > of a Virtio Device / the following information:
> >
> > \begin{description}
> > -\item [vqn] VQ number to be notified.
> > +\item [vqn] Identifies the virtqueueue to be notified. If
> > VIRTIO_F_NOTIF_CONFIG_DATA has been
> > + negotiateted, the value of \field{vqn} is the notify data suplied by the
> > device
> There is still vqn here. So no better than vq number.
> To be truly clear, it should be renamed to vq_identifier, that either contains vqn or vq_notification_data.
>
> As I replied I can take up that cleanup at later point if we find some motivation for CONFIG_DATA use.
---------------------------------------------------------------------
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-04-04 1:37 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-29 21:23 [virtio-comment] [PATCH v10 0/8] Rename queue index to queue number Parav Pandit
2023-03-29 21:23 ` [virtio-dev] " Parav Pandit
2023-03-29 21:23 ` [virtio-comment] [PATCH v10 1/8] content: Add vq number text Parav Pandit
2023-03-29 21:23 ` [virtio-dev] " Parav Pandit
2023-03-30 7:44 ` [virtio-comment] " Cornelia Huck
2023-03-30 7:44 ` [virtio-dev] " Cornelia Huck
2023-03-29 21:23 ` [virtio-comment] [PATCH v10 2/8] transport-pci: Refer to the vq by its number Parav Pandit
2023-03-29 21:23 ` [virtio-dev] " Parav Pandit
2023-03-30 17:10 ` [virtio-comment] " Halil Pasic
2023-03-30 17:10 ` [virtio-dev] " Halil Pasic
2023-03-30 19:00 ` Parav Pandit
2023-03-30 19:00 ` [virtio-dev] " Parav Pandit
2023-03-29 21:23 ` [virtio-comment] [PATCH v10 3/8] transport-mmio: Rename QueueNum register Parav Pandit
2023-03-29 21:23 ` [virtio-dev] " Parav Pandit
2023-03-29 21:23 ` [virtio-comment] [PATCH v10 4/8] transport-mmio: Refer to the vq by its number Parav Pandit
2023-03-29 21:23 ` [virtio-dev] " Parav Pandit
2023-03-29 21:23 ` [virtio-comment] [PATCH v10 5/8] transport-ccw: Rename queue depth/size to other transports Parav Pandit
2023-03-29 21:23 ` [virtio-dev] " Parav Pandit
2023-03-29 21:23 ` [virtio-comment] [PATCH v10 6/8] transport-ccw: Refer to the vq by its number Parav Pandit
2023-03-29 21:23 ` [virtio-dev] " Parav Pandit
2023-03-30 7:48 ` [virtio-comment] " Cornelia Huck
2023-03-30 7:48 ` [virtio-dev] " Cornelia Huck
2023-03-29 21:23 ` [virtio-comment] [PATCH v10 7/8] virtio-net: Avoid duplicate receive queue example Parav Pandit
2023-03-29 21:23 ` [virtio-dev] " Parav Pandit
2023-03-30 7:53 ` [virtio-comment] " Cornelia Huck
2023-03-30 7:53 ` [virtio-dev] " Cornelia Huck
2023-03-29 21:23 ` [virtio-comment] [PATCH v10 8/8] virtio-net: Describe RSS using rss rq id Parav Pandit
2023-03-29 21:23 ` [virtio-dev] " Parav Pandit
2023-03-30 9:17 ` [virtio-comment] " Cornelia Huck
2023-03-30 9:17 ` [virtio-dev] " Cornelia Huck
2023-04-03 22:29 ` [virtio-comment] " Parav Pandit
2023-04-03 22:29 ` [virtio-dev] " Parav Pandit
2023-04-04 8:15 ` [virtio-comment] " Cornelia Huck
2023-04-04 8:15 ` [virtio-dev] " Cornelia Huck
2023-04-04 16:11 ` Parav Pandit
2023-04-04 16:11 ` [virtio-dev] " Parav Pandit
2023-03-30 17:11 ` [virtio-comment] Re: [virtio-dev] [PATCH v10 0/8] Rename queue index to queue number Halil Pasic
2023-03-30 17:11 ` Halil Pasic
2023-03-30 19:13 ` [virtio-comment] " Parav Pandit
2023-03-30 19:13 ` Parav Pandit
2023-04-04 1:36 ` Halil Pasic [this message]
2023-04-04 1:36 ` Halil Pasic
2023-04-04 2:57 ` [virtio-comment] " Parav Pandit
2023-04-04 2:57 ` Parav Pandit
2023-04-04 6:33 ` [virtio-comment] " Michael S. Tsirkin
2023-04-04 6:33 ` Michael S. Tsirkin
2023-04-04 16:44 ` [virtio-comment] " Halil Pasic
2023-04-04 16:44 ` [virtio-dev] " Halil Pasic
2023-04-04 7:07 ` Michael S. Tsirkin
2023-04-04 7:07 ` Michael S. Tsirkin
2023-04-04 15:55 ` [virtio-comment] " Halil Pasic
2023-04-04 15:55 ` Halil Pasic
2023-04-04 16:08 ` [virtio-comment] " Cornelia Huck
2023-04-04 16:08 ` [virtio-dev] " Cornelia Huck
2023-04-04 7:13 ` Michael S. Tsirkin
2023-04-04 7:13 ` Michael S. Tsirkin
2023-03-31 8:13 ` [virtio-comment] " Cornelia Huck
2023-03-31 8:13 ` Cornelia Huck
2023-04-04 6:34 ` [virtio-comment] " Michael S. Tsirkin
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=20230404033622.4b749f89.pasic@linux.ibm.com \
--to=pasic@linux.ibm.com \
--cc=cohuck@redhat.com \
--cc=mst@redhat.com \
--cc=parav@nvidia.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.