Hi, Ferruh
> -----Original Message-----
> From: Ferruh Yigit <ferruh.yi...@intel.com>
> Sent: Wednesday, December 16, 2020 14:12
> To: Slava Ovsiienko <viachesl...@nvidia.com>; Andrew Boyer
> <abo...@pensando.io>
> Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon <tho...@monjalon.net>;
> sta...@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 <abo...@pensando.io>
> >> Sent: Friday, December 11, 2020 18:00
> >> To: Slava Ovsiienko <viachesl...@nvidia.com>
> >> Cc: dev@dpdk.org; NBU-Contact-Thomas Monjalon
> <tho...@monjalon.net>;
> >> ferruh.yi...@intel.com; sta...@dpdk.org
> >> Subject: Re: [dpdk-dev] [PATCH] app/testpmd: fix segment number check
> >>
> >>
> >>
> >>> On Dec 11, 2020, at 10:07 AM, Viacheslav Ovsiienko
> >> <viachesl...@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: sta...@dpdk.org
> >>> Bugzilla ID: 584
> >>>
> >>> Signed-off-by: Viacheslav Ovsiienko <viachesl...@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]
