From: Slava Ovsiienko <viacheslavo@nvidia.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>, Andrew Boyer <aboyer@pensando.io>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
NBU-Contact-Thomas Monjalon <thomas@monjalon.net>,
"stable@dpdk.org" <stable@dpdk.org>
Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH] app/testpmd: fix segment number check
Date: Wed, 16 Dec 2020 12:33:27 +0000 [thread overview]
Message-ID: <MWHPR12MB15016180979A802229E398B5DFC50@MWHPR12MB1501.namprd12.prod.outlook.com> (raw)
In-Reply-To: <d6ee6501-28e8-34e9-bad8-b99cde17fe34@intel.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]
next prev parent reply other threads:[~2020-12-16 12:33 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 ` [dpdk-stable] [dpdk-dev] " Andrew Boyer
2020-12-11 16:14 ` Slava Ovsiienko
2020-12-16 12:12 ` Ferruh Yigit
2020-12-16 12:33 ` Slava Ovsiienko [this message]
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=MWHPR12MB15016180979A802229E398B5DFC50@MWHPR12MB1501.namprd12.prod.outlook.com \
--to=viacheslavo@nvidia.com \
--cc=aboyer@pensando.io \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=stable@dpdk.org \
--cc=thomas@monjalon.net \
/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).