All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Parav Pandit <parav@nvidia.com>
Cc: "virtio-dev@lists.oasis-open.org"
	<virtio-dev@lists.oasis-open.org>,
	"pasic@linux.ibm.com" <pasic@linux.ibm.com>,
	"cohuck@redhat.com" <cohuck@redhat.com>,
	"virtio-comment@lists.oasis-open.org"
	<virtio-comment@lists.oasis-open.org>,
	Shahaf Shuler <shahafs@nvidia.com>
Subject: [virtio-comment] Re: [PATCH v3 8/8] virtio-net: Describe RSS using receive queue handle
Date: Wed, 22 Mar 2023 16:56:53 -0400	[thread overview]
Message-ID: <20230322165542-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <PH0PR12MB548118C2FB6C986D945397CCDC869@PH0PR12MB5481.namprd12.prod.outlook.com>

On Wed, Mar 22, 2023 at 05:07:51PM +0000, Parav Pandit wrote:
> 
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Tuesday, March 21, 2023 11:46 PM
> > >
> > > > And it's still kind of complex and non-standard. E.g. what does
> > > > \begin{lstlisting}
> > > > le16 rq_handle;
> > > > \end{lstlisting}
> > > > mean exactly? Apparently nothing ...
> > > >
> > > Why nothing, it is referenced further down.
> > > Did you suggest moving before using it?
> > > It was just fine to provide a forward reference.
> > 
> > because it does not say anything about the contents or the format. just some
> > kind of integer.
> > 
> Because it is an integer there is no need of a special format.
> It does say about the content very clearly = vqn / 2;
> But more below.
> 
> > > > I feel what we keep there is really the virtqueue number itself.
> > > > Just stored in this strage format.
> > > >
> > > > And all this talk about handles kind of seems to add yet another term to
> > learn.
> > > > Where in fact all it is, is just a different way to store vqn.
> > > >
> > > > So my idea was this: we say something like:
> > > >
> > > >
> > > > \field{unclassified_queue} contains the virtqueue number of the
> > > > receive queue to place unclassified packets in.
> > > > \field{indirection_table} contains an array of virtqueue numbers of
> > > > receive queues.
> > > >
> > > Above two lines are clearly confusing where virtqueue number describe in
> > rest of the spec and above doesn't align to same notion.
> > 
> > That's true.
> > 
> > > So better to say field A contains the rq_handle and
> > >
> > > struct rq_handle {
> > > 	le16 vqn_16_1: 15;
> > > 	le16 reserved : 1;
> > > };
> > 
> > 
> > 
> > >
> > > > Both \field{unclassified_queue} and \field{indirection_table} use
> > > > the following format for the virtqueue numbers:
> > > > \begin{lstlisting}
> > > > struct rss_virtqueue_number {
> > > It is really not any superior in term of cost of learning.
> > >
> > > > 	le16 vqn_16_1 : 15; /* Bits 16 to 1 of the virtqueue number */
> > > > 	le16 reserved : 1; /* Set to 0 */
> > > I like the structure and reserved bit that enables to claim one bit for some
> > unknown future use.
> > > > }
> > > > \end{lstlisting}
> > > > for example, a value of 3 corresponds to virtqueue number 6 and maps
> > > > to receiveq4.
> > > >
> > > >
> > > >
> > > > and then everywhere else we just say it keeps a vq number, we
> > > > already explained it is using this format once no need to repeat that.
> > > >
> > > I just prefer to rename it to rq_handle ( or at least other than virtqueue
> > number) to distinguish it from rest of the virtqueue number.
> > 
> > Well first of all I really want to make it clear it's specific to RSS at least for now.
> > So let's prefix with rss_.
> Yes, rss_ prefix is good.
> 
> > Maybe I'm wrong but I feel using up a completely new term for something very
> > specific to RSS is a waste.
> > We won't be able to use handle for something else without confusion.
> > So how about just
> > 
> > 	struct rss_rq {
> > 		le16 vqn_16_1 : 15; /* Bits 16 to 1 of the virtqueue number */
> > 		le16 reserved : 1; /* Set to 0 */
> > 	};
> Rq is usually an object and here we want to just refer to its id/vqn/handle.
> 
> Hence, I prefer rss_rq_handle {} or rss_rq_id{} for the structure name.
> WDYT?

