RE: [virtio-comment] [PATCH v10 2/8] transport-pci: Refer to the vq by its number

[Parav Pandit <parav@nvidia.com>]

> From: Halil Pasic <pasic@linux.ibm.com>
> Sent: Thursday, March 30, 2023 1:10 PM

> > -        The driver will use this value to put it in the 'virtqueue number' field
> > +        The driver uses this value in the field \field{vqn}
> 
> This is one of the problems with this approach...
> 
Instead of vqn, it is just q identifier.
Sometimes is vqn, sometimes its q config data.
Currently wording has taken care of it.
But a better field name can also do it in future.

> >          in the available buffer notification structure.
> >          See section \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI-
> specific Initialization And Device Operation / Available Buffer Notifications}.
> >          \begin{note}
> >          This field provides the device with flexibility to determine how
> virtqueues
> >          will be referred to in available buffer notifications.
> > -        In a trivial case the device can set \field{queue_notify_data}=vqn. Some
> devices
> > +        In a trivial case the device can set
> > +        \field{queue_notify_data} to the vq number. Some devices
> 
> ... the 'vq' number here is not the same vqn above which renders the usage of
> vqn ambiguous.
> 
Not sure I follow. It is the vqn of above case in trivial case.

> > @@ -1053,7 +1054,7 @@ \subsubsection{Available Buffer
> > Notifications}\label{sec:Virtio Transport Option  If
> VIRTIO_F_NOTIF_CONFIG_DATA has been negotiated:
> >  \begin{itemize}
> >  \item If VIRTIO_F_NOTIFICATION_DATA has not been negotiated, the
> > driver MUST use the -\field{queue_notify_data} value instead of the virtqueue
> index.
> > +\field{queue_notify_data} value instead of the vq number.
> >  \item If VIRTIO_F_NOTIFICATION_DATA has been negotiated, the driver
> > MUST set the  \field{vqn} field to the \field{queue_notify_data} value.
> 
> And here it is really obvious: if VIRTIO_F_NOTIF_CONFIG_DATA has been
> negotiated the field \field{vqn} does not hold a virtqueue number/vq
> nuber/vqn but a device supplied identifier which may or may not be same as
> the vqn.
> 
> So we went
> from:
> if !VIRTIO_F_NOTIF_CONFIG_DATA then vqn is the virtqueue index if
> !!VIRTIO_F_NOTIF_CONFIG_DATA then vqn is queue_notify_data which may or
> may not be the same as the virtqueue index to if
> !VIRTIO_F_NOTIF_CONFIG_DATA then vqn is the vq number if
> !!VIRTIO_F_NOTIF_CONFIG_DATA then vqn is queue_notify_data which may or
> may not be the same as the vq number.
> 
The current wording is written bit simpler than above multiple if-else. :)

> Which is my opinion less clear that what we had before. And in my opinion
> calling the very same thing virtqueue und vq number interchangeably is not
> helpful either -- makes grepping harder.
> 
> I don't see the benefit of replacing virtqueue index with virtqueue number.
> AFAIR the supposed benefit was to:
> a) harmonize the terminology in the notifications part with the rest of the spec
> b) to resolve the RSS problematic with its receive virtqueue indexes.
> 
And also, the upcoming patches to use either one of them that uses vqn at multiple places.
And you have already voted for vqn in the new patches ballot yesterday.

> For b) we are going down a different route calling those receive queue ids
> (AFAIR), and for the notifications part see my comments above.
> 
This would be done anyway regardless of picking "index" vs "number".

> I'm about to reply to the cover letter, and make my argument against
> standardizing virtqueue nuber (and in favor of standardizing on the on
> virtqueue index) along with a diff that is supposed to act as a counter proposal.
> If that doesn't work I will give up and make peace with vq number and vqn.

I think the filed name "vqn" in the notification area can be improved.
The main reason I didn't touch it much, because CONFIG_DATA has rare usage in most virtualized world, real devices will not implement it.
After 2+ years of introduction in the spec, no open-source user has find it useful yet.
May be some use it there.
So if there is motivation, we can rename the vqn field and further improve the language.

I will surely read through other proposal anyway.
Thanks for taking time into this.