Re: [dpdk-dev] [PATCH] app/testpmd: fix segment number check

[Slava Ovsiienko <viacheslavo@nvidia.com>]

Hi, Ferruh

> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Wednesday, December 16, 2020 14:12
> To: Slava Ovsiienko <viacheslavo@nvidia.com>; Andrew Boyer
> <aboyer@pensando.io>
> Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon <thomas@monjalon.net>;
> stable@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] app/testpmd: fix segment number check
> 
> On 12/11/2020 4:14 PM, Slava Ovsiienko wrote:
> > Hi, Andrew
> >
> > Thank you for the review, please, see below.
> >
> >> -----Original Message-----
> >> From: Andrew Boyer <aboyer@pensando.io>
> >> Sent: Friday, December 11, 2020 18:00
> >> To: Slava Ovsiienko <viacheslavo@nvidia.com>
> >> Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon
> <thomas@monjalon.net>;
> >> ferruh.yigit@intel.com; stable@dpdk.org
> >> Subject: Re: [dpdk-dev] [PATCH] app/testpmd: fix segment number check
> >>
> >>
> >>
> >>> 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...
> > OK, will fix.
> >
> >>
> >>> The "set txpkts <len0[,len1]*>" was also rejected if there was some
> >>> stopped or /unconfigured port.
> >>
> >> ... was a stopped or unconfigured ...
> > OK, will fix.
> >
> >>
> >>>
> >>> 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
> > Disagree, it is quite common in testpmd code to use "setup" wording,
> >   I just copy-pasted the message from the neighbor lines.
> >
> >> 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;
> >>> +		}
> >>
> > Do you think it is worth to be informative so much? OK, will add.
> >
> >> 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.
> > There is no correlation between  n_desc and n_seg for Tx in mlx5 PMD either.
> > And there is no information provided how many descriptors should be
> > provided for the multi-segment packets.
> >
> > If we have a look at original commit being fixed
> > ("app/testpmd: remove restriction on Tx segments set") we'll see:
> >
> > -       if (nb_segs >= (unsigned) nb_txd) {
> > -               printf("nb segments per TX packets=%u >= nb_txd=%u - ignored\n",
> > -                      nb_segs, (unsigned int) nb_txd);
> >
> > So, the check was added in replacement for other, more strict, check.
> > Now we are just improving one a little bit.
> >
> 
> Many devices use a descriptor per segment, and if there is no enough free
> descriptor to fit all segments they won't able to send the packet, I guess this
> check is to cover them.
> 
> Out of curiosity, is your device has 16 buffer address fields in the descriptor,
> can they be utilized to send multiple independent packets in single descriptor?
> 
Regarding mlx5 - there is no strong correspondence between WQE (HW desc) and
mbufs. The ConnectX-5+ supports various method of placing data to the descriptors -
by direct data inline or by pointers. In average, with engaged MPW (multipacket-write)
feature we can put up to 4 mbuf pointers into one WQE. WQEs can be combined to
handle 16-or-even-more-mbufs-chain packets. Hence, check for descriptors being discussed 
is still relevant for mlx5 disregarding it is just evaluative.

With best regards, Slava

[snip]