_id is ok. But don't define it separately as a special object, it's just
the format of indirection_table and unclassified_queue.
IOW define at point of 1st use.

-- 
MST


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: "Michael S. Tsirkin" <mst@redhat.com>
To: Parav Pandit <parav@nvidia.com>
Cc: "virtio-dev@lists.oasis-open.org"
	<virtio-dev@lists.oasis-open.org>,
	"pasic@linux.ibm.com" <pasic@linux.ibm.com>,
	"cohuck@redhat.com" <cohuck@redhat.com>,
	"virtio-comment@lists.oasis-open.org"
	<virtio-comment@lists.oasis-open.org>,
	Shahaf Shuler <shahafs@nvidia.com>
Subject: [virtio-dev] Re: [PATCH v3 8/8] virtio-net: Describe RSS using receive queue handle
Date: Wed, 22 Mar 2023 16:56:53 -0400	[thread overview]
Message-ID: <20230322165542-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <PH0PR12MB548118C2FB6C986D945397CCDC869@PH0PR12MB5481.namprd12.prod.outlook.com>

On Wed, Mar 22, 2023 at 05:07:51PM +0000, Parav Pandit wrote:
> 
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Tuesday, March 21, 2023 11:46 PM
> > >
> > > > And it's still kind of complex and non-standard. E.g. what does
> > > > \begin{lstlisting}
> > > > le16 rq_handle;
> > > > \end{lstlisting}
> > > > mean exactly? Apparently nothing ...
> > > >
> > > Why nothing, it is referenced further down.
> > > Did you suggest moving before using it?
> > > It was just fine to provide a forward reference.
> > 
> > because it does not say anything about the contents or the format. just some
> > kind of integer.
> > 
> Because it is an integer there is no need of a special format.
> It does say about the content very clearly = vqn / 2;
> But more below.
> 
> > > > I feel what we keep there is really the virtqueue number itself.
> > > > Just stored in this strage format.
> > > >
> > > > And all this talk about handles kind of seems to add yet another term to
> > learn.
> > > > Where in fact all it is, is just a different way to store vqn.
> > > >
> > > > So my idea was this: we say something like:
> > > >
> > > >
> > > > \field{unclassified_queue} contains the virtqueue number of the
> > > > receive queue to place unclassified packets in.
> > > > \field{indirection_table} contains an array of virtqueue numbers of
> > > > receive queues.
> > > >
> > > Above two lines are clearly confusing where virtqueue number describe in
> > rest of the spec and above doesn't align to same notion.
> > 
> > That's true.
> > 
> > > So better to say field A contains the rq_handle and
> > >
> > > struct rq_handle {
> > > 	le16 vqn_16_1: 15;
> > > 	le16 reserved : 1;
> > > };
> > 
> > 
> > 
> > >
> > > > Both \field{unclassified_queue} and \field{indirection_table} use
> > > > the following format for the virtqueue numbers:
> > > > \begin{lstlisting}
> > > > struct rss_virtqueue_number {
> > > It is really not any superior in term of cost of learning.
> > >
> > > > 	le16 vqn_16_1 : 15; /* Bits 16 to 1 of the virtqueue number */
> > > > 	le16 reserved : 1; /* Set to 0 */
> > > I like the structure and reserved bit that enables to claim one bit for some
> > unknown future use.
> > > > }
> > > > \end{lstlisting}
> > > > for example, a value of 3 corresponds to virtqueue number 6 and maps
> > > > to receiveq4.
> > > >
> > > >
> > > >
> > > > and then everywhere else we just say it keeps a vq number, we
> > > > already explained it is using this format once no need to repeat that.
> > > >
> > > I just prefer to rename it to rq_handle ( or at least other than virtqueue
> > number) to distinguish it from rest of the virtqueue number.
> > 
> > Well first of all I really want to make it clear it's specific to RSS at least for now.
> > So let's prefix with rss_.
> Yes, rss_ prefix is good.
> 
> > Maybe I'm wrong but I feel using up a completely new term for something very
> > specific to RSS is a waste.
> > We won't be able to use handle for something else without confusion.
> > So how about just
> > 
> > 	struct rss_rq {
> > 		le16 vqn_16_1 : 15; /* Bits 16 to 1 of the virtqueue number */
> > 		le16 reserved : 1; /* Set to 0 */
> > 	};
> Rq is usually an object and here we want to just refer to its id/vqn/handle.
> 
> Hence, I prefer rss_rq_handle {} or rss_rq_id{} for the structure name.
> WDYT?

