patches for DPDK stable branches
 help / color / mirror / Atom feed
From: Andrew Boyer <aboyer@pensando.io>
To: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Cc: dev@dpdk.org, thomas@monjalon.net, ferruh.yigit@intel.com,
	stable@dpdk.org
Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH] app/testpmd: fix segment number check
Date: Fri, 11 Dec 2020 11:00:20 -0500	[thread overview]
Message-ID: <40F5C8DC-8461-43E4-BF37-16FB1D4CA990@pensando.io> (raw)
In-Reply-To: <1607699265-5238-1-git-send-email-viacheslavo@nvidia.com>



> On Dec 11, 2020, at 10:07 AM, Viacheslav Ovsiienko <viacheslavo@nvidia.com> wrote:
> 
> The --txpkts command line parameter was silently ignored due to
> application was unable to check the Tx queue ring sizes for non
> configured ports [1].

... ignored because the application...

> The "set txpkts <len0[,len1]*>" was also rejected if there
> was some stopped or /unconfigured port.

... was a stopped or unconfigured ...

> 
> This provides the following:
> 
>  - number of segment check is performed against
>    configured Tx queues only
> 
>  - the capability to send single packet is supposed to
>    be very basic and always supported, the setting segment
>    number to 1 is always allowed, no check performed
> 
>  - at the moment of Tx queue setup the descriptor number is
>    checked against configured segment number
> 
> Fixes: 8dae835d88b7 ("app/testpmd: remove restriction on Tx segments set")
> Cc: stable@dpdk.org
> Bugzilla ID: 584
> 
> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
> ---
> app/test-pmd/cmdline.c |  5 +++++
> app/test-pmd/config.c  | 21 ++++++++++++++++-----
> app/test-pmd/testpmd.c |  7 ++++++-
> 3 files changed, 27 insertions(+), 6 deletions(-)
> 
> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
> index 0d2d6aa..86388a2 100644
> --- a/app/test-pmd/cmdline.c
> +++ b/app/test-pmd/cmdline.c
> @@ -2798,6 +2798,11 @@ struct cmd_setup_rxtx_queue {
> 		if (!numa_support || socket_id == NUMA_NO_CONFIG)
> 			socket_id = port->socket_id;
> 
> +		if (port->nb_tx_desc[res->qid] < tx_pkt_nb_segs) {
> +			printf("Failed to setup TX queue: "

setup -> set up
I find it helpful when the numbers are logged in the error message.  Like “nb_desc 8 < nb_segs 16”.

> +			       "not enough descriptors\n");
> +			return;
> +		}

Why is there a relationship between the number of descriptors and the number of segments? For our device, there isn’t. We can send 16 Tx segments per descriptor and (I suppose) you could try to create an 8 descriptor ring.

Maybe this is to protect a simpler device that consumes one descriptor per segment? If so, the check would ideally be conditioned on a related device capability flag. I’m not sure if there is such a flag today.

> 		ret = rte_eth_tx_queue_setup(res->portid,
> 					     res->qid,
> 					     port->nb_tx_desc[res->qid],
> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
> index b51de59..a6fccfa 100644
> --- a/app/test-pmd/config.c
> +++ b/app/test-pmd/config.c
> @@ -3911,12 +3911,18 @@ struct igb_ring_desc_16_bytes {
> 		for (queue_id = 0; queue_id < nb_txq; queue_id++) {
> 			ret = get_tx_ring_size(port_id, queue_id, &ring_size);
> 
> -			if (ret)
> +			/* Do the check only for the active/configured ports. */
> +			if (ret == -EINVAL)
> +				continue;
> +			if (ret) {
> +				printf("failed to get ring size for TX "
> +				       "queue(%u) Port(%u) - txpkts ignored\n",
> +				       port_id, queue_id);
> 				return true;
> -
> +			}
> 			if (ring_size < nb_segs) {
> -				printf("nb segments per TX packets=%u >= "
> -				       "TX queue(%u) ring_size=%u - ignored\n",
> +				printf("nb segments per TX packets=%u >= TX "
> +				       "queue(%u) ring_size=%u - txpkts ignored\n",
> 				       nb_segs, queue_id, ring_size);
> 				return true;
> 			}
> @@ -3932,7 +3938,12 @@ struct igb_ring_desc_16_bytes {
> 	uint16_t tx_pkt_len;
> 	unsigned int i;
> 
> -	if (nb_segs_is_invalid(nb_segs))
> +	/*
> +	 * For single sengment settings failed check is ignored.
> +	 * It is a very basic capability to send the single segment
> +	 * packets, suppose it is always supported.

sengment -> segment
... to send single segment...
suppose -> assume

> +	 */
> +	if (nb_segs > 1 && nb_segs_is_invalid(nb_segs))
> 		return;
> 
> 	/*
> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
> index 33fc0fd..9ea0145 100644
> --- a/app/test-pmd/testpmd.c
> +++ b/app/test-pmd/testpmd.c
> @@ -2575,6 +2575,11 @@ struct extmem_param {
> 			port->need_reconfig_queues = 0;
> 			/* setup tx queues */
> 			for (qi = 0; qi < nb_txq; qi++) {
> +				if (port->nb_tx_desc[qi] < tx_pkt_nb_segs) {
> +					printf("Failed to setup TX queue: "
> +					       "not enough descriptors\n");

Same comments as above

> +					goto fail;
> +				}
> 				if ((numa_support) &&
> 					(txring_numa[pi] != NUMA_NO_CONFIG))
> 					diag = rte_eth_tx_queue_setup(pi, qi,
> @@ -2589,7 +2594,7 @@ struct extmem_param {
> 
> 				if (diag == 0)
> 					continue;
> -
> +fail:
> 				/* Fail to setup tx queue, return */
> 				if (rte_atomic16_cmpset(&(port->port_status),
> 							RTE_PORT_HANDLING,
> -- 
> 1.8.3.1
> 


  reply	other threads:[~2020-12-11 16:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <dc2efa45-23e1-f974-dbab-775977d094d6@intel.com>
2020-12-11 15:07 ` [dpdk-stable] " Viacheslav Ovsiienko
2020-12-11 16:00   ` Andrew Boyer [this message]
2020-12-11 16:14     ` [dpdk-stable] [dpdk-dev] " Slava Ovsiienko
2020-12-16 12:12       ` Ferruh Yigit
2020-12-16 12:33         ` Slava Ovsiienko
2020-12-16 12:36   ` [dpdk-stable] " Ferruh Yigit
2021-04-23 16:09   ` [dpdk-stable] [PATCH v2] " Ferruh Yigit
2021-04-26 11:23     ` Li, Xiaoyun
2021-04-27 11:42       ` Ferruh Yigit

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=40F5C8DC-8461-43E4-BF37-16FB1D4CA990@pensando.io \
    --to=aboyer@pensando.io \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=stable@dpdk.org \
    --cc=thomas@monjalon.net \
    --cc=viacheslavo@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).