From: Dariusz Sosnowski <dsosnowski@nvidia.com>
To: "NBU-Contact-Thomas Monjalon (EXTERNAL)" <thomas@monjalon.net>
Cc: Slava Ovsiienko <viacheslavo@nvidia.com>,
Ori Kam <orika@nvidia.com>, Suanming Mou <suanmingm@nvidia.com>,
Matan Azrad <matan@nvidia.com>,
Ferruh Yigit <ferruh.yigit@amd.com>,
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: RE: [PATCH v2] ethdev: fast path async flow API
Date: Mon, 5 Feb 2024 13:14:57 +0000 [thread overview]
Message-ID: <IA1PR12MB831179AFE51B4A6812A63877A4472@IA1PR12MB8311.namprd12.prod.outlook.com> (raw)
In-Reply-To: <2171757.irdbgypaU6@thomas>
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Monday, February 5, 2024 12:08
> To: Dariusz Sosnowski <dsosnowski@nvidia.com>
> Cc: Slava Ovsiienko <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>;
> Suanming Mou <suanmingm@nvidia.com>; Matan Azrad
> <matan@nvidia.com>; Ferruh Yigit <ferruh.yigit@amd.com>; Andrew
> Rybchenko <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org
> Subject: Re: [PATCH v2] ethdev: fast path async flow API
>
> 31/01/2024 10:35, Dariusz Sosnowski:
> > This patch reworks the async flow API functions called in data path,
> > to reduce the overhead during flow operations at the library level.
> > Main source of the overhead was indirection and checks done while
> > ethdev library was fetching rte_flow_ops from a given driver.
> >
> > This patch introduces rte_flow_fp_ops struct which holds callbacks to
> > driver's implementation of fast path async flow API functions.
> > Each driver implementing these functions must populate flow_fp_ops
> > field inside rte_eth_dev structure with a reference to its own
> > implementation.
> > By default, ethdev library provides dummy callbacks with
> > implementations returning ENOSYS.
> > Such design provides a few assumptions:
> >
> > - rte_flow_fp_ops struct for given port is always available.
> > - Each callback is either:
> > - Default provided by library.
> > - Set up by driver.
>
> It looks similar to what was done in the commit
> c87d435a4d79 ("ethdev: copy fast-path API into separate structure") right?
> Maybe worth to mention in the commit log.
Right, proposed design is based on what happens in Rx/Tx datapath.
I think it's worth mentioning the commit. I'll add a reference in v3.
> > As a result, no checks for availability of the implementation are
> > needed at library level in data path.
> > Any library-level validation checks in async flow API are compiled if
> > and only if RTE_FLOW_DEBUG macro is defined.
>
> How are we supposed to enable RTE_FLOW_DEBUG?
I should document it, but the idea was that it must be explicitly enabled during build,
by adding -c_args=-DRTE_FLOW_DEBUG to meson options.
Do you think doc/guides/nics/build_and_test.rst is a good place to document this option?
It would be documented alongside RTE_ETHDEV_DEBUG_RX and RTE_ETHDEV_DEBUG_TX.
> May it be enabled automatically if other debug option is globally enabled?
Do you mean that if buildtype is defined as debug, then RTE_FLOW_DEBUG is defined automatically?
I think that's a good idea.
> One comment on the code style: please compare pointers explicitly with NULL
> instead of considering them as boolean.
Ok. I'll fix it and I'll send v3.
Best regards,
Dariusz Sosnowski
next prev parent reply other threads:[~2024-02-05 13:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-30 18:17 [PATCH] " Dariusz Sosnowski
2024-01-31 9:35 ` [PATCH v2] " Dariusz Sosnowski
2024-01-31 13:20 ` Ori Kam
2024-02-05 11:07 ` Thomas Monjalon
2024-02-05 13:14 ` Dariusz Sosnowski [this message]
2024-02-05 14:03 ` Thomas Monjalon
2024-02-06 17:50 ` Dariusz Sosnowski
2024-02-06 17:36 ` [PATCH v3] " Dariusz Sosnowski
2024-02-06 22:21 ` Thomas Monjalon
2024-02-07 0:57 ` Ferruh Yigit
2024-02-07 9:27 ` Thomas Monjalon
2024-02-07 10:47 ` Ferruh Yigit
2024-02-07 10:56 ` Ferruh Yigit
2024-02-07 11:54 ` Ferruh Yigit
2024-02-07 12:06 ` Dariusz Sosnowski
2024-02-07 13:31 ` Thomas Monjalon
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=IA1PR12MB831179AFE51B4A6812A63877A4472@IA1PR12MB8311.namprd12.prod.outlook.com \
--to=dsosnowski@nvidia.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@amd.com \
--cc=matan@nvidia.com \
--cc=orika@nvidia.com \
--cc=suanmingm@nvidia.com \
--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).