All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Jiawei Wang <jiaweiw@nvidia.com>
Cc: viacheslavo@nvidia.com, orika@nvidia.com,
	Aman Singh <aman.deep.singh@intel.com>,
	Yuying Zhang <yuying.zhang@intel.com>,
	Ferruh Yigit <ferruh.yigit@amd.com>,
	Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
	dev@dpdk.org, rasland@nvidia.com, jerinj@marvell.com
Subject: Re: [RFC 2/5] ethdev: introduce the affinity field in Tx queue API
Date: Wed, 18 Jan 2023 12:37:12 +0100	[thread overview]
Message-ID: <2006382.jNaZZp9DzI@thomas> (raw)
In-Reply-To: <20221221102934.13822-3-jiaweiw@nvidia.com>

21/12/2022 11:29, Jiawei Wang:
> For the multiple hardware ports connect to a single DPDK port (mhpsdp),
> the previous patch introduces the new rte flow item to match the port
> affinity of the received packets.
> 
> This patch adds the tx_affinity setting in Tx queue API, the affinity value
> reflects packets be sent to which hardware port.

I think "affinity" means we would like packet to be sent
on a specific hardware port, but it is not mandatory.
Is it the meaning you want? Or should it be a mandatory port?

> Adds the new tx_affinity field into the padding hole of rte_eth_txconf
> structure, the size of rte_eth_txconf keeps the same. Adds a suppress
> type for structure change in the ABI check file.
> 
> This patch adds the testpmd command line:
> testpmd> port config (port_id) txq (queue_id) affinity (value)
> 
> For example, there're two hardware ports connects to a single DPDK

connects -> connected

> port (port id 0), and affinity 1 stood for hard port 1 and affinity
> 2 stood for hardware port 2, used the below command to config
> tx affinity for each TxQ:
> 	port config 0 txq 0 affinity 1
> 	port config 0 txq 1 affinity 1
> 	port config 0 txq 2 affinity 2
> 	port config 0 txq 3 affinity 2
> 
> These commands config the TxQ index 0 and TxQ index 1 with affinity 1,
> uses TxQ 0 or TxQ 1 send packets, these packets will be sent from the
> hardware port 1, and similar with hardware port 2 if sending packets
> with TxQ 2 or TxQ 3.

[...]
> @@ -212,6 +212,10 @@ API Changes
> +* ethdev: added a new field:
> +
> +  - Tx affinity per-queue ``rte_eth_txconf.tx_affinity``

Adding a new field is not an API change because
existing applications don't need to update their code
if they don't care this new field.
I think you can remove this note.

> --- a/lib/ethdev/rte_ethdev.h
> +++ b/lib/ethdev/rte_ethdev.h
> @@ -1138,6 +1138,7 @@ struct rte_eth_txconf {
>  				      less free descriptors than this value. */
>  
>  	uint8_t tx_deferred_start; /**< Do not start queue with rte_eth_dev_start(). */
> +	uint8_t tx_affinity; /**< Drives the setting of affinity per-queue. */

Why "Drives"? It is the setting, right?
rte_eth_txconf is per-queue so no need to repeat.
I think a good comment here would be to mention it is a physical port index for mhpsdp.
Another good comment would be to specify how ports are numbered.



  parent reply	other threads:[~2023-01-18 11:37 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-21 10:29 [RFC 0/5] add new port affinity item and affinity in Tx queue API Jiawei Wang
2022-12-21 10:29 ` [RFC 1/5] ethdev: add port affinity match item Jiawei Wang
2023-01-11 16:41   ` Ori Kam
2023-01-18 11:07   ` Thomas Monjalon
2023-01-18 14:41     ` Jiawei(Jonny) Wang
2023-01-18 16:26       ` Thomas Monjalon
2023-01-24 14:00         ` Jiawei(Jonny) Wang
2022-12-21 10:29 ` [RFC 2/5] ethdev: introduce the affinity field in Tx queue API Jiawei Wang
2023-01-11 16:47   ` Ori Kam
2023-01-18 11:37   ` Thomas Monjalon [this message]
2023-01-18 14:44     ` Jiawei(Jonny) Wang
2023-01-18 16:31       ` Thomas Monjalon
2023-01-24 13:32         ` Jiawei(Jonny) Wang
2022-12-21 10:29 ` [RFC 3/5] drivers: add lag Rx port affinity in PRM Jiawei Wang
2022-12-21 10:29 ` [RFC 4/5] net/mlx5: add port affinity item support Jiawei Wang
2022-12-21 10:29 ` [RFC 5/5] drivers: enhance the Tx queue affinity Jiawei Wang

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=2006382.jNaZZp9DzI@thomas \
    --to=thomas@monjalon.net \
    --cc=aman.deep.singh@intel.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@amd.com \
    --cc=jerinj@marvell.com \
    --cc=jiaweiw@nvidia.com \
    --cc=orika@nvidia.com \
    --cc=rasland@nvidia.com \
    --cc=viacheslavo@nvidia.com \
    --cc=yuying.zhang@intel.com \
    /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.