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

[Thomas Monjalon <thomas@monjalon.net>]

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.

> 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?
May it be enabled automatically if other debug option is globally enabled?

One comment on the code style: please compare pointers explicitly with NULL
instead of considering them as boolean.