_id is ok. But don't define it separately as a special object, it's just
the format of indirection_table and unclassified_queue.
IOW define at point of 1st use.

-- 
MST


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


  reply	other threads:[~2023-03-22 20:57 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-21 21:58 [virtio-comment] [PATCH v3 0/8] Rename queue index to queue number Parav Pandit
2023-03-21 21:58 ` [virtio-dev] " Parav Pandit
2023-03-21 21:58 ` [virtio-comment] [PATCH v3 1/8] content: Add vq number text Parav Pandit
2023-03-21 21:58   ` [virtio-dev] " Parav Pandit
2023-03-21 21:58 ` [virtio-comment] [PATCH v3 2/8] transport-pci: Refer to the vq by its number Parav Pandit
2023-03-21 21:58   ` [virtio-dev] " Parav Pandit
2023-03-21 21:58 ` [virtio-comment] [PATCH v3 3/8] transport-mmio: Rename QueueNum register Parav Pandit
2023-03-21 21:58   ` [virtio-dev] " Parav Pandit
2023-03-21 21:58 ` [virtio-comment] [PATCH v3 4/8] transport-mmio: Refer to the vq by its number Parav Pandit
2023-03-21 21:58   ` [virtio-dev] " Parav Pandit
2023-03-21 21:58 ` [virtio-comment] [PATCH v3 5/8] transport-ccw: Rename queue depth/size to other transports Parav Pandit
2023-03-21 21:58   ` [virtio-dev] " Parav Pandit
2023-03-21 21:58 ` [virtio-comment] [PATCH v3 6/8] transport-ccw: Refer to the vq by its number Parav Pandit
2023-03-21 21:58   ` [virtio-dev] " Parav Pandit
2023-03-21 22:21   ` [virtio-comment] " Michael S. Tsirkin
2023-03-21 22:21     ` [virtio-dev] " Michael S. Tsirkin
2023-03-22  2:45     ` [virtio-comment] " Parav Pandit
2023-03-22  2:45       ` [virtio-dev] " Parav Pandit
2023-03-22  3:53       ` [virtio-comment] " Michael S. Tsirkin
2023-03-22  3:53         ` [virtio-dev] " Michael S. Tsirkin
2023-03-22 16:52         ` [virtio-comment] " Parav Pandit
2023-03-22 16:52           ` [virtio-dev] " Parav Pandit
2023-03-22 16:55           ` [virtio-comment] " Michael S. Tsirkin
2023-03-22 16:55             ` [virtio-dev] " Michael S. Tsirkin
2023-03-22 16:58             ` [virtio-comment] " Parav Pandit
2023-03-22 16:58               ` [virtio-dev] " Parav Pandit
2023-03-21 21:58 ` [virtio-comment] [PATCH v3 7/8] virtio-net: Avoid duplicate receive queue example Parav Pandit
2023-03-21 21:58   ` [virtio-dev] " Parav Pandit
2023-03-21 21:58 ` [virtio-comment] [PATCH v3 8/8] virtio-net: Describe RSS using receive queue handle Parav Pandit
2023-03-21 21:58   ` [virtio-dev] " Parav Pandit
2023-03-21 22:16   ` [virtio-comment] " Michael S. Tsirkin
2023-03-21 22:16     ` [virtio-dev] " Michael S. Tsirkin
2023-03-22  2:37     ` [virtio-comment] " Parav Pandit
2023-03-22  2:37       ` [virtio-dev] " Parav Pandit
2023-03-22  3:46       ` [virtio-comment] " Michael S. Tsirkin
2023-03-22  3:46         ` [virtio-dev] " Michael S. Tsirkin
2023-03-22 17:07         ` [virtio-comment] " Parav Pandit
2023-03-22 17:07           ` [virtio-dev] " Parav Pandit
2023-03-22 20:56           ` Michael S. Tsirkin [this message]
2023-03-22 20:56             ` [virtio-dev] " Michael S. Tsirkin
2023-03-22 22:14             ` [virtio-comment] " Parav Pandit
2023-03-22 22:14               ` [virtio-dev] " Parav Pandit

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=20230322165542-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=parav@nvidia.com \
    --cc=pasic@linux.ibm.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.