From: Thomas Monjalon <thomas@monjalon.net>
To: Dariusz Sosnowski <dsosnowski@nvidia.com>
Cc: Viacheslav 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
Date: Mon, 05 Feb 2024 12:07:39 +0100 [thread overview]
Message-ID: <2171757.irdbgypaU6@thomas> (raw)
In-Reply-To: <20240131093523.1553028-1-dsosnowski@nvidia.com>
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.
next prev parent reply other threads:[~2024-02-05 11:07 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 [this message]
2024-02-05 13:14 ` Dariusz Sosnowski
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=2171757.irdbgypaU6@thomas \
--to=thomas@monjalon.net \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=dev@dpdk.org \
--cc=dsosnowski@nvidia.com \
--cc=ferruh.yigit@amd.com \
--cc=matan@nvidia.com \
--cc=orika@nvidia.com \
--cc=suanmingm@nvidia.com \
--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).