RE: [PATCH v2] ethdev: fast path async flow API

[Dariusz Sosnowski <dsosnowski@nvidia.com>]

> -----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