> From: Halil Pasic <[email protected]>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
