RE: [virtio-comment] Re: [PATCH 0/3] Rename queue index to queue number

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, March 2, 2023 6:39 PM
> >
> > Similarly rss description can be simplified.
> 
> Unfortunately this is not what it is. It's actually vqn / 2.
> 
:(
I see it now.
It is vqn/2.

So yes, need to document it this way that it is vqn/2.

> > > Here follows the explanation.
> > >
> > > Disclaimer: For a brief math background see [1] and [2].
> > >
> > > Here the index set the set of natural numbers (which includes 0, the
> > > neutral element for the addition operation).
> > >
> > > The indexed set is the set of receive virtqueues, each member of
> > > that set is associated with an unique member of the index set.
> > >
> > > """
> > > \subsection{Virtqueues}\label{sec:Device Types / Network Device /
> > > Virtqueues}
> > >
> > > \begin{description}
> > > \item[0] receiveq1
> > > \item[1] transmitq1
> > > \item[\ldots]
> > > \item[2(N-1)] receiveqN
> > > \item[2(N-1)+1] transmitqN
> > > \item[2N] controlq
> > > \end{description}
> > > """
> > >
> > > But, as seen above, we happen to also use an other index set for the
> > > receive queues of an virtio-net device. I guess the intention is to
> > > use these as names, in any case the set is { "receiveq1", "receiveq2", ... }
> (yes, I'm a little sloppy here).
> > >
> > > Thus we can say that:
> > > * the virtqueue index 2*(N-1)
> > > * the recieve virtqueue index N-1, and the
> > > * virtqueue name receiveqN
> > > refer to the very same virtqueue (for each N > 0)
> > >
> > Receiveq1 is a name to virtuque number (currently index) 0.
> > And naming this way doesn't seem to be a problem in the description.
> >
> > Section 5.1.2 is liste them already.
Bad auto-correction.
I was saying the existing section "Virtqueues" in Network device already lists the mapping between vqn(vq index) and logical receive and transmit q.
An additional short line telling about this mapping is enough.

> > A short line tell about this mapping will suffice.
> 
> can't parse this.

My point was, there isn't a lot of change needed around current examples where receiveN is talked.
Better to see in the actual patch.