* Re: [dpdk-dev] [PATCH v14 0/5] Add PIE support for HQoS library
2021-10-15 8:16 3% ` [dpdk-dev] [PATCH v14 " Liguzinski, WojciechX
@ 2021-10-15 13:56 0% ` Dumitrescu, Cristian
0 siblings, 0 replies; 200+ results
From: Dumitrescu, Cristian @ 2021-10-15 13:56 UTC (permalink / raw)
To: Liguzinski, WojciechX, dev, Singh, Jasvinder; +Cc: Ajmera, Megha
> -----Original Message-----
> From: Liguzinski, WojciechX <wojciechx.liguzinski@intel.com>
> Sent: Friday, October 15, 2021 9:16 AM
> To: dev@dpdk.org; Singh, Jasvinder <jasvinder.singh@intel.com>;
> Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
> Cc: Ajmera, Megha <megha.ajmera@intel.com>
> Subject: [PATCH v14 0/5] Add PIE support for HQoS library
>
> DPDK sched library is equipped with mechanism that secures it from the
> bufferbloat problem
> which is a situation when excess buffers in the network cause high latency
> and latency
> variation. Currently, it supports RED for active queue management (which is
> designed
> to control the queue length but it does not control latency directly and is now
> being
> obsoleted).
Please remove the statement that RED is obsolete, as it is not true. Please refer only to the benefits on the new algorithm without any generic negative statements not supported by data versus other algorithms, thank you!
However, more advanced queue management is required to
> address this problem
> and provide desirable quality of service to users.
>
> This solution (RFC) proposes usage of new algorithm called "PIE"
> (Proportional Integral
> controller Enhanced) that can effectively and directly control queuing latency
> to address
> the bufferbloat problem.
>
> The implementation of mentioned functionality includes modification of
> existing and
> adding a new set of data structures to the library, adding PIE related APIs.
> This affects structures in public API/ABI. That is why deprecation notice is
> going
> to be prepared and sent.
>
> Liguzinski, WojciechX (5):
> sched: add PIE based congestion management
> example/qos_sched: add PIE support
> example/ip_pipeline: add PIE support
> doc/guides/prog_guide: added PIE
> app/test: add tests for PIE
>
> app/test/meson.build | 4 +
> app/test/test_pie.c | 1065 ++++++++++++++++++
> config/rte_config.h | 1 -
> doc/guides/prog_guide/glossary.rst | 3 +
> doc/guides/prog_guide/qos_framework.rst | 60 +-
> doc/guides/prog_guide/traffic_management.rst | 13 +-
> drivers/net/softnic/rte_eth_softnic_tm.c | 6 +-
> examples/ip_pipeline/tmgr.c | 142 +--
> examples/qos_sched/app_thread.c | 1 -
> examples/qos_sched/cfg_file.c | 111 +-
> examples/qos_sched/cfg_file.h | 5 +
> examples/qos_sched/init.c | 27 +-
> examples/qos_sched/main.h | 3 +
> examples/qos_sched/profile.cfg | 196 ++--
> lib/sched/meson.build | 10 +-
> lib/sched/rte_pie.c | 86 ++
> lib/sched/rte_pie.h | 398 +++++++
> lib/sched/rte_sched.c | 240 ++--
> lib/sched/rte_sched.h | 63 +-
> lib/sched/version.map | 3 +
> 20 files changed, 2161 insertions(+), 276 deletions(-)
> create mode 100644 app/test/test_pie.c
> create mode 100644 lib/sched/rte_pie.c
> create mode 100644 lib/sched/rte_pie.h
>
> --
> 2.25.1
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3] test/hash: fix buffer overflow
@ 2021-10-15 13:02 3% ` Medvedkin, Vladimir
0 siblings, 0 replies; 200+ results
From: Medvedkin, Vladimir @ 2021-10-15 13:02 UTC (permalink / raw)
To: David Marchand
Cc: dev, Wang, Yipeng1, Gobriel, Sameh, Bruce Richardson, dpdk stable
Hi David,
On 15/10/2021 11:33, David Marchand wrote:
> On Thu, Oct 14, 2021 at 7:55 PM Vladimir Medvedkin
> <vladimir.medvedkin@intel.com> wrote:
>> @@ -1607,6 +1611,17 @@ static struct rte_hash_parameters hash_params_ex = {
>> };
>>
>> /*
>> + * Wrapper function around rte_jhash_32b.
>> + * It is required because rte_jhash_32b() accepts the length
>> + * as size of 4-byte units.
>> + */
>> +static inline uint32_t
>> +test_jhash_32b(const void *k, uint32_t length, uint32_t initval)
>> +{
>> + return rte_jhash_32b(k, length >> 2, initval);
>> +}
>
> I am confused.
> Does it mean that rte_jhash_32b is not compliant with rte_hash_create API?
>
I think so too, because despite the fact that the ABI is the same, the
API remains different with respect to the length argument.
>
--
Regards,
Vladimir
^ permalink raw reply [relevance 3%]
* [dpdk-dev] 回复: [PATCH v2 1/1] devtools: add relative path support for ABI compatibility check
@ 2021-10-15 10:02 4% ` Feifei Wang
0 siblings, 0 replies; 200+ results
From: Feifei Wang @ 2021-10-15 10:02 UTC (permalink / raw)
To: Feifei Wang, Bruce Richardson, thomas, david.marchand
Cc: dev, nd, Phil Yang, Juraj Linkeš, Ruifeng Wang, nd
Hi,
Sorry to disturb you. Have more comments for this patch or if it can be applied?
Thanks very much.
Best Regards
Feifei
> -----邮件原件-----
> 发件人: Feifei Wang <feifei.wang2@arm.com>
> 发送时间: Wednesday, August 11, 2021 2:17 PM
> 收件人: Bruce Richardson <bruce.richardson@intel.com>
> 抄送: dev@dpdk.org; nd <nd@arm.com>; Phil Yang <Phil.Yang@arm.com>;
> Feifei Wang <Feifei.Wang2@arm.com>; Juraj Linkeš
> <juraj.linkes@pantheon.tech>; Ruifeng Wang <Ruifeng.Wang@arm.com>
> 主题: [PATCH v2 1/1] devtools: add relative path support for ABI compatibility
> check
>
> From: Phil Yang <phil.yang@arm.com>
>
> Because dpdk guide does not limit the relative path for ABI compatibility
> check, users maybe set 'DPDK_ABI_REF_DIR' as a relative
> path:
>
> ~/dpdk/devtools$ DPDK_ABI_REF_VERSION=v19.11
> DPDK_ABI_REF_DIR=build-gcc-shared ./test-meson-builds.sh
>
> And if the DESTDIR is not an absolute path, ninja complains:
> + install_target build-gcc-shared/v19.11/build
> + build-gcc-shared/v19.11/build-gcc-shared
> + rm -rf build-gcc-shared/v19.11/build-gcc-shared
> + echo 'DESTDIR=build-gcc-shared/v19.11/build-gcc-shared ninja -C build-gcc-
> shared/v19.11/build install'
> + DESTDIR=build-gcc-shared/v19.11/build-gcc-shared
> + ninja -C build-gcc-shared/v19.11/build install
> ...
> ValueError: dst_dir must be absolute, got build-gcc-shared/v19.11/build-gcc-
> shared/usr/local/share/dpdk/
> examples/bbdev_app
> ...
> Error: install directory 'build-gcc-shared/v19.11/build-gcc-shared' does not
> exist.
>
> To fix this, add relative path support using 'readlink -f'.
>
> Signed-off-by: Phil Yang <phil.yang@arm.com>
> Signed-off-by: Feifei Wang <feifei.wang2@arm.com>
> Reviewed-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
> Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
> devtools/test-meson-builds.sh | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
> index 9ec8e2bc7e..8ddde95276 100755
> --- a/devtools/test-meson-builds.sh
> +++ b/devtools/test-meson-builds.sh
> @@ -168,7 +168,8 @@ build () # <directory> <target cc | cross file> <ABI
> check> [meson options]
> config $srcdir $builds_dir/$targetdir $cross --werror $*
> compile $builds_dir/$targetdir
> if [ -n "$DPDK_ABI_REF_VERSION" -a "$abicheck" = ABI ] ; then
> - abirefdir=${DPDK_ABI_REF_DIR:-
> reference}/$DPDK_ABI_REF_VERSION
> + abirefdir=$(readlink -f \
> + ${DPDK_ABI_REF_DIR:-
> reference}/$DPDK_ABI_REF_VERSION)
> if [ ! -d $abirefdir/$targetdir ]; then
> # clone current sources
> if [ ! -d $abirefdir/src ]; then
> --
> 2.25.1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v4 2/4] mempool: add non-IO flag
2021-10-13 11:01 4% ` [dpdk-dev] [PATCH v4 2/4] mempool: add non-IO flag Dmitry Kozlyuk
@ 2021-10-15 9:01 0% ` Andrew Rybchenko
0 siblings, 0 replies; 200+ results
From: Andrew Rybchenko @ 2021-10-15 9:01 UTC (permalink / raw)
To: Dmitry Kozlyuk, dev; +Cc: Matan Azrad, Olivier Matz
On 10/13/21 2:01 PM, Dmitry Kozlyuk wrote:
> Mempool is a generic allocator that is not necessarily used for device
> IO operations and its memory for DMA. Add MEMPOOL_F_NON_IO flag to mark
> such mempools automatically if their objects are not contiguous
> or IOVA are not available. Components can inspect this flag
> in order to optimize their memory management.
> Discussion: https://mails.dpdk.org/archives/dev/2021-August/216654.html
>
> Signed-off-by: Dmitry Kozlyuk <dkozlyuk@nvidia.com>
> Acked-by: Matan Azrad <matan@nvidia.com>
See review notes below. With review notes processed:
Reviewed-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
[snip]
> diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
> index f643a61f44..74e0e6f495 100644
> --- a/doc/guides/rel_notes/release_21_11.rst
> +++ b/doc/guides/rel_notes/release_21_11.rst
> @@ -226,6 +226,9 @@ API Changes
> the crypto/security operation. This field will be used to communicate
> events such as soft expiry with IPsec in lookaside mode.
>
> +* mempool: Added ``MEMPOOL_F_NON_IO`` flag to give a hint to DPDK components
> + that objects from this pool will not be used for device IO (e.g. DMA).
> +
>
> ABI Changes
> -----------
> diff --git a/lib/mempool/rte_mempool.c b/lib/mempool/rte_mempool.c
> index 51c0ba2931..2204f140b3 100644
> --- a/lib/mempool/rte_mempool.c
> +++ b/lib/mempool/rte_mempool.c
> @@ -371,6 +371,8 @@ rte_mempool_populate_iova(struct rte_mempool *mp, char *vaddr,
>
> STAILQ_INSERT_TAIL(&mp->mem_list, memhdr, next);
> mp->nb_mem_chunks++;
> + if (iova == RTE_BAD_IOVA)
> + mp->flags |= MEMPOOL_F_NON_IO;
As I understand rte_mempool_populate_iova() may be called
few times for one mempool. The flag must be set if all
invocations are done with RTE_BAD_IOVA. So, it should be
set by default and just removed when iova != RTE_BAD_IOVA
happens.
Yes, it is a corner case. May be it makes sense to
cover it by unit test as well.
>
> /* Report the mempool as ready only when fully populated. */
> if (mp->populated_size >= mp->size)
> diff --git a/lib/mempool/rte_mempool.h b/lib/mempool/rte_mempool.h
> index 663123042f..029b62a650 100644
> --- a/lib/mempool/rte_mempool.h
> +++ b/lib/mempool/rte_mempool.h
> @@ -262,6 +262,8 @@ struct rte_mempool {
> #define MEMPOOL_F_SC_GET 0x0008 /**< Default get is "single-consumer".*/
> #define MEMPOOL_F_POOL_CREATED 0x0010 /**< Internal: pool is created. */
> #define MEMPOOL_F_NO_IOVA_CONTIG 0x0020 /**< Don't need IOVA contiguous objs. */
> +#define MEMPOOL_F_NON_IO 0x0040
> + /**< Internal: pool is not usable for device IO (DMA). */
Please, put the documentation before the define.
/** Internal: pool is not usable for device IO (DMA). */
#define MEMPOOL_F_NON_IO 0x0040
>
> /**
> * @internal When debug is enabled, store some statistics.
> @@ -991,6 +993,9 @@ typedef void (rte_mempool_ctor_t)(struct rte_mempool *, void *);
> * "single-consumer". Otherwise, it is "multi-consumers".
> * - MEMPOOL_F_NO_IOVA_CONTIG: If set, allocated objects won't
> * necessarily be contiguous in IO memory.
> + * - MEMPOOL_F_NON_IO: If set, the mempool is considered to be
> + * never used for device IO, i.e. for DMA operations.
> + * It's a hint to other components and does not affect the mempool behavior.
I tend to say that it should not be here if the flag is
internal.
> * @return
> * The pointer to the new allocated mempool, on success. NULL on error
> * with rte_errno set appropriately. Possible rte_errno values include:
>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v14 0/5] Add PIE support for HQoS library
2021-10-14 15:33 3% ` [dpdk-dev] [PATCH v13 " Liguzinski, WojciechX
@ 2021-10-15 8:16 3% ` Liguzinski, WojciechX
2021-10-15 13:56 0% ` Dumitrescu, Cristian
0 siblings, 1 reply; 200+ results
From: Liguzinski, WojciechX @ 2021-10-15 8:16 UTC (permalink / raw)
To: dev, jasvinder.singh, cristian.dumitrescu; +Cc: megha.ajmera
DPDK sched library is equipped with mechanism that secures it from the bufferbloat problem
which is a situation when excess buffers in the network cause high latency and latency
variation. Currently, it supports RED for active queue management (which is designed
to control the queue length but it does not control latency directly and is now being
obsoleted). However, more advanced queue management is required to address this problem
and provide desirable quality of service to users.
This solution (RFC) proposes usage of new algorithm called "PIE" (Proportional Integral
controller Enhanced) that can effectively and directly control queuing latency to address
the bufferbloat problem.
The implementation of mentioned functionality includes modification of existing and
adding a new set of data structures to the library, adding PIE related APIs.
This affects structures in public API/ABI. That is why deprecation notice is going
to be prepared and sent.
Liguzinski, WojciechX (5):
sched: add PIE based congestion management
example/qos_sched: add PIE support
example/ip_pipeline: add PIE support
doc/guides/prog_guide: added PIE
app/test: add tests for PIE
app/test/meson.build | 4 +
app/test/test_pie.c | 1065 ++++++++++++++++++
config/rte_config.h | 1 -
doc/guides/prog_guide/glossary.rst | 3 +
doc/guides/prog_guide/qos_framework.rst | 60 +-
doc/guides/prog_guide/traffic_management.rst | 13 +-
drivers/net/softnic/rte_eth_softnic_tm.c | 6 +-
examples/ip_pipeline/tmgr.c | 142 +--
examples/qos_sched/app_thread.c | 1 -
examples/qos_sched/cfg_file.c | 111 +-
examples/qos_sched/cfg_file.h | 5 +
examples/qos_sched/init.c | 27 +-
examples/qos_sched/main.h | 3 +
examples/qos_sched/profile.cfg | 196 ++--
lib/sched/meson.build | 10 +-
lib/sched/rte_pie.c | 86 ++
lib/sched/rte_pie.h | 398 +++++++
lib/sched/rte_sched.c | 240 ++--
lib/sched/rte_sched.h | 63 +-
lib/sched/version.map | 3 +
20 files changed, 2161 insertions(+), 276 deletions(-)
create mode 100644 app/test/test_pie.c
create mode 100644 lib/sched/rte_pie.c
create mode 100644 lib/sched/rte_pie.h
--
2.25.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v3 08/18] eal: fix typos in comments
@ 2021-10-14 21:56 4% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2021-10-14 21:56 UTC (permalink / raw)
To: dev
Cc: Stephen Hemminger, Ray Kinsella, Dmitry Kozlyuk,
Narcisa Ana Maria Vasile, Dmitry Malloy, Pallavi Kadam
Minor spelling errors.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
lib/eal/include/rte_function_versioning.h | 2 +-
lib/eal/windows/include/fnmatch.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/eal/include/rte_function_versioning.h b/lib/eal/include/rte_function_versioning.h
index 746a1e19923e..eb6dd2bc1727 100644
--- a/lib/eal/include/rte_function_versioning.h
+++ b/lib/eal/include/rte_function_versioning.h
@@ -15,7 +15,7 @@
/*
* Provides backwards compatibility when updating exported functions.
- * When a symol is exported from a library to provide an API, it also provides a
+ * When a symbol is exported from a library to provide an API, it also provides a
* calling convention (ABI) that is embodied in its name, return type,
* arguments, etc. On occasion that function may need to change to accommodate
* new functionality, behavior, etc. When that occurs, it is desirable to
diff --git a/lib/eal/windows/include/fnmatch.h b/lib/eal/windows/include/fnmatch.h
index 142753c3568d..c272f65ccdc3 100644
--- a/lib/eal/windows/include/fnmatch.h
+++ b/lib/eal/windows/include/fnmatch.h
@@ -30,7 +30,7 @@ extern "C" {
* with the given regular expression pattern.
*
* @param pattern
- * regular expression notation decribing the pattern to match
+ * regular expression notation describing the pattern to match
*
* @param string
* source string to searcg for the pattern
--
2.30.2
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] ring: fix size of name array in ring structure
@ 2021-10-14 20:55 11% Honnappa Nagarahalli
0 siblings, 0 replies; 200+ results
From: Honnappa Nagarahalli @ 2021-10-14 20:55 UTC (permalink / raw)
To: dev, honnappa.nagarahalli, andrew.rybchenko, konstantin.ananyev
Cc: nd, zoltan.kiss
Use correct define for the name array size. The change breaks ABI and
hence cannot be backported to stable branches.
Fixes: 38c9817ee1d8 ("mempool: adjust name size in related data types")
Cc: zoltan.kiss@schaman.hu
Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
---
lib/ring/rte_ring_core.h | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/lib/ring/rte_ring_core.h b/lib/ring/rte_ring_core.h
index 31f7200fa9..46ad584f9c 100644
--- a/lib/ring/rte_ring_core.h
+++ b/lib/ring/rte_ring_core.h
@@ -118,12 +118,7 @@ struct rte_ring_hts_headtail {
* a problem.
*/
struct rte_ring {
- /*
- * Note: this field kept the RTE_MEMZONE_NAMESIZE size due to ABI
- * compatibility requirements, it could be changed to RTE_RING_NAMESIZE
- * next time the ABI changes
- */
- char name[RTE_MEMZONE_NAMESIZE] __rte_cache_aligned;
+ char name[RTE_RING_NAMESIZE] __rte_cache_aligned;
/**< Name of the ring. */
int flags; /**< Flags supplied at creation. */
const struct rte_memzone *memzone;
--
2.25.1
^ permalink raw reply [relevance 11%]
* Re: [dpdk-dev] [PATCH v6 1/5] ethdev: update modify field flow action
2021-10-14 12:08 3% ` Ferruh Yigit
@ 2021-10-14 20:07 0% ` Slava Ovsiienko
0 siblings, 0 replies; 200+ results
From: Slava Ovsiienko @ 2021-10-14 20:07 UTC (permalink / raw)
To: Ferruh Yigit, dev
Cc: Raslan Darawsheh, Matan Azrad, Shahaf Shuler, Ori Kam,
Gregory Etelson, NBU-Contact-Thomas Monjalon
There is no actual fixing commits.
I've just followed the practice of removing the deprecation notice in dedicated commit.
So, no extra steps needed, thank you for the patch correction.
With best regards,
Slava
> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Thursday, October 14, 2021 15:09
> To: Slava Ovsiienko <viacheslavo@nvidia.com>; dev@dpdk.org
> Cc: Raslan Darawsheh <rasland@nvidia.com>; Matan Azrad
> <matan@nvidia.com>; Shahaf Shuler <shahafs@nvidia.com>; Ori Kam
> <orika@nvidia.com>; Gregory Etelson <getelson@nvidia.com>; NBU-Contact-
> Thomas Monjalon <thomas@monjalon.net>
> Subject: Re: [dpdk-dev] [PATCH v6 1/5] ethdev: update modify field flow
> action
>
> On 10/13/2021 7:45 PM, Viacheslav Ovsiienko wrote:
> > The generic modify field flow action introduced in [1] has some issues
> > related to the immediate source operand:
> >
> > - immediate source can be presented either as an unsigned
> > 64-bit integer or pointer to data pattern in memory.
> > There was no explicit pointer field defined in the union.
> >
> > - the byte ordering for 64-bit integer was not specified.
> > Many fields have shorter lengths and byte ordering
> > is crucial.
> >
> > - how the bit offset is applied to the immediate source
> > field was not defined and documented.
> >
> > - 64-bit integer size is not enough to provide IPv6
> > addresses.
> >
> > In order to cover the issues and exclude any ambiguities the following
> > is done:
> >
> > - introduce the explicit pointer field
> > in rte_flow_action_modify_data structure
> >
> > - replace the 64-bit unsigned integer with 16-byte array
> >
> > - update the modify field flow action documentation
> >
> > Appropriate deprecation notice has been removed.
> >
> > [1] commit 73b68f4c54a0 ("ethdev: introduce generic modify flow
> > action")
> >
> > Fixes: 2ba49b5f3721 ("doc: announce change to ethdev modify action
> > data")
> >
>
> Hi Viacheslav,
>
> The commit in the 'Fixes' line is the commit that announces the deprecation
> notice, sure this patch is not fixing it.
>
> I am removing the above 'Fixes' line.
>
> This patch is breaking the ABI and it can't be backported anyway, but the
> 'Fixes' line still can be useful for documentation purpose, so if there is valid fix
> commits please share them and I can squash them in next-net.
>
> > Signed-off-by: Viacheslav Ovsiienko<viacheslavo@nvidia.com>
> > Acked-by: Ori Kam<orika@nvidia.com>
> > Acked-by: Andrew Rybchenko<andrew.rybchenko@oktetlabs.ru>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 2/2] net: introduce IPv4 ihl and version fields
2021-10-14 17:41 4% ` [dpdk-dev] [PATCH v7 2/2] " Gregory Etelson
@ 2021-10-14 18:16 0% ` Ajit Khaparde
0 siblings, 0 replies; 200+ results
From: Ajit Khaparde @ 2021-10-14 18:16 UTC (permalink / raw)
To: Gregory Etelson
Cc: dpdk-dev, Matan Azrad, Raslan Darawsheh, Olivier Matz,
Thomas Monjalon, Ferruh Yigit, Ray Kinsella, Bernard Iremonger
On Thu, Oct 14, 2021 at 10:42 AM Gregory Etelson <getelson@nvidia.com> wrote:
>
> RTE IPv4 header definition combines the `version' and `ihl' fields
> into a single structure member.
> This patch introduces dedicated structure members for both `version'
> and `ihl' IPv4 fields. Separated header fields definitions allow to
> create simplified code to match on the IHL value in a flow rule.
> The original `version_ihl' structure member is kept for backward
> compatibility.
>
> Signed-off-by: Gregory Etelson <getelson@nvidia.com>
> Acked-by: Olivier Matz <olivier.matz@6wind.com>
> Acked-by: Ray Kinsella <mdr@ashroe.eu>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
> ---
> v2: Add dependency.
> v3: Add comments.
> v4: Update release notes.
> v5: Remove deprecation notice.
> Update the patch comment.
> v6: split the patch into 2 parts:
> 1: update the announce.
> 2: implement the IPv4 header changes.
> v7: Remove `#else`.
> ---
> app/test/test_flow_classify.c | 8 ++++----
> doc/guides/rel_notes/deprecation.rst | 3 ---
> doc/guides/rel_notes/release_21_11.rst | 3 +++
> lib/net/rte_ip.h | 14 +++++++++++++-
> 4 files changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/app/test/test_flow_classify.c b/app/test/test_flow_classify.c
> index 951606f248..4f64be5357 100644
> --- a/app/test/test_flow_classify.c
> +++ b/app/test/test_flow_classify.c
> @@ -95,7 +95,7 @@ static struct rte_acl_field_def ipv4_defs[NUM_FIELDS_IPV4] = {
> * dst mask 255.255.255.00 / udp src is 32 dst is 33 / end"
> */
> static struct rte_flow_item_ipv4 ipv4_udp_spec_1 = {
> - { 0, 0, 0, 0, 0, 0, IPPROTO_UDP, 0,
> + { { .version_ihl = 0}, 0, 0, 0, 0, 0, IPPROTO_UDP, 0,
> RTE_IPV4(2, 2, 2, 3), RTE_IPV4(2, 2, 2, 7)}
> };
> static const struct rte_flow_item_ipv4 ipv4_mask_24 = {
> @@ -131,7 +131,7 @@ static struct rte_flow_item end_item = { RTE_FLOW_ITEM_TYPE_END,
> * dst mask 255.255.255.00 / tcp src is 16 dst is 17 / end"
> */
> static struct rte_flow_item_ipv4 ipv4_tcp_spec_1 = {
> - { 0, 0, 0, 0, 0, 0, IPPROTO_TCP, 0,
> + { { .version_ihl = 0}, 0, 0, 0, 0, 0, IPPROTO_TCP, 0,
> RTE_IPV4(1, 2, 3, 4), RTE_IPV4(5, 6, 7, 8)}
> };
>
> @@ -150,8 +150,8 @@ static struct rte_flow_item tcp_item_1 = { RTE_FLOW_ITEM_TYPE_TCP,
> * dst mask 255.255.255.00 / sctp src is 16 dst is 17/ end"
> */
> static struct rte_flow_item_ipv4 ipv4_sctp_spec_1 = {
> - { 0, 0, 0, 0, 0, 0, IPPROTO_SCTP, 0, RTE_IPV4(11, 12, 13, 14),
> - RTE_IPV4(15, 16, 17, 18)}
> + { { .version_ihl = 0}, 0, 0, 0, 0, 0, IPPROTO_SCTP, 0,
> + RTE_IPV4(11, 12, 13, 14), RTE_IPV4(15, 16, 17, 18)}
> };
>
> static struct rte_flow_item_sctp sctp_spec_1 = {
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 841653fe30..d1f3faac39 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -158,9 +158,6 @@ Deprecation Notices
> consistent with existing outer header checksum status flag naming, which
> should help in reducing confusion about its usage.
>
> -* net: The structure ``rte_ipv4_hdr`` will have a union for
> - existing ``version_ihl`` byte and new bitfield for ``version`` and ``ihl``.
> -
> * vhost: ``rte_vdpa_register_device``, ``rte_vdpa_unregister_device``,
> ``rte_vhost_host_notifier_ctrl`` and ``rte_vdpa_relay_vring_used`` vDPA
> driver interface will be marked as internal in DPDK v21.11.
> diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
> index e1726774ba..fa60fd9a85 100644
> --- a/doc/guides/rel_notes/release_21_11.rst
> +++ b/doc/guides/rel_notes/release_21_11.rst
> @@ -216,6 +216,9 @@ API Changes
> the crypto/security operation. This field will be used to communicate
> events such as soft expiry with IPsec in lookaside mode.
>
> +* net: Add ``version`` and ``ihl`` bit-fields to ``struct rte_ipv4_hdr``.
> + Existing ``version_ihl`` field was kept for backward compatibility.
> +
>
> ABI Changes
> -----------
> diff --git a/lib/net/rte_ip.h b/lib/net/rte_ip.h
> index b3d45e85db..0ef2430607 100644
> --- a/lib/net/rte_ip.h
> +++ b/lib/net/rte_ip.h
> @@ -39,7 +39,19 @@ extern "C" {
> * IPv4 Header
> */
> struct rte_ipv4_hdr {
> - uint8_t version_ihl; /**< version and header length */
> + __extension__
> + union {
> + uint8_t version_ihl; /**< version and header length */
> + struct {
> +#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
> + uint8_t ihl:4; /**< header length */
> + uint8_t version:4; /**< version */
> +#elif RTE_BYTE_ORDER == RTE_BIG_ENDIAN
> + uint8_t version:4; /**< version */
> + uint8_t ihl:4; /**< header length */
> +#endif
> + };
> + };
> uint8_t type_of_service; /**< type of service */
> rte_be16_t total_length; /**< length of packet */
> rte_be16_t packet_id; /**< packet ID */
> --
> 2.33.0
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [EXT] Re: [PATCH v2 2/6] eal/interrupts: avoid direct access to interrupt handle
2021-10-14 17:31 0% ` [dpdk-dev] [EXT] " Harman Kalra
@ 2021-10-14 17:53 0% ` Dmitry Kozlyuk
0 siblings, 0 replies; 200+ results
From: Dmitry Kozlyuk @ 2021-10-14 17:53 UTC (permalink / raw)
To: Harman Kalra; +Cc: dev, Bruce Richardson, david.marchand, mdr
2021-10-14 17:31 (UTC+0000), Harman Kalra:
> > -----Original Message-----
> > From: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
> > Sent: Thursday, October 14, 2021 6:29 AM
> > To: Harman Kalra <hkalra@marvell.com>
> > Cc: dev@dpdk.org; Bruce Richardson <bruce.richardson@intel.com>;
> > david.marchand@redhat.com; mdr@ashroe.eu
> > Subject: [EXT] Re: [PATCH v2 2/6] eal/interrupts: avoid direct access to
> > interrupt handle
> >
> > External Email
> >
> > ----------------------------------------------------------------------
> > 2021-10-05 17:44 (UTC+0530), Harman Kalra:
> > > Making changes to the interrupt framework to use interrupt handle APIs
> > > to get/set any field. Direct access to any of the fields should be
> > > avoided to avoid any ABI breakage in future.
> >
> > How is ABI breakage applicable to internal consumers?
> >
> > This protects against fields renaming for sure, but convenience is arguable.
> > If EAL needs to add a EAL-private field to struct rte_intr_handle, it must add
> > an accessor even though the field is likely OS-specific.
> > It would be simpler if the definition was in some private EAL header and
> > could be accessed directly by EAL code.
>
> Initially we thought to implement this way only i.e. defining rte_intr_handle inside internal headers
> but supporting out of tree drivers was one of the reason to go via this get/set approach. All drivers
> internal and external should follow the same way, that was the intention.
>
> Thanks
> Harman
True for drivers, I understand this, but the question is about EAL itself.
I shouldn't say "internal consumers", I only meant EAL, not inbox drivers.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v7 2/2] net: introduce IPv4 ihl and version fields
@ 2021-10-14 17:41 4% ` Gregory Etelson
2021-10-14 18:16 0% ` Ajit Khaparde
0 siblings, 1 reply; 200+ results
From: Gregory Etelson @ 2021-10-14 17:41 UTC (permalink / raw)
To: dev, getelson
Cc: matan, rasland, olivier.matz, thomas, ferruh.yigit, Ray Kinsella,
Bernard Iremonger
RTE IPv4 header definition combines the `version' and `ihl' fields
into a single structure member.
This patch introduces dedicated structure members for both `version'
and `ihl' IPv4 fields. Separated header fields definitions allow to
create simplified code to match on the IHL value in a flow rule.
The original `version_ihl' structure member is kept for backward
compatibility.
Signed-off-by: Gregory Etelson <getelson@nvidia.com>
Acked-by: Olivier Matz <olivier.matz@6wind.com>
Acked-by: Ray Kinsella <mdr@ashroe.eu>
---
v2: Add dependency.
v3: Add comments.
v4: Update release notes.
v5: Remove deprecation notice.
Update the patch comment.
v6: split the patch into 2 parts:
1: update the announce.
2: implement the IPv4 header changes.
v7: Remove `#else`.
---
app/test/test_flow_classify.c | 8 ++++----
doc/guides/rel_notes/deprecation.rst | 3 ---
doc/guides/rel_notes/release_21_11.rst | 3 +++
lib/net/rte_ip.h | 14 +++++++++++++-
4 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/app/test/test_flow_classify.c b/app/test/test_flow_classify.c
index 951606f248..4f64be5357 100644
--- a/app/test/test_flow_classify.c
+++ b/app/test/test_flow_classify.c
@@ -95,7 +95,7 @@ static struct rte_acl_field_def ipv4_defs[NUM_FIELDS_IPV4] = {
* dst mask 255.255.255.00 / udp src is 32 dst is 33 / end"
*/
static struct rte_flow_item_ipv4 ipv4_udp_spec_1 = {
- { 0, 0, 0, 0, 0, 0, IPPROTO_UDP, 0,
+ { { .version_ihl = 0}, 0, 0, 0, 0, 0, IPPROTO_UDP, 0,
RTE_IPV4(2, 2, 2, 3), RTE_IPV4(2, 2, 2, 7)}
};
static const struct rte_flow_item_ipv4 ipv4_mask_24 = {
@@ -131,7 +131,7 @@ static struct rte_flow_item end_item = { RTE_FLOW_ITEM_TYPE_END,
* dst mask 255.255.255.00 / tcp src is 16 dst is 17 / end"
*/
static struct rte_flow_item_ipv4 ipv4_tcp_spec_1 = {
- { 0, 0, 0, 0, 0, 0, IPPROTO_TCP, 0,
+ { { .version_ihl = 0}, 0, 0, 0, 0, 0, IPPROTO_TCP, 0,
RTE_IPV4(1, 2, 3, 4), RTE_IPV4(5, 6, 7, 8)}
};
@@ -150,8 +150,8 @@ static struct rte_flow_item tcp_item_1 = { RTE_FLOW_ITEM_TYPE_TCP,
* dst mask 255.255.255.00 / sctp src is 16 dst is 17/ end"
*/
static struct rte_flow_item_ipv4 ipv4_sctp_spec_1 = {
- { 0, 0, 0, 0, 0, 0, IPPROTO_SCTP, 0, RTE_IPV4(11, 12, 13, 14),
- RTE_IPV4(15, 16, 17, 18)}
+ { { .version_ihl = 0}, 0, 0, 0, 0, 0, IPPROTO_SCTP, 0,
+ RTE_IPV4(11, 12, 13, 14), RTE_IPV4(15, 16, 17, 18)}
};
static struct rte_flow_item_sctp sctp_spec_1 = {
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 841653fe30..d1f3faac39 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -158,9 +158,6 @@ Deprecation Notices
consistent with existing outer header checksum status flag naming, which
should help in reducing confusion about its usage.
-* net: The structure ``rte_ipv4_hdr`` will have a union for
- existing ``version_ihl`` byte and new bitfield for ``version`` and ``ihl``.
-
* vhost: ``rte_vdpa_register_device``, ``rte_vdpa_unregister_device``,
``rte_vhost_host_notifier_ctrl`` and ``rte_vdpa_relay_vring_used`` vDPA
driver interface will be marked as internal in DPDK v21.11.
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index e1726774ba..fa60fd9a85 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -216,6 +216,9 @@ API Changes
the crypto/security operation. This field will be used to communicate
events such as soft expiry with IPsec in lookaside mode.
+* net: Add ``version`` and ``ihl`` bit-fields to ``struct rte_ipv4_hdr``.
+ Existing ``version_ihl`` field was kept for backward compatibility.
+
ABI Changes
-----------
diff --git a/lib/net/rte_ip.h b/lib/net/rte_ip.h
index b3d45e85db..0ef2430607 100644
--- a/lib/net/rte_ip.h
+++ b/lib/net/rte_ip.h
@@ -39,7 +39,19 @@ extern "C" {
* IPv4 Header
*/
struct rte_ipv4_hdr {
- uint8_t version_ihl; /**< version and header length */
+ __extension__
+ union {
+ uint8_t version_ihl; /**< version and header length */
+ struct {
+#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
+ uint8_t ihl:4; /**< header length */
+ uint8_t version:4; /**< version */
+#elif RTE_BYTE_ORDER == RTE_BIG_ENDIAN
+ uint8_t version:4; /**< version */
+ uint8_t ihl:4; /**< header length */
+#endif
+ };
+ };
uint8_t type_of_service; /**< type of service */
rte_be16_t total_length; /**< length of packet */
rte_be16_t packet_id; /**< packet ID */
--
2.33.0
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [EXT] Re: [PATCH v2 2/6] eal/interrupts: avoid direct access to interrupt handle
2021-10-14 0:59 3% ` Dmitry Kozlyuk
@ 2021-10-14 17:31 0% ` Harman Kalra
2021-10-14 17:53 0% ` Dmitry Kozlyuk
0 siblings, 1 reply; 200+ results
From: Harman Kalra @ 2021-10-14 17:31 UTC (permalink / raw)
To: Dmitry Kozlyuk; +Cc: dev, Bruce Richardson, david.marchand, mdr
> -----Original Message-----
> From: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
> Sent: Thursday, October 14, 2021 6:29 AM
> To: Harman Kalra <hkalra@marvell.com>
> Cc: dev@dpdk.org; Bruce Richardson <bruce.richardson@intel.com>;
> david.marchand@redhat.com; mdr@ashroe.eu
> Subject: [EXT] Re: [PATCH v2 2/6] eal/interrupts: avoid direct access to
> interrupt handle
>
> External Email
>
> ----------------------------------------------------------------------
> 2021-10-05 17:44 (UTC+0530), Harman Kalra:
> > Making changes to the interrupt framework to use interrupt handle APIs
> > to get/set any field. Direct access to any of the fields should be
> > avoided to avoid any ABI breakage in future.
>
> How is ABI breakage applicable to internal consumers?
>
> This protects against fields renaming for sure, but convenience is arguable.
> If EAL needs to add a EAL-private field to struct rte_intr_handle, it must add
> an accessor even though the field is likely OS-specific.
> It would be simpler if the definition was in some private EAL header and
> could be accessed directly by EAL code.
Initially we thought to implement this way only i.e. defining rte_intr_handle inside internal headers
but supporting out of tree drivers was one of the reason to go via this get/set approach. All drivers
internal and external should follow the same way, that was the intention.
Thanks
Harman
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v10 3/9] security: add UDP params for IPsec NAT-T
2021-10-14 16:03 5% ` [dpdk-dev] [PATCH v10 1/9] security: add ESN field to ipsec_xform Radu Nicolau
@ 2021-10-14 16:03 5% ` Radu Nicolau
1 sibling, 0 replies; 200+ results
From: Radu Nicolau @ 2021-10-14 16:03 UTC (permalink / raw)
To: Ray Kinsella, Akhil Goyal, Declan Doherty
Cc: dev, konstantin.ananyev, vladimir.medvedkin, bruce.richardson,
roy.fan.zhang, hemant.agrawal, anoobj, abhijit.sinha,
daniel.m.buckley, marchana, ktejasree, matan, Radu Nicolau
Add support for specifying UDP port params for UDP encapsulation option.
RFC3948 section-2.1 does not enforce using specific the UDP ports for
UDP-Encapsulated ESP Header
Signed-off-by: Declan Doherty <declan.doherty@intel.com>
Signed-off-by: Radu Nicolau <radu.nicolau@intel.com>
Signed-off-by: Abhijit Sinha <abhijit.sinha@intel.com>
Signed-off-by: Daniel Martin Buckley <daniel.m.buckley@intel.com>
Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
Acked-by: Anoob Joseph <anoobj@marvell.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 5 ++---
doc/guides/rel_notes/release_21_11.rst | 4 ++++
lib/security/rte_security.h | 7 +++++++
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index adec0a5677..a744fdb2c6 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -199,9 +199,8 @@ Deprecation Notices
pointer for the private data to the application which can be attached
to the packet while enqueuing.
-* security: The structure ``rte_security_ipsec_xform`` will be extended with
- multiple fields: source and destination port of UDP encapsulation,
- IPsec payload MSS (Maximum Segment Size).
+* security: The structure ``rte_security_ipsec_xform`` will be extended with:
+ new field: IPsec payload MSS (Maximum Segment Size).
* security: The IPsec SA config options ``struct rte_security_ipsec_sa_options``
will be updated with new fields to support new features like TSO in case of
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index ef078e756a..ed56c16d4b 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -282,6 +282,10 @@ ABI Changes
application to start from an arbitrary ESN value for debug and SA lifetime
enforcement purposes.
+* security: A new structure ``udp`` was added in structure
+ ``rte_security_ipsec_xform`` to allow setting the source and destination ports
+ for UDP encapsulated IPsec traffic.
+
* bbdev: Added capability related to more comprehensive CRC options,
shifting values of the ``enum rte_bbdev_op_ldpcdec_flag_bitmasks``.
diff --git a/lib/security/rte_security.h b/lib/security/rte_security.h
index 764ce83bca..17d0e95412 100644
--- a/lib/security/rte_security.h
+++ b/lib/security/rte_security.h
@@ -128,6 +128,11 @@ struct rte_security_ipsec_tunnel_param {
};
};
+struct rte_security_ipsec_udp_param {
+ uint16_t sport;
+ uint16_t dport;
+};
+
/**
* IPsec Security Association option flags
*/
@@ -326,6 +331,8 @@ struct rte_security_ipsec_xform {
};
} esn;
/**< Extended Sequence Number */
+ struct rte_security_ipsec_udp_param udp;
+ /**< UDP parameters, ignored when udp_encap option not specified */
};
/**
--
2.25.1
^ permalink raw reply [relevance 5%]
* [dpdk-dev] [PATCH v10 1/9] security: add ESN field to ipsec_xform
@ 2021-10-14 16:03 5% ` Radu Nicolau
2021-10-14 16:03 5% ` [dpdk-dev] [PATCH v10 3/9] security: add UDP params for IPsec NAT-T Radu Nicolau
1 sibling, 0 replies; 200+ results
From: Radu Nicolau @ 2021-10-14 16:03 UTC (permalink / raw)
To: Ray Kinsella, Akhil Goyal, Declan Doherty
Cc: dev, konstantin.ananyev, vladimir.medvedkin, bruce.richardson,
roy.fan.zhang, hemant.agrawal, anoobj, abhijit.sinha,
daniel.m.buckley, marchana, ktejasree, matan, Radu Nicolau
Update ipsec_xform definition to include ESN field.
This allows the application to control the ESN starting value.
Signed-off-by: Declan Doherty <declan.doherty@intel.com>
Signed-off-by: Radu Nicolau <radu.nicolau@intel.com>
Signed-off-by: Abhijit Sinha <abhijit.sinha@intel.com>
Signed-off-by: Daniel Martin Buckley <daniel.m.buckley@intel.com>
Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
Acked-by: Anoob Joseph <anoobj@marvell.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 2 +-
doc/guides/rel_notes/release_21_11.rst | 5 +++++
lib/security/rte_security.h | 8 ++++++++
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 45239ca56e..adec0a5677 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -201,7 +201,7 @@ Deprecation Notices
* security: The structure ``rte_security_ipsec_xform`` will be extended with
multiple fields: source and destination port of UDP encapsulation,
- IPsec payload MSS (Maximum Segment Size), and ESN (Extended Sequence Number).
+ IPsec payload MSS (Maximum Segment Size).
* security: The IPsec SA config options ``struct rte_security_ipsec_sa_options``
will be updated with new fields to support new features like TSO in case of
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index 4c56cdfeaa..8bc51a048c 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -273,6 +273,11 @@ ABI Changes
packet IPv4 header checksum and L4 checksum need to be offloaded to
security device.
+* security: A new structure ``esn`` was added in structure
+ ``rte_security_ipsec_xform`` to set an initial ESN value. This permits
+ application to start from an arbitrary ESN value for debug and SA lifetime
+ enforcement purposes.
+
* bbdev: Added capability related to more comprehensive CRC options,
shifting values of the ``enum rte_bbdev_op_ldpcdec_flag_bitmasks``.
diff --git a/lib/security/rte_security.h b/lib/security/rte_security.h
index 7eb9f109ae..764ce83bca 100644
--- a/lib/security/rte_security.h
+++ b/lib/security/rte_security.h
@@ -318,6 +318,14 @@ struct rte_security_ipsec_xform {
/**< Anti replay window size to enable sequence replay attack handling.
* replay checking is disabled if the window size is 0.
*/
+ union {
+ uint64_t value;
+ struct {
+ uint32_t low;
+ uint32_t hi;
+ };
+ } esn;
+ /**< Extended Sequence Number */
};
/**
--
2.25.1
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [RFC PATCH v5 1/5] sched: add PIE based congestion management
@ 2021-10-14 15:13 3% ` Liguzinski, WojciechX
0 siblings, 0 replies; 200+ results
From: Liguzinski, WojciechX @ 2021-10-14 15:13 UTC (permalink / raw)
To: Stephen Hemminger
Cc: dev, Singh, Jasvinder, Dumitrescu, Cristian, Ajmera, Megha
Hi Stephen,
I have applied as much your comments as it could be changed.
Unfortunately, not all calculations could be change to improve performance.
Thanks,
Wojtek
-----Original Message-----
From: Stephen Hemminger <stephen@networkplumber.org>
Sent: Tuesday, September 7, 2021 9:15 PM
To: Liguzinski, WojciechX <wojciechx.liguzinski@intel.com>
Cc: dev@dpdk.org; Singh, Jasvinder <jasvinder.singh@intel.com>; Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Ajmera, Megha <megha.ajmera@intel.com>
Subject: Re: [dpdk-dev] [RFC PATCH v5 1/5] sched: add PIE based congestion management
On Tue, 7 Sep 2021 07:33:24 +0000
"Liguzinski, WojciechX" <wojciechx.liguzinski@intel.com> wrote:
> +/**
> + * @brief make a decision to drop or enqueue a packet based on probability
> + * criteria
> + *
> + * @param pie_cfg [in] config pointer to a PIE configuration
> +parameter structure
> + * @param pie [in, out] data pointer to PIE runtime data
> + * @param time [in] current time (measured in cpu cycles) */ static
> +inline void __rte_experimental _calc_drop_probability(const struct
> +rte_pie_config *pie_cfg,
> + struct rte_pie *pie, uint64_t time)
This code adds a lot of inline functions in the name of performance.
But every inline like this means the internal ABI for the implmentation has to be exposed.
You would probably get a bigger performance bump from not using floating point in the internal math, than the minor performance optimization from having so many inlines.
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v13 0/5] Add PIE support for HQoS library
2021-10-14 15:11 3% ` [dpdk-dev] [PATCH v12 " Liguzinski, WojciechX
@ 2021-10-14 15:33 3% ` Liguzinski, WojciechX
2021-10-15 8:16 3% ` [dpdk-dev] [PATCH v14 " Liguzinski, WojciechX
0 siblings, 1 reply; 200+ results
From: Liguzinski, WojciechX @ 2021-10-14 15:33 UTC (permalink / raw)
To: dev, jasvinder.singh, cristian.dumitrescu; +Cc: megha.ajmera
DPDK sched library is equipped with mechanism that secures it from the bufferbloat problem
which is a situation when excess buffers in the network cause high latency and latency
variation. Currently, it supports RED for active queue management (which is designed
to control the queue length but it does not control latency directly and is now being
obsoleted). However, more advanced queue management is required to address this problem
and provide desirable quality of service to users.
This solution (RFC) proposes usage of new algorithm called "PIE" (Proportional Integral
controller Enhanced) that can effectively and directly control queuing latency to address
the bufferbloat problem.
The implementation of mentioned functionality includes modification of existing and
adding a new set of data structures to the library, adding PIE related APIs.
This affects structures in public API/ABI. That is why deprecation notice is going
to be prepared and sent.
Liguzinski, WojciechX (5):
sched: add PIE based congestion management
example/qos_sched: add PIE support
example/ip_pipeline: add PIE support
doc/guides/prog_guide: added PIE
app/test: add tests for PIE
app/test/autotest_data.py | 18 +
app/test/meson.build | 4 +
app/test/test_pie.c | 1065 ++++++++++++++++++
config/rte_config.h | 1 -
doc/guides/prog_guide/glossary.rst | 3 +
doc/guides/prog_guide/qos_framework.rst | 60 +-
doc/guides/prog_guide/traffic_management.rst | 13 +-
drivers/net/softnic/rte_eth_softnic_tm.c | 6 +-
examples/ip_pipeline/tmgr.c | 142 +--
examples/qos_sched/app_thread.c | 1 -
examples/qos_sched/cfg_file.c | 111 +-
examples/qos_sched/cfg_file.h | 5 +
examples/qos_sched/init.c | 27 +-
examples/qos_sched/main.h | 3 +
examples/qos_sched/profile.cfg | 196 ++--
lib/sched/meson.build | 10 +-
lib/sched/rte_pie.c | 86 ++
lib/sched/rte_pie.h | 398 +++++++
lib/sched/rte_sched.c | 240 ++--
lib/sched/rte_sched.h | 63 +-
lib/sched/version.map | 3 +
21 files changed, 2179 insertions(+), 276 deletions(-)
create mode 100644 app/test/test_pie.c
create mode 100644 lib/sched/rte_pie.c
create mode 100644 lib/sched/rte_pie.h
--
2.25.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v12 0/5] Add PIE support for HQoS library
2021-10-14 12:38 3% ` [dpdk-dev] [PATCH v11 " Liguzinski, WojciechX
@ 2021-10-14 15:11 3% ` Liguzinski, WojciechX
2021-10-14 15:33 3% ` [dpdk-dev] [PATCH v13 " Liguzinski, WojciechX
0 siblings, 1 reply; 200+ results
From: Liguzinski, WojciechX @ 2021-10-14 15:11 UTC (permalink / raw)
To: dev, jasvinder.singh, cristian.dumitrescu; +Cc: megha.ajmera
DPDK sched library is equipped with mechanism that secures it from the bufferbloat problem
which is a situation when excess buffers in the network cause high latency and latency
variation. Currently, it supports RED for active queue management (which is designed
to control the queue length but it does not control latency directly and is now being
obsoleted). However, more advanced queue management is required to address this problem
and provide desirable quality of service to users.
This solution (RFC) proposes usage of new algorithm called "PIE" (Proportional Integral
controller Enhanced) that can effectively and directly control queuing latency to address
the bufferbloat problem.
The implementation of mentioned functionality includes modification of existing and
adding a new set of data structures to the library, adding PIE related APIs.
This affects structures in public API/ABI. That is why deprecation notice is going
to be prepared and sent.
Liguzinski, WojciechX (5):
sched: add PIE based congestion management
example/qos_sched: add PIE support
example/ip_pipeline: add PIE support
doc/guides/prog_guide: added PIE
app/test: add tests for PIE
app/test/autotest_data.py | 18 +
app/test/meson.build | 4 +
app/test/test_pie.c | 1065 ++++++++++++++++++
config/rte_config.h | 1 -
doc/guides/prog_guide/glossary.rst | 3 +
doc/guides/prog_guide/qos_framework.rst | 60 +-
doc/guides/prog_guide/traffic_management.rst | 13 +-
drivers/net/softnic/rte_eth_softnic_tm.c | 6 +-
examples/ip_pipeline/tmgr.c | 142 +--
examples/qos_sched/app_thread.c | 1 -
examples/qos_sched/cfg_file.c | 111 +-
examples/qos_sched/cfg_file.h | 5 +
examples/qos_sched/init.c | 27 +-
examples/qos_sched/main.h | 3 +
examples/qos_sched/profile.cfg | 196 ++--
lib/sched/meson.build | 10 +-
lib/sched/rte_pie.c | 86 ++
lib/sched/rte_pie.h | 398 +++++++
lib/sched/rte_sched.c | 240 ++--
lib/sched/rte_sched.h | 63 +-
lib/sched/version.map | 3 +
21 files changed, 2179 insertions(+), 276 deletions(-)
create mode 100644 app/test/test_pie.c
create mode 100644 lib/sched/rte_pie.c
create mode 100644 lib/sched/rte_pie.h
--
2.25.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v11 0/5] Add PIE support for HQoS library
2021-10-14 11:34 3% ` [dpdk-dev] [PATCH v10 " Liguzinski, WojciechX
@ 2021-10-14 12:38 3% ` Liguzinski, WojciechX
2021-10-14 15:11 3% ` [dpdk-dev] [PATCH v12 " Liguzinski, WojciechX
0 siblings, 1 reply; 200+ results
From: Liguzinski, WojciechX @ 2021-10-14 12:38 UTC (permalink / raw)
To: dev, jasvinder.singh, cristian.dumitrescu; +Cc: megha.ajmera
DPDK sched library is equipped with mechanism that secures it from the bufferbloat problem
which is a situation when excess buffers in the network cause high latency and latency
variation. Currently, it supports RED for active queue management (which is designed
to control the queue length but it does not control latency directly and is now being
obsoleted). However, more advanced queue management is required to address this problem
and provide desirable quality of service to users.
This solution (RFC) proposes usage of new algorithm called "PIE" (Proportional Integral
controller Enhanced) that can effectively and directly control queuing latency to address
the bufferbloat problem.
The implementation of mentioned functionality includes modification of existing and
adding a new set of data structures to the library, adding PIE related APIs.
This affects structures in public API/ABI. That is why deprecation notice is going
to be prepared and sent.
Liguzinski, WojciechX (5):
sched: add PIE based congestion management
example/qos_sched: add PIE support
example/ip_pipeline: add PIE support
doc/guides/prog_guide: added PIE
app/test: add tests for PIE
app/test/autotest_data.py | 18 +
app/test/meson.build | 4 +
app/test/test_pie.c | 1065 ++++++++++++++++++
config/rte_config.h | 1 -
doc/guides/prog_guide/glossary.rst | 3 +
doc/guides/prog_guide/qos_framework.rst | 60 +-
doc/guides/prog_guide/traffic_management.rst | 13 +-
drivers/net/softnic/rte_eth_softnic_tm.c | 6 +-
examples/ip_pipeline/tmgr.c | 142 +--
examples/qos_sched/app_thread.c | 1 -
examples/qos_sched/cfg_file.c | 83 +-
examples/qos_sched/init.c | 27 +-
examples/qos_sched/main.h | 3 +
examples/qos_sched/profile.cfg | 196 ++--
lib/sched/meson.build | 10 +-
lib/sched/rte_pie.c | 86 ++
lib/sched/rte_pie.h | 398 +++++++
lib/sched/rte_sched.c | 240 ++--
lib/sched/rte_sched.h | 63 +-
lib/sched/version.map | 3 +
20 files changed, 2154 insertions(+), 268 deletions(-)
create mode 100644 app/test/test_pie.c
create mode 100644 lib/sched/rte_pie.c
create mode 100644 lib/sched/rte_pie.h
--
2.25.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v3] ci: update machine meson option to platform
2021-10-11 13:40 4% ` [dpdk-dev] [PATCH v3] " Juraj Linkeš
@ 2021-10-14 12:26 0% ` Aaron Conole
0 siblings, 0 replies; 200+ results
From: Aaron Conole @ 2021-10-14 12:26 UTC (permalink / raw)
To: Juraj Linkeš
Cc: thomas, david.marchand, maicolgabriel, dev, ohilyard, ci
Juraj Linkeš <juraj.linkes@pantheon.tech> writes:
> The way we're building DPDK in CI, with -Dmachine=default, has not been
> updated when the option got replaced to preserve a backwards-complatible
> build call to facilitate ABI verification between DPDK versions. Update
> the call to use -Dplatform=generic, which is the most up to date way to
> execute the same build which is now present in all DPDK versions the ABI
> check verifies.
>
> Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
> ---
Acked-by: Aaron Conole <aconole@redhat.com>
Looks like something didn't go well in the UNH environment w.r.t. the
windows compilation for this patch. CC'd the CI list to take a look.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v6 1/5] ethdev: update modify field flow action
2021-10-13 18:45 3% ` [dpdk-dev] [PATCH v6 1/5] " Viacheslav Ovsiienko
@ 2021-10-14 12:08 3% ` Ferruh Yigit
2021-10-14 20:07 0% ` Slava Ovsiienko
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2021-10-14 12:08 UTC (permalink / raw)
To: Viacheslav Ovsiienko, dev
Cc: rasland, matan, shahafs, orika, getelson, thomas
On 10/13/2021 7:45 PM, Viacheslav Ovsiienko wrote:
> The generic modify field flow action introduced in [1] has
> some issues related to the immediate source operand:
>
> - immediate source can be presented either as an unsigned
> 64-bit integer or pointer to data pattern in memory.
> There was no explicit pointer field defined in the union.
>
> - the byte ordering for 64-bit integer was not specified.
> Many fields have shorter lengths and byte ordering
> is crucial.
>
> - how the bit offset is applied to the immediate source
> field was not defined and documented.
>
> - 64-bit integer size is not enough to provide IPv6
> addresses.
>
> In order to cover the issues and exclude any ambiguities
> the following is done:
>
> - introduce the explicit pointer field
> in rte_flow_action_modify_data structure
>
> - replace the 64-bit unsigned integer with 16-byte array
>
> - update the modify field flow action documentation
>
> Appropriate deprecation notice has been removed.
>
> [1] commit 73b68f4c54a0 ("ethdev: introduce generic modify flow action")
>
> Fixes: 2ba49b5f3721 ("doc: announce change to ethdev modify action data")
>
Hi Viacheslav,
The commit in the 'Fixes' line is the commit that announces the deprecation
notice, sure this patch is not fixing it.
I am removing the above 'Fixes' line.
This patch is breaking the ABI and it can't be backported anyway, but
the 'Fixes' line still can be useful for documentation purpose, so if there
is valid fix commits please share them and I can squash them in next-net.
> Signed-off-by: Viacheslav Ovsiienko<viacheslavo@nvidia.com>
> Acked-by: Ori Kam<orika@nvidia.com>
> Acked-by: Andrew Rybchenko<andrew.rybchenko@oktetlabs.ru>
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v10 0/5] Add PIE support for HQoS library
2021-10-11 7:55 3% ` [dpdk-dev] [PATCH v9 " Liguzinski, WojciechX
@ 2021-10-14 11:34 3% ` Liguzinski, WojciechX
2021-10-14 12:38 3% ` [dpdk-dev] [PATCH v11 " Liguzinski, WojciechX
0 siblings, 1 reply; 200+ results
From: Liguzinski, WojciechX @ 2021-10-14 11:34 UTC (permalink / raw)
To: dev, jasvinder.singh, cristian.dumitrescu; +Cc: megha.ajmera
DPDK sched library is equipped with mechanism that secures it from the bufferbloat problem
which is a situation when excess buffers in the network cause high latency and latency
variation. Currently, it supports RED for active queue management (which is designed
to control the queue length but it does not control latency directly and is now being
obsoleted). However, more advanced queue management is required to address this problem
and provide desirable quality of service to users.
This solution (RFC) proposes usage of new algorithm called "PIE" (Proportional Integral
controller Enhanced) that can effectively and directly control queuing latency to address
the bufferbloat problem.
The implementation of mentioned functionality includes modification of existing and
adding a new set of data structures to the library, adding PIE related APIs.
This affects structures in public API/ABI. That is why deprecation notice is going
to be prepared and sent.
Liguzinski, WojciechX (5):
sched: add PIE based congestion management
example/qos_sched: add PIE support
example/ip_pipeline: add PIE support
doc/guides/prog_guide: added PIE
app/test: add tests for PIE
app/test/autotest_data.py | 18 +
app/test/meson.build | 4 +
app/test/test_pie.c | 1065 ++++++++++++++++++
config/rte_config.h | 1 -
doc/guides/prog_guide/glossary.rst | 3 +
doc/guides/prog_guide/qos_framework.rst | 60 +-
doc/guides/prog_guide/traffic_management.rst | 13 +-
drivers/net/softnic/rte_eth_softnic_tm.c | 6 +-
examples/ip_pipeline/tmgr.c | 142 +--
examples/qos_sched/app_thread.c | 1 -
examples/qos_sched/cfg_file.c | 82 +-
examples/qos_sched/init.c | 27 +-
examples/qos_sched/main.h | 3 +
examples/qos_sched/profile.cfg | 196 ++--
lib/sched/meson.build | 10 +-
lib/sched/rte_pie.c | 86 ++
lib/sched/rte_pie.h | 398 +++++++
lib/sched/rte_sched.c | 241 ++--
lib/sched/rte_sched.h | 63 +-
lib/sched/version.map | 3 +
20 files changed, 2154 insertions(+), 268 deletions(-)
create mode 100644 app/test/test_pie.c
create mode 100644 lib/sched/rte_pie.c
create mode 100644 lib/sched/rte_pie.h
--
2.25.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] 回复: [PATCH v6 0/6] hide eth dev related structures
2021-10-13 20:16 0% ` [dpdk-dev] [PATCH v6 0/6] " Ferruh Yigit
@ 2021-10-14 10:12 0% ` Feifei Wang
0 siblings, 0 replies; 200+ results
From: Feifei Wang @ 2021-10-14 10:12 UTC (permalink / raw)
To: Ferruh Yigit, Konstantin Ananyev, dev, jerinj,
Ajit Khaparde (ajit.khaparde@broadcom.com),
Raslan Darawsheh, Andrew Rybchenko, Qi Zhang,
Honnappa Nagarahalli
Cc: xiaoyun.li, anoobj, jerinj, ndabilpuram, adwivedi,
shepard.siegel, ed.czeck, john.miller, irusskikh,
Ajit Khaparde (ajit.khaparde@broadcom.com),
somnath.kotur, rahul.lakkireddy, hemant.agrawal, sachin.saxena,
haiyue.wang, johndale, hyonkim, qi.z.zhang, xiao.w.wang, humin29,
yisen.zhuang, oulijun, beilei.xing, jingjing.wu, qiming.yang,
matan, viacheslavo, sthemmin, longli, heinrich.kuhn, kirankumark,
andrew.rybchenko, mczekaj, jiawenwu, jianwang, maxime.coquelin,
chenbo.xia, thomas, mdr, jay.jayatheerthan, nd
> -----邮件原件-----
> 发件人: dev <dev-bounces@dpdk.org> 代表 Ferruh Yigit
> 发送时间: Thursday, October 14, 2021 4:16 AM
> 收件人: Konstantin Ananyev <konstantin.ananyev@intel.com>;
> dev@dpdk.org; jerinj@marvell.com; Ajit Khaparde
> (ajit.khaparde@broadcom.com) <ajit.khaparde@broadcom.com>; Raslan
> Darawsheh <rasland@nvidia.com>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>; Qi Zhang <qi.z.zhang@intel.com>;
> Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> 抄送: xiaoyun.li@intel.com; anoobj@marvell.com; jerinj@marvell.com;
> ndabilpuram@marvell.com; adwivedi@marvell.com;
> shepard.siegel@atomicrules.com; ed.czeck@atomicrules.com;
> john.miller@atomicrules.com; irusskikh@marvell.com; Ajit Khaparde
> (ajit.khaparde@broadcom.com) <ajit.khaparde@broadcom.com>;
> somnath.kotur@broadcom.com; rahul.lakkireddy@chelsio.com;
> hemant.agrawal@nxp.com; sachin.saxena@oss.nxp.com;
> haiyue.wang@intel.com; johndale@cisco.com; hyonkim@cisco.com;
> qi.z.zhang@intel.com; xiao.w.wang@intel.com; humin29@huawei.com;
> yisen.zhuang@huawei.com; oulijun@huawei.com; beilei.xing@intel.com;
> jingjing.wu@intel.com; qiming.yang@intel.com; matan@nvidia.com;
> viacheslavo@nvidia.com; sthemmin@microsoft.com; longli@microsoft.com;
> heinrich.kuhn@corigine.com; kirankumark@marvell.com;
> andrew.rybchenko@oktetlabs.ru; mczekaj@marvell.com;
> jiawenwu@trustnetic.com; jianwang@trustnetic.com;
> maxime.coquelin@redhat.com; chenbo.xia@intel.com;
> thomas@monjalon.net; mdr@ashroe.eu; jay.jayatheerthan@intel.com
> 主题: Re: [dpdk-dev] [PATCH v6 0/6] hide eth dev related structures
>
> On 10/13/2021 2:36 PM, Konstantin Ananyev wrote:
> > v6 changes:
> > - Update comments (Andrew)
> > - Move callback related variables under corresponding ifdefs (Andrew)
> > - Few nits in rte_eth_macaddrs_get (Andrew)
> > - Rebased on top of next-net tree
> >
> > v5 changes:
> > - Fix spelling (Thomas/David)
> > - Rename internal helper functions (David)
> > - Reorder patches and update commit messages (Thomas)
> > - Update comments (Thomas)
> > - Changed layout in rte_eth_fp_ops, to group functions and
> > related data based on their functionality:
> > first 64B line for Rx, second one for Tx.
> > Didn't observe any real performance difference comparing to
> > original layout. Though decided to keep a new one, as it seems
> > a bit more plausible.
> >
> > v4 changes:
> > - Fix secondary process attach (Pavan)
> > - Fix build failure (Ferruh)
> > - Update lib/ethdev/verion.map (Ferruh)
> > Note that moving newly added symbols from EXPERIMENTAL to DPDK_22
> > section makes checkpatch.sh to complain.
> >
> > v3 changes:
> > - Changes in public struct naming (Jerin/Haiyue)
> > - Split patches
> > - Update docs
> > - Shamelessly included Andrew's patch:
> >
> https://patches.dpdk.org/project/dpdk/patch/20210928154856.1015020-1-
> andrew.rybchenko@oktetlabs.ru/
> > into these series.
> > I have to do similar thing here, so decided to avoid duplicated effort.
> >
> > The aim of these patch series is to make rte_ethdev core data
> > structures (rte_eth_dev, rte_eth_dev_data, rte_eth_rxtx_callback,
> > etc.) internal to DPDK and not visible to the user.
> > That should allow future possible changes to core ethdev related
> > structures to be transparent to the user and help to improve ABI/API
> stability.
> > Note that current ethdev API is preserved, but it is a formal ABI break.
> >
> > The work is based on previous discussions at:
> > https://www.mail-archive.com/dev@dpdk.org/msg211405.html
> > https://www.mail-archive.com/dev@dpdk.org/msg216685.html
> > and consists of the following main points:
> > 1. Copy public 'fast' function pointers (rx_pkt_burst(), etc.) and
> > related data pointer from rte_eth_dev into a separate flat array.
> > We keep it public to still be able to use inline functions for these
> > 'fast' calls (like rte_eth_rx_burst(), etc.) to avoid/minimize slowdown.
> > Note that apart from function pointers itself, each element of this
> > flat array also contains two opaque pointers for each ethdev:
> > 1) a pointer to an array of internal queue data pointers
> > 2) points to array of queue callback data pointers.
> > Note that exposing this extra information allows us to avoid extra
> > changes inside PMD level, plus should help to avoid possible
> > performance degradation.
> > 2. Change implementation of 'fast' inline ethdev functions
> > (rte_eth_rx_burst(), etc.) to use new public flat array.
> > While it is an ABI breakage, this change is intended to be transparent
> > for both users (no changes in user app is required) and PMD developers
> > (no changes in PMD is required).
> > One extra note - with new implementation RX/TX callback invocation
> > will cost one extra function call with this changes. That might cause
> > some slowdown for code-path with RX/TX callbacks heavily involved.
> > Hope such trade-off is acceptable for the community.
> > 3. Move rte_eth_dev, rte_eth_dev_data, rte_eth_rxtx_callback and related
> > things into internal header: <ethdev_driver.h>.
> >
> > That approach was selected to:
> > - Avoid(/minimize) possible performance losses.
> > - Minimize required changes inside PMDs.
> >
> > Performance testing results (ICX 2.0GHz, E810 (ice)):
> > - testpmd macswap fwd mode, plus
> > a) no RX/TX callbacks:
> > no actual slowdown observed
> > b) bpf-load rx 0 0 JM ./dpdk.org/examples/bpf/t3.o:
> > ~2% slowdown
> > - l3fwd: no actual slowdown observed
> >
> > Would like to thank everyone who already reviewed and tested previous
> > versions of these series. All other interested parties please don't be
> > shy and provide your feedback.
> >
> > Konstantin Ananyev (6):
> > ethdev: allocate max space for internal queue array
> > ethdev: change input parameters for rx_queue_count
> > ethdev: copy fast-path API into separate structure
> > ethdev: make fast-path functions to use new flat array
> > ethdev: add API to retrieve multiple ethernet addresses
> > ethdev: hide eth dev related structures
> >
>
> For series,
> Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
>
> No performance regression detected on my testing.
>
> I am merging the series to next-net now which helps testing, but before
> merging to main repo it will be good to get more ack and test results (I can
> squash new tags later).
>
> @Jerin, @Ajit, @Raslan, @Andrew, @Qi, @Honnappa, Can you please test
> this set for any possible regression?
>
> Series applied to dpdk-next-net/main, thanks.
>
For series, there is no performance regression in n1sdp/thunderx2
with i40e and mlx5 40G NIC for l3fwd and testpmd.
Tested-by: Feifei Wang <feifei.wang2@arm.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [EXT] Re: [PATCH v1 2/7] eal/interrupts: implement get set APIs
@ 2021-10-14 9:37 3% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2021-10-14 9:37 UTC (permalink / raw)
To: Harman Kalra
Cc: Thomas Monjalon, dev, Raslan Darawsheh, Ray Kinsella,
Dmitry Kozlyuk, viacheslavo, matan
On Thu, Oct 14, 2021 at 11:31 AM Harman Kalra <hkalra@marvell.com> wrote:
> If we are making it automatic detection, shall we now even have argument to this alloc API?
> I added a flags argument (32 bit) in latest series where each bit of this flag can be an allocation capability.
> I used two bits for discriminating between glibc malloc and rte_malloc. Shall we keep it or drop it?
>
> David, Dmitry please share your thoughts.
I don't have ideas of how we would extend allocations of such object,
so I am unsure.
In doubt, I would keep this flags field, and validate it's always 0
(as mentioned in my reply on ABI).
--
David Marchand
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v3 14/14] eventdev: mark trace variables as internal
@ 2021-10-14 9:28 0% ` Jerin Jacob
0 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2021-10-14 9:28 UTC (permalink / raw)
To: David Marchand
Cc: Pavan Nikhilesh, Ray Kinsella, Jerin Jacob Kollanukkaran, dev
On Wed, Oct 6, 2021 at 12:41 PM David Marchand
<david.marchand@redhat.com> wrote:
>
> Hello Pavan, Ray,
>
> On Wed, Oct 6, 2021 at 8:52 AM <pbhagavatula@marvell.com> wrote:
> >
> > From: Pavan Nikhilesh <pbhagavatula@marvell.com>
> >
> > Mark rte_trace global variables as internal i.e. remove them
> > from experimental section of version map.
> > Some of them are used in inline APIs, mark those as global.
> >
> > Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
> > Acked-by: Ray Kinsella <mdr@ashroe.eu>
>
> Please, sort those symbols.
> I check with ./devtools/update-abi.sh $(cat ABI_VERSION)
>
>
> > ---
> > lib/eventdev/version.map | 77 ++++++++++++++++++----------------------
> > 1 file changed, 35 insertions(+), 42 deletions(-)
> >
> > diff --git a/lib/eventdev/version.map b/lib/eventdev/version.map
> > index 068d186c66..617fff0ae6 100644
> > --- a/lib/eventdev/version.map
> > +++ b/lib/eventdev/version.map
> > @@ -88,57 +88,19 @@ DPDK_22 {
> > rte_event_vector_pool_create;
> > rte_eventdevs;
> >
> > - #added in 21.11
> > - rte_event_fp_ops;
> > -
> > - local: *;
> > -};
> > -
> > -EXPERIMENTAL {
> > - global:
> > -
> > # added in 20.05
>
> At the next ABI bump, ./devtools/update-abi.sh will strip those
> comments from the stable section.
> You can notice this when you run ./devtools/update-abi.sh $CURRENT_ABI
> as suggested above.
Please do the David suggestion on sorting the map file.
> I would strip the comments now that the symbols are going to stable.
> Ray, do you have an opinion?
>
>
> --
> David Marchand
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3 04/14] eventdev: move inline APIs into separate structure
@ 2021-10-14 9:20 0% ` Jerin Jacob
0 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2021-10-14 9:20 UTC (permalink / raw)
To: Pavan Nikhilesh; +Cc: Jerin Jacob, Ray Kinsella, dpdk-dev
On Wed, Oct 6, 2021 at 12:21 PM <pbhagavatula@marvell.com> wrote:
>
> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
>
> Move fastpath inline function pointers from rte_eventdev into a
> separate structure accessed via a flat array.
> The intension is to make rte_eventdev and related structures private
intention
> to avoid future API/ABI breakages.`
>
> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
> Acked-by: Ray Kinsella <mdr@ashroe.eu>
> ---
> lib/eventdev/eventdev_pmd.h | 38 +++++++++++
> lib/eventdev/eventdev_pmd_pci.h | 4 +-
> lib/eventdev/eventdev_private.c | 112 +++++++++++++++++++++++++++++++
> lib/eventdev/meson.build | 1 +
> lib/eventdev/rte_eventdev.c | 22 +++++-
> lib/eventdev/rte_eventdev_core.h | 28 ++++++++
> lib/eventdev/version.map | 6 ++
> 7 files changed, 209 insertions(+), 2 deletions(-)
> create mode 100644 lib/eventdev/eventdev_private.c
>
sources = files(
> + 'eventdev_private.c',
> 'rte_eventdev.c',
> 'rte_event_ring.c',
> 'eventdev_trace_points.c',
Since you are reworking, please sort this in alphabetical order.
>
> +struct rte_event_fp_ops {
> + event_enqueue_t enqueue;
> + /**< PMD enqueue function. */
> + event_enqueue_burst_t enqueue_burst;
> + /**< PMD enqueue burst function. */
> + event_enqueue_burst_t enqueue_new_burst;
> + /**< PMD enqueue burst new function. */
> + event_enqueue_burst_t enqueue_forward_burst;
> + /**< PMD enqueue burst fwd function. */
> + event_dequeue_t dequeue;
> + /**< PMD dequeue function. */
> + event_dequeue_burst_t dequeue_burst;
> + /**< PMD dequeue burst function. */
> + event_tx_adapter_enqueue_t txa_enqueue;
> + /**< PMD Tx adapter enqueue function. */
> + event_tx_adapter_enqueue_t txa_enqueue_same_dest;
> + /**< PMD Tx adapter enqueue same destination function. */
> + event_crypto_adapter_enqueue_t ca_enqueue;
> + /**< PMD Crypto adapter enqueue function. */
> + uintptr_t reserved[2];
> +
> + void **data;
Since access to data is a must for all ops, Please move that to first.
Also, you can merge reserved and reserved2 in that case.
> + /**< points to array of internal port data pointers */
> + uintptr_t reserved2[4];
> +} __rte_cache_aligned;
> +
> +extern struct rte_event_fp_ops rte_event_fp_ops[RTE_EVENT_MAX_DEVS];
> +
> #define RTE_EVENTDEV_NAME_MAX_LEN (64)
> /**< @internal Max length of name of event PMD */
>
> diff --git a/lib/eventdev/version.map b/lib/eventdev/version.map
> index 5f1fe412a4..a3a732089b 100644
> --- a/lib/eventdev/version.map
> +++ b/lib/eventdev/version.map
> @@ -85,6 +85,9 @@ DPDK_22 {
> rte_event_timer_cancel_burst;
> rte_eventdevs;
>
> + #added in 21.11
> + rte_event_fp_ops;
> +
> local: *;
> };
>
> @@ -141,6 +144,9 @@ EXPERIMENTAL {
> INTERNAL {
> global:
>
> + event_dev_fp_ops_reset;
> + event_dev_fp_ops_set;
> + event_dev_probing_finish;
> rte_event_pmd_selftest_seqn_dynfield_offset;
> rte_event_pmd_allocate;
> rte_event_pmd_get_named_dev;
> --
> 2.17.1
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3 01/14] eventdev: make driver interface as internal
@ 2021-10-14 9:08 3% ` Jerin Jacob
2 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2021-10-14 9:08 UTC (permalink / raw)
To: Pavan Nikhilesh
Cc: Jerin Jacob, Shijith Thotton, Timothy McDaniel, Hemant Agrawal,
Nipun Gupta, Mattias Rönnblom, Liang Ma, Peter Mccarthy,
Harry van Haaren, Abhinandan Gujjar, Ray Kinsella, dpdk-dev
On Wed, Oct 6, 2021 at 12:21 PM <pbhagavatula@marvell.com> wrote:
>
> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
>
> Mark all the driver specific functions as internal, remove
> `rte` prefix from `struct rte_eventdev_ops`.
> Remove experimental tag from internal functions.
> Remove `eventdev_pmd.h` from non-internal header files.
>
> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
> ---
> v3 Changes:
> - Reset fp_ops when device is torndown.
> - Add `event_dev_probing_finish()` this function is used for
> post-initialization processing. In current usecase we use it to
> initialize fastpath ops.
>
> v2 Changes:
> - Rework inline flat array by adding port data into it.
> - Rearrange rte_event_timer elements.
>
> drivers/event/cnxk/cn10k_eventdev.c | 6 ++---
> drivers/event/cnxk/cn9k_eventdev.c | 10 ++++-----
> drivers/event/dlb2/dlb2.c | 2 +-
> drivers/event/dpaa/dpaa_eventdev.c | 2 +-
> drivers/event/dpaa2/dpaa2_eventdev.c | 2 +-
> drivers/event/dsw/dsw_evdev.c | 2 +-
> drivers/event/octeontx/ssovf_evdev.c | 2 +-
> drivers/event/octeontx/ssovf_worker.c | 4 ++--
> drivers/event/octeontx2/otx2_evdev.c | 26 +++++++++++-----------
> drivers/event/opdl/opdl_evdev.c | 2 +-
> drivers/event/skeleton/skeleton_eventdev.c | 2 +-
> drivers/event/sw/sw_evdev.c | 2 +-
> lib/eventdev/eventdev_pmd.h | 6 ++++-
> lib/eventdev/eventdev_pmd_pci.h | 4 +++-
> lib/eventdev/eventdev_pmd_vdev.h | 2 ++
> lib/eventdev/meson.build | 6 +++++
> lib/eventdev/rte_event_crypto_adapter.h | 1 -
> lib/eventdev/rte_eventdev.h | 25 ++++++++++++---------
> lib/eventdev/version.map | 17 +++++++------
Please update the release notes for API and ABI changes,
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v4] eventdev/rx_adapter: add telemetry callbacks
@ 2021-10-14 8:25 4% ` Jerin Jacob
0 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2021-10-14 8:25 UTC (permalink / raw)
To: Naga Harish K, S V; +Cc: Kundapura, Ganapati, dev, Jayatheerthan, Jay
On Wed, Oct 13, 2021 at 5:39 PM Naga Harish K, S V
<s.v.naga.harish.k@intel.com> wrote:
>
> Acked-by: Naga Harish K S V <s.v.naga.harish.k@intel.com>
>
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Ganapati Kundapura
> > Sent: Wednesday, October 13, 2021 1:27 PM
> > To: jerinjacobk@gmail.com; dev@dpdk.org
> > Cc: Jayatheerthan, Jay <jay.jayatheerthan@intel.com>
> > Subject: [dpdk-dev] [PATCH v4] eventdev/rx_adapter: add telemetry
> > callbacks
> >
> > Added telemetry callbacks to get Rx adapter stats, reset stats and to get Rx
> > queue config information.
> >
> > Acked-by: Jay Jayatheerthan <jay.jayatheerthan@intel.com>
> >
> > Signed-off-by: Ganapati Kundapura <ganapati.kundapura@intel.com>
> > ---
> > v4:
> > * Addressed segfault when per Rx queue event buffer is used.
> >
> > v3:
> > * Updated release notes.
> > * Addressed review comments.
> >
> > v2:
> > * Fixed checkpatch warning.
> > ---
> >
> > diff --git a/doc/guides/rel_notes/release_21_11.rst
> > b/doc/guides/rel_notes/release_21_11.rst
> > index dfc2cbd..9955e52 100644
> > --- a/doc/guides/rel_notes/release_21_11.rst
> > +++ b/doc/guides/rel_notes/release_21_11.rst
> > @@ -130,6 +130,10 @@ New Features
> > * Added tests to validate packets hard expiry.
> > * Added tests to verify tunnel header verification in IPsec inbound.
> >
> > +* **Updated rte_event_eth_rx_adapter_stats structure
> > + * Added 'uint64_t rx_event_buf_count'
> > + * Added 'uint64_t rx_event_buf_size'
> > +
We need to add this to ABI changed. Updated the patch to add ABI changes
as below
* eventdev: New variables ``rx_event_buf_count`` and ``rx_event_buf_size``
were added in structure ``rte_event_eth_rx_adapter_stats`` to get additional
status.
And Updatde git log as log below:
eventdev/rx_adapter: support telemetry
Added telemetry callbacks to get Rx adapter stats, reset stats and
to get Rx queue config information.
Signed-off-by: Ganapati Kundapura <ganapati.kundapura@intel.com>
Acked-by: Jay Jayatheerthan <jay.jayatheerthan@intel.com>
Acked-by: Naga Harish K S V <s.v.naga.harish.k@intel.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
Applied to dpdk-next-net-eventdev/for-main. Thanks
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs
2021-10-14 8:07 3% ` Xia, Chenbo
@ 2021-10-14 8:25 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2021-10-14 8:25 UTC (permalink / raw)
To: Harris, James R, Walker, Benjamin, Xia, Chenbo
Cc: Liu, Changpeng, David Marchand, dev, Aaron Conole, Zawadzki, Tomasz
14/10/2021 10:07, Xia, Chenbo:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 14/10/2021 09:00, Xia, Chenbo:
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > 14/10/2021 04:21, Xia, Chenbo:
> > > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > > Yes I think we need to agree on functions to keep as-is for
> > compatibility.
> > > > > > Waiting for your input please.
> > > > >
> > > > > So, do you mean currently DPDK doesn't guarantee ABI for drivers
> > > >
> > > > Yes
> > > >
> > > > > but could have driver ABI in the future?
> > > >
> > > > I don't think so, not general compatibility,
> > > > but we can think about a way to avoid breaking SPDK specifically,
> > > > which has less requirements.
> > >
> > > So the problem here is exposing some APIs to SPDK directly? Without the
> > 'enable_driver_sdk'
> > > option, I don't see a solution of both exposed and not-ABI. Any idea in your
> > mind?
> >
> > No the idea is to keep using enable_driver_sdk.
> > But so far, there is no compatibility guarantee for driver SDK.
> > The discussion is about which basic compatibility requirement is needed for
> > SPDK.
>
> Sorry for not understanding your point quickly, but what's the difference of
> 'general compatibility' and 'basic compatibility'? Because in my mind, one
> struct or function should either be ABI-compatible or not. Could you help explain
> it a bit?
I wonder whether we could have a guarantee for a subset of structs and functions.
Anyway, this is just opening the discussion to collect some inputs first.
Then we'll have to check what is possible and get a techboard approval.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs
2021-10-14 7:07 0% ` Thomas Monjalon
@ 2021-10-14 8:07 3% ` Xia, Chenbo
2021-10-14 8:25 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Xia, Chenbo @ 2021-10-14 8:07 UTC (permalink / raw)
To: Thomas Monjalon, Harris, James R, Walker, Benjamin
Cc: Liu, Changpeng, David Marchand, dev, Aaron Conole, Zawadzki, Tomasz
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Thursday, October 14, 2021 3:08 PM
> To: Harris, James R <james.r.harris@intel.com>; Walker, Benjamin
> <benjamin.walker@intel.com>; Xia, Chenbo <chenbo.xia@intel.com>
> Cc: Liu, Changpeng <changpeng.liu@intel.com>; David Marchand
> <david.marchand@redhat.com>; dev@dpdk.org; Aaron Conole <aconole@redhat.com>;
> Zawadzki, Tomasz <tomasz.zawadzki@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs
>
> 14/10/2021 09:00, Xia, Chenbo:
> > From: Thomas Monjalon <thomas@monjalon.net>
> > > 14/10/2021 04:21, Xia, Chenbo:
> > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > Yes I think we need to agree on functions to keep as-is for
> compatibility.
> > > > > Waiting for your input please.
> > > >
> > > > So, do you mean currently DPDK doesn't guarantee ABI for drivers
> > >
> > > Yes
> > >
> > > > but could have driver ABI in the future?
> > >
> > > I don't think so, not general compatibility,
> > > but we can think about a way to avoid breaking SPDK specifically,
> > > which has less requirements.
> >
> > So the problem here is exposing some APIs to SPDK directly? Without the
> 'enable_driver_sdk'
> > option, I don't see a solution of both exposed and not-ABI. Any idea in your
> mind?
>
> No the idea is to keep using enable_driver_sdk.
> But so far, there is no compatibility guarantee for driver SDK.
> The discussion is about which basic compatibility requirement is needed for
> SPDK.
Sorry for not understanding your point quickly, but what's the difference of
'general compatibility' and 'basic compatibility'? Because in my mind, one
struct or function should either be ABI-compatible or not. Could you help explain
it a bit?
Thanks,
Chenbo
>
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2 1/6] eal/interrupts: implement get set APIs
@ 2021-10-14 7:31 3% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2021-10-14 7:31 UTC (permalink / raw)
To: Harman Kalra; +Cc: dev, Thomas Monjalon, Ray Kinsella, Dmitry Kozlyuk
On Tue, Oct 5, 2021 at 2:17 PM Harman Kalra <hkalra@marvell.com> wrote:
> +struct rte_intr_handle *rte_intr_instance_alloc(uint32_t flags)
> +{
> + struct rte_intr_handle *intr_handle;
> + bool mem_allocator;
Regardless of the currently defined flags, we want to have an ABI
ready for future changes, so if there is a "flags" input parameter, it
must be checked against valid values.
You can build a RTE_INTR_ALLOC_KNOWN_FLAGS define that contains all
valid flags either in a private header or only in this .c file if no
other unit needs it.
Next, in this function:
if ((flags & ~RTE_INTR_ALLOC_KNOWN_FLAGS) != 0) {
rte_errno = EINVAL;
return NULL;
}
A check in unit tests is then a good thing to add so that developpers
adding new flag get a CI failure.
This is not a blocker as this API is still experimental, but please
let's do this from the start.
> +
> + mem_allocator = (flags & RTE_INTR_ALLOC_DPDK_ALLOCATOR) != 0;
> + if (mem_allocator)
> + intr_handle = rte_zmalloc(NULL, sizeof(struct rte_intr_handle),
> + 0);
> + else
> + intr_handle = calloc(1, sizeof(struct rte_intr_handle));
--
David Marchand
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs
2021-10-14 7:00 3% ` Xia, Chenbo
@ 2021-10-14 7:07 0% ` Thomas Monjalon
2021-10-14 8:07 3% ` Xia, Chenbo
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2021-10-14 7:07 UTC (permalink / raw)
To: Harris, James R, Walker, Benjamin, Xia, Chenbo
Cc: Liu, Changpeng, David Marchand, dev, Aaron Conole, Zawadzki, Tomasz
14/10/2021 09:00, Xia, Chenbo:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 14/10/2021 04:21, Xia, Chenbo:
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > Yes I think we need to agree on functions to keep as-is for compatibility.
> > > > Waiting for your input please.
> > >
> > > So, do you mean currently DPDK doesn't guarantee ABI for drivers
> >
> > Yes
> >
> > > but could have driver ABI in the future?
> >
> > I don't think so, not general compatibility,
> > but we can think about a way to avoid breaking SPDK specifically,
> > which has less requirements.
>
> So the problem here is exposing some APIs to SPDK directly? Without the 'enable_driver_sdk'
> option, I don't see a solution of both exposed and not-ABI. Any idea in your mind?
No the idea is to keep using enable_driver_sdk.
But so far, there is no compatibility guarantee for driver SDK.
The discussion is about which basic compatibility requirement is needed for SPDK.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v1 1/1] ci: enable DPDK GHA for arm64 with self-hosted runners
2021-10-13 11:32 0% ` Michael Santana
@ 2021-10-14 7:04 0% ` Serena He
0 siblings, 0 replies; 200+ results
From: Serena He @ 2021-10-14 7:04 UTC (permalink / raw)
To: Michael Santana
Cc: dev, nd, Honnappa Nagarahalli, Ruifeng Wang, Dean Arnold, stable,
aconole, maicolgabriel, david.marchand, thomas
Hi Michael, thanks for the feedback, and here are some comments below.
> On 10/13/21 4:03 AM, Serena He wrote:
> > CI jobs are triggered only for repos installed with given GHApp and
> > runners
> >
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Serena He <serena.he@arm.com>
> >
> > ---
> > .github/workflows/build-arm64.yml | 118
> ++++++++++++++++++++++++++++++
> > 1 file changed, 118 insertions(+)
> > create mode 100644 .github/workflows/build-arm64.yml
> >
> > diff --git a/.github/workflows/build-arm64.yml
> > b/.github/workflows/build-arm64.yml
> > new file mode 100644
> > index 0000000000..570563f7c8
> > --- /dev/null
> > +++ b/.github/workflows/build-arm64.yml
> Adding a new workflow should work on our 0-day-bot. We now support
> having multiple workflows so this looks good
Great!
> > @@ -0,0 +1,118 @@
> > +name: build-arm64
> > +
> > +on:
> > + push:
> > + schedule:
> > + - cron: '0 0 * * 1'
> nit: Please add a comment for when this is scheduled so we dont have to do
> cron math :)
Sure, I will add that.
> > +
> > +defaults:
> > + run:
> > + shell: bash --noprofile --norc -exo pipefail {0}
> > +
> > +jobs:
> > + build:
> > + # Here, runners for arm64 are accessed by installed GitHub APP, thus
> will not be available by fork.
> > + # you can change the following 'if' and 'runs-on' if you have your own
> runners installed.
> > + # or request to get your repo on the whitelist to use GitHub APP and
> delete this 'if'.
> I think I understand. I think you mean s/GitHub APP/GitHub/ . otherwise I
> dont know what that is. From my understanding you had to request special
> arm-based runners from github
>
> Are DPDK/dpdk and ovsrobot/dpdk whitelisted to use the arm-based
> runners?
>
> Maybe there was a thread about this in the past that I missed, but where and
> how do you get these arm-based runners from github?
GitHub APPs are integrations with the GitHub APIs and this one provided here will send requests for arm-based runners from AWS cloud. Document will be provided along with the APP to make better understanding after release. DPDK/dpdk and ovsrobot/dpdk are both whitelisted to use.
> > + if: ${{ github.repository == 'DPDK/dpdk' || github.repository ==
> 'ovsrobot/dpdk' }}
[...]
> > + - name: Generate cache keys
> > + id: get_ref_keys
> > + run: |
> > + echo -n '::set-output name=ccache::'
> > + echo 'ccache-${{ matrix.config.os }}-${{ matrix.config.compiler }}-
> ${{ matrix.config.cross }}-'$(date -u +%Y-w%W)
> > + echo -n '::set-output name=libabigail::'
> > + echo 'libabigail-${{ matrix.config.os }}'
> > + echo -n '::set-output name=abi::'
> > + echo 'abi-${{ matrix.config.os }}-${{ matrix.config.compiler }}-
> ${{ matrix.config.cross }}-${{ env.LIBABIGAIL_VERSION }}-
> ${{ env.REF_GIT_TAG }}'
> > + - name: Retrieve ccache cache
> > + uses: actions/cache@v2
> > + with:
> > + path: ~/.ccache
> > + key: ${{ steps.get_ref_keys.outputs.ccache }}-${{ github.ref }}
> > + restore-keys: |
> > + ${{ steps.get_ref_keys.outputs.ccache }}-refs/heads/main
> > + - name: Retrieve libabigail cache
> > + id: libabigail-cache
> > + uses: actions/cache@v2
> > + if: env.ABI_CHECKS == 'true'
> > + with:
> > + path: libabigail
> > + key: ${{ steps.get_ref_keys.outputs.libabigail }}
> > + - name: Retrieve ABI reference cache
> > + uses: actions/cache@v2
> > + if: env.ABI_CHECKS == 'true'
> > + with:
> > + path: reference
> > + key: ${{ steps.get_ref_keys.outputs.abi }}
> > + - name: Update APT cache
> > + run: sudo apt update || true
> > + - name: Install packages
> > + run: sudo apt install -y ccache libnuma-dev python3-setuptools
> > + python3-wheel python3-pip python3-pyelftools ninja-build libbsd-dev
> > + libpcap-dev libibverbs-dev libcrypto++-dev libfdt-dev libjansson-dev
> > + libarchive-dev zlib1g-dev pkgconf
> > + - name: Install libabigail build dependencies if no cache is available
> > + if: env.ABI_CHECKS == 'true' && steps.libabigail-cache.outputs.cache-
> hit != 'true'
> > + run: sudo apt install -y autoconf automake libtool pkg-config libxml2-
> dev
> > + libdw-dev
> Lots of caching stuff. All of it needed?
All these caching stuff is in consistence with the build workflow on GitHub provided runners, so should be needed.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs
2021-10-14 6:41 0% ` Thomas Monjalon
@ 2021-10-14 7:00 3% ` Xia, Chenbo
2021-10-14 7:07 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Xia, Chenbo @ 2021-10-14 7:00 UTC (permalink / raw)
To: Thomas Monjalon, Harris, James R, Walker, Benjamin
Cc: Liu, Changpeng, David Marchand, dev, Aaron Conole, Zawadzki, Tomasz
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Thursday, October 14, 2021 2:42 PM
> To: Harris, James R <james.r.harris@intel.com>; Walker, Benjamin
> <benjamin.walker@intel.com>; Xia, Chenbo <chenbo.xia@intel.com>
> Cc: Liu, Changpeng <changpeng.liu@intel.com>; David Marchand
> <david.marchand@redhat.com>; dev@dpdk.org; Aaron Conole <aconole@redhat.com>;
> Zawadzki, Tomasz <tomasz.zawadzki@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs
>
> 14/10/2021 04:21, Xia, Chenbo:
> > From: Thomas Monjalon <thomas@monjalon.net>
> > > 13/10/2021 19:56, Walker, Benjamin:
> > > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > >
> > > > > In order to be perfectly clear, all the changes done around this
> option
> > > > > enable_driver_sdk share the goal of tidying stuff in DPDK so that ABI
> > > becomes
> > > > > better manageable.
> > > > > I think that nobody want to annoy the SPDK project.
> > > > > I understand that the changes effectively add troubles, and I am sorry
> > > about
> > > > > that. If SPDK and other projects can manage with this change, good.
> > > > > If there is a real blocker, we should discuss what are the options.
> > > > >
> > > > > Thanks for your understanding
> > > >
> > > > I completely understand the desire to make the ABI manageable. If I were
> in
> > > your shoes, I'd be doing the same exact thing. What I don't currently
> > > understand is the motivation behind this enable_driver_sdk option. My
> guess is
> > > that it's one of two things.
> > > >
> > > > \1 ABI manageability: You say that's the purpose above, and that was my
> > > initial assumption. But wouldn't that necessarily mean, over time, no
> longer
> > > considering the symbols that were defined by the header files as part of
> the
> > > stable ABI?
> > >
> > > Absolutely. The idea is that we don't guarantee ABI for the drivers.
> > >
> > > > If you still consider these symbols as part of the ABI in shared library
> > > builds, then the enable_driver_sdk option does absolutely nothing to
> improve
> > > the ABI situation, so why bother to have it at all? We can't have packaged
> > > SPDK relying on symbols in a packaged DPDK that are not part of the
> official
> > > ABI.
> > >
> > > > \2 Not supporting out-of-tree drivers: Another option is that you just
> don't
> > > want people writing out of tree drivers.
> > >
> > > We don't want complications due to support of out-of-tree drivers,
> > > but we don't want to forbid them.
> > >
> > > > You can't just drop it outright because people already do it,
> > > > but you'd like to not support it for shared library builds at least.
> > >
> > > I didn't think about it in these terms.
> > > But saying we don't offer compatibility for shared library drivers
> > > is not too far of "no support" indeed.
> > >
> > > > So I'd like to really understand which of these two motivated the
> > > enable_driver_sdk option . Maybe it's not even one of the two above. If it
> is
> > > #1, then I think maybe we can work with DPDK to define a very small set of
> > > out-of-tree driver APIs/ABIs that need to continue to exist in the shared
> > > libraries by default. I do think SPDK needs only a very small number. If
> it's
> > > #2, then that's the entire SPDK use case and I'd ask you to reconsider the
> > > direction.
> > >
> > > Yes I think we need to agree on functions to keep as-is for compatibility.
> > > Waiting for your input please.
> >
> > So, do you mean currently DPDK doesn't guarantee ABI for drivers
>
> Yes
>
> > but could have driver ABI in the future?
>
> I don't think so, not general compatibility,
> but we can think about a way to avoid breaking SPDK specifically,
> which has less requirements.
So the problem here is exposing some APIs to SPDK directly? Without the 'enable_driver_sdk'
option, I don't see a solution of both exposed and not-ABI. Any idea in your mind?
Thanks,
Chenbo
>
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs
2021-10-13 22:48 3% ` Walker, Benjamin
@ 2021-10-14 6:41 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2021-10-14 6:41 UTC (permalink / raw)
To: Harris, James R, Walker, Benjamin
Cc: Liu, Changpeng, Xia, Chenbo, David Marchand, dev, Aaron Conole,
Zawadzki, Tomasz
14/10/2021 00:48, Walker, Benjamin:
> > From: Thomas Monjalon <thomas@monjalon.net>
>
> > Yes I think we need to agree on functions to keep as-is for compatibility.
> > Waiting for your input please.
>
> We've added a task to our backlog to propose a stable ABI for out of tree drivers here. It's not as simple as just keeping a couple of the existing functions - we're currently manipulating structures directly. We'll need to work a bit to design the simplest possible set of functions that we need.
OK thanks
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs
2021-10-14 2:21 4% ` Xia, Chenbo
@ 2021-10-14 6:41 0% ` Thomas Monjalon
2021-10-14 7:00 3% ` Xia, Chenbo
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2021-10-14 6:41 UTC (permalink / raw)
To: Harris, James R, Walker, Benjamin, Xia, Chenbo
Cc: Liu, Changpeng, David Marchand, dev, Aaron Conole, Zawadzki, Tomasz
14/10/2021 04:21, Xia, Chenbo:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 13/10/2021 19:56, Walker, Benjamin:
> > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > >
> > > > In order to be perfectly clear, all the changes done around this option
> > > > enable_driver_sdk share the goal of tidying stuff in DPDK so that ABI
> > becomes
> > > > better manageable.
> > > > I think that nobody want to annoy the SPDK project.
> > > > I understand that the changes effectively add troubles, and I am sorry
> > about
> > > > that. If SPDK and other projects can manage with this change, good.
> > > > If there is a real blocker, we should discuss what are the options.
> > > >
> > > > Thanks for your understanding
> > >
> > > I completely understand the desire to make the ABI manageable. If I were in
> > your shoes, I'd be doing the same exact thing. What I don't currently
> > understand is the motivation behind this enable_driver_sdk option. My guess is
> > that it's one of two things.
> > >
> > > \1 ABI manageability: You say that's the purpose above, and that was my
> > initial assumption. But wouldn't that necessarily mean, over time, no longer
> > considering the symbols that were defined by the header files as part of the
> > stable ABI?
> >
> > Absolutely. The idea is that we don't guarantee ABI for the drivers.
> >
> > > If you still consider these symbols as part of the ABI in shared library
> > builds, then the enable_driver_sdk option does absolutely nothing to improve
> > the ABI situation, so why bother to have it at all? We can't have packaged
> > SPDK relying on symbols in a packaged DPDK that are not part of the official
> > ABI.
> >
> > > \2 Not supporting out-of-tree drivers: Another option is that you just don't
> > want people writing out of tree drivers.
> >
> > We don't want complications due to support of out-of-tree drivers,
> > but we don't want to forbid them.
> >
> > > You can't just drop it outright because people already do it,
> > > but you'd like to not support it for shared library builds at least.
> >
> > I didn't think about it in these terms.
> > But saying we don't offer compatibility for shared library drivers
> > is not too far of "no support" indeed.
> >
> > > So I'd like to really understand which of these two motivated the
> > enable_driver_sdk option . Maybe it's not even one of the two above. If it is
> > #1, then I think maybe we can work with DPDK to define a very small set of
> > out-of-tree driver APIs/ABIs that need to continue to exist in the shared
> > libraries by default. I do think SPDK needs only a very small number. If it's
> > #2, then that's the entire SPDK use case and I'd ask you to reconsider the
> > direction.
> >
> > Yes I think we need to agree on functions to keep as-is for compatibility.
> > Waiting for your input please.
>
> So, do you mean currently DPDK doesn't guarantee ABI for drivers
Yes
> but could have driver ABI in the future?
I don't think so, not general compatibility,
but we can think about a way to avoid breaking SPDK specifically,
which has less requirements.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs
2021-10-13 18:59 3% ` Thomas Monjalon
2021-10-13 22:48 3% ` Walker, Benjamin
@ 2021-10-14 2:21 4% ` Xia, Chenbo
2021-10-14 6:41 0% ` Thomas Monjalon
1 sibling, 1 reply; 200+ results
From: Xia, Chenbo @ 2021-10-14 2:21 UTC (permalink / raw)
To: Thomas Monjalon, Harris, James R, Walker, Benjamin
Cc: Liu, Changpeng, David Marchand, dev, Aaron Conole, Zawadzki, Tomasz
Hi Thomas,
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Thursday, October 14, 2021 3:00 AM
> To: Harris, James R <james.r.harris@intel.com>; Walker, Benjamin
> <benjamin.walker@intel.com>
> Cc: Liu, Changpeng <changpeng.liu@intel.com>; Xia, Chenbo
> <chenbo.xia@intel.com>; David Marchand <david.marchand@redhat.com>;
> dev@dpdk.org; Aaron Conole <aconole@redhat.com>; Zawadzki, Tomasz
> <tomasz.zawadzki@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs
>
> 13/10/2021 19:56, Walker, Benjamin:
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > >
> > > In order to be perfectly clear, all the changes done around this option
> > > enable_driver_sdk share the goal of tidying stuff in DPDK so that ABI
> becomes
> > > better manageable.
> > > I think that nobody want to annoy the SPDK project.
> > > I understand that the changes effectively add troubles, and I am sorry
> about
> > > that. If SPDK and other projects can manage with this change, good.
> > > If there is a real blocker, we should discuss what are the options.
> > >
> > > Thanks for your understanding
> >
> > I completely understand the desire to make the ABI manageable. If I were in
> your shoes, I'd be doing the same exact thing. What I don't currently
> understand is the motivation behind this enable_driver_sdk option. My guess is
> that it's one of two things.
> >
> > \1 ABI manageability: You say that's the purpose above, and that was my
> initial assumption. But wouldn't that necessarily mean, over time, no longer
> considering the symbols that were defined by the header files as part of the
> stable ABI?
>
> Absolutely. The idea is that we don't guarantee ABI for the drivers.
>
> > If you still consider these symbols as part of the ABI in shared library
> builds, then the enable_driver_sdk option does absolutely nothing to improve
> the ABI situation, so why bother to have it at all? We can't have packaged
> SPDK relying on symbols in a packaged DPDK that are not part of the official
> ABI.
>
> > \2 Not supporting out-of-tree drivers: Another option is that you just don't
> want people writing out of tree drivers.
>
> We don't want complications due to support of out-of-tree drivers,
> but we don't want to forbid them.
>
> > You can't just drop it outright because people already do it,
> > but you'd like to not support it for shared library builds at least.
>
> I didn't think about it in these terms.
> But saying we don't offer compatibility for shared library drivers
> is not too far of "no support" indeed.
>
> > So I'd like to really understand which of these two motivated the
> enable_driver_sdk option . Maybe it's not even one of the two above. If it is
> #1, then I think maybe we can work with DPDK to define a very small set of
> out-of-tree driver APIs/ABIs that need to continue to exist in the shared
> libraries by default. I do think SPDK needs only a very small number. If it's
> #2, then that's the entire SPDK use case and I'd ask you to reconsider the
> direction.
>
> Yes I think we need to agree on functions to keep as-is for compatibility.
> Waiting for your input please.
So, do you mean currently DPDK doesn't guarantee ABI for drivers but could have
driver ABI in the future?
Thanks,
Chenbo
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v2 2/6] eal/interrupts: avoid direct access to interrupt handle
@ 2021-10-14 0:59 3% ` Dmitry Kozlyuk
2021-10-14 17:31 0% ` [dpdk-dev] [EXT] " Harman Kalra
0 siblings, 1 reply; 200+ results
From: Dmitry Kozlyuk @ 2021-10-14 0:59 UTC (permalink / raw)
To: Harman Kalra; +Cc: dev, Bruce Richardson, david.marchand, mdr
2021-10-05 17:44 (UTC+0530), Harman Kalra:
> Making changes to the interrupt framework to use interrupt handle
> APIs to get/set any field. Direct access to any of the fields
> should be avoided to avoid any ABI breakage in future.
How is ABI breakage applicable to internal consumers?
This protects against fields renaming for sure, but convenience is arguable.
If EAL needs to add a EAL-private field to struct rte_intr_handle,
it must add an accessor even though the field is likely OS-specific.
It would be simpler if the definition was in some private EAL header
and could be accessed directly by EAL code.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs
2021-10-13 18:59 3% ` Thomas Monjalon
@ 2021-10-13 22:48 3% ` Walker, Benjamin
2021-10-14 6:41 0% ` Thomas Monjalon
2021-10-14 2:21 4% ` Xia, Chenbo
1 sibling, 1 reply; 200+ results
From: Walker, Benjamin @ 2021-10-13 22:48 UTC (permalink / raw)
To: Thomas Monjalon, Harris, James R
Cc: Liu, Changpeng, Xia, Chenbo, David Marchand, dev, Aaron Conole,
Zawadzki, Tomasz
> From: Thomas Monjalon <thomas@monjalon.net>
> Yes I think we need to agree on functions to keep as-is for compatibility.
> Waiting for your input please.
We've added a task to our backlog to propose a stable ABI for out of tree drivers here. It's not as simple as just keeping a couple of the existing functions - we're currently manipulating structures directly. We'll need to work a bit to design the simplest possible set of functions that we need.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] mempool: fix name size in mempool structure
2021-10-13 11:07 4% ` David Marchand
2021-10-13 11:14 0% ` Andrew Rybchenko
@ 2021-10-13 20:58 0% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Thomas Monjalon @ 2021-10-13 20:58 UTC (permalink / raw)
To: Andrew Rybchenko
Cc: dev, Olivier Matz, Zoltan Kiss, dev, Ray Kinsella, David Marchand
13/10/2021 13:07, David Marchand:
> On Wed, Oct 13, 2021 at 10:57 AM Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru> wrote:
> >
> > Use correct define as a name array size.
> >
> > The change breaks ABI and therefore cannot be backported to
> > stable branches.
> >
> > Fixes: 38c9817ee1d8 ("mempool: adjust name size in related data types")
> >
> > Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>
> Reviewed-by: David Marchand <david.marchand@redhat.com>
Applied, thanks.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v6 0/6] hide eth dev related structures
2021-10-13 13:36 4% ` [dpdk-dev] [PATCH v6 0/6] hide eth dev related structures Konstantin Ananyev
` (3 preceding siblings ...)
2021-10-13 13:37 8% ` [dpdk-dev] [PATCH v6 6/6] ethdev: hide eth dev related structures Konstantin Ananyev
@ 2021-10-13 20:16 0% ` Ferruh Yigit
2021-10-14 10:12 0% ` [dpdk-dev] 回复: " Feifei Wang
4 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2021-10-13 20:16 UTC (permalink / raw)
To: Konstantin Ananyev, dev, jerinj, Ajit Khaparde, Raslan Darawsheh,
Andrew Rybchenko, Qi Zhang, Honnappa Nagarahalli
Cc: xiaoyun.li, anoobj, jerinj, ndabilpuram, adwivedi,
shepard.siegel, ed.czeck, john.miller, irusskikh, ajit.khaparde,
somnath.kotur, rahul.lakkireddy, hemant.agrawal, sachin.saxena,
haiyue.wang, johndale, hyonkim, qi.z.zhang, xiao.w.wang, humin29,
yisen.zhuang, oulijun, beilei.xing, jingjing.wu, qiming.yang,
matan, viacheslavo, sthemmin, longli, heinrich.kuhn, kirankumark,
andrew.rybchenko, mczekaj, jiawenwu, jianwang, maxime.coquelin,
chenbo.xia, thomas, mdr, jay.jayatheerthan
On 10/13/2021 2:36 PM, Konstantin Ananyev wrote:
> v6 changes:
> - Update comments (Andrew)
> - Move callback related variables under corresponding ifdefs (Andrew)
> - Few nits in rte_eth_macaddrs_get (Andrew)
> - Rebased on top of next-net tree
>
> v5 changes:
> - Fix spelling (Thomas/David)
> - Rename internal helper functions (David)
> - Reorder patches and update commit messages (Thomas)
> - Update comments (Thomas)
> - Changed layout in rte_eth_fp_ops, to group functions and
> related data based on their functionality:
> first 64B line for Rx, second one for Tx.
> Didn't observe any real performance difference comparing to
> original layout. Though decided to keep a new one, as it seems
> a bit more plausible.
>
> v4 changes:
> - Fix secondary process attach (Pavan)
> - Fix build failure (Ferruh)
> - Update lib/ethdev/verion.map (Ferruh)
> Note that moving newly added symbols from EXPERIMENTAL to DPDK_22
> section makes checkpatch.sh to complain.
>
> v3 changes:
> - Changes in public struct naming (Jerin/Haiyue)
> - Split patches
> - Update docs
> - Shamelessly included Andrew's patch:
> https://patches.dpdk.org/project/dpdk/patch/20210928154856.1015020-1-andrew.rybchenko@oktetlabs.ru/
> into these series.
> I have to do similar thing here, so decided to avoid duplicated effort.
>
> The aim of these patch series is to make rte_ethdev core data structures
> (rte_eth_dev, rte_eth_dev_data, rte_eth_rxtx_callback, etc.) internal to
> DPDK and not visible to the user.
> That should allow future possible changes to core ethdev related structures
> to be transparent to the user and help to improve ABI/API stability.
> Note that current ethdev API is preserved, but it is a formal ABI break.
>
> The work is based on previous discussions at:
> https://www.mail-archive.com/dev@dpdk.org/msg211405.html
> https://www.mail-archive.com/dev@dpdk.org/msg216685.html
> and consists of the following main points:
> 1. Copy public 'fast' function pointers (rx_pkt_burst(), etc.) and
> related data pointer from rte_eth_dev into a separate flat array.
> We keep it public to still be able to use inline functions for these
> 'fast' calls (like rte_eth_rx_burst(), etc.) to avoid/minimize slowdown.
> Note that apart from function pointers itself, each element of this
> flat array also contains two opaque pointers for each ethdev:
> 1) a pointer to an array of internal queue data pointers
> 2) points to array of queue callback data pointers.
> Note that exposing this extra information allows us to avoid extra
> changes inside PMD level, plus should help to avoid possible
> performance degradation.
> 2. Change implementation of 'fast' inline ethdev functions
> (rte_eth_rx_burst(), etc.) to use new public flat array.
> While it is an ABI breakage, this change is intended to be transparent
> for both users (no changes in user app is required) and PMD developers
> (no changes in PMD is required).
> One extra note - with new implementation RX/TX callback invocation
> will cost one extra function call with this changes. That might cause
> some slowdown for code-path with RX/TX callbacks heavily involved.
> Hope such trade-off is acceptable for the community.
> 3. Move rte_eth_dev, rte_eth_dev_data, rte_eth_rxtx_callback and related
> things into internal header: <ethdev_driver.h>.
>
> That approach was selected to:
> - Avoid(/minimize) possible performance losses.
> - Minimize required changes inside PMDs.
>
> Performance testing results (ICX 2.0GHz, E810 (ice)):
> - testpmd macswap fwd mode, plus
> a) no RX/TX callbacks:
> no actual slowdown observed
> b) bpf-load rx 0 0 JM ./dpdk.org/examples/bpf/t3.o:
> ~2% slowdown
> - l3fwd: no actual slowdown observed
>
> Would like to thank everyone who already reviewed and tested previous
> versions of these series. All other interested parties please don't be shy
> and provide your feedback.
>
> Konstantin Ananyev (6):
> ethdev: allocate max space for internal queue array
> ethdev: change input parameters for rx_queue_count
> ethdev: copy fast-path API into separate structure
> ethdev: make fast-path functions to use new flat array
> ethdev: add API to retrieve multiple ethernet addresses
> ethdev: hide eth dev related structures
>
For series,
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
No performance regression detected on my testing.
I am merging the series to next-net now which helps testing,
but before merging to main repo it will be good to get more
ack and test results (I can squash new tags later).
@Jerin, @Ajit, @Raslan, @Andrew, @Qi, @Honnappa,
Can you please test this set for any possible regression?
Series applied to dpdk-next-net/main, thanks.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v2 5/7] cryptodev: rework session framework
2021-10-13 19:22 1% ` [dpdk-dev] [PATCH v2 1/7] security: rework session framework Akhil Goyal
@ 2021-10-13 19:22 1% ` Akhil Goyal
1 sibling, 0 replies; 200+ results
From: Akhil Goyal @ 2021-10-13 19:22 UTC (permalink / raw)
To: dev
Cc: thomas, david.marchand, hemant.agrawal, anoobj,
pablo.de.lara.guarch, fiona.trahe, declan.doherty, matan,
g.singh, roy.fan.zhang, jianjay.zhou, asomalap, ruifeng.wang,
konstantin.ananyev, radu.nicolau, ajit.khaparde, rnagadheeraj,
adwivedi, ciara.power, haiyue.wang, jiawenwu, jianwang,
Akhil Goyal
As per current design, rte_cryptodev_sym_session_create() and
rte_cryptodev_sym_session_init() use separate mempool objects
for a single session.
And structure rte_cryptodev_sym_session is not directly used
by the application, it may cause ABI breakage if the structure
is modified in future.
To address these two issues, the rte_cryptodev_sym_session_create
will take one mempool object for both the session and session
private data. The API rte_cryptodev_sym_session_init will now not
take mempool object.
rte_cryptodev_sym_session_create will now return an opaque session
pointer which will be used by the app in rte_cryptodev_sym_session_init
and other APIs.
With this change, rte_cryptodev_sym_session_init will send
pointer to session private data of corresponding driver to the PMD
based on the driver_id for filling the PMD data.
In data path, opaque session pointer is attached to rte_crypto_op
and the PMD can call an internal library API to get the session
private data pointer based on the driver id.
Note: currently nb_drivers are getting updated in RTE_INIT which
result in increasing the memory requirements for session.
User can compile off drivers which are not in use to reduce the
memory consumption of a session.
Signed-off-by: Akhil Goyal <gakhil@marvell.com>
---
app/test-crypto-perf/cperf.h | 1 -
app/test-crypto-perf/cperf_ops.c | 33 ++---
app/test-crypto-perf/cperf_ops.h | 6 +-
app/test-crypto-perf/cperf_test_latency.c | 5 +-
app/test-crypto-perf/cperf_test_latency.h | 1 -
.../cperf_test_pmd_cyclecount.c | 5 +-
.../cperf_test_pmd_cyclecount.h | 1 -
app/test-crypto-perf/cperf_test_throughput.c | 5 +-
app/test-crypto-perf/cperf_test_throughput.h | 1 -
app/test-crypto-perf/cperf_test_verify.c | 5 +-
app/test-crypto-perf/cperf_test_verify.h | 1 -
app/test-crypto-perf/main.c | 29 +---
app/test/test_cryptodev.c | 130 +++++-------------
app/test/test_cryptodev.h | 1 -
app/test/test_cryptodev_asym.c | 1 -
app/test/test_cryptodev_blockcipher.c | 6 +-
app/test/test_event_crypto_adapter.c | 28 +---
app/test/test_ipsec.c | 22 +--
drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c | 33 +----
.../crypto/aesni_mb/rte_aesni_mb_pmd_ops.c | 34 +----
drivers/crypto/armv8/rte_armv8_pmd_ops.c | 34 +----
drivers/crypto/bcmfs/bcmfs_sym_session.c | 36 +----
drivers/crypto/bcmfs/bcmfs_sym_session.h | 6 +-
drivers/crypto/caam_jr/caam_jr.c | 32 ++---
drivers/crypto/ccp/ccp_pmd_ops.c | 32 +----
drivers/crypto/cnxk/cn10k_cryptodev_ops.c | 18 ++-
drivers/crypto/cnxk/cn9k_cryptodev_ops.c | 18 +--
drivers/crypto/cnxk/cnxk_cryptodev_ops.c | 61 +++-----
drivers/crypto/cnxk/cnxk_cryptodev_ops.h | 13 +-
drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c | 29 +---
drivers/crypto/dpaa_sec/dpaa_sec.c | 31 +----
drivers/crypto/kasumi/rte_kasumi_pmd_ops.c | 34 +----
drivers/crypto/mlx5/mlx5_crypto.c | 24 +---
drivers/crypto/mvsam/rte_mrvl_pmd_ops.c | 36 ++---
drivers/crypto/nitrox/nitrox_sym.c | 31 +----
drivers/crypto/null/null_crypto_pmd_ops.c | 34 +----
.../crypto/octeontx/otx_cryptodev_hw_access.h | 1 -
drivers/crypto/octeontx/otx_cryptodev_ops.c | 60 +++-----
drivers/crypto/octeontx2/otx2_cryptodev_ops.c | 52 +++----
.../octeontx2/otx2_cryptodev_ops_helper.h | 16 +--
drivers/crypto/openssl/rte_openssl_pmd_ops.c | 35 +----
drivers/crypto/qat/qat_sym_session.c | 29 +---
drivers/crypto/qat/qat_sym_session.h | 6 +-
drivers/crypto/scheduler/scheduler_pmd_ops.c | 9 +-
drivers/crypto/snow3g/rte_snow3g_pmd_ops.c | 34 +----
drivers/crypto/virtio/virtio_cryptodev.c | 31 ++---
drivers/crypto/zuc/rte_zuc_pmd_ops.c | 35 +----
.../octeontx2/otx2_evdev_crypto_adptr_rx.h | 3 +-
examples/fips_validation/fips_dev_self_test.c | 32 ++---
examples/fips_validation/main.c | 20 +--
examples/ipsec-secgw/ipsec-secgw.c | 40 ------
examples/ipsec-secgw/ipsec.c | 3 +-
examples/ipsec-secgw/ipsec.h | 1 -
examples/ipsec-secgw/ipsec_worker.c | 4 -
examples/l2fwd-crypto/main.c | 41 +-----
examples/vhost_crypto/main.c | 16 +--
lib/cryptodev/cryptodev_pmd.h | 7 +-
lib/cryptodev/rte_crypto.h | 2 +-
lib/cryptodev/rte_crypto_sym.h | 2 +-
lib/cryptodev/rte_cryptodev.c | 73 ++++++----
lib/cryptodev/rte_cryptodev.h | 23 ++--
lib/cryptodev/rte_cryptodev_trace.h | 5 +-
lib/pipeline/rte_table_action.c | 8 +-
lib/pipeline/rte_table_action.h | 2 +-
lib/vhost/rte_vhost_crypto.h | 3 -
lib/vhost/vhost_crypto.c | 7 +-
66 files changed, 366 insertions(+), 1051 deletions(-)
diff --git a/app/test-crypto-perf/cperf.h b/app/test-crypto-perf/cperf.h
index 2b0aad095c..db58228dce 100644
--- a/app/test-crypto-perf/cperf.h
+++ b/app/test-crypto-perf/cperf.h
@@ -15,7 +15,6 @@ struct cperf_op_fns;
typedef void *(*cperf_constructor_t)(
struct rte_mempool *sess_mp,
- struct rte_mempool *sess_priv_mp,
uint8_t dev_id,
uint16_t qp_id,
const struct cperf_options *options,
diff --git a/app/test-crypto-perf/cperf_ops.c b/app/test-crypto-perf/cperf_ops.c
index 6c3aa77dec..ec867b0174 100644
--- a/app/test-crypto-perf/cperf_ops.c
+++ b/app/test-crypto-perf/cperf_ops.c
@@ -13,7 +13,7 @@ static int
cperf_set_ops_asym(struct rte_crypto_op **ops,
uint32_t src_buf_offset __rte_unused,
uint32_t dst_buf_offset __rte_unused, uint16_t nb_ops,
- struct rte_cryptodev_sym_session *sess,
+ void *sess,
const struct cperf_options *options __rte_unused,
const struct cperf_test_vector *test_vector __rte_unused,
uint16_t iv_offset __rte_unused,
@@ -56,7 +56,7 @@ static int
cperf_set_ops_security(struct rte_crypto_op **ops,
uint32_t src_buf_offset __rte_unused,
uint32_t dst_buf_offset __rte_unused,
- uint16_t nb_ops, struct rte_cryptodev_sym_session *sess,
+ uint16_t nb_ops, void *sess,
const struct cperf_options *options,
const struct cperf_test_vector *test_vector,
uint16_t iv_offset __rte_unused, uint32_t *imix_idx,
@@ -141,7 +141,7 @@ cperf_set_ops_security(struct rte_crypto_op **ops,
static int
cperf_set_ops_null_cipher(struct rte_crypto_op **ops,
uint32_t src_buf_offset, uint32_t dst_buf_offset,
- uint16_t nb_ops, struct rte_cryptodev_sym_session *sess,
+ uint16_t nb_ops, void *sess,
const struct cperf_options *options,
const struct cperf_test_vector *test_vector __rte_unused,
uint16_t iv_offset __rte_unused, uint32_t *imix_idx,
@@ -181,7 +181,7 @@ cperf_set_ops_null_cipher(struct rte_crypto_op **ops,
static int
cperf_set_ops_null_auth(struct rte_crypto_op **ops,
uint32_t src_buf_offset, uint32_t dst_buf_offset,
- uint16_t nb_ops, struct rte_cryptodev_sym_session *sess,
+ uint16_t nb_ops, void *sess,
const struct cperf_options *options,
const struct cperf_test_vector *test_vector __rte_unused,
uint16_t iv_offset __rte_unused, uint32_t *imix_idx,
@@ -221,7 +221,7 @@ cperf_set_ops_null_auth(struct rte_crypto_op **ops,
static int
cperf_set_ops_cipher(struct rte_crypto_op **ops,
uint32_t src_buf_offset, uint32_t dst_buf_offset,
- uint16_t nb_ops, struct rte_cryptodev_sym_session *sess,
+ uint16_t nb_ops, void *sess,
const struct cperf_options *options,
const struct cperf_test_vector *test_vector,
uint16_t iv_offset, uint32_t *imix_idx,
@@ -278,7 +278,7 @@ cperf_set_ops_cipher(struct rte_crypto_op **ops,
static int
cperf_set_ops_auth(struct rte_crypto_op **ops,
uint32_t src_buf_offset, uint32_t dst_buf_offset,
- uint16_t nb_ops, struct rte_cryptodev_sym_session *sess,
+ uint16_t nb_ops, void *sess,
const struct cperf_options *options,
const struct cperf_test_vector *test_vector,
uint16_t iv_offset, uint32_t *imix_idx,
@@ -379,7 +379,7 @@ cperf_set_ops_auth(struct rte_crypto_op **ops,
static int
cperf_set_ops_cipher_auth(struct rte_crypto_op **ops,
uint32_t src_buf_offset, uint32_t dst_buf_offset,
- uint16_t nb_ops, struct rte_cryptodev_sym_session *sess,
+ uint16_t nb_ops, void *sess,
const struct cperf_options *options,
const struct cperf_test_vector *test_vector,
uint16_t iv_offset, uint32_t *imix_idx,
@@ -495,7 +495,7 @@ cperf_set_ops_cipher_auth(struct rte_crypto_op **ops,
static int
cperf_set_ops_aead(struct rte_crypto_op **ops,
uint32_t src_buf_offset, uint32_t dst_buf_offset,
- uint16_t nb_ops, struct rte_cryptodev_sym_session *sess,
+ uint16_t nb_ops, void *sess,
const struct cperf_options *options,
const struct cperf_test_vector *test_vector,
uint16_t iv_offset, uint32_t *imix_idx,
@@ -720,9 +720,8 @@ create_ipsec_session(struct rte_mempool *sess_mp,
&sess_conf, sess_mp);
}
-static struct rte_cryptodev_sym_session *
+static void *
cperf_create_session(struct rte_mempool *sess_mp,
- struct rte_mempool *priv_mp,
uint8_t dev_id,
const struct cperf_options *options,
const struct cperf_test_vector *test_vector,
@@ -747,7 +746,7 @@ cperf_create_session(struct rte_mempool *sess_mp,
if (sess == NULL)
return NULL;
rc = rte_cryptodev_asym_session_init(dev_id, (void *)sess,
- &xform, priv_mp);
+ &xform, sess_mp);
if (rc < 0) {
if (sess != NULL) {
rte_cryptodev_asym_session_clear(dev_id,
@@ -905,8 +904,7 @@ cperf_create_session(struct rte_mempool *sess_mp,
cipher_xform.cipher.iv.length = 0;
}
/* create crypto session */
- rte_cryptodev_sym_session_init(dev_id, sess, &cipher_xform,
- priv_mp);
+ rte_cryptodev_sym_session_init(dev_id, sess, &cipher_xform);
/*
* auth only
*/
@@ -933,8 +931,7 @@ cperf_create_session(struct rte_mempool *sess_mp,
auth_xform.auth.iv.length = 0;
}
/* create crypto session */
- rte_cryptodev_sym_session_init(dev_id, sess, &auth_xform,
- priv_mp);
+ rte_cryptodev_sym_session_init(dev_id, sess, &auth_xform);
/*
* cipher and auth
*/
@@ -993,12 +990,12 @@ cperf_create_session(struct rte_mempool *sess_mp,
cipher_xform.next = &auth_xform;
/* create crypto session */
rte_cryptodev_sym_session_init(dev_id,
- sess, &cipher_xform, priv_mp);
+ sess, &cipher_xform);
} else { /* auth then cipher */
auth_xform.next = &cipher_xform;
/* create crypto session */
rte_cryptodev_sym_session_init(dev_id,
- sess, &auth_xform, priv_mp);
+ sess, &auth_xform);
}
} else { /* options->op_type == CPERF_AEAD */
aead_xform.type = RTE_CRYPTO_SYM_XFORM_AEAD;
@@ -1019,7 +1016,7 @@ cperf_create_session(struct rte_mempool *sess_mp,
/* Create crypto session */
rte_cryptodev_sym_session_init(dev_id,
- sess, &aead_xform, priv_mp);
+ sess, &aead_xform);
}
return sess;
diff --git a/app/test-crypto-perf/cperf_ops.h b/app/test-crypto-perf/cperf_ops.h
index 30d38f90e3..d3513590f1 100644
--- a/app/test-crypto-perf/cperf_ops.h
+++ b/app/test-crypto-perf/cperf_ops.h
@@ -12,15 +12,15 @@
#include "cperf_test_vectors.h"
-typedef struct rte_cryptodev_sym_session *(*cperf_sessions_create_t)(
- struct rte_mempool *sess_mp, struct rte_mempool *sess_priv_mp,
+typedef void *(*cperf_sessions_create_t)(
+ struct rte_mempool *sess_mp,
uint8_t dev_id, const struct cperf_options *options,
const struct cperf_test_vector *test_vector,
uint16_t iv_offset);
typedef int (*cperf_populate_ops_t)(struct rte_crypto_op **ops,
uint32_t src_buf_offset, uint32_t dst_buf_offset,
- uint16_t nb_ops, struct rte_cryptodev_sym_session *sess,
+ uint16_t nb_ops, void *sess,
const struct cperf_options *options,
const struct cperf_test_vector *test_vector,
uint16_t iv_offset, uint32_t *imix_idx,
diff --git a/app/test-crypto-perf/cperf_test_latency.c b/app/test-crypto-perf/cperf_test_latency.c
index 69f55de50a..63d520ee66 100644
--- a/app/test-crypto-perf/cperf_test_latency.c
+++ b/app/test-crypto-perf/cperf_test_latency.c
@@ -24,7 +24,7 @@ struct cperf_latency_ctx {
struct rte_mempool *pool;
- struct rte_cryptodev_sym_session *sess;
+ void *sess;
cperf_populate_ops_t populate_ops;
@@ -59,7 +59,6 @@ cperf_latency_test_free(struct cperf_latency_ctx *ctx)
void *
cperf_latency_test_constructor(struct rte_mempool *sess_mp,
- struct rte_mempool *sess_priv_mp,
uint8_t dev_id, uint16_t qp_id,
const struct cperf_options *options,
const struct cperf_test_vector *test_vector,
@@ -84,7 +83,7 @@ cperf_latency_test_constructor(struct rte_mempool *sess_mp,
sizeof(struct rte_crypto_sym_op) +
sizeof(struct cperf_op_result *);
- ctx->sess = op_fns->sess_create(sess_mp, sess_priv_mp, dev_id, options,
+ ctx->sess = op_fns->sess_create(sess_mp, dev_id, options,
test_vector, iv_offset);
if (ctx->sess == NULL)
goto err;
diff --git a/app/test-crypto-perf/cperf_test_latency.h b/app/test-crypto-perf/cperf_test_latency.h
index ed5b0a07bb..d3fc3218d7 100644
--- a/app/test-crypto-perf/cperf_test_latency.h
+++ b/app/test-crypto-perf/cperf_test_latency.h
@@ -17,7 +17,6 @@
void *
cperf_latency_test_constructor(
struct rte_mempool *sess_mp,
- struct rte_mempool *sess_priv_mp,
uint8_t dev_id,
uint16_t qp_id,
const struct cperf_options *options,
diff --git a/app/test-crypto-perf/cperf_test_pmd_cyclecount.c b/app/test-crypto-perf/cperf_test_pmd_cyclecount.c
index e43e2a3b96..11083ea141 100644
--- a/app/test-crypto-perf/cperf_test_pmd_cyclecount.c
+++ b/app/test-crypto-perf/cperf_test_pmd_cyclecount.c
@@ -27,7 +27,7 @@ struct cperf_pmd_cyclecount_ctx {
struct rte_crypto_op **ops;
struct rte_crypto_op **ops_processed;
- struct rte_cryptodev_sym_session *sess;
+ void *sess;
cperf_populate_ops_t populate_ops;
@@ -93,7 +93,6 @@ cperf_pmd_cyclecount_test_free(struct cperf_pmd_cyclecount_ctx *ctx)
void *
cperf_pmd_cyclecount_test_constructor(struct rte_mempool *sess_mp,
- struct rte_mempool *sess_priv_mp,
uint8_t dev_id, uint16_t qp_id,
const struct cperf_options *options,
const struct cperf_test_vector *test_vector,
@@ -120,7 +119,7 @@ cperf_pmd_cyclecount_test_constructor(struct rte_mempool *sess_mp,
uint16_t iv_offset = sizeof(struct rte_crypto_op) +
sizeof(struct rte_crypto_sym_op);
- ctx->sess = op_fns->sess_create(sess_mp, sess_priv_mp, dev_id, options,
+ ctx->sess = op_fns->sess_create(sess_mp, dev_id, options,
test_vector, iv_offset);
if (ctx->sess == NULL)
goto err;
diff --git a/app/test-crypto-perf/cperf_test_pmd_cyclecount.h b/app/test-crypto-perf/cperf_test_pmd_cyclecount.h
index 3084038a18..beb4419910 100644
--- a/app/test-crypto-perf/cperf_test_pmd_cyclecount.h
+++ b/app/test-crypto-perf/cperf_test_pmd_cyclecount.h
@@ -18,7 +18,6 @@
void *
cperf_pmd_cyclecount_test_constructor(
struct rte_mempool *sess_mp,
- struct rte_mempool *sess_priv_mp,
uint8_t dev_id,
uint16_t qp_id,
const struct cperf_options *options,
diff --git a/app/test-crypto-perf/cperf_test_throughput.c b/app/test-crypto-perf/cperf_test_throughput.c
index 739ed9e573..887f42c532 100644
--- a/app/test-crypto-perf/cperf_test_throughput.c
+++ b/app/test-crypto-perf/cperf_test_throughput.c
@@ -18,7 +18,7 @@ struct cperf_throughput_ctx {
struct rte_mempool *pool;
- struct rte_cryptodev_sym_session *sess;
+ void *sess;
cperf_populate_ops_t populate_ops;
@@ -65,7 +65,6 @@ cperf_throughput_test_free(struct cperf_throughput_ctx *ctx)
void *
cperf_throughput_test_constructor(struct rte_mempool *sess_mp,
- struct rte_mempool *sess_priv_mp,
uint8_t dev_id, uint16_t qp_id,
const struct cperf_options *options,
const struct cperf_test_vector *test_vector,
@@ -88,7 +87,7 @@ cperf_throughput_test_constructor(struct rte_mempool *sess_mp,
uint16_t iv_offset = sizeof(struct rte_crypto_op) +
sizeof(struct rte_crypto_sym_op);
- ctx->sess = op_fns->sess_create(sess_mp, sess_priv_mp, dev_id, options,
+ ctx->sess = op_fns->sess_create(sess_mp, dev_id, options,
test_vector, iv_offset);
if (ctx->sess == NULL)
goto err;
diff --git a/app/test-crypto-perf/cperf_test_throughput.h b/app/test-crypto-perf/cperf_test_throughput.h
index 91e1a4b708..439ec8e559 100644
--- a/app/test-crypto-perf/cperf_test_throughput.h
+++ b/app/test-crypto-perf/cperf_test_throughput.h
@@ -18,7 +18,6 @@
void *
cperf_throughput_test_constructor(
struct rte_mempool *sess_mp,
- struct rte_mempool *sess_priv_mp,
uint8_t dev_id,
uint16_t qp_id,
const struct cperf_options *options,
diff --git a/app/test-crypto-perf/cperf_test_verify.c b/app/test-crypto-perf/cperf_test_verify.c
index 1962438034..0b3d4f7c59 100644
--- a/app/test-crypto-perf/cperf_test_verify.c
+++ b/app/test-crypto-perf/cperf_test_verify.c
@@ -18,7 +18,7 @@ struct cperf_verify_ctx {
struct rte_mempool *pool;
- struct rte_cryptodev_sym_session *sess;
+ void *sess;
cperf_populate_ops_t populate_ops;
@@ -51,7 +51,6 @@ cperf_verify_test_free(struct cperf_verify_ctx *ctx)
void *
cperf_verify_test_constructor(struct rte_mempool *sess_mp,
- struct rte_mempool *sess_priv_mp,
uint8_t dev_id, uint16_t qp_id,
const struct cperf_options *options,
const struct cperf_test_vector *test_vector,
@@ -74,7 +73,7 @@ cperf_verify_test_constructor(struct rte_mempool *sess_mp,
uint16_t iv_offset = sizeof(struct rte_crypto_op) +
sizeof(struct rte_crypto_sym_op);
- ctx->sess = op_fns->sess_create(sess_mp, sess_priv_mp, dev_id, options,
+ ctx->sess = op_fns->sess_create(sess_mp, dev_id, options,
test_vector, iv_offset);
if (ctx->sess == NULL)
goto err;
diff --git a/app/test-crypto-perf/cperf_test_verify.h b/app/test-crypto-perf/cperf_test_verify.h
index ac2192ba99..9f70ad87ba 100644
--- a/app/test-crypto-perf/cperf_test_verify.h
+++ b/app/test-crypto-perf/cperf_test_verify.h
@@ -18,7 +18,6 @@
void *
cperf_verify_test_constructor(
struct rte_mempool *sess_mp,
- struct rte_mempool *sess_priv_mp,
uint8_t dev_id,
uint16_t qp_id,
const struct cperf_options *options,
diff --git a/app/test-crypto-perf/main.c b/app/test-crypto-perf/main.c
index 6fdb92fb7c..7a9fb9a64d 100644
--- a/app/test-crypto-perf/main.c
+++ b/app/test-crypto-perf/main.c
@@ -119,35 +119,14 @@ fill_session_pool_socket(int32_t socket_id, uint32_t session_priv_size,
char mp_name[RTE_MEMPOOL_NAMESIZE];
struct rte_mempool *sess_mp;
- if (session_pool_socket[socket_id].priv_mp == NULL) {
- snprintf(mp_name, RTE_MEMPOOL_NAMESIZE,
- "priv_sess_mp_%u", socket_id);
-
- sess_mp = rte_mempool_create(mp_name,
- nb_sessions,
- session_priv_size,
- 0, 0, NULL, NULL, NULL,
- NULL, socket_id,
- 0);
-
- if (sess_mp == NULL) {
- printf("Cannot create pool \"%s\" on socket %d\n",
- mp_name, socket_id);
- return -ENOMEM;
- }
-
- printf("Allocated pool \"%s\" on socket %d\n",
- mp_name, socket_id);
- session_pool_socket[socket_id].priv_mp = sess_mp;
- }
-
if (session_pool_socket[socket_id].sess_mp == NULL) {
snprintf(mp_name, RTE_MEMPOOL_NAMESIZE,
"sess_mp_%u", socket_id);
sess_mp = rte_cryptodev_sym_session_pool_create(mp_name,
- nb_sessions, 0, 0, 0, socket_id);
+ nb_sessions, session_priv_size,
+ 0, 0, socket_id);
if (sess_mp == NULL) {
printf("Cannot create pool \"%s\" on socket %d\n",
@@ -345,12 +324,9 @@ cperf_initialize_cryptodev(struct cperf_options *opts, uint8_t *enabled_cdevs)
return ret;
qp_conf.mp_session = session_pool_socket[socket_id].sess_mp;
- qp_conf.mp_session_private =
- session_pool_socket[socket_id].priv_mp;
if (opts->op_type == CPERF_ASYM_MODEX) {
qp_conf.mp_session = NULL;
- qp_conf.mp_session_private = NULL;
}
ret = rte_cryptodev_configure(cdev_id, &conf);
@@ -705,7 +681,6 @@ main(int argc, char **argv)
ctx[i] = cperf_testmap[opts.test].constructor(
session_pool_socket[socket_id].sess_mp,
- session_pool_socket[socket_id].priv_mp,
cdev_id, qp_id,
&opts, t_vec, &op_fns);
if (ctx[i] == NULL) {
diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index 79019eb766..ac408863dc 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -81,7 +81,7 @@ struct crypto_unittest_params {
#endif
union {
- struct rte_cryptodev_sym_session *sess;
+ void *sess;
#ifdef RTE_LIB_SECURITY
void *sec_session;
#endif
@@ -121,7 +121,7 @@ test_AES_CBC_HMAC_SHA512_decrypt_create_session_params(
uint8_t *hmac_key);
static int
-test_AES_CBC_HMAC_SHA512_decrypt_perform(struct rte_cryptodev_sym_session *sess,
+test_AES_CBC_HMAC_SHA512_decrypt_perform(void *sess,
struct crypto_unittest_params *ut_params,
struct crypto_testsuite_params *ts_param,
const uint8_t *cipher,
@@ -598,23 +598,11 @@ testsuite_setup(void)
}
ts_params->session_mpool = rte_cryptodev_sym_session_pool_create(
- "test_sess_mp", MAX_NB_SESSIONS, 0, 0, 0,
+ "test_sess_mp", MAX_NB_SESSIONS, session_size, 0, 0,
SOCKET_ID_ANY);
TEST_ASSERT_NOT_NULL(ts_params->session_mpool,
"session mempool allocation failed");
- ts_params->session_priv_mpool = rte_mempool_create(
- "test_sess_mp_priv",
- MAX_NB_SESSIONS,
- session_size,
- 0, 0, NULL, NULL, NULL,
- NULL, SOCKET_ID_ANY,
- 0);
- TEST_ASSERT_NOT_NULL(ts_params->session_priv_mpool,
- "session mempool allocation failed");
-
-
-
TEST_ASSERT_SUCCESS(rte_cryptodev_configure(dev_id,
&ts_params->conf),
"Failed to configure cryptodev %u with %u qps",
@@ -622,7 +610,6 @@ testsuite_setup(void)
ts_params->qp_conf.nb_descriptors = MAX_NUM_OPS_INFLIGHT;
ts_params->qp_conf.mp_session = ts_params->session_mpool;
- ts_params->qp_conf.mp_session_private = ts_params->session_priv_mpool;
for (qp_id = 0; qp_id < info.max_nb_queue_pairs; qp_id++) {
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
@@ -652,11 +639,6 @@ testsuite_teardown(void)
}
/* Free session mempools */
- if (ts_params->session_priv_mpool != NULL) {
- rte_mempool_free(ts_params->session_priv_mpool);
- ts_params->session_priv_mpool = NULL;
- }
-
if (ts_params->session_mpool != NULL) {
rte_mempool_free(ts_params->session_mpool);
ts_params->session_mpool = NULL;
@@ -1332,7 +1314,6 @@ dev_configure_and_start(uint64_t ff_disable)
ts_params->conf.ff_disable = ff_disable;
ts_params->qp_conf.nb_descriptors = MAX_NUM_OPS_INFLIGHT;
ts_params->qp_conf.mp_session = ts_params->session_mpool;
- ts_params->qp_conf.mp_session_private = ts_params->session_priv_mpool;
TEST_ASSERT_SUCCESS(rte_cryptodev_configure(ts_params->valid_devs[0],
&ts_params->conf),
@@ -1554,7 +1535,6 @@ test_queue_pair_descriptor_setup(void)
*/
qp_conf.nb_descriptors = MIN_NUM_OPS_INFLIGHT; /* min size*/
qp_conf.mp_session = ts_params->session_mpool;
- qp_conf.mp_session_private = ts_params->session_priv_mpool;
for (qp_id = 0; qp_id < ts_params->conf.nb_queue_pairs; qp_id++) {
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
@@ -2148,8 +2128,7 @@ test_AES_CBC_HMAC_SHA1_encrypt_digest(void)
/* Create crypto session*/
rte_cryptodev_sym_session_init(ts_params->valid_devs[0],
- ut_params->sess, &ut_params->cipher_xform,
- ts_params->session_priv_mpool);
+ ut_params->sess, &ut_params->cipher_xform);
TEST_ASSERT_NOT_NULL(ut_params->sess, "Session creation failed");
/* Generate crypto op data structure */
@@ -2249,7 +2228,7 @@ test_AES_CBC_HMAC_SHA512_decrypt_create_session_params(
uint8_t *hmac_key);
static int
-test_AES_CBC_HMAC_SHA512_decrypt_perform(struct rte_cryptodev_sym_session *sess,
+test_AES_CBC_HMAC_SHA512_decrypt_perform(void *sess,
struct crypto_unittest_params *ut_params,
struct crypto_testsuite_params *ts_params,
const uint8_t *cipher,
@@ -2290,7 +2269,7 @@ test_AES_CBC_HMAC_SHA512_decrypt_create_session_params(
static int
-test_AES_CBC_HMAC_SHA512_decrypt_perform(struct rte_cryptodev_sym_session *sess,
+test_AES_CBC_HMAC_SHA512_decrypt_perform(void *sess,
struct crypto_unittest_params *ut_params,
struct crypto_testsuite_params *ts_params,
const uint8_t *cipher,
@@ -2403,8 +2382,7 @@ create_wireless_algo_hash_session(uint8_t dev_id,
ts_params->session_mpool);
status = rte_cryptodev_sym_session_init(dev_id, ut_params->sess,
- &ut_params->auth_xform,
- ts_params->session_priv_mpool);
+ &ut_params->auth_xform);
if (status == -ENOTSUP)
return TEST_SKIPPED;
@@ -2445,8 +2423,7 @@ create_wireless_algo_cipher_session(uint8_t dev_id,
ts_params->session_mpool);
status = rte_cryptodev_sym_session_init(dev_id, ut_params->sess,
- &ut_params->cipher_xform,
- ts_params->session_priv_mpool);
+ &ut_params->cipher_xform);
if (status == -ENOTSUP)
return TEST_SKIPPED;
@@ -2568,8 +2545,7 @@ create_wireless_algo_cipher_auth_session(uint8_t dev_id,
TEST_ASSERT_NOT_NULL(ut_params->sess, "Session creation failed");
status = rte_cryptodev_sym_session_init(dev_id, ut_params->sess,
- &ut_params->cipher_xform,
- ts_params->session_priv_mpool);
+ &ut_params->cipher_xform);
if (status == -ENOTSUP)
return TEST_SKIPPED;
@@ -2631,8 +2607,7 @@ create_wireless_cipher_auth_session(uint8_t dev_id,
ts_params->session_mpool);
status = rte_cryptodev_sym_session_init(dev_id, ut_params->sess,
- &ut_params->cipher_xform,
- ts_params->session_priv_mpool);
+ &ut_params->cipher_xform);
if (status == -ENOTSUP)
return TEST_SKIPPED;
@@ -2701,13 +2676,11 @@ create_wireless_algo_auth_cipher_session(uint8_t dev_id,
ut_params->auth_xform.next = NULL;
ut_params->cipher_xform.next = &ut_params->auth_xform;
status = rte_cryptodev_sym_session_init(dev_id, ut_params->sess,
- &ut_params->cipher_xform,
- ts_params->session_priv_mpool);
+ &ut_params->cipher_xform);
} else
status = rte_cryptodev_sym_session_init(dev_id, ut_params->sess,
- &ut_params->auth_xform,
- ts_params->session_priv_mpool);
+ &ut_params->auth_xform);
if (status == -ENOTSUP)
return TEST_SKIPPED;
@@ -7840,8 +7813,7 @@ create_aead_session(uint8_t dev_id, enum rte_crypto_aead_algorithm algo,
ts_params->session_mpool);
rte_cryptodev_sym_session_init(dev_id, ut_params->sess,
- &ut_params->aead_xform,
- ts_params->session_priv_mpool);
+ &ut_params->aead_xform);
TEST_ASSERT_NOT_NULL(ut_params->sess, "Session creation failed");
@@ -11018,8 +10990,7 @@ static int MD5_HMAC_create_session(struct crypto_testsuite_params *ts_params,
ts_params->session_mpool);
rte_cryptodev_sym_session_init(ts_params->valid_devs[0],
- ut_params->sess, &ut_params->auth_xform,
- ts_params->session_priv_mpool);
+ ut_params->sess, &ut_params->auth_xform);
if (ut_params->sess == NULL)
return TEST_FAILED;
@@ -11232,7 +11203,7 @@ test_multi_session(void)
struct crypto_unittest_params *ut_params = &unittest_params;
struct rte_cryptodev_info dev_info;
- struct rte_cryptodev_sym_session **sessions;
+ void **sessions;
uint16_t i;
@@ -11255,9 +11226,7 @@ test_multi_session(void)
rte_cryptodev_info_get(ts_params->valid_devs[0], &dev_info);
- sessions = rte_malloc(NULL,
- sizeof(struct rte_cryptodev_sym_session *) *
- (MAX_NB_SESSIONS + 1), 0);
+ sessions = rte_malloc(NULL, sizeof(void *) * (MAX_NB_SESSIONS + 1), 0);
/* Create multiple crypto sessions*/
for (i = 0; i < MAX_NB_SESSIONS; i++) {
@@ -11266,8 +11235,7 @@ test_multi_session(void)
ts_params->session_mpool);
rte_cryptodev_sym_session_init(ts_params->valid_devs[0],
- sessions[i], &ut_params->auth_xform,
- ts_params->session_priv_mpool);
+ sessions[i], &ut_params->auth_xform);
TEST_ASSERT_NOT_NULL(sessions[i],
"Session creation failed at session number %u",
i);
@@ -11305,8 +11273,7 @@ test_multi_session(void)
sessions[i] = NULL;
/* Next session create should fail */
rte_cryptodev_sym_session_init(ts_params->valid_devs[0],
- sessions[i], &ut_params->auth_xform,
- ts_params->session_priv_mpool);
+ sessions[i], &ut_params->auth_xform);
TEST_ASSERT_NULL(sessions[i],
"Session creation succeeded unexpectedly!");
@@ -11337,7 +11304,7 @@ test_multi_session_random_usage(void)
{
struct crypto_testsuite_params *ts_params = &testsuite_params;
struct rte_cryptodev_info dev_info;
- struct rte_cryptodev_sym_session **sessions;
+ void **sessions;
uint32_t i, j;
struct multi_session_params ut_paramz[] = {
@@ -11381,8 +11348,7 @@ test_multi_session_random_usage(void)
rte_cryptodev_info_get(ts_params->valid_devs[0], &dev_info);
sessions = rte_malloc(NULL,
- (sizeof(struct rte_cryptodev_sym_session *)
- * MAX_NB_SESSIONS) + 1, 0);
+ (sizeof(void *) * MAX_NB_SESSIONS) + 1, 0);
for (i = 0; i < MB_SESSION_NUMBER; i++) {
sessions[i] = rte_cryptodev_sym_session_create(
@@ -11399,8 +11365,7 @@ test_multi_session_random_usage(void)
rte_cryptodev_sym_session_init(
ts_params->valid_devs[0],
sessions[i],
- &ut_paramz[i].ut_params.auth_xform,
- ts_params->session_priv_mpool);
+ &ut_paramz[i].ut_params.auth_xform);
TEST_ASSERT_NOT_NULL(sessions[i],
"Session creation failed at session number %u",
@@ -11483,8 +11448,7 @@ test_null_invalid_operation(void)
/* Create Crypto session*/
ret = rte_cryptodev_sym_session_init(ts_params->valid_devs[0],
- ut_params->sess, &ut_params->cipher_xform,
- ts_params->session_priv_mpool);
+ ut_params->sess, &ut_params->cipher_xform);
TEST_ASSERT(ret < 0,
"Session creation succeeded unexpectedly");
@@ -11501,8 +11465,7 @@ test_null_invalid_operation(void)
/* Create Crypto session*/
ret = rte_cryptodev_sym_session_init(ts_params->valid_devs[0],
- ut_params->sess, &ut_params->auth_xform,
- ts_params->session_priv_mpool);
+ ut_params->sess, &ut_params->auth_xform);
TEST_ASSERT(ret < 0,
"Session creation succeeded unexpectedly");
@@ -11547,8 +11510,7 @@ test_null_burst_operation(void)
/* Create Crypto session*/
rte_cryptodev_sym_session_init(ts_params->valid_devs[0],
- ut_params->sess, &ut_params->cipher_xform,
- ts_params->session_priv_mpool);
+ ut_params->sess, &ut_params->cipher_xform);
TEST_ASSERT_NOT_NULL(ut_params->sess, "Session creation failed");
TEST_ASSERT_EQUAL(rte_crypto_op_bulk_alloc(ts_params->op_mpool,
@@ -11660,7 +11622,6 @@ test_enq_callback_setup(void)
qp_conf.nb_descriptors = MAX_NUM_OPS_INFLIGHT;
qp_conf.mp_session = ts_params->session_mpool;
- qp_conf.mp_session_private = ts_params->session_priv_mpool;
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0], qp_id, &qp_conf,
@@ -11760,7 +11721,6 @@ test_deq_callback_setup(void)
qp_conf.nb_descriptors = MAX_NUM_OPS_INFLIGHT;
qp_conf.mp_session = ts_params->session_mpool;
- qp_conf.mp_session_private = ts_params->session_priv_mpool;
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0], qp_id, &qp_conf,
@@ -11969,8 +11929,7 @@ static int create_gmac_session(uint8_t dev_id,
ts_params->session_mpool);
rte_cryptodev_sym_session_init(dev_id, ut_params->sess,
- &ut_params->auth_xform,
- ts_params->session_priv_mpool);
+ &ut_params->auth_xform);
TEST_ASSERT_NOT_NULL(ut_params->sess, "Session creation failed");
@@ -12614,8 +12573,7 @@ create_auth_session(struct crypto_unittest_params *ut_params,
ts_params->session_mpool);
rte_cryptodev_sym_session_init(dev_id, ut_params->sess,
- &ut_params->auth_xform,
- ts_params->session_priv_mpool);
+ &ut_params->auth_xform);
TEST_ASSERT_NOT_NULL(ut_params->sess, "Session creation failed");
@@ -12667,8 +12625,7 @@ create_auth_cipher_session(struct crypto_unittest_params *ut_params,
ts_params->session_mpool);
rte_cryptodev_sym_session_init(dev_id, ut_params->sess,
- &ut_params->auth_xform,
- ts_params->session_priv_mpool);
+ &ut_params->auth_xform);
TEST_ASSERT_NOT_NULL(ut_params->sess, "Session creation failed");
@@ -13175,8 +13132,7 @@ test_authenticated_encrypt_with_esn(
rte_cryptodev_sym_session_init(ts_params->valid_devs[0],
ut_params->sess,
- &ut_params->cipher_xform,
- ts_params->session_priv_mpool);
+ &ut_params->cipher_xform);
TEST_ASSERT_NOT_NULL(ut_params->sess, "Session creation failed");
@@ -13307,8 +13263,7 @@ test_authenticated_decrypt_with_esn(
rte_cryptodev_sym_session_init(ts_params->valid_devs[0],
ut_params->sess,
- &ut_params->auth_xform,
- ts_params->session_priv_mpool);
+ &ut_params->auth_xform);
TEST_ASSERT_NOT_NULL(ut_params->sess, "Session creation failed");
@@ -14029,11 +13984,6 @@ test_scheduler_attach_worker_op(void)
rte_mempool_free(ts_params->session_mpool);
ts_params->session_mpool = NULL;
}
- if (ts_params->session_priv_mpool) {
- rte_mempool_free(ts_params->session_priv_mpool);
- ts_params->session_priv_mpool = NULL;
- }
-
if (info.sym.max_nb_sessions != 0 &&
info.sym.max_nb_sessions < MAX_NB_SESSIONS) {
RTE_LOG(ERR, USER1,
@@ -14050,32 +14000,14 @@ test_scheduler_attach_worker_op(void)
ts_params->session_mpool =
rte_cryptodev_sym_session_pool_create(
"test_sess_mp",
- MAX_NB_SESSIONS, 0, 0, 0,
+ MAX_NB_SESSIONS,
+ session_size, 0, 0,
SOCKET_ID_ANY);
TEST_ASSERT_NOT_NULL(ts_params->session_mpool,
"session mempool allocation failed");
}
- /*
- * Create mempool with maximum number of sessions,
- * to include device specific session private data
- */
- if (ts_params->session_priv_mpool == NULL) {
- ts_params->session_priv_mpool = rte_mempool_create(
- "test_sess_mp_priv",
- MAX_NB_SESSIONS,
- session_size,
- 0, 0, NULL, NULL, NULL,
- NULL, SOCKET_ID_ANY,
- 0);
-
- TEST_ASSERT_NOT_NULL(ts_params->session_priv_mpool,
- "session mempool allocation failed");
- }
-
ts_params->qp_conf.mp_session = ts_params->session_mpool;
- ts_params->qp_conf.mp_session_private =
- ts_params->session_priv_mpool;
ret = rte_cryptodev_scheduler_worker_attach(sched_id,
(uint8_t)i);
diff --git a/app/test/test_cryptodev.h b/app/test/test_cryptodev.h
index 1cdd84d01f..a3a10d484b 100644
--- a/app/test/test_cryptodev.h
+++ b/app/test/test_cryptodev.h
@@ -89,7 +89,6 @@ struct crypto_testsuite_params {
struct rte_mempool *large_mbuf_pool;
struct rte_mempool *op_mpool;
struct rte_mempool *session_mpool;
- struct rte_mempool *session_priv_mpool;
struct rte_cryptodev_config conf;
struct rte_cryptodev_qp_conf qp_conf;
diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index 603b2e4609..2152b89180 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -924,7 +924,6 @@ testsuite_setup(void)
/* configure qp */
ts_params->qp_conf.nb_descriptors = DEFAULT_NUM_OPS_INFLIGHT;
ts_params->qp_conf.mp_session = ts_params->session_mpool;
- ts_params->qp_conf.mp_session_private = ts_params->session_mpool;
for (qp_id = 0; qp_id < info.max_nb_queue_pairs; qp_id++) {
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
dev_id, qp_id, &ts_params->qp_conf,
diff --git a/app/test/test_cryptodev_blockcipher.c b/app/test/test_cryptodev_blockcipher.c
index 3cdb2c96e8..9417803f18 100644
--- a/app/test/test_cryptodev_blockcipher.c
+++ b/app/test/test_cryptodev_blockcipher.c
@@ -68,7 +68,6 @@ test_blockcipher_one_case(const struct blockcipher_test_case *t,
struct rte_mempool *mbuf_pool,
struct rte_mempool *op_mpool,
struct rte_mempool *sess_mpool,
- struct rte_mempool *sess_priv_mpool,
uint8_t dev_id,
char *test_msg)
{
@@ -81,7 +80,7 @@ test_blockcipher_one_case(const struct blockcipher_test_case *t,
struct rte_crypto_sym_op *sym_op = NULL;
struct rte_crypto_op *op = NULL;
struct rte_cryptodev_info dev_info;
- struct rte_cryptodev_sym_session *sess = NULL;
+ void *sess = NULL;
int status = TEST_SUCCESS;
const struct blockcipher_test_data *tdata = t->test_data;
@@ -514,7 +513,7 @@ test_blockcipher_one_case(const struct blockcipher_test_case *t,
sess = rte_cryptodev_sym_session_create(sess_mpool);
status = rte_cryptodev_sym_session_init(dev_id, sess,
- init_xform, sess_priv_mpool);
+ init_xform);
if (status == -ENOTSUP) {
snprintf(test_msg, BLOCKCIPHER_TEST_MSG_LEN, "UNSUPPORTED");
status = TEST_SKIPPED;
@@ -831,7 +830,6 @@ blockcipher_test_case_run(const void *data)
p_testsuite_params->mbuf_pool,
p_testsuite_params->op_mpool,
p_testsuite_params->session_mpool,
- p_testsuite_params->session_priv_mpool,
p_testsuite_params->valid_devs[0],
test_msg);
return status;
diff --git a/app/test/test_event_crypto_adapter.c b/app/test/test_event_crypto_adapter.c
index 0c7ebe6981..76d2aeab6d 100644
--- a/app/test/test_event_crypto_adapter.c
+++ b/app/test/test_event_crypto_adapter.c
@@ -61,7 +61,6 @@ struct event_crypto_adapter_test_params {
struct rte_mempool *mbuf_pool;
struct rte_mempool *op_mpool;
struct rte_mempool *session_mpool;
- struct rte_mempool *session_priv_mpool;
struct rte_cryptodev_config *config;
uint8_t crypto_event_port_id;
uint8_t internal_port_op_fwd;
@@ -167,7 +166,7 @@ static int
test_op_forward_mode(uint8_t session_less)
{
struct rte_crypto_sym_xform cipher_xform;
- struct rte_cryptodev_sym_session *sess;
+ void *sess;
union rte_event_crypto_metadata m_data;
struct rte_crypto_sym_op *sym_op;
struct rte_crypto_op *op;
@@ -203,7 +202,7 @@ test_op_forward_mode(uint8_t session_less)
/* Create Crypto session*/
ret = rte_cryptodev_sym_session_init(TEST_CDEV_ID, sess,
- &cipher_xform, params.session_priv_mpool);
+ &cipher_xform);
TEST_ASSERT_SUCCESS(ret, "Failed to init session\n");
ret = rte_event_crypto_adapter_caps_get(evdev, TEST_CDEV_ID,
@@ -366,7 +365,7 @@ static int
test_op_new_mode(uint8_t session_less)
{
struct rte_crypto_sym_xform cipher_xform;
- struct rte_cryptodev_sym_session *sess;
+ void *sess;
union rte_event_crypto_metadata m_data;
struct rte_crypto_sym_op *sym_op;
struct rte_crypto_op *op;
@@ -409,7 +408,7 @@ test_op_new_mode(uint8_t session_less)
&m_data, sizeof(m_data));
}
ret = rte_cryptodev_sym_session_init(TEST_CDEV_ID, sess,
- &cipher_xform, params.session_priv_mpool);
+ &cipher_xform);
TEST_ASSERT_SUCCESS(ret, "Failed to init session\n");
rte_crypto_op_attach_sym_session(op, sess);
@@ -550,22 +549,12 @@ configure_cryptodev(void)
params.session_mpool = rte_cryptodev_sym_session_pool_create(
"CRYPTO_ADAPTER_SESSION_MP",
- MAX_NB_SESSIONS, 0, 0,
+ MAX_NB_SESSIONS, session_size, 0,
sizeof(union rte_event_crypto_metadata),
SOCKET_ID_ANY);
TEST_ASSERT_NOT_NULL(params.session_mpool,
"session mempool allocation failed\n");
- params.session_priv_mpool = rte_mempool_create(
- "CRYPTO_AD_SESS_MP_PRIV",
- MAX_NB_SESSIONS,
- session_size,
- 0, 0, NULL, NULL, NULL,
- NULL, SOCKET_ID_ANY,
- 0);
- TEST_ASSERT_NOT_NULL(params.session_priv_mpool,
- "session mempool allocation failed\n");
-
rte_cryptodev_info_get(TEST_CDEV_ID, &info);
conf.nb_queue_pairs = info.max_nb_queue_pairs;
conf.socket_id = SOCKET_ID_ANY;
@@ -577,7 +566,6 @@ configure_cryptodev(void)
qp_conf.nb_descriptors = DEFAULT_NUM_OPS_INFLIGHT;
qp_conf.mp_session = params.session_mpool;
- qp_conf.mp_session_private = params.session_priv_mpool;
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
TEST_CDEV_ID, TEST_CDEV_QP_ID, &qp_conf,
@@ -931,12 +919,6 @@ crypto_teardown(void)
rte_mempool_free(params.session_mpool);
params.session_mpool = NULL;
}
- if (params.session_priv_mpool != NULL) {
- rte_mempool_avail_count(params.session_priv_mpool);
- rte_mempool_free(params.session_priv_mpool);
- params.session_priv_mpool = NULL;
- }
-
/* Free ops mempool */
if (params.op_mpool != NULL) {
RTE_LOG(DEBUG, USER1, "EVENT_CRYPTO_SYM_OP_POOL count %u\n",
diff --git a/app/test/test_ipsec.c b/app/test/test_ipsec.c
index 3b49a0b13a..1e3913489d 100644
--- a/app/test/test_ipsec.c
+++ b/app/test/test_ipsec.c
@@ -356,20 +356,9 @@ testsuite_setup(void)
return TEST_FAILED;
}
- ts_params->qp_conf.mp_session_private = rte_mempool_create(
- "test_priv_sess_mp",
- MAX_NB_SESSIONS,
- sess_sz,
- 0, 0, NULL, NULL, NULL,
- NULL, SOCKET_ID_ANY,
- 0);
-
- TEST_ASSERT_NOT_NULL(ts_params->qp_conf.mp_session_private,
- "private session mempool allocation failed");
-
ts_params->qp_conf.mp_session =
rte_cryptodev_sym_session_pool_create("test_sess_mp",
- MAX_NB_SESSIONS, 0, 0, 0, SOCKET_ID_ANY);
+ MAX_NB_SESSIONS, sess_sz, 0, 0, SOCKET_ID_ANY);
TEST_ASSERT_NOT_NULL(ts_params->qp_conf.mp_session,
"session mempool allocation failed");
@@ -414,11 +403,6 @@ testsuite_teardown(void)
rte_mempool_free(ts_params->qp_conf.mp_session);
ts_params->qp_conf.mp_session = NULL;
}
-
- if (ts_params->qp_conf.mp_session_private != NULL) {
- rte_mempool_free(ts_params->qp_conf.mp_session_private);
- ts_params->qp_conf.mp_session_private = NULL;
- }
}
static int
@@ -645,7 +629,7 @@ create_crypto_session(struct ipsec_unitest_params *ut,
struct rte_cryptodev_qp_conf *qp, uint8_t dev_id, uint32_t j)
{
int32_t rc;
- struct rte_cryptodev_sym_session *s;
+ void *s;
s = rte_cryptodev_sym_session_create(qp->mp_session);
if (s == NULL)
@@ -653,7 +637,7 @@ create_crypto_session(struct ipsec_unitest_params *ut,
/* initiliaze SA crypto session for device */
rc = rte_cryptodev_sym_session_init(dev_id, s,
- ut->crypto_xforms, qp->mp_session_private);
+ ut->crypto_xforms);
if (rc == 0) {
ut->ss[j].crypto.ses = s;
return 0;
diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c b/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
index edb7275e76..75330292af 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
@@ -235,7 +235,6 @@ aesni_gcm_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
goto qp_setup_cleanup;
qp->sess_mp = qp_conf->mp_session;
- qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->qp_stats, 0, sizeof(qp->qp_stats));
@@ -259,10 +258,8 @@ aesni_gcm_pmd_sym_session_get_size(struct rte_cryptodev *dev __rte_unused)
static int
aesni_gcm_pmd_sym_session_configure(struct rte_cryptodev *dev __rte_unused,
struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *sess,
- struct rte_mempool *mempool)
+ void *sess)
{
- void *sess_private_data;
int ret;
struct aesni_gcm_private *internals = dev->data->dev_private;
@@ -271,42 +268,24 @@ aesni_gcm_pmd_sym_session_configure(struct rte_cryptodev *dev __rte_unused,
return -EINVAL;
}
- if (rte_mempool_get(mempool, &sess_private_data)) {
- AESNI_GCM_LOG(ERR,
- "Couldn't get object from session mempool");
- return -ENOMEM;
- }
ret = aesni_gcm_set_session_parameters(internals->ops,
- sess_private_data, xform);
+ sess, xform);
if (ret != 0) {
AESNI_GCM_LOG(ERR, "failed configure session parameters");
-
- /* Return session to mempool */
- rte_mempool_put(mempool, sess_private_data);
return ret;
}
- set_sym_session_private_data(sess, dev->driver_id,
- sess_private_data);
-
return 0;
}
/** Clear the memory of session so it doesn't leave key material behind */
static void
-aesni_gcm_pmd_sym_session_clear(struct rte_cryptodev *dev,
- struct rte_cryptodev_sym_session *sess)
+aesni_gcm_pmd_sym_session_clear(struct rte_cryptodev *dev, void *sess)
{
- uint8_t index = dev->driver_id;
- void *sess_priv = get_sym_session_private_data(sess, index);
-
+ RTE_SET_USED(dev);
/* Zero out the whole structure */
- if (sess_priv) {
- memset(sess_priv, 0, sizeof(struct aesni_gcm_session));
- struct rte_mempool *sess_mp = rte_mempool_from_obj(sess_priv);
- set_sym_session_private_data(sess, index, NULL);
- rte_mempool_put(sess_mp, sess_priv);
- }
+ if (sess)
+ memset(sess, 0, sizeof(struct aesni_gcm_session));
}
struct rte_cryptodev_ops aesni_gcm_pmd_ops = {
diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c
index 8ae6d18f36..997c4f330d 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c
@@ -944,7 +944,6 @@ aesni_mb_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
}
qp->sess_mp = qp_conf->mp_session;
- qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->stats, 0, sizeof(qp->stats));
@@ -974,11 +973,8 @@ aesni_mb_pmd_sym_session_get_size(struct rte_cryptodev *dev __rte_unused)
/** Configure a aesni multi-buffer session from a crypto xform chain */
static int
aesni_mb_pmd_sym_session_configure(struct rte_cryptodev *dev,
- struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *sess,
- struct rte_mempool *mempool)
+ struct rte_crypto_sym_xform *xform, void *sess)
{
- void *sess_private_data;
struct aesni_mb_private *internals = dev->data->dev_private;
int ret;
@@ -987,43 +983,25 @@ aesni_mb_pmd_sym_session_configure(struct rte_cryptodev *dev,
return -EINVAL;
}
- if (rte_mempool_get(mempool, &sess_private_data)) {
- AESNI_MB_LOG(ERR,
- "Couldn't get object from session mempool");
- return -ENOMEM;
- }
-
ret = aesni_mb_set_session_parameters(internals->mb_mgr,
- sess_private_data, xform);
+ sess, xform);
if (ret != 0) {
AESNI_MB_LOG(ERR, "failed configure session parameters");
-
- /* Return session to mempool */
- rte_mempool_put(mempool, sess_private_data);
return ret;
}
- set_sym_session_private_data(sess, dev->driver_id,
- sess_private_data);
-
return 0;
}
/** Clear the memory of session so it doesn't leave key material behind */
static void
-aesni_mb_pmd_sym_session_clear(struct rte_cryptodev *dev,
- struct rte_cryptodev_sym_session *sess)
+aesni_mb_pmd_sym_session_clear(struct rte_cryptodev *dev, void *sess)
{
- uint8_t index = dev->driver_id;
- void *sess_priv = get_sym_session_private_data(sess, index);
+ RTE_SET_USED(dev);
/* Zero out the whole structure */
- if (sess_priv) {
- memset(sess_priv, 0, sizeof(struct aesni_mb_session));
- struct rte_mempool *sess_mp = rte_mempool_from_obj(sess_priv);
- set_sym_session_private_data(sess, index, NULL);
- rte_mempool_put(sess_mp, sess_priv);
- }
+ if (sess)
+ memset(sess, 0, sizeof(struct aesni_mb_session));
}
struct rte_cryptodev_ops aesni_mb_pmd_ops = {
diff --git a/drivers/crypto/armv8/rte_armv8_pmd_ops.c b/drivers/crypto/armv8/rte_armv8_pmd_ops.c
index 1b2749fe62..2d3b54b063 100644
--- a/drivers/crypto/armv8/rte_armv8_pmd_ops.c
+++ b/drivers/crypto/armv8/rte_armv8_pmd_ops.c
@@ -244,7 +244,6 @@ armv8_crypto_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
goto qp_setup_cleanup;
qp->sess_mp = qp_conf->mp_session;
- qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->stats, 0, sizeof(qp->stats));
@@ -268,10 +267,8 @@ armv8_crypto_pmd_sym_session_get_size(struct rte_cryptodev *dev __rte_unused)
static int
armv8_crypto_pmd_sym_session_configure(struct rte_cryptodev *dev,
struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *sess,
- struct rte_mempool *mempool)
+ void *sess)
{
- void *sess_private_data;
int ret;
if (unlikely(sess == NULL)) {
@@ -279,42 +276,23 @@ armv8_crypto_pmd_sym_session_configure(struct rte_cryptodev *dev,
return -EINVAL;
}
- if (rte_mempool_get(mempool, &sess_private_data)) {
- CDEV_LOG_ERR(
- "Couldn't get object from session mempool");
- return -ENOMEM;
- }
-
- ret = armv8_crypto_set_session_parameters(sess_private_data, xform);
+ ret = armv8_crypto_set_session_parameters(sess, xform);
if (ret != 0) {
ARMV8_CRYPTO_LOG_ERR("failed configure session parameters");
-
- /* Return session to mempool */
- rte_mempool_put(mempool, sess_private_data);
return ret;
}
- set_sym_session_private_data(sess, dev->driver_id,
- sess_private_data);
-
return 0;
}
/** Clear the memory of session so it doesn't leave key material behind */
static void
-armv8_crypto_pmd_sym_session_clear(struct rte_cryptodev *dev,
- struct rte_cryptodev_sym_session *sess)
+armv8_crypto_pmd_sym_session_clear(struct rte_cryptodev *dev, void *sess)
{
- uint8_t index = dev->driver_id;
- void *sess_priv = get_sym_session_private_data(sess, index);
-
+ RTE_SET_USED(dev);
/* Zero out the whole structure */
- if (sess_priv) {
- memset(sess_priv, 0, sizeof(struct armv8_crypto_session));
- struct rte_mempool *sess_mp = rte_mempool_from_obj(sess_priv);
- set_sym_session_private_data(sess, index, NULL);
- rte_mempool_put(sess_mp, sess_priv);
- }
+ if (sess)
+ memset(sess, 0, sizeof(struct armv8_crypto_session));
}
struct rte_cryptodev_ops armv8_crypto_pmd_ops = {
diff --git a/drivers/crypto/bcmfs/bcmfs_sym_session.c b/drivers/crypto/bcmfs/bcmfs_sym_session.c
index 675ed0ad55..b4b167d0c2 100644
--- a/drivers/crypto/bcmfs/bcmfs_sym_session.c
+++ b/drivers/crypto/bcmfs/bcmfs_sym_session.c
@@ -224,10 +224,9 @@ bcmfs_sym_get_session(struct rte_crypto_op *op)
int
bcmfs_sym_session_configure(struct rte_cryptodev *dev,
struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *sess,
- struct rte_mempool *mempool)
+ void *sess)
{
- void *sess_private_data;
+ RTE_SET_USED(dev);
int ret;
if (unlikely(sess == NULL)) {
@@ -235,44 +234,23 @@ bcmfs_sym_session_configure(struct rte_cryptodev *dev,
return -EINVAL;
}
- if (rte_mempool_get(mempool, &sess_private_data)) {
- BCMFS_DP_LOG(ERR,
- "Couldn't get object from session mempool");
- return -ENOMEM;
- }
-
- ret = crypto_set_session_parameters(sess_private_data, xform);
+ ret = crypto_set_session_parameters(sess, xform);
if (ret != 0) {
BCMFS_DP_LOG(ERR, "Failed configure session parameters");
- /* Return session to mempool */
- rte_mempool_put(mempool, sess_private_data);
return ret;
}
- set_sym_session_private_data(sess, dev->driver_id,
- sess_private_data);
-
return 0;
}
/* Clear the memory of session so it doesn't leave key material behind */
void
-bcmfs_sym_session_clear(struct rte_cryptodev *dev,
- struct rte_cryptodev_sym_session *sess)
+bcmfs_sym_session_clear(struct rte_cryptodev *dev, void *sess)
{
- uint8_t index = dev->driver_id;
- void *sess_priv = get_sym_session_private_data(sess, index);
-
- if (sess_priv) {
- struct rte_mempool *sess_mp;
-
- memset(sess_priv, 0, sizeof(struct bcmfs_sym_session));
- sess_mp = rte_mempool_from_obj(sess_priv);
-
- set_sym_session_private_data(sess, index, NULL);
- rte_mempool_put(sess_mp, sess_priv);
- }
+ RTE_SET_USED(dev);
+ if (sess)
+ memset(sess, 0, sizeof(struct bcmfs_sym_session));
}
unsigned int
diff --git a/drivers/crypto/bcmfs/bcmfs_sym_session.h b/drivers/crypto/bcmfs/bcmfs_sym_session.h
index d40595b4bd..7faafe2fd5 100644
--- a/drivers/crypto/bcmfs/bcmfs_sym_session.h
+++ b/drivers/crypto/bcmfs/bcmfs_sym_session.h
@@ -93,12 +93,10 @@ bcmfs_process_crypto_op(struct rte_crypto_op *op,
int
bcmfs_sym_session_configure(struct rte_cryptodev *dev,
struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *sess,
- struct rte_mempool *mempool);
+ void *sess);
void
-bcmfs_sym_session_clear(struct rte_cryptodev *dev,
- struct rte_cryptodev_sym_session *sess);
+bcmfs_sym_session_clear(struct rte_cryptodev *dev, void *sess);
unsigned int
bcmfs_sym_session_get_private_size(struct rte_cryptodev *dev __rte_unused);
diff --git a/drivers/crypto/caam_jr/caam_jr.c b/drivers/crypto/caam_jr/caam_jr.c
index 0567f1e066..a1fd6d996a 100644
--- a/drivers/crypto/caam_jr/caam_jr.c
+++ b/drivers/crypto/caam_jr/caam_jr.c
@@ -1692,52 +1692,36 @@ caam_jr_set_session_parameters(struct rte_cryptodev *dev,
static int
caam_jr_sym_session_configure(struct rte_cryptodev *dev,
struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *sess,
- struct rte_mempool *mempool)
+ void *sess)
{
- void *sess_private_data;
int ret;
PMD_INIT_FUNC_TRACE();
- if (rte_mempool_get(mempool, &sess_private_data)) {
- CAAM_JR_ERR("Couldn't get object from session mempool");
- return -ENOMEM;
- }
-
- memset(sess_private_data, 0, sizeof(struct caam_jr_session));
- ret = caam_jr_set_session_parameters(dev, xform, sess_private_data);
+ memset(sess, 0, sizeof(struct caam_jr_session));
+ ret = caam_jr_set_session_parameters(dev, xform, sess);
if (ret != 0) {
CAAM_JR_ERR("failed to configure session parameters");
- /* Return session to mempool */
- rte_mempool_put(mempool, sess_private_data);
return ret;
}
- set_sym_session_private_data(sess, dev->driver_id, sess_private_data);
-
return 0;
}
/* Clear the memory of session so it doesn't leave key material behind */
static void
-caam_jr_sym_session_clear(struct rte_cryptodev *dev,
- struct rte_cryptodev_sym_session *sess)
+caam_jr_sym_session_clear(struct rte_cryptodev *dev, void *sess)
{
- uint8_t index = dev->driver_id;
- void *sess_priv = get_sym_session_private_data(sess, index);
- struct caam_jr_session *s = (struct caam_jr_session *)sess_priv;
+ RTE_SET_USED(dev);
+
+ struct caam_jr_session *s = (struct caam_jr_session *)sess;
PMD_INIT_FUNC_TRACE();
- if (sess_priv) {
- struct rte_mempool *sess_mp = rte_mempool_from_obj(sess_priv);
-
+ if (sess) {
rte_free(s->cipher_key.data);
rte_free(s->auth_key.data);
memset(s, 0, sizeof(struct caam_jr_session));
- set_sym_session_private_data(sess, index, NULL);
- rte_mempool_put(sess_mp, sess_priv);
}
}
diff --git a/drivers/crypto/ccp/ccp_pmd_ops.c b/drivers/crypto/ccp/ccp_pmd_ops.c
index 0d615d311c..cac1268130 100644
--- a/drivers/crypto/ccp/ccp_pmd_ops.c
+++ b/drivers/crypto/ccp/ccp_pmd_ops.c
@@ -727,7 +727,6 @@ ccp_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
}
qp->sess_mp = qp_conf->mp_session;
- qp->sess_mp_priv = qp_conf->mp_session_private;
/* mempool for batch info */
qp->batch_mp = rte_mempool_create(
@@ -758,11 +757,9 @@ ccp_pmd_sym_session_get_size(struct rte_cryptodev *dev __rte_unused)
static int
ccp_pmd_sym_session_configure(struct rte_cryptodev *dev,
struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *sess,
- struct rte_mempool *mempool)
+ void *sess)
{
int ret;
- void *sess_private_data;
struct ccp_private *internals;
if (unlikely(sess == NULL || xform == NULL)) {
@@ -770,39 +767,22 @@ ccp_pmd_sym_session_configure(struct rte_cryptodev *dev,
return -ENOMEM;
}
- if (rte_mempool_get(mempool, &sess_private_data)) {
- CCP_LOG_ERR("Couldn't get object from session mempool");
- return -ENOMEM;
- }
internals = (struct ccp_private *)dev->data->dev_private;
- ret = ccp_set_session_parameters(sess_private_data, xform, internals);
+ ret = ccp_set_session_parameters(sess, xform, internals);
if (ret != 0) {
CCP_LOG_ERR("failed configure session parameters");
-
- /* Return session to mempool */
- rte_mempool_put(mempool, sess_private_data);
return ret;
}
- set_sym_session_private_data(sess, dev->driver_id,
- sess_private_data);
return 0;
}
static void
-ccp_pmd_sym_session_clear(struct rte_cryptodev *dev,
- struct rte_cryptodev_sym_session *sess)
+ccp_pmd_sym_session_clear(struct rte_cryptodev *dev, void *sess)
{
- uint8_t index = dev->driver_id;
- void *sess_priv = get_sym_session_private_data(sess, index);
-
- if (sess_priv) {
- struct rte_mempool *sess_mp = rte_mempool_from_obj(sess_priv);
-
- rte_mempool_put(sess_mp, sess_priv);
- memset(sess_priv, 0, sizeof(struct ccp_session));
- set_sym_session_private_data(sess, index, NULL);
- }
+ RTE_SET_USED(dev);
+ if (sess)
+ memset(sess, 0, sizeof(struct ccp_session));
}
struct rte_cryptodev_ops ccp_ops = {
diff --git a/drivers/crypto/cnxk/cn10k_cryptodev_ops.c b/drivers/crypto/cnxk/cn10k_cryptodev_ops.c
index de2eebd507..76c992858f 100644
--- a/drivers/crypto/cnxk/cn10k_cryptodev_ops.c
+++ b/drivers/crypto/cnxk/cn10k_cryptodev_ops.c
@@ -32,17 +32,18 @@ cn10k_cpt_sym_temp_sess_create(struct cnxk_cpt_qp *qp, struct rte_crypto_op *op)
if (sess == NULL)
return NULL;
- ret = sym_session_configure(qp->lf.roc_cpt, driver_id, sym_op->xform,
- sess, qp->sess_mp_priv);
+ sess->sess_data[driver_id].data =
+ (void *)((uint8_t *)sess +
+ rte_cryptodev_sym_get_header_session_size() +
+ (driver_id * sess->priv_sz));
+ priv = get_sym_session_private_data(sess, driver_id);
+ ret = sym_session_configure(qp->lf.roc_cpt, sym_op->xform, (void *)priv);
if (ret)
goto sess_put;
- priv = get_sym_session_private_data(sess, driver_id);
-
sym_op->session = sess;
return priv;
-
sess_put:
rte_mempool_put(qp->sess_mp, sess);
return NULL;
@@ -147,9 +148,7 @@ cn10k_cpt_fill_inst(struct cnxk_cpt_qp *qp, struct rte_crypto_op *ops[],
ret = cpt_sym_inst_fill(qp, op, sess, infl_req,
&inst[0]);
if (unlikely(ret)) {
- sym_session_clear(cn10k_cryptodev_driver_id,
- op->sym->session);
- rte_mempool_put(qp->sess_mp, op->sym->session);
+ sym_session_clear(op->sym->session);
return 0;
}
w7 = sess->cpt_inst_w7;
@@ -474,8 +473,7 @@ cn10k_cpt_dequeue_post_process(struct cnxk_cpt_qp *qp,
temp_sess_free:
if (unlikely(cop->sess_type == RTE_CRYPTO_OP_SESSIONLESS)) {
if (cop->type == RTE_CRYPTO_OP_TYPE_SYMMETRIC) {
- sym_session_clear(cn10k_cryptodev_driver_id,
- cop->sym->session);
+ sym_session_clear(cop->sym->session);
sz = rte_cryptodev_sym_get_existing_header_session_size(
cop->sym->session);
memset(cop->sym->session, 0, sz);
diff --git a/drivers/crypto/cnxk/cn9k_cryptodev_ops.c b/drivers/crypto/cnxk/cn9k_cryptodev_ops.c
index 4c2dc5b080..5f83581131 100644
--- a/drivers/crypto/cnxk/cn9k_cryptodev_ops.c
+++ b/drivers/crypto/cnxk/cn9k_cryptodev_ops.c
@@ -81,17 +81,19 @@ cn9k_cpt_sym_temp_sess_create(struct cnxk_cpt_qp *qp, struct rte_crypto_op *op)
if (sess == NULL)
return NULL;
- ret = sym_session_configure(qp->lf.roc_cpt, driver_id, sym_op->xform,
- sess, qp->sess_mp_priv);
+ sess->sess_data[driver_id].data =
+ (void *)((uint8_t *)sess +
+ rte_cryptodev_sym_get_header_session_size() +
+ (driver_id * sess->priv_sz));
+ priv = get_sym_session_private_data(sess, driver_id);
+ ret = sym_session_configure(qp->lf.roc_cpt, sym_op->xform,
+ (void *)priv);
if (ret)
goto sess_put;
- priv = get_sym_session_private_data(sess, driver_id);
-
sym_op->session = sess;
return priv;
-
sess_put:
rte_mempool_put(qp->sess_mp, sess);
return NULL;
@@ -126,8 +128,7 @@ cn9k_cpt_inst_prep(struct cnxk_cpt_qp *qp, struct rte_crypto_op *op,
ret = cn9k_cpt_sym_inst_fill(qp, op, sess, infl_req,
inst);
if (unlikely(ret)) {
- sym_session_clear(cn9k_cryptodev_driver_id,
- op->sym->session);
+ sym_session_clear(op->sym->session);
rte_mempool_put(qp->sess_mp, op->sym->session);
}
inst->w7.u64 = sess->cpt_inst_w7;
@@ -484,8 +485,7 @@ cn9k_cpt_dequeue_post_process(struct cnxk_cpt_qp *qp, struct rte_crypto_op *cop,
temp_sess_free:
if (unlikely(cop->sess_type == RTE_CRYPTO_OP_SESSIONLESS)) {
if (cop->type == RTE_CRYPTO_OP_TYPE_SYMMETRIC) {
- sym_session_clear(cn9k_cryptodev_driver_id,
- cop->sym->session);
+ sym_session_clear(cop->sym->session);
sz = rte_cryptodev_sym_get_existing_header_session_size(
cop->sym->session);
memset(cop->sym->session, 0, sz);
diff --git a/drivers/crypto/cnxk/cnxk_cryptodev_ops.c b/drivers/crypto/cnxk/cnxk_cryptodev_ops.c
index 41d8fe49e1..52d9cf0cf3 100644
--- a/drivers/crypto/cnxk/cnxk_cryptodev_ops.c
+++ b/drivers/crypto/cnxk/cnxk_cryptodev_ops.c
@@ -379,7 +379,6 @@ cnxk_cpt_queue_pair_setup(struct rte_cryptodev *dev, uint16_t qp_id,
}
qp->sess_mp = conf->mp_session;
- qp->sess_mp_priv = conf->mp_session_private;
dev->data->queue_pairs[qp_id] = qp;
return 0;
@@ -493,27 +492,20 @@ cnxk_cpt_inst_w7_get(struct cnxk_se_sess *sess, struct roc_cpt *roc_cpt)
}
int
-sym_session_configure(struct roc_cpt *roc_cpt, int driver_id,
+sym_session_configure(struct roc_cpt *roc_cpt,
struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *sess,
- struct rte_mempool *pool)
+ void *sess)
{
struct cnxk_se_sess *sess_priv;
- void *priv;
int ret;
ret = sym_xform_verify(xform);
if (unlikely(ret < 0))
return ret;
- if (unlikely(rte_mempool_get(pool, &priv))) {
- plt_dp_err("Could not allocate session private data");
- return -ENOMEM;
- }
+ memset(sess, 0, sizeof(struct cnxk_se_sess));
- memset(priv, 0, sizeof(struct cnxk_se_sess));
-
- sess_priv = priv;
+ sess_priv = sess;
switch (ret) {
case CNXK_CPT_CIPHER:
@@ -547,7 +539,7 @@ sym_session_configure(struct roc_cpt *roc_cpt, int driver_id,
}
if (ret)
- goto priv_put;
+ return -ENOTSUP;
if ((sess_priv->roc_se_ctx.fc_type == ROC_SE_HASH_HMAC) &&
cpt_mac_len_verify(&xform->auth)) {
@@ -557,66 +549,45 @@ sym_session_configure(struct roc_cpt *roc_cpt, int driver_id,
sess_priv->roc_se_ctx.auth_key = NULL;
}
- ret = -ENOTSUP;
- goto priv_put;
+ return -ENOTSUP;
}
sess_priv->cpt_inst_w7 = cnxk_cpt_inst_w7_get(sess_priv, roc_cpt);
- set_sym_session_private_data(sess, driver_id, sess_priv);
-
return 0;
-
-priv_put:
- rte_mempool_put(pool, priv);
-
- return -ENOTSUP;
}
int
cnxk_cpt_sym_session_configure(struct rte_cryptodev *dev,
struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *sess,
- struct rte_mempool *pool)
+ void *sess)
{
struct cnxk_cpt_vf *vf = dev->data->dev_private;
struct roc_cpt *roc_cpt = &vf->cpt;
- uint8_t driver_id;
- driver_id = dev->driver_id;
-
- return sym_session_configure(roc_cpt, driver_id, xform, sess, pool);
+ return sym_session_configure(roc_cpt, xform, sess);
}
void
-sym_session_clear(int driver_id, struct rte_cryptodev_sym_session *sess)
+sym_session_clear(void *sess)
{
- void *priv = get_sym_session_private_data(sess, driver_id);
- struct cnxk_se_sess *sess_priv;
- struct rte_mempool *pool;
+ struct cnxk_se_sess *sess_priv = sess;
- if (priv == NULL)
+ if (sess == NULL)
return;
- sess_priv = priv;
-
if (sess_priv->roc_se_ctx.auth_key != NULL)
plt_free(sess_priv->roc_se_ctx.auth_key);
- memset(priv, 0, cnxk_cpt_sym_session_get_size(NULL));
-
- pool = rte_mempool_from_obj(priv);
-
- set_sym_session_private_data(sess, driver_id, NULL);
-
- rte_mempool_put(pool, priv);
+ memset(sess_priv, 0, cnxk_cpt_sym_session_get_size(NULL));
}
void
-cnxk_cpt_sym_session_clear(struct rte_cryptodev *dev,
- struct rte_cryptodev_sym_session *sess)
+cnxk_cpt_sym_session_clear(struct rte_cryptodev *dev, void *sess)
{
- return sym_session_clear(dev->driver_id, sess);
+ RTE_SET_USED(dev);
+
+ return sym_session_clear(sess);
}
unsigned int
diff --git a/drivers/crypto/cnxk/cnxk_cryptodev_ops.h b/drivers/crypto/cnxk/cnxk_cryptodev_ops.h
index c5332dec53..3c09d10582 100644
--- a/drivers/crypto/cnxk/cnxk_cryptodev_ops.h
+++ b/drivers/crypto/cnxk/cnxk_cryptodev_ops.h
@@ -111,18 +111,15 @@ unsigned int cnxk_cpt_sym_session_get_size(struct rte_cryptodev *dev);
int cnxk_cpt_sym_session_configure(struct rte_cryptodev *dev,
struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *sess,
- struct rte_mempool *pool);
+ void *sess);
-int sym_session_configure(struct roc_cpt *roc_cpt, int driver_id,
+int sym_session_configure(struct roc_cpt *roc_cpt,
struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *sess,
- struct rte_mempool *pool);
+ void *sess);
-void cnxk_cpt_sym_session_clear(struct rte_cryptodev *dev,
- struct rte_cryptodev_sym_session *sess);
+void cnxk_cpt_sym_session_clear(struct rte_cryptodev *dev, void *sess);
-void sym_session_clear(int driver_id, struct rte_cryptodev_sym_session *sess);
+void sym_session_clear(void *sess);
unsigned int cnxk_ae_session_size_get(struct rte_cryptodev *dev __rte_unused);
diff --git a/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c b/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
index 15ea5de18d..d4f223f2f9 100644
--- a/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
+++ b/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
@@ -3439,49 +3439,32 @@ dpaa2_sec_security_session_destroy(void *dev __rte_unused, void *sess)
static int
dpaa2_sec_sym_session_configure(struct rte_cryptodev *dev,
struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *sess,
- struct rte_mempool *mempool)
+ void *sess)
{
- void *sess_private_data;
int ret;
- if (rte_mempool_get(mempool, &sess_private_data)) {
- DPAA2_SEC_ERR("Couldn't get object from session mempool");
- return -ENOMEM;
- }
-
- ret = dpaa2_sec_set_session_parameters(dev, xform, sess_private_data);
+ ret = dpaa2_sec_set_session_parameters(dev, xform, sess);
if (ret != 0) {
DPAA2_SEC_ERR("Failed to configure session parameters");
- /* Return session to mempool */
- rte_mempool_put(mempool, sess_private_data);
return ret;
}
- set_sym_session_private_data(sess, dev->driver_id,
- sess_private_data);
-
return 0;
}
/** Clear the memory of session so it doesn't leave key material behind */
static void
-dpaa2_sec_sym_session_clear(struct rte_cryptodev *dev,
- struct rte_cryptodev_sym_session *sess)
+dpaa2_sec_sym_session_clear(struct rte_cryptodev *dev, void *sess)
{
PMD_INIT_FUNC_TRACE();
- uint8_t index = dev->driver_id;
- void *sess_priv = get_sym_session_private_data(sess, index);
- dpaa2_sec_session *s = (dpaa2_sec_session *)sess_priv;
+ RTE_SET_USED(dev);
+ dpaa2_sec_session *s = (dpaa2_sec_session *)sess;
- if (sess_priv) {
+ if (sess) {
rte_free(s->ctxt);
rte_free(s->cipher_key.data);
rte_free(s->auth_key.data);
memset(s, 0, sizeof(dpaa2_sec_session));
- struct rte_mempool *sess_mp = rte_mempool_from_obj(sess_priv);
- set_sym_session_private_data(sess, index, NULL);
- rte_mempool_put(sess_mp, sess_priv);
}
}
diff --git a/drivers/crypto/dpaa_sec/dpaa_sec.c b/drivers/crypto/dpaa_sec/dpaa_sec.c
index 0497931c67..a9295eb154 100644
--- a/drivers/crypto/dpaa_sec/dpaa_sec.c
+++ b/drivers/crypto/dpaa_sec/dpaa_sec.c
@@ -2537,33 +2537,18 @@ dpaa_sec_set_session_parameters(struct rte_cryptodev *dev,
static int
dpaa_sec_sym_session_configure(struct rte_cryptodev *dev,
- struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *sess,
- struct rte_mempool *mempool)
+ struct rte_crypto_sym_xform *xform, void *sess)
{
- void *sess_private_data;
int ret;
PMD_INIT_FUNC_TRACE();
- if (rte_mempool_get(mempool, &sess_private_data)) {
- DPAA_SEC_ERR("Couldn't get object from session mempool");
- return -ENOMEM;
- }
-
- ret = dpaa_sec_set_session_parameters(dev, xform, sess_private_data);
+ ret = dpaa_sec_set_session_parameters(dev, xform, sess);
if (ret != 0) {
DPAA_SEC_ERR("failed to configure session parameters");
-
- /* Return session to mempool */
- rte_mempool_put(mempool, sess_private_data);
return ret;
}
- set_sym_session_private_data(sess, dev->driver_id,
- sess_private_data);
-
-
return 0;
}
@@ -2584,18 +2569,14 @@ free_session_memory(struct rte_cryptodev *dev, dpaa_sec_session *s)
/** Clear the memory of session so it doesn't leave key material behind */
static void
-dpaa_sec_sym_session_clear(struct rte_cryptodev *dev,
- struct rte_cryptodev_sym_session *sess)
+dpaa_sec_sym_session_clear(struct rte_cryptodev *dev, void *sess)
{
PMD_INIT_FUNC_TRACE();
- uint8_t index = dev->driver_id;
- void *sess_priv = get_sym_session_private_data(sess, index);
- dpaa_sec_session *s = (dpaa_sec_session *)sess_priv;
+ RTE_SET_USED(dev);
+ dpaa_sec_session *s = (dpaa_sec_session *)sess;
- if (sess_priv) {
+ if (sess)
free_session_memory(dev, s);
- set_sym_session_private_data(sess, index, NULL);
- }
}
#ifdef RTE_LIB_SECURITY
diff --git a/drivers/crypto/kasumi/rte_kasumi_pmd_ops.c b/drivers/crypto/kasumi/rte_kasumi_pmd_ops.c
index f075054807..b2e5c92598 100644
--- a/drivers/crypto/kasumi/rte_kasumi_pmd_ops.c
+++ b/drivers/crypto/kasumi/rte_kasumi_pmd_ops.c
@@ -220,7 +220,6 @@ kasumi_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
qp->mgr = internals->mgr;
qp->sess_mp = qp_conf->mp_session;
- qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->qp_stats, 0, sizeof(qp->qp_stats));
@@ -243,10 +242,8 @@ kasumi_pmd_sym_session_get_size(struct rte_cryptodev *dev __rte_unused)
static int
kasumi_pmd_sym_session_configure(struct rte_cryptodev *dev,
struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *sess,
- struct rte_mempool *mempool)
+ void *sess)
{
- void *sess_private_data;
int ret;
struct kasumi_private *internals = dev->data->dev_private;
@@ -255,43 +252,24 @@ kasumi_pmd_sym_session_configure(struct rte_cryptodev *dev,
return -EINVAL;
}
- if (rte_mempool_get(mempool, &sess_private_data)) {
- KASUMI_LOG(ERR,
- "Couldn't get object from session mempool");
- return -ENOMEM;
- }
-
ret = kasumi_set_session_parameters(internals->mgr,
- sess_private_data, xform);
+ sess, xform);
if (ret != 0) {
KASUMI_LOG(ERR, "failed configure session parameters");
-
- /* Return session to mempool */
- rte_mempool_put(mempool, sess_private_data);
return ret;
}
- set_sym_session_private_data(sess, dev->driver_id,
- sess_private_data);
-
return 0;
}
/** Clear the memory of session so it doesn't leave key material behind */
static void
-kasumi_pmd_sym_session_clear(struct rte_cryptodev *dev,
- struct rte_cryptodev_sym_session *sess)
+kasumi_pmd_sym_session_clear(struct rte_cryptodev *dev, void *sess)
{
- uint8_t index = dev->driver_id;
- void *sess_priv = get_sym_session_private_data(sess, index);
-
+ RTE_SET_USED(dev);
/* Zero out the whole structure */
- if (sess_priv) {
- memset(sess_priv, 0, sizeof(struct kasumi_session));
- struct rte_mempool *sess_mp = rte_mempool_from_obj(sess_priv);
- set_sym_session_private_data(sess, index, NULL);
- rte_mempool_put(sess_mp, sess_priv);
- }
+ if (sess)
+ memset(sess, 0, sizeof(struct kasumi_session));
}
struct rte_cryptodev_ops kasumi_pmd_ops = {
diff --git a/drivers/crypto/mlx5/mlx5_crypto.c b/drivers/crypto/mlx5/mlx5_crypto.c
index 6a2f8b6ac6..9c60c3d117 100644
--- a/drivers/crypto/mlx5/mlx5_crypto.c
+++ b/drivers/crypto/mlx5/mlx5_crypto.c
@@ -165,14 +165,12 @@ mlx5_crypto_sym_session_get_size(struct rte_cryptodev *dev __rte_unused)
static int
mlx5_crypto_sym_session_configure(struct rte_cryptodev *dev,
struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *session,
- struct rte_mempool *mp)
+ void *session)
{
struct mlx5_crypto_priv *priv = dev->data->dev_private;
- struct mlx5_crypto_session *sess_private_data;
+ struct mlx5_crypto_session *sess_private_data = session;
struct rte_crypto_cipher_xform *cipher;
uint8_t encryption_order;
- int ret;
if (unlikely(xform->next != NULL)) {
DRV_LOG(ERR, "Xform next is not supported.");
@@ -183,17 +181,9 @@ mlx5_crypto_sym_session_configure(struct rte_cryptodev *dev,
DRV_LOG(ERR, "Only AES-XTS algorithm is supported.");
return -ENOTSUP;
}
- ret = rte_mempool_get(mp, (void *)&sess_private_data);
- if (ret != 0) {
- DRV_LOG(ERR,
- "Failed to get session %p private data from mempool.",
- sess_private_data);
- return -ENOMEM;
- }
cipher = &xform->cipher;
sess_private_data->dek = mlx5_crypto_dek_prepare(priv, cipher);
if (sess_private_data->dek == NULL) {
- rte_mempool_put(mp, sess_private_data);
DRV_LOG(ERR, "Failed to prepare dek.");
return -ENOMEM;
}
@@ -228,27 +218,21 @@ mlx5_crypto_sym_session_configure(struct rte_cryptodev *dev,
sess_private_data->dek_id =
rte_cpu_to_be_32(sess_private_data->dek->obj->id &
0xffffff);
- set_sym_session_private_data(session, dev->driver_id,
- sess_private_data);
DRV_LOG(DEBUG, "Session %p was configured.", sess_private_data);
return 0;
}
static void
-mlx5_crypto_sym_session_clear(struct rte_cryptodev *dev,
- struct rte_cryptodev_sym_session *sess)
+mlx5_crypto_sym_session_clear(struct rte_cryptodev *dev, void *sess)
{
struct mlx5_crypto_priv *priv = dev->data->dev_private;
- struct mlx5_crypto_session *spriv = get_sym_session_private_data(sess,
- dev->driver_id);
+ struct mlx5_crypto_session *spriv = sess;
if (unlikely(spriv == NULL)) {
DRV_LOG(ERR, "Failed to get session %p private data.", spriv);
return;
}
mlx5_crypto_dek_destroy(priv, spriv->dek);
- set_sym_session_private_data(sess, dev->driver_id, NULL);
- rte_mempool_put(rte_mempool_from_obj(spriv), spriv);
DRV_LOG(DEBUG, "Session %p was cleared.", spriv);
}
diff --git a/drivers/crypto/mvsam/rte_mrvl_pmd_ops.c b/drivers/crypto/mvsam/rte_mrvl_pmd_ops.c
index e04a2c88c7..2e4b27ea21 100644
--- a/drivers/crypto/mvsam/rte_mrvl_pmd_ops.c
+++ b/drivers/crypto/mvsam/rte_mrvl_pmd_ops.c
@@ -704,7 +704,6 @@ mrvl_crypto_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
break;
qp->sess_mp = qp_conf->mp_session;
- qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->stats, 0, sizeof(qp->stats));
dev->data->queue_pairs[qp_id] = qp;
@@ -735,12 +734,9 @@ mrvl_crypto_pmd_sym_session_get_size(__rte_unused struct rte_cryptodev *dev)
*/
static int
mrvl_crypto_pmd_sym_session_configure(__rte_unused struct rte_cryptodev *dev,
- struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *sess,
- struct rte_mempool *mp)
+ struct rte_crypto_sym_xform *xform, void *sess)
{
struct mrvl_crypto_session *mrvl_sess;
- void *sess_private_data;
int ret;
if (sess == NULL) {
@@ -748,25 +744,16 @@ mrvl_crypto_pmd_sym_session_configure(__rte_unused struct rte_cryptodev *dev,
return -EINVAL;
}
- if (rte_mempool_get(mp, &sess_private_data)) {
- CDEV_LOG_ERR("Couldn't get object from session mempool.");
- return -ENOMEM;
- }
+ memset(sess, 0, sizeof(struct mrvl_crypto_session));
- memset(sess_private_data, 0, sizeof(struct mrvl_crypto_session));
-
- ret = mrvl_crypto_set_session_parameters(sess_private_data, xform);
+ ret = mrvl_crypto_set_session_parameters(sess, xform);
if (ret != 0) {
MRVL_LOG(ERR, "Failed to configure session parameters!");
-
- /* Return session to mempool */
- rte_mempool_put(mp, sess_private_data);
return ret;
}
- set_sym_session_private_data(sess, dev->driver_id, sess_private_data);
- mrvl_sess = (struct mrvl_crypto_session *)sess_private_data;
+ mrvl_sess = (struct mrvl_crypto_session *)sess;
if (sam_session_create(&mrvl_sess->sam_sess_params,
&mrvl_sess->sam_sess) < 0) {
MRVL_LOG(DEBUG, "Failed to create session!");
@@ -789,17 +776,13 @@ mrvl_crypto_pmd_sym_session_configure(__rte_unused struct rte_cryptodev *dev,
* @returns 0. Always.
*/
static void
-mrvl_crypto_pmd_sym_session_clear(struct rte_cryptodev *dev,
- struct rte_cryptodev_sym_session *sess)
+mrvl_crypto_pmd_sym_session_clear(struct rte_cryptodev *dev, void *sess)
{
-
- uint8_t index = dev->driver_id;
- void *sess_priv = get_sym_session_private_data(sess, index);
-
+ RTE_SET_USED(dev);
/* Zero out the whole structure */
- if (sess_priv) {
+ if (sess) {
struct mrvl_crypto_session *mrvl_sess =
- (struct mrvl_crypto_session *)sess_priv;
+ (struct mrvl_crypto_session *)sess;
if (mrvl_sess->sam_sess &&
sam_session_destroy(mrvl_sess->sam_sess) < 0) {
@@ -807,9 +790,6 @@ mrvl_crypto_pmd_sym_session_clear(struct rte_cryptodev *dev,
}
memset(mrvl_sess, 0, sizeof(struct mrvl_crypto_session));
- struct rte_mempool *sess_mp = rte_mempool_from_obj(sess_priv);
- set_sym_session_private_data(sess, index, NULL);
- rte_mempool_put(sess_mp, sess_priv);
}
}
diff --git a/drivers/crypto/nitrox/nitrox_sym.c b/drivers/crypto/nitrox/nitrox_sym.c
index f8b7edcd69..0c9bbfef46 100644
--- a/drivers/crypto/nitrox/nitrox_sym.c
+++ b/drivers/crypto/nitrox/nitrox_sym.c
@@ -532,22 +532,16 @@ configure_aead_ctx(struct rte_crypto_aead_xform *xform,
static int
nitrox_sym_dev_sess_configure(struct rte_cryptodev *cdev,
struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *sess,
- struct rte_mempool *mempool)
+ void *sess)
{
- void *mp_obj;
struct nitrox_crypto_ctx *ctx;
struct rte_crypto_cipher_xform *cipher_xform = NULL;
struct rte_crypto_auth_xform *auth_xform = NULL;
struct rte_crypto_aead_xform *aead_xform = NULL;
int ret = -EINVAL;
- if (rte_mempool_get(mempool, &mp_obj)) {
- NITROX_LOG(ERR, "Couldn't allocate context\n");
- return -ENOMEM;
- }
-
- ctx = mp_obj;
+ RTE_SET_USED(cdev);
+ ctx = sess;
ctx->nitrox_chain = get_crypto_chain_order(xform);
switch (ctx->nitrox_chain) {
case NITROX_CHAIN_CIPHER_ONLY:
@@ -586,28 +580,17 @@ nitrox_sym_dev_sess_configure(struct rte_cryptodev *cdev,
}
ctx->iova = rte_mempool_virt2iova(ctx);
- set_sym_session_private_data(sess, cdev->driver_id, ctx);
return 0;
err:
- rte_mempool_put(mempool, mp_obj);
return ret;
}
static void
-nitrox_sym_dev_sess_clear(struct rte_cryptodev *cdev,
- struct rte_cryptodev_sym_session *sess)
+nitrox_sym_dev_sess_clear(struct rte_cryptodev *cdev, void *sess)
{
- struct nitrox_crypto_ctx *ctx = get_sym_session_private_data(sess,
- cdev->driver_id);
- struct rte_mempool *sess_mp;
-
- if (!ctx)
- return;
-
- memset(ctx, 0, sizeof(*ctx));
- sess_mp = rte_mempool_from_obj(ctx);
- set_sym_session_private_data(sess, cdev->driver_id, NULL);
- rte_mempool_put(sess_mp, ctx);
+ RTE_SET_USED(cdev);
+ if (sess)
+ memset(sess, 0, sizeof(struct nitrox_crypto_ctx));
}
static struct nitrox_crypto_ctx *
diff --git a/drivers/crypto/null/null_crypto_pmd_ops.c b/drivers/crypto/null/null_crypto_pmd_ops.c
index a8b5a06e7f..65bfa8dcf7 100644
--- a/drivers/crypto/null/null_crypto_pmd_ops.c
+++ b/drivers/crypto/null/null_crypto_pmd_ops.c
@@ -234,7 +234,6 @@ null_crypto_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
}
qp->sess_mp = qp_conf->mp_session;
- qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->qp_stats, 0, sizeof(qp->qp_stats));
@@ -258,10 +257,8 @@ null_crypto_pmd_sym_session_get_size(struct rte_cryptodev *dev __rte_unused)
static int
null_crypto_pmd_sym_session_configure(struct rte_cryptodev *dev __rte_unused,
struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *sess,
- struct rte_mempool *mp)
+ void *sess)
{
- void *sess_private_data;
int ret;
if (unlikely(sess == NULL)) {
@@ -269,42 +266,23 @@ null_crypto_pmd_sym_session_configure(struct rte_cryptodev *dev __rte_unused,
return -EINVAL;
}
- if (rte_mempool_get(mp, &sess_private_data)) {
- NULL_LOG(ERR,
- "Couldn't get object from session mempool");
- return -ENOMEM;
- }
-
- ret = null_crypto_set_session_parameters(sess_private_data, xform);
+ ret = null_crypto_set_session_parameters(sess, xform);
if (ret != 0) {
NULL_LOG(ERR, "failed configure session parameters");
-
- /* Return session to mempool */
- rte_mempool_put(mp, sess_private_data);
return ret;
}
- set_sym_session_private_data(sess, dev->driver_id,
- sess_private_data);
-
return 0;
}
/** Clear the memory of session so it doesn't leave key material behind */
static void
-null_crypto_pmd_sym_session_clear(struct rte_cryptodev *dev,
- struct rte_cryptodev_sym_session *sess)
+null_crypto_pmd_sym_session_clear(struct rte_cryptodev *dev, void *sess)
{
- uint8_t index = dev->driver_id;
- void *sess_priv = get_sym_session_private_data(sess, index);
-
+ RTE_SET_USED(dev);
/* Zero out the whole structure */
- if (sess_priv) {
- memset(sess_priv, 0, sizeof(struct null_crypto_session));
- struct rte_mempool *sess_mp = rte_mempool_from_obj(sess_priv);
- set_sym_session_private_data(sess, index, NULL);
- rte_mempool_put(sess_mp, sess_priv);
- }
+ if (sess)
+ memset(sess, 0, sizeof(struct null_crypto_session));
}
static struct rte_cryptodev_ops pmd_ops = {
diff --git a/drivers/crypto/octeontx/otx_cryptodev_hw_access.h b/drivers/crypto/octeontx/otx_cryptodev_hw_access.h
index e48805fb09..4647d568de 100644
--- a/drivers/crypto/octeontx/otx_cryptodev_hw_access.h
+++ b/drivers/crypto/octeontx/otx_cryptodev_hw_access.h
@@ -49,7 +49,6 @@ struct cpt_instance {
uint32_t queue_id;
uintptr_t rsvd;
struct rte_mempool *sess_mp;
- struct rte_mempool *sess_mp_priv;
struct cpt_qp_meta_info meta_info;
uint8_t ca_enabled;
};
diff --git a/drivers/crypto/octeontx/otx_cryptodev_ops.c b/drivers/crypto/octeontx/otx_cryptodev_ops.c
index 9e8fd495cf..abd0963be0 100644
--- a/drivers/crypto/octeontx/otx_cryptodev_ops.c
+++ b/drivers/crypto/octeontx/otx_cryptodev_ops.c
@@ -171,7 +171,6 @@ otx_cpt_que_pair_setup(struct rte_cryptodev *dev,
instance->queue_id = que_pair_id;
instance->sess_mp = qp_conf->mp_session;
- instance->sess_mp_priv = qp_conf->mp_session_private;
dev->data->queue_pairs[que_pair_id] = instance;
return 0;
@@ -243,29 +242,22 @@ sym_xform_verify(struct rte_crypto_sym_xform *xform)
}
static int
-sym_session_configure(int driver_id, struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *sess,
- struct rte_mempool *pool)
+sym_session_configure(struct rte_crypto_sym_xform *xform,
+ void *sess)
{
struct rte_crypto_sym_xform *temp_xform = xform;
struct cpt_sess_misc *misc;
vq_cmd_word3_t vq_cmd_w3;
- void *priv;
int ret;
ret = sym_xform_verify(xform);
if (unlikely(ret))
return ret;
- if (unlikely(rte_mempool_get(pool, &priv))) {
- CPT_LOG_ERR("Could not allocate session private data");
- return -ENOMEM;
- }
-
- memset(priv, 0, sizeof(struct cpt_sess_misc) +
+ memset(sess, 0, sizeof(struct cpt_sess_misc) +
offsetof(struct cpt_ctx, mc_ctx));
- misc = priv;
+ misc = sess;
for ( ; xform != NULL; xform = xform->next) {
switch (xform->type) {
@@ -301,8 +293,6 @@ sym_session_configure(int driver_id, struct rte_crypto_sym_xform *xform,
goto priv_put;
}
- set_sym_session_private_data(sess, driver_id, priv);
-
misc->ctx_dma_addr = rte_mempool_virt2iova(misc) +
sizeof(struct cpt_sess_misc);
@@ -316,56 +306,46 @@ sym_session_configure(int driver_id, struct rte_crypto_sym_xform *xform,
return 0;
priv_put:
- if (priv)
- rte_mempool_put(pool, priv);
return -ENOTSUP;
}
static void
-sym_session_clear(int driver_id, struct rte_cryptodev_sym_session *sess)
+sym_session_clear(void *sess)
{
- void *priv = get_sym_session_private_data(sess, driver_id);
struct cpt_sess_misc *misc;
- struct rte_mempool *pool;
struct cpt_ctx *ctx;
- if (priv == NULL)
+ if (sess == NULL)
return;
- misc = priv;
+ misc = sess;
ctx = SESS_PRIV(misc);
if (ctx->auth_key != NULL)
rte_free(ctx->auth_key);
- memset(priv, 0, cpt_get_session_size());
-
- pool = rte_mempool_from_obj(priv);
-
- set_sym_session_private_data(sess, driver_id, NULL);
-
- rte_mempool_put(pool, priv);
+ memset(sess, 0, cpt_get_session_size());
}
static int
otx_cpt_session_cfg(struct rte_cryptodev *dev,
struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *sess,
- struct rte_mempool *pool)
+ void *sess)
{
CPT_PMD_INIT_FUNC_TRACE();
+ RTE_SET_USED(dev);
- return sym_session_configure(dev->driver_id, xform, sess, pool);
+ return sym_session_configure(xform, sess);
}
static void
-otx_cpt_session_clear(struct rte_cryptodev *dev,
- struct rte_cryptodev_sym_session *sess)
+otx_cpt_session_clear(struct rte_cryptodev *dev, void *sess)
{
CPT_PMD_INIT_FUNC_TRACE();
+ RTE_SET_USED(dev);
- return sym_session_clear(dev->driver_id, sess);
+ return sym_session_clear(sess);
}
static unsigned int
@@ -576,7 +556,6 @@ static __rte_always_inline void * __rte_hot
otx_cpt_enq_single_sym_sessless(struct cpt_instance *instance,
struct rte_crypto_op *op)
{
- const int driver_id = otx_cryptodev_driver_id;
struct rte_crypto_sym_op *sym_op = op->sym;
struct rte_cryptodev_sym_session *sess;
void *req;
@@ -589,8 +568,12 @@ otx_cpt_enq_single_sym_sessless(struct cpt_instance *instance,
return NULL;
}
- ret = sym_session_configure(driver_id, sym_op->xform, sess,
- instance->sess_mp_priv);
+ sess->sess_data[otx_cryptodev_driver_id].data =
+ (void *)((uint8_t *)sess +
+ rte_cryptodev_sym_get_header_session_size() +
+ (otx_cryptodev_driver_id * sess->priv_sz));
+ ret = sym_session_configure(sym_op->xform,
+ sess->sess_data[otx_cryptodev_driver_id].data);
if (ret)
goto sess_put;
@@ -604,7 +587,7 @@ otx_cpt_enq_single_sym_sessless(struct cpt_instance *instance,
return req;
priv_put:
- sym_session_clear(driver_id, sess);
+ sym_session_clear(sess);
sess_put:
rte_mempool_put(instance->sess_mp, sess);
return NULL;
@@ -913,7 +896,6 @@ free_sym_session_data(const struct cpt_instance *instance,
memset(cop->sym->session, 0,
rte_cryptodev_sym_get_existing_header_session_size(
cop->sym->session));
- rte_mempool_put(instance->sess_mp_priv, sess_private_data_t);
rte_mempool_put(instance->sess_mp, cop->sym->session);
cop->sym->session = NULL;
}
diff --git a/drivers/crypto/octeontx2/otx2_cryptodev_ops.c b/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
index 7b744cd4b4..dcfbc49996 100644
--- a/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
+++ b/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
@@ -371,29 +371,21 @@ sym_xform_verify(struct rte_crypto_sym_xform *xform)
}
static int
-sym_session_configure(int driver_id, struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *sess,
- struct rte_mempool *pool)
+sym_session_configure(struct rte_crypto_sym_xform *xform, void *sess)
{
struct rte_crypto_sym_xform *temp_xform = xform;
struct cpt_sess_misc *misc;
vq_cmd_word3_t vq_cmd_w3;
- void *priv;
int ret;
ret = sym_xform_verify(xform);
if (unlikely(ret))
return ret;
- if (unlikely(rte_mempool_get(pool, &priv))) {
- CPT_LOG_ERR("Could not allocate session private data");
- return -ENOMEM;
- }
-
- memset(priv, 0, sizeof(struct cpt_sess_misc) +
+ memset(sess, 0, sizeof(struct cpt_sess_misc) +
offsetof(struct cpt_ctx, mc_ctx));
- misc = priv;
+ misc = sess;
for ( ; xform != NULL; xform = xform->next) {
switch (xform->type) {
@@ -414,7 +406,7 @@ sym_session_configure(int driver_id, struct rte_crypto_sym_xform *xform,
}
if (ret)
- goto priv_put;
+ return -ENOTSUP;
}
if ((GET_SESS_FC_TYPE(misc) == HASH_HMAC) &&
@@ -425,12 +417,9 @@ sym_session_configure(int driver_id, struct rte_crypto_sym_xform *xform,
rte_free(ctx->auth_key);
ctx->auth_key = NULL;
}
- ret = -ENOTSUP;
- goto priv_put;
+ return -ENOTSUP;
}
- set_sym_session_private_data(sess, driver_id, misc);
-
misc->ctx_dma_addr = rte_mempool_virt2iova(misc) +
sizeof(struct cpt_sess_misc);
@@ -451,11 +440,6 @@ sym_session_configure(int driver_id, struct rte_crypto_sym_xform *xform,
misc->cpt_inst_w7 = vq_cmd_w3.u64;
return 0;
-
-priv_put:
- rte_mempool_put(pool, priv);
-
- return -ENOTSUP;
}
static __rte_always_inline int32_t __rte_hot
@@ -765,7 +749,6 @@ otx2_cpt_enqueue_sym_sessless(struct otx2_cpt_qp *qp, struct rte_crypto_op *op,
struct pending_queue *pend_q,
unsigned int burst_index)
{
- const int driver_id = otx2_cryptodev_driver_id;
struct rte_crypto_sym_op *sym_op = op->sym;
struct rte_cryptodev_sym_session *sess;
int ret;
@@ -775,8 +758,12 @@ otx2_cpt_enqueue_sym_sessless(struct otx2_cpt_qp *qp, struct rte_crypto_op *op,
if (sess == NULL)
return -ENOMEM;
- ret = sym_session_configure(driver_id, sym_op->xform, sess,
- qp->sess_mp_priv);
+ sess->sess_data[otx2_cryptodev_driver_id].data =
+ (void *)((uint8_t *)sess +
+ rte_cryptodev_sym_get_header_session_size() +
+ (otx2_cryptodev_driver_id * sess->priv_sz));
+ ret = sym_session_configure(sym_op->xform,
+ sess->sess_data[otx2_cryptodev_driver_id].data);
if (ret)
goto sess_put;
@@ -790,7 +777,7 @@ otx2_cpt_enqueue_sym_sessless(struct otx2_cpt_qp *qp, struct rte_crypto_op *op,
return 0;
priv_put:
- sym_session_clear(driver_id, sess);
+ sym_session_clear(sess);
sess_put:
rte_mempool_put(qp->sess_mp, sess);
return ret;
@@ -1035,8 +1022,7 @@ otx2_cpt_dequeue_post_process(struct otx2_cpt_qp *qp, struct rte_crypto_op *cop,
}
if (unlikely(cop->sess_type == RTE_CRYPTO_OP_SESSIONLESS)) {
- sym_session_clear(otx2_cryptodev_driver_id,
- cop->sym->session);
+ sym_session_clear(cop->sym->session);
sz = rte_cryptodev_sym_get_existing_header_session_size(
cop->sym->session);
memset(cop->sym->session, 0, sz);
@@ -1291,7 +1277,6 @@ otx2_cpt_queue_pair_setup(struct rte_cryptodev *dev, uint16_t qp_id,
}
qp->sess_mp = conf->mp_session;
- qp->sess_mp_priv = conf->mp_session_private;
dev->data->queue_pairs[qp_id] = qp;
return 0;
@@ -1330,21 +1315,22 @@ otx2_cpt_sym_session_get_size(struct rte_cryptodev *dev __rte_unused)
static int
otx2_cpt_sym_session_configure(struct rte_cryptodev *dev,
struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *sess,
- struct rte_mempool *pool)
+ void *sess)
{
CPT_PMD_INIT_FUNC_TRACE();
+ RTE_SET_USED(dev);
- return sym_session_configure(dev->driver_id, xform, sess, pool);
+ return sym_session_configure(xform, sess);
}
static void
otx2_cpt_sym_session_clear(struct rte_cryptodev *dev,
- struct rte_cryptodev_sym_session *sess)
+ void *sess)
{
CPT_PMD_INIT_FUNC_TRACE();
+ RTE_SET_USED(dev);
- return sym_session_clear(dev->driver_id, sess);
+ return sym_session_clear(sess);
}
static unsigned int
diff --git a/drivers/crypto/octeontx2/otx2_cryptodev_ops_helper.h b/drivers/crypto/octeontx2/otx2_cryptodev_ops_helper.h
index 01c081a216..5f63eaf7b7 100644
--- a/drivers/crypto/octeontx2/otx2_cryptodev_ops_helper.h
+++ b/drivers/crypto/octeontx2/otx2_cryptodev_ops_helper.h
@@ -8,29 +8,21 @@
#include "cpt_pmd_logs.h"
static void
-sym_session_clear(int driver_id, struct rte_cryptodev_sym_session *sess)
+sym_session_clear(void *sess)
{
- void *priv = get_sym_session_private_data(sess, driver_id);
struct cpt_sess_misc *misc;
- struct rte_mempool *pool;
struct cpt_ctx *ctx;
- if (priv == NULL)
+ if (sess == NULL)
return;
- misc = priv;
+ misc = sess;
ctx = SESS_PRIV(misc);
if (ctx->auth_key != NULL)
rte_free(ctx->auth_key);
- memset(priv, 0, cpt_get_session_size());
-
- pool = rte_mempool_from_obj(priv);
-
- set_sym_session_private_data(sess, driver_id, NULL);
-
- rte_mempool_put(pool, priv);
+ memset(sess, 0, cpt_get_session_size());
}
static __rte_always_inline uint8_t
diff --git a/drivers/crypto/openssl/rte_openssl_pmd_ops.c b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
index 52715f86f8..1b48a6b400 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd_ops.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
@@ -741,7 +741,6 @@ openssl_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
goto qp_setup_cleanup;
qp->sess_mp = qp_conf->mp_session;
- qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->stats, 0, sizeof(qp->stats));
@@ -772,10 +771,8 @@ openssl_pmd_asym_session_get_size(struct rte_cryptodev *dev __rte_unused)
static int
openssl_pmd_sym_session_configure(struct rte_cryptodev *dev __rte_unused,
struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *sess,
- struct rte_mempool *mempool)
+ void *sess)
{
- void *sess_private_data;
int ret;
if (unlikely(sess == NULL)) {
@@ -783,24 +780,12 @@ openssl_pmd_sym_session_configure(struct rte_cryptodev *dev __rte_unused,
return -EINVAL;
}
- if (rte_mempool_get(mempool, &sess_private_data)) {
- OPENSSL_LOG(ERR,
- "Couldn't get object from session mempool");
- return -ENOMEM;
- }
-
- ret = openssl_set_session_parameters(sess_private_data, xform);
+ ret = openssl_set_session_parameters(sess, xform);
if (ret != 0) {
OPENSSL_LOG(ERR, "failed configure session parameters");
-
- /* Return session to mempool */
- rte_mempool_put(mempool, sess_private_data);
return ret;
}
- set_sym_session_private_data(sess, dev->driver_id,
- sess_private_data);
-
return 0;
}
@@ -1154,19 +1139,13 @@ openssl_pmd_asym_session_configure(struct rte_cryptodev *dev __rte_unused,
/** Clear the memory of session so it doesn't leave key material behind */
static void
-openssl_pmd_sym_session_clear(struct rte_cryptodev *dev,
- struct rte_cryptodev_sym_session *sess)
+openssl_pmd_sym_session_clear(struct rte_cryptodev *dev, void *sess)
{
- uint8_t index = dev->driver_id;
- void *sess_priv = get_sym_session_private_data(sess, index);
-
+ RTE_SET_USED(dev);
/* Zero out the whole structure */
- if (sess_priv) {
- openssl_reset_session(sess_priv);
- memset(sess_priv, 0, sizeof(struct openssl_session));
- struct rte_mempool *sess_mp = rte_mempool_from_obj(sess_priv);
- set_sym_session_private_data(sess, index, NULL);
- rte_mempool_put(sess_mp, sess_priv);
+ if (sess) {
+ openssl_reset_session(sess);
+ memset(sess, 0, sizeof(struct openssl_session));
}
}
diff --git a/drivers/crypto/qat/qat_sym_session.c b/drivers/crypto/qat/qat_sym_session.c
index 2c0e44dff4..3bca88385a 100644
--- a/drivers/crypto/qat/qat_sym_session.c
+++ b/drivers/crypto/qat/qat_sym_session.c
@@ -172,21 +172,14 @@ qat_is_auth_alg_supported(enum rte_crypto_auth_algorithm algo,
}
void
-qat_sym_session_clear(struct rte_cryptodev *dev,
- struct rte_cryptodev_sym_session *sess)
+qat_sym_session_clear(struct rte_cryptodev *dev, void *sess)
{
- uint8_t index = dev->driver_id;
- void *sess_priv = get_sym_session_private_data(sess, index);
- struct qat_sym_session *s = (struct qat_sym_session *)sess_priv;
+ struct qat_sym_session *s = (struct qat_sym_session *)sess;
- if (sess_priv) {
+ if (sess) {
if (s->bpi_ctx)
bpi_cipher_ctx_free(s->bpi_ctx);
memset(s, 0, qat_sym_session_get_private_size(dev));
- struct rte_mempool *sess_mp = rte_mempool_from_obj(sess_priv);
-
- set_sym_session_private_data(sess, index, NULL);
- rte_mempool_put(sess_mp, sess_priv);
}
}
@@ -458,31 +451,17 @@ qat_sym_session_configure_cipher(struct rte_cryptodev *dev,
int
qat_sym_session_configure(struct rte_cryptodev *dev,
struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *sess,
- struct rte_mempool *mempool)
+ void *sess_private_data)
{
- void *sess_private_data;
int ret;
- if (rte_mempool_get(mempool, &sess_private_data)) {
- CDEV_LOG_ERR(
- "Couldn't get object from session mempool");
- return -ENOMEM;
- }
-
ret = qat_sym_session_set_parameters(dev, xform, sess_private_data);
if (ret != 0) {
QAT_LOG(ERR,
"Crypto QAT PMD: failed to configure session parameters");
-
- /* Return session to mempool */
- rte_mempool_put(mempool, sess_private_data);
return ret;
}
- set_sym_session_private_data(sess, dev->driver_id,
- sess_private_data);
-
return 0;
}
diff --git a/drivers/crypto/qat/qat_sym_session.h b/drivers/crypto/qat/qat_sym_session.h
index b93dc549ef..c7dceb2add 100644
--- a/drivers/crypto/qat/qat_sym_session.h
+++ b/drivers/crypto/qat/qat_sym_session.h
@@ -112,8 +112,7 @@ struct qat_sym_session {
int
qat_sym_session_configure(struct rte_cryptodev *dev,
struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *sess,
- struct rte_mempool *mempool);
+ void *sess);
int
qat_sym_session_set_parameters(struct rte_cryptodev *dev,
@@ -135,8 +134,7 @@ qat_sym_session_configure_auth(struct rte_cryptodev *dev,
struct qat_sym_session *session);
void
-qat_sym_session_clear(struct rte_cryptodev *dev,
- struct rte_cryptodev_sym_session *session);
+qat_sym_session_clear(struct rte_cryptodev *dev, void *session);
unsigned int
qat_sym_session_get_private_size(struct rte_cryptodev *dev);
diff --git a/drivers/crypto/scheduler/scheduler_pmd_ops.c b/drivers/crypto/scheduler/scheduler_pmd_ops.c
index 465b88ade8..87260b5a22 100644
--- a/drivers/crypto/scheduler/scheduler_pmd_ops.c
+++ b/drivers/crypto/scheduler/scheduler_pmd_ops.c
@@ -476,9 +476,7 @@ scheduler_pmd_sym_session_get_size(struct rte_cryptodev *dev __rte_unused)
static int
scheduler_pmd_sym_session_configure(struct rte_cryptodev *dev,
- struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *sess,
- struct rte_mempool *mempool)
+ struct rte_crypto_sym_xform *xform, void *sess)
{
struct scheduler_ctx *sched_ctx = dev->data->dev_private;
uint32_t i;
@@ -488,7 +486,7 @@ scheduler_pmd_sym_session_configure(struct rte_cryptodev *dev,
struct scheduler_worker *worker = &sched_ctx->workers[i];
ret = rte_cryptodev_sym_session_init(worker->dev_id, sess,
- xform, mempool);
+ xform);
if (ret < 0) {
CR_SCHED_LOG(ERR, "unable to config sym session");
return ret;
@@ -500,8 +498,7 @@ scheduler_pmd_sym_session_configure(struct rte_cryptodev *dev,
/** Clear the memory of session so it doesn't leave key material behind */
static void
-scheduler_pmd_sym_session_clear(struct rte_cryptodev *dev,
- struct rte_cryptodev_sym_session *sess)
+scheduler_pmd_sym_session_clear(struct rte_cryptodev *dev, void *sess)
{
struct scheduler_ctx *sched_ctx = dev->data->dev_private;
uint32_t i;
diff --git a/drivers/crypto/snow3g/rte_snow3g_pmd_ops.c b/drivers/crypto/snow3g/rte_snow3g_pmd_ops.c
index 3f46014b7d..b0f8f6d86a 100644
--- a/drivers/crypto/snow3g/rte_snow3g_pmd_ops.c
+++ b/drivers/crypto/snow3g/rte_snow3g_pmd_ops.c
@@ -226,7 +226,6 @@ snow3g_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
qp->mgr = internals->mgr;
qp->sess_mp = qp_conf->mp_session;
- qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->qp_stats, 0, sizeof(qp->qp_stats));
@@ -250,10 +249,8 @@ snow3g_pmd_sym_session_get_size(struct rte_cryptodev *dev __rte_unused)
static int
snow3g_pmd_sym_session_configure(struct rte_cryptodev *dev,
struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *sess,
- struct rte_mempool *mempool)
+ void *sess)
{
- void *sess_private_data;
int ret;
struct snow3g_private *internals = dev->data->dev_private;
@@ -262,43 +259,24 @@ snow3g_pmd_sym_session_configure(struct rte_cryptodev *dev,
return -EINVAL;
}
- if (rte_mempool_get(mempool, &sess_private_data)) {
- SNOW3G_LOG(ERR,
- "Couldn't get object from session mempool");
- return -ENOMEM;
- }
-
ret = snow3g_set_session_parameters(internals->mgr,
- sess_private_data, xform);
+ sess, xform);
if (ret != 0) {
SNOW3G_LOG(ERR, "failed configure session parameters");
-
- /* Return session to mempool */
- rte_mempool_put(mempool, sess_private_data);
return ret;
}
- set_sym_session_private_data(sess, dev->driver_id,
- sess_private_data);
-
return 0;
}
/** Clear the memory of session so it doesn't leave key material behind */
static void
-snow3g_pmd_sym_session_clear(struct rte_cryptodev *dev,
- struct rte_cryptodev_sym_session *sess)
+snow3g_pmd_sym_session_clear(struct rte_cryptodev *dev, void *sess)
{
- uint8_t index = dev->driver_id;
- void *sess_priv = get_sym_session_private_data(sess, index);
-
+ RTE_SET_USED(dev);
/* Zero out the whole structure */
- if (sess_priv) {
- memset(sess_priv, 0, sizeof(struct snow3g_session));
- struct rte_mempool *sess_mp = rte_mempool_from_obj(sess_priv);
- set_sym_session_private_data(sess, index, NULL);
- rte_mempool_put(sess_mp, sess_priv);
- }
+ if (sess)
+ memset(sess, 0, sizeof(struct snow3g_session));
}
struct rte_cryptodev_ops snow3g_pmd_ops = {
diff --git a/drivers/crypto/virtio/virtio_cryptodev.c b/drivers/crypto/virtio/virtio_cryptodev.c
index 8faa39df4a..de52fec32e 100644
--- a/drivers/crypto/virtio/virtio_cryptodev.c
+++ b/drivers/crypto/virtio/virtio_cryptodev.c
@@ -37,11 +37,10 @@ static void virtio_crypto_dev_free_mbufs(struct rte_cryptodev *dev);
static unsigned int virtio_crypto_sym_get_session_private_size(
struct rte_cryptodev *dev);
static void virtio_crypto_sym_clear_session(struct rte_cryptodev *dev,
- struct rte_cryptodev_sym_session *sess);
+ void *sess);
static int virtio_crypto_sym_configure_session(struct rte_cryptodev *dev,
struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *session,
- struct rte_mempool *mp);
+ void *session);
/*
* The set of PCI devices this driver supports
@@ -927,7 +926,7 @@ virtio_crypto_check_sym_clear_session_paras(
static void
virtio_crypto_sym_clear_session(
struct rte_cryptodev *dev,
- struct rte_cryptodev_sym_session *sess)
+ void *sess)
{
struct virtio_crypto_hw *hw;
struct virtqueue *vq;
@@ -1290,11 +1289,9 @@ static int
virtio_crypto_check_sym_configure_session_paras(
struct rte_cryptodev *dev,
struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *sym_sess,
- struct rte_mempool *mempool)
+ void *sym_sess)
{
- if (unlikely(xform == NULL) || unlikely(sym_sess == NULL) ||
- unlikely(mempool == NULL)) {
+ if (unlikely(xform == NULL) || unlikely(sym_sess == NULL)) {
VIRTIO_CRYPTO_SESSION_LOG_ERR("NULL pointer");
return -1;
}
@@ -1309,12 +1306,9 @@ static int
virtio_crypto_sym_configure_session(
struct rte_cryptodev *dev,
struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *sess,
- struct rte_mempool *mempool)
+ void *sess)
{
int ret;
- struct virtio_crypto_session crypto_sess;
- void *session_private = &crypto_sess;
struct virtio_crypto_session *session;
struct virtio_crypto_op_ctrl_req *ctrl_req;
enum virtio_crypto_cmd_id cmd_id;
@@ -1326,19 +1320,13 @@ virtio_crypto_sym_configure_session(
PMD_INIT_FUNC_TRACE();
ret = virtio_crypto_check_sym_configure_session_paras(dev, xform,
- sess, mempool);
+ sess);
if (ret < 0) {
VIRTIO_CRYPTO_SESSION_LOG_ERR("Invalid parameters");
return ret;
}
- if (rte_mempool_get(mempool, &session_private)) {
- VIRTIO_CRYPTO_SESSION_LOG_ERR(
- "Couldn't get object from session mempool");
- return -ENOMEM;
- }
-
- session = (struct virtio_crypto_session *)session_private;
+ session = (struct virtio_crypto_session *)sess;
memset(session, 0, sizeof(struct virtio_crypto_session));
ctrl_req = &session->ctrl;
ctrl_req->header.opcode = VIRTIO_CRYPTO_CIPHER_CREATE_SESSION;
@@ -1401,9 +1389,6 @@ virtio_crypto_sym_configure_session(
goto error_out;
}
- set_sym_session_private_data(sess, dev->driver_id,
- session_private);
-
return 0;
error_out:
diff --git a/drivers/crypto/zuc/rte_zuc_pmd_ops.c b/drivers/crypto/zuc/rte_zuc_pmd_ops.c
index 38642d45ab..04126c8a04 100644
--- a/drivers/crypto/zuc/rte_zuc_pmd_ops.c
+++ b/drivers/crypto/zuc/rte_zuc_pmd_ops.c
@@ -226,7 +226,6 @@ zuc_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
qp->mb_mgr = internals->mb_mgr;
qp->sess_mp = qp_conf->mp_session;
- qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->qp_stats, 0, sizeof(qp->qp_stats));
@@ -250,10 +249,8 @@ zuc_pmd_sym_session_get_size(struct rte_cryptodev *dev __rte_unused)
static int
zuc_pmd_sym_session_configure(struct rte_cryptodev *dev __rte_unused,
struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *sess,
- struct rte_mempool *mempool)
+ void *sess)
{
- void *sess_private_data;
int ret;
if (unlikely(sess == NULL)) {
@@ -261,43 +258,23 @@ zuc_pmd_sym_session_configure(struct rte_cryptodev *dev __rte_unused,
return -EINVAL;
}
- if (rte_mempool_get(mempool, &sess_private_data)) {
- ZUC_LOG(ERR,
- "Couldn't get object from session mempool");
-
- return -ENOMEM;
- }
-
- ret = zuc_set_session_parameters(sess_private_data, xform);
+ ret = zuc_set_session_parameters(sess, xform);
if (ret != 0) {
ZUC_LOG(ERR, "failed configure session parameters");
-
- /* Return session to mempool */
- rte_mempool_put(mempool, sess_private_data);
return ret;
}
- set_sym_session_private_data(sess, dev->driver_id,
- sess_private_data);
-
return 0;
}
/** Clear the memory of session so it doesn't leave key material behind */
static void
-zuc_pmd_sym_session_clear(struct rte_cryptodev *dev,
- struct rte_cryptodev_sym_session *sess)
+zuc_pmd_sym_session_clear(struct rte_cryptodev *dev, void *sess)
{
- uint8_t index = dev->driver_id;
- void *sess_priv = get_sym_session_private_data(sess, index);
-
+ RTE_SET_USED(dev);
/* Zero out the whole structure */
- if (sess_priv) {
- memset(sess_priv, 0, sizeof(struct zuc_session));
- struct rte_mempool *sess_mp = rte_mempool_from_obj(sess_priv);
- set_sym_session_private_data(sess, index, NULL);
- rte_mempool_put(sess_mp, sess_priv);
- }
+ if (sess)
+ memset(sess, 0, sizeof(struct zuc_session));
}
struct rte_cryptodev_ops zuc_pmd_ops = {
diff --git a/drivers/event/octeontx2/otx2_evdev_crypto_adptr_rx.h b/drivers/event/octeontx2/otx2_evdev_crypto_adptr_rx.h
index b33cb7e139..8522f2dfda 100644
--- a/drivers/event/octeontx2/otx2_evdev_crypto_adptr_rx.h
+++ b/drivers/event/octeontx2/otx2_evdev_crypto_adptr_rx.h
@@ -38,8 +38,7 @@ otx2_ca_deq_post_process(const struct otx2_cpt_qp *qp,
}
if (unlikely(cop->sess_type == RTE_CRYPTO_OP_SESSIONLESS)) {
- sym_session_clear(otx2_cryptodev_driver_id,
- cop->sym->session);
+ sym_session_clear(cop->sym->session);
memset(cop->sym->session, 0,
rte_cryptodev_sym_get_existing_header_session_size(
cop->sym->session));
diff --git a/examples/fips_validation/fips_dev_self_test.c b/examples/fips_validation/fips_dev_self_test.c
index b4eab05a98..bbc27a1b6f 100644
--- a/examples/fips_validation/fips_dev_self_test.c
+++ b/examples/fips_validation/fips_dev_self_test.c
@@ -969,7 +969,6 @@ struct fips_dev_auto_test_env {
struct rte_mempool *mpool;
struct rte_mempool *op_pool;
struct rte_mempool *sess_pool;
- struct rte_mempool *sess_priv_pool;
struct rte_mbuf *mbuf;
struct rte_crypto_op *op;
};
@@ -981,7 +980,7 @@ typedef int (*fips_dev_self_test_prepare_xform_t)(uint8_t,
uint32_t);
typedef int (*fips_dev_self_test_prepare_op_t)(struct rte_crypto_op *,
- struct rte_mbuf *, struct rte_cryptodev_sym_session *,
+ struct rte_mbuf *, void *,
uint32_t, struct fips_dev_self_test_vector *);
typedef int (*fips_dev_self_test_check_result_t)(struct rte_crypto_op *,
@@ -1173,7 +1172,7 @@ prepare_aead_xform(uint8_t dev_id,
static int
prepare_cipher_op(struct rte_crypto_op *op,
struct rte_mbuf *mbuf,
- struct rte_cryptodev_sym_session *session,
+ void *session,
uint32_t dir,
struct fips_dev_self_test_vector *vec)
{
@@ -1212,7 +1211,7 @@ prepare_cipher_op(struct rte_crypto_op *op,
static int
prepare_auth_op(struct rte_crypto_op *op,
struct rte_mbuf *mbuf,
- struct rte_cryptodev_sym_session *session,
+ void *session,
uint32_t dir,
struct fips_dev_self_test_vector *vec)
{
@@ -1251,7 +1250,7 @@ prepare_auth_op(struct rte_crypto_op *op,
static int
prepare_aead_op(struct rte_crypto_op *op,
struct rte_mbuf *mbuf,
- struct rte_cryptodev_sym_session *session,
+ void *session,
uint32_t dir,
struct fips_dev_self_test_vector *vec)
{
@@ -1464,7 +1463,7 @@ run_single_test(uint8_t dev_id,
uint32_t negative_test)
{
struct rte_crypto_sym_xform xform;
- struct rte_cryptodev_sym_session *sess;
+ void *sess;
uint16_t n_deqd;
uint8_t key[256];
int ret;
@@ -1484,8 +1483,7 @@ run_single_test(uint8_t dev_id,
if (!sess)
return -ENOMEM;
- ret = rte_cryptodev_sym_session_init(dev_id,
- sess, &xform, env->sess_priv_pool);
+ ret = rte_cryptodev_sym_session_init(dev_id, sess, &xform);
if (ret < 0) {
RTE_LOG(ERR, PMD, "Error %i: Init session\n", ret);
return ret;
@@ -1533,8 +1531,6 @@ fips_dev_auto_test_uninit(uint8_t dev_id,
rte_mempool_free(env->op_pool);
if (env->sess_pool)
rte_mempool_free(env->sess_pool);
- if (env->sess_priv_pool)
- rte_mempool_free(env->sess_priv_pool);
rte_cryptodev_stop(dev_id);
}
@@ -1542,7 +1538,7 @@ fips_dev_auto_test_uninit(uint8_t dev_id,
static int
fips_dev_auto_test_init(uint8_t dev_id, struct fips_dev_auto_test_env *env)
{
- struct rte_cryptodev_qp_conf qp_conf = {128, NULL, NULL};
+ struct rte_cryptodev_qp_conf qp_conf = {128, NULL};
uint32_t sess_sz = rte_cryptodev_sym_get_private_session_size(dev_id);
struct rte_cryptodev_config conf;
char name[128];
@@ -1586,25 +1582,13 @@ fips_dev_auto_test_init(uint8_t dev_id, struct fips_dev_auto_test_env *env)
snprintf(name, 128, "%s%u", "SELF_TEST_SESS_POOL", dev_id);
env->sess_pool = rte_cryptodev_sym_session_pool_create(name,
- 128, 0, 0, 0, rte_cryptodev_socket_id(dev_id));
+ 128, sess_sz, 0, 0, rte_cryptodev_socket_id(dev_id));
if (!env->sess_pool) {
ret = -ENOMEM;
goto error_exit;
}
- memset(name, 0, 128);
- snprintf(name, 128, "%s%u", "SELF_TEST_SESS_PRIV_POOL", dev_id);
-
- env->sess_priv_pool = rte_mempool_create(name,
- 128, sess_sz, 0, 0, NULL, NULL, NULL,
- NULL, rte_cryptodev_socket_id(dev_id), 0);
- if (!env->sess_priv_pool) {
- ret = -ENOMEM;
- goto error_exit;
- }
-
qp_conf.mp_session = env->sess_pool;
- qp_conf.mp_session_private = env->sess_priv_pool;
ret = rte_cryptodev_queue_pair_setup(dev_id, 0, &qp_conf,
rte_cryptodev_socket_id(dev_id));
diff --git a/examples/fips_validation/main.c b/examples/fips_validation/main.c
index b0de3d269a..837afddcda 100644
--- a/examples/fips_validation/main.c
+++ b/examples/fips_validation/main.c
@@ -48,13 +48,12 @@ struct cryptodev_fips_validate_env {
uint16_t mbuf_data_room;
struct rte_mempool *mpool;
struct rte_mempool *sess_mpool;
- struct rte_mempool *sess_priv_mpool;
struct rte_mempool *op_pool;
struct rte_mbuf *mbuf;
uint8_t *digest;
uint16_t digest_len;
struct rte_crypto_op *op;
- struct rte_cryptodev_sym_session *sess;
+ void *sess;
uint16_t self_test;
struct fips_dev_broken_test_config *broken_test_config;
} env;
@@ -63,7 +62,7 @@ static int
cryptodev_fips_validate_app_int(void)
{
struct rte_cryptodev_config conf = {rte_socket_id(), 1, 0};
- struct rte_cryptodev_qp_conf qp_conf = {128, NULL, NULL};
+ struct rte_cryptodev_qp_conf qp_conf = {128, NULL};
struct rte_cryptodev_info dev_info;
uint32_t sess_sz = rte_cryptodev_sym_get_private_session_size(
env.dev_id);
@@ -103,16 +102,11 @@ cryptodev_fips_validate_app_int(void)
ret = -ENOMEM;
env.sess_mpool = rte_cryptodev_sym_session_pool_create(
- "FIPS_SESS_MEMPOOL", 16, 0, 0, 0, rte_socket_id());
+ "FIPS_SESS_MEMPOOL", 16, sess_sz, 0, 0,
+ rte_socket_id());
if (!env.sess_mpool)
goto error_exit;
- env.sess_priv_mpool = rte_mempool_create("FIPS_SESS_PRIV_MEMPOOL",
- 16, sess_sz, 0, 0, NULL, NULL, NULL,
- NULL, rte_socket_id(), 0);
- if (!env.sess_priv_mpool)
- goto error_exit;
-
env.op_pool = rte_crypto_op_pool_create(
"FIPS_OP_POOL",
RTE_CRYPTO_OP_TYPE_SYMMETRIC,
@@ -127,7 +121,6 @@ cryptodev_fips_validate_app_int(void)
goto error_exit;
qp_conf.mp_session = env.sess_mpool;
- qp_conf.mp_session_private = env.sess_priv_mpool;
ret = rte_cryptodev_queue_pair_setup(env.dev_id, 0, &qp_conf,
rte_socket_id());
@@ -141,8 +134,6 @@ cryptodev_fips_validate_app_int(void)
rte_mempool_free(env.mpool);
if (env.sess_mpool)
rte_mempool_free(env.sess_mpool);
- if (env.sess_priv_mpool)
- rte_mempool_free(env.sess_priv_mpool);
if (env.op_pool)
rte_mempool_free(env.op_pool);
@@ -158,7 +149,6 @@ cryptodev_fips_validate_app_uninit(void)
rte_cryptodev_sym_session_free(env.sess);
rte_mempool_free(env.mpool);
rte_mempool_free(env.sess_mpool);
- rte_mempool_free(env.sess_priv_mpool);
rte_mempool_free(env.op_pool);
}
@@ -1179,7 +1169,7 @@ fips_run_test(void)
return -ENOMEM;
ret = rte_cryptodev_sym_session_init(env.dev_id,
- env.sess, &xform, env.sess_priv_mpool);
+ env.sess, &xform);
if (ret < 0) {
RTE_LOG(ERR, USER1, "Error %i: Init session\n",
ret);
diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-secgw/ipsec-secgw.c
index 7b01872c6f..b148bb8ecf 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -1216,15 +1216,11 @@ ipsec_poll_mode_worker(void)
qconf->inbound.sa_ctx = socket_ctx[socket_id].sa_in;
qconf->inbound.cdev_map = cdev_map_in;
qconf->inbound.session_pool = socket_ctx[socket_id].session_pool;
- qconf->inbound.session_priv_pool =
- socket_ctx[socket_id].session_priv_pool;
qconf->outbound.sp4_ctx = socket_ctx[socket_id].sp_ip4_out;
qconf->outbound.sp6_ctx = socket_ctx[socket_id].sp_ip6_out;
qconf->outbound.sa_ctx = socket_ctx[socket_id].sa_out;
qconf->outbound.cdev_map = cdev_map_out;
qconf->outbound.session_pool = socket_ctx[socket_id].session_pool;
- qconf->outbound.session_priv_pool =
- socket_ctx[socket_id].session_priv_pool;
qconf->frag.pool_dir = socket_ctx[socket_id].mbuf_pool;
qconf->frag.pool_indir = socket_ctx[socket_id].mbuf_pool_indir;
@@ -2142,8 +2138,6 @@ cryptodevs_init(uint16_t req_queue_num)
qp_conf.nb_descriptors = CDEV_QUEUE_DESC;
qp_conf.mp_session =
socket_ctx[dev_conf.socket_id].session_pool;
- qp_conf.mp_session_private =
- socket_ctx[dev_conf.socket_id].session_priv_pool;
for (qp = 0; qp < dev_conf.nb_queue_pairs; qp++)
if (rte_cryptodev_queue_pair_setup(cdev_id, qp,
&qp_conf, dev_conf.socket_id))
@@ -2405,38 +2399,6 @@ session_pool_init(struct socket_ctx *ctx, int32_t socket_id, size_t sess_sz)
printf("Allocated session pool on socket %d\n", socket_id);
}
-static void
-session_priv_pool_init(struct socket_ctx *ctx, int32_t socket_id,
- size_t sess_sz)
-{
- char mp_name[RTE_MEMPOOL_NAMESIZE];
- struct rte_mempool *sess_mp;
- uint32_t nb_sess;
-
- snprintf(mp_name, RTE_MEMPOOL_NAMESIZE,
- "sess_mp_priv_%u", socket_id);
- nb_sess = (get_nb_crypto_sessions() + CDEV_MP_CACHE_SZ *
- rte_lcore_count());
- nb_sess = RTE_MAX(nb_sess, CDEV_MP_CACHE_SZ *
- CDEV_MP_CACHE_MULTIPLIER);
- sess_mp = rte_mempool_create(mp_name,
- nb_sess,
- sess_sz,
- CDEV_MP_CACHE_SZ,
- 0, NULL, NULL, NULL,
- NULL, socket_id,
- 0);
- ctx->session_priv_pool = sess_mp;
-
- if (ctx->session_priv_pool == NULL)
- rte_exit(EXIT_FAILURE,
- "Cannot init session priv pool on socket %d\n",
- socket_id);
- else
- printf("Allocated session priv pool on socket %d\n",
- socket_id);
-}
-
static void
pool_init(struct socket_ctx *ctx, int32_t socket_id, uint32_t nb_mbuf)
{
@@ -2938,8 +2900,6 @@ main(int32_t argc, char **argv)
pool_init(&socket_ctx[socket_id], socket_id, nb_bufs_in_pool);
session_pool_init(&socket_ctx[socket_id], socket_id, sess_sz);
- session_priv_pool_init(&socket_ctx[socket_id], socket_id,
- sess_sz);
}
printf("Number of mbufs in packet pool %d\n", nb_bufs_in_pool);
diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
index 03d907cba8..a5921de11c 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -143,8 +143,7 @@ create_lookaside_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa,
ips->crypto.ses = rte_cryptodev_sym_session_create(
ipsec_ctx->session_pool);
rte_cryptodev_sym_session_init(ipsec_ctx->tbl[cdev_id_qp].id,
- ips->crypto.ses, sa->xforms,
- ipsec_ctx->session_priv_pool);
+ ips->crypto.ses, sa->xforms);
rte_cryptodev_info_get(ipsec_ctx->tbl[cdev_id_qp].id,
&cdev_info);
diff --git a/examples/ipsec-secgw/ipsec.h b/examples/ipsec-secgw/ipsec.h
index 8405c48171..673c64e8dc 100644
--- a/examples/ipsec-secgw/ipsec.h
+++ b/examples/ipsec-secgw/ipsec.h
@@ -243,7 +243,6 @@ struct socket_ctx {
struct rte_mempool *mbuf_pool;
struct rte_mempool *mbuf_pool_indir;
struct rte_mempool *session_pool;
- struct rte_mempool *session_priv_pool;
};
struct cnt_blk {
diff --git a/examples/ipsec-secgw/ipsec_worker.c b/examples/ipsec-secgw/ipsec_worker.c
index 6f49239c4a..c65855a460 100644
--- a/examples/ipsec-secgw/ipsec_worker.c
+++ b/examples/ipsec-secgw/ipsec_worker.c
@@ -540,14 +540,10 @@ ipsec_wrkr_non_burst_int_port_app_mode(struct eh_event_link_info *links,
lconf.inbound.sp6_ctx = socket_ctx[socket_id].sp_ip6_in;
lconf.inbound.sa_ctx = socket_ctx[socket_id].sa_in;
lconf.inbound.session_pool = socket_ctx[socket_id].session_pool;
- lconf.inbound.session_priv_pool =
- socket_ctx[socket_id].session_priv_pool;
lconf.outbound.sp4_ctx = socket_ctx[socket_id].sp_ip4_out;
lconf.outbound.sp6_ctx = socket_ctx[socket_id].sp_ip6_out;
lconf.outbound.sa_ctx = socket_ctx[socket_id].sa_out;
lconf.outbound.session_pool = socket_ctx[socket_id].session_pool;
- lconf.outbound.session_priv_pool =
- socket_ctx[socket_id].session_priv_pool;
RTE_LOG(INFO, IPSEC,
"Launching event mode worker (non-burst - Tx internal port - "
diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index c2ffbdd506..11070466fb 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -188,7 +188,7 @@ struct l2fwd_crypto_params {
struct l2fwd_iv auth_iv;
struct l2fwd_iv aead_iv;
struct l2fwd_key aad;
- struct rte_cryptodev_sym_session *session;
+ void *session;
uint8_t do_cipher;
uint8_t do_hash;
@@ -229,7 +229,6 @@ struct rte_mempool *l2fwd_pktmbuf_pool;
struct rte_mempool *l2fwd_crypto_op_pool;
static struct {
struct rte_mempool *sess_mp;
- struct rte_mempool *priv_mp;
} session_pool_socket[RTE_MAX_NUMA_NODES];
/* Per-port statistics struct */
@@ -671,11 +670,11 @@ generate_random_key(uint8_t *key, unsigned length)
}
/* Session is created and is later attached to the crypto operation. 8< */
-static struct rte_cryptodev_sym_session *
+static void *
initialize_crypto_session(struct l2fwd_crypto_options *options, uint8_t cdev_id)
{
struct rte_crypto_sym_xform *first_xform;
- struct rte_cryptodev_sym_session *session;
+ void *session;
int retval = rte_cryptodev_socket_id(cdev_id);
if (retval < 0)
@@ -703,8 +702,7 @@ initialize_crypto_session(struct l2fwd_crypto_options *options, uint8_t cdev_id)
return NULL;
if (rte_cryptodev_sym_session_init(cdev_id, session,
- first_xform,
- session_pool_socket[socket_id].priv_mp) < 0)
+ first_xform) < 0)
return NULL;
return session;
@@ -730,7 +728,7 @@ l2fwd_main_loop(struct l2fwd_crypto_options *options)
US_PER_S * BURST_TX_DRAIN_US;
struct l2fwd_crypto_params *cparams;
struct l2fwd_crypto_params port_cparams[qconf->nb_crypto_devs];
- struct rte_cryptodev_sym_session *session;
+ void *session;
if (qconf->nb_rx_ports == 0) {
RTE_LOG(INFO, L2FWD, "lcore %u has nothing to do\n", lcore_id);
@@ -2388,30 +2386,6 @@ initialize_cryptodevs(struct l2fwd_crypto_options *options, unsigned nb_ports,
} else
sessions_needed = enabled_cdev_count;
- if (session_pool_socket[socket_id].priv_mp == NULL) {
- char mp_name[RTE_MEMPOOL_NAMESIZE];
-
- snprintf(mp_name, RTE_MEMPOOL_NAMESIZE,
- "priv_sess_mp_%u", socket_id);
-
- session_pool_socket[socket_id].priv_mp =
- rte_mempool_create(mp_name,
- sessions_needed,
- max_sess_sz,
- 0, 0, NULL, NULL, NULL,
- NULL, socket_id,
- 0);
-
- if (session_pool_socket[socket_id].priv_mp == NULL) {
- printf("Cannot create pool on socket %d\n",
- socket_id);
- return -ENOMEM;
- }
-
- printf("Allocated pool \"%s\" on socket %d\n",
- mp_name, socket_id);
- }
-
if (session_pool_socket[socket_id].sess_mp == NULL) {
char mp_name[RTE_MEMPOOL_NAMESIZE];
snprintf(mp_name, RTE_MEMPOOL_NAMESIZE,
@@ -2421,7 +2395,8 @@ initialize_cryptodevs(struct l2fwd_crypto_options *options, unsigned nb_ports,
rte_cryptodev_sym_session_pool_create(
mp_name,
sessions_needed,
- 0, 0, 0, socket_id);
+ max_sess_sz,
+ 0, 0, socket_id);
if (session_pool_socket[socket_id].sess_mp == NULL) {
printf("Cannot create pool on socket %d\n",
@@ -2573,8 +2548,6 @@ initialize_cryptodevs(struct l2fwd_crypto_options *options, unsigned nb_ports,
qp_conf.nb_descriptors = 2048;
qp_conf.mp_session = session_pool_socket[socket_id].sess_mp;
- qp_conf.mp_session_private =
- session_pool_socket[socket_id].priv_mp;
retval = rte_cryptodev_queue_pair_setup(cdev_id, 0, &qp_conf,
socket_id);
diff --git a/examples/vhost_crypto/main.c b/examples/vhost_crypto/main.c
index dea7dcbd07..cbb97aaf76 100644
--- a/examples/vhost_crypto/main.c
+++ b/examples/vhost_crypto/main.c
@@ -46,7 +46,6 @@ struct vhost_crypto_info {
int vids[MAX_NB_SOCKETS];
uint32_t nb_vids;
struct rte_mempool *sess_pool;
- struct rte_mempool *sess_priv_pool;
struct rte_mempool *cop_pool;
uint8_t cid;
uint32_t qid;
@@ -304,7 +303,6 @@ new_device(int vid)
}
ret = rte_vhost_crypto_create(vid, info->cid, info->sess_pool,
- info->sess_priv_pool,
rte_lcore_to_socket_id(options.los[i].lcore_id));
if (ret) {
RTE_LOG(ERR, USER1, "Cannot create vhost crypto\n");
@@ -458,7 +456,6 @@ free_resource(void)
rte_mempool_free(info->cop_pool);
rte_mempool_free(info->sess_pool);
- rte_mempool_free(info->sess_priv_pool);
for (j = 0; j < lo->nb_sockets; j++) {
rte_vhost_driver_unregister(lo->socket_files[i]);
@@ -544,16 +541,12 @@ main(int argc, char *argv[])
snprintf(name, 127, "SESS_POOL_%u", lo->lcore_id);
info->sess_pool = rte_cryptodev_sym_session_pool_create(name,
- SESSION_MAP_ENTRIES, 0, 0, 0,
- rte_lcore_to_socket_id(lo->lcore_id));
-
- snprintf(name, 127, "SESS_POOL_PRIV_%u", lo->lcore_id);
- info->sess_priv_pool = rte_mempool_create(name,
SESSION_MAP_ENTRIES,
rte_cryptodev_sym_get_private_session_size(
- info->cid), 64, 0, NULL, NULL, NULL, NULL,
- rte_lcore_to_socket_id(lo->lcore_id), 0);
- if (!info->sess_priv_pool || !info->sess_pool) {
+ info->cid), 0, 0,
+ rte_lcore_to_socket_id(lo->lcore_id));
+
+ if (!info->sess_pool) {
RTE_LOG(ERR, USER1, "Failed to create mempool");
goto error_exit;
}
@@ -574,7 +567,6 @@ main(int argc, char *argv[])
qp_conf.nb_descriptors = NB_CRYPTO_DESCRIPTORS;
qp_conf.mp_session = info->sess_pool;
- qp_conf.mp_session_private = info->sess_priv_pool;
for (j = 0; j < dev_info.max_nb_queue_pairs; j++) {
ret = rte_cryptodev_queue_pair_setup(info->cid, j,
diff --git a/lib/cryptodev/cryptodev_pmd.h b/lib/cryptodev/cryptodev_pmd.h
index 0d1bef0e67..94f427a912 100644
--- a/lib/cryptodev/cryptodev_pmd.h
+++ b/lib/cryptodev/cryptodev_pmd.h
@@ -301,7 +301,6 @@ typedef unsigned int (*cryptodev_asym_get_session_private_size_t)(
* @param dev Crypto device pointer
* @param xform Single or chain of crypto xforms
* @param session Pointer to cryptodev's private session structure
- * @param mp Mempool where the private session is allocated
*
* @return
* - Returns 0 if private session structure have been created successfully.
@@ -310,9 +309,7 @@ typedef unsigned int (*cryptodev_asym_get_session_private_size_t)(
* - Returns -ENOMEM if the private session could not be allocated.
*/
typedef int (*cryptodev_sym_configure_session_t)(struct rte_cryptodev *dev,
- struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *session,
- struct rte_mempool *mp);
+ struct rte_crypto_sym_xform *xform, void *session);
/**
* Configure a Crypto asymmetric session on a device.
*
@@ -338,7 +335,7 @@ typedef int (*cryptodev_asym_configure_session_t)(struct rte_cryptodev *dev,
* @param sess Cryptodev session structure
*/
typedef void (*cryptodev_sym_free_session_t)(struct rte_cryptodev *dev,
- struct rte_cryptodev_sym_session *sess);
+ void *sess);
/**
* Free asymmetric session private data.
*
diff --git a/lib/cryptodev/rte_crypto.h b/lib/cryptodev/rte_crypto.h
index a864f5036f..200617f623 100644
--- a/lib/cryptodev/rte_crypto.h
+++ b/lib/cryptodev/rte_crypto.h
@@ -420,7 +420,7 @@ rte_crypto_op_sym_xforms_alloc(struct rte_crypto_op *op, uint8_t nb_xforms)
*/
static inline int
rte_crypto_op_attach_sym_session(struct rte_crypto_op *op,
- struct rte_cryptodev_sym_session *sess)
+ void *sess)
{
if (unlikely(op->type != RTE_CRYPTO_OP_TYPE_SYMMETRIC))
return -1;
diff --git a/lib/cryptodev/rte_crypto_sym.h b/lib/cryptodev/rte_crypto_sym.h
index 58c0724743..848da1942c 100644
--- a/lib/cryptodev/rte_crypto_sym.h
+++ b/lib/cryptodev/rte_crypto_sym.h
@@ -932,7 +932,7 @@ __rte_crypto_sym_op_sym_xforms_alloc(struct rte_crypto_sym_op *sym_op,
*/
static inline int
__rte_crypto_sym_op_attach_sym_session(struct rte_crypto_sym_op *sym_op,
- struct rte_cryptodev_sym_session *sess)
+ void *sess)
{
sym_op->session = sess;
diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index 2378892d40..6d3390ad03 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -201,6 +201,8 @@ struct rte_cryptodev_sym_session_pool_private_data {
/**< number of elements in sess_data array */
uint16_t user_data_sz;
/**< session user data will be placed after sess_data */
+ uint16_t sess_priv_sz;
+ /**< session user data will be placed after sess_data */
};
int
@@ -1228,8 +1230,7 @@ rte_cryptodev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
return -EINVAL;
}
- if ((qp_conf->mp_session && !qp_conf->mp_session_private) ||
- (!qp_conf->mp_session && qp_conf->mp_session_private)) {
+ if (!qp_conf->mp_session) {
CDEV_LOG_ERR("Invalid mempools\n");
return -EINVAL;
}
@@ -1237,7 +1238,6 @@ rte_cryptodev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
if (qp_conf->mp_session) {
struct rte_cryptodev_sym_session_pool_private_data *pool_priv;
uint32_t obj_size = qp_conf->mp_session->elt_size;
- uint32_t obj_priv_size = qp_conf->mp_session_private->elt_size;
struct rte_cryptodev_sym_session s = {0};
pool_priv = rte_mempool_get_priv(qp_conf->mp_session);
@@ -1249,11 +1249,11 @@ rte_cryptodev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
s.nb_drivers = pool_priv->nb_drivers;
s.user_data_sz = pool_priv->user_data_sz;
+ s.priv_sz = pool_priv->sess_priv_sz;
- if ((rte_cryptodev_sym_get_existing_header_session_size(&s) >
- obj_size) || (s.nb_drivers <= dev->driver_id) ||
- rte_cryptodev_sym_get_private_session_size(dev_id) >
- obj_priv_size) {
+ if (((rte_cryptodev_sym_get_existing_header_session_size(&s) +
+ (s.nb_drivers * s.priv_sz)) > obj_size) ||
+ (s.nb_drivers <= dev->driver_id)) {
CDEV_LOG_ERR("Invalid mempool\n");
return -EINVAL;
}
@@ -1715,11 +1715,11 @@ rte_cryptodev_pmd_callback_process(struct rte_cryptodev *dev,
int
rte_cryptodev_sym_session_init(uint8_t dev_id,
- struct rte_cryptodev_sym_session *sess,
- struct rte_crypto_sym_xform *xforms,
- struct rte_mempool *mp)
+ void *sess_opaque,
+ struct rte_crypto_sym_xform *xforms)
{
struct rte_cryptodev *dev;
+ struct rte_cryptodev_sym_session *sess = sess_opaque;
uint32_t sess_priv_sz = rte_cryptodev_sym_get_private_session_size(
dev_id);
uint8_t index;
@@ -1732,10 +1732,10 @@ rte_cryptodev_sym_session_init(uint8_t dev_id,
dev = rte_cryptodev_pmd_get_dev(dev_id);
- if (sess == NULL || xforms == NULL || dev == NULL || mp == NULL)
+ if (sess == NULL || xforms == NULL || dev == NULL)
return -EINVAL;
- if (mp->elt_size < sess_priv_sz)
+ if (sess->priv_sz < sess_priv_sz)
return -EINVAL;
index = dev->driver_id;
@@ -1745,8 +1745,11 @@ rte_cryptodev_sym_session_init(uint8_t dev_id,
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->sym_session_configure, -ENOTSUP);
if (sess->sess_data[index].refcnt == 0) {
+ sess->sess_data[index].data = (void *)((uint8_t *)sess +
+ rte_cryptodev_sym_get_header_session_size() +
+ (index * sess->priv_sz));
ret = dev->dev_ops->sym_session_configure(dev, xforms,
- sess, mp);
+ sess->sess_data[index].data);
if (ret < 0) {
CDEV_LOG_ERR(
"dev_id %d failed to configure session details",
@@ -1755,7 +1758,7 @@ rte_cryptodev_sym_session_init(uint8_t dev_id,
}
}
- rte_cryptodev_trace_sym_session_init(dev_id, sess, xforms, mp);
+ rte_cryptodev_trace_sym_session_init(dev_id, sess, xforms);
sess->sess_data[index].refcnt++;
return 0;
}
@@ -1800,6 +1803,21 @@ rte_cryptodev_asym_session_init(uint8_t dev_id,
rte_cryptodev_trace_asym_session_init(dev_id, sess, xforms, mp);
return 0;
}
+static size_t
+get_max_sym_sess_priv_sz(void)
+{
+ size_t max_sz, sz;
+ int16_t cdev_id, n;
+
+ max_sz = 0;
+ n = rte_cryptodev_count();
+ for (cdev_id = 0; cdev_id != n; cdev_id++) {
+ sz = rte_cryptodev_sym_get_private_session_size(cdev_id);
+ if (sz > max_sz)
+ max_sz = sz;
+ }
+ return max_sz;
+}
struct rte_mempool *
rte_cryptodev_sym_session_pool_create(const char *name, uint32_t nb_elts,
@@ -1809,15 +1827,15 @@ rte_cryptodev_sym_session_pool_create(const char *name, uint32_t nb_elts,
struct rte_mempool *mp;
struct rte_cryptodev_sym_session_pool_private_data *pool_priv;
uint32_t obj_sz;
+ uint32_t sess_priv_sz = get_max_sym_sess_priv_sz();
obj_sz = rte_cryptodev_sym_get_header_session_size() + user_data_size;
- if (obj_sz > elt_size)
+ if (elt_size < obj_sz + (sess_priv_sz * nb_drivers)) {
CDEV_LOG_INFO("elt_size %u is expanded to %u\n", elt_size,
- obj_sz);
- else
- obj_sz = elt_size;
-
- mp = rte_mempool_create(name, nb_elts, obj_sz, cache_size,
+ obj_sz + (sess_priv_sz * nb_drivers));
+ elt_size = obj_sz + (sess_priv_sz * nb_drivers);
+ }
+ mp = rte_mempool_create(name, nb_elts, elt_size, cache_size,
(uint32_t)(sizeof(*pool_priv)),
NULL, NULL, NULL, NULL,
socket_id, 0);
@@ -1837,6 +1855,7 @@ rte_cryptodev_sym_session_pool_create(const char *name, uint32_t nb_elts,
pool_priv->nb_drivers = nb_drivers;
pool_priv->user_data_sz = user_data_size;
+ pool_priv->sess_priv_sz = sess_priv_sz;
rte_cryptodev_trace_sym_session_pool_create(name, nb_elts,
elt_size, cache_size, user_data_size, mp);
@@ -1870,7 +1889,7 @@ rte_cryptodev_sym_is_valid_session_pool(struct rte_mempool *mp)
return 1;
}
-struct rte_cryptodev_sym_session *
+void *
rte_cryptodev_sym_session_create(struct rte_mempool *mp)
{
struct rte_cryptodev_sym_session *sess;
@@ -1891,6 +1910,7 @@ rte_cryptodev_sym_session_create(struct rte_mempool *mp)
sess->nb_drivers = pool_priv->nb_drivers;
sess->user_data_sz = pool_priv->user_data_sz;
+ sess->priv_sz = pool_priv->sess_priv_sz;
sess->opaque_data = 0;
/* Clear device session pointer.
@@ -1900,7 +1920,7 @@ rte_cryptodev_sym_session_create(struct rte_mempool *mp)
rte_cryptodev_sym_session_data_size(sess));
rte_cryptodev_trace_sym_session_create(mp, sess);
- return sess;
+ return (void *)sess;
}
struct rte_cryptodev_asym_session *
@@ -1938,9 +1958,9 @@ rte_cryptodev_asym_session_create(struct rte_mempool *mp)
}
int
-rte_cryptodev_sym_session_clear(uint8_t dev_id,
- struct rte_cryptodev_sym_session *sess)
+rte_cryptodev_sym_session_clear(uint8_t dev_id, void *s)
{
+ struct rte_cryptodev_sym_session *sess = s;
struct rte_cryptodev *dev;
uint8_t driver_id;
@@ -1962,7 +1982,7 @@ rte_cryptodev_sym_session_clear(uint8_t dev_id,
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->sym_session_clear, -ENOTSUP);
- dev->dev_ops->sym_session_clear(dev, sess);
+ dev->dev_ops->sym_session_clear(dev, sess->sess_data[driver_id].data);
rte_cryptodev_trace_sym_session_clear(dev_id, sess);
return 0;
@@ -1993,10 +2013,11 @@ rte_cryptodev_asym_session_clear(uint8_t dev_id,
}
int
-rte_cryptodev_sym_session_free(struct rte_cryptodev_sym_session *sess)
+rte_cryptodev_sym_session_free(void *s)
{
uint8_t i;
struct rte_mempool *sess_mp;
+ struct rte_cryptodev_sym_session *sess = s;
if (sess == NULL)
return -EINVAL;
diff --git a/lib/cryptodev/rte_cryptodev.h b/lib/cryptodev/rte_cryptodev.h
index 739ad529e5..78c7ca3e20 100644
--- a/lib/cryptodev/rte_cryptodev.h
+++ b/lib/cryptodev/rte_cryptodev.h
@@ -539,8 +539,6 @@ struct rte_cryptodev_qp_conf {
uint32_t nb_descriptors; /**< Number of descriptors per queue pair */
struct rte_mempool *mp_session;
/**< The mempool for creating session in sessionless mode */
- struct rte_mempool *mp_session_private;
- /**< The mempool for creating sess private data in sessionless mode */
};
/**
@@ -910,6 +908,8 @@ struct rte_cryptodev_sym_session {
/**< number of elements in sess_data array */
uint16_t user_data_sz;
/**< session user data will be placed after sess_data */
+ uint16_t priv_sz;
+ /**< Maximum private session data size which each driver can use */
__extension__ struct {
void *data;
uint16_t refcnt;
@@ -961,10 +961,10 @@ rte_cryptodev_sym_session_pool_create(const char *name, uint32_t nb_elts,
* @param mempool Symmetric session mempool to allocate session
* objects from
* @return
- * - On success return pointer to sym-session
+ * - On success return opaque pointer to sym-session
* - On failure returns NULL
*/
-struct rte_cryptodev_sym_session *
+void *
rte_cryptodev_sym_session_create(struct rte_mempool *mempool);
/**
@@ -993,7 +993,7 @@ rte_cryptodev_asym_session_create(struct rte_mempool *mempool);
* - -EBUSY if not all device private data has been freed.
*/
int
-rte_cryptodev_sym_session_free(struct rte_cryptodev_sym_session *sess);
+rte_cryptodev_sym_session_free(void *sess);
/**
* Frees asymmetric crypto session header, after checking that all
@@ -1013,25 +1013,23 @@ rte_cryptodev_asym_session_free(struct rte_cryptodev_asym_session *sess);
/**
* Fill out private data for the device id, based on its device type.
+ * Memory for private data is already allocated in sess, driver need
+ * to fill the content.
*
* @param dev_id ID of device that we want the session to be used on
* @param sess Session where the private data will be attached to
* @param xforms Symmetric crypto transform operations to apply on flow
* processed with this session
- * @param mempool Mempool where the private data is allocated.
*
* @return
* - On success, zero.
* - -EINVAL if input parameters are invalid.
* - -ENOTSUP if crypto device does not support the crypto transform or
* does not support symmetric operations.
- * - -ENOMEM if the private session could not be allocated.
*/
int
-rte_cryptodev_sym_session_init(uint8_t dev_id,
- struct rte_cryptodev_sym_session *sess,
- struct rte_crypto_sym_xform *xforms,
- struct rte_mempool *mempool);
+rte_cryptodev_sym_session_init(uint8_t dev_id, void *sess,
+ struct rte_crypto_sym_xform *xforms);
/**
* Initialize asymmetric session on a device with specific asymmetric xform
@@ -1070,8 +1068,7 @@ rte_cryptodev_asym_session_init(uint8_t dev_id,
* - -ENOTSUP if crypto device does not support symmetric operations.
*/
int
-rte_cryptodev_sym_session_clear(uint8_t dev_id,
- struct rte_cryptodev_sym_session *sess);
+rte_cryptodev_sym_session_clear(uint8_t dev_id, void *sess);
/**
* Frees resources held by asymmetric session during rte_cryptodev_session_init
diff --git a/lib/cryptodev/rte_cryptodev_trace.h b/lib/cryptodev/rte_cryptodev_trace.h
index d1f4f069a3..44da04c425 100644
--- a/lib/cryptodev/rte_cryptodev_trace.h
+++ b/lib/cryptodev/rte_cryptodev_trace.h
@@ -56,7 +56,6 @@ RTE_TRACE_POINT(
rte_trace_point_emit_u16(queue_pair_id);
rte_trace_point_emit_u32(conf->nb_descriptors);
rte_trace_point_emit_ptr(conf->mp_session);
- rte_trace_point_emit_ptr(conf->mp_session_private);
)
RTE_TRACE_POINT(
@@ -106,15 +105,13 @@ RTE_TRACE_POINT(
RTE_TRACE_POINT(
rte_cryptodev_trace_sym_session_init,
RTE_TRACE_POINT_ARGS(uint8_t dev_id,
- struct rte_cryptodev_sym_session *sess, void *xforms,
- void *mempool),
+ struct rte_cryptodev_sym_session *sess, void *xforms),
rte_trace_point_emit_u8(dev_id);
rte_trace_point_emit_ptr(sess);
rte_trace_point_emit_u64(sess->opaque_data);
rte_trace_point_emit_u16(sess->nb_drivers);
rte_trace_point_emit_u16(sess->user_data_sz);
rte_trace_point_emit_ptr(xforms);
- rte_trace_point_emit_ptr(mempool);
)
RTE_TRACE_POINT(
diff --git a/lib/pipeline/rte_table_action.c b/lib/pipeline/rte_table_action.c
index 4b0316bfed..c3b7fb84c4 100644
--- a/lib/pipeline/rte_table_action.c
+++ b/lib/pipeline/rte_table_action.c
@@ -1719,7 +1719,7 @@ struct sym_crypto_data {
uint16_t op_mask;
/** Session pointer. */
- struct rte_cryptodev_sym_session *session;
+ void *session;
/** Direction of crypto, encrypt or decrypt */
uint16_t direction;
@@ -1780,7 +1780,7 @@ sym_crypto_apply(struct sym_crypto_data *data,
const struct rte_crypto_auth_xform *auth_xform = NULL;
const struct rte_crypto_aead_xform *aead_xform = NULL;
struct rte_crypto_sym_xform *xform = p->xform;
- struct rte_cryptodev_sym_session *session;
+ void *session;
int ret;
memset(data, 0, sizeof(*data));
@@ -1905,7 +1905,7 @@ sym_crypto_apply(struct sym_crypto_data *data,
return -ENOMEM;
ret = rte_cryptodev_sym_session_init(cfg->cryptodev_id, session,
- p->xform, cfg->mp_init);
+ p->xform);
if (ret < 0) {
rte_cryptodev_sym_session_free(session);
return ret;
@@ -2858,7 +2858,7 @@ rte_table_action_time_read(struct rte_table_action *action,
return 0;
}
-struct rte_cryptodev_sym_session *
+void *
rte_table_action_crypto_sym_session_get(struct rte_table_action *action,
void *data)
{
diff --git a/lib/pipeline/rte_table_action.h b/lib/pipeline/rte_table_action.h
index 82bc9d9ac9..68db453a8b 100644
--- a/lib/pipeline/rte_table_action.h
+++ b/lib/pipeline/rte_table_action.h
@@ -1129,7 +1129,7 @@ rte_table_action_time_read(struct rte_table_action *action,
* The pointer to the session on success, NULL otherwise.
*/
__rte_experimental
-struct rte_cryptodev_sym_session *
+void *
rte_table_action_crypto_sym_session_get(struct rte_table_action *action,
void *data);
diff --git a/lib/vhost/rte_vhost_crypto.h b/lib/vhost/rte_vhost_crypto.h
index f54d731139..d9b7beed9c 100644
--- a/lib/vhost/rte_vhost_crypto.h
+++ b/lib/vhost/rte_vhost_crypto.h
@@ -50,8 +50,6 @@ rte_vhost_crypto_driver_start(const char *path);
* multiple Vhost-crypto devices.
* @param sess_pool
* The pointer to the created cryptodev session pool.
- * @param sess_priv_pool
- * The pointer to the created cryptodev session private data mempool.
* @param socket_id
* NUMA Socket ID to allocate resources on. *
* @return
@@ -61,7 +59,6 @@ rte_vhost_crypto_driver_start(const char *path);
int
rte_vhost_crypto_create(int vid, uint8_t cryptodev_id,
struct rte_mempool *sess_pool,
- struct rte_mempool *sess_priv_pool,
int socket_id);
/**
diff --git a/lib/vhost/vhost_crypto.c b/lib/vhost/vhost_crypto.c
index 926b5c0bd9..b4464c4253 100644
--- a/lib/vhost/vhost_crypto.c
+++ b/lib/vhost/vhost_crypto.c
@@ -338,7 +338,7 @@ vhost_crypto_create_sess(struct vhost_crypto *vcrypto,
VhostUserCryptoSessionParam *sess_param)
{
struct rte_crypto_sym_xform xform1 = {0}, xform2 = {0};
- struct rte_cryptodev_sym_session *session;
+ void *session;
int ret;
switch (sess_param->op_type) {
@@ -383,8 +383,7 @@ vhost_crypto_create_sess(struct vhost_crypto *vcrypto,
return;
}
- if (rte_cryptodev_sym_session_init(vcrypto->cid, session, &xform1,
- vcrypto->sess_priv_pool) < 0) {
+ if (rte_cryptodev_sym_session_init(vcrypto->cid, session, &xform1) < 0) {
VC_LOG_ERR("Failed to initialize session");
sess_param->session_id = -VIRTIO_CRYPTO_ERR;
return;
@@ -1425,7 +1424,6 @@ rte_vhost_crypto_driver_start(const char *path)
int
rte_vhost_crypto_create(int vid, uint8_t cryptodev_id,
struct rte_mempool *sess_pool,
- struct rte_mempool *sess_priv_pool,
int socket_id)
{
struct virtio_net *dev = get_device(vid);
@@ -1447,7 +1445,6 @@ rte_vhost_crypto_create(int vid, uint8_t cryptodev_id,
}
vcrypto->sess_pool = sess_pool;
- vcrypto->sess_priv_pool = sess_priv_pool;
vcrypto->cid = cryptodev_id;
vcrypto->cache_session_id = UINT64_MAX;
vcrypto->last_session_id = 1;
--
2.25.1
^ permalink raw reply [relevance 1%]
* [dpdk-dev] [PATCH v2 1/7] security: rework session framework
@ 2021-10-13 19:22 1% ` Akhil Goyal
2021-10-13 19:22 1% ` [dpdk-dev] [PATCH v2 5/7] cryptodev: " Akhil Goyal
1 sibling, 0 replies; 200+ results
From: Akhil Goyal @ 2021-10-13 19:22 UTC (permalink / raw)
To: dev
Cc: thomas, david.marchand, hemant.agrawal, anoobj,
pablo.de.lara.guarch, fiona.trahe, declan.doherty, matan,
g.singh, roy.fan.zhang, jianjay.zhou, asomalap, ruifeng.wang,
konstantin.ananyev, radu.nicolau, ajit.khaparde, rnagadheeraj,
adwivedi, ciara.power, haiyue.wang, jiawenwu, jianwang,
Akhil Goyal
As per current design, rte_security_session_create()
unnecesarily use 2 mempool objects for a single session.
And structure rte_security_session is not directly used
by the application, it may cause ABI breakage if the structure
is modified in future.
To address these two issues, the API will now take only 1 mempool
object instead of 2 and return a void pointer directly
to the session private data. With this change, the library layer
will get the object from mempool and pass session_private_data
to the PMD for filling the PMD data.
Since set and get pkt metadata for security sessions are now
made inline for Inline crypto/proto mode, a new member fast_mdata
is added to the rte_security_session.
To access opaque data and fast_mdata will be accessed via inline
APIs which can do pointer manipulations inside library from
session_private_data pointer coming from application.
Signed-off-by: Akhil Goyal <gakhil@marvell.com>
---
app/test-crypto-perf/cperf_ops.c | 13 +-
.../cperf_test_pmd_cyclecount.c | 2 +-
app/test/test_cryptodev.c | 17 +-
app/test/test_ipsec.c | 11 +-
app/test/test_security.c | 193 ++++--------------
drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 5 +-
.../crypto/aesni_mb/rte_aesni_mb_pmd_ops.c | 30 +--
drivers/crypto/caam_jr/caam_jr.c | 32 +--
drivers/crypto/cnxk/cn10k_cryptodev_ops.c | 6 +-
drivers/crypto/cnxk/cn10k_ipsec.c | 53 +----
drivers/crypto/cnxk/cn9k_cryptodev_ops.c | 2 +-
drivers/crypto/cnxk/cn9k_ipsec.c | 50 +----
drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c | 39 +---
drivers/crypto/dpaa_sec/dpaa_sec.c | 34 +--
drivers/crypto/mvsam/rte_mrvl_pmd.c | 3 +-
drivers/crypto/mvsam/rte_mrvl_pmd_ops.c | 11 +-
drivers/crypto/octeontx2/otx2_cryptodev_ops.c | 2 +-
drivers/crypto/octeontx2/otx2_cryptodev_sec.c | 54 +----
drivers/crypto/qat/qat_sym.c | 3 +-
drivers/crypto/qat/qat_sym.h | 8 +-
drivers/crypto/qat/qat_sym_session.c | 21 +-
drivers/crypto/qat/qat_sym_session.h | 4 +-
drivers/net/ixgbe/ixgbe_ipsec.c | 38 +---
drivers/net/meson.build | 2 +-
drivers/net/octeontx2/otx2_ethdev_sec.c | 51 ++---
drivers/net/octeontx2/otx2_ethdev_sec_tx.h | 2 +-
drivers/net/txgbe/txgbe_ipsec.c | 38 +---
examples/ipsec-secgw/ipsec.c | 9 +-
lib/security/rte_security.c | 28 +--
lib/security/rte_security.h | 41 ++--
lib/security/rte_security_driver.h | 16 +-
31 files changed, 203 insertions(+), 615 deletions(-)
diff --git a/app/test-crypto-perf/cperf_ops.c b/app/test-crypto-perf/cperf_ops.c
index 263841c339..6c3aa77dec 100644
--- a/app/test-crypto-perf/cperf_ops.c
+++ b/app/test-crypto-perf/cperf_ops.c
@@ -67,8 +67,6 @@ cperf_set_ops_security(struct rte_crypto_op **ops,
for (i = 0; i < nb_ops; i++) {
struct rte_crypto_sym_op *sym_op = ops[i]->sym;
- struct rte_security_session *sec_sess =
- (struct rte_security_session *)sess;
uint32_t buf_sz;
uint32_t *per_pkt_hfn = rte_crypto_op_ctod_offset(ops[i],
@@ -76,7 +74,7 @@ cperf_set_ops_security(struct rte_crypto_op **ops,
*per_pkt_hfn = options->pdcp_ses_hfn_en ? 0 : PDCP_DEFAULT_HFN;
ops[i]->status = RTE_CRYPTO_OP_STATUS_NOT_PROCESSED;
- rte_security_attach_session(ops[i], sec_sess);
+ rte_security_attach_session(ops[i], (void *)sess);
sym_op->m_src = (struct rte_mbuf *)((uint8_t *)ops[i] +
src_buf_offset);
@@ -608,7 +606,6 @@ cperf_set_ops_aead(struct rte_crypto_op **ops,
static struct rte_cryptodev_sym_session *
create_ipsec_session(struct rte_mempool *sess_mp,
- struct rte_mempool *priv_mp,
uint8_t dev_id,
const struct cperf_options *options,
const struct cperf_test_vector *test_vector,
@@ -720,7 +717,7 @@ create_ipsec_session(struct rte_mempool *sess_mp,
/* Create security session */
return (void *)rte_security_session_create(ctx,
- &sess_conf, sess_mp, priv_mp);
+ &sess_conf, sess_mp);
}
static struct rte_cryptodev_sym_session *
@@ -831,11 +828,11 @@ cperf_create_session(struct rte_mempool *sess_mp,
/* Create security session */
return (void *)rte_security_session_create(ctx,
- &sess_conf, sess_mp, priv_mp);
+ &sess_conf, sess_mp);
}
if (options->op_type == CPERF_IPSEC) {
- return create_ipsec_session(sess_mp, priv_mp, dev_id,
+ return create_ipsec_session(sess_mp, dev_id,
options, test_vector, iv_offset);
}
@@ -880,7 +877,7 @@ cperf_create_session(struct rte_mempool *sess_mp,
/* Create security session */
return (void *)rte_security_session_create(ctx,
- &sess_conf, sess_mp, priv_mp);
+ &sess_conf, sess_mp);
}
#endif
sess = rte_cryptodev_sym_session_create(sess_mp);
diff --git a/app/test-crypto-perf/cperf_test_pmd_cyclecount.c b/app/test-crypto-perf/cperf_test_pmd_cyclecount.c
index fda97e8ab9..e43e2a3b96 100644
--- a/app/test-crypto-perf/cperf_test_pmd_cyclecount.c
+++ b/app/test-crypto-perf/cperf_test_pmd_cyclecount.c
@@ -70,7 +70,7 @@ cperf_pmd_cyclecount_test_free(struct cperf_pmd_cyclecount_ctx *ctx)
(struct rte_security_ctx *)
rte_cryptodev_get_sec_ctx(ctx->dev_id);
rte_security_session_destroy(sec_ctx,
- (struct rte_security_session *)ctx->sess);
+ (void *)ctx->sess);
} else
#endif
{
diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index 65b64e1af0..79019eb766 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -83,7 +83,7 @@ struct crypto_unittest_params {
union {
struct rte_cryptodev_sym_session *sess;
#ifdef RTE_LIB_SECURITY
- struct rte_security_session *sec_session;
+ void *sec_session;
#endif
};
#ifdef RTE_LIB_SECURITY
@@ -8278,8 +8278,7 @@ static int test_pdcp_proto(int i, int oop, enum rte_crypto_cipher_operation opc,
/* Create security session */
ut_params->sec_session = rte_security_session_create(ctx,
- &sess_conf, ts_params->session_mpool,
- ts_params->session_priv_mpool);
+ &sess_conf, ts_params->session_mpool);
if (!ut_params->sec_session) {
printf("TestCase %s()-%d line %d failed %s: ",
@@ -8539,8 +8538,7 @@ test_pdcp_proto_SGL(int i, int oop,
/* Create security session */
ut_params->sec_session = rte_security_session_create(ctx,
- &sess_conf, ts_params->session_mpool,
- ts_params->session_priv_mpool);
+ &sess_conf, ts_params->session_mpool);
if (!ut_params->sec_session) {
printf("TestCase %s()-%d line %d failed %s: ",
@@ -9024,8 +9022,7 @@ test_ipsec_proto_process(const struct ipsec_test_data td[],
/* Create security session */
ut_params->sec_session = rte_security_session_create(ctx, &sess_conf,
- ts_params->session_mpool,
- ts_params->session_priv_mpool);
+ ts_params->session_mpool);
if (ut_params->sec_session == NULL)
return TEST_SKIPPED;
@@ -9446,8 +9443,7 @@ test_docsis_proto_uplink(int i, struct docsis_test_data *d_td)
/* Create security session */
ut_params->sec_session = rte_security_session_create(ctx, &sess_conf,
- ts_params->session_mpool,
- ts_params->session_priv_mpool);
+ ts_params->session_mpool);
if (!ut_params->sec_session) {
printf("TestCase %s(%d) line %d: %s\n",
@@ -9622,8 +9618,7 @@ test_docsis_proto_downlink(int i, struct docsis_test_data *d_td)
/* Create security session */
ut_params->sec_session = rte_security_session_create(ctx, &sess_conf,
- ts_params->session_mpool,
- ts_params->session_priv_mpool);
+ ts_params->session_mpool);
if (!ut_params->sec_session) {
printf("TestCase %s(%d) line %d: %s\n",
diff --git a/app/test/test_ipsec.c b/app/test/test_ipsec.c
index c6d6b88d6d..2ffa2a8e79 100644
--- a/app/test/test_ipsec.c
+++ b/app/test/test_ipsec.c
@@ -148,18 +148,16 @@ const struct supported_auth_algo auth_algos[] = {
static int
dummy_sec_create(void *device, struct rte_security_session_conf *conf,
- struct rte_security_session *sess, struct rte_mempool *mp)
+ void *sess)
{
RTE_SET_USED(device);
RTE_SET_USED(conf);
- RTE_SET_USED(mp);
-
- sess->sess_private_data = NULL;
+ RTE_SET_USED(sess);
return 0;
}
static int
-dummy_sec_destroy(void *device, struct rte_security_session *sess)
+dummy_sec_destroy(void *device, void *sess)
{
RTE_SET_USED(device);
RTE_SET_USED(sess);
@@ -631,8 +629,7 @@ create_dummy_sec_session(struct ipsec_unitest_params *ut,
static struct rte_security_session_conf conf;
ut->ss[j].security.ses = rte_security_session_create(&dummy_sec_ctx,
- &conf, qp->mp_session,
- qp->mp_session_private);
+ &conf, qp->mp_session);
if (ut->ss[j].security.ses == NULL)
return -ENOMEM;
diff --git a/app/test/test_security.c b/app/test/test_security.c
index 060cf1ffa8..1cea756880 100644
--- a/app/test/test_security.c
+++ b/app/test/test_security.c
@@ -200,25 +200,6 @@
expected_mempool_usage, mempool_usage); \
} while (0)
-/**
- * Verify usage of mempool by checking if number of allocated objects matches
- * expectations. The mempool is used to manage objects for sessions priv data.
- * A single object is acquired from mempool during session_create
- * and put back in session_destroy.
- *
- * @param expected_priv_mp_usage expected number of used priv mp objects
- */
-#define TEST_ASSERT_PRIV_MP_USAGE(expected_priv_mp_usage) do { \
- struct security_testsuite_params *ts_params = &testsuite_params;\
- unsigned int priv_mp_usage; \
- priv_mp_usage = rte_mempool_in_use_count( \
- ts_params->session_priv_mpool); \
- TEST_ASSERT_EQUAL(expected_priv_mp_usage, priv_mp_usage, \
- "Expecting %u priv mempool allocations, " \
- "but there are %u allocated objects", \
- expected_priv_mp_usage, priv_mp_usage); \
-} while (0)
-
/**
* Mockup structures and functions for rte_security_ops;
*
@@ -253,39 +234,28 @@
static struct mock_session_create_data {
void *device;
struct rte_security_session_conf *conf;
- struct rte_security_session *sess;
+ void *sess;
struct rte_mempool *mp;
- struct rte_mempool *priv_mp;
int ret;
int called;
int failed;
-} mock_session_create_exp = {NULL, NULL, NULL, NULL, NULL, 0, 0, 0};
+} mock_session_create_exp = {NULL, NULL, NULL, NULL, 0, 0, 0};
static int
mock_session_create(void *device,
struct rte_security_session_conf *conf,
- struct rte_security_session *sess,
- struct rte_mempool *priv_mp)
+ void *sess)
{
- void *sess_priv;
- int ret;
mock_session_create_exp.called++;
MOCK_TEST_ASSERT_POINTER_PARAMETER(mock_session_create_exp, device);
MOCK_TEST_ASSERT_POINTER_PARAMETER(mock_session_create_exp, conf);
- MOCK_TEST_ASSERT_POINTER_PARAMETER(mock_session_create_exp, priv_mp);
- if (mock_session_create_exp.ret == 0) {
- ret = rte_mempool_get(priv_mp, &sess_priv);
- TEST_ASSERT_EQUAL(0, ret,
- "priv mempool does not have enough objects");
-
- set_sec_session_private_data(sess, sess_priv);
+ if (mock_session_create_exp.ret == 0)
mock_session_create_exp.sess = sess;
- }
return mock_session_create_exp.ret;
}
@@ -297,7 +267,7 @@ mock_session_create(void *device,
*/
static struct mock_session_update_data {
void *device;
- struct rte_security_session *sess;
+ void *sess;
struct rte_security_session_conf *conf;
int ret;
@@ -308,7 +278,7 @@ static struct mock_session_update_data {
static int
mock_session_update(void *device,
- struct rte_security_session *sess,
+ void *sess,
struct rte_security_session_conf *conf)
{
mock_session_update_exp.called++;
@@ -351,7 +321,7 @@ mock_session_get_size(void *device)
*/
static struct mock_session_stats_get_data {
void *device;
- struct rte_security_session *sess;
+ void *sess;
struct rte_security_stats *stats;
int ret;
@@ -362,7 +332,7 @@ static struct mock_session_stats_get_data {
static int
mock_session_stats_get(void *device,
- struct rte_security_session *sess,
+ void *sess,
struct rte_security_stats *stats)
{
mock_session_stats_get_exp.called++;
@@ -381,7 +351,7 @@ mock_session_stats_get(void *device,
*/
static struct mock_session_destroy_data {
void *device;
- struct rte_security_session *sess;
+ void *sess;
int ret;
@@ -390,15 +360,9 @@ static struct mock_session_destroy_data {
} mock_session_destroy_exp = {NULL, NULL, 0, 0, 0};
static int
-mock_session_destroy(void *device, struct rte_security_session *sess)
+mock_session_destroy(void *device, void *sess)
{
- void *sess_priv = get_sec_session_private_data(sess);
-
mock_session_destroy_exp.called++;
- if ((mock_session_destroy_exp.ret == 0) && (sess_priv != NULL)) {
- rte_mempool_put(rte_mempool_from_obj(sess_priv), sess_priv);
- set_sec_session_private_data(sess, NULL);
- }
MOCK_TEST_ASSERT_POINTER_PARAMETER(mock_session_destroy_exp, device);
MOCK_TEST_ASSERT_POINTER_PARAMETER(mock_session_destroy_exp, sess);
@@ -412,7 +376,7 @@ mock_session_destroy(void *device, struct rte_security_session *sess)
*/
static struct mock_set_pkt_metadata_data {
void *device;
- struct rte_security_session *sess;
+ void *sess;
struct rte_mbuf *m;
void *params;
@@ -424,7 +388,7 @@ static struct mock_set_pkt_metadata_data {
static int
mock_set_pkt_metadata(void *device,
- struct rte_security_session *sess,
+ void *sess,
struct rte_mbuf *m,
void *params)
{
@@ -536,7 +500,6 @@ struct rte_security_ops mock_ops = {
*/
static struct security_testsuite_params {
struct rte_mempool *session_mpool;
- struct rte_mempool *session_priv_mpool;
} testsuite_params = { NULL };
/**
@@ -549,7 +512,7 @@ static struct security_testsuite_params {
static struct security_unittest_params {
struct rte_security_ctx ctx;
struct rte_security_session_conf conf;
- struct rte_security_session *sess;
+ void *sess;
} unittest_params = {
.ctx = {
.device = NULL,
@@ -563,7 +526,7 @@ static struct security_unittest_params {
#define SECURITY_TEST_PRIV_MEMPOOL_NAME "SecurityTestPrivMp"
#define SECURITY_TEST_MEMPOOL_SIZE 15
#define SECURITY_TEST_SESSION_OBJ_SZ sizeof(struct rte_security_session)
-#define SECURITY_TEST_SESSION_PRIV_OBJ_SZ 64
+#define SECURITY_TEST_SESSION_PRIV_OBJ_SZ 1024
/**
* testsuite_setup initializes whole test suite parameters.
@@ -577,27 +540,13 @@ testsuite_setup(void)
ts_params->session_mpool = rte_mempool_create(
SECURITY_TEST_MEMPOOL_NAME,
SECURITY_TEST_MEMPOOL_SIZE,
- SECURITY_TEST_SESSION_OBJ_SZ,
+ SECURITY_TEST_SESSION_OBJ_SZ +
+ SECURITY_TEST_SESSION_PRIV_OBJ_SZ,
0, 0, NULL, NULL, NULL, NULL,
SOCKET_ID_ANY, 0);
TEST_ASSERT_NOT_NULL(ts_params->session_mpool,
"Cannot create mempool %s\n", rte_strerror(rte_errno));
- ts_params->session_priv_mpool = rte_mempool_create(
- SECURITY_TEST_PRIV_MEMPOOL_NAME,
- SECURITY_TEST_MEMPOOL_SIZE,
- SECURITY_TEST_SESSION_PRIV_OBJ_SZ,
- 0, 0, NULL, NULL, NULL, NULL,
- SOCKET_ID_ANY, 0);
- if (ts_params->session_priv_mpool == NULL) {
- RTE_LOG(ERR, USER1, "TestCase %s() line %d failed (null): "
- "Cannot create priv mempool %s\n",
- __func__, __LINE__, rte_strerror(rte_errno));
- rte_mempool_free(ts_params->session_mpool);
- ts_params->session_mpool = NULL;
- return TEST_FAILED;
- }
-
return TEST_SUCCESS;
}
@@ -612,10 +561,6 @@ testsuite_teardown(void)
rte_mempool_free(ts_params->session_mpool);
ts_params->session_mpool = NULL;
}
- if (ts_params->session_priv_mpool) {
- rte_mempool_free(ts_params->session_priv_mpool);
- ts_params->session_priv_mpool = NULL;
- }
}
/**
@@ -704,7 +649,7 @@ ut_setup_with_session(void)
{
struct security_unittest_params *ut_params = &unittest_params;
struct security_testsuite_params *ts_params = &testsuite_params;
- struct rte_security_session *sess;
+ void *sess;
int ret = ut_setup();
if (ret != TEST_SUCCESS)
@@ -713,12 +658,11 @@ ut_setup_with_session(void)
mock_session_create_exp.device = NULL;
mock_session_create_exp.conf = &ut_params->conf;
mock_session_create_exp.mp = ts_params->session_mpool;
- mock_session_create_exp.priv_mp = ts_params->session_priv_mpool;
mock_session_create_exp.ret = 0;
sess = rte_security_session_create(&ut_params->ctx, &ut_params->conf,
- ts_params->session_mpool,
- ts_params->session_priv_mpool);
+ ts_params->session_mpool);
+ mock_session_get_size_exp.called = 0;
TEST_ASSERT_MOCK_FUNCTION_CALL_NOT_NULL(rte_security_session_create,
sess);
TEST_ASSERT_EQUAL(sess, mock_session_create_exp.sess,
@@ -757,16 +701,14 @@ test_session_create_inv_context(void)
{
struct security_testsuite_params *ts_params = &testsuite_params;
struct security_unittest_params *ut_params = &unittest_params;
- struct rte_security_session *sess;
+ void *sess;
sess = rte_security_session_create(NULL, &ut_params->conf,
- ts_params->session_mpool,
- ts_params->session_priv_mpool);
+ ts_params->session_mpool);
TEST_ASSERT_MOCK_FUNCTION_CALL_RET(rte_security_session_create,
sess, NULL, "%p");
TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 0);
TEST_ASSERT_MEMPOOL_USAGE(0);
- TEST_ASSERT_PRIV_MP_USAGE(0);
TEST_ASSERT_SESSION_COUNT(0);
return TEST_SUCCESS;
@@ -781,18 +723,16 @@ test_session_create_inv_context_ops(void)
{
struct security_testsuite_params *ts_params = &testsuite_params;
struct security_unittest_params *ut_params = &unittest_params;
- struct rte_security_session *sess;
+ void *sess;
ut_params->ctx.ops = NULL;
sess = rte_security_session_create(&ut_params->ctx, &ut_params->conf,
- ts_params->session_mpool,
- ts_params->session_priv_mpool);
+ ts_params->session_mpool);
TEST_ASSERT_MOCK_FUNCTION_CALL_RET(rte_security_session_create,
sess, NULL, "%p");
TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 0);
TEST_ASSERT_MEMPOOL_USAGE(0);
- TEST_ASSERT_PRIV_MP_USAGE(0);
TEST_ASSERT_SESSION_COUNT(0);
return TEST_SUCCESS;
@@ -807,18 +747,16 @@ test_session_create_inv_context_ops_fun(void)
{
struct security_testsuite_params *ts_params = &testsuite_params;
struct security_unittest_params *ut_params = &unittest_params;
- struct rte_security_session *sess;
+ void *sess;
ut_params->ctx.ops = &empty_ops;
sess = rte_security_session_create(&ut_params->ctx, &ut_params->conf,
- ts_params->session_mpool,
- ts_params->session_priv_mpool);
+ ts_params->session_mpool);
TEST_ASSERT_MOCK_FUNCTION_CALL_RET(rte_security_session_create,
sess, NULL, "%p");
TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 0);
TEST_ASSERT_MEMPOOL_USAGE(0);
- TEST_ASSERT_PRIV_MP_USAGE(0);
TEST_ASSERT_SESSION_COUNT(0);
return TEST_SUCCESS;
@@ -832,16 +770,14 @@ test_session_create_inv_configuration(void)
{
struct security_testsuite_params *ts_params = &testsuite_params;
struct security_unittest_params *ut_params = &unittest_params;
- struct rte_security_session *sess;
+ void *sess;
sess = rte_security_session_create(&ut_params->ctx, NULL,
- ts_params->session_mpool,
- ts_params->session_priv_mpool);
+ ts_params->session_mpool);
TEST_ASSERT_MOCK_FUNCTION_CALL_RET(rte_security_session_create,
sess, NULL, "%p");
TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 0);
TEST_ASSERT_MEMPOOL_USAGE(0);
- TEST_ASSERT_PRIV_MP_USAGE(0);
TEST_ASSERT_SESSION_COUNT(0);
return TEST_SUCCESS;
@@ -855,39 +791,14 @@ static int
test_session_create_inv_mempool(void)
{
struct security_unittest_params *ut_params = &unittest_params;
- struct security_testsuite_params *ts_params = &testsuite_params;
- struct rte_security_session *sess;
+ void *sess;
sess = rte_security_session_create(&ut_params->ctx, &ut_params->conf,
- NULL, ts_params->session_priv_mpool);
+ NULL);
TEST_ASSERT_MOCK_FUNCTION_CALL_RET(rte_security_session_create,
sess, NULL, "%p");
TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 0);
TEST_ASSERT_MEMPOOL_USAGE(0);
- TEST_ASSERT_PRIV_MP_USAGE(0);
- TEST_ASSERT_SESSION_COUNT(0);
-
- return TEST_SUCCESS;
-}
-
-/**
- * Test execution of rte_security_session_create with NULL session
- * priv mempool
- */
-static int
-test_session_create_inv_sess_priv_mempool(void)
-{
- struct security_unittest_params *ut_params = &unittest_params;
- struct security_testsuite_params *ts_params = &testsuite_params;
- struct rte_security_session *sess;
-
- sess = rte_security_session_create(&ut_params->ctx, &ut_params->conf,
- ts_params->session_mpool, NULL);
- TEST_ASSERT_MOCK_FUNCTION_CALL_RET(rte_security_session_create,
- sess, NULL, "%p");
- TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 0);
- TEST_ASSERT_MEMPOOL_USAGE(0);
- TEST_ASSERT_PRIV_MP_USAGE(0);
TEST_ASSERT_SESSION_COUNT(0);
return TEST_SUCCESS;
@@ -902,9 +813,8 @@ test_session_create_mempool_empty(void)
{
struct security_testsuite_params *ts_params = &testsuite_params;
struct security_unittest_params *ut_params = &unittest_params;
- struct rte_security_session *tmp[SECURITY_TEST_MEMPOOL_SIZE];
- void *tmp1[SECURITY_TEST_MEMPOOL_SIZE];
- struct rte_security_session *sess;
+ void *tmp[SECURITY_TEST_MEMPOOL_SIZE];
+ void *sess;
/* Get all available objects from mempool. */
int i, ret;
@@ -914,34 +824,23 @@ test_session_create_mempool_empty(void)
TEST_ASSERT_EQUAL(0, ret,
"Expect getting %d object from mempool"
" to succeed", i);
- ret = rte_mempool_get(ts_params->session_priv_mpool,
- (void **)(&tmp1[i]));
- TEST_ASSERT_EQUAL(0, ret,
- "Expect getting %d object from priv mempool"
- " to succeed", i);
}
TEST_ASSERT_MEMPOOL_USAGE(SECURITY_TEST_MEMPOOL_SIZE);
- TEST_ASSERT_PRIV_MP_USAGE(SECURITY_TEST_MEMPOOL_SIZE);
sess = rte_security_session_create(&ut_params->ctx, &ut_params->conf,
- ts_params->session_mpool,
- ts_params->session_priv_mpool);
+ ts_params->session_mpool);
TEST_ASSERT_MOCK_FUNCTION_CALL_RET(rte_security_session_create,
sess, NULL, "%p");
TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 0);
TEST_ASSERT_MEMPOOL_USAGE(SECURITY_TEST_MEMPOOL_SIZE);
- TEST_ASSERT_PRIV_MP_USAGE(SECURITY_TEST_MEMPOOL_SIZE);
TEST_ASSERT_SESSION_COUNT(0);
/* Put objects back to the pool. */
for (i = 0; i < SECURITY_TEST_MEMPOOL_SIZE; ++i) {
rte_mempool_put(ts_params->session_mpool,
(void *)(tmp[i]));
- rte_mempool_put(ts_params->session_priv_mpool,
- (tmp1[i]));
}
TEST_ASSERT_MEMPOOL_USAGE(0);
- TEST_ASSERT_PRIV_MP_USAGE(0);
return TEST_SUCCESS;
}
@@ -955,22 +854,19 @@ test_session_create_ops_failure(void)
{
struct security_testsuite_params *ts_params = &testsuite_params;
struct security_unittest_params *ut_params = &unittest_params;
- struct rte_security_session *sess;
+ void *sess;
mock_session_create_exp.device = NULL;
mock_session_create_exp.conf = &ut_params->conf;
mock_session_create_exp.mp = ts_params->session_mpool;
- mock_session_create_exp.priv_mp = ts_params->session_priv_mpool;
mock_session_create_exp.ret = -1; /* Return failure status. */
sess = rte_security_session_create(&ut_params->ctx, &ut_params->conf,
- ts_params->session_mpool,
- ts_params->session_priv_mpool);
+ ts_params->session_mpool);
TEST_ASSERT_MOCK_FUNCTION_CALL_RET(rte_security_session_create,
sess, NULL, "%p");
TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 1);
TEST_ASSERT_MEMPOOL_USAGE(0);
- TEST_ASSERT_PRIV_MP_USAGE(0);
TEST_ASSERT_SESSION_COUNT(0);
return TEST_SUCCESS;
@@ -984,17 +880,15 @@ test_session_create_success(void)
{
struct security_testsuite_params *ts_params = &testsuite_params;
struct security_unittest_params *ut_params = &unittest_params;
- struct rte_security_session *sess;
+ void *sess;
mock_session_create_exp.device = NULL;
mock_session_create_exp.conf = &ut_params->conf;
mock_session_create_exp.mp = ts_params->session_mpool;
- mock_session_create_exp.priv_mp = ts_params->session_priv_mpool;
mock_session_create_exp.ret = 0; /* Return success status. */
sess = rte_security_session_create(&ut_params->ctx, &ut_params->conf,
- ts_params->session_mpool,
- ts_params->session_priv_mpool);
+ ts_params->session_mpool);
TEST_ASSERT_MOCK_FUNCTION_CALL_NOT_NULL(rte_security_session_create,
sess);
TEST_ASSERT_EQUAL(sess, mock_session_create_exp.sess,
@@ -1003,7 +897,6 @@ test_session_create_success(void)
sess, mock_session_create_exp.sess);
TEST_ASSERT_MOCK_CALLS(mock_session_create_exp, 1);
TEST_ASSERT_MEMPOOL_USAGE(1);
- TEST_ASSERT_PRIV_MP_USAGE(1);
TEST_ASSERT_SESSION_COUNT(1);
/*
@@ -1389,7 +1282,6 @@ test_session_destroy_inv_context(void)
struct security_unittest_params *ut_params = &unittest_params;
TEST_ASSERT_MEMPOOL_USAGE(1);
- TEST_ASSERT_PRIV_MP_USAGE(1);
TEST_ASSERT_SESSION_COUNT(1);
int ret = rte_security_session_destroy(NULL, ut_params->sess);
@@ -1397,7 +1289,6 @@ test_session_destroy_inv_context(void)
ret, -EINVAL, "%d");
TEST_ASSERT_MOCK_CALLS(mock_session_destroy_exp, 0);
TEST_ASSERT_MEMPOOL_USAGE(1);
- TEST_ASSERT_PRIV_MP_USAGE(1);
TEST_ASSERT_SESSION_COUNT(1);
return TEST_SUCCESS;
@@ -1414,7 +1305,6 @@ test_session_destroy_inv_context_ops(void)
ut_params->ctx.ops = NULL;
TEST_ASSERT_MEMPOOL_USAGE(1);
- TEST_ASSERT_PRIV_MP_USAGE(1);
TEST_ASSERT_SESSION_COUNT(1);
int ret = rte_security_session_destroy(&ut_params->ctx,
@@ -1423,7 +1313,6 @@ test_session_destroy_inv_context_ops(void)
ret, -EINVAL, "%d");
TEST_ASSERT_MOCK_CALLS(mock_session_destroy_exp, 0);
TEST_ASSERT_MEMPOOL_USAGE(1);
- TEST_ASSERT_PRIV_MP_USAGE(1);
TEST_ASSERT_SESSION_COUNT(1);
return TEST_SUCCESS;
@@ -1440,7 +1329,6 @@ test_session_destroy_inv_context_ops_fun(void)
ut_params->ctx.ops = &empty_ops;
TEST_ASSERT_MEMPOOL_USAGE(1);
- TEST_ASSERT_PRIV_MP_USAGE(1);
TEST_ASSERT_SESSION_COUNT(1);
int ret = rte_security_session_destroy(&ut_params->ctx,
@@ -1449,7 +1337,6 @@ test_session_destroy_inv_context_ops_fun(void)
ret, -ENOTSUP, "%d");
TEST_ASSERT_MOCK_CALLS(mock_session_destroy_exp, 0);
TEST_ASSERT_MEMPOOL_USAGE(1);
- TEST_ASSERT_PRIV_MP_USAGE(1);
TEST_ASSERT_SESSION_COUNT(1);
return TEST_SUCCESS;
@@ -1464,7 +1351,6 @@ test_session_destroy_inv_session(void)
struct security_unittest_params *ut_params = &unittest_params;
TEST_ASSERT_MEMPOOL_USAGE(1);
- TEST_ASSERT_PRIV_MP_USAGE(1);
TEST_ASSERT_SESSION_COUNT(1);
int ret = rte_security_session_destroy(&ut_params->ctx, NULL);
@@ -1472,7 +1358,6 @@ test_session_destroy_inv_session(void)
ret, -EINVAL, "%d");
TEST_ASSERT_MOCK_CALLS(mock_session_destroy_exp, 0);
TEST_ASSERT_MEMPOOL_USAGE(1);
- TEST_ASSERT_PRIV_MP_USAGE(1);
TEST_ASSERT_SESSION_COUNT(1);
return TEST_SUCCESS;
@@ -1492,7 +1377,6 @@ test_session_destroy_ops_failure(void)
mock_session_destroy_exp.ret = -1;
TEST_ASSERT_MEMPOOL_USAGE(1);
- TEST_ASSERT_PRIV_MP_USAGE(1);
TEST_ASSERT_SESSION_COUNT(1);
int ret = rte_security_session_destroy(&ut_params->ctx,
@@ -1501,7 +1385,6 @@ test_session_destroy_ops_failure(void)
ret, -1, "%d");
TEST_ASSERT_MOCK_CALLS(mock_session_destroy_exp, 1);
TEST_ASSERT_MEMPOOL_USAGE(1);
- TEST_ASSERT_PRIV_MP_USAGE(1);
TEST_ASSERT_SESSION_COUNT(1);
return TEST_SUCCESS;
@@ -1519,7 +1402,6 @@ test_session_destroy_success(void)
mock_session_destroy_exp.sess = ut_params->sess;
mock_session_destroy_exp.ret = 0;
TEST_ASSERT_MEMPOOL_USAGE(1);
- TEST_ASSERT_PRIV_MP_USAGE(1);
TEST_ASSERT_SESSION_COUNT(1);
int ret = rte_security_session_destroy(&ut_params->ctx,
@@ -1528,7 +1410,6 @@ test_session_destroy_success(void)
ret, 0, "%d");
TEST_ASSERT_MOCK_CALLS(mock_session_destroy_exp, 1);
TEST_ASSERT_MEMPOOL_USAGE(0);
- TEST_ASSERT_PRIV_MP_USAGE(0);
TEST_ASSERT_SESSION_COUNT(0);
/*
@@ -2495,8 +2376,6 @@ static struct unit_test_suite security_testsuite = {
test_session_create_inv_configuration),
TEST_CASE_ST(ut_setup, ut_teardown,
test_session_create_inv_mempool),
- TEST_CASE_ST(ut_setup, ut_teardown,
- test_session_create_inv_sess_priv_mempool),
TEST_CASE_ST(ut_setup, ut_teardown,
test_session_create_mempool_empty),
TEST_CASE_ST(ut_setup, ut_teardown,
diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
index bbf310166e..e8da9ea9e1 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
@@ -1021,8 +1021,7 @@ get_session(struct aesni_mb_qp *qp, struct rte_crypto_op *op)
} else if (op->sess_type == RTE_CRYPTO_OP_SECURITY_SESSION) {
if (likely(op->sym->sec_session != NULL))
sess = (struct aesni_mb_session *)
- get_sec_session_private_data(
- op->sym->sec_session);
+ (op->sym->sec_session);
#endif
} else {
void *_sess = rte_cryptodev_sym_session_create(qp->sess_mp);
@@ -1638,7 +1637,7 @@ post_process_mb_job(struct aesni_mb_qp *qp, JOB_AES_HMAC *job)
* this is for DOCSIS
*/
is_docsis_sec = 1;
- sess = get_sec_session_private_data(op->sym->sec_session);
+ sess = (struct aesni_mb_session *)(op->sym->sec_session);
} else
#endif
{
diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c
index 48a8f91868..39c67e3952 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c
@@ -1056,10 +1056,8 @@ struct rte_cryptodev_ops *rte_aesni_mb_pmd_ops = &aesni_mb_pmd_ops;
*/
static int
aesni_mb_pmd_sec_sess_create(void *dev, struct rte_security_session_conf *conf,
- struct rte_security_session *sess,
- struct rte_mempool *mempool)
+ void *sess)
{
- void *sess_private_data;
struct rte_cryptodev *cdev = (struct rte_cryptodev *)dev;
int ret;
@@ -1069,40 +1067,22 @@ aesni_mb_pmd_sec_sess_create(void *dev, struct rte_security_session_conf *conf,
return -EINVAL;
}
- if (rte_mempool_get(mempool, &sess_private_data)) {
- AESNI_MB_LOG(ERR, "Couldn't get object from session mempool");
- return -ENOMEM;
- }
-
- ret = aesni_mb_set_docsis_sec_session_parameters(cdev, conf,
- sess_private_data);
-
+ ret = aesni_mb_set_docsis_sec_session_parameters(cdev, conf, sess);
if (ret != 0) {
AESNI_MB_LOG(ERR, "Failed to configure session parameters");
-
- /* Return session to mempool */
- rte_mempool_put(mempool, sess_private_data);
return ret;
}
- set_sec_session_private_data(sess, sess_private_data);
-
return ret;
}
/** Clear the memory of session so it doesn't leave key material behind */
static int
-aesni_mb_pmd_sec_sess_destroy(void *dev __rte_unused,
- struct rte_security_session *sess)
+aesni_mb_pmd_sec_sess_destroy(void *dev __rte_unused, void *sess)
{
- void *sess_priv = get_sec_session_private_data(sess);
+ if (sess)
+ memset(sess, 0, sizeof(struct aesni_mb_session));
- if (sess_priv) {
- struct rte_mempool *sess_mp = rte_mempool_from_obj(sess_priv);
- memset(sess_priv, 0, sizeof(struct aesni_mb_session));
- set_sec_session_private_data(sess, NULL);
- rte_mempool_put(sess_mp, sess_priv);
- }
return 0;
}
diff --git a/drivers/crypto/caam_jr/caam_jr.c b/drivers/crypto/caam_jr/caam_jr.c
index 258750afe7..ce7a100778 100644
--- a/drivers/crypto/caam_jr/caam_jr.c
+++ b/drivers/crypto/caam_jr/caam_jr.c
@@ -1361,9 +1361,7 @@ caam_jr_enqueue_op(struct rte_crypto_op *op, struct caam_jr_qp *qp)
cryptodev_driver_id);
break;
case RTE_CRYPTO_OP_SECURITY_SESSION:
- ses = (struct caam_jr_session *)
- get_sec_session_private_data(
- op->sym->sec_session);
+ ses = (struct caam_jr_session *)(op->sym->sec_session);
break;
default:
CAAM_JR_DP_ERR("sessionless crypto op not supported");
@@ -1911,22 +1909,14 @@ caam_jr_set_ipsec_session(__rte_unused struct rte_cryptodev *dev,
static int
caam_jr_security_session_create(void *dev,
struct rte_security_session_conf *conf,
- struct rte_security_session *sess,
- struct rte_mempool *mempool)
+ void *sess)
{
- void *sess_private_data;
struct rte_cryptodev *cdev = (struct rte_cryptodev *)dev;
int ret;
- if (rte_mempool_get(mempool, &sess_private_data)) {
- CAAM_JR_ERR("Couldn't get object from session mempool");
- return -ENOMEM;
- }
-
switch (conf->protocol) {
case RTE_SECURITY_PROTOCOL_IPSEC:
- ret = caam_jr_set_ipsec_session(cdev, conf,
- sess_private_data);
+ ret = caam_jr_set_ipsec_session(cdev, conf, sess);
break;
case RTE_SECURITY_PROTOCOL_MACSEC:
return -ENOTSUP;
@@ -1935,34 +1925,24 @@ caam_jr_security_session_create(void *dev,
}
if (ret != 0) {
CAAM_JR_ERR("failed to configure session parameters");
- /* Return session to mempool */
- rte_mempool_put(mempool, sess_private_data);
return ret;
}
- set_sec_session_private_data(sess, sess_private_data);
-
return ret;
}
/* Clear the memory of session so it doesn't leave key material behind */
static int
-caam_jr_security_session_destroy(void *dev __rte_unused,
- struct rte_security_session *sess)
+caam_jr_security_session_destroy(void *dev __rte_unused, void *sess)
{
PMD_INIT_FUNC_TRACE();
- void *sess_priv = get_sec_session_private_data(sess);
- struct caam_jr_session *s = (struct caam_jr_session *)sess_priv;
-
- if (sess_priv) {
- struct rte_mempool *sess_mp = rte_mempool_from_obj(sess_priv);
+ struct caam_jr_session *s = (struct caam_jr_session *)sess;
+ if (sess) {
rte_free(s->cipher_key.data);
rte_free(s->auth_key.data);
memset(sess, 0, sizeof(struct caam_jr_session));
- set_sec_session_private_data(sess, NULL);
- rte_mempool_put(sess_mp, sess_priv);
}
return 0;
}
diff --git a/drivers/crypto/cnxk/cn10k_cryptodev_ops.c b/drivers/crypto/cnxk/cn10k_cryptodev_ops.c
index c25c8e67b2..de2eebd507 100644
--- a/drivers/crypto/cnxk/cn10k_cryptodev_ops.c
+++ b/drivers/crypto/cnxk/cn10k_cryptodev_ops.c
@@ -122,8 +122,8 @@ cn10k_cpt_fill_inst(struct cnxk_cpt_qp *qp, struct rte_crypto_op *ops[],
if (op->type == RTE_CRYPTO_OP_TYPE_SYMMETRIC) {
if (op->sess_type == RTE_CRYPTO_OP_SECURITY_SESSION) {
- sec_sess = get_sec_session_private_data(
- sym_op->sec_session);
+ sec_sess = (struct cn10k_sec_session *)
+ (sym_op->sec_session);
ret = cpt_sec_inst_fill(op, sec_sess, infl_req,
&inst[0]);
if (unlikely(ret))
@@ -360,7 +360,7 @@ cn10k_cpt_sec_ucc_process(struct rte_crypto_op *cop,
if (!(infl_req->op_flags & CPT_OP_FLAGS_IPSEC_DIR_INBOUND))
return;
- sess = get_sec_session_private_data(cop->sym->sec_session);
+ sess = (struct cn10k_sec_session *)(cop->sym->sec_session);
sa = &sess->sa;
mbuf = cop->sym->m_src;
diff --git a/drivers/crypto/cnxk/cn10k_ipsec.c b/drivers/crypto/cnxk/cn10k_ipsec.c
index 27df1dcd64..425fe599e0 100644
--- a/drivers/crypto/cnxk/cn10k_ipsec.c
+++ b/drivers/crypto/cnxk/cn10k_ipsec.c
@@ -35,17 +35,15 @@ static int
cn10k_ipsec_outb_sa_create(struct roc_cpt *roc_cpt,
struct rte_security_ipsec_xform *ipsec_xfrm,
struct rte_crypto_sym_xform *crypto_xfrm,
- struct rte_security_session *sec_sess)
+ struct cn10k_sec_session *sess)
{
union roc_ot_ipsec_outb_param1 param1;
struct roc_ot_ipsec_outb_sa *out_sa;
struct cnxk_ipsec_outb_rlens rlens;
- struct cn10k_sec_session *sess;
struct cn10k_ipsec_sa *sa;
union cpt_inst_w4 inst_w4;
int ret;
- sess = get_sec_session_private_data(sec_sess);
sa = &sess->sa;
out_sa = &sa->out_sa;
@@ -114,16 +112,14 @@ static int
cn10k_ipsec_inb_sa_create(struct roc_cpt *roc_cpt,
struct rte_security_ipsec_xform *ipsec_xfrm,
struct rte_crypto_sym_xform *crypto_xfrm,
- struct rte_security_session *sec_sess)
+ struct cn10k_sec_session *sess)
{
union roc_ot_ipsec_inb_param1 param1;
struct roc_ot_ipsec_inb_sa *in_sa;
- struct cn10k_sec_session *sess;
struct cn10k_ipsec_sa *sa;
union cpt_inst_w4 inst_w4;
int ret;
- sess = get_sec_session_private_data(sec_sess);
sa = &sess->sa;
in_sa = &sa->in_sa;
@@ -175,7 +171,7 @@ static int
cn10k_ipsec_session_create(void *dev,
struct rte_security_ipsec_xform *ipsec_xfrm,
struct rte_crypto_sym_xform *crypto_xfrm,
- struct rte_security_session *sess)
+ struct cn10k_sec_session *sess)
{
struct rte_cryptodev *crypto_dev = dev;
struct roc_cpt *roc_cpt;
@@ -204,55 +200,28 @@ cn10k_ipsec_session_create(void *dev,
static int
cn10k_sec_session_create(void *device, struct rte_security_session_conf *conf,
- struct rte_security_session *sess,
- struct rte_mempool *mempool)
+ void *sess)
{
- struct cn10k_sec_session *priv;
- int ret;
+ struct cn10k_sec_session *priv = sess;
if (conf->action_type != RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL)
return -EINVAL;
- if (rte_mempool_get(mempool, (void **)&priv)) {
- plt_err("Could not allocate security session private data");
- return -ENOMEM;
- }
-
- set_sec_session_private_data(sess, priv);
-
if (conf->protocol != RTE_SECURITY_PROTOCOL_IPSEC) {
- ret = -ENOTSUP;
- goto mempool_put;
+ return -ENOTSUP;
}
- ret = cn10k_ipsec_session_create(device, &conf->ipsec,
- conf->crypto_xform, sess);
- if (ret)
- goto mempool_put;
-
- return 0;
-
-mempool_put:
- rte_mempool_put(mempool, priv);
- set_sec_session_private_data(sess, NULL);
- return ret;
+ return cn10k_ipsec_session_create(device, &conf->ipsec,
+ conf->crypto_xform, priv);
}
static int
-cn10k_sec_session_destroy(void *device __rte_unused,
- struct rte_security_session *sess)
+cn10k_sec_session_destroy(void *device __rte_unused, void *sess)
{
- struct cn10k_sec_session *priv;
- struct rte_mempool *sess_mp;
-
- priv = get_sec_session_private_data(sess);
+ struct cn10k_sec_session *priv = sess;
if (priv == NULL)
return 0;
-
- sess_mp = rte_mempool_from_obj(priv);
-
- set_sec_session_private_data(sess, NULL);
- rte_mempool_put(sess_mp, priv);
+ memset(priv, 0, sizeof(*priv));
return 0;
}
diff --git a/drivers/crypto/cnxk/cn9k_cryptodev_ops.c b/drivers/crypto/cnxk/cn9k_cryptodev_ops.c
index 75277936b0..4c2dc5b080 100644
--- a/drivers/crypto/cnxk/cn9k_cryptodev_ops.c
+++ b/drivers/crypto/cnxk/cn9k_cryptodev_ops.c
@@ -56,7 +56,7 @@ cn9k_cpt_sec_inst_fill(struct rte_crypto_op *op,
return -ENOTSUP;
}
- priv = get_sec_session_private_data(op->sym->sec_session);
+ priv = (struct cn9k_sec_session *)(op->sym->sec_session);
sa = &priv->sa;
if (sa->dir == RTE_SECURITY_IPSEC_SA_DIR_EGRESS)
diff --git a/drivers/crypto/cnxk/cn9k_ipsec.c b/drivers/crypto/cnxk/cn9k_ipsec.c
index 53fb793654..a602d38a11 100644
--- a/drivers/crypto/cnxk/cn9k_ipsec.c
+++ b/drivers/crypto/cnxk/cn9k_ipsec.c
@@ -275,14 +275,13 @@ static int
cn9k_ipsec_outb_sa_create(struct cnxk_cpt_qp *qp,
struct rte_security_ipsec_xform *ipsec,
struct rte_crypto_sym_xform *crypto_xform,
- struct rte_security_session *sec_sess)
+ struct cn9k_sec_session *sess)
{
struct rte_crypto_sym_xform *auth_xform = crypto_xform->next;
struct roc_ie_on_ip_template *template = NULL;
struct roc_cpt *roc_cpt = qp->lf.roc_cpt;
struct cnxk_cpt_inst_tmpl *inst_tmpl;
struct roc_ie_on_outb_sa *out_sa;
- struct cn9k_sec_session *sess;
struct roc_ie_on_sa_ctl *ctl;
struct cn9k_ipsec_sa *sa;
struct rte_ipv6_hdr *ip6;
@@ -294,7 +293,6 @@ cn9k_ipsec_outb_sa_create(struct cnxk_cpt_qp *qp,
size_t ctx_len;
int ret;
- sess = get_sec_session_private_data(sec_sess);
sa = &sess->sa;
out_sa = &sa->out_sa;
ctl = &out_sa->common_sa.ctl;
@@ -422,13 +420,12 @@ static int
cn9k_ipsec_inb_sa_create(struct cnxk_cpt_qp *qp,
struct rte_security_ipsec_xform *ipsec,
struct rte_crypto_sym_xform *crypto_xform,
- struct rte_security_session *sec_sess)
+ struct cn9k_sec_session *sess)
{
struct rte_crypto_sym_xform *auth_xform = crypto_xform;
struct roc_cpt *roc_cpt = qp->lf.roc_cpt;
struct cnxk_cpt_inst_tmpl *inst_tmpl;
struct roc_ie_on_inb_sa *in_sa;
- struct cn9k_sec_session *sess;
struct cn9k_ipsec_sa *sa;
const uint8_t *auth_key;
union cpt_inst_w4 w4;
@@ -437,7 +434,6 @@ cn9k_ipsec_inb_sa_create(struct cnxk_cpt_qp *qp,
size_t ctx_len = 0;
int ret;
- sess = get_sec_session_private_data(sec_sess);
sa = &sess->sa;
in_sa = &sa->in_sa;
@@ -501,7 +497,7 @@ static int
cn9k_ipsec_session_create(void *dev,
struct rte_security_ipsec_xform *ipsec_xform,
struct rte_crypto_sym_xform *crypto_xform,
- struct rte_security_session *sess)
+ struct cn9k_sec_session *sess)
{
struct rte_cryptodev *crypto_dev = dev;
struct cnxk_cpt_qp *qp;
@@ -532,53 +528,32 @@ cn9k_ipsec_session_create(void *dev,
static int
cn9k_sec_session_create(void *device, struct rte_security_session_conf *conf,
- struct rte_security_session *sess,
- struct rte_mempool *mempool)
+ void *sess)
{
- struct cn9k_sec_session *priv;
- int ret;
+ struct cn9k_sec_session *priv = sess;
if (conf->action_type != RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL)
return -EINVAL;
- if (rte_mempool_get(mempool, (void **)&priv)) {
- plt_err("Could not allocate security session private data");
- return -ENOMEM;
- }
-
memset(priv, 0, sizeof(*priv));
- set_sec_session_private_data(sess, priv);
-
if (conf->protocol != RTE_SECURITY_PROTOCOL_IPSEC) {
- ret = -ENOTSUP;
- goto mempool_put;
+ return -ENOTSUP;
}
- ret = cn9k_ipsec_session_create(device, &conf->ipsec,
- conf->crypto_xform, sess);
- if (ret)
- goto mempool_put;
-
- return 0;
-
-mempool_put:
- rte_mempool_put(mempool, priv);
- set_sec_session_private_data(sess, NULL);
- return ret;
+ return cn9k_ipsec_session_create(device, &conf->ipsec,
+ conf->crypto_xform, priv);
}
static int
-cn9k_sec_session_destroy(void *device __rte_unused,
- struct rte_security_session *sess)
+cn9k_sec_session_destroy(void *device __rte_unused, void *sess)
{
struct roc_ie_on_outb_sa *out_sa;
struct cn9k_sec_session *priv;
- struct rte_mempool *sess_mp;
struct roc_ie_on_sa_ctl *ctl;
struct cn9k_ipsec_sa *sa;
- priv = get_sec_session_private_data(sess);
+ priv = sess;
if (priv == NULL)
return 0;
@@ -590,13 +565,8 @@ cn9k_sec_session_destroy(void *device __rte_unused,
rte_io_wmb();
- sess_mp = rte_mempool_from_obj(priv);
-
memset(priv, 0, sizeof(*priv));
- set_sec_session_private_data(sess, NULL);
- rte_mempool_put(sess_mp, priv);
-
return 0;
}
diff --git a/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c b/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
index dfa72f3f93..176f1a27a0 100644
--- a/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
+++ b/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
@@ -1358,8 +1358,7 @@ build_sec_fd(struct rte_crypto_op *op,
op->sym->session, cryptodev_driver_id);
#ifdef RTE_LIB_SECURITY
else if (op->sess_type == RTE_CRYPTO_OP_SECURITY_SESSION)
- sess = (dpaa2_sec_session *)get_sec_session_private_data(
- op->sym->sec_session);
+ sess = (dpaa2_sec_session *)(op->sym->sec_session);
#endif
else
return -ENOTSUP;
@@ -1532,7 +1531,7 @@ sec_simple_fd_to_mbuf(const struct qbman_fd *fd)
struct rte_crypto_op *op;
uint16_t len = DPAA2_GET_FD_LEN(fd);
int16_t diff = 0;
- dpaa2_sec_session *sess_priv __rte_unused;
+ dpaa2_sec_session *sess_priv;
struct rte_mbuf *mbuf = DPAA2_INLINE_MBUF_FROM_BUF(
DPAA2_IOVA_TO_VADDR(DPAA2_GET_FD_ADDR(fd)),
@@ -1545,8 +1544,7 @@ sec_simple_fd_to_mbuf(const struct qbman_fd *fd)
mbuf->buf_iova = op->sym->aead.digest.phys_addr;
op->sym->aead.digest.phys_addr = 0L;
- sess_priv = (dpaa2_sec_session *)get_sec_session_private_data(
- op->sym->sec_session);
+ sess_priv = (dpaa2_sec_session *)(op->sym->sec_session);
if (sess_priv->dir == DIR_ENC)
mbuf->data_off += SEC_FLC_DHR_OUTBOUND;
else
@@ -3395,63 +3393,44 @@ dpaa2_sec_set_pdcp_session(struct rte_cryptodev *dev,
static int
dpaa2_sec_security_session_create(void *dev,
struct rte_security_session_conf *conf,
- struct rte_security_session *sess,
- struct rte_mempool *mempool)
+ void *sess)
{
- void *sess_private_data;
struct rte_cryptodev *cdev = (struct rte_cryptodev *)dev;
int ret;
- if (rte_mempool_get(mempool, &sess_private_data)) {
- DPAA2_SEC_ERR("Couldn't get object from session mempool");
- return -ENOMEM;
- }
-
switch (conf->protocol) {
case RTE_SECURITY_PROTOCOL_IPSEC:
- ret = dpaa2_sec_set_ipsec_session(cdev, conf,
- sess_private_data);
+ ret = dpaa2_sec_set_ipsec_session(cdev, conf, sess);
break;
case RTE_SECURITY_PROTOCOL_MACSEC:
return -ENOTSUP;
case RTE_SECURITY_PROTOCOL_PDCP:
- ret = dpaa2_sec_set_pdcp_session(cdev, conf,
- sess_private_data);
+ ret = dpaa2_sec_set_pdcp_session(cdev, conf, sess);
break;
default:
return -EINVAL;
}
if (ret != 0) {
DPAA2_SEC_ERR("Failed to configure session parameters");
- /* Return session to mempool */
- rte_mempool_put(mempool, sess_private_data);
return ret;
}
- set_sec_session_private_data(sess, sess_private_data);
-
return ret;
}
/** Clear the memory of session so it doesn't leave key material behind */
static int
-dpaa2_sec_security_session_destroy(void *dev __rte_unused,
- struct rte_security_session *sess)
+dpaa2_sec_security_session_destroy(void *dev __rte_unused, void *sess)
{
PMD_INIT_FUNC_TRACE();
- void *sess_priv = get_sec_session_private_data(sess);
- dpaa2_sec_session *s = (dpaa2_sec_session *)sess_priv;
-
- if (sess_priv) {
- struct rte_mempool *sess_mp = rte_mempool_from_obj(sess_priv);
+ dpaa2_sec_session *s = (dpaa2_sec_session *)sess;
+ if (sess) {
rte_free(s->ctxt);
rte_free(s->cipher_key.data);
rte_free(s->auth_key.data);
memset(s, 0, sizeof(dpaa2_sec_session));
- set_sec_session_private_data(sess, NULL);
- rte_mempool_put(sess_mp, sess_priv);
}
return 0;
}
diff --git a/drivers/crypto/dpaa_sec/dpaa_sec.c b/drivers/crypto/dpaa_sec/dpaa_sec.c
index d5aa2748d6..832b6e64ec 100644
--- a/drivers/crypto/dpaa_sec/dpaa_sec.c
+++ b/drivers/crypto/dpaa_sec/dpaa_sec.c
@@ -1793,8 +1793,7 @@ dpaa_sec_enqueue_burst(void *qp, struct rte_crypto_op **ops,
#ifdef RTE_LIB_SECURITY
case RTE_CRYPTO_OP_SECURITY_SESSION:
ses = (dpaa_sec_session *)
- get_sec_session_private_data(
- op->sym->sec_session);
+ (op->sym->sec_session);
break;
#endif
default:
@@ -2572,7 +2571,6 @@ static inline void
free_session_memory(struct rte_cryptodev *dev, dpaa_sec_session *s)
{
struct dpaa_sec_dev_private *qi = dev->data->dev_private;
- struct rte_mempool *sess_mp = rte_mempool_from_obj((void *)s);
uint8_t i;
for (i = 0; i < MAX_DPAA_CORES; i++) {
@@ -2582,7 +2580,6 @@ free_session_memory(struct rte_cryptodev *dev, dpaa_sec_session *s)
s->qp[i] = NULL;
}
free_session_data(s);
- rte_mempool_put(sess_mp, (void *)s);
}
/** Clear the memory of session so it doesn't leave key material behind */
@@ -3117,26 +3114,17 @@ dpaa_sec_set_pdcp_session(struct rte_cryptodev *dev,
static int
dpaa_sec_security_session_create(void *dev,
struct rte_security_session_conf *conf,
- struct rte_security_session *sess,
- struct rte_mempool *mempool)
+ void *sess)
{
- void *sess_private_data;
struct rte_cryptodev *cdev = (struct rte_cryptodev *)dev;
int ret;
- if (rte_mempool_get(mempool, &sess_private_data)) {
- DPAA_SEC_ERR("Couldn't get object from session mempool");
- return -ENOMEM;
- }
-
switch (conf->protocol) {
case RTE_SECURITY_PROTOCOL_IPSEC:
- ret = dpaa_sec_set_ipsec_session(cdev, conf,
- sess_private_data);
+ ret = dpaa_sec_set_ipsec_session(cdev, conf, sess);
break;
case RTE_SECURITY_PROTOCOL_PDCP:
- ret = dpaa_sec_set_pdcp_session(cdev, conf,
- sess_private_data);
+ ret = dpaa_sec_set_pdcp_session(cdev, conf, sess);
break;
case RTE_SECURITY_PROTOCOL_MACSEC:
return -ENOTSUP;
@@ -3145,29 +3133,21 @@ dpaa_sec_security_session_create(void *dev,
}
if (ret != 0) {
DPAA_SEC_ERR("failed to configure session parameters");
- /* Return session to mempool */
- rte_mempool_put(mempool, sess_private_data);
return ret;
}
- set_sec_session_private_data(sess, sess_private_data);
-
return ret;
}
/** Clear the memory of session so it doesn't leave key material behind */
static int
-dpaa_sec_security_session_destroy(void *dev __rte_unused,
- struct rte_security_session *sess)
+dpaa_sec_security_session_destroy(void *dev __rte_unused, void *sess)
{
PMD_INIT_FUNC_TRACE();
- void *sess_priv = get_sec_session_private_data(sess);
- dpaa_sec_session *s = (dpaa_sec_session *)sess_priv;
+ dpaa_sec_session *s = (dpaa_sec_session *)sess;
- if (sess_priv) {
+ if (sess)
free_session_memory((struct rte_cryptodev *)dev, s);
- set_sec_session_private_data(sess, NULL);
- }
return 0;
}
#endif
diff --git a/drivers/crypto/mvsam/rte_mrvl_pmd.c b/drivers/crypto/mvsam/rte_mrvl_pmd.c
index a72642a772..245a4ad353 100644
--- a/drivers/crypto/mvsam/rte_mrvl_pmd.c
+++ b/drivers/crypto/mvsam/rte_mrvl_pmd.c
@@ -773,8 +773,7 @@ mrvl_request_prepare_sec(struct sam_cio_ipsec_params *request,
return -EINVAL;
}
- sess = (struct mrvl_crypto_session *)get_sec_session_private_data(
- op->sym->sec_session);
+ sess = (struct mrvl_crypto_session *)(op->sym->sec_session);
if (unlikely(sess == NULL)) {
MRVL_LOG(ERR, "Session was not created for this device! %d",
cryptodev_driver_id);
diff --git a/drivers/crypto/mvsam/rte_mrvl_pmd_ops.c b/drivers/crypto/mvsam/rte_mrvl_pmd_ops.c
index 3064b1f136..e04a2c88c7 100644
--- a/drivers/crypto/mvsam/rte_mrvl_pmd_ops.c
+++ b/drivers/crypto/mvsam/rte_mrvl_pmd_ops.c
@@ -913,16 +913,12 @@ mrvl_crypto_pmd_security_session_create(__rte_unused void *dev,
/** Clear the memory of session so it doesn't leave key material behind */
static int
-mrvl_crypto_pmd_security_session_destroy(void *dev __rte_unused,
- struct rte_security_session *sess)
+mrvl_crypto_pmd_security_session_destroy(void *dev __rte_unused, void *sess)
{
- void *sess_priv = get_sec_session_private_data(sess);
-
/* Zero out the whole structure */
- if (sess_priv) {
+ if (sess) {
struct mrvl_crypto_session *mrvl_sess =
(struct mrvl_crypto_session *)sess_priv;
- struct rte_mempool *sess_mp = rte_mempool_from_obj(sess_priv);
if (mrvl_sess->sam_sess &&
sam_session_destroy(mrvl_sess->sam_sess) < 0) {
@@ -932,9 +928,6 @@ mrvl_crypto_pmd_security_session_destroy(void *dev __rte_unused,
rte_free(mrvl_sess->sam_sess_params.cipher_key);
rte_free(mrvl_sess->sam_sess_params.auth_key);
rte_free(mrvl_sess->sam_sess_params.cipher_iv);
- memset(sess, 0, sizeof(struct rte_security_session));
- set_sec_session_private_data(sess, NULL);
- rte_mempool_put(sess_mp, sess_priv);
}
return 0;
}
diff --git a/drivers/crypto/octeontx2/otx2_cryptodev_ops.c b/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
index 37fad11d91..7b744cd4b4 100644
--- a/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
+++ b/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
@@ -702,7 +702,7 @@ otx2_cpt_enqueue_sec(struct otx2_cpt_qp *qp, struct rte_crypto_op *op,
uint8_t esn;
int ret;
- priv = get_sec_session_private_data(op->sym->sec_session);
+ priv = (struct otx2_sec_session *)(op->sym->sec_session);
sess = &priv->ipsec.lp;
sa = &sess->in_sa;
diff --git a/drivers/crypto/octeontx2/otx2_cryptodev_sec.c b/drivers/crypto/octeontx2/otx2_cryptodev_sec.c
index a5db40047d..56900e3187 100644
--- a/drivers/crypto/octeontx2/otx2_cryptodev_sec.c
+++ b/drivers/crypto/octeontx2/otx2_cryptodev_sec.c
@@ -203,7 +203,7 @@ static int
crypto_sec_ipsec_outb_session_create(struct rte_cryptodev *crypto_dev,
struct rte_security_ipsec_xform *ipsec,
struct rte_crypto_sym_xform *crypto_xform,
- struct rte_security_session *sec_sess)
+ struct otx2_sec_session *sess)
{
struct rte_crypto_sym_xform *auth_xform, *cipher_xform;
struct otx2_ipsec_po_ip_template *template = NULL;
@@ -212,13 +212,11 @@ crypto_sec_ipsec_outb_session_create(struct rte_cryptodev *crypto_dev,
struct otx2_ipsec_po_sa_ctl *ctl;
int cipher_key_len, auth_key_len;
struct otx2_ipsec_po_out_sa *sa;
- struct otx2_sec_session *sess;
struct otx2_cpt_inst_s inst;
struct rte_ipv6_hdr *ip6;
struct rte_ipv4_hdr *ip;
int ret, ctx_len;
- sess = get_sec_session_private_data(sec_sess);
sess->ipsec.dir = RTE_SECURITY_IPSEC_SA_DIR_EGRESS;
lp = &sess->ipsec.lp;
@@ -398,7 +396,7 @@ static int
crypto_sec_ipsec_inb_session_create(struct rte_cryptodev *crypto_dev,
struct rte_security_ipsec_xform *ipsec,
struct rte_crypto_sym_xform *crypto_xform,
- struct rte_security_session *sec_sess)
+ struct otx2_sec_session *sess)
{
struct rte_crypto_sym_xform *auth_xform, *cipher_xform;
const uint8_t *cipher_key, *auth_key;
@@ -406,11 +404,9 @@ crypto_sec_ipsec_inb_session_create(struct rte_cryptodev *crypto_dev,
struct otx2_ipsec_po_sa_ctl *ctl;
int cipher_key_len, auth_key_len;
struct otx2_ipsec_po_in_sa *sa;
- struct otx2_sec_session *sess;
struct otx2_cpt_inst_s inst;
int ret;
- sess = get_sec_session_private_data(sec_sess);
sess->ipsec.dir = RTE_SECURITY_IPSEC_SA_DIR_INGRESS;
lp = &sess->ipsec.lp;
@@ -512,7 +508,7 @@ static int
crypto_sec_ipsec_session_create(struct rte_cryptodev *crypto_dev,
struct rte_security_ipsec_xform *ipsec,
struct rte_crypto_sym_xform *crypto_xform,
- struct rte_security_session *sess)
+ struct otx2_sec_session *sess)
{
int ret;
@@ -536,10 +532,9 @@ crypto_sec_ipsec_session_create(struct rte_cryptodev *crypto_dev,
static int
otx2_crypto_sec_session_create(void *device,
struct rte_security_session_conf *conf,
- struct rte_security_session *sess,
- struct rte_mempool *mempool)
+ void *sess)
{
- struct otx2_sec_session *priv;
+ struct otx2_sec_session *priv = sess;
int ret;
if (conf->action_type != RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL)
@@ -548,51 +543,25 @@ otx2_crypto_sec_session_create(void *device,
if (rte_security_dynfield_register() < 0)
return -rte_errno;
- if (rte_mempool_get(mempool, (void **)&priv)) {
- otx2_err("Could not allocate security session private data");
- return -ENOMEM;
- }
-
- set_sec_session_private_data(sess, priv);
-
priv->userdata = conf->userdata;
if (conf->protocol == RTE_SECURITY_PROTOCOL_IPSEC)
ret = crypto_sec_ipsec_session_create(device, &conf->ipsec,
conf->crypto_xform,
- sess);
+ priv);
else
ret = -ENOTSUP;
- if (ret)
- goto mempool_put;
-
- return 0;
-
-mempool_put:
- rte_mempool_put(mempool, priv);
- set_sec_session_private_data(sess, NULL);
return ret;
}
static int
-otx2_crypto_sec_session_destroy(void *device __rte_unused,
- struct rte_security_session *sess)
+otx2_crypto_sec_session_destroy(void *device __rte_unused, void *sess)
{
- struct otx2_sec_session *priv;
- struct rte_mempool *sess_mp;
+ struct otx2_sec_session *priv = sess;
- priv = get_sec_session_private_data(sess);
-
- if (priv == NULL)
- return 0;
-
- sess_mp = rte_mempool_from_obj(priv);
-
- memset(priv, 0, sizeof(*priv));
-
- set_sec_session_private_data(sess, NULL);
- rte_mempool_put(sess_mp, priv);
+ if (priv)
+ memset(priv, 0, sizeof(*priv));
return 0;
}
@@ -604,8 +573,7 @@ otx2_crypto_sec_session_get_size(void *device __rte_unused)
}
static int
-otx2_crypto_sec_set_pkt_mdata(void *device __rte_unused,
- struct rte_security_session *session,
+otx2_crypto_sec_set_pkt_mdata(void *device __rte_unused, void *session,
struct rte_mbuf *m, void *params __rte_unused)
{
/* Set security session as the pkt metadata */
diff --git a/drivers/crypto/qat/qat_sym.c b/drivers/crypto/qat/qat_sym.c
index 93b257522b..fbb17e61ff 100644
--- a/drivers/crypto/qat/qat_sym.c
+++ b/drivers/crypto/qat/qat_sym.c
@@ -250,8 +250,7 @@ qat_sym_build_request(void *in_op, uint8_t *out_msg,
op->sym->session, qat_sym_driver_id);
#ifdef RTE_LIB_SECURITY
} else {
- ctx = (struct qat_sym_session *)get_sec_session_private_data(
- op->sym->sec_session);
+ ctx = (struct qat_sym_session *)(op->sym->sec_session);
if (likely(ctx)) {
if (unlikely(ctx->bpi_ctx == NULL)) {
QAT_DP_LOG(ERR, "QAT PMD only supports security"
diff --git a/drivers/crypto/qat/qat_sym.h b/drivers/crypto/qat/qat_sym.h
index e3ec7f0de4..8904aabd3d 100644
--- a/drivers/crypto/qat/qat_sym.h
+++ b/drivers/crypto/qat/qat_sym.h
@@ -202,9 +202,7 @@ qat_sym_preprocess_requests(void **ops, uint16_t nb_ops)
op = (struct rte_crypto_op *)ops[i];
if (op->sess_type == RTE_CRYPTO_OP_SECURITY_SESSION) {
- ctx = (struct qat_sym_session *)
- get_sec_session_private_data(
- op->sym->sec_session);
+ ctx = (struct qat_sym_session *)(op->sym->sec_session);
if (ctx == NULL || ctx->bpi_ctx == NULL)
continue;
@@ -243,9 +241,7 @@ qat_sym_process_response(void **op, uint8_t *resp, void *op_cookie)
* Assuming at this point that if it's a security
* op, that this is for DOCSIS
*/
- sess = (struct qat_sym_session *)
- get_sec_session_private_data(
- rx_op->sym->sec_session);
+ sess = (struct qat_sym_session *)(rx_op->sym->sec_session);
is_docsis_sec = 1;
} else
#endif
diff --git a/drivers/crypto/qat/qat_sym_session.c b/drivers/crypto/qat/qat_sym_session.c
index 3f2f6736fc..2a22347c7f 100644
--- a/drivers/crypto/qat/qat_sym_session.c
+++ b/drivers/crypto/qat/qat_sym_session.c
@@ -2283,10 +2283,8 @@ qat_sec_session_set_docsis_parameters(struct rte_cryptodev *dev,
int
qat_security_session_create(void *dev,
struct rte_security_session_conf *conf,
- struct rte_security_session *sess,
- struct rte_mempool *mempool)
+ void *sess_private_data)
{
- void *sess_private_data;
struct rte_cryptodev *cdev = (struct rte_cryptodev *)dev;
int ret;
@@ -2296,40 +2294,25 @@ qat_security_session_create(void *dev,
return -EINVAL;
}
- if (rte_mempool_get(mempool, &sess_private_data)) {
- QAT_LOG(ERR, "Couldn't get object from session mempool");
- return -ENOMEM;
- }
-
ret = qat_sec_session_set_docsis_parameters(cdev, conf,
sess_private_data);
if (ret != 0) {
QAT_LOG(ERR, "Failed to configure session parameters");
- /* Return session to mempool */
- rte_mempool_put(mempool, sess_private_data);
return ret;
}
- set_sec_session_private_data(sess, sess_private_data);
-
return ret;
}
int
-qat_security_session_destroy(void *dev __rte_unused,
- struct rte_security_session *sess)
+qat_security_session_destroy(void *dev __rte_unused, void *sess_priv)
{
- void *sess_priv = get_sec_session_private_data(sess);
struct qat_sym_session *s = (struct qat_sym_session *)sess_priv;
if (sess_priv) {
if (s->bpi_ctx)
bpi_cipher_ctx_free(s->bpi_ctx);
memset(s, 0, qat_sym_session_get_private_size(dev));
- struct rte_mempool *sess_mp = rte_mempool_from_obj(sess_priv);
-
- set_sec_session_private_data(sess, NULL);
- rte_mempool_put(sess_mp, sess_priv);
}
return 0;
}
diff --git a/drivers/crypto/qat/qat_sym_session.h b/drivers/crypto/qat/qat_sym_session.h
index 6ebc176729..7fcc1d6f7b 100644
--- a/drivers/crypto/qat/qat_sym_session.h
+++ b/drivers/crypto/qat/qat_sym_session.h
@@ -166,9 +166,9 @@ qat_sym_validate_zuc_key(int key_len, enum icp_qat_hw_cipher_algo *alg);
#ifdef RTE_LIB_SECURITY
int
qat_security_session_create(void *dev, struct rte_security_session_conf *conf,
- struct rte_security_session *sess, struct rte_mempool *mempool);
+ void *sess);
int
-qat_security_session_destroy(void *dev, struct rte_security_session *sess);
+qat_security_session_destroy(void *dev, void *sess);
#endif
#endif /* _QAT_SYM_SESSION_H_ */
diff --git a/drivers/net/ixgbe/ixgbe_ipsec.c b/drivers/net/ixgbe/ixgbe_ipsec.c
index e45c5501e6..cd54a3beee 100644
--- a/drivers/net/ixgbe/ixgbe_ipsec.c
+++ b/drivers/net/ixgbe/ixgbe_ipsec.c
@@ -369,24 +369,17 @@ ixgbe_crypto_remove_sa(struct rte_eth_dev *dev,
static int
ixgbe_crypto_create_session(void *device,
struct rte_security_session_conf *conf,
- struct rte_security_session *session,
- struct rte_mempool *mempool)
+ void *session)
{
struct rte_eth_dev *eth_dev = (struct rte_eth_dev *)device;
- struct ixgbe_crypto_session *ic_session = NULL;
+ struct ixgbe_crypto_session *ic_session = session;
struct rte_crypto_aead_xform *aead_xform;
struct rte_eth_conf *dev_conf = ð_dev->data->dev_conf;
- if (rte_mempool_get(mempool, (void **)&ic_session)) {
- PMD_DRV_LOG(ERR, "Cannot get object from ic_session mempool");
- return -ENOMEM;
- }
-
if (conf->crypto_xform->type != RTE_CRYPTO_SYM_XFORM_AEAD ||
conf->crypto_xform->aead.algo !=
RTE_CRYPTO_AEAD_AES_GCM) {
PMD_DRV_LOG(ERR, "Unsupported crypto transformation mode\n");
- rte_mempool_put(mempool, (void *)ic_session);
return -ENOTSUP;
}
aead_xform = &conf->crypto_xform->aead;
@@ -396,7 +389,6 @@ ixgbe_crypto_create_session(void *device,
ic_session->op = IXGBE_OP_AUTHENTICATED_DECRYPTION;
} else {
PMD_DRV_LOG(ERR, "IPsec decryption not enabled\n");
- rte_mempool_put(mempool, (void *)ic_session);
return -ENOTSUP;
}
} else {
@@ -404,7 +396,6 @@ ixgbe_crypto_create_session(void *device,
ic_session->op = IXGBE_OP_AUTHENTICATED_ENCRYPTION;
} else {
PMD_DRV_LOG(ERR, "IPsec encryption not enabled\n");
- rte_mempool_put(mempool, (void *)ic_session);
return -ENOTSUP;
}
}
@@ -416,12 +407,9 @@ ixgbe_crypto_create_session(void *device,
ic_session->spi = conf->ipsec.spi;
ic_session->dev = eth_dev;
- set_sec_session_private_data(session, ic_session);
-
if (ic_session->op == IXGBE_OP_AUTHENTICATED_ENCRYPTION) {
if (ixgbe_crypto_add_sa(ic_session)) {
PMD_DRV_LOG(ERR, "Failed to add SA\n");
- rte_mempool_put(mempool, (void *)ic_session);
return -EPERM;
}
}
@@ -436,14 +424,11 @@ ixgbe_crypto_session_get_size(__rte_unused void *device)
}
static int
-ixgbe_crypto_remove_session(void *device,
- struct rte_security_session *session)
+ixgbe_crypto_remove_session(void *device, void *session)
{
struct rte_eth_dev *eth_dev = device;
struct ixgbe_crypto_session *ic_session =
- (struct ixgbe_crypto_session *)
- get_sec_session_private_data(session);
- struct rte_mempool *mempool = rte_mempool_from_obj(ic_session);
+ (struct ixgbe_crypto_session *)session;
if (eth_dev != ic_session->dev) {
PMD_DRV_LOG(ERR, "Session not bound to this device\n");
@@ -455,8 +440,6 @@ ixgbe_crypto_remove_session(void *device,
return -EFAULT;
}
- rte_mempool_put(mempool, (void *)ic_session);
-
return 0;
}
@@ -476,12 +459,11 @@ ixgbe_crypto_compute_pad_len(struct rte_mbuf *m)
}
static int
-ixgbe_crypto_update_mb(void *device __rte_unused,
- struct rte_security_session *session,
+ixgbe_crypto_update_mb(void *device __rte_unused, void *session,
struct rte_mbuf *m, void *params __rte_unused)
{
- struct ixgbe_crypto_session *ic_session =
- get_sec_session_private_data(session);
+ struct ixgbe_crypto_session *ic_session = session;
+
if (ic_session->op == IXGBE_OP_AUTHENTICATED_ENCRYPTION) {
union ixgbe_crypto_tx_desc_md *mdata =
(union ixgbe_crypto_tx_desc_md *)
@@ -685,8 +667,10 @@ ixgbe_crypto_add_ingress_sa_from_flow(const void *sess,
const void *ip_spec,
uint8_t is_ipv6)
{
- struct ixgbe_crypto_session *ic_session
- = get_sec_session_private_data(sess);
+ uint64_t sess_ptr = (uint64_t)sess;
+ struct ixgbe_crypto_session *ic_session =
+ (struct ixgbe_crypto_session *)sess_ptr;
+ /* TODO: A proper fix need to be added to remove above typecasting. */
if (ic_session->op == IXGBE_OP_AUTHENTICATED_DECRYPTION) {
if (is_ipv6) {
diff --git a/drivers/net/meson.build b/drivers/net/meson.build
index bcf488f203..7a09f7183d 100644
--- a/drivers/net/meson.build
+++ b/drivers/net/meson.build
@@ -12,7 +12,7 @@ drivers = [
'bnx2x',
'bnxt',
'bonding',
- 'cnxk',
+# 'cnxk',
'cxgbe',
'dpaa',
'dpaa2',
diff --git a/drivers/net/octeontx2/otx2_ethdev_sec.c b/drivers/net/octeontx2/otx2_ethdev_sec.c
index c2a36883cb..ef851fe52c 100644
--- a/drivers/net/octeontx2/otx2_ethdev_sec.c
+++ b/drivers/net/octeontx2/otx2_ethdev_sec.c
@@ -350,7 +350,7 @@ static int
eth_sec_ipsec_out_sess_create(struct rte_eth_dev *eth_dev,
struct rte_security_ipsec_xform *ipsec,
struct rte_crypto_sym_xform *crypto_xform,
- struct rte_security_session *sec_sess)
+ struct otx2_sec_session *sec_sess)
{
struct rte_crypto_sym_xform *auth_xform, *cipher_xform;
struct otx2_sec_session_ipsec_ip *sess;
@@ -363,7 +363,7 @@ eth_sec_ipsec_out_sess_create(struct rte_eth_dev *eth_dev,
struct otx2_cpt_inst_s inst;
struct otx2_cpt_qp *qp;
- priv = get_sec_session_private_data(sec_sess);
+ priv = sec_sess;
priv->ipsec.dir = RTE_SECURITY_IPSEC_SA_DIR_EGRESS;
sess = &priv->ipsec.ip;
@@ -468,7 +468,7 @@ static int
eth_sec_ipsec_in_sess_create(struct rte_eth_dev *eth_dev,
struct rte_security_ipsec_xform *ipsec,
struct rte_crypto_sym_xform *crypto_xform,
- struct rte_security_session *sec_sess)
+ struct otx2_sec_session *sec_sess)
{
struct rte_crypto_sym_xform *auth_xform, *cipher_xform;
struct otx2_eth_dev *dev = otx2_eth_pmd_priv(eth_dev);
@@ -495,7 +495,7 @@ eth_sec_ipsec_in_sess_create(struct rte_eth_dev *eth_dev,
ctl = &sa->ctl;
- priv = get_sec_session_private_data(sec_sess);
+ priv = sec_sess;
priv->ipsec.dir = RTE_SECURITY_IPSEC_SA_DIR_INGRESS;
sess = &priv->ipsec.ip;
@@ -619,7 +619,7 @@ static int
eth_sec_ipsec_sess_create(struct rte_eth_dev *eth_dev,
struct rte_security_ipsec_xform *ipsec,
struct rte_crypto_sym_xform *crypto_xform,
- struct rte_security_session *sess)
+ struct otx2_sec_session *sess)
{
int ret;
@@ -638,22 +638,14 @@ eth_sec_ipsec_sess_create(struct rte_eth_dev *eth_dev,
static int
otx2_eth_sec_session_create(void *device,
struct rte_security_session_conf *conf,
- struct rte_security_session *sess,
- struct rte_mempool *mempool)
+ void *sess)
{
- struct otx2_sec_session *priv;
+ struct otx2_sec_session *priv = sess;
int ret;
if (conf->action_type != RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL)
return -ENOTSUP;
- if (rte_mempool_get(mempool, (void **)&priv)) {
- otx2_err("Could not allocate security session private data");
- return -ENOMEM;
- }
-
- set_sec_session_private_data(sess, priv);
-
/*
* Save userdata provided by the application. For ingress packets, this
* could be used to identify the SA.
@@ -663,19 +655,14 @@ otx2_eth_sec_session_create(void *device,
if (conf->protocol == RTE_SECURITY_PROTOCOL_IPSEC)
ret = eth_sec_ipsec_sess_create(device, &conf->ipsec,
conf->crypto_xform,
- sess);
+ priv);
else
ret = -ENOTSUP;
if (ret)
- goto mempool_put;
+ return ret;
return 0;
-
-mempool_put:
- rte_mempool_put(mempool, priv);
- set_sec_session_private_data(sess, NULL);
- return ret;
}
static void
@@ -688,20 +675,14 @@ otx2_eth_sec_free_anti_replay(struct otx2_ipsec_fp_in_sa *sa)
}
static int
-otx2_eth_sec_session_destroy(void *device,
- struct rte_security_session *sess)
+otx2_eth_sec_session_destroy(void *device, void *sess)
{
struct otx2_eth_dev *dev = otx2_eth_pmd_priv(device);
struct otx2_sec_session_ipsec_ip *sess_ip;
struct otx2_ipsec_fp_in_sa *sa;
- struct otx2_sec_session *priv;
- struct rte_mempool *sess_mp;
+ struct otx2_sec_session *priv = sess;
int ret;
- priv = get_sec_session_private_data(sess);
- if (priv == NULL)
- return -EINVAL;
-
sess_ip = &priv->ipsec.ip;
if (priv->ipsec.dir == RTE_SECURITY_IPSEC_SA_DIR_INGRESS) {
@@ -727,11 +708,6 @@ otx2_eth_sec_session_destroy(void *device,
return ret;
}
- sess_mp = rte_mempool_from_obj(priv);
-
- set_sec_session_private_data(sess, NULL);
- rte_mempool_put(sess_mp, priv);
-
return 0;
}
@@ -742,9 +718,8 @@ otx2_eth_sec_session_get_size(void *device __rte_unused)
}
static int
-otx2_eth_sec_set_pkt_mdata(void *device __rte_unused,
- struct rte_security_session *session,
- struct rte_mbuf *m, void *params __rte_unused)
+otx2_eth_sec_set_pkt_mdata(void *device __rte_unused, void *session,
+ struct rte_mbuf *m, void *params __rte_unused)
{
/* Set security session as the pkt metadata */
*rte_security_dynfield(m) = (rte_security_dynfield_t)session;
diff --git a/drivers/net/octeontx2/otx2_ethdev_sec_tx.h b/drivers/net/octeontx2/otx2_ethdev_sec_tx.h
index 623a2a841e..9ecb786947 100644
--- a/drivers/net/octeontx2/otx2_ethdev_sec_tx.h
+++ b/drivers/net/octeontx2/otx2_ethdev_sec_tx.h
@@ -54,7 +54,7 @@ otx2_sec_event_tx(uint64_t base, struct rte_event *ev, struct rte_mbuf *m,
struct nix_iova_s nix_iova;
} *sd;
- priv = get_sec_session_private_data((void *)(*rte_security_dynfield(m)));
+ priv = (void *)(*rte_security_dynfield(m));
sess = &priv->ipsec.ip;
sa = &sess->out_sa;
diff --git a/drivers/net/txgbe/txgbe_ipsec.c b/drivers/net/txgbe/txgbe_ipsec.c
index ccd747973b..444da5b8f3 100644
--- a/drivers/net/txgbe/txgbe_ipsec.c
+++ b/drivers/net/txgbe/txgbe_ipsec.c
@@ -349,24 +349,17 @@ txgbe_crypto_remove_sa(struct rte_eth_dev *dev,
static int
txgbe_crypto_create_session(void *device,
struct rte_security_session_conf *conf,
- struct rte_security_session *session,
- struct rte_mempool *mempool)
+ void *session)
{
struct rte_eth_dev *eth_dev = (struct rte_eth_dev *)device;
- struct txgbe_crypto_session *ic_session = NULL;
+ struct txgbe_crypto_session *ic_session = session;
struct rte_crypto_aead_xform *aead_xform;
struct rte_eth_conf *dev_conf = ð_dev->data->dev_conf;
- if (rte_mempool_get(mempool, (void **)&ic_session)) {
- PMD_DRV_LOG(ERR, "Cannot get object from ic_session mempool");
- return -ENOMEM;
- }
-
if (conf->crypto_xform->type != RTE_CRYPTO_SYM_XFORM_AEAD ||
conf->crypto_xform->aead.algo !=
RTE_CRYPTO_AEAD_AES_GCM) {
PMD_DRV_LOG(ERR, "Unsupported crypto transformation mode\n");
- rte_mempool_put(mempool, (void *)ic_session);
return -ENOTSUP;
}
aead_xform = &conf->crypto_xform->aead;
@@ -376,7 +369,6 @@ txgbe_crypto_create_session(void *device,
ic_session->op = TXGBE_OP_AUTHENTICATED_DECRYPTION;
} else {
PMD_DRV_LOG(ERR, "IPsec decryption not enabled\n");
- rte_mempool_put(mempool, (void *)ic_session);
return -ENOTSUP;
}
} else {
@@ -384,7 +376,6 @@ txgbe_crypto_create_session(void *device,
ic_session->op = TXGBE_OP_AUTHENTICATED_ENCRYPTION;
} else {
PMD_DRV_LOG(ERR, "IPsec encryption not enabled\n");
- rte_mempool_put(mempool, (void *)ic_session);
return -ENOTSUP;
}
}
@@ -396,12 +387,9 @@ txgbe_crypto_create_session(void *device,
ic_session->spi = conf->ipsec.spi;
ic_session->dev = eth_dev;
- set_sec_session_private_data(session, ic_session);
-
if (ic_session->op == TXGBE_OP_AUTHENTICATED_ENCRYPTION) {
if (txgbe_crypto_add_sa(ic_session)) {
PMD_DRV_LOG(ERR, "Failed to add SA\n");
- rte_mempool_put(mempool, (void *)ic_session);
return -EPERM;
}
}
@@ -416,14 +404,11 @@ txgbe_crypto_session_get_size(__rte_unused void *device)
}
static int
-txgbe_crypto_remove_session(void *device,
- struct rte_security_session *session)
+txgbe_crypto_remove_session(void *device, void *session)
{
struct rte_eth_dev *eth_dev = device;
struct txgbe_crypto_session *ic_session =
- (struct txgbe_crypto_session *)
- get_sec_session_private_data(session);
- struct rte_mempool *mempool = rte_mempool_from_obj(ic_session);
+ (struct txgbe_crypto_session *)session;
if (eth_dev != ic_session->dev) {
PMD_DRV_LOG(ERR, "Session not bound to this device\n");
@@ -435,8 +420,6 @@ txgbe_crypto_remove_session(void *device,
return -EFAULT;
}
- rte_mempool_put(mempool, (void *)ic_session);
-
return 0;
}
@@ -456,12 +439,11 @@ txgbe_crypto_compute_pad_len(struct rte_mbuf *m)
}
static int
-txgbe_crypto_update_mb(void *device __rte_unused,
- struct rte_security_session *session,
- struct rte_mbuf *m, void *params __rte_unused)
+txgbe_crypto_update_mb(void *device __rte_unused, void *session,
+ struct rte_mbuf *m, void *params __rte_unused)
{
- struct txgbe_crypto_session *ic_session =
- get_sec_session_private_data(session);
+ struct txgbe_crypto_session *ic_session = session;
+
if (ic_session->op == TXGBE_OP_AUTHENTICATED_ENCRYPTION) {
union txgbe_crypto_tx_desc_md *mdata =
(union txgbe_crypto_tx_desc_md *)
@@ -661,8 +643,10 @@ txgbe_crypto_add_ingress_sa_from_flow(const void *sess,
const void *ip_spec,
uint8_t is_ipv6)
{
+ uint64_t sess_ptr = (uint64_t)sess;
struct txgbe_crypto_session *ic_session =
- get_sec_session_private_data(sess);
+ (struct txgbe_crypto_session *)sess_ptr;
+ /* TODO: A proper fix need to be added to remove above typecasting. */
if (ic_session->op == TXGBE_OP_AUTHENTICATED_DECRYPTION) {
if (is_ipv6) {
diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
index 6817139663..03d907cba8 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -117,8 +117,7 @@ create_lookaside_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa,
set_ipsec_conf(sa, &(sess_conf.ipsec));
ips->security.ses = rte_security_session_create(ctx,
- &sess_conf, ipsec_ctx->session_pool,
- ipsec_ctx->session_priv_pool);
+ &sess_conf, ipsec_ctx->session_pool);
if (ips->security.ses == NULL) {
RTE_LOG(ERR, IPSEC,
"SEC Session init failed: err: %d\n", ret);
@@ -199,8 +198,7 @@ create_inline_session(struct socket_ctx *skt_ctx, struct ipsec_sa *sa,
}
ips->security.ses = rte_security_session_create(sec_ctx,
- &sess_conf, skt_ctx->session_pool,
- skt_ctx->session_priv_pool);
+ &sess_conf, skt_ctx->session_pool);
if (ips->security.ses == NULL) {
RTE_LOG(ERR, IPSEC,
"SEC Session init failed: err: %d\n", ret);
@@ -380,8 +378,7 @@ create_inline_session(struct socket_ctx *skt_ctx, struct ipsec_sa *sa,
sess_conf.userdata = (void *) sa;
ips->security.ses = rte_security_session_create(sec_ctx,
- &sess_conf, skt_ctx->session_pool,
- skt_ctx->session_priv_pool);
+ &sess_conf, skt_ctx->session_pool);
if (ips->security.ses == NULL) {
RTE_LOG(ERR, IPSEC,
"SEC Session init failed: err: %d\n", ret);
diff --git a/lib/security/rte_security.c b/lib/security/rte_security.c
index fe81ed3e4c..06560b9cba 100644
--- a/lib/security/rte_security.c
+++ b/lib/security/rte_security.c
@@ -39,35 +39,37 @@ rte_security_dynfield_register(void)
return rte_security_dynfield_offset;
}
-struct rte_security_session *
+void *
rte_security_session_create(struct rte_security_ctx *instance,
struct rte_security_session_conf *conf,
- struct rte_mempool *mp,
- struct rte_mempool *priv_mp)
+ struct rte_mempool *mp)
{
struct rte_security_session *sess = NULL;
RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, session_create, NULL, NULL);
RTE_PTR_OR_ERR_RET(conf, NULL);
RTE_PTR_OR_ERR_RET(mp, NULL);
- RTE_PTR_OR_ERR_RET(priv_mp, NULL);
+
+ if (mp->elt_size < sizeof(struct rte_security_session) +
+ instance->ops->session_get_size(instance->device))
+ return NULL;
if (rte_mempool_get(mp, (void **)&sess))
return NULL;
if (instance->ops->session_create(instance->device, conf,
- sess, priv_mp)) {
+ sess->sess_private_data)) {
rte_mempool_put(mp, (void *)sess);
return NULL;
}
instance->sess_cnt++;
- return sess;
+ return sess->sess_private_data;
}
int
rte_security_session_update(struct rte_security_ctx *instance,
- struct rte_security_session *sess,
+ void *sess,
struct rte_security_session_conf *conf)
{
RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, session_update, -EINVAL,
@@ -88,8 +90,7 @@ rte_security_session_get_size(struct rte_security_ctx *instance)
int
rte_security_session_stats_get(struct rte_security_ctx *instance,
- struct rte_security_session *sess,
- struct rte_security_stats *stats)
+ void *sess, struct rte_security_stats *stats)
{
RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, session_stats_get, -EINVAL,
-ENOTSUP);
@@ -100,9 +101,9 @@ rte_security_session_stats_get(struct rte_security_ctx *instance,
}
int
-rte_security_session_destroy(struct rte_security_ctx *instance,
- struct rte_security_session *sess)
+rte_security_session_destroy(struct rte_security_ctx *instance, void *sess)
{
+ struct rte_security_session *s;
int ret;
RTE_PTR_CHAIN3_OR_ERR_RET(instance, ops, session_destroy, -EINVAL,
@@ -113,7 +114,8 @@ rte_security_session_destroy(struct rte_security_ctx *instance,
if (ret != 0)
return ret;
- rte_mempool_put(rte_mempool_from_obj(sess), (void *)sess);
+ s = container_of(sess, struct rte_security_session, sess_private_data);
+ rte_mempool_put(rte_mempool_from_obj(s), (void *)s);
if (instance->sess_cnt)
instance->sess_cnt--;
@@ -123,7 +125,7 @@ rte_security_session_destroy(struct rte_security_ctx *instance,
int
__rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
- struct rte_security_session *sess,
+ void *sess,
struct rte_mbuf *m, void *params)
{
#ifdef RTE_DEBUG
diff --git a/lib/security/rte_security.h b/lib/security/rte_security.h
index c0ea13892e..2c8e78c4c7 100644
--- a/lib/security/rte_security.h
+++ b/lib/security/rte_security.h
@@ -491,10 +491,12 @@ struct rte_security_session_conf {
};
struct rte_security_session {
- void *sess_private_data;
- /**< Private session material */
uint64_t opaque_data;
/**< Opaque user defined data */
+ uint64_t fast_mdata;
+ /**< Fast metadata to be used for inline path */
+ __extension__ void *sess_private_data[0];
+ /**< Private session material */
};
/**
@@ -508,11 +510,10 @@ struct rte_security_session {
* - On success, pointer to session
* - On failure, NULL
*/
-struct rte_security_session *
+void *
rte_security_session_create(struct rte_security_ctx *instance,
struct rte_security_session_conf *conf,
- struct rte_mempool *mp,
- struct rte_mempool *priv_mp);
+ struct rte_mempool *mp);
/**
* Update security session as specified by the session configuration
@@ -527,7 +528,7 @@ rte_security_session_create(struct rte_security_ctx *instance,
__rte_experimental
int
rte_security_session_update(struct rte_security_ctx *instance,
- struct rte_security_session *sess,
+ void *sess,
struct rte_security_session_conf *conf);
/**
@@ -558,7 +559,7 @@ rte_security_session_get_size(struct rte_security_ctx *instance);
*/
int
rte_security_session_destroy(struct rte_security_ctx *instance,
- struct rte_security_session *sess);
+ void *sess);
/** Device-specific metadata field type */
typedef uint64_t rte_security_dynfield_t;
@@ -604,7 +605,7 @@ static inline bool rte_security_dynfield_is_registered(void)
/** Function to call PMD specific function pointer set_pkt_metadata() */
__rte_experimental
extern int __rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
- struct rte_security_session *sess,
+ void *sess,
struct rte_mbuf *m, void *params);
/**
@@ -622,13 +623,13 @@ extern int __rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
*/
static inline int
rte_security_set_pkt_metadata(struct rte_security_ctx *instance,
- struct rte_security_session *sess,
+ void *sess,
struct rte_mbuf *mb, void *params)
{
/* Fast Path */
if (instance->flags & RTE_SEC_CTX_F_FAST_SET_MDATA) {
*rte_security_dynfield(mb) =
- (rte_security_dynfield_t)(sess->sess_private_data);
+ (rte_security_dynfield_t)(sess);
return 0;
}
@@ -678,26 +679,13 @@ rte_security_get_userdata(struct rte_security_ctx *instance, uint64_t md)
*/
static inline int
__rte_security_attach_session(struct rte_crypto_sym_op *sym_op,
- struct rte_security_session *sess)
+ void *sess)
{
sym_op->sec_session = sess;
return 0;
}
-static inline void *
-get_sec_session_private_data(const struct rte_security_session *sess)
-{
- return sess->sess_private_data;
-}
-
-static inline void
-set_sec_session_private_data(struct rte_security_session *sess,
- void *private_data)
-{
- sess->sess_private_data = private_data;
-}
-
/**
* Attach a session to a crypto operation.
* This API is needed only in case of RTE_SECURITY_SESS_CRYPTO_PROTO_OFFLOAD
@@ -708,8 +696,7 @@ set_sec_session_private_data(struct rte_security_session *sess,
* @param sess security session
*/
static inline int
-rte_security_attach_session(struct rte_crypto_op *op,
- struct rte_security_session *sess)
+rte_security_attach_session(struct rte_crypto_op *op, void *sess)
{
if (unlikely(op->type != RTE_CRYPTO_OP_TYPE_SYMMETRIC))
return -EINVAL;
@@ -771,7 +758,7 @@ struct rte_security_stats {
__rte_experimental
int
rte_security_session_stats_get(struct rte_security_ctx *instance,
- struct rte_security_session *sess,
+ void *sess,
struct rte_security_stats *stats);
/**
diff --git a/lib/security/rte_security_driver.h b/lib/security/rte_security_driver.h
index b0253e962e..5a177d72d7 100644
--- a/lib/security/rte_security_driver.h
+++ b/lib/security/rte_security_driver.h
@@ -35,8 +35,7 @@ extern "C" {
*/
typedef int (*security_session_create_t)(void *device,
struct rte_security_session_conf *conf,
- struct rte_security_session *sess,
- struct rte_mempool *mp);
+ void *sess);
/**
* Free driver private session data.
@@ -44,8 +43,7 @@ typedef int (*security_session_create_t)(void *device,
* @param device Crypto/eth device pointer
* @param sess Security session structure
*/
-typedef int (*security_session_destroy_t)(void *device,
- struct rte_security_session *sess);
+typedef int (*security_session_destroy_t)(void *device, void *sess);
/**
* Update driver private session data.
@@ -60,8 +58,7 @@ typedef int (*security_session_destroy_t)(void *device,
* - Returns -ENOTSUP if crypto device does not support the crypto transform.
*/
typedef int (*security_session_update_t)(void *device,
- struct rte_security_session *sess,
- struct rte_security_session_conf *conf);
+ void *sess, struct rte_security_session_conf *conf);
/**
* Get the size of a security session
@@ -86,8 +83,7 @@ typedef unsigned int (*security_session_get_size)(void *device);
* - Returns -EINVAL if session parameters are invalid.
*/
typedef int (*security_session_stats_get_t)(void *device,
- struct rte_security_session *sess,
- struct rte_security_stats *stats);
+ void *sess, struct rte_security_stats *stats);
__rte_internal
int rte_security_dynfield_register(void);
@@ -96,7 +92,7 @@ int rte_security_dynfield_register(void);
* Update the mbuf with provided metadata.
*
* @param device Crypto/eth device pointer
- * @param sess Security session structure
+ * @param sess Security session
* @param mb Packet buffer
* @param params Metadata
*
@@ -105,7 +101,7 @@ int rte_security_dynfield_register(void);
* - Returns -ve value for errors.
*/
typedef int (*security_set_pkt_metadata_t)(void *device,
- struct rte_security_session *sess, struct rte_mbuf *mb,
+ void *sess, struct rte_mbuf *mb,
void *params);
/**
--
2.25.1
^ permalink raw reply [relevance 1%]
* Re: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs
2021-10-13 17:56 5% ` Walker, Benjamin
@ 2021-10-13 18:59 3% ` Thomas Monjalon
2021-10-13 22:48 3% ` Walker, Benjamin
2021-10-14 2:21 4% ` Xia, Chenbo
0 siblings, 2 replies; 200+ results
From: Thomas Monjalon @ 2021-10-13 18:59 UTC (permalink / raw)
To: Harris, James R, Walker, Benjamin
Cc: Liu, Changpeng, Xia, Chenbo, David Marchand, dev, Aaron Conole,
Zawadzki, Tomasz
13/10/2021 19:56, Walker, Benjamin:
> > From: Thomas Monjalon <thomas@monjalon.net>
> >
> > In order to be perfectly clear, all the changes done around this option
> > enable_driver_sdk share the goal of tidying stuff in DPDK so that ABI becomes
> > better manageable.
> > I think that nobody want to annoy the SPDK project.
> > I understand that the changes effectively add troubles, and I am sorry about
> > that. If SPDK and other projects can manage with this change, good.
> > If there is a real blocker, we should discuss what are the options.
> >
> > Thanks for your understanding
>
> I completely understand the desire to make the ABI manageable. If I were in your shoes, I'd be doing the same exact thing. What I don't currently understand is the motivation behind this enable_driver_sdk option. My guess is that it's one of two things.
>
> \1 ABI manageability: You say that's the purpose above, and that was my initial assumption. But wouldn't that necessarily mean, over time, no longer considering the symbols that were defined by the header files as part of the stable ABI?
Absolutely. The idea is that we don't guarantee ABI for the drivers.
> If you still consider these symbols as part of the ABI in shared library builds, then the enable_driver_sdk option does absolutely nothing to improve the ABI situation, so why bother to have it at all? We can't have packaged SPDK relying on symbols in a packaged DPDK that are not part of the official ABI.
> \2 Not supporting out-of-tree drivers: Another option is that you just don't want people writing out of tree drivers.
We don't want complications due to support of out-of-tree drivers,
but we don't want to forbid them.
> You can't just drop it outright because people already do it,
> but you'd like to not support it for shared library builds at least.
I didn't think about it in these terms.
But saying we don't offer compatibility for shared library drivers
is not too far of "no support" indeed.
> So I'd like to really understand which of these two motivated the enable_driver_sdk option . Maybe it's not even one of the two above. If it is #1, then I think maybe we can work with DPDK to define a very small set of out-of-tree driver APIs/ABIs that need to continue to exist in the shared libraries by default. I do think SPDK needs only a very small number. If it's #2, then that's the entire SPDK use case and I'd ask you to reconsider the direction.
Yes I think we need to agree on functions to keep as-is for compatibility.
Waiting for your input please.
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v6 1/5] ethdev: update modify field flow action
@ 2021-10-13 18:45 3% ` Viacheslav Ovsiienko
2021-10-14 12:08 3% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Viacheslav Ovsiienko @ 2021-10-13 18:45 UTC (permalink / raw)
To: dev; +Cc: rasland, matan, shahafs, orika, getelson, thomas
The generic modify field flow action introduced in [1] has
some issues related to the immediate source operand:
- immediate source can be presented either as an unsigned
64-bit integer or pointer to data pattern in memory.
There was no explicit pointer field defined in the union.
- the byte ordering for 64-bit integer was not specified.
Many fields have shorter lengths and byte ordering
is crucial.
- how the bit offset is applied to the immediate source
field was not defined and documented.
- 64-bit integer size is not enough to provide IPv6
addresses.
In order to cover the issues and exclude any ambiguities
the following is done:
- introduce the explicit pointer field
in rte_flow_action_modify_data structure
- replace the 64-bit unsigned integer with 16-byte array
- update the modify field flow action documentation
Appropriate deprecation notice has been removed.
[1] commit 73b68f4c54a0 ("ethdev: introduce generic modify flow action")
Fixes: 2ba49b5f3721 ("doc: announce change to ethdev modify action data")
Signed-off-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
doc/guides/prog_guide/rte_flow.rst | 24 +++++++++++++++++++++++-
doc/guides/rel_notes/deprecation.rst | 4 ----
doc/guides/rel_notes/release_21_11.rst | 7 +++++++
lib/ethdev/rte_flow.h | 16 ++++++++++++----
4 files changed, 42 insertions(+), 9 deletions(-)
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 2b42d5ec8c..b08087511f 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -2835,6 +2835,22 @@ a packet to any other part of it.
``value`` sets an immediate value to be used as a source or points to a
location of the value in memory. It is used instead of ``level`` and ``offset``
for ``RTE_FLOW_FIELD_VALUE`` and ``RTE_FLOW_FIELD_POINTER`` respectively.
+The data in memory should be presented exactly in the same byte order and
+length as in the relevant flow item, i.e. data for field with type
+``RTE_FLOW_FIELD_MAC_DST`` should follow the conventions of ``dst`` field
+in ``rte_flow_item_eth`` structure, with type ``RTE_FLOW_FIELD_IPV6_SRC`` -
+``rte_flow_item_ipv6`` conventions, and so on. If the field size is larger than
+16 bytes the pattern can be provided as pointer only.
+
+The bitfield extracted from the memory being applied as second operation
+parameter is defined by action width and by the destination field offset.
+Application should provide the data in immediate value memory (either as
+buffer or by pointer) exactly as item field without any applied explicit offset,
+and destination packet field (with specified width and bit offset) will be
+replaced by immediate source bits from the same bit offset. For example,
+to replace the third byte of MAC address with value 0x85, application should
+specify destination width as 8, destination offset as 16, and provide immediate
+value as sequence of bytes {xxx, xxx, 0x85, xxx, xxx, xxx}.
.. _table_rte_flow_action_modify_field:
@@ -2865,7 +2881,13 @@ for ``RTE_FLOW_FIELD_VALUE`` and ``RTE_FLOW_FIELD_POINTER`` respectively.
+---------------+----------------------------------------------------------+
| ``offset`` | number of bits to skip at the beginning |
+---------------+----------------------------------------------------------+
- | ``value`` | immediate value or a pointer to this value |
+ | ``value`` | immediate value buffer (source field only, not |
+ | | applicable to destination) for RTE_FLOW_FIELD_VALUE |
+ | | field type |
+ +---------------+----------------------------------------------------------+
+ | ``pvalue`` | pointer to immediate value data (source field only, not |
+ | | applicable to destination) for RTE_FLOW_FIELD_POINTER |
+ | | field type |
+---------------+----------------------------------------------------------+
Action: ``CONNTRACK``
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index a2fe766d4b..dee14077a5 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -120,10 +120,6 @@ Deprecation Notices
* ethdev: Announce moving from dedicated modify function for each field,
to using the general ``rte_flow_modify_field`` action.
-* ethdev: The struct ``rte_flow_action_modify_data`` will be modified
- to support modifying fields larger than 64 bits.
- In addition, documentation will be updated to clarify byte order.
-
* ethdev: Attribute ``shared`` of the ``struct rte_flow_action_count``
is deprecated and will be removed in DPDK 21.11. Shared counters should
be managed using shared actions API (``rte_flow_shared_action_create`` etc).
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index dfc2cbdeed..578c1206e7 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -187,6 +187,13 @@ API Changes
the crypto/security operation. This field will be used to communicate
events such as soft expiry with IPsec in lookaside mode.
+* ethdev: ``rte_flow_action_modify_data`` structure updated, immediate data
+ array is extended, data pointer field is explicitly added to union, the
+ action behavior is defined in more strict fashion and documentation updated.
+ The immediate value behavior has been changed, the entire immediate field
+ should be provided, and offset for immediate source bitfield is assigned
+ from destination one.
+
ABI Changes
-----------
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 7b1ed7f110..f14f77772b 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -3217,10 +3217,18 @@ struct rte_flow_action_modify_data {
uint32_t offset;
};
/**
- * Immediate value for RTE_FLOW_FIELD_VALUE or
- * memory address for RTE_FLOW_FIELD_POINTER.
+ * Immediate value for RTE_FLOW_FIELD_VALUE, presented in the
+ * same byte order and length as in relevant rte_flow_item_xxx.
+ * The immediate source bitfield offset is inherited from
+ * the destination's one.
*/
- uint64_t value;
+ uint8_t value[16];
+ /**
+ * Memory address for RTE_FLOW_FIELD_POINTER, memory layout
+ * should be the same as for relevant field in the
+ * rte_flow_item_xxx structure.
+ */
+ void *pvalue;
};
};
@@ -3240,7 +3248,7 @@ enum rte_flow_modify_op {
* RTE_FLOW_ACTION_TYPE_MODIFY_FIELD
*
* Modify a destination header field according to the specified
- * operation. Another packet field can be used as a source as well
+ * operation. Another field of the packet can be used as a source as well
* as tag, mark, metadata, immediate value or a pointer to it.
*/
struct rte_flow_action_modify_field {
--
2.18.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs
2021-10-12 21:50 3% ` Thomas Monjalon
@ 2021-10-13 17:56 5% ` Walker, Benjamin
2021-10-13 18:59 3% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Walker, Benjamin @ 2021-10-13 17:56 UTC (permalink / raw)
To: Thomas Monjalon, Harris, James R
Cc: Liu, Changpeng, Xia, Chenbo, David Marchand, dev, Aaron Conole,
Zawadzki, Tomasz
> From: Thomas Monjalon <thomas@monjalon.net>
>
> In order to be perfectly clear, all the changes done around this option
> enable_driver_sdk share the goal of tidying stuff in DPDK so that ABI becomes
> better manageable.
> I think that nobody want to annoy the SPDK project.
> I understand that the changes effectively add troubles, and I am sorry about
> that. If SPDK and other projects can manage with this change, good.
> If there is a real blocker, we should discuss what are the options.
>
> Thanks for your understanding
I completely understand the desire to make the ABI manageable. If I were in your shoes, I'd be doing the same exact thing. What I don't currently understand is the motivation behind this enable_driver_sdk option. My guess is that it's one of two things.
\1 ABI manageability: You say that's the purpose above, and that was my initial assumption. But wouldn't that necessarily mean, over time, no longer considering the symbols that were defined by the header files as part of the stable ABI? If you still consider these symbols as part of the ABI in shared library builds, then the enable_driver_sdk option does absolutely nothing to improve the ABI situation, so why bother to have it at all? We can't have packaged SPDK relying on symbols in a packaged DPDK that are not part of the official ABI.
\2 Not supporting out-of-tree drivers: Another option is that you just don't want people writing out of tree drivers. You can't just drop it outright because people already do it, but you'd like to not support it for shared library builds at least.
So I'd like to really understand which of these two motivated the enable_driver_sdk option . Maybe it's not even one of the two above. If it is #1, then I think maybe we can work with DPDK to define a very small set of out-of-tree driver APIs/ABIs that need to continue to exist in the shared libraries by default. I do think SPDK needs only a very small number. If it's #2, then that's the entire SPDK use case and I'd ask you to reconsider the direction.
Thanks,
Ben
^ permalink raw reply [relevance 5%]
* [dpdk-dev] [PATCH v7 06/12] ethdev: deprecate direction attributes in transfer flows
` (4 preceding siblings ...)
2021-10-13 17:34 3% ` [dpdk-dev] [PATCH v7 05/12] ethdev: deprecate hard-to-use or ambiguous items and actions Ivan Malov
@ 2021-10-13 17:34 3% ` Ivan Malov
5 siblings, 0 replies; 200+ results
From: Ivan Malov @ 2021-10-13 17:34 UTC (permalink / raw)
To: dev
Cc: Ferruh Yigit, Thomas Monjalon, Ori Kam, Andrew Rybchenko, Ray Kinsella
Attributes "ingress" and "egress" can only apply unambiguosly
to non-"transfer" flows. In "transfer" flows, the standpoint
is effectively shifted to the embedded switch. There can be
many different endpoints connected to the switch, so the
use of "ingress" / "egress" does not shed light on which
endpoints precisely can be considered as traffic sources.
Add relevant deprecation notices and suggest the use of precise
traffic source items (PORT_REPRESENTOR and REPRESENTED_PORT).
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
doc/guides/prog_guide/rte_flow.rst | 28 ++++++++----------
doc/guides/rel_notes/deprecation.rst | 9 +++---
doc/guides/rel_notes/release_21_11.rst | 3 ++
lib/ethdev/rte_flow.h | 41 ++++++++++++++++++++------
4 files changed, 52 insertions(+), 29 deletions(-)
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index d7185c49df..5957b8df4f 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -9,8 +9,8 @@ Overview
--------
This API provides a generic means to configure hardware to match specific
-ingress or egress traffic, alter its fate and query related counters
-according to any number of user-defined rules.
+traffic, alter its fate and query related counters according to any
+number of user-defined rules.
It is named *rte_flow* after the prefix used for all its symbols, and is
defined in ``rte_flow.h``.
@@ -146,13 +146,10 @@ Note that support for more than a single priority level is not guaranteed.
Attribute: Traffic direction
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Flow rule patterns apply to inbound and/or outbound traffic.
-
-In the context of this API, **ingress** and **egress** respectively stand
-for **inbound** and **outbound** based on the standpoint of the application
-creating a flow rule.
-
-There are no exceptions to this definition.
+Unless `Attribute: Transfer`_ is specified, flow rule patterns apply
+to inbound and / or outbound traffic. With this respect, ``ingress``
+and ``egress`` respectively stand for **inbound** and **outbound**
+based on the standpoint of the application creating a flow rule.
Several pattern items and actions are valid and can be used in both
directions. At least one direction must be specified.
@@ -171,12 +168,13 @@ When supported, this effectively enables an application to reroute traffic
not necessarily intended for it (e.g. coming from or addressed to different
physical ports, VFs or applications) at the device level.
-It complements the behavior of some pattern items such as `Item: PHY_PORT`_
-and is meaningless without them.
-
-When transferring flow rules, **ingress** and **egress** attributes
-(`Attribute: Traffic direction`_) keep their original meaning, as if
-processing traffic emitted or received by the application.
+In "transfer" flows, the use of `Attribute: Traffic direction`_ in the sense of
+implicitly matching packets going to or going from the ethdev used to create
+flow rules is **deprecated**. `Attribute: Transfer`_ shifts the viewpoint to
+the embedded switch. In it, `Attribute: Traffic direction`_ is ambiguous as
+the switch serves many different endpoints. The application should match
+traffic originating from precise locations. To do so, it should
+use `Item: PORT_REPRESENTOR`_ and `Item: REPRESENTED_PORT`_.
Pattern item
~~~~~~~~~~~~
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 25aec56bec..ef2e2c1141 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -113,11 +113,6 @@ Deprecation Notices
to support modifying fields larger than 64 bits.
In addition, documentation will be updated to clarify byte order.
-* ethdev: Flow API documentation is unclear if ethdev port used to create
- a flow rule adds any implicit match criteria in the case of transfer rules.
- The semantics will be clarified in DPDK 21.11 and it will require fixes in
- drivers and applications which interpret it in a different way.
-
* ethdev: The flow API matching pattern structures, ``struct rte_flow_item_*``,
should start with relevant protocol header.
Some matching pattern structures implements this by duplicating protocol header
@@ -146,6 +141,10 @@ Deprecation Notices
* ethdev: Items and actions ``PF``, ``VF``, ``PHY_PORT``, ``PORT_ID`` are
deprecated as hard-to-use / ambiguous and will be removed in DPDK 22.11.
+* ethdev: The use of attributes ``ingress`` / ``egress`` in "transfer" flows
+ is deprecated as ambiguous with respect to the embedded switch. The use of
+ these attributes will become invalid starting from DPDK 22.11.
+
* net: The structure ``rte_ipv4_hdr`` will have two unions.
The first union is for existing ``version_ihl`` byte
and new bitfield for version and IHL.
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index 75c4f6d018..45c019eb04 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -257,6 +257,9 @@ API Changes
* ethdev: Deprecated items and actions ``PF``, ``VF``, ``PHY_PORT``, ``PORT_ID``.
Suggested items and actions ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` instead.
+* ethdev: Deprecated the use of attributes ``ingress`` / ``egress`` combined
+ with ``transfer``. See items ``PORT_REPRESENTOR``, ``REPRESENTED_PORT``.
+
ABI Changes
-----------
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 76653105a0..7e7b4bce5b 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -67,7 +67,10 @@ extern "C" {
* Note that support for more than a single group and priority level is not
* guaranteed.
*
- * Flow rules can apply to inbound and/or outbound traffic (ingress/egress).
+ * At vNIC / ethdev level, flow rules can apply to inbound and / or outbound
+ * traffic (ingress / egress), with respect to the vNIC / ethdev in question.
+ * At embedded switch level, flow rules apply to all traffic seen by it
+ * unless fitting meta items are used to set concrete traffic source(s).
*
* Several pattern items and actions are valid and can be used in both
* directions. Those valid for only one direction are described as such.
@@ -80,8 +83,32 @@ extern "C" {
struct rte_flow_attr {
uint32_t group; /**< Priority group. */
uint32_t priority; /**< Rule priority level within group. */
- uint32_t ingress:1; /**< Rule applies to ingress traffic. */
- uint32_t egress:1; /**< Rule applies to egress traffic. */
+ /**
+ * The rule in question applies to ingress traffic (non-"transfer").
+ *
+ * @deprecated
+ * It has been possible to combine this attribute with "transfer".
+ * Doing so has been assumed to restrict the scope of matching
+ * to traffic going from within the embedded switch toward the
+ * ethdev the flow rule being created through. This behaviour
+ * is deprecated. During the transition period, one may still
+ * rely on it, but PMDs and applications are encouraged to
+ * gradually move away from this approach.
+ */
+ uint32_t ingress:1;
+ /**
+ * The rule in question applies to egress traffic (non-"transfer").
+ *
+ * @deprecated
+ * It has been possible to combine this attribute with "transfer".
+ * Doing so has been assumed to restrict the scope of matching
+ * to traffic sent by the application by virtue of the ethdev
+ * the flow rule being created through. This behaviour is now
+ * deprecated. During the transition period, one may still
+ * rely on it, but PMDs and applications are encouraged to
+ * gradually move away from this approach.
+ */
+ uint32_t egress:1;
/**
* Instead of simply matching the properties of traffic as it would
* appear on a given DPDK port ID, enabling this attribute transfers
@@ -93,12 +120,8 @@ struct rte_flow_attr {
* from or addressed to different physical ports, VFs or
* applications) at the device level.
*
- * It complements the behavior of some pattern items such as
- * RTE_FLOW_ITEM_TYPE_PHY_PORT and is meaningless without them.
- *
- * When transferring flow rules, ingress and egress attributes keep
- * their original meaning, as if processing traffic emitted or
- * received by the application.
+ * The application should match traffic originating from precise
+ * locations. See items PORT_REPRESENTOR and REPRESENTED_PORT.
*/
uint32_t transfer:1;
uint32_t reserved:29; /**< Reserved, must be zero. */
--
2.20.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v7 05/12] ethdev: deprecate hard-to-use or ambiguous items and actions
` (3 preceding siblings ...)
2021-10-13 17:34 4% ` [dpdk-dev] [PATCH v7 04/12] ethdev: add represented port " Ivan Malov
@ 2021-10-13 17:34 3% ` Ivan Malov
2021-10-13 17:34 3% ` [dpdk-dev] [PATCH v7 06/12] ethdev: deprecate direction attributes in transfer flows Ivan Malov
5 siblings, 0 replies; 200+ results
From: Ivan Malov @ 2021-10-13 17:34 UTC (permalink / raw)
To: dev
Cc: Ferruh Yigit, Thomas Monjalon, Ori Kam, Andrew Rybchenko, Ray Kinsella
PF, VF and PHY_PORT require that applications have extra
knowledge of the underlying NIC and thus are hard to use.
Also, the corresponding items depend on the direction
attribute (ingress / egress), which complicates their
use in applications and interpretation in PMDs.
The concept of PORT_ID is ambiguous as it doesn't say whether
the port in question is an ethdev or the represented entity.
Items and actions PORT_REPRESENTOR, REPRESENTED_PORT
should be used instead.
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
doc/guides/prog_guide/rte_flow.rst | 32 +++++++++++++++
doc/guides/rel_notes/deprecation.rst | 9 ++---
doc/guides/rel_notes/release_21_11.rst | 3 ++
lib/ethdev/rte_flow.h | 56 ++++++++++++++++++++++++++
4 files changed, 94 insertions(+), 6 deletions(-)
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 27a17fac58..d7185c49df 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -504,6 +504,10 @@ Usage example, matching non-TCPv4 packets only:
Item: ``PF``
^^^^^^^^^^^^
+This item is deprecated. Consider:
+ - `Item: PORT_REPRESENTOR`_
+ - `Item: REPRESENTED_PORT`_
+
Matches traffic originating from (ingress) or going to (egress) the physical
function of the current device.
@@ -531,6 +535,10 @@ the application and thus not associated with a DPDK port ID.
Item: ``VF``
^^^^^^^^^^^^
+This item is deprecated. Consider:
+ - `Item: PORT_REPRESENTOR`_
+ - `Item: REPRESENTED_PORT`_
+
Matches traffic originating from (ingress) or going to (egress) a given
virtual function of the current device.
@@ -562,6 +570,10 @@ separate entities, should be addressed through their own DPDK port IDs.
Item: ``PHY_PORT``
^^^^^^^^^^^^^^^^^^
+This item is deprecated. Consider:
+ - `Item: PORT_REPRESENTOR`_
+ - `Item: REPRESENTED_PORT`_
+
Matches traffic originating from (ingress) or going to (egress) a physical
port of the underlying device.
@@ -596,6 +608,10 @@ associated with a port_id should be retrieved by other means.
Item: ``PORT_ID``
^^^^^^^^^^^^^^^^^
+This item is deprecated. Consider:
+ - `Item: PORT_REPRESENTOR`_
+ - `Item: REPRESENTED_PORT`_
+
Matches traffic originating from (ingress) or going to (egress) a given DPDK
port ID.
@@ -1950,6 +1966,10 @@ only matching traffic goes through.
Action: ``PF``
^^^^^^^^^^^^^^
+This action is deprecated. Consider:
+ - `Action: PORT_REPRESENTOR`_
+ - `Action: REPRESENTED_PORT`_
+
Directs matching traffic to the physical function (PF) of the current
device.
@@ -1970,6 +1990,10 @@ See `Item: PF`_.
Action: ``VF``
^^^^^^^^^^^^^^
+This action is deprecated. Consider:
+ - `Action: PORT_REPRESENTOR`_
+ - `Action: REPRESENTED_PORT`_
+
Directs matching traffic to a given virtual function of the current device.
Packets matched by a VF pattern item can be redirected to their original VF
@@ -1994,6 +2018,10 @@ See `Item: VF`_.
Action: ``PHY_PORT``
^^^^^^^^^^^^^^^^^^^^
+This action is deprecated. Consider:
+ - `Action: PORT_REPRESENTOR`_
+ - `Action: REPRESENTED_PORT`_
+
Directs matching traffic to a given physical port index of the underlying
device.
@@ -2013,6 +2041,10 @@ See `Item: PHY_PORT`_.
Action: ``PORT_ID``
^^^^^^^^^^^^^^^^^^^
+This action is deprecated. Consider:
+ - `Action: PORT_REPRESENTOR`_
+ - `Action: REPRESENTED_PORT`_
+
Directs matching traffic to a given DPDK port ID.
See `Item: PORT_ID`_.
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 5853b5988d..25aec56bec 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -113,12 +113,6 @@ Deprecation Notices
to support modifying fields larger than 64 bits.
In addition, documentation will be updated to clarify byte order.
-* ethdev: Definition of the flow API action ``RTE_FLOW_ACTION_TYPE_PORT_ID``
- is ambiguous and needs clarification.
- Structure ``rte_flow_action_port_id`` will be extended to specify
- traffic direction to the represented entity or ethdev port itself
- in DPDK 21.11.
-
* ethdev: Flow API documentation is unclear if ethdev port used to create
a flow rule adds any implicit match criteria in the case of transfer rules.
The semantics will be clarified in DPDK 21.11 and it will require fixes in
@@ -149,6 +143,9 @@ Deprecation Notices
consistent with existing outer header checksum status flag naming, which
should help in reducing confusion about its usage.
+* ethdev: Items and actions ``PF``, ``VF``, ``PHY_PORT``, ``PORT_ID`` are
+ deprecated as hard-to-use / ambiguous and will be removed in DPDK 22.11.
+
* net: The structure ``rte_ipv4_hdr`` will have two unions.
The first union is for existing ``version_ihl`` byte
and new bitfield for version and IHL.
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index 6c15afc1e9..75c4f6d018 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -254,6 +254,9 @@ API Changes
* ethdev: Added items and actions ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` to flow API.
+* ethdev: Deprecated items and actions ``PF``, ``VF``, ``PHY_PORT``, ``PORT_ID``.
+ Suggested items and actions ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` instead.
+
ABI Changes
-----------
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index ff32c0a5ee..76653105a0 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -160,6 +160,10 @@ enum rte_flow_item_type {
RTE_FLOW_ITEM_TYPE_ANY,
/**
+ * @deprecated
+ * @see RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT
+ *
* [META]
*
* Matches traffic originating from (ingress) or going to (egress)
@@ -170,6 +174,10 @@ enum rte_flow_item_type {
RTE_FLOW_ITEM_TYPE_PF,
/**
+ * @deprecated
+ * @see RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT
+ *
* [META]
*
* Matches traffic originating from (ingress) or going to (egress) a
@@ -180,6 +188,10 @@ enum rte_flow_item_type {
RTE_FLOW_ITEM_TYPE_VF,
/**
+ * @deprecated
+ * @see RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT
+ *
* [META]
*
* Matches traffic originating from (ingress) or going to (egress) a
@@ -190,6 +202,10 @@ enum rte_flow_item_type {
RTE_FLOW_ITEM_TYPE_PHY_PORT,
/**
+ * @deprecated
+ * @see RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT
+ *
* [META]
*
* Matches traffic originating from (ingress) or going to (egress) a
@@ -640,6 +656,10 @@ static const struct rte_flow_item_any rte_flow_item_any_mask = {
#endif
/**
+ * @deprecated
+ * @see RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT
+ *
* RTE_FLOW_ITEM_TYPE_VF
*
* Matches traffic originating from (ingress) or going to (egress) a given
@@ -669,6 +689,10 @@ static const struct rte_flow_item_vf rte_flow_item_vf_mask = {
#endif
/**
+ * @deprecated
+ * @see RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT
+ *
* RTE_FLOW_ITEM_TYPE_PHY_PORT
*
* Matches traffic originating from (ingress) or going to (egress) a
@@ -700,6 +724,10 @@ static const struct rte_flow_item_phy_port rte_flow_item_phy_port_mask = {
#endif
/**
+ * @deprecated
+ * @see RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT
+ *
* RTE_FLOW_ITEM_TYPE_PORT_ID
*
* Matches traffic originating from (ingress) or going to (egress) a given
@@ -1998,6 +2026,10 @@ enum rte_flow_action_type {
RTE_FLOW_ACTION_TYPE_RSS,
/**
+ * @deprecated
+ * @see RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT
+ *
* Directs matching traffic to the physical function (PF) of the
* current device.
*
@@ -2006,6 +2038,10 @@ enum rte_flow_action_type {
RTE_FLOW_ACTION_TYPE_PF,
/**
+ * @deprecated
+ * @see RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT
+ *
* Directs matching traffic to a given virtual function of the
* current device.
*
@@ -2014,6 +2050,10 @@ enum rte_flow_action_type {
RTE_FLOW_ACTION_TYPE_VF,
/**
+ * @deprecated
+ * @see RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT
+ *
* Directs packets to a given physical port index of the underlying
* device.
*
@@ -2022,6 +2062,10 @@ enum rte_flow_action_type {
RTE_FLOW_ACTION_TYPE_PHY_PORT,
/**
+ * @deprecated
+ * @see RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT
+ *
* Directs matching traffic to a given DPDK port ID.
*
* See struct rte_flow_action_port_id.
@@ -2648,6 +2692,10 @@ struct rte_flow_action_rss {
};
/**
+ * @deprecated
+ * @see RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT
+ *
* RTE_FLOW_ACTION_TYPE_VF
*
* Directs matching traffic to a given virtual function of the current
@@ -2666,6 +2714,10 @@ struct rte_flow_action_vf {
};
/**
+ * @deprecated
+ * @see RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT
+ *
* RTE_FLOW_ACTION_TYPE_PHY_PORT
*
* Directs packets to a given physical port index of the underlying
@@ -2680,6 +2732,10 @@ struct rte_flow_action_phy_port {
};
/**
+ * @deprecated
+ * @see RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT
+ *
* RTE_FLOW_ACTION_TYPE_PORT_ID
*
* Directs matching traffic to a given DPDK port ID.
--
2.20.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v7 04/12] ethdev: add represented port action to flow API
` (2 preceding siblings ...)
2021-10-13 17:34 4% ` [dpdk-dev] [PATCH v7 03/12] ethdev: add port representor action " Ivan Malov
@ 2021-10-13 17:34 4% ` Ivan Malov
2021-10-13 17:34 3% ` [dpdk-dev] [PATCH v7 05/12] ethdev: deprecate hard-to-use or ambiguous items and actions Ivan Malov
2021-10-13 17:34 3% ` [dpdk-dev] [PATCH v7 06/12] ethdev: deprecate direction attributes in transfer flows Ivan Malov
5 siblings, 0 replies; 200+ results
From: Ivan Malov @ 2021-10-13 17:34 UTC (permalink / raw)
To: dev; +Cc: Ferruh Yigit, Thomas Monjalon, Ori Kam, Andrew Rybchenko, Xiaoyun Li
For use in "transfer" flows. Supposed to send matching traffic to the
entity represented by the given ethdev, at embedded switch level.
Such an entity can be a network (via a network port), a guest
machine (via a VF) or another ethdev in the same application.
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
app/test-pmd/cmdline_flow.c | 26 +++++++++++
doc/guides/nics/features/default.ini | 1 +
doc/guides/prog_guide/rte_flow.rst | 49 +++++++++++++++++++++
doc/guides/rel_notes/release_21_11.rst | 2 +-
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 5 +++
lib/ethdev/rte_flow.c | 1 +
lib/ethdev/rte_flow.h | 11 ++++-
7 files changed, 93 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 1496d7a067..d897d0d1d4 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -461,6 +461,8 @@ enum index {
ACTION_POL_R,
ACTION_PORT_REPRESENTOR,
ACTION_PORT_REPRESENTOR_PORT_ID,
+ ACTION_REPRESENTED_PORT,
+ ACTION_REPRESENTED_PORT_ETHDEV_PORT_ID,
};
/** Maximum size for pattern in struct rte_flow_item_raw. */
@@ -1454,6 +1456,7 @@ static const enum index next_action[] = {
ACTION_CONNTRACK,
ACTION_CONNTRACK_UPDATE,
ACTION_PORT_REPRESENTOR,
+ ACTION_REPRESENTED_PORT,
ZERO,
};
@@ -1740,6 +1743,12 @@ static const enum index action_port_representor[] = {
ZERO,
};
+static const enum index action_represented_port[] = {
+ ACTION_REPRESENTED_PORT_ETHDEV_PORT_ID,
+ ACTION_NEXT,
+ ZERO,
+};
+
static int parse_set_raw_encap_decap(struct context *, const struct token *,
const char *, unsigned int,
void *, unsigned int);
@@ -4836,6 +4845,23 @@ static const struct token token_list[] = {
port_id)),
.call = parse_vc_conf,
},
+ [ACTION_REPRESENTED_PORT] = {
+ .name = "represented_port",
+ .help = "at embedded switch level, send matching traffic to the entity represented by the given ethdev",
+ .priv = PRIV_ACTION(REPRESENTED_PORT,
+ sizeof(struct rte_flow_action_ethdev)),
+ .next = NEXT(action_represented_port),
+ .call = parse_vc,
+ },
+ [ACTION_REPRESENTED_PORT_ETHDEV_PORT_ID] = {
+ .name = "ethdev_port_id",
+ .help = "ethdev port ID",
+ .next = NEXT(action_represented_port,
+ NEXT_ENTRY(COMMON_UNSIGNED)),
+ .args = ARGS(ARGS_ENTRY(struct rte_flow_action_ethdev,
+ port_id)),
+ .call = parse_vc_conf,
+ },
/* Indirect action destroy arguments. */
[INDIRECT_ACTION_DESTROY_ID] = {
.name = "action_id",
diff --git a/doc/guides/nics/features/default.ini b/doc/guides/nics/features/default.ini
index f7f937ca0a..09914b1ad3 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -173,6 +173,7 @@ port_representor =
queue =
raw_decap =
raw_encap =
+represented_port =
rss =
sample =
security =
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 587ed37c2c..27a17fac58 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1532,6 +1532,8 @@ at the opposite end of the "wire" leading to the ethdev.
This item is meant to use the same structure as `Item: PORT_REPRESENTOR`_.
+See also `Action: REPRESENTED_PORT`_.
+
Actions
~~~~~~~
@@ -3145,6 +3147,53 @@ at the opposite end of the "wire" leading to the ethdev.
See also `Item: PORT_REPRESENTOR`_.
+Action: ``REPRESENTED_PORT``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+At embedded switch level, send matching traffic to
+the entity represented by the given ethdev.
+
+Term **ethdev** and the concept of **port representor** are synonymous.
+The **represented port** is an *entity* plugged to the embedded switch
+at the opposite end of the "wire" leading to the ethdev.
+
+::
+
+ .--------------------.
+ | PORT_REPRESENTOR | Ethdev (Application Port Referred to by its ID)
+ '--------------------'
+ :
+ :
+ .----------------.
+ | Logical Port |
+ '----------------'
+ :
+ :
+ :
+ :
+ .----------. .--------------------.
+ | Switch | <== | Matching Traffic |
+ '----------' '--------------------'
+ ||
+ ||
+ ||
+ \/
+ .----------------.
+ | Logical Port |
+ '----------------'
+ ||
+ \/
+ .--------------------.
+ | REPRESENTED_PORT | Net / Guest / Another Ethdev (Same Application)
+ '--------------------'
+
+
+- Requires `Attribute: Transfer`_.
+
+This action is meant to use the same structure as `Action: PORT_REPRESENTOR`_.
+
+See also `Item: REPRESENTED_PORT`_.
+
Negative types
~~~~~~~~~~~~~~
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index 9a0ab97914..6c15afc1e9 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -252,7 +252,7 @@ API Changes
the crypto/security operation. This field will be used to communicate
events such as soft expiry with IPsec in lookaside mode.
-* ethdev: Added items ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` and action ``PORT_REPRESENTOR`` to flow API.
+* ethdev: Added items and actions ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` to flow API.
ABI Changes
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 46b7f07cbc..22ba8f0516 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -4090,6 +4090,11 @@ This section lists supported actions and their attributes, if any.
- ``port_id {unsigned}``: ethdev port ID
+- ``represented_port``: at embedded switch level, send matching traffic to
+ the entity represented by the given ethdev
+
+ - ``ethdev_port_id {unsigned}``: ethdev port ID
+
Destroying flow rules
~~~~~~~~~~~~~~~~~~~~~
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index b074b1c77d..542e40e496 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -192,6 +192,7 @@ static const struct rte_flow_desc_data rte_flow_desc_action[] = {
MK_FLOW_ACTION(INDIRECT, 0),
MK_FLOW_ACTION(CONNTRACK, sizeof(struct rte_flow_action_conntrack)),
MK_FLOW_ACTION(PORT_REPRESENTOR, sizeof(struct rte_flow_action_ethdev)),
+ MK_FLOW_ACTION(REPRESENTED_PORT, sizeof(struct rte_flow_action_ethdev)),
};
int
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 56fd4393e5..ff32c0a5ee 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -2462,6 +2462,14 @@ enum rte_flow_action_type {
* @see struct rte_flow_action_ethdev
*/
RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR,
+
+ /**
+ * At embedded switch level, send matching traffic to
+ * the entity represented by the given ethdev.
+ *
+ * @see struct rte_flow_action_ethdev
+ */
+ RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT,
};
/**
@@ -3212,7 +3220,8 @@ struct rte_flow_action_meter_color {
* @b EXPERIMENTAL: this structure may change without prior notice
*
* Provides an ethdev port ID for use with the following actions:
- * RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR.
+ * RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR,
+ * RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT.
*/
struct rte_flow_action_ethdev {
uint16_t port_id; /**< ethdev port ID */
--
2.20.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v7 03/12] ethdev: add port representor action to flow API
2021-10-13 17:34 4% ` [dpdk-dev] [PATCH v7 01/12] ethdev: add port representor item to " Ivan Malov
2021-10-13 17:34 4% ` [dpdk-dev] [PATCH v7 02/12] ethdev: add represented port " Ivan Malov
@ 2021-10-13 17:34 4% ` Ivan Malov
2021-10-13 17:34 4% ` [dpdk-dev] [PATCH v7 04/12] ethdev: add represented port " Ivan Malov
` (2 subsequent siblings)
5 siblings, 0 replies; 200+ results
From: Ivan Malov @ 2021-10-13 17:34 UTC (permalink / raw)
To: dev; +Cc: Ferruh Yigit, Thomas Monjalon, Ori Kam, Andrew Rybchenko, Xiaoyun Li
For use in "transfer" flows. Supposed to send matching traffic to
the given ethdev (to the application), at embedded switch level.
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
app/test-pmd/cmdline_flow.c | 26 ++++++++++
doc/guides/nics/features/default.ini | 1 +
doc/guides/prog_guide/rte_flow.rst | 56 +++++++++++++++++++++
doc/guides/rel_notes/release_21_11.rst | 2 +-
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 5 ++
lib/ethdev/rte_flow.c | 1 +
lib/ethdev/rte_flow.h | 18 +++++++
7 files changed, 108 insertions(+), 1 deletion(-)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 354f0fb2d7..1496d7a067 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -459,6 +459,8 @@ enum index {
ACTION_POL_G,
ACTION_POL_Y,
ACTION_POL_R,
+ ACTION_PORT_REPRESENTOR,
+ ACTION_PORT_REPRESENTOR_PORT_ID,
};
/** Maximum size for pattern in struct rte_flow_item_raw. */
@@ -1451,6 +1453,7 @@ static const enum index next_action[] = {
ACTION_MODIFY_FIELD,
ACTION_CONNTRACK,
ACTION_CONNTRACK_UPDATE,
+ ACTION_PORT_REPRESENTOR,
ZERO,
};
@@ -1731,6 +1734,12 @@ static const enum index action_update_conntrack[] = {
ZERO,
};
+static const enum index action_port_representor[] = {
+ ACTION_PORT_REPRESENTOR_PORT_ID,
+ ACTION_NEXT,
+ ZERO,
+};
+
static int parse_set_raw_encap_decap(struct context *, const struct token *,
const char *, unsigned int,
void *, unsigned int);
@@ -4810,6 +4819,23 @@ static const struct token token_list[] = {
.next = NEXT(action_update_conntrack),
.call = parse_vc_action_conntrack_update,
},
+ [ACTION_PORT_REPRESENTOR] = {
+ .name = "port_representor",
+ .help = "at embedded switch level, send matching traffic to the given ethdev",
+ .priv = PRIV_ACTION(PORT_REPRESENTOR,
+ sizeof(struct rte_flow_action_ethdev)),
+ .next = NEXT(action_port_representor),
+ .call = parse_vc,
+ },
+ [ACTION_PORT_REPRESENTOR_PORT_ID] = {
+ .name = "port_id",
+ .help = "ethdev port ID",
+ .next = NEXT(action_port_representor,
+ NEXT_ENTRY(COMMON_UNSIGNED)),
+ .args = ARGS(ARGS_ENTRY(struct rte_flow_action_ethdev,
+ port_id)),
+ .call = parse_vc_conf,
+ },
/* Indirect action destroy arguments. */
[INDIRECT_ACTION_DESTROY_ID] = {
.name = "action_id",
diff --git a/doc/guides/nics/features/default.ini b/doc/guides/nics/features/default.ini
index 419bffc66e..f7f937ca0a 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -169,6 +169,7 @@ passthru =
pf =
phy_port =
port_id =
+port_representor =
queue =
raw_decap =
raw_encap =
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 2da286dce8..587ed37c2c 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1484,6 +1484,8 @@ at the opposite end of the "wire" leading to the ethdev.
- Default ``mask`` provides exact match behaviour.
+See also `Action: PORT_REPRESENTOR`_.
+
Item: ``REPRESENTED_PORT``
^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -3089,6 +3091,60 @@ which is set in the packet meta-data (i.e. struct ``rte_mbuf::sched::color``)
| ``meter_color`` | Packet color |
+-----------------+--------------+
+Action: ``PORT_REPRESENTOR``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+At embedded switch level, send matching traffic to the given ethdev.
+
+Term **ethdev** and the concept of **port representor** are synonymous.
+The **represented port** is an *entity* plugged to the embedded switch
+at the opposite end of the "wire" leading to the ethdev.
+
+::
+
+ .--------------------.
+ | PORT_REPRESENTOR | Ethdev (Application Port Referred to by its ID)
+ '--------------------'
+ /\
+ ||
+ .----------------.
+ | Logical Port |
+ '----------------'
+ /\
+ ||
+ ||
+ ||
+ .----------. .--------------------.
+ | Switch | <== | Matching Traffic |
+ '----------' '--------------------'
+ :
+ :
+ :
+ :
+ .----------------.
+ | Logical Port |
+ '----------------'
+ :
+ :
+ .--------------------.
+ | REPRESENTED_PORT | Net / Guest / Another Ethdev (Same Application)
+ '--------------------'
+
+
+- Requires `Attribute: Transfer`_.
+
+.. _table_rte_flow_action_ethdev:
+
+.. table:: ``struct rte_flow_action_ethdev``
+
+ +-------------+----------------+
+ | Field | Value |
+ +=============+================+
+ | ``port_id`` | ethdev port ID |
+ +-------------+----------------+
+
+See also `Item: PORT_REPRESENTOR`_.
+
Negative types
~~~~~~~~~~~~~~
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index b9f918cab8..9a0ab97914 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -252,7 +252,7 @@ API Changes
the crypto/security operation. This field will be used to communicate
events such as soft expiry with IPsec in lookaside mode.
-* ethdev: Added items ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` to flow API.
+* ethdev: Added items ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` and action ``PORT_REPRESENTOR`` to flow API.
ABI Changes
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 61669d1d5a..46b7f07cbc 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -4085,6 +4085,11 @@ This section lists supported actions and their attributes, if any.
- ``type {value}``: Set color type with specified value(green/yellow/red)
+- ``port_representor``: at embedded switch level, send matching traffic to
+ the given ethdev
+
+ - ``port_id {unsigned}``: ethdev port ID
+
Destroying flow rules
~~~~~~~~~~~~~~~~~~~~~
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index d4b654a2c6..b074b1c77d 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -191,6 +191,7 @@ static const struct rte_flow_desc_data rte_flow_desc_action[] = {
*/
MK_FLOW_ACTION(INDIRECT, 0),
MK_FLOW_ACTION(CONNTRACK, sizeof(struct rte_flow_action_conntrack)),
+ MK_FLOW_ACTION(PORT_REPRESENTOR, sizeof(struct rte_flow_action_ethdev)),
};
int
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index b50c3d38b5..56fd4393e5 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -2455,6 +2455,13 @@ enum rte_flow_action_type {
* See struct rte_flow_action_meter_color.
*/
RTE_FLOW_ACTION_TYPE_METER_COLOR,
+
+ /**
+ * At embedded switch level, sends matching traffic to the given ethdev.
+ *
+ * @see struct rte_flow_action_ethdev
+ */
+ RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR,
};
/**
@@ -3200,6 +3207,17 @@ struct rte_flow_action_meter_color {
enum rte_color color; /**< Packet color. */
};
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * Provides an ethdev port ID for use with the following actions:
+ * RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR.
+ */
+struct rte_flow_action_ethdev {
+ uint16_t port_id; /**< ethdev port ID */
+};
+
/**
* Field IDs for MODIFY_FIELD action.
*/
--
2.20.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v7 02/12] ethdev: add represented port item to flow API
2021-10-13 17:34 4% ` [dpdk-dev] [PATCH v7 01/12] ethdev: add port representor item to " Ivan Malov
@ 2021-10-13 17:34 4% ` Ivan Malov
2021-10-13 17:34 4% ` [dpdk-dev] [PATCH v7 03/12] ethdev: add port representor action " Ivan Malov
` (3 subsequent siblings)
5 siblings, 0 replies; 200+ results
From: Ivan Malov @ 2021-10-13 17:34 UTC (permalink / raw)
To: dev; +Cc: Ferruh Yigit, Thomas Monjalon, Ori Kam, Andrew Rybchenko, Xiaoyun Li
For use in "transfer" flows. Supposed to match traffic entering the
embedded switch from the entity represented by the given ethdev.
Such an entity can be a network (via a network port), a guest
machine (via a VF) or another ethdev in the same application.
Must not be combined with direction attributes.
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
app/test-pmd/cmdline_flow.c | 25 +++++++++++
doc/guides/nics/features/default.ini | 1 +
doc/guides/prog_guide/rte_flow.rst | 46 +++++++++++++++++++++
doc/guides/rel_notes/release_21_11.rst | 2 +-
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 5 +++
lib/ethdev/rte_flow.c | 1 +
lib/ethdev/rte_flow.h | 13 +++++-
7 files changed, 91 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 5c480db91d..354f0fb2d7 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -308,6 +308,8 @@ enum index {
ITEM_POL_POLICY,
ITEM_PORT_REPRESENTOR,
ITEM_PORT_REPRESENTOR_PORT_ID,
+ ITEM_REPRESENTED_PORT,
+ ITEM_REPRESENTED_PORT_ETHDEV_PORT_ID,
/* Validate/create actions. */
ACTIONS,
@@ -1002,6 +1004,7 @@ static const enum index next_item[] = {
ITEM_INTEGRITY,
ITEM_CONNTRACK,
ITEM_PORT_REPRESENTOR,
+ ITEM_REPRESENTED_PORT,
END_SET,
ZERO,
};
@@ -1376,6 +1379,12 @@ static const enum index item_port_representor[] = {
ZERO,
};
+static const enum index item_represented_port[] = {
+ ITEM_REPRESENTED_PORT_ETHDEV_PORT_ID,
+ ITEM_NEXT,
+ ZERO,
+};
+
static const enum index next_action[] = {
ACTION_END,
ACTION_VOID,
@@ -3630,6 +3639,21 @@ static const struct token token_list[] = {
item_param),
.args = ARGS(ARGS_ENTRY(struct rte_flow_item_ethdev, port_id)),
},
+ [ITEM_REPRESENTED_PORT] = {
+ .name = "represented_port",
+ .help = "match traffic entering the embedded switch from the entity represented by the given ethdev",
+ .priv = PRIV_ITEM(REPRESENTED_PORT,
+ sizeof(struct rte_flow_item_ethdev)),
+ .next = NEXT(item_represented_port),
+ .call = parse_vc,
+ },
+ [ITEM_REPRESENTED_PORT_ETHDEV_PORT_ID] = {
+ .name = "ethdev_port_id",
+ .help = "ethdev port ID",
+ .next = NEXT(item_represented_port, NEXT_ENTRY(COMMON_UNSIGNED),
+ item_param),
+ .args = ARGS(ARGS_ENTRY(struct rte_flow_item_ethdev, port_id)),
+ },
/* Validate/create actions. */
[ACTIONS] = {
.name = "actions",
@@ -8358,6 +8382,7 @@ flow_item_default_mask(const struct rte_flow_item *item)
mask = &rte_flow_item_pfcp_mask;
break;
case RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR:
+ case RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT:
mask = &rte_flow_item_ethdev_mask;
break;
default:
diff --git a/doc/guides/nics/features/default.ini b/doc/guides/nics/features/default.ini
index 560a13c1ce..419bffc66e 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -125,6 +125,7 @@ pppoed =
pppoes =
pppoe_proto_id =
raw =
+represented_port =
sctp =
tag =
tcp =
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index d194640469..2da286dce8 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1484,6 +1484,52 @@ at the opposite end of the "wire" leading to the ethdev.
- Default ``mask`` provides exact match behaviour.
+Item: ``REPRESENTED_PORT``
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Matches traffic entering the embedded switch from
+the entity represented by the given ethdev.
+
+Term **ethdev** and the concept of **port representor** are synonymous.
+The **represented port** is an *entity* plugged to the embedded switch
+at the opposite end of the "wire" leading to the ethdev.
+
+::
+
+ .--------------------.
+ | PORT_REPRESENTOR | Ethdev (Application Port Referred to by its ID)
+ '--------------------'
+ :
+ :
+ .----------------.
+ | Logical Port |
+ '----------------'
+ :
+ :
+ :
+ :
+ .----------.
+ | Switch |
+ '----------'
+ /\
+ ||
+ ||
+ ||
+ .----------------.
+ | Logical Port |
+ '----------------'
+ /\
+ ||
+ .--------------------.
+ | REPRESENTED_PORT | Net / Guest / Another Ethdev (Same Application)
+ '--------------------'
+
+
+- Incompatible with `Attribute: Traffic direction`_.
+- Requires `Attribute: Transfer`_.
+
+This item is meant to use the same structure as `Item: PORT_REPRESENTOR`_.
+
Actions
~~~~~~~
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index 07f9d39a5b..b9f918cab8 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -252,7 +252,7 @@ API Changes
the crypto/security operation. This field will be used to communicate
events such as soft expiry with IPsec in lookaside mode.
-* ethdev: Added item ``PORT_REPRESENTOR`` to flow API.
+* ethdev: Added items ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` to flow API.
ABI Changes
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 90765f9090..61669d1d5a 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -3805,6 +3805,11 @@ This section lists supported pattern items and their attributes, if any.
- ``port_id {unsigned}``: ethdev port ID
+- ``represented_port``: match traffic entering the embedded switch from
+ the entity represented by the given ethdev
+
+ - ``ethdev_port_id {unsigned}``: ethdev port ID
+
Actions list
^^^^^^^^^^^^
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index 5e9317c6d1..d4b654a2c6 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -101,6 +101,7 @@ static const struct rte_flow_desc_data rte_flow_desc_item[] = {
MK_FLOW_ITEM(INTEGRITY, sizeof(struct rte_flow_item_integrity)),
MK_FLOW_ITEM(CONNTRACK, sizeof(uint32_t)),
MK_FLOW_ITEM(PORT_REPRESENTOR, sizeof(struct rte_flow_item_ethdev)),
+ MK_FLOW_ITEM(REPRESENTED_PORT, sizeof(struct rte_flow_item_ethdev)),
};
/** Generate flow_action[] entry. */
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 1e3ef77ead..b50c3d38b5 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -583,6 +583,16 @@ enum rte_flow_item_type {
* @see struct rte_flow_item_ethdev
*/
RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR,
+
+ /**
+ * [META]
+ *
+ * Matches traffic entering the embedded switch from
+ * the entity represented by the given ethdev.
+ *
+ * @see struct rte_flow_item_ethdev
+ */
+ RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT,
};
/**
@@ -1813,7 +1823,8 @@ static const struct rte_flow_item_conntrack rte_flow_item_conntrack_mask = {
* @b EXPERIMENTAL: this structure may change without prior notice
*
* Provides an ethdev port ID for use with the following items:
- * RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR.
+ * RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR,
+ * RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT.
*/
struct rte_flow_item_ethdev {
uint16_t port_id; /**< ethdev port ID */
--
2.20.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v7 01/12] ethdev: add port representor item to flow API
@ 2021-10-13 17:34 4% ` Ivan Malov
2021-10-13 17:34 4% ` [dpdk-dev] [PATCH v7 02/12] ethdev: add represented port " Ivan Malov
` (4 subsequent siblings)
5 siblings, 0 replies; 200+ results
From: Ivan Malov @ 2021-10-13 17:34 UTC (permalink / raw)
To: dev; +Cc: Ferruh Yigit, Thomas Monjalon, Ori Kam, Andrew Rybchenko, Xiaoyun Li
For use in "transfer" flows. Supposed to match traffic
entering the embedded switch from the given ethdev.
Must not be combined with direction attributes.
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
app/test-pmd/cmdline_flow.c | 27 ++++++++++
doc/guides/nics/features/default.ini | 1 +
doc/guides/prog_guide/rte_flow.rst | 59 +++++++++++++++++++++
doc/guides/rel_notes/release_21_11.rst | 2 +
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 4 ++
lib/ethdev/rte_flow.c | 1 +
lib/ethdev/rte_flow.h | 27 ++++++++++
7 files changed, 121 insertions(+)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 0b5856c7d5..5c480db91d 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -306,6 +306,8 @@ enum index {
ITEM_POL_PORT,
ITEM_POL_METER,
ITEM_POL_POLICY,
+ ITEM_PORT_REPRESENTOR,
+ ITEM_PORT_REPRESENTOR_PORT_ID,
/* Validate/create actions. */
ACTIONS,
@@ -999,6 +1001,7 @@ static const enum index next_item[] = {
ITEM_GENEVE_OPT,
ITEM_INTEGRITY,
ITEM_CONNTRACK,
+ ITEM_PORT_REPRESENTOR,
END_SET,
ZERO,
};
@@ -1367,6 +1370,12 @@ static const enum index item_integrity_lv[] = {
ZERO,
};
+static const enum index item_port_representor[] = {
+ ITEM_PORT_REPRESENTOR_PORT_ID,
+ ITEM_NEXT,
+ ZERO,
+};
+
static const enum index next_action[] = {
ACTION_END,
ACTION_VOID,
@@ -3606,6 +3615,21 @@ static const struct token token_list[] = {
item_param),
.args = ARGS(ARGS_ENTRY(struct rte_flow_item_conntrack, flags)),
},
+ [ITEM_PORT_REPRESENTOR] = {
+ .name = "port_representor",
+ .help = "match traffic entering the embedded switch from the given ethdev",
+ .priv = PRIV_ITEM(PORT_REPRESENTOR,
+ sizeof(struct rte_flow_item_ethdev)),
+ .next = NEXT(item_port_representor),
+ .call = parse_vc,
+ },
+ [ITEM_PORT_REPRESENTOR_PORT_ID] = {
+ .name = "port_id",
+ .help = "ethdev port ID",
+ .next = NEXT(item_port_representor, NEXT_ENTRY(COMMON_UNSIGNED),
+ item_param),
+ .args = ARGS(ARGS_ENTRY(struct rte_flow_item_ethdev, port_id)),
+ },
/* Validate/create actions. */
[ACTIONS] = {
.name = "actions",
@@ -8333,6 +8357,9 @@ flow_item_default_mask(const struct rte_flow_item *item)
case RTE_FLOW_ITEM_TYPE_PFCP:
mask = &rte_flow_item_pfcp_mask;
break;
+ case RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR:
+ mask = &rte_flow_item_ethdev_mask;
+ break;
default:
break;
}
diff --git a/doc/guides/nics/features/default.ini b/doc/guides/nics/features/default.ini
index d473b94091..560a13c1ce 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -120,6 +120,7 @@ pf =
pfcp =
phy_port =
port_id =
+port_representor =
pppoed =
pppoes =
pppoe_proto_id =
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 3cb014c1fa..d194640469 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1425,6 +1425,65 @@ Matches a conntrack state after conntrack action.
- ``flags``: conntrack packet state flags.
- Default ``mask`` matches all state bits.
+Item: ``PORT_REPRESENTOR``
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Matches traffic entering the embedded switch from the given ethdev.
+
+Term **ethdev** and the concept of **port representor** are synonymous.
+The **represented port** is an *entity* plugged to the embedded switch
+at the opposite end of the "wire" leading to the ethdev.
+
+::
+
+ .--------------------.
+ | PORT_REPRESENTOR | Ethdev (Application Port Referred to by its ID)
+ '--------------------'
+ ||
+ \/
+ .----------------.
+ | Logical Port |
+ '----------------'
+ ||
+ ||
+ ||
+ \/
+ .----------.
+ | Switch |
+ '----------'
+ :
+ :
+ :
+ :
+ .----------------.
+ | Logical Port |
+ '----------------'
+ :
+ :
+ .--------------------.
+ | REPRESENTED_PORT | Net / Guest / Another Ethdev (Same Application)
+ '--------------------'
+
+
+- Incompatible with `Attribute: Traffic direction`_.
+- Requires `Attribute: Transfer`_.
+
+.. _table_rte_flow_item_ethdev:
+
+.. table:: ``struct rte_flow_item_ethdev``
+
+ +----------+-------------+---------------------------+
+ | Field | Subfield | Value |
+ +==========+=============+===========================+
+ | ``spec`` | ``port_id`` | ethdev port ID |
+ +----------+-------------+---------------------------+
+ | ``last`` | ``port_id`` | upper range value |
+ +----------+-------------+---------------------------+
+ | ``mask`` | ``port_id`` | zeroed for wildcard match |
+ +----------+-------------+---------------------------+
+
+- Default ``mask`` provides exact match behaviour.
+
Actions
~~~~~~~
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index d5c762df62..07f9d39a5b 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -252,6 +252,8 @@ API Changes
the crypto/security operation. This field will be used to communicate
events such as soft expiry with IPsec in lookaside mode.
+* ethdev: Added item ``PORT_REPRESENTOR`` to flow API.
+
ABI Changes
-----------
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index a0efb7d0b0..90765f9090 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -3801,6 +3801,10 @@ This section lists supported pattern items and their attributes, if any.
- ``conntrack``: match conntrack state.
+- ``port_representor``: match traffic entering the embedded switch from the given ethdev
+
+ - ``port_id {unsigned}``: ethdev port ID
+
Actions list
^^^^^^^^^^^^
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index 8cb7a069c8..5e9317c6d1 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -100,6 +100,7 @@ static const struct rte_flow_desc_data rte_flow_desc_item[] = {
MK_FLOW_ITEM(GENEVE_OPT, sizeof(struct rte_flow_item_geneve_opt)),
MK_FLOW_ITEM(INTEGRITY, sizeof(struct rte_flow_item_integrity)),
MK_FLOW_ITEM(CONNTRACK, sizeof(uint32_t)),
+ MK_FLOW_ITEM(PORT_REPRESENTOR, sizeof(struct rte_flow_item_ethdev)),
};
/** Generate flow_action[] entry. */
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 5f87851f8c..1e3ef77ead 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -574,6 +574,15 @@ enum rte_flow_item_type {
* @see struct rte_flow_item_conntrack.
*/
RTE_FLOW_ITEM_TYPE_CONNTRACK,
+
+ /**
+ * [META]
+ *
+ * Matches traffic entering the embedded switch from the given ethdev.
+ *
+ * @see struct rte_flow_item_ethdev
+ */
+ RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR,
};
/**
@@ -1799,6 +1808,24 @@ static const struct rte_flow_item_conntrack rte_flow_item_conntrack_mask = {
};
#endif
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * Provides an ethdev port ID for use with the following items:
+ * RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR.
+ */
+struct rte_flow_item_ethdev {
+ uint16_t port_id; /**< ethdev port ID */
+};
+
+/** Default mask for items based on struct rte_flow_item_ethdev */
+#ifndef __cplusplus
+static const struct rte_flow_item_ethdev rte_flow_item_ethdev_mask = {
+ .port_id = 0xffff,
+};
+#endif
+
/**
* Matching pattern item definition.
*
--
2.20.1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] mempool: fix name size in mempool structure
2021-10-13 11:14 0% ` Andrew Rybchenko
@ 2021-10-13 17:30 0% ` Honnappa Nagarahalli
0 siblings, 0 replies; 200+ results
From: Honnappa Nagarahalli @ 2021-10-13 17:30 UTC (permalink / raw)
To: Andrew Rybchenko, David Marchand
Cc: Olivier Matz, Zoltan Kiss, dev, Ray Kinsella, thomas,
Konstantin Ananyev, nd, nd
<snip>
>
> On 10/13/21 2:07 PM, David Marchand wrote:
> > On Wed, Oct 13, 2021 at 10:57 AM Andrew Rybchenko
> > <andrew.rybchenko@oktetlabs.ru> wrote:
> >>
> >> Use correct define as a name array size.
> >>
> >> The change breaks ABI and therefore cannot be backported to stable
> >> branches.
> >>
> >> Fixes: 38c9817ee1d8 ("mempool: adjust name size in related data
> >> types")
> >>
> >> Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> >
> > Reviewed-by: David Marchand <david.marchand@redhat.com>
> >
> > Good catch, I guess we can clean ring too, quick grep:
> >
> > lib/ring/rte_ring_core.h-struct rte_ring {
> > lib/ring/rte_ring_core.h- /*
> > lib/ring/rte_ring_core.h: * Note: this field kept the
> > RTE_MEMZONE_NAMESIZE size due to ABI
> > lib/ring/rte_ring_core.h- * compatibility requirements, it
> > could be changed to RTE_RING_NAMESIZE
> > lib/ring/rte_ring_core.h: * next time the ABI changes
> > lib/ring/rte_ring_core.h- */
> > lib/ring/rte_ring_core.h- char name[RTE_MEMZONE_NAMESIZE]
> > __rte_cache_aligned;
> >
> >
>
> Yes. I've not bothered to grep... Cc maintainers.
>
> @David, @Konstantin, or @Honnappa, will you send a patch or should I do?
I will send a patch
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v6 2/2] net: introduce IPv4 ihl and version fields
@ 2021-10-13 17:13 4% ` Gregory Etelson
0 siblings, 0 replies; 200+ results
From: Gregory Etelson @ 2021-10-13 17:13 UTC (permalink / raw)
To: dev, getelson
Cc: matan, rasland, olivier.matz, thomas, ferruh.yigit, Ray Kinsella,
Bernard Iremonger
RTE IPv4 header definition combines the `version' and `ihl' fields
into a single structure member.
This patch introduces dedicated structure members for both `version'
and `ihl' IPv4 fields. Separated header fields definitions allow to
create simplified code to match on the IHL value in a flow rule.
The original `version_ihl' structure member is kept for backward
compatibility.
Signed-off-by: Gregory Etelson <getelson@nvidia.com>
Acked-by: Olivier Matz <olivier.matz@6wind.com>
Acked-by: Ray Kinsella <mdr@ashroe.eu>
---
v2: Add dependency.
v3: Add comments.
v4: Update release notes.
v5: Remove deprecation notice.
Update the patch comment.
v6: split the patch into 2 parts:
1: update the announce.
2: implement the IPv4 header changes.
---
app/test/test_flow_classify.c | 8 ++++----
doc/guides/rel_notes/deprecation.rst | 3 ---
doc/guides/rel_notes/release_21_11.rst | 3 +++
lib/net/rte_ip.h | 16 +++++++++++++++-
4 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/app/test/test_flow_classify.c b/app/test/test_flow_classify.c
index 951606f248..4f64be5357 100644
--- a/app/test/test_flow_classify.c
+++ b/app/test/test_flow_classify.c
@@ -95,7 +95,7 @@ static struct rte_acl_field_def ipv4_defs[NUM_FIELDS_IPV4] = {
* dst mask 255.255.255.00 / udp src is 32 dst is 33 / end"
*/
static struct rte_flow_item_ipv4 ipv4_udp_spec_1 = {
- { 0, 0, 0, 0, 0, 0, IPPROTO_UDP, 0,
+ { { .version_ihl = 0}, 0, 0, 0, 0, 0, IPPROTO_UDP, 0,
RTE_IPV4(2, 2, 2, 3), RTE_IPV4(2, 2, 2, 7)}
};
static const struct rte_flow_item_ipv4 ipv4_mask_24 = {
@@ -131,7 +131,7 @@ static struct rte_flow_item end_item = { RTE_FLOW_ITEM_TYPE_END,
* dst mask 255.255.255.00 / tcp src is 16 dst is 17 / end"
*/
static struct rte_flow_item_ipv4 ipv4_tcp_spec_1 = {
- { 0, 0, 0, 0, 0, 0, IPPROTO_TCP, 0,
+ { { .version_ihl = 0}, 0, 0, 0, 0, 0, IPPROTO_TCP, 0,
RTE_IPV4(1, 2, 3, 4), RTE_IPV4(5, 6, 7, 8)}
};
@@ -150,8 +150,8 @@ static struct rte_flow_item tcp_item_1 = { RTE_FLOW_ITEM_TYPE_TCP,
* dst mask 255.255.255.00 / sctp src is 16 dst is 17/ end"
*/
static struct rte_flow_item_ipv4 ipv4_sctp_spec_1 = {
- { 0, 0, 0, 0, 0, 0, IPPROTO_SCTP, 0, RTE_IPV4(11, 12, 13, 14),
- RTE_IPV4(15, 16, 17, 18)}
+ { { .version_ihl = 0}, 0, 0, 0, 0, 0, IPPROTO_SCTP, 0,
+ RTE_IPV4(11, 12, 13, 14), RTE_IPV4(15, 16, 17, 18)}
};
static struct rte_flow_item_sctp sctp_spec_1 = {
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 841653fe30..d1f3faac39 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -158,9 +158,6 @@ Deprecation Notices
consistent with existing outer header checksum status flag naming, which
should help in reducing confusion about its usage.
-* net: The structure ``rte_ipv4_hdr`` will have a union for
- existing ``version_ihl`` byte and new bitfield for ``version`` and ``ihl``.
-
* vhost: ``rte_vdpa_register_device``, ``rte_vdpa_unregister_device``,
``rte_vhost_host_notifier_ctrl`` and ``rte_vdpa_relay_vring_used`` vDPA
driver interface will be marked as internal in DPDK v21.11.
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index e1726774ba..fa60fd9a85 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -216,6 +216,9 @@ API Changes
the crypto/security operation. This field will be used to communicate
events such as soft expiry with IPsec in lookaside mode.
+* net: Add ``version`` and ``ihl`` bit-fields to ``struct rte_ipv4_hdr``.
+ Existing ``version_ihl`` field was kept for backward compatibility.
+
ABI Changes
-----------
diff --git a/lib/net/rte_ip.h b/lib/net/rte_ip.h
index b3d45e85db..1f3660e8b4 100644
--- a/lib/net/rte_ip.h
+++ b/lib/net/rte_ip.h
@@ -39,7 +39,21 @@ extern "C" {
* IPv4 Header
*/
struct rte_ipv4_hdr {
- uint8_t version_ihl; /**< version and header length */
+ __extension__
+ union {
+ uint8_t version_ihl; /**< version and header length */
+ struct {
+#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
+ uint8_t ihl:4; /**< header length */
+ uint8_t version:4; /**< version */
+#elif RTE_BYTE_ORDER == RTE_BIG_ENDIAN
+ uint8_t version:4; /**< version */
+ uint8_t ihl:4; /**< header length */
+#else
+#error "setup endian definition"
+#endif
+ };
+ };
uint8_t type_of_service; /**< type of service */
rte_be16_t total_length; /**< length of packet */
rte_be16_t packet_id; /**< packet ID */
--
2.33.0
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v6 06/12] ethdev: deprecate direction attributes in transfer flows
` (4 preceding siblings ...)
2021-10-13 17:02 3% ` [dpdk-dev] [PATCH v6 05/12] ethdev: deprecate hard-to-use or ambiguous items and actions Ivan Malov
@ 2021-10-13 17:02 3% ` Ivan Malov
5 siblings, 0 replies; 200+ results
From: Ivan Malov @ 2021-10-13 17:02 UTC (permalink / raw)
To: dev
Cc: Ferruh Yigit, Thomas Monjalon, Ori Kam, Andrew Rybchenko, Ray Kinsella
Attributes "ingress" and "egress" can only apply unambiguosly
to non-"transfer" flows. In "transfer" flows, the standpoint
is effectively shifted to the embedded switch. There can be
many different endpoints connected to the switch, so the
use of "ingress" / "egress" does not shed light on which
endpoints precisely can be considered as traffic sources.
Add relevant deprecation notices and suggest the use of precise
traffic source items (PORT_REPRESENTOR and REPRESENTED_PORT).
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
doc/guides/prog_guide/rte_flow.rst | 28 ++++++++----------
doc/guides/rel_notes/deprecation.rst | 9 +++---
doc/guides/rel_notes/release_21_11.rst | 3 ++
lib/ethdev/rte_flow.h | 41 ++++++++++++++++++++------
4 files changed, 52 insertions(+), 29 deletions(-)
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index d7185c49df..5957b8df4f 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -9,8 +9,8 @@ Overview
--------
This API provides a generic means to configure hardware to match specific
-ingress or egress traffic, alter its fate and query related counters
-according to any number of user-defined rules.
+traffic, alter its fate and query related counters according to any
+number of user-defined rules.
It is named *rte_flow* after the prefix used for all its symbols, and is
defined in ``rte_flow.h``.
@@ -146,13 +146,10 @@ Note that support for more than a single priority level is not guaranteed.
Attribute: Traffic direction
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Flow rule patterns apply to inbound and/or outbound traffic.
-
-In the context of this API, **ingress** and **egress** respectively stand
-for **inbound** and **outbound** based on the standpoint of the application
-creating a flow rule.
-
-There are no exceptions to this definition.
+Unless `Attribute: Transfer`_ is specified, flow rule patterns apply
+to inbound and / or outbound traffic. With this respect, ``ingress``
+and ``egress`` respectively stand for **inbound** and **outbound**
+based on the standpoint of the application creating a flow rule.
Several pattern items and actions are valid and can be used in both
directions. At least one direction must be specified.
@@ -171,12 +168,13 @@ When supported, this effectively enables an application to reroute traffic
not necessarily intended for it (e.g. coming from or addressed to different
physical ports, VFs or applications) at the device level.
-It complements the behavior of some pattern items such as `Item: PHY_PORT`_
-and is meaningless without them.
-
-When transferring flow rules, **ingress** and **egress** attributes
-(`Attribute: Traffic direction`_) keep their original meaning, as if
-processing traffic emitted or received by the application.
+In "transfer" flows, the use of `Attribute: Traffic direction`_ in the sense of
+implicitly matching packets going to or going from the ethdev used to create
+flow rules is **deprecated**. `Attribute: Transfer`_ shifts the viewpoint to
+the embedded switch. In it, `Attribute: Traffic direction`_ is ambiguous as
+the switch serves many different endpoints. The application should match
+traffic originating from precise locations. To do so, it should
+use `Item: PORT_REPRESENTOR`_ and `Item: REPRESENTED_PORT`_.
Pattern item
~~~~~~~~~~~~
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 25aec56bec..ef2e2c1141 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -113,11 +113,6 @@ Deprecation Notices
to support modifying fields larger than 64 bits.
In addition, documentation will be updated to clarify byte order.
-* ethdev: Flow API documentation is unclear if ethdev port used to create
- a flow rule adds any implicit match criteria in the case of transfer rules.
- The semantics will be clarified in DPDK 21.11 and it will require fixes in
- drivers and applications which interpret it in a different way.
-
* ethdev: The flow API matching pattern structures, ``struct rte_flow_item_*``,
should start with relevant protocol header.
Some matching pattern structures implements this by duplicating protocol header
@@ -146,6 +141,10 @@ Deprecation Notices
* ethdev: Items and actions ``PF``, ``VF``, ``PHY_PORT``, ``PORT_ID`` are
deprecated as hard-to-use / ambiguous and will be removed in DPDK 22.11.
+* ethdev: The use of attributes ``ingress`` / ``egress`` in "transfer" flows
+ is deprecated as ambiguous with respect to the embedded switch. The use of
+ these attributes will become invalid starting from DPDK 22.11.
+
* net: The structure ``rte_ipv4_hdr`` will have two unions.
The first union is for existing ``version_ihl`` byte
and new bitfield for version and IHL.
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index 75c4f6d018..45c019eb04 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -257,6 +257,9 @@ API Changes
* ethdev: Deprecated items and actions ``PF``, ``VF``, ``PHY_PORT``, ``PORT_ID``.
Suggested items and actions ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` instead.
+* ethdev: Deprecated the use of attributes ``ingress`` / ``egress`` combined
+ with ``transfer``. See items ``PORT_REPRESENTOR``, ``REPRESENTED_PORT``.
+
ABI Changes
-----------
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 76653105a0..7e7b4bce5b 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -67,7 +67,10 @@ extern "C" {
* Note that support for more than a single group and priority level is not
* guaranteed.
*
- * Flow rules can apply to inbound and/or outbound traffic (ingress/egress).
+ * At vNIC / ethdev level, flow rules can apply to inbound and / or outbound
+ * traffic (ingress / egress), with respect to the vNIC / ethdev in question.
+ * At embedded switch level, flow rules apply to all traffic seen by it
+ * unless fitting meta items are used to set concrete traffic source(s).
*
* Several pattern items and actions are valid and can be used in both
* directions. Those valid for only one direction are described as such.
@@ -80,8 +83,32 @@ extern "C" {
struct rte_flow_attr {
uint32_t group; /**< Priority group. */
uint32_t priority; /**< Rule priority level within group. */
- uint32_t ingress:1; /**< Rule applies to ingress traffic. */
- uint32_t egress:1; /**< Rule applies to egress traffic. */
+ /**
+ * The rule in question applies to ingress traffic (non-"transfer").
+ *
+ * @deprecated
+ * It has been possible to combine this attribute with "transfer".
+ * Doing so has been assumed to restrict the scope of matching
+ * to traffic going from within the embedded switch toward the
+ * ethdev the flow rule being created through. This behaviour
+ * is deprecated. During the transition period, one may still
+ * rely on it, but PMDs and applications are encouraged to
+ * gradually move away from this approach.
+ */
+ uint32_t ingress:1;
+ /**
+ * The rule in question applies to egress traffic (non-"transfer").
+ *
+ * @deprecated
+ * It has been possible to combine this attribute with "transfer".
+ * Doing so has been assumed to restrict the scope of matching
+ * to traffic sent by the application by virtue of the ethdev
+ * the flow rule being created through. This behaviour is now
+ * deprecated. During the transition period, one may still
+ * rely on it, but PMDs and applications are encouraged to
+ * gradually move away from this approach.
+ */
+ uint32_t egress:1;
/**
* Instead of simply matching the properties of traffic as it would
* appear on a given DPDK port ID, enabling this attribute transfers
@@ -93,12 +120,8 @@ struct rte_flow_attr {
* from or addressed to different physical ports, VFs or
* applications) at the device level.
*
- * It complements the behavior of some pattern items such as
- * RTE_FLOW_ITEM_TYPE_PHY_PORT and is meaningless without them.
- *
- * When transferring flow rules, ingress and egress attributes keep
- * their original meaning, as if processing traffic emitted or
- * received by the application.
+ * The application should match traffic originating from precise
+ * locations. See items PORT_REPRESENTOR and REPRESENTED_PORT.
*/
uint32_t transfer:1;
uint32_t reserved:29; /**< Reserved, must be zero. */
--
2.20.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v6 05/12] ethdev: deprecate hard-to-use or ambiguous items and actions
` (3 preceding siblings ...)
2021-10-13 17:02 4% ` [dpdk-dev] [PATCH v6 04/12] ethdev: add represented port " Ivan Malov
@ 2021-10-13 17:02 3% ` Ivan Malov
2021-10-13 17:02 3% ` [dpdk-dev] [PATCH v6 06/12] ethdev: deprecate direction attributes in transfer flows Ivan Malov
5 siblings, 0 replies; 200+ results
From: Ivan Malov @ 2021-10-13 17:02 UTC (permalink / raw)
To: dev
Cc: Ferruh Yigit, Thomas Monjalon, Ori Kam, Andrew Rybchenko, Ray Kinsella
PF, VF and PHY_PORT require that applications have extra
knowledge of the underlying NIC and thus are hard to use.
Also, the corresponding items depend on the direction
attribute (ingress / egress), which complicates their
use in applications and interpretation in PMDs.
The concept of PORT_ID is ambiguous as it doesn't say whether
the port in question is an ethdev or the represented entity.
Items and actions PORT_REPRESENTOR, REPRESENTED_PORT
should be used instead.
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
doc/guides/prog_guide/rte_flow.rst | 32 +++++++++++++++
doc/guides/rel_notes/deprecation.rst | 9 ++---
doc/guides/rel_notes/release_21_11.rst | 3 ++
lib/ethdev/rte_flow.h | 56 ++++++++++++++++++++++++++
4 files changed, 94 insertions(+), 6 deletions(-)
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 27a17fac58..d7185c49df 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -504,6 +504,10 @@ Usage example, matching non-TCPv4 packets only:
Item: ``PF``
^^^^^^^^^^^^
+This item is deprecated. Consider:
+ - `Item: PORT_REPRESENTOR`_
+ - `Item: REPRESENTED_PORT`_
+
Matches traffic originating from (ingress) or going to (egress) the physical
function of the current device.
@@ -531,6 +535,10 @@ the application and thus not associated with a DPDK port ID.
Item: ``VF``
^^^^^^^^^^^^
+This item is deprecated. Consider:
+ - `Item: PORT_REPRESENTOR`_
+ - `Item: REPRESENTED_PORT`_
+
Matches traffic originating from (ingress) or going to (egress) a given
virtual function of the current device.
@@ -562,6 +570,10 @@ separate entities, should be addressed through their own DPDK port IDs.
Item: ``PHY_PORT``
^^^^^^^^^^^^^^^^^^
+This item is deprecated. Consider:
+ - `Item: PORT_REPRESENTOR`_
+ - `Item: REPRESENTED_PORT`_
+
Matches traffic originating from (ingress) or going to (egress) a physical
port of the underlying device.
@@ -596,6 +608,10 @@ associated with a port_id should be retrieved by other means.
Item: ``PORT_ID``
^^^^^^^^^^^^^^^^^
+This item is deprecated. Consider:
+ - `Item: PORT_REPRESENTOR`_
+ - `Item: REPRESENTED_PORT`_
+
Matches traffic originating from (ingress) or going to (egress) a given DPDK
port ID.
@@ -1950,6 +1966,10 @@ only matching traffic goes through.
Action: ``PF``
^^^^^^^^^^^^^^
+This action is deprecated. Consider:
+ - `Action: PORT_REPRESENTOR`_
+ - `Action: REPRESENTED_PORT`_
+
Directs matching traffic to the physical function (PF) of the current
device.
@@ -1970,6 +1990,10 @@ See `Item: PF`_.
Action: ``VF``
^^^^^^^^^^^^^^
+This action is deprecated. Consider:
+ - `Action: PORT_REPRESENTOR`_
+ - `Action: REPRESENTED_PORT`_
+
Directs matching traffic to a given virtual function of the current device.
Packets matched by a VF pattern item can be redirected to their original VF
@@ -1994,6 +2018,10 @@ See `Item: VF`_.
Action: ``PHY_PORT``
^^^^^^^^^^^^^^^^^^^^
+This action is deprecated. Consider:
+ - `Action: PORT_REPRESENTOR`_
+ - `Action: REPRESENTED_PORT`_
+
Directs matching traffic to a given physical port index of the underlying
device.
@@ -2013,6 +2041,10 @@ See `Item: PHY_PORT`_.
Action: ``PORT_ID``
^^^^^^^^^^^^^^^^^^^
+This action is deprecated. Consider:
+ - `Action: PORT_REPRESENTOR`_
+ - `Action: REPRESENTED_PORT`_
+
Directs matching traffic to a given DPDK port ID.
See `Item: PORT_ID`_.
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 5853b5988d..25aec56bec 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -113,12 +113,6 @@ Deprecation Notices
to support modifying fields larger than 64 bits.
In addition, documentation will be updated to clarify byte order.
-* ethdev: Definition of the flow API action ``RTE_FLOW_ACTION_TYPE_PORT_ID``
- is ambiguous and needs clarification.
- Structure ``rte_flow_action_port_id`` will be extended to specify
- traffic direction to the represented entity or ethdev port itself
- in DPDK 21.11.
-
* ethdev: Flow API documentation is unclear if ethdev port used to create
a flow rule adds any implicit match criteria in the case of transfer rules.
The semantics will be clarified in DPDK 21.11 and it will require fixes in
@@ -149,6 +143,9 @@ Deprecation Notices
consistent with existing outer header checksum status flag naming, which
should help in reducing confusion about its usage.
+* ethdev: Items and actions ``PF``, ``VF``, ``PHY_PORT``, ``PORT_ID`` are
+ deprecated as hard-to-use / ambiguous and will be removed in DPDK 22.11.
+
* net: The structure ``rte_ipv4_hdr`` will have two unions.
The first union is for existing ``version_ihl`` byte
and new bitfield for version and IHL.
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index 6c15afc1e9..75c4f6d018 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -254,6 +254,9 @@ API Changes
* ethdev: Added items and actions ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` to flow API.
+* ethdev: Deprecated items and actions ``PF``, ``VF``, ``PHY_PORT``, ``PORT_ID``.
+ Suggested items and actions ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` instead.
+
ABI Changes
-----------
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index ff32c0a5ee..76653105a0 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -160,6 +160,10 @@ enum rte_flow_item_type {
RTE_FLOW_ITEM_TYPE_ANY,
/**
+ * @deprecated
+ * @see RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT
+ *
* [META]
*
* Matches traffic originating from (ingress) or going to (egress)
@@ -170,6 +174,10 @@ enum rte_flow_item_type {
RTE_FLOW_ITEM_TYPE_PF,
/**
+ * @deprecated
+ * @see RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT
+ *
* [META]
*
* Matches traffic originating from (ingress) or going to (egress) a
@@ -180,6 +188,10 @@ enum rte_flow_item_type {
RTE_FLOW_ITEM_TYPE_VF,
/**
+ * @deprecated
+ * @see RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT
+ *
* [META]
*
* Matches traffic originating from (ingress) or going to (egress) a
@@ -190,6 +202,10 @@ enum rte_flow_item_type {
RTE_FLOW_ITEM_TYPE_PHY_PORT,
/**
+ * @deprecated
+ * @see RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT
+ *
* [META]
*
* Matches traffic originating from (ingress) or going to (egress) a
@@ -640,6 +656,10 @@ static const struct rte_flow_item_any rte_flow_item_any_mask = {
#endif
/**
+ * @deprecated
+ * @see RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT
+ *
* RTE_FLOW_ITEM_TYPE_VF
*
* Matches traffic originating from (ingress) or going to (egress) a given
@@ -669,6 +689,10 @@ static const struct rte_flow_item_vf rte_flow_item_vf_mask = {
#endif
/**
+ * @deprecated
+ * @see RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT
+ *
* RTE_FLOW_ITEM_TYPE_PHY_PORT
*
* Matches traffic originating from (ingress) or going to (egress) a
@@ -700,6 +724,10 @@ static const struct rte_flow_item_phy_port rte_flow_item_phy_port_mask = {
#endif
/**
+ * @deprecated
+ * @see RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT
+ *
* RTE_FLOW_ITEM_TYPE_PORT_ID
*
* Matches traffic originating from (ingress) or going to (egress) a given
@@ -1998,6 +2026,10 @@ enum rte_flow_action_type {
RTE_FLOW_ACTION_TYPE_RSS,
/**
+ * @deprecated
+ * @see RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT
+ *
* Directs matching traffic to the physical function (PF) of the
* current device.
*
@@ -2006,6 +2038,10 @@ enum rte_flow_action_type {
RTE_FLOW_ACTION_TYPE_PF,
/**
+ * @deprecated
+ * @see RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT
+ *
* Directs matching traffic to a given virtual function of the
* current device.
*
@@ -2014,6 +2050,10 @@ enum rte_flow_action_type {
RTE_FLOW_ACTION_TYPE_VF,
/**
+ * @deprecated
+ * @see RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT
+ *
* Directs packets to a given physical port index of the underlying
* device.
*
@@ -2022,6 +2062,10 @@ enum rte_flow_action_type {
RTE_FLOW_ACTION_TYPE_PHY_PORT,
/**
+ * @deprecated
+ * @see RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT
+ *
* Directs matching traffic to a given DPDK port ID.
*
* See struct rte_flow_action_port_id.
@@ -2648,6 +2692,10 @@ struct rte_flow_action_rss {
};
/**
+ * @deprecated
+ * @see RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT
+ *
* RTE_FLOW_ACTION_TYPE_VF
*
* Directs matching traffic to a given virtual function of the current
@@ -2666,6 +2714,10 @@ struct rte_flow_action_vf {
};
/**
+ * @deprecated
+ * @see RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT
+ *
* RTE_FLOW_ACTION_TYPE_PHY_PORT
*
* Directs packets to a given physical port index of the underlying
@@ -2680,6 +2732,10 @@ struct rte_flow_action_phy_port {
};
/**
+ * @deprecated
+ * @see RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT
+ *
* RTE_FLOW_ACTION_TYPE_PORT_ID
*
* Directs matching traffic to a given DPDK port ID.
--
2.20.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v6 04/12] ethdev: add represented port action to flow API
` (2 preceding siblings ...)
2021-10-13 17:02 4% ` [dpdk-dev] [PATCH v6 03/12] ethdev: add port representor action " Ivan Malov
@ 2021-10-13 17:02 4% ` Ivan Malov
2021-10-13 17:02 3% ` [dpdk-dev] [PATCH v6 05/12] ethdev: deprecate hard-to-use or ambiguous items and actions Ivan Malov
2021-10-13 17:02 3% ` [dpdk-dev] [PATCH v6 06/12] ethdev: deprecate direction attributes in transfer flows Ivan Malov
5 siblings, 0 replies; 200+ results
From: Ivan Malov @ 2021-10-13 17:02 UTC (permalink / raw)
To: dev; +Cc: Ferruh Yigit, Thomas Monjalon, Ori Kam, Andrew Rybchenko, Xiaoyun Li
For use in "transfer" flows. Supposed to send matching traffic to the
entity represented by the given ethdev, at embedded switch level.
Such an entity can be a network (via a network port), a guest
machine (via a VF) or another ethdev in the same application.
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
app/test-pmd/cmdline_flow.c | 26 +++++++++++
doc/guides/nics/features/default.ini | 1 +
doc/guides/prog_guide/rte_flow.rst | 49 +++++++++++++++++++++
doc/guides/rel_notes/release_21_11.rst | 2 +-
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 5 +++
lib/ethdev/rte_flow.c | 1 +
lib/ethdev/rte_flow.h | 11 ++++-
7 files changed, 93 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 1496d7a067..d897d0d1d4 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -461,6 +461,8 @@ enum index {
ACTION_POL_R,
ACTION_PORT_REPRESENTOR,
ACTION_PORT_REPRESENTOR_PORT_ID,
+ ACTION_REPRESENTED_PORT,
+ ACTION_REPRESENTED_PORT_ETHDEV_PORT_ID,
};
/** Maximum size for pattern in struct rte_flow_item_raw. */
@@ -1454,6 +1456,7 @@ static const enum index next_action[] = {
ACTION_CONNTRACK,
ACTION_CONNTRACK_UPDATE,
ACTION_PORT_REPRESENTOR,
+ ACTION_REPRESENTED_PORT,
ZERO,
};
@@ -1740,6 +1743,12 @@ static const enum index action_port_representor[] = {
ZERO,
};
+static const enum index action_represented_port[] = {
+ ACTION_REPRESENTED_PORT_ETHDEV_PORT_ID,
+ ACTION_NEXT,
+ ZERO,
+};
+
static int parse_set_raw_encap_decap(struct context *, const struct token *,
const char *, unsigned int,
void *, unsigned int);
@@ -4836,6 +4845,23 @@ static const struct token token_list[] = {
port_id)),
.call = parse_vc_conf,
},
+ [ACTION_REPRESENTED_PORT] = {
+ .name = "represented_port",
+ .help = "at embedded switch level, send matching traffic to the entity represented by the given ethdev",
+ .priv = PRIV_ACTION(REPRESENTED_PORT,
+ sizeof(struct rte_flow_action_ethdev)),
+ .next = NEXT(action_represented_port),
+ .call = parse_vc,
+ },
+ [ACTION_REPRESENTED_PORT_ETHDEV_PORT_ID] = {
+ .name = "ethdev_port_id",
+ .help = "ethdev port ID",
+ .next = NEXT(action_represented_port,
+ NEXT_ENTRY(COMMON_UNSIGNED)),
+ .args = ARGS(ARGS_ENTRY(struct rte_flow_action_ethdev,
+ port_id)),
+ .call = parse_vc_conf,
+ },
/* Indirect action destroy arguments. */
[INDIRECT_ACTION_DESTROY_ID] = {
.name = "action_id",
diff --git a/doc/guides/nics/features/default.ini b/doc/guides/nics/features/default.ini
index 0868c14a4c..3abac9d460 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -192,3 +192,4 @@ vf =
vxlan_decap =
vxlan_encap =
port_representor =
+represented_port =
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 587ed37c2c..27a17fac58 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1532,6 +1532,8 @@ at the opposite end of the "wire" leading to the ethdev.
This item is meant to use the same structure as `Item: PORT_REPRESENTOR`_.
+See also `Action: REPRESENTED_PORT`_.
+
Actions
~~~~~~~
@@ -3145,6 +3147,53 @@ at the opposite end of the "wire" leading to the ethdev.
See also `Item: PORT_REPRESENTOR`_.
+Action: ``REPRESENTED_PORT``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+At embedded switch level, send matching traffic to
+the entity represented by the given ethdev.
+
+Term **ethdev** and the concept of **port representor** are synonymous.
+The **represented port** is an *entity* plugged to the embedded switch
+at the opposite end of the "wire" leading to the ethdev.
+
+::
+
+ .--------------------.
+ | PORT_REPRESENTOR | Ethdev (Application Port Referred to by its ID)
+ '--------------------'
+ :
+ :
+ .----------------.
+ | Logical Port |
+ '----------------'
+ :
+ :
+ :
+ :
+ .----------. .--------------------.
+ | Switch | <== | Matching Traffic |
+ '----------' '--------------------'
+ ||
+ ||
+ ||
+ \/
+ .----------------.
+ | Logical Port |
+ '----------------'
+ ||
+ \/
+ .--------------------.
+ | REPRESENTED_PORT | Net / Guest / Another Ethdev (Same Application)
+ '--------------------'
+
+
+- Requires `Attribute: Transfer`_.
+
+This action is meant to use the same structure as `Action: PORT_REPRESENTOR`_.
+
+See also `Item: REPRESENTED_PORT`_.
+
Negative types
~~~~~~~~~~~~~~
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index 9a0ab97914..6c15afc1e9 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -252,7 +252,7 @@ API Changes
the crypto/security operation. This field will be used to communicate
events such as soft expiry with IPsec in lookaside mode.
-* ethdev: Added items ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` and action ``PORT_REPRESENTOR`` to flow API.
+* ethdev: Added items and actions ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` to flow API.
ABI Changes
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 46b7f07cbc..22ba8f0516 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -4090,6 +4090,11 @@ This section lists supported actions and their attributes, if any.
- ``port_id {unsigned}``: ethdev port ID
+- ``represented_port``: at embedded switch level, send matching traffic to
+ the entity represented by the given ethdev
+
+ - ``ethdev_port_id {unsigned}``: ethdev port ID
+
Destroying flow rules
~~~~~~~~~~~~~~~~~~~~~
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index b074b1c77d..542e40e496 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -192,6 +192,7 @@ static const struct rte_flow_desc_data rte_flow_desc_action[] = {
MK_FLOW_ACTION(INDIRECT, 0),
MK_FLOW_ACTION(CONNTRACK, sizeof(struct rte_flow_action_conntrack)),
MK_FLOW_ACTION(PORT_REPRESENTOR, sizeof(struct rte_flow_action_ethdev)),
+ MK_FLOW_ACTION(REPRESENTED_PORT, sizeof(struct rte_flow_action_ethdev)),
};
int
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 56fd4393e5..ff32c0a5ee 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -2462,6 +2462,14 @@ enum rte_flow_action_type {
* @see struct rte_flow_action_ethdev
*/
RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR,
+
+ /**
+ * At embedded switch level, send matching traffic to
+ * the entity represented by the given ethdev.
+ *
+ * @see struct rte_flow_action_ethdev
+ */
+ RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT,
};
/**
@@ -3212,7 +3220,8 @@ struct rte_flow_action_meter_color {
* @b EXPERIMENTAL: this structure may change without prior notice
*
* Provides an ethdev port ID for use with the following actions:
- * RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR.
+ * RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR,
+ * RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT.
*/
struct rte_flow_action_ethdev {
uint16_t port_id; /**< ethdev port ID */
--
2.20.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v6 03/12] ethdev: add port representor action to flow API
2021-10-13 17:02 4% ` [dpdk-dev] [PATCH v6 01/12] ethdev: add port representor item to " Ivan Malov
2021-10-13 17:02 4% ` [dpdk-dev] [PATCH v6 02/12] ethdev: add represented port " Ivan Malov
@ 2021-10-13 17:02 4% ` Ivan Malov
2021-10-13 17:02 4% ` [dpdk-dev] [PATCH v6 04/12] ethdev: add represented port " Ivan Malov
` (2 subsequent siblings)
5 siblings, 0 replies; 200+ results
From: Ivan Malov @ 2021-10-13 17:02 UTC (permalink / raw)
To: dev; +Cc: Ferruh Yigit, Thomas Monjalon, Ori Kam, Andrew Rybchenko, Xiaoyun Li
For use in "transfer" flows. Supposed to send matching traffic to
the given ethdev (to the application), at embedded switch level.
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
app/test-pmd/cmdline_flow.c | 26 ++++++++++
doc/guides/nics/features/default.ini | 1 +
doc/guides/prog_guide/rte_flow.rst | 56 +++++++++++++++++++++
doc/guides/rel_notes/release_21_11.rst | 2 +-
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 5 ++
lib/ethdev/rte_flow.c | 1 +
lib/ethdev/rte_flow.h | 18 +++++++
7 files changed, 108 insertions(+), 1 deletion(-)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 354f0fb2d7..1496d7a067 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -459,6 +459,8 @@ enum index {
ACTION_POL_G,
ACTION_POL_Y,
ACTION_POL_R,
+ ACTION_PORT_REPRESENTOR,
+ ACTION_PORT_REPRESENTOR_PORT_ID,
};
/** Maximum size for pattern in struct rte_flow_item_raw. */
@@ -1451,6 +1453,7 @@ static const enum index next_action[] = {
ACTION_MODIFY_FIELD,
ACTION_CONNTRACK,
ACTION_CONNTRACK_UPDATE,
+ ACTION_PORT_REPRESENTOR,
ZERO,
};
@@ -1731,6 +1734,12 @@ static const enum index action_update_conntrack[] = {
ZERO,
};
+static const enum index action_port_representor[] = {
+ ACTION_PORT_REPRESENTOR_PORT_ID,
+ ACTION_NEXT,
+ ZERO,
+};
+
static int parse_set_raw_encap_decap(struct context *, const struct token *,
const char *, unsigned int,
void *, unsigned int);
@@ -4810,6 +4819,23 @@ static const struct token token_list[] = {
.next = NEXT(action_update_conntrack),
.call = parse_vc_action_conntrack_update,
},
+ [ACTION_PORT_REPRESENTOR] = {
+ .name = "port_representor",
+ .help = "at embedded switch level, send matching traffic to the given ethdev",
+ .priv = PRIV_ACTION(PORT_REPRESENTOR,
+ sizeof(struct rte_flow_action_ethdev)),
+ .next = NEXT(action_port_representor),
+ .call = parse_vc,
+ },
+ [ACTION_PORT_REPRESENTOR_PORT_ID] = {
+ .name = "port_id",
+ .help = "ethdev port ID",
+ .next = NEXT(action_port_representor,
+ NEXT_ENTRY(COMMON_UNSIGNED)),
+ .args = ARGS(ARGS_ENTRY(struct rte_flow_action_ethdev,
+ port_id)),
+ .call = parse_vc_conf,
+ },
/* Indirect action destroy arguments. */
[INDIRECT_ACTION_DESTROY_ID] = {
.name = "action_id",
diff --git a/doc/guides/nics/features/default.ini b/doc/guides/nics/features/default.ini
index 365d9b7a39..0868c14a4c 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -191,3 +191,4 @@ set_ttl =
vf =
vxlan_decap =
vxlan_encap =
+port_representor =
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 2da286dce8..587ed37c2c 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1484,6 +1484,8 @@ at the opposite end of the "wire" leading to the ethdev.
- Default ``mask`` provides exact match behaviour.
+See also `Action: PORT_REPRESENTOR`_.
+
Item: ``REPRESENTED_PORT``
^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -3089,6 +3091,60 @@ which is set in the packet meta-data (i.e. struct ``rte_mbuf::sched::color``)
| ``meter_color`` | Packet color |
+-----------------+--------------+
+Action: ``PORT_REPRESENTOR``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+At embedded switch level, send matching traffic to the given ethdev.
+
+Term **ethdev** and the concept of **port representor** are synonymous.
+The **represented port** is an *entity* plugged to the embedded switch
+at the opposite end of the "wire" leading to the ethdev.
+
+::
+
+ .--------------------.
+ | PORT_REPRESENTOR | Ethdev (Application Port Referred to by its ID)
+ '--------------------'
+ /\
+ ||
+ .----------------.
+ | Logical Port |
+ '----------------'
+ /\
+ ||
+ ||
+ ||
+ .----------. .--------------------.
+ | Switch | <== | Matching Traffic |
+ '----------' '--------------------'
+ :
+ :
+ :
+ :
+ .----------------.
+ | Logical Port |
+ '----------------'
+ :
+ :
+ .--------------------.
+ | REPRESENTED_PORT | Net / Guest / Another Ethdev (Same Application)
+ '--------------------'
+
+
+- Requires `Attribute: Transfer`_.
+
+.. _table_rte_flow_action_ethdev:
+
+.. table:: ``struct rte_flow_action_ethdev``
+
+ +-------------+----------------+
+ | Field | Value |
+ +=============+================+
+ | ``port_id`` | ethdev port ID |
+ +-------------+----------------+
+
+See also `Item: PORT_REPRESENTOR`_.
+
Negative types
~~~~~~~~~~~~~~
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index b9f918cab8..9a0ab97914 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -252,7 +252,7 @@ API Changes
the crypto/security operation. This field will be used to communicate
events such as soft expiry with IPsec in lookaside mode.
-* ethdev: Added items ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` to flow API.
+* ethdev: Added items ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` and action ``PORT_REPRESENTOR`` to flow API.
ABI Changes
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 61669d1d5a..46b7f07cbc 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -4085,6 +4085,11 @@ This section lists supported actions and their attributes, if any.
- ``type {value}``: Set color type with specified value(green/yellow/red)
+- ``port_representor``: at embedded switch level, send matching traffic to
+ the given ethdev
+
+ - ``port_id {unsigned}``: ethdev port ID
+
Destroying flow rules
~~~~~~~~~~~~~~~~~~~~~
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index d4b654a2c6..b074b1c77d 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -191,6 +191,7 @@ static const struct rte_flow_desc_data rte_flow_desc_action[] = {
*/
MK_FLOW_ACTION(INDIRECT, 0),
MK_FLOW_ACTION(CONNTRACK, sizeof(struct rte_flow_action_conntrack)),
+ MK_FLOW_ACTION(PORT_REPRESENTOR, sizeof(struct rte_flow_action_ethdev)),
};
int
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index b50c3d38b5..56fd4393e5 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -2455,6 +2455,13 @@ enum rte_flow_action_type {
* See struct rte_flow_action_meter_color.
*/
RTE_FLOW_ACTION_TYPE_METER_COLOR,
+
+ /**
+ * At embedded switch level, sends matching traffic to the given ethdev.
+ *
+ * @see struct rte_flow_action_ethdev
+ */
+ RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR,
};
/**
@@ -3200,6 +3207,17 @@ struct rte_flow_action_meter_color {
enum rte_color color; /**< Packet color. */
};
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * Provides an ethdev port ID for use with the following actions:
+ * RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR.
+ */
+struct rte_flow_action_ethdev {
+ uint16_t port_id; /**< ethdev port ID */
+};
+
/**
* Field IDs for MODIFY_FIELD action.
*/
--
2.20.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v6 02/12] ethdev: add represented port item to flow API
2021-10-13 17:02 4% ` [dpdk-dev] [PATCH v6 01/12] ethdev: add port representor item to " Ivan Malov
@ 2021-10-13 17:02 4% ` Ivan Malov
2021-10-13 17:02 4% ` [dpdk-dev] [PATCH v6 03/12] ethdev: add port representor action " Ivan Malov
` (3 subsequent siblings)
5 siblings, 0 replies; 200+ results
From: Ivan Malov @ 2021-10-13 17:02 UTC (permalink / raw)
To: dev; +Cc: Ferruh Yigit, Thomas Monjalon, Ori Kam, Andrew Rybchenko, Xiaoyun Li
For use in "transfer" flows. Supposed to match traffic entering the
embedded switch from the entity represented by the given ethdev.
Such an entity can be a network (via a network port), a guest
machine (via a VF) or another ethdev in the same application.
Must not be combined with direction attributes.
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
app/test-pmd/cmdline_flow.c | 25 +++++++++++
doc/guides/nics/features/default.ini | 1 +
doc/guides/prog_guide/rte_flow.rst | 46 +++++++++++++++++++++
doc/guides/rel_notes/release_21_11.rst | 2 +-
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 5 +++
lib/ethdev/rte_flow.c | 1 +
lib/ethdev/rte_flow.h | 13 +++++-
7 files changed, 91 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 5c480db91d..354f0fb2d7 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -308,6 +308,8 @@ enum index {
ITEM_POL_POLICY,
ITEM_PORT_REPRESENTOR,
ITEM_PORT_REPRESENTOR_PORT_ID,
+ ITEM_REPRESENTED_PORT,
+ ITEM_REPRESENTED_PORT_ETHDEV_PORT_ID,
/* Validate/create actions. */
ACTIONS,
@@ -1002,6 +1004,7 @@ static const enum index next_item[] = {
ITEM_INTEGRITY,
ITEM_CONNTRACK,
ITEM_PORT_REPRESENTOR,
+ ITEM_REPRESENTED_PORT,
END_SET,
ZERO,
};
@@ -1376,6 +1379,12 @@ static const enum index item_port_representor[] = {
ZERO,
};
+static const enum index item_represented_port[] = {
+ ITEM_REPRESENTED_PORT_ETHDEV_PORT_ID,
+ ITEM_NEXT,
+ ZERO,
+};
+
static const enum index next_action[] = {
ACTION_END,
ACTION_VOID,
@@ -3630,6 +3639,21 @@ static const struct token token_list[] = {
item_param),
.args = ARGS(ARGS_ENTRY(struct rte_flow_item_ethdev, port_id)),
},
+ [ITEM_REPRESENTED_PORT] = {
+ .name = "represented_port",
+ .help = "match traffic entering the embedded switch from the entity represented by the given ethdev",
+ .priv = PRIV_ITEM(REPRESENTED_PORT,
+ sizeof(struct rte_flow_item_ethdev)),
+ .next = NEXT(item_represented_port),
+ .call = parse_vc,
+ },
+ [ITEM_REPRESENTED_PORT_ETHDEV_PORT_ID] = {
+ .name = "ethdev_port_id",
+ .help = "ethdev port ID",
+ .next = NEXT(item_represented_port, NEXT_ENTRY(COMMON_UNSIGNED),
+ item_param),
+ .args = ARGS(ARGS_ENTRY(struct rte_flow_item_ethdev, port_id)),
+ },
/* Validate/create actions. */
[ACTIONS] = {
.name = "actions",
@@ -8358,6 +8382,7 @@ flow_item_default_mask(const struct rte_flow_item *item)
mask = &rte_flow_item_pfcp_mask;
break;
case RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR:
+ case RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT:
mask = &rte_flow_item_ethdev_mask;
break;
default:
diff --git a/doc/guides/nics/features/default.ini b/doc/guides/nics/features/default.ini
index 9b53a887a4..365d9b7a39 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -133,6 +133,7 @@ vlan =
vxlan =
vxlan_gpe =
port_representor =
+represented_port =
[rte_flow actions]
age =
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index d194640469..2da286dce8 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1484,6 +1484,52 @@ at the opposite end of the "wire" leading to the ethdev.
- Default ``mask`` provides exact match behaviour.
+Item: ``REPRESENTED_PORT``
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Matches traffic entering the embedded switch from
+the entity represented by the given ethdev.
+
+Term **ethdev** and the concept of **port representor** are synonymous.
+The **represented port** is an *entity* plugged to the embedded switch
+at the opposite end of the "wire" leading to the ethdev.
+
+::
+
+ .--------------------.
+ | PORT_REPRESENTOR | Ethdev (Application Port Referred to by its ID)
+ '--------------------'
+ :
+ :
+ .----------------.
+ | Logical Port |
+ '----------------'
+ :
+ :
+ :
+ :
+ .----------.
+ | Switch |
+ '----------'
+ /\
+ ||
+ ||
+ ||
+ .----------------.
+ | Logical Port |
+ '----------------'
+ /\
+ ||
+ .--------------------.
+ | REPRESENTED_PORT | Net / Guest / Another Ethdev (Same Application)
+ '--------------------'
+
+
+- Incompatible with `Attribute: Traffic direction`_.
+- Requires `Attribute: Transfer`_.
+
+This item is meant to use the same structure as `Item: PORT_REPRESENTOR`_.
+
Actions
~~~~~~~
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index 07f9d39a5b..b9f918cab8 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -252,7 +252,7 @@ API Changes
the crypto/security operation. This field will be used to communicate
events such as soft expiry with IPsec in lookaside mode.
-* ethdev: Added item ``PORT_REPRESENTOR`` to flow API.
+* ethdev: Added items ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` to flow API.
ABI Changes
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 90765f9090..61669d1d5a 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -3805,6 +3805,11 @@ This section lists supported pattern items and their attributes, if any.
- ``port_id {unsigned}``: ethdev port ID
+- ``represented_port``: match traffic entering the embedded switch from
+ the entity represented by the given ethdev
+
+ - ``ethdev_port_id {unsigned}``: ethdev port ID
+
Actions list
^^^^^^^^^^^^
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index 5e9317c6d1..d4b654a2c6 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -101,6 +101,7 @@ static const struct rte_flow_desc_data rte_flow_desc_item[] = {
MK_FLOW_ITEM(INTEGRITY, sizeof(struct rte_flow_item_integrity)),
MK_FLOW_ITEM(CONNTRACK, sizeof(uint32_t)),
MK_FLOW_ITEM(PORT_REPRESENTOR, sizeof(struct rte_flow_item_ethdev)),
+ MK_FLOW_ITEM(REPRESENTED_PORT, sizeof(struct rte_flow_item_ethdev)),
};
/** Generate flow_action[] entry. */
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 1e3ef77ead..b50c3d38b5 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -583,6 +583,16 @@ enum rte_flow_item_type {
* @see struct rte_flow_item_ethdev
*/
RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR,
+
+ /**
+ * [META]
+ *
+ * Matches traffic entering the embedded switch from
+ * the entity represented by the given ethdev.
+ *
+ * @see struct rte_flow_item_ethdev
+ */
+ RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT,
};
/**
@@ -1813,7 +1823,8 @@ static const struct rte_flow_item_conntrack rte_flow_item_conntrack_mask = {
* @b EXPERIMENTAL: this structure may change without prior notice
*
* Provides an ethdev port ID for use with the following items:
- * RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR.
+ * RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR,
+ * RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT.
*/
struct rte_flow_item_ethdev {
uint16_t port_id; /**< ethdev port ID */
--
2.20.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v6 01/12] ethdev: add port representor item to flow API
@ 2021-10-13 17:02 4% ` Ivan Malov
2021-10-13 17:02 4% ` [dpdk-dev] [PATCH v6 02/12] ethdev: add represented port " Ivan Malov
` (4 subsequent siblings)
5 siblings, 0 replies; 200+ results
From: Ivan Malov @ 2021-10-13 17:02 UTC (permalink / raw)
To: dev; +Cc: Ferruh Yigit, Thomas Monjalon, Ori Kam, Andrew Rybchenko, Xiaoyun Li
For use in "transfer" flows. Supposed to match traffic
entering the embedded switch from the given ethdev.
Must not be combined with direction attributes.
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
app/test-pmd/cmdline_flow.c | 27 ++++++++++
doc/guides/nics/features/default.ini | 1 +
doc/guides/prog_guide/rte_flow.rst | 59 +++++++++++++++++++++
doc/guides/rel_notes/release_21_11.rst | 2 +
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 4 ++
lib/ethdev/rte_flow.c | 1 +
lib/ethdev/rte_flow.h | 27 ++++++++++
7 files changed, 121 insertions(+)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 0b5856c7d5..5c480db91d 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -306,6 +306,8 @@ enum index {
ITEM_POL_PORT,
ITEM_POL_METER,
ITEM_POL_POLICY,
+ ITEM_PORT_REPRESENTOR,
+ ITEM_PORT_REPRESENTOR_PORT_ID,
/* Validate/create actions. */
ACTIONS,
@@ -999,6 +1001,7 @@ static const enum index next_item[] = {
ITEM_GENEVE_OPT,
ITEM_INTEGRITY,
ITEM_CONNTRACK,
+ ITEM_PORT_REPRESENTOR,
END_SET,
ZERO,
};
@@ -1367,6 +1370,12 @@ static const enum index item_integrity_lv[] = {
ZERO,
};
+static const enum index item_port_representor[] = {
+ ITEM_PORT_REPRESENTOR_PORT_ID,
+ ITEM_NEXT,
+ ZERO,
+};
+
static const enum index next_action[] = {
ACTION_END,
ACTION_VOID,
@@ -3606,6 +3615,21 @@ static const struct token token_list[] = {
item_param),
.args = ARGS(ARGS_ENTRY(struct rte_flow_item_conntrack, flags)),
},
+ [ITEM_PORT_REPRESENTOR] = {
+ .name = "port_representor",
+ .help = "match traffic entering the embedded switch from the given ethdev",
+ .priv = PRIV_ITEM(PORT_REPRESENTOR,
+ sizeof(struct rte_flow_item_ethdev)),
+ .next = NEXT(item_port_representor),
+ .call = parse_vc,
+ },
+ [ITEM_PORT_REPRESENTOR_PORT_ID] = {
+ .name = "port_id",
+ .help = "ethdev port ID",
+ .next = NEXT(item_port_representor, NEXT_ENTRY(COMMON_UNSIGNED),
+ item_param),
+ .args = ARGS(ARGS_ENTRY(struct rte_flow_item_ethdev, port_id)),
+ },
/* Validate/create actions. */
[ACTIONS] = {
.name = "actions",
@@ -8333,6 +8357,9 @@ flow_item_default_mask(const struct rte_flow_item *item)
case RTE_FLOW_ITEM_TYPE_PFCP:
mask = &rte_flow_item_pfcp_mask;
break;
+ case RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR:
+ mask = &rte_flow_item_ethdev_mask;
+ break;
default:
break;
}
diff --git a/doc/guides/nics/features/default.ini b/doc/guides/nics/features/default.ini
index d473b94091..9b53a887a4 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -132,6 +132,7 @@ vf =
vlan =
vxlan =
vxlan_gpe =
+port_representor =
[rte_flow actions]
age =
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 3cb014c1fa..d194640469 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1425,6 +1425,65 @@ Matches a conntrack state after conntrack action.
- ``flags``: conntrack packet state flags.
- Default ``mask`` matches all state bits.
+Item: ``PORT_REPRESENTOR``
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Matches traffic entering the embedded switch from the given ethdev.
+
+Term **ethdev** and the concept of **port representor** are synonymous.
+The **represented port** is an *entity* plugged to the embedded switch
+at the opposite end of the "wire" leading to the ethdev.
+
+::
+
+ .--------------------.
+ | PORT_REPRESENTOR | Ethdev (Application Port Referred to by its ID)
+ '--------------------'
+ ||
+ \/
+ .----------------.
+ | Logical Port |
+ '----------------'
+ ||
+ ||
+ ||
+ \/
+ .----------.
+ | Switch |
+ '----------'
+ :
+ :
+ :
+ :
+ .----------------.
+ | Logical Port |
+ '----------------'
+ :
+ :
+ .--------------------.
+ | REPRESENTED_PORT | Net / Guest / Another Ethdev (Same Application)
+ '--------------------'
+
+
+- Incompatible with `Attribute: Traffic direction`_.
+- Requires `Attribute: Transfer`_.
+
+.. _table_rte_flow_item_ethdev:
+
+.. table:: ``struct rte_flow_item_ethdev``
+
+ +----------+-------------+---------------------------+
+ | Field | Subfield | Value |
+ +==========+=============+===========================+
+ | ``spec`` | ``port_id`` | ethdev port ID |
+ +----------+-------------+---------------------------+
+ | ``last`` | ``port_id`` | upper range value |
+ +----------+-------------+---------------------------+
+ | ``mask`` | ``port_id`` | zeroed for wildcard match |
+ +----------+-------------+---------------------------+
+
+- Default ``mask`` provides exact match behaviour.
+
Actions
~~~~~~~
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index d5c762df62..07f9d39a5b 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -252,6 +252,8 @@ API Changes
the crypto/security operation. This field will be used to communicate
events such as soft expiry with IPsec in lookaside mode.
+* ethdev: Added item ``PORT_REPRESENTOR`` to flow API.
+
ABI Changes
-----------
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index a0efb7d0b0..90765f9090 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -3801,6 +3801,10 @@ This section lists supported pattern items and their attributes, if any.
- ``conntrack``: match conntrack state.
+- ``port_representor``: match traffic entering the embedded switch from the given ethdev
+
+ - ``port_id {unsigned}``: ethdev port ID
+
Actions list
^^^^^^^^^^^^
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index 8cb7a069c8..5e9317c6d1 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -100,6 +100,7 @@ static const struct rte_flow_desc_data rte_flow_desc_item[] = {
MK_FLOW_ITEM(GENEVE_OPT, sizeof(struct rte_flow_item_geneve_opt)),
MK_FLOW_ITEM(INTEGRITY, sizeof(struct rte_flow_item_integrity)),
MK_FLOW_ITEM(CONNTRACK, sizeof(uint32_t)),
+ MK_FLOW_ITEM(PORT_REPRESENTOR, sizeof(struct rte_flow_item_ethdev)),
};
/** Generate flow_action[] entry. */
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 5f87851f8c..1e3ef77ead 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -574,6 +574,15 @@ enum rte_flow_item_type {
* @see struct rte_flow_item_conntrack.
*/
RTE_FLOW_ITEM_TYPE_CONNTRACK,
+
+ /**
+ * [META]
+ *
+ * Matches traffic entering the embedded switch from the given ethdev.
+ *
+ * @see struct rte_flow_item_ethdev
+ */
+ RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR,
};
/**
@@ -1799,6 +1808,24 @@ static const struct rte_flow_item_conntrack rte_flow_item_conntrack_mask = {
};
#endif
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * Provides an ethdev port ID for use with the following items:
+ * RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR.
+ */
+struct rte_flow_item_ethdev {
+ uint16_t port_id; /**< ethdev port ID */
+};
+
+/** Default mask for items based on struct rte_flow_item_ethdev */
+#ifndef __cplusplus
+static const struct rte_flow_item_ethdev rte_flow_item_ethdev_mask = {
+ .port_id = 0xffff,
+};
+#endif
+
/**
* Matching pattern item definition.
*
--
2.20.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v5 06/12] ethdev: deprecate direction attributes in transfer flows
` (4 preceding siblings ...)
2021-10-13 16:57 3% ` [dpdk-dev] [PATCH v5 05/12] ethdev: deprecate hard-to-use or ambiguous items and actions Ivan Malov
@ 2021-10-13 16:57 3% ` Ivan Malov
5 siblings, 0 replies; 200+ results
From: Ivan Malov @ 2021-10-13 16:57 UTC (permalink / raw)
To: dev
Cc: Ferruh Yigit, Thomas Monjalon, Ori Kam, Andrew Rybchenko, Ray Kinsella
Attributes "ingress" and "egress" can only apply unambiguosly
to non-"transfer" flows. In "transfer" flows, the standpoint
is effectively shifted to the embedded switch. There can be
many different endpoints connected to the switch, so the
use of "ingress" / "egress" does not shed light on which
endpoints precisely can be considered as traffic sources.
Add relevant deprecation notices and suggest the use of precise
traffic source items (PORT_REPRESENTOR and REPRESENTED_PORT).
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
doc/guides/prog_guide/rte_flow.rst | 28 ++++++++----------
doc/guides/rel_notes/deprecation.rst | 9 +++---
doc/guides/rel_notes/release_21_11.rst | 3 ++
lib/ethdev/rte_flow.h | 41 ++++++++++++++++++++------
4 files changed, 52 insertions(+), 29 deletions(-)
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index d7185c49df..5957b8df4f 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -9,8 +9,8 @@ Overview
--------
This API provides a generic means to configure hardware to match specific
-ingress or egress traffic, alter its fate and query related counters
-according to any number of user-defined rules.
+traffic, alter its fate and query related counters according to any
+number of user-defined rules.
It is named *rte_flow* after the prefix used for all its symbols, and is
defined in ``rte_flow.h``.
@@ -146,13 +146,10 @@ Note that support for more than a single priority level is not guaranteed.
Attribute: Traffic direction
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Flow rule patterns apply to inbound and/or outbound traffic.
-
-In the context of this API, **ingress** and **egress** respectively stand
-for **inbound** and **outbound** based on the standpoint of the application
-creating a flow rule.
-
-There are no exceptions to this definition.
+Unless `Attribute: Transfer`_ is specified, flow rule patterns apply
+to inbound and / or outbound traffic. With this respect, ``ingress``
+and ``egress`` respectively stand for **inbound** and **outbound**
+based on the standpoint of the application creating a flow rule.
Several pattern items and actions are valid and can be used in both
directions. At least one direction must be specified.
@@ -171,12 +168,13 @@ When supported, this effectively enables an application to reroute traffic
not necessarily intended for it (e.g. coming from or addressed to different
physical ports, VFs or applications) at the device level.
-It complements the behavior of some pattern items such as `Item: PHY_PORT`_
-and is meaningless without them.
-
-When transferring flow rules, **ingress** and **egress** attributes
-(`Attribute: Traffic direction`_) keep their original meaning, as if
-processing traffic emitted or received by the application.
+In "transfer" flows, the use of `Attribute: Traffic direction`_ in the sense of
+implicitly matching packets going to or going from the ethdev used to create
+flow rules is **deprecated**. `Attribute: Transfer`_ shifts the viewpoint to
+the embedded switch. In it, `Attribute: Traffic direction`_ is ambiguous as
+the switch serves many different endpoints. The application should match
+traffic originating from precise locations. To do so, it should
+use `Item: PORT_REPRESENTOR`_ and `Item: REPRESENTED_PORT`_.
Pattern item
~~~~~~~~~~~~
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 25aec56bec..ef2e2c1141 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -113,11 +113,6 @@ Deprecation Notices
to support modifying fields larger than 64 bits.
In addition, documentation will be updated to clarify byte order.
-* ethdev: Flow API documentation is unclear if ethdev port used to create
- a flow rule adds any implicit match criteria in the case of transfer rules.
- The semantics will be clarified in DPDK 21.11 and it will require fixes in
- drivers and applications which interpret it in a different way.
-
* ethdev: The flow API matching pattern structures, ``struct rte_flow_item_*``,
should start with relevant protocol header.
Some matching pattern structures implements this by duplicating protocol header
@@ -146,6 +141,10 @@ Deprecation Notices
* ethdev: Items and actions ``PF``, ``VF``, ``PHY_PORT``, ``PORT_ID`` are
deprecated as hard-to-use / ambiguous and will be removed in DPDK 22.11.
+* ethdev: The use of attributes ``ingress`` / ``egress`` in "transfer" flows
+ is deprecated as ambiguous with respect to the embedded switch. The use of
+ these attributes will become invalid starting from DPDK 22.11.
+
* net: The structure ``rte_ipv4_hdr`` will have two unions.
The first union is for existing ``version_ihl`` byte
and new bitfield for version and IHL.
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index 75c4f6d018..45c019eb04 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -257,6 +257,9 @@ API Changes
* ethdev: Deprecated items and actions ``PF``, ``VF``, ``PHY_PORT``, ``PORT_ID``.
Suggested items and actions ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` instead.
+* ethdev: Deprecated the use of attributes ``ingress`` / ``egress`` combined
+ with ``transfer``. See items ``PORT_REPRESENTOR``, ``REPRESENTED_PORT``.
+
ABI Changes
-----------
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 76653105a0..7e7b4bce5b 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -67,7 +67,10 @@ extern "C" {
* Note that support for more than a single group and priority level is not
* guaranteed.
*
- * Flow rules can apply to inbound and/or outbound traffic (ingress/egress).
+ * At vNIC / ethdev level, flow rules can apply to inbound and / or outbound
+ * traffic (ingress / egress), with respect to the vNIC / ethdev in question.
+ * At embedded switch level, flow rules apply to all traffic seen by it
+ * unless fitting meta items are used to set concrete traffic source(s).
*
* Several pattern items and actions are valid and can be used in both
* directions. Those valid for only one direction are described as such.
@@ -80,8 +83,32 @@ extern "C" {
struct rte_flow_attr {
uint32_t group; /**< Priority group. */
uint32_t priority; /**< Rule priority level within group. */
- uint32_t ingress:1; /**< Rule applies to ingress traffic. */
- uint32_t egress:1; /**< Rule applies to egress traffic. */
+ /**
+ * The rule in question applies to ingress traffic (non-"transfer").
+ *
+ * @deprecated
+ * It has been possible to combine this attribute with "transfer".
+ * Doing so has been assumed to restrict the scope of matching
+ * to traffic going from within the embedded switch toward the
+ * ethdev the flow rule being created through. This behaviour
+ * is deprecated. During the transition period, one may still
+ * rely on it, but PMDs and applications are encouraged to
+ * gradually move away from this approach.
+ */
+ uint32_t ingress:1;
+ /**
+ * The rule in question applies to egress traffic (non-"transfer").
+ *
+ * @deprecated
+ * It has been possible to combine this attribute with "transfer".
+ * Doing so has been assumed to restrict the scope of matching
+ * to traffic sent by the application by virtue of the ethdev
+ * the flow rule being created through. This behaviour is now
+ * deprecated. During the transition period, one may still
+ * rely on it, but PMDs and applications are encouraged to
+ * gradually move away from this approach.
+ */
+ uint32_t egress:1;
/**
* Instead of simply matching the properties of traffic as it would
* appear on a given DPDK port ID, enabling this attribute transfers
@@ -93,12 +120,8 @@ struct rte_flow_attr {
* from or addressed to different physical ports, VFs or
* applications) at the device level.
*
- * It complements the behavior of some pattern items such as
- * RTE_FLOW_ITEM_TYPE_PHY_PORT and is meaningless without them.
- *
- * When transferring flow rules, ingress and egress attributes keep
- * their original meaning, as if processing traffic emitted or
- * received by the application.
+ * The application should match traffic originating from precise
+ * locations. See items PORT_REPRESENTOR and REPRESENTED_PORT.
*/
uint32_t transfer:1;
uint32_t reserved:29; /**< Reserved, must be zero. */
--
2.20.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v5 05/12] ethdev: deprecate hard-to-use or ambiguous items and actions
` (3 preceding siblings ...)
2021-10-13 16:57 4% ` [dpdk-dev] [PATCH v5 04/12] ethdev: add represented port " Ivan Malov
@ 2021-10-13 16:57 3% ` Ivan Malov
2021-10-13 16:57 3% ` [dpdk-dev] [PATCH v5 06/12] ethdev: deprecate direction attributes in transfer flows Ivan Malov
5 siblings, 0 replies; 200+ results
From: Ivan Malov @ 2021-10-13 16:57 UTC (permalink / raw)
To: dev
Cc: Ferruh Yigit, Thomas Monjalon, Ori Kam, Andrew Rybchenko, Ray Kinsella
PF, VF and PHY_PORT require that applications have extra
knowledge of the underlying NIC and thus are hard to use.
Also, the corresponding items depend on the direction
attribute (ingress / egress), which complicates their
use in applications and interpretation in PMDs.
The concept of PORT_ID is ambiguous as it doesn't say whether
the port in question is an ethdev or the represented entity.
Items and actions PORT_REPRESENTOR, REPRESENTED_PORT
should be used instead.
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
doc/guides/prog_guide/rte_flow.rst | 32 +++++++++++++++
doc/guides/rel_notes/deprecation.rst | 9 ++---
doc/guides/rel_notes/release_21_11.rst | 3 ++
lib/ethdev/rte_flow.h | 56 ++++++++++++++++++++++++++
4 files changed, 94 insertions(+), 6 deletions(-)
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 27a17fac58..d7185c49df 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -504,6 +504,10 @@ Usage example, matching non-TCPv4 packets only:
Item: ``PF``
^^^^^^^^^^^^
+This item is deprecated. Consider:
+ - `Item: PORT_REPRESENTOR`_
+ - `Item: REPRESENTED_PORT`_
+
Matches traffic originating from (ingress) or going to (egress) the physical
function of the current device.
@@ -531,6 +535,10 @@ the application and thus not associated with a DPDK port ID.
Item: ``VF``
^^^^^^^^^^^^
+This item is deprecated. Consider:
+ - `Item: PORT_REPRESENTOR`_
+ - `Item: REPRESENTED_PORT`_
+
Matches traffic originating from (ingress) or going to (egress) a given
virtual function of the current device.
@@ -562,6 +570,10 @@ separate entities, should be addressed through their own DPDK port IDs.
Item: ``PHY_PORT``
^^^^^^^^^^^^^^^^^^
+This item is deprecated. Consider:
+ - `Item: PORT_REPRESENTOR`_
+ - `Item: REPRESENTED_PORT`_
+
Matches traffic originating from (ingress) or going to (egress) a physical
port of the underlying device.
@@ -596,6 +608,10 @@ associated with a port_id should be retrieved by other means.
Item: ``PORT_ID``
^^^^^^^^^^^^^^^^^
+This item is deprecated. Consider:
+ - `Item: PORT_REPRESENTOR`_
+ - `Item: REPRESENTED_PORT`_
+
Matches traffic originating from (ingress) or going to (egress) a given DPDK
port ID.
@@ -1950,6 +1966,10 @@ only matching traffic goes through.
Action: ``PF``
^^^^^^^^^^^^^^
+This action is deprecated. Consider:
+ - `Action: PORT_REPRESENTOR`_
+ - `Action: REPRESENTED_PORT`_
+
Directs matching traffic to the physical function (PF) of the current
device.
@@ -1970,6 +1990,10 @@ See `Item: PF`_.
Action: ``VF``
^^^^^^^^^^^^^^
+This action is deprecated. Consider:
+ - `Action: PORT_REPRESENTOR`_
+ - `Action: REPRESENTED_PORT`_
+
Directs matching traffic to a given virtual function of the current device.
Packets matched by a VF pattern item can be redirected to their original VF
@@ -1994,6 +2018,10 @@ See `Item: VF`_.
Action: ``PHY_PORT``
^^^^^^^^^^^^^^^^^^^^
+This action is deprecated. Consider:
+ - `Action: PORT_REPRESENTOR`_
+ - `Action: REPRESENTED_PORT`_
+
Directs matching traffic to a given physical port index of the underlying
device.
@@ -2013,6 +2041,10 @@ See `Item: PHY_PORT`_.
Action: ``PORT_ID``
^^^^^^^^^^^^^^^^^^^
+This action is deprecated. Consider:
+ - `Action: PORT_REPRESENTOR`_
+ - `Action: REPRESENTED_PORT`_
+
Directs matching traffic to a given DPDK port ID.
See `Item: PORT_ID`_.
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 5853b5988d..25aec56bec 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -113,12 +113,6 @@ Deprecation Notices
to support modifying fields larger than 64 bits.
In addition, documentation will be updated to clarify byte order.
-* ethdev: Definition of the flow API action ``RTE_FLOW_ACTION_TYPE_PORT_ID``
- is ambiguous and needs clarification.
- Structure ``rte_flow_action_port_id`` will be extended to specify
- traffic direction to the represented entity or ethdev port itself
- in DPDK 21.11.
-
* ethdev: Flow API documentation is unclear if ethdev port used to create
a flow rule adds any implicit match criteria in the case of transfer rules.
The semantics will be clarified in DPDK 21.11 and it will require fixes in
@@ -149,6 +143,9 @@ Deprecation Notices
consistent with existing outer header checksum status flag naming, which
should help in reducing confusion about its usage.
+* ethdev: Items and actions ``PF``, ``VF``, ``PHY_PORT``, ``PORT_ID`` are
+ deprecated as hard-to-use / ambiguous and will be removed in DPDK 22.11.
+
* net: The structure ``rte_ipv4_hdr`` will have two unions.
The first union is for existing ``version_ihl`` byte
and new bitfield for version and IHL.
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index 6c15afc1e9..75c4f6d018 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -254,6 +254,9 @@ API Changes
* ethdev: Added items and actions ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` to flow API.
+* ethdev: Deprecated items and actions ``PF``, ``VF``, ``PHY_PORT``, ``PORT_ID``.
+ Suggested items and actions ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` instead.
+
ABI Changes
-----------
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index ff32c0a5ee..76653105a0 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -160,6 +160,10 @@ enum rte_flow_item_type {
RTE_FLOW_ITEM_TYPE_ANY,
/**
+ * @deprecated
+ * @see RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT
+ *
* [META]
*
* Matches traffic originating from (ingress) or going to (egress)
@@ -170,6 +174,10 @@ enum rte_flow_item_type {
RTE_FLOW_ITEM_TYPE_PF,
/**
+ * @deprecated
+ * @see RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT
+ *
* [META]
*
* Matches traffic originating from (ingress) or going to (egress) a
@@ -180,6 +188,10 @@ enum rte_flow_item_type {
RTE_FLOW_ITEM_TYPE_VF,
/**
+ * @deprecated
+ * @see RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT
+ *
* [META]
*
* Matches traffic originating from (ingress) or going to (egress) a
@@ -190,6 +202,10 @@ enum rte_flow_item_type {
RTE_FLOW_ITEM_TYPE_PHY_PORT,
/**
+ * @deprecated
+ * @see RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT
+ *
* [META]
*
* Matches traffic originating from (ingress) or going to (egress) a
@@ -640,6 +656,10 @@ static const struct rte_flow_item_any rte_flow_item_any_mask = {
#endif
/**
+ * @deprecated
+ * @see RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT
+ *
* RTE_FLOW_ITEM_TYPE_VF
*
* Matches traffic originating from (ingress) or going to (egress) a given
@@ -669,6 +689,10 @@ static const struct rte_flow_item_vf rte_flow_item_vf_mask = {
#endif
/**
+ * @deprecated
+ * @see RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT
+ *
* RTE_FLOW_ITEM_TYPE_PHY_PORT
*
* Matches traffic originating from (ingress) or going to (egress) a
@@ -700,6 +724,10 @@ static const struct rte_flow_item_phy_port rte_flow_item_phy_port_mask = {
#endif
/**
+ * @deprecated
+ * @see RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT
+ *
* RTE_FLOW_ITEM_TYPE_PORT_ID
*
* Matches traffic originating from (ingress) or going to (egress) a given
@@ -1998,6 +2026,10 @@ enum rte_flow_action_type {
RTE_FLOW_ACTION_TYPE_RSS,
/**
+ * @deprecated
+ * @see RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT
+ *
* Directs matching traffic to the physical function (PF) of the
* current device.
*
@@ -2006,6 +2038,10 @@ enum rte_flow_action_type {
RTE_FLOW_ACTION_TYPE_PF,
/**
+ * @deprecated
+ * @see RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT
+ *
* Directs matching traffic to a given virtual function of the
* current device.
*
@@ -2014,6 +2050,10 @@ enum rte_flow_action_type {
RTE_FLOW_ACTION_TYPE_VF,
/**
+ * @deprecated
+ * @see RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT
+ *
* Directs packets to a given physical port index of the underlying
* device.
*
@@ -2022,6 +2062,10 @@ enum rte_flow_action_type {
RTE_FLOW_ACTION_TYPE_PHY_PORT,
/**
+ * @deprecated
+ * @see RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT
+ *
* Directs matching traffic to a given DPDK port ID.
*
* See struct rte_flow_action_port_id.
@@ -2648,6 +2692,10 @@ struct rte_flow_action_rss {
};
/**
+ * @deprecated
+ * @see RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT
+ *
* RTE_FLOW_ACTION_TYPE_VF
*
* Directs matching traffic to a given virtual function of the current
@@ -2666,6 +2714,10 @@ struct rte_flow_action_vf {
};
/**
+ * @deprecated
+ * @see RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT
+ *
* RTE_FLOW_ACTION_TYPE_PHY_PORT
*
* Directs packets to a given physical port index of the underlying
@@ -2680,6 +2732,10 @@ struct rte_flow_action_phy_port {
};
/**
+ * @deprecated
+ * @see RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT
+ *
* RTE_FLOW_ACTION_TYPE_PORT_ID
*
* Directs matching traffic to a given DPDK port ID.
--
2.20.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v5 04/12] ethdev: add represented port action to flow API
` (2 preceding siblings ...)
2021-10-13 16:57 4% ` [dpdk-dev] [PATCH v5 03/12] ethdev: add port representor action " Ivan Malov
@ 2021-10-13 16:57 4% ` Ivan Malov
2021-10-13 16:57 3% ` [dpdk-dev] [PATCH v5 05/12] ethdev: deprecate hard-to-use or ambiguous items and actions Ivan Malov
2021-10-13 16:57 3% ` [dpdk-dev] [PATCH v5 06/12] ethdev: deprecate direction attributes in transfer flows Ivan Malov
5 siblings, 0 replies; 200+ results
From: Ivan Malov @ 2021-10-13 16:57 UTC (permalink / raw)
To: dev; +Cc: Ferruh Yigit, Thomas Monjalon, Ori Kam, Andrew Rybchenko, Xiaoyun Li
For use in "transfer" flows. Supposed to send matching traffic to the
entity represented by the given ethdev, at embedded switch level.
Such an entity can be a network (via a network port), a guest
machine (via a VF) or another ethdev in the same application.
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
app/test-pmd/cmdline_flow.c | 26 +++++++++++
doc/guides/nics/features/default.ini | 1 +
doc/guides/prog_guide/rte_flow.rst | 49 +++++++++++++++++++++
doc/guides/rel_notes/release_21_11.rst | 2 +-
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 5 +++
lib/ethdev/rte_flow.c | 1 +
lib/ethdev/rte_flow.h | 11 ++++-
7 files changed, 93 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 1496d7a067..d897d0d1d4 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -461,6 +461,8 @@ enum index {
ACTION_POL_R,
ACTION_PORT_REPRESENTOR,
ACTION_PORT_REPRESENTOR_PORT_ID,
+ ACTION_REPRESENTED_PORT,
+ ACTION_REPRESENTED_PORT_ETHDEV_PORT_ID,
};
/** Maximum size for pattern in struct rte_flow_item_raw. */
@@ -1454,6 +1456,7 @@ static const enum index next_action[] = {
ACTION_CONNTRACK,
ACTION_CONNTRACK_UPDATE,
ACTION_PORT_REPRESENTOR,
+ ACTION_REPRESENTED_PORT,
ZERO,
};
@@ -1740,6 +1743,12 @@ static const enum index action_port_representor[] = {
ZERO,
};
+static const enum index action_represented_port[] = {
+ ACTION_REPRESENTED_PORT_ETHDEV_PORT_ID,
+ ACTION_NEXT,
+ ZERO,
+};
+
static int parse_set_raw_encap_decap(struct context *, const struct token *,
const char *, unsigned int,
void *, unsigned int);
@@ -4836,6 +4845,23 @@ static const struct token token_list[] = {
port_id)),
.call = parse_vc_conf,
},
+ [ACTION_REPRESENTED_PORT] = {
+ .name = "represented_port",
+ .help = "at embedded switch level, send matching traffic to the entity represented by the given ethdev",
+ .priv = PRIV_ACTION(REPRESENTED_PORT,
+ sizeof(struct rte_flow_action_ethdev)),
+ .next = NEXT(action_represented_port),
+ .call = parse_vc,
+ },
+ [ACTION_REPRESENTED_PORT_ETHDEV_PORT_ID] = {
+ .name = "ethdev_port_id",
+ .help = "ethdev port ID",
+ .next = NEXT(action_represented_port,
+ NEXT_ENTRY(COMMON_UNSIGNED)),
+ .args = ARGS(ARGS_ENTRY(struct rte_flow_action_ethdev,
+ port_id)),
+ .call = parse_vc_conf,
+ },
/* Indirect action destroy arguments. */
[INDIRECT_ACTION_DESTROY_ID] = {
.name = "action_id",
diff --git a/doc/guides/nics/features/default.ini b/doc/guides/nics/features/default.ini
index 0868c14a4c..3abac9d460 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -192,3 +192,4 @@ vf =
vxlan_decap =
vxlan_encap =
port_representor =
+represented_port =
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 587ed37c2c..27a17fac58 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1532,6 +1532,8 @@ at the opposite end of the "wire" leading to the ethdev.
This item is meant to use the same structure as `Item: PORT_REPRESENTOR`_.
+See also `Action: REPRESENTED_PORT`_.
+
Actions
~~~~~~~
@@ -3145,6 +3147,53 @@ at the opposite end of the "wire" leading to the ethdev.
See also `Item: PORT_REPRESENTOR`_.
+Action: ``REPRESENTED_PORT``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+At embedded switch level, send matching traffic to
+the entity represented by the given ethdev.
+
+Term **ethdev** and the concept of **port representor** are synonymous.
+The **represented port** is an *entity* plugged to the embedded switch
+at the opposite end of the "wire" leading to the ethdev.
+
+::
+
+ .--------------------.
+ | PORT_REPRESENTOR | Ethdev (Application Port Referred to by its ID)
+ '--------------------'
+ :
+ :
+ .----------------.
+ | Logical Port |
+ '----------------'
+ :
+ :
+ :
+ :
+ .----------. .--------------------.
+ | Switch | <== | Matching Traffic |
+ '----------' '--------------------'
+ ||
+ ||
+ ||
+ \/
+ .----------------.
+ | Logical Port |
+ '----------------'
+ ||
+ \/
+ .--------------------.
+ | REPRESENTED_PORT | Net / Guest / Another Ethdev (Same Application)
+ '--------------------'
+
+
+- Requires `Attribute: Transfer`_.
+
+This action is meant to use the same structure as `Action: PORT_REPRESENTOR`_.
+
+See also `Item: REPRESENTED_PORT`_.
+
Negative types
~~~~~~~~~~~~~~
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index 9a0ab97914..6c15afc1e9 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -252,7 +252,7 @@ API Changes
the crypto/security operation. This field will be used to communicate
events such as soft expiry with IPsec in lookaside mode.
-* ethdev: Added items ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` and action ``PORT_REPRESENTOR`` to flow API.
+* ethdev: Added items and actions ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` to flow API.
ABI Changes
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 46b7f07cbc..22ba8f0516 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -4090,6 +4090,11 @@ This section lists supported actions and their attributes, if any.
- ``port_id {unsigned}``: ethdev port ID
+- ``represented_port``: at embedded switch level, send matching traffic to
+ the entity represented by the given ethdev
+
+ - ``ethdev_port_id {unsigned}``: ethdev port ID
+
Destroying flow rules
~~~~~~~~~~~~~~~~~~~~~
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index b074b1c77d..542e40e496 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -192,6 +192,7 @@ static const struct rte_flow_desc_data rte_flow_desc_action[] = {
MK_FLOW_ACTION(INDIRECT, 0),
MK_FLOW_ACTION(CONNTRACK, sizeof(struct rte_flow_action_conntrack)),
MK_FLOW_ACTION(PORT_REPRESENTOR, sizeof(struct rte_flow_action_ethdev)),
+ MK_FLOW_ACTION(REPRESENTED_PORT, sizeof(struct rte_flow_action_ethdev)),
};
int
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 56fd4393e5..ff32c0a5ee 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -2462,6 +2462,14 @@ enum rte_flow_action_type {
* @see struct rte_flow_action_ethdev
*/
RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR,
+
+ /**
+ * At embedded switch level, send matching traffic to
+ * the entity represented by the given ethdev.
+ *
+ * @see struct rte_flow_action_ethdev
+ */
+ RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT,
};
/**
@@ -3212,7 +3220,8 @@ struct rte_flow_action_meter_color {
* @b EXPERIMENTAL: this structure may change without prior notice
*
* Provides an ethdev port ID for use with the following actions:
- * RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR.
+ * RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR,
+ * RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT.
*/
struct rte_flow_action_ethdev {
uint16_t port_id; /**< ethdev port ID */
--
2.20.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v5 03/12] ethdev: add port representor action to flow API
2021-10-13 16:57 4% ` [dpdk-dev] [PATCH v5 01/12] ethdev: add port representor item to " Ivan Malov
2021-10-13 16:57 4% ` [dpdk-dev] [PATCH v5 02/12] ethdev: add represented port " Ivan Malov
@ 2021-10-13 16:57 4% ` Ivan Malov
2021-10-13 16:57 4% ` [dpdk-dev] [PATCH v5 04/12] ethdev: add represented port " Ivan Malov
` (2 subsequent siblings)
5 siblings, 0 replies; 200+ results
From: Ivan Malov @ 2021-10-13 16:57 UTC (permalink / raw)
To: dev; +Cc: Ferruh Yigit, Thomas Monjalon, Ori Kam, Andrew Rybchenko, Xiaoyun Li
For use in "transfer" flows. Supposed to send matching traffic to
the given ethdev (to the application), at embedded switch level.
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
app/test-pmd/cmdline_flow.c | 26 ++++++++++
doc/guides/nics/features/default.ini | 1 +
doc/guides/prog_guide/rte_flow.rst | 56 +++++++++++++++++++++
doc/guides/rel_notes/release_21_11.rst | 2 +-
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 5 ++
lib/ethdev/rte_flow.c | 1 +
lib/ethdev/rte_flow.h | 18 +++++++
7 files changed, 108 insertions(+), 1 deletion(-)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 354f0fb2d7..1496d7a067 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -459,6 +459,8 @@ enum index {
ACTION_POL_G,
ACTION_POL_Y,
ACTION_POL_R,
+ ACTION_PORT_REPRESENTOR,
+ ACTION_PORT_REPRESENTOR_PORT_ID,
};
/** Maximum size for pattern in struct rte_flow_item_raw. */
@@ -1451,6 +1453,7 @@ static const enum index next_action[] = {
ACTION_MODIFY_FIELD,
ACTION_CONNTRACK,
ACTION_CONNTRACK_UPDATE,
+ ACTION_PORT_REPRESENTOR,
ZERO,
};
@@ -1731,6 +1734,12 @@ static const enum index action_update_conntrack[] = {
ZERO,
};
+static const enum index action_port_representor[] = {
+ ACTION_PORT_REPRESENTOR_PORT_ID,
+ ACTION_NEXT,
+ ZERO,
+};
+
static int parse_set_raw_encap_decap(struct context *, const struct token *,
const char *, unsigned int,
void *, unsigned int);
@@ -4810,6 +4819,23 @@ static const struct token token_list[] = {
.next = NEXT(action_update_conntrack),
.call = parse_vc_action_conntrack_update,
},
+ [ACTION_PORT_REPRESENTOR] = {
+ .name = "port_representor",
+ .help = "at embedded switch level, send matching traffic to the given ethdev",
+ .priv = PRIV_ACTION(PORT_REPRESENTOR,
+ sizeof(struct rte_flow_action_ethdev)),
+ .next = NEXT(action_port_representor),
+ .call = parse_vc,
+ },
+ [ACTION_PORT_REPRESENTOR_PORT_ID] = {
+ .name = "port_id",
+ .help = "ethdev port ID",
+ .next = NEXT(action_port_representor,
+ NEXT_ENTRY(COMMON_UNSIGNED)),
+ .args = ARGS(ARGS_ENTRY(struct rte_flow_action_ethdev,
+ port_id)),
+ .call = parse_vc_conf,
+ },
/* Indirect action destroy arguments. */
[INDIRECT_ACTION_DESTROY_ID] = {
.name = "action_id",
diff --git a/doc/guides/nics/features/default.ini b/doc/guides/nics/features/default.ini
index 365d9b7a39..0868c14a4c 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -191,3 +191,4 @@ set_ttl =
vf =
vxlan_decap =
vxlan_encap =
+port_representor =
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 2da286dce8..587ed37c2c 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1484,6 +1484,8 @@ at the opposite end of the "wire" leading to the ethdev.
- Default ``mask`` provides exact match behaviour.
+See also `Action: PORT_REPRESENTOR`_.
+
Item: ``REPRESENTED_PORT``
^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -3089,6 +3091,60 @@ which is set in the packet meta-data (i.e. struct ``rte_mbuf::sched::color``)
| ``meter_color`` | Packet color |
+-----------------+--------------+
+Action: ``PORT_REPRESENTOR``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+At embedded switch level, send matching traffic to the given ethdev.
+
+Term **ethdev** and the concept of **port representor** are synonymous.
+The **represented port** is an *entity* plugged to the embedded switch
+at the opposite end of the "wire" leading to the ethdev.
+
+::
+
+ .--------------------.
+ | PORT_REPRESENTOR | Ethdev (Application Port Referred to by its ID)
+ '--------------------'
+ /\
+ ||
+ .----------------.
+ | Logical Port |
+ '----------------'
+ /\
+ ||
+ ||
+ ||
+ .----------. .--------------------.
+ | Switch | <== | Matching Traffic |
+ '----------' '--------------------'
+ :
+ :
+ :
+ :
+ .----------------.
+ | Logical Port |
+ '----------------'
+ :
+ :
+ .--------------------.
+ | REPRESENTED_PORT | Net / Guest / Another Ethdev (Same Application)
+ '--------------------'
+
+
+- Requires `Attribute: Transfer`_.
+
+.. _table_rte_flow_action_ethdev:
+
+.. table:: ``struct rte_flow_action_ethdev``
+
+ +-------------+----------------+
+ | Field | Value |
+ +=============+================+
+ | ``port_id`` | ethdev port ID |
+ +-------------+----------------+
+
+See also `Item: PORT_REPRESENTOR`_.
+
Negative types
~~~~~~~~~~~~~~
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index b9f918cab8..9a0ab97914 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -252,7 +252,7 @@ API Changes
the crypto/security operation. This field will be used to communicate
events such as soft expiry with IPsec in lookaside mode.
-* ethdev: Added items ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` to flow API.
+* ethdev: Added items ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` and action ``PORT_REPRESENTOR`` to flow API.
ABI Changes
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 61669d1d5a..46b7f07cbc 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -4085,6 +4085,11 @@ This section lists supported actions and their attributes, if any.
- ``type {value}``: Set color type with specified value(green/yellow/red)
+- ``port_representor``: at embedded switch level, send matching traffic to
+ the given ethdev
+
+ - ``port_id {unsigned}``: ethdev port ID
+
Destroying flow rules
~~~~~~~~~~~~~~~~~~~~~
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index d4b654a2c6..b074b1c77d 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -191,6 +191,7 @@ static const struct rte_flow_desc_data rte_flow_desc_action[] = {
*/
MK_FLOW_ACTION(INDIRECT, 0),
MK_FLOW_ACTION(CONNTRACK, sizeof(struct rte_flow_action_conntrack)),
+ MK_FLOW_ACTION(PORT_REPRESENTOR, sizeof(struct rte_flow_action_ethdev)),
};
int
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index b50c3d38b5..56fd4393e5 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -2455,6 +2455,13 @@ enum rte_flow_action_type {
* See struct rte_flow_action_meter_color.
*/
RTE_FLOW_ACTION_TYPE_METER_COLOR,
+
+ /**
+ * At embedded switch level, sends matching traffic to the given ethdev.
+ *
+ * @see struct rte_flow_action_ethdev
+ */
+ RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR,
};
/**
@@ -3200,6 +3207,17 @@ struct rte_flow_action_meter_color {
enum rte_color color; /**< Packet color. */
};
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * Provides an ethdev port ID for use with the following actions:
+ * RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR.
+ */
+struct rte_flow_action_ethdev {
+ uint16_t port_id; /**< ethdev port ID */
+};
+
/**
* Field IDs for MODIFY_FIELD action.
*/
--
2.20.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v5 02/12] ethdev: add represented port item to flow API
2021-10-13 16:57 4% ` [dpdk-dev] [PATCH v5 01/12] ethdev: add port representor item to " Ivan Malov
@ 2021-10-13 16:57 4% ` Ivan Malov
2021-10-13 16:57 4% ` [dpdk-dev] [PATCH v5 03/12] ethdev: add port representor action " Ivan Malov
` (3 subsequent siblings)
5 siblings, 0 replies; 200+ results
From: Ivan Malov @ 2021-10-13 16:57 UTC (permalink / raw)
To: dev; +Cc: Ferruh Yigit, Thomas Monjalon, Ori Kam, Andrew Rybchenko, Xiaoyun Li
For use in "transfer" flows. Supposed to match traffic entering the
embedded switch from the entity represented by the given ethdev.
Such an entity can be a network (via a network port), a guest
machine (via a VF) or another ethdev in the same application.
Must not be combined with direction attributes.
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
app/test-pmd/cmdline_flow.c | 25 +++++++++++
doc/guides/nics/features/default.ini | 1 +
doc/guides/prog_guide/rte_flow.rst | 46 +++++++++++++++++++++
doc/guides/rel_notes/release_21_11.rst | 2 +-
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 5 +++
lib/ethdev/rte_flow.c | 1 +
lib/ethdev/rte_flow.h | 13 +++++-
7 files changed, 91 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 5c480db91d..354f0fb2d7 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -308,6 +308,8 @@ enum index {
ITEM_POL_POLICY,
ITEM_PORT_REPRESENTOR,
ITEM_PORT_REPRESENTOR_PORT_ID,
+ ITEM_REPRESENTED_PORT,
+ ITEM_REPRESENTED_PORT_ETHDEV_PORT_ID,
/* Validate/create actions. */
ACTIONS,
@@ -1002,6 +1004,7 @@ static const enum index next_item[] = {
ITEM_INTEGRITY,
ITEM_CONNTRACK,
ITEM_PORT_REPRESENTOR,
+ ITEM_REPRESENTED_PORT,
END_SET,
ZERO,
};
@@ -1376,6 +1379,12 @@ static const enum index item_port_representor[] = {
ZERO,
};
+static const enum index item_represented_port[] = {
+ ITEM_REPRESENTED_PORT_ETHDEV_PORT_ID,
+ ITEM_NEXT,
+ ZERO,
+};
+
static const enum index next_action[] = {
ACTION_END,
ACTION_VOID,
@@ -3630,6 +3639,21 @@ static const struct token token_list[] = {
item_param),
.args = ARGS(ARGS_ENTRY(struct rte_flow_item_ethdev, port_id)),
},
+ [ITEM_REPRESENTED_PORT] = {
+ .name = "represented_port",
+ .help = "match traffic entering the embedded switch from the entity represented by the given ethdev",
+ .priv = PRIV_ITEM(REPRESENTED_PORT,
+ sizeof(struct rte_flow_item_ethdev)),
+ .next = NEXT(item_represented_port),
+ .call = parse_vc,
+ },
+ [ITEM_REPRESENTED_PORT_ETHDEV_PORT_ID] = {
+ .name = "ethdev_port_id",
+ .help = "ethdev port ID",
+ .next = NEXT(item_represented_port, NEXT_ENTRY(COMMON_UNSIGNED),
+ item_param),
+ .args = ARGS(ARGS_ENTRY(struct rte_flow_item_ethdev, port_id)),
+ },
/* Validate/create actions. */
[ACTIONS] = {
.name = "actions",
@@ -8358,6 +8382,7 @@ flow_item_default_mask(const struct rte_flow_item *item)
mask = &rte_flow_item_pfcp_mask;
break;
case RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR:
+ case RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT:
mask = &rte_flow_item_ethdev_mask;
break;
default:
diff --git a/doc/guides/nics/features/default.ini b/doc/guides/nics/features/default.ini
index 9b53a887a4..365d9b7a39 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -133,6 +133,7 @@ vlan =
vxlan =
vxlan_gpe =
port_representor =
+represented_port =
[rte_flow actions]
age =
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index d194640469..2da286dce8 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1484,6 +1484,52 @@ at the opposite end of the "wire" leading to the ethdev.
- Default ``mask`` provides exact match behaviour.
+Item: ``REPRESENTED_PORT``
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Matches traffic entering the embedded switch from
+the entity represented by the given ethdev.
+
+Term **ethdev** and the concept of **port representor** are synonymous.
+The **represented port** is an *entity* plugged to the embedded switch
+at the opposite end of the "wire" leading to the ethdev.
+
+::
+
+ .--------------------.
+ | PORT_REPRESENTOR | Ethdev (Application Port Referred to by its ID)
+ '--------------------'
+ :
+ :
+ .----------------.
+ | Logical Port |
+ '----------------'
+ :
+ :
+ :
+ :
+ .----------.
+ | Switch |
+ '----------'
+ /\
+ ||
+ ||
+ ||
+ .----------------.
+ | Logical Port |
+ '----------------'
+ /\
+ ||
+ .--------------------.
+ | REPRESENTED_PORT | Net / Guest / Another Ethdev (Same Application)
+ '--------------------'
+
+
+- Incompatible with `Attribute: Traffic direction`_.
+- Requires `Attribute: Transfer`_.
+
+This item is meant to use the same structure as `Item: PORT_REPRESENTOR`_.
+
Actions
~~~~~~~
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index 07f9d39a5b..b9f918cab8 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -252,7 +252,7 @@ API Changes
the crypto/security operation. This field will be used to communicate
events such as soft expiry with IPsec in lookaside mode.
-* ethdev: Added item ``PORT_REPRESENTOR`` to flow API.
+* ethdev: Added items ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` to flow API.
ABI Changes
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 90765f9090..61669d1d5a 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -3805,6 +3805,11 @@ This section lists supported pattern items and their attributes, if any.
- ``port_id {unsigned}``: ethdev port ID
+- ``represented_port``: match traffic entering the embedded switch from
+ the entity represented by the given ethdev
+
+ - ``ethdev_port_id {unsigned}``: ethdev port ID
+
Actions list
^^^^^^^^^^^^
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index 5e9317c6d1..d4b654a2c6 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -101,6 +101,7 @@ static const struct rte_flow_desc_data rte_flow_desc_item[] = {
MK_FLOW_ITEM(INTEGRITY, sizeof(struct rte_flow_item_integrity)),
MK_FLOW_ITEM(CONNTRACK, sizeof(uint32_t)),
MK_FLOW_ITEM(PORT_REPRESENTOR, sizeof(struct rte_flow_item_ethdev)),
+ MK_FLOW_ITEM(REPRESENTED_PORT, sizeof(struct rte_flow_item_ethdev)),
};
/** Generate flow_action[] entry. */
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 1e3ef77ead..b50c3d38b5 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -583,6 +583,16 @@ enum rte_flow_item_type {
* @see struct rte_flow_item_ethdev
*/
RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR,
+
+ /**
+ * [META]
+ *
+ * Matches traffic entering the embedded switch from
+ * the entity represented by the given ethdev.
+ *
+ * @see struct rte_flow_item_ethdev
+ */
+ RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT,
};
/**
@@ -1813,7 +1823,8 @@ static const struct rte_flow_item_conntrack rte_flow_item_conntrack_mask = {
* @b EXPERIMENTAL: this structure may change without prior notice
*
* Provides an ethdev port ID for use with the following items:
- * RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR.
+ * RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR,
+ * RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT.
*/
struct rte_flow_item_ethdev {
uint16_t port_id; /**< ethdev port ID */
--
2.20.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v5 01/12] ethdev: add port representor item to flow API
@ 2021-10-13 16:57 4% ` Ivan Malov
2021-10-13 16:57 4% ` [dpdk-dev] [PATCH v5 02/12] ethdev: add represented port " Ivan Malov
` (4 subsequent siblings)
5 siblings, 0 replies; 200+ results
From: Ivan Malov @ 2021-10-13 16:57 UTC (permalink / raw)
To: dev; +Cc: Ferruh Yigit, Thomas Monjalon, Ori Kam, Andrew Rybchenko, Xiaoyun Li
For use in "transfer" flows. Supposed to match traffic
entering the embedded switch from the given ethdev.
Must not be combined with direction attributes.
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
app/test-pmd/cmdline_flow.c | 27 ++++++++++
doc/guides/nics/features/default.ini | 1 +
doc/guides/prog_guide/rte_flow.rst | 59 +++++++++++++++++++++
doc/guides/rel_notes/release_21_11.rst | 2 +
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 4 ++
lib/ethdev/rte_flow.c | 1 +
lib/ethdev/rte_flow.h | 27 ++++++++++
7 files changed, 121 insertions(+)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 0b5856c7d5..5c480db91d 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -306,6 +306,8 @@ enum index {
ITEM_POL_PORT,
ITEM_POL_METER,
ITEM_POL_POLICY,
+ ITEM_PORT_REPRESENTOR,
+ ITEM_PORT_REPRESENTOR_PORT_ID,
/* Validate/create actions. */
ACTIONS,
@@ -999,6 +1001,7 @@ static const enum index next_item[] = {
ITEM_GENEVE_OPT,
ITEM_INTEGRITY,
ITEM_CONNTRACK,
+ ITEM_PORT_REPRESENTOR,
END_SET,
ZERO,
};
@@ -1367,6 +1370,12 @@ static const enum index item_integrity_lv[] = {
ZERO,
};
+static const enum index item_port_representor[] = {
+ ITEM_PORT_REPRESENTOR_PORT_ID,
+ ITEM_NEXT,
+ ZERO,
+};
+
static const enum index next_action[] = {
ACTION_END,
ACTION_VOID,
@@ -3606,6 +3615,21 @@ static const struct token token_list[] = {
item_param),
.args = ARGS(ARGS_ENTRY(struct rte_flow_item_conntrack, flags)),
},
+ [ITEM_PORT_REPRESENTOR] = {
+ .name = "port_representor",
+ .help = "match traffic entering the embedded switch from the given ethdev",
+ .priv = PRIV_ITEM(PORT_REPRESENTOR,
+ sizeof(struct rte_flow_item_ethdev)),
+ .next = NEXT(item_port_representor),
+ .call = parse_vc,
+ },
+ [ITEM_PORT_REPRESENTOR_PORT_ID] = {
+ .name = "port_id",
+ .help = "ethdev port ID",
+ .next = NEXT(item_port_representor, NEXT_ENTRY(COMMON_UNSIGNED),
+ item_param),
+ .args = ARGS(ARGS_ENTRY(struct rte_flow_item_ethdev, port_id)),
+ },
/* Validate/create actions. */
[ACTIONS] = {
.name = "actions",
@@ -8333,6 +8357,9 @@ flow_item_default_mask(const struct rte_flow_item *item)
case RTE_FLOW_ITEM_TYPE_PFCP:
mask = &rte_flow_item_pfcp_mask;
break;
+ case RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR:
+ mask = &rte_flow_item_ethdev_mask;
+ break;
default:
break;
}
diff --git a/doc/guides/nics/features/default.ini b/doc/guides/nics/features/default.ini
index d473b94091..9b53a887a4 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -132,6 +132,7 @@ vf =
vlan =
vxlan =
vxlan_gpe =
+port_representor =
[rte_flow actions]
age =
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 3cb014c1fa..d194640469 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1425,6 +1425,65 @@ Matches a conntrack state after conntrack action.
- ``flags``: conntrack packet state flags.
- Default ``mask`` matches all state bits.
+Item: ``PORT_REPRESENTOR``
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Matches traffic entering the embedded switch from the given ethdev.
+
+Term **ethdev** and the concept of **port representor** are synonymous.
+The **represented port** is an *entity* plugged to the embedded switch
+at the opposite end of the "wire" leading to the ethdev.
+
+::
+
+ .--------------------.
+ | PORT_REPRESENTOR | Ethdev (Application Port Referred to by its ID)
+ '--------------------'
+ ||
+ \/
+ .----------------.
+ | Logical Port |
+ '----------------'
+ ||
+ ||
+ ||
+ \/
+ .----------.
+ | Switch |
+ '----------'
+ :
+ :
+ :
+ :
+ .----------------.
+ | Logical Port |
+ '----------------'
+ :
+ :
+ .--------------------.
+ | REPRESENTED_PORT | Net / Guest / Another Ethdev (Same Application)
+ '--------------------'
+
+
+- Incompatible with `Attribute: Traffic direction`_.
+- Requires `Attribute: Transfer`_.
+
+.. _table_rte_flow_item_ethdev:
+
+.. table:: ``struct rte_flow_item_ethdev``
+
+ +----------+-------------+---------------------------+
+ | Field | Subfield | Value |
+ +==========+=============+===========================+
+ | ``spec`` | ``port_id`` | ethdev port ID |
+ +----------+-------------+---------------------------+
+ | ``last`` | ``port_id`` | upper range value |
+ +----------+-------------+---------------------------+
+ | ``mask`` | ``port_id`` | zeroed for wildcard match |
+ +----------+-------------+---------------------------+
+
+- Default ``mask`` provides exact match behaviour.
+
Actions
~~~~~~~
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index d5c762df62..07f9d39a5b 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -252,6 +252,8 @@ API Changes
the crypto/security operation. This field will be used to communicate
events such as soft expiry with IPsec in lookaside mode.
+* ethdev: Added item ``PORT_REPRESENTOR`` to flow API.
+
ABI Changes
-----------
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index a0efb7d0b0..90765f9090 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -3801,6 +3801,10 @@ This section lists supported pattern items and their attributes, if any.
- ``conntrack``: match conntrack state.
+- ``port_representor``: match traffic entering the embedded switch from the given ethdev
+
+ - ``port_id {unsigned}``: ethdev port ID
+
Actions list
^^^^^^^^^^^^
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index 8cb7a069c8..5e9317c6d1 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -100,6 +100,7 @@ static const struct rte_flow_desc_data rte_flow_desc_item[] = {
MK_FLOW_ITEM(GENEVE_OPT, sizeof(struct rte_flow_item_geneve_opt)),
MK_FLOW_ITEM(INTEGRITY, sizeof(struct rte_flow_item_integrity)),
MK_FLOW_ITEM(CONNTRACK, sizeof(uint32_t)),
+ MK_FLOW_ITEM(PORT_REPRESENTOR, sizeof(struct rte_flow_item_ethdev)),
};
/** Generate flow_action[] entry. */
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 5f87851f8c..1e3ef77ead 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -574,6 +574,15 @@ enum rte_flow_item_type {
* @see struct rte_flow_item_conntrack.
*/
RTE_FLOW_ITEM_TYPE_CONNTRACK,
+
+ /**
+ * [META]
+ *
+ * Matches traffic entering the embedded switch from the given ethdev.
+ *
+ * @see struct rte_flow_item_ethdev
+ */
+ RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR,
};
/**
@@ -1799,6 +1808,24 @@ static const struct rte_flow_item_conntrack rte_flow_item_conntrack_mask = {
};
#endif
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * Provides an ethdev port ID for use with the following items:
+ * RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR.
+ */
+struct rte_flow_item_ethdev {
+ uint16_t port_id; /**< ethdev port ID */
+};
+
+/** Default mask for items based on struct rte_flow_item_ethdev */
+#ifndef __cplusplus
+static const struct rte_flow_item_ethdev rte_flow_item_ethdev_mask = {
+ .port_id = 0xffff,
+};
+#endif
+
/**
* Matching pattern item definition.
*
--
2.20.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v4 06/12] ethdev: deprecate direction attributes in transfer flows
` (4 preceding siblings ...)
2021-10-13 16:42 3% ` [dpdk-dev] [PATCH v4 05/12] ethdev: deprecate hard-to-use or ambiguous items and actions Ivan Malov
@ 2021-10-13 16:42 3% ` Ivan Malov
5 siblings, 0 replies; 200+ results
From: Ivan Malov @ 2021-10-13 16:42 UTC (permalink / raw)
To: dev
Cc: Ferruh Yigit, Thomas Monjalon, Ori Kam, Andrew Rybchenko, Ray Kinsella
Attributes "ingress" and "egress" can only apply unambiguosly
to non-"transfer" flows. In "transfer" flows, the standpoint
is effectively shifted to the embedded switch. There can be
many different endpoints connected to the switch, so the
use of "ingress" / "egress" does not shed light on which
endpoints precisely can be considered as traffic sources.
Add relevant deprecation notices and suggest the use of precise
traffic source items (PORT_REPRESENTOR and REPRESENTED_PORT).
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
doc/guides/prog_guide/rte_flow.rst | 28 ++++++++----------
doc/guides/rel_notes/deprecation.rst | 9 +++---
doc/guides/rel_notes/release_21_11.rst | 3 ++
lib/ethdev/rte_flow.h | 41 ++++++++++++++++++++------
4 files changed, 52 insertions(+), 29 deletions(-)
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index d7185c49df..5957b8df4f 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -9,8 +9,8 @@ Overview
--------
This API provides a generic means to configure hardware to match specific
-ingress or egress traffic, alter its fate and query related counters
-according to any number of user-defined rules.
+traffic, alter its fate and query related counters according to any
+number of user-defined rules.
It is named *rte_flow* after the prefix used for all its symbols, and is
defined in ``rte_flow.h``.
@@ -146,13 +146,10 @@ Note that support for more than a single priority level is not guaranteed.
Attribute: Traffic direction
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Flow rule patterns apply to inbound and/or outbound traffic.
-
-In the context of this API, **ingress** and **egress** respectively stand
-for **inbound** and **outbound** based on the standpoint of the application
-creating a flow rule.
-
-There are no exceptions to this definition.
+Unless `Attribute: Transfer`_ is specified, flow rule patterns apply
+to inbound and / or outbound traffic. With this respect, ``ingress``
+and ``egress`` respectively stand for **inbound** and **outbound**
+based on the standpoint of the application creating a flow rule.
Several pattern items and actions are valid and can be used in both
directions. At least one direction must be specified.
@@ -171,12 +168,13 @@ When supported, this effectively enables an application to reroute traffic
not necessarily intended for it (e.g. coming from or addressed to different
physical ports, VFs or applications) at the device level.
-It complements the behavior of some pattern items such as `Item: PHY_PORT`_
-and is meaningless without them.
-
-When transferring flow rules, **ingress** and **egress** attributes
-(`Attribute: Traffic direction`_) keep their original meaning, as if
-processing traffic emitted or received by the application.
+In "transfer" flows, the use of `Attribute: Traffic direction`_ in the sense of
+implicitly matching packets going to or going from the ethdev used to create
+flow rules is **deprecated**. `Attribute: Transfer`_ shifts the viewpoint to
+the embedded switch. In it, `Attribute: Traffic direction`_ is ambiguous as
+the switch serves many different endpoints. The application should match
+traffic originating from precise locations. To do so, it should
+use `Item: PORT_REPRESENTOR`_ and `Item: REPRESENTED_PORT`_.
Pattern item
~~~~~~~~~~~~
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 25aec56bec..ef2e2c1141 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -113,11 +113,6 @@ Deprecation Notices
to support modifying fields larger than 64 bits.
In addition, documentation will be updated to clarify byte order.
-* ethdev: Flow API documentation is unclear if ethdev port used to create
- a flow rule adds any implicit match criteria in the case of transfer rules.
- The semantics will be clarified in DPDK 21.11 and it will require fixes in
- drivers and applications which interpret it in a different way.
-
* ethdev: The flow API matching pattern structures, ``struct rte_flow_item_*``,
should start with relevant protocol header.
Some matching pattern structures implements this by duplicating protocol header
@@ -146,6 +141,10 @@ Deprecation Notices
* ethdev: Items and actions ``PF``, ``VF``, ``PHY_PORT``, ``PORT_ID`` are
deprecated as hard-to-use / ambiguous and will be removed in DPDK 22.11.
+* ethdev: The use of attributes ``ingress`` / ``egress`` in "transfer" flows
+ is deprecated as ambiguous with respect to the embedded switch. The use of
+ these attributes will become invalid starting from DPDK 22.11.
+
* net: The structure ``rte_ipv4_hdr`` will have two unions.
The first union is for existing ``version_ihl`` byte
and new bitfield for version and IHL.
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index 75c4f6d018..45c019eb04 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -257,6 +257,9 @@ API Changes
* ethdev: Deprecated items and actions ``PF``, ``VF``, ``PHY_PORT``, ``PORT_ID``.
Suggested items and actions ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` instead.
+* ethdev: Deprecated the use of attributes ``ingress`` / ``egress`` combined
+ with ``transfer``. See items ``PORT_REPRESENTOR``, ``REPRESENTED_PORT``.
+
ABI Changes
-----------
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 76653105a0..7e7b4bce5b 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -67,7 +67,10 @@ extern "C" {
* Note that support for more than a single group and priority level is not
* guaranteed.
*
- * Flow rules can apply to inbound and/or outbound traffic (ingress/egress).
+ * At vNIC / ethdev level, flow rules can apply to inbound and / or outbound
+ * traffic (ingress / egress), with respect to the vNIC / ethdev in question.
+ * At embedded switch level, flow rules apply to all traffic seen by it
+ * unless fitting meta items are used to set concrete traffic source(s).
*
* Several pattern items and actions are valid and can be used in both
* directions. Those valid for only one direction are described as such.
@@ -80,8 +83,32 @@ extern "C" {
struct rte_flow_attr {
uint32_t group; /**< Priority group. */
uint32_t priority; /**< Rule priority level within group. */
- uint32_t ingress:1; /**< Rule applies to ingress traffic. */
- uint32_t egress:1; /**< Rule applies to egress traffic. */
+ /**
+ * The rule in question applies to ingress traffic (non-"transfer").
+ *
+ * @deprecated
+ * It has been possible to combine this attribute with "transfer".
+ * Doing so has been assumed to restrict the scope of matching
+ * to traffic going from within the embedded switch toward the
+ * ethdev the flow rule being created through. This behaviour
+ * is deprecated. During the transition period, one may still
+ * rely on it, but PMDs and applications are encouraged to
+ * gradually move away from this approach.
+ */
+ uint32_t ingress:1;
+ /**
+ * The rule in question applies to egress traffic (non-"transfer").
+ *
+ * @deprecated
+ * It has been possible to combine this attribute with "transfer".
+ * Doing so has been assumed to restrict the scope of matching
+ * to traffic sent by the application by virtue of the ethdev
+ * the flow rule being created through. This behaviour is now
+ * deprecated. During the transition period, one may still
+ * rely on it, but PMDs and applications are encouraged to
+ * gradually move away from this approach.
+ */
+ uint32_t egress:1;
/**
* Instead of simply matching the properties of traffic as it would
* appear on a given DPDK port ID, enabling this attribute transfers
@@ -93,12 +120,8 @@ struct rte_flow_attr {
* from or addressed to different physical ports, VFs or
* applications) at the device level.
*
- * It complements the behavior of some pattern items such as
- * RTE_FLOW_ITEM_TYPE_PHY_PORT and is meaningless without them.
- *
- * When transferring flow rules, ingress and egress attributes keep
- * their original meaning, as if processing traffic emitted or
- * received by the application.
+ * The application should match traffic originating from precise
+ * locations. See items PORT_REPRESENTOR and REPRESENTED_PORT.
*/
uint32_t transfer:1;
uint32_t reserved:29; /**< Reserved, must be zero. */
--
2.20.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v4 05/12] ethdev: deprecate hard-to-use or ambiguous items and actions
` (3 preceding siblings ...)
2021-10-13 16:42 4% ` [dpdk-dev] [PATCH v4 04/12] ethdev: add represented port " Ivan Malov
@ 2021-10-13 16:42 3% ` Ivan Malov
2021-10-13 16:42 3% ` [dpdk-dev] [PATCH v4 06/12] ethdev: deprecate direction attributes in transfer flows Ivan Malov
5 siblings, 0 replies; 200+ results
From: Ivan Malov @ 2021-10-13 16:42 UTC (permalink / raw)
To: dev
Cc: Ferruh Yigit, Thomas Monjalon, Ori Kam, Andrew Rybchenko, Ray Kinsella
PF, VF and PHY_PORT require that applications have extra
knowledge of the underlying NIC and thus are hard to use.
Also, the corresponding items depend on the direction
attribute (ingress / egress), which complicates their
use in applications and interpretation in PMDs.
The concept of PORT_ID is ambiguous as it doesn't say whether
the port in question is an ethdev or the represented entity.
Items and actions PORT_REPRESENTOR, REPRESENTED_PORT
should be used instead.
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
doc/guides/prog_guide/rte_flow.rst | 32 +++++++++++++++
doc/guides/rel_notes/deprecation.rst | 9 ++---
doc/guides/rel_notes/release_21_11.rst | 3 ++
lib/ethdev/rte_flow.h | 56 ++++++++++++++++++++++++++
4 files changed, 94 insertions(+), 6 deletions(-)
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 27a17fac58..d7185c49df 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -504,6 +504,10 @@ Usage example, matching non-TCPv4 packets only:
Item: ``PF``
^^^^^^^^^^^^
+This item is deprecated. Consider:
+ - `Item: PORT_REPRESENTOR`_
+ - `Item: REPRESENTED_PORT`_
+
Matches traffic originating from (ingress) or going to (egress) the physical
function of the current device.
@@ -531,6 +535,10 @@ the application and thus not associated with a DPDK port ID.
Item: ``VF``
^^^^^^^^^^^^
+This item is deprecated. Consider:
+ - `Item: PORT_REPRESENTOR`_
+ - `Item: REPRESENTED_PORT`_
+
Matches traffic originating from (ingress) or going to (egress) a given
virtual function of the current device.
@@ -562,6 +570,10 @@ separate entities, should be addressed through their own DPDK port IDs.
Item: ``PHY_PORT``
^^^^^^^^^^^^^^^^^^
+This item is deprecated. Consider:
+ - `Item: PORT_REPRESENTOR`_
+ - `Item: REPRESENTED_PORT`_
+
Matches traffic originating from (ingress) or going to (egress) a physical
port of the underlying device.
@@ -596,6 +608,10 @@ associated with a port_id should be retrieved by other means.
Item: ``PORT_ID``
^^^^^^^^^^^^^^^^^
+This item is deprecated. Consider:
+ - `Item: PORT_REPRESENTOR`_
+ - `Item: REPRESENTED_PORT`_
+
Matches traffic originating from (ingress) or going to (egress) a given DPDK
port ID.
@@ -1950,6 +1966,10 @@ only matching traffic goes through.
Action: ``PF``
^^^^^^^^^^^^^^
+This action is deprecated. Consider:
+ - `Action: PORT_REPRESENTOR`_
+ - `Action: REPRESENTED_PORT`_
+
Directs matching traffic to the physical function (PF) of the current
device.
@@ -1970,6 +1990,10 @@ See `Item: PF`_.
Action: ``VF``
^^^^^^^^^^^^^^
+This action is deprecated. Consider:
+ - `Action: PORT_REPRESENTOR`_
+ - `Action: REPRESENTED_PORT`_
+
Directs matching traffic to a given virtual function of the current device.
Packets matched by a VF pattern item can be redirected to their original VF
@@ -1994,6 +2018,10 @@ See `Item: VF`_.
Action: ``PHY_PORT``
^^^^^^^^^^^^^^^^^^^^
+This action is deprecated. Consider:
+ - `Action: PORT_REPRESENTOR`_
+ - `Action: REPRESENTED_PORT`_
+
Directs matching traffic to a given physical port index of the underlying
device.
@@ -2013,6 +2041,10 @@ See `Item: PHY_PORT`_.
Action: ``PORT_ID``
^^^^^^^^^^^^^^^^^^^
+This action is deprecated. Consider:
+ - `Action: PORT_REPRESENTOR`_
+ - `Action: REPRESENTED_PORT`_
+
Directs matching traffic to a given DPDK port ID.
See `Item: PORT_ID`_.
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 5853b5988d..25aec56bec 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -113,12 +113,6 @@ Deprecation Notices
to support modifying fields larger than 64 bits.
In addition, documentation will be updated to clarify byte order.
-* ethdev: Definition of the flow API action ``RTE_FLOW_ACTION_TYPE_PORT_ID``
- is ambiguous and needs clarification.
- Structure ``rte_flow_action_port_id`` will be extended to specify
- traffic direction to the represented entity or ethdev port itself
- in DPDK 21.11.
-
* ethdev: Flow API documentation is unclear if ethdev port used to create
a flow rule adds any implicit match criteria in the case of transfer rules.
The semantics will be clarified in DPDK 21.11 and it will require fixes in
@@ -149,6 +143,9 @@ Deprecation Notices
consistent with existing outer header checksum status flag naming, which
should help in reducing confusion about its usage.
+* ethdev: Items and actions ``PF``, ``VF``, ``PHY_PORT``, ``PORT_ID`` are
+ deprecated as hard-to-use / ambiguous and will be removed in DPDK 22.11.
+
* net: The structure ``rte_ipv4_hdr`` will have two unions.
The first union is for existing ``version_ihl`` byte
and new bitfield for version and IHL.
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index 6c15afc1e9..75c4f6d018 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -254,6 +254,9 @@ API Changes
* ethdev: Added items and actions ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` to flow API.
+* ethdev: Deprecated items and actions ``PF``, ``VF``, ``PHY_PORT``, ``PORT_ID``.
+ Suggested items and actions ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` instead.
+
ABI Changes
-----------
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index ff32c0a5ee..76653105a0 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -160,6 +160,10 @@ enum rte_flow_item_type {
RTE_FLOW_ITEM_TYPE_ANY,
/**
+ * @deprecated
+ * @see RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT
+ *
* [META]
*
* Matches traffic originating from (ingress) or going to (egress)
@@ -170,6 +174,10 @@ enum rte_flow_item_type {
RTE_FLOW_ITEM_TYPE_PF,
/**
+ * @deprecated
+ * @see RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT
+ *
* [META]
*
* Matches traffic originating from (ingress) or going to (egress) a
@@ -180,6 +188,10 @@ enum rte_flow_item_type {
RTE_FLOW_ITEM_TYPE_VF,
/**
+ * @deprecated
+ * @see RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT
+ *
* [META]
*
* Matches traffic originating from (ingress) or going to (egress) a
@@ -190,6 +202,10 @@ enum rte_flow_item_type {
RTE_FLOW_ITEM_TYPE_PHY_PORT,
/**
+ * @deprecated
+ * @see RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT
+ *
* [META]
*
* Matches traffic originating from (ingress) or going to (egress) a
@@ -640,6 +656,10 @@ static const struct rte_flow_item_any rte_flow_item_any_mask = {
#endif
/**
+ * @deprecated
+ * @see RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT
+ *
* RTE_FLOW_ITEM_TYPE_VF
*
* Matches traffic originating from (ingress) or going to (egress) a given
@@ -669,6 +689,10 @@ static const struct rte_flow_item_vf rte_flow_item_vf_mask = {
#endif
/**
+ * @deprecated
+ * @see RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT
+ *
* RTE_FLOW_ITEM_TYPE_PHY_PORT
*
* Matches traffic originating from (ingress) or going to (egress) a
@@ -700,6 +724,10 @@ static const struct rte_flow_item_phy_port rte_flow_item_phy_port_mask = {
#endif
/**
+ * @deprecated
+ * @see RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT
+ *
* RTE_FLOW_ITEM_TYPE_PORT_ID
*
* Matches traffic originating from (ingress) or going to (egress) a given
@@ -1998,6 +2026,10 @@ enum rte_flow_action_type {
RTE_FLOW_ACTION_TYPE_RSS,
/**
+ * @deprecated
+ * @see RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT
+ *
* Directs matching traffic to the physical function (PF) of the
* current device.
*
@@ -2006,6 +2038,10 @@ enum rte_flow_action_type {
RTE_FLOW_ACTION_TYPE_PF,
/**
+ * @deprecated
+ * @see RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT
+ *
* Directs matching traffic to a given virtual function of the
* current device.
*
@@ -2014,6 +2050,10 @@ enum rte_flow_action_type {
RTE_FLOW_ACTION_TYPE_VF,
/**
+ * @deprecated
+ * @see RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT
+ *
* Directs packets to a given physical port index of the underlying
* device.
*
@@ -2022,6 +2062,10 @@ enum rte_flow_action_type {
RTE_FLOW_ACTION_TYPE_PHY_PORT,
/**
+ * @deprecated
+ * @see RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT
+ *
* Directs matching traffic to a given DPDK port ID.
*
* See struct rte_flow_action_port_id.
@@ -2648,6 +2692,10 @@ struct rte_flow_action_rss {
};
/**
+ * @deprecated
+ * @see RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT
+ *
* RTE_FLOW_ACTION_TYPE_VF
*
* Directs matching traffic to a given virtual function of the current
@@ -2666,6 +2714,10 @@ struct rte_flow_action_vf {
};
/**
+ * @deprecated
+ * @see RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT
+ *
* RTE_FLOW_ACTION_TYPE_PHY_PORT
*
* Directs packets to a given physical port index of the underlying
@@ -2680,6 +2732,10 @@ struct rte_flow_action_phy_port {
};
/**
+ * @deprecated
+ * @see RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR
+ * @see RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT
+ *
* RTE_FLOW_ACTION_TYPE_PORT_ID
*
* Directs matching traffic to a given DPDK port ID.
--
2.20.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v4 04/12] ethdev: add represented port action to flow API
` (2 preceding siblings ...)
2021-10-13 16:42 4% ` [dpdk-dev] [PATCH v4 03/12] ethdev: add port representor action " Ivan Malov
@ 2021-10-13 16:42 4% ` Ivan Malov
2021-10-13 16:42 3% ` [dpdk-dev] [PATCH v4 05/12] ethdev: deprecate hard-to-use or ambiguous items and actions Ivan Malov
2021-10-13 16:42 3% ` [dpdk-dev] [PATCH v4 06/12] ethdev: deprecate direction attributes in transfer flows Ivan Malov
5 siblings, 0 replies; 200+ results
From: Ivan Malov @ 2021-10-13 16:42 UTC (permalink / raw)
To: dev; +Cc: Ferruh Yigit, Thomas Monjalon, Ori Kam, Andrew Rybchenko, Xiaoyun Li
For use in "transfer" flows. Supposed to send matching traffic to the
entity represented by the given ethdev, at embedded switch level.
Such an entity can be a network (via a network port), a guest
machine (via a VF) or another ethdev in the same application.
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
app/test-pmd/cmdline_flow.c | 26 +++++++++++
doc/guides/prog_guide/rte_flow.rst | 49 +++++++++++++++++++++
doc/guides/rel_notes/release_21_11.rst | 2 +-
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 5 +++
lib/ethdev/rte_flow.c | 1 +
lib/ethdev/rte_flow.h | 11 ++++-
6 files changed, 92 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 1496d7a067..d897d0d1d4 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -461,6 +461,8 @@ enum index {
ACTION_POL_R,
ACTION_PORT_REPRESENTOR,
ACTION_PORT_REPRESENTOR_PORT_ID,
+ ACTION_REPRESENTED_PORT,
+ ACTION_REPRESENTED_PORT_ETHDEV_PORT_ID,
};
/** Maximum size for pattern in struct rte_flow_item_raw. */
@@ -1454,6 +1456,7 @@ static const enum index next_action[] = {
ACTION_CONNTRACK,
ACTION_CONNTRACK_UPDATE,
ACTION_PORT_REPRESENTOR,
+ ACTION_REPRESENTED_PORT,
ZERO,
};
@@ -1740,6 +1743,12 @@ static const enum index action_port_representor[] = {
ZERO,
};
+static const enum index action_represented_port[] = {
+ ACTION_REPRESENTED_PORT_ETHDEV_PORT_ID,
+ ACTION_NEXT,
+ ZERO,
+};
+
static int parse_set_raw_encap_decap(struct context *, const struct token *,
const char *, unsigned int,
void *, unsigned int);
@@ -4836,6 +4845,23 @@ static const struct token token_list[] = {
port_id)),
.call = parse_vc_conf,
},
+ [ACTION_REPRESENTED_PORT] = {
+ .name = "represented_port",
+ .help = "at embedded switch level, send matching traffic to the entity represented by the given ethdev",
+ .priv = PRIV_ACTION(REPRESENTED_PORT,
+ sizeof(struct rte_flow_action_ethdev)),
+ .next = NEXT(action_represented_port),
+ .call = parse_vc,
+ },
+ [ACTION_REPRESENTED_PORT_ETHDEV_PORT_ID] = {
+ .name = "ethdev_port_id",
+ .help = "ethdev port ID",
+ .next = NEXT(action_represented_port,
+ NEXT_ENTRY(COMMON_UNSIGNED)),
+ .args = ARGS(ARGS_ENTRY(struct rte_flow_action_ethdev,
+ port_id)),
+ .call = parse_vc_conf,
+ },
/* Indirect action destroy arguments. */
[INDIRECT_ACTION_DESTROY_ID] = {
.name = "action_id",
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 587ed37c2c..27a17fac58 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1532,6 +1532,8 @@ at the opposite end of the "wire" leading to the ethdev.
This item is meant to use the same structure as `Item: PORT_REPRESENTOR`_.
+See also `Action: REPRESENTED_PORT`_.
+
Actions
~~~~~~~
@@ -3145,6 +3147,53 @@ at the opposite end of the "wire" leading to the ethdev.
See also `Item: PORT_REPRESENTOR`_.
+Action: ``REPRESENTED_PORT``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+At embedded switch level, send matching traffic to
+the entity represented by the given ethdev.
+
+Term **ethdev** and the concept of **port representor** are synonymous.
+The **represented port** is an *entity* plugged to the embedded switch
+at the opposite end of the "wire" leading to the ethdev.
+
+::
+
+ .--------------------.
+ | PORT_REPRESENTOR | Ethdev (Application Port Referred to by its ID)
+ '--------------------'
+ :
+ :
+ .----------------.
+ | Logical Port |
+ '----------------'
+ :
+ :
+ :
+ :
+ .----------. .--------------------.
+ | Switch | <== | Matching Traffic |
+ '----------' '--------------------'
+ ||
+ ||
+ ||
+ \/
+ .----------------.
+ | Logical Port |
+ '----------------'
+ ||
+ \/
+ .--------------------.
+ | REPRESENTED_PORT | Net / Guest / Another Ethdev (Same Application)
+ '--------------------'
+
+
+- Requires `Attribute: Transfer`_.
+
+This action is meant to use the same structure as `Action: PORT_REPRESENTOR`_.
+
+See also `Item: REPRESENTED_PORT`_.
+
Negative types
~~~~~~~~~~~~~~
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index 9a0ab97914..6c15afc1e9 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -252,7 +252,7 @@ API Changes
the crypto/security operation. This field will be used to communicate
events such as soft expiry with IPsec in lookaside mode.
-* ethdev: Added items ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` and action ``PORT_REPRESENTOR`` to flow API.
+* ethdev: Added items and actions ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` to flow API.
ABI Changes
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 46b7f07cbc..22ba8f0516 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -4090,6 +4090,11 @@ This section lists supported actions and their attributes, if any.
- ``port_id {unsigned}``: ethdev port ID
+- ``represented_port``: at embedded switch level, send matching traffic to
+ the entity represented by the given ethdev
+
+ - ``ethdev_port_id {unsigned}``: ethdev port ID
+
Destroying flow rules
~~~~~~~~~~~~~~~~~~~~~
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index b074b1c77d..542e40e496 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -192,6 +192,7 @@ static const struct rte_flow_desc_data rte_flow_desc_action[] = {
MK_FLOW_ACTION(INDIRECT, 0),
MK_FLOW_ACTION(CONNTRACK, sizeof(struct rte_flow_action_conntrack)),
MK_FLOW_ACTION(PORT_REPRESENTOR, sizeof(struct rte_flow_action_ethdev)),
+ MK_FLOW_ACTION(REPRESENTED_PORT, sizeof(struct rte_flow_action_ethdev)),
};
int
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 56fd4393e5..ff32c0a5ee 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -2462,6 +2462,14 @@ enum rte_flow_action_type {
* @see struct rte_flow_action_ethdev
*/
RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR,
+
+ /**
+ * At embedded switch level, send matching traffic to
+ * the entity represented by the given ethdev.
+ *
+ * @see struct rte_flow_action_ethdev
+ */
+ RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT,
};
/**
@@ -3212,7 +3220,8 @@ struct rte_flow_action_meter_color {
* @b EXPERIMENTAL: this structure may change without prior notice
*
* Provides an ethdev port ID for use with the following actions:
- * RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR.
+ * RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR,
+ * RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT.
*/
struct rte_flow_action_ethdev {
uint16_t port_id; /**< ethdev port ID */
--
2.20.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v4 03/12] ethdev: add port representor action to flow API
2021-10-13 16:42 4% ` [dpdk-dev] [PATCH v4 01/12] ethdev: add port representor item to " Ivan Malov
2021-10-13 16:42 4% ` [dpdk-dev] [PATCH v4 02/12] ethdev: add represented port " Ivan Malov
@ 2021-10-13 16:42 4% ` Ivan Malov
2021-10-13 16:42 4% ` [dpdk-dev] [PATCH v4 04/12] ethdev: add represented port " Ivan Malov
` (2 subsequent siblings)
5 siblings, 0 replies; 200+ results
From: Ivan Malov @ 2021-10-13 16:42 UTC (permalink / raw)
To: dev; +Cc: Ferruh Yigit, Thomas Monjalon, Ori Kam, Andrew Rybchenko, Xiaoyun Li
For use in "transfer" flows. Supposed to send matching traffic to
the given ethdev (to the application), at embedded switch level.
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
app/test-pmd/cmdline_flow.c | 26 ++++++++++
doc/guides/prog_guide/rte_flow.rst | 56 +++++++++++++++++++++
doc/guides/rel_notes/release_21_11.rst | 2 +-
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 5 ++
lib/ethdev/rte_flow.c | 1 +
lib/ethdev/rte_flow.h | 18 +++++++
6 files changed, 107 insertions(+), 1 deletion(-)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 354f0fb2d7..1496d7a067 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -459,6 +459,8 @@ enum index {
ACTION_POL_G,
ACTION_POL_Y,
ACTION_POL_R,
+ ACTION_PORT_REPRESENTOR,
+ ACTION_PORT_REPRESENTOR_PORT_ID,
};
/** Maximum size for pattern in struct rte_flow_item_raw. */
@@ -1451,6 +1453,7 @@ static const enum index next_action[] = {
ACTION_MODIFY_FIELD,
ACTION_CONNTRACK,
ACTION_CONNTRACK_UPDATE,
+ ACTION_PORT_REPRESENTOR,
ZERO,
};
@@ -1731,6 +1734,12 @@ static const enum index action_update_conntrack[] = {
ZERO,
};
+static const enum index action_port_representor[] = {
+ ACTION_PORT_REPRESENTOR_PORT_ID,
+ ACTION_NEXT,
+ ZERO,
+};
+
static int parse_set_raw_encap_decap(struct context *, const struct token *,
const char *, unsigned int,
void *, unsigned int);
@@ -4810,6 +4819,23 @@ static const struct token token_list[] = {
.next = NEXT(action_update_conntrack),
.call = parse_vc_action_conntrack_update,
},
+ [ACTION_PORT_REPRESENTOR] = {
+ .name = "port_representor",
+ .help = "at embedded switch level, send matching traffic to the given ethdev",
+ .priv = PRIV_ACTION(PORT_REPRESENTOR,
+ sizeof(struct rte_flow_action_ethdev)),
+ .next = NEXT(action_port_representor),
+ .call = parse_vc,
+ },
+ [ACTION_PORT_REPRESENTOR_PORT_ID] = {
+ .name = "port_id",
+ .help = "ethdev port ID",
+ .next = NEXT(action_port_representor,
+ NEXT_ENTRY(COMMON_UNSIGNED)),
+ .args = ARGS(ARGS_ENTRY(struct rte_flow_action_ethdev,
+ port_id)),
+ .call = parse_vc_conf,
+ },
/* Indirect action destroy arguments. */
[INDIRECT_ACTION_DESTROY_ID] = {
.name = "action_id",
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 2da286dce8..587ed37c2c 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1484,6 +1484,8 @@ at the opposite end of the "wire" leading to the ethdev.
- Default ``mask`` provides exact match behaviour.
+See also `Action: PORT_REPRESENTOR`_.
+
Item: ``REPRESENTED_PORT``
^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -3089,6 +3091,60 @@ which is set in the packet meta-data (i.e. struct ``rte_mbuf::sched::color``)
| ``meter_color`` | Packet color |
+-----------------+--------------+
+Action: ``PORT_REPRESENTOR``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+At embedded switch level, send matching traffic to the given ethdev.
+
+Term **ethdev** and the concept of **port representor** are synonymous.
+The **represented port** is an *entity* plugged to the embedded switch
+at the opposite end of the "wire" leading to the ethdev.
+
+::
+
+ .--------------------.
+ | PORT_REPRESENTOR | Ethdev (Application Port Referred to by its ID)
+ '--------------------'
+ /\
+ ||
+ .----------------.
+ | Logical Port |
+ '----------------'
+ /\
+ ||
+ ||
+ ||
+ .----------. .--------------------.
+ | Switch | <== | Matching Traffic |
+ '----------' '--------------------'
+ :
+ :
+ :
+ :
+ .----------------.
+ | Logical Port |
+ '----------------'
+ :
+ :
+ .--------------------.
+ | REPRESENTED_PORT | Net / Guest / Another Ethdev (Same Application)
+ '--------------------'
+
+
+- Requires `Attribute: Transfer`_.
+
+.. _table_rte_flow_action_ethdev:
+
+.. table:: ``struct rte_flow_action_ethdev``
+
+ +-------------+----------------+
+ | Field | Value |
+ +=============+================+
+ | ``port_id`` | ethdev port ID |
+ +-------------+----------------+
+
+See also `Item: PORT_REPRESENTOR`_.
+
Negative types
~~~~~~~~~~~~~~
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index b9f918cab8..9a0ab97914 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -252,7 +252,7 @@ API Changes
the crypto/security operation. This field will be used to communicate
events such as soft expiry with IPsec in lookaside mode.
-* ethdev: Added items ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` to flow API.
+* ethdev: Added items ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` and action ``PORT_REPRESENTOR`` to flow API.
ABI Changes
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 61669d1d5a..46b7f07cbc 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -4085,6 +4085,11 @@ This section lists supported actions and their attributes, if any.
- ``type {value}``: Set color type with specified value(green/yellow/red)
+- ``port_representor``: at embedded switch level, send matching traffic to
+ the given ethdev
+
+ - ``port_id {unsigned}``: ethdev port ID
+
Destroying flow rules
~~~~~~~~~~~~~~~~~~~~~
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index d4b654a2c6..b074b1c77d 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -191,6 +191,7 @@ static const struct rte_flow_desc_data rte_flow_desc_action[] = {
*/
MK_FLOW_ACTION(INDIRECT, 0),
MK_FLOW_ACTION(CONNTRACK, sizeof(struct rte_flow_action_conntrack)),
+ MK_FLOW_ACTION(PORT_REPRESENTOR, sizeof(struct rte_flow_action_ethdev)),
};
int
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index b50c3d38b5..56fd4393e5 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -2455,6 +2455,13 @@ enum rte_flow_action_type {
* See struct rte_flow_action_meter_color.
*/
RTE_FLOW_ACTION_TYPE_METER_COLOR,
+
+ /**
+ * At embedded switch level, sends matching traffic to the given ethdev.
+ *
+ * @see struct rte_flow_action_ethdev
+ */
+ RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR,
};
/**
@@ -3200,6 +3207,17 @@ struct rte_flow_action_meter_color {
enum rte_color color; /**< Packet color. */
};
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * Provides an ethdev port ID for use with the following actions:
+ * RTE_FLOW_ACTION_TYPE_PORT_REPRESENTOR.
+ */
+struct rte_flow_action_ethdev {
+ uint16_t port_id; /**< ethdev port ID */
+};
+
/**
* Field IDs for MODIFY_FIELD action.
*/
--
2.20.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v4 02/12] ethdev: add represented port item to flow API
2021-10-13 16:42 4% ` [dpdk-dev] [PATCH v4 01/12] ethdev: add port representor item to " Ivan Malov
@ 2021-10-13 16:42 4% ` Ivan Malov
2021-10-13 16:42 4% ` [dpdk-dev] [PATCH v4 03/12] ethdev: add port representor action " Ivan Malov
` (3 subsequent siblings)
5 siblings, 0 replies; 200+ results
From: Ivan Malov @ 2021-10-13 16:42 UTC (permalink / raw)
To: dev; +Cc: Ferruh Yigit, Thomas Monjalon, Ori Kam, Andrew Rybchenko, Xiaoyun Li
For use in "transfer" flows. Supposed to match traffic entering the
embedded switch from the entity represented by the given ethdev.
Such an entity can be a network (via a network port), a guest
machine (via a VF) or another ethdev in the same application.
Must not be combined with direction attributes.
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
app/test-pmd/cmdline_flow.c | 25 +++++++++++
doc/guides/prog_guide/rte_flow.rst | 46 +++++++++++++++++++++
doc/guides/rel_notes/release_21_11.rst | 2 +-
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 5 +++
lib/ethdev/rte_flow.c | 1 +
lib/ethdev/rte_flow.h | 13 +++++-
6 files changed, 90 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 5c480db91d..354f0fb2d7 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -308,6 +308,8 @@ enum index {
ITEM_POL_POLICY,
ITEM_PORT_REPRESENTOR,
ITEM_PORT_REPRESENTOR_PORT_ID,
+ ITEM_REPRESENTED_PORT,
+ ITEM_REPRESENTED_PORT_ETHDEV_PORT_ID,
/* Validate/create actions. */
ACTIONS,
@@ -1002,6 +1004,7 @@ static const enum index next_item[] = {
ITEM_INTEGRITY,
ITEM_CONNTRACK,
ITEM_PORT_REPRESENTOR,
+ ITEM_REPRESENTED_PORT,
END_SET,
ZERO,
};
@@ -1376,6 +1379,12 @@ static const enum index item_port_representor[] = {
ZERO,
};
+static const enum index item_represented_port[] = {
+ ITEM_REPRESENTED_PORT_ETHDEV_PORT_ID,
+ ITEM_NEXT,
+ ZERO,
+};
+
static const enum index next_action[] = {
ACTION_END,
ACTION_VOID,
@@ -3630,6 +3639,21 @@ static const struct token token_list[] = {
item_param),
.args = ARGS(ARGS_ENTRY(struct rte_flow_item_ethdev, port_id)),
},
+ [ITEM_REPRESENTED_PORT] = {
+ .name = "represented_port",
+ .help = "match traffic entering the embedded switch from the entity represented by the given ethdev",
+ .priv = PRIV_ITEM(REPRESENTED_PORT,
+ sizeof(struct rte_flow_item_ethdev)),
+ .next = NEXT(item_represented_port),
+ .call = parse_vc,
+ },
+ [ITEM_REPRESENTED_PORT_ETHDEV_PORT_ID] = {
+ .name = "ethdev_port_id",
+ .help = "ethdev port ID",
+ .next = NEXT(item_represented_port, NEXT_ENTRY(COMMON_UNSIGNED),
+ item_param),
+ .args = ARGS(ARGS_ENTRY(struct rte_flow_item_ethdev, port_id)),
+ },
/* Validate/create actions. */
[ACTIONS] = {
.name = "actions",
@@ -8358,6 +8382,7 @@ flow_item_default_mask(const struct rte_flow_item *item)
mask = &rte_flow_item_pfcp_mask;
break;
case RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR:
+ case RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT:
mask = &rte_flow_item_ethdev_mask;
break;
default:
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index d194640469..2da286dce8 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1484,6 +1484,52 @@ at the opposite end of the "wire" leading to the ethdev.
- Default ``mask`` provides exact match behaviour.
+Item: ``REPRESENTED_PORT``
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Matches traffic entering the embedded switch from
+the entity represented by the given ethdev.
+
+Term **ethdev** and the concept of **port representor** are synonymous.
+The **represented port** is an *entity* plugged to the embedded switch
+at the opposite end of the "wire" leading to the ethdev.
+
+::
+
+ .--------------------.
+ | PORT_REPRESENTOR | Ethdev (Application Port Referred to by its ID)
+ '--------------------'
+ :
+ :
+ .----------------.
+ | Logical Port |
+ '----------------'
+ :
+ :
+ :
+ :
+ .----------.
+ | Switch |
+ '----------'
+ /\
+ ||
+ ||
+ ||
+ .----------------.
+ | Logical Port |
+ '----------------'
+ /\
+ ||
+ .--------------------.
+ | REPRESENTED_PORT | Net / Guest / Another Ethdev (Same Application)
+ '--------------------'
+
+
+- Incompatible with `Attribute: Traffic direction`_.
+- Requires `Attribute: Transfer`_.
+
+This item is meant to use the same structure as `Item: PORT_REPRESENTOR`_.
+
Actions
~~~~~~~
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index 07f9d39a5b..b9f918cab8 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -252,7 +252,7 @@ API Changes
the crypto/security operation. This field will be used to communicate
events such as soft expiry with IPsec in lookaside mode.
-* ethdev: Added item ``PORT_REPRESENTOR`` to flow API.
+* ethdev: Added items ``PORT_REPRESENTOR``, ``REPRESENTED_PORT`` to flow API.
ABI Changes
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 90765f9090..61669d1d5a 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -3805,6 +3805,11 @@ This section lists supported pattern items and their attributes, if any.
- ``port_id {unsigned}``: ethdev port ID
+- ``represented_port``: match traffic entering the embedded switch from
+ the entity represented by the given ethdev
+
+ - ``ethdev_port_id {unsigned}``: ethdev port ID
+
Actions list
^^^^^^^^^^^^
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index 5e9317c6d1..d4b654a2c6 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -101,6 +101,7 @@ static const struct rte_flow_desc_data rte_flow_desc_item[] = {
MK_FLOW_ITEM(INTEGRITY, sizeof(struct rte_flow_item_integrity)),
MK_FLOW_ITEM(CONNTRACK, sizeof(uint32_t)),
MK_FLOW_ITEM(PORT_REPRESENTOR, sizeof(struct rte_flow_item_ethdev)),
+ MK_FLOW_ITEM(REPRESENTED_PORT, sizeof(struct rte_flow_item_ethdev)),
};
/** Generate flow_action[] entry. */
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 1e3ef77ead..b50c3d38b5 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -583,6 +583,16 @@ enum rte_flow_item_type {
* @see struct rte_flow_item_ethdev
*/
RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR,
+
+ /**
+ * [META]
+ *
+ * Matches traffic entering the embedded switch from
+ * the entity represented by the given ethdev.
+ *
+ * @see struct rte_flow_item_ethdev
+ */
+ RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT,
};
/**
@@ -1813,7 +1823,8 @@ static const struct rte_flow_item_conntrack rte_flow_item_conntrack_mask = {
* @b EXPERIMENTAL: this structure may change without prior notice
*
* Provides an ethdev port ID for use with the following items:
- * RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR.
+ * RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR,
+ * RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT.
*/
struct rte_flow_item_ethdev {
uint16_t port_id; /**< ethdev port ID */
--
2.20.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v4 01/12] ethdev: add port representor item to flow API
@ 2021-10-13 16:42 4% ` Ivan Malov
2021-10-13 16:42 4% ` [dpdk-dev] [PATCH v4 02/12] ethdev: add represented port " Ivan Malov
` (4 subsequent siblings)
5 siblings, 0 replies; 200+ results
From: Ivan Malov @ 2021-10-13 16:42 UTC (permalink / raw)
To: dev; +Cc: Ferruh Yigit, Thomas Monjalon, Ori Kam, Andrew Rybchenko, Xiaoyun Li
For use in "transfer" flows. Supposed to match traffic
entering the embedded switch from the given ethdev.
Must not be combined with direction attributes.
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
app/test-pmd/cmdline_flow.c | 27 ++++++++++
doc/guides/prog_guide/rte_flow.rst | 59 +++++++++++++++++++++
doc/guides/rel_notes/release_21_11.rst | 2 +
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 4 ++
lib/ethdev/rte_flow.c | 1 +
lib/ethdev/rte_flow.h | 27 ++++++++++
6 files changed, 120 insertions(+)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 0b5856c7d5..5c480db91d 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -306,6 +306,8 @@ enum index {
ITEM_POL_PORT,
ITEM_POL_METER,
ITEM_POL_POLICY,
+ ITEM_PORT_REPRESENTOR,
+ ITEM_PORT_REPRESENTOR_PORT_ID,
/* Validate/create actions. */
ACTIONS,
@@ -999,6 +1001,7 @@ static const enum index next_item[] = {
ITEM_GENEVE_OPT,
ITEM_INTEGRITY,
ITEM_CONNTRACK,
+ ITEM_PORT_REPRESENTOR,
END_SET,
ZERO,
};
@@ -1367,6 +1370,12 @@ static const enum index item_integrity_lv[] = {
ZERO,
};
+static const enum index item_port_representor[] = {
+ ITEM_PORT_REPRESENTOR_PORT_ID,
+ ITEM_NEXT,
+ ZERO,
+};
+
static const enum index next_action[] = {
ACTION_END,
ACTION_VOID,
@@ -3606,6 +3615,21 @@ static const struct token token_list[] = {
item_param),
.args = ARGS(ARGS_ENTRY(struct rte_flow_item_conntrack, flags)),
},
+ [ITEM_PORT_REPRESENTOR] = {
+ .name = "port_representor",
+ .help = "match traffic entering the embedded switch from the given ethdev",
+ .priv = PRIV_ITEM(PORT_REPRESENTOR,
+ sizeof(struct rte_flow_item_ethdev)),
+ .next = NEXT(item_port_representor),
+ .call = parse_vc,
+ },
+ [ITEM_PORT_REPRESENTOR_PORT_ID] = {
+ .name = "port_id",
+ .help = "ethdev port ID",
+ .next = NEXT(item_port_representor, NEXT_ENTRY(COMMON_UNSIGNED),
+ item_param),
+ .args = ARGS(ARGS_ENTRY(struct rte_flow_item_ethdev, port_id)),
+ },
/* Validate/create actions. */
[ACTIONS] = {
.name = "actions",
@@ -8333,6 +8357,9 @@ flow_item_default_mask(const struct rte_flow_item *item)
case RTE_FLOW_ITEM_TYPE_PFCP:
mask = &rte_flow_item_pfcp_mask;
break;
+ case RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR:
+ mask = &rte_flow_item_ethdev_mask;
+ break;
default:
break;
}
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 3cb014c1fa..d194640469 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1425,6 +1425,65 @@ Matches a conntrack state after conntrack action.
- ``flags``: conntrack packet state flags.
- Default ``mask`` matches all state bits.
+Item: ``PORT_REPRESENTOR``
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Matches traffic entering the embedded switch from the given ethdev.
+
+Term **ethdev** and the concept of **port representor** are synonymous.
+The **represented port** is an *entity* plugged to the embedded switch
+at the opposite end of the "wire" leading to the ethdev.
+
+::
+
+ .--------------------.
+ | PORT_REPRESENTOR | Ethdev (Application Port Referred to by its ID)
+ '--------------------'
+ ||
+ \/
+ .----------------.
+ | Logical Port |
+ '----------------'
+ ||
+ ||
+ ||
+ \/
+ .----------.
+ | Switch |
+ '----------'
+ :
+ :
+ :
+ :
+ .----------------.
+ | Logical Port |
+ '----------------'
+ :
+ :
+ .--------------------.
+ | REPRESENTED_PORT | Net / Guest / Another Ethdev (Same Application)
+ '--------------------'
+
+
+- Incompatible with `Attribute: Traffic direction`_.
+- Requires `Attribute: Transfer`_.
+
+.. _table_rte_flow_item_ethdev:
+
+.. table:: ``struct rte_flow_item_ethdev``
+
+ +----------+-------------+---------------------------+
+ | Field | Subfield | Value |
+ +==========+=============+===========================+
+ | ``spec`` | ``port_id`` | ethdev port ID |
+ +----------+-------------+---------------------------+
+ | ``last`` | ``port_id`` | upper range value |
+ +----------+-------------+---------------------------+
+ | ``mask`` | ``port_id`` | zeroed for wildcard match |
+ +----------+-------------+---------------------------+
+
+- Default ``mask`` provides exact match behaviour.
+
Actions
~~~~~~~
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index d5c762df62..07f9d39a5b 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -252,6 +252,8 @@ API Changes
the crypto/security operation. This field will be used to communicate
events such as soft expiry with IPsec in lookaside mode.
+* ethdev: Added item ``PORT_REPRESENTOR`` to flow API.
+
ABI Changes
-----------
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index a0efb7d0b0..90765f9090 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -3801,6 +3801,10 @@ This section lists supported pattern items and their attributes, if any.
- ``conntrack``: match conntrack state.
+- ``port_representor``: match traffic entering the embedded switch from the given ethdev
+
+ - ``port_id {unsigned}``: ethdev port ID
+
Actions list
^^^^^^^^^^^^
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index 8cb7a069c8..5e9317c6d1 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -100,6 +100,7 @@ static const struct rte_flow_desc_data rte_flow_desc_item[] = {
MK_FLOW_ITEM(GENEVE_OPT, sizeof(struct rte_flow_item_geneve_opt)),
MK_FLOW_ITEM(INTEGRITY, sizeof(struct rte_flow_item_integrity)),
MK_FLOW_ITEM(CONNTRACK, sizeof(uint32_t)),
+ MK_FLOW_ITEM(PORT_REPRESENTOR, sizeof(struct rte_flow_item_ethdev)),
};
/** Generate flow_action[] entry. */
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 5f87851f8c..1e3ef77ead 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -574,6 +574,15 @@ enum rte_flow_item_type {
* @see struct rte_flow_item_conntrack.
*/
RTE_FLOW_ITEM_TYPE_CONNTRACK,
+
+ /**
+ * [META]
+ *
+ * Matches traffic entering the embedded switch from the given ethdev.
+ *
+ * @see struct rte_flow_item_ethdev
+ */
+ RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR,
};
/**
@@ -1799,6 +1808,24 @@ static const struct rte_flow_item_conntrack rte_flow_item_conntrack_mask = {
};
#endif
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * Provides an ethdev port ID for use with the following items:
+ * RTE_FLOW_ITEM_TYPE_PORT_REPRESENTOR.
+ */
+struct rte_flow_item_ethdev {
+ uint16_t port_id; /**< ethdev port ID */
+};
+
+/** Default mask for items based on struct rte_flow_item_ethdev */
+#ifndef __cplusplus
+static const struct rte_flow_item_ethdev rte_flow_item_ethdev_mask = {
+ .port_id = 0xffff,
+};
+#endif
+
/**
* Matching pattern item definition.
*
--
2.20.1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v6 3/6] ethdev: copy fast-path API into separate structure
2021-10-13 13:37 2% ` [dpdk-dev] [PATCH v6 3/6] ethdev: copy fast-path API into separate structure Konstantin Ananyev
@ 2021-10-13 14:25 0% ` Andrew Rybchenko
0 siblings, 0 replies; 200+ results
From: Andrew Rybchenko @ 2021-10-13 14:25 UTC (permalink / raw)
To: Konstantin Ananyev, dev
Cc: xiaoyun.li, anoobj, jerinj, ndabilpuram, adwivedi,
shepard.siegel, ed.czeck, john.miller, irusskikh, ajit.khaparde,
somnath.kotur, rahul.lakkireddy, hemant.agrawal, sachin.saxena,
haiyue.wang, johndale, hyonkim, qi.z.zhang, xiao.w.wang, humin29,
yisen.zhuang, oulijun, beilei.xing, jingjing.wu, qiming.yang,
matan, viacheslavo, sthemmin, longli, heinrich.kuhn, kirankumark,
mczekaj, jiawenwu, jianwang, maxime.coquelin, chenbo.xia, thomas,
ferruh.yigit, mdr, jay.jayatheerthan
On 10/13/21 4:37 PM, Konstantin Ananyev wrote:
> Copy public function pointers (rx_pkt_burst(), etc.) and related
> pointers to internal data from rte_eth_dev structure into a
> separate flat array. That array will remain in a public header.
> The intention here is to make rte_eth_dev and related structures internal.
> That should allow future possible changes to core eth_dev structures
> to be transparent to the user and help to avoid ABI/API breakages.
> The plan is to keep minimal part of data from rte_eth_dev public,
> so we still can use inline functions for fast-path calls
> (like rte_eth_rx_burst(), etc.) to avoid/minimize slowdown.
> The whole idea beyond this new schema:
> 1. PMDs keep to setup fast-path function pointers and related data
> inside rte_eth_dev struct in the same way they did it before.
> 2. Inside rte_eth_dev_start() and inside rte_eth_dev_probing_finish()
> (for secondary process) we call eth_dev_fp_ops_setup, which
> copies these function and data pointers into rte_eth_fp_ops[port_id].
> 3. Inside rte_eth_dev_stop() and inside rte_eth_dev_release_port()
> we call eth_dev_fp_ops_reset(), which resets rte_eth_fp_ops[port_id]
> into some dummy values.
> 4. fast-path ethdev API (rte_eth_rx_burst(), etc.) will use that new
> flat array to call PMD specific functions.
> That approach should allow us to make rte_eth_devices[] private
> without introducing regression and help to avoid changes in drivers code.
>
> Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
Reviewed-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v6 6/6] ethdev: hide eth dev related structures
2021-10-13 13:36 4% ` [dpdk-dev] [PATCH v6 0/6] hide eth dev related structures Konstantin Ananyev
` (2 preceding siblings ...)
2021-10-13 13:37 2% ` [dpdk-dev] [PATCH v6 4/6] ethdev: make fast-path functions to use new flat array Konstantin Ananyev
@ 2021-10-13 13:37 8% ` Konstantin Ananyev
2021-10-13 20:16 0% ` [dpdk-dev] [PATCH v6 0/6] " Ferruh Yigit
4 siblings, 0 replies; 200+ results
From: Konstantin Ananyev @ 2021-10-13 13:37 UTC (permalink / raw)
To: dev
Cc: xiaoyun.li, anoobj, jerinj, ndabilpuram, adwivedi,
shepard.siegel, ed.czeck, john.miller, irusskikh, ajit.khaparde,
somnath.kotur, rahul.lakkireddy, hemant.agrawal, sachin.saxena,
haiyue.wang, johndale, hyonkim, qi.z.zhang, xiao.w.wang, humin29,
yisen.zhuang, oulijun, beilei.xing, jingjing.wu, qiming.yang,
matan, viacheslavo, sthemmin, longli, heinrich.kuhn, kirankumark,
andrew.rybchenko, mczekaj, jiawenwu, jianwang, maxime.coquelin,
chenbo.xia, thomas, ferruh.yigit, mdr, jay.jayatheerthan,
Konstantin Ananyev
Move rte_eth_dev, rte_eth_dev_data, rte_eth_rxtx_callback and related
data into private header (ethdev_driver.h).
Few minor changes to keep DPDK building after that.
Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
---
doc/guides/rel_notes/release_21_11.rst | 6 +
drivers/common/octeontx2/otx2_sec_idev.c | 2 +-
drivers/crypto/octeontx2/otx2_cryptodev_ops.c | 2 +-
drivers/net/cxgbe/base/adapter.h | 2 +-
drivers/net/dpaa2/dpaa2_ptp.c | 2 +-
drivers/net/netvsc/hn_var.h | 1 +
lib/ethdev/ethdev_driver.h | 154 ++++++++++++++++++
lib/ethdev/rte_ethdev_core.h | 149 -----------------
lib/ethdev/version.map | 2 +-
lib/eventdev/rte_event_eth_rx_adapter.c | 2 +-
lib/eventdev/rte_event_eth_tx_adapter.c | 2 +-
lib/eventdev/rte_eventdev.c | 2 +-
lib/metrics/rte_metrics_telemetry.c | 2 +-
13 files changed, 170 insertions(+), 158 deletions(-)
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index d44c1696cd..626448988d 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -310,6 +310,12 @@ ABI Changes
to user, it still counts as an ABI change, as ``eth_rx_queue_count_t``
is used by public inline function ``rte_eth_rx_queue_count``.
+* ethdev: Made ``rte_eth_dev``, ``rte_eth_dev_data``, ``rte_eth_rxtx_callback``
+ private data structures. ``rte_eth_devices[]`` can't be accessed directly
+ by user any more. While it is an ABI breakage, this change is intended
+ to be transparent for both users (no changes in user app is required) and
+ PMD developers (no changes in PMD is required).
+
Known Issues
------------
diff --git a/drivers/common/octeontx2/otx2_sec_idev.c b/drivers/common/octeontx2/otx2_sec_idev.c
index 6e9643c383..b561b67174 100644
--- a/drivers/common/octeontx2/otx2_sec_idev.c
+++ b/drivers/common/octeontx2/otx2_sec_idev.c
@@ -4,7 +4,7 @@
#include <rte_atomic.h>
#include <rte_bus_pci.h>
-#include <rte_ethdev.h>
+#include <ethdev_driver.h>
#include <rte_spinlock.h>
#include "otx2_common.h"
diff --git a/drivers/crypto/octeontx2/otx2_cryptodev_ops.c b/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
index 37fad11d91..f0b72e05c2 100644
--- a/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
+++ b/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
@@ -6,7 +6,7 @@
#include <cryptodev_pmd.h>
#include <rte_errno.h>
-#include <rte_ethdev.h>
+#include <ethdev_driver.h>
#include <rte_event_crypto_adapter.h>
#include "otx2_cryptodev.h"
diff --git a/drivers/net/cxgbe/base/adapter.h b/drivers/net/cxgbe/base/adapter.h
index 01a2a9d147..1c7c8afe16 100644
--- a/drivers/net/cxgbe/base/adapter.h
+++ b/drivers/net/cxgbe/base/adapter.h
@@ -12,7 +12,7 @@
#include <rte_mbuf.h>
#include <rte_io.h>
#include <rte_rwlock.h>
-#include <rte_ethdev.h>
+#include <ethdev_driver.h>
#include "../cxgbe_compat.h"
#include "../cxgbe_ofld.h"
diff --git a/drivers/net/dpaa2/dpaa2_ptp.c b/drivers/net/dpaa2/dpaa2_ptp.c
index 899dd5d442..8d79e39244 100644
--- a/drivers/net/dpaa2/dpaa2_ptp.c
+++ b/drivers/net/dpaa2/dpaa2_ptp.c
@@ -10,7 +10,7 @@
#include <unistd.h>
#include <stdarg.h>
-#include <rte_ethdev.h>
+#include <ethdev_driver.h>
#include <rte_log.h>
#include <rte_eth_ctrl.h>
#include <rte_malloc.h>
diff --git a/drivers/net/netvsc/hn_var.h b/drivers/net/netvsc/hn_var.h
index 18703f99b9..fbb3995507 100644
--- a/drivers/net/netvsc/hn_var.h
+++ b/drivers/net/netvsc/hn_var.h
@@ -7,6 +7,7 @@
*/
#include <rte_eal_paging.h>
+#include <ethdev_driver.h>
/*
* Tunable ethdev params
diff --git a/lib/ethdev/ethdev_driver.h b/lib/ethdev/ethdev_driver.h
index 56db53df1a..0174ba03d7 100644
--- a/lib/ethdev/ethdev_driver.h
+++ b/lib/ethdev/ethdev_driver.h
@@ -17,6 +17,160 @@
#include <rte_ethdev.h>
+/**
+ * @internal
+ * Structure used to hold information about the callbacks to be called for a
+ * queue on RX and TX.
+ */
+struct rte_eth_rxtx_callback {
+ struct rte_eth_rxtx_callback *next;
+ union{
+ rte_rx_callback_fn rx;
+ rte_tx_callback_fn tx;
+ } fn;
+ void *param;
+};
+
+/**
+ * @internal
+ * The generic data structure associated with each ethernet device.
+ *
+ * Pointers to burst-oriented packet receive and transmit functions are
+ * located at the beginning of the structure, along with the pointer to
+ * where all the data elements for the particular device are stored in shared
+ * memory. This split allows the function pointer and driver data to be per-
+ * process, while the actual configuration data for the device is shared.
+ */
+struct rte_eth_dev {
+ eth_rx_burst_t rx_pkt_burst; /**< Pointer to PMD receive function. */
+ eth_tx_burst_t tx_pkt_burst; /**< Pointer to PMD transmit function. */
+ eth_tx_prep_t tx_pkt_prepare;
+ /**< Pointer to PMD transmit prepare function. */
+ eth_rx_queue_count_t rx_queue_count;
+ /**< Get the number of used RX descriptors. */
+ eth_rx_descriptor_status_t rx_descriptor_status;
+ /**< Check the status of a Rx descriptor. */
+ eth_tx_descriptor_status_t tx_descriptor_status;
+ /**< Check the status of a Tx descriptor. */
+
+ /**
+ * points to device data that is shared between
+ * primary and secondary processes.
+ */
+ struct rte_eth_dev_data *data;
+ void *process_private; /**< Pointer to per-process device data. */
+ const struct eth_dev_ops *dev_ops; /**< Functions exported by PMD */
+ struct rte_device *device; /**< Backing device */
+ struct rte_intr_handle *intr_handle; /**< Device interrupt handle */
+ /** User application callbacks for NIC interrupts */
+ struct rte_eth_dev_cb_list link_intr_cbs;
+ /**
+ * User-supplied functions called from rx_burst to post-process
+ * received packets before passing them to the user
+ */
+ struct rte_eth_rxtx_callback *post_rx_burst_cbs[RTE_MAX_QUEUES_PER_PORT];
+ /**
+ * User-supplied functions called from tx_burst to pre-process
+ * received packets before passing them to the driver for transmission.
+ */
+ struct rte_eth_rxtx_callback *pre_tx_burst_cbs[RTE_MAX_QUEUES_PER_PORT];
+ enum rte_eth_dev_state state; /**< Flag indicating the port state */
+ void *security_ctx; /**< Context for security ops */
+
+ uint64_t reserved_64s[4]; /**< Reserved for future fields */
+ void *reserved_ptrs[4]; /**< Reserved for future fields */
+} __rte_cache_aligned;
+
+struct rte_eth_dev_sriov;
+struct rte_eth_dev_owner;
+
+/**
+ * @internal
+ * The data part, with no function pointers, associated with each ethernet
+ * device. This structure is safe to place in shared memory to be common
+ * among different processes in a multi-process configuration.
+ */
+struct rte_eth_dev_data {
+ char name[RTE_ETH_NAME_MAX_LEN]; /**< Unique identifier name */
+
+ void **rx_queues; /**< Array of pointers to RX queues. */
+ void **tx_queues; /**< Array of pointers to TX queues. */
+ uint16_t nb_rx_queues; /**< Number of RX queues. */
+ uint16_t nb_tx_queues; /**< Number of TX queues. */
+
+ struct rte_eth_dev_sriov sriov; /**< SRIOV data */
+
+ void *dev_private;
+ /**< PMD-specific private data.
+ * @see rte_eth_dev_release_port()
+ */
+
+ struct rte_eth_link dev_link; /**< Link-level information & status. */
+ struct rte_eth_conf dev_conf; /**< Configuration applied to device. */
+ uint16_t mtu; /**< Maximum Transmission Unit. */
+ uint32_t min_rx_buf_size;
+ /**< Common RX buffer size handled by all queues. */
+
+ uint64_t rx_mbuf_alloc_failed; /**< RX ring mbuf allocation failures. */
+ struct rte_ether_addr *mac_addrs;
+ /**< Device Ethernet link address.
+ * @see rte_eth_dev_release_port()
+ */
+ uint64_t mac_pool_sel[ETH_NUM_RECEIVE_MAC_ADDR];
+ /**< Bitmap associating MAC addresses to pools. */
+ struct rte_ether_addr *hash_mac_addrs;
+ /**< Device Ethernet MAC addresses of hash filtering.
+ * @see rte_eth_dev_release_port()
+ */
+ uint16_t port_id; /**< Device [external] port identifier. */
+
+ __extension__
+ uint8_t promiscuous : 1,
+ /**< RX promiscuous mode ON(1) / OFF(0). */
+ scattered_rx : 1,
+ /**< RX of scattered packets is ON(1) / OFF(0) */
+ all_multicast : 1,
+ /**< RX all multicast mode ON(1) / OFF(0). */
+ dev_started : 1,
+ /**< Device state: STARTED(1) / STOPPED(0). */
+ lro : 1,
+ /**< RX LRO is ON(1) / OFF(0) */
+ dev_configured : 1;
+ /**< Indicates whether the device is configured.
+ * CONFIGURED(1) / NOT CONFIGURED(0).
+ */
+ uint8_t rx_queue_state[RTE_MAX_QUEUES_PER_PORT];
+ /**< Queues state: HAIRPIN(2) / STARTED(1) / STOPPED(0). */
+ uint8_t tx_queue_state[RTE_MAX_QUEUES_PER_PORT];
+ /**< Queues state: HAIRPIN(2) / STARTED(1) / STOPPED(0). */
+ uint32_t dev_flags; /**< Capabilities. */
+ int numa_node; /**< NUMA node connection. */
+ struct rte_vlan_filter_conf vlan_filter_conf;
+ /**< VLAN filter configuration. */
+ struct rte_eth_dev_owner owner; /**< The port owner. */
+ uint16_t representor_id;
+ /**< Switch-specific identifier.
+ * Valid if RTE_ETH_DEV_REPRESENTOR in dev_flags.
+ */
+ uint16_t backer_port_id;
+ /**< Port ID of the backing device.
+ * This device will be used to query representor
+ * info and calculate representor IDs.
+ * Valid if RTE_ETH_DEV_REPRESENTOR in dev_flags.
+ */
+
+ pthread_mutex_t flow_ops_mutex; /**< rte_flow ops mutex. */
+ uint64_t reserved_64s[4]; /**< Reserved for future fields */
+ void *reserved_ptrs[4]; /**< Reserved for future fields */
+} __rte_cache_aligned;
+
+/**
+ * @internal
+ * The pool of *rte_eth_dev* structures. The size of the pool
+ * is configured at compile-time in the <rte_ethdev.c> file.
+ */
+extern struct rte_eth_dev rte_eth_devices[];
+
/**< @internal Declaration of the hairpin peer queue information structure. */
struct rte_hairpin_peer_info;
diff --git a/lib/ethdev/rte_ethdev_core.h b/lib/ethdev/rte_ethdev_core.h
index df7168ca4b..2b8660c578 100644
--- a/lib/ethdev/rte_ethdev_core.h
+++ b/lib/ethdev/rte_ethdev_core.h
@@ -109,153 +109,4 @@ struct rte_eth_fp_ops {
extern struct rte_eth_fp_ops rte_eth_fp_ops[RTE_MAX_ETHPORTS];
-
-/**
- * @internal
- * Structure used to hold information about the callbacks to be called for a
- * queue on RX and TX.
- */
-struct rte_eth_rxtx_callback {
- struct rte_eth_rxtx_callback *next;
- union{
- rte_rx_callback_fn rx;
- rte_tx_callback_fn tx;
- } fn;
- void *param;
-};
-
-/**
- * @internal
- * The generic data structure associated with each ethernet device.
- *
- * Pointers to burst-oriented packet receive and transmit functions are
- * located at the beginning of the structure, along with the pointer to
- * where all the data elements for the particular device are stored in shared
- * memory. This split allows the function pointer and driver data to be per-
- * process, while the actual configuration data for the device is shared.
- */
-struct rte_eth_dev {
- eth_rx_burst_t rx_pkt_burst; /**< Pointer to PMD receive function. */
- eth_tx_burst_t tx_pkt_burst; /**< Pointer to PMD transmit function. */
- eth_tx_prep_t tx_pkt_prepare; /**< Pointer to PMD transmit prepare function. */
-
- eth_rx_queue_count_t rx_queue_count; /**< Get the number of used RX descriptors. */
- eth_rx_descriptor_status_t rx_descriptor_status; /**< Check the status of a Rx descriptor. */
- eth_tx_descriptor_status_t tx_descriptor_status; /**< Check the status of a Tx descriptor. */
-
- /**
- * Next two fields are per-device data but *data is shared between
- * primary and secondary processes and *process_private is per-process
- * private. The second one is managed by PMDs if necessary.
- */
- struct rte_eth_dev_data *data; /**< Pointer to device data. */
- void *process_private; /**< Pointer to per-process device data. */
- const struct eth_dev_ops *dev_ops; /**< Functions exported by PMD */
- struct rte_device *device; /**< Backing device */
- struct rte_intr_handle *intr_handle; /**< Device interrupt handle */
- /** User application callbacks for NIC interrupts */
- struct rte_eth_dev_cb_list link_intr_cbs;
- /**
- * User-supplied functions called from rx_burst to post-process
- * received packets before passing them to the user
- */
- struct rte_eth_rxtx_callback *post_rx_burst_cbs[RTE_MAX_QUEUES_PER_PORT];
- /**
- * User-supplied functions called from tx_burst to pre-process
- * received packets before passing them to the driver for transmission.
- */
- struct rte_eth_rxtx_callback *pre_tx_burst_cbs[RTE_MAX_QUEUES_PER_PORT];
- enum rte_eth_dev_state state; /**< Flag indicating the port state */
- void *security_ctx; /**< Context for security ops */
-
- uint64_t reserved_64s[4]; /**< Reserved for future fields */
- void *reserved_ptrs[4]; /**< Reserved for future fields */
-} __rte_cache_aligned;
-
-struct rte_eth_dev_sriov;
-struct rte_eth_dev_owner;
-
-/**
- * @internal
- * The data part, with no function pointers, associated with each ethernet device.
- *
- * This structure is safe to place in shared memory to be common among different
- * processes in a multi-process configuration.
- */
-struct rte_eth_dev_data {
- char name[RTE_ETH_NAME_MAX_LEN]; /**< Unique identifier name */
-
- void **rx_queues; /**< Array of pointers to RX queues. */
- void **tx_queues; /**< Array of pointers to TX queues. */
- uint16_t nb_rx_queues; /**< Number of RX queues. */
- uint16_t nb_tx_queues; /**< Number of TX queues. */
-
- struct rte_eth_dev_sriov sriov; /**< SRIOV data */
-
- void *dev_private;
- /**< PMD-specific private data.
- * @see rte_eth_dev_release_port()
- */
-
- struct rte_eth_link dev_link; /**< Link-level information & status. */
- struct rte_eth_conf dev_conf; /**< Configuration applied to device. */
- uint16_t mtu; /**< Maximum Transmission Unit. */
- uint32_t min_rx_buf_size;
- /**< Common RX buffer size handled by all queues. */
-
- uint64_t rx_mbuf_alloc_failed; /**< RX ring mbuf allocation failures. */
- struct rte_ether_addr *mac_addrs;
- /**< Device Ethernet link address.
- * @see rte_eth_dev_release_port()
- */
- uint64_t mac_pool_sel[ETH_NUM_RECEIVE_MAC_ADDR];
- /**< Bitmap associating MAC addresses to pools. */
- struct rte_ether_addr *hash_mac_addrs;
- /**< Device Ethernet MAC addresses of hash filtering.
- * @see rte_eth_dev_release_port()
- */
- uint16_t port_id; /**< Device [external] port identifier. */
-
- __extension__
- uint8_t promiscuous : 1, /**< RX promiscuous mode ON(1) / OFF(0). */
- scattered_rx : 1, /**< RX of scattered packets is ON(1) / OFF(0) */
- all_multicast : 1, /**< RX all multicast mode ON(1) / OFF(0). */
- dev_started : 1, /**< Device state: STARTED(1) / STOPPED(0). */
- lro : 1, /**< RX LRO is ON(1) / OFF(0) */
- dev_configured : 1;
- /**< Indicates whether the device is configured.
- * CONFIGURED(1) / NOT CONFIGURED(0).
- */
- uint8_t rx_queue_state[RTE_MAX_QUEUES_PER_PORT];
- /**< Queues state: HAIRPIN(2) / STARTED(1) / STOPPED(0). */
- uint8_t tx_queue_state[RTE_MAX_QUEUES_PER_PORT];
- /**< Queues state: HAIRPIN(2) / STARTED(1) / STOPPED(0). */
- uint32_t dev_flags; /**< Capabilities. */
- int numa_node; /**< NUMA node connection. */
- struct rte_vlan_filter_conf vlan_filter_conf;
- /**< VLAN filter configuration. */
- struct rte_eth_dev_owner owner; /**< The port owner. */
- uint16_t representor_id;
- /**< Switch-specific identifier.
- * Valid if RTE_ETH_DEV_REPRESENTOR in dev_flags.
- */
- uint16_t backer_port_id;
- /**< Port ID of the backing device.
- * This device will be used to query representor
- * info and calculate representor IDs.
- * Valid if RTE_ETH_DEV_REPRESENTOR in dev_flags.
- */
-
- pthread_mutex_t flow_ops_mutex; /**< rte_flow ops mutex. */
- uint64_t reserved_64s[4]; /**< Reserved for future fields */
- void *reserved_ptrs[4]; /**< Reserved for future fields */
-} __rte_cache_aligned;
-
-/**
- * @internal
- * The pool of *rte_eth_dev* structures. The size of the pool
- * is configured at compile-time in the <rte_ethdev.c> file.
- */
-extern struct rte_eth_dev rte_eth_devices[];
-
#endif /* _RTE_ETHDEV_CORE_H_ */
diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map
index ca81f5d237..96ac8abb6b 100644
--- a/lib/ethdev/version.map
+++ b/lib/ethdev/version.map
@@ -73,7 +73,6 @@ DPDK_22 {
rte_eth_dev_udp_tunnel_port_add;
rte_eth_dev_udp_tunnel_port_delete;
rte_eth_dev_vlan_filter;
- rte_eth_devices;
rte_eth_find_next;
rte_eth_find_next_of;
rte_eth_find_next_owned_by;
@@ -269,6 +268,7 @@ INTERNAL {
rte_eth_dev_release_port;
rte_eth_dev_internal_reset;
rte_eth_devargs_parse;
+ rte_eth_devices;
rte_eth_dma_zone_free;
rte_eth_dma_zone_reserve;
rte_eth_hairpin_queue_peer_bind;
diff --git a/lib/eventdev/rte_event_eth_rx_adapter.c b/lib/eventdev/rte_event_eth_rx_adapter.c
index 13dfb28401..89c4ca5d40 100644
--- a/lib/eventdev/rte_event_eth_rx_adapter.c
+++ b/lib/eventdev/rte_event_eth_rx_adapter.c
@@ -11,7 +11,7 @@
#include <rte_common.h>
#include <rte_dev.h>
#include <rte_errno.h>
-#include <rte_ethdev.h>
+#include <ethdev_driver.h>
#include <rte_log.h>
#include <rte_malloc.h>
#include <rte_service_component.h>
diff --git a/lib/eventdev/rte_event_eth_tx_adapter.c b/lib/eventdev/rte_event_eth_tx_adapter.c
index 18c0359db7..1c06c8707c 100644
--- a/lib/eventdev/rte_event_eth_tx_adapter.c
+++ b/lib/eventdev/rte_event_eth_tx_adapter.c
@@ -3,7 +3,7 @@
*/
#include <rte_spinlock.h>
#include <rte_service_component.h>
-#include <rte_ethdev.h>
+#include <ethdev_driver.h>
#include "eventdev_pmd.h"
#include "rte_eventdev_trace.h"
diff --git a/lib/eventdev/rte_eventdev.c b/lib/eventdev/rte_eventdev.c
index e347d6dfd5..ebef5f0906 100644
--- a/lib/eventdev/rte_eventdev.c
+++ b/lib/eventdev/rte_eventdev.c
@@ -29,7 +29,7 @@
#include <rte_common.h>
#include <rte_malloc.h>
#include <rte_errno.h>
-#include <rte_ethdev.h>
+#include <ethdev_driver.h>
#include <rte_cryptodev.h>
#include <cryptodev_pmd.h>
#include <rte_telemetry.h>
diff --git a/lib/metrics/rte_metrics_telemetry.c b/lib/metrics/rte_metrics_telemetry.c
index 269f8ef613..5be21b2e86 100644
--- a/lib/metrics/rte_metrics_telemetry.c
+++ b/lib/metrics/rte_metrics_telemetry.c
@@ -2,7 +2,7 @@
* Copyright(c) 2020 Intel Corporation
*/
-#include <rte_ethdev.h>
+#include <ethdev_driver.h>
#include <rte_string_fns.h>
#ifdef RTE_LIB_TELEMETRY
#include <telemetry_internal.h>
--
2.26.3
^ permalink raw reply [relevance 8%]
* [dpdk-dev] [PATCH v6 4/6] ethdev: make fast-path functions to use new flat array
2021-10-13 13:36 4% ` [dpdk-dev] [PATCH v6 0/6] hide eth dev related structures Konstantin Ananyev
2021-10-13 13:37 6% ` [dpdk-dev] [PATCH v6 2/6] ethdev: change input parameters for rx_queue_count Konstantin Ananyev
2021-10-13 13:37 2% ` [dpdk-dev] [PATCH v6 3/6] ethdev: copy fast-path API into separate structure Konstantin Ananyev
@ 2021-10-13 13:37 2% ` Konstantin Ananyev
2021-10-13 13:37 8% ` [dpdk-dev] [PATCH v6 6/6] ethdev: hide eth dev related structures Konstantin Ananyev
2021-10-13 20:16 0% ` [dpdk-dev] [PATCH v6 0/6] " Ferruh Yigit
4 siblings, 0 replies; 200+ results
From: Konstantin Ananyev @ 2021-10-13 13:37 UTC (permalink / raw)
To: dev
Cc: xiaoyun.li, anoobj, jerinj, ndabilpuram, adwivedi,
shepard.siegel, ed.czeck, john.miller, irusskikh, ajit.khaparde,
somnath.kotur, rahul.lakkireddy, hemant.agrawal, sachin.saxena,
haiyue.wang, johndale, hyonkim, qi.z.zhang, xiao.w.wang, humin29,
yisen.zhuang, oulijun, beilei.xing, jingjing.wu, qiming.yang,
matan, viacheslavo, sthemmin, longli, heinrich.kuhn, kirankumark,
andrew.rybchenko, mczekaj, jiawenwu, jianwang, maxime.coquelin,
chenbo.xia, thomas, ferruh.yigit, mdr, jay.jayatheerthan,
Konstantin Ananyev
Rework fast-path ethdev functions to use rte_eth_fp_ops[].
While it is an API/ABI breakage, this change is intended to be
transparent for both users (no changes in user app is required) and
PMD developers (no changes in PMD is required).
One extra thing to note - RX/TX callback invocation will cause extra
function call with these changes. That might cause some insignificant
slowdown for code-path where RX/TX callbacks are heavily involved.
Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
---
lib/ethdev/ethdev_private.c | 31 +++++
lib/ethdev/rte_ethdev.h | 270 +++++++++++++++++++++++++-----------
lib/ethdev/version.map | 3 +
3 files changed, 226 insertions(+), 78 deletions(-)
diff --git a/lib/ethdev/ethdev_private.c b/lib/ethdev/ethdev_private.c
index d810c3a1d4..c905c2df6f 100644
--- a/lib/ethdev/ethdev_private.c
+++ b/lib/ethdev/ethdev_private.c
@@ -226,3 +226,34 @@ eth_dev_fp_ops_setup(struct rte_eth_fp_ops *fpo,
fpo->txq.data = dev->data->tx_queues;
fpo->txq.clbk = (void **)(uintptr_t)dev->pre_tx_burst_cbs;
}
+
+uint16_t
+rte_eth_call_rx_callbacks(uint16_t port_id, uint16_t queue_id,
+ struct rte_mbuf **rx_pkts, uint16_t nb_rx, uint16_t nb_pkts,
+ void *opaque)
+{
+ const struct rte_eth_rxtx_callback *cb = opaque;
+
+ while (cb != NULL) {
+ nb_rx = cb->fn.rx(port_id, queue_id, rx_pkts, nb_rx,
+ nb_pkts, cb->param);
+ cb = cb->next;
+ }
+
+ return nb_rx;
+}
+
+uint16_t
+rte_eth_call_tx_callbacks(uint16_t port_id, uint16_t queue_id,
+ struct rte_mbuf **tx_pkts, uint16_t nb_pkts, void *opaque)
+{
+ const struct rte_eth_rxtx_callback *cb = opaque;
+
+ while (cb != NULL) {
+ nb_pkts = cb->fn.tx(port_id, queue_id, tx_pkts, nb_pkts,
+ cb->param);
+ cb = cb->next;
+ }
+
+ return nb_pkts;
+}
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index 4007bd0e73..f4c92b3b5e 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -4884,6 +4884,33 @@ int rte_eth_rx_metadata_negotiate(uint16_t port_id, uint64_t *features);
#include <rte_ethdev_core.h>
+/**
+ * @internal
+ * Helper routine for rte_eth_rx_burst().
+ * Should be called at exit from PMD's rte_eth_rx_bulk implementation.
+ * Does necessary post-processing - invokes Rx callbacks if any, etc.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param queue_id
+ * The index of the receive queue from which to retrieve input packets.
+ * @param rx_pkts
+ * The address of an array of pointers to *rte_mbuf* structures that
+ * have been retrieved from the device.
+ * @param nb_rx
+ * The number of packets that were retrieved from the device.
+ * @param nb_pkts
+ * The number of elements in @p rx_pkts array.
+ * @param opaque
+ * Opaque pointer of Rx queue callback related data.
+ *
+ * @return
+ * The number of packets effectively supplied to the @p rx_pkts array.
+ */
+uint16_t rte_eth_call_rx_callbacks(uint16_t port_id, uint16_t queue_id,
+ struct rte_mbuf **rx_pkts, uint16_t nb_rx, uint16_t nb_pkts,
+ void *opaque);
+
/**
*
* Retrieve a burst of input packets from a receive queue of an Ethernet
@@ -4975,39 +5002,51 @@ static inline uint16_t
rte_eth_rx_burst(uint16_t port_id, uint16_t queue_id,
struct rte_mbuf **rx_pkts, const uint16_t nb_pkts)
{
- struct rte_eth_dev *dev = &rte_eth_devices[port_id];
uint16_t nb_rx;
+ struct rte_eth_fp_ops *p;
+ void *qd;
+
+#ifdef RTE_ETHDEV_DEBUG_RX
+ if (port_id >= RTE_MAX_ETHPORTS ||
+ queue_id >= RTE_MAX_QUEUES_PER_PORT) {
+ RTE_ETHDEV_LOG(ERR,
+ "Invalid port_id=%u or queue_id=%u\n",
+ port_id, queue_id);
+ return 0;
+ }
+#endif
+
+ /* fetch pointer to queue data */
+ p = &rte_eth_fp_ops[port_id];
+ qd = p->rxq.data[queue_id];
#ifdef RTE_ETHDEV_DEBUG_RX
RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
- RTE_FUNC_PTR_OR_ERR_RET(*dev->rx_pkt_burst, 0);
- if (queue_id >= dev->data->nb_rx_queues) {
- RTE_ETHDEV_LOG(ERR, "Invalid RX queue_id=%u\n", queue_id);
+ if (qd == NULL) {
+ RTE_ETHDEV_LOG(ERR, "Invalid RX queue_id=%u for port_id=%u\n",
+ queue_id, port_id);
return 0;
}
#endif
- nb_rx = (*dev->rx_pkt_burst)(dev->data->rx_queues[queue_id],
- rx_pkts, nb_pkts);
-#ifdef RTE_ETHDEV_RXTX_CALLBACKS
- struct rte_eth_rxtx_callback *cb;
+ nb_rx = p->rx_pkt_burst(qd, rx_pkts, nb_pkts);
- /* __ATOMIC_RELEASE memory order was used when the
- * call back was inserted into the list.
- * Since there is a clear dependency between loading
- * cb and cb->fn/cb->next, __ATOMIC_ACQUIRE memory order is
- * not required.
- */
- cb = __atomic_load_n(&dev->post_rx_burst_cbs[queue_id],
+#ifdef RTE_ETHDEV_RXTX_CALLBACKS
+ {
+ void *cb;
+
+ /* __ATOMIC_RELEASE memory order was used when the
+ * call back was inserted into the list.
+ * Since there is a clear dependency between loading
+ * cb and cb->fn/cb->next, __ATOMIC_ACQUIRE memory order is
+ * not required.
+ */
+ cb = __atomic_load_n((void **)&p->rxq.clbk[queue_id],
__ATOMIC_RELAXED);
-
- if (unlikely(cb != NULL)) {
- do {
- nb_rx = cb->fn.rx(port_id, queue_id, rx_pkts, nb_rx,
- nb_pkts, cb->param);
- cb = cb->next;
- } while (cb != NULL);
+ if (unlikely(cb != NULL))
+ nb_rx = rte_eth_call_rx_callbacks(port_id, queue_id,
+ rx_pkts, nb_rx, nb_pkts, cb);
}
#endif
@@ -5031,16 +5070,27 @@ rte_eth_rx_burst(uint16_t port_id, uint16_t queue_id,
static inline int
rte_eth_rx_queue_count(uint16_t port_id, uint16_t queue_id)
{
- struct rte_eth_dev *dev;
+ struct rte_eth_fp_ops *p;
+ void *qd;
+
+ if (port_id >= RTE_MAX_ETHPORTS ||
+ queue_id >= RTE_MAX_QUEUES_PER_PORT) {
+ RTE_ETHDEV_LOG(ERR,
+ "Invalid port_id=%u or queue_id=%u\n",
+ port_id, queue_id);
+ return -EINVAL;
+ }
+
+ /* fetch pointer to queue data */
+ p = &rte_eth_fp_ops[port_id];
+ qd = p->rxq.data[queue_id];
RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
- dev = &rte_eth_devices[port_id];
- RTE_FUNC_PTR_OR_ERR_RET(*dev->rx_queue_count, -ENOTSUP);
- if (queue_id >= dev->data->nb_rx_queues ||
- dev->data->rx_queues[queue_id] == NULL)
+ RTE_FUNC_PTR_OR_ERR_RET(*p->rx_queue_count, -ENOTSUP);
+ if (qd == NULL)
return -EINVAL;
- return (int)(*dev->rx_queue_count)(dev->data->rx_queues[queue_id]);
+ return (int)(*p->rx_queue_count)(qd);
}
/**@{@name Rx hardware descriptor states
@@ -5088,21 +5138,30 @@ static inline int
rte_eth_rx_descriptor_status(uint16_t port_id, uint16_t queue_id,
uint16_t offset)
{
- struct rte_eth_dev *dev;
- void *rxq;
+ struct rte_eth_fp_ops *p;
+ void *qd;
#ifdef RTE_ETHDEV_DEBUG_RX
- RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ if (port_id >= RTE_MAX_ETHPORTS ||
+ queue_id >= RTE_MAX_QUEUES_PER_PORT) {
+ RTE_ETHDEV_LOG(ERR,
+ "Invalid port_id=%u or queue_id=%u\n",
+ port_id, queue_id);
+ return -EINVAL;
+ }
#endif
- dev = &rte_eth_devices[port_id];
+
+ /* fetch pointer to queue data */
+ p = &rte_eth_fp_ops[port_id];
+ qd = p->rxq.data[queue_id];
+
#ifdef RTE_ETHDEV_DEBUG_RX
- if (queue_id >= dev->data->nb_rx_queues)
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ if (qd == NULL)
return -ENODEV;
#endif
- RTE_FUNC_PTR_OR_ERR_RET(*dev->rx_descriptor_status, -ENOTSUP);
- rxq = dev->data->rx_queues[queue_id];
-
- return (*dev->rx_descriptor_status)(rxq, offset);
+ RTE_FUNC_PTR_OR_ERR_RET(*p->rx_descriptor_status, -ENOTSUP);
+ return (*p->rx_descriptor_status)(qd, offset);
}
/**@{@name Tx hardware descriptor states
@@ -5149,23 +5208,54 @@ rte_eth_rx_descriptor_status(uint16_t port_id, uint16_t queue_id,
static inline int rte_eth_tx_descriptor_status(uint16_t port_id,
uint16_t queue_id, uint16_t offset)
{
- struct rte_eth_dev *dev;
- void *txq;
+ struct rte_eth_fp_ops *p;
+ void *qd;
#ifdef RTE_ETHDEV_DEBUG_TX
- RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ if (port_id >= RTE_MAX_ETHPORTS ||
+ queue_id >= RTE_MAX_QUEUES_PER_PORT) {
+ RTE_ETHDEV_LOG(ERR,
+ "Invalid port_id=%u or queue_id=%u\n",
+ port_id, queue_id);
+ return -EINVAL;
+ }
#endif
- dev = &rte_eth_devices[port_id];
+
+ /* fetch pointer to queue data */
+ p = &rte_eth_fp_ops[port_id];
+ qd = p->txq.data[queue_id];
+
#ifdef RTE_ETHDEV_DEBUG_TX
- if (queue_id >= dev->data->nb_tx_queues)
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ if (qd == NULL)
return -ENODEV;
#endif
- RTE_FUNC_PTR_OR_ERR_RET(*dev->tx_descriptor_status, -ENOTSUP);
- txq = dev->data->tx_queues[queue_id];
-
- return (*dev->tx_descriptor_status)(txq, offset);
+ RTE_FUNC_PTR_OR_ERR_RET(*p->tx_descriptor_status, -ENOTSUP);
+ return (*p->tx_descriptor_status)(qd, offset);
}
+/**
+ * @internal
+ * Helper routine for rte_eth_tx_burst().
+ * Should be called before entry PMD's rte_eth_tx_bulk implementation.
+ * Does necessary pre-processing - invokes Tx callbacks if any, etc.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param queue_id
+ * The index of the transmit queue through which output packets must be
+ * sent.
+ * @param tx_pkts
+ * The address of an array of *nb_pkts* pointers to *rte_mbuf* structures
+ * which contain the output packets.
+ * @param nb_pkts
+ * The maximum number of packets to transmit.
+ * @return
+ * The number of output packets to transmit.
+ */
+uint16_t rte_eth_call_tx_callbacks(uint16_t port_id, uint16_t queue_id,
+ struct rte_mbuf **tx_pkts, uint16_t nb_pkts, void *opaque);
+
/**
* Send a burst of output packets on a transmit queue of an Ethernet device.
*
@@ -5236,42 +5326,55 @@ static inline uint16_t
rte_eth_tx_burst(uint16_t port_id, uint16_t queue_id,
struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
{
- struct rte_eth_dev *dev = &rte_eth_devices[port_id];
+ struct rte_eth_fp_ops *p;
+ void *qd;
+
+#ifdef RTE_ETHDEV_DEBUG_TX
+ if (port_id >= RTE_MAX_ETHPORTS ||
+ queue_id >= RTE_MAX_QUEUES_PER_PORT) {
+ RTE_ETHDEV_LOG(ERR,
+ "Invalid port_id=%u or queue_id=%u\n",
+ port_id, queue_id);
+ return 0;
+ }
+#endif
+
+ /* fetch pointer to queue data */
+ p = &rte_eth_fp_ops[port_id];
+ qd = p->txq.data[queue_id];
#ifdef RTE_ETHDEV_DEBUG_TX
RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
- RTE_FUNC_PTR_OR_ERR_RET(*dev->tx_pkt_burst, 0);
- if (queue_id >= dev->data->nb_tx_queues) {
- RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u\n", queue_id);
+ if (qd == NULL) {
+ RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u for port_id=%u\n",
+ queue_id, port_id);
return 0;
}
#endif
#ifdef RTE_ETHDEV_RXTX_CALLBACKS
- struct rte_eth_rxtx_callback *cb;
-
- /* __ATOMIC_RELEASE memory order was used when the
- * call back was inserted into the list.
- * Since there is a clear dependency between loading
- * cb and cb->fn/cb->next, __ATOMIC_ACQUIRE memory order is
- * not required.
- */
- cb = __atomic_load_n(&dev->pre_tx_burst_cbs[queue_id],
+ {
+ void *cb;
+
+ /* __ATOMIC_RELEASE memory order was used when the
+ * call back was inserted into the list.
+ * Since there is a clear dependency between loading
+ * cb and cb->fn/cb->next, __ATOMIC_ACQUIRE memory order is
+ * not required.
+ */
+ cb = __atomic_load_n((void **)&p->txq.clbk[queue_id],
__ATOMIC_RELAXED);
-
- if (unlikely(cb != NULL)) {
- do {
- nb_pkts = cb->fn.tx(port_id, queue_id, tx_pkts, nb_pkts,
- cb->param);
- cb = cb->next;
- } while (cb != NULL);
+ if (unlikely(cb != NULL))
+ nb_pkts = rte_eth_call_tx_callbacks(port_id, queue_id,
+ tx_pkts, nb_pkts, cb);
}
#endif
- rte_ethdev_trace_tx_burst(port_id, queue_id, (void **)tx_pkts,
- nb_pkts);
- return (*dev->tx_pkt_burst)(dev->data->tx_queues[queue_id], tx_pkts, nb_pkts);
+ nb_pkts = p->tx_pkt_burst(qd, tx_pkts, nb_pkts);
+
+ rte_ethdev_trace_tx_burst(port_id, queue_id, (void **)tx_pkts, nb_pkts);
+ return nb_pkts;
}
/**
@@ -5334,31 +5437,42 @@ static inline uint16_t
rte_eth_tx_prepare(uint16_t port_id, uint16_t queue_id,
struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
{
- struct rte_eth_dev *dev;
+ struct rte_eth_fp_ops *p;
+ void *qd;
#ifdef RTE_ETHDEV_DEBUG_TX
- if (!rte_eth_dev_is_valid_port(port_id)) {
- RTE_ETHDEV_LOG(ERR, "Invalid TX port_id=%u\n", port_id);
+ if (port_id >= RTE_MAX_ETHPORTS ||
+ queue_id >= RTE_MAX_QUEUES_PER_PORT) {
+ RTE_ETHDEV_LOG(ERR,
+ "Invalid port_id=%u or queue_id=%u\n",
+ port_id, queue_id);
rte_errno = ENODEV;
return 0;
}
#endif
- dev = &rte_eth_devices[port_id];
+ /* fetch pointer to queue data */
+ p = &rte_eth_fp_ops[port_id];
+ qd = p->txq.data[queue_id];
#ifdef RTE_ETHDEV_DEBUG_TX
- if (queue_id >= dev->data->nb_tx_queues) {
- RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u\n", queue_id);
+ if (!rte_eth_dev_is_valid_port(port_id)) {
+ RTE_ETHDEV_LOG(ERR, "Invalid TX port_id=%u\n", port_id);
+ rte_errno = ENODEV;
+ return 0;
+ }
+ if (qd == NULL) {
+ RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u for port_id=%u\n",
+ queue_id, port_id);
rte_errno = EINVAL;
return 0;
}
#endif
- if (!dev->tx_pkt_prepare)
+ if (!p->tx_pkt_prepare)
return nb_pkts;
- return (*dev->tx_pkt_prepare)(dev->data->tx_queues[queue_id],
- tx_pkts, nb_pkts);
+ return p->tx_pkt_prepare(qd, tx_pkts, nb_pkts);
}
#else
diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map
index 29fb71f1af..61011b110a 100644
--- a/lib/ethdev/version.map
+++ b/lib/ethdev/version.map
@@ -7,6 +7,8 @@ DPDK_22 {
rte_eth_allmulticast_disable;
rte_eth_allmulticast_enable;
rte_eth_allmulticast_get;
+ rte_eth_call_rx_callbacks;
+ rte_eth_call_tx_callbacks;
rte_eth_dev_adjust_nb_rx_tx_desc;
rte_eth_dev_callback_register;
rte_eth_dev_callback_unregister;
@@ -76,6 +78,7 @@ DPDK_22 {
rte_eth_find_next_of;
rte_eth_find_next_owned_by;
rte_eth_find_next_sibling;
+ rte_eth_fp_ops;
rte_eth_iterator_cleanup;
rte_eth_iterator_init;
rte_eth_iterator_next;
--
2.26.3
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v6 3/6] ethdev: copy fast-path API into separate structure
2021-10-13 13:36 4% ` [dpdk-dev] [PATCH v6 0/6] hide eth dev related structures Konstantin Ananyev
2021-10-13 13:37 6% ` [dpdk-dev] [PATCH v6 2/6] ethdev: change input parameters for rx_queue_count Konstantin Ananyev
@ 2021-10-13 13:37 2% ` Konstantin Ananyev
2021-10-13 14:25 0% ` Andrew Rybchenko
2021-10-13 13:37 2% ` [dpdk-dev] [PATCH v6 4/6] ethdev: make fast-path functions to use new flat array Konstantin Ananyev
` (2 subsequent siblings)
4 siblings, 1 reply; 200+ results
From: Konstantin Ananyev @ 2021-10-13 13:37 UTC (permalink / raw)
To: dev
Cc: xiaoyun.li, anoobj, jerinj, ndabilpuram, adwivedi,
shepard.siegel, ed.czeck, john.miller, irusskikh, ajit.khaparde,
somnath.kotur, rahul.lakkireddy, hemant.agrawal, sachin.saxena,
haiyue.wang, johndale, hyonkim, qi.z.zhang, xiao.w.wang, humin29,
yisen.zhuang, oulijun, beilei.xing, jingjing.wu, qiming.yang,
matan, viacheslavo, sthemmin, longli, heinrich.kuhn, kirankumark,
andrew.rybchenko, mczekaj, jiawenwu, jianwang, maxime.coquelin,
chenbo.xia, thomas, ferruh.yigit, mdr, jay.jayatheerthan,
Konstantin Ananyev
Copy public function pointers (rx_pkt_burst(), etc.) and related
pointers to internal data from rte_eth_dev structure into a
separate flat array. That array will remain in a public header.
The intention here is to make rte_eth_dev and related structures internal.
That should allow future possible changes to core eth_dev structures
to be transparent to the user and help to avoid ABI/API breakages.
The plan is to keep minimal part of data from rte_eth_dev public,
so we still can use inline functions for fast-path calls
(like rte_eth_rx_burst(), etc.) to avoid/minimize slowdown.
The whole idea beyond this new schema:
1. PMDs keep to setup fast-path function pointers and related data
inside rte_eth_dev struct in the same way they did it before.
2. Inside rte_eth_dev_start() and inside rte_eth_dev_probing_finish()
(for secondary process) we call eth_dev_fp_ops_setup, which
copies these function and data pointers into rte_eth_fp_ops[port_id].
3. Inside rte_eth_dev_stop() and inside rte_eth_dev_release_port()
we call eth_dev_fp_ops_reset(), which resets rte_eth_fp_ops[port_id]
into some dummy values.
4. fast-path ethdev API (rte_eth_rx_burst(), etc.) will use that new
flat array to call PMD specific functions.
That approach should allow us to make rte_eth_devices[] private
without introducing regression and help to avoid changes in drivers code.
Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
---
lib/ethdev/ethdev_private.c | 52 +++++++++++++++++++++++++++++++
lib/ethdev/ethdev_private.h | 7 +++++
lib/ethdev/rte_ethdev.c | 27 +++++++++++++++++
lib/ethdev/rte_ethdev_core.h | 59 ++++++++++++++++++++++++++++++++++++
4 files changed, 145 insertions(+)
diff --git a/lib/ethdev/ethdev_private.c b/lib/ethdev/ethdev_private.c
index 012cf73ca2..d810c3a1d4 100644
--- a/lib/ethdev/ethdev_private.c
+++ b/lib/ethdev/ethdev_private.c
@@ -174,3 +174,55 @@ rte_eth_devargs_parse_representor_ports(char *str, void *data)
RTE_LOG(ERR, EAL, "wrong representor format: %s\n", str);
return str == NULL ? -1 : 0;
}
+
+static uint16_t
+dummy_eth_rx_burst(__rte_unused void *rxq,
+ __rte_unused struct rte_mbuf **rx_pkts,
+ __rte_unused uint16_t nb_pkts)
+{
+ RTE_ETHDEV_LOG(ERR, "rx_pkt_burst for not ready port\n");
+ rte_errno = ENOTSUP;
+ return 0;
+}
+
+static uint16_t
+dummy_eth_tx_burst(__rte_unused void *txq,
+ __rte_unused struct rte_mbuf **tx_pkts,
+ __rte_unused uint16_t nb_pkts)
+{
+ RTE_ETHDEV_LOG(ERR, "tx_pkt_burst for not ready port\n");
+ rte_errno = ENOTSUP;
+ return 0;
+}
+
+void
+eth_dev_fp_ops_reset(struct rte_eth_fp_ops *fpo)
+{
+ static void *dummy_data[RTE_MAX_QUEUES_PER_PORT];
+ static const struct rte_eth_fp_ops dummy_ops = {
+ .rx_pkt_burst = dummy_eth_rx_burst,
+ .tx_pkt_burst = dummy_eth_tx_burst,
+ .rxq = {.data = dummy_data, .clbk = dummy_data,},
+ .txq = {.data = dummy_data, .clbk = dummy_data,},
+ };
+
+ *fpo = dummy_ops;
+}
+
+void
+eth_dev_fp_ops_setup(struct rte_eth_fp_ops *fpo,
+ const struct rte_eth_dev *dev)
+{
+ fpo->rx_pkt_burst = dev->rx_pkt_burst;
+ fpo->tx_pkt_burst = dev->tx_pkt_burst;
+ fpo->tx_pkt_prepare = dev->tx_pkt_prepare;
+ fpo->rx_queue_count = dev->rx_queue_count;
+ fpo->rx_descriptor_status = dev->rx_descriptor_status;
+ fpo->tx_descriptor_status = dev->tx_descriptor_status;
+
+ fpo->rxq.data = dev->data->rx_queues;
+ fpo->rxq.clbk = (void **)(uintptr_t)dev->post_rx_burst_cbs;
+
+ fpo->txq.data = dev->data->tx_queues;
+ fpo->txq.clbk = (void **)(uintptr_t)dev->pre_tx_burst_cbs;
+}
diff --git a/lib/ethdev/ethdev_private.h b/lib/ethdev/ethdev_private.h
index 3724429577..5721be7bdc 100644
--- a/lib/ethdev/ethdev_private.h
+++ b/lib/ethdev/ethdev_private.h
@@ -26,4 +26,11 @@ eth_find_device(const struct rte_eth_dev *_start, rte_eth_cmp_t cmp,
/* Parse devargs value for representor parameter. */
int rte_eth_devargs_parse_representor_ports(char *str, void *data);
+/* reset eth fast-path API to dummy values */
+void eth_dev_fp_ops_reset(struct rte_eth_fp_ops *fpo);
+
+/* setup eth fast-path API to ethdev values */
+void eth_dev_fp_ops_setup(struct rte_eth_fp_ops *fpo,
+ const struct rte_eth_dev *dev);
+
#endif /* _ETH_PRIVATE_H_ */
diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index e446f3b3f8..178f5b88b7 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -44,6 +44,9 @@
static const char *MZ_RTE_ETH_DEV_DATA = "rte_eth_dev_data";
struct rte_eth_dev rte_eth_devices[RTE_MAX_ETHPORTS];
+/* public fast-path API */
+struct rte_eth_fp_ops rte_eth_fp_ops[RTE_MAX_ETHPORTS];
+
/* spinlock for eth device callbacks */
static rte_spinlock_t eth_dev_cb_lock = RTE_SPINLOCK_INITIALIZER;
@@ -579,6 +582,8 @@ rte_eth_dev_release_port(struct rte_eth_dev *eth_dev)
rte_eth_dev_callback_process(eth_dev,
RTE_ETH_EVENT_DESTROY, NULL);
+ eth_dev_fp_ops_reset(rte_eth_fp_ops + eth_dev->data->port_id);
+
rte_spinlock_lock(ð_dev_shared_data->ownership_lock);
eth_dev->state = RTE_ETH_DEV_UNUSED;
@@ -1792,6 +1797,9 @@ rte_eth_dev_start(uint16_t port_id)
(*dev->dev_ops->link_update)(dev, 0);
}
+ /* expose selection of PMD fast-path functions */
+ eth_dev_fp_ops_setup(rte_eth_fp_ops + port_id, dev);
+
rte_ethdev_trace_start(port_id);
return 0;
}
@@ -1814,6 +1822,9 @@ rte_eth_dev_stop(uint16_t port_id)
return 0;
}
+ /* point fast-path functions to dummy ones */
+ eth_dev_fp_ops_reset(rte_eth_fp_ops + port_id);
+
dev->data->dev_started = 0;
ret = (*dev->dev_ops->dev_stop)(dev);
rte_ethdev_trace_stop(port_id, ret);
@@ -4477,6 +4488,14 @@ int rte_eth_set_queue_rate_limit(uint16_t port_id, uint16_t queue_idx,
queue_idx, tx_rate));
}
+RTE_INIT(eth_dev_init_fp_ops)
+{
+ uint32_t i;
+
+ for (i = 0; i != RTE_DIM(rte_eth_fp_ops); i++)
+ eth_dev_fp_ops_reset(rte_eth_fp_ops + i);
+}
+
RTE_INIT(eth_dev_init_cb_lists)
{
uint16_t i;
@@ -4645,6 +4664,14 @@ rte_eth_dev_probing_finish(struct rte_eth_dev *dev)
if (dev == NULL)
return;
+ /*
+ * for secondary process, at that point we expect device
+ * to be already 'usable', so shared data and all function pointers
+ * for fast-path devops have to be setup properly inside rte_eth_dev.
+ */
+ if (rte_eal_process_type() == RTE_PROC_SECONDARY)
+ eth_dev_fp_ops_setup(rte_eth_fp_ops + dev->data->port_id, dev);
+
rte_eth_dev_callback_process(dev, RTE_ETH_EVENT_NEW, NULL);
dev->state = RTE_ETH_DEV_ATTACHED;
diff --git a/lib/ethdev/rte_ethdev_core.h b/lib/ethdev/rte_ethdev_core.h
index af824ef890..df7168ca4b 100644
--- a/lib/ethdev/rte_ethdev_core.h
+++ b/lib/ethdev/rte_ethdev_core.h
@@ -50,6 +50,65 @@ typedef int (*eth_rx_descriptor_status_t)(void *rxq, uint16_t offset);
typedef int (*eth_tx_descriptor_status_t)(void *txq, uint16_t offset);
/**< @internal Check the status of a Tx descriptor */
+/**
+ * @internal
+ * Structure used to hold opaque pointers to internal ethdev Rx/Tx
+ * queues data.
+ * The main purpose to expose these pointers at all - allow compiler
+ * to fetch this data for fast-path ethdev inline functions in advance.
+ */
+struct rte_ethdev_qdata {
+ /** points to array of internal queue data pointers */
+ void **data;
+ /** points to array of queue callback data pointers */
+ void **clbk;
+};
+
+/**
+ * @internal
+ * fast-path ethdev functions and related data are hold in a flat array.
+ * One entry per ethdev.
+ * On 64-bit systems contents of this structure occupy exactly two 64B lines.
+ * On 32-bit systems contents of this structure fits into one 64B line.
+ */
+struct rte_eth_fp_ops {
+
+ /**@{*/
+ /**
+ * Rx fast-path functions and related data.
+ * 64-bit systems: occupies first 64B line
+ */
+ /** PMD receive function. */
+ eth_rx_burst_t rx_pkt_burst;
+ /** Get the number of used RX descriptors. */
+ eth_rx_queue_count_t rx_queue_count;
+ /** Check the status of a Rx descriptor. */
+ eth_rx_descriptor_status_t rx_descriptor_status;
+ /** Rx queues data. */
+ struct rte_ethdev_qdata rxq;
+ uintptr_t reserved1[3];
+ /**@}*/
+
+ /**@{*/
+ /**
+ * Tx fast-path functions and related data.
+ * 64-bit systems: occupies second 64B line
+ */
+ /** PMD transmit function. */
+ eth_tx_burst_t tx_pkt_burst;
+ /** PMD transmit prepare function. */
+ eth_tx_prep_t tx_pkt_prepare;
+ /** Check the status of a Tx descriptor. */
+ eth_tx_descriptor_status_t tx_descriptor_status;
+ /** Tx queues data. */
+ struct rte_ethdev_qdata txq;
+ uintptr_t reserved2[3];
+ /**@}*/
+
+} __rte_cache_aligned;
+
+extern struct rte_eth_fp_ops rte_eth_fp_ops[RTE_MAX_ETHPORTS];
+
/**
* @internal
--
2.26.3
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v6 2/6] ethdev: change input parameters for rx_queue_count
2021-10-13 13:36 4% ` [dpdk-dev] [PATCH v6 0/6] hide eth dev related structures Konstantin Ananyev
@ 2021-10-13 13:37 6% ` Konstantin Ananyev
2021-10-13 13:37 2% ` [dpdk-dev] [PATCH v6 3/6] ethdev: copy fast-path API into separate structure Konstantin Ananyev
` (3 subsequent siblings)
4 siblings, 0 replies; 200+ results
From: Konstantin Ananyev @ 2021-10-13 13:37 UTC (permalink / raw)
To: dev
Cc: xiaoyun.li, anoobj, jerinj, ndabilpuram, adwivedi,
shepard.siegel, ed.czeck, john.miller, irusskikh, ajit.khaparde,
somnath.kotur, rahul.lakkireddy, hemant.agrawal, sachin.saxena,
haiyue.wang, johndale, hyonkim, qi.z.zhang, xiao.w.wang, humin29,
yisen.zhuang, oulijun, beilei.xing, jingjing.wu, qiming.yang,
matan, viacheslavo, sthemmin, longli, heinrich.kuhn, kirankumark,
andrew.rybchenko, mczekaj, jiawenwu, jianwang, maxime.coquelin,
chenbo.xia, thomas, ferruh.yigit, mdr, jay.jayatheerthan,
Konstantin Ananyev
Currently majority of fast-path ethdev ops take pointers to internal
queue data structures as an input parameter.
While eth_rx_queue_count() takes a pointer to rte_eth_dev and queue
index.
For future work to hide rte_eth_devices[] and friends it would be
plausible to unify parameters list of all fast-path ethdev ops.
This patch changes eth_rx_queue_count() to accept pointer to internal
queue data as input parameter.
While this change is transparent to user, it still counts as an ABI change,
as eth_rx_queue_count_t is used by ethdev public inline function
rte_eth_rx_queue_count().
Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
Reviewed-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Acked-by: Hyong Youb Kim <hyonkim@cisco.com>
---
doc/guides/rel_notes/release_21_11.rst | 6 ++++++
drivers/net/ark/ark_ethdev_rx.c | 4 ++--
drivers/net/ark/ark_ethdev_rx.h | 3 +--
drivers/net/atlantic/atl_ethdev.h | 2 +-
drivers/net/atlantic/atl_rxtx.c | 9 ++-------
drivers/net/bnxt/bnxt_ethdev.c | 8 +++++---
drivers/net/dpaa/dpaa_ethdev.c | 9 ++++-----
drivers/net/dpaa2/dpaa2_ethdev.c | 9 ++++-----
drivers/net/e1000/e1000_ethdev.h | 6 ++----
drivers/net/e1000/em_rxtx.c | 4 ++--
drivers/net/e1000/igb_rxtx.c | 4 ++--
drivers/net/enic/enic_ethdev.c | 12 ++++++------
drivers/net/fm10k/fm10k.h | 2 +-
drivers/net/fm10k/fm10k_rxtx.c | 4 ++--
drivers/net/hns3/hns3_rxtx.c | 7 +++++--
drivers/net/hns3/hns3_rxtx.h | 2 +-
drivers/net/i40e/i40e_rxtx.c | 4 ++--
drivers/net/i40e/i40e_rxtx.h | 3 +--
drivers/net/iavf/iavf_rxtx.c | 4 ++--
drivers/net/iavf/iavf_rxtx.h | 2 +-
drivers/net/ice/ice_rxtx.c | 4 ++--
drivers/net/ice/ice_rxtx.h | 2 +-
drivers/net/igc/igc_txrx.c | 5 ++---
drivers/net/igc/igc_txrx.h | 3 +--
drivers/net/ixgbe/ixgbe_ethdev.h | 3 +--
drivers/net/ixgbe/ixgbe_rxtx.c | 4 ++--
drivers/net/mlx5/mlx5_rx.c | 26 ++++++++++++-------------
drivers/net/mlx5/mlx5_rx.h | 2 +-
drivers/net/netvsc/hn_rxtx.c | 4 ++--
drivers/net/netvsc/hn_var.h | 2 +-
drivers/net/nfp/nfp_rxtx.c | 4 ++--
drivers/net/nfp/nfp_rxtx.h | 3 +--
drivers/net/octeontx2/otx2_ethdev.h | 2 +-
drivers/net/octeontx2/otx2_ethdev_ops.c | 8 ++++----
drivers/net/sfc/sfc_ethdev.c | 12 ++++++------
drivers/net/thunderx/nicvf_ethdev.c | 3 +--
drivers/net/thunderx/nicvf_rxtx.c | 4 ++--
drivers/net/thunderx/nicvf_rxtx.h | 2 +-
drivers/net/txgbe/txgbe_ethdev.h | 3 +--
drivers/net/txgbe/txgbe_rxtx.c | 4 ++--
drivers/net/vhost/rte_eth_vhost.c | 4 ++--
lib/ethdev/rte_ethdev.h | 2 +-
lib/ethdev/rte_ethdev_core.h | 3 +--
43 files changed, 103 insertions(+), 110 deletions(-)
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index d5c762df62..bb884f5f32 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -299,6 +299,12 @@ ABI Changes
* bbdev: Added capability related to more comprehensive CRC options,
shifting values of the ``enum rte_bbdev_op_ldpcdec_flag_bitmasks``.
+* ethdev: Input parameters for ``eth_rx_queue_count_t`` was changed.
+ Instead of pointer to ``rte_eth_dev`` and queue index, now it accepts pointer
+ to internal queue data as input parameter. While this change is transparent
+ to user, it still counts as an ABI change, as ``eth_rx_queue_count_t``
+ is used by public inline function ``rte_eth_rx_queue_count``.
+
Known Issues
------------
diff --git a/drivers/net/ark/ark_ethdev_rx.c b/drivers/net/ark/ark_ethdev_rx.c
index d255f0177b..98658ce621 100644
--- a/drivers/net/ark/ark_ethdev_rx.c
+++ b/drivers/net/ark/ark_ethdev_rx.c
@@ -388,11 +388,11 @@ eth_ark_rx_queue_drain(struct ark_rx_queue *queue)
}
uint32_t
-eth_ark_dev_rx_queue_count(struct rte_eth_dev *dev, uint16_t queue_id)
+eth_ark_dev_rx_queue_count(void *rx_queue)
{
struct ark_rx_queue *queue;
- queue = dev->data->rx_queues[queue_id];
+ queue = rx_queue;
return (queue->prod_index - queue->cons_index); /* mod arith */
}
diff --git a/drivers/net/ark/ark_ethdev_rx.h b/drivers/net/ark/ark_ethdev_rx.h
index c8dc340a8a..859fcf1e6f 100644
--- a/drivers/net/ark/ark_ethdev_rx.h
+++ b/drivers/net/ark/ark_ethdev_rx.h
@@ -17,8 +17,7 @@ int eth_ark_dev_rx_queue_setup(struct rte_eth_dev *dev,
unsigned int socket_id,
const struct rte_eth_rxconf *rx_conf,
struct rte_mempool *mp);
-uint32_t eth_ark_dev_rx_queue_count(struct rte_eth_dev *dev,
- uint16_t rx_queue_id);
+uint32_t eth_ark_dev_rx_queue_count(void *rx_queue);
int eth_ark_rx_stop_queue(struct rte_eth_dev *dev, uint16_t queue_id);
int eth_ark_rx_start_queue(struct rte_eth_dev *dev, uint16_t queue_id);
uint16_t eth_ark_recv_pkts_noop(void *rx_queue, struct rte_mbuf **rx_pkts,
diff --git a/drivers/net/atlantic/atl_ethdev.h b/drivers/net/atlantic/atl_ethdev.h
index a2d1d4397c..fbc9917ed3 100644
--- a/drivers/net/atlantic/atl_ethdev.h
+++ b/drivers/net/atlantic/atl_ethdev.h
@@ -66,7 +66,7 @@ int atl_tx_queue_setup(struct rte_eth_dev *dev, uint16_t tx_queue_id,
uint16_t nb_tx_desc, unsigned int socket_id,
const struct rte_eth_txconf *tx_conf);
-uint32_t atl_rx_queue_count(struct rte_eth_dev *dev, uint16_t rx_queue_id);
+uint32_t atl_rx_queue_count(void *rx_queue);
int atl_dev_rx_descriptor_status(void *rx_queue, uint16_t offset);
int atl_dev_tx_descriptor_status(void *tx_queue, uint16_t offset);
diff --git a/drivers/net/atlantic/atl_rxtx.c b/drivers/net/atlantic/atl_rxtx.c
index fca682d8b0..0d3460383a 100644
--- a/drivers/net/atlantic/atl_rxtx.c
+++ b/drivers/net/atlantic/atl_rxtx.c
@@ -689,18 +689,13 @@ atl_txq_info_get(struct rte_eth_dev *dev, uint16_t queue_id,
/* Return Rx queue avail count */
uint32_t
-atl_rx_queue_count(struct rte_eth_dev *dev, uint16_t rx_queue_id)
+atl_rx_queue_count(void *rx_queue)
{
struct atl_rx_queue *rxq;
PMD_INIT_FUNC_TRACE();
- if (rx_queue_id >= dev->data->nb_rx_queues) {
- PMD_DRV_LOG(ERR, "Invalid RX queue id=%d", rx_queue_id);
- return 0;
- }
-
- rxq = dev->data->rx_queues[rx_queue_id];
+ rxq = rx_queue;
if (rxq == NULL)
return 0;
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index a98f93ab29..ebda74d02f 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -3154,20 +3154,22 @@ bnxt_dev_led_off_op(struct rte_eth_dev *dev)
}
static uint32_t
-bnxt_rx_queue_count_op(struct rte_eth_dev *dev, uint16_t rx_queue_id)
+bnxt_rx_queue_count_op(void *rx_queue)
{
- struct bnxt *bp = (struct bnxt *)dev->data->dev_private;
+ struct bnxt *bp;
struct bnxt_cp_ring_info *cpr;
uint32_t desc = 0, raw_cons, cp_ring_size;
struct bnxt_rx_queue *rxq;
struct rx_pkt_cmpl *rxcmp;
int rc;
+ rxq = rx_queue;
+ bp = rxq->bp;
+
rc = is_bnxt_in_error(bp);
if (rc)
return rc;
- rxq = dev->data->rx_queues[rx_queue_id];
cpr = rxq->cp_ring;
raw_cons = cpr->cp_raw_cons;
cp_ring_size = cpr->cp_ring_struct->ring_size;
diff --git a/drivers/net/dpaa/dpaa_ethdev.c b/drivers/net/dpaa/dpaa_ethdev.c
index 59f4a93b3e..c087ce6341 100644
--- a/drivers/net/dpaa/dpaa_ethdev.c
+++ b/drivers/net/dpaa/dpaa_ethdev.c
@@ -1267,17 +1267,16 @@ int dpaa_eth_tx_queue_setup(struct rte_eth_dev *dev, uint16_t queue_idx,
}
static uint32_t
-dpaa_dev_rx_queue_count(struct rte_eth_dev *dev, uint16_t rx_queue_id)
+dpaa_dev_rx_queue_count(void *rx_queue)
{
- struct dpaa_if *dpaa_intf = dev->data->dev_private;
- struct qman_fq *rxq = &dpaa_intf->rx_queues[rx_queue_id];
+ struct qman_fq *rxq = rx_queue;
u32 frm_cnt = 0;
PMD_INIT_FUNC_TRACE();
if (qman_query_fq_frm_cnt(rxq, &frm_cnt) == 0) {
- DPAA_PMD_DEBUG("RX frame count for q(%d) is %u",
- rx_queue_id, frm_cnt);
+ DPAA_PMD_DEBUG("RX frame count for q(%p) is %u",
+ rx_queue, frm_cnt);
}
return frm_cnt;
}
diff --git a/drivers/net/dpaa2/dpaa2_ethdev.c b/drivers/net/dpaa2/dpaa2_ethdev.c
index ff8ae89922..f2519f0fad 100644
--- a/drivers/net/dpaa2/dpaa2_ethdev.c
+++ b/drivers/net/dpaa2/dpaa2_ethdev.c
@@ -1007,10 +1007,9 @@ dpaa2_dev_rx_queue_release(struct rte_eth_dev *dev, uint16_t rx_queue_id)
}
static uint32_t
-dpaa2_dev_rx_queue_count(struct rte_eth_dev *dev, uint16_t rx_queue_id)
+dpaa2_dev_rx_queue_count(void *rx_queue)
{
int32_t ret;
- struct dpaa2_dev_priv *priv = dev->data->dev_private;
struct dpaa2_queue *dpaa2_q;
struct qbman_swp *swp;
struct qbman_fq_query_np_rslt state;
@@ -1027,12 +1026,12 @@ dpaa2_dev_rx_queue_count(struct rte_eth_dev *dev, uint16_t rx_queue_id)
}
swp = DPAA2_PER_LCORE_PORTAL;
- dpaa2_q = (struct dpaa2_queue *)priv->rx_vq[rx_queue_id];
+ dpaa2_q = rx_queue;
if (qbman_fq_query_state(swp, dpaa2_q->fqid, &state) == 0) {
frame_cnt = qbman_fq_state_frame_count(&state);
- DPAA2_PMD_DP_DEBUG("RX frame count for q(%d) is %u",
- rx_queue_id, frame_cnt);
+ DPAA2_PMD_DP_DEBUG("RX frame count for q(%p) is %u",
+ rx_queue, frame_cnt);
}
return frame_cnt;
}
diff --git a/drivers/net/e1000/e1000_ethdev.h b/drivers/net/e1000/e1000_ethdev.h
index dafd586b12..050852be79 100644
--- a/drivers/net/e1000/e1000_ethdev.h
+++ b/drivers/net/e1000/e1000_ethdev.h
@@ -399,8 +399,7 @@ int eth_igb_rx_queue_setup(struct rte_eth_dev *dev, uint16_t rx_queue_id,
const struct rte_eth_rxconf *rx_conf,
struct rte_mempool *mb_pool);
-uint32_t eth_igb_rx_queue_count(struct rte_eth_dev *dev,
- uint16_t rx_queue_id);
+uint32_t eth_igb_rx_queue_count(void *rx_queue);
int eth_igb_rx_descriptor_status(void *rx_queue, uint16_t offset);
int eth_igb_tx_descriptor_status(void *tx_queue, uint16_t offset);
@@ -474,8 +473,7 @@ int eth_em_rx_queue_setup(struct rte_eth_dev *dev, uint16_t rx_queue_id,
const struct rte_eth_rxconf *rx_conf,
struct rte_mempool *mb_pool);
-uint32_t eth_em_rx_queue_count(struct rte_eth_dev *dev,
- uint16_t rx_queue_id);
+uint32_t eth_em_rx_queue_count(void *rx_queue);
int eth_em_rx_descriptor_status(void *rx_queue, uint16_t offset);
int eth_em_tx_descriptor_status(void *tx_queue, uint16_t offset);
diff --git a/drivers/net/e1000/em_rxtx.c b/drivers/net/e1000/em_rxtx.c
index 9994703cc2..506b4159a2 100644
--- a/drivers/net/e1000/em_rxtx.c
+++ b/drivers/net/e1000/em_rxtx.c
@@ -1495,14 +1495,14 @@ eth_em_rx_queue_setup(struct rte_eth_dev *dev,
}
uint32_t
-eth_em_rx_queue_count(struct rte_eth_dev *dev, uint16_t rx_queue_id)
+eth_em_rx_queue_count(void *rx_queue)
{
#define EM_RXQ_SCAN_INTERVAL 4
volatile struct e1000_rx_desc *rxdp;
struct em_rx_queue *rxq;
uint32_t desc = 0;
- rxq = dev->data->rx_queues[rx_queue_id];
+ rxq = rx_queue;
rxdp = &(rxq->rx_ring[rxq->rx_tail]);
while ((desc < rxq->nb_rx_desc) &&
diff --git a/drivers/net/e1000/igb_rxtx.c b/drivers/net/e1000/igb_rxtx.c
index 7b2a6b0490..e04c2b41ab 100644
--- a/drivers/net/e1000/igb_rxtx.c
+++ b/drivers/net/e1000/igb_rxtx.c
@@ -1776,14 +1776,14 @@ eth_igb_rx_queue_setup(struct rte_eth_dev *dev,
}
uint32_t
-eth_igb_rx_queue_count(struct rte_eth_dev *dev, uint16_t rx_queue_id)
+eth_igb_rx_queue_count(void *rx_queue)
{
#define IGB_RXQ_SCAN_INTERVAL 4
volatile union e1000_adv_rx_desc *rxdp;
struct igb_rx_queue *rxq;
uint32_t desc = 0;
- rxq = dev->data->rx_queues[rx_queue_id];
+ rxq = rx_queue;
rxdp = &(rxq->rx_ring[rxq->rx_tail]);
while ((desc < rxq->nb_rx_desc) &&
diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
index b03e56bc25..b94332cc86 100644
--- a/drivers/net/enic/enic_ethdev.c
+++ b/drivers/net/enic/enic_ethdev.c
@@ -237,18 +237,18 @@ static void enicpmd_dev_rx_queue_release(struct rte_eth_dev *dev, uint16_t qid)
enic_free_rq(rxq);
}
-static uint32_t enicpmd_dev_rx_queue_count(struct rte_eth_dev *dev,
- uint16_t rx_queue_id)
+static uint32_t enicpmd_dev_rx_queue_count(void *rx_queue)
{
- struct enic *enic = pmd_priv(dev);
+ struct enic *enic;
+ struct vnic_rq *sop_rq;
uint32_t queue_count = 0;
struct vnic_cq *cq;
uint32_t cq_tail;
uint16_t cq_idx;
- int rq_num;
- rq_num = enic_rte_rq_idx_to_sop_idx(rx_queue_id);
- cq = &enic->cq[enic_cq_rq(enic, rq_num)];
+ sop_rq = rx_queue;
+ enic = vnic_dev_priv(sop_rq->vdev);
+ cq = &enic->cq[enic_cq_rq(enic, sop_rq->index)];
cq_idx = cq->to_clean;
cq_tail = ioread32(&cq->ctrl->cq_tail);
diff --git a/drivers/net/fm10k/fm10k.h b/drivers/net/fm10k/fm10k.h
index 2e47ada829..17c73c4dc5 100644
--- a/drivers/net/fm10k/fm10k.h
+++ b/drivers/net/fm10k/fm10k.h
@@ -324,7 +324,7 @@ uint16_t fm10k_recv_scattered_pkts(void *rx_queue,
struct rte_mbuf **rx_pkts, uint16_t nb_pkts);
uint32_t
-fm10k_dev_rx_queue_count(struct rte_eth_dev *dev, uint16_t rx_queue_id);
+fm10k_dev_rx_queue_count(void *rx_queue);
int
fm10k_dev_rx_descriptor_status(void *rx_queue, uint16_t offset);
diff --git a/drivers/net/fm10k/fm10k_rxtx.c b/drivers/net/fm10k/fm10k_rxtx.c
index d9833505d1..b3515ae96a 100644
--- a/drivers/net/fm10k/fm10k_rxtx.c
+++ b/drivers/net/fm10k/fm10k_rxtx.c
@@ -367,14 +367,14 @@ fm10k_recv_scattered_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
}
uint32_t
-fm10k_dev_rx_queue_count(struct rte_eth_dev *dev, uint16_t rx_queue_id)
+fm10k_dev_rx_queue_count(void *rx_queue)
{
#define FM10K_RXQ_SCAN_INTERVAL 4
volatile union fm10k_rx_desc *rxdp;
struct fm10k_rx_queue *rxq;
uint16_t desc = 0;
- rxq = dev->data->rx_queues[rx_queue_id];
+ rxq = rx_queue;
rxdp = &rxq->hw_ring[rxq->next_dd];
while ((desc < rxq->nb_desc) &&
rxdp->w.status & rte_cpu_to_le_16(FM10K_RXD_STATUS_DD)) {
diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
index 70de0d2b58..02040b84f3 100644
--- a/drivers/net/hns3/hns3_rxtx.c
+++ b/drivers/net/hns3/hns3_rxtx.c
@@ -4685,7 +4685,7 @@ hns3_dev_tx_descriptor_status(void *tx_queue, uint16_t offset)
}
uint32_t
-hns3_rx_queue_count(struct rte_eth_dev *dev, uint16_t rx_queue_id)
+hns3_rx_queue_count(void *rx_queue)
{
/*
* Number of BDs that have been processed by the driver
@@ -4693,9 +4693,12 @@ hns3_rx_queue_count(struct rte_eth_dev *dev, uint16_t rx_queue_id)
*/
uint32_t driver_hold_bd_num;
struct hns3_rx_queue *rxq;
+ const struct rte_eth_dev *dev;
uint32_t fbd_num;
- rxq = dev->data->rx_queues[rx_queue_id];
+ rxq = rx_queue;
+ dev = &rte_eth_devices[rxq->port_id];
+
fbd_num = hns3_read_dev(rxq, HNS3_RING_RX_FBDNUM_REG);
if (dev->rx_pkt_burst == hns3_recv_pkts_vec ||
dev->rx_pkt_burst == hns3_recv_pkts_vec_sve)
diff --git a/drivers/net/hns3/hns3_rxtx.h b/drivers/net/hns3/hns3_rxtx.h
index bb309d38ed..c8229e9076 100644
--- a/drivers/net/hns3/hns3_rxtx.h
+++ b/drivers/net/hns3/hns3_rxtx.h
@@ -696,7 +696,7 @@ int hns3_rx_queue_setup(struct rte_eth_dev *dev, uint16_t idx, uint16_t nb_desc,
struct rte_mempool *mp);
int hns3_tx_queue_setup(struct rte_eth_dev *dev, uint16_t idx, uint16_t nb_desc,
unsigned int socket, const struct rte_eth_txconf *conf);
-uint32_t hns3_rx_queue_count(struct rte_eth_dev *dev, uint16_t rx_queue_id);
+uint32_t hns3_rx_queue_count(void *rx_queue);
int hns3_dev_rx_queue_start(struct rte_eth_dev *dev, uint16_t rx_queue_id);
int hns3_dev_rx_queue_stop(struct rte_eth_dev *dev, uint16_t rx_queue_id);
int hns3_dev_tx_queue_start(struct rte_eth_dev *dev, uint16_t tx_queue_id);
diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index ab77ec04b5..3df4e3de18 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -2121,14 +2121,14 @@ i40e_rx_queue_release(void *rxq)
}
uint32_t
-i40e_dev_rx_queue_count(struct rte_eth_dev *dev, uint16_t rx_queue_id)
+i40e_dev_rx_queue_count(void *rx_queue)
{
#define I40E_RXQ_SCAN_INTERVAL 4
volatile union i40e_rx_desc *rxdp;
struct i40e_rx_queue *rxq;
uint16_t desc = 0;
- rxq = dev->data->rx_queues[rx_queue_id];
+ rxq = rx_queue;
rxdp = &(rxq->rx_ring[rxq->rx_tail]);
while ((desc < rxq->nb_rx_desc) &&
((rte_le_to_cpu_64(rxdp->wb.qword1.status_error_len) &
diff --git a/drivers/net/i40e/i40e_rxtx.h b/drivers/net/i40e/i40e_rxtx.h
index 7a24dd6be5..2301e6301d 100644
--- a/drivers/net/i40e/i40e_rxtx.h
+++ b/drivers/net/i40e/i40e_rxtx.h
@@ -229,8 +229,7 @@ int i40e_tx_done_cleanup(void *txq, uint32_t free_cnt);
int i40e_alloc_rx_queue_mbufs(struct i40e_rx_queue *rxq);
void i40e_rx_queue_release_mbufs(struct i40e_rx_queue *rxq);
-uint32_t i40e_dev_rx_queue_count(struct rte_eth_dev *dev,
- uint16_t rx_queue_id);
+uint32_t i40e_dev_rx_queue_count(void *rx_queue);
int i40e_dev_rx_descriptor_status(void *rx_queue, uint16_t offset);
int i40e_dev_tx_descriptor_status(void *tx_queue, uint16_t offset);
diff --git a/drivers/net/iavf/iavf_rxtx.c b/drivers/net/iavf/iavf_rxtx.c
index 88661e5d74..88bbd40c10 100644
--- a/drivers/net/iavf/iavf_rxtx.c
+++ b/drivers/net/iavf/iavf_rxtx.c
@@ -2799,14 +2799,14 @@ iavf_dev_txq_info_get(struct rte_eth_dev *dev, uint16_t queue_id,
/* Get the number of used descriptors of a rx queue */
uint32_t
-iavf_dev_rxq_count(struct rte_eth_dev *dev, uint16_t queue_id)
+iavf_dev_rxq_count(void *rx_queue)
{
#define IAVF_RXQ_SCAN_INTERVAL 4
volatile union iavf_rx_desc *rxdp;
struct iavf_rx_queue *rxq;
uint16_t desc = 0;
- rxq = dev->data->rx_queues[queue_id];
+ rxq = rx_queue;
rxdp = &rxq->rx_ring[rxq->rx_tail];
while ((desc < rxq->nb_rx_desc) &&
diff --git a/drivers/net/iavf/iavf_rxtx.h b/drivers/net/iavf/iavf_rxtx.h
index 9591e45cb0..f4ae2fd6e1 100644
--- a/drivers/net/iavf/iavf_rxtx.h
+++ b/drivers/net/iavf/iavf_rxtx.h
@@ -453,7 +453,7 @@ void iavf_dev_rxq_info_get(struct rte_eth_dev *dev, uint16_t queue_id,
struct rte_eth_rxq_info *qinfo);
void iavf_dev_txq_info_get(struct rte_eth_dev *dev, uint16_t queue_id,
struct rte_eth_txq_info *qinfo);
-uint32_t iavf_dev_rxq_count(struct rte_eth_dev *dev, uint16_t queue_id);
+uint32_t iavf_dev_rxq_count(void *rx_queue);
int iavf_dev_rx_desc_status(void *rx_queue, uint16_t offset);
int iavf_dev_tx_desc_status(void *tx_queue, uint16_t offset);
diff --git a/drivers/net/ice/ice_rxtx.c b/drivers/net/ice/ice_rxtx.c
index 7a2220daa4..b06c2f1438 100644
--- a/drivers/net/ice/ice_rxtx.c
+++ b/drivers/net/ice/ice_rxtx.c
@@ -1460,14 +1460,14 @@ ice_txq_info_get(struct rte_eth_dev *dev, uint16_t queue_id,
}
uint32_t
-ice_rx_queue_count(struct rte_eth_dev *dev, uint16_t rx_queue_id)
+ice_rx_queue_count(void *rx_queue)
{
#define ICE_RXQ_SCAN_INTERVAL 4
volatile union ice_rx_flex_desc *rxdp;
struct ice_rx_queue *rxq;
uint16_t desc = 0;
- rxq = dev->data->rx_queues[rx_queue_id];
+ rxq = rx_queue;
rxdp = &rxq->rx_ring[rxq->rx_tail];
while ((desc < rxq->nb_rx_desc) &&
rte_le_to_cpu_16(rxdp->wb.status_error0) &
diff --git a/drivers/net/ice/ice_rxtx.h b/drivers/net/ice/ice_rxtx.h
index c5ec6b7d1a..e1c644fb63 100644
--- a/drivers/net/ice/ice_rxtx.h
+++ b/drivers/net/ice/ice_rxtx.h
@@ -230,7 +230,7 @@ uint16_t ice_prep_pkts(__rte_unused void *tx_queue, struct rte_mbuf **tx_pkts,
void ice_set_tx_function_flag(struct rte_eth_dev *dev,
struct ice_tx_queue *txq);
void ice_set_tx_function(struct rte_eth_dev *dev);
-uint32_t ice_rx_queue_count(struct rte_eth_dev *dev, uint16_t rx_queue_id);
+uint32_t ice_rx_queue_count(void *rx_queue);
void ice_rxq_info_get(struct rte_eth_dev *dev, uint16_t queue_id,
struct rte_eth_rxq_info *qinfo);
void ice_txq_info_get(struct rte_eth_dev *dev, uint16_t queue_id,
diff --git a/drivers/net/igc/igc_txrx.c b/drivers/net/igc/igc_txrx.c
index a66ce1d2b7..383bf834f3 100644
--- a/drivers/net/igc/igc_txrx.c
+++ b/drivers/net/igc/igc_txrx.c
@@ -722,8 +722,7 @@ void eth_igc_rx_queue_release(struct rte_eth_dev *dev, uint16_t qid)
igc_rx_queue_release(dev->data->rx_queues[qid]);
}
-uint32_t eth_igc_rx_queue_count(struct rte_eth_dev *dev,
- uint16_t rx_queue_id)
+uint32_t eth_igc_rx_queue_count(void *rx_queue)
{
/**
* Check the DD bit of a rx descriptor of each 4 in a group,
@@ -736,7 +735,7 @@ uint32_t eth_igc_rx_queue_count(struct rte_eth_dev *dev,
struct igc_rx_queue *rxq;
uint16_t desc = 0;
- rxq = dev->data->rx_queues[rx_queue_id];
+ rxq = rx_queue;
rxdp = &rxq->rx_ring[rxq->rx_tail];
while (desc < rxq->nb_rx_desc - rxq->rx_tail) {
diff --git a/drivers/net/igc/igc_txrx.h b/drivers/net/igc/igc_txrx.h
index bb040366f0..535108a868 100644
--- a/drivers/net/igc/igc_txrx.h
+++ b/drivers/net/igc/igc_txrx.h
@@ -22,8 +22,7 @@ int eth_igc_rx_queue_setup(struct rte_eth_dev *dev, uint16_t rx_queue_id,
const struct rte_eth_rxconf *rx_conf,
struct rte_mempool *mb_pool);
-uint32_t eth_igc_rx_queue_count(struct rte_eth_dev *dev,
- uint16_t rx_queue_id);
+uint32_t eth_igc_rx_queue_count(void *rx_queue);
int eth_igc_rx_descriptor_status(void *rx_queue, uint16_t offset);
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.h b/drivers/net/ixgbe/ixgbe_ethdev.h
index c01a74de89..950fb2d245 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.h
+++ b/drivers/net/ixgbe/ixgbe_ethdev.h
@@ -594,8 +594,7 @@ int ixgbe_dev_tx_queue_setup(struct rte_eth_dev *dev, uint16_t tx_queue_id,
uint16_t nb_tx_desc, unsigned int socket_id,
const struct rte_eth_txconf *tx_conf);
-uint32_t ixgbe_dev_rx_queue_count(struct rte_eth_dev *dev,
- uint16_t rx_queue_id);
+uint32_t ixgbe_dev_rx_queue_count(void *rx_queue);
int ixgbe_dev_rx_descriptor_status(void *rx_queue, uint16_t offset);
int ixgbe_dev_tx_descriptor_status(void *tx_queue, uint16_t offset);
diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index 0ac89cb711..4d3d30b662 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -3262,14 +3262,14 @@ ixgbe_dev_rx_queue_setup(struct rte_eth_dev *dev,
}
uint32_t
-ixgbe_dev_rx_queue_count(struct rte_eth_dev *dev, uint16_t rx_queue_id)
+ixgbe_dev_rx_queue_count(void *rx_queue)
{
#define IXGBE_RXQ_SCAN_INTERVAL 4
volatile union ixgbe_adv_rx_desc *rxdp;
struct ixgbe_rx_queue *rxq;
uint32_t desc = 0;
- rxq = dev->data->rx_queues[rx_queue_id];
+ rxq = rx_queue;
rxdp = &(rxq->rx_ring[rxq->rx_tail]);
while ((desc < rxq->nb_rx_desc) &&
diff --git a/drivers/net/mlx5/mlx5_rx.c b/drivers/net/mlx5/mlx5_rx.c
index e3b1051ba4..1a9eb35acc 100644
--- a/drivers/net/mlx5/mlx5_rx.c
+++ b/drivers/net/mlx5/mlx5_rx.c
@@ -240,32 +240,32 @@ mlx5_rx_burst_mode_get(struct rte_eth_dev *dev,
/**
* DPDK callback to get the number of used descriptors in a RX queue.
*
- * @param dev
- * Pointer to the device structure.
- *
- * @param rx_queue_id
- * The Rx queue.
+ * @param rx_queue
+ * The Rx queue pointer.
*
* @return
* The number of used rx descriptor.
* -EINVAL if the queue is invalid
*/
uint32_t
-mlx5_rx_queue_count(struct rte_eth_dev *dev, uint16_t rx_queue_id)
+mlx5_rx_queue_count(void *rx_queue)
{
- struct mlx5_priv *priv = dev->data->dev_private;
- struct mlx5_rxq_data *rxq;
+ struct mlx5_rxq_data *rxq = rx_queue;
+ struct rte_eth_dev *dev;
+
+ if (!rxq) {
+ rte_errno = EINVAL;
+ return -rte_errno;
+ }
+
+ dev = &rte_eth_devices[rxq->port_id];
if (dev->rx_pkt_burst == NULL ||
dev->rx_pkt_burst == removed_rx_burst) {
rte_errno = ENOTSUP;
return -rte_errno;
}
- rxq = (*priv->rxqs)[rx_queue_id];
- if (!rxq) {
- rte_errno = EINVAL;
- return -rte_errno;
- }
+
return rx_queue_count(rxq);
}
diff --git a/drivers/net/mlx5/mlx5_rx.h b/drivers/net/mlx5/mlx5_rx.h
index 2b7ad3e48b..bdc48f3d9f 100644
--- a/drivers/net/mlx5/mlx5_rx.h
+++ b/drivers/net/mlx5/mlx5_rx.h
@@ -260,7 +260,7 @@ uint16_t mlx5_rx_burst_mprq(void *dpdk_rxq, struct rte_mbuf **pkts,
uint16_t removed_rx_burst(void *dpdk_rxq, struct rte_mbuf **pkts,
uint16_t pkts_n);
int mlx5_rx_descriptor_status(void *rx_queue, uint16_t offset);
-uint32_t mlx5_rx_queue_count(struct rte_eth_dev *dev, uint16_t rx_queue_id);
+uint32_t mlx5_rx_queue_count(void *rx_queue);
void mlx5_rxq_info_get(struct rte_eth_dev *dev, uint16_t queue_id,
struct rte_eth_rxq_info *qinfo);
int mlx5_rx_burst_mode_get(struct rte_eth_dev *dev, uint16_t rx_queue_id,
diff --git a/drivers/net/netvsc/hn_rxtx.c b/drivers/net/netvsc/hn_rxtx.c
index e880dc2bb2..f8fff1bcd1 100644
--- a/drivers/net/netvsc/hn_rxtx.c
+++ b/drivers/net/netvsc/hn_rxtx.c
@@ -1018,9 +1018,9 @@ hn_dev_rx_queue_release(struct rte_eth_dev *dev, uint16_t qid)
* For this device that means how many packets are pending in the ring.
*/
uint32_t
-hn_dev_rx_queue_count(struct rte_eth_dev *dev, uint16_t queue_id)
+hn_dev_rx_queue_count(void *rx_queue)
{
- struct hn_rx_queue *rxq = dev->data->rx_queues[queue_id];
+ struct hn_rx_queue *rxq = rx_queue;
return rte_ring_count(rxq->rx_ring);
}
diff --git a/drivers/net/netvsc/hn_var.h b/drivers/net/netvsc/hn_var.h
index 2cd1f8a881..18703f99b9 100644
--- a/drivers/net/netvsc/hn_var.h
+++ b/drivers/net/netvsc/hn_var.h
@@ -215,7 +215,7 @@ int hn_dev_rx_queue_setup(struct rte_eth_dev *dev,
void hn_dev_rx_queue_info(struct rte_eth_dev *dev, uint16_t queue_id,
struct rte_eth_rxq_info *qinfo);
void hn_dev_rx_queue_release(struct rte_eth_dev *dev, uint16_t qid);
-uint32_t hn_dev_rx_queue_count(struct rte_eth_dev *dev, uint16_t queue_id);
+uint32_t hn_dev_rx_queue_count(void *rx_queue);
int hn_dev_rx_queue_status(void *rxq, uint16_t offset);
void hn_dev_free_queues(struct rte_eth_dev *dev);
diff --git a/drivers/net/nfp/nfp_rxtx.c b/drivers/net/nfp/nfp_rxtx.c
index feeacb5614..733f81e4b2 100644
--- a/drivers/net/nfp/nfp_rxtx.c
+++ b/drivers/net/nfp/nfp_rxtx.c
@@ -97,14 +97,14 @@ nfp_net_rx_freelist_setup(struct rte_eth_dev *dev)
}
uint32_t
-nfp_net_rx_queue_count(struct rte_eth_dev *dev, uint16_t queue_idx)
+nfp_net_rx_queue_count(void *rx_queue)
{
struct nfp_net_rxq *rxq;
struct nfp_net_rx_desc *rxds;
uint32_t idx;
uint32_t count;
- rxq = (struct nfp_net_rxq *)dev->data->rx_queues[queue_idx];
+ rxq = rx_queue;
idx = rxq->rd_p;
diff --git a/drivers/net/nfp/nfp_rxtx.h b/drivers/net/nfp/nfp_rxtx.h
index ab49898605..1a813ded15 100644
--- a/drivers/net/nfp/nfp_rxtx.h
+++ b/drivers/net/nfp/nfp_rxtx.h
@@ -275,8 +275,7 @@ struct nfp_net_rxq {
} __rte_aligned(64);
int nfp_net_rx_freelist_setup(struct rte_eth_dev *dev);
-uint32_t nfp_net_rx_queue_count(struct rte_eth_dev *dev,
- uint16_t queue_idx);
+uint32_t nfp_net_rx_queue_count(void *rx_queue);
uint16_t nfp_net_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
uint16_t nb_pkts);
void nfp_net_rx_queue_release(struct rte_eth_dev *dev, uint16_t queue_idx);
diff --git a/drivers/net/octeontx2/otx2_ethdev.h b/drivers/net/octeontx2/otx2_ethdev.h
index 0d73013433..7a8d19d541 100644
--- a/drivers/net/octeontx2/otx2_ethdev.h
+++ b/drivers/net/octeontx2/otx2_ethdev.h
@@ -431,7 +431,7 @@ int otx2_rx_burst_mode_get(struct rte_eth_dev *dev, uint16_t queue_id,
struct rte_eth_burst_mode *mode);
int otx2_tx_burst_mode_get(struct rte_eth_dev *dev, uint16_t queue_id,
struct rte_eth_burst_mode *mode);
-uint32_t otx2_nix_rx_queue_count(struct rte_eth_dev *eth_dev, uint16_t qidx);
+uint32_t otx2_nix_rx_queue_count(void *rx_queue);
int otx2_nix_tx_done_cleanup(void *txq, uint32_t free_cnt);
int otx2_nix_rx_descriptor_status(void *rx_queue, uint16_t offset);
int otx2_nix_tx_descriptor_status(void *tx_queue, uint16_t offset);
diff --git a/drivers/net/octeontx2/otx2_ethdev_ops.c b/drivers/net/octeontx2/otx2_ethdev_ops.c
index 5cb3905b64..3a763f691b 100644
--- a/drivers/net/octeontx2/otx2_ethdev_ops.c
+++ b/drivers/net/octeontx2/otx2_ethdev_ops.c
@@ -342,13 +342,13 @@ nix_rx_head_tail_get(struct otx2_eth_dev *dev,
}
uint32_t
-otx2_nix_rx_queue_count(struct rte_eth_dev *eth_dev, uint16_t queue_idx)
+otx2_nix_rx_queue_count(void *rx_queue)
{
- struct otx2_eth_rxq *rxq = eth_dev->data->rx_queues[queue_idx];
- struct otx2_eth_dev *dev = otx2_eth_pmd_priv(eth_dev);
+ struct otx2_eth_rxq *rxq = rx_queue;
+ struct otx2_eth_dev *dev = otx2_eth_pmd_priv(rxq->eth_dev);
uint32_t head, tail;
- nix_rx_head_tail_get(dev, &head, &tail, queue_idx);
+ nix_rx_head_tail_get(dev, &head, &tail, rxq->rq);
return (tail - head) % rxq->qlen;
}
diff --git a/drivers/net/sfc/sfc_ethdev.c b/drivers/net/sfc/sfc_ethdev.c
index c0d9810fbb..603af6242d 100644
--- a/drivers/net/sfc/sfc_ethdev.c
+++ b/drivers/net/sfc/sfc_ethdev.c
@@ -1356,19 +1356,19 @@ sfc_tx_queue_info_get(struct rte_eth_dev *dev, uint16_t ethdev_qid,
* use any process-local pointers from the adapter data.
*/
static uint32_t
-sfc_rx_queue_count(struct rte_eth_dev *dev, uint16_t ethdev_qid)
+sfc_rx_queue_count(void *rx_queue)
{
- const struct sfc_adapter_priv *sap = sfc_adapter_priv_by_eth_dev(dev);
- struct sfc_adapter_shared *sas = sfc_adapter_shared_by_eth_dev(dev);
- sfc_ethdev_qid_t sfc_ethdev_qid = ethdev_qid;
+ struct sfc_dp_rxq *dp_rxq = rx_queue;
+ const struct sfc_dp_rx *dp_rx;
struct sfc_rxq_info *rxq_info;
- rxq_info = sfc_rxq_info_by_ethdev_qid(sas, sfc_ethdev_qid);
+ dp_rx = sfc_dp_rx_by_dp_rxq(dp_rxq);
+ rxq_info = sfc_rxq_info_by_dp_rxq(dp_rxq);
if ((rxq_info->state & SFC_RXQ_STARTED) == 0)
return 0;
- return sap->dp_rx->qdesc_npending(rxq_info->dp);
+ return dp_rx->qdesc_npending(dp_rxq);
}
/*
diff --git a/drivers/net/thunderx/nicvf_ethdev.c b/drivers/net/thunderx/nicvf_ethdev.c
index 5502f1ee69..2103f96d5e 100644
--- a/drivers/net/thunderx/nicvf_ethdev.c
+++ b/drivers/net/thunderx/nicvf_ethdev.c
@@ -1060,8 +1060,7 @@ nicvf_rx_queue_release_mbufs(struct rte_eth_dev *dev, struct nicvf_rxq *rxq)
if (dev->rx_pkt_burst == NULL)
return;
- while ((rxq_cnt = nicvf_dev_rx_queue_count(dev,
- nicvf_netdev_qidx(rxq->nic, rxq->queue_id)))) {
+ while ((rxq_cnt = nicvf_dev_rx_queue_count(rxq))) {
nb_pkts = dev->rx_pkt_burst(rxq, rx_pkts,
NICVF_MAX_RX_FREE_THRESH);
PMD_DRV_LOG(INFO, "nb_pkts=%d rxq_cnt=%d", nb_pkts, rxq_cnt);
diff --git a/drivers/net/thunderx/nicvf_rxtx.c b/drivers/net/thunderx/nicvf_rxtx.c
index 91e09ff8d5..0d4f4ae87e 100644
--- a/drivers/net/thunderx/nicvf_rxtx.c
+++ b/drivers/net/thunderx/nicvf_rxtx.c
@@ -649,11 +649,11 @@ nicvf_recv_pkts_multiseg_cksum_vlan_strip(void *rx_queue,
}
uint32_t
-nicvf_dev_rx_queue_count(struct rte_eth_dev *dev, uint16_t queue_idx)
+nicvf_dev_rx_queue_count(void *rx_queue)
{
struct nicvf_rxq *rxq;
- rxq = dev->data->rx_queues[queue_idx];
+ rxq = rx_queue;
return nicvf_addr_read(rxq->cq_status) & NICVF_CQ_CQE_COUNT_MASK;
}
diff --git a/drivers/net/thunderx/nicvf_rxtx.h b/drivers/net/thunderx/nicvf_rxtx.h
index d6ed660b4e..271f329dc4 100644
--- a/drivers/net/thunderx/nicvf_rxtx.h
+++ b/drivers/net/thunderx/nicvf_rxtx.h
@@ -83,7 +83,7 @@ nicvf_mbuff_init_mseg_update(struct rte_mbuf *pkt, const uint64_t mbuf_init,
*(uint64_t *)(&pkt->rearm_data) = init.value;
}
-uint32_t nicvf_dev_rx_queue_count(struct rte_eth_dev *dev, uint16_t queue_idx);
+uint32_t nicvf_dev_rx_queue_count(void *rx_queue);
uint32_t nicvf_dev_rbdr_refill(struct rte_eth_dev *dev, uint16_t queue_idx);
uint16_t nicvf_recv_pkts_no_offload(void *rxq, struct rte_mbuf **rx_pkts,
diff --git a/drivers/net/txgbe/txgbe_ethdev.h b/drivers/net/txgbe/txgbe_ethdev.h
index 112567eecc..528f11439b 100644
--- a/drivers/net/txgbe/txgbe_ethdev.h
+++ b/drivers/net/txgbe/txgbe_ethdev.h
@@ -438,8 +438,7 @@ int txgbe_dev_tx_queue_setup(struct rte_eth_dev *dev, uint16_t tx_queue_id,
uint16_t nb_tx_desc, unsigned int socket_id,
const struct rte_eth_txconf *tx_conf);
-uint32_t txgbe_dev_rx_queue_count(struct rte_eth_dev *dev,
- uint16_t rx_queue_id);
+uint32_t txgbe_dev_rx_queue_count(void *rx_queue);
int txgbe_dev_rx_descriptor_status(void *rx_queue, uint16_t offset);
int txgbe_dev_tx_descriptor_status(void *tx_queue, uint16_t offset);
diff --git a/drivers/net/txgbe/txgbe_rxtx.c b/drivers/net/txgbe/txgbe_rxtx.c
index b6339fe50b..4849fb385e 100644
--- a/drivers/net/txgbe/txgbe_rxtx.c
+++ b/drivers/net/txgbe/txgbe_rxtx.c
@@ -2688,14 +2688,14 @@ txgbe_dev_rx_queue_setup(struct rte_eth_dev *dev,
}
uint32_t
-txgbe_dev_rx_queue_count(struct rte_eth_dev *dev, uint16_t rx_queue_id)
+txgbe_dev_rx_queue_count(void *rx_queue)
{
#define TXGBE_RXQ_SCAN_INTERVAL 4
volatile struct txgbe_rx_desc *rxdp;
struct txgbe_rx_queue *rxq;
uint32_t desc = 0;
- rxq = dev->data->rx_queues[rx_queue_id];
+ rxq = rx_queue;
rxdp = &rxq->rx_ring[rxq->rx_tail];
while ((desc < rxq->nb_rx_desc) &&
diff --git a/drivers/net/vhost/rte_eth_vhost.c b/drivers/net/vhost/rte_eth_vhost.c
index 2e24e5f7ff..a7935a716d 100644
--- a/drivers/net/vhost/rte_eth_vhost.c
+++ b/drivers/net/vhost/rte_eth_vhost.c
@@ -1375,11 +1375,11 @@ eth_link_update(struct rte_eth_dev *dev __rte_unused,
}
static uint32_t
-eth_rx_queue_count(struct rte_eth_dev *dev, uint16_t rx_queue_id)
+eth_rx_queue_count(void *rx_queue)
{
struct vhost_queue *vq;
- vq = dev->data->rx_queues[rx_queue_id];
+ vq = rx_queue;
if (vq == NULL)
return 0;
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index cb847a2c38..4007bd0e73 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -5040,7 +5040,7 @@ rte_eth_rx_queue_count(uint16_t port_id, uint16_t queue_id)
dev->data->rx_queues[queue_id] == NULL)
return -EINVAL;
- return (int)(*dev->rx_queue_count)(dev, queue_id);
+ return (int)(*dev->rx_queue_count)(dev->data->rx_queues[queue_id]);
}
/**@{@name Rx hardware descriptor states
diff --git a/lib/ethdev/rte_ethdev_core.h b/lib/ethdev/rte_ethdev_core.h
index 8aae713af6..af824ef890 100644
--- a/lib/ethdev/rte_ethdev_core.h
+++ b/lib/ethdev/rte_ethdev_core.h
@@ -41,8 +41,7 @@ typedef uint16_t (*eth_tx_prep_t)(void *txq,
/**< @internal Prepare output packets on a transmit queue of an Ethernet device. */
-typedef uint32_t (*eth_rx_queue_count_t)(struct rte_eth_dev *dev,
- uint16_t rx_queue_id);
+typedef uint32_t (*eth_rx_queue_count_t)(void *rxq);
/**< @internal Get number of used descriptors on a receive queue. */
typedef int (*eth_rx_descriptor_status_t)(void *rxq, uint16_t offset);
--
2.26.3
^ permalink raw reply [relevance 6%]
* [dpdk-dev] [PATCH v6 0/6] hide eth dev related structures
[not found] <0211007112750.25526-1-konstantin.ananyev@intel.com>
@ 2021-10-13 13:36 4% ` Konstantin Ananyev
2021-10-13 13:37 6% ` [dpdk-dev] [PATCH v6 2/6] ethdev: change input parameters for rx_queue_count Konstantin Ananyev
` (4 more replies)
0 siblings, 5 replies; 200+ results
From: Konstantin Ananyev @ 2021-10-13 13:36 UTC (permalink / raw)
To: dev
Cc: xiaoyun.li, anoobj, jerinj, ndabilpuram, adwivedi,
shepard.siegel, ed.czeck, john.miller, irusskikh, ajit.khaparde,
somnath.kotur, rahul.lakkireddy, hemant.agrawal, sachin.saxena,
haiyue.wang, johndale, hyonkim, qi.z.zhang, xiao.w.wang, humin29,
yisen.zhuang, oulijun, beilei.xing, jingjing.wu, qiming.yang,
matan, viacheslavo, sthemmin, longli, heinrich.kuhn, kirankumark,
andrew.rybchenko, mczekaj, jiawenwu, jianwang, maxime.coquelin,
chenbo.xia, thomas, ferruh.yigit, mdr, jay.jayatheerthan,
Konstantin Ananyev
v6 changes:
- Update comments (Andrew)
- Move callback related variables under corresponding ifdefs (Andrew)
- Few nits in rte_eth_macaddrs_get (Andrew)
- Rebased on top of next-net tree
v5 changes:
- Fix spelling (Thomas/David)
- Rename internal helper functions (David)
- Reorder patches and update commit messages (Thomas)
- Update comments (Thomas)
- Changed layout in rte_eth_fp_ops, to group functions and
related data based on their functionality:
first 64B line for Rx, second one for Tx.
Didn't observe any real performance difference comparing to
original layout. Though decided to keep a new one, as it seems
a bit more plausible.
v4 changes:
- Fix secondary process attach (Pavan)
- Fix build failure (Ferruh)
- Update lib/ethdev/verion.map (Ferruh)
Note that moving newly added symbols from EXPERIMENTAL to DPDK_22
section makes checkpatch.sh to complain.
v3 changes:
- Changes in public struct naming (Jerin/Haiyue)
- Split patches
- Update docs
- Shamelessly included Andrew's patch:
https://patches.dpdk.org/project/dpdk/patch/20210928154856.1015020-1-andrew.rybchenko@oktetlabs.ru/
into these series.
I have to do similar thing here, so decided to avoid duplicated effort.
The aim of these patch series is to make rte_ethdev core data structures
(rte_eth_dev, rte_eth_dev_data, rte_eth_rxtx_callback, etc.) internal to
DPDK and not visible to the user.
That should allow future possible changes to core ethdev related structures
to be transparent to the user and help to improve ABI/API stability.
Note that current ethdev API is preserved, but it is a formal ABI break.
The work is based on previous discussions at:
https://www.mail-archive.com/dev@dpdk.org/msg211405.html
https://www.mail-archive.com/dev@dpdk.org/msg216685.html
and consists of the following main points:
1. Copy public 'fast' function pointers (rx_pkt_burst(), etc.) and
related data pointer from rte_eth_dev into a separate flat array.
We keep it public to still be able to use inline functions for these
'fast' calls (like rte_eth_rx_burst(), etc.) to avoid/minimize slowdown.
Note that apart from function pointers itself, each element of this
flat array also contains two opaque pointers for each ethdev:
1) a pointer to an array of internal queue data pointers
2) points to array of queue callback data pointers.
Note that exposing this extra information allows us to avoid extra
changes inside PMD level, plus should help to avoid possible
performance degradation.
2. Change implementation of 'fast' inline ethdev functions
(rte_eth_rx_burst(), etc.) to use new public flat array.
While it is an ABI breakage, this change is intended to be transparent
for both users (no changes in user app is required) and PMD developers
(no changes in PMD is required).
One extra note - with new implementation RX/TX callback invocation
will cost one extra function call with this changes. That might cause
some slowdown for code-path with RX/TX callbacks heavily involved.
Hope such trade-off is acceptable for the community.
3. Move rte_eth_dev, rte_eth_dev_data, rte_eth_rxtx_callback and related
things into internal header: <ethdev_driver.h>.
That approach was selected to:
- Avoid(/minimize) possible performance losses.
- Minimize required changes inside PMDs.
Performance testing results (ICX 2.0GHz, E810 (ice)):
- testpmd macswap fwd mode, plus
a) no RX/TX callbacks:
no actual slowdown observed
b) bpf-load rx 0 0 JM ./dpdk.org/examples/bpf/t3.o:
~2% slowdown
- l3fwd: no actual slowdown observed
Would like to thank everyone who already reviewed and tested previous
versions of these series. All other interested parties please don't be shy
and provide your feedback.
Konstantin Ananyev (6):
ethdev: allocate max space for internal queue array
ethdev: change input parameters for rx_queue_count
ethdev: copy fast-path API into separate structure
ethdev: make fast-path functions to use new flat array
ethdev: add API to retrieve multiple ethernet addresses
ethdev: hide eth dev related structures
app/test-pmd/config.c | 23 +-
doc/guides/rel_notes/release_21_11.rst | 17 +
drivers/common/octeontx2/otx2_sec_idev.c | 2 +-
drivers/crypto/octeontx2/otx2_cryptodev_ops.c | 2 +-
drivers/net/ark/ark_ethdev_rx.c | 4 +-
drivers/net/ark/ark_ethdev_rx.h | 3 +-
drivers/net/atlantic/atl_ethdev.h | 2 +-
drivers/net/atlantic/atl_rxtx.c | 9 +-
drivers/net/bnxt/bnxt_ethdev.c | 8 +-
drivers/net/cxgbe/base/adapter.h | 2 +-
drivers/net/dpaa/dpaa_ethdev.c | 9 +-
drivers/net/dpaa2/dpaa2_ethdev.c | 9 +-
drivers/net/dpaa2/dpaa2_ptp.c | 2 +-
drivers/net/e1000/e1000_ethdev.h | 6 +-
drivers/net/e1000/em_rxtx.c | 4 +-
drivers/net/e1000/igb_rxtx.c | 4 +-
drivers/net/enic/enic_ethdev.c | 12 +-
drivers/net/fm10k/fm10k.h | 2 +-
drivers/net/fm10k/fm10k_rxtx.c | 4 +-
drivers/net/hns3/hns3_rxtx.c | 7 +-
drivers/net/hns3/hns3_rxtx.h | 2 +-
drivers/net/i40e/i40e_rxtx.c | 4 +-
drivers/net/i40e/i40e_rxtx.h | 3 +-
drivers/net/iavf/iavf_rxtx.c | 4 +-
drivers/net/iavf/iavf_rxtx.h | 2 +-
drivers/net/ice/ice_rxtx.c | 4 +-
drivers/net/ice/ice_rxtx.h | 2 +-
drivers/net/igc/igc_txrx.c | 5 +-
drivers/net/igc/igc_txrx.h | 3 +-
drivers/net/ixgbe/ixgbe_ethdev.h | 3 +-
drivers/net/ixgbe/ixgbe_rxtx.c | 4 +-
drivers/net/mlx5/mlx5_rx.c | 26 +-
drivers/net/mlx5/mlx5_rx.h | 2 +-
drivers/net/netvsc/hn_rxtx.c | 4 +-
drivers/net/netvsc/hn_var.h | 3 +-
drivers/net/nfp/nfp_rxtx.c | 4 +-
drivers/net/nfp/nfp_rxtx.h | 3 +-
drivers/net/octeontx2/otx2_ethdev.h | 2 +-
drivers/net/octeontx2/otx2_ethdev_ops.c | 8 +-
drivers/net/sfc/sfc_ethdev.c | 12 +-
drivers/net/thunderx/nicvf_ethdev.c | 3 +-
drivers/net/thunderx/nicvf_rxtx.c | 4 +-
drivers/net/thunderx/nicvf_rxtx.h | 2 +-
drivers/net/txgbe/txgbe_ethdev.h | 3 +-
drivers/net/txgbe/txgbe_rxtx.c | 4 +-
drivers/net/vhost/rte_eth_vhost.c | 4 +-
lib/ethdev/ethdev_driver.h | 154 +++++++++
lib/ethdev/ethdev_private.c | 83 +++++
lib/ethdev/ethdev_private.h | 7 +
lib/ethdev/rte_ethdev.c | 90 ++++--
lib/ethdev/rte_ethdev.h | 291 +++++++++++++-----
lib/ethdev/rte_ethdev_core.h | 177 +++--------
lib/ethdev/version.map | 6 +-
lib/eventdev/rte_event_eth_rx_adapter.c | 2 +-
lib/eventdev/rte_event_eth_tx_adapter.c | 2 +-
lib/eventdev/rte_eventdev.c | 2 +-
lib/metrics/rte_metrics_telemetry.c | 2 +-
57 files changed, 694 insertions(+), 373 deletions(-)
--
2.26.3
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v9 03/10] security: add UDP params for IPsec NAT-T
2021-10-13 12:13 5% ` [dpdk-dev] [PATCH v9 01/10] security: add ESN field to ipsec_xform Radu Nicolau
@ 2021-10-13 12:13 5% ` Radu Nicolau
1 sibling, 0 replies; 200+ results
From: Radu Nicolau @ 2021-10-13 12:13 UTC (permalink / raw)
To: Ray Kinsella, Akhil Goyal, Declan Doherty
Cc: dev, konstantin.ananyev, vladimir.medvedkin, bruce.richardson,
roy.fan.zhang, hemant.agrawal, anoobj, abhijit.sinha,
daniel.m.buckley, marchana, ktejasree, matan, Radu Nicolau
Add support for specifying UDP port params for UDP encapsulation option.
RFC3948 section-2.1 does not enforce using specific the UDP ports for
UDP-Encapsulated ESP Header
Signed-off-by: Declan Doherty <declan.doherty@intel.com>
Signed-off-by: Radu Nicolau <radu.nicolau@intel.com>
Signed-off-by: Abhijit Sinha <abhijit.sinha@intel.com>
Signed-off-by: Daniel Martin Buckley <daniel.m.buckley@intel.com>
Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
Acked-by: Anoob Joseph <anoobj@marvell.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 5 ++---
doc/guides/rel_notes/release_21_11.rst | 4 ++++
lib/security/rte_security.h | 7 +++++++
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index accb9c7d83..6517e7821f 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -204,9 +204,8 @@ Deprecation Notices
pointer for the private data to the application which can be attached
to the packet while enqueuing.
-* security: The structure ``rte_security_ipsec_xform`` will be extended with
- multiple fields: source and destination port of UDP encapsulation,
- IPsec payload MSS (Maximum Segment Size).
+* security: The structure ``rte_security_ipsec_xform`` will be extended with:
+ new field: IPsec payload MSS (Maximum Segment Size).
* security: The IPsec SA config options ``struct rte_security_ipsec_sa_options``
will be updated with new fields to support new features like TSO in case of
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index 544d44b1a8..1748c2db05 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -274,6 +274,10 @@ ABI Changes
application to start from an arbitrary ESN value for debug and SA lifetime
enforcement purposes.
+* security: A new structure ``udp`` was added in structure
+ ``rte_security_ipsec_xform`` to allow setting the source and destination ports
+ for UDP encapsulated IPsec traffic.
+
* bbdev: Added capability related to more comprehensive CRC options,
shifting values of the ``enum rte_bbdev_op_ldpcdec_flag_bitmasks``.
diff --git a/lib/security/rte_security.h b/lib/security/rte_security.h
index 764ce83bca..17d0e95412 100644
--- a/lib/security/rte_security.h
+++ b/lib/security/rte_security.h
@@ -128,6 +128,11 @@ struct rte_security_ipsec_tunnel_param {
};
};
+struct rte_security_ipsec_udp_param {
+ uint16_t sport;
+ uint16_t dport;
+};
+
/**
* IPsec Security Association option flags
*/
@@ -326,6 +331,8 @@ struct rte_security_ipsec_xform {
};
} esn;
/**< Extended Sequence Number */
+ struct rte_security_ipsec_udp_param udp;
+ /**< UDP parameters, ignored when udp_encap option not specified */
};
/**
--
2.25.1
^ permalink raw reply [relevance 5%]
* [dpdk-dev] [PATCH v9 01/10] security: add ESN field to ipsec_xform
@ 2021-10-13 12:13 5% ` Radu Nicolau
2021-10-13 12:13 5% ` [dpdk-dev] [PATCH v9 03/10] security: add UDP params for IPsec NAT-T Radu Nicolau
1 sibling, 0 replies; 200+ results
From: Radu Nicolau @ 2021-10-13 12:13 UTC (permalink / raw)
To: Ray Kinsella, Akhil Goyal, Declan Doherty
Cc: dev, konstantin.ananyev, vladimir.medvedkin, bruce.richardson,
roy.fan.zhang, hemant.agrawal, anoobj, abhijit.sinha,
daniel.m.buckley, marchana, ktejasree, matan, Radu Nicolau
Update ipsec_xform definition to include ESN field.
This allows the application to control the ESN starting value.
Signed-off-by: Declan Doherty <declan.doherty@intel.com>
Signed-off-by: Radu Nicolau <radu.nicolau@intel.com>
Signed-off-by: Abhijit Sinha <abhijit.sinha@intel.com>
Signed-off-by: Daniel Martin Buckley <daniel.m.buckley@intel.com>
Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
Acked-by: Anoob Joseph <anoobj@marvell.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 2 +-
doc/guides/rel_notes/release_21_11.rst | 5 +++++
lib/security/rte_security.h | 8 ++++++++
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index a4e86b31f5..accb9c7d83 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -206,7 +206,7 @@ Deprecation Notices
* security: The structure ``rte_security_ipsec_xform`` will be extended with
multiple fields: source and destination port of UDP encapsulation,
- IPsec payload MSS (Maximum Segment Size), and ESN (Extended Sequence Number).
+ IPsec payload MSS (Maximum Segment Size).
* security: The IPsec SA config options ``struct rte_security_ipsec_sa_options``
will be updated with new fields to support new features like TSO in case of
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index 54718ff367..f840586a20 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -265,6 +265,11 @@ ABI Changes
packet IPv4 header checksum and L4 checksum need to be offloaded to
security device.
+* security: A new structure ``esn`` was added in structure
+ ``rte_security_ipsec_xform`` to set an initial ESN value. This permits
+ application to start from an arbitrary ESN value for debug and SA lifetime
+ enforcement purposes.
+
* bbdev: Added capability related to more comprehensive CRC options,
shifting values of the ``enum rte_bbdev_op_ldpcdec_flag_bitmasks``.
diff --git a/lib/security/rte_security.h b/lib/security/rte_security.h
index 7eb9f109ae..764ce83bca 100644
--- a/lib/security/rte_security.h
+++ b/lib/security/rte_security.h
@@ -318,6 +318,14 @@ struct rte_security_ipsec_xform {
/**< Anti replay window size to enable sequence replay attack handling.
* replay checking is disabled if the window size is 0.
*/
+ union {
+ uint64_t value;
+ struct {
+ uint32_t low;
+ uint32_t hi;
+ };
+ } esn;
+ /**< Extended Sequence Number */
};
/**
--
2.25.1
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH] pipeline: remove experimental tag from API
2021-10-13 11:42 0% ` Kinsella, Ray
@ 2021-10-13 11:58 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2021-10-13 11:58 UTC (permalink / raw)
To: Bruce Richardson, Kinsella, Ray, Dumitrescu, Cristian, Singh, Jasvinder
Cc: dev, Zhang, Roy Fan, david.marchand
13/10/2021 13:42, Kinsella, Ray:
> On 13/10/2021 12:11, Bruce Richardson wrote:
> > On Wed, Oct 13, 2021 at 11:02:02AM +0100, Kinsella, Ray wrote:
> >> On 13/10/2021 10:49, Thomas Monjalon wrote:
> >>> 13/10/2021 11:43, Kinsella, Ray:
> >>>> On 13/10/2021 10:40, Thomas Monjalon wrote:
> >>>>> 13/10/2021 10:51, Kinsella, Ray:
> >>>>>> On 12/10/2021 22:52, Thomas Monjalon wrote:
> >>>>>>> 12/10/2021 22:34, Dumitrescu, Cristian:
> >>>>>>>> From: Thomas Monjalon <thomas@monjalon.net>
> >>>>>>>>> 01/09/2021 14:20, Jasvinder Singh:
> >>>>>>>>>> These APIs were introduced in 18.05, therefore removing
> >>>>>>>>>> experimental tag to promote them to stable state.
> >>>>>>>>>>
> >>>>>>>>>> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
> >>>>>>>>>> ---
> >>>>>>>>>> lib/pipeline/rte_port_in_action.h | 10 ----------
> >>>>>>>>>> lib/pipeline/rte_table_action.h | 18 ------------------
> >>>>>>>>>> lib/pipeline/version.map | 16 ++++++----------
> >>>>>>>>>> 3 files changed, 6 insertions(+), 38 deletions(-)
> >>>>>>>>>
> >>>>>>>>> Cristian, please can you check whether you intend to keep these functions in
> >>>>>>>>> future?
> >>>>>>>>> If they are candidate to be removed, there is no point to promote them.
> >>>>>>>>
> >>>>>>>> Hi Thomas,
> >>>>>>>>
> >>>>>>>> Yes, they are candidate for removal, as the new rte_swx_pipeline API evolves.
> >>>>>>>>
> >>>>>>>> But removing them requires updating the drivers/net/softnic code to use the new API, which is not going to be completed in time for release 21.11.
> >>>>>>>>
> >>>>>>>> So given this lag, it might be better to simply promote these functions to stable API now, as Ray suggests, instead of continuing to keep them experimental; then, once these functions are no longer used, then we can remove them, most likely in 22.11.
> >>>>>>>>
> >>>>>>>> So I will ack these patches, but I am willing to reconsider if you feel strongly against this approach.
> >>>>>>>
> >>>>>>> I think we should not promote API that we know will disappear soon.
> >>>>>>> The stable status means something for the users.
> >>>>>>> Ray, what is your opinion?
> >>>>>>>
> >>>>>>
> >>>>>> Well - I agree with Cristian (he and I discuss this a few weeks ago).
> >>>>>> My position is if you are going to maintain an API, that means giving a few guarantees.
> >>>>>> The API's have been experimental for 3 years ... at what point do they mature?
> >>>>>>
> >>>>>> However, I agree there is two ways to look at this thing, I try to be pragmatic.
> >>>>>> Maturing of any ABI/API is a conversation between a maintainer and the contributor.
> >>>>>> If they strongly feel, it is a pointless exercise - I won't argue.
> >>>>>
> >>>>> I think you did't get it.
> >>>>> This API will be removed soon.
> >>>>> That's why I think it doesn't make sense to make them stable, just before removing.
> >>>>>
> >>>>
> >>>> Nope, I got it 110%
> >>>> I reflected both my opinion as ABI Maintainer, and tried to be pragmatic about the situation.
> >>>>
> >>>> As I said "Maturing of any ABI/API is a conversation between a maintainer and the contributor.
> >>>> If they strongly feel, it is a pointless exercise - I won't argue."
> >>>
> >>> Sorry, I don't understand your position.
> >>> Do you think we should promote functions to stable which are candidate to be removed soon?
> >>>
> >>
> >> I am just reflecting the policy here.
> >>
> >> "An API’s experimental status should be reviewed annually, by both the maintainer and/or the original contributor. Ordinarily APIs marked as experimental will be promoted to the stable ABI once a maintainer has become satisfied that the API is mature and is unlikely to change."
> >>
> > If an API is planned for removal, then I think it falls under the bucket of
> > "likely to change", so should not be made non-experimental. Therefore I'd
> > agree with Thomas view on this - not so much that promoting them is
> > pointless, but I'd actually view it as harmful in encouraging use that will
> > be broken in future.
> >
>
> To be clear (again).
>
> I don't think we should promote functions needlessly, as I said, if others decide it is pointless, I won't argue.
> I do think if we have a policy, that experimental symbols will mature or be removed, we should be careful about the exceptions we make, lest the policy becomes irrelevant and ignored.
>
> Since we have argued this out, endlessly ... we can agree, we have been careful about this exception and move on?
The patch is set as rejected.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] pipeline: remove experimental tag from API
2021-10-13 11:11 0% ` Bruce Richardson
@ 2021-10-13 11:42 0% ` Kinsella, Ray
2021-10-13 11:58 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Kinsella, Ray @ 2021-10-13 11:42 UTC (permalink / raw)
To: Bruce Richardson
Cc: Thomas Monjalon, Dumitrescu, Cristian, dev, Zhang, Roy Fan,
Singh, Jasvinder, david.marchand
On 13/10/2021 12:11, Bruce Richardson wrote:
> On Wed, Oct 13, 2021 at 11:02:02AM +0100, Kinsella, Ray wrote:
>>
>>
>> On 13/10/2021 10:49, Thomas Monjalon wrote:
>>> 13/10/2021 11:43, Kinsella, Ray:
>>>> On 13/10/2021 10:40, Thomas Monjalon wrote:
>>>>> 13/10/2021 10:51, Kinsella, Ray:
>>>>>> On 12/10/2021 22:52, Thomas Monjalon wrote:
>>>>>>> 12/10/2021 22:34, Dumitrescu, Cristian:
>>>>>>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>>>>>>> 01/09/2021 14:20, Jasvinder Singh:
>>>>>>>>>> These APIs were introduced in 18.05, therefore removing
>>>>>>>>>> experimental tag to promote them to stable state.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
>>>>>>>>>> ---
>>>>>>>>>> lib/pipeline/rte_port_in_action.h | 10 ----------
>>>>>>>>>> lib/pipeline/rte_table_action.h | 18 ------------------
>>>>>>>>>> lib/pipeline/version.map | 16 ++++++----------
>>>>>>>>>> 3 files changed, 6 insertions(+), 38 deletions(-)
>>>>>>>>>
>>>>>>>>> Cristian, please can you check whether you intend to keep these functions in
>>>>>>>>> future?
>>>>>>>>> If they are candidate to be removed, there is no point to promote them.
>>>>>>>>
>>>>>>>> Hi Thomas,
>>>>>>>>
>>>>>>>> Yes, they are candidate for removal, as the new rte_swx_pipeline API evolves.
>>>>>>>>
>>>>>>>> But removing them requires updating the drivers/net/softnic code to use the new API, which is not going to be completed in time for release 21.11.
>>>>>>>>
>>>>>>>> So given this lag, it might be better to simply promote these functions to stable API now, as Ray suggests, instead of continuing to keep them experimental; then, once these functions are no longer used, then we can remove them, most likely in 22.11.
>>>>>>>>
>>>>>>>> So I will ack these patches, but I am willing to reconsider if you feel strongly against this approach.
>>>>>>>
>>>>>>> I think we should not promote API that we know will disappear soon.
>>>>>>> The stable status means something for the users.
>>>>>>> Ray, what is your opinion?
>>>>>>>
>>>>>>
>>>>>> Well - I agree with Cristian (he and I discuss this a few weeks ago).
>>>>>> My position is if you are going to maintain an API, that means giving a few guarantees.
>>>>>> The API's have been experimental for 3 years ... at what point do they mature?
>>>>>>
>>>>>> However, I agree there is two ways to look at this thing, I try to be pragmatic.
>>>>>> Maturing of any ABI/API is a conversation between a maintainer and the contributor.
>>>>>> If they strongly feel, it is a pointless exercise - I won't argue.
>>>>>
>>>>> I think you did't get it.
>>>>> This API will be removed soon.
>>>>> That's why I think it doesn't make sense to make them stable, just before removing.
>>>>>
>>>>
>>>> Nope, I got it 110%
>>>> I reflected both my opinion as ABI Maintainer, and tried to be pragmatic about the situation.
>>>>
>>>> As I said "Maturing of any ABI/API is a conversation between a maintainer and the contributor.
>>>> If they strongly feel, it is a pointless exercise - I won't argue."
>>>
>>> Sorry, I don't understand your position.
>>> Do you think we should promote functions to stable which are candidate to be removed soon?
>>>
>>
>> I am just reflecting the policy here.
>>
>> "An API’s experimental status should be reviewed annually, by both the maintainer and/or the original contributor. Ordinarily APIs marked as experimental will be promoted to the stable ABI once a maintainer has become satisfied that the API is mature and is unlikely to change."
>>
> If an API is planned for removal, then I think it falls under the bucket of
> "likely to change", so should not be made non-experimental. Therefore I'd
> agree with Thomas view on this - not so much that promoting them is
> pointless, but I'd actually view it as harmful in encouraging use that will
> be broken in future.
>
To be clear (again).
I don't think we should promote functions needlessly, as I said, if others decide it is pointless, I won't argue.
I do think if we have a policy, that experimental symbols will mature or be removed, we should be careful about the exceptions we make, lest the policy becomes irrelevant and ignored.
Since we have argued this out, endlessly ... we can agree, we have been careful about this exception and move on?
Ray K
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v1 1/1] ci: enable DPDK GHA for arm64 with self-hosted runners
2021-10-13 8:03 7% ` [dpdk-dev] [PATCH v1 1/1] " Serena He
@ 2021-10-13 11:32 0% ` Michael Santana
2021-10-14 7:04 0% ` Serena He
0 siblings, 1 reply; 200+ results
From: Michael Santana @ 2021-10-13 11:32 UTC (permalink / raw)
To: Serena He, aconole, maicolgabriel, david.marchand, thomas
Cc: dev, nd, honnappa.nagarahalli, ruifeng.wang, Dean.Arnold, stable
On 10/13/21 4:03 AM, Serena He wrote:
> CI jobs are triggered only for repos installed with given GHApp and runners
>
> Cc: stable@dpdk.org
>
> Signed-off-by: Serena He <serena.he@arm.com>
>
> ---
> .github/workflows/build-arm64.yml | 118 ++++++++++++++++++++++++++++++
> 1 file changed, 118 insertions(+)
> create mode 100644 .github/workflows/build-arm64.yml
>
> diff --git a/.github/workflows/build-arm64.yml b/.github/workflows/build-arm64.yml
> new file mode 100644
> index 0000000000..570563f7c8
> --- /dev/null
> +++ b/.github/workflows/build-arm64.yml
Adding a new workflow should work on our 0-day-bot. We now support
having multiple workflows so this looks good
> @@ -0,0 +1,118 @@
> +name: build-arm64
> +
> +on:
> + push:
> + schedule:
> + - cron: '0 0 * * 1'
nit: Please add a comment for when this is scheduled so we dont have to
do cron math :)
> +
> +defaults:
> + run:
> + shell: bash --noprofile --norc -exo pipefail {0}
> +
> +jobs:
> + build:
> + # Here, runners for arm64 are accessed by installed GitHub APP, thus will not be available by fork.
> + # you can change the following 'if' and 'runs-on' if you have your own runners installed.
> + # or request to get your repo on the whitelist to use GitHub APP and delete this 'if'.
I think I understand. I think you mean s/GitHub APP/GitHub/ . otherwise
I dont know what that is. From my understanding you had to request
special arm-based runners from github
Are DPDK/dpdk and ovsrobot/dpdk whitelisted to use the arm-based runners?
Maybe there was a thread about this in the past that I missed, but where
and how do you get these arm-based runners from github?
> + if: ${{ github.repository == 'DPDK/dpdk' || github.repository == 'ovsrobot/dpdk' }}
> + name: ${{ join(matrix.config.*, '-') }}
> + runs-on: ${{ matrix.config.os }}
> + env:
> + ABI_CHECKS: ${{ contains(matrix.config.checks, 'abi') }}
> + BUILD_DOCS: ${{ contains(matrix.config.checks, 'doc') }}
> + CL: ${{ matrix.config.compiler == 'clang' }}
> + CC: ccache ${{ matrix.config.compiler }}
> + DEF_LIB: ${{ matrix.config.library }}
> + LIBABIGAIL_VERSION: libabigail-1.8
> + REF_GIT_TAG: none
> +
> + strategy:
> + fail-fast: false
> + matrix:
> + config:
> + - os: [self-hosted,arm-ubuntu-20.04]
> + compiler: gcc
> + library: static
> + - os: [self-hosted,arm-ubuntu-20.04]
> + compiler: gcc
> + library: shared
> + checks: doc+tests
> + - os: [self-hosted,arm-ubuntu-20.04]
> + compiler: clang
> + library: static
> + - os: [self-hosted,arm-ubuntu-20.04]
> + compiler: clang
> + library: shared
> + checks: doc+tests
> +
> + steps:
> + - name: Checkout sources
> + uses: actions/checkout@v2
> + - name: Generate cache keys
> + id: get_ref_keys
> + run: |
> + echo -n '::set-output name=ccache::'
> + echo 'ccache-${{ matrix.config.os }}-${{ matrix.config.compiler }}-${{ matrix.config.cross }}-'$(date -u +%Y-w%W)
> + echo -n '::set-output name=libabigail::'
> + echo 'libabigail-${{ matrix.config.os }}'
> + echo -n '::set-output name=abi::'
> + echo 'abi-${{ matrix.config.os }}-${{ matrix.config.compiler }}-${{ matrix.config.cross }}-${{ env.LIBABIGAIL_VERSION }}-${{ env.REF_GIT_TAG }}'
> + - name: Retrieve ccache cache
> + uses: actions/cache@v2
> + with:
> + path: ~/.ccache
> + key: ${{ steps.get_ref_keys.outputs.ccache }}-${{ github.ref }}
> + restore-keys: |
> + ${{ steps.get_ref_keys.outputs.ccache }}-refs/heads/main
> + - name: Retrieve libabigail cache
> + id: libabigail-cache
> + uses: actions/cache@v2
> + if: env.ABI_CHECKS == 'true'
> + with:
> + path: libabigail
> + key: ${{ steps.get_ref_keys.outputs.libabigail }}
> + - name: Retrieve ABI reference cache
> + uses: actions/cache@v2
> + if: env.ABI_CHECKS == 'true'
> + with:
> + path: reference
> + key: ${{ steps.get_ref_keys.outputs.abi }}
> + - name: Update APT cache
> + run: sudo apt update || true
> + - name: Install packages
> + run: sudo apt install -y ccache libnuma-dev python3-setuptools
> + python3-wheel python3-pip python3-pyelftools ninja-build libbsd-dev
> + libpcap-dev libibverbs-dev libcrypto++-dev libfdt-dev libjansson-dev
> + libarchive-dev zlib1g-dev pkgconf
> + - name: Install libabigail build dependencies if no cache is available
> + if: env.ABI_CHECKS == 'true' && steps.libabigail-cache.outputs.cache-hit != 'true'
> + run: sudo apt install -y autoconf automake libtool pkg-config libxml2-dev
> + libdw-dev
Lots of caching stuff. All of it needed?
> +
> + - name: Install test tools packages
> + run: sudo apt install -y gdb
> + - name: Install doc generation packages
> + if: env.BUILD_DOCS == 'true'
> + run: sudo apt install -y doxygen graphviz python3-sphinx
> + python3-sphinx-rtd-theme
> + - name: Run setup
> + run: |
> + .ci/linux-setup.sh
> + # Workaround on $HOME permissions as EAL checks them for plugin loading
> + chmod o-w $HOME
> + - name: Install clang
> + if: env.CL == 'true'
> + run: sudo apt install -y clang
> + - name: Build and test
> + run: .ci/linux-build.sh
> + - name: Upload logs on failure
> + if: failure()
> + uses: actions/upload-artifact@v2
> + with:
> + name: meson-logs-${{ join(matrix.config.*, '-') }}
> + path: |
> + build/meson-logs/testlog.txt
> + build/.ninja_log
> + build/meson-logs/meson-log.txt
> + build/gdb.log
LGTM!
> +
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] mempool: fix name size in mempool structure
2021-10-13 11:07 4% ` David Marchand
@ 2021-10-13 11:14 0% ` Andrew Rybchenko
2021-10-13 17:30 0% ` Honnappa Nagarahalli
2021-10-13 20:58 0% ` Thomas Monjalon
1 sibling, 1 reply; 200+ results
From: Andrew Rybchenko @ 2021-10-13 11:14 UTC (permalink / raw)
To: David Marchand
Cc: Olivier Matz, Zoltan Kiss, dev, Ray Kinsella, Thomas Monjalon,
Konstantin Ananyev, Honnappa Nagarahalli
On 10/13/21 2:07 PM, David Marchand wrote:
> On Wed, Oct 13, 2021 at 10:57 AM Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru> wrote:
>>
>> Use correct define as a name array size.
>>
>> The change breaks ABI and therefore cannot be backported to
>> stable branches.
>>
>> Fixes: 38c9817ee1d8 ("mempool: adjust name size in related data types")
>>
>> Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>
> Reviewed-by: David Marchand <david.marchand@redhat.com>
>
> Good catch, I guess we can clean ring too, quick grep:
>
> lib/ring/rte_ring_core.h-struct rte_ring {
> lib/ring/rte_ring_core.h- /*
> lib/ring/rte_ring_core.h: * Note: this field kept the
> RTE_MEMZONE_NAMESIZE size due to ABI
> lib/ring/rte_ring_core.h- * compatibility requirements, it
> could be changed to RTE_RING_NAMESIZE
> lib/ring/rte_ring_core.h: * next time the ABI changes
> lib/ring/rte_ring_core.h- */
> lib/ring/rte_ring_core.h- char name[RTE_MEMZONE_NAMESIZE]
> __rte_cache_aligned;
>
>
Yes. I've not bothered to grep... Cc maintainers.
@David, @Konstantin, or @Honnappa, will you send a patch or
should I do?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] pipeline: remove experimental tag from API
2021-10-13 10:02 4% ` Kinsella, Ray
@ 2021-10-13 11:11 0% ` Bruce Richardson
2021-10-13 11:42 0% ` Kinsella, Ray
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2021-10-13 11:11 UTC (permalink / raw)
To: Kinsella, Ray
Cc: Thomas Monjalon, Dumitrescu, Cristian, dev, Zhang, Roy Fan,
Singh, Jasvinder, david.marchand
On Wed, Oct 13, 2021 at 11:02:02AM +0100, Kinsella, Ray wrote:
>
>
> On 13/10/2021 10:49, Thomas Monjalon wrote:
> > 13/10/2021 11:43, Kinsella, Ray:
> >> On 13/10/2021 10:40, Thomas Monjalon wrote:
> >>> 13/10/2021 10:51, Kinsella, Ray:
> >>>> On 12/10/2021 22:52, Thomas Monjalon wrote:
> >>>>> 12/10/2021 22:34, Dumitrescu, Cristian:
> >>>>>> From: Thomas Monjalon <thomas@monjalon.net>
> >>>>>>> 01/09/2021 14:20, Jasvinder Singh:
> >>>>>>>> These APIs were introduced in 18.05, therefore removing
> >>>>>>>> experimental tag to promote them to stable state.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
> >>>>>>>> ---
> >>>>>>>> lib/pipeline/rte_port_in_action.h | 10 ----------
> >>>>>>>> lib/pipeline/rte_table_action.h | 18 ------------------
> >>>>>>>> lib/pipeline/version.map | 16 ++++++----------
> >>>>>>>> 3 files changed, 6 insertions(+), 38 deletions(-)
> >>>>>>>
> >>>>>>> Cristian, please can you check whether you intend to keep these functions in
> >>>>>>> future?
> >>>>>>> If they are candidate to be removed, there is no point to promote them.
> >>>>>>
> >>>>>> Hi Thomas,
> >>>>>>
> >>>>>> Yes, they are candidate for removal, as the new rte_swx_pipeline API evolves.
> >>>>>>
> >>>>>> But removing them requires updating the drivers/net/softnic code to use the new API, which is not going to be completed in time for release 21.11.
> >>>>>>
> >>>>>> So given this lag, it might be better to simply promote these functions to stable API now, as Ray suggests, instead of continuing to keep them experimental; then, once these functions are no longer used, then we can remove them, most likely in 22.11.
> >>>>>>
> >>>>>> So I will ack these patches, but I am willing to reconsider if you feel strongly against this approach.
> >>>>>
> >>>>> I think we should not promote API that we know will disappear soon.
> >>>>> The stable status means something for the users.
> >>>>> Ray, what is your opinion?
> >>>>>
> >>>>
> >>>> Well - I agree with Cristian (he and I discuss this a few weeks ago).
> >>>> My position is if you are going to maintain an API, that means giving a few guarantees.
> >>>> The API's have been experimental for 3 years ... at what point do they mature?
> >>>>
> >>>> However, I agree there is two ways to look at this thing, I try to be pragmatic.
> >>>> Maturing of any ABI/API is a conversation between a maintainer and the contributor.
> >>>> If they strongly feel, it is a pointless exercise - I won't argue.
> >>>
> >>> I think you did't get it.
> >>> This API will be removed soon.
> >>> That's why I think it doesn't make sense to make them stable, just before removing.
> >>>
> >>
> >> Nope, I got it 110%
> >> I reflected both my opinion as ABI Maintainer, and tried to be pragmatic about the situation.
> >>
> >> As I said "Maturing of any ABI/API is a conversation between a maintainer and the contributor.
> >> If they strongly feel, it is a pointless exercise - I won't argue."
> >
> > Sorry, I don't understand your position.
> > Do you think we should promote functions to stable which are candidate to be removed soon?
> >
>
> I am just reflecting the policy here.
>
> "An API’s experimental status should be reviewed annually, by both the maintainer and/or the original contributor. Ordinarily APIs marked as experimental will be promoted to the stable ABI once a maintainer has become satisfied that the API is mature and is unlikely to change."
>
If an API is planned for removal, then I think it falls under the bucket of
"likely to change", so should not be made non-experimental. Therefore I'd
agree with Thomas view on this - not so much that promoting them is
pointless, but I'd actually view it as harmful in encouraging use that will
be broken in future.
/Bruce
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] mempool: fix name size in mempool structure
2021-10-13 8:57 11% [dpdk-dev] [PATCH] mempool: fix name size in mempool structure Andrew Rybchenko
@ 2021-10-13 11:07 4% ` David Marchand
2021-10-13 11:14 0% ` Andrew Rybchenko
2021-10-13 20:58 0% ` Thomas Monjalon
0 siblings, 2 replies; 200+ results
From: David Marchand @ 2021-10-13 11:07 UTC (permalink / raw)
To: Andrew Rybchenko
Cc: Olivier Matz, Zoltan Kiss, dev, Ray Kinsella, Thomas Monjalon
On Wed, Oct 13, 2021 at 10:57 AM Andrew Rybchenko
<andrew.rybchenko@oktetlabs.ru> wrote:
>
> Use correct define as a name array size.
>
> The change breaks ABI and therefore cannot be backported to
> stable branches.
>
> Fixes: 38c9817ee1d8 ("mempool: adjust name size in related data types")
>
> Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Reviewed-by: David Marchand <david.marchand@redhat.com>
Good catch, I guess we can clean ring too, quick grep:
lib/ring/rte_ring_core.h-struct rte_ring {
lib/ring/rte_ring_core.h- /*
lib/ring/rte_ring_core.h: * Note: this field kept the
RTE_MEMZONE_NAMESIZE size due to ABI
lib/ring/rte_ring_core.h- * compatibility requirements, it
could be changed to RTE_RING_NAMESIZE
lib/ring/rte_ring_core.h: * next time the ABI changes
lib/ring/rte_ring_core.h- */
lib/ring/rte_ring_core.h- char name[RTE_MEMZONE_NAMESIZE]
__rte_cache_aligned;
--
David Marchand
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v4 2/4] mempool: add non-IO flag
@ 2021-10-13 11:01 4% ` Dmitry Kozlyuk
2021-10-15 9:01 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Dmitry Kozlyuk @ 2021-10-13 11:01 UTC (permalink / raw)
To: dev; +Cc: Andrew Rybchenko, Matan Azrad, Olivier Matz
Mempool is a generic allocator that is not necessarily used for device
IO operations and its memory for DMA. Add MEMPOOL_F_NON_IO flag to mark
such mempools automatically if their objects are not contiguous
or IOVA are not available. Components can inspect this flag
in order to optimize their memory management.
Discussion: https://mails.dpdk.org/archives/dev/2021-August/216654.html
Signed-off-by: Dmitry Kozlyuk <dkozlyuk@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
---
app/test/test_mempool.c | 76 ++++++++++++++++++++++++++
doc/guides/rel_notes/release_21_11.rst | 3 +
lib/mempool/rte_mempool.c | 2 +
lib/mempool/rte_mempool.h | 5 ++
4 files changed, 86 insertions(+)
diff --git a/app/test/test_mempool.c b/app/test/test_mempool.c
index bc0cc9ed48..15146dd737 100644
--- a/app/test/test_mempool.c
+++ b/app/test/test_mempool.c
@@ -672,6 +672,74 @@ test_mempool_events_safety(void)
return 0;
}
+static int
+test_mempool_flag_non_io_set_when_no_iova_contig_set(void)
+{
+ struct rte_mempool *mp;
+ int ret;
+
+ mp = rte_mempool_create_empty("empty", MEMPOOL_SIZE,
+ MEMPOOL_ELT_SIZE, 0, 0,
+ SOCKET_ID_ANY, MEMPOOL_F_NO_IOVA_CONTIG);
+ RTE_TEST_ASSERT_NOT_NULL(mp, "Cannot create mempool: %s",
+ rte_strerror(rte_errno));
+ rte_mempool_set_ops_byname(mp, rte_mbuf_best_mempool_ops(), NULL);
+ ret = rte_mempool_populate_default(mp);
+ RTE_TEST_ASSERT(ret > 0, "Failed to populate mempool: %s",
+ rte_strerror(rte_errno));
+ RTE_TEST_ASSERT(mp->flags & MEMPOOL_F_NON_IO,
+ "NON_IO flag is not set when NO_IOVA_CONTIG is set");
+ rte_mempool_free(mp);
+ return 0;
+}
+
+static int
+test_mempool_flag_non_io_set_when_populated_with_bad_iova(void)
+{
+ void *addr;
+ size_t size = 1 << 16;
+ struct rte_mempool *mp;
+ int ret;
+
+ addr = rte_malloc("test_mempool", size, 0);
+ RTE_TEST_ASSERT_NOT_NULL(addr, "Cannot allocate memory");
+ mp = rte_mempool_create_empty("empty", MEMPOOL_SIZE,
+ MEMPOOL_ELT_SIZE, 0, 0,
+ SOCKET_ID_ANY, 0);
+ RTE_TEST_ASSERT_NOT_NULL(mp, "Cannot create mempool: %s",
+ rte_strerror(rte_errno));
+ ret = rte_mempool_populate_iova(mp, addr, RTE_BAD_IOVA, size,
+ NULL, NULL);
+ /* The flag must be inferred even if population isn't full. */
+ RTE_TEST_ASSERT(ret > 0, "Failed to populate mempool: %s",
+ rte_strerror(rte_errno));
+ RTE_TEST_ASSERT(mp->flags & MEMPOOL_F_NON_IO,
+ "NON_IO flag is not set when mempool is populated with RTE_BAD_IOVA");
+ rte_mempool_free(mp);
+ rte_free(addr);
+ return 0;
+}
+
+static int
+test_mempool_flag_non_io_unset_by_default(void)
+{
+ struct rte_mempool *mp;
+ int ret;
+
+ mp = rte_mempool_create_empty("empty", MEMPOOL_SIZE,
+ MEMPOOL_ELT_SIZE, 0, 0,
+ SOCKET_ID_ANY, 0);
+ RTE_TEST_ASSERT_NOT_NULL(mp, "Cannot create mempool: %s",
+ rte_strerror(rte_errno));
+ ret = rte_mempool_populate_default(mp);
+ RTE_TEST_ASSERT_EQUAL(ret, (int)mp->size, "Failed to populate mempool: %s",
+ rte_strerror(rte_errno));
+ RTE_TEST_ASSERT(!(mp->flags & MEMPOOL_F_NON_IO),
+ "NON_IO flag is set by default");
+ rte_mempool_free(mp);
+ return 0;
+}
+
static int
test_mempool(void)
{
@@ -854,6 +922,14 @@ test_mempool(void)
if (test_mempool_events_safety() < 0)
GOTO_ERR(ret, err);
+ /* test NON_IO flag inference */
+ if (test_mempool_flag_non_io_unset_by_default() < 0)
+ GOTO_ERR(ret, err);
+ if (test_mempool_flag_non_io_set_when_no_iova_contig_set() < 0)
+ GOTO_ERR(ret, err);
+ if (test_mempool_flag_non_io_set_when_populated_with_bad_iova() < 0)
+ GOTO_ERR(ret, err);
+
rte_mempool_list_dump(stdout);
ret = 0;
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index f643a61f44..74e0e6f495 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -226,6 +226,9 @@ API Changes
the crypto/security operation. This field will be used to communicate
events such as soft expiry with IPsec in lookaside mode.
+* mempool: Added ``MEMPOOL_F_NON_IO`` flag to give a hint to DPDK components
+ that objects from this pool will not be used for device IO (e.g. DMA).
+
ABI Changes
-----------
diff --git a/lib/mempool/rte_mempool.c b/lib/mempool/rte_mempool.c
index 51c0ba2931..2204f140b3 100644
--- a/lib/mempool/rte_mempool.c
+++ b/lib/mempool/rte_mempool.c
@@ -371,6 +371,8 @@ rte_mempool_populate_iova(struct rte_mempool *mp, char *vaddr,
STAILQ_INSERT_TAIL(&mp->mem_list, memhdr, next);
mp->nb_mem_chunks++;
+ if (iova == RTE_BAD_IOVA)
+ mp->flags |= MEMPOOL_F_NON_IO;
/* Report the mempool as ready only when fully populated. */
if (mp->populated_size >= mp->size)
diff --git a/lib/mempool/rte_mempool.h b/lib/mempool/rte_mempool.h
index 663123042f..029b62a650 100644
--- a/lib/mempool/rte_mempool.h
+++ b/lib/mempool/rte_mempool.h
@@ -262,6 +262,8 @@ struct rte_mempool {
#define MEMPOOL_F_SC_GET 0x0008 /**< Default get is "single-consumer".*/
#define MEMPOOL_F_POOL_CREATED 0x0010 /**< Internal: pool is created. */
#define MEMPOOL_F_NO_IOVA_CONTIG 0x0020 /**< Don't need IOVA contiguous objs. */
+#define MEMPOOL_F_NON_IO 0x0040
+ /**< Internal: pool is not usable for device IO (DMA). */
/**
* @internal When debug is enabled, store some statistics.
@@ -991,6 +993,9 @@ typedef void (rte_mempool_ctor_t)(struct rte_mempool *, void *);
* "single-consumer". Otherwise, it is "multi-consumers".
* - MEMPOOL_F_NO_IOVA_CONTIG: If set, allocated objects won't
* necessarily be contiguous in IO memory.
+ * - MEMPOOL_F_NON_IO: If set, the mempool is considered to be
+ * never used for device IO, i.e. for DMA operations.
+ * It's a hint to other components and does not affect the mempool behavior.
* @return
* The pointer to the new allocated mempool, on success. NULL on error
* with rte_errno set appropriately. Possible rte_errno values include:
--
2.25.1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] pipeline: remove experimental tag from API
2021-10-13 9:49 0% ` Thomas Monjalon
@ 2021-10-13 10:02 4% ` Kinsella, Ray
2021-10-13 11:11 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Kinsella, Ray @ 2021-10-13 10:02 UTC (permalink / raw)
To: Thomas Monjalon, Dumitrescu, Cristian
Cc: dev, Zhang, Roy Fan, Singh, Jasvinder, david.marchand
On 13/10/2021 10:49, Thomas Monjalon wrote:
> 13/10/2021 11:43, Kinsella, Ray:
>> On 13/10/2021 10:40, Thomas Monjalon wrote:
>>> 13/10/2021 10:51, Kinsella, Ray:
>>>> On 12/10/2021 22:52, Thomas Monjalon wrote:
>>>>> 12/10/2021 22:34, Dumitrescu, Cristian:
>>>>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>>>>> 01/09/2021 14:20, Jasvinder Singh:
>>>>>>>> These APIs were introduced in 18.05, therefore removing
>>>>>>>> experimental tag to promote them to stable state.
>>>>>>>>
>>>>>>>> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
>>>>>>>> ---
>>>>>>>> lib/pipeline/rte_port_in_action.h | 10 ----------
>>>>>>>> lib/pipeline/rte_table_action.h | 18 ------------------
>>>>>>>> lib/pipeline/version.map | 16 ++++++----------
>>>>>>>> 3 files changed, 6 insertions(+), 38 deletions(-)
>>>>>>>
>>>>>>> Cristian, please can you check whether you intend to keep these functions in
>>>>>>> future?
>>>>>>> If they are candidate to be removed, there is no point to promote them.
>>>>>>
>>>>>> Hi Thomas,
>>>>>>
>>>>>> Yes, they are candidate for removal, as the new rte_swx_pipeline API evolves.
>>>>>>
>>>>>> But removing them requires updating the drivers/net/softnic code to use the new API, which is not going to be completed in time for release 21.11.
>>>>>>
>>>>>> So given this lag, it might be better to simply promote these functions to stable API now, as Ray suggests, instead of continuing to keep them experimental; then, once these functions are no longer used, then we can remove them, most likely in 22.11.
>>>>>>
>>>>>> So I will ack these patches, but I am willing to reconsider if you feel strongly against this approach.
>>>>>
>>>>> I think we should not promote API that we know will disappear soon.
>>>>> The stable status means something for the users.
>>>>> Ray, what is your opinion?
>>>>>
>>>>
>>>> Well - I agree with Cristian (he and I discuss this a few weeks ago).
>>>> My position is if you are going to maintain an API, that means giving a few guarantees.
>>>> The API's have been experimental for 3 years ... at what point do they mature?
>>>>
>>>> However, I agree there is two ways to look at this thing, I try to be pragmatic.
>>>> Maturing of any ABI/API is a conversation between a maintainer and the contributor.
>>>> If they strongly feel, it is a pointless exercise - I won't argue.
>>>
>>> I think you did't get it.
>>> This API will be removed soon.
>>> That's why I think it doesn't make sense to make them stable, just before removing.
>>>
>>
>> Nope, I got it 110%
>> I reflected both my opinion as ABI Maintainer, and tried to be pragmatic about the situation.
>>
>> As I said "Maturing of any ABI/API is a conversation between a maintainer and the contributor.
>> If they strongly feel, it is a pointless exercise - I won't argue."
>
> Sorry, I don't understand your position.
> Do you think we should promote functions to stable which are candidate to be removed soon?
>
I am just reflecting the policy here.
"An API’s experimental status should be reviewed annually, by both the maintainer and/or the original contributor. Ordinarily APIs marked as experimental will be promoted to the stable ABI once a maintainer has become satisfied that the API is mature and is unlikely to change."
then,
"The promotion or removal of symbols will typically form part of a conversation between the maintainer and the original contributor.".
As I said, in my email above ...
"Maturing of any ABI/API is a conversation between a maintainer and the contributor.
If they strongly feel, it is a pointless exercise [to make the symbols stable] - I won't argue.
Or to be _abundantly clear_ ...
I don't think we should promote functions needlessly, as I said, if others decide it is pointless, I won't argue.
I do think if we have a policy, that experimental symbols will mature or be removed, we should be careful about the exceptions we make, lest the policy becomes irrelevant and ignored.
Ray K
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] pipeline: remove experimental tag from API
2021-10-13 9:43 4% ` Kinsella, Ray
@ 2021-10-13 9:49 0% ` Thomas Monjalon
2021-10-13 10:02 4% ` Kinsella, Ray
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2021-10-13 9:49 UTC (permalink / raw)
To: Dumitrescu, Cristian, Kinsella, Ray
Cc: dev, Zhang, Roy Fan, Singh, Jasvinder, david.marchand
13/10/2021 11:43, Kinsella, Ray:
> On 13/10/2021 10:40, Thomas Monjalon wrote:
> > 13/10/2021 10:51, Kinsella, Ray:
> >> On 12/10/2021 22:52, Thomas Monjalon wrote:
> >>> 12/10/2021 22:34, Dumitrescu, Cristian:
> >>>> From: Thomas Monjalon <thomas@monjalon.net>
> >>>>> 01/09/2021 14:20, Jasvinder Singh:
> >>>>>> These APIs were introduced in 18.05, therefore removing
> >>>>>> experimental tag to promote them to stable state.
> >>>>>>
> >>>>>> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
> >>>>>> ---
> >>>>>> lib/pipeline/rte_port_in_action.h | 10 ----------
> >>>>>> lib/pipeline/rte_table_action.h | 18 ------------------
> >>>>>> lib/pipeline/version.map | 16 ++++++----------
> >>>>>> 3 files changed, 6 insertions(+), 38 deletions(-)
> >>>>>
> >>>>> Cristian, please can you check whether you intend to keep these functions in
> >>>>> future?
> >>>>> If they are candidate to be removed, there is no point to promote them.
> >>>>
> >>>> Hi Thomas,
> >>>>
> >>>> Yes, they are candidate for removal, as the new rte_swx_pipeline API evolves.
> >>>>
> >>>> But removing them requires updating the drivers/net/softnic code to use the new API, which is not going to be completed in time for release 21.11.
> >>>>
> >>>> So given this lag, it might be better to simply promote these functions to stable API now, as Ray suggests, instead of continuing to keep them experimental; then, once these functions are no longer used, then we can remove them, most likely in 22.11.
> >>>>
> >>>> So I will ack these patches, but I am willing to reconsider if you feel strongly against this approach.
> >>>
> >>> I think we should not promote API that we know will disappear soon.
> >>> The stable status means something for the users.
> >>> Ray, what is your opinion?
> >>>
> >>
> >> Well - I agree with Cristian (he and I discuss this a few weeks ago).
> >> My position is if you are going to maintain an API, that means giving a few guarantees.
> >> The API's have been experimental for 3 years ... at what point do they mature?
> >>
> >> However, I agree there is two ways to look at this thing, I try to be pragmatic.
> >> Maturing of any ABI/API is a conversation between a maintainer and the contributor.
> >> If they strongly feel, it is a pointless exercise - I won't argue.
> >
> > I think you did't get it.
> > This API will be removed soon.
> > That's why I think it doesn't make sense to make them stable, just before removing.
> >
>
> Nope, I got it 110%
> I reflected both my opinion as ABI Maintainer, and tried to be pragmatic about the situation.
>
> As I said "Maturing of any ABI/API is a conversation between a maintainer and the contributor.
> If they strongly feel, it is a pointless exercise - I won't argue."
Sorry, I don't understand your position.
Do you think we should promote functions to stable which are candidate to be removed soon?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] pipeline: remove experimental tag from API
2021-10-13 9:40 0% ` Thomas Monjalon
@ 2021-10-13 9:43 4% ` Kinsella, Ray
2021-10-13 9:49 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Kinsella, Ray @ 2021-10-13 9:43 UTC (permalink / raw)
To: Thomas Monjalon, Dumitrescu, Cristian
Cc: dev, Zhang, Roy Fan, Singh, Jasvinder, david.marchand
On 13/10/2021 10:40, Thomas Monjalon wrote:
> 13/10/2021 10:51, Kinsella, Ray:
>>
>> On 12/10/2021 22:52, Thomas Monjalon wrote:
>>> 12/10/2021 22:34, Dumitrescu, Cristian:
>>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>>> 01/09/2021 14:20, Jasvinder Singh:
>>>>>> These APIs were introduced in 18.05, therefore removing
>>>>>> experimental tag to promote them to stable state.
>>>>>>
>>>>>> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
>>>>>> ---
>>>>>> lib/pipeline/rte_port_in_action.h | 10 ----------
>>>>>> lib/pipeline/rte_table_action.h | 18 ------------------
>>>>>> lib/pipeline/version.map | 16 ++++++----------
>>>>>> 3 files changed, 6 insertions(+), 38 deletions(-)
>>>>>
>>>>> Cristian, please can you check whether you intend to keep these functions in
>>>>> future?
>>>>> If they are candidate to be removed, there is no point to promote them.
>>>>
>>>> Hi Thomas,
>>>>
>>>> Yes, they are candidate for removal, as the new rte_swx_pipeline API evolves.
>>>>
>>>> But removing them requires updating the drivers/net/softnic code to use the new API, which is not going to be completed in time for release 21.11.
>>>>
>>>> So given this lag, it might be better to simply promote these functions to stable API now, as Ray suggests, instead of continuing to keep them experimental; then, once these functions are no longer used, then we can remove them, most likely in 22.11.
>>>>
>>>> So I will ack these patches, but I am willing to reconsider if you feel strongly against this approach.
>>>
>>> I think we should not promote API that we know will disappear soon.
>>> The stable status means something for the users.
>>> Ray, what is your opinion?
>>>
>>
>> Well - I agree with Cristian (he and I discuss this a few weeks ago).
>> My position is if you are going to maintain an API, that means giving a few guarantees.
>> The API's have been experimental for 3 years ... at what point do they mature?
>>
>> However, I agree there is two ways to look at this thing, I try to be pragmatic.
>> Maturing of any ABI/API is a conversation between a maintainer and the contributor.
>> If they strongly feel, it is a pointless exercise - I won't argue.
>
> I think you did't get it.
> This API will be removed soon.
> That's why I think it doesn't make sense to make them stable, just before removing.
>
Nope, I got it 110%
I reflected both my opinion as ABI Maintainer, and tried to be pragmatic about the situation.
As I said "Maturing of any ABI/API is a conversation between a maintainer and the contributor.
If they strongly feel, it is a pointless exercise - I won't argue."
Ray K
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] pipeline: remove experimental tag from API
2021-10-13 8:51 3% ` Kinsella, Ray
@ 2021-10-13 9:40 0% ` Thomas Monjalon
2021-10-13 9:43 4% ` Kinsella, Ray
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2021-10-13 9:40 UTC (permalink / raw)
To: Dumitrescu, Cristian, Kinsella, Ray
Cc: dev, Zhang, Roy Fan, Singh, Jasvinder, david.marchand
13/10/2021 10:51, Kinsella, Ray:
>
> On 12/10/2021 22:52, Thomas Monjalon wrote:
> > 12/10/2021 22:34, Dumitrescu, Cristian:
> >> From: Thomas Monjalon <thomas@monjalon.net>
> >>> 01/09/2021 14:20, Jasvinder Singh:
> >>>> These APIs were introduced in 18.05, therefore removing
> >>>> experimental tag to promote them to stable state.
> >>>>
> >>>> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
> >>>> ---
> >>>> lib/pipeline/rte_port_in_action.h | 10 ----------
> >>>> lib/pipeline/rte_table_action.h | 18 ------------------
> >>>> lib/pipeline/version.map | 16 ++++++----------
> >>>> 3 files changed, 6 insertions(+), 38 deletions(-)
> >>>
> >>> Cristian, please can you check whether you intend to keep these functions in
> >>> future?
> >>> If they are candidate to be removed, there is no point to promote them.
> >>
> >> Hi Thomas,
> >>
> >> Yes, they are candidate for removal, as the new rte_swx_pipeline API evolves.
> >>
> >> But removing them requires updating the drivers/net/softnic code to use the new API, which is not going to be completed in time for release 21.11.
> >>
> >> So given this lag, it might be better to simply promote these functions to stable API now, as Ray suggests, instead of continuing to keep them experimental; then, once these functions are no longer used, then we can remove them, most likely in 22.11.
> >>
> >> So I will ack these patches, but I am willing to reconsider if you feel strongly against this approach.
> >
> > I think we should not promote API that we know will disappear soon.
> > The stable status means something for the users.
> > Ray, what is your opinion?
> >
>
> Well - I agree with Cristian (he and I discuss this a few weeks ago).
> My position is if you are going to maintain an API, that means giving a few guarantees.
> The API's have been experimental for 3 years ... at what point do they mature?
>
> However, I agree there is two ways to look at this thing, I try to be pragmatic.
> Maturing of any ABI/API is a conversation between a maintainer and the contributor.
> If they strongly feel, it is a pointless exercise - I won't argue.
I think you did't get it.
This API will be removed soon.
That's why I think it doesn't make sense to make them stable, just before removing.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH] mempool: fix name size in mempool structure
@ 2021-10-13 8:57 11% Andrew Rybchenko
2021-10-13 11:07 4% ` David Marchand
0 siblings, 1 reply; 200+ results
From: Andrew Rybchenko @ 2021-10-13 8:57 UTC (permalink / raw)
To: Olivier Matz, Zoltan Kiss; +Cc: dev
Use correct define as a name array size.
The change breaks ABI and therefore cannot be backported to
stable branches.
Fixes: 38c9817ee1d8 ("mempool: adjust name size in related data types")
Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
lib/mempool/rte_mempool.h | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/lib/mempool/rte_mempool.h b/lib/mempool/rte_mempool.h
index f57ecbd6fc..04b14d7ae9 100644
--- a/lib/mempool/rte_mempool.h
+++ b/lib/mempool/rte_mempool.h
@@ -209,12 +209,7 @@ struct rte_mempool_info {
* The RTE mempool structure.
*/
struct rte_mempool {
- /*
- * Note: this field kept the RTE_MEMZONE_NAMESIZE size due to ABI
- * compatibility requirements, it could be changed to
- * RTE_MEMPOOL_NAMESIZE next time the ABI changes
- */
- char name[RTE_MEMZONE_NAMESIZE]; /**< Name of mempool. */
+ char name[RTE_MEMPOOL_NAMESIZE]; /**< Name of mempool. */
RTE_STD_C11
union {
void *pool_data; /**< Ring or pool to store objects. */
--
2.30.2
^ permalink raw reply [relevance 11%]
* Re: [dpdk-dev] [PATCH] pipeline: remove experimental tag from API
@ 2021-10-13 8:51 3% ` Kinsella, Ray
2021-10-13 9:40 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Kinsella, Ray @ 2021-10-13 8:51 UTC (permalink / raw)
To: Thomas Monjalon, Dumitrescu, Cristian
Cc: dev, Zhang, Roy Fan, Singh, Jasvinder, david.marchand
On 12/10/2021 22:52, Thomas Monjalon wrote:
> 12/10/2021 22:34, Dumitrescu, Cristian:
>> From: Thomas Monjalon <thomas@monjalon.net>
>>> 01/09/2021 14:20, Jasvinder Singh:
>>>> These APIs were introduced in 18.05, therefore removing
>>>> experimental tag to promote them to stable state.
>>>>
>>>> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
>>>> ---
>>>> lib/pipeline/rte_port_in_action.h | 10 ----------
>>>> lib/pipeline/rte_table_action.h | 18 ------------------
>>>> lib/pipeline/version.map | 16 ++++++----------
>>>> 3 files changed, 6 insertions(+), 38 deletions(-)
>>>
>>> Cristian, please can you check whether you intend to keep these functions in
>>> future?
>>> If they are candidate to be removed, there is no point to promote them.
>>
>> Hi Thomas,
>>
>> Yes, they are candidate for removal, as the new rte_swx_pipeline API evolves.
>>
>> But removing them requires updating the drivers/net/softnic code to use the new API, which is not going to be completed in time for release 21.11.
>>
>> So given this lag, it might be better to simply promote these functions to stable API now, as Ray suggests, instead of continuing to keep them experimental; then, once these functions are no longer used, then we can remove them, most likely in 22.11.
>>
>> So I will ack these patches, but I am willing to reconsider if you feel strongly against this approach.
>
> I think we should not promote API that we know will disappear soon.
> The stable status means something for the users.
> Ray, what is your opinion?
>
Well - I agree with Cristian (he and I discuss this a few weeks ago).
My position is if you are going to maintain an API, that means giving a few guarantees.
The API's have been experimental for 3 years ... at what point do they mature?
However, I agree there is two ways to look at this thing, I try to be pragmatic.
Maturing of any ABI/API is a conversation between a maintainer and the contributor.
If they strongly feel, it is a pointless exercise - I won't argue.
Ray K
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v12 00/12] Packet capture framework update
2021-10-12 18:22 0% ` Thomas Monjalon
@ 2021-10-13 8:44 0% ` Pattan, Reshma
0 siblings, 0 replies; 200+ results
From: Pattan, Reshma @ 2021-10-13 8:44 UTC (permalink / raw)
To: Thomas Monjalon, Stephen Hemminger; +Cc: dev, Richardson, Bruce, david.marchand
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> > Thought they were, look like Reshma got missed.
> >
> > No worries about doing in 22.02 since there is no API/ABI breakage in
> > the patchset. No pre-release note needed either.
>
> We can still merge it for 21.11 if Reshma is OK with the v12.
>
FYI, I have reviewed and acked the below pdump library patch.
[v12,06/12] pdump: support pcapng and filtering
There are some other patches , mainly new library librte_pcapng which needs a review and an Ack, can someone join to review and provide an Ack?
I will also take a look.
Thanks,
Reshma
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [EXT] Re: [PATCH v2 1/3] cryptodev: remove LIST_END enumerators
2021-10-13 7:04 0% ` Anoob Joseph
@ 2021-10-13 8:39 3% ` Kinsella, Ray
0 siblings, 0 replies; 200+ results
From: Kinsella, Ray @ 2021-10-13 8:39 UTC (permalink / raw)
To: Anoob Joseph, Thomas Monjalon, Akhil Goyal, dev
Cc: david.marchand, hemant.agrawal, pablo.de.lara.guarch,
fiona.trahe, declan.doherty, matan, g.singh, roy.fan.zhang,
jianjay.zhou, asomalap, ruifeng.wang, konstantin.ananyev,
radu.nicolau, ajit.khaparde, Nagadheeraj Rottela, Ankur Dwivedi,
ciara.power, Stephen Hemminger, Yigit, Ferruh, bruce.richardson
On 13/10/2021 08:04, Anoob Joseph wrote:
> Hi Akhil, Ray, Thomas,
>
> Please see inline.
>
> Thanks,
> Anoob
>
>> -----Original Message-----
>> From: Thomas Monjalon <thomas@monjalon.net>
>> Sent: Wednesday, October 13, 2021 12:32 PM
>> To: Akhil Goyal <gakhil@marvell.com>; dev@dpdk.org; Kinsella, Ray
>> <mdr@ashroe.eu>; Anoob Joseph <anoobj@marvell.com>
>> Cc: david.marchand@redhat.com; hemant.agrawal@nxp.com;
>> pablo.de.lara.guarch@intel.com; fiona.trahe@intel.com;
>> declan.doherty@intel.com; matan@nvidia.com; g.singh@nxp.com;
>> roy.fan.zhang@intel.com; jianjay.zhou@huawei.com; asomalap@amd.com;
>> ruifeng.wang@arm.com; konstantin.ananyev@intel.com;
>> radu.nicolau@intel.com; ajit.khaparde@broadcom.com; Nagadheeraj
>> Rottela <rnagadheeraj@marvell.com>; Ankur Dwivedi
>> <adwivedi@marvell.com>; ciara.power@intel.com; Stephen Hemminger
>> <stephen@networkplumber.org>; Yigit, Ferruh <ferruh.yigit@intel.com>;
>> bruce.richardson@intel.com
>> Subject: Re: [EXT] Re: [dpdk-dev] [PATCH v2 1/3] cryptodev: remove
>> LIST_END enumerators
>>
>> 13/10/2021 07:36, Anoob Joseph:
>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>> 12/10/2021 16:47, Kinsella, Ray:
>>>>> On 12/10/2021 15:18, Anoob Joseph wrote:
>>>>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>>>>> 12/10/2021 15:38, Anoob Joseph:
>>>>>>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>>>>>>> 12/10/2021 13:34, Anoob Joseph:
>>>>>>>>>> From: Kinsella, Ray <mdr@ashroe.eu>
>>>>>>>>>>> On 12/10/2021 11:50, Anoob Joseph wrote:
>>>>>>>>>>>> From: Akhil Goyal <gakhil@marvell.com>
>>>>>>>>>>>>>> On 08/10/2021 21:45, Akhil Goyal wrote:
>>>>>>>>>>>>>>> Remove *_LIST_END enumerators from asymmetric
>> crypto
>>>> lib to
>>>>>>>>>>>>>>> avoid ABI breakage for every new addition in enums.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>> - } else if (xform->xform_type >=
>>>>>>>>>>>>>> RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
>>>>>>>>>>>>>>> + } else if (xform->xform_type >
>>>>>>>>> RTE_CRYPTO_ASYM_XFORM_ECPM
>>>>>>>>> [...]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So I am not sure that this is an improvement.
>>>>>>>>>
>>>>>>>>> Indeed, it is not an improvement.
>>>>>>>>>
>>>>>>>>>>>>>> The cryptodev issue we had, was that _LIST_END was being
>>>>>>>>>>>>>> used to size arrays.
>>>>>>>>>>>>>> And that broke when new algorithms got added. Is that an
>>>>>>>>>>>>>> issue, in this
>>>>>>>>>>> case?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes we did this same exercise for symmetric crypto enums
>>>> earlier.
>>>>>>>>>>>>> Asym enums were left as it was experimental at that point.
>>>>>>>>>>>>> They are still experimental, but thought of making this
>>>>>>>>>>>>> uniform throughout DPDK enums.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am not sure that swapping out _LIST_END, and then
>>>>>>>>>>>>>> littering the code with RTE_CRYPTO_ASYM_XFORM_ECPM
>> and
>>>>>>>>>>>>>> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE, is an
>>>>>>>>> improvement
>>>>>>>>>>>>> here.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> My 2c is that from an ABI PoV
>>>> RTE_CRYPTO_ASYM_OP_LIST_END is
>>>>>>>>>>>>>> not better or worse, than
>>>>>>>>>>> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Interested to hear other thoughts.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I don’t have any better solution for avoiding ABI issues for
>> now.
>>>>>>>>>>>>> The change is for avoiding ABI breakage. But we can drop
>>>>>>>>>>>>> this patch For now as asym is still experimental.
>>>>>>>>>>>>
>>>>>>>>>>>> [Anoob] Having LIST_END would preclude new additions to
>>>>>>>>>>>> asymmetric
>>>>>>>>> algos?
>>>>>>>>>>> If yes, then I would suggest we address it now.
>>>>>>>>>>>
>>>>>>>>>>> Not at all - but it can be problematic, if two versions of
>>>>>>>>>>> DPDK disagree with the value of LIST_END.
>>>>>>>>>>>
>>>>>>>>>>>> Looking at the "problematic changes", we only have 2-3
>>>>>>>>>>>> application & PMD changes. For unit test application, we
>>>>>>>>>>>> could may be do something like,
>>>>>>>>>>>
>>>>>>>>>>> The essental functionality not that different, I am just
>>>>>>>>>>> not sure that the verbosity below is helping.
>>>>>>>>>>> What you are really trying to guard against is people using
>>>>>>>>>>> LIST_END to size arrays.
>>>>>>>>>>
>>>>>>>>>> [Anoob] Our problem is application using LIST_END (which
>>>>>>>>>> comes from library)
>>>>>>>>> to determine the number of iterations for the loop. My
>>>>>>>>> suggestion is to modify the UT such that, we could use
>>>>>>>>> RTE_DIM(types) (which comes from application) to determine
>>>>>>>>> iterations of loop. This would solve the
>>>>>>> problem, right?
>>>>>>>>>
>>>>>>>>> The problem is not the application.
>>>>>>>>> Are you asking the app to define DPDK types?
>>>>>>>>
>>>>>>>> [Anoob] I didn't understand how you concluded that.
>>>>>>>
>>>>>>> Because you define a specific array in the test app.
>>>>>>>
>>>>>>>> The app is supposed to test "n" asymmetric features supported
>>>>>>>> by
>>>> DPDK.
>>>>>>> Currently, it does that by looping from 0 to LIST_END which
>>>>>>> happens to give you the first n features. Now, if we add any
>>>>>>> new asymmetric feature, LIST_END value would change. Isn't that
>>>>>>> the very reason why we removed LIST_END from symmetric library
>> and applications?
>>>>>>>
>>>>>>> Yes
>>>>>>>
>>>>>>>> Now coming to what I proposed, the app is supposed to test "n"
>>>>>>>> asymmetric
>>>>>>> features. LIST_END helps in doing the loops. If we remove
>>>>>>> LIST_END, then application will not be in a position to do a
>>>>>>> loop. My suggestion is, we list the types that are supposed to
>>>>>>> be tested by the app, and let that array be used as feature list.
>>>>>>>>
>>>>>>>> PS: Just to reiterate, my proposal is just a local array which
>>>>>>>> would hold DPDK
>>>>>>> defined RTE enum values for the features that would be tested
>>>>>>> by this app/function.
>>>>>>>
>>>>>>> I am more concerned by the general case than the test app.
>>>>>>> I think a function returning a number is more app-friendly.
>>>>>>
>>>>>> [Anoob] Indeed. But there are 3 LIST_ENDs removed with this
>>>>>> patch. Do
>>>> you propose 3 new APIs to just get max number?
>>>>>
>>>>> 1 API returning a single "info" structure perhaps - as being the
>>>>> most
>>>> extensible?
>>>>
>>>> Or 3 iterators (foreach construct).
>>>> Instead of just returning a size, we can have an iterator for each
>>>> enum which needs to be iterated.
>>>
>>> [Anoob] Something like this?
>>>
>>> diff --git a/app/test/test_cryptodev_asym.c
>>> b/app/test/test_cryptodev_asym.c index 847b074a4f..68a6197851 100644
>>> --- a/app/test/test_cryptodev_asym.c
>>> +++ b/app/test/test_cryptodev_asym.c
>>> @@ -542,7 +542,7 @@ test_one_case(const void *test_case, int
>> sessionless)
>>> printf(" %u) TestCase %s %s\n", test_index++,
>>> tc.modex.description, test_msg);
>>> } else {
>>> - for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
>>> + RTE_CRYPTO_ASYM_FOREACH_OP_TYPE(i) {
>>> if (tc.modex.xform_type == RTE_CRYPTO_ASYM_XFORM_RSA)
>> {
>>> if (tc.rsa_data.op_type_flags & (1 << i)) {
>>> if (tc.rsa_data.key_exp) {
>>> diff --git a/lib/cryptodev/rte_crypto_asym.h
>>> b/lib/cryptodev/rte_crypto_asym.h index 9c866f553f..5627dcaff1 100644
>>> --- a/lib/cryptodev/rte_crypto_asym.h
>>> +++ b/lib/cryptodev/rte_crypto_asym.h
>>> @@ -119,6 +119,11 @@ enum rte_crypto_asym_op_type {
>>> RTE_CRYPTO_ASYM_OP_LIST_END
>>> };
>>>
>>> +#define RTE_CRYPTO_ASYM_FOREACH_OP_TYPE(i) \
>>> + for (i = RTE_CRYPTO_ASYM_OP_ENCRYPT; \
>>> + i <= RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE; \
>>> + i++)
>>
>> You must not use enum values in the .h, otherwise ABI compatibility is not
>> ensured.
>> Yes you can do a macro, but it must call functions, not using direct values.
>>
>
> [Anoob] Understood. Will do that.
>
> @Ray, @Akhil, you are also in agreement, right?
>
Yes - whether you use the MACRO or not less important.
In order to maintain the ABI ... you need to learn the array size through an API.
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v1 1/1] ci: enable DPDK GHA for arm64 with self-hosted runners
@ 2021-10-13 8:03 7% ` Serena He
2021-10-13 11:32 0% ` Michael Santana
0 siblings, 1 reply; 200+ results
From: Serena He @ 2021-10-13 8:03 UTC (permalink / raw)
To: aconole, maicolgabriel, david.marchand, thomas
Cc: dev, nd, honnappa.nagarahalli, ruifeng.wang, Dean.Arnold,
Serena He, stable
CI jobs are triggered only for repos installed with given GHApp and runners
Cc: stable@dpdk.org
Signed-off-by: Serena He <serena.he@arm.com>
---
.github/workflows/build-arm64.yml | 118 ++++++++++++++++++++++++++++++
1 file changed, 118 insertions(+)
create mode 100644 .github/workflows/build-arm64.yml
diff --git a/.github/workflows/build-arm64.yml b/.github/workflows/build-arm64.yml
new file mode 100644
index 0000000000..570563f7c8
--- /dev/null
+++ b/.github/workflows/build-arm64.yml
@@ -0,0 +1,118 @@
+name: build-arm64
+
+on:
+ push:
+ schedule:
+ - cron: '0 0 * * 1'
+
+defaults:
+ run:
+ shell: bash --noprofile --norc -exo pipefail {0}
+
+jobs:
+ build:
+ # Here, runners for arm64 are accessed by installed GitHub APP, thus will not be available by fork.
+ # you can change the following 'if' and 'runs-on' if you have your own runners installed.
+ # or request to get your repo on the whitelist to use GitHub APP and delete this 'if'.
+ if: ${{ github.repository == 'DPDK/dpdk' || github.repository == 'ovsrobot/dpdk' }}
+ name: ${{ join(matrix.config.*, '-') }}
+ runs-on: ${{ matrix.config.os }}
+ env:
+ ABI_CHECKS: ${{ contains(matrix.config.checks, 'abi') }}
+ BUILD_DOCS: ${{ contains(matrix.config.checks, 'doc') }}
+ CL: ${{ matrix.config.compiler == 'clang' }}
+ CC: ccache ${{ matrix.config.compiler }}
+ DEF_LIB: ${{ matrix.config.library }}
+ LIBABIGAIL_VERSION: libabigail-1.8
+ REF_GIT_TAG: none
+
+ strategy:
+ fail-fast: false
+ matrix:
+ config:
+ - os: [self-hosted,arm-ubuntu-20.04]
+ compiler: gcc
+ library: static
+ - os: [self-hosted,arm-ubuntu-20.04]
+ compiler: gcc
+ library: shared
+ checks: doc+tests
+ - os: [self-hosted,arm-ubuntu-20.04]
+ compiler: clang
+ library: static
+ - os: [self-hosted,arm-ubuntu-20.04]
+ compiler: clang
+ library: shared
+ checks: doc+tests
+
+ steps:
+ - name: Checkout sources
+ uses: actions/checkout@v2
+ - name: Generate cache keys
+ id: get_ref_keys
+ run: |
+ echo -n '::set-output name=ccache::'
+ echo 'ccache-${{ matrix.config.os }}-${{ matrix.config.compiler }}-${{ matrix.config.cross }}-'$(date -u +%Y-w%W)
+ echo -n '::set-output name=libabigail::'
+ echo 'libabigail-${{ matrix.config.os }}'
+ echo -n '::set-output name=abi::'
+ echo 'abi-${{ matrix.config.os }}-${{ matrix.config.compiler }}-${{ matrix.config.cross }}-${{ env.LIBABIGAIL_VERSION }}-${{ env.REF_GIT_TAG }}'
+ - name: Retrieve ccache cache
+ uses: actions/cache@v2
+ with:
+ path: ~/.ccache
+ key: ${{ steps.get_ref_keys.outputs.ccache }}-${{ github.ref }}
+ restore-keys: |
+ ${{ steps.get_ref_keys.outputs.ccache }}-refs/heads/main
+ - name: Retrieve libabigail cache
+ id: libabigail-cache
+ uses: actions/cache@v2
+ if: env.ABI_CHECKS == 'true'
+ with:
+ path: libabigail
+ key: ${{ steps.get_ref_keys.outputs.libabigail }}
+ - name: Retrieve ABI reference cache
+ uses: actions/cache@v2
+ if: env.ABI_CHECKS == 'true'
+ with:
+ path: reference
+ key: ${{ steps.get_ref_keys.outputs.abi }}
+ - name: Update APT cache
+ run: sudo apt update || true
+ - name: Install packages
+ run: sudo apt install -y ccache libnuma-dev python3-setuptools
+ python3-wheel python3-pip python3-pyelftools ninja-build libbsd-dev
+ libpcap-dev libibverbs-dev libcrypto++-dev libfdt-dev libjansson-dev
+ libarchive-dev zlib1g-dev pkgconf
+ - name: Install libabigail build dependencies if no cache is available
+ if: env.ABI_CHECKS == 'true' && steps.libabigail-cache.outputs.cache-hit != 'true'
+ run: sudo apt install -y autoconf automake libtool pkg-config libxml2-dev
+ libdw-dev
+
+ - name: Install test tools packages
+ run: sudo apt install -y gdb
+ - name: Install doc generation packages
+ if: env.BUILD_DOCS == 'true'
+ run: sudo apt install -y doxygen graphviz python3-sphinx
+ python3-sphinx-rtd-theme
+ - name: Run setup
+ run: |
+ .ci/linux-setup.sh
+ # Workaround on $HOME permissions as EAL checks them for plugin loading
+ chmod o-w $HOME
+ - name: Install clang
+ if: env.CL == 'true'
+ run: sudo apt install -y clang
+ - name: Build and test
+ run: .ci/linux-build.sh
+ - name: Upload logs on failure
+ if: failure()
+ uses: actions/upload-artifact@v2
+ with:
+ name: meson-logs-${{ join(matrix.config.*, '-') }}
+ path: |
+ build/meson-logs/testlog.txt
+ build/.ninja_log
+ build/meson-logs/meson-log.txt
+ build/gdb.log
+
--
2.17.1
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [EXT] Re: [PATCH v2 1/3] cryptodev: remove LIST_END enumerators
2021-10-13 7:02 3% ` Thomas Monjalon
@ 2021-10-13 7:04 0% ` Anoob Joseph
2021-10-13 8:39 3% ` Kinsella, Ray
0 siblings, 1 reply; 200+ results
From: Anoob Joseph @ 2021-10-13 7:04 UTC (permalink / raw)
To: Thomas Monjalon, Akhil Goyal, dev, Kinsella, Ray
Cc: david.marchand, hemant.agrawal, pablo.de.lara.guarch,
fiona.trahe, declan.doherty, matan, g.singh, roy.fan.zhang,
jianjay.zhou, asomalap, ruifeng.wang, konstantin.ananyev,
radu.nicolau, ajit.khaparde, Nagadheeraj Rottela, Ankur Dwivedi,
ciara.power, Stephen Hemminger, Yigit, Ferruh, bruce.richardson
Hi Akhil, Ray, Thomas,
Please see inline.
Thanks,
Anoob
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Wednesday, October 13, 2021 12:32 PM
> To: Akhil Goyal <gakhil@marvell.com>; dev@dpdk.org; Kinsella, Ray
> <mdr@ashroe.eu>; Anoob Joseph <anoobj@marvell.com>
> Cc: david.marchand@redhat.com; hemant.agrawal@nxp.com;
> pablo.de.lara.guarch@intel.com; fiona.trahe@intel.com;
> declan.doherty@intel.com; matan@nvidia.com; g.singh@nxp.com;
> roy.fan.zhang@intel.com; jianjay.zhou@huawei.com; asomalap@amd.com;
> ruifeng.wang@arm.com; konstantin.ananyev@intel.com;
> radu.nicolau@intel.com; ajit.khaparde@broadcom.com; Nagadheeraj
> Rottela <rnagadheeraj@marvell.com>; Ankur Dwivedi
> <adwivedi@marvell.com>; ciara.power@intel.com; Stephen Hemminger
> <stephen@networkplumber.org>; Yigit, Ferruh <ferruh.yigit@intel.com>;
> bruce.richardson@intel.com
> Subject: Re: [EXT] Re: [dpdk-dev] [PATCH v2 1/3] cryptodev: remove
> LIST_END enumerators
>
> 13/10/2021 07:36, Anoob Joseph:
> > From: Thomas Monjalon <thomas@monjalon.net>
> > > 12/10/2021 16:47, Kinsella, Ray:
> > > > On 12/10/2021 15:18, Anoob Joseph wrote:
> > > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > >> 12/10/2021 15:38, Anoob Joseph:
> > > > >>> From: Thomas Monjalon <thomas@monjalon.net>
> > > > >>>> 12/10/2021 13:34, Anoob Joseph:
> > > > >>>>> From: Kinsella, Ray <mdr@ashroe.eu>
> > > > >>>>>> On 12/10/2021 11:50, Anoob Joseph wrote:
> > > > >>>>>>> From: Akhil Goyal <gakhil@marvell.com>
> > > > >>>>>>>>> On 08/10/2021 21:45, Akhil Goyal wrote:
> > > > >>>>>>>>>> Remove *_LIST_END enumerators from asymmetric
> crypto
> > > lib to
> > > > >>>>>>>>>> avoid ABI breakage for every new addition in enums.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> > > > >>>>>>>>>> ---
> > > > >>>>>>>>>> - } else if (xform->xform_type >=
> > > > >>>>>>>>> RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
> > > > >>>>>>>>>> + } else if (xform->xform_type >
> > > > >>>> RTE_CRYPTO_ASYM_XFORM_ECPM
> > > > >>>> [...]
> > > > >>>>>>>>>
> > > > >>>>>>>>> So I am not sure that this is an improvement.
> > > > >>>>
> > > > >>>> Indeed, it is not an improvement.
> > > > >>>>
> > > > >>>>>>>>> The cryptodev issue we had, was that _LIST_END was being
> > > > >>>>>>>>> used to size arrays.
> > > > >>>>>>>>> And that broke when new algorithms got added. Is that an
> > > > >>>>>>>>> issue, in this
> > > > >>>>>> case?
> > > > >>>>>>>>
> > > > >>>>>>>> Yes we did this same exercise for symmetric crypto enums
> > > earlier.
> > > > >>>>>>>> Asym enums were left as it was experimental at that point.
> > > > >>>>>>>> They are still experimental, but thought of making this
> > > > >>>>>>>> uniform throughout DPDK enums.
> > > > >>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>> I am not sure that swapping out _LIST_END, and then
> > > > >>>>>>>>> littering the code with RTE_CRYPTO_ASYM_XFORM_ECPM
> and
> > > > >>>>>>>>> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE, is an
> > > > >>>> improvement
> > > > >>>>>>>> here.
> > > > >>>>>>>>>
> > > > >>>>>>>>> My 2c is that from an ABI PoV
> > > RTE_CRYPTO_ASYM_OP_LIST_END is
> > > > >>>>>>>>> not better or worse, than
> > > > >>>>>> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE?
> > > > >>>>>>>>>
> > > > >>>>>>>>> Interested to hear other thoughts.
> > > > >>>>>>>>
> > > > >>>>>>>> I don’t have any better solution for avoiding ABI issues for
> now.
> > > > >>>>>>>> The change is for avoiding ABI breakage. But we can drop
> > > > >>>>>>>> this patch For now as asym is still experimental.
> > > > >>>>>>>
> > > > >>>>>>> [Anoob] Having LIST_END would preclude new additions to
> > > > >>>>>>> asymmetric
> > > > >>>> algos?
> > > > >>>>>> If yes, then I would suggest we address it now.
> > > > >>>>>>
> > > > >>>>>> Not at all - but it can be problematic, if two versions of
> > > > >>>>>> DPDK disagree with the value of LIST_END.
> > > > >>>>>>
> > > > >>>>>>> Looking at the "problematic changes", we only have 2-3
> > > > >>>>>>> application & PMD changes. For unit test application, we
> > > > >>>>>>> could may be do something like,
> > > > >>>>>>
> > > > >>>>>> The essental functionality not that different, I am just
> > > > >>>>>> not sure that the verbosity below is helping.
> > > > >>>>>> What you are really trying to guard against is people using
> > > > >>>>>> LIST_END to size arrays.
> > > > >>>>>
> > > > >>>>> [Anoob] Our problem is application using LIST_END (which
> > > > >>>>> comes from library)
> > > > >>>> to determine the number of iterations for the loop. My
> > > > >>>> suggestion is to modify the UT such that, we could use
> > > > >>>> RTE_DIM(types) (which comes from application) to determine
> > > > >>>> iterations of loop. This would solve the
> > > > >> problem, right?
> > > > >>>>
> > > > >>>> The problem is not the application.
> > > > >>>> Are you asking the app to define DPDK types?
> > > > >>>
> > > > >>> [Anoob] I didn't understand how you concluded that.
> > > > >>
> > > > >> Because you define a specific array in the test app.
> > > > >>
> > > > >>> The app is supposed to test "n" asymmetric features supported
> > > > >>> by
> > > DPDK.
> > > > >> Currently, it does that by looping from 0 to LIST_END which
> > > > >> happens to give you the first n features. Now, if we add any
> > > > >> new asymmetric feature, LIST_END value would change. Isn't that
> > > > >> the very reason why we removed LIST_END from symmetric library
> and applications?
> > > > >>
> > > > >> Yes
> > > > >>
> > > > >>> Now coming to what I proposed, the app is supposed to test "n"
> > > > >>> asymmetric
> > > > >> features. LIST_END helps in doing the loops. If we remove
> > > > >> LIST_END, then application will not be in a position to do a
> > > > >> loop. My suggestion is, we list the types that are supposed to
> > > > >> be tested by the app, and let that array be used as feature list.
> > > > >>>
> > > > >>> PS: Just to reiterate, my proposal is just a local array which
> > > > >>> would hold DPDK
> > > > >> defined RTE enum values for the features that would be tested
> > > > >> by this app/function.
> > > > >>
> > > > >> I am more concerned by the general case than the test app.
> > > > >> I think a function returning a number is more app-friendly.
> > > > >
> > > > > [Anoob] Indeed. But there are 3 LIST_ENDs removed with this
> > > > > patch. Do
> > > you propose 3 new APIs to just get max number?
> > > >
> > > > 1 API returning a single "info" structure perhaps - as being the
> > > > most
> > > extensible?
> > >
> > > Or 3 iterators (foreach construct).
> > > Instead of just returning a size, we can have an iterator for each
> > > enum which needs to be iterated.
> >
> > [Anoob] Something like this?
> >
> > diff --git a/app/test/test_cryptodev_asym.c
> > b/app/test/test_cryptodev_asym.c index 847b074a4f..68a6197851 100644
> > --- a/app/test/test_cryptodev_asym.c
> > +++ b/app/test/test_cryptodev_asym.c
> > @@ -542,7 +542,7 @@ test_one_case(const void *test_case, int
> sessionless)
> > printf(" %u) TestCase %s %s\n", test_index++,
> > tc.modex.description, test_msg);
> > } else {
> > - for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
> > + RTE_CRYPTO_ASYM_FOREACH_OP_TYPE(i) {
> > if (tc.modex.xform_type == RTE_CRYPTO_ASYM_XFORM_RSA)
> {
> > if (tc.rsa_data.op_type_flags & (1 << i)) {
> > if (tc.rsa_data.key_exp) {
> > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > b/lib/cryptodev/rte_crypto_asym.h index 9c866f553f..5627dcaff1 100644
> > --- a/lib/cryptodev/rte_crypto_asym.h
> > +++ b/lib/cryptodev/rte_crypto_asym.h
> > @@ -119,6 +119,11 @@ enum rte_crypto_asym_op_type {
> > RTE_CRYPTO_ASYM_OP_LIST_END
> > };
> >
> > +#define RTE_CRYPTO_ASYM_FOREACH_OP_TYPE(i) \
> > + for (i = RTE_CRYPTO_ASYM_OP_ENCRYPT; \
> > + i <= RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE; \
> > + i++)
>
> You must not use enum values in the .h, otherwise ABI compatibility is not
> ensured.
> Yes you can do a macro, but it must call functions, not using direct values.
>
[Anoob] Understood. Will do that.
@Ray, @Akhil, you are also in agreement, right?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [EXT] Re: [PATCH v2 1/3] cryptodev: remove LIST_END enumerators
2021-10-13 5:36 0% ` Anoob Joseph
@ 2021-10-13 7:02 3% ` Thomas Monjalon
2021-10-13 7:04 0% ` Anoob Joseph
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2021-10-13 7:02 UTC (permalink / raw)
To: Akhil Goyal, dev, Kinsella, Ray, Anoob Joseph
Cc: david.marchand, hemant.agrawal, pablo.de.lara.guarch,
fiona.trahe, declan.doherty, matan, g.singh, roy.fan.zhang,
jianjay.zhou, asomalap, ruifeng.wang, konstantin.ananyev,
radu.nicolau, ajit.khaparde, Nagadheeraj Rottela, Ankur Dwivedi,
ciara.power, Stephen Hemminger, Yigit, Ferruh, bruce.richardson
13/10/2021 07:36, Anoob Joseph:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 12/10/2021 16:47, Kinsella, Ray:
> > > On 12/10/2021 15:18, Anoob Joseph wrote:
> > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > >> 12/10/2021 15:38, Anoob Joseph:
> > > >>> From: Thomas Monjalon <thomas@monjalon.net>
> > > >>>> 12/10/2021 13:34, Anoob Joseph:
> > > >>>>> From: Kinsella, Ray <mdr@ashroe.eu>
> > > >>>>>> On 12/10/2021 11:50, Anoob Joseph wrote:
> > > >>>>>>> From: Akhil Goyal <gakhil@marvell.com>
> > > >>>>>>>>> On 08/10/2021 21:45, Akhil Goyal wrote:
> > > >>>>>>>>>> Remove *_LIST_END enumerators from asymmetric crypto
> > lib to
> > > >>>>>>>>>> avoid ABI breakage for every new addition in enums.
> > > >>>>>>>>>>
> > > >>>>>>>>>> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> > > >>>>>>>>>> ---
> > > >>>>>>>>>> - } else if (xform->xform_type >=
> > > >>>>>>>>> RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
> > > >>>>>>>>>> + } else if (xform->xform_type >
> > > >>>> RTE_CRYPTO_ASYM_XFORM_ECPM
> > > >>>> [...]
> > > >>>>>>>>>
> > > >>>>>>>>> So I am not sure that this is an improvement.
> > > >>>>
> > > >>>> Indeed, it is not an improvement.
> > > >>>>
> > > >>>>>>>>> The cryptodev issue we had, was that _LIST_END was being
> > > >>>>>>>>> used to size arrays.
> > > >>>>>>>>> And that broke when new algorithms got added. Is that an
> > > >>>>>>>>> issue, in this
> > > >>>>>> case?
> > > >>>>>>>>
> > > >>>>>>>> Yes we did this same exercise for symmetric crypto enums
> > earlier.
> > > >>>>>>>> Asym enums were left as it was experimental at that point.
> > > >>>>>>>> They are still experimental, but thought of making this
> > > >>>>>>>> uniform throughout DPDK enums.
> > > >>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> I am not sure that swapping out _LIST_END, and then
> > > >>>>>>>>> littering the code with RTE_CRYPTO_ASYM_XFORM_ECPM and
> > > >>>>>>>>> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE, is an
> > > >>>> improvement
> > > >>>>>>>> here.
> > > >>>>>>>>>
> > > >>>>>>>>> My 2c is that from an ABI PoV
> > RTE_CRYPTO_ASYM_OP_LIST_END is
> > > >>>>>>>>> not better or worse, than
> > > >>>>>> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE?
> > > >>>>>>>>>
> > > >>>>>>>>> Interested to hear other thoughts.
> > > >>>>>>>>
> > > >>>>>>>> I don’t have any better solution for avoiding ABI issues for now.
> > > >>>>>>>> The change is for avoiding ABI breakage. But we can drop this
> > > >>>>>>>> patch For now as asym is still experimental.
> > > >>>>>>>
> > > >>>>>>> [Anoob] Having LIST_END would preclude new additions to
> > > >>>>>>> asymmetric
> > > >>>> algos?
> > > >>>>>> If yes, then I would suggest we address it now.
> > > >>>>>>
> > > >>>>>> Not at all - but it can be problematic, if two versions of DPDK
> > > >>>>>> disagree with the value of LIST_END.
> > > >>>>>>
> > > >>>>>>> Looking at the "problematic changes", we only have 2-3
> > > >>>>>>> application & PMD changes. For unit test application, we could
> > > >>>>>>> may be do something like,
> > > >>>>>>
> > > >>>>>> The essental functionality not that different, I am just not
> > > >>>>>> sure that the verbosity below is helping.
> > > >>>>>> What you are really trying to guard against is people using
> > > >>>>>> LIST_END to size arrays.
> > > >>>>>
> > > >>>>> [Anoob] Our problem is application using LIST_END (which comes
> > > >>>>> from library)
> > > >>>> to determine the number of iterations for the loop. My suggestion
> > > >>>> is to modify the UT such that, we could use RTE_DIM(types) (which
> > > >>>> comes from application) to determine iterations of loop. This
> > > >>>> would solve the
> > > >> problem, right?
> > > >>>>
> > > >>>> The problem is not the application.
> > > >>>> Are you asking the app to define DPDK types?
> > > >>>
> > > >>> [Anoob] I didn't understand how you concluded that.
> > > >>
> > > >> Because you define a specific array in the test app.
> > > >>
> > > >>> The app is supposed to test "n" asymmetric features supported by
> > DPDK.
> > > >> Currently, it does that by looping from 0 to LIST_END which happens
> > > >> to give you the first n features. Now, if we add any new asymmetric
> > > >> feature, LIST_END value would change. Isn't that the very reason
> > > >> why we removed LIST_END from symmetric library and applications?
> > > >>
> > > >> Yes
> > > >>
> > > >>> Now coming to what I proposed, the app is supposed to test "n"
> > > >>> asymmetric
> > > >> features. LIST_END helps in doing the loops. If we remove LIST_END,
> > > >> then application will not be in a position to do a loop. My
> > > >> suggestion is, we list the types that are supposed to be tested by
> > > >> the app, and let that array be used as feature list.
> > > >>>
> > > >>> PS: Just to reiterate, my proposal is just a local array which
> > > >>> would hold DPDK
> > > >> defined RTE enum values for the features that would be tested by
> > > >> this app/function.
> > > >>
> > > >> I am more concerned by the general case than the test app.
> > > >> I think a function returning a number is more app-friendly.
> > > >
> > > > [Anoob] Indeed. But there are 3 LIST_ENDs removed with this patch. Do
> > you propose 3 new APIs to just get max number?
> > >
> > > 1 API returning a single "info" structure perhaps - as being the most
> > extensible?
> >
> > Or 3 iterators (foreach construct).
> > Instead of just returning a size, we can have an iterator for each enum which
> > needs to be iterated.
>
> [Anoob] Something like this?
>
> diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
> index 847b074a4f..68a6197851 100644
> --- a/app/test/test_cryptodev_asym.c
> +++ b/app/test/test_cryptodev_asym.c
> @@ -542,7 +542,7 @@ test_one_case(const void *test_case, int sessionless)
> printf(" %u) TestCase %s %s\n", test_index++,
> tc.modex.description, test_msg);
> } else {
> - for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
> + RTE_CRYPTO_ASYM_FOREACH_OP_TYPE(i) {
> if (tc.modex.xform_type == RTE_CRYPTO_ASYM_XFORM_RSA) {
> if (tc.rsa_data.op_type_flags & (1 << i)) {
> if (tc.rsa_data.key_exp) {
> diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
> index 9c866f553f..5627dcaff1 100644
> --- a/lib/cryptodev/rte_crypto_asym.h
> +++ b/lib/cryptodev/rte_crypto_asym.h
> @@ -119,6 +119,11 @@ enum rte_crypto_asym_op_type {
> RTE_CRYPTO_ASYM_OP_LIST_END
> };
>
> +#define RTE_CRYPTO_ASYM_FOREACH_OP_TYPE(i) \
> + for (i = RTE_CRYPTO_ASYM_OP_ENCRYPT; \
> + i <= RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE; \
> + i++)
You must not use enum values in the .h, otherwise ABI compatibility is not ensured.
Yes you can do a macro, but it must call functions, not using direct values.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [EXT] Re: [PATCH v2 1/3] cryptodev: remove LIST_END enumerators
2021-10-12 15:06 0% ` Thomas Monjalon
@ 2021-10-13 5:36 0% ` Anoob Joseph
2021-10-13 7:02 3% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Anoob Joseph @ 2021-10-13 5:36 UTC (permalink / raw)
To: Thomas Monjalon, Akhil Goyal, dev, Kinsella, Ray
Cc: david.marchand, hemant.agrawal, pablo.de.lara.guarch,
fiona.trahe, declan.doherty, matan, g.singh, roy.fan.zhang,
jianjay.zhou, asomalap, ruifeng.wang, konstantin.ananyev,
radu.nicolau, ajit.khaparde, Nagadheeraj Rottela, Ankur Dwivedi,
ciara.power, Stephen Hemminger, Yigit, Ferruh, bruce.richardson
Hi Thomas, Ray,
Please see inline.
Thanks,
Anoob
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Tuesday, October 12, 2021 8:37 PM
> To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal
> <gakhil@marvell.com>; dev@dpdk.org; Kinsella, Ray <mdr@ashroe.eu>
> Cc: david.marchand@redhat.com; hemant.agrawal@nxp.com;
> pablo.de.lara.guarch@intel.com; fiona.trahe@intel.com;
> declan.doherty@intel.com; matan@nvidia.com; g.singh@nxp.com;
> roy.fan.zhang@intel.com; jianjay.zhou@huawei.com; asomalap@amd.com;
> ruifeng.wang@arm.com; konstantin.ananyev@intel.com;
> radu.nicolau@intel.com; ajit.khaparde@broadcom.com; Nagadheeraj
> Rottela <rnagadheeraj@marvell.com>; Ankur Dwivedi
> <adwivedi@marvell.com>; ciara.power@intel.com; Stephen Hemminger
> <stephen@networkplumber.org>; Yigit, Ferruh <ferruh.yigit@intel.com>;
> bruce.richardson@intel.com
> Subject: Re: [EXT] Re: [dpdk-dev] [PATCH v2 1/3] cryptodev: remove
> LIST_END enumerators
>
> 12/10/2021 16:47, Kinsella, Ray:
> > On 12/10/2021 15:18, Anoob Joseph wrote:
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > >> 12/10/2021 15:38, Anoob Joseph:
> > >>> From: Thomas Monjalon <thomas@monjalon.net>
> > >>>> 12/10/2021 13:34, Anoob Joseph:
> > >>>>> From: Kinsella, Ray <mdr@ashroe.eu>
> > >>>>>> On 12/10/2021 11:50, Anoob Joseph wrote:
> > >>>>>>> From: Akhil Goyal <gakhil@marvell.com>
> > >>>>>>>>> On 08/10/2021 21:45, Akhil Goyal wrote:
> > >>>>>>>>>> Remove *_LIST_END enumerators from asymmetric crypto
> lib to
> > >>>>>>>>>> avoid ABI breakage for every new addition in enums.
> > >>>>>>>>>>
> > >>>>>>>>>> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> > >>>>>>>>>> ---
> > >>>>>>>>>> - } else if (xform->xform_type >=
> > >>>>>>>>> RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
> > >>>>>>>>>> + } else if (xform->xform_type >
> > >>>> RTE_CRYPTO_ASYM_XFORM_ECPM
> > >>>> [...]
> > >>>>>>>>>
> > >>>>>>>>> So I am not sure that this is an improvement.
> > >>>>
> > >>>> Indeed, it is not an improvement.
> > >>>>
> > >>>>>>>>> The cryptodev issue we had, was that _LIST_END was being
> > >>>>>>>>> used to size arrays.
> > >>>>>>>>> And that broke when new algorithms got added. Is that an
> > >>>>>>>>> issue, in this
> > >>>>>> case?
> > >>>>>>>>
> > >>>>>>>> Yes we did this same exercise for symmetric crypto enums
> earlier.
> > >>>>>>>> Asym enums were left as it was experimental at that point.
> > >>>>>>>> They are still experimental, but thought of making this
> > >>>>>>>> uniform throughout DPDK enums.
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> I am not sure that swapping out _LIST_END, and then
> > >>>>>>>>> littering the code with RTE_CRYPTO_ASYM_XFORM_ECPM and
> > >>>>>>>>> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE, is an
> > >>>> improvement
> > >>>>>>>> here.
> > >>>>>>>>>
> > >>>>>>>>> My 2c is that from an ABI PoV
> RTE_CRYPTO_ASYM_OP_LIST_END is
> > >>>>>>>>> not better or worse, than
> > >>>>>> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE?
> > >>>>>>>>>
> > >>>>>>>>> Interested to hear other thoughts.
> > >>>>>>>>
> > >>>>>>>> I don’t have any better solution for avoiding ABI issues for now.
> > >>>>>>>> The change is for avoiding ABI breakage. But we can drop this
> > >>>>>>>> patch For now as asym is still experimental.
> > >>>>>>>
> > >>>>>>> [Anoob] Having LIST_END would preclude new additions to
> > >>>>>>> asymmetric
> > >>>> algos?
> > >>>>>> If yes, then I would suggest we address it now.
> > >>>>>>
> > >>>>>> Not at all - but it can be problematic, if two versions of DPDK
> > >>>>>> disagree with the value of LIST_END.
> > >>>>>>
> > >>>>>>> Looking at the "problematic changes", we only have 2-3
> > >>>>>>> application & PMD changes. For unit test application, we could
> > >>>>>>> may be do something like,
> > >>>>>>
> > >>>>>> The essental functionality not that different, I am just not
> > >>>>>> sure that the verbosity below is helping.
> > >>>>>> What you are really trying to guard against is people using
> > >>>>>> LIST_END to size arrays.
> > >>>>>
> > >>>>> [Anoob] Our problem is application using LIST_END (which comes
> > >>>>> from library)
> > >>>> to determine the number of iterations for the loop. My suggestion
> > >>>> is to modify the UT such that, we could use RTE_DIM(types) (which
> > >>>> comes from application) to determine iterations of loop. This
> > >>>> would solve the
> > >> problem, right?
> > >>>>
> > >>>> The problem is not the application.
> > >>>> Are you asking the app to define DPDK types?
> > >>>
> > >>> [Anoob] I didn't understand how you concluded that.
> > >>
> > >> Because you define a specific array in the test app.
> > >>
> > >>> The app is supposed to test "n" asymmetric features supported by
> DPDK.
> > >> Currently, it does that by looping from 0 to LIST_END which happens
> > >> to give you the first n features. Now, if we add any new asymmetric
> > >> feature, LIST_END value would change. Isn't that the very reason
> > >> why we removed LIST_END from symmetric library and applications?
> > >>
> > >> Yes
> > >>
> > >>> Now coming to what I proposed, the app is supposed to test "n"
> > >>> asymmetric
> > >> features. LIST_END helps in doing the loops. If we remove LIST_END,
> > >> then application will not be in a position to do a loop. My
> > >> suggestion is, we list the types that are supposed to be tested by
> > >> the app, and let that array be used as feature list.
> > >>>
> > >>> PS: Just to reiterate, my proposal is just a local array which
> > >>> would hold DPDK
> > >> defined RTE enum values for the features that would be tested by
> > >> this app/function.
> > >>
> > >> I am more concerned by the general case than the test app.
> > >> I think a function returning a number is more app-friendly.
> > >
> > > [Anoob] Indeed. But there are 3 LIST_ENDs removed with this patch. Do
> you propose 3 new APIs to just get max number?
> >
> > 1 API returning a single "info" structure perhaps - as being the most
> extensible?
>
> Or 3 iterators (foreach construct).
> Instead of just returning a size, we can have an iterator for each enum which
> needs to be iterated.
[Anoob] Something like this?
diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index 847b074a4f..68a6197851 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -542,7 +542,7 @@ test_one_case(const void *test_case, int sessionless)
printf(" %u) TestCase %s %s\n", test_index++,
tc.modex.description, test_msg);
} else {
- for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
+ RTE_CRYPTO_ASYM_FOREACH_OP_TYPE(i) {
if (tc.modex.xform_type == RTE_CRYPTO_ASYM_XFORM_RSA) {
if (tc.rsa_data.op_type_flags & (1 << i)) {
if (tc.rsa_data.key_exp) {
diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 9c866f553f..5627dcaff1 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -119,6 +119,11 @@ enum rte_crypto_asym_op_type {
RTE_CRYPTO_ASYM_OP_LIST_END
};
+#define RTE_CRYPTO_ASYM_FOREACH_OP_TYPE(i) \
+ for (i = RTE_CRYPTO_ASYM_OP_ENCRYPT; \
+ i <= RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE; \
+ i++)
+
/**
* Padding types for RSA signature.
*/
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3 1/2] lib/cmdline: release cl when cmdline exit
2021-10-13 2:36 4% ` Dmitry Kozlyuk
@ 2021-10-13 3:12 0% ` Peng, ZhihongX
0 siblings, 0 replies; 200+ results
From: Peng, ZhihongX @ 2021-10-13 3:12 UTC (permalink / raw)
To: Dmitry Kozlyuk; +Cc: olivier.matz, dev, stable
> -----Original Message-----
> From: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
> Sent: Wednesday, October 13, 2021 10:36 AM
> To: Peng, ZhihongX <zhihongx.peng@intel.com>
> Cc: olivier.matz@6wind.com; dev@dpdk.org; stable@dpdk.org
> Subject: Re: [PATCH v3 1/2] lib/cmdline: release cl when cmdline exit
>
> 2021-10-13 01:53 (UTC+0000), Peng, ZhihongX:
> > > -----Original Message-----
> > > From: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
> > > Sent: Monday, October 11, 2021 4:26 PM
> > > To: Peng, ZhihongX <zhihongx.peng@intel.com>
> > > Cc: olivier.matz@6wind.com; dev@dpdk.org; stable@dpdk.org
> > > Subject: Re: [PATCH v3 1/2] lib/cmdline: release cl when cmdline
> > > exit
> > >
> > > 2021-10-08 06:41 (UTC+0000), zhihongx.peng@intel.com:
> > > > From: Zhihong Peng <zhihongx.peng@intel.com>
> > > >
> > > > Malloc cl in the cmdline_stdin_new function, so release in the
> > > > cmdline_stdin_exit function is logical, so that cl will not be
> > > > released alone.
> > > >
> > > > Fixes: af75078fece3 (first public release)
> > > > Cc: stable@dpdk.org
> > >
> > > As I have explained before, backporting this will introduce a
> > > double-free bug in user apps unless their code are fixed, so it must not
> be done.
> >
> > The release notes have stated that this is the only thing we can do,
> > and this unreasonable design should be resolved as soon as possible.
> > And the user apps change is very small.
>
> Stable release means stable ABI, which means that a compiled binary can use
> the next minor version of DPDK without recompilation. No code change is
> possible in this scenario. If the behavior changes such that cmdline_exit() +
> cmdline_free() worked before and now cmdline_free() cause double-free,
> this is an ABI breakage. Simply put, DPDK .so are replaced, the app restarts
> and crashes. Users can do nothing about that.
>
> Release notes are for developers updating their application code for the next
> DPDK version.
I may not understand what you mean. I want to know whether this code
can be merged, and if it can be merged, what work do I need to do.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3 1/2] lib/cmdline: release cl when cmdline exit
2021-10-13 1:53 0% ` Peng, ZhihongX
@ 2021-10-13 2:36 4% ` Dmitry Kozlyuk
2021-10-13 3:12 0% ` Peng, ZhihongX
0 siblings, 1 reply; 200+ results
From: Dmitry Kozlyuk @ 2021-10-13 2:36 UTC (permalink / raw)
To: Peng, ZhihongX; +Cc: olivier.matz, dev, stable
2021-10-13 01:53 (UTC+0000), Peng, ZhihongX:
> > -----Original Message-----
> > From: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
> > Sent: Monday, October 11, 2021 4:26 PM
> > To: Peng, ZhihongX <zhihongx.peng@intel.com>
> > Cc: olivier.matz@6wind.com; dev@dpdk.org; stable@dpdk.org
> > Subject: Re: [PATCH v3 1/2] lib/cmdline: release cl when cmdline exit
> >
> > 2021-10-08 06:41 (UTC+0000), zhihongx.peng@intel.com:
> > > From: Zhihong Peng <zhihongx.peng@intel.com>
> > >
> > > Malloc cl in the cmdline_stdin_new function, so release in the
> > > cmdline_stdin_exit function is logical, so that cl will not be
> > > released alone.
> > >
> > > Fixes: af75078fece3 (first public release)
> > > Cc: stable@dpdk.org
> >
> > As I have explained before, backporting this will introduce a double-free bug
> > in user apps unless their code are fixed, so it must not be done.
>
> The release notes have stated that this is the only thing we can do,
> and this unreasonable design should be resolved as soon as possible.
> And the user apps change is very small.
Stable release means stable ABI, which means that a compiled binary can use
the next minor version of DPDK without recompilation. No code change is
possible in this scenario. If the behavior changes such that cmdline_exit() +
cmdline_free() worked before and now cmdline_free() cause double-free, this
is an ABI breakage. Simply put, DPDK .so are replaced, the app restarts and
crashes. Users can do nothing about that.
Release notes are for developers updating their application code for the next
DPDK version.
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v4 1/2] lib/cmdline: release cl when cmdline exit
2021-10-08 6:41 4% ` [dpdk-dev] [PATCH v3 1/2] lib/cmdline: release cl when cmdline exit zhihongx.peng
2021-10-11 5:20 0% ` Peng, ZhihongX
2021-10-11 8:25 0% ` Dmitry Kozlyuk
@ 2021-10-13 1:52 4% ` zhihongx.peng
2 siblings, 0 replies; 200+ results
From: zhihongx.peng @ 2021-10-13 1:52 UTC (permalink / raw)
To: olivier.matz, dmitry.kozliuk; +Cc: dev, Zhihong Peng, stable
From: Zhihong Peng <zhihongx.peng@intel.com>
Malloc cl in the cmdline_stdin_new function, so release in the
cmdline_stdin_exit function is logical, so that cl will not be
released alone.
Fixes: af75078fece3 ("first public release")
Cc: stable@dpdk.org
Signed-off-by: Zhihong Peng <zhihongx.peng@intel.com>
---
doc/guides/rel_notes/release_21_11.rst | 3 +++
lib/cmdline/cmdline_socket.c | 1 +
2 files changed, 4 insertions(+)
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index f643a61f44..2f59077709 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -226,6 +226,9 @@ API Changes
the crypto/security operation. This field will be used to communicate
events such as soft expiry with IPsec in lookaside mode.
+* cmdline: ``cmdline_stdin_exit()`` now frees the ``cmdline`` structure.
+ Calls to ``cmdline_free()`` after it need to be deleted from applications.
+
ABI Changes
-----------
diff --git a/lib/cmdline/cmdline_socket.c b/lib/cmdline/cmdline_socket.c
index 998e8ade25..ebd5343754 100644
--- a/lib/cmdline/cmdline_socket.c
+++ b/lib/cmdline/cmdline_socket.c
@@ -53,4 +53,5 @@ cmdline_stdin_exit(struct cmdline *cl)
return;
terminal_restore(cl);
+ cmdline_free(cl);
}
--
2.25.1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v3 1/2] lib/cmdline: release cl when cmdline exit
2021-10-11 8:25 0% ` Dmitry Kozlyuk
@ 2021-10-13 1:53 0% ` Peng, ZhihongX
2021-10-13 2:36 4% ` Dmitry Kozlyuk
0 siblings, 1 reply; 200+ results
From: Peng, ZhihongX @ 2021-10-13 1:53 UTC (permalink / raw)
To: Dmitry Kozlyuk; +Cc: olivier.matz, dev, stable
> -----Original Message-----
> From: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
> Sent: Monday, October 11, 2021 4:26 PM
> To: Peng, ZhihongX <zhihongx.peng@intel.com>
> Cc: olivier.matz@6wind.com; dev@dpdk.org; stable@dpdk.org
> Subject: Re: [PATCH v3 1/2] lib/cmdline: release cl when cmdline exit
>
> 2021-10-08 06:41 (UTC+0000), zhihongx.peng@intel.com:
> > From: Zhihong Peng <zhihongx.peng@intel.com>
> >
> > Malloc cl in the cmdline_stdin_new function, so release in the
> > cmdline_stdin_exit function is logical, so that cl will not be
> > released alone.
> >
> > Fixes: af75078fece3 (first public release)
> > Cc: stable@dpdk.org
>
> As I have explained before, backporting this will introduce a double-free bug
> in user apps unless their code are fixed, so it must not be done.
The release notes have stated that this is the only thing we can do,
and this unreasonable design should be resolved as soon as possible.
And the user apps change is very small.
> >
> > Signed-off-by: Zhihong Peng <zhihongx.peng@intel.com>
> > ---
> > doc/guides/rel_notes/release_21_11.rst | 5 +++++
> > lib/cmdline/cmdline_socket.c | 1 +
> > 2 files changed, 6 insertions(+)
> >
> > diff --git a/doc/guides/rel_notes/release_21_11.rst
> > b/doc/guides/rel_notes/release_21_11.rst
> > index efeffe37a0..be24925d16 100644
> > --- a/doc/guides/rel_notes/release_21_11.rst
> > +++ b/doc/guides/rel_notes/release_21_11.rst
> > @@ -191,6 +191,11 @@ API Changes
> > the crypto/security operation. This field will be used to communicate
> > events such as soft expiry with IPsec in lookaside mode.
> >
> > +* cmdline: The API cmdline_stdin_exit has added cmdline_free function.
> > + Malloc cl in the cmdline_stdin_new function, so release in the
> > + cmdline_stdin_exit function is logical. The application code
> > + that calls cmdline_free needs to be deleted.
> > +
>
> There's probably no need to go into such details, suggestion:
>
> * cmdline: ``cmdline_stdin_exit()`` now frees the ``cmdline`` structure.
> Calls to ``cmdline_free()`` after it need to be deleted from applications.
v4 version will be fixed.
> >
> > ABI Changes
> > -----------
> > diff --git a/lib/cmdline/cmdline_socket.c
> > b/lib/cmdline/cmdline_socket.c index 998e8ade25..ebd5343754 100644
> > --- a/lib/cmdline/cmdline_socket.c
> > +++ b/lib/cmdline/cmdline_socket.c
> > @@ -53,4 +53,5 @@ cmdline_stdin_exit(struct cmdline *cl)
> > return;
> >
> > terminal_restore(cl);
> > + cmdline_free(cl);
> > }
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs
2021-10-12 19:26 3% ` Walker, Benjamin
@ 2021-10-12 21:50 3% ` Thomas Monjalon
2021-10-13 17:56 5% ` Walker, Benjamin
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2021-10-12 21:50 UTC (permalink / raw)
To: Harris, James R, Walker, Benjamin
Cc: Liu, Changpeng, Xia, Chenbo, David Marchand, dev, Aaron Conole,
Zawadzki, Tomasz
12/10/2021 21:26, Walker, Benjamin:
> > From: Thomas Monjalon <thomas@monjalon.net>
> > 12/10/2021 18:59, Walker, Benjamin:
> > > For networking drivers, maybe. But certainly years and years ago when SPDK
> > was started no one recommended putting an nvme driver into DPDK.
> >
> > No one from SPDK project proposed such thing.
> > I asked several times in person why that, and even the DPDK techboard asked for
> > such a merge:
> > https://mails.dpdk.org/archives/dev/2018-December/120706.html
> > The reply:
> > http://inbox.dpdk.org/dev/20181217141030.bhe5pwlqnzb3w3i7@platinum/
> > Even older question in 2015:
> > http://inbox.dpdk.org/dev/6421280.5XkMhqyP4M@xps13/
> >
>
> For my part in these discussions, it was always about merging the governance of the projects rather than the code. I don't think a merger even occurred to anyone I spoke with during that - certainly it didn't to me. SPDK is huge and beyond its use of EAL/PCI doesn't share much in common with the rest of DPDK (SPDK uses lightweight green threading, all virtual addresses, etc.). Anyway, as I pointed out one of our key use cases for several users is the ability to replace DPDK entirely, so merging isn't an option.
OK I understand, that's clear.
I would be interesting to know if the NVMe drivers could be split in two parts:
one part in DPDK, and the other part in SPDK for the non-DPDK case.
I ask because it may ease things for DPDK integration in SPDK.
There is probably a cost for the SPDK project, so it could be interesting
to compare pros and cons, if possible at all.
> > > This means that a distro-packaged SPDK cannot exist, because it cannot use a
> > distro-packaged DPDK as a dependency.
> >
> > I don't think so.
> > Once SPDK is packaged, what do you need from DPDK?
> > I think you need only .so files for some libs like EAL and PCI, so that's available in
> > the DPDK package, right?
> >
>
> So is DPDK committed to maintaining the existing ABI,
> such that the necessary symbols are still exported
> even when enable_driver_sdk is off?
Symbols required by drivers are necessarily exported.
Do you think I am missing something?
Do you need EAL internal functions?
We should check which functions are called by SPDK,
because there is a trend to export less functions if not needed.
> This option will, into the foreseeable future,
> only impact the installation of those header files?
I don't see what else it could impact.
> If that's the case, we can just copy the header file into SPDK,
> as could anyone else that wants to continue using DPDK
> to implement out of tree drivers.
> Can you clarify if something like this scheme would be considered a supported use of DPDK?
DPDK can be used by anybody as far as the (permissive) license is respected.
I consider copying files as a source of sync issues, but you are free.
In order to be perfectly clear, all the changes done
around this option enable_driver_sdk share the goal of tidying stuff
in DPDK so that ABI becomes better manageable.
I think that nobody want to annoy the SPDK project.
I understand that the changes effectively add troubles, and I am sorry
about that. If SPDK and other projects can manage with this change, good.
If there is a real blocker, we should discuss what are the options.
Thanks for your understanding
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v5 1/5] ethdev: update modify field flow action
@ 2021-10-12 20:25 3% ` Viacheslav Ovsiienko
0 siblings, 0 replies; 200+ results
From: Viacheslav Ovsiienko @ 2021-10-12 20:25 UTC (permalink / raw)
To: dev; +Cc: rasland, matan, shahafs, orika, getelson, thomas
The generic modify field flow action introduced in [1] has
some issues related to the immediate source operand:
- immediate source can be presented either as an unsigned
64-bit integer or pointer to data pattern in memory.
There was no explicit pointer field defined in the union.
- the byte ordering for 64-bit integer was not specified.
Many fields have shorter lengths and byte ordering
is crucial.
- how the bit offset is applied to the immediate source
field was not defined and documented.
- 64-bit integer size is not enough to provide IPv6
addresses.
In order to cover the issues and exclude any ambiguities
the following is done:
- introduce the explicit pointer field
in rte_flow_action_modify_data structure
- replace the 64-bit unsigned integer with 16-byte array
- update the modify field flow action documentation
Appropriate deprecation notice has been removed.
[1] commit 73b68f4c54a0 ("ethdev: introduce generic modify flow action")
Fixes: 2ba49b5f3721 ("doc: announce change to ethdev modify action data")
Signed-off-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
doc/guides/prog_guide/rte_flow.rst | 24 +++++++++++++++++++++++-
doc/guides/rel_notes/deprecation.rst | 4 ----
doc/guides/rel_notes/release_21_11.rst | 7 +++++++
lib/ethdev/rte_flow.h | 16 ++++++++++++----
4 files changed, 42 insertions(+), 9 deletions(-)
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 2b42d5ec8c..b08087511f 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -2835,6 +2835,22 @@ a packet to any other part of it.
``value`` sets an immediate value to be used as a source or points to a
location of the value in memory. It is used instead of ``level`` and ``offset``
for ``RTE_FLOW_FIELD_VALUE`` and ``RTE_FLOW_FIELD_POINTER`` respectively.
+The data in memory should be presented exactly in the same byte order and
+length as in the relevant flow item, i.e. data for field with type
+``RTE_FLOW_FIELD_MAC_DST`` should follow the conventions of ``dst`` field
+in ``rte_flow_item_eth`` structure, with type ``RTE_FLOW_FIELD_IPV6_SRC`` -
+``rte_flow_item_ipv6`` conventions, and so on. If the field size is larger than
+16 bytes the pattern can be provided as pointer only.
+
+The bitfield extracted from the memory being applied as second operation
+parameter is defined by action width and by the destination field offset.
+Application should provide the data in immediate value memory (either as
+buffer or by pointer) exactly as item field without any applied explicit offset,
+and destination packet field (with specified width and bit offset) will be
+replaced by immediate source bits from the same bit offset. For example,
+to replace the third byte of MAC address with value 0x85, application should
+specify destination width as 8, destination offset as 16, and provide immediate
+value as sequence of bytes {xxx, xxx, 0x85, xxx, xxx, xxx}.
.. _table_rte_flow_action_modify_field:
@@ -2865,7 +2881,13 @@ for ``RTE_FLOW_FIELD_VALUE`` and ``RTE_FLOW_FIELD_POINTER`` respectively.
+---------------+----------------------------------------------------------+
| ``offset`` | number of bits to skip at the beginning |
+---------------+----------------------------------------------------------+
- | ``value`` | immediate value or a pointer to this value |
+ | ``value`` | immediate value buffer (source field only, not |
+ | | applicable to destination) for RTE_FLOW_FIELD_VALUE |
+ | | field type |
+ +---------------+----------------------------------------------------------+
+ | ``pvalue`` | pointer to immediate value data (source field only, not |
+ | | applicable to destination) for RTE_FLOW_FIELD_POINTER |
+ | | field type |
+---------------+----------------------------------------------------------+
Action: ``CONNTRACK``
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index a2fe766d4b..dee14077a5 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -120,10 +120,6 @@ Deprecation Notices
* ethdev: Announce moving from dedicated modify function for each field,
to using the general ``rte_flow_modify_field`` action.
-* ethdev: The struct ``rte_flow_action_modify_data`` will be modified
- to support modifying fields larger than 64 bits.
- In addition, documentation will be updated to clarify byte order.
-
* ethdev: Attribute ``shared`` of the ``struct rte_flow_action_count``
is deprecated and will be removed in DPDK 21.11. Shared counters should
be managed using shared actions API (``rte_flow_shared_action_create`` etc).
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index dfc2cbdeed..578c1206e7 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -187,6 +187,13 @@ API Changes
the crypto/security operation. This field will be used to communicate
events such as soft expiry with IPsec in lookaside mode.
+* ethdev: ``rte_flow_action_modify_data`` structure updated, immediate data
+ array is extended, data pointer field is explicitly added to union, the
+ action behavior is defined in more strict fashion and documentation updated.
+ The immediate value behavior has been changed, the entire immediate field
+ should be provided, and offset for immediate source bitfield is assigned
+ from destination one.
+
ABI Changes
-----------
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 7b1ed7f110..f14f77772b 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -3217,10 +3217,18 @@ struct rte_flow_action_modify_data {
uint32_t offset;
};
/**
- * Immediate value for RTE_FLOW_FIELD_VALUE or
- * memory address for RTE_FLOW_FIELD_POINTER.
+ * Immediate value for RTE_FLOW_FIELD_VALUE, presented in the
+ * same byte order and length as in relevant rte_flow_item_xxx.
+ * The immediate source bitfield offset is inherited from
+ * the destination's one.
*/
- uint64_t value;
+ uint8_t value[16];
+ /**
+ * Memory address for RTE_FLOW_FIELD_POINTER, memory layout
+ * should be the same as for relevant field in the
+ * rte_flow_item_xxx structure.
+ */
+ void *pvalue;
};
};
@@ -3240,7 +3248,7 @@ enum rte_flow_modify_op {
* RTE_FLOW_ACTION_TYPE_MODIFY_FIELD
*
* Modify a destination header field according to the specified
- * operation. Another packet field can be used as a source as well
+ * operation. Another field of the packet can be used as a source as well
* as tag, mark, metadata, immediate value or a pointer to it.
*/
struct rte_flow_action_modify_field {
--
2.18.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs
@ 2021-10-12 19:26 3% ` Walker, Benjamin
2021-10-12 21:50 3% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Walker, Benjamin @ 2021-10-12 19:26 UTC (permalink / raw)
To: Thomas Monjalon, Liu, Changpeng, Xia, Chenbo, Harris, James R
Cc: David Marchand, dev, Aaron Conole, Zawadzki, Tomasz
> From: Thomas Monjalon <thomas@monjalon.net>
> 12/10/2021 18:59, Walker, Benjamin:
> > For networking drivers, maybe. But certainly years and years ago when SPDK
> was started no one recommended putting an nvme driver into DPDK.
>
> No one from SPDK project proposed such thing.
> I asked several times in person why that, and even the DPDK techboard asked for
> such a merge:
> https://mails.dpdk.org/archives/dev/2018-December/120706.html
> The reply:
> http://inbox.dpdk.org/dev/20181217141030.bhe5pwlqnzb3w3i7@platinum/
> Even older question in 2015:
> http://inbox.dpdk.org/dev/6421280.5XkMhqyP4M@xps13/
>
For my part in these discussions, it was always about merging the governance of the projects rather than the code. I don't think a merger even occurred to anyone I spoke with during that - certainly it didn't to me. SPDK is huge and beyond its use of EAL/PCI doesn't share much in common with the rest of DPDK (SPDK uses lightweight green threading, all virtual addresses, etc.). Anyway, as I pointed out one of our key use cases for several users is the ability to replace DPDK entirely, so merging isn't an option.
> > This means that a distro-packaged SPDK cannot exist, because it cannot use a
> distro-packaged DPDK as a dependency.
>
> I don't think so.
> Once SPDK is packaged, what do you need from DPDK?
> I think you need only .so files for some libs like EAL and PCI, so that's available in
> the DPDK package, right?
>
So is DPDK committed to maintaining the existing ABI, such that the necessary symbols are still exported even when enable_driver_sdk is off? This option will, into the foreseeable future, only impact the installation of those header files? If that's the case, we can just copy the header file into SPDK, as could anyone else that wants to continue using DPDK to implement out of tree drivers. Can you clarify if something like this scheme would be considered a supported use of DPDK?
Thanks,
Ben
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v12 00/12] Packet capture framework update
2021-10-12 18:00 3% ` Stephen Hemminger
@ 2021-10-12 18:22 0% ` Thomas Monjalon
2021-10-13 8:44 0% ` Pattan, Reshma
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2021-10-12 18:22 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Pattan, Reshma, dev, Richardson, Bruce, david.marchand
12/10/2021 20:00, Stephen Hemminger:
> On Tue, 12 Oct 2021 17:48:47 +0200
> Thomas Monjalon <thomas@monjalon.net> wrote:
> > 12/10/2021 17:44, Stephen Hemminger:
> > > On Tue, 12 Oct 2021 10:21:41 +0000
> > > "Pattan, Reshma" <reshma.pattan@intel.com> wrote:
> > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > >
> > > > > I was hoping to see a feedback from the current maintainer, but it seems you
> > > > > didn't Cc her... Reshma, are you aware of these patches?
> > > >
> > > > I was aware of v10 where I had comments, I will take a look at V12.
> > > > Yes, please add me to CC for future patch sets, that would help me to not miss them.
> > >
> > > This means we have a flawed process if patches can't get
> > > reviewed that have been submitted a month ahead of release.
> >
> > Part of the process, you are supposed to use "--cc-cmd devtools/get-maintainer.sh"
> > so maintainers are Cc'ed.
>
> Thought they were, look like Reshma got missed.
>
> No worries about doing in 22.02 since there is no API/ABI breakage in the
> patchset. No pre-release note needed either.
We can still merge it for 21.11 if Reshma is OK with the v12.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v12 00/12] Packet capture framework update
@ 2021-10-12 18:00 3% ` Stephen Hemminger
2021-10-12 18:22 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2021-10-12 18:00 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: Pattan, Reshma, dev, Richardson, Bruce, david.marchand
On Tue, 12 Oct 2021 17:48:47 +0200
Thomas Monjalon <thomas@monjalon.net> wrote:
> 12/10/2021 17:44, Stephen Hemminger:
> > On Tue, 12 Oct 2021 10:21:41 +0000
> > "Pattan, Reshma" <reshma.pattan@intel.com> wrote:
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > >
> > > > I was hoping to see a feedback from the current maintainer, but it seems you
> > > > didn't Cc her... Reshma, are you aware of these patches?
> > >
> > > I was aware of v10 where I had comments, I will take a look at V12.
> > > Yes, please add me to CC for future patch sets, that would help me to not miss them.
> >
> > This means we have a flawed process if patches can't get
> > reviewed that have been submitted a month ahead of release.
>
> Part of the process, you are supposed to use "--cc-cmd devtools/get-maintainer.sh"
> so maintainers are Cc'ed.
Thought they were, look like Reshma got missed.
No worries about doing in 22.02 since there is no API/ABI breakage in the
patchset. No pre-release note needed either.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 3/7] ethdev: change input parameters for rx_queue_count
2021-10-11 8:06 0% ` Andrew Rybchenko
@ 2021-10-12 17:59 0% ` Hyong Youb Kim (hyonkim)
1 sibling, 0 replies; 200+ results
From: Hyong Youb Kim (hyonkim) @ 2021-10-12 17:59 UTC (permalink / raw)
To: Konstantin Ananyev, dev
Cc: xiaoyun.li, anoobj, jerinj, ndabilpuram, adwivedi,
shepard.siegel, ed.czeck, john.miller, irusskikh, ajit.khaparde,
somnath.kotur, rahul.lakkireddy, hemant.agrawal, sachin.saxena,
haiyue.wang, John Daley (johndale),
qi.z.zhang, xiao.w.wang, humin29, yisen.zhuang, oulijun,
beilei.xing, jingjing.wu, qiming.yang, matan, viacheslavo,
sthemmin, longli, heinrich.kuhn, kirankumark, andrew.rybchenko,
mczekaj, jiawenwu, jianwang, maxime.coquelin, chenbo.xia, thomas,
ferruh.yigit, mdr, jay.jayatheerthan
> -----Original Message-----
> From: Konstantin Ananyev <konstantin.ananyev@intel.com>
> Sent: Thursday, October 7, 2021 8:28 PM
[...]
> Subject: [PATCH v5 3/7] ethdev: change input parameters for
> rx_queue_count
>
> Currently majority of fast-path ethdev ops take pointers to internal
> queue data structures as an input parameter.
> While eth_rx_queue_count() takes a pointer to rte_eth_dev and queue
> index.
> For future work to hide rte_eth_devices[] and friends it would be
> plausible to unify parameters list of all fast-path ethdev ops.
> This patch changes eth_rx_queue_count() to accept pointer to internal
> queue data as input parameter.
> While this change is transparent to user, it still counts as an ABI change,
> as eth_rx_queue_count_t is used by ethdev public inline function
> rte_eth_rx_queue_count().
>
> Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> ---
For net/enic,
Acked-by: Hyong Youb Kim <hyonkim@cisco.com>
Thanks.
-Hyong
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v1 1/6] bbdev: add capability for CRC16 check
2021-10-12 16:36 4% ` Chautru, Nicolas
@ 2021-10-12 16:59 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2021-10-12 16:59 UTC (permalink / raw)
To: Chautru, Nicolas
Cc: gakhil, dev, trix, hemant.agrawal, Zhang, Mingshan, Yigit, Ferruh
12/10/2021 18:36, Chautru, Nicolas:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 11/10/2021 22:38, Chautru, Nicolas:
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > 13/08/2021 18:51, Nicolas Chautru:
> > > > > Adding a missing operation when CRC16 is being used for TB CRC
> > > > > check.
> > > > >
> > > > > Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
> > > > > ---
> > > > > --- a/doc/guides/rel_notes/release_21_11.rst
> > > > > +++ b/doc/guides/rel_notes/release_21_11.rst
> > > > > @@ -84,6 +84,7 @@ API Changes
> > > > > Also, make sure to start the actual text at the margin.
> > > > >
> > =======================================================
> > > > >
> > > > > +* bbdev: Added capability related to more comprehensive CRC
> > options.
> > > >
> > > > That's not an API change, the enum symbols are the same.
> > > > Only enum values are changed so it impacts only ABI.
> > >
> > > Hi Thomas,
> > > How is that not a API change when new additional capability are exposed?
> > Ie. new enums defined for new capabilities.
> >
> > API change is when the app source code has to be updated.
>
> Thanks. What you are referring to may be strictly API breakage as opposed to generic API change. I would expect an API change could be either backward compatible (extending API but application only has to change if it wants to use the new functionality) vs an actual API breakage (application needs to change regardless even to keep same functionality as before).
Yes
An API change which does not break is a new feature, so it is referenced
at the beginning of the release notes in general.
> In case the intent is to use the 2 terms interchangeably (change vs breakage) then I agree that these 2 bbdev changes do not constitute an API breakage (only ABI).
> It might be good to capture this more explicitly except if you believe this is obvious (doc describes ABI change, not API change). Regardless for next time I will use that distinction (change == breakage).
Yes feel free to send a patch to rename "change" to 'breakage".
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v1 1/6] bbdev: add capability for CRC16 check
2021-10-12 6:53 3% ` Thomas Monjalon
@ 2021-10-12 16:36 4% ` Chautru, Nicolas
2021-10-12 16:59 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Chautru, Nicolas @ 2021-10-12 16:36 UTC (permalink / raw)
To: Thomas Monjalon
Cc: gakhil, dev, trix, hemant.agrawal, Zhang, Mingshan, Yigit, Ferruh
Hi Thomas,
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Monday, October 11, 2021 11:53 PM
> To: Chautru, Nicolas <nicolas.chautru@intel.com>
> Cc: gakhil@marvell.com; dev@dpdk.org; trix@redhat.com;
> hemant.agrawal@nxp.com; Zhang, Mingshan <mingshan.zhang@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v1 1/6] bbdev: add capability for CRC16
> check
>
> 11/10/2021 22:38, Chautru, Nicolas:
> > From: Thomas Monjalon <thomas@monjalon.net>
> > > 13/08/2021 18:51, Nicolas Chautru:
> > > > Adding a missing operation when CRC16 is being used for TB CRC
> > > > check.
> > > >
> > > > Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
> > > > ---
> > > > --- a/doc/guides/rel_notes/release_21_11.rst
> > > > +++ b/doc/guides/rel_notes/release_21_11.rst
> > > > @@ -84,6 +84,7 @@ API Changes
> > > > Also, make sure to start the actual text at the margin.
> > > >
> =======================================================
> > > >
> > > > +* bbdev: Added capability related to more comprehensive CRC
> options.
> > >
> > > That's not an API change, the enum symbols are the same.
> > > Only enum values are changed so it impacts only ABI.
> >
> > Hi Thomas,
> > How is that not a API change when new additional capability are exposed?
> Ie. new enums defined for new capabilities.
>
> API change is when the app source code has to be updated.
Thanks. What you are referring to may be strictly API breakage as opposed to generic API change. I would expect an API change could be either backward compatible (extending API but application only has to change if it wants to use the new functionality) vs an actual API breakage (application needs to change regardless even to keep same functionality as before).
In case the intent is to use the 2 terms interchangeably (change vs breakage) then I agree that these 2 bbdev changes do not constitute an API breakage (only ABI).
It might be good to capture this more explicitly except if you believe this is obvious (doc describes ABI change, not API change). Regardless for next time I will use that distinction (change == breakage).
Thanks
> ABI change is when the app binary has to be rebuilt.
>
> > I think I see other similar cases in the same release notes " * cryptodev:
> ``RTE_CRYPTO_AEAD_LIST_END`` from ``enum rte_crypto_aead_algo ...".
>
> I don't see this one.
>
> > You know best, just checking the intent, maybe worth clarifying the
> guideline except in case this is just me.
>
> Given my explanation above, how would you classify your change?
>
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [EXT] Re: [PATCH v2 1/3] cryptodev: remove LIST_END enumerators
2021-10-12 14:47 0% ` Kinsella, Ray
@ 2021-10-12 15:06 0% ` Thomas Monjalon
2021-10-13 5:36 0% ` Anoob Joseph
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2021-10-12 15:06 UTC (permalink / raw)
To: Anoob Joseph, Akhil Goyal, dev, Kinsella, Ray
Cc: david.marchand, hemant.agrawal, pablo.de.lara.guarch,
fiona.trahe, declan.doherty, matan, g.singh, roy.fan.zhang,
jianjay.zhou, asomalap, ruifeng.wang, konstantin.ananyev,
radu.nicolau, ajit.khaparde, Nagadheeraj Rottela, Ankur Dwivedi,
ciara.power, Stephen Hemminger, Yigit, Ferruh, bruce.richardson
12/10/2021 16:47, Kinsella, Ray:
> On 12/10/2021 15:18, Anoob Joseph wrote:
> > From: Thomas Monjalon <thomas@monjalon.net>
> >> 12/10/2021 15:38, Anoob Joseph:
> >>> From: Thomas Monjalon <thomas@monjalon.net>
> >>>> 12/10/2021 13:34, Anoob Joseph:
> >>>>> From: Kinsella, Ray <mdr@ashroe.eu>
> >>>>>> On 12/10/2021 11:50, Anoob Joseph wrote:
> >>>>>>> From: Akhil Goyal <gakhil@marvell.com>
> >>>>>>>>> On 08/10/2021 21:45, Akhil Goyal wrote:
> >>>>>>>>>> Remove *_LIST_END enumerators from asymmetric crypto lib to
> >>>>>>>>>> avoid ABI breakage for every new addition in enums.
> >>>>>>>>>>
> >>>>>>>>>> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> >>>>>>>>>> ---
> >>>>>>>>>> - } else if (xform->xform_type >=
> >>>>>>>>> RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
> >>>>>>>>>> + } else if (xform->xform_type >
> >>>> RTE_CRYPTO_ASYM_XFORM_ECPM
> >>>> [...]
> >>>>>>>>>
> >>>>>>>>> So I am not sure that this is an improvement.
> >>>>
> >>>> Indeed, it is not an improvement.
> >>>>
> >>>>>>>>> The cryptodev issue we had, was that _LIST_END was being
> >>>>>>>>> used to size arrays.
> >>>>>>>>> And that broke when new algorithms got added. Is that an
> >>>>>>>>> issue, in this
> >>>>>> case?
> >>>>>>>>
> >>>>>>>> Yes we did this same exercise for symmetric crypto enums earlier.
> >>>>>>>> Asym enums were left as it was experimental at that point.
> >>>>>>>> They are still experimental, but thought of making this
> >>>>>>>> uniform throughout DPDK enums.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I am not sure that swapping out _LIST_END, and then
> >>>>>>>>> littering the code with RTE_CRYPTO_ASYM_XFORM_ECPM and
> >>>>>>>>> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE, is an
> >>>> improvement
> >>>>>>>> here.
> >>>>>>>>>
> >>>>>>>>> My 2c is that from an ABI PoV RTE_CRYPTO_ASYM_OP_LIST_END is
> >>>>>>>>> not better or worse, than
> >>>>>> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE?
> >>>>>>>>>
> >>>>>>>>> Interested to hear other thoughts.
> >>>>>>>>
> >>>>>>>> I don’t have any better solution for avoiding ABI issues for now.
> >>>>>>>> The change is for avoiding ABI breakage. But we can drop this
> >>>>>>>> patch For now as asym is still experimental.
> >>>>>>>
> >>>>>>> [Anoob] Having LIST_END would preclude new additions to
> >>>>>>> asymmetric
> >>>> algos?
> >>>>>> If yes, then I would suggest we address it now.
> >>>>>>
> >>>>>> Not at all - but it can be problematic, if two versions of DPDK
> >>>>>> disagree with the value of LIST_END.
> >>>>>>
> >>>>>>> Looking at the "problematic changes", we only have 2-3
> >>>>>>> application & PMD changes. For unit test application, we could
> >>>>>>> may be do something like,
> >>>>>>
> >>>>>> The essental functionality not that different, I am just not
> >>>>>> sure that the verbosity below is helping.
> >>>>>> What you are really trying to guard against is people using
> >>>>>> LIST_END to size arrays.
> >>>>>
> >>>>> [Anoob] Our problem is application using LIST_END (which comes
> >>>>> from library)
> >>>> to determine the number of iterations for the loop. My suggestion is
> >>>> to modify the UT such that, we could use RTE_DIM(types) (which comes
> >>>> from application) to determine iterations of loop. This would solve the
> >> problem, right?
> >>>>
> >>>> The problem is not the application.
> >>>> Are you asking the app to define DPDK types?
> >>>
> >>> [Anoob] I didn't understand how you concluded that.
> >>
> >> Because you define a specific array in the test app.
> >>
> >>> The app is supposed to test "n" asymmetric features supported by DPDK.
> >> Currently, it does that by looping from 0 to LIST_END which happens to give you
> >> the first n features. Now, if we add any new asymmetric feature, LIST_END
> >> value would change. Isn't that the very reason why we removed LIST_END from
> >> symmetric library and applications?
> >>
> >> Yes
> >>
> >>> Now coming to what I proposed, the app is supposed to test "n" asymmetric
> >> features. LIST_END helps in doing the loops. If we remove LIST_END, then
> >> application will not be in a position to do a loop. My suggestion is, we list the
> >> types that are supposed to be tested by the app, and let that array be used as
> >> feature list.
> >>>
> >>> PS: Just to reiterate, my proposal is just a local array which would hold DPDK
> >> defined RTE enum values for the features that would be tested by this
> >> app/function.
> >>
> >> I am more concerned by the general case than the test app.
> >> I think a function returning a number is more app-friendly.
> >
> > [Anoob] Indeed. But there are 3 LIST_ENDs removed with this patch. Do you propose 3 new APIs to just get max number?
>
> 1 API returning a single "info" structure perhaps - as being the most extensible?
Or 3 iterators (foreach construct).
Instead of just returning a size, we can have an iterator for each enum
which needs to be iterated.
Feel free to consider the alternative which fits the best in cryptodev.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [EXT] Re: [PATCH v2 1/3] cryptodev: remove LIST_END enumerators
2021-10-12 14:18 0% ` Anoob Joseph
@ 2021-10-12 14:47 0% ` Kinsella, Ray
2021-10-12 15:06 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Kinsella, Ray @ 2021-10-12 14:47 UTC (permalink / raw)
To: Anoob Joseph, Thomas Monjalon, Akhil Goyal, dev
Cc: david.marchand, hemant.agrawal, pablo.de.lara.guarch,
fiona.trahe, declan.doherty, matan, g.singh, roy.fan.zhang,
jianjay.zhou, asomalap, ruifeng.wang, konstantin.ananyev,
radu.nicolau, ajit.khaparde, Nagadheeraj Rottela, Ankur Dwivedi,
ciara.power, Stephen Hemminger, Yigit, Ferruh, bruce.richardson
On 12/10/2021 15:18, Anoob Joseph wrote:
> Hi Thomas,
>
> Please see inline.
>
> Thanks,
> Anoob
>
>> -----Original Message-----
>> From: Thomas Monjalon <thomas@monjalon.net>
>> Sent: Tuesday, October 12, 2021 7:25 PM
>> To: Kinsella, Ray <mdr@ashroe.eu>; Akhil Goyal <gakhil@marvell.com>;
>> dev@dpdk.org; Anoob Joseph <anoobj@marvell.com>
>> Cc: david.marchand@redhat.com; hemant.agrawal@nxp.com;
>> pablo.de.lara.guarch@intel.com; fiona.trahe@intel.com;
>> declan.doherty@intel.com; matan@nvidia.com; g.singh@nxp.com;
>> roy.fan.zhang@intel.com; jianjay.zhou@huawei.com; asomalap@amd.com;
>> ruifeng.wang@arm.com; konstantin.ananyev@intel.com;
>> radu.nicolau@intel.com; ajit.khaparde@broadcom.com; Nagadheeraj Rottela
>> <rnagadheeraj@marvell.com>; Ankur Dwivedi <adwivedi@marvell.com>;
>> ciara.power@intel.com; Stephen Hemminger <stephen@networkplumber.org>;
>> Yigit, Ferruh <ferruh.yigit@intel.com>; bruce.richardson@intel.com
>> Subject: Re: [EXT] Re: [dpdk-dev] [PATCH v2 1/3] cryptodev: remove LIST_END
>> enumerators
>>
>> 12/10/2021 15:38, Anoob Joseph:
>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>> 12/10/2021 13:34, Anoob Joseph:
>>>>> From: Kinsella, Ray <mdr@ashroe.eu>
>>>>>> On 12/10/2021 11:50, Anoob Joseph wrote:
>>>>>>> From: Akhil Goyal <gakhil@marvell.com>
>>>>>>>>> On 08/10/2021 21:45, Akhil Goyal wrote:
>>>>>>>>>> Remove *_LIST_END enumerators from asymmetric crypto lib to
>>>>>>>>>> avoid ABI breakage for every new addition in enums.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
>>>>>>>>>> ---
>>>>>>>>>> - } else if (xform->xform_type >=
>>>>>>>>> RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
>>>>>>>>>> + } else if (xform->xform_type >
>>>> RTE_CRYPTO_ASYM_XFORM_ECPM
>>>> [...]
>>>>>>>>>
>>>>>>>>> So I am not sure that this is an improvement.
>>>>
>>>> Indeed, it is not an improvement.
>>>>
>>>>>>>>> The cryptodev issue we had, was that _LIST_END was being
>>>>>>>>> used to size arrays.
>>>>>>>>> And that broke when new algorithms got added. Is that an
>>>>>>>>> issue, in this
>>>>>> case?
>>>>>>>>
>>>>>>>> Yes we did this same exercise for symmetric crypto enums earlier.
>>>>>>>> Asym enums were left as it was experimental at that point.
>>>>>>>> They are still experimental, but thought of making this
>>>>>>>> uniform throughout DPDK enums.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I am not sure that swapping out _LIST_END, and then
>>>>>>>>> littering the code with RTE_CRYPTO_ASYM_XFORM_ECPM and
>>>>>>>>> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE, is an
>>>> improvement
>>>>>>>> here.
>>>>>>>>>
>>>>>>>>> My 2c is that from an ABI PoV RTE_CRYPTO_ASYM_OP_LIST_END is
>>>>>>>>> not better or worse, than
>>>>>> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE?
>>>>>>>>>
>>>>>>>>> Interested to hear other thoughts.
>>>>>>>>
>>>>>>>> I don’t have any better solution for avoiding ABI issues for now.
>>>>>>>> The change is for avoiding ABI breakage. But we can drop this
>>>>>>>> patch For now as asym is still experimental.
>>>>>>>
>>>>>>> [Anoob] Having LIST_END would preclude new additions to
>>>>>>> asymmetric
>>>> algos?
>>>>>> If yes, then I would suggest we address it now.
>>>>>>
>>>>>> Not at all - but it can be problematic, if two versions of DPDK
>>>>>> disagree with the value of LIST_END.
>>>>>>
>>>>>>> Looking at the "problematic changes", we only have 2-3
>>>>>>> application & PMD changes. For unit test application, we could
>>>>>>> may be do something like,
>>>>>>
>>>>>> The essental functionality not that different, I am just not
>>>>>> sure that the verbosity below is helping.
>>>>>> What you are really trying to guard against is people using
>>>>>> LIST_END to size arrays.
>>>>>
>>>>> [Anoob] Our problem is application using LIST_END (which comes
>>>>> from library)
>>>> to determine the number of iterations for the loop. My suggestion is
>>>> to modify the UT such that, we could use RTE_DIM(types) (which comes
>>>> from application) to determine iterations of loop. This would solve the
>> problem, right?
>>>>
>>>> The problem is not the application.
>>>> Are you asking the app to define DPDK types?
>>>
>>> [Anoob] I didn't understand how you concluded that.
>>
>> Because you define a specific array in the test app.
>>
>>> The app is supposed to test "n" asymmetric features supported by DPDK.
>> Currently, it does that by looping from 0 to LIST_END which happens to give you
>> the first n features. Now, if we add any new asymmetric feature, LIST_END
>> value would change. Isn't that the very reason why we removed LIST_END from
>> symmetric library and applications?
>>
>> Yes
>>
>>> Now coming to what I proposed, the app is supposed to test "n" asymmetric
>> features. LIST_END helps in doing the loops. If we remove LIST_END, then
>> application will not be in a position to do a loop. My suggestion is, we list the
>> types that are supposed to be tested by the app, and let that array be used as
>> feature list.
>>>
>>> PS: Just to reiterate, my proposal is just a local array which would hold DPDK
>> defined RTE enum values for the features that would be tested by this
>> app/function.
>>
>> I am more concerned by the general case than the test app.
>> I think a function returning a number is more app-friendly.
>
> [Anoob] Indeed. But there are 3 LIST_ENDs removed with this patch. Do you propose 3 new APIs to just get max number?
1 API returning a single "info" structure perhaps - as being the most extensible?
>
>>
>>>>>>> + enum rte_crypto_asym_op_type types[] = {
>>>
>>>>
>>>> The problem is in DPDK API. We must not suggest a size for enums.
>>>
>>> [Anoob] So agreed that LIST_END should be removed?
>>
>> Yes
>>
>>>> If we really need a size, then it must be explicit and updated in
>>>> the lib binary (through a function) when the size increases.
>>>
>>> [Anoob] Precisely my thoughts. The loop with LIST_END done in application is
>> not correct.
>>>>
>>>>
>>>>
>>>>>>> - for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
>>>>>>> + enum rte_crypto_asym_op_type types[] = {
>>>>>>> + RTE_CRYPTO_ASYM_OP_ENCRYPT,
>>>>>>> + RTE_CRYPTO_ASYM_OP_DECRYPT,
>>>>>>> + RTE_CRYPTO_ASYM_OP_SIGN,
>>>>>>> + RTE_CRYPTO_ASYM_OP_VERIFY,
>>>>>>> + RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE,
>>>>>>> + RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE,
>>>>>>> +
>> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE,
>>>>>>> + };
>>>>>>> + for (i = 0; i <= RTE_DIM(types); i++) {
>>>>>>> if (tc.modex.xform_type ==
>>>> RTE_CRYPTO_ASYM_XFORM_RSA) {
>>>>>>> - if (tc.rsa_data.op_type_flags & (1 << i)) {
>>>>>>> + if (tc.rsa_data.op_type_flags
>>>>>>> + & (1 <<
>>>>>>> + types[i])) {
>>>>>>> if (tc.rsa_data.key_exp) {
>>>>>>> status = test_cryptodev_asym_op(
>>>>>>> &testsuite_params, &tc,
>>>>>>> - test_msg, sessionless, i,
>>>>>>> +
>>>>>>> + test_msg, sessionless, types[i],
>>>>>>> RTE_RSA_KEY_TYPE_EXP);
>>>>>>> }
>>>>>>> if (status)
>>>>>>> break;
>>>>>>> - if (tc.rsa_data.key_qt && (i ==
>>>>>>> + if (tc.rsa_data.key_qt
>>>>>>> + && (types[i] ==
>>>>>>> RTE_CRYPTO_ASYM_OP_DECRYPT ||
>>>>>>> - i == RTE_CRYPTO_ASYM_OP_SIGN)) {
>>>>>>> +
>>>>>>> + types[i] ==
>>>>>>> + RTE_CRYPTO_ASYM_OP_SIGN)) {
>>>>>>> status = test_cryptodev_asym_op(
>>>>>>> &testsuite_params,
>>>>>>> - &tc, test_msg, sessionless, i,
>>>>>>> + &tc,
>>>>>>> + test_msg, sessionless, types[i],
>>>>>>> RTE_RSA_KET_TYPE_QT);
>>>>>>> }
>>>>>>> if (status)
>>>>>>>
>>>>>>> This way, application would only use the ones which it is
>>>>>>> designed to work
>>>>>> with. For QAT driver changes, we could have an overload if
>>>>>> condition (if alg == x
>>>>>> || alg = y || ...) to get the same effect.
>>
>>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [EXT] Re: [PATCH v2 1/3] cryptodev: remove LIST_END enumerators
2021-10-12 13:54 0% ` Thomas Monjalon
@ 2021-10-12 14:18 0% ` Anoob Joseph
2021-10-12 14:47 0% ` Kinsella, Ray
0 siblings, 1 reply; 200+ results
From: Anoob Joseph @ 2021-10-12 14:18 UTC (permalink / raw)
To: Thomas Monjalon, Kinsella, Ray, Akhil Goyal, dev
Cc: david.marchand, hemant.agrawal, pablo.de.lara.guarch,
fiona.trahe, declan.doherty, matan, g.singh, roy.fan.zhang,
jianjay.zhou, asomalap, ruifeng.wang, konstantin.ananyev,
radu.nicolau, ajit.khaparde, Nagadheeraj Rottela, Ankur Dwivedi,
ciara.power, Stephen Hemminger, Yigit, Ferruh, bruce.richardson
Hi Thomas,
Please see inline.
Thanks,
Anoob
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Tuesday, October 12, 2021 7:25 PM
> To: Kinsella, Ray <mdr@ashroe.eu>; Akhil Goyal <gakhil@marvell.com>;
> dev@dpdk.org; Anoob Joseph <anoobj@marvell.com>
> Cc: david.marchand@redhat.com; hemant.agrawal@nxp.com;
> pablo.de.lara.guarch@intel.com; fiona.trahe@intel.com;
> declan.doherty@intel.com; matan@nvidia.com; g.singh@nxp.com;
> roy.fan.zhang@intel.com; jianjay.zhou@huawei.com; asomalap@amd.com;
> ruifeng.wang@arm.com; konstantin.ananyev@intel.com;
> radu.nicolau@intel.com; ajit.khaparde@broadcom.com; Nagadheeraj Rottela
> <rnagadheeraj@marvell.com>; Ankur Dwivedi <adwivedi@marvell.com>;
> ciara.power@intel.com; Stephen Hemminger <stephen@networkplumber.org>;
> Yigit, Ferruh <ferruh.yigit@intel.com>; bruce.richardson@intel.com
> Subject: Re: [EXT] Re: [dpdk-dev] [PATCH v2 1/3] cryptodev: remove LIST_END
> enumerators
>
> 12/10/2021 15:38, Anoob Joseph:
> > From: Thomas Monjalon <thomas@monjalon.net>
> > > 12/10/2021 13:34, Anoob Joseph:
> > > > From: Kinsella, Ray <mdr@ashroe.eu>
> > > > > On 12/10/2021 11:50, Anoob Joseph wrote:
> > > > > > From: Akhil Goyal <gakhil@marvell.com>
> > > > > >>> On 08/10/2021 21:45, Akhil Goyal wrote:
> > > > > >>>> Remove *_LIST_END enumerators from asymmetric crypto lib to
> > > > > >>>> avoid ABI breakage for every new addition in enums.
> > > > > >>>>
> > > > > >>>> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> > > > > >>>> ---
> > > > > >>>> - } else if (xform->xform_type >=
> > > > > >>> RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
> > > > > >>>> + } else if (xform->xform_type >
> > > RTE_CRYPTO_ASYM_XFORM_ECPM
> > > [...]
> > > > > >>>
> > > > > >>> So I am not sure that this is an improvement.
> > >
> > > Indeed, it is not an improvement.
> > >
> > > > > >>> The cryptodev issue we had, was that _LIST_END was being
> > > > > >>> used to size arrays.
> > > > > >>> And that broke when new algorithms got added. Is that an
> > > > > >>> issue, in this
> > > > > case?
> > > > > >>
> > > > > >> Yes we did this same exercise for symmetric crypto enums earlier.
> > > > > >> Asym enums were left as it was experimental at that point.
> > > > > >> They are still experimental, but thought of making this
> > > > > >> uniform throughout DPDK enums.
> > > > > >>
> > > > > >>>
> > > > > >>> I am not sure that swapping out _LIST_END, and then
> > > > > >>> littering the code with RTE_CRYPTO_ASYM_XFORM_ECPM and
> > > > > >>> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE, is an
> > > improvement
> > > > > >> here.
> > > > > >>>
> > > > > >>> My 2c is that from an ABI PoV RTE_CRYPTO_ASYM_OP_LIST_END is
> > > > > >>> not better or worse, than
> > > > > RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE?
> > > > > >>>
> > > > > >>> Interested to hear other thoughts.
> > > > > >>
> > > > > >> I don’t have any better solution for avoiding ABI issues for now.
> > > > > >> The change is for avoiding ABI breakage. But we can drop this
> > > > > >> patch For now as asym is still experimental.
> > > > > >
> > > > > > [Anoob] Having LIST_END would preclude new additions to
> > > > > > asymmetric
> > > algos?
> > > > > If yes, then I would suggest we address it now.
> > > > >
> > > > > Not at all - but it can be problematic, if two versions of DPDK
> > > > > disagree with the value of LIST_END.
> > > > >
> > > > > > Looking at the "problematic changes", we only have 2-3
> > > > > > application & PMD changes. For unit test application, we could
> > > > > > may be do something like,
> > > > >
> > > > > The essental functionality not that different, I am just not
> > > > > sure that the verbosity below is helping.
> > > > > What you are really trying to guard against is people using
> > > > > LIST_END to size arrays.
> > > >
> > > > [Anoob] Our problem is application using LIST_END (which comes
> > > > from library)
> > > to determine the number of iterations for the loop. My suggestion is
> > > to modify the UT such that, we could use RTE_DIM(types) (which comes
> > > from application) to determine iterations of loop. This would solve the
> problem, right?
> > >
> > > The problem is not the application.
> > > Are you asking the app to define DPDK types?
> >
> > [Anoob] I didn't understand how you concluded that.
>
> Because you define a specific array in the test app.
>
> > The app is supposed to test "n" asymmetric features supported by DPDK.
> Currently, it does that by looping from 0 to LIST_END which happens to give you
> the first n features. Now, if we add any new asymmetric feature, LIST_END
> value would change. Isn't that the very reason why we removed LIST_END from
> symmetric library and applications?
>
> Yes
>
> > Now coming to what I proposed, the app is supposed to test "n" asymmetric
> features. LIST_END helps in doing the loops. If we remove LIST_END, then
> application will not be in a position to do a loop. My suggestion is, we list the
> types that are supposed to be tested by the app, and let that array be used as
> feature list.
> >
> > PS: Just to reiterate, my proposal is just a local array which would hold DPDK
> defined RTE enum values for the features that would be tested by this
> app/function.
>
> I am more concerned by the general case than the test app.
> I think a function returning a number is more app-friendly.
[Anoob] Indeed. But there are 3 LIST_ENDs removed with this patch. Do you propose 3 new APIs to just get max number?
>
> > > > > > + enum rte_crypto_asym_op_type types[] = {
> >
> > >
> > > The problem is in DPDK API. We must not suggest a size for enums.
> >
> > [Anoob] So agreed that LIST_END should be removed?
>
> Yes
>
> > > If we really need a size, then it must be explicit and updated in
> > > the lib binary (through a function) when the size increases.
> >
> > [Anoob] Precisely my thoughts. The loop with LIST_END done in application is
> not correct.
> > >
> > >
> > >
> > > > > > - for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
> > > > > > + enum rte_crypto_asym_op_type types[] = {
> > > > > > + RTE_CRYPTO_ASYM_OP_ENCRYPT,
> > > > > > + RTE_CRYPTO_ASYM_OP_DECRYPT,
> > > > > > + RTE_CRYPTO_ASYM_OP_SIGN,
> > > > > > + RTE_CRYPTO_ASYM_OP_VERIFY,
> > > > > > + RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE,
> > > > > > + RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE,
> > > > > > +
> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE,
> > > > > > + };
> > > > > > + for (i = 0; i <= RTE_DIM(types); i++) {
> > > > > > if (tc.modex.xform_type ==
> > > RTE_CRYPTO_ASYM_XFORM_RSA) {
> > > > > > - if (tc.rsa_data.op_type_flags & (1 << i)) {
> > > > > > + if (tc.rsa_data.op_type_flags
> > > > > > + & (1 <<
> > > > > > + types[i])) {
> > > > > > if (tc.rsa_data.key_exp) {
> > > > > > status = test_cryptodev_asym_op(
> > > > > > &testsuite_params, &tc,
> > > > > > - test_msg, sessionless, i,
> > > > > > +
> > > > > > + test_msg, sessionless, types[i],
> > > > > > RTE_RSA_KEY_TYPE_EXP);
> > > > > > }
> > > > > > if (status)
> > > > > > break;
> > > > > > - if (tc.rsa_data.key_qt && (i ==
> > > > > > + if (tc.rsa_data.key_qt
> > > > > > + && (types[i] ==
> > > > > > RTE_CRYPTO_ASYM_OP_DECRYPT ||
> > > > > > - i == RTE_CRYPTO_ASYM_OP_SIGN)) {
> > > > > > +
> > > > > > + types[i] ==
> > > > > > + RTE_CRYPTO_ASYM_OP_SIGN)) {
> > > > > > status = test_cryptodev_asym_op(
> > > > > > &testsuite_params,
> > > > > > - &tc, test_msg, sessionless, i,
> > > > > > + &tc,
> > > > > > + test_msg, sessionless, types[i],
> > > > > > RTE_RSA_KET_TYPE_QT);
> > > > > > }
> > > > > > if (status)
> > > > > >
> > > > > > This way, application would only use the ones which it is
> > > > > > designed to work
> > > > > with. For QAT driver changes, we could have an overload if
> > > > > condition (if alg == x
> > > > > || alg = y || ...) to get the same effect.
>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [EXT] Re: [PATCH v2 1/3] cryptodev: remove LIST_END enumerators
2021-10-12 13:38 0% ` Anoob Joseph
@ 2021-10-12 13:54 0% ` Thomas Monjalon
2021-10-12 14:18 0% ` Anoob Joseph
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2021-10-12 13:54 UTC (permalink / raw)
To: Kinsella, Ray, Akhil Goyal, dev, Anoob Joseph
Cc: david.marchand, hemant.agrawal, pablo.de.lara.guarch,
fiona.trahe, declan.doherty, matan, g.singh, roy.fan.zhang,
jianjay.zhou, asomalap, ruifeng.wang, konstantin.ananyev,
radu.nicolau, ajit.khaparde, Nagadheeraj Rottela, Ankur Dwivedi,
ciara.power, Stephen Hemminger, Yigit, Ferruh, bruce.richardson
12/10/2021 15:38, Anoob Joseph:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 12/10/2021 13:34, Anoob Joseph:
> > > From: Kinsella, Ray <mdr@ashroe.eu>
> > > > On 12/10/2021 11:50, Anoob Joseph wrote:
> > > > > From: Akhil Goyal <gakhil@marvell.com>
> > > > >>> On 08/10/2021 21:45, Akhil Goyal wrote:
> > > > >>>> Remove *_LIST_END enumerators from asymmetric crypto lib to
> > > > >>>> avoid ABI breakage for every new addition in enums.
> > > > >>>>
> > > > >>>> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> > > > >>>> ---
> > > > >>>> - } else if (xform->xform_type >=
> > > > >>> RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
> > > > >>>> + } else if (xform->xform_type >
> > RTE_CRYPTO_ASYM_XFORM_ECPM
> > [...]
> > > > >>>
> > > > >>> So I am not sure that this is an improvement.
> >
> > Indeed, it is not an improvement.
> >
> > > > >>> The cryptodev issue we had, was that _LIST_END was being used to
> > > > >>> size arrays.
> > > > >>> And that broke when new algorithms got added. Is that an issue,
> > > > >>> in this
> > > > case?
> > > > >>
> > > > >> Yes we did this same exercise for symmetric crypto enums earlier.
> > > > >> Asym enums were left as it was experimental at that point.
> > > > >> They are still experimental, but thought of making this uniform
> > > > >> throughout DPDK enums.
> > > > >>
> > > > >>>
> > > > >>> I am not sure that swapping out _LIST_END, and then littering
> > > > >>> the code with RTE_CRYPTO_ASYM_XFORM_ECPM and
> > > > >>> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE, is an
> > improvement
> > > > >> here.
> > > > >>>
> > > > >>> My 2c is that from an ABI PoV RTE_CRYPTO_ASYM_OP_LIST_END is not
> > > > >>> better or worse, than
> > > > RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE?
> > > > >>>
> > > > >>> Interested to hear other thoughts.
> > > > >>
> > > > >> I don’t have any better solution for avoiding ABI issues for now.
> > > > >> The change is for avoiding ABI breakage. But we can drop this
> > > > >> patch For now as asym is still experimental.
> > > > >
> > > > > [Anoob] Having LIST_END would preclude new additions to asymmetric
> > algos?
> > > > If yes, then I would suggest we address it now.
> > > >
> > > > Not at all - but it can be problematic, if two versions of DPDK
> > > > disagree with the value of LIST_END.
> > > >
> > > > > Looking at the "problematic changes", we only have 2-3 application
> > > > > & PMD changes. For unit test application, we could may be do
> > > > > something like,
> > > >
> > > > The essental functionality not that different, I am just not sure
> > > > that the verbosity below is helping.
> > > > What you are really trying to guard against is people using LIST_END
> > > > to size arrays.
> > >
> > > [Anoob] Our problem is application using LIST_END (which comes from library)
> > to determine the number of iterations for the loop. My suggestion is to modify
> > the UT such that, we could use RTE_DIM(types) (which comes from application)
> > to determine iterations of loop. This would solve the problem, right?
> >
> > The problem is not the application.
> > Are you asking the app to define DPDK types?
>
> [Anoob] I didn't understand how you concluded that.
Because you define a specific array in the test app.
> The app is supposed to test "n" asymmetric features supported by DPDK. Currently, it does that by looping from 0 to LIST_END which happens to give you the first n features. Now, if we add any new asymmetric feature, LIST_END value would change. Isn't that the very reason why we removed LIST_END from symmetric library and applications?
Yes
> Now coming to what I proposed, the app is supposed to test "n" asymmetric features. LIST_END helps in doing the loops. If we remove LIST_END, then application will not be in a position to do a loop. My suggestion is, we list the types that are supposed to be tested by the app, and let that array be used as feature list.
>
> PS: Just to reiterate, my proposal is just a local array which would hold DPDK defined RTE enum values for the features that would be tested by this app/function.
I am more concerned by the general case than the test app.
I think a function returning a number is more app-friendly.
> > > > > + enum rte_crypto_asym_op_type types[] = {
>
> >
> > The problem is in DPDK API. We must not suggest a size for enums.
>
> [Anoob] So agreed that LIST_END should be removed?
Yes
> > If we really need a size, then it must be explicit and updated in the lib binary
> > (through a function) when the size increases.
>
> [Anoob] Precisely my thoughts. The loop with LIST_END done in application is not correct.
> >
> >
> >
> > > > > - for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
> > > > > + enum rte_crypto_asym_op_type types[] = {
> > > > > + RTE_CRYPTO_ASYM_OP_ENCRYPT,
> > > > > + RTE_CRYPTO_ASYM_OP_DECRYPT,
> > > > > + RTE_CRYPTO_ASYM_OP_SIGN,
> > > > > + RTE_CRYPTO_ASYM_OP_VERIFY,
> > > > > + RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE,
> > > > > + RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE,
> > > > > + RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE,
> > > > > + };
> > > > > + for (i = 0; i <= RTE_DIM(types); i++) {
> > > > > if (tc.modex.xform_type ==
> > RTE_CRYPTO_ASYM_XFORM_RSA) {
> > > > > - if (tc.rsa_data.op_type_flags & (1 << i)) {
> > > > > + if (tc.rsa_data.op_type_flags & (1
> > > > > + <<
> > > > > + types[i])) {
> > > > > if (tc.rsa_data.key_exp) {
> > > > > status = test_cryptodev_asym_op(
> > > > > &testsuite_params, &tc,
> > > > > - test_msg, sessionless, i,
> > > > > + test_msg,
> > > > > + sessionless, types[i],
> > > > > RTE_RSA_KEY_TYPE_EXP);
> > > > > }
> > > > > if (status)
> > > > > break;
> > > > > - if (tc.rsa_data.key_qt && (i ==
> > > > > + if (tc.rsa_data.key_qt &&
> > > > > + (types[i] ==
> > > > > RTE_CRYPTO_ASYM_OP_DECRYPT ||
> > > > > - i == RTE_CRYPTO_ASYM_OP_SIGN)) {
> > > > > + types[i]
> > > > > + ==
> > > > > + RTE_CRYPTO_ASYM_OP_SIGN)) {
> > > > > status = test_cryptodev_asym_op(
> > > > > &testsuite_params,
> > > > > - &tc, test_msg, sessionless, i,
> > > > > + &tc,
> > > > > + test_msg, sessionless, types[i],
> > > > > RTE_RSA_KET_TYPE_QT);
> > > > > }
> > > > > if (status)
> > > > >
> > > > > This way, application would only use the ones which it is designed
> > > > > to work
> > > > with. For QAT driver changes, we could have an overload if condition
> > > > (if alg == x
> > > > || alg = y || ...) to get the same effect.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [EXT] Re: [PATCH v2 1/3] cryptodev: remove LIST_END enumerators
2021-10-12 11:52 0% ` Thomas Monjalon
@ 2021-10-12 13:38 0% ` Anoob Joseph
2021-10-12 13:54 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Anoob Joseph @ 2021-10-12 13:38 UTC (permalink / raw)
To: Thomas Monjalon, Kinsella, Ray, Akhil Goyal, dev
Cc: david.marchand, hemant.agrawal, pablo.de.lara.guarch,
fiona.trahe, declan.doherty, matan, g.singh, roy.fan.zhang,
jianjay.zhou, asomalap, ruifeng.wang, konstantin.ananyev,
radu.nicolau, ajit.khaparde, Nagadheeraj Rottela, Ankur Dwivedi,
ciara.power, Stephen Hemminger, Yigit, Ferruh
Hi Thomas,
Please see inline.
Thanks,
Anoob
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Tuesday, October 12, 2021 5:22 PM
> To: Kinsella, Ray <mdr@ashroe.eu>; Akhil Goyal <gakhil@marvell.com>;
> dev@dpdk.org; Anoob Joseph <anoobj@marvell.com>
> Cc: david.marchand@redhat.com; hemant.agrawal@nxp.com;
> pablo.de.lara.guarch@intel.com; fiona.trahe@intel.com;
> declan.doherty@intel.com; matan@nvidia.com; g.singh@nxp.com;
> roy.fan.zhang@intel.com; jianjay.zhou@huawei.com; asomalap@amd.com;
> ruifeng.wang@arm.com; konstantin.ananyev@intel.com;
> radu.nicolau@intel.com; ajit.khaparde@broadcom.com; Nagadheeraj Rottela
> <rnagadheeraj@marvell.com>; Ankur Dwivedi <adwivedi@marvell.com>;
> ciara.power@intel.com; Stephen Hemminger <stephen@networkplumber.org>;
> Yigit, Ferruh <ferruh.yigit@intel.com>
> Subject: Re: [EXT] Re: [dpdk-dev] [PATCH v2 1/3] cryptodev: remove LIST_END
> enumerators
>
> 12/10/2021 13:34, Anoob Joseph:
> > From: Kinsella, Ray <mdr@ashroe.eu>
> > > On 12/10/2021 11:50, Anoob Joseph wrote:
> > > > From: Akhil Goyal <gakhil@marvell.com>
> > > >>> On 08/10/2021 21:45, Akhil Goyal wrote:
> > > >>>> Remove *_LIST_END enumerators from asymmetric crypto lib to
> > > >>>> avoid ABI breakage for every new addition in enums.
> > > >>>>
> > > >>>> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> > > >>>> ---
> > > >>>> - } else if (xform->xform_type >=
> > > >>> RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
> > > >>>> + } else if (xform->xform_type >
> RTE_CRYPTO_ASYM_XFORM_ECPM
> [...]
> > > >>>
> > > >>> So I am not sure that this is an improvement.
>
> Indeed, it is not an improvement.
>
> > > >>> The cryptodev issue we had, was that _LIST_END was being used to
> > > >>> size arrays.
> > > >>> And that broke when new algorithms got added. Is that an issue,
> > > >>> in this
> > > case?
> > > >>
> > > >> Yes we did this same exercise for symmetric crypto enums earlier.
> > > >> Asym enums were left as it was experimental at that point.
> > > >> They are still experimental, but thought of making this uniform
> > > >> throughout DPDK enums.
> > > >>
> > > >>>
> > > >>> I am not sure that swapping out _LIST_END, and then littering
> > > >>> the code with RTE_CRYPTO_ASYM_XFORM_ECPM and
> > > >>> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE, is an
> improvement
> > > >> here.
> > > >>>
> > > >>> My 2c is that from an ABI PoV RTE_CRYPTO_ASYM_OP_LIST_END is not
> > > >>> better or worse, than
> > > RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE?
> > > >>>
> > > >>> Interested to hear other thoughts.
> > > >>
> > > >> I don’t have any better solution for avoiding ABI issues for now.
> > > >> The change is for avoiding ABI breakage. But we can drop this
> > > >> patch For now as asym is still experimental.
> > > >
> > > > [Anoob] Having LIST_END would preclude new additions to asymmetric
> algos?
> > > If yes, then I would suggest we address it now.
> > >
> > > Not at all - but it can be problematic, if two versions of DPDK
> > > disagree with the value of LIST_END.
> > >
> > > > Looking at the "problematic changes", we only have 2-3 application
> > > > & PMD changes. For unit test application, we could may be do
> > > > something like,
> > >
> > > The essental functionality not that different, I am just not sure
> > > that the verbosity below is helping.
> > > What you are really trying to guard against is people using LIST_END
> > > to size arrays.
> >
> > [Anoob] Our problem is application using LIST_END (which comes from library)
> to determine the number of iterations for the loop. My suggestion is to modify
> the UT such that, we could use RTE_DIM(types) (which comes from application)
> to determine iterations of loop. This would solve the problem, right?
>
> The problem is not the application.
> Are you asking the app to define DPDK types?
[Anoob] I didn't understand how you concluded that. The app is supposed to test "n" asymmetric features supported by DPDK. Currently, it does that by looping from 0 to LIST_END which happens to give you the first n features. Now, if we add any new asymmetric feature, LIST_END value would change. Isn't that the very reason why we removed LIST_END from symmetric library and applications?
Now coming to what I proposed, the app is supposed to test "n" asymmetric features. LIST_END helps in doing the loops. If we remove LIST_END, then application will not be in a position to do a loop. My suggestion is, we list the types that are supposed to be tested by the app, and let that array be used as feature list.
PS: Just to reiterate, my proposal is just a local array which would hold DPDK defined RTE enum values for the features that would be tested by this app/function.
> > > > + enum rte_crypto_asym_op_type types[] = {
>
> The problem is in DPDK API. We must not suggest a size for enums.
[Anoob] So agreed that LIST_END should be removed?
> If we really need a size, then it must be explicit and updated in the lib binary
> (through a function) when the size increases.
[Anoob] Precisely my thoughts. The loop with LIST_END done in application is not correct.
>
>
>
> > > > - for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
> > > > + enum rte_crypto_asym_op_type types[] = {
> > > > + RTE_CRYPTO_ASYM_OP_ENCRYPT,
> > > > + RTE_CRYPTO_ASYM_OP_DECRYPT,
> > > > + RTE_CRYPTO_ASYM_OP_SIGN,
> > > > + RTE_CRYPTO_ASYM_OP_VERIFY,
> > > > + RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE,
> > > > + RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE,
> > > > + RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE,
> > > > + };
> > > > + for (i = 0; i <= RTE_DIM(types); i++) {
> > > > if (tc.modex.xform_type ==
> RTE_CRYPTO_ASYM_XFORM_RSA) {
> > > > - if (tc.rsa_data.op_type_flags & (1 << i)) {
> > > > + if (tc.rsa_data.op_type_flags & (1
> > > > + <<
> > > > + types[i])) {
> > > > if (tc.rsa_data.key_exp) {
> > > > status = test_cryptodev_asym_op(
> > > > &testsuite_params, &tc,
> > > > - test_msg, sessionless, i,
> > > > + test_msg,
> > > > + sessionless, types[i],
> > > > RTE_RSA_KEY_TYPE_EXP);
> > > > }
> > > > if (status)
> > > > break;
> > > > - if (tc.rsa_data.key_qt && (i ==
> > > > + if (tc.rsa_data.key_qt &&
> > > > + (types[i] ==
> > > > RTE_CRYPTO_ASYM_OP_DECRYPT ||
> > > > - i == RTE_CRYPTO_ASYM_OP_SIGN)) {
> > > > + types[i]
> > > > + ==
> > > > + RTE_CRYPTO_ASYM_OP_SIGN)) {
> > > > status = test_cryptodev_asym_op(
> > > > &testsuite_params,
> > > > - &tc, test_msg, sessionless, i,
> > > > + &tc,
> > > > + test_msg, sessionless, types[i],
> > > > RTE_RSA_KET_TYPE_QT);
> > > > }
> > > > if (status)
> > > >
> > > > This way, application would only use the ones which it is designed
> > > > to work
> > > with. For QAT driver changes, we could have an overload if condition
> > > (if alg == x
> > > || alg = y || ...) to get the same effect.
>
>
>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v5] net: introduce IPv4 ihl and version fields
@ 2021-10-12 12:29 4% ` Gregory Etelson
2 siblings, 0 replies; 200+ results
From: Gregory Etelson @ 2021-10-12 12:29 UTC (permalink / raw)
To: dev, getelson
Cc: matan, rasland, olivier.matz, thomas, Bernard Iremonger, Ray Kinsella
RTE IPv4 header definition combines the `version' and `ihl' fields
into a single structure member.
This patch introduces dedicated structure members for both `version'
and `ihl' IPv4 fields. Separated header fields definitions allow to
create simplified code to match on the IHL value in a flow rule.
The original `version_ihl' structure member is kept for backward
compatibility.
The patch implements one of 2 announced changes to the
IPv4 header.
IPv4 header encodes fragment information into 16 bits field.
3 bits hold flags and remaining 13 bits are for fragment offset.
13 bits bit-field cannot be defined both for big and little endian
systems.
Signed-off-by: Gregory Etelson <getelson@nvidia.com>
Acked-by: Olivier Matz <olivier.matz@6wind.com>
---
v2: Add dependency.
v3: Add comments.
v4: Update release notes.
v5: Remove deprecation notice.
Update the patch comment.
---
app/test/test_flow_classify.c | 8 ++++----
doc/guides/rel_notes/deprecation.rst | 6 ------
doc/guides/rel_notes/release_21_11.rst | 3 +++
lib/net/rte_ip.h | 16 +++++++++++++++-
4 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/app/test/test_flow_classify.c b/app/test/test_flow_classify.c
index 951606f248..4f64be5357 100644
--- a/app/test/test_flow_classify.c
+++ b/app/test/test_flow_classify.c
@@ -95,7 +95,7 @@ static struct rte_acl_field_def ipv4_defs[NUM_FIELDS_IPV4] = {
* dst mask 255.255.255.00 / udp src is 32 dst is 33 / end"
*/
static struct rte_flow_item_ipv4 ipv4_udp_spec_1 = {
- { 0, 0, 0, 0, 0, 0, IPPROTO_UDP, 0,
+ { { .version_ihl = 0}, 0, 0, 0, 0, 0, IPPROTO_UDP, 0,
RTE_IPV4(2, 2, 2, 3), RTE_IPV4(2, 2, 2, 7)}
};
static const struct rte_flow_item_ipv4 ipv4_mask_24 = {
@@ -131,7 +131,7 @@ static struct rte_flow_item end_item = { RTE_FLOW_ITEM_TYPE_END,
* dst mask 255.255.255.00 / tcp src is 16 dst is 17 / end"
*/
static struct rte_flow_item_ipv4 ipv4_tcp_spec_1 = {
- { 0, 0, 0, 0, 0, 0, IPPROTO_TCP, 0,
+ { { .version_ihl = 0}, 0, 0, 0, 0, 0, IPPROTO_TCP, 0,
RTE_IPV4(1, 2, 3, 4), RTE_IPV4(5, 6, 7, 8)}
};
@@ -150,8 +150,8 @@ static struct rte_flow_item tcp_item_1 = { RTE_FLOW_ITEM_TYPE_TCP,
* dst mask 255.255.255.00 / sctp src is 16 dst is 17/ end"
*/
static struct rte_flow_item_ipv4 ipv4_sctp_spec_1 = {
- { 0, 0, 0, 0, 0, 0, IPPROTO_SCTP, 0, RTE_IPV4(11, 12, 13, 14),
- RTE_IPV4(15, 16, 17, 18)}
+ { { .version_ihl = 0}, 0, 0, 0, 0, 0, IPPROTO_SCTP, 0,
+ RTE_IPV4(11, 12, 13, 14), RTE_IPV4(15, 16, 17, 18)}
};
static struct rte_flow_item_sctp sctp_spec_1 = {
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index a2fe766d4b..040f4a8868 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -167,12 +167,6 @@ Deprecation Notices
* net: ``s_addr`` and ``d_addr`` fields of ``rte_ether_hdr`` structure
will be renamed in DPDK 21.11 to avoid conflict with Windows Sockets headers.
-* net: The structure ``rte_ipv4_hdr`` will have two unions.
- The first union is for existing ``version_ihl`` byte
- and new bitfield for version and IHL.
- The second union is for existing ``fragment_offset``
- and new bitfield for fragment flags and offset.
-
* vhost: ``rte_vdpa_register_device``, ``rte_vdpa_unregister_device``,
``rte_vhost_host_notifier_ctrl`` and ``rte_vdpa_relay_vring_used`` vDPA
driver interface will be marked as internal in DPDK v21.11.
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index dfc2cbdeed..4fb4a1dac4 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -187,6 +187,9 @@ API Changes
the crypto/security operation. This field will be used to communicate
events such as soft expiry with IPsec in lookaside mode.
+* net: Add ``version`` and ``ihl`` bit-fields to ``struct rte_ipv4_hdr``.
+ Existing ``version_ihl`` field was kept for backward compatibility.
+
ABI Changes
-----------
diff --git a/lib/net/rte_ip.h b/lib/net/rte_ip.h
index 05948b69b7..89a68d9433 100644
--- a/lib/net/rte_ip.h
+++ b/lib/net/rte_ip.h
@@ -38,7 +38,21 @@ extern "C" {
* IPv4 Header
*/
struct rte_ipv4_hdr {
- uint8_t version_ihl; /**< version and header length */
+ __extension__
+ union {
+ uint8_t version_ihl; /**< version and header length */
+ struct {
+#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
+ uint8_t ihl:4; /**< header length */
+ uint8_t version:4; /**< version */
+#elif RTE_BYTE_ORDER == RTE_BIG_ENDIAN
+ uint8_t version:4; /**< version */
+ uint8_t ihl:4; /**< header length */
+#else
+#error "setup endian definition"
+#endif
+ };
+ };
uint8_t type_of_service; /**< type of service */
rte_be16_t total_length; /**< length of packet */
rte_be16_t packet_id; /**< packet ID */
--
2.33.0
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [EXT] Re: [PATCH v2 1/3] cryptodev: remove LIST_END enumerators
2021-10-12 11:34 0% ` Anoob Joseph
@ 2021-10-12 11:52 0% ` Thomas Monjalon
2021-10-12 13:38 0% ` Anoob Joseph
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2021-10-12 11:52 UTC (permalink / raw)
To: Kinsella, Ray, Akhil Goyal, dev, Anoob Joseph
Cc: david.marchand, hemant.agrawal, pablo.de.lara.guarch,
fiona.trahe, declan.doherty, matan, g.singh, roy.fan.zhang,
jianjay.zhou, asomalap, ruifeng.wang, konstantin.ananyev,
radu.nicolau, ajit.khaparde, Nagadheeraj Rottela, Ankur Dwivedi,
ciara.power, Stephen Hemminger, Yigit, Ferruh
12/10/2021 13:34, Anoob Joseph:
> From: Kinsella, Ray <mdr@ashroe.eu>
> > On 12/10/2021 11:50, Anoob Joseph wrote:
> > > From: Akhil Goyal <gakhil@marvell.com>
> > >>> On 08/10/2021 21:45, Akhil Goyal wrote:
> > >>>> Remove *_LIST_END enumerators from asymmetric crypto lib to avoid
> > >>>> ABI breakage for every new addition in enums.
> > >>>>
> > >>>> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> > >>>> ---
> > >>>> - } else if (xform->xform_type >=
> > >>> RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
> > >>>> + } else if (xform->xform_type > RTE_CRYPTO_ASYM_XFORM_ECPM
[...]
> > >>>
> > >>> So I am not sure that this is an improvement.
Indeed, it is not an improvement.
> > >>> The cryptodev issue we had, was that _LIST_END was being used to
> > >>> size arrays.
> > >>> And that broke when new algorithms got added. Is that an issue, in this
> > case?
> > >>
> > >> Yes we did this same exercise for symmetric crypto enums earlier.
> > >> Asym enums were left as it was experimental at that point.
> > >> They are still experimental, but thought of making this uniform
> > >> throughout DPDK enums.
> > >>
> > >>>
> > >>> I am not sure that swapping out _LIST_END, and then littering the
> > >>> code with RTE_CRYPTO_ASYM_XFORM_ECPM and
> > >>> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE, is an improvement
> > >> here.
> > >>>
> > >>> My 2c is that from an ABI PoV RTE_CRYPTO_ASYM_OP_LIST_END is not
> > >>> better or worse, than
> > RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE?
> > >>>
> > >>> Interested to hear other thoughts.
> > >>
> > >> I don’t have any better solution for avoiding ABI issues for now.
> > >> The change is for avoiding ABI breakage. But we can drop this patch
> > >> For now as asym is still experimental.
> > >
> > > [Anoob] Having LIST_END would preclude new additions to asymmetric algos?
> > If yes, then I would suggest we address it now.
> >
> > Not at all - but it can be problematic, if two versions of DPDK disagree with the
> > value of LIST_END.
> >
> > > Looking at the "problematic changes", we only have 2-3 application &
> > > PMD changes. For unit test application, we could may be do something
> > > like,
> >
> > The essental functionality not that different, I am just not sure that the verbosity
> > below is helping.
> > What you are really trying to guard against is people using LIST_END to size
> > arrays.
>
> [Anoob] Our problem is application using LIST_END (which comes from library) to determine the number of iterations for the loop. My suggestion is to modify the UT such that, we could use RTE_DIM(types) (which comes from application) to determine iterations of loop. This would solve the problem, right?
The problem is not the application.
Are you asking the app to define DPDK types?
The problem is in DPDK API. We must not suggest a size for enums.
If we really need a size, then it must be explicit and updated in the lib binary
(through a function) when the size increases.
> > > - for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
> > > + enum rte_crypto_asym_op_type types[] = {
> > > + RTE_CRYPTO_ASYM_OP_ENCRYPT,
> > > + RTE_CRYPTO_ASYM_OP_DECRYPT,
> > > + RTE_CRYPTO_ASYM_OP_SIGN,
> > > + RTE_CRYPTO_ASYM_OP_VERIFY,
> > > + RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE,
> > > + RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE,
> > > + RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE,
> > > + };
> > > + for (i = 0; i <= RTE_DIM(types); i++) {
> > > if (tc.modex.xform_type == RTE_CRYPTO_ASYM_XFORM_RSA) {
> > > - if (tc.rsa_data.op_type_flags & (1 << i)) {
> > > + if (tc.rsa_data.op_type_flags & (1 <<
> > > + types[i])) {
> > > if (tc.rsa_data.key_exp) {
> > > status = test_cryptodev_asym_op(
> > > &testsuite_params, &tc,
> > > - test_msg, sessionless, i,
> > > + test_msg,
> > > + sessionless, types[i],
> > > RTE_RSA_KEY_TYPE_EXP);
> > > }
> > > if (status)
> > > break;
> > > - if (tc.rsa_data.key_qt && (i ==
> > > + if (tc.rsa_data.key_qt &&
> > > + (types[i] ==
> > > RTE_CRYPTO_ASYM_OP_DECRYPT ||
> > > - i == RTE_CRYPTO_ASYM_OP_SIGN)) {
> > > + types[i] ==
> > > + RTE_CRYPTO_ASYM_OP_SIGN)) {
> > > status = test_cryptodev_asym_op(
> > > &testsuite_params,
> > > - &tc, test_msg, sessionless, i,
> > > + &tc, test_msg,
> > > + sessionless, types[i],
> > > RTE_RSA_KET_TYPE_QT);
> > > }
> > > if (status)
> > >
> > > This way, application would only use the ones which it is designed to work
> > with. For QAT driver changes, we could have an overload if condition (if alg == x
> > || alg = y || ...) to get the same effect.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [EXT] Re: [PATCH v2 1/3] cryptodev: remove LIST_END enumerators
2021-10-12 11:28 0% ` Kinsella, Ray
@ 2021-10-12 11:34 0% ` Anoob Joseph
2021-10-12 11:52 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Anoob Joseph @ 2021-10-12 11:34 UTC (permalink / raw)
To: Kinsella, Ray, Akhil Goyal, dev
Cc: thomas, david.marchand, hemant.agrawal, pablo.de.lara.guarch,
fiona.trahe, declan.doherty, matan, g.singh, roy.fan.zhang,
jianjay.zhou, asomalap, ruifeng.wang, konstantin.ananyev,
radu.nicolau, ajit.khaparde, Nagadheeraj Rottela, Ankur Dwivedi,
ciara.power, Stephen Hemminger, Yigit, Ferruh
Hi Ray,
Please see inline.
Thanks,
Anoob
> -----Original Message-----
> From: Kinsella, Ray <mdr@ashroe.eu>
> Sent: Tuesday, October 12, 2021 4:58 PM
> To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal <gakhil@marvell.com>;
> dev@dpdk.org
> Cc: thomas@monjalon.net; david.marchand@redhat.com;
> hemant.agrawal@nxp.com; pablo.de.lara.guarch@intel.com;
> fiona.trahe@intel.com; declan.doherty@intel.com; matan@nvidia.com;
> g.singh@nxp.com; roy.fan.zhang@intel.com; jianjay.zhou@huawei.com;
> asomalap@amd.com; ruifeng.wang@arm.com; konstantin.ananyev@intel.com;
> radu.nicolau@intel.com; ajit.khaparde@broadcom.com; Nagadheeraj Rottela
> <rnagadheeraj@marvell.com>; Ankur Dwivedi <adwivedi@marvell.com>;
> ciara.power@intel.com; Stephen Hemminger <stephen@networkplumber.org>;
> Yigit, Ferruh <ferruh.yigit@intel.com>
> Subject: Re: [EXT] Re: [dpdk-dev] [PATCH v2 1/3] cryptodev: remove LIST_END
> enumerators
>
>
>
> On 12/10/2021 11:50, Anoob Joseph wrote:
> > Hi Ray, Akhil,
> >
> > Please see inline.
> >
> > Thanks,
> > Anoob
> >
> >> -----Original Message-----
> >> From: Akhil Goyal <gakhil@marvell.com>
> >> Sent: Tuesday, October 12, 2021 3:49 PM
> >> To: Kinsella, Ray <mdr@ashroe.eu>; dev@dpdk.org
> >> Cc: thomas@monjalon.net; david.marchand@redhat.com;
> >> hemant.agrawal@nxp.com; Anoob Joseph <anoobj@marvell.com>;
> >> pablo.de.lara.guarch@intel.com; fiona.trahe@intel.com;
> >> declan.doherty@intel.com; matan@nvidia.com; g.singh@nxp.com;
> >> roy.fan.zhang@intel.com; jianjay.zhou@huawei.com; asomalap@amd.com;
> >> ruifeng.wang@arm.com; konstantin.ananyev@intel.com;
> >> radu.nicolau@intel.com; ajit.khaparde@broadcom.com; Nagadheeraj
> >> Rottela <rnagadheeraj@marvell.com>; Ankur Dwivedi
> >> <adwivedi@marvell.com>; ciara.power@intel.com; Stephen Hemminger
> >> <stephen@networkplumber.org>; Yigit, Ferruh <ferruh.yigit@intel.com>
> >> Subject: RE: [EXT] Re: [dpdk-dev] [PATCH v2 1/3] cryptodev: remove
> >> LIST_END enumerators
> >>
> >>>
> >>> On 08/10/2021 21:45, Akhil Goyal wrote:
> >>>> Remove *_LIST_END enumerators from asymmetric crypto lib to avoid
> >>>> ABI breakage for every new addition in enums.
> >>>>
> >>>> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> >>>> ---
> >>>> v2: no change
> >>>>
> >>>> app/test/test_cryptodev_asym.c | 4 ++--
> >>>> drivers/crypto/qat/qat_asym.c | 2 +-
> >>>> lib/cryptodev/rte_crypto_asym.h | 4 ----
> >>>> 3 files changed, 3 insertions(+), 7 deletions(-)
> >>>>
> >>>> diff --git a/app/test/test_cryptodev_asym.c
> >>> b/app/test/test_cryptodev_asym.c
> >>>> index 9d19a6d6d9..603b2e4609 100644
> >>>> --- a/app/test/test_cryptodev_asym.c
> >>>> +++ b/app/test/test_cryptodev_asym.c
> >>>> @@ -541,7 +541,7 @@ test_one_case(const void *test_case, int
> >>> sessionless)
> >>>> printf(" %u) TestCase %s %s\n", test_index++,
> >>>> tc.modex.description, test_msg);
> >>>> } else {
> >>>> - for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
> >>>> + for (i = 0; i <=
> >>> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE; i++) {
> >>>> if (tc.modex.xform_type ==
> >>> RTE_CRYPTO_ASYM_XFORM_RSA) {
> >>>> if (tc.rsa_data.op_type_flags & (1 << i)) {
> >>>> if (tc.rsa_data.key_exp) {
> >>>> @@ -1027,7 +1027,7 @@ static inline void print_asym_capa(
> >>>> rte_crypto_asym_xform_strings[capa->xform_type]);
> >>>> printf("operation supported -");
> >>>>
> >>>> - for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
> >>>> + for (i = 0; i <= RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE;
> >>> i++) {
> >>>> /* check supported operations */
> >>>> if
> >>> (rte_cryptodev_asym_xform_capability_check_optype(capa, i))
> >>>> printf(" %s",
> >>>> diff --git a/drivers/crypto/qat/qat_asym.c
> >>>> b/drivers/crypto/qat/qat_asym.c index 85973812a8..026625a4d2 100644
> >>>> --- a/drivers/crypto/qat/qat_asym.c
> >>>> +++ b/drivers/crypto/qat/qat_asym.c
> >>>> @@ -742,7 +742,7 @@ qat_asym_session_configure(struct rte_cryptodev
> >>> *dev,
> >>>> err = -EINVAL;
> >>>> goto error;
> >>>> }
> >>>> - } else if (xform->xform_type >=
> >>> RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
> >>>> + } else if (xform->xform_type > RTE_CRYPTO_ASYM_XFORM_ECPM
> >>>> || xform->xform_type <=
> >>> RTE_CRYPTO_ASYM_XFORM_NONE) {
> >>>> QAT_LOG(ERR, "Invalid asymmetric crypto xform");
> >>>> err = -EINVAL;
> >>>> diff --git a/lib/cryptodev/rte_crypto_asym.h
> >>> b/lib/cryptodev/rte_crypto_asym.h
> >>>> index 9c866f553f..5edf658572 100644
> >>>> --- a/lib/cryptodev/rte_crypto_asym.h
> >>>> +++ b/lib/cryptodev/rte_crypto_asym.h
> >>>> @@ -94,8 +94,6 @@ enum rte_crypto_asym_xform_type {
> >>>> */
> >>>> RTE_CRYPTO_ASYM_XFORM_ECPM,
> >>>> /**< Elliptic Curve Point Multiplication */
> >>>> - RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
> >>>> - /**< End of list */
> >>>> };
> >>>>
> >>>> /**
> >>>> @@ -116,7 +114,6 @@ enum rte_crypto_asym_op_type {
> >>>> /**< DH Public Key generation operation */
> >>>> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE,
> >>>> /**< DH Shared Secret compute operation */
> >>>> - RTE_CRYPTO_ASYM_OP_LIST_END
> >>>> };
> >>>>
> >>>> /**
> >>>> @@ -133,7 +130,6 @@ enum rte_crypto_rsa_padding_type {
> >>>> /**< RSA PKCS#1 OAEP padding scheme */
> >>>> RTE_CRYPTO_RSA_PADDING_PSS,
> >>>> /**< RSA PKCS#1 PSS padding scheme */
> >>>> - RTE_CRYPTO_RSA_PADDING_TYPE_LIST_END
> >>>> };
> >>>>
> >>>> /**
> >>>
> >>> So I am not sure that this is an improvement.
> >>> The cryptodev issue we had, was that _LIST_END was being used to
> >>> size arrays.
> >>> And that broke when new algorithms got added. Is that an issue, in this
> case?
> >>
> >> Yes we did this same exercise for symmetric crypto enums earlier.
> >> Asym enums were left as it was experimental at that point.
> >> They are still experimental, but thought of making this uniform
> >> throughout DPDK enums.
> >>
> >>>
> >>> I am not sure that swapping out _LIST_END, and then littering the
> >>> code with RTE_CRYPTO_ASYM_XFORM_ECPM and
> >>> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE, is an improvement
> >> here.
> >>>
> >>> My 2c is that from an ABI PoV RTE_CRYPTO_ASYM_OP_LIST_END is not
> >>> better or worse, than
> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE?
> >>>
> >>> Interested to hear other thoughts.
> >>
> >> I don’t have any better solution for avoiding ABI issues for now.
> >> The change is for avoiding ABI breakage. But we can drop this patch
> >> For now as asym is still experimental.
> >
> > [Anoob] Having LIST_END would preclude new additions to asymmetric algos?
> If yes, then I would suggest we address it now.
>
> Not at all - but it can be problematic, if two versions of DPDK disagree with the
> value of LIST_END.
>
> > Looking at the "problematic changes", we only have 2-3 application &
> > PMD changes. For unit test application, we could may be do something
> > like,
>
> The essental functionality not that different, I am just not sure that the verbosity
> below is helping.
> What you are really trying to guard against is people using LIST_END to size
> arrays.
[Anoob] Our problem is application using LIST_END (which comes from library) to determine the number of iterations for the loop. My suggestion is to modify the UT such that, we could use RTE_DIM(types) (which comes from application) to determine iterations of loop. This would solve the problem, right?
>
> >
> > - for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
> > + enum rte_crypto_asym_op_type types[] = {
> > + RTE_CRYPTO_ASYM_OP_ENCRYPT,
> > + RTE_CRYPTO_ASYM_OP_DECRYPT,
> > + RTE_CRYPTO_ASYM_OP_SIGN,
> > + RTE_CRYPTO_ASYM_OP_VERIFY,
> > + RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE,
> > + RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE,
> > + RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE,
> > + };
> > + for (i = 0; i <= RTE_DIM(types); i++) {
> > if (tc.modex.xform_type == RTE_CRYPTO_ASYM_XFORM_RSA) {
> > - if (tc.rsa_data.op_type_flags & (1 << i)) {
> > + if (tc.rsa_data.op_type_flags & (1 <<
> > + types[i])) {
> > if (tc.rsa_data.key_exp) {
> > status = test_cryptodev_asym_op(
> > &testsuite_params, &tc,
> > - test_msg, sessionless, i,
> > + test_msg,
> > + sessionless, types[i],
> > RTE_RSA_KEY_TYPE_EXP);
> > }
> > if (status)
> > break;
> > - if (tc.rsa_data.key_qt && (i ==
> > + if (tc.rsa_data.key_qt &&
> > + (types[i] ==
> > RTE_CRYPTO_ASYM_OP_DECRYPT ||
> > - i == RTE_CRYPTO_ASYM_OP_SIGN)) {
> > + types[i] ==
> > + RTE_CRYPTO_ASYM_OP_SIGN)) {
> > status = test_cryptodev_asym_op(
> > &testsuite_params,
> > - &tc, test_msg, sessionless, i,
> > + &tc, test_msg,
> > + sessionless, types[i],
> > RTE_RSA_KET_TYPE_QT);
> > }
> > if (status)
> >
> > This way, application would only use the ones which it is designed to work
> with. For QAT driver changes, we could have an overload if condition (if alg == x
> || alg = y || ...) to get the same effect.
> >
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [EXT] Re: [PATCH v2 1/3] cryptodev: remove LIST_END enumerators
2021-10-12 10:50 0% ` Anoob Joseph
@ 2021-10-12 11:28 0% ` Kinsella, Ray
2021-10-12 11:34 0% ` Anoob Joseph
0 siblings, 1 reply; 200+ results
From: Kinsella, Ray @ 2021-10-12 11:28 UTC (permalink / raw)
To: Anoob Joseph, Akhil Goyal, dev
Cc: thomas, david.marchand, hemant.agrawal, pablo.de.lara.guarch,
fiona.trahe, declan.doherty, matan, g.singh, roy.fan.zhang,
jianjay.zhou, asomalap, ruifeng.wang, konstantin.ananyev,
radu.nicolau, ajit.khaparde, Nagadheeraj Rottela, Ankur Dwivedi,
ciara.power, Stephen Hemminger, Yigit, Ferruh
On 12/10/2021 11:50, Anoob Joseph wrote:
> Hi Ray, Akhil,
>
> Please see inline.
>
> Thanks,
> Anoob
>
>> -----Original Message-----
>> From: Akhil Goyal <gakhil@marvell.com>
>> Sent: Tuesday, October 12, 2021 3:49 PM
>> To: Kinsella, Ray <mdr@ashroe.eu>; dev@dpdk.org
>> Cc: thomas@monjalon.net; david.marchand@redhat.com;
>> hemant.agrawal@nxp.com; Anoob Joseph <anoobj@marvell.com>;
>> pablo.de.lara.guarch@intel.com; fiona.trahe@intel.com;
>> declan.doherty@intel.com; matan@nvidia.com; g.singh@nxp.com;
>> roy.fan.zhang@intel.com; jianjay.zhou@huawei.com; asomalap@amd.com;
>> ruifeng.wang@arm.com; konstantin.ananyev@intel.com;
>> radu.nicolau@intel.com; ajit.khaparde@broadcom.com; Nagadheeraj Rottela
>> <rnagadheeraj@marvell.com>; Ankur Dwivedi <adwivedi@marvell.com>;
>> ciara.power@intel.com; Stephen Hemminger <stephen@networkplumber.org>;
>> Yigit, Ferruh <ferruh.yigit@intel.com>
>> Subject: RE: [EXT] Re: [dpdk-dev] [PATCH v2 1/3] cryptodev: remove LIST_END
>> enumerators
>>
>>>
>>> On 08/10/2021 21:45, Akhil Goyal wrote:
>>>> Remove *_LIST_END enumerators from asymmetric crypto lib to avoid
>>>> ABI breakage for every new addition in enums.
>>>>
>>>> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
>>>> ---
>>>> v2: no change
>>>>
>>>> app/test/test_cryptodev_asym.c | 4 ++--
>>>> drivers/crypto/qat/qat_asym.c | 2 +-
>>>> lib/cryptodev/rte_crypto_asym.h | 4 ----
>>>> 3 files changed, 3 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/app/test/test_cryptodev_asym.c
>>> b/app/test/test_cryptodev_asym.c
>>>> index 9d19a6d6d9..603b2e4609 100644
>>>> --- a/app/test/test_cryptodev_asym.c
>>>> +++ b/app/test/test_cryptodev_asym.c
>>>> @@ -541,7 +541,7 @@ test_one_case(const void *test_case, int
>>> sessionless)
>>>> printf(" %u) TestCase %s %s\n", test_index++,
>>>> tc.modex.description, test_msg);
>>>> } else {
>>>> - for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
>>>> + for (i = 0; i <=
>>> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE; i++) {
>>>> if (tc.modex.xform_type ==
>>> RTE_CRYPTO_ASYM_XFORM_RSA) {
>>>> if (tc.rsa_data.op_type_flags & (1 << i)) {
>>>> if (tc.rsa_data.key_exp) {
>>>> @@ -1027,7 +1027,7 @@ static inline void print_asym_capa(
>>>> rte_crypto_asym_xform_strings[capa->xform_type]);
>>>> printf("operation supported -");
>>>>
>>>> - for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
>>>> + for (i = 0; i <= RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE;
>>> i++) {
>>>> /* check supported operations */
>>>> if
>>> (rte_cryptodev_asym_xform_capability_check_optype(capa, i))
>>>> printf(" %s",
>>>> diff --git a/drivers/crypto/qat/qat_asym.c
>>>> b/drivers/crypto/qat/qat_asym.c index 85973812a8..026625a4d2 100644
>>>> --- a/drivers/crypto/qat/qat_asym.c
>>>> +++ b/drivers/crypto/qat/qat_asym.c
>>>> @@ -742,7 +742,7 @@ qat_asym_session_configure(struct rte_cryptodev
>>> *dev,
>>>> err = -EINVAL;
>>>> goto error;
>>>> }
>>>> - } else if (xform->xform_type >=
>>> RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
>>>> + } else if (xform->xform_type > RTE_CRYPTO_ASYM_XFORM_ECPM
>>>> || xform->xform_type <=
>>> RTE_CRYPTO_ASYM_XFORM_NONE) {
>>>> QAT_LOG(ERR, "Invalid asymmetric crypto xform");
>>>> err = -EINVAL;
>>>> diff --git a/lib/cryptodev/rte_crypto_asym.h
>>> b/lib/cryptodev/rte_crypto_asym.h
>>>> index 9c866f553f..5edf658572 100644
>>>> --- a/lib/cryptodev/rte_crypto_asym.h
>>>> +++ b/lib/cryptodev/rte_crypto_asym.h
>>>> @@ -94,8 +94,6 @@ enum rte_crypto_asym_xform_type {
>>>> */
>>>> RTE_CRYPTO_ASYM_XFORM_ECPM,
>>>> /**< Elliptic Curve Point Multiplication */
>>>> - RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
>>>> - /**< End of list */
>>>> };
>>>>
>>>> /**
>>>> @@ -116,7 +114,6 @@ enum rte_crypto_asym_op_type {
>>>> /**< DH Public Key generation operation */
>>>> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE,
>>>> /**< DH Shared Secret compute operation */
>>>> - RTE_CRYPTO_ASYM_OP_LIST_END
>>>> };
>>>>
>>>> /**
>>>> @@ -133,7 +130,6 @@ enum rte_crypto_rsa_padding_type {
>>>> /**< RSA PKCS#1 OAEP padding scheme */
>>>> RTE_CRYPTO_RSA_PADDING_PSS,
>>>> /**< RSA PKCS#1 PSS padding scheme */
>>>> - RTE_CRYPTO_RSA_PADDING_TYPE_LIST_END
>>>> };
>>>>
>>>> /**
>>>
>>> So I am not sure that this is an improvement.
>>> The cryptodev issue we had, was that _LIST_END was being used to size
>>> arrays.
>>> And that broke when new algorithms got added. Is that an issue, in this case?
>>
>> Yes we did this same exercise for symmetric crypto enums earlier.
>> Asym enums were left as it was experimental at that point.
>> They are still experimental, but thought of making this uniform throughout DPDK
>> enums.
>>
>>>
>>> I am not sure that swapping out _LIST_END, and then littering the code
>>> with RTE_CRYPTO_ASYM_XFORM_ECPM and
>>> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE, is an improvement
>> here.
>>>
>>> My 2c is that from an ABI PoV RTE_CRYPTO_ASYM_OP_LIST_END is not
>>> better or worse, than RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE?
>>>
>>> Interested to hear other thoughts.
>>
>> I don’t have any better solution for avoiding ABI issues for now.
>> The change is for avoiding ABI breakage. But we can drop this patch For now as
>> asym is still experimental.
>
> [Anoob] Having LIST_END would preclude new additions to asymmetric algos? If yes, then I would suggest we address it now.
Not at all - but it can be problematic, if two versions of DPDK disagree with the value of LIST_END.
> Looking at the "problematic changes", we only have 2-3 application & PMD changes. For unit test application, we could may be do something like,
The essental functionality not that different, I am just not sure that the verbosity below is helping.
What you are really trying to guard against is people using LIST_END to size arrays.
>
> - for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
> + enum rte_crypto_asym_op_type types[] = {
> + RTE_CRYPTO_ASYM_OP_ENCRYPT,
> + RTE_CRYPTO_ASYM_OP_DECRYPT,
> + RTE_CRYPTO_ASYM_OP_SIGN,
> + RTE_CRYPTO_ASYM_OP_VERIFY,
> + RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE,
> + RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE,
> + RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE,
> + };
> + for (i = 0; i <= RTE_DIM(types); i++) {
> if (tc.modex.xform_type == RTE_CRYPTO_ASYM_XFORM_RSA) {
> - if (tc.rsa_data.op_type_flags & (1 << i)) {
> + if (tc.rsa_data.op_type_flags & (1 << types[i])) {
> if (tc.rsa_data.key_exp) {
> status = test_cryptodev_asym_op(
> &testsuite_params, &tc,
> - test_msg, sessionless, i,
> + test_msg, sessionless, types[i],
> RTE_RSA_KEY_TYPE_EXP);
> }
> if (status)
> break;
> - if (tc.rsa_data.key_qt && (i ==
> + if (tc.rsa_data.key_qt && (types[i] ==
> RTE_CRYPTO_ASYM_OP_DECRYPT ||
> - i == RTE_CRYPTO_ASYM_OP_SIGN)) {
> + types[i] == RTE_CRYPTO_ASYM_OP_SIGN)) {
> status = test_cryptodev_asym_op(
> &testsuite_params,
> - &tc, test_msg, sessionless, i,
> + &tc, test_msg, sessionless, types[i],
> RTE_RSA_KET_TYPE_QT);
> }
> if (status)
>
> This way, application would only use the ones which it is designed to work with. For QAT driver changes, we could have an overload if condition (if alg == x || alg = y || ...) to get the same effect.
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [EXT] Re: [PATCH v2 1/3] cryptodev: remove LIST_END enumerators
2021-10-12 10:19 4% ` [dpdk-dev] [EXT] " Akhil Goyal
@ 2021-10-12 10:50 0% ` Anoob Joseph
2021-10-12 11:28 0% ` Kinsella, Ray
0 siblings, 1 reply; 200+ results
From: Anoob Joseph @ 2021-10-12 10:50 UTC (permalink / raw)
To: Akhil Goyal, Kinsella, Ray, dev
Cc: thomas, david.marchand, hemant.agrawal, pablo.de.lara.guarch,
fiona.trahe, declan.doherty, matan, g.singh, roy.fan.zhang,
jianjay.zhou, asomalap, ruifeng.wang, konstantin.ananyev,
radu.nicolau, ajit.khaparde, Nagadheeraj Rottela, Ankur Dwivedi,
ciara.power, Stephen Hemminger, Yigit, Ferruh
Hi Ray, Akhil,
Please see inline.
Thanks,
Anoob
> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Tuesday, October 12, 2021 3:49 PM
> To: Kinsella, Ray <mdr@ashroe.eu>; dev@dpdk.org
> Cc: thomas@monjalon.net; david.marchand@redhat.com;
> hemant.agrawal@nxp.com; Anoob Joseph <anoobj@marvell.com>;
> pablo.de.lara.guarch@intel.com; fiona.trahe@intel.com;
> declan.doherty@intel.com; matan@nvidia.com; g.singh@nxp.com;
> roy.fan.zhang@intel.com; jianjay.zhou@huawei.com; asomalap@amd.com;
> ruifeng.wang@arm.com; konstantin.ananyev@intel.com;
> radu.nicolau@intel.com; ajit.khaparde@broadcom.com; Nagadheeraj Rottela
> <rnagadheeraj@marvell.com>; Ankur Dwivedi <adwivedi@marvell.com>;
> ciara.power@intel.com; Stephen Hemminger <stephen@networkplumber.org>;
> Yigit, Ferruh <ferruh.yigit@intel.com>
> Subject: RE: [EXT] Re: [dpdk-dev] [PATCH v2 1/3] cryptodev: remove LIST_END
> enumerators
>
> >
> > On 08/10/2021 21:45, Akhil Goyal wrote:
> > > Remove *_LIST_END enumerators from asymmetric crypto lib to avoid
> > > ABI breakage for every new addition in enums.
> > >
> > > Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> > > ---
> > > v2: no change
> > >
> > > app/test/test_cryptodev_asym.c | 4 ++--
> > > drivers/crypto/qat/qat_asym.c | 2 +-
> > > lib/cryptodev/rte_crypto_asym.h | 4 ----
> > > 3 files changed, 3 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/app/test/test_cryptodev_asym.c
> > b/app/test/test_cryptodev_asym.c
> > > index 9d19a6d6d9..603b2e4609 100644
> > > --- a/app/test/test_cryptodev_asym.c
> > > +++ b/app/test/test_cryptodev_asym.c
> > > @@ -541,7 +541,7 @@ test_one_case(const void *test_case, int
> > sessionless)
> > > printf(" %u) TestCase %s %s\n", test_index++,
> > > tc.modex.description, test_msg);
> > > } else {
> > > - for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
> > > + for (i = 0; i <=
> > RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE; i++) {
> > > if (tc.modex.xform_type ==
> > RTE_CRYPTO_ASYM_XFORM_RSA) {
> > > if (tc.rsa_data.op_type_flags & (1 << i)) {
> > > if (tc.rsa_data.key_exp) {
> > > @@ -1027,7 +1027,7 @@ static inline void print_asym_capa(
> > > rte_crypto_asym_xform_strings[capa->xform_type]);
> > > printf("operation supported -");
> > >
> > > - for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
> > > + for (i = 0; i <= RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE;
> > i++) {
> > > /* check supported operations */
> > > if
> > (rte_cryptodev_asym_xform_capability_check_optype(capa, i))
> > > printf(" %s",
> > > diff --git a/drivers/crypto/qat/qat_asym.c
> > > b/drivers/crypto/qat/qat_asym.c index 85973812a8..026625a4d2 100644
> > > --- a/drivers/crypto/qat/qat_asym.c
> > > +++ b/drivers/crypto/qat/qat_asym.c
> > > @@ -742,7 +742,7 @@ qat_asym_session_configure(struct rte_cryptodev
> > *dev,
> > > err = -EINVAL;
> > > goto error;
> > > }
> > > - } else if (xform->xform_type >=
> > RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
> > > + } else if (xform->xform_type > RTE_CRYPTO_ASYM_XFORM_ECPM
> > > || xform->xform_type <=
> > RTE_CRYPTO_ASYM_XFORM_NONE) {
> > > QAT_LOG(ERR, "Invalid asymmetric crypto xform");
> > > err = -EINVAL;
> > > diff --git a/lib/cryptodev/rte_crypto_asym.h
> > b/lib/cryptodev/rte_crypto_asym.h
> > > index 9c866f553f..5edf658572 100644
> > > --- a/lib/cryptodev/rte_crypto_asym.h
> > > +++ b/lib/cryptodev/rte_crypto_asym.h
> > > @@ -94,8 +94,6 @@ enum rte_crypto_asym_xform_type {
> > > */
> > > RTE_CRYPTO_ASYM_XFORM_ECPM,
> > > /**< Elliptic Curve Point Multiplication */
> > > - RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
> > > - /**< End of list */
> > > };
> > >
> > > /**
> > > @@ -116,7 +114,6 @@ enum rte_crypto_asym_op_type {
> > > /**< DH Public Key generation operation */
> > > RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE,
> > > /**< DH Shared Secret compute operation */
> > > - RTE_CRYPTO_ASYM_OP_LIST_END
> > > };
> > >
> > > /**
> > > @@ -133,7 +130,6 @@ enum rte_crypto_rsa_padding_type {
> > > /**< RSA PKCS#1 OAEP padding scheme */
> > > RTE_CRYPTO_RSA_PADDING_PSS,
> > > /**< RSA PKCS#1 PSS padding scheme */
> > > - RTE_CRYPTO_RSA_PADDING_TYPE_LIST_END
> > > };
> > >
> > > /**
> >
> > So I am not sure that this is an improvement.
> > The cryptodev issue we had, was that _LIST_END was being used to size
> > arrays.
> > And that broke when new algorithms got added. Is that an issue, in this case?
>
> Yes we did this same exercise for symmetric crypto enums earlier.
> Asym enums were left as it was experimental at that point.
> They are still experimental, but thought of making this uniform throughout DPDK
> enums.
>
> >
> > I am not sure that swapping out _LIST_END, and then littering the code
> > with RTE_CRYPTO_ASYM_XFORM_ECPM and
> > RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE, is an improvement
> here.
> >
> > My 2c is that from an ABI PoV RTE_CRYPTO_ASYM_OP_LIST_END is not
> > better or worse, than RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE?
> >
> > Interested to hear other thoughts.
>
> I don’t have any better solution for avoiding ABI issues for now.
> The change is for avoiding ABI breakage. But we can drop this patch For now as
> asym is still experimental.
[Anoob] Having LIST_END would preclude new additions to asymmetric algos? If yes, then I would suggest we address it now.
Looking at the "problematic changes", we only have 2-3 application & PMD changes. For unit test application, we could may be do something like,
- for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
+ enum rte_crypto_asym_op_type types[] = {
+ RTE_CRYPTO_ASYM_OP_ENCRYPT,
+ RTE_CRYPTO_ASYM_OP_DECRYPT,
+ RTE_CRYPTO_ASYM_OP_SIGN,
+ RTE_CRYPTO_ASYM_OP_VERIFY,
+ RTE_CRYPTO_ASYM_OP_PRIVATE_KEY_GENERATE,
+ RTE_CRYPTO_ASYM_OP_PUBLIC_KEY_GENERATE,
+ RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE,
+ };
+ for (i = 0; i <= RTE_DIM(types); i++) {
if (tc.modex.xform_type == RTE_CRYPTO_ASYM_XFORM_RSA) {
- if (tc.rsa_data.op_type_flags & (1 << i)) {
+ if (tc.rsa_data.op_type_flags & (1 << types[i])) {
if (tc.rsa_data.key_exp) {
status = test_cryptodev_asym_op(
&testsuite_params, &tc,
- test_msg, sessionless, i,
+ test_msg, sessionless, types[i],
RTE_RSA_KEY_TYPE_EXP);
}
if (status)
break;
- if (tc.rsa_data.key_qt && (i ==
+ if (tc.rsa_data.key_qt && (types[i] ==
RTE_CRYPTO_ASYM_OP_DECRYPT ||
- i == RTE_CRYPTO_ASYM_OP_SIGN)) {
+ types[i] == RTE_CRYPTO_ASYM_OP_SIGN)) {
status = test_cryptodev_asym_op(
&testsuite_params,
- &tc, test_msg, sessionless, i,
+ &tc, test_msg, sessionless, types[i],
RTE_RSA_KET_TYPE_QT);
}
if (status)
This way, application would only use the ones which it is designed to work with. For QAT driver changes, we could have an overload if condition (if alg == x || alg = y || ...) to get the same effect.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v4 1/5] ethdev: update modify field flow action
@ 2021-10-12 10:49 3% ` Viacheslav Ovsiienko
0 siblings, 0 replies; 200+ results
From: Viacheslav Ovsiienko @ 2021-10-12 10:49 UTC (permalink / raw)
To: dev; +Cc: rasland, matan, shahafs, orika, getelson, thomas
The generic modify field flow action introduced in [1] has
some issues related to the immediate source operand:
- immediate source can be presented either as an unsigned
64-bit integer or pointer to data pattern in memory.
There was no explicit pointer field defined in the union.
- the byte ordering for 64-bit integer was not specified.
Many fields have shorter lengths and byte ordering
is crucial.
- how the bit offset is applied to the immediate source
field was not defined and documented.
- 64-bit integer size is not enough to provide IPv6
addresses.
In order to cover the issues and exclude any ambiguities
the following is done:
- introduce the explicit pointer field
in rte_flow_action_modify_data structure
- replace the 64-bit unsigned integer with 16-byte array
- update the modify field flow action documentation
Appropriate deprecation notice has been removed.
[1] commit 73b68f4c54a0 ("ethdev: introduce generic modify flow action")
Fixes: 2ba49b5f3721 ("doc: announce change to ethdev modify action data")
Signed-off-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
doc/guides/prog_guide/rte_flow.rst | 24 +++++++++++++++++++++++-
doc/guides/rel_notes/deprecation.rst | 4 ----
doc/guides/rel_notes/release_21_11.rst | 7 +++++++
lib/ethdev/rte_flow.h | 16 ++++++++++++----
4 files changed, 42 insertions(+), 9 deletions(-)
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 2b42d5ec8c..b08087511f 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -2835,6 +2835,22 @@ a packet to any other part of it.
``value`` sets an immediate value to be used as a source or points to a
location of the value in memory. It is used instead of ``level`` and ``offset``
for ``RTE_FLOW_FIELD_VALUE`` and ``RTE_FLOW_FIELD_POINTER`` respectively.
+The data in memory should be presented exactly in the same byte order and
+length as in the relevant flow item, i.e. data for field with type
+``RTE_FLOW_FIELD_MAC_DST`` should follow the conventions of ``dst`` field
+in ``rte_flow_item_eth`` structure, with type ``RTE_FLOW_FIELD_IPV6_SRC`` -
+``rte_flow_item_ipv6`` conventions, and so on. If the field size is larger than
+16 bytes the pattern can be provided as pointer only.
+
+The bitfield extracted from the memory being applied as second operation
+parameter is defined by action width and by the destination field offset.
+Application should provide the data in immediate value memory (either as
+buffer or by pointer) exactly as item field without any applied explicit offset,
+and destination packet field (with specified width and bit offset) will be
+replaced by immediate source bits from the same bit offset. For example,
+to replace the third byte of MAC address with value 0x85, application should
+specify destination width as 8, destination offset as 16, and provide immediate
+value as sequence of bytes {xxx, xxx, 0x85, xxx, xxx, xxx}.
.. _table_rte_flow_action_modify_field:
@@ -2865,7 +2881,13 @@ for ``RTE_FLOW_FIELD_VALUE`` and ``RTE_FLOW_FIELD_POINTER`` respectively.
+---------------+----------------------------------------------------------+
| ``offset`` | number of bits to skip at the beginning |
+---------------+----------------------------------------------------------+
- | ``value`` | immediate value or a pointer to this value |
+ | ``value`` | immediate value buffer (source field only, not |
+ | | applicable to destination) for RTE_FLOW_FIELD_VALUE |
+ | | field type |
+ +---------------+----------------------------------------------------------+
+ | ``pvalue`` | pointer to immediate value data (source field only, not |
+ | | applicable to destination) for RTE_FLOW_FIELD_POINTER |
+ | | field type |
+---------------+----------------------------------------------------------+
Action: ``CONNTRACK``
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index a2fe766d4b..dee14077a5 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -120,10 +120,6 @@ Deprecation Notices
* ethdev: Announce moving from dedicated modify function for each field,
to using the general ``rte_flow_modify_field`` action.
-* ethdev: The struct ``rte_flow_action_modify_data`` will be modified
- to support modifying fields larger than 64 bits.
- In addition, documentation will be updated to clarify byte order.
-
* ethdev: Attribute ``shared`` of the ``struct rte_flow_action_count``
is deprecated and will be removed in DPDK 21.11. Shared counters should
be managed using shared actions API (``rte_flow_shared_action_create`` etc).
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index dfc2cbdeed..578c1206e7 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -187,6 +187,13 @@ API Changes
the crypto/security operation. This field will be used to communicate
events such as soft expiry with IPsec in lookaside mode.
+* ethdev: ``rte_flow_action_modify_data`` structure updated, immediate data
+ array is extended, data pointer field is explicitly added to union, the
+ action behavior is defined in more strict fashion and documentation updated.
+ The immediate value behavior has been changed, the entire immediate field
+ should be provided, and offset for immediate source bitfield is assigned
+ from destination one.
+
ABI Changes
-----------
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 7b1ed7f110..f14f77772b 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -3217,10 +3217,18 @@ struct rte_flow_action_modify_data {
uint32_t offset;
};
/**
- * Immediate value for RTE_FLOW_FIELD_VALUE or
- * memory address for RTE_FLOW_FIELD_POINTER.
+ * Immediate value for RTE_FLOW_FIELD_VALUE, presented in the
+ * same byte order and length as in relevant rte_flow_item_xxx.
+ * The immediate source bitfield offset is inherited from
+ * the destination's one.
*/
- uint64_t value;
+ uint8_t value[16];
+ /**
+ * Memory address for RTE_FLOW_FIELD_POINTER, memory layout
+ * should be the same as for relevant field in the
+ * rte_flow_item_xxx structure.
+ */
+ void *pvalue;
};
};
@@ -3240,7 +3248,7 @@ enum rte_flow_modify_op {
* RTE_FLOW_ACTION_TYPE_MODIFY_FIELD
*
* Modify a destination header field according to the specified
- * operation. Another packet field can be used as a source as well
+ * operation. Another field of the packet can be used as a source as well
* as tag, mark, metadata, immediate value or a pointer to it.
*/
struct rte_flow_action_modify_field {
--
2.18.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v1] eventdev/rx-adapter: add telemetry callbacks
2021-10-12 10:05 3% ` Kinsella, Ray
@ 2021-10-12 10:29 0% ` Kundapura, Ganapati
0 siblings, 0 replies; 200+ results
From: Kundapura, Ganapati @ 2021-10-12 10:29 UTC (permalink / raw)
To: Kinsella, Ray, Jerin Jacob, Thomas Monjalon
Cc: David Marchand, dpdk-dev, Jayatheerthan, Jay
Hi,
> -----Original Message-----
> From: Kinsella, Ray <mdr@ashroe.eu>
> Sent: 12 October 2021 15:35
> To: Jerin Jacob <jerinjacobk@gmail.com>; Thomas Monjalon
> <thomas@monjalon.net>
> Cc: Kundapura, Ganapati <ganapati.kundapura@intel.com>; David Marchand
> <david.marchand@redhat.com>; dpdk-dev <dev@dpdk.org>; Jayatheerthan, Jay
> <jay.jayatheerthan@intel.com>
> Subject: Re: [PATCH v1] eventdev/rx-adapter: add telemetry callbacks
>
>
>
> On 12/10/2021 10:26, Jerin Jacob wrote:
> > On Tue, Oct 12, 2021 at 2:40 PM Thomas Monjalon <thomas@monjalon.net>
> wrote:
> >>
> >> 12/10/2021 10:47, Jerin Jacob:
> >>> On Tue, Oct 12, 2021 at 2:05 PM Kundapura, Ganapati
> >>> <ganapati.kundapura@intel.com> wrote:
> >>>> From: Jerin Jacob <jerinjacobk@gmail.com>
> >>>>>> --- a/lib/eventdev/rte_event_eth_rx_adapter.h
> >>>>>> +++ b/lib/eventdev/rte_event_eth_rx_adapter.h
> >>>>>> @@ -216,6 +216,10 @@ struct rte_event_eth_rx_adapter_stats {
> >>>>>> /**< Eventdev enqueue count */
> >>>>>> uint64_t rx_enq_retry;
> >>>>>> /**< Eventdev enqueue retry count */
> >>>>>> + uint64_t rx_event_buf_count;
> >>>>>> + /**< Rx event buffered count */
> >>>>>> + uint64_t rx_event_buf_size;
> >>>>>
> >>>>>
> >>>>> Isn't ABI breakage? CI did not warn this. Isn't this a public structure?
> >>>> Please confirm if moving the above two members to end of the structure
> overcomes ABI breakage?
> >>>
> >>>
> >>> + @Ray Kinsella @Thomas Monjalon @David Marchand
> >>>
> >>> It will still break the ABI. IMO, Since it is an ABI breaking
> >>> release it is OK. If there are no other objections, Please move the
> >>> variable to end of the structure and update release notes for ABI
> >>> changes.
> >>
> >> Why moving since it breaks ABI anyway?
> >
> > There is no specific gain in keeping new additions in the middle of structure.
>
> 21.11 is an ABI breaking release, so move it where you like :-)
Posted new patch with the new struct members moved to the end of the struct,
updated release notes and review comments addressed.
>
> >> I think you can keep as is.
> >>
> >>
> >>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v8 03/10] security: add UDP params for IPsec NAT-T
2021-10-11 11:29 5% ` [dpdk-dev] [PATCH v8 03/10] security: add UDP params for IPsec NAT-T Radu Nicolau
@ 2021-10-12 10:24 0% ` Ananyev, Konstantin
0 siblings, 0 replies; 200+ results
From: Ananyev, Konstantin @ 2021-10-12 10:24 UTC (permalink / raw)
To: Nicolau, Radu, Ray Kinsella, Akhil Goyal, Doherty, Declan
Cc: dev, Medvedkin, Vladimir, Richardson, Bruce, Zhang, Roy Fan,
hemant.agrawal, anoobj, Sinha, Abhijit, Buckley, Daniel M,
marchana, ktejasree, matan
> Add support for specifying UDP port params for UDP encapsulation option.
> RFC3948 section-2.1 does not enforce using specific the UDP ports for
> UDP-Encapsulated ESP Header
>
> Signed-off-by: Declan Doherty <declan.doherty@intel.com>
> Signed-off-by: Radu Nicolau <radu.nicolau@intel.com>
> Signed-off-by: Abhijit Sinha <abhijit.sinha@intel.com>
> Signed-off-by: Daniel Martin Buckley <daniel.m.buckley@intel.com>
> Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
> Acked-by: Anoob Joseph <anoobj@marvell.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 5 ++---
> doc/guides/rel_notes/release_21_11.rst | 5 +++++
> lib/security/rte_security.h | 7 +++++++
> 3 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 8b7b0beee2..d24d69b669 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -210,9 +210,8 @@ Deprecation Notices
> pointer for the private data to the application which can be attached
> to the packet while enqueuing.
>
> -* security: The structure ``rte_security_ipsec_xform`` will be extended with
> - multiple fields: source and destination port of UDP encapsulation,
> - IPsec payload MSS (Maximum Segment Size).
> +* security: The structure ``rte_security_ipsec_xform`` will be extended with:
> + new field: IPsec payload MSS (Maximum Segment Size).
>
> * security: The IPsec SA config options ``struct rte_security_ipsec_sa_options``
> will be updated with new fields to support new features like IPsec inner
> diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
> index 8ac6632abf..1a29640eea 100644
> --- a/doc/guides/rel_notes/release_21_11.rst
> +++ b/doc/guides/rel_notes/release_21_11.rst
> @@ -238,6 +238,11 @@ ABI Changes
> application to start from an arbitrary ESN value for debug and SA lifetime
> enforcement purposes.
>
> +* security: A new structure ``udp`` was added in structure
> + ``rte_security_ipsec_xform`` to allow setting the source and destination ports
> + for UDP encapsulated IPsec traffic.
> +
> +
> Known Issues
> ------------
>
> diff --git a/lib/security/rte_security.h b/lib/security/rte_security.h
> index 371d64647a..b30425e206 100644
> --- a/lib/security/rte_security.h
> +++ b/lib/security/rte_security.h
> @@ -128,6 +128,11 @@ struct rte_security_ipsec_tunnel_param {
> };
> };
>
> +struct rte_security_ipsec_udp_param {
> + uint16_t sport;
> + uint16_t dport;
> +};
> +
> /**
> * IPsec Security Association option flags
> */
> @@ -288,6 +293,8 @@ struct rte_security_ipsec_xform {
> };
> } esn;
> /**< Extended Sequence Number */
> + struct rte_security_ipsec_udp_param udp;
> + /**< UDP parameters, ignored when udp_encap option not specified */
> };
>
> /**
> --
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> 2.25.1
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v8 01/10] security: add ESN field to ipsec_xform
2021-10-11 11:29 5% ` [dpdk-dev] [PATCH v8 01/10] security: add ESN field to ipsec_xform Radu Nicolau
@ 2021-10-12 10:23 0% ` Ananyev, Konstantin
0 siblings, 0 replies; 200+ results
From: Ananyev, Konstantin @ 2021-10-12 10:23 UTC (permalink / raw)
To: Nicolau, Radu, Ray Kinsella, Akhil Goyal, Doherty, Declan
Cc: dev, Medvedkin, Vladimir, Richardson, Bruce, Zhang, Roy Fan,
hemant.agrawal, anoobj, Sinha, Abhijit, Buckley, Daniel M,
marchana, ktejasree, matan
>
> Update ipsec_xform definition to include ESN field.
> This allows the application to control the ESN starting value.
>
> Signed-off-by: Declan Doherty <declan.doherty@intel.com>
> Signed-off-by: Radu Nicolau <radu.nicolau@intel.com>
> Signed-off-by: Abhijit Sinha <abhijit.sinha@intel.com>
> Signed-off-by: Daniel Martin Buckley <daniel.m.buckley@intel.com>
> Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
> Acked-by: Anoob Joseph <anoobj@marvell.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 2 +-
> doc/guides/rel_notes/release_21_11.rst | 4 ++++
> lib/security/rte_security.h | 8 ++++++++
> 3 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index baf15aa722..8b7b0beee2 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -212,7 +212,7 @@ Deprecation Notices
>
> * security: The structure ``rte_security_ipsec_xform`` will be extended with
> multiple fields: source and destination port of UDP encapsulation,
> - IPsec payload MSS (Maximum Segment Size), and ESN (Extended Sequence Number).
> + IPsec payload MSS (Maximum Segment Size).
>
> * security: The IPsec SA config options ``struct rte_security_ipsec_sa_options``
> will be updated with new fields to support new features like IPsec inner
> diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
> index c0a7f75518..401c6d453a 100644
> --- a/doc/guides/rel_notes/release_21_11.rst
> +++ b/doc/guides/rel_notes/release_21_11.rst
> @@ -229,6 +229,10 @@ ABI Changes
> ``rte_security_ipsec_xform`` to allow applications to configure SA soft
> and hard expiry limits. Limits can be either in number of packets or bytes.
>
> +* security: A new structure ``esn`` was added in structure
> + ``rte_security_ipsec_xform`` to set an initial ESN value. This permits
> + application to start from an arbitrary ESN value for debug and SA lifetime
> + enforcement purposes.
>
> Known Issues
> ------------
> diff --git a/lib/security/rte_security.h b/lib/security/rte_security.h
> index 2013e65e49..371d64647a 100644
> --- a/lib/security/rte_security.h
> +++ b/lib/security/rte_security.h
> @@ -280,6 +280,14 @@ struct rte_security_ipsec_xform {
> /**< Anti replay window size to enable sequence replay attack handling.
> * replay checking is disabled if the window size is 0.
> */
> + union {
> + uint64_t value;
> + struct {
> + uint32_t low;
> + uint32_t hi;
> + };
> + } esn;
> + /**< Extended Sequence Number */
> };
>
> /**
> --
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> 2.25.1
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [EXT] Re: [PATCH v2 1/3] cryptodev: remove LIST_END enumerators
2021-10-12 9:55 3% ` Kinsella, Ray
@ 2021-10-12 10:19 4% ` Akhil Goyal
2021-10-12 10:50 0% ` Anoob Joseph
0 siblings, 1 reply; 200+ results
From: Akhil Goyal @ 2021-10-12 10:19 UTC (permalink / raw)
To: Kinsella, Ray, dev
Cc: thomas, david.marchand, hemant.agrawal, Anoob Joseph,
pablo.de.lara.guarch, fiona.trahe, declan.doherty, matan,
g.singh, roy.fan.zhang, jianjay.zhou, asomalap, ruifeng.wang,
konstantin.ananyev, radu.nicolau, ajit.khaparde,
Nagadheeraj Rottela, Ankur Dwivedi, ciara.power,
Stephen Hemminger, Yigit, Ferruh
>
> On 08/10/2021 21:45, Akhil Goyal wrote:
> > Remove *_LIST_END enumerators from asymmetric crypto
> > lib to avoid ABI breakage for every new addition in
> > enums.
> >
> > Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> > ---
> > v2: no change
> >
> > app/test/test_cryptodev_asym.c | 4 ++--
> > drivers/crypto/qat/qat_asym.c | 2 +-
> > lib/cryptodev/rte_crypto_asym.h | 4 ----
> > 3 files changed, 3 insertions(+), 7 deletions(-)
> >
> > diff --git a/app/test/test_cryptodev_asym.c
> b/app/test/test_cryptodev_asym.c
> > index 9d19a6d6d9..603b2e4609 100644
> > --- a/app/test/test_cryptodev_asym.c
> > +++ b/app/test/test_cryptodev_asym.c
> > @@ -541,7 +541,7 @@ test_one_case(const void *test_case, int
> sessionless)
> > printf(" %u) TestCase %s %s\n", test_index++,
> > tc.modex.description, test_msg);
> > } else {
> > - for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
> > + for (i = 0; i <=
> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE; i++) {
> > if (tc.modex.xform_type ==
> RTE_CRYPTO_ASYM_XFORM_RSA) {
> > if (tc.rsa_data.op_type_flags & (1 << i)) {
> > if (tc.rsa_data.key_exp) {
> > @@ -1027,7 +1027,7 @@ static inline void print_asym_capa(
> > rte_crypto_asym_xform_strings[capa->xform_type]);
> > printf("operation supported -");
> >
> > - for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
> > + for (i = 0; i <= RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE;
> i++) {
> > /* check supported operations */
> > if
> (rte_cryptodev_asym_xform_capability_check_optype(capa, i))
> > printf(" %s",
> > diff --git a/drivers/crypto/qat/qat_asym.c b/drivers/crypto/qat/qat_asym.c
> > index 85973812a8..026625a4d2 100644
> > --- a/drivers/crypto/qat/qat_asym.c
> > +++ b/drivers/crypto/qat/qat_asym.c
> > @@ -742,7 +742,7 @@ qat_asym_session_configure(struct rte_cryptodev
> *dev,
> > err = -EINVAL;
> > goto error;
> > }
> > - } else if (xform->xform_type >=
> RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
> > + } else if (xform->xform_type > RTE_CRYPTO_ASYM_XFORM_ECPM
> > || xform->xform_type <=
> RTE_CRYPTO_ASYM_XFORM_NONE) {
> > QAT_LOG(ERR, "Invalid asymmetric crypto xform");
> > err = -EINVAL;
> > diff --git a/lib/cryptodev/rte_crypto_asym.h
> b/lib/cryptodev/rte_crypto_asym.h
> > index 9c866f553f..5edf658572 100644
> > --- a/lib/cryptodev/rte_crypto_asym.h
> > +++ b/lib/cryptodev/rte_crypto_asym.h
> > @@ -94,8 +94,6 @@ enum rte_crypto_asym_xform_type {
> > */
> > RTE_CRYPTO_ASYM_XFORM_ECPM,
> > /**< Elliptic Curve Point Multiplication */
> > - RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
> > - /**< End of list */
> > };
> >
> > /**
> > @@ -116,7 +114,6 @@ enum rte_crypto_asym_op_type {
> > /**< DH Public Key generation operation */
> > RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE,
> > /**< DH Shared Secret compute operation */
> > - RTE_CRYPTO_ASYM_OP_LIST_END
> > };
> >
> > /**
> > @@ -133,7 +130,6 @@ enum rte_crypto_rsa_padding_type {
> > /**< RSA PKCS#1 OAEP padding scheme */
> > RTE_CRYPTO_RSA_PADDING_PSS,
> > /**< RSA PKCS#1 PSS padding scheme */
> > - RTE_CRYPTO_RSA_PADDING_TYPE_LIST_END
> > };
> >
> > /**
>
> So I am not sure that this is an improvement.
> The cryptodev issue we had, was that _LIST_END was being used to size
> arrays.
> And that broke when new algorithms got added. Is that an issue, in this case?
Yes we did this same exercise for symmetric crypto enums earlier.
Asym enums were left as it was experimental at that point.
They are still experimental, but thought of making this uniform
throughout DPDK enums.
>
> I am not sure that swapping out _LIST_END, and then littering the code with
> RTE_CRYPTO_ASYM_XFORM_ECPM and
> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE, is an improvement
> here.
>
> My 2c is that from an ABI PoV RTE_CRYPTO_ASYM_OP_LIST_END is not
> better or worse,
> than RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE?
>
> Interested to hear other thoughts.
I don’t have any better solution for avoiding ABI issues for now.
The change is for avoiding ABI breakage. But we can drop this patch
For now as asym is still experimental.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v1] eventdev/rx-adapter: add telemetry callbacks
2021-10-12 9:26 0% ` Jerin Jacob
@ 2021-10-12 10:05 3% ` Kinsella, Ray
2021-10-12 10:29 0% ` Kundapura, Ganapati
0 siblings, 1 reply; 200+ results
From: Kinsella, Ray @ 2021-10-12 10:05 UTC (permalink / raw)
To: Jerin Jacob, Thomas Monjalon
Cc: Kundapura, Ganapati, David Marchand, dpdk-dev, Jayatheerthan, Jay
On 12/10/2021 10:26, Jerin Jacob wrote:
> On Tue, Oct 12, 2021 at 2:40 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>>
>> 12/10/2021 10:47, Jerin Jacob:
>>> On Tue, Oct 12, 2021 at 2:05 PM Kundapura, Ganapati
>>> <ganapati.kundapura@intel.com> wrote:
>>>> From: Jerin Jacob <jerinjacobk@gmail.com>
>>>>>> --- a/lib/eventdev/rte_event_eth_rx_adapter.h
>>>>>> +++ b/lib/eventdev/rte_event_eth_rx_adapter.h
>>>>>> @@ -216,6 +216,10 @@ struct rte_event_eth_rx_adapter_stats {
>>>>>> /**< Eventdev enqueue count */
>>>>>> uint64_t rx_enq_retry;
>>>>>> /**< Eventdev enqueue retry count */
>>>>>> + uint64_t rx_event_buf_count;
>>>>>> + /**< Rx event buffered count */
>>>>>> + uint64_t rx_event_buf_size;
>>>>>
>>>>>
>>>>> Isn't ABI breakage? CI did not warn this. Isn't this a public structure?
>>>> Please confirm if moving the above two members to end of the structure overcomes ABI breakage?
>>>
>>>
>>> + @Ray Kinsella @Thomas Monjalon @David Marchand
>>>
>>> It will still break the ABI. IMO, Since it is an ABI breaking release
>>> it is OK. If there are no other objections, Please move the variable
>>> to end
>>> of the structure and update release notes for ABI changes.
>>
>> Why moving since it breaks ABI anyway?
>
> There is no specific gain in keeping new additions in the middle of structure.
21.11 is an ABI breaking release, so move it where you like :-)
>> I think you can keep as is.
>>
>>
>>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2 1/3] cryptodev: remove LIST_END enumerators
2021-10-08 20:45 3% ` [dpdk-dev] [PATCH v2 1/3] cryptodev: remove LIST_END enumerators Akhil Goyal
2021-10-08 20:45 3% ` [dpdk-dev] [PATCH v2 3/3] security: add reserved bitfields Akhil Goyal
2021-10-11 10:46 0% ` [dpdk-dev] [PATCH v2 1/3] cryptodev: remove LIST_END enumerators Zhang, Roy Fan
@ 2021-10-12 9:55 3% ` Kinsella, Ray
2021-10-12 10:19 4% ` [dpdk-dev] [EXT] " Akhil Goyal
2 siblings, 1 reply; 200+ results
From: Kinsella, Ray @ 2021-10-12 9:55 UTC (permalink / raw)
To: Akhil Goyal, dev
Cc: thomas, david.marchand, hemant.agrawal, anoobj,
pablo.de.lara.guarch, fiona.trahe, declan.doherty, matan,
g.singh, roy.fan.zhang, jianjay.zhou, asomalap, ruifeng.wang,
konstantin.ananyev, radu.nicolau, ajit.khaparde, rnagadheeraj,
adwivedi, ciara.power, Stephen Hemminger, Yigit, Ferruh
On 08/10/2021 21:45, Akhil Goyal wrote:
> Remove *_LIST_END enumerators from asymmetric crypto
> lib to avoid ABI breakage for every new addition in
> enums.
>
> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> ---
> v2: no change
>
> app/test/test_cryptodev_asym.c | 4 ++--
> drivers/crypto/qat/qat_asym.c | 2 +-
> lib/cryptodev/rte_crypto_asym.h | 4 ----
> 3 files changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
> index 9d19a6d6d9..603b2e4609 100644
> --- a/app/test/test_cryptodev_asym.c
> +++ b/app/test/test_cryptodev_asym.c
> @@ -541,7 +541,7 @@ test_one_case(const void *test_case, int sessionless)
> printf(" %u) TestCase %s %s\n", test_index++,
> tc.modex.description, test_msg);
> } else {
> - for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
> + for (i = 0; i <= RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE; i++) {
> if (tc.modex.xform_type == RTE_CRYPTO_ASYM_XFORM_RSA) {
> if (tc.rsa_data.op_type_flags & (1 << i)) {
> if (tc.rsa_data.key_exp) {
> @@ -1027,7 +1027,7 @@ static inline void print_asym_capa(
> rte_crypto_asym_xform_strings[capa->xform_type]);
> printf("operation supported -");
>
> - for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
> + for (i = 0; i <= RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE; i++) {
> /* check supported operations */
> if (rte_cryptodev_asym_xform_capability_check_optype(capa, i))
> printf(" %s",
> diff --git a/drivers/crypto/qat/qat_asym.c b/drivers/crypto/qat/qat_asym.c
> index 85973812a8..026625a4d2 100644
> --- a/drivers/crypto/qat/qat_asym.c
> +++ b/drivers/crypto/qat/qat_asym.c
> @@ -742,7 +742,7 @@ qat_asym_session_configure(struct rte_cryptodev *dev,
> err = -EINVAL;
> goto error;
> }
> - } else if (xform->xform_type >= RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
> + } else if (xform->xform_type > RTE_CRYPTO_ASYM_XFORM_ECPM
> || xform->xform_type <= RTE_CRYPTO_ASYM_XFORM_NONE) {
> QAT_LOG(ERR, "Invalid asymmetric crypto xform");
> err = -EINVAL;
> diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
> index 9c866f553f..5edf658572 100644
> --- a/lib/cryptodev/rte_crypto_asym.h
> +++ b/lib/cryptodev/rte_crypto_asym.h
> @@ -94,8 +94,6 @@ enum rte_crypto_asym_xform_type {
> */
> RTE_CRYPTO_ASYM_XFORM_ECPM,
> /**< Elliptic Curve Point Multiplication */
> - RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
> - /**< End of list */
> };
>
> /**
> @@ -116,7 +114,6 @@ enum rte_crypto_asym_op_type {
> /**< DH Public Key generation operation */
> RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE,
> /**< DH Shared Secret compute operation */
> - RTE_CRYPTO_ASYM_OP_LIST_END
> };
>
> /**
> @@ -133,7 +130,6 @@ enum rte_crypto_rsa_padding_type {
> /**< RSA PKCS#1 OAEP padding scheme */
> RTE_CRYPTO_RSA_PADDING_PSS,
> /**< RSA PKCS#1 PSS padding scheme */
> - RTE_CRYPTO_RSA_PADDING_TYPE_LIST_END
> };
>
> /**
So I am not sure that this is an improvement.
The cryptodev issue we had, was that _LIST_END was being used to size arrays.
And that broke when new algorithms got added. Is that an issue, in this case?
I am not sure that swapping out _LIST_END, and then littering the code with
RTE_CRYPTO_ASYM_XFORM_ECPM and RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE, is an improvement here.
My 2c is that from an ABI PoV RTE_CRYPTO_ASYM_OP_LIST_END is not better or worse,
than RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE?
Interested to hear other thoughts.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v1] eventdev/rx-adapter: add telemetry callbacks
2021-10-12 9:10 3% ` Thomas Monjalon
@ 2021-10-12 9:26 0% ` Jerin Jacob
2021-10-12 10:05 3% ` Kinsella, Ray
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2021-10-12 9:26 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Kundapura, Ganapati, Ray Kinsella, David Marchand, dpdk-dev,
Jayatheerthan, Jay
On Tue, Oct 12, 2021 at 2:40 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 12/10/2021 10:47, Jerin Jacob:
> > On Tue, Oct 12, 2021 at 2:05 PM Kundapura, Ganapati
> > <ganapati.kundapura@intel.com> wrote:
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > --- a/lib/eventdev/rte_event_eth_rx_adapter.h
> > > > > +++ b/lib/eventdev/rte_event_eth_rx_adapter.h
> > > > > @@ -216,6 +216,10 @@ struct rte_event_eth_rx_adapter_stats {
> > > > > /**< Eventdev enqueue count */
> > > > > uint64_t rx_enq_retry;
> > > > > /**< Eventdev enqueue retry count */
> > > > > + uint64_t rx_event_buf_count;
> > > > > + /**< Rx event buffered count */
> > > > > + uint64_t rx_event_buf_size;
> > > >
> > > >
> > > > Isn't ABI breakage? CI did not warn this. Isn't this a public structure?
> > > Please confirm if moving the above two members to end of the structure overcomes ABI breakage?
> >
> >
> > + @Ray Kinsella @Thomas Monjalon @David Marchand
> >
> > It will still break the ABI. IMO, Since it is an ABI breaking release
> > it is OK. If there are no other objections, Please move the variable
> > to end
> > of the structure and update release notes for ABI changes.
>
> Why moving since it breaks ABI anyway?
There is no specific gain in keeping new additions in the middle of structure.
> I think you can keep as is.
>
>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v1] eventdev/rx-adapter: add telemetry callbacks
2021-10-12 8:47 4% ` Jerin Jacob
@ 2021-10-12 9:10 3% ` Thomas Monjalon
2021-10-12 9:26 0% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2021-10-12 9:10 UTC (permalink / raw)
To: Kundapura, Ganapati, Ray Kinsella, David Marchand, Jerin Jacob
Cc: dpdk-dev, Jayatheerthan, Jay
12/10/2021 10:47, Jerin Jacob:
> On Tue, Oct 12, 2021 at 2:05 PM Kundapura, Ganapati
> <ganapati.kundapura@intel.com> wrote:
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > --- a/lib/eventdev/rte_event_eth_rx_adapter.h
> > > > +++ b/lib/eventdev/rte_event_eth_rx_adapter.h
> > > > @@ -216,6 +216,10 @@ struct rte_event_eth_rx_adapter_stats {
> > > > /**< Eventdev enqueue count */
> > > > uint64_t rx_enq_retry;
> > > > /**< Eventdev enqueue retry count */
> > > > + uint64_t rx_event_buf_count;
> > > > + /**< Rx event buffered count */
> > > > + uint64_t rx_event_buf_size;
> > >
> > >
> > > Isn't ABI breakage? CI did not warn this. Isn't this a public structure?
> > Please confirm if moving the above two members to end of the structure overcomes ABI breakage?
>
>
> + @Ray Kinsella @Thomas Monjalon @David Marchand
>
> It will still break the ABI. IMO, Since it is an ABI breaking release
> it is OK. If there are no other objections, Please move the variable
> to end
> of the structure and update release notes for ABI changes.
Why moving since it breaks ABI anyway?
I think you can keep as is.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [EXT] Re: [PATCH v2 3/3] security: add reserved bitfields
2021-10-12 6:59 0% ` Thomas Monjalon
@ 2021-10-12 8:53 0% ` Kinsella, Ray
0 siblings, 0 replies; 200+ results
From: Kinsella, Ray @ 2021-10-12 8:53 UTC (permalink / raw)
To: dev
On 12/10/2021 07:59, Thomas Monjalon wrote:
> 11/10/2021 18:58, Akhil Goyal:
>>> 08/10/2021 22:45, Akhil Goyal:
>>>> In struct rte_security_ipsec_sa_options, for every new option
>>>> added, there is an ABI breakage, to avoid, a reserved_opts
>>>> bitfield is added to for the remaining bits available in the
>>>> structure.
>>>> Now for every new sa option, these reserved_opts can be reduced
>>>> and new option can be added.
>>>
>>> How do you make sure this field is initialized to 0?
>>>
>> Struct rte_security_ipsec_xform Is part of rte_security_capability as well
>> As a configuration structure in session create.
>> User, should ensure that if a device support that option(in capability), then
>> only these options will take into effect or else it will be don't care for the PMD.
>> The initial values of capabilities are set by PMD statically based on the features
>> that it support.
>> So if someone sets a bit in reserved_opts, it will work only if PMD support it
>> And sets the corresponding field in capabilities.
>> But yes, if a new field is added in future, and user sets the reserved_opts by mistake
>> And the PMD supports that feature as well, then that feature will be enabled.
>> This may or may not create issue depending on the feature which is enabled.
>>
>> Should I add a note in the comments to clarify that reserved_opts should be set as 0
>> And future releases may change this without notice(But reserved in itself suggest that)?
>> Adding an explicit check in session_create does not make sense to me.
>> What do you suggest?
>
> Yes at the minimum you should add a comment.
> You could also initialize it in the lib, but it is not always possible.
>
Provide a macro for initialization perhaps ... but there would be no way to enforce using it.
Ray K
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 3/3] security: add reserved bitfields
2021-10-08 20:45 3% ` [dpdk-dev] [PATCH v2 3/3] security: add reserved bitfields Akhil Goyal
2021-10-11 8:31 0% ` Thomas Monjalon
@ 2021-10-12 8:50 0% ` Kinsella, Ray
1 sibling, 0 replies; 200+ results
From: Kinsella, Ray @ 2021-10-12 8:50 UTC (permalink / raw)
To: dev
On 08/10/2021 21:45, Akhil Goyal wrote:
> In struct rte_security_ipsec_sa_options, for every new option
> added, there is an ABI breakage, to avoid, a reserved_opts
> bitfield is added to for the remaining bits available in the
> structure.
> Now for every new sa option, these reserved_opts can be reduced
> and new option can be added.
>
> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> ---
> v2: rebase and removed libabigail.abignore change.
> Exception may be added when there is a need for change.
>
> lib/security/rte_security.h | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/lib/security/rte_security.h b/lib/security/rte_security.h
> index 7eb9f109ae..c0ea13892e 100644
> --- a/lib/security/rte_security.h
> +++ b/lib/security/rte_security.h
> @@ -258,6 +258,12 @@ struct rte_security_ipsec_sa_options {
> * PKT_TX_UDP_CKSUM or PKT_TX_L4_MASK in mbuf.
> */
> uint32_t l4_csum_enable : 1;
> +
> + /** Reserved bit fields for future extension
> + *
> + * Note: reduce number of bits in reserved_opts for every new option
> + */
> + uint32_t reserved_opts : 18;
> };
>
> /** IPSec security association direction */
>
Acked-by: Ray Kinsella <mdr@ashroe.eu>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v1] eventdev/rx-adapter: add telemetry callbacks
2021-10-12 8:35 3% ` Kundapura, Ganapati
@ 2021-10-12 8:47 4% ` Jerin Jacob
2021-10-12 9:10 3% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2021-10-12 8:47 UTC (permalink / raw)
To: Kundapura, Ganapati, Ray Kinsella, Thomas Monjalon, David Marchand
Cc: dpdk-dev, Jayatheerthan, Jay
On Tue, Oct 12, 2021 at 2:05 PM Kundapura, Ganapati
<ganapati.kundapura@intel.com> wrote:
>
> Hi Jerin,
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: 11 October 2021 21:44
> > To: Kundapura, Ganapati <ganapati.kundapura@intel.com>
> > Cc: dpdk-dev <dev@dpdk.org>; Jayatheerthan, Jay
> > > +que_id"); }
> > > diff --git a/lib/eventdev/rte_event_eth_rx_adapter.h
> > > b/lib/eventdev/rte_event_eth_rx_adapter.h
> > > index 70ca427..acabed4 100644
> > > --- a/lib/eventdev/rte_event_eth_rx_adapter.h
> > > +++ b/lib/eventdev/rte_event_eth_rx_adapter.h
> > > @@ -216,6 +216,10 @@ struct rte_event_eth_rx_adapter_stats {
> > > /**< Eventdev enqueue count */
> > > uint64_t rx_enq_retry;
> > > /**< Eventdev enqueue retry count */
> > > + uint64_t rx_event_buf_count;
> > > + /**< Rx event buffered count */
> > > + uint64_t rx_event_buf_size;
> >
> >
> > Isn't ABI breakage? CI did not warn this. Isn't this a public structure?
> Please confirm if moving the above two members to end of the structure overcomes ABI breakage?
+ @Ray Kinsella @Thomas Monjalon @David Marchand
It will still break the ABI. IMO, Since it is an ABI breaking release
it is OK. If there are no other objections, Please move the variable
to end
of the structure and update release notes for ABI changes.
> >
> >
> >
> > > + /**< Rx event buffer size */
> > > uint64_t rx_dropped;
> > > /**< Received packet dropped count */
> > > uint64_t rx_enq_start_ts;
> > > --
> > > 2.6.4
> > >
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v1] eventdev/rx-adapter: add telemetry callbacks
2021-10-11 16:14 3% ` Jerin Jacob
@ 2021-10-12 8:35 3% ` Kundapura, Ganapati
2021-10-12 8:47 4% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Kundapura, Ganapati @ 2021-10-12 8:35 UTC (permalink / raw)
To: Jerin Jacob; +Cc: dpdk-dev, Jayatheerthan, Jay
Hi Jerin,
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: 11 October 2021 21:44
> To: Kundapura, Ganapati <ganapati.kundapura@intel.com>
> Cc: dpdk-dev <dev@dpdk.org>; Jayatheerthan, Jay
> <jay.jayatheerthan@intel.com>
> Subject: Re: [PATCH v1] eventdev/rx-adapter: add telemetry callbacks
>
> On Thu, Oct 7, 2021 at 6:27 PM Ganapati Kundapura
> <ganapati.kundapura@intel.com> wrote:
> >
> > Added telemetry callbacks to get Rx adapter stats, reset stats and to
> > get rx queue config information.
>
> rx -> Rx
>
> Change the subject to eventdev/rx_adapter
>
> >
> > Signed-off-by: Ganapati Kundapura <ganapati.kundapura@intel.com>
> >
> > diff --git a/lib/eventdev/rte_event_eth_rx_adapter.c
> > b/lib/eventdev/rte_event_eth_rx_adapter.c
> > index 9ac976c..fa7191c 100644
> > --- a/lib/eventdev/rte_event_eth_rx_adapter.c
> > +++ b/lib/eventdev/rte_event_eth_rx_adapter.c
> > @@ -23,6 +23,7 @@
> > #include "eventdev_pmd.h"
> > #include "rte_eventdev_trace.h"
> > #include "rte_event_eth_rx_adapter.h"
> > +#include <rte_telemetry.h>
>
> Move this to the above block where all <...h> header files are grouped.
OK
>
>
> >
> > #define BATCH_SIZE 32
> > #define BLOCK_CNT_THRESHOLD 10
> > @@ -2852,6 +2853,7 @@ rte_event_eth_rx_adapter_stats_get(uint8_t id,
> > struct rte_event_eth_rx_adapter_stats
> > *stats) {
> > struct rte_event_eth_rx_adapter *rx_adapter;
> > + struct rte_eth_event_enqueue_buffer *buf;
> > struct rte_event_eth_rx_adapter_stats dev_stats_sum = { 0 };
> > struct rte_event_eth_rx_adapter_stats dev_stats;
> > struct rte_eventdev *dev;
> > @@ -2887,8 +2889,11 @@ rte_event_eth_rx_adapter_stats_get(uint8_t id,
> > if (rx_adapter->service_inited)
> > *stats = rx_adapter->stats;
> >
> > + buf = &rx_adapter->event_enqueue_buffer;
> > stats->rx_packets += dev_stats_sum.rx_packets;
> > stats->rx_enq_count += dev_stats_sum.rx_enq_count;
> > + stats->rx_event_buf_count = buf->count;
> > + stats->rx_event_buf_size = buf->events_size;
> >
> > return 0;
> > }
> > @@ -3052,3 +3057,146 @@
> > rte_event_eth_rx_adapter_queue_conf_get(uint8_t id,
> >
> > return 0;
> > }
> > +
> > +#define RXA_ADD_DICT(stats, s) rte_tel_data_add_dict_u64(d, #s,
> > +stats.s)
> > +
> > +static int
> > +handle_rxa_stats(const char *cmd __rte_unused,
> > + const char *params,
> > + struct rte_tel_data *d) {
> > + uint8_t rx_adapter_id;
> > + struct rte_event_eth_rx_adapter_stats rx_adptr_stats;
> > +
> > + if (params == NULL || strlen(params) == 0 || !isdigit(*params))
> > + return -1;
> > +
> > + /* Get Rx adapter ID from parameter string */
> > + rx_adapter_id = atoi(params);
> > + RTE_EVENT_ETH_RX_ADAPTER_ID_VALID_OR_ERR_RET(rx_adapter_id,
> > + -EINVAL);
> > +
> > + /* Get Rx adapter stats */
> > + if (rte_event_eth_rx_adapter_stats_get(rx_adapter_id,
> > + &rx_adptr_stats)) {
> > + RTE_EDEV_LOG_ERR("Failed to get Rx adapter stats\n");
> > + return -1;
> > + }
> > +
> > + rte_tel_data_start_dict(d);
> > + rte_tel_data_add_dict_u64(d, "rx_adapter_id", rx_adapter_id);
> > + RXA_ADD_DICT(rx_adptr_stats, rx_packets);
> > + RXA_ADD_DICT(rx_adptr_stats, rx_poll_count);
> > + RXA_ADD_DICT(rx_adptr_stats, rx_dropped);
> > + RXA_ADD_DICT(rx_adptr_stats, rx_enq_retry);
> > + RXA_ADD_DICT(rx_adptr_stats, rx_event_buf_count);
> > + RXA_ADD_DICT(rx_adptr_stats, rx_event_buf_size);
> > + RXA_ADD_DICT(rx_adptr_stats, rx_enq_count);
> > + RXA_ADD_DICT(rx_adptr_stats, rx_enq_start_ts);
> > + RXA_ADD_DICT(rx_adptr_stats, rx_enq_block_cycles);
> > + RXA_ADD_DICT(rx_adptr_stats, rx_enq_end_ts);
> > + RXA_ADD_DICT(rx_adptr_stats, rx_intr_packets);
> > +
> > + return 0;
> > +}
> > +
> > +static int
> > +handle_rxa_stats_reset(const char *cmd __rte_unused,
> > + const char *params,
> > + struct rte_tel_data *d __rte_unused) {
> > + uint8_t rx_adapter_id;
> > +
> > + if (params == NULL || strlen(params) == 0 || ~isdigit(*params))
> > + return -1;
> > +
> > + /* Get Rx adapter ID from parameter string */
> > + rx_adapter_id = atoi(params);
> > + RTE_EVENT_ETH_RX_ADAPTER_ID_VALID_OR_ERR_RET(rx_adapter_id,
> > + -EINVAL);
> > +
> > + /* Reset Rx adapter stats */
> > + if (rte_event_eth_rx_adapter_stats_reset(rx_adapter_id)) {
> > + RTE_EDEV_LOG_ERR("Failed to reset Rx adapter stats\n");
> > + return -1;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int
> > +handle_rxa_get_queue_conf(const char *cmd __rte_unused,
> > + const char *params,
> > + struct rte_tel_data *d) {
> > + uint8_t rx_adapter_id;
> > + uint16_t rx_queue_id;
> > + int eth_dev_id;
> > + char *token, *l_params;
> > + struct rte_event_eth_rx_adapter_queue_conf queue_conf;
> > +
> > + if (params == NULL || strlen(params) == 0 || !isdigit(*params))
> > + return -1;
> > +
> > + /* Get Rx adapter ID from parameter string */
> > + l_params = strdup(params);
> > + token = strtok(l_params, ",");
> > + rx_adapter_id = strtoul(token, NULL, 10);
> > + RTE_EVENT_ETH_RX_ADAPTER_ID_VALID_OR_ERR_RET(rx_adapter_id,
> > + -EINVAL);
> > +
> > + token = strtok(NULL, ",");
> > + if (token == NULL || strlen(token) == 0 || !isdigit(*token))
> > + return -1;
> > +
> > + /* Get device ID from parameter string */
> > + eth_dev_id = strtoul(token, NULL, 10);
> > + RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(eth_dev_id, -EINVAL);
> > +
> > + token = strtok(NULL, ",");
> > + if (token == NULL || strlen(token) == 0 || !isdigit(*token))
> > + return -1;
> > +
> > + /* Get Rx queue ID from parameter string */
> > + rx_queue_id = strtoul(token, NULL, 10);
> > + if (rx_queue_id >= rte_eth_devices[eth_dev_id].data->nb_rx_queues) {
> > + RTE_EDEV_LOG_ERR("Invalid rx queue_id %u", rx_queue_id);
> > + return -EINVAL;
> > + }
> > +
> > + token = strtok(NULL, "\0");
> > + if (token != NULL)
> > + RTE_EDEV_LOG_ERR("Extra parameters passed to eventdev"
> > + " telemetry command, igrnoring");
> > +
> > + if (rte_event_eth_rx_adapter_queue_conf_get(rx_adapter_id,
> eth_dev_id,
> > + rx_queue_id, &queue_conf)) {
> > + RTE_EDEV_LOG_ERR("Failed to get Rx adapter queue config");
> > + return -1;
> > + }
> > +
> > + rte_tel_data_start_dict(d);
> > + rte_tel_data_add_dict_u64(d, "rx_adapter_id", rx_adapter_id);
> > + rte_tel_data_add_dict_u64(d, "eth_dev_id", eth_dev_id);
> > + rte_tel_data_add_dict_u64(d, "rx_queue_id", rx_queue_id);
> > + RXA_ADD_DICT(queue_conf, rx_queue_flags);
> > + RXA_ADD_DICT(queue_conf, servicing_weight);
> > + RXA_ADD_DICT(queue_conf.ev, queue_id);
> > + RXA_ADD_DICT(queue_conf.ev, sched_type);
> > + RXA_ADD_DICT(queue_conf.ev, priority);
> > + RXA_ADD_DICT(queue_conf.ev, flow_id);
> > +
> > + return 0;
> > +}
> > +
> > +RTE_INIT(rxa_init_telemetry)
> > +{
> > + rte_telemetry_register_cmd("/eventdev/rxa_stats",
> > + handle_rxa_stats,
> > + "Returns Rx adapter stats. Parameter: rx_adapter_id");
> > +
> > + rte_telemetry_register_cmd("/eventdev/rxa_stats_reset",
> > + handle_rxa_stats_reset,
> > + "Reset Rx adapter stats. Parameter: rx_adapter_id");
> > +
> > + rte_telemetry_register_cmd("/eventdev/rxa_queue_conf",
> > + handle_rxa_get_queue_conf,
> > + "Returns Rx queue config. Parameter: rxa_id, DevID,
> > +que_id"); }
> > diff --git a/lib/eventdev/rte_event_eth_rx_adapter.h
> > b/lib/eventdev/rte_event_eth_rx_adapter.h
> > index 70ca427..acabed4 100644
> > --- a/lib/eventdev/rte_event_eth_rx_adapter.h
> > +++ b/lib/eventdev/rte_event_eth_rx_adapter.h
> > @@ -216,6 +216,10 @@ struct rte_event_eth_rx_adapter_stats {
> > /**< Eventdev enqueue count */
> > uint64_t rx_enq_retry;
> > /**< Eventdev enqueue retry count */
> > + uint64_t rx_event_buf_count;
> > + /**< Rx event buffered count */
> > + uint64_t rx_event_buf_size;
>
>
> Isn't ABI breakage? CI did not warn this. Isn't this a public structure?
Please confirm if moving the above two members to end of the structure overcomes ABI breakage?
>
>
>
> > + /**< Rx event buffer size */
> > uint64_t rx_dropped;
> > /**< Received packet dropped count */
> > uint64_t rx_enq_start_ts;
> > --
> > 2.6.4
> >
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [EXT] Re: [PATCH v2 3/3] security: add reserved bitfields
2021-10-11 22:15 3% ` Stephen Hemminger
@ 2021-10-12 8:31 0% ` Kinsella, Ray
0 siblings, 0 replies; 200+ results
From: Kinsella, Ray @ 2021-10-12 8:31 UTC (permalink / raw)
To: Stephen Hemminger, Akhil Goyal
Cc: Thomas Monjalon, dev, david.marchand, hemant.agrawal,
Anoob Joseph, De Lara Guarch, Pablo, Trahe, Fiona, Doherty,
Declan, matan, g.singh, Zhang, Roy Fan, jianjay.zhou, asomalap,
ruifeng.wang, Ananyev, Konstantin, Nicolau, Radu, ajit.khaparde,
Nagadheeraj Rottela, Ankur Dwivedi, Power, Ciara, Richardson,
Bruce
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Monday 11 October 2021 23:16
> To: Akhil Goyal <gakhil@marvell.com>
> Cc: Thomas Monjalon <thomas@monjalon.net>; dev@dpdk.org;
> david.marchand@redhat.com; hemant.agrawal@nxp.com; Anoob Joseph
> <anoobj@marvell.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; Trahe, Fiona <fiona.trahe@intel.com>;
> Doherty, Declan <declan.doherty@intel.com>; matan@nvidia.com;
> g.singh@nxp.com; Zhang, Roy Fan <roy.fan.zhang@intel.com>;
> jianjay.zhou@huawei.com; asomalap@amd.com; ruifeng.wang@arm.com;
> Ananyev, Konstantin <konstantin.ananyev@intel.com>; Nicolau, Radu
> <radu.nicolau@intel.com>; ajit.khaparde@broadcom.com; Nagadheeraj
> Rottela <rnagadheeraj@marvell.com>; Ankur Dwivedi
> <adwivedi@marvell.com>; Power, Ciara <ciara.power@intel.com>; Kinsella,
> Ray <ray.kinsella@intel.com>; Richardson, Bruce
> <bruce.richardson@intel.com>
> Subject: Re: [EXT] Re: [PATCH v2 3/3] security: add reserved bitfields
>
> On Mon, 11 Oct 2021 16:58:24 +0000
> Akhil Goyal <gakhil@marvell.com> wrote:
>
> > > 08/10/2021 22:45, Akhil Goyal:
> > > > In struct rte_security_ipsec_sa_options, for every new option
> > > > added, there is an ABI breakage, to avoid, a reserved_opts
> > > > bitfield is added to for the remaining bits available in the
> > > > structure.
> > > > Now for every new sa option, these reserved_opts can be reduced
> > > > and new option can be added.
> > >
> > > How do you make sure this field is initialized to 0?
> > >
> > Struct rte_security_ipsec_xform Is part of rte_security_capability as
> > well As a configuration structure in session create.
> > User, should ensure that if a device support that option(in
> > capability), then only these options will take into effect or else it
> will be don't care for the PMD.
> > The initial values of capabilities are set by PMD statically based on
> > the features that it support.
> > So if someone sets a bit in reserved_opts, it will work only if PMD
> > support it And sets the corresponding field in capabilities.
> > But yes, if a new field is added in future, and user sets the
> > reserved_opts by mistake And the PMD supports that feature as well,
> then that feature will be enabled.
> > This may or may not create issue depending on the feature which is
> enabled.
> >
> > Should I add a note in the comments to clarify that reserved_opts
> > should be set as 0 And future releases may change this without
> notice(But reserved in itself suggest that)?
> > Adding an explicit check in session_create does not make sense to me.
> > What do you suggest?
> >
> > Regards,
> > Akhil
> >
>
> The problem is if user creates an on stack variable and sets the
> unreserved fields to good values but other parts are garbage. This
> passes API/ABI unless you strictly enforce that all reserved fields are
> zero.
Right, but that is no better or worse than the current struct, in that respect, right?
User case be careless there also - declare it on the stack and forget to memset.
struct rte_security_ipsec_sa_options {
uint32_t esn : 1;
uint32_t udp_encap : 1;
uint32_t copy_dscp : 1;
uint32_t copy_flabel : 1;
uint32_t copy_df : 1;
uint32_t dec_ttl : 1;
uint32_t ecn : 1;
uint32_t stats : 1;
uint32_t iv_gen_disable : 1;
uint32_t tunnel_hdr_verify : 2;
};
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v3 1/5] ethdev: update modify field flow action
@ 2021-10-12 8:06 3% ` Viacheslav Ovsiienko
0 siblings, 0 replies; 200+ results
From: Viacheslav Ovsiienko @ 2021-10-12 8:06 UTC (permalink / raw)
To: dev; +Cc: rasland, matan, shahafs, orika, getelson, thomas
The generic modify field flow action introduced in [1] has
some issues related to the immediate source operand:
- immediate source can be presented either as an unsigned
64-bit integer or pointer to data pattern in memory.
There was no explicit pointer field defined in the union.
- the byte ordering for 64-bit integer was not specified.
Many fields have shorter lengths and byte ordering
is crucial.
- how the bit offset is applied to the immediate source
field was not defined and documented.
- 64-bit integer size is not enough to provide IPv6
addresses.
In order to cover the issues and exclude any ambiguities
the following is done:
- introduce the explicit pointer field
in rte_flow_action_modify_data structure
- replace the 64-bit unsigned integer with 16-byte array
- update the modify field flow action documentation
Appropriate deprecation notice has been removed.
[1] commit 73b68f4c54a0 ("ethdev: introduce generic modify flow action")
Fixes: 2ba49b5f3721 ("doc: announce change to ethdev modify action data")
Signed-off-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
---
doc/guides/prog_guide/rte_flow.rst | 24 +++++++++++++++++++++++-
doc/guides/rel_notes/deprecation.rst | 4 ----
doc/guides/rel_notes/release_21_11.rst | 7 +++++++
lib/ethdev/rte_flow.h | 16 ++++++++++++----
4 files changed, 42 insertions(+), 9 deletions(-)
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 2b42d5ec8c..b08087511f 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -2835,6 +2835,22 @@ a packet to any other part of it.
``value`` sets an immediate value to be used as a source or points to a
location of the value in memory. It is used instead of ``level`` and ``offset``
for ``RTE_FLOW_FIELD_VALUE`` and ``RTE_FLOW_FIELD_POINTER`` respectively.
+The data in memory should be presented exactly in the same byte order and
+length as in the relevant flow item, i.e. data for field with type
+``RTE_FLOW_FIELD_MAC_DST`` should follow the conventions of ``dst`` field
+in ``rte_flow_item_eth`` structure, with type ``RTE_FLOW_FIELD_IPV6_SRC`` -
+``rte_flow_item_ipv6`` conventions, and so on. If the field size is larger than
+16 bytes the pattern can be provided as pointer only.
+
+The bitfield extracted from the memory being applied as second operation
+parameter is defined by action width and by the destination field offset.
+Application should provide the data in immediate value memory (either as
+buffer or by pointer) exactly as item field without any applied explicit offset,
+and destination packet field (with specified width and bit offset) will be
+replaced by immediate source bits from the same bit offset. For example,
+to replace the third byte of MAC address with value 0x85, application should
+specify destination width as 8, destination offset as 16, and provide immediate
+value as sequence of bytes {xxx, xxx, 0x85, xxx, xxx, xxx}.
.. _table_rte_flow_action_modify_field:
@@ -2865,7 +2881,13 @@ for ``RTE_FLOW_FIELD_VALUE`` and ``RTE_FLOW_FIELD_POINTER`` respectively.
+---------------+----------------------------------------------------------+
| ``offset`` | number of bits to skip at the beginning |
+---------------+----------------------------------------------------------+
- | ``value`` | immediate value or a pointer to this value |
+ | ``value`` | immediate value buffer (source field only, not |
+ | | applicable to destination) for RTE_FLOW_FIELD_VALUE |
+ | | field type |
+ +---------------+----------------------------------------------------------+
+ | ``pvalue`` | pointer to immediate value data (source field only, not |
+ | | applicable to destination) for RTE_FLOW_FIELD_POINTER |
+ | | field type |
+---------------+----------------------------------------------------------+
Action: ``CONNTRACK``
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index a2fe766d4b..dee14077a5 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -120,10 +120,6 @@ Deprecation Notices
* ethdev: Announce moving from dedicated modify function for each field,
to using the general ``rte_flow_modify_field`` action.
-* ethdev: The struct ``rte_flow_action_modify_data`` will be modified
- to support modifying fields larger than 64 bits.
- In addition, documentation will be updated to clarify byte order.
-
* ethdev: Attribute ``shared`` of the ``struct rte_flow_action_count``
is deprecated and will be removed in DPDK 21.11. Shared counters should
be managed using shared actions API (``rte_flow_shared_action_create`` etc).
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index dfc2cbdeed..578c1206e7 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -187,6 +187,13 @@ API Changes
the crypto/security operation. This field will be used to communicate
events such as soft expiry with IPsec in lookaside mode.
+* ethdev: ``rte_flow_action_modify_data`` structure updated, immediate data
+ array is extended, data pointer field is explicitly added to union, the
+ action behavior is defined in more strict fashion and documentation updated.
+ The immediate value behavior has been changed, the entire immediate field
+ should be provided, and offset for immediate source bitfield is assigned
+ from destination one.
+
ABI Changes
-----------
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 7b1ed7f110..f14f77772b 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -3217,10 +3217,18 @@ struct rte_flow_action_modify_data {
uint32_t offset;
};
/**
- * Immediate value for RTE_FLOW_FIELD_VALUE or
- * memory address for RTE_FLOW_FIELD_POINTER.
+ * Immediate value for RTE_FLOW_FIELD_VALUE, presented in the
+ * same byte order and length as in relevant rte_flow_item_xxx.
+ * The immediate source bitfield offset is inherited from
+ * the destination's one.
*/
- uint64_t value;
+ uint8_t value[16];
+ /**
+ * Memory address for RTE_FLOW_FIELD_POINTER, memory layout
+ * should be the same as for relevant field in the
+ * rte_flow_item_xxx structure.
+ */
+ void *pvalue;
};
};
@@ -3240,7 +3248,7 @@ enum rte_flow_modify_op {
* RTE_FLOW_ACTION_TYPE_MODIFY_FIELD
*
* Modify a destination header field according to the specified
- * operation. Another packet field can be used as a source as well
+ * operation. Another field of the packet can be used as a source as well
* as tag, mark, metadata, immediate value or a pointer to it.
*/
struct rte_flow_action_modify_field {
--
2.18.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [EXT] Re: [PATCH v2 3/3] security: add reserved bitfields
2021-10-11 16:58 0% ` [dpdk-dev] [EXT] " Akhil Goyal
2021-10-11 22:15 3% ` Stephen Hemminger
@ 2021-10-12 6:59 0% ` Thomas Monjalon
2021-10-12 8:53 0% ` Kinsella, Ray
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2021-10-12 6:59 UTC (permalink / raw)
To: Akhil Goyal
Cc: dev, david.marchand, hemant.agrawal, Anoob Joseph,
pablo.de.lara.guarch, fiona.trahe, declan.doherty, matan,
g.singh, roy.fan.zhang, jianjay.zhou, asomalap, ruifeng.wang,
konstantin.ananyev, radu.nicolau, ajit.khaparde,
Nagadheeraj Rottela, Ankur Dwivedi, ciara.power,
Stephen Hemminger, ray.kinsella, bruce.richardson
11/10/2021 18:58, Akhil Goyal:
> > 08/10/2021 22:45, Akhil Goyal:
> > > In struct rte_security_ipsec_sa_options, for every new option
> > > added, there is an ABI breakage, to avoid, a reserved_opts
> > > bitfield is added to for the remaining bits available in the
> > > structure.
> > > Now for every new sa option, these reserved_opts can be reduced
> > > and new option can be added.
> >
> > How do you make sure this field is initialized to 0?
> >
> Struct rte_security_ipsec_xform Is part of rte_security_capability as well
> As a configuration structure in session create.
> User, should ensure that if a device support that option(in capability), then
> only these options will take into effect or else it will be don't care for the PMD.
> The initial values of capabilities are set by PMD statically based on the features
> that it support.
> So if someone sets a bit in reserved_opts, it will work only if PMD support it
> And sets the corresponding field in capabilities.
> But yes, if a new field is added in future, and user sets the reserved_opts by mistake
> And the PMD supports that feature as well, then that feature will be enabled.
> This may or may not create issue depending on the feature which is enabled.
>
> Should I add a note in the comments to clarify that reserved_opts should be set as 0
> And future releases may change this without notice(But reserved in itself suggest that)?
> Adding an explicit check in session_create does not make sense to me.
> What do you suggest?
Yes at the minimum you should add a comment.
You could also initialize it in the lib, but it is not always possible.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v1 1/6] bbdev: add capability for CRC16 check
2021-10-11 20:38 0% ` Chautru, Nicolas
@ 2021-10-12 6:53 3% ` Thomas Monjalon
2021-10-12 16:36 4% ` Chautru, Nicolas
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2021-10-12 6:53 UTC (permalink / raw)
To: Chautru, Nicolas; +Cc: gakhil, dev, trix, hemant.agrawal, Zhang, Mingshan
11/10/2021 22:38, Chautru, Nicolas:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 13/08/2021 18:51, Nicolas Chautru:
> > > Adding a missing operation when CRC16
> > > is being used for TB CRC check.
> > >
> > > Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
> > > ---
> > > --- a/doc/guides/rel_notes/release_21_11.rst
> > > +++ b/doc/guides/rel_notes/release_21_11.rst
> > > @@ -84,6 +84,7 @@ API Changes
> > > Also, make sure to start the actual text at the margin.
> > > =======================================================
> > >
> > > +* bbdev: Added capability related to more comprehensive CRC options.
> >
> > That's not an API change, the enum symbols are the same.
> > Only enum values are changed so it impacts only ABI.
>
> Hi Thomas,
> How is that not a API change when new additional capability are exposed? Ie. new enums defined for new capabilities.
API change is when the app source code has to be updated.
ABI change is when the app binary has to be rebuilt.
> I think I see other similar cases in the same release notes " * cryptodev: ``RTE_CRYPTO_AEAD_LIST_END`` from ``enum rte_crypto_aead_algo ...".
I don't see this one.
> You know best, just checking the intent, maybe worth clarifying the guideline except in case this is just me.
Given my explanation above, how would you classify your change?
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v3 2/4] mempool: add non-IO flag
2021-10-12 0:04 4% ` [dpdk-dev] [PATCH v3 2/4] mempool: add non-IO flag Dmitry Kozlyuk
2021-10-12 3:37 0% ` Jerin Jacob
@ 2021-10-12 6:42 0% ` Andrew Rybchenko
1 sibling, 0 replies; 200+ results
From: Andrew Rybchenko @ 2021-10-12 6:42 UTC (permalink / raw)
To: Dmitry Kozlyuk, dev; +Cc: Thomas Monjalon, Matan Azrad, Olivier Matz
On 10/12/21 3:04 AM, Dmitry Kozlyuk wrote:
> Mempool is a generic allocator that is not necessarily used for device
> IO operations and its memory for DMA. Add MEMPOOL_F_NON_IO flag to mark
> such mempools.
> Discussion: https://mails.dpdk.org/archives/dev/2021-August/216654.html
>
> Signed-off-by: Dmitry Kozlyuk <dkozlyuk@nvidia.com>
> Acked-by: Matan Azrad <matan@nvidia.com>
> ---
> doc/guides/rel_notes/release_21_11.rst | 3 +++
> lib/mempool/rte_mempool.h | 4 ++++
> 2 files changed, 7 insertions(+)
>
> diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
> index 5036641842..dbabdc9759 100644
> --- a/doc/guides/rel_notes/release_21_11.rst
> +++ b/doc/guides/rel_notes/release_21_11.rst
> @@ -208,6 +208,9 @@ API Changes
> the crypto/security operation. This field will be used to communicate
> events such as soft expiry with IPsec in lookaside mode.
>
> +* mempool: Added ``MEMPOOL_F_NON_IO`` flag to give a hint to DPDK components
> + that objects from this pool will not be used for device IO (e.g. DMA).
> +
>
> ABI Changes
> -----------
> diff --git a/lib/mempool/rte_mempool.h b/lib/mempool/rte_mempool.h
> index e2bf40aa09..b48d9f89c2 100644
> --- a/lib/mempool/rte_mempool.h
> +++ b/lib/mempool/rte_mempool.h
> @@ -262,6 +262,7 @@ struct rte_mempool {
> #define MEMPOOL_F_SC_GET 0x0008 /**< Default get is "single-consumer".*/
> #define MEMPOOL_F_POOL_CREATED 0x0010 /**< Internal: pool is created. */
> #define MEMPOOL_F_NO_IOVA_CONTIG 0x0020 /**< Don't need IOVA contiguous objs. */
> +#define MEMPOOL_F_NON_IO 0x0040 /**< Not used for device IO (DMA). */
Doesn't it imply MEMPOOL_F_NO_IOVA_CONTIG?
Shouldn't it reject mempool population with not RTE_BAD_IOVA
iova parameter?
I see that it is just a hint, but just trying to make
full picture consistent.
As the second thought: isn't iova==RTE_BAD_IOVA
sufficient as a hint?
>
> /**
> * @internal When debug is enabled, store some statistics.
> @@ -991,6 +992,9 @@ typedef void (rte_mempool_ctor_t)(struct rte_mempool *, void *);
> * "single-consumer". Otherwise, it is "multi-consumers".
> * - MEMPOOL_F_NO_IOVA_CONTIG: If set, allocated objects won't
> * necessarily be contiguous in IO memory.
> + * - MEMPOOL_F_NON_IO: If set, the mempool is considered to be
> + * never used for device IO, i.e. for DMA operations.
> + * It's a hint to other components and does not affect the mempool behavior.
> * @return
> * The pointer to the new allocated mempool, on success. NULL on error
> * with rte_errno set appropriately. Possible rte_errno values include:
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 2/7] ethdev: allocate max space for internal queue array
2021-10-11 23:06 0% ` Ananyev, Konstantin
@ 2021-10-12 5:47 0% ` Andrew Rybchenko
0 siblings, 0 replies; 200+ results
From: Andrew Rybchenko @ 2021-10-12 5:47 UTC (permalink / raw)
To: Ananyev, Konstantin, dev
Cc: Li, Xiaoyun, anoobj, jerinj, ndabilpuram, adwivedi,
shepard.siegel, ed.czeck, john.miller, irusskikh, ajit.khaparde,
somnath.kotur, rahul.lakkireddy, hemant.agrawal, sachin.saxena,
Wang, Haiyue, Daley, John, hyonkim, Zhang, Qi Z, Wang, Xiao W,
humin29, yisen.zhuang, oulijun, Xing, Beilei, Wu, Jingjing, Yang,
Qiming, matan, viacheslavo, sthemmin, longli, heinrich.kuhn,
kirankumark, mczekaj, jiawenwu, jianwang, maxime.coquelin, Xia,
Chenbo, thomas, Yigit, Ferruh, mdr, Jayatheerthan, Jay
On 10/12/21 2:06 AM, Ananyev, Konstantin wrote:
>>>>> At queue configure stage always allocate space for maximum possible
>>>>> number (RTE_MAX_QUEUES_PER_PORT) of queue pointers.
>>>>> That will allow 'fast' inline functions (eth_rx_burst, etc.) to refer
>>>>> pointer to internal queue data without extra checking of current number
>>>>> of configured queues.
>>>>> That would help in future to hide rte_eth_dev and related structures.
>>>>> It means that from now on, each ethdev port will always consume:
>>>>> ((2*sizeof(uintptr_t))* RTE_MAX_QUEUES_PER_PORT)
>>>>> bytes of memory for its queue pointers.
>>>>> With RTE_MAX_QUEUES_PER_PORT==1024 (default value) it is 16KB per port.
>>>>>
>>>>> Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
>>>>> ---
>>>>> lib/ethdev/rte_ethdev.c | 36 +++++++++---------------------------
>>>>> 1 file changed, 9 insertions(+), 27 deletions(-)
>>>>>
>>>>> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
>>>>> index ed37f8871b..c8abda6dd7 100644
>>>>> --- a/lib/ethdev/rte_ethdev.c
>>>>> +++ b/lib/ethdev/rte_ethdev.c
>>>>> @@ -897,7 +897,8 @@ eth_dev_rx_queue_config(struct rte_eth_dev *dev, uint16_t nb_queues)
>>>>>
>>>>> if (dev->data->rx_queues == NULL && nb_queues != 0) { /* first time configuration */
>>>>> dev->data->rx_queues = rte_zmalloc("ethdev->rx_queues",
>>>>> - sizeof(dev->data->rx_queues[0]) * nb_queues,
>>>>> + sizeof(dev->data->rx_queues[0]) *
>>>>> + RTE_MAX_QUEUES_PER_PORT,
>>>>> RTE_CACHE_LINE_SIZE);
>>>>
>>>> Looking at it I have few questions:
>>>> 1. Why is nb_queues == 0 case kept as an exception? Yes,
>>>> strictly speaking it is not the problem of the patch,
>>>> DPDK will still segfault (non-debug build) if I
>>>> allocate Tx queues only but call rte_eth_rx_burst().
>>>
>>> eth_dev_rx_queue_config(.., nb_queues=0) is used in few places to clean-up things.
>>
>> No, as far as I know. For Tx only application (e.g. traffic generator)
>> it is 100% legal to configure with tx_queues=X, rx_queues=0.
>> The same is for Rx only application (e.g. packet capture).
>
> Yes, that is valid config for sure.
> I just pointed that simply ignoring 'nb_queues' value and
> always allocating space for max possible queues, i.e:
>
> eth_dev_rx_queue_config(struct rte_eth_dev *dev, uint16_t nb_queues)
> {
> ....
> - if (dev->data->rx_queues == NULL && nb_queues != 0) { /* first time configuration */
> + if (dev->data->rx_queues == NULL) {
> wouldn't work, as right now nb_queues == 0 has extra special meaning -
> do final cleanup and free dev->data->rx_queues.
> But re-reading the text below, it seems that I misunderstood you
> and it probably wasn't your intention anyway.
>
>>
>>>
>>>> After reading the patch description I thought that
>>>> we're trying to address it.
>>>
>>> We do, though I can't see how we can address it in this patch.
>>> Though it is a good idea - I think I can add extra check in eth_dev_fp_ops_setup()
>>> or around and setup RX function pointers only when dev->data->rx_queues != NULL.
>>> Same for TX.
>>
>> You don't need to care about these pointers, if these arrays are
>> always allocated. See (3) below.
>>
>>>
>>>> 2. Why do we need to allocate memory dynamically?
>>>> Can we just make rx_queues an array of appropriate size?
>>>
>>> Pavan already asked same question.
>>> My answer to him:
>>> Yep we can, and yes it will simplify this peace of code.
>>> The main reason I decided no to do this change now -
>>> it will change layout of the_eth_dev_data structure.
>>> In this series I tried to mininize(/avoid) changes in rte_eth_dev and rte_eth_dev_data,
>>> as much as possible to avoid any unforeseen performance and functional impacts.
>>> If we'll manage to make rte_eth_dev and rte_eth_dev_data private we can in future
>>> consider that one and other changes in rte_eth_dev and rte_eth_dev_data layouts
>>> without worrying about ABI breakage
>>
>> Thanks a lot. Makes sense.
>>
>>>> May be wasting 512K unconditionally is too much.
>>>> 3. If wasting 512K is too much, I'd consider to move
>>>> allocation to eth_dev_get(). If
>>>
>>> Don't understand where 512KB came from.
>>
>> 32 port * 1024 queues * 2 types * 8 pointer size
>> if we allocate as in (2) above.
>>
>>> each ethdev port will always consume:
>>> ((2*sizeof(uintptr_t))* RTE_MAX_QUEUES_PER_PORT)
>>> bytes of memory for its queue pointers.
>>> With RTE_MAX_QUEUES_PER_PORT==1024 (default value) it is 16KB per port.
>>
>> IMHO it will be a bit nicer if queue pointers arrays are allocated
>> on device get if size is fixed. It is just a suggestion. If you
>> disagree, feel free to drop it.
>
> You mean - allocate these arrays somewhere at rte_eth_dev_allocate() path?
Yes, eth_dev_get() mentioned above is called from
rte_eth_dev_allocate().
> That sounds like an interesting idea, but seems too drastic to me at that stage.
Yes, of course, we can address it later.
>
>>
>>>>> if (dev->data->rx_queues == NULL) {
>>>>> dev->data->nb_rx_queues = 0;
>>>>> @@ -908,21 +909,11 @@ eth_dev_rx_queue_config(struct rte_eth_dev *dev, uint16_t nb_queues)
>>>>>
>>>>> rxq = dev->data->rx_queues;
>>>>>
>>>>> - for (i = nb_queues; i < old_nb_queues; i++)
>>>>> + for (i = nb_queues; i < old_nb_queues; i++) {
>>>>> (*dev->dev_ops->rx_queue_release)(rxq[i]);
>>>>> - rxq = rte_realloc(rxq, sizeof(rxq[0]) * nb_queues,
>>>>> - RTE_CACHE_LINE_SIZE);
>>>>> - if (rxq == NULL)
>>>>> - return -(ENOMEM);
>>>>> - if (nb_queues > old_nb_queues) {
>>>>> - uint16_t new_qs = nb_queues - old_nb_queues;
>>>>> -
>>>>> - memset(rxq + old_nb_queues, 0,
>>>>> - sizeof(rxq[0]) * new_qs);
>>>>> + rxq[i] = NULL;
>>>>
>>>> It looks like the patch should be rebased on top of
>>>> next-net main because of queue release patches.
>>>>
>>>> [snip]
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3 2/4] mempool: add non-IO flag
2021-10-12 0:04 4% ` [dpdk-dev] [PATCH v3 2/4] mempool: add non-IO flag Dmitry Kozlyuk
@ 2021-10-12 3:37 0% ` Jerin Jacob
2021-10-12 6:42 0% ` Andrew Rybchenko
1 sibling, 0 replies; 200+ results
From: Jerin Jacob @ 2021-10-12 3:37 UTC (permalink / raw)
To: Dmitry Kozlyuk
Cc: dpdk-dev, Thomas Monjalon, Matan Azrad, Olivier Matz, Andrew Rybchenko
On Tue, Oct 12, 2021 at 5:34 AM Dmitry Kozlyuk <dkozlyuk@oss.nvidia.com> wrote:
>
> Mempool is a generic allocator that is not necessarily used for device
> IO operations and its memory for DMA. Add MEMPOOL_F_NON_IO flag to mark
> such mempools.
> Discussion: https://mails.dpdk.org/archives/dev/2021-August/216654.html
>
> Signed-off-by: Dmitry Kozlyuk <dkozlyuk@nvidia.com>
> Acked-by: Matan Azrad <matan@nvidia.com>
> ---
> doc/guides/rel_notes/release_21_11.rst | 3 +++
> lib/mempool/rte_mempool.h | 4 ++++
> 2 files changed, 7 insertions(+)
>
> diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
> index 5036641842..dbabdc9759 100644
> --- a/doc/guides/rel_notes/release_21_11.rst
> +++ b/doc/guides/rel_notes/release_21_11.rst
> @@ -208,6 +208,9 @@ API Changes
> the crypto/security operation. This field will be used to communicate
> events such as soft expiry with IPsec in lookaside mode.
>
> +* mempool: Added ``MEMPOOL_F_NON_IO`` flag to give a hint to DPDK components
> + that objects from this pool will not be used for device IO (e.g. DMA).
> +
>
> ABI Changes
> -----------
> diff --git a/lib/mempool/rte_mempool.h b/lib/mempool/rte_mempool.h
> index e2bf40aa09..b48d9f89c2 100644
> --- a/lib/mempool/rte_mempool.h
> +++ b/lib/mempool/rte_mempool.h
> @@ -262,6 +262,7 @@ struct rte_mempool {
> #define MEMPOOL_F_SC_GET 0x0008 /**< Default get is "single-consumer".*/
> #define MEMPOOL_F_POOL_CREATED 0x0010 /**< Internal: pool is created. */
> #define MEMPOOL_F_NO_IOVA_CONTIG 0x0020 /**< Don't need IOVA contiguous objs. */
> +#define MEMPOOL_F_NON_IO 0x0040 /**< Not used for device IO (DMA). */
Since it is the hint, How about changing the flag to MEMPOOL_F_HINT_NON_IO.
Otherwise, it looks good to me.
Acked-by: Jerin Jacob <jerinj@marvell.com>
>
> /**
> * @internal When debug is enabled, store some statistics.
> @@ -991,6 +992,9 @@ typedef void (rte_mempool_ctor_t)(struct rte_mempool *, void *);
> * "single-consumer". Otherwise, it is "multi-consumers".
> * - MEMPOOL_F_NO_IOVA_CONTIG: If set, allocated objects won't
> * necessarily be contiguous in IO memory.
> + * - MEMPOOL_F_NON_IO: If set, the mempool is considered to be
> + * never used for device IO, i.e. for DMA operations.
> + * It's a hint to other components and does not affect the mempool behavior.
> * @return
> * The pointer to the new allocated mempool, on success. NULL on error
> * with rte_errno set appropriately. Possible rte_errno values include:
> --
> 2.25.1
>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v3 2/4] mempool: add non-IO flag
@ 2021-10-12 0:04 4% ` Dmitry Kozlyuk
2021-10-12 3:37 0% ` Jerin Jacob
2021-10-12 6:42 0% ` Andrew Rybchenko
1 sibling, 2 replies; 200+ results
From: Dmitry Kozlyuk @ 2021-10-12 0:04 UTC (permalink / raw)
To: dev; +Cc: Thomas Monjalon, Matan Azrad, Olivier Matz, Andrew Rybchenko
Mempool is a generic allocator that is not necessarily used for device
IO operations and its memory for DMA. Add MEMPOOL_F_NON_IO flag to mark
such mempools.
Discussion: https://mails.dpdk.org/archives/dev/2021-August/216654.html
Signed-off-by: Dmitry Kozlyuk <dkozlyuk@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
---
doc/guides/rel_notes/release_21_11.rst | 3 +++
lib/mempool/rte_mempool.h | 4 ++++
2 files changed, 7 insertions(+)
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index 5036641842..dbabdc9759 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -208,6 +208,9 @@ API Changes
the crypto/security operation. This field will be used to communicate
events such as soft expiry with IPsec in lookaside mode.
+* mempool: Added ``MEMPOOL_F_NON_IO`` flag to give a hint to DPDK components
+ that objects from this pool will not be used for device IO (e.g. DMA).
+
ABI Changes
-----------
diff --git a/lib/mempool/rte_mempool.h b/lib/mempool/rte_mempool.h
index e2bf40aa09..b48d9f89c2 100644
--- a/lib/mempool/rte_mempool.h
+++ b/lib/mempool/rte_mempool.h
@@ -262,6 +262,7 @@ struct rte_mempool {
#define MEMPOOL_F_SC_GET 0x0008 /**< Default get is "single-consumer".*/
#define MEMPOOL_F_POOL_CREATED 0x0010 /**< Internal: pool is created. */
#define MEMPOOL_F_NO_IOVA_CONTIG 0x0020 /**< Don't need IOVA contiguous objs. */
+#define MEMPOOL_F_NON_IO 0x0040 /**< Not used for device IO (DMA). */
/**
* @internal When debug is enabled, store some statistics.
@@ -991,6 +992,9 @@ typedef void (rte_mempool_ctor_t)(struct rte_mempool *, void *);
* "single-consumer". Otherwise, it is "multi-consumers".
* - MEMPOOL_F_NO_IOVA_CONTIG: If set, allocated objects won't
* necessarily be contiguous in IO memory.
+ * - MEMPOOL_F_NON_IO: If set, the mempool is considered to be
+ * never used for device IO, i.e. for DMA operations.
+ * It's a hint to other components and does not affect the mempool behavior.
* @return
* The pointer to the new allocated mempool, on success. NULL on error
* with rte_errno set appropriately. Possible rte_errno values include:
--
2.25.1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v5 2/7] ethdev: allocate max space for internal queue array
2021-10-11 17:15 0% ` Andrew Rybchenko
@ 2021-10-11 23:06 0% ` Ananyev, Konstantin
2021-10-12 5:47 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2021-10-11 23:06 UTC (permalink / raw)
To: Andrew Rybchenko, dev
Cc: Li, Xiaoyun, anoobj, jerinj, ndabilpuram, adwivedi,
shepard.siegel, ed.czeck, john.miller, irusskikh, ajit.khaparde,
somnath.kotur, rahul.lakkireddy, hemant.agrawal, sachin.saxena,
Wang, Haiyue, Daley, John, hyonkim, Zhang, Qi Z, Wang, Xiao W,
humin29, yisen.zhuang, oulijun, Xing, Beilei, Wu, Jingjing, Yang,
Qiming, matan, viacheslavo, sthemmin, longli, heinrich.kuhn,
kirankumark, mczekaj, jiawenwu, jianwang, maxime.coquelin, Xia,
Chenbo, thomas, Yigit, Ferruh, mdr, Jayatheerthan, Jay
> >>> At queue configure stage always allocate space for maximum possible
> >>> number (RTE_MAX_QUEUES_PER_PORT) of queue pointers.
> >>> That will allow 'fast' inline functions (eth_rx_burst, etc.) to refer
> >>> pointer to internal queue data without extra checking of current number
> >>> of configured queues.
> >>> That would help in future to hide rte_eth_dev and related structures.
> >>> It means that from now on, each ethdev port will always consume:
> >>> ((2*sizeof(uintptr_t))* RTE_MAX_QUEUES_PER_PORT)
> >>> bytes of memory for its queue pointers.
> >>> With RTE_MAX_QUEUES_PER_PORT==1024 (default value) it is 16KB per port.
> >>>
> >>> Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> >>> ---
> >>> lib/ethdev/rte_ethdev.c | 36 +++++++++---------------------------
> >>> 1 file changed, 9 insertions(+), 27 deletions(-)
> >>>
> >>> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
> >>> index ed37f8871b..c8abda6dd7 100644
> >>> --- a/lib/ethdev/rte_ethdev.c
> >>> +++ b/lib/ethdev/rte_ethdev.c
> >>> @@ -897,7 +897,8 @@ eth_dev_rx_queue_config(struct rte_eth_dev *dev, uint16_t nb_queues)
> >>>
> >>> if (dev->data->rx_queues == NULL && nb_queues != 0) { /* first time configuration */
> >>> dev->data->rx_queues = rte_zmalloc("ethdev->rx_queues",
> >>> - sizeof(dev->data->rx_queues[0]) * nb_queues,
> >>> + sizeof(dev->data->rx_queues[0]) *
> >>> + RTE_MAX_QUEUES_PER_PORT,
> >>> RTE_CACHE_LINE_SIZE);
> >>
> >> Looking at it I have few questions:
> >> 1. Why is nb_queues == 0 case kept as an exception? Yes,
> >> strictly speaking it is not the problem of the patch,
> >> DPDK will still segfault (non-debug build) if I
> >> allocate Tx queues only but call rte_eth_rx_burst().
> >
> > eth_dev_rx_queue_config(.., nb_queues=0) is used in few places to clean-up things.
>
> No, as far as I know. For Tx only application (e.g. traffic generator)
> it is 100% legal to configure with tx_queues=X, rx_queues=0.
> The same is for Rx only application (e.g. packet capture).
Yes, that is valid config for sure.
I just pointed that simply ignoring 'nb_queues' value and
always allocating space for max possible queues, i.e:
eth_dev_rx_queue_config(struct rte_eth_dev *dev, uint16_t nb_queues)
{
....
- if (dev->data->rx_queues == NULL && nb_queues != 0) { /* first time configuration */
+ if (dev->data->rx_queues == NULL) {
wouldn't work, as right now nb_queues == 0 has extra special meaning -
do final cleanup and free dev->data->rx_queues.
But re-reading the text below, it seems that I misunderstood you
and it probably wasn't your intention anyway.
>
> >
> >> After reading the patch description I thought that
> >> we're trying to address it.
> >
> > We do, though I can't see how we can address it in this patch.
> > Though it is a good idea - I think I can add extra check in eth_dev_fp_ops_setup()
> > or around and setup RX function pointers only when dev->data->rx_queues != NULL.
> > Same for TX.
>
> You don't need to care about these pointers, if these arrays are
> always allocated. See (3) below.
>
> >
> >> 2. Why do we need to allocate memory dynamically?
> >> Can we just make rx_queues an array of appropriate size?
> >
> > Pavan already asked same question.
> > My answer to him:
> > Yep we can, and yes it will simplify this peace of code.
> > The main reason I decided no to do this change now -
> > it will change layout of the_eth_dev_data structure.
> > In this series I tried to mininize(/avoid) changes in rte_eth_dev and rte_eth_dev_data,
> > as much as possible to avoid any unforeseen performance and functional impacts.
> > If we'll manage to make rte_eth_dev and rte_eth_dev_data private we can in future
> > consider that one and other changes in rte_eth_dev and rte_eth_dev_data layouts
> > without worrying about ABI breakage
>
> Thanks a lot. Makes sense.
>
> >> May be wasting 512K unconditionally is too much.
> >> 3. If wasting 512K is too much, I'd consider to move
> >> allocation to eth_dev_get(). If
> >
> > Don't understand where 512KB came from.
>
> 32 port * 1024 queues * 2 types * 8 pointer size
> if we allocate as in (2) above.
>
> > each ethdev port will always consume:
> > ((2*sizeof(uintptr_t))* RTE_MAX_QUEUES_PER_PORT)
> > bytes of memory for its queue pointers.
> > With RTE_MAX_QUEUES_PER_PORT==1024 (default value) it is 16KB per port.
>
> IMHO it will be a bit nicer if queue pointers arrays are allocated
> on device get if size is fixed. It is just a suggestion. If you
> disagree, feel free to drop it.
You mean - allocate these arrays somewhere at rte_eth_dev_allocate() path?
That sounds like an interesting idea, but seems too drastic to me at that stage.
>
> >>> if (dev->data->rx_queues == NULL) {
> >>> dev->data->nb_rx_queues = 0;
> >>> @@ -908,21 +909,11 @@ eth_dev_rx_queue_config(struct rte_eth_dev *dev, uint16_t nb_queues)
> >>>
> >>> rxq = dev->data->rx_queues;
> >>>
> >>> - for (i = nb_queues; i < old_nb_queues; i++)
> >>> + for (i = nb_queues; i < old_nb_queues; i++) {
> >>> (*dev->dev_ops->rx_queue_release)(rxq[i]);
> >>> - rxq = rte_realloc(rxq, sizeof(rxq[0]) * nb_queues,
> >>> - RTE_CACHE_LINE_SIZE);
> >>> - if (rxq == NULL)
> >>> - return -(ENOMEM);
> >>> - if (nb_queues > old_nb_queues) {
> >>> - uint16_t new_qs = nb_queues - old_nb_queues;
> >>> -
> >>> - memset(rxq + old_nb_queues, 0,
> >>> - sizeof(rxq[0]) * new_qs);
> >>> + rxq[i] = NULL;
> >>
> >> It looks like the patch should be rebased on top of
> >> next-net main because of queue release patches.
> >>
> >> [snip]
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [EXT] Re: [PATCH v2 3/3] security: add reserved bitfields
2021-10-11 16:58 0% ` [dpdk-dev] [EXT] " Akhil Goyal
@ 2021-10-11 22:15 3% ` Stephen Hemminger
2021-10-12 8:31 0% ` Kinsella, Ray
2021-10-12 6:59 0% ` Thomas Monjalon
1 sibling, 1 reply; 200+ results
From: Stephen Hemminger @ 2021-10-11 22:15 UTC (permalink / raw)
To: Akhil Goyal
Cc: Thomas Monjalon, dev, david.marchand, hemant.agrawal,
Anoob Joseph, pablo.de.lara.guarch, fiona.trahe, declan.doherty,
matan, g.singh, roy.fan.zhang, jianjay.zhou, asomalap,
ruifeng.wang, konstantin.ananyev, radu.nicolau, ajit.khaparde,
Nagadheeraj Rottela, Ankur Dwivedi, ciara.power, ray.kinsella,
bruce.richardson
On Mon, 11 Oct 2021 16:58:24 +0000
Akhil Goyal <gakhil@marvell.com> wrote:
> > 08/10/2021 22:45, Akhil Goyal:
> > > In struct rte_security_ipsec_sa_options, for every new option
> > > added, there is an ABI breakage, to avoid, a reserved_opts
> > > bitfield is added to for the remaining bits available in the
> > > structure.
> > > Now for every new sa option, these reserved_opts can be reduced
> > > and new option can be added.
> >
> > How do you make sure this field is initialized to 0?
> >
> Struct rte_security_ipsec_xform Is part of rte_security_capability as well
> As a configuration structure in session create.
> User, should ensure that if a device support that option(in capability), then
> only these options will take into effect or else it will be don't care for the PMD.
> The initial values of capabilities are set by PMD statically based on the features
> that it support.
> So if someone sets a bit in reserved_opts, it will work only if PMD support it
> And sets the corresponding field in capabilities.
> But yes, if a new field is added in future, and user sets the reserved_opts by mistake
> And the PMD supports that feature as well, then that feature will be enabled.
> This may or may not create issue depending on the feature which is enabled.
>
> Should I add a note in the comments to clarify that reserved_opts should be set as 0
> And future releases may change this without notice(But reserved in itself suggest that)?
> Adding an explicit check in session_create does not make sense to me.
> What do you suggest?
>
> Regards,
> Akhil
>
The problem is if user creates an on stack variable and sets the unreserved
fields to good values but other parts are garbage. This passes API/ABI unless
you strictly enforce that all reserved fields are zero.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v1 1/6] bbdev: add capability for CRC16 check
2021-10-11 20:17 3% ` Thomas Monjalon
@ 2021-10-11 20:38 0% ` Chautru, Nicolas
2021-10-12 6:53 3% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Chautru, Nicolas @ 2021-10-11 20:38 UTC (permalink / raw)
To: Thomas Monjalon, gakhil; +Cc: dev, trix, hemant.agrawal, Zhang, Mingshan
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Monday, October 11, 2021 1:17 PM
> To: gakhil@marvell.com; Chautru, Nicolas <nicolas.chautru@intel.com>
> Cc: dev@dpdk.org; trix@redhat.com; hemant.agrawal@nxp.com; Zhang,
> Mingshan <mingshan.zhang@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v1 1/6] bbdev: add capability for CRC16
> check
>
> 13/08/2021 18:51, Nicolas Chautru:
> > Adding a missing operation when CRC16
> > is being used for TB CRC check.
> >
> > Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
> > ---
> > --- a/doc/guides/rel_notes/release_21_11.rst
> > +++ b/doc/guides/rel_notes/release_21_11.rst
> > @@ -84,6 +84,7 @@ API Changes
> > Also, make sure to start the actual text at the margin.
> > =======================================================
> >
> > +* bbdev: Added capability related to more comprehensive CRC options.
>
> That's not an API change, the enum symbols are the same.
> Only enum values are changed so it impacts only ABI.
Hi Thomas,
How is that not a API change when new additional capability are exposed? Ie. new enums defined for new capabilities.
I think I see other similar cases in the same release notes " * cryptodev: ``RTE_CRYPTO_AEAD_LIST_END`` from ``enum rte_crypto_aead_algo ...".
You know best, just checking the intent, maybe worth clarifying the guideline except in case this is just me.
>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v1 1/6] bbdev: add capability for CRC16 check
@ 2021-10-11 20:17 3% ` Thomas Monjalon
2021-10-11 20:38 0% ` Chautru, Nicolas
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2021-10-11 20:17 UTC (permalink / raw)
To: gakhil, Nicolas Chautru; +Cc: dev, trix, hemant.agrawal, mingshan.zhang
13/08/2021 18:51, Nicolas Chautru:
> Adding a missing operation when CRC16
> is being used for TB CRC check.
>
> Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
> ---
> --- a/doc/guides/rel_notes/release_21_11.rst
> +++ b/doc/guides/rel_notes/release_21_11.rst
> @@ -84,6 +84,7 @@ API Changes
> Also, make sure to start the actual text at the margin.
> =======================================================
>
> +* bbdev: Added capability related to more comprehensive CRC options.
That's not an API change, the enum symbols are the same.
Only enum values are changed so it impacts only ABI.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 4/7] ethdev: copy fast-path API into separate structure
2021-10-11 16:52 0% ` Ananyev, Konstantin
@ 2021-10-11 17:22 0% ` Andrew Rybchenko
0 siblings, 0 replies; 200+ results
From: Andrew Rybchenko @ 2021-10-11 17:22 UTC (permalink / raw)
To: Ananyev, Konstantin, dev
Cc: Li, Xiaoyun, anoobj, jerinj, ndabilpuram, adwivedi,
shepard.siegel, ed.czeck, john.miller, irusskikh, ajit.khaparde,
somnath.kotur, rahul.lakkireddy, hemant.agrawal, sachin.saxena,
Wang, Haiyue, Daley, John, hyonkim, Zhang, Qi Z, Wang, Xiao W,
humin29, yisen.zhuang, oulijun, Xing, Beilei, Wu, Jingjing, Yang,
Qiming, matan, viacheslavo, sthemmin, longli, heinrich.kuhn,
kirankumark, mczekaj, jiawenwu, jianwang, maxime.coquelin, Xia,
Chenbo, thomas, Yigit, Ferruh, mdr, Jayatheerthan, Jay
On 10/11/21 7:52 PM, Ananyev, Konstantin wrote:
>
>
>> On 10/7/21 2:27 PM, Konstantin Ananyev wrote:
>>> Copy public function pointers (rx_pkt_burst(), etc.) and related
>>> pointers to internal data from rte_eth_dev structure into a
>>> separate flat array. That array will remain in a public header.
>>> The intention here is to make rte_eth_dev and related structures internal.
>>> That should allow future possible changes to core eth_dev structures
>>> to be transparent to the user and help to avoid ABI/API breakages.
>>> The plan is to keep minimal part of data from rte_eth_dev public,
>>> so we still can use inline functions for fast-path calls
>>> (like rte_eth_rx_burst(), etc.) to avoid/minimize slowdown.
>>> The whole idea beyond this new schema:
>>> 1. PMDs keep to setup fast-path function pointers and related data
>>> inside rte_eth_dev struct in the same way they did it before.
>>> 2. Inside rte_eth_dev_start() and inside rte_eth_dev_probing_finish()
>>> (for secondary process) we call eth_dev_fp_ops_setup, which
>>> copies these function and data pointers into rte_eth_fp_ops[port_id].
>>> 3. Inside rte_eth_dev_stop() and inside rte_eth_dev_release_port()
>>> we call eth_dev_fp_ops_reset(), which resets rte_eth_fp_ops[port_id]
>>> into some dummy values.
>>> 4. fast-path ethdev API (rte_eth_rx_burst(), etc.) will use that new
>>> flat array to call PMD specific functions.
>>> That approach should allow us to make rte_eth_devices[] private
>>> without introducing regression and help to avoid changes in drivers code.
>>>
>>> Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
>>
>> Overall LGTM, few nits below.
>>
>>> ---
>>> lib/ethdev/ethdev_private.c | 52 ++++++++++++++++++++++++++++++++++
>>> lib/ethdev/ethdev_private.h | 7 +++++
>>> lib/ethdev/rte_ethdev.c | 27 ++++++++++++++++++
>>> lib/ethdev/rte_ethdev_core.h | 55 ++++++++++++++++++++++++++++++++++++
>>> 4 files changed, 141 insertions(+)
>>>
>>> diff --git a/lib/ethdev/ethdev_private.c b/lib/ethdev/ethdev_private.c
>>> index 012cf73ca2..3eeda6e9f9 100644
>>> --- a/lib/ethdev/ethdev_private.c
>>> +++ b/lib/ethdev/ethdev_private.c
>>> @@ -174,3 +174,55 @@ rte_eth_devargs_parse_representor_ports(char *str, void *data)
>>> RTE_LOG(ERR, EAL, "wrong representor format: %s\n", str);
>>> return str == NULL ? -1 : 0;
>>> }
>>> +
>>> +static uint16_t
>>> +dummy_eth_rx_burst(__rte_unused void *rxq,
>>> + __rte_unused struct rte_mbuf **rx_pkts,
>>> + __rte_unused uint16_t nb_pkts)
>>> +{
>>> + RTE_ETHDEV_LOG(ERR, "rx_pkt_burst for unconfigured port\n");
>>
>> May be "unconfigured" -> "stopped" ? Or "non-started" ?
>
> Yes, it can be configured but not started.
> So 'not started' seems like a better wording here.
> Another option probably: 'not ready'.
> What people think?
Taking into account that some PMds would like to set dummy
pointers in some specifics conditions, I think "not ready"
is the best option here.
>
> ...
>
>>
>>> + rte_errno = ENOTSUP;
>>> + return 0;
>>> +}
>>> +
>>> +struct rte_eth_fp_ops {
>>> +
>>> + /**
>>> + * Rx fast-path functions and related data.
>>> + * 64-bit systems: occupies first 64B line
>>> + */
>>
>> As I understand the above comment is for a group of below
>> fields. If so, Doxygen annocation for member groups should
>> be used.
>
> Ok, and how to do it?
>
See [1]
[1] https://www.doxygen.nl/manual/grouping.html#memgroup
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 2/7] ethdev: allocate max space for internal queue array
2021-10-11 16:25 3% ` Ananyev, Konstantin
@ 2021-10-11 17:15 0% ` Andrew Rybchenko
2021-10-11 23:06 0% ` Ananyev, Konstantin
0 siblings, 1 reply; 200+ results
From: Andrew Rybchenko @ 2021-10-11 17:15 UTC (permalink / raw)
To: Ananyev, Konstantin, dev
Cc: Li, Xiaoyun, anoobj, jerinj, ndabilpuram, adwivedi,
shepard.siegel, ed.czeck, john.miller, irusskikh, ajit.khaparde,
somnath.kotur, rahul.lakkireddy, hemant.agrawal, sachin.saxena,
Wang, Haiyue, Daley, John, hyonkim, Zhang, Qi Z, Wang, Xiao W,
humin29, yisen.zhuang, oulijun, Xing, Beilei, Wu, Jingjing, Yang,
Qiming, matan, viacheslavo, sthemmin, longli, heinrich.kuhn,
kirankumark, mczekaj, jiawenwu, jianwang, maxime.coquelin, Xia,
Chenbo, thomas, Yigit, Ferruh, mdr, Jayatheerthan, Jay
On 10/11/21 7:25 PM, Ananyev, Konstantin wrote:
>
>
>>> At queue configure stage always allocate space for maximum possible
>>> number (RTE_MAX_QUEUES_PER_PORT) of queue pointers.
>>> That will allow 'fast' inline functions (eth_rx_burst, etc.) to refer
>>> pointer to internal queue data without extra checking of current number
>>> of configured queues.
>>> That would help in future to hide rte_eth_dev and related structures.
>>> It means that from now on, each ethdev port will always consume:
>>> ((2*sizeof(uintptr_t))* RTE_MAX_QUEUES_PER_PORT)
>>> bytes of memory for its queue pointers.
>>> With RTE_MAX_QUEUES_PER_PORT==1024 (default value) it is 16KB per port.
>>>
>>> Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
>>> ---
>>> lib/ethdev/rte_ethdev.c | 36 +++++++++---------------------------
>>> 1 file changed, 9 insertions(+), 27 deletions(-)
>>>
>>> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
>>> index ed37f8871b..c8abda6dd7 100644
>>> --- a/lib/ethdev/rte_ethdev.c
>>> +++ b/lib/ethdev/rte_ethdev.c
>>> @@ -897,7 +897,8 @@ eth_dev_rx_queue_config(struct rte_eth_dev *dev, uint16_t nb_queues)
>>>
>>> if (dev->data->rx_queues == NULL && nb_queues != 0) { /* first time configuration */
>>> dev->data->rx_queues = rte_zmalloc("ethdev->rx_queues",
>>> - sizeof(dev->data->rx_queues[0]) * nb_queues,
>>> + sizeof(dev->data->rx_queues[0]) *
>>> + RTE_MAX_QUEUES_PER_PORT,
>>> RTE_CACHE_LINE_SIZE);
>>
>> Looking at it I have few questions:
>> 1. Why is nb_queues == 0 case kept as an exception? Yes,
>> strictly speaking it is not the problem of the patch,
>> DPDK will still segfault (non-debug build) if I
>> allocate Tx queues only but call rte_eth_rx_burst().
>
> eth_dev_rx_queue_config(.., nb_queues=0) is used in few places to clean-up things.
No, as far as I know. For Tx only application (e.g. traffic generator)
it is 100% legal to configure with tx_queues=X, rx_queues=0.
The same is for Rx only application (e.g. packet capture).
>
>> After reading the patch description I thought that
>> we're trying to address it.
>
> We do, though I can't see how we can address it in this patch.
> Though it is a good idea - I think I can add extra check in eth_dev_fp_ops_setup()
> or around and setup RX function pointers only when dev->data->rx_queues != NULL.
> Same for TX.
You don't need to care about these pointers, if these arrays are
always allocated. See (3) below.
>
>> 2. Why do we need to allocate memory dynamically?
>> Can we just make rx_queues an array of appropriate size?
>
> Pavan already asked same question.
> My answer to him:
> Yep we can, and yes it will simplify this peace of code.
> The main reason I decided no to do this change now -
> it will change layout of the_eth_dev_data structure.
> In this series I tried to mininize(/avoid) changes in rte_eth_dev and rte_eth_dev_data,
> as much as possible to avoid any unforeseen performance and functional impacts.
> If we'll manage to make rte_eth_dev and rte_eth_dev_data private we can in future
> consider that one and other changes in rte_eth_dev and rte_eth_dev_data layouts
> without worrying about ABI breakage
Thanks a lot. Makes sense.
>> May be wasting 512K unconditionally is too much.
>> 3. If wasting 512K is too much, I'd consider to move
>> allocation to eth_dev_get(). If
>
> Don't understand where 512KB came from.
32 port * 1024 queues * 2 types * 8 pointer size
if we allocate as in (2) above.
> each ethdev port will always consume:
> ((2*sizeof(uintptr_t))* RTE_MAX_QUEUES_PER_PORT)
> bytes of memory for its queue pointers.
> With RTE_MAX_QUEUES_PER_PORT==1024 (default value) it is 16KB per port.
IMHO it will be a bit nicer if queue pointers arrays are allocated
on device get if size is fixed. It is just a suggestion. If you
disagree, feel free to drop it.
>>> if (dev->data->rx_queues == NULL) {
>>> dev->data->nb_rx_queues = 0;
>>> @@ -908,21 +909,11 @@ eth_dev_rx_queue_config(struct rte_eth_dev *dev, uint16_t nb_queues)
>>>
>>> rxq = dev->data->rx_queues;
>>>
>>> - for (i = nb_queues; i < old_nb_queues; i++)
>>> + for (i = nb_queues; i < old_nb_queues; i++) {
>>> (*dev->dev_ops->rx_queue_release)(rxq[i]);
>>> - rxq = rte_realloc(rxq, sizeof(rxq[0]) * nb_queues,
>>> - RTE_CACHE_LINE_SIZE);
>>> - if (rxq == NULL)
>>> - return -(ENOMEM);
>>> - if (nb_queues > old_nb_queues) {
>>> - uint16_t new_qs = nb_queues - old_nb_queues;
>>> -
>>> - memset(rxq + old_nb_queues, 0,
>>> - sizeof(rxq[0]) * new_qs);
>>> + rxq[i] = NULL;
>>
>> It looks like the patch should be rebased on top of
>> next-net main because of queue release patches.
>>
>> [snip]
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 5/7] ethdev: make fast-path functions to use new flat array
2021-10-11 15:47 0% ` Ananyev, Konstantin
@ 2021-10-11 17:03 0% ` Andrew Rybchenko
0 siblings, 0 replies; 200+ results
From: Andrew Rybchenko @ 2021-10-11 17:03 UTC (permalink / raw)
To: Ananyev, Konstantin, dev
Cc: Li, Xiaoyun, anoobj, jerinj, ndabilpuram, adwivedi,
shepard.siegel, ed.czeck, john.miller, irusskikh, ajit.khaparde,
somnath.kotur, rahul.lakkireddy, hemant.agrawal, sachin.saxena,
Wang, Haiyue, Daley, John, hyonkim, Zhang, Qi Z, Wang, Xiao W,
humin29, yisen.zhuang, oulijun, Xing, Beilei, Wu, Jingjing, Yang,
Qiming, matan, viacheslavo, sthemmin, longli, heinrich.kuhn,
kirankumark, mczekaj, jiawenwu, jianwang, maxime.coquelin, Xia,
Chenbo, thomas, Yigit, Ferruh, mdr, Jayatheerthan, Jay
On 10/11/21 6:47 PM, Ananyev, Konstantin wrote:
>
>>
>> On 10/7/21 2:27 PM, Konstantin Ananyev wrote:
>>> Rework fast-path ethdev functions to use rte_eth_fp_ops[].
>>> While it is an API/ABI breakage, this change is intended to be
>>> transparent for both users (no changes in user app is required) and
>>> PMD developers (no changes in PMD is required).
>>> One extra thing to note - RX/TX callback invocation will cause extra
>>> function call with these changes. That might cause some insignificant
>>> slowdown for code-path where RX/TX callbacks are heavily involved.
>>
>> I'm sorry for nit picking here and below:
>>
>> RX -> Rx, TX -> Tx everywhere above.
>>
>>>
>>> Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
>>> ---
>>> lib/ethdev/ethdev_private.c | 31 +++++
>>> lib/ethdev/rte_ethdev.h | 242 ++++++++++++++++++++++++++----------
>>> lib/ethdev/version.map | 3 +
>>> 3 files changed, 208 insertions(+), 68 deletions(-)
>>>
>>> diff --git a/lib/ethdev/ethdev_private.c b/lib/ethdev/ethdev_private.c
>>> index 3eeda6e9f9..1222c6f84e 100644
>>> --- a/lib/ethdev/ethdev_private.c
>>> +++ b/lib/ethdev/ethdev_private.c
>>> @@ -226,3 +226,34 @@ eth_dev_fp_ops_setup(struct rte_eth_fp_ops *fpo,
>>> fpo->txq.data = dev->data->tx_queues;
>>> fpo->txq.clbk = (void **)(uintptr_t)dev->pre_tx_burst_cbs;
>>> }
>>> +
>>> +uint16_t
>>> +rte_eth_call_rx_callbacks(uint16_t port_id, uint16_t queue_id,
>>> + struct rte_mbuf **rx_pkts, uint16_t nb_rx, uint16_t nb_pkts,
>>> + void *opaque)
>>> +{
>>> + const struct rte_eth_rxtx_callback *cb = opaque;
>>> +
>>> + while (cb != NULL) {
>>> + nb_rx = cb->fn.rx(port_id, queue_id, rx_pkts, nb_rx,
>>> + nb_pkts, cb->param);
>>> + cb = cb->next;
>>> + }
>>> +
>>> + return nb_rx;
>>> +}
>>> +
>>> +uint16_t
>>> +rte_eth_call_tx_callbacks(uint16_t port_id, uint16_t queue_id,
>>> + struct rte_mbuf **tx_pkts, uint16_t nb_pkts, void *opaque)
>>> +{
>>> + const struct rte_eth_rxtx_callback *cb = opaque;
>>> +
>>> + while (cb != NULL) {
>>> + nb_pkts = cb->fn.tx(port_id, queue_id, tx_pkts, nb_pkts,
>>> + cb->param);
>>> + cb = cb->next;
>>> + }
>>> +
>>> + return nb_pkts;
>>> +}
>>> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
>>> index cdd16d6e57..c0e1a40681 100644
>>> --- a/lib/ethdev/rte_ethdev.h
>>> +++ b/lib/ethdev/rte_ethdev.h
>>> @@ -4904,6 +4904,33 @@ int rte_eth_representor_info_get(uint16_t port_id,
>>>
>>> #include <rte_ethdev_core.h>
>>>
>>> +/**
>>> + * @internal
>>> + * Helper routine for eth driver rx_burst API.
>>
>> rx -> Rx
>>
>>> + * Should be called at exit from PMD's rte_eth_rx_bulk implementation.
>>> + * Does necessary post-processing - invokes RX callbacks if any, etc.
>>
>> RX -> Rx
>>
>>> + *
>>> + * @param port_id
>>> + * The port identifier of the Ethernet device.
>>> + * @param queue_id
>>> + * The index of the receive queue from which to retrieve input packets.
>>
>> Isn't:
>> The index of the queue from which packets are received from?
>
> I copied it from comments from rte_eth_rx_burst().
> I suppose it is just two ways to say the same thing.
May be it is just my problem that I don't understand the
initial description.
>
>>
>>> + * @param rx_pkts
>>> + * The address of an array of pointers to *rte_mbuf* structures that
>>> + * have been retrieved from the device.
>>> + * @param nb_pkts
>>
>> Should be @param nb_rx
>
> Ack, will fix.
>
>>
>>> + * The number of packets that were retrieved from the device.
>>> + * @param nb_pkts
>>> + * The number of elements in *rx_pkts* array.
>>
>> @p should be used to refer to a paramter.
>
> To be more precise you are talking about:
> s/*rx_pkts*/@ rx_pkts/
s/"rx_pkts"/@p rx_pkts/
> ?
>
>>
>> The description does not help to understand why both nb_rx and
>> nb_pkts are necessary. Isn't nb_pkts >= nb_rx and nb_rx
>> sufficient?
>
> Nope, that's for callbacks call.
> Will update the comment.
Thanks.
>>> + * @param opaque
>>> + * Opaque pointer of RX queue callback related data.
>>
>> RX -> Rx
>>
>>> + *
>>> + * @return
>>> + * The number of packets effectively supplied to the *rx_pkts* array.
>>
>> @p should be used to refer to a parameter.
>>
>>> + */
>>> +uint16_t rte_eth_call_rx_callbacks(uint16_t port_id, uint16_t queue_id,
>>> + struct rte_mbuf **rx_pkts, uint16_t nb_rx, uint16_t nb_pkts,
>>> + void *opaque);
>>> +
>>> /**
>>> *
>>> * Retrieve a burst of input packets from a receive queue of an Ethernet
>>> @@ -4995,23 +5022,37 @@ static inline uint16_t
>>> rte_eth_rx_burst(uint16_t port_id, uint16_t queue_id,
>>> struct rte_mbuf **rx_pkts, const uint16_t nb_pkts)
>>> {
>>> - struct rte_eth_dev *dev = &rte_eth_devices[port_id];
>>> uint16_t nb_rx;
>>> + struct rte_eth_fp_ops *p;
>>
>> p is typically a very bad name in a funcion with
>> many pointer variables etc. May be "fpo" as in previous
>> patch?
>>
>>> + void *cb, *qd;
>>
>> Please, avoid variable, expecially pointers, declaration in
>> one line.
>
> Here and in other places, I think local variable names and placement,
> is just a matter of personal preference.
Of course you can drop my notes as long as I'm alone.
I've started my comment from "Please" :)
May be I'm asking too much.
Also, I'm sorry, but I stricly against 'p' name since such
naming makes code harder to read.
>
>>
>> I'd suggest to use 'rxq' instead of 'qd'. The first paramter
>> of the rx_pkt_burst is 'rxq'.
>>
>> Also 'cb' seems to be used under RTE_ETHDEV_RXTX_CALLBACKS
>> only. If so, it could be unused variable warning if
>> RTE_ETHDEV_RXTX_CALLBACKS is not defined.
>
> Good point, will move it back under #ifdef RTE_ETHDEV_RXTX_CALLBACKS.
>
>>> +
>>> +#ifdef RTE_ETHDEV_DEBUG_RX
>>> + if (port_id >= RTE_MAX_ETHPORTS ||
>>> + queue_id >= RTE_MAX_QUEUES_PER_PORT) {
>>> + RTE_ETHDEV_LOG(ERR,
>>> + "Invalid port_id=%u or queue_id=%u\n",
>>> + port_id, queue_id);
>>> + return 0;
>>> + }
>>> +#endif
>>> +
>>> + /* fetch pointer to queue data */
>>> + p = &rte_eth_fp_ops[port_id];
>>> + qd = p->rxq.data[queue_id];
>>>
>>> #ifdef RTE_ETHDEV_DEBUG_RX
>>> RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
>>> - RTE_FUNC_PTR_OR_ERR_RET(*dev->rx_pkt_burst, 0);
>>>
>>> - if (queue_id >= dev->data->nb_rx_queues) {
>>> - RTE_ETHDEV_LOG(ERR, "Invalid RX queue_id=%u\n", queue_id);
>>> + if (qd == NULL) {
>>> + RTE_ETHDEV_LOG(ERR, "Invalid RX queue_id=%u for port_id=%u\n",
>>
>> RX -> Rx
>>
>>> + queue_id, port_id);
>>> return 0;
>>> }
>>> #endif
>>> - nb_rx = (*dev->rx_pkt_burst)(dev->data->rx_queues[queue_id],
>>> - rx_pkts, nb_pkts);
>>> +
>>> + nb_rx = p->rx_pkt_burst(qd, rx_pkts, nb_pkts);
>>>
>>> #ifdef RTE_ETHDEV_RXTX_CALLBACKS
>>> - struct rte_eth_rxtx_callback *cb;
>>>
>>> /* __ATOMIC_RELEASE memory order was used when the
>>> * call back was inserted into the list.
>>> @@ -5019,16 +5060,10 @@ rte_eth_rx_burst(uint16_t port_id, uint16_t queue_id,
>>> * cb and cb->fn/cb->next, __ATOMIC_ACQUIRE memory order is
>>> * not required.
>>> */
>>> - cb = __atomic_load_n(&dev->post_rx_burst_cbs[queue_id],
>>> - __ATOMIC_RELAXED);
>>> -
>>> - if (unlikely(cb != NULL)) {
>>> - do {
>>> - nb_rx = cb->fn.rx(port_id, queue_id, rx_pkts, nb_rx,
>>> - nb_pkts, cb->param);
>>> - cb = cb->next;
>>> - } while (cb != NULL);
>>> - }
>>> + cb = __atomic_load_n((void **)&p->rxq.clbk[queue_id], __ATOMIC_RELAXED);
>>> + if (unlikely(cb != NULL))
>>> + nb_rx = rte_eth_call_rx_callbacks(port_id, queue_id, rx_pkts,
>>> + nb_rx, nb_pkts, cb);
>>> #endif
>>>
>>> rte_ethdev_trace_rx_burst(port_id, queue_id, (void **)rx_pkts, nb_rx);
>>> @@ -5051,16 +5086,27 @@ rte_eth_rx_burst(uint16_t port_id, uint16_t queue_id,
>>> static inline int
>>> rte_eth_rx_queue_count(uint16_t port_id, uint16_t queue_id)
>>> {
>>> - struct rte_eth_dev *dev;
>>> + struct rte_eth_fp_ops *p;
>>> + void *qd;
>>
>> p -> fpo, qd -> rxq
>>
>>> +
>>> + if (port_id >= RTE_MAX_ETHPORTS ||
>>> + queue_id >= RTE_MAX_QUEUES_PER_PORT) {
>>> + RTE_ETHDEV_LOG(ERR,
>>> + "Invalid port_id=%u or queue_id=%u\n",
>>> + port_id, queue_id);
>>> + return -EINVAL;
>>> + }
>>> +
>>> + /* fetch pointer to queue data */
>>> + p = &rte_eth_fp_ops[port_id];
>>> + qd = p->rxq.data[queue_id];
>>>
>>> RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
>>> - dev = &rte_eth_devices[port_id];
>>> - RTE_FUNC_PTR_OR_ERR_RET(*dev->rx_queue_count, -ENOTSUP);
>>> - if (queue_id >= dev->data->nb_rx_queues ||
>>> - dev->data->rx_queues[queue_id] == NULL)
>>> + RTE_FUNC_PTR_OR_ERR_RET(*p->rx_queue_count, -ENOTSUP);
>>> + if (qd == NULL)
>>> return -EINVAL;
>>>
>>> - return (int)(*dev->rx_queue_count)(dev->data->rx_queues[queue_id]);
>>> + return (int)(*p->rx_queue_count)(qd);
>>> }
>>>
>>> /**@{@name Rx hardware descriptor states
>>> @@ -5108,21 +5154,30 @@ static inline int
>>> rte_eth_rx_descriptor_status(uint16_t port_id, uint16_t queue_id,
>>> uint16_t offset)
>>> {
>>> - struct rte_eth_dev *dev;
>>> - void *rxq;
>>> + struct rte_eth_fp_ops *p;
>>> + void *qd;
>>
>> p -> fpo, qd -> rxq
>>
>>>
>>> #ifdef RTE_ETHDEV_DEBUG_RX
>>> - RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
>>> + if (port_id >= RTE_MAX_ETHPORTS ||
>>> + queue_id >= RTE_MAX_QUEUES_PER_PORT) {
>>> + RTE_ETHDEV_LOG(ERR,
>>> + "Invalid port_id=%u or queue_id=%u\n",
>>> + port_id, queue_id);
>>> + return -EINVAL;
>>> + }
>>> #endif
>>> - dev = &rte_eth_devices[port_id];
>>> +
>>> + /* fetch pointer to queue data */
>>> + p = &rte_eth_fp_ops[port_id];
>>> + qd = p->rxq.data[queue_id];
>>> +
>>> #ifdef RTE_ETHDEV_DEBUG_RX
>>> - if (queue_id >= dev->data->nb_rx_queues)
>>> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
>>> + if (qd == NULL)
>>> return -ENODEV;
>>> #endif
>>> - RTE_FUNC_PTR_OR_ERR_RET(*dev->rx_descriptor_status, -ENOTSUP);
>>> - rxq = dev->data->rx_queues[queue_id];
>>> -
>>> - return (*dev->rx_descriptor_status)(rxq, offset);
>>> + RTE_FUNC_PTR_OR_ERR_RET(*p->rx_descriptor_status, -ENOTSUP);
>>> + return (*p->rx_descriptor_status)(qd, offset);
>>> }
>>>
>>> /**@{@name Tx hardware descriptor states
>>> @@ -5169,23 +5224,54 @@ rte_eth_rx_descriptor_status(uint16_t port_id, uint16_t queue_id,
>>> static inline int rte_eth_tx_descriptor_status(uint16_t port_id,
>>> uint16_t queue_id, uint16_t offset)
>>> {
>>> - struct rte_eth_dev *dev;
>>> - void *txq;
>>> + struct rte_eth_fp_ops *p;
>>> + void *qd;
>>
>> p -> fpo, qd -> txq
>>
>>>
>>> #ifdef RTE_ETHDEV_DEBUG_TX
>>> - RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
>>> + if (port_id >= RTE_MAX_ETHPORTS ||
>>> + queue_id >= RTE_MAX_QUEUES_PER_PORT) {
>>> + RTE_ETHDEV_LOG(ERR,
>>> + "Invalid port_id=%u or queue_id=%u\n",
>>> + port_id, queue_id);
>>> + return -EINVAL;
>>> + }
>>> #endif
>>> - dev = &rte_eth_devices[port_id];
>>> +
>>> + /* fetch pointer to queue data */
>>> + p = &rte_eth_fp_ops[port_id];
>>> + qd = p->txq.data[queue_id];
>>> +
>>> #ifdef RTE_ETHDEV_DEBUG_TX
>>> - if (queue_id >= dev->data->nb_tx_queues)
>>> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
>>> + if (qd == NULL)
>>> return -ENODEV;
>>> #endif
>>> - RTE_FUNC_PTR_OR_ERR_RET(*dev->tx_descriptor_status, -ENOTSUP);
>>> - txq = dev->data->tx_queues[queue_id];
>>> -
>>> - return (*dev->tx_descriptor_status)(txq, offset);
>>> + RTE_FUNC_PTR_OR_ERR_RET(*p->tx_descriptor_status, -ENOTSUP);
>>> + return (*p->tx_descriptor_status)(qd, offset);
>>> }
>>>
>>> +/**
>>> + * @internal
>>> + * Helper routine for eth driver tx_burst API.
>>> + * Should be called before entry PMD's rte_eth_tx_bulk implementation.
>>> + * Does necessary pre-processing - invokes TX callbacks if any, etc.
>>
>> TX -> Tx
>>
>>> + *
>>> + * @param port_id
>>> + * The port identifier of the Ethernet device.
>>> + * @param queue_id
>>> + * The index of the transmit queue through which output packets must be
>>> + * sent.
>>> + * @param tx_pkts
>>> + * The address of an array of *nb_pkts* pointers to *rte_mbuf* structures
>>> + * which contain the output packets.
>>
>> *nb_pkts* -> @p nb_pkts
>>
>>> + * @param nb_pkts
>>> + * The maximum number of packets to transmit.
>>> + * @return
>>> + * The number of output packets to transmit.
>>> + */
>>> +uint16_t rte_eth_call_tx_callbacks(uint16_t port_id, uint16_t queue_id,
>>> + struct rte_mbuf **tx_pkts, uint16_t nb_pkts, void *opaque);
>>> +
>>> /**
>>> * Send a burst of output packets on a transmit queue of an Ethernet device.
>>> *
>>> @@ -5256,20 +5342,34 @@ static inline uint16_t
>>> rte_eth_tx_burst(uint16_t port_id, uint16_t queue_id,
>>> struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
>>> {
>>> - struct rte_eth_dev *dev = &rte_eth_devices[port_id];
>>> + struct rte_eth_fp_ops *p;
>>> + void *cb, *qd;
>>
>> Same as above
>>
>>> +
>>> +#ifdef RTE_ETHDEV_DEBUG_TX
>>> + if (port_id >= RTE_MAX_ETHPORTS ||
>>> + queue_id >= RTE_MAX_QUEUES_PER_PORT) {
>>> + RTE_ETHDEV_LOG(ERR,
>>> + "Invalid port_id=%u or queue_id=%u\n",
>>> + port_id, queue_id);
>>> + return 0;
>>> + }
>>> +#endif
>>> +
>>> + /* fetch pointer to queue data */
>>> + p = &rte_eth_fp_ops[port_id];
>>> + qd = p->txq.data[queue_id];
>>>
>>> #ifdef RTE_ETHDEV_DEBUG_TX
>>> RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
>>> - RTE_FUNC_PTR_OR_ERR_RET(*dev->tx_pkt_burst, 0);
>>>
>>> - if (queue_id >= dev->data->nb_tx_queues) {
>>> - RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u\n", queue_id);
>>> + if (qd == NULL) {
>>> + RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u for port_id=%u\n",
>>
>> TX -> Tx
>>
>>> + queue_id, port_id);
>>> return 0;
>>> }
>>> #endif
>>>
>>> #ifdef RTE_ETHDEV_RXTX_CALLBACKS
>>> - struct rte_eth_rxtx_callback *cb;
>>>
>>> /* __ATOMIC_RELEASE memory order was used when the
>>> * call back was inserted into the list.
>>> @@ -5277,21 +5377,16 @@ rte_eth_tx_burst(uint16_t port_id, uint16_t queue_id,
>>> * cb and cb->fn/cb->next, __ATOMIC_ACQUIRE memory order is
>>> * not required.
>>> */
>>> - cb = __atomic_load_n(&dev->pre_tx_burst_cbs[queue_id],
>>> - __ATOMIC_RELAXED);
>>> -
>>> - if (unlikely(cb != NULL)) {
>>> - do {
>>> - nb_pkts = cb->fn.tx(port_id, queue_id, tx_pkts, nb_pkts,
>>> - cb->param);
>>> - cb = cb->next;
>>> - } while (cb != NULL);
>>> - }
>>> + cb = __atomic_load_n((void **)&p->txq.clbk[queue_id], __ATOMIC_RELAXED);
>>> + if (unlikely(cb != NULL))
>>> + nb_pkts = rte_eth_call_tx_callbacks(port_id, queue_id, tx_pkts,
>>> + nb_pkts, cb);
>>> #endif
>>>
>>> - rte_ethdev_trace_tx_burst(port_id, queue_id, (void **)tx_pkts,
>>> - nb_pkts);
>>> - return (*dev->tx_pkt_burst)(dev->data->tx_queues[queue_id], tx_pkts, nb_pkts);
>>> + nb_pkts = p->tx_pkt_burst(qd, tx_pkts, nb_pkts);
>>> +
>>> + rte_ethdev_trace_tx_burst(port_id, queue_id, (void **)tx_pkts, nb_pkts);
>>> + return nb_pkts;
>>> }
>>>
>>> /**
>>> @@ -5354,31 +5449,42 @@ static inline uint16_t
>>> rte_eth_tx_prepare(uint16_t port_id, uint16_t queue_id,
>>> struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
>>> {
>>> - struct rte_eth_dev *dev;
>>> + struct rte_eth_fp_ops *p;
>>> + void *qd;
>>
>> p->fpo, qd->txq
>>
>>>
>>> #ifdef RTE_ETHDEV_DEBUG_TX
>>> - if (!rte_eth_dev_is_valid_port(port_id)) {
>>> - RTE_ETHDEV_LOG(ERR, "Invalid TX port_id=%u\n", port_id);
>>> + if (port_id >= RTE_MAX_ETHPORTS ||
>>> + queue_id >= RTE_MAX_QUEUES_PER_PORT) {
>>> + RTE_ETHDEV_LOG(ERR,
>>> + "Invalid port_id=%u or queue_id=%u\n",
>>> + port_id, queue_id);
>>> rte_errno = ENODEV;
>>> return 0;
>>> }
>>> #endif
>>>
>>> - dev = &rte_eth_devices[port_id];
>>> + /* fetch pointer to queue data */
>>> + p = &rte_eth_fp_ops[port_id];
>>> + qd = p->txq.data[queue_id];
>>>
>>> #ifdef RTE_ETHDEV_DEBUG_TX
>>> - if (queue_id >= dev->data->nb_tx_queues) {
>>> - RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u\n", queue_id);
>>> + if (!rte_eth_dev_is_valid_port(port_id)) {
>>> + RTE_ETHDEV_LOG(ERR, "Invalid TX port_id=%u\n", port_id);
>>
>> TX -> Tx
>>
>>> + rte_errno = ENODEV;
>>> + return 0;
>>> + }
>>> + if (qd == NULL) {
>>> + RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u for port_id=%u\n",
>>
>> TX -> Tx
>>
>>> + queue_id, port_id);
>>> rte_errno = EINVAL;
>>> return 0;
>>> }
>>> #endif
>>>
>>> - if (!dev->tx_pkt_prepare)
>>> + if (!p->tx_pkt_prepare)
>>
>> Please, change it to compare vs NULL since you touch the line.
>> Just to be consistent with DPDK coding style and lines above.
>
> Ok, I am also fond of explicit comparisons :)
Thanks.
>
>
>>> return nb_pkts;
>>>
>>> - return (*dev->tx_pkt_prepare)(dev->data->tx_queues[queue_id],
>>> - tx_pkts, nb_pkts);
>>> + return p->tx_pkt_prepare(qd, tx_pkts, nb_pkts);
>>> }
>>>
>>> #else
>>> diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map
>>> index 904bce6ea1..79e62dcf61 100644
>>> --- a/lib/ethdev/version.map
>>> +++ b/lib/ethdev/version.map
>>> @@ -7,6 +7,8 @@ DPDK_22 {
>>> rte_eth_allmulticast_disable;
>>> rte_eth_allmulticast_enable;
>>> rte_eth_allmulticast_get;
>>> + rte_eth_call_rx_callbacks;
>>> + rte_eth_call_tx_callbacks;
>>> rte_eth_dev_adjust_nb_rx_tx_desc;
>>> rte_eth_dev_callback_register;
>>> rte_eth_dev_callback_unregister;
>>> @@ -76,6 +78,7 @@ DPDK_22 {
>>> rte_eth_find_next_of;
>>> rte_eth_find_next_owned_by;
>>> rte_eth_find_next_sibling;
>>> + rte_eth_fp_ops;
>>> rte_eth_iterator_cleanup;
>>> rte_eth_iterator_init;
>>> rte_eth_iterator_next;
>>>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [EXT] Re: [PATCH v2 3/3] security: add reserved bitfields
2021-10-11 8:31 0% ` Thomas Monjalon
@ 2021-10-11 16:58 0% ` Akhil Goyal
2021-10-11 22:15 3% ` Stephen Hemminger
2021-10-12 6:59 0% ` Thomas Monjalon
0 siblings, 2 replies; 200+ results
From: Akhil Goyal @ 2021-10-11 16:58 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev, david.marchand, hemant.agrawal, Anoob Joseph,
pablo.de.lara.guarch, fiona.trahe, declan.doherty, matan,
g.singh, roy.fan.zhang, jianjay.zhou, asomalap, ruifeng.wang,
konstantin.ananyev, radu.nicolau, ajit.khaparde,
Nagadheeraj Rottela, Ankur Dwivedi, ciara.power,
Stephen Hemminger, ray.kinsella, bruce.richardson
> 08/10/2021 22:45, Akhil Goyal:
> > In struct rte_security_ipsec_sa_options, for every new option
> > added, there is an ABI breakage, to avoid, a reserved_opts
> > bitfield is added to for the remaining bits available in the
> > structure.
> > Now for every new sa option, these reserved_opts can be reduced
> > and new option can be added.
>
> How do you make sure this field is initialized to 0?
>
Struct rte_security_ipsec_xform Is part of rte_security_capability as well
As a configuration structure in session create.
User, should ensure that if a device support that option(in capability), then
only these options will take into effect or else it will be don't care for the PMD.
The initial values of capabilities are set by PMD statically based on the features
that it support.
So if someone sets a bit in reserved_opts, it will work only if PMD support it
And sets the corresponding field in capabilities.
But yes, if a new field is added in future, and user sets the reserved_opts by mistake
And the PMD supports that feature as well, then that feature will be enabled.
This may or may not create issue depending on the feature which is enabled.
Should I add a note in the comments to clarify that reserved_opts should be set as 0
And future releases may change this without notice(But reserved in itself suggest that)?
Adding an explicit check in session_create does not make sense to me.
What do you suggest?
Regards,
Akhil
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 4/7] ethdev: copy fast-path API into separate structure
2021-10-11 8:25 0% ` Andrew Rybchenko
@ 2021-10-11 16:52 0% ` Ananyev, Konstantin
2021-10-11 17:22 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2021-10-11 16:52 UTC (permalink / raw)
To: Andrew Rybchenko, dev
Cc: Li, Xiaoyun, anoobj, jerinj, ndabilpuram, adwivedi,
shepard.siegel, ed.czeck, john.miller, irusskikh, ajit.khaparde,
somnath.kotur, rahul.lakkireddy, hemant.agrawal, sachin.saxena,
Wang, Haiyue, Daley, John, hyonkim, Zhang, Qi Z, Wang, Xiao W,
humin29, yisen.zhuang, oulijun, Xing, Beilei, Wu, Jingjing, Yang,
Qiming, matan, viacheslavo, sthemmin, longli, heinrich.kuhn,
kirankumark, mczekaj, jiawenwu, jianwang, maxime.coquelin, Xia,
Chenbo, thomas, Yigit, Ferruh, mdr, Jayatheerthan, Jay
> On 10/7/21 2:27 PM, Konstantin Ananyev wrote:
> > Copy public function pointers (rx_pkt_burst(), etc.) and related
> > pointers to internal data from rte_eth_dev structure into a
> > separate flat array. That array will remain in a public header.
> > The intention here is to make rte_eth_dev and related structures internal.
> > That should allow future possible changes to core eth_dev structures
> > to be transparent to the user and help to avoid ABI/API breakages.
> > The plan is to keep minimal part of data from rte_eth_dev public,
> > so we still can use inline functions for fast-path calls
> > (like rte_eth_rx_burst(), etc.) to avoid/minimize slowdown.
> > The whole idea beyond this new schema:
> > 1. PMDs keep to setup fast-path function pointers and related data
> > inside rte_eth_dev struct in the same way they did it before.
> > 2. Inside rte_eth_dev_start() and inside rte_eth_dev_probing_finish()
> > (for secondary process) we call eth_dev_fp_ops_setup, which
> > copies these function and data pointers into rte_eth_fp_ops[port_id].
> > 3. Inside rte_eth_dev_stop() and inside rte_eth_dev_release_port()
> > we call eth_dev_fp_ops_reset(), which resets rte_eth_fp_ops[port_id]
> > into some dummy values.
> > 4. fast-path ethdev API (rte_eth_rx_burst(), etc.) will use that new
> > flat array to call PMD specific functions.
> > That approach should allow us to make rte_eth_devices[] private
> > without introducing regression and help to avoid changes in drivers code.
> >
> > Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
>
> Overall LGTM, few nits below.
>
> > ---
> > lib/ethdev/ethdev_private.c | 52 ++++++++++++++++++++++++++++++++++
> > lib/ethdev/ethdev_private.h | 7 +++++
> > lib/ethdev/rte_ethdev.c | 27 ++++++++++++++++++
> > lib/ethdev/rte_ethdev_core.h | 55 ++++++++++++++++++++++++++++++++++++
> > 4 files changed, 141 insertions(+)
> >
> > diff --git a/lib/ethdev/ethdev_private.c b/lib/ethdev/ethdev_private.c
> > index 012cf73ca2..3eeda6e9f9 100644
> > --- a/lib/ethdev/ethdev_private.c
> > +++ b/lib/ethdev/ethdev_private.c
> > @@ -174,3 +174,55 @@ rte_eth_devargs_parse_representor_ports(char *str, void *data)
> > RTE_LOG(ERR, EAL, "wrong representor format: %s\n", str);
> > return str == NULL ? -1 : 0;
> > }
> > +
> > +static uint16_t
> > +dummy_eth_rx_burst(__rte_unused void *rxq,
> > + __rte_unused struct rte_mbuf **rx_pkts,
> > + __rte_unused uint16_t nb_pkts)
> > +{
> > + RTE_ETHDEV_LOG(ERR, "rx_pkt_burst for unconfigured port\n");
>
> May be "unconfigured" -> "stopped" ? Or "non-started" ?
Yes, it can be configured but not started.
So 'not started' seems like a better wording here.
Another option probably: 'not ready'.
What people think?
...
>
> > + rte_errno = ENOTSUP;
> > + return 0;
> > +}
> > +
> > +struct rte_eth_fp_ops {
> > +
> > + /**
> > + * Rx fast-path functions and related data.
> > + * 64-bit systems: occupies first 64B line
> > + */
>
> As I understand the above comment is for a group of below
> fields. If so, Doxygen annocation for member groups should
> be used.
Ok, and how to do it?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 2/7] ethdev: allocate max space for internal queue array
@ 2021-10-11 16:25 3% ` Ananyev, Konstantin
2021-10-11 17:15 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2021-10-11 16:25 UTC (permalink / raw)
To: Andrew Rybchenko, dev
Cc: Li, Xiaoyun, anoobj, jerinj, ndabilpuram, adwivedi,
shepard.siegel, ed.czeck, john.miller, irusskikh, ajit.khaparde,
somnath.kotur, rahul.lakkireddy, hemant.agrawal, sachin.saxena,
Wang, Haiyue, Daley, John, hyonkim, Zhang, Qi Z, Wang, Xiao W,
humin29, yisen.zhuang, oulijun, Xing, Beilei, Wu, Jingjing, Yang,
Qiming, matan, viacheslavo, sthemmin, longli, heinrich.kuhn,
kirankumark, mczekaj, jiawenwu, jianwang, maxime.coquelin, Xia,
Chenbo, thomas, Yigit, Ferruh, mdr, Jayatheerthan, Jay
> > At queue configure stage always allocate space for maximum possible
> > number (RTE_MAX_QUEUES_PER_PORT) of queue pointers.
> > That will allow 'fast' inline functions (eth_rx_burst, etc.) to refer
> > pointer to internal queue data without extra checking of current number
> > of configured queues.
> > That would help in future to hide rte_eth_dev and related structures.
> > It means that from now on, each ethdev port will always consume:
> > ((2*sizeof(uintptr_t))* RTE_MAX_QUEUES_PER_PORT)
> > bytes of memory for its queue pointers.
> > With RTE_MAX_QUEUES_PER_PORT==1024 (default value) it is 16KB per port.
> >
> > Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > ---
> > lib/ethdev/rte_ethdev.c | 36 +++++++++---------------------------
> > 1 file changed, 9 insertions(+), 27 deletions(-)
> >
> > diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
> > index ed37f8871b..c8abda6dd7 100644
> > --- a/lib/ethdev/rte_ethdev.c
> > +++ b/lib/ethdev/rte_ethdev.c
> > @@ -897,7 +897,8 @@ eth_dev_rx_queue_config(struct rte_eth_dev *dev, uint16_t nb_queues)
> >
> > if (dev->data->rx_queues == NULL && nb_queues != 0) { /* first time configuration */
> > dev->data->rx_queues = rte_zmalloc("ethdev->rx_queues",
> > - sizeof(dev->data->rx_queues[0]) * nb_queues,
> > + sizeof(dev->data->rx_queues[0]) *
> > + RTE_MAX_QUEUES_PER_PORT,
> > RTE_CACHE_LINE_SIZE);
>
> Looking at it I have few questions:
> 1. Why is nb_queues == 0 case kept as an exception? Yes,
> strictly speaking it is not the problem of the patch,
> DPDK will still segfault (non-debug build) if I
> allocate Tx queues only but call rte_eth_rx_burst().
eth_dev_rx_queue_config(.., nb_queues=0) is used in few places to clean-up things.
> After reading the patch description I thought that
> we're trying to address it.
We do, though I can't see how we can address it in this patch.
Though it is a good idea - I think I can add extra check in eth_dev_fp_ops_setup()
or around and setup RX function pointers only when dev->data->rx_queues != NULL.
Same for TX.
> 2. Why do we need to allocate memory dynamically?
> Can we just make rx_queues an array of appropriate size?
Pavan already asked same question.
My answer to him:
Yep we can, and yes it will simplify this peace of code.
The main reason I decided no to do this change now -
it will change layout of the_eth_dev_data structure.
In this series I tried to mininize(/avoid) changes in rte_eth_dev and rte_eth_dev_data,
as much as possible to avoid any unforeseen performance and functional impacts.
If we'll manage to make rte_eth_dev and rte_eth_dev_data private we can in future
consider that one and other changes in rte_eth_dev and rte_eth_dev_data layouts
without worrying about ABI breakage
> May be wasting 512K unconditionally is too much.
> 3. If wasting 512K is too much, I'd consider to move
> allocation to eth_dev_get(). If
Don't understand where 512KB came from.
each ethdev port will always consume:
((2*sizeof(uintptr_t))* RTE_MAX_QUEUES_PER_PORT)
bytes of memory for its queue pointers.
With RTE_MAX_QUEUES_PER_PORT==1024 (default value) it is 16KB per port.
> > if (dev->data->rx_queues == NULL) {
> > dev->data->nb_rx_queues = 0;
> > @@ -908,21 +909,11 @@ eth_dev_rx_queue_config(struct rte_eth_dev *dev, uint16_t nb_queues)
> >
> > rxq = dev->data->rx_queues;
> >
> > - for (i = nb_queues; i < old_nb_queues; i++)
> > + for (i = nb_queues; i < old_nb_queues; i++) {
> > (*dev->dev_ops->rx_queue_release)(rxq[i]);
> > - rxq = rte_realloc(rxq, sizeof(rxq[0]) * nb_queues,
> > - RTE_CACHE_LINE_SIZE);
> > - if (rxq == NULL)
> > - return -(ENOMEM);
> > - if (nb_queues > old_nb_queues) {
> > - uint16_t new_qs = nb_queues - old_nb_queues;
> > -
> > - memset(rxq + old_nb_queues, 0,
> > - sizeof(rxq[0]) * new_qs);
> > + rxq[i] = NULL;
>
> It looks like the patch should be rebased on top of
> next-net main because of queue release patches.
>
> [snip]
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v1] eventdev/rx-adapter: add telemetry callbacks
@ 2021-10-11 16:14 3% ` Jerin Jacob
2021-10-12 8:35 3% ` Kundapura, Ganapati
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2021-10-11 16:14 UTC (permalink / raw)
To: Ganapati Kundapura; +Cc: dpdk-dev, Jayatheerthan, Jay
On Thu, Oct 7, 2021 at 6:27 PM Ganapati Kundapura
<ganapati.kundapura@intel.com> wrote:
>
> Added telemetry callbacks to get Rx adapter stats, reset stats and
> to get rx queue config information.
rx -> Rx
Change the subject to eventdev/rx_adapter
>
> Signed-off-by: Ganapati Kundapura <ganapati.kundapura@intel.com>
>
> diff --git a/lib/eventdev/rte_event_eth_rx_adapter.c b/lib/eventdev/rte_event_eth_rx_adapter.c
> index 9ac976c..fa7191c 100644
> --- a/lib/eventdev/rte_event_eth_rx_adapter.c
> +++ b/lib/eventdev/rte_event_eth_rx_adapter.c
> @@ -23,6 +23,7 @@
> #include "eventdev_pmd.h"
> #include "rte_eventdev_trace.h"
> #include "rte_event_eth_rx_adapter.h"
> +#include <rte_telemetry.h>
Move this to the above block where all <...h> header files are grouped.
>
> #define BATCH_SIZE 32
> #define BLOCK_CNT_THRESHOLD 10
> @@ -2852,6 +2853,7 @@ rte_event_eth_rx_adapter_stats_get(uint8_t id,
> struct rte_event_eth_rx_adapter_stats *stats)
> {
> struct rte_event_eth_rx_adapter *rx_adapter;
> + struct rte_eth_event_enqueue_buffer *buf;
> struct rte_event_eth_rx_adapter_stats dev_stats_sum = { 0 };
> struct rte_event_eth_rx_adapter_stats dev_stats;
> struct rte_eventdev *dev;
> @@ -2887,8 +2889,11 @@ rte_event_eth_rx_adapter_stats_get(uint8_t id,
> if (rx_adapter->service_inited)
> *stats = rx_adapter->stats;
>
> + buf = &rx_adapter->event_enqueue_buffer;
> stats->rx_packets += dev_stats_sum.rx_packets;
> stats->rx_enq_count += dev_stats_sum.rx_enq_count;
> + stats->rx_event_buf_count = buf->count;
> + stats->rx_event_buf_size = buf->events_size;
>
> return 0;
> }
> @@ -3052,3 +3057,146 @@ rte_event_eth_rx_adapter_queue_conf_get(uint8_t id,
>
> return 0;
> }
> +
> +#define RXA_ADD_DICT(stats, s) rte_tel_data_add_dict_u64(d, #s, stats.s)
> +
> +static int
> +handle_rxa_stats(const char *cmd __rte_unused,
> + const char *params,
> + struct rte_tel_data *d)
> +{
> + uint8_t rx_adapter_id;
> + struct rte_event_eth_rx_adapter_stats rx_adptr_stats;
> +
> + if (params == NULL || strlen(params) == 0 || !isdigit(*params))
> + return -1;
> +
> + /* Get Rx adapter ID from parameter string */
> + rx_adapter_id = atoi(params);
> + RTE_EVENT_ETH_RX_ADAPTER_ID_VALID_OR_ERR_RET(rx_adapter_id, -EINVAL);
> +
> + /* Get Rx adapter stats */
> + if (rte_event_eth_rx_adapter_stats_get(rx_adapter_id,
> + &rx_adptr_stats)) {
> + RTE_EDEV_LOG_ERR("Failed to get Rx adapter stats\n");
> + return -1;
> + }
> +
> + rte_tel_data_start_dict(d);
> + rte_tel_data_add_dict_u64(d, "rx_adapter_id", rx_adapter_id);
> + RXA_ADD_DICT(rx_adptr_stats, rx_packets);
> + RXA_ADD_DICT(rx_adptr_stats, rx_poll_count);
> + RXA_ADD_DICT(rx_adptr_stats, rx_dropped);
> + RXA_ADD_DICT(rx_adptr_stats, rx_enq_retry);
> + RXA_ADD_DICT(rx_adptr_stats, rx_event_buf_count);
> + RXA_ADD_DICT(rx_adptr_stats, rx_event_buf_size);
> + RXA_ADD_DICT(rx_adptr_stats, rx_enq_count);
> + RXA_ADD_DICT(rx_adptr_stats, rx_enq_start_ts);
> + RXA_ADD_DICT(rx_adptr_stats, rx_enq_block_cycles);
> + RXA_ADD_DICT(rx_adptr_stats, rx_enq_end_ts);
> + RXA_ADD_DICT(rx_adptr_stats, rx_intr_packets);
> +
> + return 0;
> +}
> +
> +static int
> +handle_rxa_stats_reset(const char *cmd __rte_unused,
> + const char *params,
> + struct rte_tel_data *d __rte_unused)
> +{
> + uint8_t rx_adapter_id;
> +
> + if (params == NULL || strlen(params) == 0 || ~isdigit(*params))
> + return -1;
> +
> + /* Get Rx adapter ID from parameter string */
> + rx_adapter_id = atoi(params);
> + RTE_EVENT_ETH_RX_ADAPTER_ID_VALID_OR_ERR_RET(rx_adapter_id, -EINVAL);
> +
> + /* Reset Rx adapter stats */
> + if (rte_event_eth_rx_adapter_stats_reset(rx_adapter_id)) {
> + RTE_EDEV_LOG_ERR("Failed to reset Rx adapter stats\n");
> + return -1;
> + }
> +
> + return 0;
> +}
> +
> +static int
> +handle_rxa_get_queue_conf(const char *cmd __rte_unused,
> + const char *params,
> + struct rte_tel_data *d)
> +{
> + uint8_t rx_adapter_id;
> + uint16_t rx_queue_id;
> + int eth_dev_id;
> + char *token, *l_params;
> + struct rte_event_eth_rx_adapter_queue_conf queue_conf;
> +
> + if (params == NULL || strlen(params) == 0 || !isdigit(*params))
> + return -1;
> +
> + /* Get Rx adapter ID from parameter string */
> + l_params = strdup(params);
> + token = strtok(l_params, ",");
> + rx_adapter_id = strtoul(token, NULL, 10);
> + RTE_EVENT_ETH_RX_ADAPTER_ID_VALID_OR_ERR_RET(rx_adapter_id, -EINVAL);
> +
> + token = strtok(NULL, ",");
> + if (token == NULL || strlen(token) == 0 || !isdigit(*token))
> + return -1;
> +
> + /* Get device ID from parameter string */
> + eth_dev_id = strtoul(token, NULL, 10);
> + RTE_EVENTDEV_VALID_DEVID_OR_ERR_RET(eth_dev_id, -EINVAL);
> +
> + token = strtok(NULL, ",");
> + if (token == NULL || strlen(token) == 0 || !isdigit(*token))
> + return -1;
> +
> + /* Get Rx queue ID from parameter string */
> + rx_queue_id = strtoul(token, NULL, 10);
> + if (rx_queue_id >= rte_eth_devices[eth_dev_id].data->nb_rx_queues) {
> + RTE_EDEV_LOG_ERR("Invalid rx queue_id %u", rx_queue_id);
> + return -EINVAL;
> + }
> +
> + token = strtok(NULL, "\0");
> + if (token != NULL)
> + RTE_EDEV_LOG_ERR("Extra parameters passed to eventdev"
> + " telemetry command, igrnoring");
> +
> + if (rte_event_eth_rx_adapter_queue_conf_get(rx_adapter_id, eth_dev_id,
> + rx_queue_id, &queue_conf)) {
> + RTE_EDEV_LOG_ERR("Failed to get Rx adapter queue config");
> + return -1;
> + }
> +
> + rte_tel_data_start_dict(d);
> + rte_tel_data_add_dict_u64(d, "rx_adapter_id", rx_adapter_id);
> + rte_tel_data_add_dict_u64(d, "eth_dev_id", eth_dev_id);
> + rte_tel_data_add_dict_u64(d, "rx_queue_id", rx_queue_id);
> + RXA_ADD_DICT(queue_conf, rx_queue_flags);
> + RXA_ADD_DICT(queue_conf, servicing_weight);
> + RXA_ADD_DICT(queue_conf.ev, queue_id);
> + RXA_ADD_DICT(queue_conf.ev, sched_type);
> + RXA_ADD_DICT(queue_conf.ev, priority);
> + RXA_ADD_DICT(queue_conf.ev, flow_id);
> +
> + return 0;
> +}
> +
> +RTE_INIT(rxa_init_telemetry)
> +{
> + rte_telemetry_register_cmd("/eventdev/rxa_stats",
> + handle_rxa_stats,
> + "Returns Rx adapter stats. Parameter: rx_adapter_id");
> +
> + rte_telemetry_register_cmd("/eventdev/rxa_stats_reset",
> + handle_rxa_stats_reset,
> + "Reset Rx adapter stats. Parameter: rx_adapter_id");
> +
> + rte_telemetry_register_cmd("/eventdev/rxa_queue_conf",
> + handle_rxa_get_queue_conf,
> + "Returns Rx queue config. Parameter: rxa_id, DevID, que_id");
> +}
> diff --git a/lib/eventdev/rte_event_eth_rx_adapter.h b/lib/eventdev/rte_event_eth_rx_adapter.h
> index 70ca427..acabed4 100644
> --- a/lib/eventdev/rte_event_eth_rx_adapter.h
> +++ b/lib/eventdev/rte_event_eth_rx_adapter.h
> @@ -216,6 +216,10 @@ struct rte_event_eth_rx_adapter_stats {
> /**< Eventdev enqueue count */
> uint64_t rx_enq_retry;
> /**< Eventdev enqueue retry count */
> + uint64_t rx_event_buf_count;
> + /**< Rx event buffered count */
> + uint64_t rx_event_buf_size;
Isn't ABI breakage? CI did not warn this. Isn't this a public structure?
> + /**< Rx event buffer size */
> uint64_t rx_dropped;
> /**< Received packet dropped count */
> uint64_t rx_enq_start_ts;
> --
> 2.6.4
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 5/7] ethdev: make fast-path functions to use new flat array
2021-10-11 9:02 0% ` Andrew Rybchenko
@ 2021-10-11 15:47 0% ` Ananyev, Konstantin
2021-10-11 17:03 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2021-10-11 15:47 UTC (permalink / raw)
To: Andrew Rybchenko, dev
Cc: Li, Xiaoyun, anoobj, jerinj, ndabilpuram, adwivedi,
shepard.siegel, ed.czeck, john.miller, irusskikh, ajit.khaparde,
somnath.kotur, rahul.lakkireddy, hemant.agrawal, sachin.saxena,
Wang, Haiyue, Daley, John, hyonkim, Zhang, Qi Z, Wang, Xiao W,
humin29, yisen.zhuang, oulijun, Xing, Beilei, Wu, Jingjing, Yang,
Qiming, matan, viacheslavo, sthemmin, longli, heinrich.kuhn,
kirankumark, mczekaj, jiawenwu, jianwang, maxime.coquelin, Xia,
Chenbo, thomas, Yigit, Ferruh, mdr, Jayatheerthan, Jay
>
> On 10/7/21 2:27 PM, Konstantin Ananyev wrote:
> > Rework fast-path ethdev functions to use rte_eth_fp_ops[].
> > While it is an API/ABI breakage, this change is intended to be
> > transparent for both users (no changes in user app is required) and
> > PMD developers (no changes in PMD is required).
> > One extra thing to note - RX/TX callback invocation will cause extra
> > function call with these changes. That might cause some insignificant
> > slowdown for code-path where RX/TX callbacks are heavily involved.
>
> I'm sorry for nit picking here and below:
>
> RX -> Rx, TX -> Tx everywhere above.
>
> >
> > Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > ---
> > lib/ethdev/ethdev_private.c | 31 +++++
> > lib/ethdev/rte_ethdev.h | 242 ++++++++++++++++++++++++++----------
> > lib/ethdev/version.map | 3 +
> > 3 files changed, 208 insertions(+), 68 deletions(-)
> >
> > diff --git a/lib/ethdev/ethdev_private.c b/lib/ethdev/ethdev_private.c
> > index 3eeda6e9f9..1222c6f84e 100644
> > --- a/lib/ethdev/ethdev_private.c
> > +++ b/lib/ethdev/ethdev_private.c
> > @@ -226,3 +226,34 @@ eth_dev_fp_ops_setup(struct rte_eth_fp_ops *fpo,
> > fpo->txq.data = dev->data->tx_queues;
> > fpo->txq.clbk = (void **)(uintptr_t)dev->pre_tx_burst_cbs;
> > }
> > +
> > +uint16_t
> > +rte_eth_call_rx_callbacks(uint16_t port_id, uint16_t queue_id,
> > + struct rte_mbuf **rx_pkts, uint16_t nb_rx, uint16_t nb_pkts,
> > + void *opaque)
> > +{
> > + const struct rte_eth_rxtx_callback *cb = opaque;
> > +
> > + while (cb != NULL) {
> > + nb_rx = cb->fn.rx(port_id, queue_id, rx_pkts, nb_rx,
> > + nb_pkts, cb->param);
> > + cb = cb->next;
> > + }
> > +
> > + return nb_rx;
> > +}
> > +
> > +uint16_t
> > +rte_eth_call_tx_callbacks(uint16_t port_id, uint16_t queue_id,
> > + struct rte_mbuf **tx_pkts, uint16_t nb_pkts, void *opaque)
> > +{
> > + const struct rte_eth_rxtx_callback *cb = opaque;
> > +
> > + while (cb != NULL) {
> > + nb_pkts = cb->fn.tx(port_id, queue_id, tx_pkts, nb_pkts,
> > + cb->param);
> > + cb = cb->next;
> > + }
> > +
> > + return nb_pkts;
> > +}
> > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> > index cdd16d6e57..c0e1a40681 100644
> > --- a/lib/ethdev/rte_ethdev.h
> > +++ b/lib/ethdev/rte_ethdev.h
> > @@ -4904,6 +4904,33 @@ int rte_eth_representor_info_get(uint16_t port_id,
> >
> > #include <rte_ethdev_core.h>
> >
> > +/**
> > + * @internal
> > + * Helper routine for eth driver rx_burst API.
>
> rx -> Rx
>
> > + * Should be called at exit from PMD's rte_eth_rx_bulk implementation.
> > + * Does necessary post-processing - invokes RX callbacks if any, etc.
>
> RX -> Rx
>
> > + *
> > + * @param port_id
> > + * The port identifier of the Ethernet device.
> > + * @param queue_id
> > + * The index of the receive queue from which to retrieve input packets.
>
> Isn't:
> The index of the queue from which packets are received from?
I copied it from comments from rte_eth_rx_burst().
I suppose it is just two ways to say the same thing.
>
> > + * @param rx_pkts
> > + * The address of an array of pointers to *rte_mbuf* structures that
> > + * have been retrieved from the device.
> > + * @param nb_pkts
>
> Should be @param nb_rx
Ack, will fix.
>
> > + * The number of packets that were retrieved from the device.
> > + * @param nb_pkts
> > + * The number of elements in *rx_pkts* array.
>
> @p should be used to refer to a paramter.
To be more precise you are talking about:
s/*rx_pkts*/@ rx_pkts/
?
>
> The description does not help to understand why both nb_rx and
> nb_pkts are necessary. Isn't nb_pkts >= nb_rx and nb_rx
> sufficient?
Nope, that's for callbacks call.
Will update the comment.
> > + * @param opaque
> > + * Opaque pointer of RX queue callback related data.
>
> RX -> Rx
>
> > + *
> > + * @return
> > + * The number of packets effectively supplied to the *rx_pkts* array.
>
> @p should be used to refer to a parameter.
>
> > + */
> > +uint16_t rte_eth_call_rx_callbacks(uint16_t port_id, uint16_t queue_id,
> > + struct rte_mbuf **rx_pkts, uint16_t nb_rx, uint16_t nb_pkts,
> > + void *opaque);
> > +
> > /**
> > *
> > * Retrieve a burst of input packets from a receive queue of an Ethernet
> > @@ -4995,23 +5022,37 @@ static inline uint16_t
> > rte_eth_rx_burst(uint16_t port_id, uint16_t queue_id,
> > struct rte_mbuf **rx_pkts, const uint16_t nb_pkts)
> > {
> > - struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> > uint16_t nb_rx;
> > + struct rte_eth_fp_ops *p;
>
> p is typically a very bad name in a funcion with
> many pointer variables etc. May be "fpo" as in previous
> patch?
>
> > + void *cb, *qd;
>
> Please, avoid variable, expecially pointers, declaration in
> one line.
Here and in other places, I think local variable names and placement,
is just a matter of personal preference.
>
> I'd suggest to use 'rxq' instead of 'qd'. The first paramter
> of the rx_pkt_burst is 'rxq'.
>
> Also 'cb' seems to be used under RTE_ETHDEV_RXTX_CALLBACKS
> only. If so, it could be unused variable warning if
> RTE_ETHDEV_RXTX_CALLBACKS is not defined.
Good point, will move it back under #ifdef RTE_ETHDEV_RXTX_CALLBACKS.
> > +
> > +#ifdef RTE_ETHDEV_DEBUG_RX
> > + if (port_id >= RTE_MAX_ETHPORTS ||
> > + queue_id >= RTE_MAX_QUEUES_PER_PORT) {
> > + RTE_ETHDEV_LOG(ERR,
> > + "Invalid port_id=%u or queue_id=%u\n",
> > + port_id, queue_id);
> > + return 0;
> > + }
> > +#endif
> > +
> > + /* fetch pointer to queue data */
> > + p = &rte_eth_fp_ops[port_id];
> > + qd = p->rxq.data[queue_id];
> >
> > #ifdef RTE_ETHDEV_DEBUG_RX
> > RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
> > - RTE_FUNC_PTR_OR_ERR_RET(*dev->rx_pkt_burst, 0);
> >
> > - if (queue_id >= dev->data->nb_rx_queues) {
> > - RTE_ETHDEV_LOG(ERR, "Invalid RX queue_id=%u\n", queue_id);
> > + if (qd == NULL) {
> > + RTE_ETHDEV_LOG(ERR, "Invalid RX queue_id=%u for port_id=%u\n",
>
> RX -> Rx
>
> > + queue_id, port_id);
> > return 0;
> > }
> > #endif
> > - nb_rx = (*dev->rx_pkt_burst)(dev->data->rx_queues[queue_id],
> > - rx_pkts, nb_pkts);
> > +
> > + nb_rx = p->rx_pkt_burst(qd, rx_pkts, nb_pkts);
> >
> > #ifdef RTE_ETHDEV_RXTX_CALLBACKS
> > - struct rte_eth_rxtx_callback *cb;
> >
> > /* __ATOMIC_RELEASE memory order was used when the
> > * call back was inserted into the list.
> > @@ -5019,16 +5060,10 @@ rte_eth_rx_burst(uint16_t port_id, uint16_t queue_id,
> > * cb and cb->fn/cb->next, __ATOMIC_ACQUIRE memory order is
> > * not required.
> > */
> > - cb = __atomic_load_n(&dev->post_rx_burst_cbs[queue_id],
> > - __ATOMIC_RELAXED);
> > -
> > - if (unlikely(cb != NULL)) {
> > - do {
> > - nb_rx = cb->fn.rx(port_id, queue_id, rx_pkts, nb_rx,
> > - nb_pkts, cb->param);
> > - cb = cb->next;
> > - } while (cb != NULL);
> > - }
> > + cb = __atomic_load_n((void **)&p->rxq.clbk[queue_id], __ATOMIC_RELAXED);
> > + if (unlikely(cb != NULL))
> > + nb_rx = rte_eth_call_rx_callbacks(port_id, queue_id, rx_pkts,
> > + nb_rx, nb_pkts, cb);
> > #endif
> >
> > rte_ethdev_trace_rx_burst(port_id, queue_id, (void **)rx_pkts, nb_rx);
> > @@ -5051,16 +5086,27 @@ rte_eth_rx_burst(uint16_t port_id, uint16_t queue_id,
> > static inline int
> > rte_eth_rx_queue_count(uint16_t port_id, uint16_t queue_id)
> > {
> > - struct rte_eth_dev *dev;
> > + struct rte_eth_fp_ops *p;
> > + void *qd;
>
> p -> fpo, qd -> rxq
>
> > +
> > + if (port_id >= RTE_MAX_ETHPORTS ||
> > + queue_id >= RTE_MAX_QUEUES_PER_PORT) {
> > + RTE_ETHDEV_LOG(ERR,
> > + "Invalid port_id=%u or queue_id=%u\n",
> > + port_id, queue_id);
> > + return -EINVAL;
> > + }
> > +
> > + /* fetch pointer to queue data */
> > + p = &rte_eth_fp_ops[port_id];
> > + qd = p->rxq.data[queue_id];
> >
> > RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> > - dev = &rte_eth_devices[port_id];
> > - RTE_FUNC_PTR_OR_ERR_RET(*dev->rx_queue_count, -ENOTSUP);
> > - if (queue_id >= dev->data->nb_rx_queues ||
> > - dev->data->rx_queues[queue_id] == NULL)
> > + RTE_FUNC_PTR_OR_ERR_RET(*p->rx_queue_count, -ENOTSUP);
> > + if (qd == NULL)
> > return -EINVAL;
> >
> > - return (int)(*dev->rx_queue_count)(dev->data->rx_queues[queue_id]);
> > + return (int)(*p->rx_queue_count)(qd);
> > }
> >
> > /**@{@name Rx hardware descriptor states
> > @@ -5108,21 +5154,30 @@ static inline int
> > rte_eth_rx_descriptor_status(uint16_t port_id, uint16_t queue_id,
> > uint16_t offset)
> > {
> > - struct rte_eth_dev *dev;
> > - void *rxq;
> > + struct rte_eth_fp_ops *p;
> > + void *qd;
>
> p -> fpo, qd -> rxq
>
> >
> > #ifdef RTE_ETHDEV_DEBUG_RX
> > - RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> > + if (port_id >= RTE_MAX_ETHPORTS ||
> > + queue_id >= RTE_MAX_QUEUES_PER_PORT) {
> > + RTE_ETHDEV_LOG(ERR,
> > + "Invalid port_id=%u or queue_id=%u\n",
> > + port_id, queue_id);
> > + return -EINVAL;
> > + }
> > #endif
> > - dev = &rte_eth_devices[port_id];
> > +
> > + /* fetch pointer to queue data */
> > + p = &rte_eth_fp_ops[port_id];
> > + qd = p->rxq.data[queue_id];
> > +
> > #ifdef RTE_ETHDEV_DEBUG_RX
> > - if (queue_id >= dev->data->nb_rx_queues)
> > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> > + if (qd == NULL)
> > return -ENODEV;
> > #endif
> > - RTE_FUNC_PTR_OR_ERR_RET(*dev->rx_descriptor_status, -ENOTSUP);
> > - rxq = dev->data->rx_queues[queue_id];
> > -
> > - return (*dev->rx_descriptor_status)(rxq, offset);
> > + RTE_FUNC_PTR_OR_ERR_RET(*p->rx_descriptor_status, -ENOTSUP);
> > + return (*p->rx_descriptor_status)(qd, offset);
> > }
> >
> > /**@{@name Tx hardware descriptor states
> > @@ -5169,23 +5224,54 @@ rte_eth_rx_descriptor_status(uint16_t port_id, uint16_t queue_id,
> > static inline int rte_eth_tx_descriptor_status(uint16_t port_id,
> > uint16_t queue_id, uint16_t offset)
> > {
> > - struct rte_eth_dev *dev;
> > - void *txq;
> > + struct rte_eth_fp_ops *p;
> > + void *qd;
>
> p -> fpo, qd -> txq
>
> >
> > #ifdef RTE_ETHDEV_DEBUG_TX
> > - RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> > + if (port_id >= RTE_MAX_ETHPORTS ||
> > + queue_id >= RTE_MAX_QUEUES_PER_PORT) {
> > + RTE_ETHDEV_LOG(ERR,
> > + "Invalid port_id=%u or queue_id=%u\n",
> > + port_id, queue_id);
> > + return -EINVAL;
> > + }
> > #endif
> > - dev = &rte_eth_devices[port_id];
> > +
> > + /* fetch pointer to queue data */
> > + p = &rte_eth_fp_ops[port_id];
> > + qd = p->txq.data[queue_id];
> > +
> > #ifdef RTE_ETHDEV_DEBUG_TX
> > - if (queue_id >= dev->data->nb_tx_queues)
> > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> > + if (qd == NULL)
> > return -ENODEV;
> > #endif
> > - RTE_FUNC_PTR_OR_ERR_RET(*dev->tx_descriptor_status, -ENOTSUP);
> > - txq = dev->data->tx_queues[queue_id];
> > -
> > - return (*dev->tx_descriptor_status)(txq, offset);
> > + RTE_FUNC_PTR_OR_ERR_RET(*p->tx_descriptor_status, -ENOTSUP);
> > + return (*p->tx_descriptor_status)(qd, offset);
> > }
> >
> > +/**
> > + * @internal
> > + * Helper routine for eth driver tx_burst API.
> > + * Should be called before entry PMD's rte_eth_tx_bulk implementation.
> > + * Does necessary pre-processing - invokes TX callbacks if any, etc.
>
> TX -> Tx
>
> > + *
> > + * @param port_id
> > + * The port identifier of the Ethernet device.
> > + * @param queue_id
> > + * The index of the transmit queue through which output packets must be
> > + * sent.
> > + * @param tx_pkts
> > + * The address of an array of *nb_pkts* pointers to *rte_mbuf* structures
> > + * which contain the output packets.
>
> *nb_pkts* -> @p nb_pkts
>
> > + * @param nb_pkts
> > + * The maximum number of packets to transmit.
> > + * @return
> > + * The number of output packets to transmit.
> > + */
> > +uint16_t rte_eth_call_tx_callbacks(uint16_t port_id, uint16_t queue_id,
> > + struct rte_mbuf **tx_pkts, uint16_t nb_pkts, void *opaque);
> > +
> > /**
> > * Send a burst of output packets on a transmit queue of an Ethernet device.
> > *
> > @@ -5256,20 +5342,34 @@ static inline uint16_t
> > rte_eth_tx_burst(uint16_t port_id, uint16_t queue_id,
> > struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
> > {
> > - struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> > + struct rte_eth_fp_ops *p;
> > + void *cb, *qd;
>
> Same as above
>
> > +
> > +#ifdef RTE_ETHDEV_DEBUG_TX
> > + if (port_id >= RTE_MAX_ETHPORTS ||
> > + queue_id >= RTE_MAX_QUEUES_PER_PORT) {
> > + RTE_ETHDEV_LOG(ERR,
> > + "Invalid port_id=%u or queue_id=%u\n",
> > + port_id, queue_id);
> > + return 0;
> > + }
> > +#endif
> > +
> > + /* fetch pointer to queue data */
> > + p = &rte_eth_fp_ops[port_id];
> > + qd = p->txq.data[queue_id];
> >
> > #ifdef RTE_ETHDEV_DEBUG_TX
> > RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
> > - RTE_FUNC_PTR_OR_ERR_RET(*dev->tx_pkt_burst, 0);
> >
> > - if (queue_id >= dev->data->nb_tx_queues) {
> > - RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u\n", queue_id);
> > + if (qd == NULL) {
> > + RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u for port_id=%u\n",
>
> TX -> Tx
>
> > + queue_id, port_id);
> > return 0;
> > }
> > #endif
> >
> > #ifdef RTE_ETHDEV_RXTX_CALLBACKS
> > - struct rte_eth_rxtx_callback *cb;
> >
> > /* __ATOMIC_RELEASE memory order was used when the
> > * call back was inserted into the list.
> > @@ -5277,21 +5377,16 @@ rte_eth_tx_burst(uint16_t port_id, uint16_t queue_id,
> > * cb and cb->fn/cb->next, __ATOMIC_ACQUIRE memory order is
> > * not required.
> > */
> > - cb = __atomic_load_n(&dev->pre_tx_burst_cbs[queue_id],
> > - __ATOMIC_RELAXED);
> > -
> > - if (unlikely(cb != NULL)) {
> > - do {
> > - nb_pkts = cb->fn.tx(port_id, queue_id, tx_pkts, nb_pkts,
> > - cb->param);
> > - cb = cb->next;
> > - } while (cb != NULL);
> > - }
> > + cb = __atomic_load_n((void **)&p->txq.clbk[queue_id], __ATOMIC_RELAXED);
> > + if (unlikely(cb != NULL))
> > + nb_pkts = rte_eth_call_tx_callbacks(port_id, queue_id, tx_pkts,
> > + nb_pkts, cb);
> > #endif
> >
> > - rte_ethdev_trace_tx_burst(port_id, queue_id, (void **)tx_pkts,
> > - nb_pkts);
> > - return (*dev->tx_pkt_burst)(dev->data->tx_queues[queue_id], tx_pkts, nb_pkts);
> > + nb_pkts = p->tx_pkt_burst(qd, tx_pkts, nb_pkts);
> > +
> > + rte_ethdev_trace_tx_burst(port_id, queue_id, (void **)tx_pkts, nb_pkts);
> > + return nb_pkts;
> > }
> >
> > /**
> > @@ -5354,31 +5449,42 @@ static inline uint16_t
> > rte_eth_tx_prepare(uint16_t port_id, uint16_t queue_id,
> > struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
> > {
> > - struct rte_eth_dev *dev;
> > + struct rte_eth_fp_ops *p;
> > + void *qd;
>
> p->fpo, qd->txq
>
> >
> > #ifdef RTE_ETHDEV_DEBUG_TX
> > - if (!rte_eth_dev_is_valid_port(port_id)) {
> > - RTE_ETHDEV_LOG(ERR, "Invalid TX port_id=%u\n", port_id);
> > + if (port_id >= RTE_MAX_ETHPORTS ||
> > + queue_id >= RTE_MAX_QUEUES_PER_PORT) {
> > + RTE_ETHDEV_LOG(ERR,
> > + "Invalid port_id=%u or queue_id=%u\n",
> > + port_id, queue_id);
> > rte_errno = ENODEV;
> > return 0;
> > }
> > #endif
> >
> > - dev = &rte_eth_devices[port_id];
> > + /* fetch pointer to queue data */
> > + p = &rte_eth_fp_ops[port_id];
> > + qd = p->txq.data[queue_id];
> >
> > #ifdef RTE_ETHDEV_DEBUG_TX
> > - if (queue_id >= dev->data->nb_tx_queues) {
> > - RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u\n", queue_id);
> > + if (!rte_eth_dev_is_valid_port(port_id)) {
> > + RTE_ETHDEV_LOG(ERR, "Invalid TX port_id=%u\n", port_id);
>
> TX -> Tx
>
> > + rte_errno = ENODEV;
> > + return 0;
> > + }
> > + if (qd == NULL) {
> > + RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u for port_id=%u\n",
>
> TX -> Tx
>
> > + queue_id, port_id);
> > rte_errno = EINVAL;
> > return 0;
> > }
> > #endif
> >
> > - if (!dev->tx_pkt_prepare)
> > + if (!p->tx_pkt_prepare)
>
> Please, change it to compare vs NULL since you touch the line.
> Just to be consistent with DPDK coding style and lines above.
Ok, I am also fond of explicit comparisons :)
> > return nb_pkts;
> >
> > - return (*dev->tx_pkt_prepare)(dev->data->tx_queues[queue_id],
> > - tx_pkts, nb_pkts);
> > + return p->tx_pkt_prepare(qd, tx_pkts, nb_pkts);
> > }
> >
> > #else
> > diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map
> > index 904bce6ea1..79e62dcf61 100644
> > --- a/lib/ethdev/version.map
> > +++ b/lib/ethdev/version.map
> > @@ -7,6 +7,8 @@ DPDK_22 {
> > rte_eth_allmulticast_disable;
> > rte_eth_allmulticast_enable;
> > rte_eth_allmulticast_get;
> > + rte_eth_call_rx_callbacks;
> > + rte_eth_call_tx_callbacks;
> > rte_eth_dev_adjust_nb_rx_tx_desc;
> > rte_eth_dev_callback_register;
> > rte_eth_dev_callback_unregister;
> > @@ -76,6 +78,7 @@ DPDK_22 {
> > rte_eth_find_next_of;
> > rte_eth_find_next_owned_by;
> > rte_eth_find_next_sibling;
> > + rte_eth_fp_ops;
> > rte_eth_iterator_cleanup;
> > rte_eth_iterator_init;
> > rte_eth_iterator_next;
> >
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 4/7] ethdev: copy fast-path API into separate structure
2021-10-09 12:05 0% ` fengchengwen
2021-10-11 1:18 0% ` fengchengwen
2021-10-11 8:35 0% ` Andrew Rybchenko
@ 2021-10-11 15:15 0% ` Ananyev, Konstantin
2 siblings, 0 replies; 200+ results
From: Ananyev, Konstantin @ 2021-10-11 15:15 UTC (permalink / raw)
To: fengchengwen, dev
Cc: Li, Xiaoyun, anoobj, jerinj, ndabilpuram, adwivedi,
shepard.siegel, ed.czeck, john.miller, irusskikh, ajit.khaparde,
somnath.kotur, rahul.lakkireddy, hemant.agrawal, sachin.saxena,
Wang, Haiyue, Daley, John, hyonkim, Zhang, Qi Z, Wang, Xiao W,
humin29, yisen.zhuang, oulijun, Xing, Beilei, Wu, Jingjing, Yang,
Qiming, matan, viacheslavo, sthemmin, longli, heinrich.kuhn,
kirankumark, andrew.rybchenko, mczekaj, jiawenwu, jianwang,
maxime.coquelin, Xia, Chenbo, thomas, Yigit, Ferruh, mdr,
Jayatheerthan, Jay
> > Copy public function pointers (rx_pkt_burst(), etc.) and related
> > pointers to internal data from rte_eth_dev structure into a
> > separate flat array. That array will remain in a public header.
> > The intention here is to make rte_eth_dev and related structures internal.
> > That should allow future possible changes to core eth_dev structures
> > to be transparent to the user and help to avoid ABI/API breakages.
> > The plan is to keep minimal part of data from rte_eth_dev public,
> > so we still can use inline functions for fast-path calls
> > (like rte_eth_rx_burst(), etc.) to avoid/minimize slowdown.
> > The whole idea beyond this new schema:
> > 1. PMDs keep to setup fast-path function pointers and related data
> > inside rte_eth_dev struct in the same way they did it before.
> > 2. Inside rte_eth_dev_start() and inside rte_eth_dev_probing_finish()
> > (for secondary process) we call eth_dev_fp_ops_setup, which
> > copies these function and data pointers into rte_eth_fp_ops[port_id].
> > 3. Inside rte_eth_dev_stop() and inside rte_eth_dev_release_port()
> > we call eth_dev_fp_ops_reset(), which resets rte_eth_fp_ops[port_id]
> > into some dummy values.
> > 4. fast-path ethdev API (rte_eth_rx_burst(), etc.) will use that new
> > flat array to call PMD specific functions.
> > That approach should allow us to make rte_eth_devices[] private
> > without introducing regression and help to avoid changes in drivers code.
> >
> > Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > ---
> > lib/ethdev/ethdev_private.c | 52 ++++++++++++++++++++++++++++++++++
> > lib/ethdev/ethdev_private.h | 7 +++++
> > lib/ethdev/rte_ethdev.c | 27 ++++++++++++++++++
> > lib/ethdev/rte_ethdev_core.h | 55 ++++++++++++++++++++++++++++++++++++
> > 4 files changed, 141 insertions(+)
> >
> > diff --git a/lib/ethdev/ethdev_private.c b/lib/ethdev/ethdev_private.c
> > index 012cf73ca2..3eeda6e9f9 100644
> > --- a/lib/ethdev/ethdev_private.c
> > +++ b/lib/ethdev/ethdev_private.c
> > @@ -174,3 +174,55 @@ rte_eth_devargs_parse_representor_ports(char *str, void *data)
> > RTE_LOG(ERR, EAL, "wrong representor format: %s\n", str);
> > return str == NULL ? -1 : 0;
> > }
> > +
> > +static uint16_t
> > +dummy_eth_rx_burst(__rte_unused void *rxq,
> > + __rte_unused struct rte_mbuf **rx_pkts,
> > + __rte_unused uint16_t nb_pkts)
> > +{
> > + RTE_ETHDEV_LOG(ERR, "rx_pkt_burst for unconfigured port\n");
> > + rte_errno = ENOTSUP;
> > + return 0;
> > +}
> > +
> > +static uint16_t
> > +dummy_eth_tx_burst(__rte_unused void *txq,
> > + __rte_unused struct rte_mbuf **tx_pkts,
> > + __rte_unused uint16_t nb_pkts)
> > +{
> > + RTE_ETHDEV_LOG(ERR, "tx_pkt_burst for unconfigured port\n");
> > + rte_errno = ENOTSUP;
> > + return 0;
> > +}
> > +
> > +void
> > +eth_dev_fp_ops_reset(struct rte_eth_fp_ops *fpo)
>
> The port_id parameter is preferable, this will hide rte_eth_fp_ops as much as possible.
Why do we need to hide it here?
rte_eth_fp_ops is a public structure, and it is a helper function that
just resets fields of this structure to some predefined dummy values.
Nice and simple, so I prefer to keep it like that.
>
> > +{
> > + static void *dummy_data[RTE_MAX_QUEUES_PER_PORT];
> > + static const struct rte_eth_fp_ops dummy_ops = {
> > + .rx_pkt_burst = dummy_eth_rx_burst,
> > + .tx_pkt_burst = dummy_eth_tx_burst,
> > + .rxq = {.data = dummy_data, .clbk = dummy_data,},
> > + .txq = {.data = dummy_data, .clbk = dummy_data,},
> > + };
> > +
> > + *fpo = dummy_ops;
> > +}
> > +
> > +void
> > +eth_dev_fp_ops_setup(struct rte_eth_fp_ops *fpo,
> > + const struct rte_eth_dev *dev)
>
> Because fp_ops and eth_dev is a one-to-one correspondence. It's better only use
> port_id parameter.
Same as above:
All this internal helper function does - copies some fields from one structure to another.
Both structures are visible by ethdev layer.
No point to add extra assumptions and complexity here.
>
> > +{
> > + fpo->rx_pkt_burst = dev->rx_pkt_burst;
> > + fpo->tx_pkt_burst = dev->tx_pkt_burst;
> > + fpo->tx_pkt_prepare = dev->tx_pkt_prepare;
> > + fpo->rx_queue_count = dev->rx_queue_count;
> > + fpo->rx_descriptor_status = dev->rx_descriptor_status;
> > + fpo->tx_descriptor_status = dev->tx_descriptor_status;
> > +
> > + fpo->rxq.data = dev->data->rx_queues;
> > + fpo->rxq.clbk = (void **)(uintptr_t)dev->post_rx_burst_cbs;
> > +
> > + fpo->txq.data = dev->data->tx_queues;
> > + fpo->txq.clbk = (void **)(uintptr_t)dev->pre_tx_burst_cbs;
> > +}
> > diff --git a/lib/ethdev/ethdev_private.h b/lib/ethdev/ethdev_private.h
> > index 3724429577..5721be7bdc 100644
> > --- a/lib/ethdev/ethdev_private.h
> > +++ b/lib/ethdev/ethdev_private.h
> > @@ -26,4 +26,11 @@ eth_find_device(const struct rte_eth_dev *_start, rte_eth_cmp_t cmp,
> > /* Parse devargs value for representor parameter. */
> > int rte_eth_devargs_parse_representor_ports(char *str, void *data);
> >
> > +/* reset eth fast-path API to dummy values */
> > +void eth_dev_fp_ops_reset(struct rte_eth_fp_ops *fpo);
> > +
> > +/* setup eth fast-path API to ethdev values */
> > +void eth_dev_fp_ops_setup(struct rte_eth_fp_ops *fpo,
> > + const struct rte_eth_dev *dev);
>
> Some drivers control the transmit/receive function during operation. E.g.
> for hns3 driver, when detect reset, primary process will set rx/tx burst to dummy, after
> process reset, primary process will set the correct rx/tx burst. During this process, the
> send and receive threads are still working, but the bursts they call are changed. So:
This text above is a bit too cryptic for me...
Are you saying that your driver changes rte_eth_dev.rx_pkt_burst(/ tx_pkt_burst) on the fly
(after dev_start() and before dev_stop())?
If so, then generally speaking, it is a bad idea.
While it might works for some limited scenarios, right now it is not supported by ethdev framework,
and might introduce a lot of problems.
> 1. it is recommended that trace be deleted from the dummy function.
You are talking about:
RTE_ETHDEV_LOG(ERR, "rx_pkt_burst for unconfigured port\n");
right?
Dummy function is supposed to be set only when device is not able to do RX/TX properly
(not attached, or attached but not configured, or attached and configured, but not started).
Obviously if app calls rx/tx_burst for such port it is a major issue, that should be flagged imemdiatelly.
So I believe having log here makes a perfect sense here.
> 2. public the eth_dev_fp_ops_reset/setup interface for driver usage.
You mean move their declarations into ethdev_driver.h?
I suppose that could be done, but still wonder why driver would need to
call these functions directly?
> > +
> > #endif /* _ETH_PRIVATE_H_ */
> > diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
> > index c8abda6dd7..9f7a0cbb8c 100644
> > --- a/lib/ethdev/rte_ethdev.c
> > +++ b/lib/ethdev/rte_ethdev.c
> > @@ -44,6 +44,9 @@
> > static const char *MZ_RTE_ETH_DEV_DATA = "rte_eth_dev_data";
> > struct rte_eth_dev rte_eth_devices[RTE_MAX_ETHPORTS];
> >
> > +/* public fast-path API */
> > +struct rte_eth_fp_ops rte_eth_fp_ops[RTE_MAX_ETHPORTS];
> > +
> > /* spinlock for eth device callbacks */
> > static rte_spinlock_t eth_dev_cb_lock = RTE_SPINLOCK_INITIALIZER;
> >
> > @@ -578,6 +581,8 @@ rte_eth_dev_release_port(struct rte_eth_dev *eth_dev)
> > rte_eth_dev_callback_process(eth_dev,
> > RTE_ETH_EVENT_DESTROY, NULL);
> >
> > + eth_dev_fp_ops_reset(rte_eth_fp_ops + eth_dev->data->port_id);
> > +
> > rte_spinlock_lock(ð_dev_shared_data->ownership_lock);
> >
> > eth_dev->state = RTE_ETH_DEV_UNUSED;
> > @@ -1787,6 +1792,9 @@ rte_eth_dev_start(uint16_t port_id)
> > (*dev->dev_ops->link_update)(dev, 0);
> > }
> >
> > + /* expose selection of PMD fast-path functions */
> > + eth_dev_fp_ops_setup(rte_eth_fp_ops + port_id, dev);
> > +
> > rte_ethdev_trace_start(port_id);
> > return 0;
> > }
> > @@ -1809,6 +1817,9 @@ rte_eth_dev_stop(uint16_t port_id)
> > return 0;
> > }
> >
> > + /* point fast-path functions to dummy ones */
> > + eth_dev_fp_ops_reset(rte_eth_fp_ops + port_id);
> > +
> > dev->data->dev_started = 0;
> > ret = (*dev->dev_ops->dev_stop)(dev);
> > rte_ethdev_trace_stop(port_id, ret);
> > @@ -4567,6 +4578,14 @@ rte_eth_mirror_rule_reset(uint16_t port_id, uint8_t rule_id)
> > return eth_err(port_id, (*dev->dev_ops->mirror_rule_reset)(dev, rule_id));
> > }
> >
> > +RTE_INIT(eth_dev_init_fp_ops)
> > +{
> > + uint32_t i;
> > +
> > + for (i = 0; i != RTE_DIM(rte_eth_fp_ops); i++)
> > + eth_dev_fp_ops_reset(rte_eth_fp_ops + i);
> > +}
> > +
> > RTE_INIT(eth_dev_init_cb_lists)
> > {
> > uint16_t i;
> > @@ -4735,6 +4754,14 @@ rte_eth_dev_probing_finish(struct rte_eth_dev *dev)
> > if (dev == NULL)
> > return;
> >
> > + /*
> > + * for secondary process, at that point we expect device
> > + * to be already 'usable', so shared data and all function pointers
> > + * for fast-path devops have to be setup properly inside rte_eth_dev.
> > + */
> > + if (rte_eal_process_type() == RTE_PROC_SECONDARY)
> > + eth_dev_fp_ops_setup(rte_eth_fp_ops + dev->data->port_id, dev);
> > +
> > rte_eth_dev_callback_process(dev, RTE_ETH_EVENT_NEW, NULL);
> >
> > dev->state = RTE_ETH_DEV_ATTACHED;
> > diff --git a/lib/ethdev/rte_ethdev_core.h b/lib/ethdev/rte_ethdev_core.h
> > index 51cd68de94..d5853dff86 100644
> > --- a/lib/ethdev/rte_ethdev_core.h
> > +++ b/lib/ethdev/rte_ethdev_core.h
> > @@ -50,6 +50,61 @@ typedef int (*eth_rx_descriptor_status_t)(void *rxq, uint16_t offset);
> > typedef int (*eth_tx_descriptor_status_t)(void *txq, uint16_t offset);
> > /**< @internal Check the status of a Tx descriptor */
> >
> > +/**
> > + * @internal
> > + * Structure used to hold opaque pointers to internal ethdev Rx/Tx
> > + * queues data.
> > + * The main purpose to expose these pointers at all - allow compiler
> > + * to fetch this data for fast-path ethdev inline functions in advance.
> > + */
> > +struct rte_ethdev_qdata {
> > + void **data;
> > + /**< points to array of internal queue data pointers */
> > + void **clbk;
> > + /**< points to array of queue callback data pointers */
> > +};
> > +
> > +/**
> > + * @internal
> > + * fast-path ethdev functions and related data are hold in a flat array.
> > + * One entry per ethdev.
> > + * On 64-bit systems contents of this structure occupy exactly two 64B lines.
> > + * On 32-bit systems contents of this structure fits into one 64B line.
> > + */
> > +struct rte_eth_fp_ops {
> > +
> > + /**
> > + * Rx fast-path functions and related data.
> > + * 64-bit systems: occupies first 64B line
> > + */
> > + eth_rx_burst_t rx_pkt_burst;
> > + /**< PMD receive function. */
> > + eth_rx_queue_count_t rx_queue_count;
> > + /**< Get the number of used RX descriptors. */
> > + eth_rx_descriptor_status_t rx_descriptor_status;
> > + /**< Check the status of a Rx descriptor. */
> > + struct rte_ethdev_qdata rxq;
> > + /**< Rx queues data. */
> > + uintptr_t reserved1[3];
> > +
> > + /**
> > + * Tx fast-path functions and related data.
> > + * 64-bit systems: occupies second 64B line
> > + */
> > + eth_tx_burst_t tx_pkt_burst;
>
> Why not place rx_pkt_burst/tx_pkt_burst/rxq /txq to the first cacheline ?
> Other function, e.g. rx_queue_count/descriptor_status are low frequency call functions.
I suppose you are talking about layout like that:
struct rte_eth_fp_ops {
/* first 64B line */
rx_pkt_burst;
tx_pkt_burst;
tx_pkt_prepare;
struct rte_ethdev_qdata rxq;
struct rte_ethdev_qdata txq;
reserved1[1];
/* second 64B line */
...
};
I thought about such ability, even tried it, but I didn't see any performance gain.
From other side current layout seems better to me from structural point:
it is more uniform and easy to extend in future (both RX and TX data occupies
separate 64B line, each have equal rom for extension).
> > + /**< PMD transmit function. */
> > + eth_tx_prep_t tx_pkt_prepare;
> > + /**< PMD transmit prepare function. */
> > + eth_tx_descriptor_status_t tx_descriptor_status;
> > + /**< Check the status of a Tx descriptor. */
> > + struct rte_ethdev_qdata txq;
> > + /**< Tx queues data. */
> > + uintptr_t reserved2[3];
> > +
> > +} __rte_cache_aligned;
> > +
> > +extern struct rte_eth_fp_ops rte_eth_fp_ops[RTE_MAX_ETHPORTS];
> > +
> >
> > /**
> > * @internal
> >
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 4/5] cryptodev: update fast path APIs to use new flat array
2021-10-11 12:43 3% ` [dpdk-dev] [PATCH v2 4/5] cryptodev: update fast path APIs to use new flat array Akhil Goyal
@ 2021-10-11 14:54 0% ` Zhang, Roy Fan
0 siblings, 0 replies; 200+ results
From: Zhang, Roy Fan @ 2021-10-11 14:54 UTC (permalink / raw)
To: Akhil Goyal, dev
Cc: thomas, david.marchand, hemant.agrawal, anoobj, De Lara Guarch,
Pablo, Trahe, Fiona, Doherty, Declan, matan, g.singh,
jianjay.zhou, asomalap, ruifeng.wang, Ananyev, Konstantin,
Nicolau, Radu, ajit.khaparde, rnagadheeraj, adwivedi, Power,
Ciara
Hi Akhil,
> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Monday, October 11, 2021 1:43 PM
> To: dev@dpdk.org
> Cc: thomas@monjalon.net; david.marchand@redhat.com;
> hemant.agrawal@nxp.com; anoobj@marvell.com; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; Trahe, Fiona <fiona.trahe@intel.com>;
> Doherty, Declan <declan.doherty@intel.com>; matan@nvidia.com;
> g.singh@nxp.com; Zhang, Roy Fan <roy.fan.zhang@intel.com>;
> jianjay.zhou@huawei.com; asomalap@amd.com; ruifeng.wang@arm.com;
> Ananyev, Konstantin <konstantin.ananyev@intel.com>; Nicolau, Radu
> <radu.nicolau@intel.com>; ajit.khaparde@broadcom.com;
> rnagadheeraj@marvell.com; adwivedi@marvell.com; Power, Ciara
> <ciara.power@intel.com>; Akhil Goyal <gakhil@marvell.com>
> Subject: [PATCH v2 4/5] cryptodev: update fast path APIs to use new flat
> array
>
> Rework fast-path cryptodev functions to use rte_crypto_fp_ops[].
> While it is an API/ABI breakage, this change is intended to be
> transparent for both users (no changes in user app is required) and
> PMD developers (no changes in PMD is required).
>
> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> ---
> lib/cryptodev/rte_cryptodev.h | 27 +++++++++++++++++----------
> 1 file changed, 17 insertions(+), 10 deletions(-)
>
> diff --git a/lib/cryptodev/rte_cryptodev.h b/lib/cryptodev/rte_cryptodev.h
> index ce0dca72be..739ad529e5 100644
> --- a/lib/cryptodev/rte_cryptodev.h
> +++ b/lib/cryptodev/rte_cryptodev.h
> @@ -1832,13 +1832,18 @@ static inline uint16_t
> rte_cryptodev_dequeue_burst(uint8_t dev_id, uint16_t qp_id,
> struct rte_crypto_op **ops, uint16_t nb_ops)
> {
> - struct rte_cryptodev *dev = &rte_cryptodevs[dev_id];
> + struct rte_crypto_fp_ops *fp_ops;
We may need to use const for fp_ops since we only call the function pointers in it.
> + void *qp;
>
> rte_cryptodev_trace_dequeue_burst(dev_id, qp_id, (void **)ops,
> nb_ops);
> - nb_ops = (*dev->dequeue_burst)
> - (dev->data->queue_pairs[qp_id], ops, nb_ops);
> +
> + fp_ops = &rte_crypto_fp_ops[dev_id];
> + qp = fp_ops->qp.data[qp_id];
> +
> + nb_ops = fp_ops->dequeue_burst(qp, ops, nb_ops);
> +
> #ifdef RTE_CRYPTO_CALLBACKS
> - if (unlikely(dev->deq_cbs != NULL)) {
> + if (unlikely(fp_ops->qp.deq_cb != NULL)) {
> struct rte_cryptodev_cb_rcu *list;
> struct rte_cryptodev_cb *cb;
>
> @@ -1848,7 +1853,7 @@ rte_cryptodev_dequeue_burst(uint8_t dev_id,
> uint16_t qp_id,
> * cb and cb->fn/cb->next, __ATOMIC_ACQUIRE memory
> order is
> * not required.
> */
> - list = &dev->deq_cbs[qp_id];
> + list = (struct rte_cryptodev_cb_rcu *)&fp_ops-
> >qp.deq_cb[qp_id];
> rte_rcu_qsbr_thread_online(list->qsbr, 0);
> cb = __atomic_load_n(&list->next, __ATOMIC_RELAXED);
>
> @@ -1899,10 +1904,13 @@ static inline uint16_t
> rte_cryptodev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
> struct rte_crypto_op **ops, uint16_t nb_ops)
> {
> - struct rte_cryptodev *dev = &rte_cryptodevs[dev_id];
> + struct rte_crypto_fp_ops *fp_ops;
Same as above
> + void *qp;
>
> + fp_ops = &rte_crypto_fp_ops[dev_id];
> + qp = fp_ops->qp.data[qp_id];
> #ifdef RTE_CRYPTO_CALLBACKS
> - if (unlikely(dev->enq_cbs != NULL)) {
> + if (unlikely(fp_ops->qp.enq_cb != NULL)) {
> struct rte_cryptodev_cb_rcu *list;
> struct rte_cryptodev_cb *cb;
>
> @@ -1912,7 +1920,7 @@ rte_cryptodev_enqueue_burst(uint8_t dev_id,
> uint16_t qp_id,
> * cb and cb->fn/cb->next, __ATOMIC_ACQUIRE memory
> order is
> * not required.
> */
> - list = &dev->enq_cbs[qp_id];
> + list = (struct rte_cryptodev_cb_rcu *)&fp_ops-
> >qp.enq_cb[qp_id];
> rte_rcu_qsbr_thread_online(list->qsbr, 0);
> cb = __atomic_load_n(&list->next, __ATOMIC_RELAXED);
>
> @@ -1927,8 +1935,7 @@ rte_cryptodev_enqueue_burst(uint8_t dev_id,
> uint16_t qp_id,
> #endif
>
> rte_cryptodev_trace_enqueue_burst(dev_id, qp_id, (void **)ops,
> nb_ops);
> - return (*dev->enqueue_burst)(
> - dev->data->queue_pairs[qp_id], ops, nb_ops);
> + return fp_ops->enqueue_burst(qp, ops, nb_ops);
> }
>
>
> --
> 2.25.1
Other than the minor comments above
Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v2 01/38] common/sfc_efx/base: update MCDI headers
@ 2021-10-11 14:48 2% ` Andrew Rybchenko
0 siblings, 0 replies; 200+ results
From: Andrew Rybchenko @ 2021-10-11 14:48 UTC (permalink / raw)
To: dev
Pickup new FW interface definitions.
Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
drivers/common/sfc_efx/base/efx_regs_mcdi.h | 1211 ++++++++++++++++++-
1 file changed, 1176 insertions(+), 35 deletions(-)
diff --git a/drivers/common/sfc_efx/base/efx_regs_mcdi.h b/drivers/common/sfc_efx/base/efx_regs_mcdi.h
index a3c9f076ec..2daf825a36 100644
--- a/drivers/common/sfc_efx/base/efx_regs_mcdi.h
+++ b/drivers/common/sfc_efx/base/efx_regs_mcdi.h
@@ -492,6 +492,24 @@
*/
#define MAE_FIELD_SUPPORTED_MATCH_MASK 0x5
+/* MAE_CT_VNI_MODE enum: Controls the layout of the VNI input to the conntrack
+ * lookup. (Values are not arbitrary - constrained by table access ABI.)
+ */
+/* enum: The VNI input to the conntrack lookup will be zero. */
+#define MAE_CT_VNI_MODE_ZERO 0x0
+/* enum: The VNI input to the conntrack lookup will be the VNI (VXLAN/Geneve)
+ * or VSID (NVGRE) field from the packet.
+ */
+#define MAE_CT_VNI_MODE_VNI 0x1
+/* enum: The VNI input to the conntrack lookup will be the VLAN ID from the
+ * outermost VLAN tag (in bottom 12 bits; top 12 bits zero).
+ */
+#define MAE_CT_VNI_MODE_1VLAN 0x2
+/* enum: The VNI input to the conntrack lookup will be the VLAN IDs from both
+ * VLAN tags (outermost in bottom 12 bits, innermost in top 12 bits).
+ */
+#define MAE_CT_VNI_MODE_2VLAN 0x3
+
/* MAE_FIELD enum: NB: this enum shares namespace with the support status enum.
*/
/* enum: Source mport upon entering the MAE. */
@@ -617,7 +635,8 @@
/* MAE_MCDI_ENCAP_TYPE enum: Encapsulation type. Defines how the payload will
* be parsed to an inner frame. Other values are reserved. Unknown values
- * should be treated same as NONE.
+ * should be treated same as NONE. (Values are not arbitrary - constrained by
+ * table access ABI.)
*/
#define MAE_MCDI_ENCAP_TYPE_NONE 0x0 /* enum */
/* enum: Don't assume enum aligns with support bitmask... */
@@ -634,6 +653,18 @@
/* enum: Selects the virtual NIC plugged into the MAE switch */
#define MAE_MPORT_END_VNIC 0x2
+/* MAE_COUNTER_TYPE enum: The datapath maintains several sets of counters, each
+ * being associated with a different table. Note that the same counter ID may
+ * be allocated by different counter blocks, so e.g. AR counter 42 is different
+ * from CT counter 42. Generation counts are also type-specific. This value is
+ * also present in the header of streaming counter packets, in the IDENTIFIER
+ * field (see packetiser packet format definitions).
+ */
+/* enum: Action Rule counters - can be referenced in AR response. */
+#define MAE_COUNTER_TYPE_AR 0x0
+/* enum: Conntrack counters - can be referenced in CT response. */
+#define MAE_COUNTER_TYPE_CT 0x1
+
/* MCDI_EVENT structuredef: The structure of an MCDI_EVENT on Siena/EF10/EF100
* platforms
*/
@@ -4547,6 +4578,8 @@
#define MC_CMD_MEDIA_BASE_T 0x6
/* enum: QSFP+. */
#define MC_CMD_MEDIA_QSFP_PLUS 0x7
+/* enum: DSFP. */
+#define MC_CMD_MEDIA_DSFP 0x8
#define MC_CMD_GET_PHY_CFG_OUT_MMD_MASK_OFST 48
#define MC_CMD_GET_PHY_CFG_OUT_MMD_MASK_LEN 4
/* enum: Native clause 22 */
@@ -7823,11 +7856,16 @@
/***********************************/
/* MC_CMD_GET_PHY_MEDIA_INFO
* Read media-specific data from PHY (e.g. SFP/SFP+ module ID information for
- * SFP+ PHYs). The 'media type' can be found via GET_PHY_CFG
- * (GET_PHY_CFG_OUT_MEDIA_TYPE); the valid 'page number' input values, and the
- * output data, are interpreted on a per-type basis. For SFP+: PAGE=0 or 1
+ * SFP+ PHYs). The "media type" can be found via GET_PHY_CFG
+ * (GET_PHY_CFG_OUT_MEDIA_TYPE); the valid "page number" input values, and the
+ * output data, are interpreted on a per-type basis. For SFP+, PAGE=0 or 1
* returns a 128-byte block read from module I2C address 0xA0 offset 0 or 0x80.
- * Anything else: currently undefined. Locks required: None. Return code: 0.
+ * For QSFP, PAGE=-1 is the lower (unbanked) page. PAGE=2 is the EEPROM and
+ * PAGE=3 is the module limits. For DSFP, module addressing requires a
+ * "BANK:PAGE". Not every bank has the same number of pages. See the Common
+ * Management Interface Specification (CMIS) for further details. A BANK:PAGE
+ * of "0xffff:0xffff" retrieves the lower (unbanked) page. Locks required -
+ * None. Return code - 0.
*/
#define MC_CMD_GET_PHY_MEDIA_INFO 0x4b
#define MC_CMD_GET_PHY_MEDIA_INFO_MSGSET 0x4b
@@ -7839,6 +7877,12 @@
#define MC_CMD_GET_PHY_MEDIA_INFO_IN_LEN 4
#define MC_CMD_GET_PHY_MEDIA_INFO_IN_PAGE_OFST 0
#define MC_CMD_GET_PHY_MEDIA_INFO_IN_PAGE_LEN 4
+#define MC_CMD_GET_PHY_MEDIA_INFO_IN_DSFP_PAGE_OFST 0
+#define MC_CMD_GET_PHY_MEDIA_INFO_IN_DSFP_PAGE_LBN 0
+#define MC_CMD_GET_PHY_MEDIA_INFO_IN_DSFP_PAGE_WIDTH 16
+#define MC_CMD_GET_PHY_MEDIA_INFO_IN_DSFP_BANK_OFST 0
+#define MC_CMD_GET_PHY_MEDIA_INFO_IN_DSFP_BANK_LBN 16
+#define MC_CMD_GET_PHY_MEDIA_INFO_IN_DSFP_BANK_WIDTH 16
/* MC_CMD_GET_PHY_MEDIA_INFO_OUT msgresponse */
#define MC_CMD_GET_PHY_MEDIA_INFO_OUT_LENMIN 5
@@ -9350,6 +9394,8 @@
#define NVRAM_PARTITION_TYPE_FPGA_JUMP 0xb08
/* enum: FPGA Validate XCLBIN */
#define NVRAM_PARTITION_TYPE_FPGA_XCLBIN_VALIDATE 0xb09
+/* enum: FPGA XOCL Configuration information */
+#define NVRAM_PARTITION_TYPE_FPGA_XOCL_CONFIG 0xb0a
/* enum: MUM firmware partition */
#define NVRAM_PARTITION_TYPE_MUM_FIRMWARE 0xc00
/* enum: SUC firmware partition (this is intentionally an alias of
@@ -9427,6 +9473,8 @@
#define NVRAM_PARTITION_TYPE_BUNDLE_LOG 0x1e02
/* enum: Partition for Solarflare gPXE bootrom installed via Bundle update. */
#define NVRAM_PARTITION_TYPE_EXPANSION_ROM_INTERNAL 0x1e03
+/* enum: Partition to store ASN.1 format Bundle Signature for checking. */
+#define NVRAM_PARTITION_TYPE_BUNDLE_SIGNATURE 0x1e04
/* enum: Test partition on SmartNIC system microcontroller (SUC) */
#define NVRAM_PARTITION_TYPE_SUC_TEST 0x1f00
/* enum: System microcontroller access to primary FPGA flash. */
@@ -10051,6 +10099,158 @@
#define MC_CMD_INIT_EVQ_V2_OUT_FLAG_RXQ_FORCE_EV_MERGING_LBN 3
#define MC_CMD_INIT_EVQ_V2_OUT_FLAG_RXQ_FORCE_EV_MERGING_WIDTH 1
+/* MC_CMD_INIT_EVQ_V3_IN msgrequest: Extended request to specify per-queue
+ * event merge timeouts.
+ */
+#define MC_CMD_INIT_EVQ_V3_IN_LEN 556
+/* Size, in entries */
+#define MC_CMD_INIT_EVQ_V3_IN_SIZE_OFST 0
+#define MC_CMD_INIT_EVQ_V3_IN_SIZE_LEN 4
+/* Desired instance. Must be set to a specific instance, which is a function
+ * local queue index. The calling client must be the currently-assigned user of
+ * this VI (see MC_CMD_SET_VI_USER).
+ */
+#define MC_CMD_INIT_EVQ_V3_IN_INSTANCE_OFST 4
+#define MC_CMD_INIT_EVQ_V3_IN_INSTANCE_LEN 4
+/* The initial timer value. The load value is ignored if the timer mode is DIS.
+ */
+#define MC_CMD_INIT_EVQ_V3_IN_TMR_LOAD_OFST 8
+#define MC_CMD_INIT_EVQ_V3_IN_TMR_LOAD_LEN 4
+/* The reload value is ignored in one-shot modes */
+#define MC_CMD_INIT_EVQ_V3_IN_TMR_RELOAD_OFST 12
+#define MC_CMD_INIT_EVQ_V3_IN_TMR_RELOAD_LEN 4
+/* tbd */
+#define MC_CMD_INIT_EVQ_V3_IN_FLAGS_OFST 16
+#define MC_CMD_INIT_EVQ_V3_IN_FLAGS_LEN 4
+#define MC_CMD_INIT_EVQ_V3_IN_FLAG_INTERRUPTING_OFST 16
+#define MC_CMD_INIT_EVQ_V3_IN_FLAG_INTERRUPTING_LBN 0
+#define MC_CMD_INIT_EVQ_V3_IN_FLAG_INTERRUPTING_WIDTH 1
+#define MC_CMD_INIT_EVQ_V3_IN_FLAG_RPTR_DOS_OFST 16
+#define MC_CMD_INIT_EVQ_V3_IN_FLAG_RPTR_DOS_LBN 1
+#define MC_CMD_INIT_EVQ_V3_IN_FLAG_RPTR_DOS_WIDTH 1
+#define MC_CMD_INIT_EVQ_V3_IN_FLAG_INT_ARMD_OFST 16
+#define MC_CMD_INIT_EVQ_V3_IN_FLAG_INT_ARMD_LBN 2
+#define MC_CMD_INIT_EVQ_V3_IN_FLAG_INT_ARMD_WIDTH 1
+#define MC_CMD_INIT_EVQ_V3_IN_FLAG_CUT_THRU_OFST 16
+#define MC_CMD_INIT_EVQ_V3_IN_FLAG_CUT_THRU_LBN 3
+#define MC_CMD_INIT_EVQ_V3_IN_FLAG_CUT_THRU_WIDTH 1
+#define MC_CMD_INIT_EVQ_V3_IN_FLAG_RX_MERGE_OFST 16
+#define MC_CMD_INIT_EVQ_V3_IN_FLAG_RX_MERGE_LBN 4
+#define MC_CMD_INIT_EVQ_V3_IN_FLAG_RX_MERGE_WIDTH 1
+#define MC_CMD_INIT_EVQ_V3_IN_FLAG_TX_MERGE_OFST 16
+#define MC_CMD_INIT_EVQ_V3_IN_FLAG_TX_MERGE_LBN 5
+#define MC_CMD_INIT_EVQ_V3_IN_FLAG_TX_MERGE_WIDTH 1
+#define MC_CMD_INIT_EVQ_V3_IN_FLAG_USE_TIMER_OFST 16
+#define MC_CMD_INIT_EVQ_V3_IN_FLAG_USE_TIMER_LBN 6
+#define MC_CMD_INIT_EVQ_V3_IN_FLAG_USE_TIMER_WIDTH 1
+#define MC_CMD_INIT_EVQ_V3_IN_FLAG_TYPE_OFST 16
+#define MC_CMD_INIT_EVQ_V3_IN_FLAG_TYPE_LBN 7
+#define MC_CMD_INIT_EVQ_V3_IN_FLAG_TYPE_WIDTH 4
+/* enum: All initialisation flags specified by host. */
+#define MC_CMD_INIT_EVQ_V3_IN_FLAG_TYPE_MANUAL 0x0
+/* enum: MEDFORD only. Certain initialisation flags specified by host may be
+ * over-ridden by firmware based on licenses and firmware variant in order to
+ * provide the lowest latency achievable. See
+ * MC_CMD_INIT_EVQ_V2/MC_CMD_INIT_EVQ_V2_OUT/FLAGS for list of affected flags.
+ */
+#define MC_CMD_INIT_EVQ_V3_IN_FLAG_TYPE_LOW_LATENCY 0x1
+/* enum: MEDFORD only. Certain initialisation flags specified by host may be
+ * over-ridden by firmware based on licenses and firmware variant in order to
+ * provide the best throughput achievable. See
+ * MC_CMD_INIT_EVQ_V2/MC_CMD_INIT_EVQ_V2_OUT/FLAGS for list of affected flags.
+ */
+#define MC_CMD_INIT_EVQ_V3_IN_FLAG_TYPE_THROUGHPUT 0x2
+/* enum: MEDFORD only. Certain initialisation flags may be over-ridden by
+ * firmware based on licenses and firmware variant. See
+ * MC_CMD_INIT_EVQ_V2/MC_CMD_INIT_EVQ_V2_OUT/FLAGS for list of affected flags.
+ */
+#define MC_CMD_INIT_EVQ_V3_IN_FLAG_TYPE_AUTO 0x3
+#define MC_CMD_INIT_EVQ_V3_IN_FLAG_EXT_WIDTH_OFST 16
+#define MC_CMD_INIT_EVQ_V3_IN_FLAG_EXT_WIDTH_LBN 11
+#define MC_CMD_INIT_EVQ_V3_IN_FLAG_EXT_WIDTH_WIDTH 1
+#define MC_CMD_INIT_EVQ_V3_IN_TMR_MODE_OFST 20
+#define MC_CMD_INIT_EVQ_V3_IN_TMR_MODE_LEN 4
+/* enum: Disabled */
+#define MC_CMD_INIT_EVQ_V3_IN_TMR_MODE_DIS 0x0
+/* enum: Immediate */
+#define MC_CMD_INIT_EVQ_V3_IN_TMR_IMMED_START 0x1
+/* enum: Triggered */
+#define MC_CMD_INIT_EVQ_V3_IN_TMR_TRIG_START 0x2
+/* enum: Hold-off */
+#define MC_CMD_INIT_EVQ_V3_IN_TMR_INT_HLDOFF 0x3
+/* Target EVQ for wakeups if in wakeup mode. */
+#define MC_CMD_INIT_EVQ_V3_IN_TARGET_EVQ_OFST 24
+#define MC_CMD_INIT_EVQ_V3_IN_TARGET_EVQ_LEN 4
+/* Target interrupt if in interrupting mode (note union with target EVQ). Use
+ * MC_CMD_RESOURCE_INSTANCE_ANY unless a specific one required for test
+ * purposes.
+ */
+#define MC_CMD_INIT_EVQ_V3_IN_IRQ_NUM_OFST 24
+#define MC_CMD_INIT_EVQ_V3_IN_IRQ_NUM_LEN 4
+/* Event Counter Mode. */
+#define MC_CMD_INIT_EVQ_V3_IN_COUNT_MODE_OFST 28
+#define MC_CMD_INIT_EVQ_V3_IN_COUNT_MODE_LEN 4
+/* enum: Disabled */
+#define MC_CMD_INIT_EVQ_V3_IN_COUNT_MODE_DIS 0x0
+/* enum: Disabled */
+#define MC_CMD_INIT_EVQ_V3_IN_COUNT_MODE_RX 0x1
+/* enum: Disabled */
+#define MC_CMD_INIT_EVQ_V3_IN_COUNT_MODE_TX 0x2
+/* enum: Disabled */
+#define MC_CMD_INIT_EVQ_V3_IN_COUNT_MODE_RXTX 0x3
+/* Event queue packet count threshold. */
+#define MC_CMD_INIT_EVQ_V3_IN_COUNT_THRSHLD_OFST 32
+#define MC_CMD_INIT_EVQ_V3_IN_COUNT_THRSHLD_LEN 4
+/* 64-bit address of 4k of 4k-aligned host memory buffer */
+#define MC_CMD_INIT_EVQ_V3_IN_DMA_ADDR_OFST 36
+#define MC_CMD_INIT_EVQ_V3_IN_DMA_ADDR_LEN 8
+#define MC_CMD_INIT_EVQ_V3_IN_DMA_ADDR_LO_OFST 36
+#define MC_CMD_INIT_EVQ_V3_IN_DMA_ADDR_LO_LEN 4
+#define MC_CMD_INIT_EVQ_V3_IN_DMA_ADDR_LO_LBN 288
+#define MC_CMD_INIT_EVQ_V3_IN_DMA_ADDR_LO_WIDTH 32
+#define MC_CMD_INIT_EVQ_V3_IN_DMA_ADDR_HI_OFST 40
+#define MC_CMD_INIT_EVQ_V3_IN_DMA_ADDR_HI_LEN 4
+#define MC_CMD_INIT_EVQ_V3_IN_DMA_ADDR_HI_LBN 320
+#define MC_CMD_INIT_EVQ_V3_IN_DMA_ADDR_HI_WIDTH 32
+#define MC_CMD_INIT_EVQ_V3_IN_DMA_ADDR_MINNUM 1
+#define MC_CMD_INIT_EVQ_V3_IN_DMA_ADDR_MAXNUM 64
+#define MC_CMD_INIT_EVQ_V3_IN_DMA_ADDR_MAXNUM_MCDI2 64
+/* Receive event merge timeout to configure, in nanoseconds. The valid range
+ * and granularity are device specific. Specify 0 to use the firmware's default
+ * value. This field is ignored and per-queue merging is disabled if
+ * MC_CMD_INIT_EVQ/MC_CMD_INIT_EVQ_IN/FLAG_RX_MERGE is not set.
+ */
+#define MC_CMD_INIT_EVQ_V3_IN_RX_MERGE_TIMEOUT_NS_OFST 548
+#define MC_CMD_INIT_EVQ_V3_IN_RX_MERGE_TIMEOUT_NS_LEN 4
+/* Transmit event merge timeout to configure, in nanoseconds. The valid range
+ * and granularity are device specific. Specify 0 to use the firmware's default
+ * value. This field is ignored and per-queue merging is disabled if
+ * MC_CMD_INIT_EVQ/MC_CMD_INIT_EVQ_IN/FLAG_TX_MERGE is not set.
+ */
+#define MC_CMD_INIT_EVQ_V3_IN_TX_MERGE_TIMEOUT_NS_OFST 552
+#define MC_CMD_INIT_EVQ_V3_IN_TX_MERGE_TIMEOUT_NS_LEN 4
+
+/* MC_CMD_INIT_EVQ_V3_OUT msgresponse */
+#define MC_CMD_INIT_EVQ_V3_OUT_LEN 8
+/* Only valid if INTRFLAG was true */
+#define MC_CMD_INIT_EVQ_V3_OUT_IRQ_OFST 0
+#define MC_CMD_INIT_EVQ_V3_OUT_IRQ_LEN 4
+/* Actual configuration applied on the card */
+#define MC_CMD_INIT_EVQ_V3_OUT_FLAGS_OFST 4
+#define MC_CMD_INIT_EVQ_V3_OUT_FLAGS_LEN 4
+#define MC_CMD_INIT_EVQ_V3_OUT_FLAG_CUT_THRU_OFST 4
+#define MC_CMD_INIT_EVQ_V3_OUT_FLAG_CUT_THRU_LBN 0
+#define MC_CMD_INIT_EVQ_V3_OUT_FLAG_CUT_THRU_WIDTH 1
+#define MC_CMD_INIT_EVQ_V3_OUT_FLAG_RX_MERGE_OFST 4
+#define MC_CMD_INIT_EVQ_V3_OUT_FLAG_RX_MERGE_LBN 1
+#define MC_CMD_INIT_EVQ_V3_OUT_FLAG_RX_MERGE_WIDTH 1
+#define MC_CMD_INIT_EVQ_V3_OUT_FLAG_TX_MERGE_OFST 4
+#define MC_CMD_INIT_EVQ_V3_OUT_FLAG_TX_MERGE_LBN 2
+#define MC_CMD_INIT_EVQ_V3_OUT_FLAG_TX_MERGE_WIDTH 1
+#define MC_CMD_INIT_EVQ_V3_OUT_FLAG_RXQ_FORCE_EV_MERGING_OFST 4
+#define MC_CMD_INIT_EVQ_V3_OUT_FLAG_RXQ_FORCE_EV_MERGING_LBN 3
+#define MC_CMD_INIT_EVQ_V3_OUT_FLAG_RXQ_FORCE_EV_MERGING_WIDTH 1
+
/* QUEUE_CRC_MODE structuredef */
#define QUEUE_CRC_MODE_LEN 1
#define QUEUE_CRC_MODE_MODE_LBN 0
@@ -10256,7 +10456,9 @@
#define MC_CMD_INIT_RXQ_EXT_IN_DMA_ADDR_HI_LEN 4
#define MC_CMD_INIT_RXQ_EXT_IN_DMA_ADDR_HI_LBN 256
#define MC_CMD_INIT_RXQ_EXT_IN_DMA_ADDR_HI_WIDTH 32
-#define MC_CMD_INIT_RXQ_EXT_IN_DMA_ADDR_NUM 64
+#define MC_CMD_INIT_RXQ_EXT_IN_DMA_ADDR_MINNUM 0
+#define MC_CMD_INIT_RXQ_EXT_IN_DMA_ADDR_MAXNUM 64
+#define MC_CMD_INIT_RXQ_EXT_IN_DMA_ADDR_MAXNUM_MCDI2 64
/* Maximum length of packet to receive, if SNAPSHOT_MODE flag is set */
#define MC_CMD_INIT_RXQ_EXT_IN_SNAPSHOT_LENGTH_OFST 540
#define MC_CMD_INIT_RXQ_EXT_IN_SNAPSHOT_LENGTH_LEN 4
@@ -10360,7 +10562,9 @@
#define MC_CMD_INIT_RXQ_V3_IN_DMA_ADDR_HI_LEN 4
#define MC_CMD_INIT_RXQ_V3_IN_DMA_ADDR_HI_LBN 256
#define MC_CMD_INIT_RXQ_V3_IN_DMA_ADDR_HI_WIDTH 32
-#define MC_CMD_INIT_RXQ_V3_IN_DMA_ADDR_NUM 64
+#define MC_CMD_INIT_RXQ_V3_IN_DMA_ADDR_MINNUM 0
+#define MC_CMD_INIT_RXQ_V3_IN_DMA_ADDR_MAXNUM 64
+#define MC_CMD_INIT_RXQ_V3_IN_DMA_ADDR_MAXNUM_MCDI2 64
/* Maximum length of packet to receive, if SNAPSHOT_MODE flag is set */
#define MC_CMD_INIT_RXQ_V3_IN_SNAPSHOT_LENGTH_OFST 540
#define MC_CMD_INIT_RXQ_V3_IN_SNAPSHOT_LENGTH_LEN 4
@@ -10493,7 +10697,9 @@
#define MC_CMD_INIT_RXQ_V4_IN_DMA_ADDR_HI_LEN 4
#define MC_CMD_INIT_RXQ_V4_IN_DMA_ADDR_HI_LBN 256
#define MC_CMD_INIT_RXQ_V4_IN_DMA_ADDR_HI_WIDTH 32
-#define MC_CMD_INIT_RXQ_V4_IN_DMA_ADDR_NUM 64
+#define MC_CMD_INIT_RXQ_V4_IN_DMA_ADDR_MINNUM 0
+#define MC_CMD_INIT_RXQ_V4_IN_DMA_ADDR_MAXNUM 64
+#define MC_CMD_INIT_RXQ_V4_IN_DMA_ADDR_MAXNUM_MCDI2 64
/* Maximum length of packet to receive, if SNAPSHOT_MODE flag is set */
#define MC_CMD_INIT_RXQ_V4_IN_SNAPSHOT_LENGTH_OFST 540
#define MC_CMD_INIT_RXQ_V4_IN_SNAPSHOT_LENGTH_LEN 4
@@ -10639,7 +10845,9 @@
#define MC_CMD_INIT_RXQ_V5_IN_DMA_ADDR_HI_LEN 4
#define MC_CMD_INIT_RXQ_V5_IN_DMA_ADDR_HI_LBN 256
#define MC_CMD_INIT_RXQ_V5_IN_DMA_ADDR_HI_WIDTH 32
-#define MC_CMD_INIT_RXQ_V5_IN_DMA_ADDR_NUM 64
+#define MC_CMD_INIT_RXQ_V5_IN_DMA_ADDR_MINNUM 0
+#define MC_CMD_INIT_RXQ_V5_IN_DMA_ADDR_MAXNUM 64
+#define MC_CMD_INIT_RXQ_V5_IN_DMA_ADDR_MAXNUM_MCDI2 64
/* Maximum length of packet to receive, if SNAPSHOT_MODE flag is set */
#define MC_CMD_INIT_RXQ_V5_IN_SNAPSHOT_LENGTH_OFST 540
#define MC_CMD_INIT_RXQ_V5_IN_SNAPSHOT_LENGTH_LEN 4
@@ -10878,7 +11086,7 @@
#define MC_CMD_INIT_TXQ_EXT_IN_DMA_ADDR_HI_LEN 4
#define MC_CMD_INIT_TXQ_EXT_IN_DMA_ADDR_HI_LBN 256
#define MC_CMD_INIT_TXQ_EXT_IN_DMA_ADDR_HI_WIDTH 32
-#define MC_CMD_INIT_TXQ_EXT_IN_DMA_ADDR_MINNUM 1
+#define MC_CMD_INIT_TXQ_EXT_IN_DMA_ADDR_MINNUM 0
#define MC_CMD_INIT_TXQ_EXT_IN_DMA_ADDR_MAXNUM 64
#define MC_CMD_INIT_TXQ_EXT_IN_DMA_ADDR_MAXNUM_MCDI2 64
/* Flags related to Qbb flow control mode. */
@@ -12228,6 +12436,8 @@
* rules inserted by MC_CMD_VNIC_ENCAP_RULE_ADD. (ef100 and later)
*/
#define MC_CMD_GET_PARSER_DISP_INFO_IN_OP_GET_SUPPORTED_VNIC_ENCAP_MATCHES 0x5
+/* enum: read the supported encapsulation types for the VNIC */
+#define MC_CMD_GET_PARSER_DISP_INFO_IN_OP_GET_SUPPORTED_VNIC_ENCAP_TYPES 0x6
/* MC_CMD_GET_PARSER_DISP_INFO_OUT msgresponse */
#define MC_CMD_GET_PARSER_DISP_INFO_OUT_LENMIN 8
@@ -12336,6 +12546,30 @@
#define MC_CMD_GET_PARSER_DISP_VNIC_ENCAP_MATCHES_OUT_SUPPORTED_MATCHES_MAXNUM 61
#define MC_CMD_GET_PARSER_DISP_VNIC_ENCAP_MATCHES_OUT_SUPPORTED_MATCHES_MAXNUM_MCDI2 253
+/* MC_CMD_GET_PARSER_DISP_SUPPORTED_VNIC_ENCAP_TYPES_OUT msgresponse: Returns
+ * the supported encapsulation types for the VNIC
+ */
+#define MC_CMD_GET_PARSER_DISP_SUPPORTED_VNIC_ENCAP_TYPES_OUT_LEN 8
+/* The op code OP_GET_SUPPORTED_VNIC_ENCAP_TYPES is returned */
+#define MC_CMD_GET_PARSER_DISP_SUPPORTED_VNIC_ENCAP_TYPES_OUT_OP_OFST 0
+#define MC_CMD_GET_PARSER_DISP_SUPPORTED_VNIC_ENCAP_TYPES_OUT_OP_LEN 4
+/* Enum values, see field(s): */
+/* MC_CMD_GET_PARSER_DISP_INFO_IN/OP */
+#define MC_CMD_GET_PARSER_DISP_SUPPORTED_VNIC_ENCAP_TYPES_OUT_ENCAP_TYPES_SUPPORTED_OFST 4
+#define MC_CMD_GET_PARSER_DISP_SUPPORTED_VNIC_ENCAP_TYPES_OUT_ENCAP_TYPES_SUPPORTED_LEN 4
+#define MC_CMD_GET_PARSER_DISP_SUPPORTED_VNIC_ENCAP_TYPES_OUT_ENCAP_TYPE_VXLAN_OFST 4
+#define MC_CMD_GET_PARSER_DISP_SUPPORTED_VNIC_ENCAP_TYPES_OUT_ENCAP_TYPE_VXLAN_LBN 0
+#define MC_CMD_GET_PARSER_DISP_SUPPORTED_VNIC_ENCAP_TYPES_OUT_ENCAP_TYPE_VXLAN_WIDTH 1
+#define MC_CMD_GET_PARSER_DISP_SUPPORTED_VNIC_ENCAP_TYPES_OUT_ENCAP_TYPE_NVGRE_OFST 4
+#define MC_CMD_GET_PARSER_DISP_SUPPORTED_VNIC_ENCAP_TYPES_OUT_ENCAP_TYPE_NVGRE_LBN 1
+#define MC_CMD_GET_PARSER_DISP_SUPPORTED_VNIC_ENCAP_TYPES_OUT_ENCAP_TYPE_NVGRE_WIDTH 1
+#define MC_CMD_GET_PARSER_DISP_SUPPORTED_VNIC_ENCAP_TYPES_OUT_ENCAP_TYPE_GENEVE_OFST 4
+#define MC_CMD_GET_PARSER_DISP_SUPPORTED_VNIC_ENCAP_TYPES_OUT_ENCAP_TYPE_GENEVE_LBN 2
+#define MC_CMD_GET_PARSER_DISP_SUPPORTED_VNIC_ENCAP_TYPES_OUT_ENCAP_TYPE_GENEVE_WIDTH 1
+#define MC_CMD_GET_PARSER_DISP_SUPPORTED_VNIC_ENCAP_TYPES_OUT_ENCAP_TYPE_L2GRE_OFST 4
+#define MC_CMD_GET_PARSER_DISP_SUPPORTED_VNIC_ENCAP_TYPES_OUT_ENCAP_TYPE_L2GRE_LBN 3
+#define MC_CMD_GET_PARSER_DISP_SUPPORTED_VNIC_ENCAP_TYPES_OUT_ENCAP_TYPE_L2GRE_WIDTH 1
+
/***********************************/
/* MC_CMD_PARSER_DISP_RW
@@ -16236,6 +16470,9 @@
#define MC_CMD_GET_CAPABILITIES_V7_OUT_MAE_ACTION_SET_ALLOC_V2_SUPPORTED_OFST 148
#define MC_CMD_GET_CAPABILITIES_V7_OUT_MAE_ACTION_SET_ALLOC_V2_SUPPORTED_LBN 11
#define MC_CMD_GET_CAPABILITIES_V7_OUT_MAE_ACTION_SET_ALLOC_V2_SUPPORTED_WIDTH 1
+#define MC_CMD_GET_CAPABILITIES_V7_OUT_RSS_STEER_ON_OUTER_SUPPORTED_OFST 148
+#define MC_CMD_GET_CAPABILITIES_V7_OUT_RSS_STEER_ON_OUTER_SUPPORTED_LBN 12
+#define MC_CMD_GET_CAPABILITIES_V7_OUT_RSS_STEER_ON_OUTER_SUPPORTED_WIDTH 1
/* MC_CMD_GET_CAPABILITIES_V8_OUT msgresponse */
#define MC_CMD_GET_CAPABILITIES_V8_OUT_LEN 160
@@ -16734,6 +16971,9 @@
#define MC_CMD_GET_CAPABILITIES_V8_OUT_MAE_ACTION_SET_ALLOC_V2_SUPPORTED_OFST 148
#define MC_CMD_GET_CAPABILITIES_V8_OUT_MAE_ACTION_SET_ALLOC_V2_SUPPORTED_LBN 11
#define MC_CMD_GET_CAPABILITIES_V8_OUT_MAE_ACTION_SET_ALLOC_V2_SUPPORTED_WIDTH 1
+#define MC_CMD_GET_CAPABILITIES_V8_OUT_RSS_STEER_ON_OUTER_SUPPORTED_OFST 148
+#define MC_CMD_GET_CAPABILITIES_V8_OUT_RSS_STEER_ON_OUTER_SUPPORTED_LBN 12
+#define MC_CMD_GET_CAPABILITIES_V8_OUT_RSS_STEER_ON_OUTER_SUPPORTED_WIDTH 1
/* These bits are reserved for communicating test-specific capabilities to
* host-side test software. All production drivers should treat this field as
* opaque.
@@ -17246,6 +17486,9 @@
#define MC_CMD_GET_CAPABILITIES_V9_OUT_MAE_ACTION_SET_ALLOC_V2_SUPPORTED_OFST 148
#define MC_CMD_GET_CAPABILITIES_V9_OUT_MAE_ACTION_SET_ALLOC_V2_SUPPORTED_LBN 11
#define MC_CMD_GET_CAPABILITIES_V9_OUT_MAE_ACTION_SET_ALLOC_V2_SUPPORTED_WIDTH 1
+#define MC_CMD_GET_CAPABILITIES_V9_OUT_RSS_STEER_ON_OUTER_SUPPORTED_OFST 148
+#define MC_CMD_GET_CAPABILITIES_V9_OUT_RSS_STEER_ON_OUTER_SUPPORTED_LBN 12
+#define MC_CMD_GET_CAPABILITIES_V9_OUT_RSS_STEER_ON_OUTER_SUPPORTED_WIDTH 1
/* These bits are reserved for communicating test-specific capabilities to
* host-side test software. All production drivers should treat this field as
* opaque.
@@ -17793,6 +18036,9 @@
#define MC_CMD_GET_CAPABILITIES_V10_OUT_MAE_ACTION_SET_ALLOC_V2_SUPPORTED_OFST 148
#define MC_CMD_GET_CAPABILITIES_V10_OUT_MAE_ACTION_SET_ALLOC_V2_SUPPORTED_LBN 11
#define MC_CMD_GET_CAPABILITIES_V10_OUT_MAE_ACTION_SET_ALLOC_V2_SUPPORTED_WIDTH 1
+#define MC_CMD_GET_CAPABILITIES_V10_OUT_RSS_STEER_ON_OUTER_SUPPORTED_OFST 148
+#define MC_CMD_GET_CAPABILITIES_V10_OUT_RSS_STEER_ON_OUTER_SUPPORTED_LBN 12
+#define MC_CMD_GET_CAPABILITIES_V10_OUT_RSS_STEER_ON_OUTER_SUPPORTED_WIDTH 1
/* These bits are reserved for communicating test-specific capabilities to
* host-side test software. All production drivers should treat this field as
* opaque.
@@ -19900,6 +20146,18 @@
#define MC_CMD_GET_FUNCTION_INFO_OUT_VF_OFST 4
#define MC_CMD_GET_FUNCTION_INFO_OUT_VF_LEN 4
+/* MC_CMD_GET_FUNCTION_INFO_OUT_V2 msgresponse */
+#define MC_CMD_GET_FUNCTION_INFO_OUT_V2_LEN 12
+#define MC_CMD_GET_FUNCTION_INFO_OUT_V2_PF_OFST 0
+#define MC_CMD_GET_FUNCTION_INFO_OUT_V2_PF_LEN 4
+#define MC_CMD_GET_FUNCTION_INFO_OUT_V2_VF_OFST 4
+#define MC_CMD_GET_FUNCTION_INFO_OUT_V2_VF_LEN 4
+/* Values from PCIE_INTERFACE enumeration. For NICs with a single interface, or
+ * in the case of a V1 response, this should be HOST_PRIMARY.
+ */
+#define MC_CMD_GET_FUNCTION_INFO_OUT_V2_INTF_OFST 8
+#define MC_CMD_GET_FUNCTION_INFO_OUT_V2_INTF_LEN 4
+
/***********************************/
/* MC_CMD_ENABLE_OFFLINE_BIST
@@ -25682,6 +25940,9 @@
#define MC_CMD_GET_RX_PREFIX_ID_IN_USER_MARK_OFST 0
#define MC_CMD_GET_RX_PREFIX_ID_IN_USER_MARK_LBN 6
#define MC_CMD_GET_RX_PREFIX_ID_IN_USER_MARK_WIDTH 1
+#define MC_CMD_GET_RX_PREFIX_ID_IN_INGRESS_MPORT_OFST 0
+#define MC_CMD_GET_RX_PREFIX_ID_IN_INGRESS_MPORT_LBN 7
+#define MC_CMD_GET_RX_PREFIX_ID_IN_INGRESS_MPORT_WIDTH 1
#define MC_CMD_GET_RX_PREFIX_ID_IN_INGRESS_VPORT_OFST 0
#define MC_CMD_GET_RX_PREFIX_ID_IN_INGRESS_VPORT_LBN 7
#define MC_CMD_GET_RX_PREFIX_ID_IN_INGRESS_VPORT_WIDTH 1
@@ -25691,6 +25952,12 @@
#define MC_CMD_GET_RX_PREFIX_ID_IN_VLAN_STRIP_TCI_OFST 0
#define MC_CMD_GET_RX_PREFIX_ID_IN_VLAN_STRIP_TCI_LBN 9
#define MC_CMD_GET_RX_PREFIX_ID_IN_VLAN_STRIP_TCI_WIDTH 1
+#define MC_CMD_GET_RX_PREFIX_ID_IN_VLAN_STRIPPED_OFST 0
+#define MC_CMD_GET_RX_PREFIX_ID_IN_VLAN_STRIPPED_LBN 10
+#define MC_CMD_GET_RX_PREFIX_ID_IN_VLAN_STRIPPED_WIDTH 1
+#define MC_CMD_GET_RX_PREFIX_ID_IN_VSWITCH_STATUS_OFST 0
+#define MC_CMD_GET_RX_PREFIX_ID_IN_VSWITCH_STATUS_LBN 11
+#define MC_CMD_GET_RX_PREFIX_ID_IN_VSWITCH_STATUS_WIDTH 1
/* MC_CMD_GET_RX_PREFIX_ID_OUT msgresponse */
#define MC_CMD_GET_RX_PREFIX_ID_OUT_LENMIN 8
@@ -25736,9 +26003,12 @@
#define RX_PREFIX_FIELD_INFO_PARTIAL_TSTAMP 0x4 /* enum */
#define RX_PREFIX_FIELD_INFO_RSS_HASH 0x5 /* enum */
#define RX_PREFIX_FIELD_INFO_USER_MARK 0x6 /* enum */
+#define RX_PREFIX_FIELD_INFO_INGRESS_MPORT 0x7 /* enum */
#define RX_PREFIX_FIELD_INFO_INGRESS_VPORT 0x7 /* enum */
#define RX_PREFIX_FIELD_INFO_CSUM_FRAME 0x8 /* enum */
#define RX_PREFIX_FIELD_INFO_VLAN_STRIP_TCI 0x9 /* enum */
+#define RX_PREFIX_FIELD_INFO_VLAN_STRIPPED 0xa /* enum */
+#define RX_PREFIX_FIELD_INFO_VSWITCH_STATUS 0xb /* enum */
#define RX_PREFIX_FIELD_INFO_TYPE_LBN 24
#define RX_PREFIX_FIELD_INFO_TYPE_WIDTH 8
@@ -26063,6 +26333,10 @@
#define MC_CMD_FPGA_IN_OP_SET_INTERNAL_LINK 0x5
/* enum: Read internal link configuration. */
#define MC_CMD_FPGA_IN_OP_GET_INTERNAL_LINK 0x6
+/* enum: Get MAC statistics of FPGA external port. */
+#define MC_CMD_FPGA_IN_OP_GET_MAC_STATS 0x7
+/* enum: Set configuration on internal FPGA MAC. */
+#define MC_CMD_FPGA_IN_OP_SET_INTERNAL_MAC 0x8
/* MC_CMD_FPGA_OP_GET_VERSION_IN msgrequest: Get the FPGA version string. A
* free-format string is returned in response to this command. Any checks on
@@ -26206,6 +26480,87 @@
#define MC_CMD_FPGA_OP_GET_INTERNAL_LINK_OUT_SPEED_OFST 4
#define MC_CMD_FPGA_OP_GET_INTERNAL_LINK_OUT_SPEED_LEN 4
+/* MC_CMD_FPGA_OP_GET_MAC_STATS_IN msgrequest: Get FPGA external port MAC
+ * statistics.
+ */
+#define MC_CMD_FPGA_OP_GET_MAC_STATS_IN_LEN 4
+/* Sub-command code. Must be OP_GET_MAC_STATS. */
+#define MC_CMD_FPGA_OP_GET_MAC_STATS_IN_OP_OFST 0
+#define MC_CMD_FPGA_OP_GET_MAC_STATS_IN_OP_LEN 4
+
+/* MC_CMD_FPGA_OP_GET_MAC_STATS_OUT msgresponse */
+#define MC_CMD_FPGA_OP_GET_MAC_STATS_OUT_LENMIN 4
+#define MC_CMD_FPGA_OP_GET_MAC_STATS_OUT_LENMAX 252
+#define MC_CMD_FPGA_OP_GET_MAC_STATS_OUT_LENMAX_MCDI2 1020
+#define MC_CMD_FPGA_OP_GET_MAC_STATS_OUT_LEN(num) (4+8*(num))
+#define MC_CMD_FPGA_OP_GET_MAC_STATS_OUT_STATISTICS_NUM(len) (((len)-4)/8)
+#define MC_CMD_FPGA_OP_GET_MAC_STATS_OUT_NUM_STATS_OFST 0
+#define MC_CMD_FPGA_OP_GET_MAC_STATS_OUT_NUM_STATS_LEN 4
+#define MC_CMD_FPGA_OP_GET_MAC_STATS_OUT_STATISTICS_OFST 4
+#define MC_CMD_FPGA_OP_GET_MAC_STATS_OUT_STATISTICS_LEN 8
+#define MC_CMD_FPGA_OP_GET_MAC_STATS_OUT_STATISTICS_LO_OFST 4
+#define MC_CMD_FPGA_OP_GET_MAC_STATS_OUT_STATISTICS_LO_LEN 4
+#define MC_CMD_FPGA_OP_GET_MAC_STATS_OUT_STATISTICS_LO_LBN 32
+#define MC_CMD_FPGA_OP_GET_MAC_STATS_OUT_STATISTICS_LO_WIDTH 32
+#define MC_CMD_FPGA_OP_GET_MAC_STATS_OUT_STATISTICS_HI_OFST 8
+#define MC_CMD_FPGA_OP_GET_MAC_STATS_OUT_STATISTICS_HI_LEN 4
+#define MC_CMD_FPGA_OP_GET_MAC_STATS_OUT_STATISTICS_HI_LBN 64
+#define MC_CMD_FPGA_OP_GET_MAC_STATS_OUT_STATISTICS_HI_WIDTH 32
+#define MC_CMD_FPGA_OP_GET_MAC_STATS_OUT_STATISTICS_MINNUM 0
+#define MC_CMD_FPGA_OP_GET_MAC_STATS_OUT_STATISTICS_MAXNUM 31
+#define MC_CMD_FPGA_OP_GET_MAC_STATS_OUT_STATISTICS_MAXNUM_MCDI2 127
+#define MC_CMD_FPGA_MAC_TX_TOTAL_PACKETS 0x0 /* enum */
+#define MC_CMD_FPGA_MAC_TX_TOTAL_BYTES 0x1 /* enum */
+#define MC_CMD_FPGA_MAC_TX_TOTAL_GOOD_PACKETS 0x2 /* enum */
+#define MC_CMD_FPGA_MAC_TX_TOTAL_GOOD_BYTES 0x3 /* enum */
+#define MC_CMD_FPGA_MAC_TX_BAD_FCS 0x4 /* enum */
+#define MC_CMD_FPGA_MAC_TX_PAUSE 0x5 /* enum */
+#define MC_CMD_FPGA_MAC_TX_USER_PAUSE 0x6 /* enum */
+#define MC_CMD_FPGA_MAC_RX_TOTAL_PACKETS 0x7 /* enum */
+#define MC_CMD_FPGA_MAC_RX_TOTAL_BYTES 0x8 /* enum */
+#define MC_CMD_FPGA_MAC_RX_TOTAL_GOOD_PACKETS 0x9 /* enum */
+#define MC_CMD_FPGA_MAC_RX_TOTAL_GOOD_BYTES 0xa /* enum */
+#define MC_CMD_FPGA_MAC_RX_BAD_FCS 0xb /* enum */
+#define MC_CMD_FPGA_MAC_RX_PAUSE 0xc /* enum */
+#define MC_CMD_FPGA_MAC_RX_USER_PAUSE 0xd /* enum */
+#define MC_CMD_FPGA_MAC_RX_UNDERSIZE 0xe /* enum */
+#define MC_CMD_FPGA_MAC_RX_OVERSIZE 0xf /* enum */
+#define MC_CMD_FPGA_MAC_RX_FRAMING_ERR 0x10 /* enum */
+#define MC_CMD_FPGA_MAC_FEC_UNCORRECTED_ERRORS 0x11 /* enum */
+#define MC_CMD_FPGA_MAC_FEC_CORRECTED_ERRORS 0x12 /* enum */
+
+/* MC_CMD_FPGA_OP_SET_INTERNAL_MAC_IN msgrequest: Configures the internal port
+ * MAC on the FPGA.
+ */
+#define MC_CMD_FPGA_OP_SET_INTERNAL_MAC_IN_LEN 20
+/* Sub-command code. Must be OP_SET_INTERNAL_MAC. */
+#define MC_CMD_FPGA_OP_SET_INTERNAL_MAC_IN_OP_OFST 0
+#define MC_CMD_FPGA_OP_SET_INTERNAL_MAC_IN_OP_LEN 4
+/* Select which parameters to configure. */
+#define MC_CMD_FPGA_OP_SET_INTERNAL_MAC_IN_CONTROL_OFST 4
+#define MC_CMD_FPGA_OP_SET_INTERNAL_MAC_IN_CONTROL_LEN 4
+#define MC_CMD_FPGA_OP_SET_INTERNAL_MAC_IN_CFG_MTU_OFST 4
+#define MC_CMD_FPGA_OP_SET_INTERNAL_MAC_IN_CFG_MTU_LBN 0
+#define MC_CMD_FPGA_OP_SET_INTERNAL_MAC_IN_CFG_MTU_WIDTH 1
+#define MC_CMD_FPGA_OP_SET_INTERNAL_MAC_IN_CFG_DRAIN_OFST 4
+#define MC_CMD_FPGA_OP_SET_INTERNAL_MAC_IN_CFG_DRAIN_LBN 1
+#define MC_CMD_FPGA_OP_SET_INTERNAL_MAC_IN_CFG_DRAIN_WIDTH 1
+#define MC_CMD_FPGA_OP_SET_INTERNAL_MAC_IN_CFG_FCNTL_OFST 4
+#define MC_CMD_FPGA_OP_SET_INTERNAL_MAC_IN_CFG_FCNTL_LBN 2
+#define MC_CMD_FPGA_OP_SET_INTERNAL_MAC_IN_CFG_FCNTL_WIDTH 1
+/* The MTU to be programmed into the MAC. */
+#define MC_CMD_FPGA_OP_SET_INTERNAL_MAC_IN_MTU_OFST 8
+#define MC_CMD_FPGA_OP_SET_INTERNAL_MAC_IN_MTU_LEN 4
+/* Drain Tx FIFO */
+#define MC_CMD_FPGA_OP_SET_INTERNAL_MAC_IN_DRAIN_OFST 12
+#define MC_CMD_FPGA_OP_SET_INTERNAL_MAC_IN_DRAIN_LEN 4
+/* flow control configuration. See MC_CMD_SET_MAC/MC_CMD_SET_MAC_IN/FCNTL. */
+#define MC_CMD_FPGA_OP_SET_INTERNAL_MAC_IN_FCNTL_OFST 16
+#define MC_CMD_FPGA_OP_SET_INTERNAL_MAC_IN_FCNTL_LEN 4
+
+/* MC_CMD_FPGA_OP_SET_INTERNAL_MAC_OUT msgresponse */
+#define MC_CMD_FPGA_OP_SET_INTERNAL_MAC_OUT_LEN 0
+
/***********************************/
/* MC_CMD_EXTERNAL_MAE_GET_LINK_MODE
@@ -26483,6 +26838,12 @@
#define MC_CMD_VNIC_ENCAP_RULE_ADD_IN_STRIP_OUTER_VLAN_OFST 29
#define MC_CMD_VNIC_ENCAP_RULE_ADD_IN_STRIP_OUTER_VLAN_LBN 0
#define MC_CMD_VNIC_ENCAP_RULE_ADD_IN_STRIP_OUTER_VLAN_WIDTH 1
+#define MC_CMD_VNIC_ENCAP_RULE_ADD_IN_RSS_ON_OUTER_OFST 29
+#define MC_CMD_VNIC_ENCAP_RULE_ADD_IN_RSS_ON_OUTER_LBN 1
+#define MC_CMD_VNIC_ENCAP_RULE_ADD_IN_RSS_ON_OUTER_WIDTH 1
+#define MC_CMD_VNIC_ENCAP_RULE_ADD_IN_STEER_ON_OUTER_OFST 29
+#define MC_CMD_VNIC_ENCAP_RULE_ADD_IN_STEER_ON_OUTER_LBN 2
+#define MC_CMD_VNIC_ENCAP_RULE_ADD_IN_STEER_ON_OUTER_WIDTH 1
/* Only if MATCH_DST_PORT is set. Port number as bytes in network order. */
#define MC_CMD_VNIC_ENCAP_RULE_ADD_IN_DST_PORT_OFST 30
#define MC_CMD_VNIC_ENCAP_RULE_ADD_IN_DST_PORT_LEN 2
@@ -26544,6 +26905,257 @@
#define UUID_NODE_LBN 80
#define UUID_NODE_WIDTH 48
+
+/***********************************/
+/* MC_CMD_PLUGIN_ALLOC
+ * Create a handle to a datapath plugin's extension. This involves finding a
+ * currently-loaded plugin offering the given functionality (as identified by
+ * the UUID) and allocating a handle to track the usage of it. Plugin
+ * functionality is identified by 'extension' rather than any other identifier
+ * so that a single plugin bitfile may offer more than one piece of independent
+ * functionality. If two bitfiles are loaded which both offer the same
+ * extension, then the metadata is interrogated further to determine which is
+ * the newest and that is the one opened. See SF-123625-SW for architectural
+ * detail on datapath plugins.
+ */
+#define MC_CMD_PLUGIN_ALLOC 0x1ad
+#define MC_CMD_PLUGIN_ALLOC_MSGSET 0x1ad
+#undef MC_CMD_0x1ad_PRIVILEGE_CTG
+
+#define MC_CMD_0x1ad_PRIVILEGE_CTG SRIOV_CTG_GENERAL
+
+/* MC_CMD_PLUGIN_ALLOC_IN msgrequest */
+#define MC_CMD_PLUGIN_ALLOC_IN_LEN 24
+/* The functionality requested of the plugin, as a UUID structure */
+#define MC_CMD_PLUGIN_ALLOC_IN_UUID_OFST 0
+#define MC_CMD_PLUGIN_ALLOC_IN_UUID_LEN 16
+/* Additional options for opening the handle */
+#define MC_CMD_PLUGIN_ALLOC_IN_FLAGS_OFST 16
+#define MC_CMD_PLUGIN_ALLOC_IN_FLAGS_LEN 4
+#define MC_CMD_PLUGIN_ALLOC_IN_FLAG_INFO_ONLY_OFST 16
+#define MC_CMD_PLUGIN_ALLOC_IN_FLAG_INFO_ONLY_LBN 0
+#define MC_CMD_PLUGIN_ALLOC_IN_FLAG_INFO_ONLY_WIDTH 1
+#define MC_CMD_PLUGIN_ALLOC_IN_FLAG_ALLOW_DISABLED_OFST 16
+#define MC_CMD_PLUGIN_ALLOC_IN_FLAG_ALLOW_DISABLED_LBN 1
+#define MC_CMD_PLUGIN_ALLOC_IN_FLAG_ALLOW_DISABLED_WIDTH 1
+/* Load the extension only if it is in the specified administrative group.
+ * Specify ANY to load the extension wherever it is found (if there are
+ * multiple choices then the extension with the highest MINOR_VER/PATCH_VER
+ * will be loaded). See MC_CMD_PLUGIN_GET_META_GLOBAL for a description of
+ * administrative groups.
+ */
+#define MC_CMD_PLUGIN_ALLOC_IN_ADMIN_GROUP_OFST 20
+#define MC_CMD_PLUGIN_ALLOC_IN_ADMIN_GROUP_LEN 2
+/* enum: Load the extension from any ADMIN_GROUP. */
+#define MC_CMD_PLUGIN_ALLOC_IN_ANY 0xffff
+/* Reserved */
+#define MC_CMD_PLUGIN_ALLOC_IN_RESERVED_OFST 22
+#define MC_CMD_PLUGIN_ALLOC_IN_RESERVED_LEN 2
+
+/* MC_CMD_PLUGIN_ALLOC_OUT msgresponse */
+#define MC_CMD_PLUGIN_ALLOC_OUT_LEN 4
+/* Unique identifier of this usage */
+#define MC_CMD_PLUGIN_ALLOC_OUT_HANDLE_OFST 0
+#define MC_CMD_PLUGIN_ALLOC_OUT_HANDLE_LEN 4
+
+
+/***********************************/
+/* MC_CMD_PLUGIN_FREE
+ * Delete a handle to a plugin's extension.
+ */
+#define MC_CMD_PLUGIN_FREE 0x1ae
+#define MC_CMD_PLUGIN_FREE_MSGSET 0x1ae
+#undef MC_CMD_0x1ae_PRIVILEGE_CTG
+
+#define MC_CMD_0x1ae_PRIVILEGE_CTG SRIOV_CTG_GENERAL
+
+/* MC_CMD_PLUGIN_FREE_IN msgrequest */
+#define MC_CMD_PLUGIN_FREE_IN_LEN 4
+/* Handle returned by MC_CMD_PLUGIN_ALLOC_OUT */
+#define MC_CMD_PLUGIN_FREE_IN_HANDLE_OFST 0
+#define MC_CMD_PLUGIN_FREE_IN_HANDLE_LEN 4
+
+/* MC_CMD_PLUGIN_FREE_OUT msgresponse */
+#define MC_CMD_PLUGIN_FREE_OUT_LEN 0
+
+
+/***********************************/
+/* MC_CMD_PLUGIN_GET_META_GLOBAL
+ * Returns the global metadata applying to the whole plugin extension. See the
+ * other metadata calls for subtypes of data.
+ */
+#define MC_CMD_PLUGIN_GET_META_GLOBAL 0x1af
+#define MC_CMD_PLUGIN_GET_META_GLOBAL_MSGSET 0x1af
+#undef MC_CMD_0x1af_PRIVILEGE_CTG
+
+#define MC_CMD_0x1af_PRIVILEGE_CTG SRIOV_CTG_GENERAL
+
+/* MC_CMD_PLUGIN_GET_META_GLOBAL_IN msgrequest */
+#define MC_CMD_PLUGIN_GET_META_GLOBAL_IN_LEN 4
+/* Handle returned by MC_CMD_PLUGIN_ALLOC_OUT */
+#define MC_CMD_PLUGIN_GET_META_GLOBAL_IN_HANDLE_OFST 0
+#define MC_CMD_PLUGIN_GET_META_GLOBAL_IN_HANDLE_LEN 4
+
+/* MC_CMD_PLUGIN_GET_META_GLOBAL_OUT msgresponse */
+#define MC_CMD_PLUGIN_GET_META_GLOBAL_OUT_LEN 36
+/* Unique identifier of this plugin extension. This is identical to the value
+ * which was requested when the handle was allocated.
+ */
+#define MC_CMD_PLUGIN_GET_META_GLOBAL_OUT_UUID_OFST 0
+#define MC_CMD_PLUGIN_GET_META_GLOBAL_OUT_UUID_LEN 16
+/* semver sub-version of this plugin extension */
+#define MC_CMD_PLUGIN_GET_META_GLOBAL_OUT_MINOR_VER_OFST 16
+#define MC_CMD_PLUGIN_GET_META_GLOBAL_OUT_MINOR_VER_LEN 2
+/* semver micro-version of this plugin extension */
+#define MC_CMD_PLUGIN_GET_META_GLOBAL_OUT_PATCH_VER_OFST 18
+#define MC_CMD_PLUGIN_GET_META_GLOBAL_OUT_PATCH_VER_LEN 2
+/* Number of different messages which can be sent to this extension */
+#define MC_CMD_PLUGIN_GET_META_GLOBAL_OUT_NUM_MSGS_OFST 20
+#define MC_CMD_PLUGIN_GET_META_GLOBAL_OUT_NUM_MSGS_LEN 4
+/* Byte offset within the VI window of the plugin's mapped CSR window. */
+#define MC_CMD_PLUGIN_GET_META_GLOBAL_OUT_MAPPED_CSR_OFFSET_OFST 24
+#define MC_CMD_PLUGIN_GET_META_GLOBAL_OUT_MAPPED_CSR_OFFSET_LEN 2
+/* Number of bytes mapped through to the plugin's CSRs. 0 if that feature was
+ * not requested by the plugin (in which case MAPPED_CSR_OFFSET and
+ * MAPPED_CSR_FLAGS are ignored).
+ */
+#define MC_CMD_PLUGIN_GET_META_GLOBAL_OUT_MAPPED_CSR_SIZE_OFST 26
+#define MC_CMD_PLUGIN_GET_META_GLOBAL_OUT_MAPPED_CSR_SIZE_LEN 2
+/* Flags indicating how to perform the CSR window mapping. */
+#define MC_CMD_PLUGIN_GET_META_GLOBAL_OUT_MAPPED_CSR_FLAGS_OFST 28
+#define MC_CMD_PLUGIN_GET_META_GLOBAL_OUT_MAPPED_CSR_FLAGS_LEN 4
+#define MC_CMD_PLUGIN_GET_META_GLOBAL_OUT_MAPPED_CSR_FLAG_READ_OFST 28
+#define MC_CMD_PLUGIN_GET_META_GLOBAL_OUT_MAPPED_CSR_FLAG_READ_LBN 0
+#define MC_CMD_PLUGIN_GET_META_GLOBAL_OUT_MAPPED_CSR_FLAG_READ_WIDTH 1
+#define MC_CMD_PLUGIN_GET_META_GLOBAL_OUT_MAPPED_CSR_FLAG_WRITE_OFST 28
+#define MC_CMD_PLUGIN_GET_META_GLOBAL_OUT_MAPPED_CSR_FLAG_WRITE_LBN 1
+#define MC_CMD_PLUGIN_GET_META_GLOBAL_OUT_MAPPED_CSR_FLAG_WRITE_WIDTH 1
+/* Identifier of the set of extensions which all change state together.
+ * Extensions having the same ADMIN_GROUP will always load and unload at the
+ * same time. ADMIN_GROUP values themselves are arbitrary (but they contain a
+ * generation number as an implementation detail to ensure that they're not
+ * reused rapidly).
+ */
+#define MC_CMD_PLUGIN_GET_META_GLOBAL_OUT_ADMIN_GROUP_OFST 32
+#define MC_CMD_PLUGIN_GET_META_GLOBAL_OUT_ADMIN_GROUP_LEN 1
+/* Bitshift in MC_CMD_DEVEL_CLIENT_PRIVILEGE_MODIFY's MASK parameters
+ * corresponding to this extension, i.e. set the bit 1<<PRIVILEGE_BIT to permit
+ * access to this extension.
+ */
+#define MC_CMD_PLUGIN_GET_META_GLOBAL_OUT_PRIVILEGE_BIT_OFST 33
+#define MC_CMD_PLUGIN_GET_META_GLOBAL_OUT_PRIVILEGE_BIT_LEN 1
+/* Reserved */
+#define MC_CMD_PLUGIN_GET_META_GLOBAL_OUT_RESERVED_OFST 34
+#define MC_CMD_PLUGIN_GET_META_GLOBAL_OUT_RESERVED_LEN 2
+
+
+/***********************************/
+/* MC_CMD_PLUGIN_GET_META_PUBLISHER
+ * Returns metadata supplied by the plugin author which describes this
+ * extension in a human-readable way. Contrast with
+ * MC_CMD_PLUGIN_GET_META_GLOBAL, which returns information needed for software
+ * to operate.
+ */
+#define MC_CMD_PLUGIN_GET_META_PUBLISHER 0x1b0
+#define MC_CMD_PLUGIN_GET_META_PUBLISHER_MSGSET 0x1b0
+#undef MC_CMD_0x1b0_PRIVILEGE_CTG
+
+#define MC_CMD_0x1b0_PRIVILEGE_CTG SRIOV_CTG_GENERAL
+
+/* MC_CMD_PLUGIN_GET_META_PUBLISHER_IN msgrequest */
+#define MC_CMD_PLUGIN_GET_META_PUBLISHER_IN_LEN 12
+/* Handle returned by MC_CMD_PLUGIN_ALLOC_OUT */
+#define MC_CMD_PLUGIN_GET_META_PUBLISHER_IN_HANDLE_OFST 0
+#define MC_CMD_PLUGIN_GET_META_PUBLISHER_IN_HANDLE_LEN 4
+/* Category of data to return */
+#define MC_CMD_PLUGIN_GET_META_PUBLISHER_IN_SUBTYPE_OFST 4
+#define MC_CMD_PLUGIN_GET_META_PUBLISHER_IN_SUBTYPE_LEN 4
+/* enum: Top-level information about the extension. The returned data is an
+ * array of key/value pairs using the keys in RFC5013 (Dublin Core) to describe
+ * the extension. The data is a back-to-back list of zero-terminated strings;
+ * the even-numbered fields (0,2,4,...) are keys and their following odd-
+ * numbered fields are the corresponding values. Both keys and values are
+ * nominally UTF-8. Per RFC5013, the same key may be repeated any number of
+ * times. Note that all information (including the key/value structure itself
+ * and the UTF-8 encoding) may have been provided by the plugin author, so
+ * callers must be cautious about parsing it. Callers should parse only the
+ * top-level structure to separate out the keys and values; the contents of the
+ * values is not expected to be machine-readable.
+ */
+#define MC_CMD_PLUGIN_GET_META_PUBLISHER_IN_EXTENSION_KVS 0x0
+/* Byte position of the data to be returned within the full data block of the
+ * given SUBTYPE.
+ */
+#define MC_CMD_PLUGIN_GET_META_PUBLISHER_IN_OFFSET_OFST 8
+#define MC_CMD_PLUGIN_GET_META_PUBLISHER_IN_OFFSET_LEN 4
+
+/* MC_CMD_PLUGIN_GET_META_PUBLISHER_OUT msgresponse */
+#define MC_CMD_PLUGIN_GET_META_PUBLISHER_OUT_LENMIN 4
+#define MC_CMD_PLUGIN_GET_META_PUBLISHER_OUT_LENMAX 252
+#define MC_CMD_PLUGIN_GET_META_PUBLISHER_OUT_LENMAX_MCDI2 1020
+#define MC_CMD_PLUGIN_GET_META_PUBLISHER_OUT_LEN(num) (4+1*(num))
+#define MC_CMD_PLUGIN_GET_META_PUBLISHER_OUT_DATA_NUM(len) (((len)-4)/1)
+/* Full length of the data block of the requested SUBTYPE, in bytes. */
+#define MC_CMD_PLUGIN_GET_META_PUBLISHER_OUT_TOTAL_SIZE_OFST 0
+#define MC_CMD_PLUGIN_GET_META_PUBLISHER_OUT_TOTAL_SIZE_LEN 4
+/* The information requested by SUBTYPE. */
+#define MC_CMD_PLUGIN_GET_META_PUBLISHER_OUT_DATA_OFST 4
+#define MC_CMD_PLUGIN_GET_META_PUBLISHER_OUT_DATA_LEN 1
+#define MC_CMD_PLUGIN_GET_META_PUBLISHER_OUT_DATA_MINNUM 0
+#define MC_CMD_PLUGIN_GET_META_PUBLISHER_OUT_DATA_MAXNUM 248
+#define MC_CMD_PLUGIN_GET_META_PUBLISHER_OUT_DATA_MAXNUM_MCDI2 1016
+
+
+/***********************************/
+/* MC_CMD_PLUGIN_GET_META_MSG
+ * Returns the simple metadata for a specific plugin request message. This
+ * supplies information necessary for the host to know how to build an
+ * MC_CMD_PLUGIN_REQ request.
+ */
+#define MC_CMD_PLUGIN_GET_META_MSG 0x1b1
+#define MC_CMD_PLUGIN_GET_META_MSG_MSGSET 0x1b1
+#undef MC_CMD_0x1b1_PRIVILEGE_CTG
+
+#define MC_CMD_0x1b1_PRIVILEGE_CTG SRIOV_CTG_GENERAL
+
+/* MC_CMD_PLUGIN_GET_META_MSG_IN msgrequest */
+#define MC_CMD_PLUGIN_GET_META_MSG_IN_LEN 8
+/* Handle returned by MC_CMD_PLUGIN_ALLOC_OUT */
+#define MC_CMD_PLUGIN_GET_META_MSG_IN_HANDLE_OFST 0
+#define MC_CMD_PLUGIN_GET_META_MSG_IN_HANDLE_LEN 4
+/* Unique message ID to obtain */
+#define MC_CMD_PLUGIN_GET_META_MSG_IN_ID_OFST 4
+#define MC_CMD_PLUGIN_GET_META_MSG_IN_ID_LEN 4
+
+/* MC_CMD_PLUGIN_GET_META_MSG_OUT msgresponse */
+#define MC_CMD_PLUGIN_GET_META_MSG_OUT_LEN 44
+/* Unique message ID. This is the same value as the input parameter; it exists
+ * to allow future MCDI extensions which enumerate all messages.
+ */
+#define MC_CMD_PLUGIN_GET_META_MSG_OUT_ID_OFST 0
+#define MC_CMD_PLUGIN_GET_META_MSG_OUT_ID_LEN 4
+/* Packed index number of this message, assigned by the MC to give each message
+ * a unique ID in an array to allow for more efficient storage/management.
+ */
+#define MC_CMD_PLUGIN_GET_META_MSG_OUT_INDEX_OFST 4
+#define MC_CMD_PLUGIN_GET_META_MSG_OUT_INDEX_LEN 4
+/* Short human-readable codename for this message. This is conventionally
+ * formatted as a C identifier in the basic ASCII character set with any spare
+ * bytes at the end set to 0, however this convention is not enforced by the MC
+ * so consumers must check for all potential malformations before using it for
+ * a trusted purpose.
+ */
+#define MC_CMD_PLUGIN_GET_META_MSG_OUT_NAME_OFST 8
+#define MC_CMD_PLUGIN_GET_META_MSG_OUT_NAME_LEN 32
+/* Number of bytes of data which must be passed from the host kernel to the MC
+ * for this message's payload, and which are passed back again in the response.
+ * The MC's plugin metadata loader will have validated that the number of bytes
+ * specified here will fit in to MC_CMD_PLUGIN_REQ_IN_DATA in a single MCDI
+ * message.
+ */
+#define MC_CMD_PLUGIN_GET_META_MSG_OUT_DATA_SIZE_OFST 40
+#define MC_CMD_PLUGIN_GET_META_MSG_OUT_DATA_SIZE_LEN 4
+
/* PLUGIN_EXTENSION structuredef: Used within MC_CMD_PLUGIN_GET_ALL to describe
* an individual extension.
*/
@@ -26561,6 +27173,100 @@
#define PLUGIN_EXTENSION_RESERVED_LBN 137
#define PLUGIN_EXTENSION_RESERVED_WIDTH 23
+
+/***********************************/
+/* MC_CMD_PLUGIN_GET_ALL
+ * Returns a list of all plugin extensions currently loaded and available. The
+ * UUIDs returned can be passed to MC_CMD_PLUGIN_ALLOC in order to obtain more
+ * detailed metadata via the MC_CMD_PLUGIN_GET_META_* family of requests. The
+ * ADMIN_GROUP field collects how extensions are grouped in to units which are
+ * loaded/unloaded together; extensions with the same value are in the same
+ * group.
+ */
+#define MC_CMD_PLUGIN_GET_ALL 0x1b2
+#define MC_CMD_PLUGIN_GET_ALL_MSGSET 0x1b2
+#undef MC_CMD_0x1b2_PRIVILEGE_CTG
+
+#define MC_CMD_0x1b2_PRIVILEGE_CTG SRIOV_CTG_GENERAL
+
+/* MC_CMD_PLUGIN_GET_ALL_IN msgrequest */
+#define MC_CMD_PLUGIN_GET_ALL_IN_LEN 4
+/* Additional options for querying. Note that if neither FLAG_INCLUDE_ENABLED
+ * nor FLAG_INCLUDE_DISABLED are specified then the result set will be empty.
+ */
+#define MC_CMD_PLUGIN_GET_ALL_IN_FLAGS_OFST 0
+#define MC_CMD_PLUGIN_GET_ALL_IN_FLAGS_LEN 4
+#define MC_CMD_PLUGIN_GET_ALL_IN_FLAG_INCLUDE_ENABLED_OFST 0
+#define MC_CMD_PLUGIN_GET_ALL_IN_FLAG_INCLUDE_ENABLED_LBN 0
+#define MC_CMD_PLUGIN_GET_ALL_IN_FLAG_INCLUDE_ENABLED_WIDTH 1
+#define MC_CMD_PLUGIN_GET_ALL_IN_FLAG_INCLUDE_DISABLED_OFST 0
+#define MC_CMD_PLUGIN_GET_ALL_IN_FLAG_INCLUDE_DISABLED_LBN 1
+#define MC_CMD_PLUGIN_GET_ALL_IN_FLAG_INCLUDE_DISABLED_WIDTH 1
+
+/* MC_CMD_PLUGIN_GET_ALL_OUT msgresponse */
+#define MC_CMD_PLUGIN_GET_ALL_OUT_LENMIN 0
+#define MC_CMD_PLUGIN_GET_ALL_OUT_LENMAX 240
+#define MC_CMD_PLUGIN_GET_ALL_OUT_LENMAX_MCDI2 1020
+#define MC_CMD_PLUGIN_GET_ALL_OUT_LEN(num) (0+20*(num))
+#define MC_CMD_PLUGIN_GET_ALL_OUT_EXTENSIONS_NUM(len) (((len)-0)/20)
+/* The list of available plugin extensions, as an array of PLUGIN_EXTENSION
+ * structs.
+ */
+#define MC_CMD_PLUGIN_GET_ALL_OUT_EXTENSIONS_OFST 0
+#define MC_CMD_PLUGIN_GET_ALL_OUT_EXTENSIONS_LEN 20
+#define MC_CMD_PLUGIN_GET_ALL_OUT_EXTENSIONS_MINNUM 0
+#define MC_CMD_PLUGIN_GET_ALL_OUT_EXTENSIONS_MAXNUM 12
+#define MC_CMD_PLUGIN_GET_ALL_OUT_EXTENSIONS_MAXNUM_MCDI2 51
+
+
+/***********************************/
+/* MC_CMD_PLUGIN_REQ
+ * Send a command to a plugin. A plugin may define an arbitrary number of
+ * 'messages' which it allows applications on the host system to send, each
+ * identified by a 32-bit ID.
+ */
+#define MC_CMD_PLUGIN_REQ 0x1b3
+#define MC_CMD_PLUGIN_REQ_MSGSET 0x1b3
+#undef MC_CMD_0x1b3_PRIVILEGE_CTG
+
+#define MC_CMD_0x1b3_PRIVILEGE_CTG SRIOV_CTG_GENERAL
+
+/* MC_CMD_PLUGIN_REQ_IN msgrequest */
+#define MC_CMD_PLUGIN_REQ_IN_LENMIN 8
+#define MC_CMD_PLUGIN_REQ_IN_LENMAX 252
+#define MC_CMD_PLUGIN_REQ_IN_LENMAX_MCDI2 1020
+#define MC_CMD_PLUGIN_REQ_IN_LEN(num) (8+1*(num))
+#define MC_CMD_PLUGIN_REQ_IN_DATA_NUM(len) (((len)-8)/1)
+/* Handle returned by MC_CMD_PLUGIN_ALLOC_OUT */
+#define MC_CMD_PLUGIN_REQ_IN_HANDLE_OFST 0
+#define MC_CMD_PLUGIN_REQ_IN_HANDLE_LEN 4
+/* Message ID defined by the plugin author */
+#define MC_CMD_PLUGIN_REQ_IN_ID_OFST 4
+#define MC_CMD_PLUGIN_REQ_IN_ID_LEN 4
+/* Data blob being the parameter to the message. This must be of the length
+ * specified by MC_CMD_PLUGIN_GET_META_MSG_IN_MCDI_PARAM_SIZE.
+ */
+#define MC_CMD_PLUGIN_REQ_IN_DATA_OFST 8
+#define MC_CMD_PLUGIN_REQ_IN_DATA_LEN 1
+#define MC_CMD_PLUGIN_REQ_IN_DATA_MINNUM 0
+#define MC_CMD_PLUGIN_REQ_IN_DATA_MAXNUM 244
+#define MC_CMD_PLUGIN_REQ_IN_DATA_MAXNUM_MCDI2 1012
+
+/* MC_CMD_PLUGIN_REQ_OUT msgresponse */
+#define MC_CMD_PLUGIN_REQ_OUT_LENMIN 0
+#define MC_CMD_PLUGIN_REQ_OUT_LENMAX 252
+#define MC_CMD_PLUGIN_REQ_OUT_LENMAX_MCDI2 1020
+#define MC_CMD_PLUGIN_REQ_OUT_LEN(num) (0+1*(num))
+#define MC_CMD_PLUGIN_REQ_OUT_DATA_NUM(len) (((len)-0)/1)
+/* The input data, as transformed and/or updated by the plugin's eBPF. Will be
+ * the same size as the input DATA parameter.
+ */
+#define MC_CMD_PLUGIN_REQ_OUT_DATA_OFST 0
+#define MC_CMD_PLUGIN_REQ_OUT_DATA_LEN 1
+#define MC_CMD_PLUGIN_REQ_OUT_DATA_MINNUM 0
+#define MC_CMD_PLUGIN_REQ_OUT_DATA_MAXNUM 252
+#define MC_CMD_PLUGIN_REQ_OUT_DATA_MAXNUM_MCDI2 1020
+
/* DESC_ADDR_REGION structuredef: Describes a contiguous region of DESC_ADDR
* space that maps to a contiguous region of TRGT_ADDR space. Addresses
* DESC_ADDR in the range [DESC_ADDR_BASE:DESC_ADDR_BASE + 1 <<
@@ -27219,6 +27925,38 @@
#define MC_CMD_VIRTIO_TEST_FEATURES_OUT_LEN 0
+/***********************************/
+/* MC_CMD_VIRTIO_GET_CAPABILITIES
+ * Get virtio capabilities supported by the device. Returns general virtio
+ * capabilities and limitations of the hardware / firmware implementation
+ * (hardware device as a whole), rather than that of individual configured
+ * virtio devices. At present, only the absolute maximum number of queues
+ * allowed on multi-queue devices is returned. Response is expected to be
+ * extended as necessary in the future.
+ */
+#define MC_CMD_VIRTIO_GET_CAPABILITIES 0x1d3
+#define MC_CMD_VIRTIO_GET_CAPABILITIES_MSGSET 0x1d3
+#undef MC_CMD_0x1d3_PRIVILEGE_CTG
+
+#define MC_CMD_0x1d3_PRIVILEGE_CTG SRIOV_CTG_GENERAL
+
+/* MC_CMD_VIRTIO_GET_CAPABILITIES_IN msgrequest */
+#define MC_CMD_VIRTIO_GET_CAPABILITIES_IN_LEN 4
+/* Type of device to get capabilities for. Matches the device id as defined by
+ * the virtio spec.
+ */
+#define MC_CMD_VIRTIO_GET_CAPABILITIES_IN_DEVICE_ID_OFST 0
+#define MC_CMD_VIRTIO_GET_CAPABILITIES_IN_DEVICE_ID_LEN 4
+/* Enum values, see field(s): */
+/* MC_CMD_VIRTIO_GET_FEATURES/MC_CMD_VIRTIO_GET_FEATURES_IN/DEVICE_ID */
+
+/* MC_CMD_VIRTIO_GET_CAPABILITIES_OUT msgresponse */
+#define MC_CMD_VIRTIO_GET_CAPABILITIES_OUT_LEN 4
+/* Maximum number of queues supported for a single device instance */
+#define MC_CMD_VIRTIO_GET_CAPABILITIES_OUT_MAX_QUEUES_OFST 0
+#define MC_CMD_VIRTIO_GET_CAPABILITIES_OUT_MAX_QUEUES_LEN 4
+
+
/***********************************/
/* MC_CMD_VIRTIO_INIT_QUEUE
* Create a virtio virtqueue. Fails with EALREADY if the queue already exists.
@@ -27490,6 +28228,24 @@
#define PCIE_FUNCTION_INTF_LBN 32
#define PCIE_FUNCTION_INTF_WIDTH 32
+/* QUEUE_ID structuredef: Structure representing an absolute queue identifier
+ * (absolute VI number + VI relative queue number). On Keystone, a VI can
+ * contain multiple queues (at present, up to 2), each with separate controls
+ * for direction. This structure is required to uniquely identify the absolute
+ * source queue for descriptor proxy functions.
+ */
+#define QUEUE_ID_LEN 4
+/* Absolute VI number */
+#define QUEUE_ID_ABS_VI_OFST 0
+#define QUEUE_ID_ABS_VI_LEN 2
+#define QUEUE_ID_ABS_VI_LBN 0
+#define QUEUE_ID_ABS_VI_WIDTH 16
+/* Relative queue number within the VI */
+#define QUEUE_ID_REL_QUEUE_LBN 16
+#define QUEUE_ID_REL_QUEUE_WIDTH 1
+#define QUEUE_ID_RESERVED_LBN 17
+#define QUEUE_ID_RESERVED_WIDTH 15
+
/***********************************/
/* MC_CMD_DESC_PROXY_FUNC_CREATE
@@ -28088,7 +28844,11 @@
* Enable descriptor proxying for function into target event queue. Returns VI
* allocation info for the proxy source function, so that the caller can map
* absolute VI IDs from descriptor proxy events back to the originating
- * function.
+ * function. This is a legacy function that only supports single queue proxy
+ * devices. It is also limited in that it can only be called after host driver
+ * attach (once VI allocation is known) and will return MC_CMD_ERR_ENOTCONN
+ * otherwise. For new code, see MC_CMD_DESC_PROXY_FUNC_ENABLE_QUEUE which
+ * supports multi-queue devices and has no dependency on host driver attach.
*/
#define MC_CMD_DESC_PROXY_FUNC_ENABLE 0x178
#define MC_CMD_DESC_PROXY_FUNC_ENABLE_MSGSET 0x178
@@ -28119,9 +28879,46 @@
#define MC_CMD_DESC_PROXY_FUNC_ENABLE_OUT_VI_BASE_LEN 4
+/***********************************/
+/* MC_CMD_DESC_PROXY_FUNC_ENABLE_QUEUE
+ * Enable descriptor proxying for a source queue on a host function into target
+ * event queue. Source queue number is a relative virtqueue number on the
+ * source function (0 to max_virtqueues-1). For a multi-queue device, the
+ * caller must enable all source queues individually. To retrieve absolute VI
+ * information for the source function (so that VI IDs from descriptor proxy
+ * events can be mapped back to source function / queue) see
+ * MC_CMD_DESC_PROXY_FUNC_GET_VI_INFO
+ */
+#define MC_CMD_DESC_PROXY_FUNC_ENABLE_QUEUE 0x1d0
+#define MC_CMD_DESC_PROXY_FUNC_ENABLE_QUEUE_MSGSET 0x1d0
+#undef MC_CMD_0x1d0_PRIVILEGE_CTG
+
+#define MC_CMD_0x1d0_PRIVILEGE_CTG SRIOV_CTG_ADMIN
+
+/* MC_CMD_DESC_PROXY_FUNC_ENABLE_QUEUE_IN msgrequest */
+#define MC_CMD_DESC_PROXY_FUNC_ENABLE_QUEUE_IN_LEN 12
+/* Handle to descriptor proxy function (as returned by
+ * MC_CMD_DESC_PROXY_FUNC_OPEN)
+ */
+#define MC_CMD_DESC_PROXY_FUNC_ENABLE_QUEUE_IN_HANDLE_OFST 0
+#define MC_CMD_DESC_PROXY_FUNC_ENABLE_QUEUE_IN_HANDLE_LEN 4
+/* Source relative queue number to enable proxying on */
+#define MC_CMD_DESC_PROXY_FUNC_ENABLE_QUEUE_IN_SOURCE_QUEUE_OFST 4
+#define MC_CMD_DESC_PROXY_FUNC_ENABLE_QUEUE_IN_SOURCE_QUEUE_LEN 4
+/* Descriptor proxy sink queue (caller function relative). Must be extended
+ * width event queue
+ */
+#define MC_CMD_DESC_PROXY_FUNC_ENABLE_QUEUE_IN_TARGET_EVQ_OFST 8
+#define MC_CMD_DESC_PROXY_FUNC_ENABLE_QUEUE_IN_TARGET_EVQ_LEN 4
+
+/* MC_CMD_DESC_PROXY_FUNC_ENABLE_QUEUE_OUT msgresponse */
+#define MC_CMD_DESC_PROXY_FUNC_ENABLE_QUEUE_OUT_LEN 0
+
+
/***********************************/
/* MC_CMD_DESC_PROXY_FUNC_DISABLE
- * Disable descriptor proxying for function
+ * Disable descriptor proxying for function. For multi-queue functions,
+ * disables all queues.
*/
#define MC_CMD_DESC_PROXY_FUNC_DISABLE 0x179
#define MC_CMD_DESC_PROXY_FUNC_DISABLE_MSGSET 0x179
@@ -28141,6 +28938,77 @@
#define MC_CMD_DESC_PROXY_FUNC_DISABLE_OUT_LEN 0
+/***********************************/
+/* MC_CMD_DESC_PROXY_FUNC_DISABLE_QUEUE
+ * Disable descriptor proxying for a specific source queue on a function.
+ */
+#define MC_CMD_DESC_PROXY_FUNC_DISABLE_QUEUE 0x1d1
+#define MC_CMD_DESC_PROXY_FUNC_DISABLE_QUEUE_MSGSET 0x1d1
+#undef MC_CMD_0x1d1_PRIVILEGE_CTG
+
+#define MC_CMD_0x1d1_PRIVILEGE_CTG SRIOV_CTG_ADMIN
+
+/* MC_CMD_DESC_PROXY_FUNC_DISABLE_QUEUE_IN msgrequest */
+#define MC_CMD_DESC_PROXY_FUNC_DISABLE_QUEUE_IN_LEN 8
+/* Handle to descriptor proxy function (as returned by
+ * MC_CMD_DESC_PROXY_FUNC_OPEN)
+ */
+#define MC_CMD_DESC_PROXY_FUNC_DISABLE_QUEUE_IN_HANDLE_OFST 0
+#define MC_CMD_DESC_PROXY_FUNC_DISABLE_QUEUE_IN_HANDLE_LEN 4
+/* Source relative queue number to disable proxying on */
+#define MC_CMD_DESC_PROXY_FUNC_DISABLE_QUEUE_IN_SOURCE_QUEUE_OFST 4
+#define MC_CMD_DESC_PROXY_FUNC_DISABLE_QUEUE_IN_SOURCE_QUEUE_LEN 4
+
+/* MC_CMD_DESC_PROXY_FUNC_DISABLE_QUEUE_OUT msgresponse */
+#define MC_CMD_DESC_PROXY_FUNC_DISABLE_QUEUE_OUT_LEN 0
+
+
+/***********************************/
+/* MC_CMD_DESC_PROXY_GET_VI_INFO
+ * Returns absolute VI allocation information for the descriptor proxy source
+ * function referenced by HANDLE, so that the caller can map absolute VI IDs
+ * from descriptor proxy events back to the originating function and queue. The
+ * call is only valid after the host driver for the source function has
+ * attached (after receiving a driver attach event for the descriptor proxy
+ * function) and will fail with ENOTCONN otherwise.
+ */
+#define MC_CMD_DESC_PROXY_GET_VI_INFO 0x1d2
+#define MC_CMD_DESC_PROXY_GET_VI_INFO_MSGSET 0x1d2
+#undef MC_CMD_0x1d2_PRIVILEGE_CTG
+
+#define MC_CMD_0x1d2_PRIVILEGE_CTG SRIOV_CTG_ADMIN
+
+/* MC_CMD_DESC_PROXY_GET_VI_INFO_IN msgrequest */
+#define MC_CMD_DESC_PROXY_GET_VI_INFO_IN_LEN 4
+/* Handle to descriptor proxy function (as returned by
+ * MC_CMD_DESC_PROXY_FUNC_OPEN)
+ */
+#define MC_CMD_DESC_PROXY_GET_VI_INFO_IN_HANDLE_OFST 0
+#define MC_CMD_DESC_PROXY_GET_VI_INFO_IN_HANDLE_LEN 4
+
+/* MC_CMD_DESC_PROXY_FUNC_GET_VI_INFO_OUT msgresponse */
+#define MC_CMD_DESC_PROXY_FUNC_GET_VI_INFO_OUT_LENMIN 0
+#define MC_CMD_DESC_PROXY_FUNC_GET_VI_INFO_OUT_LENMAX 252
+#define MC_CMD_DESC_PROXY_FUNC_GET_VI_INFO_OUT_LENMAX_MCDI2 1020
+#define MC_CMD_DESC_PROXY_FUNC_GET_VI_INFO_OUT_LEN(num) (0+4*(num))
+#define MC_CMD_DESC_PROXY_FUNC_GET_VI_INFO_OUT_VI_MAP_NUM(len) (((len)-0)/4)
+/* VI information (VI ID + VI relative queue number) for each of the source
+ * queues (in order from 0 to max_virtqueues-1), as array of QUEUE_ID
+ * structures.
+ */
+#define MC_CMD_DESC_PROXY_FUNC_GET_VI_INFO_OUT_VI_MAP_OFST 0
+#define MC_CMD_DESC_PROXY_FUNC_GET_VI_INFO_OUT_VI_MAP_LEN 4
+#define MC_CMD_DESC_PROXY_FUNC_GET_VI_INFO_OUT_VI_MAP_MINNUM 0
+#define MC_CMD_DESC_PROXY_FUNC_GET_VI_INFO_OUT_VI_MAP_MAXNUM 63
+#define MC_CMD_DESC_PROXY_FUNC_GET_VI_INFO_OUT_VI_MAP_MAXNUM_MCDI2 255
+#define MC_CMD_DESC_PROXY_FUNC_GET_VI_INFO_OUT_VI_MAP_ABS_VI_OFST 0
+#define MC_CMD_DESC_PROXY_FUNC_GET_VI_INFO_OUT_VI_MAP_ABS_VI_LEN 2
+#define MC_CMD_DESC_PROXY_FUNC_GET_VI_INFO_OUT_VI_MAP_REL_QUEUE_LBN 16
+#define MC_CMD_DESC_PROXY_FUNC_GET_VI_INFO_OUT_VI_MAP_REL_QUEUE_WIDTH 1
+#define MC_CMD_DESC_PROXY_FUNC_GET_VI_INFO_OUT_VI_MAP_RESERVED_LBN 17
+#define MC_CMD_DESC_PROXY_FUNC_GET_VI_INFO_OUT_VI_MAP_RESERVED_WIDTH 15
+
+
/***********************************/
/* MC_CMD_GET_ADDR_SPC_ID
* Get Address space identifier for use in mem2mem descriptors for a given
@@ -29384,9 +30252,12 @@
#define MC_CMD_MAE_GET_CAPS_OUT_ENCAP_TYPE_L2GRE_OFST 4
#define MC_CMD_MAE_GET_CAPS_OUT_ENCAP_TYPE_L2GRE_LBN 3
#define MC_CMD_MAE_GET_CAPS_OUT_ENCAP_TYPE_L2GRE_WIDTH 1
-/* The total number of counters available to allocate. */
+/* Deprecated alias for AR_COUNTERS. */
#define MC_CMD_MAE_GET_CAPS_OUT_COUNTERS_OFST 8
#define MC_CMD_MAE_GET_CAPS_OUT_COUNTERS_LEN 4
+/* The total number of AR counters available to allocate. */
+#define MC_CMD_MAE_GET_CAPS_OUT_AR_COUNTERS_OFST 8
+#define MC_CMD_MAE_GET_CAPS_OUT_AR_COUNTERS_LEN 4
/* The total number of counters lists available to allocate. A value of zero
* indicates that counter lists are not supported by the NIC. (But single
* counters may still be.)
@@ -29429,6 +30300,87 @@
#define MC_CMD_MAE_GET_CAPS_OUT_API_VER_OFST 48
#define MC_CMD_MAE_GET_CAPS_OUT_API_VER_LEN 4
+/* MC_CMD_MAE_GET_CAPS_V2_OUT msgresponse */
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_LEN 60
+/* The number of field IDs that the NIC supports. Any field with a ID greater
+ * than or equal to the value returned in this field must be treated as having
+ * a support level of MAE_FIELD_UNSUPPORTED in all requests.
+ */
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_MATCH_FIELD_COUNT_OFST 0
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_MATCH_FIELD_COUNT_LEN 4
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_ENCAP_TYPES_SUPPORTED_OFST 4
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_ENCAP_TYPES_SUPPORTED_LEN 4
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_ENCAP_TYPE_VXLAN_OFST 4
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_ENCAP_TYPE_VXLAN_LBN 0
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_ENCAP_TYPE_VXLAN_WIDTH 1
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_ENCAP_TYPE_NVGRE_OFST 4
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_ENCAP_TYPE_NVGRE_LBN 1
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_ENCAP_TYPE_NVGRE_WIDTH 1
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_ENCAP_TYPE_GENEVE_OFST 4
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_ENCAP_TYPE_GENEVE_LBN 2
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_ENCAP_TYPE_GENEVE_WIDTH 1
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_ENCAP_TYPE_L2GRE_OFST 4
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_ENCAP_TYPE_L2GRE_LBN 3
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_ENCAP_TYPE_L2GRE_WIDTH 1
+/* Deprecated alias for AR_COUNTERS. */
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_COUNTERS_OFST 8
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_COUNTERS_LEN 4
+/* The total number of AR counters available to allocate. */
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_AR_COUNTERS_OFST 8
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_AR_COUNTERS_LEN 4
+/* The total number of counters lists available to allocate. A value of zero
+ * indicates that counter lists are not supported by the NIC. (But single
+ * counters may still be.)
+ */
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_COUNTER_LISTS_OFST 12
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_COUNTER_LISTS_LEN 4
+/* The total number of encap header structures available to allocate. */
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_ENCAP_HEADER_LIMIT_OFST 16
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_ENCAP_HEADER_LIMIT_LEN 4
+/* Reserved. Should be zero. */
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_RSVD_OFST 20
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_RSVD_LEN 4
+/* The total number of action sets available to allocate. */
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_ACTION_SETS_OFST 24
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_ACTION_SETS_LEN 4
+/* The total number of action set lists available to allocate. */
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_ACTION_SET_LISTS_OFST 28
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_ACTION_SET_LISTS_LEN 4
+/* The total number of outer rules available to allocate. */
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_OUTER_RULES_OFST 32
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_OUTER_RULES_LEN 4
+/* The total number of action rules available to allocate. */
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_ACTION_RULES_OFST 36
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_ACTION_RULES_LEN 4
+/* The number of priorities available for ACTION_RULE filters. It is invalid to
+ * install a MATCH_ACTION filter with a priority number >= ACTION_PRIOS.
+ */
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_ACTION_PRIOS_OFST 40
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_ACTION_PRIOS_LEN 4
+/* The number of priorities available for OUTER_RULE filters. It is invalid to
+ * install an OUTER_RULE filter with a priority number >= OUTER_PRIOS.
+ */
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_OUTER_PRIOS_OFST 44
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_OUTER_PRIOS_LEN 4
+/* MAE API major version. Currently 1. If this field is not present in the
+ * response (i.e. response shorter than 384 bits), then its value is zero. If
+ * the value does not match the client's expectations, the client should raise
+ * a fatal error.
+ */
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_API_VER_OFST 48
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_API_VER_LEN 4
+/* Mask of supported counter types. Each bit position corresponds to a value of
+ * the MAE_COUNTER_TYPE enum. If this field is missing (i.e. V1 response),
+ * clients must assume that only AR counters are supported (i.e.
+ * COUNTER_TYPES_SUPPORTED==0x1). See also
+ * MC_CMD_MAE_COUNTERS_STREAM_START/COUNTER_TYPES_MASK.
+ */
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_COUNTER_TYPES_SUPPORTED_OFST 52
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_COUNTER_TYPES_SUPPORTED_LEN 4
+/* The total number of conntrack counters available to allocate. */
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_CT_COUNTERS_OFST 56
+#define MC_CMD_MAE_GET_CAPS_V2_OUT_CT_COUNTERS_LEN 4
+
/***********************************/
/* MC_CMD_MAE_GET_AR_CAPS
@@ -29495,8 +30447,8 @@
/***********************************/
/* MC_CMD_MAE_COUNTER_ALLOC
- * Allocate match-action-engine counters, which can be referenced in Action
- * Rules.
+ * Allocate match-action-engine counters, which can be referenced in various
+ * tables.
*/
#define MC_CMD_MAE_COUNTER_ALLOC 0x143
#define MC_CMD_MAE_COUNTER_ALLOC_MSGSET 0x143
@@ -29504,12 +30456,25 @@
#define MC_CMD_0x143_PRIVILEGE_CTG SRIOV_CTG_MAE
-/* MC_CMD_MAE_COUNTER_ALLOC_IN msgrequest */
+/* MC_CMD_MAE_COUNTER_ALLOC_IN msgrequest: Using this is equivalent to using V2
+ * with COUNTER_TYPE=AR.
+ */
#define MC_CMD_MAE_COUNTER_ALLOC_IN_LEN 4
/* The number of counters that the driver would like allocated */
#define MC_CMD_MAE_COUNTER_ALLOC_IN_REQUESTED_COUNT_OFST 0
#define MC_CMD_MAE_COUNTER_ALLOC_IN_REQUESTED_COUNT_LEN 4
+/* MC_CMD_MAE_COUNTER_ALLOC_V2_IN msgrequest */
+#define MC_CMD_MAE_COUNTER_ALLOC_V2_IN_LEN 8
+/* The number of counters that the driver would like allocated */
+#define MC_CMD_MAE_COUNTER_ALLOC_V2_IN_REQUESTED_COUNT_OFST 0
+#define MC_CMD_MAE_COUNTER_ALLOC_V2_IN_REQUESTED_COUNT_LEN 4
+/* Which type of counter to allocate. */
+#define MC_CMD_MAE_COUNTER_ALLOC_V2_IN_COUNTER_TYPE_OFST 4
+#define MC_CMD_MAE_COUNTER_ALLOC_V2_IN_COUNTER_TYPE_LEN 4
+/* Enum values, see field(s): */
+/* MAE_COUNTER_TYPE */
+
/* MC_CMD_MAE_COUNTER_ALLOC_OUT msgresponse */
#define MC_CMD_MAE_COUNTER_ALLOC_OUT_LENMIN 12
#define MC_CMD_MAE_COUNTER_ALLOC_OUT_LENMAX 252
@@ -29518,7 +30483,8 @@
#define MC_CMD_MAE_COUNTER_ALLOC_OUT_COUNTER_ID_NUM(len) (((len)-8)/4)
/* Generation count. Packets with generation count >= GENERATION_COUNT will
* contain valid counter values for counter IDs allocated in this call, unless
- * the counter values are zero and zero squash is enabled.
+ * the counter values are zero and zero squash is enabled. Note that there is
+ * an independent GENERATION_COUNT object per counter type.
*/
#define MC_CMD_MAE_COUNTER_ALLOC_OUT_GENERATION_COUNT_OFST 0
#define MC_CMD_MAE_COUNTER_ALLOC_OUT_GENERATION_COUNT_LEN 4
@@ -29548,7 +30514,9 @@
#define MC_CMD_0x144_PRIVILEGE_CTG SRIOV_CTG_MAE
-/* MC_CMD_MAE_COUNTER_FREE_IN msgrequest */
+/* MC_CMD_MAE_COUNTER_FREE_IN msgrequest: Using this is equivalent to using V2
+ * with COUNTER_TYPE=AR.
+ */
#define MC_CMD_MAE_COUNTER_FREE_IN_LENMIN 8
#define MC_CMD_MAE_COUNTER_FREE_IN_LENMAX 132
#define MC_CMD_MAE_COUNTER_FREE_IN_LENMAX_MCDI2 132
@@ -29564,6 +30532,23 @@
#define MC_CMD_MAE_COUNTER_FREE_IN_FREE_COUNTER_ID_MAXNUM 32
#define MC_CMD_MAE_COUNTER_FREE_IN_FREE_COUNTER_ID_MAXNUM_MCDI2 32
+/* MC_CMD_MAE_COUNTER_FREE_V2_IN msgrequest */
+#define MC_CMD_MAE_COUNTER_FREE_V2_IN_LEN 136
+/* The number of counter IDs to be freed. */
+#define MC_CMD_MAE_COUNTER_FREE_V2_IN_COUNTER_ID_COUNT_OFST 0
+#define MC_CMD_MAE_COUNTER_FREE_V2_IN_COUNTER_ID_COUNT_LEN 4
+/* An array containing the counter IDs to be freed. */
+#define MC_CMD_MAE_COUNTER_FREE_V2_IN_FREE_COUNTER_ID_OFST 4
+#define MC_CMD_MAE_COUNTER_FREE_V2_IN_FREE_COUNTER_ID_LEN 4
+#define MC_CMD_MAE_COUNTER_FREE_V2_IN_FREE_COUNTER_ID_MINNUM 1
+#define MC_CMD_MAE_COUNTER_FREE_V2_IN_FREE_COUNTER_ID_MAXNUM 32
+#define MC_CMD_MAE_COUNTER_FREE_V2_IN_FREE_COUNTER_ID_MAXNUM_MCDI2 32
+/* Which type of counter to free. */
+#define MC_CMD_MAE_COUNTER_FREE_V2_IN_COUNTER_TYPE_OFST 132
+#define MC_CMD_MAE_COUNTER_FREE_V2_IN_COUNTER_TYPE_LEN 4
+/* Enum values, see field(s): */
+/* MAE_COUNTER_TYPE */
+
/* MC_CMD_MAE_COUNTER_FREE_OUT msgresponse */
#define MC_CMD_MAE_COUNTER_FREE_OUT_LENMIN 12
#define MC_CMD_MAE_COUNTER_FREE_OUT_LENMAX 136
@@ -29572,11 +30557,13 @@
#define MC_CMD_MAE_COUNTER_FREE_OUT_FREED_COUNTER_ID_NUM(len) (((len)-8)/4)
/* Generation count. A packet with generation count == GENERATION_COUNT will
* contain the final values for these counter IDs, unless the counter values
- * are zero and zero squash is enabled. Receiving a packet with generation
- * count > GENERATION_COUNT guarantees that no more values will be written for
- * these counters. If values for these counter IDs are present, the counter ID
- * has been reallocated. A counter ID will not be reallocated within a single
- * read cycle as this would merge increments from the 'old' and 'new' counters.
+ * are zero and zero squash is enabled. Note that the GENERATION_COUNT value is
+ * specific to the COUNTER_TYPE (IDENTIFIER field in packet header). Receiving
+ * a packet with generation count > GENERATION_COUNT guarantees that no more
+ * values will be written for these counters. If values for these counter IDs
+ * are present, the counter ID has been reallocated. A counter ID will not be
+ * reallocated within a single read cycle as this would merge increments from
+ * the 'old' and 'new' counters.
*/
#define MC_CMD_MAE_COUNTER_FREE_OUT_GENERATION_COUNT_OFST 0
#define MC_CMD_MAE_COUNTER_FREE_OUT_GENERATION_COUNT_LEN 4
@@ -29616,7 +30603,9 @@
#define MC_CMD_0x151_PRIVILEGE_CTG SRIOV_CTG_MAE
-/* MC_CMD_MAE_COUNTERS_STREAM_START_IN msgrequest */
+/* MC_CMD_MAE_COUNTERS_STREAM_START_IN msgrequest: Using V1 is equivalent to V2
+ * with COUNTER_TYPES_MASK=0x1 (i.e. AR counters only).
+ */
#define MC_CMD_MAE_COUNTERS_STREAM_START_IN_LEN 8
/* The RxQ to write packets to. */
#define MC_CMD_MAE_COUNTERS_STREAM_START_IN_QID_OFST 0
@@ -29634,6 +30623,35 @@
#define MC_CMD_MAE_COUNTERS_STREAM_START_IN_COUNTER_STALL_EN_LBN 1
#define MC_CMD_MAE_COUNTERS_STREAM_START_IN_COUNTER_STALL_EN_WIDTH 1
+/* MC_CMD_MAE_COUNTERS_STREAM_START_V2_IN msgrequest */
+#define MC_CMD_MAE_COUNTERS_STREAM_START_V2_IN_LEN 12
+/* The RxQ to write packets to. */
+#define MC_CMD_MAE_COUNTERS_STREAM_START_V2_IN_QID_OFST 0
+#define MC_CMD_MAE_COUNTERS_STREAM_START_V2_IN_QID_LEN 2
+/* Maximum size in bytes of packets that may be written to the RxQ. */
+#define MC_CMD_MAE_COUNTERS_STREAM_START_V2_IN_PACKET_SIZE_OFST 2
+#define MC_CMD_MAE_COUNTERS_STREAM_START_V2_IN_PACKET_SIZE_LEN 2
+/* Optional flags. */
+#define MC_CMD_MAE_COUNTERS_STREAM_START_V2_IN_FLAGS_OFST 4
+#define MC_CMD_MAE_COUNTERS_STREAM_START_V2_IN_FLAGS_LEN 4
+#define MC_CMD_MAE_COUNTERS_STREAM_START_V2_IN_ZERO_SQUASH_DISABLE_OFST 4
+#define MC_CMD_MAE_COUNTERS_STREAM_START_V2_IN_ZERO_SQUASH_DISABLE_LBN 0
+#define MC_CMD_MAE_COUNTERS_STREAM_START_V2_IN_ZERO_SQUASH_DISABLE_WIDTH 1
+#define MC_CMD_MAE_COUNTERS_STREAM_START_V2_IN_COUNTER_STALL_EN_OFST 4
+#define MC_CMD_MAE_COUNTERS_STREAM_START_V2_IN_COUNTER_STALL_EN_LBN 1
+#define MC_CMD_MAE_COUNTERS_STREAM_START_V2_IN_COUNTER_STALL_EN_WIDTH 1
+/* Mask of which counter types should be reported. Each bit position
+ * corresponds to a value of the MAE_COUNTER_TYPE enum. For example a value of
+ * 0x3 requests both AR and CT counters. A value of zero is invalid. Counter
+ * types not selected by the mask value won't be included in the stream. If a
+ * client wishes to change which counter types are reported, it must first call
+ * MAE_COUNTERS_STREAM_STOP, then restart it with the new mask value.
+ * Requesting a counter type which isn't supported by firmware (reported in
+ * MC_CMD_MAE_GET_CAPS/COUNTER_TYPES_SUPPORTED) will result in ENOTSUP.
+ */
+#define MC_CMD_MAE_COUNTERS_STREAM_START_V2_IN_COUNTER_TYPES_MASK_OFST 8
+#define MC_CMD_MAE_COUNTERS_STREAM_START_V2_IN_COUNTER_TYPES_MASK_LEN 4
+
/* MC_CMD_MAE_COUNTERS_STREAM_START_OUT msgresponse */
#define MC_CMD_MAE_COUNTERS_STREAM_START_OUT_LEN 4
#define MC_CMD_MAE_COUNTERS_STREAM_START_OUT_FLAGS_OFST 0
@@ -29661,14 +30679,32 @@
/* MC_CMD_MAE_COUNTERS_STREAM_STOP_OUT msgresponse */
#define MC_CMD_MAE_COUNTERS_STREAM_STOP_OUT_LEN 4
-/* Generation count. The final set of counter values will be written out in
- * packets with count == GENERATION_COUNT. An empty packet with count >
- * GENERATION_COUNT indicates that no more counter values will be written to
- * this stream.
+/* Generation count for AR counters. The final set of AR counter values will be
+ * written out in packets with count == GENERATION_COUNT. An empty packet with
+ * count > GENERATION_COUNT indicates that no more counter values of this type
+ * will be written to this stream.
*/
#define MC_CMD_MAE_COUNTERS_STREAM_STOP_OUT_GENERATION_COUNT_OFST 0
#define MC_CMD_MAE_COUNTERS_STREAM_STOP_OUT_GENERATION_COUNT_LEN 4
+/* MC_CMD_MAE_COUNTERS_STREAM_STOP_V2_OUT msgresponse */
+#define MC_CMD_MAE_COUNTERS_STREAM_STOP_V2_OUT_LENMIN 4
+#define MC_CMD_MAE_COUNTERS_STREAM_STOP_V2_OUT_LENMAX 32
+#define MC_CMD_MAE_COUNTERS_STREAM_STOP_V2_OUT_LENMAX_MCDI2 32
+#define MC_CMD_MAE_COUNTERS_STREAM_STOP_V2_OUT_LEN(num) (0+4*(num))
+#define MC_CMD_MAE_COUNTERS_STREAM_STOP_V2_OUT_GENERATION_COUNT_NUM(len) (((len)-0)/4)
+/* Array of generation counts, indexed by MAE_COUNTER_TYPE. Note that since
+ * MAE_COUNTER_TYPE_AR==0, this response is backwards-compatible with V1. The
+ * final set of counter values will be written out in packets with count ==
+ * GENERATION_COUNT. An empty packet with count > GENERATION_COUNT indicates
+ * that no more counter values of this type will be written to this stream.
+ */
+#define MC_CMD_MAE_COUNTERS_STREAM_STOP_V2_OUT_GENERATION_COUNT_OFST 0
+#define MC_CMD_MAE_COUNTERS_STREAM_STOP_V2_OUT_GENERATION_COUNT_LEN 4
+#define MC_CMD_MAE_COUNTERS_STREAM_STOP_V2_OUT_GENERATION_COUNT_MINNUM 1
+#define MC_CMD_MAE_COUNTERS_STREAM_STOP_V2_OUT_GENERATION_COUNT_MAXNUM 8
+#define MC_CMD_MAE_COUNTERS_STREAM_STOP_V2_OUT_GENERATION_COUNT_MAXNUM_MCDI2 8
+
/***********************************/
/* MC_CMD_MAE_COUNTERS_STREAM_GIVE_CREDITS
@@ -29941,9 +30977,10 @@
#define MC_CMD_MAE_ACTION_SET_ALLOC_IN_COUNTER_LIST_ID_LEN 4
/* If a driver only wished to update one counter within this action set, then
* it can supply a COUNTER_ID instead of allocating a single-element counter
- * list. This field should be set to COUNTER_ID_NULL if this behaviour is not
- * required. It is not valid to supply a non-NULL value for both
- * COUNTER_LIST_ID and COUNTER_ID.
+ * list. The ID must have been allocated with COUNTER_TYPE=AR. This field
+ * should be set to COUNTER_ID_NULL if this behaviour is not required. It is
+ * not valid to supply a non-NULL value for both COUNTER_LIST_ID and
+ * COUNTER_ID.
*/
#define MC_CMD_MAE_ACTION_SET_ALLOC_IN_COUNTER_ID_OFST 28
#define MC_CMD_MAE_ACTION_SET_ALLOC_IN_COUNTER_ID_LEN 4
@@ -30021,9 +31058,10 @@
#define MC_CMD_MAE_ACTION_SET_ALLOC_V2_IN_COUNTER_LIST_ID_LEN 4
/* If a driver only wished to update one counter within this action set, then
* it can supply a COUNTER_ID instead of allocating a single-element counter
- * list. This field should be set to COUNTER_ID_NULL if this behaviour is not
- * required. It is not valid to supply a non-NULL value for both
- * COUNTER_LIST_ID and COUNTER_ID.
+ * list. The ID must have been allocated with COUNTER_TYPE=AR. This field
+ * should be set to COUNTER_ID_NULL if this behaviour is not required. It is
+ * not valid to supply a non-NULL value for both COUNTER_LIST_ID and
+ * COUNTER_ID.
*/
#define MC_CMD_MAE_ACTION_SET_ALLOC_V2_IN_COUNTER_ID_OFST 28
#define MC_CMD_MAE_ACTION_SET_ALLOC_V2_IN_COUNTER_ID_LEN 4
@@ -30352,7 +31390,8 @@
#define MAE_ACTION_RULE_RESPONSE_LOOKUP_CONTROL_LBN 64
#define MAE_ACTION_RULE_RESPONSE_LOOKUP_CONTROL_WIDTH 32
/* Counter ID to increment if DO_CT or DO_RECIRC is set. Must be set to
- * COUNTER_ID_NULL otherwise.
+ * COUNTER_ID_NULL otherwise. Counter ID must have been allocated with
+ * COUNTER_TYPE=AR.
*/
#define MAE_ACTION_RULE_RESPONSE_COUNTER_ID_OFST 12
#define MAE_ACTION_RULE_RESPONSE_COUNTER_ID_LEN 4
@@ -30710,6 +31749,108 @@
#define MAE_MPORT_DESC_VNIC_PLUGIN_TBD_LBN 352
#define MAE_MPORT_DESC_VNIC_PLUGIN_TBD_WIDTH 32
+/* MAE_MPORT_DESC_V2 structuredef */
+#define MAE_MPORT_DESC_V2_LEN 56
+#define MAE_MPORT_DESC_V2_MPORT_ID_OFST 0
+#define MAE_MPORT_DESC_V2_MPORT_ID_LEN 4
+#define MAE_MPORT_DESC_V2_MPORT_ID_LBN 0
+#define MAE_MPORT_DESC_V2_MPORT_ID_WIDTH 32
+/* Reserved for future purposes, contains information independent of caller */
+#define MAE_MPORT_DESC_V2_FLAGS_OFST 4
+#define MAE_MPORT_DESC_V2_FLAGS_LEN 4
+#define MAE_MPORT_DESC_V2_FLAGS_LBN 32
+#define MAE_MPORT_DESC_V2_FLAGS_WIDTH 32
+#define MAE_MPORT_DESC_V2_CALLER_FLAGS_OFST 8
+#define MAE_MPORT_DESC_V2_CALLER_FLAGS_LEN 4
+#define MAE_MPORT_DESC_V2_CAN_RECEIVE_ON_OFST 8
+#define MAE_MPORT_DESC_V2_CAN_RECEIVE_ON_LBN 0
+#define MAE_MPORT_DESC_V2_CAN_RECEIVE_ON_WIDTH 1
+#define MAE_MPORT_DESC_V2_CAN_DELIVER_TO_OFST 8
+#define MAE_MPORT_DESC_V2_CAN_DELIVER_TO_LBN 1
+#define MAE_MPORT_DESC_V2_CAN_DELIVER_TO_WIDTH 1
+#define MAE_MPORT_DESC_V2_CAN_DELETE_OFST 8
+#define MAE_MPORT_DESC_V2_CAN_DELETE_LBN 2
+#define MAE_MPORT_DESC_V2_CAN_DELETE_WIDTH 1
+#define MAE_MPORT_DESC_V2_IS_ZOMBIE_OFST 8
+#define MAE_MPORT_DESC_V2_IS_ZOMBIE_LBN 3
+#define MAE_MPORT_DESC_V2_IS_ZOMBIE_WIDTH 1
+#define MAE_MPORT_DESC_V2_CALLER_FLAGS_LBN 64
+#define MAE_MPORT_DESC_V2_CALLER_FLAGS_WIDTH 32
+/* Not the ideal name; it's really the type of thing connected to the m-port */
+#define MAE_MPORT_DESC_V2_MPORT_TYPE_OFST 12
+#define MAE_MPORT_DESC_V2_MPORT_TYPE_LEN 4
+/* enum: Connected to a MAC... */
+#define MAE_MPORT_DESC_V2_MPORT_TYPE_NET_PORT 0x0
+/* enum: Adds metadata and delivers to another m-port */
+#define MAE_MPORT_DESC_V2_MPORT_TYPE_ALIAS 0x1
+/* enum: Connected to a VNIC. */
+#define MAE_MPORT_DESC_V2_MPORT_TYPE_VNIC 0x2
+#define MAE_MPORT_DESC_V2_MPORT_TYPE_LBN 96
+#define MAE_MPORT_DESC_V2_MPORT_TYPE_WIDTH 32
+/* 128-bit value available to drivers for m-port identification. */
+#define MAE_MPORT_DESC_V2_UUID_OFST 16
+#define MAE_MPORT_DESC_V2_UUID_LEN 16
+#define MAE_MPORT_DESC_V2_UUID_LBN 128
+#define MAE_MPORT_DESC_V2_UUID_WIDTH 128
+/* Big wadge of space reserved for other common properties */
+#define MAE_MPORT_DESC_V2_RESERVED_OFST 32
+#define MAE_MPORT_DESC_V2_RESERVED_LEN 8
+#define MAE_MPORT_DESC_V2_RESERVED_LO_OFST 32
+#define MAE_MPORT_DESC_V2_RESERVED_LO_LEN 4
+#define MAE_MPORT_DESC_V2_RESERVED_LO_LBN 256
+#define MAE_MPORT_DESC_V2_RESERVED_LO_WIDTH 32
+#define MAE_MPORT_DESC_V2_RESERVED_HI_OFST 36
+#define MAE_MPORT_DESC_V2_RESERVED_HI_LEN 4
+#define MAE_MPORT_DESC_V2_RESERVED_HI_LBN 288
+#define MAE_MPORT_DESC_V2_RESERVED_HI_WIDTH 32
+#define MAE_MPORT_DESC_V2_RESERVED_LBN 256
+#define MAE_MPORT_DESC_V2_RESERVED_WIDTH 64
+/* Logical port index. Only valid when type NET Port. */
+#define MAE_MPORT_DESC_V2_NET_PORT_IDX_OFST 40
+#define MAE_MPORT_DESC_V2_NET_PORT_IDX_LEN 4
+#define MAE_MPORT_DESC_V2_NET_PORT_IDX_LBN 320
+#define MAE_MPORT_DESC_V2_NET_PORT_IDX_WIDTH 32
+/* The m-port delivered to */
+#define MAE_MPORT_DESC_V2_ALIAS_DELIVER_MPORT_ID_OFST 40
+#define MAE_MPORT_DESC_V2_ALIAS_DELIVER_MPORT_ID_LEN 4
+#define MAE_MPORT_DESC_V2_ALIAS_DELIVER_MPORT_ID_LBN 320
+#define MAE_MPORT_DESC_V2_ALIAS_DELIVER_MPORT_ID_WIDTH 32
+/* The type of thing that owns the VNIC */
+#define MAE_MPORT_DESC_V2_VNIC_CLIENT_TYPE_OFST 40
+#define MAE_MPORT_DESC_V2_VNIC_CLIENT_TYPE_LEN 4
+#define MAE_MPORT_DESC_V2_VNIC_CLIENT_TYPE_FUNCTION 0x1 /* enum */
+#define MAE_MPORT_DESC_V2_VNIC_CLIENT_TYPE_PLUGIN 0x2 /* enum */
+#define MAE_MPORT_DESC_V2_VNIC_CLIENT_TYPE_LBN 320
+#define MAE_MPORT_DESC_V2_VNIC_CLIENT_TYPE_WIDTH 32
+/* The PCIe interface on which the function lives. CJK: We need an enumeration
+ * of interfaces that we extend as new interface (types) appear. This belongs
+ * elsewhere and should be referenced from here
+ */
+#define MAE_MPORT_DESC_V2_VNIC_FUNCTION_INTERFACE_OFST 44
+#define MAE_MPORT_DESC_V2_VNIC_FUNCTION_INTERFACE_LEN 4
+#define MAE_MPORT_DESC_V2_VNIC_FUNCTION_INTERFACE_LBN 352
+#define MAE_MPORT_DESC_V2_VNIC_FUNCTION_INTERFACE_WIDTH 32
+#define MAE_MPORT_DESC_V2_VNIC_FUNCTION_PF_IDX_OFST 48
+#define MAE_MPORT_DESC_V2_VNIC_FUNCTION_PF_IDX_LEN 2
+#define MAE_MPORT_DESC_V2_VNIC_FUNCTION_PF_IDX_LBN 384
+#define MAE_MPORT_DESC_V2_VNIC_FUNCTION_PF_IDX_WIDTH 16
+#define MAE_MPORT_DESC_V2_VNIC_FUNCTION_VF_IDX_OFST 50
+#define MAE_MPORT_DESC_V2_VNIC_FUNCTION_VF_IDX_LEN 2
+/* enum: Indicates that the function is a PF */
+#define MAE_MPORT_DESC_V2_VF_IDX_NULL 0xffff
+#define MAE_MPORT_DESC_V2_VNIC_FUNCTION_VF_IDX_LBN 400
+#define MAE_MPORT_DESC_V2_VNIC_FUNCTION_VF_IDX_WIDTH 16
+/* Reserved. Should be ignored for now. */
+#define MAE_MPORT_DESC_V2_VNIC_PLUGIN_TBD_OFST 44
+#define MAE_MPORT_DESC_V2_VNIC_PLUGIN_TBD_LEN 4
+#define MAE_MPORT_DESC_V2_VNIC_PLUGIN_TBD_LBN 352
+#define MAE_MPORT_DESC_V2_VNIC_PLUGIN_TBD_WIDTH 32
+/* A client handle for the VNIC's owner. Only valid for type VNIC. */
+#define MAE_MPORT_DESC_V2_VNIC_CLIENT_HANDLE_OFST 52
+#define MAE_MPORT_DESC_V2_VNIC_CLIENT_HANDLE_LEN 4
+#define MAE_MPORT_DESC_V2_VNIC_CLIENT_HANDLE_LBN 416
+#define MAE_MPORT_DESC_V2_VNIC_CLIENT_HANDLE_WIDTH 32
+
/***********************************/
/* MC_CMD_MAE_MPORT_ENUMERATE
--
2.30.2
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [PATCH v2 3/5] cryptodev: move inline APIs into separate structure
2021-10-11 12:43 2% ` [dpdk-dev] [PATCH v2 3/5] cryptodev: move inline APIs into separate structure Akhil Goyal
@ 2021-10-11 14:45 0% ` Zhang, Roy Fan
0 siblings, 0 replies; 200+ results
From: Zhang, Roy Fan @ 2021-10-11 14:45 UTC (permalink / raw)
To: Akhil Goyal, dev
Cc: thomas, david.marchand, hemant.agrawal, anoobj, De Lara Guarch,
Pablo, Trahe, Fiona, Doherty, Declan, matan, g.singh,
jianjay.zhou, asomalap, ruifeng.wang, Ananyev, Konstantin,
Nicolau, Radu, ajit.khaparde, rnagadheeraj, adwivedi, Power,
Ciara
Hi Akhil,
> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Monday, October 11, 2021 1:43 PM
> To: dev@dpdk.org
> Cc: thomas@monjalon.net; david.marchand@redhat.com;
> hemant.agrawal@nxp.com; anoobj@marvell.com; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; Trahe, Fiona <fiona.trahe@intel.com>;
> Doherty, Declan <declan.doherty@intel.com>; matan@nvidia.com;
> g.singh@nxp.com; Zhang, Roy Fan <roy.fan.zhang@intel.com>;
> jianjay.zhou@huawei.com; asomalap@amd.com; ruifeng.wang@arm.com;
> Ananyev, Konstantin <konstantin.ananyev@intel.com>; Nicolau, Radu
> <radu.nicolau@intel.com>; ajit.khaparde@broadcom.com;
> rnagadheeraj@marvell.com; adwivedi@marvell.com; Power, Ciara
> <ciara.power@intel.com>; Akhil Goyal <gakhil@marvell.com>
> Subject: [PATCH v2 3/5] cryptodev: move inline APIs into separate structure
>
> Move fastpath inline function pointers from rte_cryptodev into a
> separate structure accessed via a flat array.
> The intension is to make rte_cryptodev and related structures private
> to avoid future API/ABI breakages.
>
> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> ---
> lib/cryptodev/cryptodev_pmd.c | 51
> ++++++++++++++++++++++++++++++
> lib/cryptodev/cryptodev_pmd.h | 11 +++++++
> lib/cryptodev/rte_cryptodev.c | 29 +++++++++++++++++
> lib/cryptodev/rte_cryptodev_core.h | 29 +++++++++++++++++
> lib/cryptodev/version.map | 5 +++
> 5 files changed, 125 insertions(+)
>
> diff --git a/lib/cryptodev/cryptodev_pmd.c
> b/lib/cryptodev/cryptodev_pmd.c
> index 44a70ecb35..4646708045 100644
> --- a/lib/cryptodev/cryptodev_pmd.c
> +++ b/lib/cryptodev/cryptodev_pmd.c
> @@ -4,6 +4,7 @@
>
> #include <sys/queue.h>
>
> +#include <rte_errno.h>
> #include <rte_string_fns.h>
> #include <rte_malloc.h>
>
> @@ -160,3 +161,53 @@ rte_cryptodev_pmd_destroy(struct rte_cryptodev
> *cryptodev)
>
When a device is removed - aka when rte_pci_remove() is called
cryptodev_fp_ops_reset() will never be called. This may expose a problem.
Looks like cryptodev_fp_ops_reset() needs to be called here too.
> return 0;
...
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v3] ci: update machine meson option to platform
@ 2021-10-11 13:40 4% ` Juraj Linkeš
2021-10-14 12:26 0% ` Aaron Conole
0 siblings, 1 reply; 200+ results
From: Juraj Linkeš @ 2021-10-11 13:40 UTC (permalink / raw)
To: thomas, david.marchand, aconole, maicolgabriel; +Cc: dev, Juraj Linkeš
The way we're building DPDK in CI, with -Dmachine=default, has not been
updated when the option got replaced to preserve a backwards-complatible
build call to facilitate ABI verification between DPDK versions. Update
the call to use -Dplatform=generic, which is the most up to date way to
execute the same build which is now present in all DPDK versions the ABI
check verifies.
Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
---
v3: ci retest
---
.ci/linux-build.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
index 91e43a975b..06aaa79100 100755
--- a/.ci/linux-build.sh
+++ b/.ci/linux-build.sh
@@ -77,7 +77,7 @@ else
OPTS="$OPTS -Dexamples=all"
fi
-OPTS="$OPTS -Dmachine=default"
+OPTS="$OPTS -Dplatform=generic"
OPTS="$OPTS --default-library=$DEF_LIB"
OPTS="$OPTS --buildtype=debugoptimized"
OPTS="$OPTS -Dcheck_includes=true"
--
2.20.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v8] ethdev: fix representor port ID search by name
` (2 preceding siblings ...)
2021-10-11 12:30 4% ` [dpdk-dev] [PATCH v7] " Andrew Rybchenko
@ 2021-10-11 12:53 4% ` Andrew Rybchenko
3 siblings, 0 replies; 200+ results
From: Andrew Rybchenko @ 2021-10-11 12:53 UTC (permalink / raw)
To: Ajit Khaparde, Somnath Kotur, John Daley, Hyong Youb Kim,
Beilei Xing, Qiming Yang, Qi Zhang, Haiyue Wang, Matan Azrad,
Viacheslav Ovsiienko, Thomas Monjalon, Ferruh Yigit
Cc: dev, Viacheslav Galaktionov, Xueming Li
From: Viacheslav Galaktionov <viacheslav.galaktionov@oktetlabs.ru>
The patch is required for all PMDs which do not provide representors
info on the representor itself.
The function, rte_eth_representor_id_get(), is used in
eth_representor_cmp() which is required in ethdev class iterator to
search ethdev port ID by name (representor case). Before the patch
the function is called on the representor itself and tries to get
representors info to match.
Search of port ID by name is used after hotplug to find out port ID
of the just plugged device.
Getting a list of representors from a representor does not make sense.
Instead, a backer device should be used.
To this end, extend the rte_eth_dev_data structure to include the port ID
of the backing device for representors.
Signed-off-by: Viacheslav Galaktionov <viacheslav.galaktionov@oktetlabs.ru>
Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Acked-by: Haiyue Wang <haiyue.wang@intel.com>
Acked-by: Beilei Xing <beilei.xing@intel.com>
Reviewed-by: Xueming Li <xuemingl@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
---
The new field is added into the hole in rte_eth_dev_data structure.
The patch does not change ABI, but extra care is required since ABI
check is disabled for the structure because of the libabigail bug [1].
It should not be a problem anyway since 21.11 is a ABI breaking release.
Potentially it is bad for out-of-tree drivers which implement
representors but do not fill in a new backer_port_id field in
rte_eth_dev_data structure. Get ID by name will not work.
mlx5 changes should be reviwed by maintainers very carefully, since
we are not sure if we patch it correctly.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=28060
v8:
- restore lost description improvements
v7:
- use dpdk_dev in net/mlx5 as suggested by Viacheslav O.
v6:
- provide more information in the changeset description
v5:
- try to improve name: backer_port_id instead of parent_port_id
- init new field to RTE_MAX_ETHPORTS on allocation to avoid
zero port usage by default
v4:
- apply mlx5 review notes: remove fallback from generic ethdev
code and add fallback to mlx5 code to handle legacy usecase
v3:
- fix mlx5 build breakage
v2:
- fix mlx5 review notes
- try device port ID first before parent in order to address
backward compatibility issue
drivers/net/bnxt/bnxt_reps.c | 1 +
drivers/net/enic/enic_vf_representor.c | 1 +
drivers/net/i40e/i40e_vf_representor.c | 1 +
drivers/net/ice/ice_dcf_vf_representor.c | 1 +
drivers/net/ixgbe/ixgbe_vf_representor.c | 1 +
drivers/net/mlx5/linux/mlx5_os.c | 13 +++++++++++++
drivers/net/mlx5/windows/mlx5_os.c | 13 +++++++++++++
lib/ethdev/ethdev_driver.h | 6 +++---
lib/ethdev/rte_class_eth.c | 2 +-
lib/ethdev/rte_ethdev.c | 9 +++++----
lib/ethdev/rte_ethdev_core.h | 6 ++++++
11 files changed, 46 insertions(+), 8 deletions(-)
diff --git a/drivers/net/bnxt/bnxt_reps.c b/drivers/net/bnxt/bnxt_reps.c
index df05619c3f..b7e88e013a 100644
--- a/drivers/net/bnxt/bnxt_reps.c
+++ b/drivers/net/bnxt/bnxt_reps.c
@@ -187,6 +187,7 @@ int bnxt_representor_init(struct rte_eth_dev *eth_dev, void *params)
eth_dev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR |
RTE_ETH_DEV_AUTOFILL_QUEUE_XSTATS;
eth_dev->data->representor_id = rep_params->vf_id;
+ eth_dev->data->backer_port_id = rep_params->parent_dev->data->port_id;
rte_eth_random_addr(vf_rep_bp->dflt_mac_addr);
memcpy(vf_rep_bp->mac_addr, vf_rep_bp->dflt_mac_addr,
diff --git a/drivers/net/enic/enic_vf_representor.c b/drivers/net/enic/enic_vf_representor.c
index cfd02c03cc..1a4411844a 100644
--- a/drivers/net/enic/enic_vf_representor.c
+++ b/drivers/net/enic/enic_vf_representor.c
@@ -666,6 +666,7 @@ int enic_vf_representor_init(struct rte_eth_dev *eth_dev, void *init_params)
eth_dev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR |
RTE_ETH_DEV_AUTOFILL_QUEUE_XSTATS;
eth_dev->data->representor_id = vf->vf_id;
+ eth_dev->data->backer_port_id = pf->port_id;
eth_dev->data->mac_addrs = rte_zmalloc("enic_mac_addr_vf",
sizeof(struct rte_ether_addr) *
ENIC_UNICAST_PERFECT_FILTERS, 0);
diff --git a/drivers/net/i40e/i40e_vf_representor.c b/drivers/net/i40e/i40e_vf_representor.c
index 0481b55381..d65b821a01 100644
--- a/drivers/net/i40e/i40e_vf_representor.c
+++ b/drivers/net/i40e/i40e_vf_representor.c
@@ -514,6 +514,7 @@ i40e_vf_representor_init(struct rte_eth_dev *ethdev, void *init_params)
ethdev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR |
RTE_ETH_DEV_AUTOFILL_QUEUE_XSTATS;
ethdev->data->representor_id = representor->vf_id;
+ ethdev->data->backer_port_id = pf->dev_data->port_id;
/* Setting the number queues allocated to the VF */
ethdev->data->nb_rx_queues = vf->vsi->nb_qps;
diff --git a/drivers/net/ice/ice_dcf_vf_representor.c b/drivers/net/ice/ice_dcf_vf_representor.c
index b547c42f91..c5335ac3cc 100644
--- a/drivers/net/ice/ice_dcf_vf_representor.c
+++ b/drivers/net/ice/ice_dcf_vf_representor.c
@@ -426,6 +426,7 @@ ice_dcf_vf_repr_init(struct rte_eth_dev *vf_rep_eth_dev, void *init_param)
vf_rep_eth_dev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR;
vf_rep_eth_dev->data->representor_id = repr->vf_id;
+ vf_rep_eth_dev->data->backer_port_id = repr->dcf_eth_dev->data->port_id;
vf_rep_eth_dev->data->mac_addrs = &repr->mac_addr;
diff --git a/drivers/net/ixgbe/ixgbe_vf_representor.c b/drivers/net/ixgbe/ixgbe_vf_representor.c
index d5b636a194..9fa75984fb 100644
--- a/drivers/net/ixgbe/ixgbe_vf_representor.c
+++ b/drivers/net/ixgbe/ixgbe_vf_representor.c
@@ -197,6 +197,7 @@ ixgbe_vf_representor_init(struct rte_eth_dev *ethdev, void *init_params)
ethdev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR;
ethdev->data->representor_id = representor->vf_id;
+ ethdev->data->backer_port_id = representor->pf_ethdev->data->port_id;
/* Set representor device ops */
ethdev->dev_ops = &ixgbe_vf_representor_dev_ops;
diff --git a/drivers/net/mlx5/linux/mlx5_os.c b/drivers/net/mlx5/linux/mlx5_os.c
index 3746057673..3858984f02 100644
--- a/drivers/net/mlx5/linux/mlx5_os.c
+++ b/drivers/net/mlx5/linux/mlx5_os.c
@@ -1677,6 +1677,19 @@ mlx5_dev_spawn(struct rte_device *dpdk_dev,
if (priv->representor) {
eth_dev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR;
eth_dev->data->representor_id = priv->representor_id;
+ MLX5_ETH_FOREACH_DEV(port_id, dpdk_dev) {
+ struct mlx5_priv *opriv =
+ rte_eth_devices[port_id].data->dev_private;
+ if (opriv &&
+ opriv->master &&
+ opriv->domain_id == priv->domain_id &&
+ opriv->sh == priv->sh) {
+ eth_dev->data->backer_port_id = port_id;
+ break;
+ }
+ }
+ if (port_id >= RTE_MAX_ETHPORTS)
+ eth_dev->data->backer_port_id = eth_dev->data->port_id;
}
priv->mp_id.port_id = eth_dev->data->port_id;
strlcpy(priv->mp_id.name, MLX5_MP_NAME, RTE_MP_MAX_NAME_LEN);
diff --git a/drivers/net/mlx5/windows/mlx5_os.c b/drivers/net/mlx5/windows/mlx5_os.c
index 26fa927039..9de8adecf4 100644
--- a/drivers/net/mlx5/windows/mlx5_os.c
+++ b/drivers/net/mlx5/windows/mlx5_os.c
@@ -543,6 +543,19 @@ mlx5_dev_spawn(struct rte_device *dpdk_dev,
if (priv->representor) {
eth_dev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR;
eth_dev->data->representor_id = priv->representor_id;
+ MLX5_ETH_FOREACH_DEV(port_id, dpdk_dev) {
+ struct mlx5_priv *opriv =
+ rte_eth_devices[port_id].data->dev_private;
+ if (opriv &&
+ opriv->master &&
+ opriv->domain_id == priv->domain_id &&
+ opriv->sh == priv->sh) {
+ eth_dev->data->backer_port_id = port_id;
+ break;
+ }
+ }
+ if (port_id >= RTE_MAX_ETHPORTS)
+ eth_dev->data->backer_port_id = eth_dev->data->port_id;
}
/*
* Store associated network device interface index. This index
diff --git a/lib/ethdev/ethdev_driver.h b/lib/ethdev/ethdev_driver.h
index 7ce0f7729a..c4ea735732 100644
--- a/lib/ethdev/ethdev_driver.h
+++ b/lib/ethdev/ethdev_driver.h
@@ -1266,8 +1266,8 @@ struct rte_eth_devargs {
* For backward compatibility, if no representor info, direct
* map legacy VF (no controller and pf).
*
- * @param ethdev
- * Handle of ethdev port.
+ * @param port_id
+ * Port ID of the backing device.
* @param type
* Representor type.
* @param controller
@@ -1284,7 +1284,7 @@ struct rte_eth_devargs {
*/
__rte_internal
int
-rte_eth_representor_id_get(const struct rte_eth_dev *ethdev,
+rte_eth_representor_id_get(uint16_t port_id,
enum rte_eth_representor_type type,
int controller, int pf, int representor_port,
uint16_t *repr_id);
diff --git a/lib/ethdev/rte_class_eth.c b/lib/ethdev/rte_class_eth.c
index 1fe5fa1f36..eda216ced5 100644
--- a/lib/ethdev/rte_class_eth.c
+++ b/lib/ethdev/rte_class_eth.c
@@ -95,7 +95,7 @@ eth_representor_cmp(const char *key __rte_unused,
c = i / (np * nf);
p = (i / nf) % np;
f = i % nf;
- if (rte_eth_representor_id_get(edev,
+ if (rte_eth_representor_id_get(edev->data->backer_port_id,
eth_da.type,
eth_da.nb_mh_controllers == 0 ? -1 :
eth_da.mh_controllers[c],
diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index 028907bc4b..ed7b43a99f 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -524,6 +524,7 @@ rte_eth_dev_allocate(const char *name)
eth_dev = eth_dev_get(port_id);
strlcpy(eth_dev->data->name, name, sizeof(eth_dev->data->name));
eth_dev->data->port_id = port_id;
+ eth_dev->data->backer_port_id = RTE_MAX_ETHPORTS;
eth_dev->data->mtu = RTE_ETHER_MTU;
pthread_mutex_init(ð_dev->data->flow_ops_mutex, NULL);
@@ -5915,7 +5916,7 @@ rte_eth_devargs_parse(const char *dargs, struct rte_eth_devargs *eth_da)
}
int
-rte_eth_representor_id_get(const struct rte_eth_dev *ethdev,
+rte_eth_representor_id_get(uint16_t port_id,
enum rte_eth_representor_type type,
int controller, int pf, int representor_port,
uint16_t *repr_id)
@@ -5931,7 +5932,7 @@ rte_eth_representor_id_get(const struct rte_eth_dev *ethdev,
return -EINVAL;
/* Get PMD representor range info. */
- ret = rte_eth_representor_info_get(ethdev->data->port_id, NULL);
+ ret = rte_eth_representor_info_get(port_id, NULL);
if (ret == -ENOTSUP && type == RTE_ETH_REPRESENTOR_VF &&
controller == -1 && pf == -1) {
/* Direct mapping for legacy VF representor. */
@@ -5946,7 +5947,7 @@ rte_eth_representor_id_get(const struct rte_eth_dev *ethdev,
if (info == NULL)
return -ENOMEM;
info->nb_ranges_alloc = n;
- ret = rte_eth_representor_info_get(ethdev->data->port_id, info);
+ ret = rte_eth_representor_info_get(port_id, info);
if (ret < 0)
goto out;
@@ -5965,7 +5966,7 @@ rte_eth_representor_id_get(const struct rte_eth_dev *ethdev,
continue;
if (info->ranges[i].id_end < info->ranges[i].id_base) {
RTE_LOG(WARNING, EAL, "Port %hu invalid representor ID Range %u - %u, entry %d\n",
- ethdev->data->port_id, info->ranges[i].id_base,
+ port_id, info->ranges[i].id_base,
info->ranges[i].id_end, i);
continue;
diff --git a/lib/ethdev/rte_ethdev_core.h b/lib/ethdev/rte_ethdev_core.h
index d2c9ec42c7..66ad8b13c8 100644
--- a/lib/ethdev/rte_ethdev_core.h
+++ b/lib/ethdev/rte_ethdev_core.h
@@ -185,6 +185,12 @@ struct rte_eth_dev_data {
/**< Switch-specific identifier.
* Valid if RTE_ETH_DEV_REPRESENTOR in dev_flags.
*/
+ uint16_t backer_port_id;
+ /**< Port ID of the backing device.
+ * This device will be used to query representor
+ * info and calculate representor IDs.
+ * Valid if RTE_ETH_DEV_REPRESENTOR in dev_flags.
+ */
pthread_mutex_t flow_ops_mutex; /**< rte_flow ops mutex. */
uint64_t reserved_64s[4]; /**< Reserved for future fields */
--
2.30.2
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v2 4/5] cryptodev: update fast path APIs to use new flat array
2021-10-11 12:43 2% ` [dpdk-dev] [PATCH v2 3/5] cryptodev: move inline APIs into separate structure Akhil Goyal
@ 2021-10-11 12:43 3% ` Akhil Goyal
2021-10-11 14:54 0% ` Zhang, Roy Fan
1 sibling, 1 reply; 200+ results
From: Akhil Goyal @ 2021-10-11 12:43 UTC (permalink / raw)
To: dev
Cc: thomas, david.marchand, hemant.agrawal, anoobj,
pablo.de.lara.guarch, fiona.trahe, declan.doherty, matan,
g.singh, roy.fan.zhang, jianjay.zhou, asomalap, ruifeng.wang,
konstantin.ananyev, radu.nicolau, ajit.khaparde, rnagadheeraj,
adwivedi, ciara.power, Akhil Goyal
Rework fast-path cryptodev functions to use rte_crypto_fp_ops[].
While it is an API/ABI breakage, this change is intended to be
transparent for both users (no changes in user app is required) and
PMD developers (no changes in PMD is required).
Signed-off-by: Akhil Goyal <gakhil@marvell.com>
---
lib/cryptodev/rte_cryptodev.h | 27 +++++++++++++++++----------
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/lib/cryptodev/rte_cryptodev.h b/lib/cryptodev/rte_cryptodev.h
index ce0dca72be..739ad529e5 100644
--- a/lib/cryptodev/rte_cryptodev.h
+++ b/lib/cryptodev/rte_cryptodev.h
@@ -1832,13 +1832,18 @@ static inline uint16_t
rte_cryptodev_dequeue_burst(uint8_t dev_id, uint16_t qp_id,
struct rte_crypto_op **ops, uint16_t nb_ops)
{
- struct rte_cryptodev *dev = &rte_cryptodevs[dev_id];
+ struct rte_crypto_fp_ops *fp_ops;
+ void *qp;
rte_cryptodev_trace_dequeue_burst(dev_id, qp_id, (void **)ops, nb_ops);
- nb_ops = (*dev->dequeue_burst)
- (dev->data->queue_pairs[qp_id], ops, nb_ops);
+
+ fp_ops = &rte_crypto_fp_ops[dev_id];
+ qp = fp_ops->qp.data[qp_id];
+
+ nb_ops = fp_ops->dequeue_burst(qp, ops, nb_ops);
+
#ifdef RTE_CRYPTO_CALLBACKS
- if (unlikely(dev->deq_cbs != NULL)) {
+ if (unlikely(fp_ops->qp.deq_cb != NULL)) {
struct rte_cryptodev_cb_rcu *list;
struct rte_cryptodev_cb *cb;
@@ -1848,7 +1853,7 @@ rte_cryptodev_dequeue_burst(uint8_t dev_id, uint16_t qp_id,
* cb and cb->fn/cb->next, __ATOMIC_ACQUIRE memory order is
* not required.
*/
- list = &dev->deq_cbs[qp_id];
+ list = (struct rte_cryptodev_cb_rcu *)&fp_ops->qp.deq_cb[qp_id];
rte_rcu_qsbr_thread_online(list->qsbr, 0);
cb = __atomic_load_n(&list->next, __ATOMIC_RELAXED);
@@ -1899,10 +1904,13 @@ static inline uint16_t
rte_cryptodev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
struct rte_crypto_op **ops, uint16_t nb_ops)
{
- struct rte_cryptodev *dev = &rte_cryptodevs[dev_id];
+ struct rte_crypto_fp_ops *fp_ops;
+ void *qp;
+ fp_ops = &rte_crypto_fp_ops[dev_id];
+ qp = fp_ops->qp.data[qp_id];
#ifdef RTE_CRYPTO_CALLBACKS
- if (unlikely(dev->enq_cbs != NULL)) {
+ if (unlikely(fp_ops->qp.enq_cb != NULL)) {
struct rte_cryptodev_cb_rcu *list;
struct rte_cryptodev_cb *cb;
@@ -1912,7 +1920,7 @@ rte_cryptodev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
* cb and cb->fn/cb->next, __ATOMIC_ACQUIRE memory order is
* not required.
*/
- list = &dev->enq_cbs[qp_id];
+ list = (struct rte_cryptodev_cb_rcu *)&fp_ops->qp.enq_cb[qp_id];
rte_rcu_qsbr_thread_online(list->qsbr, 0);
cb = __atomic_load_n(&list->next, __ATOMIC_RELAXED);
@@ -1927,8 +1935,7 @@ rte_cryptodev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
#endif
rte_cryptodev_trace_enqueue_burst(dev_id, qp_id, (void **)ops, nb_ops);
- return (*dev->enqueue_burst)(
- dev->data->queue_pairs[qp_id], ops, nb_ops);
+ return fp_ops->enqueue_burst(qp, ops, nb_ops);
}
--
2.25.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v2 3/5] cryptodev: move inline APIs into separate structure
@ 2021-10-11 12:43 2% ` Akhil Goyal
2021-10-11 14:45 0% ` Zhang, Roy Fan
2021-10-11 12:43 3% ` [dpdk-dev] [PATCH v2 4/5] cryptodev: update fast path APIs to use new flat array Akhil Goyal
1 sibling, 1 reply; 200+ results
From: Akhil Goyal @ 2021-10-11 12:43 UTC (permalink / raw)
To: dev
Cc: thomas, david.marchand, hemant.agrawal, anoobj,
pablo.de.lara.guarch, fiona.trahe, declan.doherty, matan,
g.singh, roy.fan.zhang, jianjay.zhou, asomalap, ruifeng.wang,
konstantin.ananyev, radu.nicolau, ajit.khaparde, rnagadheeraj,
adwivedi, ciara.power, Akhil Goyal
Move fastpath inline function pointers from rte_cryptodev into a
separate structure accessed via a flat array.
The intension is to make rte_cryptodev and related structures private
to avoid future API/ABI breakages.
Signed-off-by: Akhil Goyal <gakhil@marvell.com>
---
lib/cryptodev/cryptodev_pmd.c | 51 ++++++++++++++++++++++++++++++
lib/cryptodev/cryptodev_pmd.h | 11 +++++++
lib/cryptodev/rte_cryptodev.c | 29 +++++++++++++++++
lib/cryptodev/rte_cryptodev_core.h | 29 +++++++++++++++++
lib/cryptodev/version.map | 5 +++
5 files changed, 125 insertions(+)
diff --git a/lib/cryptodev/cryptodev_pmd.c b/lib/cryptodev/cryptodev_pmd.c
index 44a70ecb35..4646708045 100644
--- a/lib/cryptodev/cryptodev_pmd.c
+++ b/lib/cryptodev/cryptodev_pmd.c
@@ -4,6 +4,7 @@
#include <sys/queue.h>
+#include <rte_errno.h>
#include <rte_string_fns.h>
#include <rte_malloc.h>
@@ -160,3 +161,53 @@ rte_cryptodev_pmd_destroy(struct rte_cryptodev *cryptodev)
return 0;
}
+
+static uint16_t
+dummy_crypto_enqueue_burst(__rte_unused void *qp,
+ __rte_unused struct rte_crypto_op **ops,
+ __rte_unused uint16_t nb_ops)
+{
+ CDEV_LOG_ERR(
+ "crypto enqueue burst requested for unconfigured device");
+ rte_errno = ENOTSUP;
+ return 0;
+}
+
+static uint16_t
+dummy_crypto_dequeue_burst(__rte_unused void *qp,
+ __rte_unused struct rte_crypto_op **ops,
+ __rte_unused uint16_t nb_ops)
+{
+ CDEV_LOG_ERR(
+ "crypto dequeue burst requested for unconfigured device");
+ rte_errno = ENOTSUP;
+ return 0;
+}
+
+void
+cryptodev_fp_ops_reset(struct rte_crypto_fp_ops *fp_ops)
+{
+ static void *dummy_data[RTE_MAX_QUEUES_PER_PORT];
+ static const struct rte_crypto_fp_ops dummy = {
+ .enqueue_burst = dummy_crypto_enqueue_burst,
+ .dequeue_burst = dummy_crypto_dequeue_burst,
+ .qp = {
+ .data = dummy_data,
+ .enq_cb = dummy_data,
+ .deq_cb = dummy_data,
+ },
+ };
+
+ *fp_ops = dummy;
+}
+
+void
+cryptodev_fp_ops_set(struct rte_crypto_fp_ops *fp_ops,
+ const struct rte_cryptodev *dev)
+{
+ fp_ops->enqueue_burst = dev->enqueue_burst;
+ fp_ops->dequeue_burst = dev->dequeue_burst;
+ fp_ops->qp.data = dev->data->queue_pairs;
+ fp_ops->qp.enq_cb = (void **)(uintptr_t)dev->enq_cbs;
+ fp_ops->qp.deq_cb = (void **)(uintptr_t)dev->deq_cbs;
+}
diff --git a/lib/cryptodev/cryptodev_pmd.h b/lib/cryptodev/cryptodev_pmd.h
index 36606dd10b..a71edbb991 100644
--- a/lib/cryptodev/cryptodev_pmd.h
+++ b/lib/cryptodev/cryptodev_pmd.h
@@ -516,6 +516,17 @@ RTE_INIT(init_ ##driver_id)\
driver_id = rte_cryptodev_allocate_driver(&crypto_drv, &(drv));\
}
+/* Reset crypto device fastpath APIs to dummy values. */
+__rte_internal
+void
+cryptodev_fp_ops_reset(struct rte_crypto_fp_ops *fp_ops);
+
+/* Setup crypto device fastpath APIs. */
+__rte_internal
+void
+cryptodev_fp_ops_set(struct rte_crypto_fp_ops *fp_ops,
+ const struct rte_cryptodev *dev);
+
static inline void *
get_sym_session_private_data(const struct rte_cryptodev_sym_session *sess,
uint8_t driver_id) {
diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index eb86e629aa..2378892d40 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -53,6 +53,9 @@ static struct rte_cryptodev_global cryptodev_globals = {
.nb_devs = 0
};
+/* Public fastpath APIs. */
+struct rte_crypto_fp_ops rte_crypto_fp_ops[RTE_CRYPTO_MAX_DEVS];
+
/* spinlock for crypto device callbacks */
static rte_spinlock_t rte_cryptodev_cb_lock = RTE_SPINLOCK_INITIALIZER;
@@ -903,6 +906,16 @@ rte_cryptodev_pmd_allocate(const char *name, int socket_id)
cryptodev_globals.nb_devs++;
}
+ /*
+ * for secondary process, at that point we expect device
+ * to be already 'usable', so shared data and all function
+ * pointers for fast-path devops have to be setup properly
+ * inside rte_cryptodev.
+ */
+ if (rte_eal_process_type() == RTE_PROC_SECONDARY)
+ cryptodev_fp_ops_set(rte_crypto_fp_ops +
+ cryptodev->data->dev_id, cryptodev);
+
return cryptodev;
}
@@ -917,6 +930,8 @@ rte_cryptodev_pmd_release_device(struct rte_cryptodev *cryptodev)
dev_id = cryptodev->data->dev_id;
+ cryptodev_fp_ops_reset(rte_crypto_fp_ops + dev_id);
+
/* Close device only if device operations have been set */
if (cryptodev->dev_ops) {
ret = rte_cryptodev_close(dev_id);
@@ -1080,6 +1095,9 @@ rte_cryptodev_start(uint8_t dev_id)
}
diag = (*dev->dev_ops->dev_start)(dev);
+ /* expose selection of PMD fast-path functions */
+ cryptodev_fp_ops_set(rte_crypto_fp_ops + dev_id, dev);
+
rte_cryptodev_trace_start(dev_id, diag);
if (diag == 0)
dev->data->dev_started = 1;
@@ -1109,6 +1127,9 @@ rte_cryptodev_stop(uint8_t dev_id)
return;
}
+ /* point fast-path functions to dummy ones */
+ cryptodev_fp_ops_reset(rte_crypto_fp_ops + dev_id);
+
(*dev->dev_ops->dev_stop)(dev);
rte_cryptodev_trace_stop(dev_id);
dev->data->dev_started = 0;
@@ -2411,3 +2432,11 @@ rte_cryptodev_allocate_driver(struct cryptodev_driver *crypto_drv,
return nb_drivers++;
}
+
+RTE_INIT(cryptodev_init_fp_ops)
+{
+ uint32_t i;
+
+ for (i = 0; i != RTE_DIM(rte_crypto_fp_ops); i++)
+ cryptodev_fp_ops_reset(rte_crypto_fp_ops + i);
+}
diff --git a/lib/cryptodev/rte_cryptodev_core.h b/lib/cryptodev/rte_cryptodev_core.h
index 1633e55889..bac5f8d984 100644
--- a/lib/cryptodev/rte_cryptodev_core.h
+++ b/lib/cryptodev/rte_cryptodev_core.h
@@ -25,6 +25,35 @@ typedef uint16_t (*enqueue_pkt_burst_t)(void *qp,
struct rte_crypto_op **ops, uint16_t nb_ops);
/**< Enqueue packets for processing on queue pair of a device. */
+/**
+ * @internal
+ * Structure used to hold opaque pointers to internal ethdev Rx/Tx
+ * queues data.
+ * The main purpose to expose these pointers at all - allow compiler
+ * to fetch this data for fast-path cryptodev inline functions in advance.
+ */
+struct rte_cryptodev_qpdata {
+ /** points to array of internal queue pair data pointers. */
+ void **data;
+ /** points to array of enqueue callback data pointers */
+ void **enq_cb;
+ /** points to array of dequeue callback data pointers */
+ void **deq_cb;
+};
+
+struct rte_crypto_fp_ops {
+ /** PMD enqueue burst function. */
+ enqueue_pkt_burst_t enqueue_burst;
+ /** PMD dequeue burst function. */
+ dequeue_pkt_burst_t dequeue_burst;
+ /** Internal queue pair data pointers. */
+ struct rte_cryptodev_qpdata qp;
+ /** Reserved for future ops. */
+ uintptr_t reserved[4];
+} __rte_cache_aligned;
+
+extern struct rte_crypto_fp_ops rte_crypto_fp_ops[RTE_CRYPTO_MAX_DEVS];
+
/**
* @internal
* The data part, with no function pointers, associated with each device.
diff --git a/lib/cryptodev/version.map b/lib/cryptodev/version.map
index 43cf937e40..ed62ced221 100644
--- a/lib/cryptodev/version.map
+++ b/lib/cryptodev/version.map
@@ -45,6 +45,9 @@ DPDK_22 {
rte_cryptodev_sym_session_init;
rte_cryptodevs;
+ #added in 21.11
+ rte_crypto_fp_ops;
+
local: *;
};
@@ -109,6 +112,8 @@ EXPERIMENTAL {
INTERNAL {
global:
+ cryptodev_fp_ops_reset;
+ cryptodev_fp_ops_set;
rte_cryptodev_allocate_driver;
rte_cryptodev_pmd_allocate;
rte_cryptodev_pmd_callback_process;
--
2.25.1
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v7] ethdev: fix representor port ID search by name
2021-10-08 9:27 4% ` [dpdk-dev] [PATCH v6] " Andrew Rybchenko
@ 2021-10-11 12:30 4% ` Andrew Rybchenko
2021-10-11 12:53 4% ` [dpdk-dev] [PATCH v8] " Andrew Rybchenko
3 siblings, 0 replies; 200+ results
From: Andrew Rybchenko @ 2021-10-11 12:30 UTC (permalink / raw)
To: Ajit Khaparde, Somnath Kotur, John Daley, Hyong Youb Kim,
Beilei Xing, Qiming Yang, Qi Zhang, Haiyue Wang, Matan Azrad,
Viacheslav Ovsiienko, Thomas Monjalon, Ferruh Yigit
Cc: dev, Viacheslav Galaktionov, Xueming Li
From: Viacheslav Galaktionov <viacheslav.galaktionov@oktetlabs.ru>
Getting a list of representors from a representor does not make sense.
Instead, a parent device should be used.
To this end, extend the rte_eth_dev_data structure to include the port ID
of the backing device for representors.
Signed-off-by: Viacheslav Galaktionov <viacheslav.galaktionov@oktetlabs.ru>
Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Acked-by: Haiyue Wang <haiyue.wang@intel.com>
Acked-by: Beilei Xing <beilei.xing@intel.com>
Reviewed-by: Xueming Li <xuemingl@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
---
The new field is added into the hole in rte_eth_dev_data structure.
The patch does not change ABI, but extra care is required since ABI
check is disabled for the structure because of the libabigail bug [1].
It should not be a problem anyway since 21.11 is a ABI breaking release.
Potentially it is bad for out-of-tree drivers which implement
representors but do not fill in a new backer_port_id field in
rte_eth_dev_data structure. Get ID by name will not work.
mlx5 changes should be reviwed by maintainers very carefully, since
we are not sure if we patch it correctly.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=28060
v7:
- use dpdk_dev in net/mlx5 as suggested by Viacheslav O.
v6:
- provide more information in the changeset description
v5:
- try to improve name: backer_port_id instead of parent_port_id
- init new field to RTE_MAX_ETHPORTS on allocation to avoid
zero port usage by default
v4:
- apply mlx5 review notes: remove fallback from generic ethdev
code and add fallback to mlx5 code to handle legacy usecase
v3:
- fix mlx5 build breakage
v2:
- fix mlx5 review notes
- try device port ID first before parent in order to address
backward compatibility issue
drivers/net/bnxt/bnxt_reps.c | 1 +
drivers/net/enic/enic_vf_representor.c | 1 +
drivers/net/i40e/i40e_vf_representor.c | 1 +
drivers/net/ice/ice_dcf_vf_representor.c | 1 +
drivers/net/ixgbe/ixgbe_vf_representor.c | 1 +
drivers/net/mlx5/linux/mlx5_os.c | 13 +++++++++++++
drivers/net/mlx5/windows/mlx5_os.c | 13 +++++++++++++
lib/ethdev/ethdev_driver.h | 6 +++---
lib/ethdev/rte_class_eth.c | 2 +-
lib/ethdev/rte_ethdev.c | 9 +++++----
lib/ethdev/rte_ethdev_core.h | 6 ++++++
11 files changed, 46 insertions(+), 8 deletions(-)
diff --git a/drivers/net/bnxt/bnxt_reps.c b/drivers/net/bnxt/bnxt_reps.c
index df05619c3f..b7e88e013a 100644
--- a/drivers/net/bnxt/bnxt_reps.c
+++ b/drivers/net/bnxt/bnxt_reps.c
@@ -187,6 +187,7 @@ int bnxt_representor_init(struct rte_eth_dev *eth_dev, void *params)
eth_dev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR |
RTE_ETH_DEV_AUTOFILL_QUEUE_XSTATS;
eth_dev->data->representor_id = rep_params->vf_id;
+ eth_dev->data->backer_port_id = rep_params->parent_dev->data->port_id;
rte_eth_random_addr(vf_rep_bp->dflt_mac_addr);
memcpy(vf_rep_bp->mac_addr, vf_rep_bp->dflt_mac_addr,
diff --git a/drivers/net/enic/enic_vf_representor.c b/drivers/net/enic/enic_vf_representor.c
index cfd02c03cc..1a4411844a 100644
--- a/drivers/net/enic/enic_vf_representor.c
+++ b/drivers/net/enic/enic_vf_representor.c
@@ -666,6 +666,7 @@ int enic_vf_representor_init(struct rte_eth_dev *eth_dev, void *init_params)
eth_dev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR |
RTE_ETH_DEV_AUTOFILL_QUEUE_XSTATS;
eth_dev->data->representor_id = vf->vf_id;
+ eth_dev->data->backer_port_id = pf->port_id;
eth_dev->data->mac_addrs = rte_zmalloc("enic_mac_addr_vf",
sizeof(struct rte_ether_addr) *
ENIC_UNICAST_PERFECT_FILTERS, 0);
diff --git a/drivers/net/i40e/i40e_vf_representor.c b/drivers/net/i40e/i40e_vf_representor.c
index 0481b55381..d65b821a01 100644
--- a/drivers/net/i40e/i40e_vf_representor.c
+++ b/drivers/net/i40e/i40e_vf_representor.c
@@ -514,6 +514,7 @@ i40e_vf_representor_init(struct rte_eth_dev *ethdev, void *init_params)
ethdev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR |
RTE_ETH_DEV_AUTOFILL_QUEUE_XSTATS;
ethdev->data->representor_id = representor->vf_id;
+ ethdev->data->backer_port_id = pf->dev_data->port_id;
/* Setting the number queues allocated to the VF */
ethdev->data->nb_rx_queues = vf->vsi->nb_qps;
diff --git a/drivers/net/ice/ice_dcf_vf_representor.c b/drivers/net/ice/ice_dcf_vf_representor.c
index b547c42f91..c5335ac3cc 100644
--- a/drivers/net/ice/ice_dcf_vf_representor.c
+++ b/drivers/net/ice/ice_dcf_vf_representor.c
@@ -426,6 +426,7 @@ ice_dcf_vf_repr_init(struct rte_eth_dev *vf_rep_eth_dev, void *init_param)
vf_rep_eth_dev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR;
vf_rep_eth_dev->data->representor_id = repr->vf_id;
+ vf_rep_eth_dev->data->backer_port_id = repr->dcf_eth_dev->data->port_id;
vf_rep_eth_dev->data->mac_addrs = &repr->mac_addr;
diff --git a/drivers/net/ixgbe/ixgbe_vf_representor.c b/drivers/net/ixgbe/ixgbe_vf_representor.c
index d5b636a194..9fa75984fb 100644
--- a/drivers/net/ixgbe/ixgbe_vf_representor.c
+++ b/drivers/net/ixgbe/ixgbe_vf_representor.c
@@ -197,6 +197,7 @@ ixgbe_vf_representor_init(struct rte_eth_dev *ethdev, void *init_params)
ethdev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR;
ethdev->data->representor_id = representor->vf_id;
+ ethdev->data->backer_port_id = representor->pf_ethdev->data->port_id;
/* Set representor device ops */
ethdev->dev_ops = &ixgbe_vf_representor_dev_ops;
diff --git a/drivers/net/mlx5/linux/mlx5_os.c b/drivers/net/mlx5/linux/mlx5_os.c
index 3746057673..3858984f02 100644
--- a/drivers/net/mlx5/linux/mlx5_os.c
+++ b/drivers/net/mlx5/linux/mlx5_os.c
@@ -1677,6 +1677,19 @@ mlx5_dev_spawn(struct rte_device *dpdk_dev,
if (priv->representor) {
eth_dev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR;
eth_dev->data->representor_id = priv->representor_id;
+ MLX5_ETH_FOREACH_DEV(port_id, dpdk_dev) {
+ struct mlx5_priv *opriv =
+ rte_eth_devices[port_id].data->dev_private;
+ if (opriv &&
+ opriv->master &&
+ opriv->domain_id == priv->domain_id &&
+ opriv->sh == priv->sh) {
+ eth_dev->data->backer_port_id = port_id;
+ break;
+ }
+ }
+ if (port_id >= RTE_MAX_ETHPORTS)
+ eth_dev->data->backer_port_id = eth_dev->data->port_id;
}
priv->mp_id.port_id = eth_dev->data->port_id;
strlcpy(priv->mp_id.name, MLX5_MP_NAME, RTE_MP_MAX_NAME_LEN);
diff --git a/drivers/net/mlx5/windows/mlx5_os.c b/drivers/net/mlx5/windows/mlx5_os.c
index 26fa927039..9de8adecf4 100644
--- a/drivers/net/mlx5/windows/mlx5_os.c
+++ b/drivers/net/mlx5/windows/mlx5_os.c
@@ -543,6 +543,19 @@ mlx5_dev_spawn(struct rte_device *dpdk_dev,
if (priv->representor) {
eth_dev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR;
eth_dev->data->representor_id = priv->representor_id;
+ MLX5_ETH_FOREACH_DEV(port_id, dpdk_dev) {
+ struct mlx5_priv *opriv =
+ rte_eth_devices[port_id].data->dev_private;
+ if (opriv &&
+ opriv->master &&
+ opriv->domain_id == priv->domain_id &&
+ opriv->sh == priv->sh) {
+ eth_dev->data->backer_port_id = port_id;
+ break;
+ }
+ }
+ if (port_id >= RTE_MAX_ETHPORTS)
+ eth_dev->data->backer_port_id = eth_dev->data->port_id;
}
/*
* Store associated network device interface index. This index
diff --git a/lib/ethdev/ethdev_driver.h b/lib/ethdev/ethdev_driver.h
index 7ce0f7729a..c4ea735732 100644
--- a/lib/ethdev/ethdev_driver.h
+++ b/lib/ethdev/ethdev_driver.h
@@ -1266,8 +1266,8 @@ struct rte_eth_devargs {
* For backward compatibility, if no representor info, direct
* map legacy VF (no controller and pf).
*
- * @param ethdev
- * Handle of ethdev port.
+ * @param port_id
+ * Port ID of the backing device.
* @param type
* Representor type.
* @param controller
@@ -1284,7 +1284,7 @@ struct rte_eth_devargs {
*/
__rte_internal
int
-rte_eth_representor_id_get(const struct rte_eth_dev *ethdev,
+rte_eth_representor_id_get(uint16_t port_id,
enum rte_eth_representor_type type,
int controller, int pf, int representor_port,
uint16_t *repr_id);
diff --git a/lib/ethdev/rte_class_eth.c b/lib/ethdev/rte_class_eth.c
index 1fe5fa1f36..eda216ced5 100644
--- a/lib/ethdev/rte_class_eth.c
+++ b/lib/ethdev/rte_class_eth.c
@@ -95,7 +95,7 @@ eth_representor_cmp(const char *key __rte_unused,
c = i / (np * nf);
p = (i / nf) % np;
f = i % nf;
- if (rte_eth_representor_id_get(edev,
+ if (rte_eth_representor_id_get(edev->data->backer_port_id,
eth_da.type,
eth_da.nb_mh_controllers == 0 ? -1 :
eth_da.mh_controllers[c],
diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index 028907bc4b..ed7b43a99f 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -524,6 +524,7 @@ rte_eth_dev_allocate(const char *name)
eth_dev = eth_dev_get(port_id);
strlcpy(eth_dev->data->name, name, sizeof(eth_dev->data->name));
eth_dev->data->port_id = port_id;
+ eth_dev->data->backer_port_id = RTE_MAX_ETHPORTS;
eth_dev->data->mtu = RTE_ETHER_MTU;
pthread_mutex_init(ð_dev->data->flow_ops_mutex, NULL);
@@ -5915,7 +5916,7 @@ rte_eth_devargs_parse(const char *dargs, struct rte_eth_devargs *eth_da)
}
int
-rte_eth_representor_id_get(const struct rte_eth_dev *ethdev,
+rte_eth_representor_id_get(uint16_t port_id,
enum rte_eth_representor_type type,
int controller, int pf, int representor_port,
uint16_t *repr_id)
@@ -5931,7 +5932,7 @@ rte_eth_representor_id_get(const struct rte_eth_dev *ethdev,
return -EINVAL;
/* Get PMD representor range info. */
- ret = rte_eth_representor_info_get(ethdev->data->port_id, NULL);
+ ret = rte_eth_representor_info_get(port_id, NULL);
if (ret == -ENOTSUP && type == RTE_ETH_REPRESENTOR_VF &&
controller == -1 && pf == -1) {
/* Direct mapping for legacy VF representor. */
@@ -5946,7 +5947,7 @@ rte_eth_representor_id_get(const struct rte_eth_dev *ethdev,
if (info == NULL)
return -ENOMEM;
info->nb_ranges_alloc = n;
- ret = rte_eth_representor_info_get(ethdev->data->port_id, info);
+ ret = rte_eth_representor_info_get(port_id, info);
if (ret < 0)
goto out;
@@ -5965,7 +5966,7 @@ rte_eth_representor_id_get(const struct rte_eth_dev *ethdev,
continue;
if (info->ranges[i].id_end < info->ranges[i].id_base) {
RTE_LOG(WARNING, EAL, "Port %hu invalid representor ID Range %u - %u, entry %d\n",
- ethdev->data->port_id, info->ranges[i].id_base,
+ port_id, info->ranges[i].id_base,
info->ranges[i].id_end, i);
continue;
diff --git a/lib/ethdev/rte_ethdev_core.h b/lib/ethdev/rte_ethdev_core.h
index d2c9ec42c7..66ad8b13c8 100644
--- a/lib/ethdev/rte_ethdev_core.h
+++ b/lib/ethdev/rte_ethdev_core.h
@@ -185,6 +185,12 @@ struct rte_eth_dev_data {
/**< Switch-specific identifier.
* Valid if RTE_ETH_DEV_REPRESENTOR in dev_flags.
*/
+ uint16_t backer_port_id;
+ /**< Port ID of the backing device.
+ * This device will be used to query representor
+ * info and calculate representor IDs.
+ * Valid if RTE_ETH_DEV_REPRESENTOR in dev_flags.
+ */
pthread_mutex_t flow_ops_mutex; /**< rte_flow ops mutex. */
uint64_t reserved_64s[4]; /**< Reserved for future fields */
--
2.30.2
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v8 03/10] security: add UDP params for IPsec NAT-T
2021-10-11 11:29 5% ` [dpdk-dev] [PATCH v8 01/10] security: add ESN field to ipsec_xform Radu Nicolau
@ 2021-10-11 11:29 5% ` Radu Nicolau
2021-10-12 10:24 0% ` Ananyev, Konstantin
1 sibling, 1 reply; 200+ results
From: Radu Nicolau @ 2021-10-11 11:29 UTC (permalink / raw)
To: Ray Kinsella, Akhil Goyal, Declan Doherty
Cc: dev, konstantin.ananyev, vladimir.medvedkin, bruce.richardson,
roy.fan.zhang, hemant.agrawal, anoobj, abhijit.sinha,
daniel.m.buckley, marchana, ktejasree, matan, Radu Nicolau
Add support for specifying UDP port params for UDP encapsulation option.
RFC3948 section-2.1 does not enforce using specific the UDP ports for
UDP-Encapsulated ESP Header
Signed-off-by: Declan Doherty <declan.doherty@intel.com>
Signed-off-by: Radu Nicolau <radu.nicolau@intel.com>
Signed-off-by: Abhijit Sinha <abhijit.sinha@intel.com>
Signed-off-by: Daniel Martin Buckley <daniel.m.buckley@intel.com>
Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
Acked-by: Anoob Joseph <anoobj@marvell.com>
---
doc/guides/rel_notes/deprecation.rst | 5 ++---
doc/guides/rel_notes/release_21_11.rst | 5 +++++
lib/security/rte_security.h | 7 +++++++
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 8b7b0beee2..d24d69b669 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -210,9 +210,8 @@ Deprecation Notices
pointer for the private data to the application which can be attached
to the packet while enqueuing.
-* security: The structure ``rte_security_ipsec_xform`` will be extended with
- multiple fields: source and destination port of UDP encapsulation,
- IPsec payload MSS (Maximum Segment Size).
+* security: The structure ``rte_security_ipsec_xform`` will be extended with:
+ new field: IPsec payload MSS (Maximum Segment Size).
* security: The IPsec SA config options ``struct rte_security_ipsec_sa_options``
will be updated with new fields to support new features like IPsec inner
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index 8ac6632abf..1a29640eea 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -238,6 +238,11 @@ ABI Changes
application to start from an arbitrary ESN value for debug and SA lifetime
enforcement purposes.
+* security: A new structure ``udp`` was added in structure
+ ``rte_security_ipsec_xform`` to allow setting the source and destination ports
+ for UDP encapsulated IPsec traffic.
+
+
Known Issues
------------
diff --git a/lib/security/rte_security.h b/lib/security/rte_security.h
index 371d64647a..b30425e206 100644
--- a/lib/security/rte_security.h
+++ b/lib/security/rte_security.h
@@ -128,6 +128,11 @@ struct rte_security_ipsec_tunnel_param {
};
};
+struct rte_security_ipsec_udp_param {
+ uint16_t sport;
+ uint16_t dport;
+};
+
/**
* IPsec Security Association option flags
*/
@@ -288,6 +293,8 @@ struct rte_security_ipsec_xform {
};
} esn;
/**< Extended Sequence Number */
+ struct rte_security_ipsec_udp_param udp;
+ /**< UDP parameters, ignored when udp_encap option not specified */
};
/**
--
2.25.1
^ permalink raw reply [relevance 5%]
* [dpdk-dev] [PATCH v8 01/10] security: add ESN field to ipsec_xform
@ 2021-10-11 11:29 5% ` Radu Nicolau
2021-10-12 10:23 0% ` Ananyev, Konstantin
2021-10-11 11:29 5% ` [dpdk-dev] [PATCH v8 03/10] security: add UDP params for IPsec NAT-T Radu Nicolau
1 sibling, 1 reply; 200+ results
From: Radu Nicolau @ 2021-10-11 11:29 UTC (permalink / raw)
To: Ray Kinsella, Akhil Goyal, Declan Doherty
Cc: dev, konstantin.ananyev, vladimir.medvedkin, bruce.richardson,
roy.fan.zhang, hemant.agrawal, anoobj, abhijit.sinha,
daniel.m.buckley, marchana, ktejasree, matan, Radu Nicolau
Update ipsec_xform definition to include ESN field.
This allows the application to control the ESN starting value.
Signed-off-by: Declan Doherty <declan.doherty@intel.com>
Signed-off-by: Radu Nicolau <radu.nicolau@intel.com>
Signed-off-by: Abhijit Sinha <abhijit.sinha@intel.com>
Signed-off-by: Daniel Martin Buckley <daniel.m.buckley@intel.com>
Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
Acked-by: Anoob Joseph <anoobj@marvell.com>
---
doc/guides/rel_notes/deprecation.rst | 2 +-
doc/guides/rel_notes/release_21_11.rst | 4 ++++
lib/security/rte_security.h | 8 ++++++++
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index baf15aa722..8b7b0beee2 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -212,7 +212,7 @@ Deprecation Notices
* security: The structure ``rte_security_ipsec_xform`` will be extended with
multiple fields: source and destination port of UDP encapsulation,
- IPsec payload MSS (Maximum Segment Size), and ESN (Extended Sequence Number).
+ IPsec payload MSS (Maximum Segment Size).
* security: The IPsec SA config options ``struct rte_security_ipsec_sa_options``
will be updated with new fields to support new features like IPsec inner
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index c0a7f75518..401c6d453a 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -229,6 +229,10 @@ ABI Changes
``rte_security_ipsec_xform`` to allow applications to configure SA soft
and hard expiry limits. Limits can be either in number of packets or bytes.
+* security: A new structure ``esn`` was added in structure
+ ``rte_security_ipsec_xform`` to set an initial ESN value. This permits
+ application to start from an arbitrary ESN value for debug and SA lifetime
+ enforcement purposes.
Known Issues
------------
diff --git a/lib/security/rte_security.h b/lib/security/rte_security.h
index 2013e65e49..371d64647a 100644
--- a/lib/security/rte_security.h
+++ b/lib/security/rte_security.h
@@ -280,6 +280,14 @@ struct rte_security_ipsec_xform {
/**< Anti replay window size to enable sequence replay attack handling.
* replay checking is disabled if the window size is 0.
*/
+ union {
+ uint64_t value;
+ struct {
+ uint32_t low;
+ uint32_t hi;
+ };
+ } esn;
+ /**< Extended Sequence Number */
};
/**
--
2.25.1
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH] sort symbols map
@ 2021-10-11 11:36 0% ` Dumitrescu, Cristian
0 siblings, 0 replies; 200+ results
From: Dumitrescu, Cristian @ 2021-10-11 11:36 UTC (permalink / raw)
To: David Marchand, dev
Cc: thomas, Yigit, Ferruh, Ray Kinsella, Singh, Jasvinder, Medvedkin,
Vladimir, Walsh, Conor, Stephen Hemminger
> -----Original Message-----
> From: David Marchand <david.marchand@redhat.com>
> Sent: Tuesday, October 5, 2021 10:16 AM
> To: dev@dpdk.org
> Cc: thomas@monjalon.net; Yigit, Ferruh <ferruh.yigit@intel.com>; Ray
> Kinsella <mdr@ashroe.eu>; Singh, Jasvinder <jasvinder.singh@intel.com>;
> Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Medvedkin, Vladimir
> <vladimir.medvedkin@intel.com>; Walsh, Conor <conor.walsh@intel.com>;
> Stephen Hemminger <stephen@networkplumber.org>
> Subject: [PATCH] sort symbols map
>
> Fixed with ./devtools/update-abi.sh $(cat ABI_VERSION)
>
> Fixes: e73a7ab22422 ("net/softnic: promote manage API")
> Fixes: 8f532a34c4f2 ("fib: promote API to stable")
> Fixes: 4aeb92396b85 ("rib: promote API to stable")
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
> I added "./devtools/update-abi.sh $(cat ABI_VERSION)" to my checks.
>
> I should have caught it when merging fib and rib patches...
> But my eyes (or more likely brain) stopped at net/softnic bits.
>
> What do you think?
> Should I wait a bit more and send a global patch to catch any missed
> sorting just before rc1?
>
> In the meantime, if you merge .map updates, try to remember to run the
> command above.
>
> Thanks.
> ---
> drivers/net/softnic/version.map | 2 +-
> lib/fib/version.map | 21 ++++++++++-----------
> lib/rib/version.map | 33 ++++++++++++++++-----------------
> 3 files changed, 27 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/net/softnic/version.map
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 1/3] cryptodev: remove LIST_END enumerators
2021-10-08 20:45 3% ` [dpdk-dev] [PATCH v2 1/3] cryptodev: remove LIST_END enumerators Akhil Goyal
2021-10-08 20:45 3% ` [dpdk-dev] [PATCH v2 3/3] security: add reserved bitfields Akhil Goyal
@ 2021-10-11 10:46 0% ` Zhang, Roy Fan
2021-10-12 9:55 3% ` Kinsella, Ray
2 siblings, 0 replies; 200+ results
From: Zhang, Roy Fan @ 2021-10-11 10:46 UTC (permalink / raw)
To: Akhil Goyal, dev
Cc: thomas, david.marchand, hemant.agrawal, anoobj, De Lara Guarch,
Pablo, Trahe, Fiona, Doherty, Declan, matan, g.singh,
jianjay.zhou, asomalap, ruifeng.wang, Ananyev, Konstantin,
Nicolau, Radu, ajit.khaparde, rnagadheeraj, adwivedi, Power,
Ciara
> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Friday, October 8, 2021 9:45 PM
> To: dev@dpdk.org
> Cc: thomas@monjalon.net; david.marchand@redhat.com;
> hemant.agrawal@nxp.com; anoobj@marvell.com; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; Trahe, Fiona <fiona.trahe@intel.com>;
> Doherty, Declan <declan.doherty@intel.com>; matan@nvidia.com;
> g.singh@nxp.com; Zhang, Roy Fan <roy.fan.zhang@intel.com>;
> jianjay.zhou@huawei.com; asomalap@amd.com; ruifeng.wang@arm.com;
> Ananyev, Konstantin <konstantin.ananyev@intel.com>; Nicolau, Radu
> <radu.nicolau@intel.com>; ajit.khaparde@broadcom.com;
> rnagadheeraj@marvell.com; adwivedi@marvell.com; Power, Ciara
> <ciara.power@intel.com>; Akhil Goyal <gakhil@marvell.com>
> Subject: [PATCH v2 1/3] cryptodev: remove LIST_END enumerators
>
> Remove *_LIST_END enumerators from asymmetric crypto
> lib to avoid ABI breakage for every new addition in
> enums.
>
> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> ---
Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 1/5] ethdev: update modify field flow action
2021-10-10 23:45 8% ` [dpdk-dev] [PATCH v2 1/5] " Viacheslav Ovsiienko
@ 2021-10-11 9:54 3% ` Andrew Rybchenko
0 siblings, 0 replies; 200+ results
From: Andrew Rybchenko @ 2021-10-11 9:54 UTC (permalink / raw)
To: Viacheslav Ovsiienko, dev
Cc: rasland, matan, shahafs, orika, getelson, thomas
On 10/11/21 2:45 AM, Viacheslav Ovsiienko wrote:
> The generic modify field flow action introduced in [1] has
> some issues related to the immediate source operand:
>
> - immediate source can be presented either as an unsigned
> 64-bit integer or pointer to data pattern in memory.
> There was no explicit pointer field defined in the union.
>
> - the byte ordering for 64-bit integer was not specified.
> Many fields have shorter lengths and byte ordering
> is crucial.
>
> - how the bit offset is applied to the immediate source
> field was not defined and documented.
>
> - 64-bit integer size is not enough to provide IPv6
> addresses.
>
> In order to cover the issues and exclude any ambiguities
> the following is done:
>
> - introduce the explicit pointer field
> in rte_flow_action_modify_data structure
>
> - replace the 64-bit unsigned integer with 16-byte array
>
> - update the modify field flow action documentation
>
> [1] commit 73b68f4c54a0 ("ethdev: introduce generic modify flow action")
>
> Signed-off-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
> ---
> doc/guides/prog_guide/rte_flow.rst | 16 ++++++++++++++++
> doc/guides/rel_notes/release_21_11.rst | 9 +++++++++
> lib/ethdev/rte_flow.h | 17 ++++++++++++++---
> 3 files changed, 39 insertions(+), 3 deletions(-)
>
> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> index 2b42d5ec8c..1ceecb399f 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -2835,6 +2835,22 @@ a packet to any other part of it.
> ``value`` sets an immediate value to be used as a source or points to a
> location of the value in memory. It is used instead of ``level`` and ``offset``
> for ``RTE_FLOW_FIELD_VALUE`` and ``RTE_FLOW_FIELD_POINTER`` respectively.
> +The data in memory should be presented exactly in the same byte order and
> +length as in the relevant flow item, i.e. data for field with type
> +RTE_FLOW_FIELD_MAC_DST should follow the conventions of dst field
> +in rte_flow_item_eth structure, with type RTE_FLOW_FIELD_IPV6_SRC -
> +rte_flow_item_ipv6 conventions, and so on. If the field size is large than
large -> larger
> +16 bytes the pattern can be provided as pointer only.
RTE_FLOW_FIELD_MAC_DST, dst, rte_flow_item_eth, RTE_FLOW_FIELD_IPV6_SRC,
rte_flow_item_ipv6 should be ``x``.
> +
> +The bitfield extracted from the memory being applied as second operation
> +parameter is defined by action width and by the destination field offset.
> +Application should provide the data in immediate value memory (either as
> +buffer or by pointer) exactly as item field without any applied explicit offset,
> +and destination packet field (with specified width and bit offset) will be
> +replaced by immediate source bits from the same bit offset. For example,
> +to replace the third byte of MAC address with value 0x85, application should
> +specify destination width as 8, destination width as 16, and provide immediate
destination width twice above
> +value as sequence of bytes {xxx, xxx, 0x85, xxx, xxx, xxx}.
>
> .. _table_rte_flow_action_modify_field:
pvalue should be added in the "destination/source field
definition".
dst and src members documentation should be improved to
highlight the difference. Destination cannot be "immediate" and
"pointer". In fact, "pointer" is a kind of "immediate". May be
it is better to use "constant value" instead of "immediate".
>
> diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
> index dfc2cbdeed..41a087d7c1 100644
> --- a/doc/guides/rel_notes/release_21_11.rst
> +++ b/doc/guides/rel_notes/release_21_11.rst
> @@ -187,6 +187,13 @@ API Changes
> the crypto/security operation. This field will be used to communicate
> events such as soft expiry with IPsec in lookaside mode.
>
> +* ethdev: ``rte_flow_action_modify_data`` structure udpdated, immediate data
udpdated -> updated
> + array is extended, data pointer field is explicitly added to union, the
> + action behavior is defined in more strict fashion and documentation updated.
> + The immediate value behavior has been changed, the entire immediate field
> + should be provided, and offset for immediate source bitfield is assigned
> + from destination one.
> +
>
> ABI Changes
> -----------
> @@ -222,6 +229,8 @@ ABI Changes
> ``rte_security_ipsec_xform`` to allow applications to configure SA soft
> and hard expiry limits. Limits can be either in number of packets or bytes.
>
> +* ethdev: ``rte_flow_action_modify_data`` structure udpdated.
udpdated -> updated
I'm not sure that it makes sense to duplicate ABI changes if
API is changed.
> +
>
> Known Issues
> ------------
> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
> index 7b1ed7f110..953924d42b 100644
> --- a/lib/ethdev/rte_flow.h
> +++ b/lib/ethdev/rte_flow.h
> @@ -3204,6 +3204,9 @@ enum rte_flow_field_id {
> };
>
> /**
> + * @warning
> + * @b EXPERIMENTAL: this structure may change without prior notice
> + *
Isn't a separate fix to add missing experimental header?
> * Field description for MODIFY_FIELD action.
> */
"Another packet field" in the next paragraph I read as
a field of another packet which sounds confusing.
I guess it is "Another field of the packet" in fact.
I think it would be nice to clarify as well.
> struct rte_flow_action_modify_data {
> @@ -3217,10 +3220,18 @@ struct rte_flow_action_modify_data {
> uint32_t offset;
> };
> /**
> - * Immediate value for RTE_FLOW_FIELD_VALUE or
> - * memory address for RTE_FLOW_FIELD_POINTER.
> + * Immediate value for RTE_FLOW_FIELD_VALUE, presented in the
> + * same byte order and length as in relevant rte_flow_item_xxx.
> + * The immediate source bitfield offset is inherited from
> + * the destination's one.
> */
> - uint64_t value;
> + uint8_t value[16];
> + /*
It should be a Doxygen style comment.
> + * Memory address for RTE_FLOW_FIELD_POINTER, memory layout
> + * should be the same as for relevant field in the
> + * rte_flow_item_xxx structure.
> + */
> + void *pvalue;
> };
> };
>
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 0/7] hide eth dev related structures
` (4 preceding siblings ...)
2021-10-08 18:13 0% ` [dpdk-dev] [PATCH v5 0/7] hide eth dev related structures Slava Ovsiienko
@ 2021-10-11 9:22 0% ` Andrew Rybchenko
5 siblings, 0 replies; 200+ results
From: Andrew Rybchenko @ 2021-10-11 9:22 UTC (permalink / raw)
To: Konstantin Ananyev, dev
Cc: xiaoyun.li, anoobj, jerinj, ndabilpuram, adwivedi,
shepard.siegel, ed.czeck, john.miller, irusskikh, ajit.khaparde,
somnath.kotur, rahul.lakkireddy, hemant.agrawal, sachin.saxena,
haiyue.wang, johndale, hyonkim, qi.z.zhang, xiao.w.wang, humin29,
yisen.zhuang, oulijun, beilei.xing, jingjing.wu, qiming.yang,
matan, viacheslavo, sthemmin, longli, heinrich.kuhn, kirankumark,
mczekaj, jiawenwu, jianwang, maxime.coquelin, chenbo.xia, thomas,
ferruh.yigit, mdr, jay.jayatheerthan
Hi Konstantin,
On 10/7/21 2:27 PM, Konstantin Ananyev wrote:
> v5 changes:
> - Fix spelling (Thomas/David)
> - Rename internal helper functions (David)
> - Reorder patches and update commit messages (Thomas)
> - Update comments (Thomas)
> - Changed layout in rte_eth_fp_ops, to group functions and
> related data based on their functionality:
> first 64B line for Rx, second one for Tx.
> Didn't observe any real performance difference comparing to
> original layout. Though decided to keep a new one, as it seems
> a bit more plausible.
>
> v4 changes:
> - Fix secondary process attach (Pavan)
> - Fix build failure (Ferruh)
> - Update lib/ethdev/verion.map (Ferruh)
> Note that moving newly added symbols from EXPERIMENTAL to DPDK_22
> section makes checkpatch.sh to complain.
>
> v3 changes:
> - Changes in public struct naming (Jerin/Haiyue)
> - Split patches
> - Update docs
> - Shamelessly included Andrew's patch:
> https://patches.dpdk.org/project/dpdk/patch/20210928154856.1015020-1-andrew.rybchenko@oktetlabs.ru/
> into these series.
> I have to do similar thing here, so decided to avoid duplicated effort.
>
> The aim of these patch series is to make rte_ethdev core data structures
> (rte_eth_dev, rte_eth_dev_data, rte_eth_rxtx_callback, etc.) internal to
> DPDK and not visible to the user.
> That should allow future possible changes to core ethdev related structures
> to be transparent to the user and help to improve ABI/API stability.
> Note that current ethdev API is preserved, but it is a formal ABI break.
>
> The work is based on previous discussions at:
> https://www.mail-archive.com/dev@dpdk.org/msg211405.html
> https://www.mail-archive.com/dev@dpdk.org/msg216685.html
> and consists of the following main points:
> 1. Copy public 'fast' function pointers (rx_pkt_burst(), etc.) and
> related data pointer from rte_eth_dev into a separate flat array.
> We keep it public to still be able to use inline functions for these
> 'fast' calls (like rte_eth_rx_burst(), etc.) to avoid/minimize slowdown.
> Note that apart from function pointers itself, each element of this
> flat array also contains two opaque pointers for each ethdev:
> 1) a pointer to an array of internal queue data pointers
> 2) points to array of queue callback data pointers.
> Note that exposing this extra information allows us to avoid extra
> changes inside PMD level, plus should help to avoid possible
> performance degradation.
> 2. Change implementation of 'fast' inline ethdev functions
> (rte_eth_rx_burst(), etc.) to use new public flat array.
> While it is an ABI breakage, this change is intended to be transparent
> for both users (no changes in user app is required) and PMD developers
> (no changes in PMD is required).
> One extra note - with new implementation RX/TX callback invocation
> will cost one extra function call with this changes. That might cause
> some slowdown for code-path with RX/TX callbacks heavily involved.
> Hope such trade-off is acceptable for the community.
> 3. Move rte_eth_dev, rte_eth_dev_data, rte_eth_rxtx_callback and related
> things into internal header: <ethdev_driver.h>.
>
> That approach was selected to:
> - Avoid(/minimize) possible performance losses.
> - Minimize required changes inside PMDs.
>
> Performance testing results (ICX 2.0GHz, E810 (ice)):
> - testpmd macswap fwd mode, plus
> a) no RX/TX callbacks:
> no actual slowdown observed
> b) bpf-load rx 0 0 JM ./dpdk.org/examples/bpf/t3.o:
> ~2% slowdown
> - l3fwd: no actual slowdown observed
>
> Would like to thank everyone who already reviewed and tested previous
> versions of these series. All other interested parties please don't be shy
> and provide your feedback.
Many thanks for the very good patch series.
I hope we'll make it to be included in 21.11.
If you need any help with cosmetic fixes suggested
by me on review, please, let me know.
Andrew.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 5/7] ethdev: make fast-path functions to use new flat array
@ 2021-10-11 9:02 0% ` Andrew Rybchenko
2021-10-11 15:47 0% ` Ananyev, Konstantin
0 siblings, 1 reply; 200+ results
From: Andrew Rybchenko @ 2021-10-11 9:02 UTC (permalink / raw)
To: Konstantin Ananyev, dev
Cc: xiaoyun.li, anoobj, jerinj, ndabilpuram, adwivedi,
shepard.siegel, ed.czeck, john.miller, irusskikh, ajit.khaparde,
somnath.kotur, rahul.lakkireddy, hemant.agrawal, sachin.saxena,
haiyue.wang, johndale, hyonkim, qi.z.zhang, xiao.w.wang, humin29,
yisen.zhuang, oulijun, beilei.xing, jingjing.wu, qiming.yang,
matan, viacheslavo, sthemmin, longli, heinrich.kuhn, kirankumark,
mczekaj, jiawenwu, jianwang, maxime.coquelin, chenbo.xia, thomas,
ferruh.yigit, mdr, jay.jayatheerthan
On 10/7/21 2:27 PM, Konstantin Ananyev wrote:
> Rework fast-path ethdev functions to use rte_eth_fp_ops[].
> While it is an API/ABI breakage, this change is intended to be
> transparent for both users (no changes in user app is required) and
> PMD developers (no changes in PMD is required).
> One extra thing to note - RX/TX callback invocation will cause extra
> function call with these changes. That might cause some insignificant
> slowdown for code-path where RX/TX callbacks are heavily involved.
I'm sorry for nit picking here and below:
RX -> Rx, TX -> Tx everywhere above.
>
> Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> ---
> lib/ethdev/ethdev_private.c | 31 +++++
> lib/ethdev/rte_ethdev.h | 242 ++++++++++++++++++++++++++----------
> lib/ethdev/version.map | 3 +
> 3 files changed, 208 insertions(+), 68 deletions(-)
>
> diff --git a/lib/ethdev/ethdev_private.c b/lib/ethdev/ethdev_private.c
> index 3eeda6e9f9..1222c6f84e 100644
> --- a/lib/ethdev/ethdev_private.c
> +++ b/lib/ethdev/ethdev_private.c
> @@ -226,3 +226,34 @@ eth_dev_fp_ops_setup(struct rte_eth_fp_ops *fpo,
> fpo->txq.data = dev->data->tx_queues;
> fpo->txq.clbk = (void **)(uintptr_t)dev->pre_tx_burst_cbs;
> }
> +
> +uint16_t
> +rte_eth_call_rx_callbacks(uint16_t port_id, uint16_t queue_id,
> + struct rte_mbuf **rx_pkts, uint16_t nb_rx, uint16_t nb_pkts,
> + void *opaque)
> +{
> + const struct rte_eth_rxtx_callback *cb = opaque;
> +
> + while (cb != NULL) {
> + nb_rx = cb->fn.rx(port_id, queue_id, rx_pkts, nb_rx,
> + nb_pkts, cb->param);
> + cb = cb->next;
> + }
> +
> + return nb_rx;
> +}
> +
> +uint16_t
> +rte_eth_call_tx_callbacks(uint16_t port_id, uint16_t queue_id,
> + struct rte_mbuf **tx_pkts, uint16_t nb_pkts, void *opaque)
> +{
> + const struct rte_eth_rxtx_callback *cb = opaque;
> +
> + while (cb != NULL) {
> + nb_pkts = cb->fn.tx(port_id, queue_id, tx_pkts, nb_pkts,
> + cb->param);
> + cb = cb->next;
> + }
> +
> + return nb_pkts;
> +}
> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> index cdd16d6e57..c0e1a40681 100644
> --- a/lib/ethdev/rte_ethdev.h
> +++ b/lib/ethdev/rte_ethdev.h
> @@ -4904,6 +4904,33 @@ int rte_eth_representor_info_get(uint16_t port_id,
>
> #include <rte_ethdev_core.h>
>
> +/**
> + * @internal
> + * Helper routine for eth driver rx_burst API.
rx -> Rx
> + * Should be called at exit from PMD's rte_eth_rx_bulk implementation.
> + * Does necessary post-processing - invokes RX callbacks if any, etc.
RX -> Rx
> + *
> + * @param port_id
> + * The port identifier of the Ethernet device.
> + * @param queue_id
> + * The index of the receive queue from which to retrieve input packets.
Isn't:
The index of the queue from which packets are received from?
> + * @param rx_pkts
> + * The address of an array of pointers to *rte_mbuf* structures that
> + * have been retrieved from the device.
> + * @param nb_pkts
Should be @param nb_rx
> + * The number of packets that were retrieved from the device.
> + * @param nb_pkts
> + * The number of elements in *rx_pkts* array.
@p should be used to refer to a paramter.
The description does not help to understand why both nb_rx and
nb_pkts are necessary. Isn't nb_pkts >= nb_rx and nb_rx
sufficient?
> + * @param opaque
> + * Opaque pointer of RX queue callback related data.
RX -> Rx
> + *
> + * @return
> + * The number of packets effectively supplied to the *rx_pkts* array.
@p should be used to refer to a parameter.
> + */
> +uint16_t rte_eth_call_rx_callbacks(uint16_t port_id, uint16_t queue_id,
> + struct rte_mbuf **rx_pkts, uint16_t nb_rx, uint16_t nb_pkts,
> + void *opaque);
> +
> /**
> *
> * Retrieve a burst of input packets from a receive queue of an Ethernet
> @@ -4995,23 +5022,37 @@ static inline uint16_t
> rte_eth_rx_burst(uint16_t port_id, uint16_t queue_id,
> struct rte_mbuf **rx_pkts, const uint16_t nb_pkts)
> {
> - struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> uint16_t nb_rx;
> + struct rte_eth_fp_ops *p;
p is typically a very bad name in a funcion with
many pointer variables etc. May be "fpo" as in previous
patch?
> + void *cb, *qd;
Please, avoid variable, expecially pointers, declaration in
one line.
I'd suggest to use 'rxq' instead of 'qd'. The first paramter
of the rx_pkt_burst is 'rxq'.
Also 'cb' seems to be used under RTE_ETHDEV_RXTX_CALLBACKS
only. If so, it could be unused variable warning if
RTE_ETHDEV_RXTX_CALLBACKS is not defined.
> +
> +#ifdef RTE_ETHDEV_DEBUG_RX
> + if (port_id >= RTE_MAX_ETHPORTS ||
> + queue_id >= RTE_MAX_QUEUES_PER_PORT) {
> + RTE_ETHDEV_LOG(ERR,
> + "Invalid port_id=%u or queue_id=%u\n",
> + port_id, queue_id);
> + return 0;
> + }
> +#endif
> +
> + /* fetch pointer to queue data */
> + p = &rte_eth_fp_ops[port_id];
> + qd = p->rxq.data[queue_id];
>
> #ifdef RTE_ETHDEV_DEBUG_RX
> RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
> - RTE_FUNC_PTR_OR_ERR_RET(*dev->rx_pkt_burst, 0);
>
> - if (queue_id >= dev->data->nb_rx_queues) {
> - RTE_ETHDEV_LOG(ERR, "Invalid RX queue_id=%u\n", queue_id);
> + if (qd == NULL) {
> + RTE_ETHDEV_LOG(ERR, "Invalid RX queue_id=%u for port_id=%u\n",
RX -> Rx
> + queue_id, port_id);
> return 0;
> }
> #endif
> - nb_rx = (*dev->rx_pkt_burst)(dev->data->rx_queues[queue_id],
> - rx_pkts, nb_pkts);
> +
> + nb_rx = p->rx_pkt_burst(qd, rx_pkts, nb_pkts);
>
> #ifdef RTE_ETHDEV_RXTX_CALLBACKS
> - struct rte_eth_rxtx_callback *cb;
>
> /* __ATOMIC_RELEASE memory order was used when the
> * call back was inserted into the list.
> @@ -5019,16 +5060,10 @@ rte_eth_rx_burst(uint16_t port_id, uint16_t queue_id,
> * cb and cb->fn/cb->next, __ATOMIC_ACQUIRE memory order is
> * not required.
> */
> - cb = __atomic_load_n(&dev->post_rx_burst_cbs[queue_id],
> - __ATOMIC_RELAXED);
> -
> - if (unlikely(cb != NULL)) {
> - do {
> - nb_rx = cb->fn.rx(port_id, queue_id, rx_pkts, nb_rx,
> - nb_pkts, cb->param);
> - cb = cb->next;
> - } while (cb != NULL);
> - }
> + cb = __atomic_load_n((void **)&p->rxq.clbk[queue_id], __ATOMIC_RELAXED);
> + if (unlikely(cb != NULL))
> + nb_rx = rte_eth_call_rx_callbacks(port_id, queue_id, rx_pkts,
> + nb_rx, nb_pkts, cb);
> #endif
>
> rte_ethdev_trace_rx_burst(port_id, queue_id, (void **)rx_pkts, nb_rx);
> @@ -5051,16 +5086,27 @@ rte_eth_rx_burst(uint16_t port_id, uint16_t queue_id,
> static inline int
> rte_eth_rx_queue_count(uint16_t port_id, uint16_t queue_id)
> {
> - struct rte_eth_dev *dev;
> + struct rte_eth_fp_ops *p;
> + void *qd;
p -> fpo, qd -> rxq
> +
> + if (port_id >= RTE_MAX_ETHPORTS ||
> + queue_id >= RTE_MAX_QUEUES_PER_PORT) {
> + RTE_ETHDEV_LOG(ERR,
> + "Invalid port_id=%u or queue_id=%u\n",
> + port_id, queue_id);
> + return -EINVAL;
> + }
> +
> + /* fetch pointer to queue data */
> + p = &rte_eth_fp_ops[port_id];
> + qd = p->rxq.data[queue_id];
>
> RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> - dev = &rte_eth_devices[port_id];
> - RTE_FUNC_PTR_OR_ERR_RET(*dev->rx_queue_count, -ENOTSUP);
> - if (queue_id >= dev->data->nb_rx_queues ||
> - dev->data->rx_queues[queue_id] == NULL)
> + RTE_FUNC_PTR_OR_ERR_RET(*p->rx_queue_count, -ENOTSUP);
> + if (qd == NULL)
> return -EINVAL;
>
> - return (int)(*dev->rx_queue_count)(dev->data->rx_queues[queue_id]);
> + return (int)(*p->rx_queue_count)(qd);
> }
>
> /**@{@name Rx hardware descriptor states
> @@ -5108,21 +5154,30 @@ static inline int
> rte_eth_rx_descriptor_status(uint16_t port_id, uint16_t queue_id,
> uint16_t offset)
> {
> - struct rte_eth_dev *dev;
> - void *rxq;
> + struct rte_eth_fp_ops *p;
> + void *qd;
p -> fpo, qd -> rxq
>
> #ifdef RTE_ETHDEV_DEBUG_RX
> - RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> + if (port_id >= RTE_MAX_ETHPORTS ||
> + queue_id >= RTE_MAX_QUEUES_PER_PORT) {
> + RTE_ETHDEV_LOG(ERR,
> + "Invalid port_id=%u or queue_id=%u\n",
> + port_id, queue_id);
> + return -EINVAL;
> + }
> #endif
> - dev = &rte_eth_devices[port_id];
> +
> + /* fetch pointer to queue data */
> + p = &rte_eth_fp_ops[port_id];
> + qd = p->rxq.data[queue_id];
> +
> #ifdef RTE_ETHDEV_DEBUG_RX
> - if (queue_id >= dev->data->nb_rx_queues)
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> + if (qd == NULL)
> return -ENODEV;
> #endif
> - RTE_FUNC_PTR_OR_ERR_RET(*dev->rx_descriptor_status, -ENOTSUP);
> - rxq = dev->data->rx_queues[queue_id];
> -
> - return (*dev->rx_descriptor_status)(rxq, offset);
> + RTE_FUNC_PTR_OR_ERR_RET(*p->rx_descriptor_status, -ENOTSUP);
> + return (*p->rx_descriptor_status)(qd, offset);
> }
>
> /**@{@name Tx hardware descriptor states
> @@ -5169,23 +5224,54 @@ rte_eth_rx_descriptor_status(uint16_t port_id, uint16_t queue_id,
> static inline int rte_eth_tx_descriptor_status(uint16_t port_id,
> uint16_t queue_id, uint16_t offset)
> {
> - struct rte_eth_dev *dev;
> - void *txq;
> + struct rte_eth_fp_ops *p;
> + void *qd;
p -> fpo, qd -> txq
>
> #ifdef RTE_ETHDEV_DEBUG_TX
> - RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> + if (port_id >= RTE_MAX_ETHPORTS ||
> + queue_id >= RTE_MAX_QUEUES_PER_PORT) {
> + RTE_ETHDEV_LOG(ERR,
> + "Invalid port_id=%u or queue_id=%u\n",
> + port_id, queue_id);
> + return -EINVAL;
> + }
> #endif
> - dev = &rte_eth_devices[port_id];
> +
> + /* fetch pointer to queue data */
> + p = &rte_eth_fp_ops[port_id];
> + qd = p->txq.data[queue_id];
> +
> #ifdef RTE_ETHDEV_DEBUG_TX
> - if (queue_id >= dev->data->nb_tx_queues)
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> + if (qd == NULL)
> return -ENODEV;
> #endif
> - RTE_FUNC_PTR_OR_ERR_RET(*dev->tx_descriptor_status, -ENOTSUP);
> - txq = dev->data->tx_queues[queue_id];
> -
> - return (*dev->tx_descriptor_status)(txq, offset);
> + RTE_FUNC_PTR_OR_ERR_RET(*p->tx_descriptor_status, -ENOTSUP);
> + return (*p->tx_descriptor_status)(qd, offset);
> }
>
> +/**
> + * @internal
> + * Helper routine for eth driver tx_burst API.
> + * Should be called before entry PMD's rte_eth_tx_bulk implementation.
> + * Does necessary pre-processing - invokes TX callbacks if any, etc.
TX -> Tx
> + *
> + * @param port_id
> + * The port identifier of the Ethernet device.
> + * @param queue_id
> + * The index of the transmit queue through which output packets must be
> + * sent.
> + * @param tx_pkts
> + * The address of an array of *nb_pkts* pointers to *rte_mbuf* structures
> + * which contain the output packets.
*nb_pkts* -> @p nb_pkts
> + * @param nb_pkts
> + * The maximum number of packets to transmit.
> + * @return
> + * The number of output packets to transmit.
> + */
> +uint16_t rte_eth_call_tx_callbacks(uint16_t port_id, uint16_t queue_id,
> + struct rte_mbuf **tx_pkts, uint16_t nb_pkts, void *opaque);
> +
> /**
> * Send a burst of output packets on a transmit queue of an Ethernet device.
> *
> @@ -5256,20 +5342,34 @@ static inline uint16_t
> rte_eth_tx_burst(uint16_t port_id, uint16_t queue_id,
> struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
> {
> - struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> + struct rte_eth_fp_ops *p;
> + void *cb, *qd;
Same as above
> +
> +#ifdef RTE_ETHDEV_DEBUG_TX
> + if (port_id >= RTE_MAX_ETHPORTS ||
> + queue_id >= RTE_MAX_QUEUES_PER_PORT) {
> + RTE_ETHDEV_LOG(ERR,
> + "Invalid port_id=%u or queue_id=%u\n",
> + port_id, queue_id);
> + return 0;
> + }
> +#endif
> +
> + /* fetch pointer to queue data */
> + p = &rte_eth_fp_ops[port_id];
> + qd = p->txq.data[queue_id];
>
> #ifdef RTE_ETHDEV_DEBUG_TX
> RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
> - RTE_FUNC_PTR_OR_ERR_RET(*dev->tx_pkt_burst, 0);
>
> - if (queue_id >= dev->data->nb_tx_queues) {
> - RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u\n", queue_id);
> + if (qd == NULL) {
> + RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u for port_id=%u\n",
TX -> Tx
> + queue_id, port_id);
> return 0;
> }
> #endif
>
> #ifdef RTE_ETHDEV_RXTX_CALLBACKS
> - struct rte_eth_rxtx_callback *cb;
>
> /* __ATOMIC_RELEASE memory order was used when the
> * call back was inserted into the list.
> @@ -5277,21 +5377,16 @@ rte_eth_tx_burst(uint16_t port_id, uint16_t queue_id,
> * cb and cb->fn/cb->next, __ATOMIC_ACQUIRE memory order is
> * not required.
> */
> - cb = __atomic_load_n(&dev->pre_tx_burst_cbs[queue_id],
> - __ATOMIC_RELAXED);
> -
> - if (unlikely(cb != NULL)) {
> - do {
> - nb_pkts = cb->fn.tx(port_id, queue_id, tx_pkts, nb_pkts,
> - cb->param);
> - cb = cb->next;
> - } while (cb != NULL);
> - }
> + cb = __atomic_load_n((void **)&p->txq.clbk[queue_id], __ATOMIC_RELAXED);
> + if (unlikely(cb != NULL))
> + nb_pkts = rte_eth_call_tx_callbacks(port_id, queue_id, tx_pkts,
> + nb_pkts, cb);
> #endif
>
> - rte_ethdev_trace_tx_burst(port_id, queue_id, (void **)tx_pkts,
> - nb_pkts);
> - return (*dev->tx_pkt_burst)(dev->data->tx_queues[queue_id], tx_pkts, nb_pkts);
> + nb_pkts = p->tx_pkt_burst(qd, tx_pkts, nb_pkts);
> +
> + rte_ethdev_trace_tx_burst(port_id, queue_id, (void **)tx_pkts, nb_pkts);
> + return nb_pkts;
> }
>
> /**
> @@ -5354,31 +5449,42 @@ static inline uint16_t
> rte_eth_tx_prepare(uint16_t port_id, uint16_t queue_id,
> struct rte_mbuf **tx_pkts, uint16_t nb_pkts)
> {
> - struct rte_eth_dev *dev;
> + struct rte_eth_fp_ops *p;
> + void *qd;
p->fpo, qd->txq
>
> #ifdef RTE_ETHDEV_DEBUG_TX
> - if (!rte_eth_dev_is_valid_port(port_id)) {
> - RTE_ETHDEV_LOG(ERR, "Invalid TX port_id=%u\n", port_id);
> + if (port_id >= RTE_MAX_ETHPORTS ||
> + queue_id >= RTE_MAX_QUEUES_PER_PORT) {
> + RTE_ETHDEV_LOG(ERR,
> + "Invalid port_id=%u or queue_id=%u\n",
> + port_id, queue_id);
> rte_errno = ENODEV;
> return 0;
> }
> #endif
>
> - dev = &rte_eth_devices[port_id];
> + /* fetch pointer to queue data */
> + p = &rte_eth_fp_ops[port_id];
> + qd = p->txq.data[queue_id];
>
> #ifdef RTE_ETHDEV_DEBUG_TX
> - if (queue_id >= dev->data->nb_tx_queues) {
> - RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u\n", queue_id);
> + if (!rte_eth_dev_is_valid_port(port_id)) {
> + RTE_ETHDEV_LOG(ERR, "Invalid TX port_id=%u\n", port_id);
TX -> Tx
> + rte_errno = ENODEV;
> + return 0;
> + }
> + if (qd == NULL) {
> + RTE_ETHDEV_LOG(ERR, "Invalid TX queue_id=%u for port_id=%u\n",
TX -> Tx
> + queue_id, port_id);
> rte_errno = EINVAL;
> return 0;
> }
> #endif
>
> - if (!dev->tx_pkt_prepare)
> + if (!p->tx_pkt_prepare)
Please, change it to compare vs NULL since you touch the line.
Just to be consistent with DPDK coding style and lines above.
> return nb_pkts;
>
> - return (*dev->tx_pkt_prepare)(dev->data->tx_queues[queue_id],
> - tx_pkts, nb_pkts);
> + return p->tx_pkt_prepare(qd, tx_pkts, nb_pkts);
> }
>
> #else
> diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map
> index 904bce6ea1..79e62dcf61 100644
> --- a/lib/ethdev/version.map
> +++ b/lib/ethdev/version.map
> @@ -7,6 +7,8 @@ DPDK_22 {
> rte_eth_allmulticast_disable;
> rte_eth_allmulticast_enable;
> rte_eth_allmulticast_get;
> + rte_eth_call_rx_callbacks;
> + rte_eth_call_tx_callbacks;
> rte_eth_dev_adjust_nb_rx_tx_desc;
> rte_eth_dev_callback_register;
> rte_eth_dev_callback_unregister;
> @@ -76,6 +78,7 @@ DPDK_22 {
> rte_eth_find_next_of;
> rte_eth_find_next_owned_by;
> rte_eth_find_next_sibling;
> + rte_eth_fp_ops;
> rte_eth_iterator_cleanup;
> rte_eth_iterator_init;
> rte_eth_iterator_next;
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 4/7] ethdev: copy fast-path API into separate structure
2021-10-09 12:05 0% ` fengchengwen
2021-10-11 1:18 0% ` fengchengwen
@ 2021-10-11 8:35 0% ` Andrew Rybchenko
2021-10-11 15:15 0% ` Ananyev, Konstantin
2 siblings, 0 replies; 200+ results
From: Andrew Rybchenko @ 2021-10-11 8:35 UTC (permalink / raw)
To: fengchengwen, Konstantin Ananyev, dev
Cc: xiaoyun.li, anoobj, jerinj, ndabilpuram, adwivedi,
shepard.siegel, ed.czeck, john.miller, irusskikh, ajit.khaparde,
somnath.kotur, rahul.lakkireddy, hemant.agrawal, sachin.saxena,
haiyue.wang, johndale, hyonkim, qi.z.zhang, xiao.w.wang, humin29,
yisen.zhuang, oulijun, beilei.xing, jingjing.wu, qiming.yang,
matan, viacheslavo, sthemmin, longli, heinrich.kuhn, kirankumark,
mczekaj, jiawenwu, jianwang, maxime.coquelin, chenbo.xia, thomas,
ferruh.yigit, mdr, jay.jayatheerthan
On 10/9/21 3:05 PM, fengchengwen wrote:
> On 2021/10/7 19:27, Konstantin Ananyev wrote:
>> Copy public function pointers (rx_pkt_burst(), etc.) and related
>> pointers to internal data from rte_eth_dev structure into a
>> separate flat array. That array will remain in a public header.
>> The intention here is to make rte_eth_dev and related structures internal.
>> That should allow future possible changes to core eth_dev structures
>> to be transparent to the user and help to avoid ABI/API breakages.
>> The plan is to keep minimal part of data from rte_eth_dev public,
>> so we still can use inline functions for fast-path calls
>> (like rte_eth_rx_burst(), etc.) to avoid/minimize slowdown.
>> The whole idea beyond this new schema:
>> 1. PMDs keep to setup fast-path function pointers and related data
>> inside rte_eth_dev struct in the same way they did it before.
>> 2. Inside rte_eth_dev_start() and inside rte_eth_dev_probing_finish()
>> (for secondary process) we call eth_dev_fp_ops_setup, which
>> copies these function and data pointers into rte_eth_fp_ops[port_id].
>> 3. Inside rte_eth_dev_stop() and inside rte_eth_dev_release_port()
>> we call eth_dev_fp_ops_reset(), which resets rte_eth_fp_ops[port_id]
>> into some dummy values.
>> 4. fast-path ethdev API (rte_eth_rx_burst(), etc.) will use that new
>> flat array to call PMD specific functions.
>> That approach should allow us to make rte_eth_devices[] private
>> without introducing regression and help to avoid changes in drivers code.
>>
>> Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
>> ---
>> lib/ethdev/ethdev_private.c | 52 ++++++++++++++++++++++++++++++++++
>> lib/ethdev/ethdev_private.h | 7 +++++
>> lib/ethdev/rte_ethdev.c | 27 ++++++++++++++++++
>> lib/ethdev/rte_ethdev_core.h | 55 ++++++++++++++++++++++++++++++++++++
>> 4 files changed, 141 insertions(+)
>>
>> diff --git a/lib/ethdev/ethdev_private.c b/lib/ethdev/ethdev_private.c
>> index 012cf73ca2..3eeda6e9f9 100644
>> --- a/lib/ethdev/ethdev_private.c
>> +++ b/lib/ethdev/ethdev_private.c
>> @@ -174,3 +174,55 @@ rte_eth_devargs_parse_representor_ports(char *str, void *data)
>> RTE_LOG(ERR, EAL, "wrong representor format: %s\n", str);
>> return str == NULL ? -1 : 0;
>> }
>> +
>> +static uint16_t
>> +dummy_eth_rx_burst(__rte_unused void *rxq,
>> + __rte_unused struct rte_mbuf **rx_pkts,
>> + __rte_unused uint16_t nb_pkts)
>> +{
>> + RTE_ETHDEV_LOG(ERR, "rx_pkt_burst for unconfigured port\n");
>> + rte_errno = ENOTSUP;
>> + return 0;
>> +}
>> +
>> +static uint16_t
>> +dummy_eth_tx_burst(__rte_unused void *txq,
>> + __rte_unused struct rte_mbuf **tx_pkts,
>> + __rte_unused uint16_t nb_pkts)
>> +{
>> + RTE_ETHDEV_LOG(ERR, "tx_pkt_burst for unconfigured port\n");
>> + rte_errno = ENOTSUP;
>> + return 0;
>> +}
>> +
>> +void
>> +eth_dev_fp_ops_reset(struct rte_eth_fp_ops *fpo)
>
> The port_id parameter is preferable, this will hide rte_eth_fp_ops as much as possible.
Sorry, but I see no point to hide it inside ethdev.
Of course, prototype should be reconsidered if we make
it ethdev-internal API available for drivers.
If so, I agree that the parameter should be port_id.
[snip]
>> diff --git a/lib/ethdev/ethdev_private.h b/lib/ethdev/ethdev_private.h
>> index 3724429577..5721be7bdc 100644
>> --- a/lib/ethdev/ethdev_private.h
>> +++ b/lib/ethdev/ethdev_private.h
>> @@ -26,4 +26,11 @@ eth_find_device(const struct rte_eth_dev *_start, rte_eth_cmp_t cmp,
>> /* Parse devargs value for representor parameter. */
>> int rte_eth_devargs_parse_representor_ports(char *str, void *data);
>>
>> +/* reset eth fast-path API to dummy values */
>> +void eth_dev_fp_ops_reset(struct rte_eth_fp_ops *fpo);
>> +
>> +/* setup eth fast-path API to ethdev values */
>> +void eth_dev_fp_ops_setup(struct rte_eth_fp_ops *fpo,
>> + const struct rte_eth_dev *dev);
>
> Some drivers control the transmit/receive function during operation. E.g.
> for hns3 driver, when detect reset, primary process will set rx/tx burst to dummy, after
> process reset, primary process will set the correct rx/tx burst. During this process, the
> send and receive threads are still working, but the bursts they call are changed. So:
> 1. it is recommended that trace be deleted from the dummy function.
> 2. public the eth_dev_fp_ops_reset/setup interface for driver usage.
Good point.
[snip]
>> diff --git a/lib/ethdev/rte_ethdev_core.h b/lib/ethdev/rte_ethdev_core.h
>> index 51cd68de94..d5853dff86 100644
>> --- a/lib/ethdev/rte_ethdev_core.h
>> +++ b/lib/ethdev/rte_ethdev_core.h
>> @@ -50,6 +50,61 @@ typedef int (*eth_rx_descriptor_status_t)(void *rxq, uint16_t offset);
>> typedef int (*eth_tx_descriptor_status_t)(void *txq, uint16_t offset);
>> /**< @internal Check the status of a Tx descriptor */
>>
>> +/**
>> + * @internal
>> + * Structure used to hold opaque pointers to internal ethdev Rx/Tx
>> + * queues data.
>> + * The main purpose to expose these pointers at all - allow compiler
>> + * to fetch this data for fast-path ethdev inline functions in advance.
>> + */
>> +struct rte_ethdev_qdata {
>> + void **data;
>> + /**< points to array of internal queue data pointers */
>> + void **clbk;
>> + /**< points to array of queue callback data pointers */
>> +};
>> +
>> +/**
>> + * @internal
>> + * fast-path ethdev functions and related data are hold in a flat array.
>> + * One entry per ethdev.
>> + * On 64-bit systems contents of this structure occupy exactly two 64B lines.
>> + * On 32-bit systems contents of this structure fits into one 64B line.
>> + */
>> +struct rte_eth_fp_ops {
>> +
>> + /**
>> + * Rx fast-path functions and related data.
>> + * 64-bit systems: occupies first 64B line
>> + */
>> + eth_rx_burst_t rx_pkt_burst;
>> + /**< PMD receive function. */
>> + eth_rx_queue_count_t rx_queue_count;
>> + /**< Get the number of used RX descriptors. */
>> + eth_rx_descriptor_status_t rx_descriptor_status;
>> + /**< Check the status of a Rx descriptor. */
>> + struct rte_ethdev_qdata rxq;
>> + /**< Rx queues data. */
>> + uintptr_t reserved1[3];
>> +
>> + /**
>> + * Tx fast-path functions and related data.
>> + * 64-bit systems: occupies second 64B line
>> + */
>> + eth_tx_burst_t tx_pkt_burst;
>
> Why not place rx_pkt_burst/tx_pkt_burst/rxq /txq to the first cacheline ?
> Other function, e.g. rx_queue_count/descriptor_status are low frequency call functions.
+1 Very good question
If so, tx_pkt_prepare should be on the first cache-line
as well.
>> + /**< PMD transmit function. */
>> + eth_tx_prep_t tx_pkt_prepare;
>> + /**< PMD transmit prepare function. */
>> + eth_tx_descriptor_status_t tx_descriptor_status;
>> + /**< Check the status of a Tx descriptor. */
>> + struct rte_ethdev_qdata txq;
>> + /**< Tx queues data. */
>> + uintptr_t reserved2[3];
>> +
>> +} __rte_cache_aligned;
>> +
>> +extern struct rte_eth_fp_ops rte_eth_fp_ops[RTE_MAX_ETHPORTS];
>> +
>>
>> /**
>> * @internal
>>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 3/3] security: add reserved bitfields
2021-10-08 20:45 3% ` [dpdk-dev] [PATCH v2 3/3] security: add reserved bitfields Akhil Goyal
@ 2021-10-11 8:31 0% ` Thomas Monjalon
2021-10-11 16:58 0% ` [dpdk-dev] [EXT] " Akhil Goyal
2021-10-12 8:50 0% ` [dpdk-dev] " Kinsella, Ray
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2021-10-11 8:31 UTC (permalink / raw)
To: Akhil Goyal
Cc: dev, david.marchand, hemant.agrawal, anoobj,
pablo.de.lara.guarch, fiona.trahe, declan.doherty, matan,
g.singh, roy.fan.zhang, jianjay.zhou, asomalap, ruifeng.wang,
konstantin.ananyev, radu.nicolau, ajit.khaparde, rnagadheeraj,
adwivedi, ciara.power, Stephen Hemminger, ray.kinsella,
bruce.richardson
08/10/2021 22:45, Akhil Goyal:
> In struct rte_security_ipsec_sa_options, for every new option
> added, there is an ABI breakage, to avoid, a reserved_opts
> bitfield is added to for the remaining bits available in the
> structure.
> Now for every new sa option, these reserved_opts can be reduced
> and new option can be added.
How do you make sure this field is initialized to 0?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3 1/2] lib/cmdline: release cl when cmdline exit
2021-10-08 6:41 4% ` [dpdk-dev] [PATCH v3 1/2] lib/cmdline: release cl when cmdline exit zhihongx.peng
2021-10-11 5:20 0% ` Peng, ZhihongX
@ 2021-10-11 8:25 0% ` Dmitry Kozlyuk
2021-10-13 1:53 0% ` Peng, ZhihongX
2021-10-13 1:52 4% ` [dpdk-dev] [PATCH v4 " zhihongx.peng
2 siblings, 1 reply; 200+ results
From: Dmitry Kozlyuk @ 2021-10-11 8:25 UTC (permalink / raw)
To: zhihongx.peng; +Cc: olivier.matz, dev, stable
2021-10-08 06:41 (UTC+0000), zhihongx.peng@intel.com:
> From: Zhihong Peng <zhihongx.peng@intel.com>
>
> Malloc cl in the cmdline_stdin_new function, so release in the
> cmdline_stdin_exit function is logical, so that cl will not be
> released alone.
>
> Fixes: af75078fece3 (first public release)
> Cc: stable@dpdk.org
As I have explained before, backporting this will introduce a double-free bug
in user apps unless their code are fixed, so it must not be done.
>
> Signed-off-by: Zhihong Peng <zhihongx.peng@intel.com>
> ---
> doc/guides/rel_notes/release_21_11.rst | 5 +++++
> lib/cmdline/cmdline_socket.c | 1 +
> 2 files changed, 6 insertions(+)
>
> diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
> index efeffe37a0..be24925d16 100644
> --- a/doc/guides/rel_notes/release_21_11.rst
> +++ b/doc/guides/rel_notes/release_21_11.rst
> @@ -191,6 +191,11 @@ API Changes
> the crypto/security operation. This field will be used to communicate
> events such as soft expiry with IPsec in lookaside mode.
>
> +* cmdline: The API cmdline_stdin_exit has added cmdline_free function.
> + Malloc cl in the cmdline_stdin_new function, so release in the
> + cmdline_stdin_exit function is logical. The application code
> + that calls cmdline_free needs to be deleted.
> +
There's probably no need to go into such details, suggestion:
* cmdline: ``cmdline_stdin_exit()`` now frees the ``cmdline`` structure.
Calls to ``cmdline_free()`` after it need to be deleted from applications.
>
> ABI Changes
> -----------
> diff --git a/lib/cmdline/cmdline_socket.c b/lib/cmdline/cmdline_socket.c
> index 998e8ade25..ebd5343754 100644
> --- a/lib/cmdline/cmdline_socket.c
> +++ b/lib/cmdline/cmdline_socket.c
> @@ -53,4 +53,5 @@ cmdline_stdin_exit(struct cmdline *cl)
> return;
>
> terminal_restore(cl);
> + cmdline_free(cl);
> }
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 4/7] ethdev: copy fast-path API into separate structure
2021-10-09 12:05 0% ` fengchengwen
@ 2021-10-11 8:25 0% ` Andrew Rybchenko
2021-10-11 16:52 0% ` Ananyev, Konstantin
1 sibling, 1 reply; 200+ results
From: Andrew Rybchenko @ 2021-10-11 8:25 UTC (permalink / raw)
To: Konstantin Ananyev, dev
Cc: xiaoyun.li, anoobj, jerinj, ndabilpuram, adwivedi,
shepard.siegel, ed.czeck, john.miller, irusskikh, ajit.khaparde,
somnath.kotur, rahul.lakkireddy, hemant.agrawal, sachin.saxena,
haiyue.wang, johndale, hyonkim, qi.z.zhang, xiao.w.wang, humin29,
yisen.zhuang, oulijun, beilei.xing, jingjing.wu, qiming.yang,
matan, viacheslavo, sthemmin, longli, heinrich.kuhn, kirankumark,
mczekaj, jiawenwu, jianwang, maxime.coquelin, chenbo.xia, thomas,
ferruh.yigit, mdr, jay.jayatheerthan
On 10/7/21 2:27 PM, Konstantin Ananyev wrote:
> Copy public function pointers (rx_pkt_burst(), etc.) and related
> pointers to internal data from rte_eth_dev structure into a
> separate flat array. That array will remain in a public header.
> The intention here is to make rte_eth_dev and related structures internal.
> That should allow future possible changes to core eth_dev structures
> to be transparent to the user and help to avoid ABI/API breakages.
> The plan is to keep minimal part of data from rte_eth_dev public,
> so we still can use inline functions for fast-path calls
> (like rte_eth_rx_burst(), etc.) to avoid/minimize slowdown.
> The whole idea beyond this new schema:
> 1. PMDs keep to setup fast-path function pointers and related data
> inside rte_eth_dev struct in the same way they did it before.
> 2. Inside rte_eth_dev_start() and inside rte_eth_dev_probing_finish()
> (for secondary process) we call eth_dev_fp_ops_setup, which
> copies these function and data pointers into rte_eth_fp_ops[port_id].
> 3. Inside rte_eth_dev_stop() and inside rte_eth_dev_release_port()
> we call eth_dev_fp_ops_reset(), which resets rte_eth_fp_ops[port_id]
> into some dummy values.
> 4. fast-path ethdev API (rte_eth_rx_burst(), etc.) will use that new
> flat array to call PMD specific functions.
> That approach should allow us to make rte_eth_devices[] private
> without introducing regression and help to avoid changes in drivers code.
>
> Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
Overall LGTM, few nits below.
> ---
> lib/ethdev/ethdev_private.c | 52 ++++++++++++++++++++++++++++++++++
> lib/ethdev/ethdev_private.h | 7 +++++
> lib/ethdev/rte_ethdev.c | 27 ++++++++++++++++++
> lib/ethdev/rte_ethdev_core.h | 55 ++++++++++++++++++++++++++++++++++++
> 4 files changed, 141 insertions(+)
>
> diff --git a/lib/ethdev/ethdev_private.c b/lib/ethdev/ethdev_private.c
> index 012cf73ca2..3eeda6e9f9 100644
> --- a/lib/ethdev/ethdev_private.c
> +++ b/lib/ethdev/ethdev_private.c
> @@ -174,3 +174,55 @@ rte_eth_devargs_parse_representor_ports(char *str, void *data)
> RTE_LOG(ERR, EAL, "wrong representor format: %s\n", str);
> return str == NULL ? -1 : 0;
> }
> +
> +static uint16_t
> +dummy_eth_rx_burst(__rte_unused void *rxq,
> + __rte_unused struct rte_mbuf **rx_pkts,
> + __rte_unused uint16_t nb_pkts)
> +{
> + RTE_ETHDEV_LOG(ERR, "rx_pkt_burst for unconfigured port\n");
May be "unconfigured" -> "stopped" ? Or "non-started" ?
> + rte_errno = ENOTSUP;
> + return 0;
> +}
> +
> +static uint16_t
> +dummy_eth_tx_burst(__rte_unused void *txq,
> + __rte_unused struct rte_mbuf **tx_pkts,
> + __rte_unused uint16_t nb_pkts)
> +{
> + RTE_ETHDEV_LOG(ERR, "tx_pkt_burst for unconfigured port\n");
May be "unconfigured" -> "stopped" ?
> + rte_errno = ENOTSUP;
> + return 0;
> +}
> +
> +void
> +eth_dev_fp_ops_reset(struct rte_eth_fp_ops *fpo)
> +{
> + static void *dummy_data[RTE_MAX_QUEUES_PER_PORT];
> + static const struct rte_eth_fp_ops dummy_ops = {
> + .rx_pkt_burst = dummy_eth_rx_burst,
> + .tx_pkt_burst = dummy_eth_tx_burst,
> + .rxq = {.data = dummy_data, .clbk = dummy_data,},
> + .txq = {.data = dummy_data, .clbk = dummy_data,},
> + };
> +
> + *fpo = dummy_ops;
> +}
> +
> +void
> +eth_dev_fp_ops_setup(struct rte_eth_fp_ops *fpo,
> + const struct rte_eth_dev *dev)
> +{
> + fpo->rx_pkt_burst = dev->rx_pkt_burst;
> + fpo->tx_pkt_burst = dev->tx_pkt_burst;
> + fpo->tx_pkt_prepare = dev->tx_pkt_prepare;
> + fpo->rx_queue_count = dev->rx_queue_count;
> + fpo->rx_descriptor_status = dev->rx_descriptor_status;
> + fpo->tx_descriptor_status = dev->tx_descriptor_status;
> +
> + fpo->rxq.data = dev->data->rx_queues;
> + fpo->rxq.clbk = (void **)(uintptr_t)dev->post_rx_burst_cbs;
> +
> + fpo->txq.data = dev->data->tx_queues;
> + fpo->txq.clbk = (void **)(uintptr_t)dev->pre_tx_burst_cbs;
> +}
> diff --git a/lib/ethdev/ethdev_private.h b/lib/ethdev/ethdev_private.h
> index 3724429577..5721be7bdc 100644
> --- a/lib/ethdev/ethdev_private.h
> +++ b/lib/ethdev/ethdev_private.h
> @@ -26,4 +26,11 @@ eth_find_device(const struct rte_eth_dev *_start, rte_eth_cmp_t cmp,
> /* Parse devargs value for representor parameter. */
> int rte_eth_devargs_parse_representor_ports(char *str, void *data);
>
> +/* reset eth fast-path API to dummy values */
> +void eth_dev_fp_ops_reset(struct rte_eth_fp_ops *fpo);
> +
> +/* setup eth fast-path API to ethdev values */
> +void eth_dev_fp_ops_setup(struct rte_eth_fp_ops *fpo,
> + const struct rte_eth_dev *dev);
> +
> #endif /* _ETH_PRIVATE_H_ */
> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
> index c8abda6dd7..9f7a0cbb8c 100644
> --- a/lib/ethdev/rte_ethdev.c
> +++ b/lib/ethdev/rte_ethdev.c
> @@ -44,6 +44,9 @@
> static const char *MZ_RTE_ETH_DEV_DATA = "rte_eth_dev_data";
> struct rte_eth_dev rte_eth_devices[RTE_MAX_ETHPORTS];
>
> +/* public fast-path API */
Shoudn't it be a doxygen style comment?
> +struct rte_eth_fp_ops rte_eth_fp_ops[RTE_MAX_ETHPORTS];
> +
> /* spinlock for eth device callbacks */
> static rte_spinlock_t eth_dev_cb_lock = RTE_SPINLOCK_INITIALIZER;
>
[snip]
> diff --git a/lib/ethdev/rte_ethdev_core.h b/lib/ethdev/rte_ethdev_core.h
> index 51cd68de94..d5853dff86 100644
> --- a/lib/ethdev/rte_ethdev_core.h
> +++ b/lib/ethdev/rte_ethdev_core.h
> @@ -50,6 +50,61 @@ typedef int (*eth_rx_descriptor_status_t)(void *rxq, uint16_t offset);
> typedef int (*eth_tx_descriptor_status_t)(void *txq, uint16_t offset);
> /**< @internal Check the status of a Tx descriptor */
>
> +/**
> + * @internal
> + * Structure used to hold opaque pointers to internal ethdev Rx/Tx
> + * queues data.
> + * The main purpose to expose these pointers at all - allow compiler
> + * to fetch this data for fast-path ethdev inline functions in advance.
> + */
> +struct rte_ethdev_qdata {
> + void **data;
> + /**< points to array of internal queue data pointers */
Please, put the documentation on the same like or just
put documentation before the documented member.
> + void **clbk;
> + /**< points to array of queue callback data pointers */
> +};
> +
> +/**
> + * @internal
> + * fast-path ethdev functions and related data are hold in a flat array.
> + * One entry per ethdev.
> + * On 64-bit systems contents of this structure occupy exactly two 64B lines.
> + * On 32-bit systems contents of this structure fits into one 64B line.
> + */
> +struct rte_eth_fp_ops {
> +
> + /**
> + * Rx fast-path functions and related data.
> + * 64-bit systems: occupies first 64B line
> + */
As I understand the above comment is for a group of below
fields. If so, Doxygen annocation for member groups should
be used.
> + eth_rx_burst_t rx_pkt_burst;
> + /**< PMD receive function. */
May I ask to avoid usage of documentation after member in a
separate line. It makes sense to if it is located in the same
line, but otherwise, it should be simply put before the
documented member.
[snip]
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v7 0/2] Support IOMMU for DMA device
@ 2021-10-11 7:59 3% ` Xuan Ding
0 siblings, 0 replies; 200+ results
From: Xuan Ding @ 2021-10-11 7:59 UTC (permalink / raw)
To: dev, anatoly.burakov, maxime.coquelin, chenbo.xia
Cc: jiayu.hu, cheng1.jiang, bruce.richardson, sunil.pai.g,
yinan.wang, yvonnex.yang, Xuan Ding
This series supports DMA device to use vfio in async vhost.
The first patch extends the capability of current vfio dma mapping
API to allow partial unmapping for adjacent memory if the platform
does not support partial unmapping. The second patch involves the
IOMMU programming for guest memory in async vhost.
v7:
* Fix an operator error.
v6:
* Fix a potential memory leak.
v5:
* Fix issue of a pointer be freed early.
v4:
* Fix a format issue.
v3:
* Move the async_map_status flag to virtio_net structure to avoid
ABI breaking.
v2:
* Add rte_errno filtering for some devices bound in the kernel driver.
* Add a flag to check the status of region mapping.
* Fix one typo.
Xuan Ding (2):
vfio: allow partially unmapping adjacent memory
vhost: enable IOMMU for async vhost
lib/eal/linux/eal_vfio.c | 338 ++++++++++++++++++++++++++-------------
lib/vhost/vhost.h | 4 +
lib/vhost/vhost_user.c | 116 +++++++++++++-
3 files changed, 346 insertions(+), 112 deletions(-)
--
2.17.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 3/7] ethdev: change input parameters for rx_queue_count
@ 2021-10-11 8:06 0% ` Andrew Rybchenko
2021-10-12 17:59 0% ` Hyong Youb Kim (hyonkim)
1 sibling, 0 replies; 200+ results
From: Andrew Rybchenko @ 2021-10-11 8:06 UTC (permalink / raw)
To: Konstantin Ananyev, dev
Cc: xiaoyun.li, anoobj, jerinj, ndabilpuram, adwivedi,
shepard.siegel, ed.czeck, john.miller, irusskikh, ajit.khaparde,
somnath.kotur, rahul.lakkireddy, hemant.agrawal, sachin.saxena,
haiyue.wang, johndale, hyonkim, qi.z.zhang, xiao.w.wang, humin29,
yisen.zhuang, oulijun, beilei.xing, jingjing.wu, qiming.yang,
matan, viacheslavo, sthemmin, longli, heinrich.kuhn, kirankumark,
mczekaj, jiawenwu, jianwang, maxime.coquelin, chenbo.xia, thomas,
ferruh.yigit, mdr, jay.jayatheerthan
On 10/7/21 2:27 PM, Konstantin Ananyev wrote:
> Currently majority of fast-path ethdev ops take pointers to internal
> queue data structures as an input parameter.
> While eth_rx_queue_count() takes a pointer to rte_eth_dev and queue
> index.
> For future work to hide rte_eth_devices[] and friends it would be
> plausible to unify parameters list of all fast-path ethdev ops.
> This patch changes eth_rx_queue_count() to accept pointer to internal
> queue data as input parameter.
> While this change is transparent to user, it still counts as an ABI change,
> as eth_rx_queue_count_t is used by ethdev public inline function
> rte_eth_rx_queue_count().
>
> Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
Reviewed-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
The patch introduces a number usages of rte_eth_devices in
drivers. As I understand it is undesirable, but I don't
think it is a blocker of the patch series. It should be
addresses separately.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v9 0/5] Add PIE support for HQoS library
@ 2021-10-11 7:55 3% ` Liguzinski, WojciechX
2021-10-14 11:34 3% ` [dpdk-dev] [PATCH v10 " Liguzinski, WojciechX
0 siblings, 1 reply; 200+ results
From: Liguzinski, WojciechX @ 2021-10-11 7:55 UTC (permalink / raw)
To: dev, jasvinder.singh, cristian.dumitrescu; +Cc: megha.ajmera
DPDK sched library is equipped with mechanism that secures it from the bufferbloat problem
which is a situation when excess buffers in the network cause high latency and latency
variation. Currently, it supports RED for active queue management (which is designed
to control the queue length but it does not control latency directly and is now being
obsoleted). However, more advanced queue management is required to address this problem
and provide desirable quality of service to users.
This solution (RFC) proposes usage of new algorithm called "PIE" (Proportional Integral
controller Enhanced) that can effectively and directly control queuing latency to address
the bufferbloat problem.
The implementation of mentioned functionality includes modification of existing and
adding a new set of data structures to the library, adding PIE related APIs.
This affects structures in public API/ABI. That is why deprecation notice is going
to be prepared and sent.
Liguzinski, WojciechX (5):
sched: add PIE based congestion management
example/qos_sched: add PIE support
example/ip_pipeline: add PIE support
doc/guides/prog_guide: added PIE
app/test: add tests for PIE
app/test/autotest_data.py | 18 +
app/test/meson.build | 4 +
app/test/test_pie.c | 1065 ++++++++++++++++++
config/rte_config.h | 1 -
doc/guides/prog_guide/glossary.rst | 3 +
doc/guides/prog_guide/qos_framework.rst | 60 +-
doc/guides/prog_guide/traffic_management.rst | 13 +-
drivers/net/softnic/rte_eth_softnic_tm.c | 6 +-
examples/ip_pipeline/tmgr.c | 6 +-
examples/qos_sched/app_thread.c | 1 -
examples/qos_sched/cfg_file.c | 82 +-
examples/qos_sched/init.c | 7 +-
examples/qos_sched/profile.cfg | 196 ++--
lib/sched/meson.build | 10 +-
lib/sched/rte_pie.c | 86 ++
lib/sched/rte_pie.h | 398 +++++++
lib/sched/rte_sched.c | 228 ++--
lib/sched/rte_sched.h | 53 +-
lib/sched/version.map | 3 +
19 files changed, 2050 insertions(+), 190 deletions(-)
create mode 100644 app/test/test_pie.c
create mode 100644 lib/sched/rte_pie.c
create mode 100644 lib/sched/rte_pie.h
--
2.25.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs
2021-10-08 7:44 0% ` Liu, Changpeng
@ 2021-10-11 6:58 0% ` Xia, Chenbo
0 siblings, 0 replies; 200+ results
From: Xia, Chenbo @ 2021-10-11 6:58 UTC (permalink / raw)
To: Liu, Changpeng, David Marchand, Harris, James R
Cc: dev, ci, Aaron Conole, dpdklab, Zawadzki, Tomasz, alexeymar
Hi David & Changpeng,
> -----Original Message-----
> From: Liu, Changpeng <changpeng.liu@intel.com>
> Sent: Friday, October 8, 2021 3:45 PM
> To: David Marchand <david.marchand@redhat.com>; Harris, James R
> <james.r.harris@intel.com>
> Cc: Xia, Chenbo <chenbo.xia@intel.com>; dev@dpdk.org; ci@dpdk.org; Aaron
> Conole <aconole@redhat.com>; dpdklab <dpdklab@iol.unh.edu>; Zawadzki, Tomasz
> <tomasz.zawadzki@intel.com>; alexeymar@mellanox.com
> Subject: RE: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs
>
> Thanks, I have worked with Chenbo to address this issue before. After enable
> the `ALLOW_INTERNAL_API` option, it works now with SPDK.
>
> Another issue raised by Jim Harris is that for distro packaged DPDK, since
> this option isn't enabled by default, this will not allow SPDK
> to use the distro packaged DPDK after this release.
I think for this problem, we have two options: enable driver sdk by default or
let OSV configure the option when building distros. I'm fine with either option.
@David, What do you think?
Thanks,
Chenbo
>
> > -----Original Message-----
> > From: David Marchand <david.marchand@redhat.com>
> > Sent: Friday, October 8, 2021 3:08 PM
> > To: Liu, Changpeng <changpeng.liu@intel.com>
> > Cc: Xia, Chenbo <chenbo.xia@intel.com>; Harris, James R
> > <james.r.harris@intel.com>; dev@dpdk.org; ci@dpdk.org; Aaron Conole
> > <aconole@redhat.com>; dpdklab <dpdklab@iol.unh.edu>; Zawadzki, Tomasz
> > <tomasz.zawadzki@intel.com>; alexeymar@mellanox.com
> > Subject: Re: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs
> >
> > Hello,
> >
> > On Fri, Oct 8, 2021 at 8:15 AM Liu, Changpeng <changpeng.liu@intel.com>
> wrote:
> > >
> > > I tried the above DPDK patches, and got the following errors:
> > >
> > > pci.c:115:7: error: call to ‘rte_pci_read_config’ declared with attribute
> error:
> > Symbol is not public ABI
> > > 115 | rc = rte_pci_read_config(dev->dev_handle, value, len, offset);
> > > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > pci.c: In function ‘cfg_write_rte’:
> > > pci.c:125:7: error: call to ‘rte_pci_write_config’ declared with attribute
> error:
> > Symbol is not public ABI
> > > 125 | rc = rte_pci_write_config(dev->dev_handle, value, len, offset);
> > > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > pci.c: In function ‘register_rte_driver’:
> > > pci.c:375:2: error: call to ‘rte_pci_register’ declared with attribute
> error:
> > Symbol is not public ABI
> > > 375 | rte_pci_register(&driver->driver);
> >
> > I should have got this warning... but compilation passed fine for me.
> > Happy you tested it.
> >
> > >
> > > We may use the new added API to replace rte_pci_write_config and
> > rte_pci_read_config, but SPDK
> > > do require rte_pci_register().
> >
> > Since SPDK has a PCI driver, you'll need to compile code that calls
> > those PCI driver internal API with ALLOW_INTERNAL_API defined.
> > You can probably add a #define ALLOW_INTERNAL_API first thing (it's
> > important to have it defined before including any dpdk header) in
> > pci.c
> >
> > Another option, is to add it to lib/env_dpdk/env.mk:ENV_CFLAGS =
> > $(DPDK_INC) -DALLOW_EXPERIMENTAL_API.
> >
> > Can someone from SPDK take over this and sync with Chenbo?
> >
> >
> > Thanks.
> >
> > --
> > David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3 1/2] lib/cmdline: release cl when cmdline exit
2021-10-08 6:41 4% ` [dpdk-dev] [PATCH v3 1/2] lib/cmdline: release cl when cmdline exit zhihongx.peng
@ 2021-10-11 5:20 0% ` Peng, ZhihongX
2021-10-11 8:25 0% ` Dmitry Kozlyuk
2021-10-13 1:52 4% ` [dpdk-dev] [PATCH v4 " zhihongx.peng
2 siblings, 0 replies; 200+ results
From: Peng, ZhihongX @ 2021-10-11 5:20 UTC (permalink / raw)
To: dmitry.kozliuk; +Cc: dev, stable, olivier.matz
> -----Original Message-----
> From: Peng, ZhihongX <zhihongx.peng@intel.com>
> Sent: Friday, October 8, 2021 2:42 PM
> To: olivier.matz@6wind.com; dmitry.kozliuk@gmail.com
> Cc: dev@dpdk.org; Peng, ZhihongX <zhihongx.peng@intel.com>;
> stable@dpdk.org
> Subject: [PATCH v3 1/2] lib/cmdline: release cl when cmdline exit
>
> From: Zhihong Peng <zhihongx.peng@intel.com>
>
> Malloc cl in the cmdline_stdin_new function, so release in the
> cmdline_stdin_exit function is logical, so that cl will not be released alone.
>
> Fixes: af75078fece3 (first public release)
> Cc: stable@dpdk.org
>
> Signed-off-by: Zhihong Peng <zhihongx.peng@intel.com>
> ---
> doc/guides/rel_notes/release_21_11.rst | 5 +++++
> lib/cmdline/cmdline_socket.c | 1 +
> 2 files changed, 6 insertions(+)
>
> diff --git a/doc/guides/rel_notes/release_21_11.rst
> b/doc/guides/rel_notes/release_21_11.rst
> index efeffe37a0..be24925d16 100644
> --- a/doc/guides/rel_notes/release_21_11.rst
> +++ b/doc/guides/rel_notes/release_21_11.rst
> @@ -191,6 +191,11 @@ API Changes
> the crypto/security operation. This field will be used to communicate
> events such as soft expiry with IPsec in lookaside mode.
>
> +* cmdline: The API cmdline_stdin_exit has added cmdline_free function.
> + Malloc cl in the cmdline_stdin_new function, so release in the
> + cmdline_stdin_exit function is logical. The application code
> + that calls cmdline_free needs to be deleted.
> +
>
> ABI Changes
> -----------
> diff --git a/lib/cmdline/cmdline_socket.c b/lib/cmdline/cmdline_socket.c
> index 998e8ade25..ebd5343754 100644
> --- a/lib/cmdline/cmdline_socket.c
> +++ b/lib/cmdline/cmdline_socket.c
> @@ -53,4 +53,5 @@ cmdline_stdin_exit(struct cmdline *cl)
> return;
>
> terminal_restore(cl);
> + cmdline_free(cl);
> }
> --
> 2.25.1
Hi, kozliuk
Can you give me an ack, I have submitted v3, I have added the release notes.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v10 1/8] bbdev: add device info related to data endianness
@ 2021-10-11 4:32 4% ` nipun.gupta
0 siblings, 0 replies; 200+ results
From: nipun.gupta @ 2021-10-11 4:32 UTC (permalink / raw)
To: dev, gakhil, nicolas.chautru; +Cc: david.marchand, hemant.agrawal, Nipun Gupta
From: Nicolas Chautru <nicolas.chautru@intel.com>
Adding device information to capture explicitly the assumption
of the input/output data byte endianness being processed.
Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
doc/guides/rel_notes/release_21_11.rst | 1 +
drivers/baseband/acc100/rte_acc100_pmd.c | 1 +
drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 1 +
drivers/baseband/fpga_lte_fec/fpga_lte_fec.c | 1 +
drivers/baseband/null/bbdev_null.c | 6 ++++++
drivers/baseband/turbo_sw/bbdev_turbo_software.c | 1 +
lib/bbdev/rte_bbdev.h | 4 ++++
7 files changed, 15 insertions(+)
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index c0a7f75518..135aa467f2 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -194,6 +194,7 @@ API Changes
the crypto/security operation. This field will be used to communicate
events such as soft expiry with IPsec in lookaside mode.
+* bbdev: Added device info related to data byte endianness processing.
ABI Changes
-----------
diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c b/drivers/baseband/acc100/rte_acc100_pmd.c
index 68ba523ea9..361e06cf94 100644
--- a/drivers/baseband/acc100/rte_acc100_pmd.c
+++ b/drivers/baseband/acc100/rte_acc100_pmd.c
@@ -1088,6 +1088,7 @@ acc100_dev_info_get(struct rte_bbdev *dev,
#else
dev_info->harq_buffer_size = 0;
#endif
+ dev_info->data_endianness = RTE_LITTLE_ENDIAN;
acc100_check_ir(d);
}
diff --git a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
index 6485cc824a..ee457f3071 100644
--- a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
+++ b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
@@ -372,6 +372,7 @@ fpga_dev_info_get(struct rte_bbdev *dev,
dev_info->default_queue_conf = default_queue_conf;
dev_info->capabilities = bbdev_capabilities;
dev_info->cpu_flag_reqs = NULL;
+ dev_info->data_endianness = RTE_LITTLE_ENDIAN;
/* Calculates number of queues assigned to device */
dev_info->max_num_queues = 0;
diff --git a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
index 350c4248eb..703bb611a0 100644
--- a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
+++ b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
@@ -644,6 +644,7 @@ fpga_dev_info_get(struct rte_bbdev *dev,
dev_info->default_queue_conf = default_queue_conf;
dev_info->capabilities = bbdev_capabilities;
dev_info->cpu_flag_reqs = NULL;
+ dev_info->data_endianness = RTE_LITTLE_ENDIAN;
/* Calculates number of queues assigned to device */
dev_info->max_num_queues = 0;
diff --git a/drivers/baseband/null/bbdev_null.c b/drivers/baseband/null/bbdev_null.c
index 53c538ba44..753d920e18 100644
--- a/drivers/baseband/null/bbdev_null.c
+++ b/drivers/baseband/null/bbdev_null.c
@@ -77,6 +77,12 @@ info_get(struct rte_bbdev *dev, struct rte_bbdev_driver_info *dev_info)
dev_info->cpu_flag_reqs = NULL;
dev_info->min_alignment = 0;
+ /* BBDEV null device does not process the data, so
+ * endianness setting is not relevant, but setting it
+ * here for code completeness.
+ */
+ dev_info->data_endianness = RTE_LITTLE_ENDIAN;
+
rte_bbdev_log_debug("got device info from %u", dev->data->dev_id);
}
diff --git a/drivers/baseband/turbo_sw/bbdev_turbo_software.c b/drivers/baseband/turbo_sw/bbdev_turbo_software.c
index 77e9a2ecbc..7dfeec665a 100644
--- a/drivers/baseband/turbo_sw/bbdev_turbo_software.c
+++ b/drivers/baseband/turbo_sw/bbdev_turbo_software.c
@@ -251,6 +251,7 @@ info_get(struct rte_bbdev *dev, struct rte_bbdev_driver_info *dev_info)
dev_info->capabilities = bbdev_capabilities;
dev_info->min_alignment = 64;
dev_info->harq_buffer_size = 0;
+ dev_info->data_endianness = RTE_LITTLE_ENDIAN;
rte_bbdev_log_debug("got device info from %u\n", dev->data->dev_id);
}
diff --git a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h
index 3ebf62e697..e863bd913f 100644
--- a/lib/bbdev/rte_bbdev.h
+++ b/lib/bbdev/rte_bbdev.h
@@ -309,6 +309,10 @@ struct rte_bbdev_driver_info {
uint16_t min_alignment;
/** HARQ memory available in kB */
uint32_t harq_buffer_size;
+ /** Byte endianness (RTE_BIG_ENDIAN/RTE_LITTLE_ENDIAN) supported
+ * for input/output data
+ */
+ uint8_t data_endianness;
/** Default queue configuration used if none is supplied */
struct rte_bbdev_queue_conf default_queue_conf;
/** Device operation capabilities */
--
2.17.1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v5 4/7] ethdev: copy fast-path API into separate structure
2021-10-09 12:05 0% ` fengchengwen
@ 2021-10-11 1:18 0% ` fengchengwen
2021-10-11 8:35 0% ` Andrew Rybchenko
2021-10-11 15:15 0% ` Ananyev, Konstantin
2 siblings, 0 replies; 200+ results
From: fengchengwen @ 2021-10-11 1:18 UTC (permalink / raw)
To: Konstantin Ananyev, dev
Cc: xiaoyun.li, anoobj, jerinj, ndabilpuram, adwivedi,
shepard.siegel, ed.czeck, john.miller, irusskikh, ajit.khaparde,
somnath.kotur, rahul.lakkireddy, hemant.agrawal, sachin.saxena,
haiyue.wang, johndale, hyonkim, qi.z.zhang, xiao.w.wang, humin29,
yisen.zhuang, oulijun, beilei.xing, jingjing.wu, qiming.yang,
matan, viacheslavo, sthemmin, longli, heinrich.kuhn, kirankumark,
andrew.rybchenko, mczekaj, jiawenwu, jianwang, maxime.coquelin,
chenbo.xia, thomas, ferruh.yigit, mdr, jay.jayatheerthan
Sorry to self-reply.
I think it's better the 'struct rte_eth_dev *dev' hold a pointer to the
'struct rte_eth_fp_ops', e.g.
struct rte_eth_dev {
struct rte_eth_fp_ops *fp_ops;
... // other field
}
The eth framework set the pointer in the rte_eth_dev_pci_allocate(), and driver fill
corresponding callback:
dev->fp_ops->rx_pkt_burst = xxx_recv_pkts;
dev->fp_ops->tx_pkt_burst = xxx_xmit_pkts;
...
In this way, the behavior of the primary and secondary processes can be unified, which
is basically the same as that of the original process.
On 2021/10/9 20:05, fengchengwen wrote:
> On 2021/10/7 19:27, Konstantin Ananyev wrote:
>> Copy public function pointers (rx_pkt_burst(), etc.) and related
>> pointers to internal data from rte_eth_dev structure into a
>> separate flat array. That array will remain in a public header.
>> The intention here is to make rte_eth_dev and related structures internal.
>> That should allow future possible changes to core eth_dev structures
>> to be transparent to the user and help to avoid ABI/API breakages.
>> The plan is to keep minimal part of data from rte_eth_dev public,
>> so we still can use inline functions for fast-path calls
>> (like rte_eth_rx_burst(), etc.) to avoid/minimize slowdown.
>> The whole idea beyond this new schema:
>> 1. PMDs keep to setup fast-path function pointers and related data
>> inside rte_eth_dev struct in the same way they did it before.
>> 2. Inside rte_eth_dev_start() and inside rte_eth_dev_probing_finish()
>> (for secondary process) we call eth_dev_fp_ops_setup, which
>> copies these function and data pointers into rte_eth_fp_ops[port_id].
>> 3. Inside rte_eth_dev_stop() and inside rte_eth_dev_release_port()
>> we call eth_dev_fp_ops_reset(), which resets rte_eth_fp_ops[port_id]
>> into some dummy values.
>> 4. fast-path ethdev API (rte_eth_rx_burst(), etc.) will use that new
>> flat array to call PMD specific functions.
>> That approach should allow us to make rte_eth_devices[] private
>> without introducing regression and help to avoid changes in drivers code.
>>
>> Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
>> ---
>> lib/ethdev/ethdev_private.c | 52 ++++++++++++++++++++++++++++++++++
>> lib/ethdev/ethdev_private.h | 7 +++++
>> lib/ethdev/rte_ethdev.c | 27 ++++++++++++++++++
>> lib/ethdev/rte_ethdev_core.h | 55 ++++++++++++++++++++++++++++++++++++
>> 4 files changed, 141 insertions(+)
>>
>> diff --git a/lib/ethdev/ethdev_private.c b/lib/ethdev/ethdev_private.c
>> index 012cf73ca2..3eeda6e9f9 100644
>> --- a/lib/ethdev/ethdev_private.c
>> +++ b/lib/ethdev/ethdev_private.c
>> @@ -174,3 +174,55 @@ rte_eth_devargs_parse_representor_ports(char *str, void *data)
>> RTE_LOG(ERR, EAL, "wrong representor format: %s\n", str);
>> return str == NULL ? -1 : 0;
>> }
>> +
>> +static uint16_t
>> +dummy_eth_rx_burst(__rte_unused void *rxq,
>> + __rte_unused struct rte_mbuf **rx_pkts,
>> + __rte_unused uint16_t nb_pkts)
>> +{
>> + RTE_ETHDEV_LOG(ERR, "rx_pkt_burst for unconfigured port\n");
>> + rte_errno = ENOTSUP;
>> + return 0;
>> +}
>> +
>> +static uint16_t
>> +dummy_eth_tx_burst(__rte_unused void *txq,
>> + __rte_unused struct rte_mbuf **tx_pkts,
>> + __rte_unused uint16_t nb_pkts)
>> +{
>> + RTE_ETHDEV_LOG(ERR, "tx_pkt_burst for unconfigured port\n");
>> + rte_errno = ENOTSUP;
>> + return 0;
>> +}
>> +
>> +void
>> +eth_dev_fp_ops_reset(struct rte_eth_fp_ops *fpo)
>
> The port_id parameter is preferable, this will hide rte_eth_fp_ops as much as possible.
>
>> +{
>> + static void *dummy_data[RTE_MAX_QUEUES_PER_PORT];
>> + static const struct rte_eth_fp_ops dummy_ops = {
>> + .rx_pkt_burst = dummy_eth_rx_burst,
>> + .tx_pkt_burst = dummy_eth_tx_burst,
>> + .rxq = {.data = dummy_data, .clbk = dummy_data,},
>> + .txq = {.data = dummy_data, .clbk = dummy_data,},
>> + };
>> +
>> + *fpo = dummy_ops;
>> +}
>> +
>> +void
>> +eth_dev_fp_ops_setup(struct rte_eth_fp_ops *fpo,
>> + const struct rte_eth_dev *dev)
>
> Because fp_ops and eth_dev is a one-to-one correspondence. It's better only use
> port_id parameter.
>
>> +{
>> + fpo->rx_pkt_burst = dev->rx_pkt_burst;
>> + fpo->tx_pkt_burst = dev->tx_pkt_burst;
>> + fpo->tx_pkt_prepare = dev->tx_pkt_prepare;
>> + fpo->rx_queue_count = dev->rx_queue_count;
>> + fpo->rx_descriptor_status = dev->rx_descriptor_status;
>> + fpo->tx_descriptor_status = dev->tx_descriptor_status;
>> +
>> + fpo->rxq.data = dev->data->rx_queues;
>> + fpo->rxq.clbk = (void **)(uintptr_t)dev->post_rx_burst_cbs;
>> +
>> + fpo->txq.data = dev->data->tx_queues;
>> + fpo->txq.clbk = (void **)(uintptr_t)dev->pre_tx_burst_cbs;
>> +}
>> diff --git a/lib/ethdev/ethdev_private.h b/lib/ethdev/ethdev_private.h
>> index 3724429577..5721be7bdc 100644
>> --- a/lib/ethdev/ethdev_private.h
>> +++ b/lib/ethdev/ethdev_private.h
>> @@ -26,4 +26,11 @@ eth_find_device(const struct rte_eth_dev *_start, rte_eth_cmp_t cmp,
>> /* Parse devargs value for representor parameter. */
>> int rte_eth_devargs_parse_representor_ports(char *str, void *data);
>>
>> +/* reset eth fast-path API to dummy values */
>> +void eth_dev_fp_ops_reset(struct rte_eth_fp_ops *fpo);
>> +
>> +/* setup eth fast-path API to ethdev values */
>> +void eth_dev_fp_ops_setup(struct rte_eth_fp_ops *fpo,
>> + const struct rte_eth_dev *dev);
>
> Some drivers control the transmit/receive function during operation. E.g.
> for hns3 driver, when detect reset, primary process will set rx/tx burst to dummy, after
> process reset, primary process will set the correct rx/tx burst. During this process, the
> send and receive threads are still working, but the bursts they call are changed. So:
> 1. it is recommended that trace be deleted from the dummy function.
> 2. public the eth_dev_fp_ops_reset/setup interface for driver usage.
>
>> +
>> #endif /* _ETH_PRIVATE_H_ */
>> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
>> index c8abda6dd7..9f7a0cbb8c 100644
>> --- a/lib/ethdev/rte_ethdev.c
>> +++ b/lib/ethdev/rte_ethdev.c
>> @@ -44,6 +44,9 @@
>> static const char *MZ_RTE_ETH_DEV_DATA = "rte_eth_dev_data";
>> struct rte_eth_dev rte_eth_devices[RTE_MAX_ETHPORTS];
>>
>> +/* public fast-path API */
>> +struct rte_eth_fp_ops rte_eth_fp_ops[RTE_MAX_ETHPORTS];
>> +
>> /* spinlock for eth device callbacks */
>> static rte_spinlock_t eth_dev_cb_lock = RTE_SPINLOCK_INITIALIZER;
>>
>> @@ -578,6 +581,8 @@ rte_eth_dev_release_port(struct rte_eth_dev *eth_dev)
>> rte_eth_dev_callback_process(eth_dev,
>> RTE_ETH_EVENT_DESTROY, NULL);
>>
>> + eth_dev_fp_ops_reset(rte_eth_fp_ops + eth_dev->data->port_id);
>> +
>> rte_spinlock_lock(ð_dev_shared_data->ownership_lock);
>>
>> eth_dev->state = RTE_ETH_DEV_UNUSED;
>> @@ -1787,6 +1792,9 @@ rte_eth_dev_start(uint16_t port_id)
>> (*dev->dev_ops->link_update)(dev, 0);
>> }
>>
>> + /* expose selection of PMD fast-path functions */
>> + eth_dev_fp_ops_setup(rte_eth_fp_ops + port_id, dev);
>> +
>> rte_ethdev_trace_start(port_id);
>> return 0;
>> }
>> @@ -1809,6 +1817,9 @@ rte_eth_dev_stop(uint16_t port_id)
>> return 0;
>> }
>>
>> + /* point fast-path functions to dummy ones */
>> + eth_dev_fp_ops_reset(rte_eth_fp_ops + port_id);
>> +
>> dev->data->dev_started = 0;
>> ret = (*dev->dev_ops->dev_stop)(dev);
>> rte_ethdev_trace_stop(port_id, ret);
>> @@ -4567,6 +4578,14 @@ rte_eth_mirror_rule_reset(uint16_t port_id, uint8_t rule_id)
>> return eth_err(port_id, (*dev->dev_ops->mirror_rule_reset)(dev, rule_id));
>> }
>>
>> +RTE_INIT(eth_dev_init_fp_ops)
>> +{
>> + uint32_t i;
>> +
>> + for (i = 0; i != RTE_DIM(rte_eth_fp_ops); i++)
>> + eth_dev_fp_ops_reset(rte_eth_fp_ops + i);
>> +}
>> +
>> RTE_INIT(eth_dev_init_cb_lists)
>> {
>> uint16_t i;
>> @@ -4735,6 +4754,14 @@ rte_eth_dev_probing_finish(struct rte_eth_dev *dev)
>> if (dev == NULL)
>> return;
>>
>> + /*
>> + * for secondary process, at that point we expect device
>> + * to be already 'usable', so shared data and all function pointers
>> + * for fast-path devops have to be setup properly inside rte_eth_dev.
>> + */
>> + if (rte_eal_process_type() == RTE_PROC_SECONDARY)
>> + eth_dev_fp_ops_setup(rte_eth_fp_ops + dev->data->port_id, dev);
>> +
>> rte_eth_dev_callback_process(dev, RTE_ETH_EVENT_NEW, NULL);
>>
>> dev->state = RTE_ETH_DEV_ATTACHED;
>> diff --git a/lib/ethdev/rte_ethdev_core.h b/lib/ethdev/rte_ethdev_core.h
>> index 51cd68de94..d5853dff86 100644
>> --- a/lib/ethdev/rte_ethdev_core.h
>> +++ b/lib/ethdev/rte_ethdev_core.h
>> @@ -50,6 +50,61 @@ typedef int (*eth_rx_descriptor_status_t)(void *rxq, uint16_t offset);
>> typedef int (*eth_tx_descriptor_status_t)(void *txq, uint16_t offset);
>> /**< @internal Check the status of a Tx descriptor */
>>
>> +/**
>> + * @internal
>> + * Structure used to hold opaque pointers to internal ethdev Rx/Tx
>> + * queues data.
>> + * The main purpose to expose these pointers at all - allow compiler
>> + * to fetch this data for fast-path ethdev inline functions in advance.
>> + */
>> +struct rte_ethdev_qdata {
>> + void **data;
>> + /**< points to array of internal queue data pointers */
>> + void **clbk;
>> + /**< points to array of queue callback data pointers */
>> +};
>> +
>> +/**
>> + * @internal
>> + * fast-path ethdev functions and related data are hold in a flat array.
>> + * One entry per ethdev.
>> + * On 64-bit systems contents of this structure occupy exactly two 64B lines.
>> + * On 32-bit systems contents of this structure fits into one 64B line.
>> + */
>> +struct rte_eth_fp_ops {
>> +
>> + /**
>> + * Rx fast-path functions and related data.
>> + * 64-bit systems: occupies first 64B line
>> + */
>> + eth_rx_burst_t rx_pkt_burst;
>> + /**< PMD receive function. */
>> + eth_rx_queue_count_t rx_queue_count;
>> + /**< Get the number of used RX descriptors. */
>> + eth_rx_descriptor_status_t rx_descriptor_status;
>> + /**< Check the status of a Rx descriptor. */
>> + struct rte_ethdev_qdata rxq;
>> + /**< Rx queues data. */
>> + uintptr_t reserved1[3];
>> +
>> + /**
>> + * Tx fast-path functions and related data.
>> + * 64-bit systems: occupies second 64B line
>> + */
>> + eth_tx_burst_t tx_pkt_burst;
>
> Why not place rx_pkt_burst/tx_pkt_burst/rxq /txq to the first cacheline ?
> Other function, e.g. rx_queue_count/descriptor_status are low frequency call functions.
>
>> + /**< PMD transmit function. */
>> + eth_tx_prep_t tx_pkt_prepare;
>> + /**< PMD transmit prepare function. */
>> + eth_tx_descriptor_status_t tx_descriptor_status;
>> + /**< Check the status of a Tx descriptor. */
>> + struct rte_ethdev_qdata txq;
>> + /**< Tx queues data. */
>> + uintptr_t reserved2[3];
>> +
>> +} __rte_cache_aligned;
>> +
>> +extern struct rte_eth_fp_ops rte_eth_fp_ops[RTE_MAX_ETHPORTS];
>> +
>>
>> /**
>> * @internal
>>
>
>
> .
>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v2 1/5] ethdev: update modify field flow action
@ 2021-10-10 23:45 8% ` Viacheslav Ovsiienko
2021-10-11 9:54 3% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Viacheslav Ovsiienko @ 2021-10-10 23:45 UTC (permalink / raw)
To: dev; +Cc: rasland, matan, shahafs, orika, getelson, thomas
The generic modify field flow action introduced in [1] has
some issues related to the immediate source operand:
- immediate source can be presented either as an unsigned
64-bit integer or pointer to data pattern in memory.
There was no explicit pointer field defined in the union.
- the byte ordering for 64-bit integer was not specified.
Many fields have shorter lengths and byte ordering
is crucial.
- how the bit offset is applied to the immediate source
field was not defined and documented.
- 64-bit integer size is not enough to provide IPv6
addresses.
In order to cover the issues and exclude any ambiguities
the following is done:
- introduce the explicit pointer field
in rte_flow_action_modify_data structure
- replace the 64-bit unsigned integer with 16-byte array
- update the modify field flow action documentation
[1] commit 73b68f4c54a0 ("ethdev: introduce generic modify flow action")
Signed-off-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
---
doc/guides/prog_guide/rte_flow.rst | 16 ++++++++++++++++
doc/guides/rel_notes/release_21_11.rst | 9 +++++++++
lib/ethdev/rte_flow.h | 17 ++++++++++++++---
3 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 2b42d5ec8c..1ceecb399f 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -2835,6 +2835,22 @@ a packet to any other part of it.
``value`` sets an immediate value to be used as a source or points to a
location of the value in memory. It is used instead of ``level`` and ``offset``
for ``RTE_FLOW_FIELD_VALUE`` and ``RTE_FLOW_FIELD_POINTER`` respectively.
+The data in memory should be presented exactly in the same byte order and
+length as in the relevant flow item, i.e. data for field with type
+RTE_FLOW_FIELD_MAC_DST should follow the conventions of dst field
+in rte_flow_item_eth structure, with type RTE_FLOW_FIELD_IPV6_SRC -
+rte_flow_item_ipv6 conventions, and so on. If the field size is large than
+16 bytes the pattern can be provided as pointer only.
+
+The bitfield extracted from the memory being applied as second operation
+parameter is defined by action width and by the destination field offset.
+Application should provide the data in immediate value memory (either as
+buffer or by pointer) exactly as item field without any applied explicit offset,
+and destination packet field (with specified width and bit offset) will be
+replaced by immediate source bits from the same bit offset. For example,
+to replace the third byte of MAC address with value 0x85, application should
+specify destination width as 8, destination width as 16, and provide immediate
+value as sequence of bytes {xxx, xxx, 0x85, xxx, xxx, xxx}.
.. _table_rte_flow_action_modify_field:
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index dfc2cbdeed..41a087d7c1 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -187,6 +187,13 @@ API Changes
the crypto/security operation. This field will be used to communicate
events such as soft expiry with IPsec in lookaside mode.
+* ethdev: ``rte_flow_action_modify_data`` structure udpdated, immediate data
+ array is extended, data pointer field is explicitly added to union, the
+ action behavior is defined in more strict fashion and documentation updated.
+ The immediate value behavior has been changed, the entire immediate field
+ should be provided, and offset for immediate source bitfield is assigned
+ from destination one.
+
ABI Changes
-----------
@@ -222,6 +229,8 @@ ABI Changes
``rte_security_ipsec_xform`` to allow applications to configure SA soft
and hard expiry limits. Limits can be either in number of packets or bytes.
+* ethdev: ``rte_flow_action_modify_data`` structure udpdated.
+
Known Issues
------------
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 7b1ed7f110..953924d42b 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -3204,6 +3204,9 @@ enum rte_flow_field_id {
};
/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
* Field description for MODIFY_FIELD action.
*/
struct rte_flow_action_modify_data {
@@ -3217,10 +3220,18 @@ struct rte_flow_action_modify_data {
uint32_t offset;
};
/**
- * Immediate value for RTE_FLOW_FIELD_VALUE or
- * memory address for RTE_FLOW_FIELD_POINTER.
+ * Immediate value for RTE_FLOW_FIELD_VALUE, presented in the
+ * same byte order and length as in relevant rte_flow_item_xxx.
+ * The immediate source bitfield offset is inherited from
+ * the destination's one.
*/
- uint64_t value;
+ uint8_t value[16];
+ /*
+ * Memory address for RTE_FLOW_FIELD_POINTER, memory layout
+ * should be the same as for relevant field in the
+ * rte_flow_item_xxx structure.
+ */
+ void *pvalue;
};
};
--
2.18.1
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [PATCH v5 4/7] ethdev: copy fast-path API into separate structure
@ 2021-10-09 12:05 0% ` fengchengwen
2021-10-11 1:18 0% ` fengchengwen
` (2 more replies)
2021-10-11 8:25 0% ` Andrew Rybchenko
1 sibling, 3 replies; 200+ results
From: fengchengwen @ 2021-10-09 12:05 UTC (permalink / raw)
To: Konstantin Ananyev, dev
Cc: xiaoyun.li, anoobj, jerinj, ndabilpuram, adwivedi,
shepard.siegel, ed.czeck, john.miller, irusskikh, ajit.khaparde,
somnath.kotur, rahul.lakkireddy, hemant.agrawal, sachin.saxena,
haiyue.wang, johndale, hyonkim, qi.z.zhang, xiao.w.wang, humin29,
yisen.zhuang, oulijun, beilei.xing, jingjing.wu, qiming.yang,
matan, viacheslavo, sthemmin, longli, heinrich.kuhn, kirankumark,
andrew.rybchenko, mczekaj, jiawenwu, jianwang, maxime.coquelin,
chenbo.xia, thomas, ferruh.yigit, mdr, jay.jayatheerthan
On 2021/10/7 19:27, Konstantin Ananyev wrote:
> Copy public function pointers (rx_pkt_burst(), etc.) and related
> pointers to internal data from rte_eth_dev structure into a
> separate flat array. That array will remain in a public header.
> The intention here is to make rte_eth_dev and related structures internal.
> That should allow future possible changes to core eth_dev structures
> to be transparent to the user and help to avoid ABI/API breakages.
> The plan is to keep minimal part of data from rte_eth_dev public,
> so we still can use inline functions for fast-path calls
> (like rte_eth_rx_burst(), etc.) to avoid/minimize slowdown.
> The whole idea beyond this new schema:
> 1. PMDs keep to setup fast-path function pointers and related data
> inside rte_eth_dev struct in the same way they did it before.
> 2. Inside rte_eth_dev_start() and inside rte_eth_dev_probing_finish()
> (for secondary process) we call eth_dev_fp_ops_setup, which
> copies these function and data pointers into rte_eth_fp_ops[port_id].
> 3. Inside rte_eth_dev_stop() and inside rte_eth_dev_release_port()
> we call eth_dev_fp_ops_reset(), which resets rte_eth_fp_ops[port_id]
> into some dummy values.
> 4. fast-path ethdev API (rte_eth_rx_burst(), etc.) will use that new
> flat array to call PMD specific functions.
> That approach should allow us to make rte_eth_devices[] private
> without introducing regression and help to avoid changes in drivers code.
>
> Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> ---
> lib/ethdev/ethdev_private.c | 52 ++++++++++++++++++++++++++++++++++
> lib/ethdev/ethdev_private.h | 7 +++++
> lib/ethdev/rte_ethdev.c | 27 ++++++++++++++++++
> lib/ethdev/rte_ethdev_core.h | 55 ++++++++++++++++++++++++++++++++++++
> 4 files changed, 141 insertions(+)
>
> diff --git a/lib/ethdev/ethdev_private.c b/lib/ethdev/ethdev_private.c
> index 012cf73ca2..3eeda6e9f9 100644
> --- a/lib/ethdev/ethdev_private.c
> +++ b/lib/ethdev/ethdev_private.c
> @@ -174,3 +174,55 @@ rte_eth_devargs_parse_representor_ports(char *str, void *data)
> RTE_LOG(ERR, EAL, "wrong representor format: %s\n", str);
> return str == NULL ? -1 : 0;
> }
> +
> +static uint16_t
> +dummy_eth_rx_burst(__rte_unused void *rxq,
> + __rte_unused struct rte_mbuf **rx_pkts,
> + __rte_unused uint16_t nb_pkts)
> +{
> + RTE_ETHDEV_LOG(ERR, "rx_pkt_burst for unconfigured port\n");
> + rte_errno = ENOTSUP;
> + return 0;
> +}
> +
> +static uint16_t
> +dummy_eth_tx_burst(__rte_unused void *txq,
> + __rte_unused struct rte_mbuf **tx_pkts,
> + __rte_unused uint16_t nb_pkts)
> +{
> + RTE_ETHDEV_LOG(ERR, "tx_pkt_burst for unconfigured port\n");
> + rte_errno = ENOTSUP;
> + return 0;
> +}
> +
> +void
> +eth_dev_fp_ops_reset(struct rte_eth_fp_ops *fpo)
The port_id parameter is preferable, this will hide rte_eth_fp_ops as much as possible.
> +{
> + static void *dummy_data[RTE_MAX_QUEUES_PER_PORT];
> + static const struct rte_eth_fp_ops dummy_ops = {
> + .rx_pkt_burst = dummy_eth_rx_burst,
> + .tx_pkt_burst = dummy_eth_tx_burst,
> + .rxq = {.data = dummy_data, .clbk = dummy_data,},
> + .txq = {.data = dummy_data, .clbk = dummy_data,},
> + };
> +
> + *fpo = dummy_ops;
> +}
> +
> +void
> +eth_dev_fp_ops_setup(struct rte_eth_fp_ops *fpo,
> + const struct rte_eth_dev *dev)
Because fp_ops and eth_dev is a one-to-one correspondence. It's better only use
port_id parameter.
> +{
> + fpo->rx_pkt_burst = dev->rx_pkt_burst;
> + fpo->tx_pkt_burst = dev->tx_pkt_burst;
> + fpo->tx_pkt_prepare = dev->tx_pkt_prepare;
> + fpo->rx_queue_count = dev->rx_queue_count;
> + fpo->rx_descriptor_status = dev->rx_descriptor_status;
> + fpo->tx_descriptor_status = dev->tx_descriptor_status;
> +
> + fpo->rxq.data = dev->data->rx_queues;
> + fpo->rxq.clbk = (void **)(uintptr_t)dev->post_rx_burst_cbs;
> +
> + fpo->txq.data = dev->data->tx_queues;
> + fpo->txq.clbk = (void **)(uintptr_t)dev->pre_tx_burst_cbs;
> +}
> diff --git a/lib/ethdev/ethdev_private.h b/lib/ethdev/ethdev_private.h
> index 3724429577..5721be7bdc 100644
> --- a/lib/ethdev/ethdev_private.h
> +++ b/lib/ethdev/ethdev_private.h
> @@ -26,4 +26,11 @@ eth_find_device(const struct rte_eth_dev *_start, rte_eth_cmp_t cmp,
> /* Parse devargs value for representor parameter. */
> int rte_eth_devargs_parse_representor_ports(char *str, void *data);
>
> +/* reset eth fast-path API to dummy values */
> +void eth_dev_fp_ops_reset(struct rte_eth_fp_ops *fpo);
> +
> +/* setup eth fast-path API to ethdev values */
> +void eth_dev_fp_ops_setup(struct rte_eth_fp_ops *fpo,
> + const struct rte_eth_dev *dev);
Some drivers control the transmit/receive function during operation. E.g.
for hns3 driver, when detect reset, primary process will set rx/tx burst to dummy, after
process reset, primary process will set the correct rx/tx burst. During this process, the
send and receive threads are still working, but the bursts they call are changed. So:
1. it is recommended that trace be deleted from the dummy function.
2. public the eth_dev_fp_ops_reset/setup interface for driver usage.
> +
> #endif /* _ETH_PRIVATE_H_ */
> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
> index c8abda6dd7..9f7a0cbb8c 100644
> --- a/lib/ethdev/rte_ethdev.c
> +++ b/lib/ethdev/rte_ethdev.c
> @@ -44,6 +44,9 @@
> static const char *MZ_RTE_ETH_DEV_DATA = "rte_eth_dev_data";
> struct rte_eth_dev rte_eth_devices[RTE_MAX_ETHPORTS];
>
> +/* public fast-path API */
> +struct rte_eth_fp_ops rte_eth_fp_ops[RTE_MAX_ETHPORTS];
> +
> /* spinlock for eth device callbacks */
> static rte_spinlock_t eth_dev_cb_lock = RTE_SPINLOCK_INITIALIZER;
>
> @@ -578,6 +581,8 @@ rte_eth_dev_release_port(struct rte_eth_dev *eth_dev)
> rte_eth_dev_callback_process(eth_dev,
> RTE_ETH_EVENT_DESTROY, NULL);
>
> + eth_dev_fp_ops_reset(rte_eth_fp_ops + eth_dev->data->port_id);
> +
> rte_spinlock_lock(ð_dev_shared_data->ownership_lock);
>
> eth_dev->state = RTE_ETH_DEV_UNUSED;
> @@ -1787,6 +1792,9 @@ rte_eth_dev_start(uint16_t port_id)
> (*dev->dev_ops->link_update)(dev, 0);
> }
>
> + /* expose selection of PMD fast-path functions */
> + eth_dev_fp_ops_setup(rte_eth_fp_ops + port_id, dev);
> +
> rte_ethdev_trace_start(port_id);
> return 0;
> }
> @@ -1809,6 +1817,9 @@ rte_eth_dev_stop(uint16_t port_id)
> return 0;
> }
>
> + /* point fast-path functions to dummy ones */
> + eth_dev_fp_ops_reset(rte_eth_fp_ops + port_id);
> +
> dev->data->dev_started = 0;
> ret = (*dev->dev_ops->dev_stop)(dev);
> rte_ethdev_trace_stop(port_id, ret);
> @@ -4567,6 +4578,14 @@ rte_eth_mirror_rule_reset(uint16_t port_id, uint8_t rule_id)
> return eth_err(port_id, (*dev->dev_ops->mirror_rule_reset)(dev, rule_id));
> }
>
> +RTE_INIT(eth_dev_init_fp_ops)
> +{
> + uint32_t i;
> +
> + for (i = 0; i != RTE_DIM(rte_eth_fp_ops); i++)
> + eth_dev_fp_ops_reset(rte_eth_fp_ops + i);
> +}
> +
> RTE_INIT(eth_dev_init_cb_lists)
> {
> uint16_t i;
> @@ -4735,6 +4754,14 @@ rte_eth_dev_probing_finish(struct rte_eth_dev *dev)
> if (dev == NULL)
> return;
>
> + /*
> + * for secondary process, at that point we expect device
> + * to be already 'usable', so shared data and all function pointers
> + * for fast-path devops have to be setup properly inside rte_eth_dev.
> + */
> + if (rte_eal_process_type() == RTE_PROC_SECONDARY)
> + eth_dev_fp_ops_setup(rte_eth_fp_ops + dev->data->port_id, dev);
> +
> rte_eth_dev_callback_process(dev, RTE_ETH_EVENT_NEW, NULL);
>
> dev->state = RTE_ETH_DEV_ATTACHED;
> diff --git a/lib/ethdev/rte_ethdev_core.h b/lib/ethdev/rte_ethdev_core.h
> index 51cd68de94..d5853dff86 100644
> --- a/lib/ethdev/rte_ethdev_core.h
> +++ b/lib/ethdev/rte_ethdev_core.h
> @@ -50,6 +50,61 @@ typedef int (*eth_rx_descriptor_status_t)(void *rxq, uint16_t offset);
> typedef int (*eth_tx_descriptor_status_t)(void *txq, uint16_t offset);
> /**< @internal Check the status of a Tx descriptor */
>
> +/**
> + * @internal
> + * Structure used to hold opaque pointers to internal ethdev Rx/Tx
> + * queues data.
> + * The main purpose to expose these pointers at all - allow compiler
> + * to fetch this data for fast-path ethdev inline functions in advance.
> + */
> +struct rte_ethdev_qdata {
> + void **data;
> + /**< points to array of internal queue data pointers */
> + void **clbk;
> + /**< points to array of queue callback data pointers */
> +};
> +
> +/**
> + * @internal
> + * fast-path ethdev functions and related data are hold in a flat array.
> + * One entry per ethdev.
> + * On 64-bit systems contents of this structure occupy exactly two 64B lines.
> + * On 32-bit systems contents of this structure fits into one 64B line.
> + */
> +struct rte_eth_fp_ops {
> +
> + /**
> + * Rx fast-path functions and related data.
> + * 64-bit systems: occupies first 64B line
> + */
> + eth_rx_burst_t rx_pkt_burst;
> + /**< PMD receive function. */
> + eth_rx_queue_count_t rx_queue_count;
> + /**< Get the number of used RX descriptors. */
> + eth_rx_descriptor_status_t rx_descriptor_status;
> + /**< Check the status of a Rx descriptor. */
> + struct rte_ethdev_qdata rxq;
> + /**< Rx queues data. */
> + uintptr_t reserved1[3];
> +
> + /**
> + * Tx fast-path functions and related data.
> + * 64-bit systems: occupies second 64B line
> + */
> + eth_tx_burst_t tx_pkt_burst;
Why not place rx_pkt_burst/tx_pkt_burst/rxq /txq to the first cacheline ?
Other function, e.g. rx_queue_count/descriptor_status are low frequency call functions.
> + /**< PMD transmit function. */
> + eth_tx_prep_t tx_pkt_prepare;
> + /**< PMD transmit prepare function. */
> + eth_tx_descriptor_status_t tx_descriptor_status;
> + /**< Check the status of a Tx descriptor. */
> + struct rte_ethdev_qdata txq;
> + /**< Tx queues data. */
> + uintptr_t reserved2[3];
> +
> +} __rte_cache_aligned;
> +
> +extern struct rte_eth_fp_ops rte_eth_fp_ops[RTE_MAX_ETHPORTS];
> +
>
> /**
> * @internal
>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v24 0/6] support dmadev
@ 2021-10-09 9:33 3% ` Chengwen Feng
0 siblings, 0 replies; 200+ results
From: Chengwen Feng @ 2021-10-09 9:33 UTC (permalink / raw)
To: thomas, ferruh.yigit, bruce.richardson, jerinj, jerinjacobk,
andrew.rybchenko
Cc: dev, mb, nipun.gupta, hemant.agrawal, maxime.coquelin,
honnappa.nagarahalli, david.marchand, sburla, pkapoor,
konstantin.ananyev, conor.walsh, kevin.laatz
This patch set contains six patch for new add dmadev.
Chengwen Feng (6):
dmadev: introduce DMA device library
dmadev: add control plane API support
dmadev: add data plane API support
dmadev: add multi-process support
dma/skeleton: introduce skeleton dmadev driver
app/test: add dmadev API test
---
v24:
* use rte_dma_fp_object to hide implementation details.
* support group doxygen for RTE_DMA_CAPA_* and RTE_DMA_OP_*.
* adjusted the naming of some functions.
* fix typo.
v23:
* split multi-process support from 1st patch.
* fix some static check warning.
* fix skeleton cpu thread zero_req_count flip bug.
* add test_dmadev_api.h.
* add the description of modifying the dmadev state when init OK.
v22:
* function prefix change from rte_dmadev_* to rte_dma_*.
* change to prefix comment in most scenarios.
* dmadev dev_id use int16_t type.
* fix typo.
* organize patchsets in incremental mode.
v21:
* add comment for reserved fields of struct rte_dmadev.
v20:
* delete unnecessary and duplicate include header files.
* the conf_sz parameter is added to the configure and vchan-setup
callbacks of the PMD, this is mainly used to enhance ABI
compatibility.
* the rte_dmadev structure field is rearranged to reserve more space
for I/O functions.
* fix some ambiguous and unnecessary comments.
* fix the potential memory leak of ut.
* redefine skeldma_init_once to skeldma_count.
* suppress rte_dmadev error output when execute ut.
MAINTAINERS | 7 +
app/test/meson.build | 4 +
app/test/test_dmadev.c | 41 +
app/test/test_dmadev_api.c | 574 +++++++++++++
app/test/test_dmadev_api.h | 5 +
doc/api/doxy-api-index.md | 1 +
doc/api/doxy-api.conf.in | 1 +
doc/guides/dmadevs/index.rst | 12 +
doc/guides/index.rst | 1 +
doc/guides/prog_guide/dmadev.rst | 120 +++
doc/guides/prog_guide/img/dmadev.svg | 283 +++++++
doc/guides/prog_guide/index.rst | 1 +
doc/guides/rel_notes/release_21_11.rst | 6 +
drivers/dma/meson.build | 6 +
drivers/dma/skeleton/meson.build | 7 +
drivers/dma/skeleton/skeleton_dmadev.c | 571 +++++++++++++
drivers/dma/skeleton/skeleton_dmadev.h | 61 ++
drivers/dma/skeleton/version.map | 3 +
drivers/meson.build | 1 +
lib/dmadev/meson.build | 7 +
lib/dmadev/rte_dmadev.c | 844 +++++++++++++++++++
lib/dmadev/rte_dmadev.h | 1048 ++++++++++++++++++++++++
lib/dmadev/rte_dmadev_core.h | 78 ++
lib/dmadev/rte_dmadev_pmd.h | 173 ++++
lib/dmadev/version.map | 35 +
lib/meson.build | 1 +
26 files changed, 3891 insertions(+)
create mode 100644 app/test/test_dmadev.c
create mode 100644 app/test/test_dmadev_api.c
create mode 100644 app/test/test_dmadev_api.h
create mode 100644 doc/guides/dmadevs/index.rst
create mode 100644 doc/guides/prog_guide/dmadev.rst
create mode 100644 doc/guides/prog_guide/img/dmadev.svg
create mode 100644 drivers/dma/meson.build
create mode 100644 drivers/dma/skeleton/meson.build
create mode 100644 drivers/dma/skeleton/skeleton_dmadev.c
create mode 100644 drivers/dma/skeleton/skeleton_dmadev.h
create mode 100644 drivers/dma/skeleton/version.map
create mode 100644 lib/dmadev/meson.build
create mode 100644 lib/dmadev/rte_dmadev.c
create mode 100644 lib/dmadev/rte_dmadev.h
create mode 100644 lib/dmadev/rte_dmadev_core.h
create mode 100644 lib/dmadev/rte_dmadev_pmd.h
create mode 100644 lib/dmadev/version.map
--
2.33.0
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v16 0/9] eal: Add EAL API for threading
2021-10-08 22:40 3% ` [dpdk-dev] [PATCH v15 " Narcisa Ana Maria Vasile
@ 2021-10-09 7:41 3% ` Narcisa Ana Maria Vasile
0 siblings, 0 replies; 200+ results
From: Narcisa Ana Maria Vasile @ 2021-10-09 7:41 UTC (permalink / raw)
To: dev, thomas, dmitry.kozliuk, khot, navasile, dmitrym, roretzla,
talshn, ocardona
Cc: bruce.richardson, david.marchand, pallavi.kadam
From: Narcisa Vasile <navasile@microsoft.com>
EAL thread API
**Problem Statement**
DPDK currently uses the pthread interface to create and manage threads.
Windows does not support the POSIX thread programming model,
so it currently
relies on a header file that hides the Windows calls under
pthread matched interfaces. Given that EAL should isolate the environment
specifics from the applications and libraries and mediate
all the communication with the operating systems, a new EAL interface
is needed for thread management.
**Goals**
* Introduce a generic EAL API for threading support that will remove
the current Windows pthread.h shim.
* Replace references to pthread_* across the DPDK codebase with the new
RTE_THREAD_* API.
* Allow users to choose between using the RTE_THREAD_* API or a
3rd party thread library through a configuration option.
**Design plan**
New API main files:
* rte_thread.h (librte_eal/include)
* rte_thread.c (librte_eal/windows)
* rte_thread.c (librte_eal/common)
**A schematic example of the design**
--------------------------------------------------
lib/librte_eal/include/rte_thread.h
int rte_thread_create();
lib/librte_eal/common/rte_thread.c
int rte_thread_create()
{
return pthread_create();
}
lib/librte_eal/windows/rte_thread.c
int rte_thread_create()
{
return CreateThread();
}
-----------------------------------------------------
**Thread attributes**
When or after a thread is created, specific characteristics of the thread
can be adjusted. Given that the thread characteristics that are of interest
for DPDK applications are affinity and priority, the following structure
that represents thread attributes has been defined:
typedef struct
{
enum rte_thread_priority priority;
rte_cpuset_t cpuset;
} rte_thread_attr_t;
The *rte_thread_create()* function can optionally receive
an rte_thread_attr_t
object that will cause the thread to be created with the
affinity and priority
described by the attributes object. If no rte_thread_attr_t is passed
(parameter is NULL), the default affinity and priority are used.
An rte_thread_attr_t object can also be set to the default values
by calling *rte_thread_attr_init()*.
*Priority* is represented through an enum that currently advertises
two values for priority:
- RTE_THREAD_PRIORITY_NORMAL
- RTE_THREAD_PRIORITY_REALTIME_CRITICAL
The enum can be extended to allow for multiple priority levels.
rte_thread_set_priority - sets the priority of a thread
rte_thread_get_priority - retrieves the priority of a thread
from the OS
rte_thread_attr_set_priority - updates an rte_thread_attr_t object
with a new value for priority
The user can choose thread priority through an EAL parameter,
when starting an application. If EAL parameter is not used,
the per-platform default value for thread priority is used.
Otherwise administrator has an option to set one of available options:
--thread-prio normal
--thread-prio realtime
Example:
./dpdk-l2fwd -l 0-3 -n 4 –thread-prio normal -- -q 8 -p ffff
*Affinity* is described by the already known “rte_cpuset_t” type.
rte_thread_attr_set/get_affinity - sets/gets the affinity field in a
rte_thread_attr_t object
rte_thread_set/get_affinity – sets/gets the affinity of a thread
**Errors**
A translation function that maps Windows error codes to errno-style
error codes is provided.
**Future work**
The long term plan is for EAL to provide full threading support:
* Add support for conditional variables
* Additional functionality offered by pthread_*
(such as pthread_setname_np, etc.)
v16:
- Fix warning on freebsd by adding cast
- Change affinity unit test to consider ases when the requested CPU
are not available on the system.
- Fix priority unit test to avoid termination of thread before the
priority is checked.
v15:
- Add try_lock mutex functionality. If the mutex is already owned by a
different thread, the function returns immediately. Otherwise,
the mutex will be acquired.
- Add function for getting the priority of a thread.
An auxiliary function that translates the OS priority to the
EAL accepted ones is added.
- Fix unit tests logging, add descriptive asserts that mark test failures.
Verify mutex locking, verify barrier return values. Add test for
statically initialized mutexes.
- Fix Alpine build by removing the use of pthread_attr_set_affinity() and
using pthread_set_affinity() after the thread is created.
v14:
- Remove patch "eal: add EAL argument for setting thread priority"
This will be added later when enabling the new threading API.
- Remove priority enum value "_UNDEFINED". NORMAL is used
as the default.
- Fix issue with thread return value.
v13:
- Fix syntax error in unit tests
v12:
- Fix freebsd warning about initializer in unit tests
v11:
- Add unit tests for thread API
- Rebase
v10:
- Remove patch no. 10. It will be broken down in subpatches
and sent as a different patchset that depends on this one.
This is done due to the ABI breaks that would be caused by patch 10.
- Replace unix/rte_thread.c with common/rte_thread.c
- Remove initializations that may prevent compiler from issuing useful
warnings.
- Remove rte_thread_types.h and rte_windows_thread_types.h
- Remove unneeded priority macros (EAL_THREAD_PRIORITY*)
- Remove functions that retrieves thread handle from process handle
- Remove rte_thread_cancel() until same behavior is obtained on
all platforms.
- Fix rte_thread_detach() function description,
return value and remove empty line.
- Reimplement mutex functions. Add compatible representation for mutex
identifier. Add macro to replace static mutex initialization instances.
- Fix commit messages (lines too long, remove unicode symbols)
v9:
- Sign patches
v8:
- Rebase
- Add rte_thread_detach() API
- Set default priority, when user did not specify a value
v7:
Based on DmitryK's review:
- Change thread id representation
- Change mutex id representation
- Implement static mutex inititalizer for Windows
- Change barrier identifier representation
- Improve commit messages
- Add missing doxygen comments
- Split error translation function
- Improve name for affinity function
- Remove cpuset_size parameter
- Fix eal_create_cpu_map function
- Map EAL priority values to OS specific values
- Add thread wrapper for start routine
- Do not export rte_thread_cancel() on Windows
- Cleanup, fix comments, fix typos.
v6:
- improve error-translation function
- call the error translation function in rte_thread_value_get()
v5:
- update cover letter with more details on the priority argument
v4:
- fix function description
- rebase
v3:
- rebase
v2:
- revert changes that break ABI
- break up changes into smaller patches
- fix coding style issues
- fix issues with errors
- fix parameter type in examples/kni.c
Narcisa Vasile (9):
eal: add basic threading functions
eal: add thread attributes
eal/windows: translate Windows errors to errno-style errors
eal: implement functions for thread affinity management
eal: implement thread priority management functions
eal: add thread lifetime management
eal: implement functions for mutex management
eal: implement functions for thread barrier management
Add unit tests for thread API
app/test/meson.build | 2 +
app/test/test_threads.c | 372 ++++++++++++++++++
lib/eal/common/meson.build | 1 +
lib/eal/common/rte_thread.c | 497 ++++++++++++++++++++++++
lib/eal/include/rte_thread.h | 435 ++++++++++++++++++++-
lib/eal/unix/meson.build | 1 -
lib/eal/unix/rte_thread.c | 92 -----
lib/eal/version.map | 22 ++
lib/eal/windows/eal_lcore.c | 176 ++++++---
lib/eal/windows/eal_windows.h | 10 +
lib/eal/windows/include/sched.h | 2 +-
lib/eal/windows/rte_thread.c | 656 ++++++++++++++++++++++++++++++--
12 files changed, 2093 insertions(+), 173 deletions(-)
create mode 100644 app/test/test_threads.c
create mode 100644 lib/eal/common/rte_thread.c
delete mode 100644 lib/eal/unix/rte_thread.c
--
2.31.0.vfs.0.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v15 0/9] eal: Add EAL API for threading
@ 2021-10-08 22:40 3% ` Narcisa Ana Maria Vasile
2021-10-09 7:41 3% ` [dpdk-dev] [PATCH v16 " Narcisa Ana Maria Vasile
0 siblings, 1 reply; 200+ results
From: Narcisa Ana Maria Vasile @ 2021-10-08 22:40 UTC (permalink / raw)
To: dev, thomas, dmitry.kozliuk, khot, navasile, dmitrym, roretzla,
talshn, ocardona
Cc: bruce.richardson, david.marchand, pallavi.kadam
From: Narcisa Vasile <navasile@microsoft.com>
EAL thread API
**Problem Statement**
DPDK currently uses the pthread interface to create and manage threads.
Windows does not support the POSIX thread programming model,
so it currently
relies on a header file that hides the Windows calls under
pthread matched interfaces. Given that EAL should isolate the environment
specifics from the applications and libraries and mediate
all the communication with the operating systems, a new EAL interface
is needed for thread management.
**Goals**
* Introduce a generic EAL API for threading support that will remove
the current Windows pthread.h shim.
* Replace references to pthread_* across the DPDK codebase with the new
RTE_THREAD_* API.
* Allow users to choose between using the RTE_THREAD_* API or a
3rd party thread library through a configuration option.
**Design plan**
New API main files:
* rte_thread.h (librte_eal/include)
* rte_thread.c (librte_eal/windows)
* rte_thread.c (librte_eal/common)
**A schematic example of the design**
--------------------------------------------------
lib/librte_eal/include/rte_thread.h
int rte_thread_create();
lib/librte_eal/common/rte_thread.c
int rte_thread_create()
{
return pthread_create();
}
lib/librte_eal/windows/rte_thread.c
int rte_thread_create()
{
return CreateThread();
}
-----------------------------------------------------
**Thread attributes**
When or after a thread is created, specific characteristics of the thread
can be adjusted. Given that the thread characteristics that are of interest
for DPDK applications are affinity and priority, the following structure
that represents thread attributes has been defined:
typedef struct
{
enum rte_thread_priority priority;
rte_cpuset_t cpuset;
} rte_thread_attr_t;
The *rte_thread_create()* function can optionally receive
an rte_thread_attr_t
object that will cause the thread to be created with the
affinity and priority
described by the attributes object. If no rte_thread_attr_t is passed
(parameter is NULL), the default affinity and priority are used.
An rte_thread_attr_t object can also be set to the default values
by calling *rte_thread_attr_init()*.
*Priority* is represented through an enum that currently advertises
two values for priority:
- RTE_THREAD_PRIORITY_NORMAL
- RTE_THREAD_PRIORITY_REALTIME_CRITICAL
The enum can be extended to allow for multiple priority levels.
rte_thread_set_priority - sets the priority of a thread
rte_thread_get_priority - retrieves the priority of a thread
from the OS
rte_thread_attr_set_priority - updates an rte_thread_attr_t object
with a new value for priority
The user can choose thread priority through an EAL parameter,
when starting an application. If EAL parameter is not used,
the per-platform default value for thread priority is used.
Otherwise administrator has an option to set one of available options:
--thread-prio normal
--thread-prio realtime
Example:
./dpdk-l2fwd -l 0-3 -n 4 –thread-prio normal -- -q 8 -p ffff
*Affinity* is described by the already known “rte_cpuset_t” type.
rte_thread_attr_set/get_affinity - sets/gets the affinity field in a
rte_thread_attr_t object
rte_thread_set/get_affinity – sets/gets the affinity of a thread
**Errors**
A translation function that maps Windows error codes to errno-style
error codes is provided.
**Future work**
The long term plan is for EAL to provide full threading support:
* Add support for conditional variables
* Additional functionality offered by pthread_*
(such as pthread_setname_np, etc.)
v15:
- Add try_lock mutex functionality. If the mutex is already owned by a
different thread, the function returns immediately. Otherwise,
the mutex will be acquired.
- Add function for getting the priority of a thread.
An auxiliary function that translates the OS priority to the
EAL accepted ones is added.
- Fix unit tests logging, add descriptive asserts that mark test failures.
Verify mutex locking, verify barrier return values. Add test for
statically initialized mutexes.
- Fix Alpine build by removing the use of pthread_attr_set_affinity() and
using pthread_set_affinity() after the thread is created.
v14:
- Remove patch "eal: add EAL argument for setting thread priority"
This will be added later when enabling the new threading API.
- Remove priority enum value "_UNDEFINED". NORMAL is used
as the default.
- Fix issue with thread return value.
v13:
- Fix syntax error in unit tests
v12:
- Fix freebsd warning about initializer in unit tests
v11:
- Add unit tests for thread API
- Rebase
v10:
- Remove patch no. 10. It will be broken down in subpatches
and sent as a different patchset that depends on this one.
This is done due to the ABI breaks that would be caused by patch 10.
- Replace unix/rte_thread.c with common/rte_thread.c
- Remove initializations that may prevent compiler from issuing useful
warnings.
- Remove rte_thread_types.h and rte_windows_thread_types.h
- Remove unneeded priority macros (EAL_THREAD_PRIORITY*)
- Remove functions that retrieves thread handle from process handle
- Remove rte_thread_cancel() until same behavior is obtained on
all platforms.
- Fix rte_thread_detach() function description,
return value and remove empty line.
- Reimplement mutex functions. Add compatible representation for mutex
identifier. Add macro to replace static mutex initialization instances.
- Fix commit messages (lines too long, remove unicode symbols)
v9:
- Sign patches
v8:
- Rebase
- Add rte_thread_detach() API
- Set default priority, when user did not specify a value
v7:
Based on DmitryK's review:
- Change thread id representation
- Change mutex id representation
- Implement static mutex inititalizer for Windows
- Change barrier identifier representation
- Improve commit messages
- Add missing doxygen comments
- Split error translation function
- Improve name for affinity function
- Remove cpuset_size parameter
- Fix eal_create_cpu_map function
- Map EAL priority values to OS specific values
- Add thread wrapper for start routine
- Do not export rte_thread_cancel() on Windows
- Cleanup, fix comments, fix typos.
v6:
- improve error-translation function
- call the error translation function in rte_thread_value_get()
v5:
- update cover letter with more details on the priority argument
v4:
- fix function description
- rebase
v3:
- rebase
v2:
- revert changes that break ABI
- break up changes into smaller patches
- fix coding style issues
- fix issues with errors
- fix parameter type in examples/kni.c
Narcisa Vasile (9):
eal: add basic threading functions
eal: add thread attributes
eal/windows: translate Windows errors to errno-style errors
eal: implement functions for thread affinity management
eal: implement thread priority management functions
eal: add thread lifetime management
eal: implement functions for mutex management
eal: implement functions for thread barrier management
Add unit tests for thread API
app/test/meson.build | 2 +
app/test/test_threads.c | 359 +++++++++++++++++
lib/eal/common/meson.build | 1 +
lib/eal/common/rte_thread.c | 496 ++++++++++++++++++++++++
lib/eal/include/rte_thread.h | 435 ++++++++++++++++++++-
lib/eal/unix/meson.build | 1 -
lib/eal/unix/rte_thread.c | 92 -----
lib/eal/version.map | 22 ++
lib/eal/windows/eal_lcore.c | 176 ++++++---
lib/eal/windows/eal_windows.h | 10 +
lib/eal/windows/include/sched.h | 2 +-
lib/eal/windows/rte_thread.c | 656 ++++++++++++++++++++++++++++++--
12 files changed, 2079 insertions(+), 173 deletions(-)
create mode 100644 app/test/test_threads.c
create mode 100644 lib/eal/common/rte_thread.c
delete mode 100644 lib/eal/unix/rte_thread.c
--
2.31.0.vfs.0.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v2 3/3] security: add reserved bitfields
2021-10-08 20:45 3% ` [dpdk-dev] [PATCH v2 1/3] cryptodev: remove LIST_END enumerators Akhil Goyal
@ 2021-10-08 20:45 3% ` Akhil Goyal
2021-10-11 8:31 0% ` Thomas Monjalon
2021-10-12 8:50 0% ` [dpdk-dev] " Kinsella, Ray
2021-10-11 10:46 0% ` [dpdk-dev] [PATCH v2 1/3] cryptodev: remove LIST_END enumerators Zhang, Roy Fan
2021-10-12 9:55 3% ` Kinsella, Ray
2 siblings, 2 replies; 200+ results
From: Akhil Goyal @ 2021-10-08 20:45 UTC (permalink / raw)
To: dev
Cc: thomas, david.marchand, hemant.agrawal, anoobj,
pablo.de.lara.guarch, fiona.trahe, declan.doherty, matan,
g.singh, roy.fan.zhang, jianjay.zhou, asomalap, ruifeng.wang,
konstantin.ananyev, radu.nicolau, ajit.khaparde, rnagadheeraj,
adwivedi, ciara.power, Akhil Goyal
In struct rte_security_ipsec_sa_options, for every new option
added, there is an ABI breakage, to avoid, a reserved_opts
bitfield is added to for the remaining bits available in the
structure.
Now for every new sa option, these reserved_opts can be reduced
and new option can be added.
Signed-off-by: Akhil Goyal <gakhil@marvell.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
---
v2: rebase and removed libabigail.abignore change.
Exception may be added when there is a need for change.
lib/security/rte_security.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/lib/security/rte_security.h b/lib/security/rte_security.h
index 7eb9f109ae..c0ea13892e 100644
--- a/lib/security/rte_security.h
+++ b/lib/security/rte_security.h
@@ -258,6 +258,12 @@ struct rte_security_ipsec_sa_options {
* PKT_TX_UDP_CKSUM or PKT_TX_L4_MASK in mbuf.
*/
uint32_t l4_csum_enable : 1;
+
+ /** Reserved bit fields for future extension
+ *
+ * Note: reduce number of bits in reserved_opts for every new option
+ */
+ uint32_t reserved_opts : 18;
};
/** IPSec security association direction */
--
2.25.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v2 1/3] cryptodev: remove LIST_END enumerators
@ 2021-10-08 20:45 3% ` Akhil Goyal
2021-10-08 20:45 3% ` [dpdk-dev] [PATCH v2 3/3] security: add reserved bitfields Akhil Goyal
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Akhil Goyal @ 2021-10-08 20:45 UTC (permalink / raw)
To: dev
Cc: thomas, david.marchand, hemant.agrawal, anoobj,
pablo.de.lara.guarch, fiona.trahe, declan.doherty, matan,
g.singh, roy.fan.zhang, jianjay.zhou, asomalap, ruifeng.wang,
konstantin.ananyev, radu.nicolau, ajit.khaparde, rnagadheeraj,
adwivedi, ciara.power, Akhil Goyal
Remove *_LIST_END enumerators from asymmetric crypto
lib to avoid ABI breakage for every new addition in
enums.
Signed-off-by: Akhil Goyal <gakhil@marvell.com>
---
v2: no change
app/test/test_cryptodev_asym.c | 4 ++--
drivers/crypto/qat/qat_asym.c | 2 +-
lib/cryptodev/rte_crypto_asym.h | 4 ----
3 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index 9d19a6d6d9..603b2e4609 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -541,7 +541,7 @@ test_one_case(const void *test_case, int sessionless)
printf(" %u) TestCase %s %s\n", test_index++,
tc.modex.description, test_msg);
} else {
- for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
+ for (i = 0; i <= RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE; i++) {
if (tc.modex.xform_type == RTE_CRYPTO_ASYM_XFORM_RSA) {
if (tc.rsa_data.op_type_flags & (1 << i)) {
if (tc.rsa_data.key_exp) {
@@ -1027,7 +1027,7 @@ static inline void print_asym_capa(
rte_crypto_asym_xform_strings[capa->xform_type]);
printf("operation supported -");
- for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
+ for (i = 0; i <= RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE; i++) {
/* check supported operations */
if (rte_cryptodev_asym_xform_capability_check_optype(capa, i))
printf(" %s",
diff --git a/drivers/crypto/qat/qat_asym.c b/drivers/crypto/qat/qat_asym.c
index 85973812a8..026625a4d2 100644
--- a/drivers/crypto/qat/qat_asym.c
+++ b/drivers/crypto/qat/qat_asym.c
@@ -742,7 +742,7 @@ qat_asym_session_configure(struct rte_cryptodev *dev,
err = -EINVAL;
goto error;
}
- } else if (xform->xform_type >= RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
+ } else if (xform->xform_type > RTE_CRYPTO_ASYM_XFORM_ECPM
|| xform->xform_type <= RTE_CRYPTO_ASYM_XFORM_NONE) {
QAT_LOG(ERR, "Invalid asymmetric crypto xform");
err = -EINVAL;
diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 9c866f553f..5edf658572 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -94,8 +94,6 @@ enum rte_crypto_asym_xform_type {
*/
RTE_CRYPTO_ASYM_XFORM_ECPM,
/**< Elliptic Curve Point Multiplication */
- RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
- /**< End of list */
};
/**
@@ -116,7 +114,6 @@ enum rte_crypto_asym_op_type {
/**< DH Public Key generation operation */
RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE,
/**< DH Shared Secret compute operation */
- RTE_CRYPTO_ASYM_OP_LIST_END
};
/**
@@ -133,7 +130,6 @@ enum rte_crypto_rsa_padding_type {
/**< RSA PKCS#1 OAEP padding scheme */
RTE_CRYPTO_RSA_PADDING_PSS,
/**< RSA PKCS#1 PSS padding scheme */
- RTE_CRYPTO_RSA_PADDING_TYPE_LIST_END
};
/**
--
2.25.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 0/7] hide eth dev related structures
` (3 preceding siblings ...)
@ 2021-10-08 18:13 0% ` Slava Ovsiienko
2021-10-11 9:22 0% ` Andrew Rybchenko
5 siblings, 0 replies; 200+ results
From: Slava Ovsiienko @ 2021-10-08 18:13 UTC (permalink / raw)
To: Konstantin Ananyev, dev
Cc: xiaoyun.li, anoobj, jerinj, ndabilpuram, adwivedi,
shepard.siegel, ed.czeck, john.miller, irusskikh, ajit.khaparde,
somnath.kotur, rahul.lakkireddy, hemant.agrawal, sachin.saxena,
haiyue.wang, johndale, hyonkim, qi.z.zhang, xiao.w.wang, humin29,
yisen.zhuang, oulijun, beilei.xing, jingjing.wu, qiming.yang,
Matan Azrad, sthemmin, NBU-Contact-longli, heinrich.kuhn,
kirankumark, andrew.rybchenko, mczekaj, jiawenwu, jianwang,
maxime.coquelin, chenbo.xia, NBU-Contact-Thomas Monjalon,
ferruh.yigit, mdr, jay.jayatheerthan
Hi,
I've reviewed the series, and it looks good to me.
I see we did not introduce new indirect referencing on the datapath
(just replaced rte_eth_devices[] being hidden with the new rte_eth_fp_ops[].)
My only concern - we'll get two places where pointers to the PMDs routines are stored,
and it means potential unsynchro between them, but I do not see the actual scenario for that.
For example, mlx5 PMD proposes multiple tx/rx_burst routines, and actual routine
selection happens on dev_start(), but then it is not supposed to be changed till dev_stop().
The internal PMD checks like this:
"if (dev->rx_pkt_burst == mlx5_rx_burst)"
supposed to continue working OK as well.
Hence, for series:
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
With best regards,
Slava
> -----Original Message-----
> From: Konstantin Ananyev <konstantin.ananyev@intel.com>
> Sent: Thursday, October 7, 2021 14:28
> To: dev@dpdk.org
> Cc: xiaoyun.li@intel.com; anoobj@marvell.com; jerinj@marvell.com;
> ndabilpuram@marvell.com; adwivedi@marvell.com;
> shepard.siegel@atomicrules.com; ed.czeck@atomicrules.com;
> john.miller@atomicrules.com; irusskikh@marvell.com;
> ajit.khaparde@broadcom.com; somnath.kotur@broadcom.com;
> rahul.lakkireddy@chelsio.com; hemant.agrawal@nxp.com;
> sachin.saxena@oss.nxp.com; haiyue.wang@intel.com; johndale@cisco.com;
> hyonkim@cisco.com; qi.z.zhang@intel.com; xiao.w.wang@intel.com;
> humin29@huawei.com; yisen.zhuang@huawei.com; oulijun@huawei.com;
> beilei.xing@intel.com; jingjing.wu@intel.com; qiming.yang@intel.com; Matan
> Azrad <matan@nvidia.com>; Slava Ovsiienko <viacheslavo@nvidia.com>;
> sthemmin@microsoft.com; NBU-Contact-longli <longli@microsoft.com>;
> heinrich.kuhn@corigine.com; kirankumark@marvell.com;
> andrew.rybchenko@oktetlabs.ru; mczekaj@marvell.com;
> jiawenwu@trustnetic.com; jianwang@trustnetic.com;
> maxime.coquelin@redhat.com; chenbo.xia@intel.com; NBU-Contact-Thomas
> Monjalon <thomas@monjalon.net>; ferruh.yigit@intel.com; mdr@ashroe.eu;
> jay.jayatheerthan@intel.com; Konstantin Ananyev
> <konstantin.ananyev@intel.com>
> Subject: [PATCH v5 0/7] hide eth dev related structures
>
> v5 changes:
> - Fix spelling (Thomas/David)
> - Rename internal helper functions (David)
> - Reorder patches and update commit messages (Thomas)
> - Update comments (Thomas)
> - Changed layout in rte_eth_fp_ops, to group functions and
> related data based on their functionality:
> first 64B line for Rx, second one for Tx.
> Didn't observe any real performance difference comparing to
> original layout. Though decided to keep a new one, as it seems
> a bit more plausible.
>
> v4 changes:
> - Fix secondary process attach (Pavan)
> - Fix build failure (Ferruh)
> - Update lib/ethdev/verion.map (Ferruh)
> Note that moving newly added symbols from EXPERIMENTAL to DPDK_22
> section makes checkpatch.sh to complain.
>
> v3 changes:
> - Changes in public struct naming (Jerin/Haiyue)
> - Split patches
> - Update docs
> - Shamelessly included Andrew's patch:
> https://patches.dpdk.org/project/dpdk/patch/20210928154856.1015020-
> 1-andrew.rybchenko@oktetlabs.ru/
> into these series.
> I have to do similar thing here, so decided to avoid duplicated effort.
>
> The aim of these patch series is to make rte_ethdev core data structures
> (rte_eth_dev, rte_eth_dev_data, rte_eth_rxtx_callback, etc.) internal to DPDK
> and not visible to the user.
> That should allow future possible changes to core ethdev related structures to
> be transparent to the user and help to improve ABI/API stability.
> Note that current ethdev API is preserved, but it is a formal ABI break.
>
> The work is based on previous discussions at:
> https://www.mail-archive.com/dev@dpdk.org/msg211405.html
> https://www.mail-archive.com/dev@dpdk.org/msg216685.html
> and consists of the following main points:
> 1. Copy public 'fast' function pointers (rx_pkt_burst(), etc.) and
> related data pointer from rte_eth_dev into a separate flat array.
> We keep it public to still be able to use inline functions for these
> 'fast' calls (like rte_eth_rx_burst(), etc.) to avoid/minimize slowdown.
> Note that apart from function pointers itself, each element of this
> flat array also contains two opaque pointers for each ethdev:
> 1) a pointer to an array of internal queue data pointers
> 2) points to array of queue callback data pointers.
> Note that exposing this extra information allows us to avoid extra
> changes inside PMD level, plus should help to avoid possible
> performance degradation.
> 2. Change implementation of 'fast' inline ethdev functions
> (rte_eth_rx_burst(), etc.) to use new public flat array.
> While it is an ABI breakage, this change is intended to be transparent
> for both users (no changes in user app is required) and PMD developers
> (no changes in PMD is required).
> One extra note - with new implementation RX/TX callback invocation
> will cost one extra function call with this changes. That might cause
> some slowdown for code-path with RX/TX callbacks heavily involved.
> Hope such trade-off is acceptable for the community.
> 3. Move rte_eth_dev, rte_eth_dev_data, rte_eth_rxtx_callback and related
> things into internal header: <ethdev_driver.h>.
>
> That approach was selected to:
> - Avoid(/minimize) possible performance losses.
> - Minimize required changes inside PMDs.
>
> Performance testing results (ICX 2.0GHz, E810 (ice)):
> - testpmd macswap fwd mode, plus
> a) no RX/TX callbacks:
> no actual slowdown observed
> b) bpf-load rx 0 0 JM ./dpdk.org/examples/bpf/t3.o:
> ~2% slowdown
> - l3fwd: no actual slowdown observed
>
> Would like to thank everyone who already reviewed and tested previous
> versions of these series. All other interested parties please don't be shy and
> provide your feedback.
>
> Andrew Rybchenko (1):
> ethdev: remove legacy Rx descriptor done API
>
> Konstantin Ananyev (6):
> ethdev: allocate max space for internal queue array
> ethdev: change input parameters for rx_queue_count
> ethdev: copy fast-path API into separate structure
> ethdev: make fast-path functions to use new flat array
> ethdev: add API to retrieve multiple ethernet addresses
> ethdev: hide eth dev related structures
>
> app/test-pmd/config.c | 23 +-
> doc/guides/nics/features.rst | 6 +-
> doc/guides/rel_notes/deprecation.rst | 5 -
> doc/guides/rel_notes/release_21_11.rst | 21 ++
> drivers/common/octeontx2/otx2_sec_idev.c | 2 +-
> drivers/crypto/octeontx2/otx2_cryptodev_ops.c | 2 +-
> drivers/net/ark/ark_ethdev_rx.c | 4 +-
> drivers/net/ark/ark_ethdev_rx.h | 3 +-
> drivers/net/atlantic/atl_ethdev.h | 2 +-
> drivers/net/atlantic/atl_rxtx.c | 9 +-
> drivers/net/bnxt/bnxt_ethdev.c | 8 +-
> drivers/net/cxgbe/base/adapter.h | 2 +-
> drivers/net/dpaa/dpaa_ethdev.c | 9 +-
> drivers/net/dpaa2/dpaa2_ethdev.c | 9 +-
> drivers/net/dpaa2/dpaa2_ptp.c | 2 +-
> drivers/net/e1000/e1000_ethdev.h | 10 +-
> drivers/net/e1000/em_ethdev.c | 1 -
> drivers/net/e1000/em_rxtx.c | 21 +-
> drivers/net/e1000/igb_ethdev.c | 2 -
> drivers/net/e1000/igb_rxtx.c | 21 +-
> drivers/net/enic/enic_ethdev.c | 12 +-
> drivers/net/fm10k/fm10k.h | 5 +-
> drivers/net/fm10k/fm10k_ethdev.c | 1 -
> drivers/net/fm10k/fm10k_rxtx.c | 29 +-
> drivers/net/hns3/hns3_rxtx.c | 7 +-
> drivers/net/hns3/hns3_rxtx.h | 2 +-
> drivers/net/i40e/i40e_ethdev.c | 1 -
> drivers/net/i40e/i40e_rxtx.c | 30 +-
> drivers/net/i40e/i40e_rxtx.h | 4 +-
> drivers/net/iavf/iavf_rxtx.c | 4 +-
> drivers/net/iavf/iavf_rxtx.h | 2 +-
> drivers/net/ice/ice_rxtx.c | 4 +-
> drivers/net/ice/ice_rxtx.h | 2 +-
> drivers/net/igc/igc_ethdev.c | 1 -
> drivers/net/igc/igc_txrx.c | 23 +-
> drivers/net/igc/igc_txrx.h | 5 +-
> drivers/net/ixgbe/ixgbe_ethdev.c | 2 -
> drivers/net/ixgbe/ixgbe_ethdev.h | 5 +-
> drivers/net/ixgbe/ixgbe_rxtx.c | 22 +-
> drivers/net/mlx5/mlx5_rx.c | 26 +-
> drivers/net/mlx5/mlx5_rx.h | 2 +-
> drivers/net/netvsc/hn_rxtx.c | 4 +-
> drivers/net/netvsc/hn_var.h | 3 +-
> drivers/net/nfp/nfp_rxtx.c | 4 +-
> drivers/net/nfp/nfp_rxtx.h | 3 +-
> drivers/net/octeontx2/otx2_ethdev.c | 1 -
> drivers/net/octeontx2/otx2_ethdev.h | 3 +-
> drivers/net/octeontx2/otx2_ethdev_ops.c | 20 +-
> drivers/net/sfc/sfc_ethdev.c | 29 +-
> drivers/net/thunderx/nicvf_ethdev.c | 3 +-
> drivers/net/thunderx/nicvf_rxtx.c | 4 +-
> drivers/net/thunderx/nicvf_rxtx.h | 2 +-
> drivers/net/txgbe/txgbe_ethdev.h | 3 +-
> drivers/net/txgbe/txgbe_rxtx.c | 4 +-
> drivers/net/vhost/rte_eth_vhost.c | 4 +-
> drivers/net/virtio/virtio_ethdev.c | 1 -
> lib/ethdev/ethdev_driver.h | 148 +++++++++
> lib/ethdev/ethdev_private.c | 83 +++++
> lib/ethdev/ethdev_private.h | 7 +
> lib/ethdev/rte_ethdev.c | 89 ++++--
> lib/ethdev/rte_ethdev.h | 288 ++++++++++++------
> lib/ethdev/rte_ethdev_core.h | 171 +++--------
> lib/ethdev/version.map | 8 +-
> lib/eventdev/rte_event_eth_rx_adapter.c | 2 +-
> lib/eventdev/rte_event_eth_tx_adapter.c | 2 +-
> lib/eventdev/rte_eventdev.c | 2 +-
> lib/metrics/rte_metrics_telemetry.c | 2 +-
> 67 files changed, 677 insertions(+), 564 deletions(-)
>
> --
> 2.26.3
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v6] ethdev: fix representor port ID search by name
@ 2021-10-08 9:27 4% ` Andrew Rybchenko
2021-10-11 12:30 4% ` [dpdk-dev] [PATCH v7] " Andrew Rybchenko
2021-10-11 12:53 4% ` [dpdk-dev] [PATCH v8] " Andrew Rybchenko
3 siblings, 0 replies; 200+ results
From: Andrew Rybchenko @ 2021-10-08 9:27 UTC (permalink / raw)
To: Ajit Khaparde, Somnath Kotur, John Daley, Hyong Youb Kim,
Beilei Xing, Qiming Yang, Qi Zhang, Haiyue Wang, Matan Azrad,
Viacheslav Ovsiienko, Thomas Monjalon, Ferruh Yigit
Cc: dev, Viacheslav Galaktionov, Xueming Li
From: Viacheslav Galaktionov <viacheslav.galaktionov@oktetlabs.ru>
The patch is required for all PMDs which do not provide representors
info on the representor itself.
The function, rte_eth_representor_id_get(), is used in
eth_representor_cmp() which is required in ethdev class iterator to
search ethdev port ID by name (representor case). Before the patch
the function is called on the representor itself and tries to get
representors info to match.
Search of port ID by name is used after hotplug to find out port ID
of the just plugged device.
Getting a list of representors from a representor does not make sense.
Instead, a backer device should be used.
To this end, extend the rte_eth_dev_data structure to include the port ID
of the backing device for representors.
Signed-off-by: Viacheslav Galaktionov <viacheslav.galaktionov@oktetlabs.ru>
Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Acked-by: Haiyue Wang <haiyue.wang@intel.com>
Acked-by: Beilei Xing <beilei.xing@intel.com>
Reviewed-by: Xueming Li <xuemingl@nvidia.com>
---
The new field is added into the hole in rte_eth_dev_data structure.
The patch does not change ABI, but extra care is required since ABI
check is disabled for the structure because of the libabigail bug [1].
It should not be a problem anyway since 21.11 is a ABI breaking release.
Potentially it is bad for out-of-tree drivers which implement
representors but do not fill in a new backer_port_id field in
rte_eth_dev_data structure. Get ID by name will not work.
mlx5 changes should be reviwed by maintainers very carefully, since
we are not sure if we patch it correctly.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=28060
v6:
- provide more information in the changeset description
v5:
- try to improve name: backer_port_id instead of parent_port_id
- init new field to RTE_MAX_ETHPORTS on allocation to avoid
zero port usage by default
v4:
- apply mlx5 review notes: remove fallback from generic ethdev
code and add fallback to mlx5 code to handle legacy usecase
v3:
- fix mlx5 build breakage
v2:
- fix mlx5 review notes
- try device port ID first before parent in order to address
backward compatibility issue
drivers/net/bnxt/bnxt_reps.c | 1 +
drivers/net/enic/enic_vf_representor.c | 1 +
drivers/net/i40e/i40e_vf_representor.c | 1 +
drivers/net/ice/ice_dcf_vf_representor.c | 1 +
drivers/net/ixgbe/ixgbe_vf_representor.c | 1 +
drivers/net/mlx5/linux/mlx5_os.c | 13 +++++++++++++
drivers/net/mlx5/windows/mlx5_os.c | 13 +++++++++++++
lib/ethdev/ethdev_driver.h | 6 +++---
lib/ethdev/rte_class_eth.c | 2 +-
lib/ethdev/rte_ethdev.c | 9 +++++----
lib/ethdev/rte_ethdev_core.h | 6 ++++++
11 files changed, 46 insertions(+), 8 deletions(-)
diff --git a/drivers/net/bnxt/bnxt_reps.c b/drivers/net/bnxt/bnxt_reps.c
index df05619c3f..b7e88e013a 100644
--- a/drivers/net/bnxt/bnxt_reps.c
+++ b/drivers/net/bnxt/bnxt_reps.c
@@ -187,6 +187,7 @@ int bnxt_representor_init(struct rte_eth_dev *eth_dev, void *params)
eth_dev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR |
RTE_ETH_DEV_AUTOFILL_QUEUE_XSTATS;
eth_dev->data->representor_id = rep_params->vf_id;
+ eth_dev->data->backer_port_id = rep_params->parent_dev->data->port_id;
rte_eth_random_addr(vf_rep_bp->dflt_mac_addr);
memcpy(vf_rep_bp->mac_addr, vf_rep_bp->dflt_mac_addr,
diff --git a/drivers/net/enic/enic_vf_representor.c b/drivers/net/enic/enic_vf_representor.c
index cfd02c03cc..1a4411844a 100644
--- a/drivers/net/enic/enic_vf_representor.c
+++ b/drivers/net/enic/enic_vf_representor.c
@@ -666,6 +666,7 @@ int enic_vf_representor_init(struct rte_eth_dev *eth_dev, void *init_params)
eth_dev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR |
RTE_ETH_DEV_AUTOFILL_QUEUE_XSTATS;
eth_dev->data->representor_id = vf->vf_id;
+ eth_dev->data->backer_port_id = pf->port_id;
eth_dev->data->mac_addrs = rte_zmalloc("enic_mac_addr_vf",
sizeof(struct rte_ether_addr) *
ENIC_UNICAST_PERFECT_FILTERS, 0);
diff --git a/drivers/net/i40e/i40e_vf_representor.c b/drivers/net/i40e/i40e_vf_representor.c
index 0481b55381..d65b821a01 100644
--- a/drivers/net/i40e/i40e_vf_representor.c
+++ b/drivers/net/i40e/i40e_vf_representor.c
@@ -514,6 +514,7 @@ i40e_vf_representor_init(struct rte_eth_dev *ethdev, void *init_params)
ethdev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR |
RTE_ETH_DEV_AUTOFILL_QUEUE_XSTATS;
ethdev->data->representor_id = representor->vf_id;
+ ethdev->data->backer_port_id = pf->dev_data->port_id;
/* Setting the number queues allocated to the VF */
ethdev->data->nb_rx_queues = vf->vsi->nb_qps;
diff --git a/drivers/net/ice/ice_dcf_vf_representor.c b/drivers/net/ice/ice_dcf_vf_representor.c
index b547c42f91..c5335ac3cc 100644
--- a/drivers/net/ice/ice_dcf_vf_representor.c
+++ b/drivers/net/ice/ice_dcf_vf_representor.c
@@ -426,6 +426,7 @@ ice_dcf_vf_repr_init(struct rte_eth_dev *vf_rep_eth_dev, void *init_param)
vf_rep_eth_dev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR;
vf_rep_eth_dev->data->representor_id = repr->vf_id;
+ vf_rep_eth_dev->data->backer_port_id = repr->dcf_eth_dev->data->port_id;
vf_rep_eth_dev->data->mac_addrs = &repr->mac_addr;
diff --git a/drivers/net/ixgbe/ixgbe_vf_representor.c b/drivers/net/ixgbe/ixgbe_vf_representor.c
index d5b636a194..9fa75984fb 100644
--- a/drivers/net/ixgbe/ixgbe_vf_representor.c
+++ b/drivers/net/ixgbe/ixgbe_vf_representor.c
@@ -197,6 +197,7 @@ ixgbe_vf_representor_init(struct rte_eth_dev *ethdev, void *init_params)
ethdev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR;
ethdev->data->representor_id = representor->vf_id;
+ ethdev->data->backer_port_id = representor->pf_ethdev->data->port_id;
/* Set representor device ops */
ethdev->dev_ops = &ixgbe_vf_representor_dev_ops;
diff --git a/drivers/net/mlx5/linux/mlx5_os.c b/drivers/net/mlx5/linux/mlx5_os.c
index 3746057673..612340b3b6 100644
--- a/drivers/net/mlx5/linux/mlx5_os.c
+++ b/drivers/net/mlx5/linux/mlx5_os.c
@@ -1677,6 +1677,19 @@ mlx5_dev_spawn(struct rte_device *dpdk_dev,
if (priv->representor) {
eth_dev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR;
eth_dev->data->representor_id = priv->representor_id;
+ MLX5_ETH_FOREACH_DEV(port_id, &priv->pci_dev->device) {
+ struct mlx5_priv *opriv =
+ rte_eth_devices[port_id].data->dev_private;
+ if (opriv &&
+ opriv->master &&
+ opriv->domain_id == priv->domain_id &&
+ opriv->sh == priv->sh) {
+ eth_dev->data->backer_port_id = port_id;
+ break;
+ }
+ }
+ if (port_id >= RTE_MAX_ETHPORTS)
+ eth_dev->data->backer_port_id = eth_dev->data->port_id;
}
priv->mp_id.port_id = eth_dev->data->port_id;
strlcpy(priv->mp_id.name, MLX5_MP_NAME, RTE_MP_MAX_NAME_LEN);
diff --git a/drivers/net/mlx5/windows/mlx5_os.c b/drivers/net/mlx5/windows/mlx5_os.c
index 26fa927039..a9c244c7dc 100644
--- a/drivers/net/mlx5/windows/mlx5_os.c
+++ b/drivers/net/mlx5/windows/mlx5_os.c
@@ -543,6 +543,19 @@ mlx5_dev_spawn(struct rte_device *dpdk_dev,
if (priv->representor) {
eth_dev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR;
eth_dev->data->representor_id = priv->representor_id;
+ MLX5_ETH_FOREACH_DEV(port_id, &priv->pci_dev->device) {
+ struct mlx5_priv *opriv =
+ rte_eth_devices[port_id].data->dev_private;
+ if (opriv &&
+ opriv->master &&
+ opriv->domain_id == priv->domain_id &&
+ opriv->sh == priv->sh) {
+ eth_dev->data->backer_port_id = port_id;
+ break;
+ }
+ }
+ if (port_id >= RTE_MAX_ETHPORTS)
+ eth_dev->data->backer_port_id = eth_dev->data->port_id;
}
/*
* Store associated network device interface index. This index
diff --git a/lib/ethdev/ethdev_driver.h b/lib/ethdev/ethdev_driver.h
index 7ce0f7729a..c4ea735732 100644
--- a/lib/ethdev/ethdev_driver.h
+++ b/lib/ethdev/ethdev_driver.h
@@ -1266,8 +1266,8 @@ struct rte_eth_devargs {
* For backward compatibility, if no representor info, direct
* map legacy VF (no controller and pf).
*
- * @param ethdev
- * Handle of ethdev port.
+ * @param port_id
+ * Port ID of the backing device.
* @param type
* Representor type.
* @param controller
@@ -1284,7 +1284,7 @@ struct rte_eth_devargs {
*/
__rte_internal
int
-rte_eth_representor_id_get(const struct rte_eth_dev *ethdev,
+rte_eth_representor_id_get(uint16_t port_id,
enum rte_eth_representor_type type,
int controller, int pf, int representor_port,
uint16_t *repr_id);
diff --git a/lib/ethdev/rte_class_eth.c b/lib/ethdev/rte_class_eth.c
index 1fe5fa1f36..eda216ced5 100644
--- a/lib/ethdev/rte_class_eth.c
+++ b/lib/ethdev/rte_class_eth.c
@@ -95,7 +95,7 @@ eth_representor_cmp(const char *key __rte_unused,
c = i / (np * nf);
p = (i / nf) % np;
f = i % nf;
- if (rte_eth_representor_id_get(edev,
+ if (rte_eth_representor_id_get(edev->data->backer_port_id,
eth_da.type,
eth_da.nb_mh_controllers == 0 ? -1 :
eth_da.mh_controllers[c],
diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index 028907bc4b..ed7b43a99f 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -524,6 +524,7 @@ rte_eth_dev_allocate(const char *name)
eth_dev = eth_dev_get(port_id);
strlcpy(eth_dev->data->name, name, sizeof(eth_dev->data->name));
eth_dev->data->port_id = port_id;
+ eth_dev->data->backer_port_id = RTE_MAX_ETHPORTS;
eth_dev->data->mtu = RTE_ETHER_MTU;
pthread_mutex_init(ð_dev->data->flow_ops_mutex, NULL);
@@ -5915,7 +5916,7 @@ rte_eth_devargs_parse(const char *dargs, struct rte_eth_devargs *eth_da)
}
int
-rte_eth_representor_id_get(const struct rte_eth_dev *ethdev,
+rte_eth_representor_id_get(uint16_t port_id,
enum rte_eth_representor_type type,
int controller, int pf, int representor_port,
uint16_t *repr_id)
@@ -5931,7 +5932,7 @@ rte_eth_representor_id_get(const struct rte_eth_dev *ethdev,
return -EINVAL;
/* Get PMD representor range info. */
- ret = rte_eth_representor_info_get(ethdev->data->port_id, NULL);
+ ret = rte_eth_representor_info_get(port_id, NULL);
if (ret == -ENOTSUP && type == RTE_ETH_REPRESENTOR_VF &&
controller == -1 && pf == -1) {
/* Direct mapping for legacy VF representor. */
@@ -5946,7 +5947,7 @@ rte_eth_representor_id_get(const struct rte_eth_dev *ethdev,
if (info == NULL)
return -ENOMEM;
info->nb_ranges_alloc = n;
- ret = rte_eth_representor_info_get(ethdev->data->port_id, info);
+ ret = rte_eth_representor_info_get(port_id, info);
if (ret < 0)
goto out;
@@ -5965,7 +5966,7 @@ rte_eth_representor_id_get(const struct rte_eth_dev *ethdev,
continue;
if (info->ranges[i].id_end < info->ranges[i].id_base) {
RTE_LOG(WARNING, EAL, "Port %hu invalid representor ID Range %u - %u, entry %d\n",
- ethdev->data->port_id, info->ranges[i].id_base,
+ port_id, info->ranges[i].id_base,
info->ranges[i].id_end, i);
continue;
diff --git a/lib/ethdev/rte_ethdev_core.h b/lib/ethdev/rte_ethdev_core.h
index d2c9ec42c7..66ad8b13c8 100644
--- a/lib/ethdev/rte_ethdev_core.h
+++ b/lib/ethdev/rte_ethdev_core.h
@@ -185,6 +185,12 @@ struct rte_eth_dev_data {
/**< Switch-specific identifier.
* Valid if RTE_ETH_DEV_REPRESENTOR in dev_flags.
*/
+ uint16_t backer_port_id;
+ /**< Port ID of the backing device.
+ * This device will be used to query representor
+ * info and calculate representor IDs.
+ * Valid if RTE_ETH_DEV_REPRESENTOR in dev_flags.
+ */
pthread_mutex_t flow_ops_mutex; /**< rte_flow ops mutex. */
uint64_t reserved_64s[4]; /**< Reserved for future fields */
--
2.30.2
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v5] ethdev: fix representor port ID search by name
@ 2021-10-08 8:39 0% ` Xueming(Steven) Li
0 siblings, 0 replies; 200+ results
From: Xueming(Steven) Li @ 2021-10-08 8:39 UTC (permalink / raw)
To: johndale, qi.z.zhang, Slava Ovsiienko, somnath.kotur,
ajit.khaparde, andrew.rybchenko, Matan Azrad, hyonkim,
qiming.yang
Cc: beilei.xing, NBU-Contact-Thomas Monjalon, dev, haiyue.wang,
viacheslav.galaktionov, ferruh.yigit
On Fri, 2021-10-01 at 14:39 +0300, Andrew Rybchenko wrote:
> Hello PMD maintainers,
>
> please, review the patch.
>
> It is especially important for net/mlx5 since changes there are
> not trivial.
>
> Thanks,
> Andrew.
>
> On 9/13/21 2:26 PM, Andrew Rybchenko wrote:
> > From: Viacheslav Galaktionov <viacheslav.galaktionov@oktetlabs.ru>
> >
> > Getting a list of representors from a representor does not make sense.
> > Instead, a parent device should be used.
> >
> > To this end, extend the rte_eth_dev_data structure to include the port ID
> > of the backing device for representors.
> >
> > Signed-off-by: Viacheslav Galaktionov <viacheslav.galaktionov@oktetlabs.ru>
> > Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> > Acked-by: Haiyue Wang <haiyue.wang@intel.com>
> > Acked-by: Beilei Xing <beilei.xing@intel.com>
> > ---
> > The new field is added into the hole in rte_eth_dev_data structure.
> > The patch does not change ABI, but extra care is required since ABI
> > check is disabled for the structure because of the libabigail bug [1].
> > It should not be a problem anyway since 21.11 is a ABI breaking release.
> >
> > Potentially it is bad for out-of-tree drivers which implement
> > representors but do not fill in a new parert_port_id field in
> > rte_eth_dev_data structure. Get ID by name will not work.
> >
> > mlx5 changes should be reviwed by maintainers very carefully, since
> > we are not sure if we patch it correctly.
> >
> > [1] https://sourceware.org/bugzilla/show_bug.cgi?id=28060
> >
> > v5:
> > - try to improve name: backer_port_id instead of parent_port_id
> > - init new field to RTE_MAX_ETHPORTS on allocation to avoid
> > zero port usage by default
> >
> > v4:
> > - apply mlx5 review notes: remove fallback from generic ethdev
> > code and add fallback to mlx5 code to handle legacy usecase
> >
> > v3:
> > - fix mlx5 build breakage
> >
> > v2:
> > - fix mlx5 review notes
> > - try device port ID first before parent in order to address
> > backward compatibility issue
> >
> > drivers/net/bnxt/bnxt_reps.c | 1 +
> > drivers/net/enic/enic_vf_representor.c | 1 +
> > drivers/net/i40e/i40e_vf_representor.c | 1 +
> > drivers/net/ice/ice_dcf_vf_representor.c | 1 +
> > drivers/net/ixgbe/ixgbe_vf_representor.c | 1 +
> > drivers/net/mlx5/linux/mlx5_os.c | 13 +++++++++++++
> > drivers/net/mlx5/windows/mlx5_os.c | 13 +++++++++++++
> > lib/ethdev/ethdev_driver.h | 6 +++---
> > lib/ethdev/rte_class_eth.c | 2 +-
> > lib/ethdev/rte_ethdev.c | 9 +++++----
> > lib/ethdev/rte_ethdev_core.h | 6 ++++++
> > 11 files changed, 46 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/net/bnxt/bnxt_reps.c b/drivers/net/bnxt/bnxt_reps.c
> > index bdbad53b7d..0d50c0f1da 100644
> > --- a/drivers/net/bnxt/bnxt_reps.c
> > +++ b/drivers/net/bnxt/bnxt_reps.c
> > @@ -187,6 +187,7 @@ int bnxt_representor_init(struct rte_eth_dev *eth_dev, void *params)
> > eth_dev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR |
> > RTE_ETH_DEV_AUTOFILL_QUEUE_XSTATS;
> > eth_dev->data->representor_id = rep_params->vf_id;
> > + eth_dev->data->backer_port_id = rep_params->parent_dev->data->port_id;
> >
> > rte_eth_random_addr(vf_rep_bp->dflt_mac_addr);
> > memcpy(vf_rep_bp->mac_addr, vf_rep_bp->dflt_mac_addr,
> > diff --git a/drivers/net/enic/enic_vf_representor.c b/drivers/net/enic/enic_vf_representor.c
> > index 79dd6e5640..fedb09ecd6 100644
> > --- a/drivers/net/enic/enic_vf_representor.c
> > +++ b/drivers/net/enic/enic_vf_representor.c
> > @@ -662,6 +662,7 @@ int enic_vf_representor_init(struct rte_eth_dev *eth_dev, void *init_params)
> > eth_dev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR |
> > RTE_ETH_DEV_AUTOFILL_QUEUE_XSTATS;
> > eth_dev->data->representor_id = vf->vf_id;
> > + eth_dev->data->backer_port_id = pf->port_id;
> > eth_dev->data->mac_addrs = rte_zmalloc("enic_mac_addr_vf",
> > sizeof(struct rte_ether_addr) *
> > ENIC_UNICAST_PERFECT_FILTERS, 0);
> > diff --git a/drivers/net/i40e/i40e_vf_representor.c b/drivers/net/i40e/i40e_vf_representor.c
> > index 0481b55381..d65b821a01 100644
> > --- a/drivers/net/i40e/i40e_vf_representor.c
> > +++ b/drivers/net/i40e/i40e_vf_representor.c
> > @@ -514,6 +514,7 @@ i40e_vf_representor_init(struct rte_eth_dev *ethdev, void *init_params)
> > ethdev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR |
> > RTE_ETH_DEV_AUTOFILL_QUEUE_XSTATS;
> > ethdev->data->representor_id = representor->vf_id;
> > + ethdev->data->backer_port_id = pf->dev_data->port_id;
> >
> > /* Setting the number queues allocated to the VF */
> > ethdev->data->nb_rx_queues = vf->vsi->nb_qps;
> > diff --git a/drivers/net/ice/ice_dcf_vf_representor.c b/drivers/net/ice/ice_dcf_vf_representor.c
> > index 970461f3e9..e51d0aa6b9 100644
> > --- a/drivers/net/ice/ice_dcf_vf_representor.c
> > +++ b/drivers/net/ice/ice_dcf_vf_representor.c
> > @@ -418,6 +418,7 @@ ice_dcf_vf_repr_init(struct rte_eth_dev *vf_rep_eth_dev, void *init_param)
> >
> > vf_rep_eth_dev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR;
> > vf_rep_eth_dev->data->representor_id = repr->vf_id;
> > + vf_rep_eth_dev->data->backer_port_id = repr->dcf_eth_dev->data->port_id;
> >
> > vf_rep_eth_dev->data->mac_addrs = &repr->mac_addr;
> >
> > diff --git a/drivers/net/ixgbe/ixgbe_vf_representor.c b/drivers/net/ixgbe/ixgbe_vf_representor.c
> > index d5b636a194..9fa75984fb 100644
> > --- a/drivers/net/ixgbe/ixgbe_vf_representor.c
> > +++ b/drivers/net/ixgbe/ixgbe_vf_representor.c
> > @@ -197,6 +197,7 @@ ixgbe_vf_representor_init(struct rte_eth_dev *ethdev, void *init_params)
> >
> > ethdev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR;
> > ethdev->data->representor_id = representor->vf_id;
> > + ethdev->data->backer_port_id = representor->pf_ethdev->data->port_id;
> >
> > /* Set representor device ops */
> > ethdev->dev_ops = &ixgbe_vf_representor_dev_ops;
> > diff --git a/drivers/net/mlx5/linux/mlx5_os.c b/drivers/net/mlx5/linux/mlx5_os.c
> > index 470b16cb9a..1cddaaba1a 100644
> > --- a/drivers/net/mlx5/linux/mlx5_os.c
> > +++ b/drivers/net/mlx5/linux/mlx5_os.c
> > @@ -1677,6 +1677,19 @@ mlx5_dev_spawn(struct rte_device *dpdk_dev,
> > if (priv->representor) {
> > eth_dev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR;
> > eth_dev->data->representor_id = priv->representor_id;
> > + MLX5_ETH_FOREACH_DEV(port_id, &priv->pci_dev->device) {
> > + struct mlx5_priv *opriv =
> > + rte_eth_devices[port_id].data->dev_private;
> > + if (opriv &&
> > + opriv->master &&
> > + opriv->domain_id == priv->domain_id &&
> > + opriv->sh == priv->sh) {
> > + eth_dev->data->backer_port_id = port_id;
> > + break;
> > + }
> > + }
> > + if (port_id >= RTE_MAX_ETHPORTS)
> > + eth_dev->data->backer_port_id = eth_dev->data->port_id;
> > }
> > priv->mp_id.port_id = eth_dev->data->port_id;
> > strlcpy(priv->mp_id.name, MLX5_MP_NAME, RTE_MP_MAX_NAME_LEN);
> > diff --git a/drivers/net/mlx5/windows/mlx5_os.c b/drivers/net/mlx5/windows/mlx5_os.c
> > index 26fa927039..a9c244c7dc 100644
> > --- a/drivers/net/mlx5/windows/mlx5_os.c
> > +++ b/drivers/net/mlx5/windows/mlx5_os.c
> > @@ -543,6 +543,19 @@ mlx5_dev_spawn(struct rte_device *dpdk_dev,
> > if (priv->representor) {
> > eth_dev->data->dev_flags |= RTE_ETH_DEV_REPRESENTOR;
> > eth_dev->data->representor_id = priv->representor_id;
> > + MLX5_ETH_FOREACH_DEV(port_id, &priv->pci_dev->device) {
> > + struct mlx5_priv *opriv =
> > + rte_eth_devices[port_id].data->dev_private;
> > + if (opriv &&
> > + opriv->master &&
> > + opriv->domain_id == priv->domain_id &&
> > + opriv->sh == priv->sh) {
> > + eth_dev->data->backer_port_id = port_id;
> > + break;
> > + }
> > + }
> > + if (port_id >= RTE_MAX_ETHPORTS)
> > + eth_dev->data->backer_port_id = eth_dev->data->port_id;
> > }
> > /*
> > * Store associated network device interface index. This index
> > diff --git a/lib/ethdev/ethdev_driver.h b/lib/ethdev/ethdev_driver.h
> > index 40e474aa7e..b940e6cb38 100644
> > --- a/lib/ethdev/ethdev_driver.h
> > +++ b/lib/ethdev/ethdev_driver.h
> > @@ -1248,8 +1248,8 @@ struct rte_eth_devargs {
> > * For backward compatibility, if no representor info, direct
> > * map legacy VF (no controller and pf).
> > *
> > - * @param ethdev
> > - * Handle of ethdev port.
> > + * @param port_id
> > + * Port ID of the backing device.
> > * @param type
> > * Representor type.
> > * @param controller
> > @@ -1266,7 +1266,7 @@ struct rte_eth_devargs {
> > */
> > __rte_internal
> > int
> > -rte_eth_representor_id_get(const struct rte_eth_dev *ethdev,
> > +rte_eth_representor_id_get(uint16_t port_id,
> > enum rte_eth_representor_type type,
> > int controller, int pf, int representor_port,
> > uint16_t *repr_id);
> > diff --git a/lib/ethdev/rte_class_eth.c b/lib/ethdev/rte_class_eth.c
> > index 1fe5fa1f36..eda216ced5 100644
> > --- a/lib/ethdev/rte_class_eth.c
> > +++ b/lib/ethdev/rte_class_eth.c
> > @@ -95,7 +95,7 @@ eth_representor_cmp(const char *key __rte_unused,
> > c = i / (np * nf);
> > p = (i / nf) % np;
> > f = i % nf;
> > - if (rte_eth_representor_id_get(edev,
> > + if (rte_eth_representor_id_get(edev->data->backer_port_id,
> > eth_da.type,
> > eth_da.nb_mh_controllers == 0 ? -1 :
> > eth_da.mh_controllers[c],
> > diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
> > index daf5ca9242..7c9b0d6b3b 100644
> > --- a/lib/ethdev/rte_ethdev.c
> > +++ b/lib/ethdev/rte_ethdev.c
> > @@ -524,6 +524,7 @@ rte_eth_dev_allocate(const char *name)
> > eth_dev = eth_dev_get(port_id);
> > strlcpy(eth_dev->data->name, name, sizeof(eth_dev->data->name));
> > eth_dev->data->port_id = port_id;
> > + eth_dev->data->backer_port_id = RTE_MAX_ETHPORTS;
> > eth_dev->data->mtu = RTE_ETHER_MTU;
> > pthread_mutex_init(ð_dev->data->flow_ops_mutex, NULL);
> >
> > @@ -5996,7 +5997,7 @@ rte_eth_devargs_parse(const char *dargs, struct rte_eth_devargs *eth_da)
> > }
> >
> > int
> > -rte_eth_representor_id_get(const struct rte_eth_dev *ethdev,
> > +rte_eth_representor_id_get(uint16_t port_id,
> > enum rte_eth_representor_type type,
> > int controller, int pf, int representor_port,
> > uint16_t *repr_id)
> > @@ -6012,7 +6013,7 @@ rte_eth_representor_id_get(const struct rte_eth_dev *ethdev,
> > return -EINVAL;
> >
> > /* Get PMD representor range info. */
> > - ret = rte_eth_representor_info_get(ethdev->data->port_id, NULL);
> > + ret = rte_eth_representor_info_get(port_id, NULL);
> > if (ret == -ENOTSUP && type == RTE_ETH_REPRESENTOR_VF &&
> > controller == -1 && pf == -1) {
> > /* Direct mapping for legacy VF representor. */
> > @@ -6027,7 +6028,7 @@ rte_eth_representor_id_get(const struct rte_eth_dev *ethdev,
> > if (info == NULL)
> > return -ENOMEM;
> > info->nb_ranges_alloc = n;
> > - ret = rte_eth_representor_info_get(ethdev->data->port_id, info);
> > + ret = rte_eth_representor_info_get(port_id, info);
> > if (ret < 0)
> > goto out;
> >
> > @@ -6046,7 +6047,7 @@ rte_eth_representor_id_get(const struct rte_eth_dev *ethdev,
> > continue;
> > if (info->ranges[i].id_end < info->ranges[i].id_base) {
> > RTE_LOG(WARNING, EAL, "Port %hu invalid representor ID Range %u - %u, entry %d\n",
> > - ethdev->data->port_id, info->ranges[i].id_base,
> > + port_id, info->ranges[i].id_base,
> > info->ranges[i].id_end, i);
> > continue;
> >
> > diff --git a/lib/ethdev/rte_ethdev_core.h b/lib/ethdev/rte_ethdev_core.h
> > index edf96de2dc..48b814e8a1 100644
> > --- a/lib/ethdev/rte_ethdev_core.h
> > +++ b/lib/ethdev/rte_ethdev_core.h
> > @@ -185,6 +185,12 @@ struct rte_eth_dev_data {
> > /**< Switch-specific identifier.
> > * Valid if RTE_ETH_DEV_REPRESENTOR in dev_flags.
> > */
> > + uint16_t backer_port_id;
> > + /**< Port ID of the backing device.
> > + * This device will be used to query representor
> > + * info and calculate representor IDs.
> > + * Valid if RTE_ETH_DEV_REPRESENTOR in dev_flags.
> > + */
> >
> > pthread_mutex_t flow_ops_mutex; /**< rte_flow ops mutex. */
> > uint64_t reserved_64s[4]; /**< Reserved for future fields */
> >
>
Reviewed-by: Xueming Li <xuemingl@nvidia.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs
2021-10-08 7:08 0% ` David Marchand
@ 2021-10-08 7:44 0% ` Liu, Changpeng
2021-10-11 6:58 0% ` Xia, Chenbo
0 siblings, 1 reply; 200+ results
From: Liu, Changpeng @ 2021-10-08 7:44 UTC (permalink / raw)
To: David Marchand, Harris, James R
Cc: Xia, Chenbo, dev, ci, Aaron Conole, dpdklab, Zawadzki, Tomasz, alexeymar
Thanks, I have worked with Chenbo to address this issue before. After enable the `ALLOW_INTERNAL_API` option, it works now with SPDK.
Another issue raised by Jim Harris is that for distro packaged DPDK, since this option isn't enabled by default, this will not allow SPDK
to use the distro packaged DPDK after this release.
> -----Original Message-----
> From: David Marchand <david.marchand@redhat.com>
> Sent: Friday, October 8, 2021 3:08 PM
> To: Liu, Changpeng <changpeng.liu@intel.com>
> Cc: Xia, Chenbo <chenbo.xia@intel.com>; Harris, James R
> <james.r.harris@intel.com>; dev@dpdk.org; ci@dpdk.org; Aaron Conole
> <aconole@redhat.com>; dpdklab <dpdklab@iol.unh.edu>; Zawadzki, Tomasz
> <tomasz.zawadzki@intel.com>; alexeymar@mellanox.com
> Subject: Re: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs
>
> Hello,
>
> On Fri, Oct 8, 2021 at 8:15 AM Liu, Changpeng <changpeng.liu@intel.com> wrote:
> >
> > I tried the above DPDK patches, and got the following errors:
> >
> > pci.c:115:7: error: call to ‘rte_pci_read_config’ declared with attribute error:
> Symbol is not public ABI
> > 115 | rc = rte_pci_read_config(dev->dev_handle, value, len, offset);
> > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > pci.c: In function ‘cfg_write_rte’:
> > pci.c:125:7: error: call to ‘rte_pci_write_config’ declared with attribute error:
> Symbol is not public ABI
> > 125 | rc = rte_pci_write_config(dev->dev_handle, value, len, offset);
> > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > pci.c: In function ‘register_rte_driver’:
> > pci.c:375:2: error: call to ‘rte_pci_register’ declared with attribute error:
> Symbol is not public ABI
> > 375 | rte_pci_register(&driver->driver);
>
> I should have got this warning... but compilation passed fine for me.
> Happy you tested it.
>
> >
> > We may use the new added API to replace rte_pci_write_config and
> rte_pci_read_config, but SPDK
> > do require rte_pci_register().
>
> Since SPDK has a PCI driver, you'll need to compile code that calls
> those PCI driver internal API with ALLOW_INTERNAL_API defined.
> You can probably add a #define ALLOW_INTERNAL_API first thing (it's
> important to have it defined before including any dpdk header) in
> pci.c
>
> Another option, is to add it to lib/env_dpdk/env.mk:ENV_CFLAGS =
> $(DPDK_INC) -DALLOW_EXPERIMENTAL_API.
>
> Can someone from SPDK take over this and sync with Chenbo?
>
>
> Thanks.
>
> --
> David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs
2021-10-08 6:15 4% ` Liu, Changpeng
@ 2021-10-08 7:08 0% ` David Marchand
2021-10-08 7:44 0% ` Liu, Changpeng
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2021-10-08 7:08 UTC (permalink / raw)
To: Liu, Changpeng
Cc: Xia, Chenbo, Harris, James R, dev, ci, Aaron Conole, dpdklab,
Zawadzki, Tomasz, alexeymar
Hello,
On Fri, Oct 8, 2021 at 8:15 AM Liu, Changpeng <changpeng.liu@intel.com> wrote:
>
> I tried the above DPDK patches, and got the following errors:
>
> pci.c:115:7: error: call to ‘rte_pci_read_config’ declared with attribute error: Symbol is not public ABI
> 115 | rc = rte_pci_read_config(dev->dev_handle, value, len, offset);
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> pci.c: In function ‘cfg_write_rte’:
> pci.c:125:7: error: call to ‘rte_pci_write_config’ declared with attribute error: Symbol is not public ABI
> 125 | rc = rte_pci_write_config(dev->dev_handle, value, len, offset);
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> pci.c: In function ‘register_rte_driver’:
> pci.c:375:2: error: call to ‘rte_pci_register’ declared with attribute error: Symbol is not public ABI
> 375 | rte_pci_register(&driver->driver);
I should have got this warning... but compilation passed fine for me.
Happy you tested it.
>
> We may use the new added API to replace rte_pci_write_config and rte_pci_read_config, but SPDK
> do require rte_pci_register().
Since SPDK has a PCI driver, you'll need to compile code that calls
those PCI driver internal API with ALLOW_INTERNAL_API defined.
You can probably add a #define ALLOW_INTERNAL_API first thing (it's
important to have it defined before including any dpdk header) in
pci.c
Another option, is to add it to lib/env_dpdk/env.mk:ENV_CFLAGS =
$(DPDK_INC) -DALLOW_EXPERIMENTAL_API.
Can someone from SPDK take over this and sync with Chenbo?
Thanks.
--
David Marchand
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v3 1/2] lib/cmdline: release cl when cmdline exit
@ 2021-10-08 6:41 4% ` zhihongx.peng
2021-10-11 5:20 0% ` Peng, ZhihongX
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: zhihongx.peng @ 2021-10-08 6:41 UTC (permalink / raw)
To: olivier.matz, dmitry.kozliuk; +Cc: dev, Zhihong Peng, stable
From: Zhihong Peng <zhihongx.peng@intel.com>
Malloc cl in the cmdline_stdin_new function, so release in the
cmdline_stdin_exit function is logical, so that cl will not be
released alone.
Fixes: af75078fece3 (first public release)
Cc: stable@dpdk.org
Signed-off-by: Zhihong Peng <zhihongx.peng@intel.com>
---
doc/guides/rel_notes/release_21_11.rst | 5 +++++
lib/cmdline/cmdline_socket.c | 1 +
2 files changed, 6 insertions(+)
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index efeffe37a0..be24925d16 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -191,6 +191,11 @@ API Changes
the crypto/security operation. This field will be used to communicate
events such as soft expiry with IPsec in lookaside mode.
+* cmdline: The API cmdline_stdin_exit has added cmdline_free function.
+ Malloc cl in the cmdline_stdin_new function, so release in the
+ cmdline_stdin_exit function is logical. The application code
+ that calls cmdline_free needs to be deleted.
+
ABI Changes
-----------
diff --git a/lib/cmdline/cmdline_socket.c b/lib/cmdline/cmdline_socket.c
index 998e8ade25..ebd5343754 100644
--- a/lib/cmdline/cmdline_socket.c
+++ b/lib/cmdline/cmdline_socket.c
@@ -53,4 +53,5 @@ cmdline_stdin_exit(struct cmdline *cl)
return;
terminal_restore(cl);
+ cmdline_free(cl);
}
--
2.25.1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs
@ 2021-10-08 6:15 4% ` Liu, Changpeng
2021-10-08 7:08 0% ` David Marchand
0 siblings, 1 reply; 200+ results
From: Liu, Changpeng @ 2021-10-08 6:15 UTC (permalink / raw)
To: Xia, Chenbo, Harris, James R, David Marchand
Cc: dev, ci, Aaron Conole, dpdklab, Zawadzki, Tomasz, alexeymar
I tried the above DPDK patches, and got the following errors:
pci.c:115:7: error: call to ‘rte_pci_read_config’ declared with attribute error: Symbol is not public ABI
115 | rc = rte_pci_read_config(dev->dev_handle, value, len, offset);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pci.c: In function ‘cfg_write_rte’:
pci.c:125:7: error: call to ‘rte_pci_write_config’ declared with attribute error: Symbol is not public ABI
125 | rc = rte_pci_write_config(dev->dev_handle, value, len, offset);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pci.c: In function ‘register_rte_driver’:
pci.c:375:2: error: call to ‘rte_pci_register’ declared with attribute error: Symbol is not public ABI
375 | rte_pci_register(&driver->driver);
We may use the new added API to replace rte_pci_write_config and rte_pci_read_config, but SPDK
do require rte_pci_register().
> -----Original Message-----
> From: Xia, Chenbo <chenbo.xia@intel.com>
> Sent: Wednesday, October 6, 2021 12:26 PM
> To: Harris, James R <james.r.harris@intel.com>; David Marchand
> <david.marchand@redhat.com>; Liu, Changpeng <changpeng.liu@intel.com>
> Cc: dev@dpdk.org; ci@dpdk.org; Aaron Conole <aconole@redhat.com>; dpdklab
> <dpdklab@iol.unh.edu>; Zawadzki, Tomasz <tomasz.zawadzki@intel.com>;
> alexeymar@mellanox.com
> Subject: RE: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs
>
> Thanks David for helping check this and including SPDK folks!
>
> Hi Changpeng,
>
> Although we have synced about this during last release's deprecation notice,
> I’d like to summarize two points for SPDK to change if this patchset applied.
>
> 1. The pci bus header for drivers will only be exposed if meson option
> 'enable_driver_sdk' is added, so SPDK need this DPDK meson option to build.
>
> 2. As some functions in pci bus is needed for apps and the rest for drivers,
> the header for driver is renamed to pci_driver.h (header for app is rte_bus_pci.h).
> So SPDK drivers will need pci_driver.h instead of rte_bus_pci.h starting from
> DPDK
> 21.11. David showed some tests he did below.
>
> Could you help check above two updates are fine to SPDK?
>
> Thanks,
> Chenbo
>
> > -----Original Message-----
> > From: Harris, James R <james.r.harris@intel.com>
> > Sent: Monday, October 4, 2021 11:56 PM
> > To: David Marchand <david.marchand@redhat.com>; Xia, Chenbo
> > <chenbo.xia@intel.com>; Liu, Changpeng <changpeng.liu@intel.com>
> > Cc: dev@dpdk.org; ci@dpdk.org; Aaron Conole <aconole@redhat.com>;
> dpdklab
> > <dpdklab@iol.unh.edu>; Zawadzki, Tomasz <tomasz.zawadzki@intel.com>;
> > alexeymar@mellanox.com
> > Subject: Re: [dpdk-dev] [PATCH v2 0/7] Removal of PCI bus ABIs
> >
> > Adding Changpeng Liu from SPDK side.
> >
> > On 10/4/21, 6:48 AM, "David Marchand" <david.marchand@redhat.com>
> wrote:
> >
> > On Thu, Sep 30, 2021 at 10:45 AM David Marchand
> > <david.marchand@redhat.com> wrote:
> > > On Wed, Sep 29, 2021 at 9:38 AM Xia, Chenbo <chenbo.xia@intel.com>
> > wrote:
> > > > @David, could you help me understand what is the compile error in
> > Fedora 31?
> > > > DPDK_compile_spdk failure is expected as the header name for SPDK
> > is changed,
> > > > I am not sure if it's the same error...
> > >
> > > The error log is odd (no compilation "backtrace").
> > > You'll need to test spdk manually I guess.
> >
> > Tried your series with SPDK (w/o and w/ enable_driver_sdk).
> > I think the same, and the error is likely due to the file rename.
> >
> > $ make
> > CC lib/env_dpdk/env.o
> > In file included from env.c:39:0:
> > env_internal.h:64:25: error: field ‘driver’ has incomplete type
> > struct rte_pci_driver driver;
> > ^
> > env_internal.h:75:59: warning: ‘struct rte_pci_device’ declared inside
> > parameter list [enabled by default]
> > int pci_device_init(struct rte_pci_driver *driver, struct
> > rte_pci_device *device);
> > ^
> > env_internal.h:75:59: warning: its scope is only this definition or
> > declaration, which is probably not what you want [enabled by default]
> > env_internal.h:76:28: warning: ‘struct rte_pci_device’ declared inside
> > parameter list [enabled by default]
> > int pci_device_fini(struct rte_pci_device *device);
> > ^
> > env_internal.h:89:38: warning: ‘struct rte_pci_device’ declared inside
> > parameter list [enabled by default]
> > void vtophys_pci_device_added(struct rte_pci_device *pci_device);
> > ^
> > env_internal.h:96:40: warning: ‘struct rte_pci_device’ declared inside
> > parameter list [enabled by default]
> > void vtophys_pci_device_removed(struct rte_pci_device *pci_device);
> > ^
> > make[2]: *** [env.o] Error 1
> > make[1]: *** [env_dpdk] Error 2
> > make: *** [lib] Error 2
> >
> >
> >
> > So basically, SPDK needs some updates since it has its own pci drivers.
> > I copied some SPDK folks for info.
> >
> > *Disclaimer* I only checked it links fine against my 21.11 dpdk env,
> > and did not test the other cases:
> >
> > diff --git a/dpdkbuild/Makefile b/dpdkbuild/Makefile
> > index d51b1a6e5..0e666735d 100644
> > --- a/dpdkbuild/Makefile
> > +++ b/dpdkbuild/Makefile
> > @@ -166,6 +166,7 @@ all: $(SPDK_ROOT_DIR)/dpdk/build-tmp
> > $(SPDK_ROOT_DIR)/dpdk/build-tmp: $(SPDK_ROOT_DIR)/mk/cc.mk
> > $(SPDK_ROOT_DIR)/include/spdk/config.h
> > $(Q)rm -rf $(SPDK_ROOT_DIR)/dpdk/build
> > $(SPDK_ROOT_DIR)/dpdk/build-tmp
> > $(Q)cd "$(SPDK_ROOT_DIR)/dpdk"; CC="$(SUB_CC)" meson
> > --prefix="$(MESON_PREFIX)" --libdir lib -Dc_args="$(DPDK_CFLAGS)"
> > -Dc_link_args="$(DPDK_LDFLAGS)" $(DPDK_OPTS)
> > -Ddisable_drivers="$(shell echo $(DPDK_DISABLED_DRVERS) | sed -E "s/
> > +/,/g")" build-tmp
> > + $(Q)! meson configure build-tmp | grep -qw enable_driver_sdk
> > || meson configure build-tmp -Denable_driver_sdk=true
> > $(Q)sed $(SED_INPLACE_FLAG) 's/#define RTE_EAL_PMD_PATH
> > .*/#define RTE_EAL_PMD_PATH ""/g'
> > $(SPDK_ROOT_DIR)/dpdk/build-tmp/rte_build_config.h
> > $(Q) \
> > # TODO Meson build adds libbsd dependency when it's available.
> > This means any app will be \
> > diff --git a/lib/env_dpdk/env.mk b/lib/env_dpdk/env.mk
> > index cc7db8aab..e24c6942f 100644bits with an embedded dpdk
> > --- a/lib/env_dpdk/env.mk
> > +++ b/lib/env_dpdk/env.mk
> > @@ -172,6 +172,12 @@ DPDK_PRIVATE_LINKER_ARGS += -lnuma
> > endif
> > endif
> >
> > +ifneq (,$(wildcard $(DPDK_INC_DIR)/rte_build_config.h))
> > +ifneq (,$(shell grep -e "define RTE_HAS_LIBARCHIVE 1"
> > $(DPDK_INC_DIR)/rte_build_config.h))
> > +DPDK_PRIVATE_LINKER_ARGS += -larchive
> > +endif
> > +endif
> > +
> > ifeq ($(OS),Linux)
> > DPDK_PRIVATE_LINKER_ARGS += -ldl
> > endif
> > diff --git a/lib/env_dpdk/env_internal.h b/lib/env_dpdk/env_internal.h
> > index 2303f432c..24b377545 100644
> > --- a/lib/env_dpdk/env_internal.h
> > +++ b/lib/env_dpdk/env_internal.h
> > @@ -43,13 +43,18 @@
> > #include <rte_eal.h>
> > #include <rte_bus.h>
> > #include <rte_pci.h>
> > -#include <rte_bus_pci.h>
> > #include <rte_dev.h>
> >
> > #if RTE_VERSION < RTE_VERSION_NUM(19, 11, 0, 0)
> > #error RTE_VERSION is too old! Minimum 19.11 is required.
> > #endif
> >
> > +#if RTE_VERSION < RTE_VERSION_NUM(21, 11, 0, 0)
> > +#include <rte_bus_pci.h>
> > +#else
> > +#include <pci_driver.h>
> > +#endif
> > +
> > /* x86-64 and ARM userspace virtual addresses use only the low 48
> > bits [0..47],
> > * which is enough to cover 256 TB.
> > */
> >
> >
> >
> > --
> > David Marchand
> >
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [EXT] [PATCH v9] bbdev: add device info related to data endianness assumption
2021-10-07 18:58 0% ` Chautru, Nicolas
@ 2021-10-08 4:34 0% ` Nipun Gupta
0 siblings, 0 replies; 200+ results
From: Nipun Gupta @ 2021-10-08 4:34 UTC (permalink / raw)
To: Chautru, Nicolas, Akhil Goyal, dev, trix
Cc: thomas, Zhang, Mingshan, Joshi, Arun, Hemant Agrawal, david.marchand
> -----Original Message-----
> From: Chautru, Nicolas <nicolas.chautru@intel.com>
> Sent: Friday, October 8, 2021 12:29 AM
> To: Nipun Gupta <nipun.gupta@nxp.com>; Akhil Goyal <gakhil@marvell.com>;
> dev@dpdk.org; trix@redhat.com
> Cc: thomas@monjalon.net; Zhang, Mingshan <mingshan.zhang@intel.com>;
> Joshi, Arun <arun.joshi@intel.com>; Hemant Agrawal
> <hemant.agrawal@nxp.com>; david.marchand@redhat.com
> Subject: RE: [EXT] [PATCH v9] bbdev: add device info related to data endianness
> assumption
>
> Hi Nipun,
>
> > -----Original Message-----
> > From: Nipun Gupta <nipun.gupta@nxp.com>
> > Sent: Thursday, October 7, 2021 9:49 AM
> > To: Chautru, Nicolas <nicolas.chautru@intel.com>; Akhil Goyal
> > <gakhil@marvell.com>; dev@dpdk.org; trix@redhat.com
> > Cc: thomas@monjalon.net; Zhang, Mingshan <mingshan.zhang@intel.com>;
> > Joshi, Arun <arun.joshi@intel.com>; Hemant Agrawal
> > <hemant.agrawal@nxp.com>; david.marchand@redhat.com
> > Subject: RE: [EXT] [PATCH v9] bbdev: add device info related to data
> > endianness assumption
> >
> >
> >
> > > -----Original Message-----
> > > From: Chautru, Nicolas <nicolas.chautru@intel.com>
> > > Sent: Thursday, October 7, 2021 9:12 PM
> > > To: Akhil Goyal <gakhil@marvell.com>; dev@dpdk.org; Nipun Gupta
> > > <nipun.gupta@nxp.com>; trix@redhat.com
> > > Cc: thomas@monjalon.net; Zhang, Mingshan
> > <mingshan.zhang@intel.com>;
> > > Joshi, Arun <arun.joshi@intel.com>; Hemant Agrawal
> > > <hemant.agrawal@nxp.com>; david.marchand@redhat.com
> > > Subject: RE: [EXT] [PATCH v9] bbdev: add device info related to data
> > > endianness assumption
> > >
> > > Hi Akhil,
> > >
> > >
> > > > -----Original Message-----
> > > > From: Akhil Goyal <gakhil@marvell.com>
> > > > Sent: Thursday, October 7, 2021 6:14 AM
> > > > To: Chautru, Nicolas <nicolas.chautru@intel.com>; dev@dpdk.org;
> > > > nipun.gupta@nxp.com; trix@redhat.com
> > > > Cc: thomas@monjalon.net; Zhang, Mingshan
> > <mingshan.zhang@intel.com>;
> > > > Joshi, Arun <arun.joshi@intel.com>; hemant.agrawal@nxp.com;
> > > > david.marchand@redhat.com
> > > > Subject: RE: [EXT] [PATCH v9] bbdev: add device info related to data
> > > > endianness assumption
> > > >
> > > > > Subject: [EXT] [PATCH v9] bbdev: add device info related to data
> > > > > endianness assumption
> > > > >
> > > > Title is too long.
> > > > bbdev: add dev info for data endianness
> > >
> > > OK
> > >
> > > >
> > > > > Adding device information to capture explicitly the assumption of
> > > > > the input/output data byte endianness being processed.
> > > > >
> > > > > Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
> > > > > ---
> > > > > doc/guides/rel_notes/release_21_11.rst | 1 +
> > > > > drivers/baseband/acc100/rte_acc100_pmd.c | 1 +
> > > > > drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 1 +
> > > > > drivers/baseband/fpga_lte_fec/fpga_lte_fec.c | 1 +
> > > > > drivers/baseband/turbo_sw/bbdev_turbo_software.c | 1 +
> > > > > lib/bbdev/rte_bbdev.h | 8 ++++++++
> > > > > 6 files changed, 13 insertions(+)
> > > > >
> > > > > diff --git a/doc/guides/rel_notes/release_21_11.rst
> > > > > b/doc/guides/rel_notes/release_21_11.rst
> > > > > index a8900a3..f0b3006 100644
> > > > > --- a/doc/guides/rel_notes/release_21_11.rst
> > > > > +++ b/doc/guides/rel_notes/release_21_11.rst
> > > > > @@ -191,6 +191,7 @@ API Changes
> > > > >
> > > > > * bbdev: Added capability related to more comprehensive CRC
> > options.
> > > > >
> > > > > +* bbdev: Added device info related to data byte endianness
> > > > > +processing
> > > > > assumption.
> > > >
> > > > It is not clear from the description or the release notes, what the
> > > > application is supposed to do based on the new dev_info field set
> > > > and how the driver determine what value to set?
> > > > Isn't there a standard from the application stand point that the
> > > > input/output data Should be in BE or in LE like in case of IP packets which
> > are always in BE?
> > > > I mean why is it dependent on the PMD which is processing it?
> > > > Whatever application understands, PMD should comply with that and do
> > > > internal Swapping if it does not support it.
> > > > Am I missing something?
> > >
> > > This is really to allow Nipin to add his own NXP la12xx PMD, which
> > > appears to have different assumption on endianness.
> > > All existing processing is done in LE by default by the existing PMDs
> > > and the existing ecosystem.
> > > I cannot comment on why they would want to do that for the la12xx
> > > specifically, I could only speculate but here trying to help to find
> > > the best way for the new PMD to be supported.
> > > So here this suggested change is purely about exposing different
> > > assumption for the PMDs, so that this new PMD can still be supported
> > > under this API even though this is in effect incompatible with existing
> > ecosystem.
> > > In case the application has different assumption that what the PMD
> > > does, then byte swapping would have to be done in the application,
> > > more likely I assume that la12xx has its own ecosystem with different
> > > endianness required for other reasons.
> > > The option you are suggesting would be to put the burden on the PMD
> > > but I doubt there is an actual usecase for that. I assume they assume
> > > different endianness for other specific reason, not necessary to be
> > > compatible with existing ecosystem.
> > > Niping, Hemant, feel free to comment back, from previous discussion I
> > > believe this is what you wanted to do. Unsure of the reason, feel free
> > > to share more details or not.
> >
> > Akhil/Nicolas,
> >
> > As Hemant mentioned on v4 (previously asked by Dave)
> >
> > "---
> > If we go back to the data providing source i.e. FAPI interface, it is
> > implementation specific, as per SCF222.
> >
> > Our customers do use BE data in network and at FAPI interface.
> >
> > In LA12xx, at present, we use u8 Big-endian data for processing to FECA
> > engine. We do see that other drivers in DPDK are using Little Endian *(with
> > u32 data)* but standards is open for both.
> > "---
> >
> > Standard is not specific to endianness and is open for implementation.
> > So it does not makes a reason to have one endianness as default and other
> > managed in the PMD, and the current change seems right.
> >
> > Yes endianness assumption is taken in the test vector input/output data, but
> > this should be acceptable as it does not impact the PMD's and end user
> > applications in general.
>
> I want clarify that this would impact the application in case user wanted to
> switch between 2 such hw accelator.
> Ie. you cannot switch the 2 solutions, they are incompatible except if you
> explicitly do the byteswap in the application (as is done in bbdev-test).
> Not necessarily a problem in case they address 2 different ecosystems but
> capturing the implication to be explicit. Ie each device expose the assumptions
> expected by the application and it is up to the application the bbdev api to
> satisfy the relared assumptions.
Hi Nicolas,
Bbdev-test is one of a test application and it is using test vectors. Consider bbdev
example application, the packets are in the network order (i.e. big-endian) and no
swapping is being done in this application. It is probably assumed that the packets
which are arriving/going out at the network are in the endianness order which
are to be processed by the device.
Similarly in the real world usage/applications, the endianness handling would be done
on the other end (the originator/consumer of the data), which again could be done in
hw accelerators without impacting the real world applications.
Also, as standard is open for both, the current change makes sense and swapping in
any of the PMD does not seems suitable.
Regards,
Nipun
>
> >
> > BTW Nicolos, my name is Nipun :)
>
> My bad!
>
> I am marking this patch as obsolete since you have included it in your serie.
>
>
> >
> > >
> > >
> > > >
> > > > >
> > > > > ABI Changes
> > > > > -----------
> > > > > diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
> > > > > b/drivers/baseband/acc100/rte_acc100_pmd.c
> > > > > index 4e2feef..eb2c6c1 100644
> > > > > --- a/drivers/baseband/acc100/rte_acc100_pmd.c
> > > > > +++ b/drivers/baseband/acc100/rte_acc100_pmd.c
> > > > > @@ -1089,6 +1089,7 @@
> > > > > #else
> > > > > dev_info->harq_buffer_size = 0;
> > > > > #endif
> > > > > + dev_info->data_endianness = RTE_BBDEV_LITTLE_ENDIAN;
> > > > > acc100_check_ir(d);
> > > > > }
> > > > >
> > > > > diff --git a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
> > > > > b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
> > > > > index 6485cc8..c7f15c0 100644
> > > > > --- a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
> > > > > +++ b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
> > > > > @@ -372,6 +372,7 @@
> > > > > dev_info->default_queue_conf = default_queue_conf;
> > > > > dev_info->capabilities = bbdev_capabilities;
> > > > > dev_info->cpu_flag_reqs = NULL;
> > > > > + dev_info->data_endianness = RTE_BBDEV_LITTLE_ENDIAN;
> > > > >
> > > > > /* Calculates number of queues assigned to device */
> > > > > dev_info->max_num_queues = 0;
> > > > > diff --git a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
> > > > > b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
> > > > > index 350c424..72e213e 100644
> > > > > --- a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
> > > > > +++ b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
> > > > > @@ -644,6 +644,7 @@ struct __rte_cache_aligned fpga_queue {
> > > > > dev_info->default_queue_conf = default_queue_conf;
> > > > > dev_info->capabilities = bbdev_capabilities;
> > > > > dev_info->cpu_flag_reqs = NULL;
> > > > > + dev_info->data_endianness = RTE_BBDEV_LITTLE_ENDIAN;
> > > > >
> > > > > /* Calculates number of queues assigned to device */
> > > > > dev_info->max_num_queues = 0;
> > > > > diff --git a/drivers/baseband/turbo_sw/bbdev_turbo_software.c
> > > > > b/drivers/baseband/turbo_sw/bbdev_turbo_software.c
> > > > > index e1db2bf..0cab91a 100644
> > > > > --- a/drivers/baseband/turbo_sw/bbdev_turbo_software.c
> > > > > +++ b/drivers/baseband/turbo_sw/bbdev_turbo_software.c
> > > > > @@ -253,6 +253,7 @@ struct turbo_sw_queue {
> > > > > dev_info->capabilities = bbdev_capabilities;
> > > > > dev_info->min_alignment = 64;
> > > > > dev_info->harq_buffer_size = 0;
> > > > > + dev_info->data_endianness = RTE_BBDEV_LITTLE_ENDIAN;
> > > > >
> > > > > rte_bbdev_log_debug("got device info from %u\n", dev->data-
> > > > > >dev_id);
> > > > > }
> > > > > diff --git a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h index
> > > > > 3ebf62e..b3f3000 100644
> > > > > --- a/lib/bbdev/rte_bbdev.h
> > > > > +++ b/lib/bbdev/rte_bbdev.h
> > > > > @@ -49,6 +49,12 @@ enum rte_bbdev_state {
> > > > > RTE_BBDEV_INITIALIZED
> > > > > };
> > > > >
> > > > > +/** Definitions of device data byte endianness types */ enum
> > > > > +rte_bbdev_endianness {
> > > > > + RTE_BBDEV_BIG_ENDIAN, /**< Data with byte-endianness BE
> */
> > > > > + RTE_BBDEV_LITTLE_ENDIAN, /**< Data with byte-endianness
> LE */ };
> > > > If at all be need this dev_info field, as Tom suggested we should
> > > > use RTE_BIG/LITTLE_ENDIAN.
> > >
> > > See separate comment on my reply to Tom:
> > > I considered this but the usage is different, these are build time
> > > #define, and really would bring confusion here.
> > > Note that there are not really the endianness of the system itself but
> > > specific to the bbdev data output going through signal processing.
> > > I thought it was more explicit and less confusing this way, feel free
> > > to comment back.
> > > NXP would know best why a different endianness would be required in the
> > PMD.
> >
> > Please see previous comment for endianness support.
> > I agree with the RTE_ prefix we can add it as it is for the application interface.
> >
> > >
> > > >
> > > > > +
> > > > > /**
> > > > > * Get the total number of devices that have been successfully
> > initialised.
> > > > > *
> > > > > @@ -309,6 +315,8 @@ struct rte_bbdev_driver_info {
> > > > > uint16_t min_alignment;
> > > > > /** HARQ memory available in kB */
> > > > > uint32_t harq_buffer_size;
> > > > > + /** Byte endianness assumption for input/output data */
> > > > > + enum rte_bbdev_endianness data_endianness;
> > > >
> > > > We should define how the input and output data are expected from the
> > app.
> > > > If need be, we can define a simple ``bool swap`` instead of an enum.
> > >
> > > This could be done as well. Default no swap, and swap required for the
> > > new PMD.
> > > I will let Nipin/Hemant comment back.
> >
> > Again endianness is implementation specific and not standard for 5G
> > processing, unlike it is for network packet.
> >
> > Regards,
> > Nipun
> >
> > >
> > > >
> > > > > /** Default queue configuration used if none is supplied */
> > > > > struct rte_bbdev_queue_conf default_queue_conf;
> > > > > /** Device operation capabilities */
> > > > > --
> > > > > 1.8.3.1
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v5 2/2] cmdline: make struct rdline opaque
2021-10-07 22:10 4% ` [dpdk-dev] [PATCH v5 " Dmitry Kozlyuk
2021-10-07 22:10 4% ` [dpdk-dev] [PATCH v5 1/2] cmdline: make struct cmdline opaque Dmitry Kozlyuk
@ 2021-10-07 22:10 3% ` Dmitry Kozlyuk
1 sibling, 0 replies; 200+ results
From: Dmitry Kozlyuk @ 2021-10-07 22:10 UTC (permalink / raw)
To: dev
Cc: Dmitry Kozlyuk, Ali Alnubani, Gregory Etelson, David Marchand,
Olivier Matz, Ray Kinsella
Hide struct rdline definition and some RDLINE_* constants in order
to be able to change internal buffer sizes transparently to the user.
Add new functions:
* rdline_new(): allocate and initialize struct rdline.
This function replaces rdline_init() and takes an extra parameter:
opaque user data for the callbacks.
* rdline_free(): deallocate struct rdline.
* rdline_get_history_buffer_size(): for use in tests.
* rdline_get_opaque(): to obtain user data in callback functions.
Remove rdline_init() function from library headers and export list,
because using it requires the knowledge of sizeof(struct rdline).
Signed-off-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Acked-by: Olivier Matz <olivier.matz@6wind.com>
---
app/test-cmdline/commands.c | 2 +-
app/test/test_cmdline_lib.c | 22 ++++---
doc/guides/rel_notes/release_21_11.rst | 3 +
lib/cmdline/cmdline.c | 3 +-
lib/cmdline/cmdline_private.h | 49 +++++++++++++++
lib/cmdline/cmdline_rdline.c | 43 ++++++++++++-
lib/cmdline/cmdline_rdline.h | 86 ++++++++++----------------
lib/cmdline/version.map | 8 ++-
8 files changed, 147 insertions(+), 69 deletions(-)
diff --git a/app/test-cmdline/commands.c b/app/test-cmdline/commands.c
index d732976f08..a13e1d1afd 100644
--- a/app/test-cmdline/commands.c
+++ b/app/test-cmdline/commands.c
@@ -297,7 +297,7 @@ cmd_get_history_bufsize_parsed(__rte_unused void *parsed_result,
struct rdline *rdl = cmdline_get_rdline(cl);
cmdline_printf(cl, "History buffer size: %zu\n",
- sizeof(rdl->history_buf));
+ rdline_get_history_buffer_size(rdl));
}
cmdline_parse_token_string_t cmd_get_history_bufsize_tok =
diff --git a/app/test/test_cmdline_lib.c b/app/test/test_cmdline_lib.c
index d5a09b4541..054ebf5e9d 100644
--- a/app/test/test_cmdline_lib.c
+++ b/app/test/test_cmdline_lib.c
@@ -83,18 +83,19 @@ test_cmdline_parse_fns(void)
static int
test_cmdline_rdline_fns(void)
{
- struct rdline rdl;
+ struct rdline *rdl;
rdline_write_char_t *wc = &cmdline_write_char;
rdline_validate_t *v = &valid_buffer;
rdline_complete_t *c = &complete_buffer;
- if (rdline_init(NULL, wc, v, c) >= 0)
+ rdl = rdline_new(NULL, v, c, NULL);
+ if (rdl != NULL)
goto error;
- if (rdline_init(&rdl, NULL, v, c) >= 0)
+ rdl = rdline_new(wc, NULL, c, NULL);
+ if (rdl != NULL)
goto error;
- if (rdline_init(&rdl, wc, NULL, c) >= 0)
- goto error;
- if (rdline_init(&rdl, wc, v, NULL) >= 0)
+ rdl = rdline_new(wc, v, NULL, NULL);
+ if (rdl != NULL)
goto error;
if (rdline_char_in(NULL, 0) >= 0)
goto error;
@@ -102,25 +103,30 @@ test_cmdline_rdline_fns(void)
goto error;
if (rdline_add_history(NULL, "history") >= 0)
goto error;
- if (rdline_add_history(&rdl, NULL) >= 0)
+ if (rdline_add_history(rdl, NULL) >= 0)
goto error;
if (rdline_get_history_item(NULL, 0) != NULL)
goto error;
/* void functions */
+ rdline_get_history_buffer_size(NULL);
+ rdline_get_opaque(NULL);
rdline_newline(NULL, "prompt");
- rdline_newline(&rdl, NULL);
+ rdline_newline(rdl, NULL);
rdline_stop(NULL);
rdline_quit(NULL);
rdline_restart(NULL);
rdline_redisplay(NULL);
rdline_reset(NULL);
rdline_clear_history(NULL);
+ rdline_free(NULL);
+ rdline_free(rdl);
return 0;
error:
printf("Error: function accepted null parameter!\n");
+ rdline_free(rdl);
return -1;
}
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index 18377e5813..af11f4a656 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -103,6 +103,9 @@ API Changes
* cmdline: Made ``cmdline`` structure definition hidden on Linux and FreeBSD.
+* cmdline: Made ``rdline`` structure definition hidden. Functions are added
+ to dynamically allocate and free it, and to access user data in callbacks.
+
ABI Changes
-----------
diff --git a/lib/cmdline/cmdline.c b/lib/cmdline/cmdline.c
index a176d15130..8f1854cb0b 100644
--- a/lib/cmdline/cmdline.c
+++ b/lib/cmdline/cmdline.c
@@ -85,13 +85,12 @@ cmdline_new(cmdline_parse_ctx_t *ctx, const char *prompt, int s_in, int s_out)
cl->ctx = ctx;
ret = rdline_init(&cl->rdl, cmdline_write_char, cmdline_valid_buffer,
- cmdline_complete_buffer);
+ cmdline_complete_buffer, cl);
if (ret != 0) {
free(cl);
return NULL;
}
- cl->rdl.opaque = cl;
cmdline_set_prompt(cl, prompt);
rdline_newline(&cl->rdl, cl->prompt);
diff --git a/lib/cmdline/cmdline_private.h b/lib/cmdline/cmdline_private.h
index 2e93674c66..c2e906d8de 100644
--- a/lib/cmdline/cmdline_private.h
+++ b/lib/cmdline/cmdline_private.h
@@ -17,6 +17,49 @@
#include <cmdline.h>
+#define RDLINE_BUF_SIZE 512
+#define RDLINE_PROMPT_SIZE 32
+#define RDLINE_VT100_BUF_SIZE 8
+#define RDLINE_HISTORY_BUF_SIZE BUFSIZ
+#define RDLINE_HISTORY_MAX_LINE 64
+
+enum rdline_status {
+ RDLINE_INIT,
+ RDLINE_RUNNING,
+ RDLINE_EXITED
+};
+
+struct rdline {
+ enum rdline_status status;
+ /* rdline bufs */
+ struct cirbuf left;
+ struct cirbuf right;
+ char left_buf[RDLINE_BUF_SIZE+2]; /* reserve 2 chars for the \n\0 */
+ char right_buf[RDLINE_BUF_SIZE];
+
+ char prompt[RDLINE_PROMPT_SIZE];
+ unsigned int prompt_size;
+
+ char kill_buf[RDLINE_BUF_SIZE];
+ unsigned int kill_size;
+
+ /* history */
+ struct cirbuf history;
+ char history_buf[RDLINE_HISTORY_BUF_SIZE];
+ int history_cur_line;
+
+ /* callbacks and func pointers */
+ rdline_write_char_t *write_char;
+ rdline_validate_t *validate;
+ rdline_complete_t *complete;
+
+ /* vt100 parser */
+ struct cmdline_vt100 vt100;
+
+ /* opaque pointer */
+ void *opaque;
+};
+
#ifdef RTE_EXEC_ENV_WINDOWS
struct terminal {
DWORD input_mode;
@@ -57,4 +100,10 @@ ssize_t cmdline_read_char(struct cmdline *cl, char *c);
__rte_format_printf(2, 0)
int cmdline_vdprintf(int fd, const char *format, va_list op);
+int rdline_init(struct rdline *rdl,
+ rdline_write_char_t *write_char,
+ rdline_validate_t *validate,
+ rdline_complete_t *complete,
+ void *opaque);
+
#endif
diff --git a/lib/cmdline/cmdline_rdline.c b/lib/cmdline/cmdline_rdline.c
index 2cb53e38f2..d92b1cda53 100644
--- a/lib/cmdline/cmdline_rdline.c
+++ b/lib/cmdline/cmdline_rdline.c
@@ -13,6 +13,7 @@
#include <ctype.h>
#include "cmdline_cirbuf.h"
+#include "cmdline_private.h"
#include "cmdline_rdline.h"
static void rdline_puts(struct rdline *rdl, const char *buf);
@@ -37,9 +38,10 @@ isblank2(char c)
int
rdline_init(struct rdline *rdl,
- rdline_write_char_t *write_char,
- rdline_validate_t *validate,
- rdline_complete_t *complete)
+ rdline_write_char_t *write_char,
+ rdline_validate_t *validate,
+ rdline_complete_t *complete,
+ void *opaque)
{
if (!rdl || !write_char || !validate || !complete)
return -EINVAL;
@@ -47,10 +49,33 @@ rdline_init(struct rdline *rdl,
rdl->validate = validate;
rdl->complete = complete;
rdl->write_char = write_char;
+ rdl->opaque = opaque;
rdl->status = RDLINE_INIT;
return cirbuf_init(&rdl->history, rdl->history_buf, 0, RDLINE_HISTORY_BUF_SIZE);
}
+struct rdline *
+rdline_new(rdline_write_char_t *write_char,
+ rdline_validate_t *validate,
+ rdline_complete_t *complete,
+ void *opaque)
+{
+ struct rdline *rdl;
+
+ rdl = malloc(sizeof(*rdl));
+ if (rdline_init(rdl, write_char, validate, complete, opaque) < 0) {
+ free(rdl);
+ rdl = NULL;
+ }
+ return rdl;
+}
+
+void
+rdline_free(struct rdline *rdl)
+{
+ free(rdl);
+}
+
void
rdline_newline(struct rdline *rdl, const char *prompt)
{
@@ -564,6 +589,18 @@ rdline_get_history_item(struct rdline * rdl, unsigned int idx)
return NULL;
}
+size_t
+rdline_get_history_buffer_size(struct rdline *rdl)
+{
+ return sizeof(rdl->history_buf);
+}
+
+void *
+rdline_get_opaque(struct rdline *rdl)
+{
+ return rdl != NULL ? rdl->opaque : NULL;
+}
+
int
rdline_add_history(struct rdline * rdl, const char * buf)
{
diff --git a/lib/cmdline/cmdline_rdline.h b/lib/cmdline/cmdline_rdline.h
index d2170293de..1b4cc7ce57 100644
--- a/lib/cmdline/cmdline_rdline.h
+++ b/lib/cmdline/cmdline_rdline.h
@@ -10,9 +10,7 @@
/**
* This file is a small equivalent to the GNU readline library, but it
* was originally designed for small systems, like Atmel AVR
- * microcontrollers (8 bits). Indeed, we don't use any malloc that is
- * sometimes not implemented (or just not recommended) on such
- * systems.
+ * microcontrollers (8 bits). It only uses malloc() on object creation.
*
* Obviously, it does not support as many things as the GNU readline,
* but at least it supports some interesting features like a kill
@@ -31,6 +29,7 @@
*/
#include <stdio.h>
+#include <rte_compat.h>
#include <cmdline_cirbuf.h>
#include <cmdline_vt100.h>
@@ -38,19 +37,6 @@
extern "C" {
#endif
-/* configuration */
-#define RDLINE_BUF_SIZE 512
-#define RDLINE_PROMPT_SIZE 32
-#define RDLINE_VT100_BUF_SIZE 8
-#define RDLINE_HISTORY_BUF_SIZE BUFSIZ
-#define RDLINE_HISTORY_MAX_LINE 64
-
-enum rdline_status {
- RDLINE_INIT,
- RDLINE_RUNNING,
- RDLINE_EXITED
-};
-
struct rdline;
typedef int (rdline_write_char_t)(struct rdline *rdl, char);
@@ -60,52 +46,32 @@ typedef int (rdline_complete_t)(struct rdline *rdl, const char *buf,
char *dstbuf, unsigned int dstsize,
int *state);
-struct rdline {
- enum rdline_status status;
- /* rdline bufs */
- struct cirbuf left;
- struct cirbuf right;
- char left_buf[RDLINE_BUF_SIZE+2]; /* reserve 2 chars for the \n\0 */
- char right_buf[RDLINE_BUF_SIZE];
-
- char prompt[RDLINE_PROMPT_SIZE];
- unsigned int prompt_size;
-
- char kill_buf[RDLINE_BUF_SIZE];
- unsigned int kill_size;
-
- /* history */
- struct cirbuf history;
- char history_buf[RDLINE_HISTORY_BUF_SIZE];
- int history_cur_line;
-
- /* callbacks and func pointers */
- rdline_write_char_t *write_char;
- rdline_validate_t *validate;
- rdline_complete_t *complete;
-
- /* vt100 parser */
- struct cmdline_vt100 vt100;
-
- /* opaque pointer */
- void *opaque;
-};
-
/**
- * Init fields for a struct rdline. Call this only once at the beginning
- * of your program.
- * \param rdl A pointer to an uninitialized struct rdline
+ * Allocate and initialize a new rdline instance.
+ *
* \param write_char The function used by the function to write a character
* \param validate A pointer to the function to execute when the
* user validates the buffer.
* \param complete A pointer to the function to execute when the
* user completes the buffer.
+ * \param opaque User data for use in the callbacks.
+ *
+ * \return New rdline object on success, NULL on failure.
*/
-int rdline_init(struct rdline *rdl,
- rdline_write_char_t *write_char,
- rdline_validate_t *validate,
- rdline_complete_t *complete);
+__rte_experimental
+struct rdline *rdline_new(rdline_write_char_t *write_char,
+ rdline_validate_t *validate,
+ rdline_complete_t *complete,
+ void *opaque);
+/**
+ * Free an rdline instance.
+ *
+ * \param rdl A pointer to an initialized struct rdline.
+ * If NULL, this function is a no-op.
+ */
+__rte_experimental
+void rdline_free(struct rdline *rdl);
/**
* Init the current buffer, and display a prompt.
@@ -194,6 +160,18 @@ void rdline_clear_history(struct rdline *rdl);
*/
char *rdline_get_history_item(struct rdline *rdl, unsigned int i);
+/**
+ * Get maximum history buffer size.
+ */
+__rte_experimental
+size_t rdline_get_history_buffer_size(struct rdline *rdl);
+
+/**
+ * Get the opaque pointer supplied on struct rdline creation.
+ */
+__rte_experimental
+void *rdline_get_opaque(struct rdline *rdl);
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/cmdline/version.map b/lib/cmdline/version.map
index 980adb4f23..b9bbb87510 100644
--- a/lib/cmdline/version.map
+++ b/lib/cmdline/version.map
@@ -57,7 +57,6 @@ DPDK_22 {
rdline_clear_history;
rdline_get_buffer;
rdline_get_history_item;
- rdline_init;
rdline_newline;
rdline_quit;
rdline_redisplay;
@@ -73,7 +72,14 @@ DPDK_22 {
EXPERIMENTAL {
global:
+ # added in 20.11
cmdline_get_rdline;
+ # added in 21.11
+ rdline_new;
+ rdline_free;
+ rdline_get_history_buffer_size;
+ rdline_get_opaque;
+
local: *;
};
--
2.29.3
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v5 1/2] cmdline: make struct cmdline opaque
2021-10-07 22:10 4% ` [dpdk-dev] [PATCH v5 " Dmitry Kozlyuk
@ 2021-10-07 22:10 4% ` Dmitry Kozlyuk
2021-10-07 22:10 3% ` [dpdk-dev] [PATCH v5 2/2] cmdline: make struct rdline opaque Dmitry Kozlyuk
1 sibling, 0 replies; 200+ results
From: Dmitry Kozlyuk @ 2021-10-07 22:10 UTC (permalink / raw)
To: dev; +Cc: Dmitry Kozlyuk, David Marchand, Olivier Matz, Ray Kinsella
Remove the definition of `struct cmdline` from public header.
Deprecation notice:
https://mails.dpdk.org/archives/dev/2020-September/183310.html
Signed-off-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Acked-by: David Marchand <david.marchand@redhat.com>
Acked-by: Olivier Matz <olivier.matz@6wind.com>
---
doc/guides/rel_notes/deprecation.rst | 4 ----
doc/guides/rel_notes/release_21_11.rst | 2 ++
lib/cmdline/cmdline.h | 19 -------------------
lib/cmdline/cmdline_private.h | 8 +++++++-
4 files changed, 9 insertions(+), 24 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 76a4abfd6b..a404276fa2 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -275,10 +275,6 @@ Deprecation Notices
* metrics: The function ``rte_metrics_init`` will have a non-void return
in order to notify errors instead of calling ``rte_exit``.
-* cmdline: ``cmdline`` structure will be made opaque to hide platform-specific
- content. On Linux and FreeBSD, supported prior to DPDK 20.11,
- original structure will be kept until DPDK 21.11.
-
* security: The functions ``rte_security_set_pkt_metadata`` and
``rte_security_get_userdata`` will be made inline functions and additional
flags will be added in structure ``rte_security_ctx`` in DPDK 21.11.
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index b55900936d..18377e5813 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -101,6 +101,8 @@ API Changes
Also, make sure to start the actual text at the margin.
=======================================================
+* cmdline: Made ``cmdline`` structure definition hidden on Linux and FreeBSD.
+
ABI Changes
-----------
diff --git a/lib/cmdline/cmdline.h b/lib/cmdline/cmdline.h
index c29762ddae..96674dfda2 100644
--- a/lib/cmdline/cmdline.h
+++ b/lib/cmdline/cmdline.h
@@ -7,10 +7,6 @@
#ifndef _CMDLINE_H_
#define _CMDLINE_H_
-#ifndef RTE_EXEC_ENV_WINDOWS
-#include <termios.h>
-#endif
-
#include <rte_common.h>
#include <rte_compat.h>
@@ -27,23 +23,8 @@
extern "C" {
#endif
-#ifndef RTE_EXEC_ENV_WINDOWS
-
-struct cmdline {
- int s_in;
- int s_out;
- cmdline_parse_ctx_t *ctx;
- struct rdline rdl;
- char prompt[RDLINE_PROMPT_SIZE];
- struct termios oldterm;
-};
-
-#else
-
struct cmdline;
-#endif /* RTE_EXEC_ENV_WINDOWS */
-
struct cmdline *cmdline_new(cmdline_parse_ctx_t *ctx, const char *prompt, int s_in, int s_out);
void cmdline_set_prompt(struct cmdline *cl, const char *prompt);
void cmdline_free(struct cmdline *cl);
diff --git a/lib/cmdline/cmdline_private.h b/lib/cmdline/cmdline_private.h
index a87c45275c..2e93674c66 100644
--- a/lib/cmdline/cmdline_private.h
+++ b/lib/cmdline/cmdline_private.h
@@ -11,6 +11,8 @@
#include <rte_os_shim.h>
#ifdef RTE_EXEC_ENV_WINDOWS
#include <rte_windows.h>
+#else
+#include <termios.h>
#endif
#include <cmdline.h>
@@ -22,6 +24,7 @@ struct terminal {
int is_console_input;
int is_console_output;
};
+#endif
struct cmdline {
int s_in;
@@ -29,11 +32,14 @@ struct cmdline {
cmdline_parse_ctx_t *ctx;
struct rdline rdl;
char prompt[RDLINE_PROMPT_SIZE];
+#ifdef RTE_EXEC_ENV_WINDOWS
struct terminal oldterm;
char repeated_char;
WORD repeat_count;
-};
+#else
+ struct termios oldterm;
#endif
+};
/* Disable buffering and echoing, save previous settings to oldterm. */
void terminal_adjust(struct cmdline *cl);
--
2.29.3
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v5 0/2] cmdline: reduce ABI
@ 2021-10-07 22:10 4% ` Dmitry Kozlyuk
2021-10-07 22:10 4% ` [dpdk-dev] [PATCH v5 1/2] cmdline: make struct cmdline opaque Dmitry Kozlyuk
2021-10-07 22:10 3% ` [dpdk-dev] [PATCH v5 2/2] cmdline: make struct rdline opaque Dmitry Kozlyuk
0 siblings, 2 replies; 200+ results
From: Dmitry Kozlyuk @ 2021-10-07 22:10 UTC (permalink / raw)
To: dev; +Cc: Dmitry Kozlyuk
Hide struct cmdline following the deprecation notice.
Hide struct rdline following the v1 discussion.
v5: fix API documentation (Olivier),
remove useless NULL assignment (Stephen).
v4: rdline_create -> rdline_new, restore empty line (Olivier).
v3: add experimental tags and releae notes for rdline.
v2: also hide struct rdline (David, Olivier).
Dmitry Kozlyuk (2):
cmdline: make struct cmdline opaque
cmdline: make struct rdline opaque
app/test-cmdline/commands.c | 2 +-
app/test/test_cmdline_lib.c | 22 ++++---
doc/guides/rel_notes/deprecation.rst | 4 --
doc/guides/rel_notes/release_21_11.rst | 5 ++
lib/cmdline/cmdline.c | 3 +-
lib/cmdline/cmdline.h | 19 ------
lib/cmdline/cmdline_private.h | 57 ++++++++++++++++-
lib/cmdline/cmdline_rdline.c | 43 ++++++++++++-
lib/cmdline/cmdline_rdline.h | 86 ++++++++++----------------
lib/cmdline/version.map | 8 ++-
10 files changed, 156 insertions(+), 93 deletions(-)
--
2.29.3
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v3 1/2] net: rename Ethernet header fields
@ 2021-10-07 22:07 1% ` Dmitry Kozlyuk
0 siblings, 0 replies; 200+ results
From: Dmitry Kozlyuk @ 2021-10-07 22:07 UTC (permalink / raw)
To: dev; +Cc: Dmitry Kozlyuk, Ferruh Yigit, Olivier Matz, Stephen Hemminger
Definition of `rte_ether_addr` structure used a workaround allowing DPDK
and Windows SDK headers to be used in the same file, because Windows SDK
defines `s_addr` as a macro. Rename `s_addr` to `src_addr` and `d_addr`
to `dst_addr` to avoid the conflict and remove the workaround.
Deprecation notice:
https://mails.dpdk.org/archives/dev/2021-July/215270.html
Signed-off-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
---
app/test-pmd/5tswap.c | 6 +-
app/test-pmd/csumonly.c | 4 +-
app/test-pmd/flowgen.c | 4 +-
app/test-pmd/icmpecho.c | 16 ++---
app/test-pmd/ieee1588fwd.c | 6 +-
app/test-pmd/macfwd.c | 4 +-
app/test-pmd/macswap.h | 6 +-
app/test-pmd/txonly.c | 4 +-
app/test-pmd/util.c | 4 +-
app/test/packet_burst_generator.c | 4 +-
app/test/test_bpf.c | 4 +-
app/test/test_link_bonding_mode4.c | 15 ++--
doc/guides/rel_notes/deprecation.rst | 9 ++-
doc/guides/rel_notes/release_21_11.rst | 3 +
drivers/net/avp/avp_ethdev.c | 6 +-
drivers/net/bnx2x/bnx2x.c | 16 ++---
drivers/net/bonding/rte_eth_bond_8023ad.c | 6 +-
drivers/net/bonding/rte_eth_bond_alb.c | 4 +-
drivers/net/bonding/rte_eth_bond_pmd.c | 20 +++---
drivers/net/enic/enic_flow.c | 8 +--
drivers/net/mlx5/mlx5_txpp.c | 4 +-
examples/bond/main.c | 20 +++---
examples/ethtool/ethtool-app/main.c | 4 +-
examples/eventdev_pipeline/pipeline_common.h | 4 +-
examples/flow_filtering/main.c | 4 +-
examples/ioat/ioatfwd.c | 4 +-
examples/ip_fragmentation/main.c | 4 +-
examples/ip_reassembly/main.c | 4 +-
examples/ipsec-secgw/ipsec-secgw.c | 4 +-
examples/ipsec-secgw/ipsec_worker.c | 4 +-
examples/ipv4_multicast/main.c | 4 +-
examples/l2fwd-crypto/main.c | 4 +-
examples/l2fwd-event/l2fwd_common.h | 4 +-
examples/l2fwd-jobstats/main.c | 4 +-
examples/l2fwd-keepalive/main.c | 4 +-
examples/l2fwd/main.c | 4 +-
examples/l3fwd-acl/main.c | 19 ++---
examples/l3fwd-power/main.c | 8 +--
examples/l3fwd/l3fwd_em.h | 8 +--
examples/l3fwd/l3fwd_fib.c | 4 +-
examples/l3fwd/l3fwd_lpm.c | 4 +-
examples/l3fwd/l3fwd_lpm.h | 8 +--
examples/link_status_interrupt/main.c | 4 +-
.../performance-thread/l3fwd-thread/main.c | 72 +++++++++----------
examples/ptpclient/ptpclient.c | 16 ++---
examples/vhost/main.c | 11 +--
examples/vmdq/main.c | 4 +-
examples/vmdq_dcb/main.c | 4 +-
lib/ethdev/rte_flow.h | 4 +-
lib/gro/gro_tcp4.c | 4 +-
lib/gro/gro_udp4.c | 4 +-
lib/gro/gro_vxlan_tcp4.c | 8 +--
lib/gro/gro_vxlan_udp4.c | 8 +--
lib/net/rte_arp.c | 4 +-
lib/net/rte_ether.h | 22 +-----
lib/pipeline/rte_table_action.c | 40 +++++------
56 files changed, 241 insertions(+), 244 deletions(-)
diff --git a/app/test-pmd/5tswap.c b/app/test-pmd/5tswap.c
index e8cef9623b..629d3e0d31 100644
--- a/app/test-pmd/5tswap.c
+++ b/app/test-pmd/5tswap.c
@@ -27,9 +27,9 @@ swap_mac(struct rte_ether_hdr *eth_hdr)
struct rte_ether_addr addr;
/* Swap dest and src mac addresses. */
- rte_ether_addr_copy(ð_hdr->d_addr, &addr);
- rte_ether_addr_copy(ð_hdr->s_addr, ð_hdr->d_addr);
- rte_ether_addr_copy(&addr, ð_hdr->s_addr);
+ rte_ether_addr_copy(ð_hdr->dst_addr, &addr);
+ rte_ether_addr_copy(ð_hdr->src_addr, ð_hdr->dst_addr);
+ rte_ether_addr_copy(&addr, ð_hdr->src_addr);
}
static inline void
diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index 38cc256533..090797318a 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -873,9 +873,9 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
eth_hdr = rte_pktmbuf_mtod(m, struct rte_ether_hdr *);
rte_ether_addr_copy(&peer_eth_addrs[fs->peer_addr],
- ð_hdr->d_addr);
+ ð_hdr->dst_addr);
rte_ether_addr_copy(&ports[fs->tx_port].eth_addr,
- ð_hdr->s_addr);
+ ð_hdr->src_addr);
parse_ethernet(eth_hdr, &info);
l3_hdr = (char *)eth_hdr + info.l2_len;
diff --git a/app/test-pmd/flowgen.c b/app/test-pmd/flowgen.c
index 0d3664a64d..a96169e680 100644
--- a/app/test-pmd/flowgen.c
+++ b/app/test-pmd/flowgen.c
@@ -122,8 +122,8 @@ pkt_burst_flow_gen(struct fwd_stream *fs)
/* Initialize Ethernet header. */
eth_hdr = rte_pktmbuf_mtod(pkt, struct rte_ether_hdr *);
- rte_ether_addr_copy(&cfg_ether_dst, ð_hdr->d_addr);
- rte_ether_addr_copy(&cfg_ether_src, ð_hdr->s_addr);
+ rte_ether_addr_copy(&cfg_ether_dst, ð_hdr->dst_addr);
+ rte_ether_addr_copy(&cfg_ether_src, ð_hdr->src_addr);
eth_hdr->ether_type = rte_cpu_to_be_16(RTE_ETHER_TYPE_IPV4);
/* Initialize IP header. */
diff --git a/app/test-pmd/icmpecho.c b/app/test-pmd/icmpecho.c
index 8948f28eb5..8f1d68a83a 100644
--- a/app/test-pmd/icmpecho.c
+++ b/app/test-pmd/icmpecho.c
@@ -319,8 +319,8 @@ reply_to_icmp_echo_rqsts(struct fwd_stream *fs)
if (verbose_level > 0) {
printf("\nPort %d pkt-len=%u nb-segs=%u\n",
fs->rx_port, pkt->pkt_len, pkt->nb_segs);
- ether_addr_dump(" ETH: src=", ð_h->s_addr);
- ether_addr_dump(" dst=", ð_h->d_addr);
+ ether_addr_dump(" ETH: src=", ð_h->src_addr);
+ ether_addr_dump(" dst=", ð_h->dst_addr);
}
if (eth_type == RTE_ETHER_TYPE_VLAN) {
vlan_h = (struct rte_vlan_hdr *)
@@ -385,17 +385,17 @@ reply_to_icmp_echo_rqsts(struct fwd_stream *fs)
*/
/* Use source MAC address as destination MAC address. */
- rte_ether_addr_copy(ð_h->s_addr, ð_h->d_addr);
+ rte_ether_addr_copy(ð_h->src_addr, ð_h->dst_addr);
/* Set source MAC address with MAC address of TX port */
rte_ether_addr_copy(&ports[fs->tx_port].eth_addr,
- ð_h->s_addr);
+ ð_h->src_addr);
arp_h->arp_opcode = rte_cpu_to_be_16(RTE_ARP_OP_REPLY);
rte_ether_addr_copy(&arp_h->arp_data.arp_tha,
ð_addr);
rte_ether_addr_copy(&arp_h->arp_data.arp_sha,
&arp_h->arp_data.arp_tha);
- rte_ether_addr_copy(ð_h->s_addr,
+ rte_ether_addr_copy(ð_h->src_addr,
&arp_h->arp_data.arp_sha);
/* Swap IP addresses in ARP payload */
@@ -453,9 +453,9 @@ reply_to_icmp_echo_rqsts(struct fwd_stream *fs)
* ICMP checksum is computed by assuming it is valid in the
* echo request and not verified.
*/
- rte_ether_addr_copy(ð_h->s_addr, ð_addr);
- rte_ether_addr_copy(ð_h->d_addr, ð_h->s_addr);
- rte_ether_addr_copy(ð_addr, ð_h->d_addr);
+ rte_ether_addr_copy(ð_h->src_addr, ð_addr);
+ rte_ether_addr_copy(ð_h->dst_addr, ð_h->src_addr);
+ rte_ether_addr_copy(ð_addr, ð_h->dst_addr);
ip_addr = ip_h->src_addr;
if (is_multicast_ipv4_addr(ip_h->dst_addr)) {
uint32_t ip_src;
diff --git a/app/test-pmd/ieee1588fwd.c b/app/test-pmd/ieee1588fwd.c
index 034f238c34..9cf10c1c50 100644
--- a/app/test-pmd/ieee1588fwd.c
+++ b/app/test-pmd/ieee1588fwd.c
@@ -178,9 +178,9 @@ ieee1588_packet_fwd(struct fwd_stream *fs)
port_ieee1588_rx_timestamp_check(fs->rx_port, timesync_index);
/* Swap dest and src mac addresses. */
- rte_ether_addr_copy(ð_hdr->d_addr, &addr);
- rte_ether_addr_copy(ð_hdr->s_addr, ð_hdr->d_addr);
- rte_ether_addr_copy(&addr, ð_hdr->s_addr);
+ rte_ether_addr_copy(ð_hdr->dst_addr, &addr);
+ rte_ether_addr_copy(ð_hdr->src_addr, ð_hdr->dst_addr);
+ rte_ether_addr_copy(&addr, ð_hdr->src_addr);
/* Forward PTP packet with hardware TX timestamp */
mb->ol_flags |= PKT_TX_IEEE1588_TMST;
diff --git a/app/test-pmd/macfwd.c b/app/test-pmd/macfwd.c
index 0568ea794d..ee76df7f03 100644
--- a/app/test-pmd/macfwd.c
+++ b/app/test-pmd/macfwd.c
@@ -85,9 +85,9 @@ pkt_burst_mac_forward(struct fwd_stream *fs)
mb = pkts_burst[i];
eth_hdr = rte_pktmbuf_mtod(mb, struct rte_ether_hdr *);
rte_ether_addr_copy(&peer_eth_addrs[fs->peer_addr],
- ð_hdr->d_addr);
+ ð_hdr->dst_addr);
rte_ether_addr_copy(&ports[fs->tx_port].eth_addr,
- ð_hdr->s_addr);
+ ð_hdr->src_addr);
mb->ol_flags &= IND_ATTACHED_MBUF | EXT_ATTACHED_MBUF;
mb->ol_flags |= ol_flags;
mb->l2_len = sizeof(struct rte_ether_hdr);
diff --git a/app/test-pmd/macswap.h b/app/test-pmd/macswap.h
index 0138441566..29c252bb8f 100644
--- a/app/test-pmd/macswap.h
+++ b/app/test-pmd/macswap.h
@@ -29,9 +29,9 @@ do_macswap(struct rte_mbuf *pkts[], uint16_t nb,
eth_hdr = rte_pktmbuf_mtod(mb, struct rte_ether_hdr *);
/* Swap dest and src mac addresses. */
- rte_ether_addr_copy(ð_hdr->d_addr, &addr);
- rte_ether_addr_copy(ð_hdr->s_addr, ð_hdr->d_addr);
- rte_ether_addr_copy(&addr, ð_hdr->s_addr);
+ rte_ether_addr_copy(ð_hdr->dst_addr, &addr);
+ rte_ether_addr_copy(ð_hdr->src_addr, ð_hdr->dst_addr);
+ rte_ether_addr_copy(&addr, ð_hdr->src_addr);
mbuf_field_set(mb, ol_flags);
}
diff --git a/app/test-pmd/txonly.c b/app/test-pmd/txonly.c
index aed820f5d3..40655801cc 100644
--- a/app/test-pmd/txonly.c
+++ b/app/test-pmd/txonly.c
@@ -362,8 +362,8 @@ pkt_burst_transmit(struct fwd_stream *fs)
/*
* Initialize Ethernet header.
*/
- rte_ether_addr_copy(&peer_eth_addrs[fs->peer_addr], ð_hdr.d_addr);
- rte_ether_addr_copy(&ports[fs->tx_port].eth_addr, ð_hdr.s_addr);
+ rte_ether_addr_copy(&peer_eth_addrs[fs->peer_addr], ð_hdr.dst_addr);
+ rte_ether_addr_copy(&ports[fs->tx_port].eth_addr, ð_hdr.src_addr);
eth_hdr.ether_type = rte_cpu_to_be_16(RTE_ETHER_TYPE_IPV4);
if (rte_mempool_get_bulk(mbp, (void **)pkts_burst,
diff --git a/app/test-pmd/util.c b/app/test-pmd/util.c
index 14a9a251fb..51506e4940 100644
--- a/app/test-pmd/util.c
+++ b/app/test-pmd/util.c
@@ -142,9 +142,9 @@ dump_pkt_burst(uint16_t port_id, uint16_t queue, struct rte_mbuf *pkts[],
" - no miss group");
MKDUMPSTR(print_buf, buf_size, cur_len, "\n");
}
- print_ether_addr(" src=", ð_hdr->s_addr,
+ print_ether_addr(" src=", ð_hdr->src_addr,
print_buf, buf_size, &cur_len);
- print_ether_addr(" - dst=", ð_hdr->d_addr,
+ print_ether_addr(" - dst=", ð_hdr->dst_addr,
print_buf, buf_size, &cur_len);
MKDUMPSTR(print_buf, buf_size, cur_len,
" - type=0x%04x - length=%u - nb_segs=%d",
diff --git a/app/test/packet_burst_generator.c b/app/test/packet_burst_generator.c
index 0fd7290b0e..8ac24577ba 100644
--- a/app/test/packet_burst_generator.c
+++ b/app/test/packet_burst_generator.c
@@ -56,8 +56,8 @@ initialize_eth_header(struct rte_ether_hdr *eth_hdr,
struct rte_ether_addr *dst_mac, uint16_t ether_type,
uint8_t vlan_enabled, uint16_t van_id)
{
- rte_ether_addr_copy(dst_mac, ð_hdr->d_addr);
- rte_ether_addr_copy(src_mac, ð_hdr->s_addr);
+ rte_ether_addr_copy(dst_mac, ð_hdr->dst_addr);
+ rte_ether_addr_copy(src_mac, ð_hdr->src_addr);
if (vlan_enabled) {
struct rte_vlan_hdr *vhdr = (struct rte_vlan_hdr *)(
diff --git a/app/test/test_bpf.c b/app/test/test_bpf.c
index 527c06b807..8118a1849b 100644
--- a/app/test/test_bpf.c
+++ b/app/test/test_bpf.c
@@ -1008,9 +1008,9 @@ test_jump2_prepare(void *arg)
* Initialize ether header.
*/
rte_ether_addr_copy((struct rte_ether_addr *)dst_mac,
- &dn->eth_hdr.d_addr);
+ &dn->eth_hdr.dst_addr);
rte_ether_addr_copy((struct rte_ether_addr *)src_mac,
- &dn->eth_hdr.s_addr);
+ &dn->eth_hdr.src_addr);
dn->eth_hdr.ether_type = rte_cpu_to_be_16(RTE_ETHER_TYPE_VLAN);
/*
diff --git a/app/test/test_link_bonding_mode4.c b/app/test/test_link_bonding_mode4.c
index 2c835fa7ad..f120b2e3be 100644
--- a/app/test/test_link_bonding_mode4.c
+++ b/app/test/test_link_bonding_mode4.c
@@ -502,8 +502,8 @@ make_lacp_reply(struct slave_conf *slave, struct rte_mbuf *pkt)
slow_hdr = rte_pktmbuf_mtod(pkt, struct slow_protocol_frame *);
/* Change source address to partner address */
- rte_ether_addr_copy(&parnter_mac_default, &slow_hdr->eth_hdr.s_addr);
- slow_hdr->eth_hdr.s_addr.addr_bytes[RTE_ETHER_ADDR_LEN - 1] =
+ rte_ether_addr_copy(&parnter_mac_default, &slow_hdr->eth_hdr.src_addr);
+ slow_hdr->eth_hdr.src_addr.addr_bytes[RTE_ETHER_ADDR_LEN - 1] =
slave->port_id;
lacp = (struct lacpdu *) &slow_hdr->slow_protocol;
@@ -870,7 +870,7 @@ test_mode4_rx(void)
for (i = 0; i < expected_pkts_cnt; i++) {
hdr = rte_pktmbuf_mtod(pkts[i], struct rte_ether_hdr *);
- cnt[rte_is_same_ether_addr(&hdr->d_addr,
+ cnt[rte_is_same_ether_addr(&hdr->dst_addr,
&bonded_mac)]++;
}
@@ -918,7 +918,7 @@ test_mode4_rx(void)
for (i = 0; i < expected_pkts_cnt; i++) {
hdr = rte_pktmbuf_mtod(pkts[i], struct rte_ether_hdr *);
- eq_cnt += rte_is_same_ether_addr(&hdr->d_addr,
+ eq_cnt += rte_is_same_ether_addr(&hdr->dst_addr,
&bonded_mac);
}
@@ -1163,11 +1163,12 @@ init_marker(struct rte_mbuf *pkt, struct slave_conf *slave)
/* Copy multicast destination address */
rte_ether_addr_copy(&slow_protocol_mac_addr,
- &marker_hdr->eth_hdr.d_addr);
+ &marker_hdr->eth_hdr.dst_addr);
/* Init source address */
- rte_ether_addr_copy(&parnter_mac_default, &marker_hdr->eth_hdr.s_addr);
- marker_hdr->eth_hdr.s_addr.addr_bytes[RTE_ETHER_ADDR_LEN - 1] =
+ rte_ether_addr_copy(&parnter_mac_default,
+ &marker_hdr->eth_hdr.src_addr);
+ marker_hdr->eth_hdr.src_addr.addr_bytes[RTE_ETHER_ADDR_LEN - 1] =
slave->port_id;
marker_hdr->eth_hdr.ether_type = rte_cpu_to_be_16(RTE_ETHER_TYPE_SLOW);
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index a2fe766d4b..918ea3f403 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -164,8 +164,13 @@ Deprecation Notices
consistent with existing outer header checksum status flag naming, which
should help in reducing confusion about its usage.
-* net: ``s_addr`` and ``d_addr`` fields of ``rte_ether_hdr`` structure
- will be renamed in DPDK 21.11 to avoid conflict with Windows Sockets headers.
+* i40e: As there are both i40evf and iavf pmd, the functions of them are
+ duplicated. And now more and more advanced features are developed on iavf.
+ To keep consistent with kernel driver's name
+ (https://patchwork.ozlabs.org/patch/970154/), i40evf is no need to maintain.
+ Starting from 21.05, the default VF driver of i40e will be iavf, but i40evf
+ can still be used if users specify the devarg "driver=i40evf". I40evf will
+ be deleted in DPDK 21.11.
* net: The structure ``rte_ipv4_hdr`` will have two unions.
The first union is for existing ``version_ihl`` byte
diff --git a/doc/guides/rel_notes/release_21_11.rst b/doc/guides/rel_notes/release_21_11.rst
index efeffe37a0..907e45c4e7 100644
--- a/doc/guides/rel_notes/release_21_11.rst
+++ b/doc/guides/rel_notes/release_21_11.rst
@@ -191,6 +191,9 @@ API Changes
the crypto/security operation. This field will be used to communicate
events such as soft expiry with IPsec in lookaside mode.
+* net: Renamed ``s_addr`` and ``d_addr`` fields of ``rte_ether_hdr`` structure
+ to ``src_addr`` and ``dst_addr``, respectively.
+
ABI Changes
-----------
diff --git a/drivers/net/avp/avp_ethdev.c b/drivers/net/avp/avp_ethdev.c
index 623fa5e5ff..b5fafd32b0 100644
--- a/drivers/net/avp/avp_ethdev.c
+++ b/drivers/net/avp/avp_ethdev.c
@@ -1205,17 +1205,17 @@ _avp_mac_filter(struct avp_dev *avp, struct rte_mbuf *m)
{
struct rte_ether_hdr *eth = rte_pktmbuf_mtod(m, struct rte_ether_hdr *);
- if (likely(_avp_cmp_ether_addr(&avp->ethaddr, ð->d_addr) == 0)) {
+ if (likely(_avp_cmp_ether_addr(&avp->ethaddr, ð->dst_addr) == 0)) {
/* allow all packets destined to our address */
return 0;
}
- if (likely(rte_is_broadcast_ether_addr(ð->d_addr))) {
+ if (likely(rte_is_broadcast_ether_addr(ð->dst_addr))) {
/* allow all broadcast packets */
return 0;
}
- if (likely(rte_is_multicast_ether_addr(ð->d_addr))) {
+ if (likely(rte_is_multicast_ether_addr(ð->dst_addr))) {
/* allow all multicast packets */
return 0;
}
diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
index 9163b8b1fd..083deff1b1 100644
--- a/drivers/net/bnx2x/bnx2x.c
+++ b/drivers/net/bnx2x/bnx2x.c
@@ -2233,8 +2233,8 @@ int bnx2x_tx_encap(struct bnx2x_tx_queue *txq, struct rte_mbuf *m0)
tx_parse_bd =
&txq->tx_ring[TX_BD(bd_prod, txq)].parse_bd_e2;
- if (rte_is_multicast_ether_addr(&eh->d_addr)) {
- if (rte_is_broadcast_ether_addr(&eh->d_addr))
+ if (rte_is_multicast_ether_addr(&eh->dst_addr)) {
+ if (rte_is_broadcast_ether_addr(&eh->dst_addr))
mac_type = BROADCAST_ADDRESS;
else
mac_type = MULTICAST_ADDRESS;
@@ -2243,17 +2243,17 @@ int bnx2x_tx_encap(struct bnx2x_tx_queue *txq, struct rte_mbuf *m0)
(mac_type << ETH_TX_PARSE_BD_E2_ETH_ADDR_TYPE_SHIFT);
rte_memcpy(&tx_parse_bd->data.mac_addr.dst_hi,
- &eh->d_addr.addr_bytes[0], 2);
+ &eh->dst_addr.addr_bytes[0], 2);
rte_memcpy(&tx_parse_bd->data.mac_addr.dst_mid,
- &eh->d_addr.addr_bytes[2], 2);
+ &eh->dst_addr.addr_bytes[2], 2);
rte_memcpy(&tx_parse_bd->data.mac_addr.dst_lo,
- &eh->d_addr.addr_bytes[4], 2);
+ &eh->dst_addr.addr_bytes[4], 2);
rte_memcpy(&tx_parse_bd->data.mac_addr.src_hi,
- &eh->s_addr.addr_bytes[0], 2);
+ &eh->src_addr.addr_bytes[0], 2);
rte_memcpy(&tx_parse_bd->data.mac_addr.src_mid,
- &eh->s_addr.addr_bytes[2], 2);
+ &eh->src_addr.addr_bytes[2], 2);
rte_memcpy(&tx_parse_bd->data.mac_addr.src_lo,
- &eh->s_addr.addr_bytes[4], 2);
+ &eh->src_addr.addr_bytes[4], 2);
tx_parse_bd->data.mac_addr.dst_hi =
rte_cpu_to_be_16(tx_parse_bd->data.mac_addr.dst_hi);
diff --git a/drivers/net/bonding/rte_eth_bond_8023ad.c b/drivers/net/bonding/rte_eth_bond_8023ad.c
index 8b5b32fcaf..3558644232 100644
--- a/drivers/net/bonding/rte_eth_bond_8023ad.c
+++ b/drivers/net/bonding/rte_eth_bond_8023ad.c
@@ -587,8 +587,8 @@ tx_machine(struct bond_dev_private *internals, uint16_t slave_id)
hdr = rte_pktmbuf_mtod(lacp_pkt, struct lacpdu_header *);
/* Source and destination MAC */
- rte_ether_addr_copy(&lacp_mac_addr, &hdr->eth_hdr.d_addr);
- rte_eth_macaddr_get(slave_id, &hdr->eth_hdr.s_addr);
+ rte_ether_addr_copy(&lacp_mac_addr, &hdr->eth_hdr.dst_addr);
+ rte_eth_macaddr_get(slave_id, &hdr->eth_hdr.src_addr);
hdr->eth_hdr.ether_type = rte_cpu_to_be_16(RTE_ETHER_TYPE_SLOW);
lacpdu = &hdr->lacpdu;
@@ -1346,7 +1346,7 @@ bond_mode_8023ad_handle_slow_pkt(struct bond_dev_private *internals,
} while (unlikely(retval == 0));
m_hdr->marker.tlv_type_marker = MARKER_TLV_TYPE_RESP;
- rte_eth_macaddr_get(slave_id, &m_hdr->eth_hdr.s_addr);
+ rte_eth_macaddr_get(slave_id, &m_hdr->eth_hdr.src_addr);
if (internals->mode4.dedicated_queues.enabled == 0) {
if (rte_ring_enqueue(port->tx_ring, pkt) != 0) {
diff --git a/drivers/net/bonding/rte_eth_bond_alb.c b/drivers/net/bonding/rte_eth_bond_alb.c
index 1d36a4a4a2..86335a7971 100644
--- a/drivers/net/bonding/rte_eth_bond_alb.c
+++ b/drivers/net/bonding/rte_eth_bond_alb.c
@@ -213,8 +213,8 @@ bond_mode_alb_arp_upd(struct client_data *client_info,
rte_spinlock_lock(&internals->mode6.lock);
eth_h = rte_pktmbuf_mtod(pkt, struct rte_ether_hdr *);
- rte_ether_addr_copy(&client_info->app_mac, ð_h->s_addr);
- rte_ether_addr_copy(&client_info->cli_mac, ð_h->d_addr);
+ rte_ether_addr_copy(&client_info->app_mac, ð_h->src_addr);
+ rte_ether_addr_copy(&client_info->cli_mac, ð_h->dst_addr);
if (client_info->vlan_count > 0)
eth_h->ether_type = rte_cpu_to_be_16(RTE_ETHER_TYPE_VLAN);
else
diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c b/drivers/net/bonding/rte_eth_bond_pmd.c
index 54987d96b3..6831fcb104 100644
--- a/drivers/net/bonding/rte_eth_bond_pmd.c
+++ b/drivers/net/bonding/rte_eth_bond_pmd.c
@@ -342,11 +342,11 @@ rx_burst_8023ad(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts,
bufs[j])) ||
!collecting ||
(!promisc &&
- ((rte_is_unicast_ether_addr(&hdr->d_addr) &&
+ ((rte_is_unicast_ether_addr(&hdr->dst_addr) &&
!rte_is_same_ether_addr(bond_mac,
- &hdr->d_addr)) ||
+ &hdr->dst_addr)) ||
(!allmulti &&
- rte_is_multicast_ether_addr(&hdr->d_addr)))))) {
+ rte_is_multicast_ether_addr(&hdr->dst_addr)))))) {
if (hdr->ether_type == ether_type_slow_be) {
bond_mode_8023ad_handle_slow_pkt(
@@ -477,9 +477,9 @@ update_client_stats(uint32_t addr, uint16_t port, uint32_t *TXorRXindicator)
"DstMAC:" RTE_ETHER_ADDR_PRT_FMT " DstIP:%s %s %d\n", \
info, \
port, \
- RTE_ETHER_ADDR_BYTES(ð_h->s_addr), \
+ RTE_ETHER_ADDR_BYTES(ð_h->src_addr), \
src_ip, \
- RTE_ETHER_ADDR_BYTES(ð_h->d_addr), \
+ RTE_ETHER_ADDR_BYTES(ð_h->dst_addr), \
dst_ip, \
arp_op, ++burstnumber)
#endif
@@ -643,9 +643,9 @@ static inline uint16_t
ether_hash(struct rte_ether_hdr *eth_hdr)
{
unaligned_uint16_t *word_src_addr =
- (unaligned_uint16_t *)eth_hdr->s_addr.addr_bytes;
+ (unaligned_uint16_t *)eth_hdr->src_addr.addr_bytes;
unaligned_uint16_t *word_dst_addr =
- (unaligned_uint16_t *)eth_hdr->d_addr.addr_bytes;
+ (unaligned_uint16_t *)eth_hdr->dst_addr.addr_bytes;
return (word_src_addr[0] ^ word_dst_addr[0]) ^
(word_src_addr[1] ^ word_dst_addr[1]) ^
@@ -942,10 +942,10 @@ bond_ethdev_tx_burst_tlb(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
ether_hdr = rte_pktmbuf_mtod(bufs[j],
struct rte_ether_hdr *);
- if (rte_is_same_ether_addr(ðer_hdr->s_addr,
+ if (rte_is_same_ether_addr(ðer_hdr->src_addr,
&primary_slave_addr))
rte_ether_addr_copy(&active_slave_addr,
- ðer_hdr->s_addr);
+ ðer_hdr->src_addr);
#if defined(RTE_LIBRTE_BOND_DEBUG_ALB) || defined(RTE_LIBRTE_BOND_DEBUG_ALB_L1)
mode6_debug("TX IPv4:", ether_hdr, slaves[i], &burstnumberTX);
#endif
@@ -1017,7 +1017,7 @@ bond_ethdev_tx_burst_alb(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
slave_idx = bond_mode_alb_arp_xmit(eth_h, offset, internals);
/* Change src mac in eth header */
- rte_eth_macaddr_get(slave_idx, ð_h->s_addr);
+ rte_eth_macaddr_get(slave_idx, ð_h->src_addr);
/* Add packet to slave tx buffer */
slave_bufs[slave_idx][slave_bufs_pkts[slave_idx]] = bufs[i];
diff --git a/drivers/net/enic/enic_flow.c b/drivers/net/enic/enic_flow.c
index cdfdc904a6..33147169ba 100644
--- a/drivers/net/enic/enic_flow.c
+++ b/drivers/net/enic/enic_flow.c
@@ -656,14 +656,14 @@ enic_copy_item_eth_v2(struct copy_item_args *arg)
if (!mask)
mask = &rte_flow_item_eth_mask;
- memcpy(enic_spec.d_addr.addr_bytes, spec->dst.addr_bytes,
+ memcpy(enic_spec.dst_addr.addr_bytes, spec->dst.addr_bytes,
RTE_ETHER_ADDR_LEN);
- memcpy(enic_spec.s_addr.addr_bytes, spec->src.addr_bytes,
+ memcpy(enic_spec.src_addr.addr_bytes, spec->src.addr_bytes,
RTE_ETHER_ADDR_LEN);
- memcpy(enic_mask.d_addr.addr_bytes, mask->dst.addr_bytes,
+ memcpy(enic_mask.dst_addr.addr_bytes, mask->dst.addr_bytes,
RTE_ETHER_ADDR_LEN);
- memcpy(enic_mask.s_addr.addr_bytes, mask->src.addr_bytes,
+ memcpy(enic_mask.src_addr.addr_bytes, mask->src.addr_bytes,
RTE_ETHER_ADDR_LEN);
enic_spec.ether_type = spec->type;
enic_mask.ether_type = mask->type;
diff --git a/drivers/net/mlx5/mlx5_txpp.c b/drivers/net/mlx5/mlx5_txpp.c
index 4f6da9f2d1..2be7e71f89 100644
--- a/drivers/net/mlx5/mlx5_txpp.c
+++ b/drivers/net/mlx5/mlx5_txpp.c
@@ -333,8 +333,8 @@ mlx5_txpp_fill_wqe_clock_queue(struct mlx5_dev_ctx_shared *sh)
/* Build test packet L2 header (Ethernet). */
dst = (uint8_t *)&es->inline_data;
eth_hdr = (struct rte_ether_hdr *)dst;
- rte_eth_random_addr(ð_hdr->d_addr.addr_bytes[0]);
- rte_eth_random_addr(ð_hdr->s_addr.addr_bytes[0]);
+ rte_eth_random_addr(ð_hdr->dst_addr.addr_bytes[0]);
+ rte_eth_random_addr(ð_hdr->src_addr.addr_bytes[0]);
eth_hdr->ether_type = rte_cpu_to_be_16(RTE_ETHER_TYPE_IPV4);
/* Build test packet L3 header (IP v4). */
dst += sizeof(struct rte_ether_hdr);
diff --git a/examples/bond/main.c b/examples/bond/main.c
index a63ca70a7f..7adaa93cad 100644
--- a/examples/bond/main.c
+++ b/examples/bond/main.c
@@ -358,7 +358,7 @@ struct global_flag_stru_t *global_flag_stru_p = &global_flag_stru;
static int lcore_main(__rte_unused void *arg1)
{
struct rte_mbuf *pkts[MAX_PKT_BURST] __rte_cache_aligned;
- struct rte_ether_addr d_addr;
+ struct rte_ether_addr dst_addr;
struct rte_ether_addr bond_mac_addr;
struct rte_ether_hdr *eth_hdr;
@@ -422,13 +422,13 @@ static int lcore_main(__rte_unused void *arg1)
if (arp_hdr->arp_opcode == rte_cpu_to_be_16(RTE_ARP_OP_REQUEST)) {
arp_hdr->arp_opcode = rte_cpu_to_be_16(RTE_ARP_OP_REPLY);
/* Switch src and dst data and set bonding MAC */
- rte_ether_addr_copy(ð_hdr->s_addr, ð_hdr->d_addr);
- rte_ether_addr_copy(&bond_mac_addr, ð_hdr->s_addr);
+ rte_ether_addr_copy(ð_hdr->src_addr, ð_hdr->dst_addr);
+ rte_ether_addr_copy(&bond_mac_addr, ð_hdr->src_addr);
rte_ether_addr_copy(&arp_hdr->arp_data.arp_sha,
&arp_hdr->arp_data.arp_tha);
arp_hdr->arp_data.arp_tip = arp_hdr->arp_data.arp_sip;
- rte_ether_addr_copy(&bond_mac_addr, &d_addr);
- rte_ether_addr_copy(&d_addr, &arp_hdr->arp_data.arp_sha);
+ rte_ether_addr_copy(&bond_mac_addr, &dst_addr);
+ rte_ether_addr_copy(&dst_addr, &arp_hdr->arp_data.arp_sha);
arp_hdr->arp_data.arp_sip = bond_ip;
rte_eth_tx_burst(BOND_PORT, 0, &pkts[i], 1);
is_free = 1;
@@ -443,8 +443,10 @@ static int lcore_main(__rte_unused void *arg1)
}
ipv4_hdr = (struct rte_ipv4_hdr *)((char *)(eth_hdr + 1) + offset);
if (ipv4_hdr->dst_addr == bond_ip) {
- rte_ether_addr_copy(ð_hdr->s_addr, ð_hdr->d_addr);
- rte_ether_addr_copy(&bond_mac_addr, ð_hdr->s_addr);
+ rte_ether_addr_copy(ð_hdr->src_addr,
+ ð_hdr->dst_addr);
+ rte_ether_addr_copy(&bond_mac_addr,
+ ð_hdr->src_addr);
ipv4_hdr->dst_addr = ipv4_hdr->src_addr;
ipv4_hdr->src_addr = bond_ip;
rte_eth_tx_burst(BOND_PORT, 0, &pkts[i], 1);
@@ -519,8 +521,8 @@ static void cmd_obj_send_parsed(void *parsed_result,
created_pkt->pkt_len = pkt_size;
eth_hdr = rte_pktmbuf_mtod(created_pkt, struct rte_ether_hdr *);
- rte_ether_addr_copy(&bond_mac_addr, ð_hdr->s_addr);
- memset(ð_hdr->d_addr, 0xFF, RTE_ETHER_ADDR_LEN);
+ rte_ether_addr_copy(&bond_mac_addr, ð_hdr->src_addr);
+ memset(ð_hdr->dst_addr, 0xFF, RTE_ETHER_ADDR_LEN);
eth_hdr->ether_type = rte_cpu_to_be_16(RTE_ETHER_TYPE_ARP);
arp_hdr = (struct rte_arp_hdr *)(
diff --git a/examples/ethtool/ethtool-app/main.c b/examples/ethtool/ethtool-app/main.c
index 21ed85c7d6..1bc675962b 100644
--- a/examples/ethtool/ethtool-app/main.c
+++ b/examples/ethtool/ethtool-app/main.c
@@ -172,8 +172,8 @@ static void process_frame(struct app_port *ptr_port,
struct rte_ether_hdr *ptr_mac_hdr;
ptr_mac_hdr = rte_pktmbuf_mtod(ptr_frame, struct rte_ether_hdr *);
- rte_ether_addr_copy(&ptr_mac_hdr->s_addr, &ptr_mac_hdr->d_addr);
- rte_ether_addr_copy(&ptr_port->mac_addr, &ptr_mac_hdr->s_addr);
+ rte_ether_addr_copy(&ptr_mac_hdr->src_addr, &ptr_mac_hdr->dst_addr);
+ rte_ether_addr_copy(&ptr_port->mac_addr, &ptr_mac_hdr->src_addr);
}
static int worker_main(__rte_unused void *ptr_data)
diff --git a/examples/eventdev_pipeline/pipeline_common.h b/examples/eventdev_pipeline/pipeline_common.h
index 6a4287602e..b12eb281e1 100644
--- a/examples/eventdev_pipeline/pipeline_common.h
+++ b/examples/eventdev_pipeline/pipeline_common.h
@@ -104,8 +104,8 @@ exchange_mac(struct rte_mbuf *m)
/* change mac addresses on packet (to use mbuf data) */
eth = rte_pktmbuf_mtod(m, struct rte_ether_hdr *);
- rte_ether_addr_copy(ð->d_addr, &addr);
- rte_ether_addr_copy(&addr, ð->d_addr);
+ rte_ether_addr_copy(ð->dst_addr, &addr);
+ rte_ether_addr_copy(&addr, ð->dst_addr);
}
static __rte_always_inline void
diff --git a/examples/flow_filtering/main.c b/examples/flow_filtering/main.c
index 29fb4b3d55..dd8a33d036 100644
--- a/examples/flow_filtering/main.c
+++ b/examples/flow_filtering/main.c
@@ -75,9 +75,9 @@ main_loop(void)
eth_hdr = rte_pktmbuf_mtod(m,
struct rte_ether_hdr *);
print_ether_addr("src=",
- ð_hdr->s_addr);
+ ð_hdr->src_addr);
print_ether_addr(" - dst=",
- ð_hdr->d_addr);
+ ð_hdr->dst_addr);
printf(" - queue=0x%x",
(unsigned int)i);
printf("\n");
diff --git a/examples/ioat/ioatfwd.c b/examples/ioat/ioatfwd.c
index b3977a8be5..ff36aa7f1e 100644
--- a/examples/ioat/ioatfwd.c
+++ b/examples/ioat/ioatfwd.c
@@ -322,11 +322,11 @@ update_mac_addrs(struct rte_mbuf *m, uint32_t dest_portid)
/* 02:00:00:00:00:xx - overwriting 2 bytes of source address but
* it's acceptable cause it gets overwritten by rte_ether_addr_copy
*/
- tmp = ð->d_addr.addr_bytes[0];
+ tmp = ð->dst_addr.addr_bytes[0];
*((uint64_t *)tmp) = 0x000000000002 + ((uint64_t)dest_portid << 40);
/* src addr */
- rte_ether_addr_copy(&ioat_ports_eth_addr[dest_portid], ð->s_addr);
+ rte_ether_addr_copy(&ioat_ports_eth_addr[dest_portid], ð->src_addr);
}
/* Perform packet copy there is a user-defined function. 8< */
diff --git a/examples/ip_fragmentation/main.c b/examples/ip_fragmentation/main.c
index f245369720..a7f40970f2 100644
--- a/examples/ip_fragmentation/main.c
+++ b/examples/ip_fragmentation/main.c
@@ -362,13 +362,13 @@ l3fwd_simple_forward(struct rte_mbuf *m, struct lcore_queue_conf *qconf,
m->l2_len = sizeof(struct rte_ether_hdr);
/* 02:00:00:00:00:xx */
- d_addr_bytes = ð_hdr->d_addr.addr_bytes[0];
+ d_addr_bytes = ð_hdr->dst_addr.addr_bytes[0];
*((uint64_t *)d_addr_bytes) = 0x000000000002 +
((uint64_t)port_out << 40);
/* src addr */
rte_ether_addr_copy(&ports_eth_addr[port_out],
- ð_hdr->s_addr);
+ ð_hdr->src_addr);
eth_hdr->ether_type = ether_type;
}
diff --git a/examples/ip_reassembly/main.c b/examples/ip_reassembly/main.c
index 8645ac790b..d611c7d016 100644
--- a/examples/ip_reassembly/main.c
+++ b/examples/ip_reassembly/main.c
@@ -413,11 +413,11 @@ reassemble(struct rte_mbuf *m, uint16_t portid, uint32_t queue,
/* if packet wasn't IPv4 or IPv6, it's forwarded to the port it came from */
/* 02:00:00:00:00:xx */
- d_addr_bytes = ð_hdr->d_addr.addr_bytes[0];
+ d_addr_bytes = ð_hdr->dst_addr.addr_bytes[0];
*((uint64_t *)d_addr_bytes) = 0x000000000002 + ((uint64_t)dst_port << 40);
/* src addr */
- rte_ether_addr_copy(&ports_eth_addr[dst_port], ð_hdr->s_addr);
+ rte_ether_addr_copy(&ports_eth_addr[dst_port], ð_hdr->src_addr);
send_single_packet(m, dst_port);
}
diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-secgw/ipsec-secgw.c
index 7ad94cb822..7b01872c6f 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -545,9 +545,9 @@ prepare_tx_pkt(struct rte_mbuf *pkt, uint16_t port,
ethhdr->ether_type = rte_cpu_to_be_16(RTE_ETHER_TYPE_IPV6);
}
- memcpy(ðhdr->s_addr, ðaddr_tbl[port].src,
+ memcpy(ðhdr->src_addr, ðaddr_tbl[port].src,
sizeof(struct rte_ether_addr));
- memcpy(ðhdr->d_addr, ðaddr_tbl[port].dst,
+ memcpy(ðhdr->dst_addr, ðaddr_tbl[port].dst,
sizeof(struct rte_ether_addr));
}
diff --git a/examples/ipsec-secgw/ipsec_worker.c b/examples/ipsec-secgw/ipsec_worker.c
index c545497cee..61cf9f57fb 100644
--- a/examples/ipsec-secgw/ipsec_worker.c
+++ b/examples/ipsec-secgw/ipsec_worker.c
@@ -49,8 +49,8 @@ update_mac_addrs(struct rte_mbuf *pkt, uint16_t portid)
struct rte_ether_hdr *ethhdr;
ethhdr = rte_pktmbuf_mtod(pkt, struct rte_ether_hdr *);
- memcpy(ðhdr->s_addr, ðaddr_tbl[portid].src, RTE_ETHER_ADDR_LEN);
- memcpy(ðhdr->d_addr, ðaddr_tbl[portid].dst, RTE_ETHER_ADDR_LEN);
+ memcpy(ðhdr->src_addr, ðaddr_tbl[portid].src, RTE_ETHER_ADDR_LEN);
+ memcpy(ðhdr->dst_addr, ðaddr_tbl[portid].dst, RTE_ETHER_ADDR_LEN);
}
static inline void
diff --git a/examples/ipv4_multicast/main.c b/examples/ipv4_multicast/main.c
index cc527d7f6b..d10de30ddb 100644
--- a/examples/ipv4_multicast/main.c
+++ b/examples/ipv4_multicast/main.c
@@ -283,8 +283,8 @@ mcast_send_pkt(struct rte_mbuf *pkt, struct rte_ether_addr *dest_addr,
rte_pktmbuf_prepend(pkt, (uint16_t)sizeof(*ethdr));
RTE_ASSERT(ethdr != NULL);
- rte_ether_addr_copy(dest_addr, ðdr->d_addr);
- rte_ether_addr_copy(&ports_eth_addr[port], ðdr->s_addr);
+ rte_ether_addr_copy(dest_addr, ðdr->dst_addr);
+ rte_ether_addr_copy(&ports_eth_addr[port], ðdr->src_addr);
ethdr->ether_type = rte_be_to_cpu_16(RTE_ETHER_TYPE_IPV4);
/* Put new packet into the output queue */
diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index 66d1491bf7..c2ffbdd506 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -617,11 +617,11 @@ l2fwd_mac_updating(struct rte_mbuf *m, uint16_t dest_portid)
eth = rte_pktmbuf_mtod(m, struct rte_ether_hdr *);
/* 02:00:00:00:00:xx */
- tmp = ð->d_addr.addr_bytes[0];
+ tmp = ð->dst_addr.addr_bytes[0];
*((uint64_t *)tmp) = 0x000000000002 + ((uint64_t)dest_portid << 40);
/* src addr */
- rte_ether_addr_copy(&l2fwd_ports_eth_addr[dest_portid], ð->s_addr);
+ rte_ether_addr_copy(&l2fwd_ports_eth_addr[dest_portid], ð->src_addr);
}
static void
diff --git a/examples/l2fwd-event/l2fwd_common.h b/examples/l2fwd-event/l2fwd_common.h
index 939221d45a..cecbd9b70e 100644
--- a/examples/l2fwd-event/l2fwd_common.h
+++ b/examples/l2fwd-event/l2fwd_common.h
@@ -92,11 +92,11 @@ l2fwd_mac_updating(struct rte_mbuf *m, uint32_t dest_port_id,
eth = rte_pktmbuf_mtod(m, struct rte_ether_hdr *);
/* 02:00:00:00:00:xx */
- tmp = ð->d_addr.addr_bytes[0];
+ tmp = ð->dst_addr.addr_bytes[0];
*((uint64_t *)tmp) = 0x000000000002 + ((uint64_t)dest_port_id << 40);
/* src addr */
- rte_ether_addr_copy(addr, ð->s_addr);
+ rte_ether_addr_copy(addr, ð->src_addr);
}
static __rte_always_inline struct l2fwd_resources *
diff --git a/examples/l2fwd-jobstats/main.c b/examples/l2fwd-jobstats/main.c
index afe7fe6ead..06280321b1 100644
--- a/examples/l2fwd-jobstats/main.c
+++ b/examples/l2fwd-jobstats/main.c
@@ -351,11 +351,11 @@ l2fwd_simple_forward(struct rte_mbuf *m, unsigned portid)
eth = rte_pktmbuf_mtod(m, struct rte_ether_hdr *);
/* 02:00:00:00:00:xx */
- tmp = ð->d_addr.addr_bytes[0];
+ tmp = ð->dst_addr.addr_bytes[0];
*((uint64_t *)tmp) = 0x000000000002 + ((uint64_t)dst_port << 40);
/* src addr */
- rte_ether_addr_copy(&l2fwd_ports_eth_addr[dst_port], ð->s_addr);
+ rte_ether_addr_copy(&l2fwd_ports_eth_addr[dst_port], ð->src_addr);
buffer = tx_buffer[dst_port];
sent = rte_eth_tx_buffer(dst_port, 0, buffer, m);
diff --git a/examples/l2fwd-keepalive/main.c b/examples/l2fwd-keepalive/main.c
index d0d979f5ba..07271affb4 100644
--- a/examples/l2fwd-keepalive/main.c
+++ b/examples/l2fwd-keepalive/main.c
@@ -177,11 +177,11 @@ l2fwd_simple_forward(struct rte_mbuf *m, unsigned portid)
eth = rte_pktmbuf_mtod(m, struct rte_ether_hdr *);
/* 02:00:00:00:00:xx */
- tmp = ð->d_addr.addr_bytes[0];
+ tmp = ð->dst_addr.addr_bytes[0];
*((uint64_t *)tmp) = 0x000000000002 + ((uint64_t)dst_port << 40);
/* src addr */
- rte_ether_addr_copy(&l2fwd_ports_eth_addr[dst_port], ð->s_addr);
+ rte_ether_addr_copy(&l2fwd_ports_eth_addr[dst_port], ð->src_addr);
buffer = tx_buffer[dst_port];
sent = rte_eth_tx_buffer(dst_port, 0, buffer, m);
diff --git a/examples/l2fwd/main.c b/examples/l2fwd/main.c
index 05532551a5..f3deeba0a6 100644
--- a/examples/l2fwd/main.c
+++ b/examples/l2fwd/main.c
@@ -170,11 +170,11 @@ l2fwd_mac_updating(struct rte_mbuf *m, unsigned dest_portid)
eth = rte_pktmbuf_mtod(m, struct rte_ether_hdr *);
/* 02:00:00:00:00:xx */
- tmp = ð->d_addr.addr_bytes[0];
+ tmp = ð->dst_addr.addr_bytes[0];
*((uint64_t *)tmp) = 0x000000000002 + ((uint64_t)dest_portid << 40);
/* src addr */
- rte_ether_addr_copy(&l2fwd_ports_eth_addr[dest_portid], ð->s_addr);
+ rte_ether_addr_copy(&l2fwd_ports_eth_addr[dest_portid], ð->src_addr);
}
/* Simple forward. 8< */
diff --git a/examples/l3fwd-acl/main.c b/examples/l3fwd-acl/main.c
index a1f457b564..60545f3059 100644
--- a/examples/l3fwd-acl/main.c
+++ b/examples/l3fwd-acl/main.c
@@ -1375,7 +1375,8 @@ send_single_packet(struct rte_mbuf *m, uint16_t port)
/* update src and dst mac*/
eh = rte_pktmbuf_mtod(m, struct rte_ether_hdr *);
- memcpy(eh, &port_l2hdr[port], sizeof(eh->d_addr) + sizeof(eh->s_addr));
+ memcpy(eh, &port_l2hdr[port],
+ sizeof(eh->dst_addr) + sizeof(eh->src_addr));
qconf = &lcore_conf[lcore_id];
rte_eth_tx_buffer(port, qconf->tx_queue_id[port],
@@ -1743,8 +1744,9 @@ parse_eth_dest(const char *optarg)
return "port value exceeds RTE_MAX_ETHPORTS("
RTE_STR(RTE_MAX_ETHPORTS) ")";
- if (cmdline_parse_etheraddr(NULL, port_end, &port_l2hdr[portid].d_addr,
- sizeof(port_l2hdr[portid].d_addr)) < 0)
+ if (cmdline_parse_etheraddr(NULL, port_end,
+ &port_l2hdr[portid].dst_addr,
+ sizeof(port_l2hdr[portid].dst_addr)) < 0)
return "Invalid ethernet address";
return NULL;
}
@@ -2002,8 +2004,9 @@ set_default_dest_mac(void)
uint32_t i;
for (i = 0; i != RTE_DIM(port_l2hdr); i++) {
- port_l2hdr[i].d_addr.addr_bytes[0] = RTE_ETHER_LOCAL_ADMIN_ADDR;
- port_l2hdr[i].d_addr.addr_bytes[5] = i;
+ port_l2hdr[i].dst_addr.addr_bytes[0] =
+ RTE_ETHER_LOCAL_ADMIN_ADDR;
+ port_l2hdr[i].dst_addr.addr_bytes[5] = i;
}
}
@@ -2109,14 +2112,14 @@ main(int argc, char **argv)
"rte_eth_dev_adjust_nb_rx_tx_desc: err=%d, port=%d\n",
ret, portid);
- ret = rte_eth_macaddr_get(portid, &port_l2hdr[portid].s_addr);
+ ret = rte_eth_macaddr_get(portid, &port_l2hdr[portid].src_addr);
if (ret < 0)
rte_exit(EXIT_FAILURE,
"rte_eth_macaddr_get: err=%d, port=%d\n",
ret, portid);
- print_ethaddr("Dst MAC:", &port_l2hdr[portid].d_addr);
- print_ethaddr(", Src MAC:", &port_l2hdr[portid].s_addr);
+ print_ethaddr("Dst MAC:", &port_l2hdr[portid].dst_addr);
+ print_ethaddr(", Src MAC:", &port_l2hdr[portid].src_addr);
printf(", ");
/* init memory */
diff --git a/examples/l3fwd-power/main.c b/examples/l3fwd-power/main.c
index aa7b8db44a..73a3ab5bc0 100644
--- a/examples/l3fwd-power/main.c
+++ b/examples/l3fwd-power/main.c
@@ -717,7 +717,7 @@ l3fwd_simple_forward(struct rte_mbuf *m, uint16_t portid,
dst_port = portid;
/* 02:00:00:00:00:xx */
- d_addr_bytes = ð_hdr->d_addr.addr_bytes[0];
+ d_addr_bytes = ð_hdr->dst_addr.addr_bytes[0];
*((uint64_t *)d_addr_bytes) =
0x000000000002 + ((uint64_t)dst_port << 40);
@@ -729,7 +729,7 @@ l3fwd_simple_forward(struct rte_mbuf *m, uint16_t portid,
/* src addr */
rte_ether_addr_copy(&ports_eth_addr[dst_port],
- ð_hdr->s_addr);
+ ð_hdr->src_addr);
send_single_packet(m, dst_port);
} else if (RTE_ETH_IS_IPV6_HDR(m->packet_type)) {
@@ -749,13 +749,13 @@ l3fwd_simple_forward(struct rte_mbuf *m, uint16_t portid,
dst_port = portid;
/* 02:00:00:00:00:xx */
- d_addr_bytes = ð_hdr->d_addr.addr_bytes[0];
+ d_addr_bytes = ð_hdr->dst_addr.addr_bytes[0];
*((uint64_t *)d_addr_bytes) =
0x000000000002 + ((uint64_t)dst_port << 40);
/* src addr */
rte_ether_addr_copy(&ports_eth_addr[dst_port],
- ð_hdr->s_addr);
+ ð_hdr->src_addr);
send_single_packet(m, dst_port);
#else
diff --git a/examples/l3fwd/l3fwd_em.h b/examples/l3fwd/l3fwd_em.h
index b992a21da4..e67f5f328c 100644
--- a/examples/l3fwd/l3fwd_em.h
+++ b/examples/l3fwd/l3fwd_em.h
@@ -36,11 +36,11 @@ l3fwd_em_handle_ipv4(struct rte_mbuf *m, uint16_t portid,
++(ipv4_hdr->hdr_checksum);
#endif
/* dst addr */
- *(uint64_t *)ð_hdr->d_addr = dest_eth_addr[dst_port];
+ *(uint64_t *)ð_hdr->dst_addr = dest_eth_addr[dst_port];
/* src addr */
rte_ether_addr_copy(&ports_eth_addr[dst_port],
- ð_hdr->s_addr);
+ ð_hdr->src_addr);
return dst_port;
}
@@ -64,11 +64,11 @@ l3fwd_em_handle_ipv6(struct rte_mbuf *m, uint16_t portid,
dst_port = portid;
/* dst addr */
- *(uint64_t *)ð_hdr->d_addr = dest_eth_addr[dst_port];
+ *(uint64_t *)ð_hdr->dst_addr = dest_eth_addr[dst_port];
/* src addr */
rte_ether_addr_copy(&ports_eth_addr[dst_port],
- ð_hdr->s_addr);
+ ð_hdr->src_addr);
return dst_port;
}
diff --git a/examples/l3fwd/l3fwd_fib.c b/examples/l3fwd/l3fwd_fib.c
index f8d6a3ac39..7fd7c1dd64 100644
--- a/examples/l3fwd/l3fwd_fib.c
+++ b/examples/l3fwd/l3fwd_fib.c
@@ -92,9 +92,9 @@ fib_send_single(int nb_tx, struct lcore_conf *qconf,
/* Set MAC addresses. */
eth_hdr = rte_pktmbuf_mtod(pkts_burst[j],
struct rte_ether_hdr *);
- *(uint64_t *)ð_hdr->d_addr = dest_eth_addr[hops[j]];
+ *(uint64_t *)ð_hdr->dst_addr = dest_eth_addr[hops[j]];
rte_ether_addr_copy(&ports_eth_addr[hops[j]],
- ð_hdr->s_addr);
+ ð_hdr->src_addr);
/* Send single packet. */
send_single_packet(qconf, pkts_burst[j], hops[j]);
diff --git a/examples/l3fwd/l3fwd_lpm.c b/examples/l3fwd/l3fwd_lpm.c
index 7200160164..232b606b54 100644
--- a/examples/l3fwd/l3fwd_lpm.c
+++ b/examples/l3fwd/l3fwd_lpm.c
@@ -256,11 +256,11 @@ lpm_process_event_pkt(const struct lcore_conf *lconf, struct rte_mbuf *mbuf)
}
#endif
/* dst addr */
- *(uint64_t *)ð_hdr->d_addr = dest_eth_addr[mbuf->port];
+ *(uint64_t *)ð_hdr->dst_addr = dest_eth_addr[mbuf->port];
/* src addr */
rte_ether_addr_copy(&ports_eth_addr[mbuf->port],
- ð_hdr->s_addr);
+ ð_hdr->src_addr);
#endif
return mbuf->port;
}
diff --git a/examples/l3fwd/l3fwd_lpm.h b/examples/l3fwd/l3fwd_lpm.h
index d730d72a20..c61b969584 100644
--- a/examples/l3fwd/l3fwd_lpm.h
+++ b/examples/l3fwd/l3fwd_lpm.h
@@ -40,11 +40,11 @@ l3fwd_lpm_simple_forward(struct rte_mbuf *m, uint16_t portid,
++(ipv4_hdr->hdr_checksum);
#endif
/* dst addr */
- *(uint64_t *)ð_hdr->d_addr = dest_eth_addr[dst_port];
+ *(uint64_t *)ð_hdr->dst_addr = dest_eth_addr[dst_port];
/* src addr */
rte_ether_addr_copy(&ports_eth_addr[dst_port],
- ð_hdr->s_addr);
+ ð_hdr->src_addr);
send_single_packet(qconf, m, dst_port);
} else if (RTE_ETH_IS_IPV6_HDR(m->packet_type)) {
@@ -62,11 +62,11 @@ l3fwd_lpm_simple_forward(struct rte_mbuf *m, uint16_t portid,
dst_port = portid;
/* dst addr */
- *(uint64_t *)ð_hdr->d_addr = dest_eth_addr[dst_port];
+ *(uint64_t *)ð_hdr->dst_addr = dest_eth_addr[dst_port];
/* src addr */
rte_ether_addr_copy(&ports_eth_addr[dst_port],
- ð_hdr->s_addr);
+ ð_hdr->src_addr);
send_single_packet(qconf, m, dst_port);
} else {
diff --git a/examples/link_status_interrupt/main.c b/examples/link_status_interrupt/main.c
index a0bc1e56d0..e4542df11f 100644
--- a/examples/link_status_interrupt/main.c
+++ b/examples/link_status_interrupt/main.c
@@ -182,11 +182,11 @@ lsi_simple_forward(struct rte_mbuf *m, unsigned portid)
eth = rte_pktmbuf_mtod(m, struct rte_ether_hdr *);
/* 02:00:00:00:00:xx */
- tmp = ð->d_addr.addr_bytes[0];
+ tmp = ð->dst_addr.addr_bytes[0];
*((uint64_t *)tmp) = 0x000000000002 + ((uint64_t)dst_port << 40);
/* src addr */
- rte_ether_addr_copy(&lsi_ports_eth_addr[dst_port], ð->s_addr);
+ rte_ether_addr_copy(&lsi_ports_eth_addr[dst_port], ð->src_addr);
buffer = tx_buffer[dst_port];
sent = rte_eth_tx_buffer(dst_port, 0, buffer, m);
diff --git a/examples/performance-thread/l3fwd-thread/main.c b/examples/performance-thread/l3fwd-thread/main.c
index 2f593abf26..2905199743 100644
--- a/examples/performance-thread/l3fwd-thread/main.c
+++ b/examples/performance-thread/l3fwd-thread/main.c
@@ -1068,24 +1068,24 @@ simple_ipv4_fwd_8pkts(struct rte_mbuf *m[8], uint16_t portid)
#endif
/* dst addr */
- *(uint64_t *)ð_hdr[0]->d_addr = dest_eth_addr[dst_port[0]];
- *(uint64_t *)ð_hdr[1]->d_addr = dest_eth_addr[dst_port[1]];
- *(uint64_t *)ð_hdr[2]->d_addr = dest_eth_addr[dst_port[2]];
- *(uint64_t *)ð_hdr[3]->d_addr = dest_eth_addr[dst_port[3]];
- *(uint64_t *)ð_hdr[4]->d_addr = dest_eth_addr[dst_port[4]];
- *(uint64_t *)ð_hdr[5]->d_addr = dest_eth_addr[dst_port[5]];
- *(uint64_t *)ð_hdr[6]->d_addr = dest_eth_addr[dst_port[6]];
- *(uint64_t *)ð_hdr[7]->d_addr = dest_eth_addr[dst_port[7]];
+ *(uint64_t *)ð_hdr[0]->dst_addr = dest_eth_addr[dst_port[0]];
+ *(uint64_t *)ð_hdr[1]->dst_addr = dest_eth_addr[dst_port[1]];
+ *(uint64_t *)ð_hdr[2]->dst_addr = dest_eth_addr[dst_port[2]];
+ *(uint64_t *)ð_hdr[3]->dst_addr = dest_eth_addr[dst_port[3]];
+ *(uint64_t *)ð_hdr[4]->dst_addr = dest_eth_addr[dst_port[4]];
+ *(uint64_t *)ð_hdr[5]->dst_addr = dest_eth_addr[dst_port[5]];
+ *(uint64_t *)ð_hdr[6]->dst_addr = dest_eth_addr[dst_port[6]];
+ *(uint64_t *)ð_hdr[7]->dst_addr = dest_eth_addr[dst_port[7]];
/* src addr */
- rte_ether_addr_copy(&ports_eth_addr[dst_port[0]], ð_hdr[0]->s_addr);
- rte_ether_addr_copy(&ports_eth_addr[dst_port[1]], ð_hdr[1]->s_addr);
- rte_ether_addr_copy(&ports_eth_addr[dst_port[2]], ð_hdr[2]->s_addr);
- rte_ether_addr_copy(&ports_eth_addr[dst_port[3]], ð_hdr[3]->s_addr);
- rte_ether_addr_copy(&ports_eth_addr[dst_port[4]], ð_hdr[4]->s_addr);
- rte_ether_addr_copy(&ports_eth_addr[dst_port[5]], ð_hdr[5]->s_addr);
- rte_ether_addr_copy(&ports_eth_addr[dst_port[6]], ð_hdr[6]->s_addr);
- rte_ether_addr_copy(&ports_eth_addr[dst_port[7]], ð_hdr[7]->s_addr);
+ rte_ether_addr_copy(&ports_eth_addr[dst_port[0]], ð_hdr[0]->src_addr);
+ rte_ether_addr_copy(&ports_eth_addr[dst_port[1]], ð_hdr[1]->src_addr);
+ rte_ether_addr_copy(&ports_eth_addr[dst_port[2]], ð_hdr[2]->src_addr);
+ rte_ether_addr_copy(&ports_eth_addr[dst_port[3]], ð_hdr[3]->src_addr);
+ rte_ether_addr_copy(&ports_eth_addr[dst_port[4]], ð_hdr[4]->src_addr);
+ rte_ether_addr_copy(&ports_eth_addr[dst_port[5]], ð_hdr[5]->src_addr);
+ rte_ether_addr_copy(&ports_eth_addr[dst_port[6]], ð_hdr[6]->src_addr);
+ rte_ether_addr_copy(&ports_eth_addr[dst_port[7]], ð_hdr[7]->src_addr);
send_single_packet(m[0], (uint8_t)dst_port[0]);
send_single_packet(m[1], (uint8_t)dst_port[1]);
@@ -1203,24 +1203,24 @@ simple_ipv6_fwd_8pkts(struct rte_mbuf *m[8], uint16_t portid)
dst_port[7] = portid;
/* dst addr */
- *(uint64_t *)ð_hdr[0]->d_addr = dest_eth_addr[dst_port[0]];
- *(uint64_t *)ð_hdr[1]->d_addr = dest_eth_addr[dst_port[1]];
- *(uint64_t *)ð_hdr[2]->d_addr = dest_eth_addr[dst_port[2]];
- *(uint64_t *)ð_hdr[3]->d_addr = dest_eth_addr[dst_port[3]];
- *(uint64_t *)ð_hdr[4]->d_addr = dest_eth_addr[dst_port[4]];
- *(uint64_t *)ð_hdr[5]->d_addr = dest_eth_addr[dst_port[5]];
- *(uint64_t *)ð_hdr[6]->d_addr = dest_eth_addr[dst_port[6]];
- *(uint64_t *)ð_hdr[7]->d_addr = dest_eth_addr[dst_port[7]];
+ *(uint64_t *)ð_hdr[0]->dst_addr = dest_eth_addr[dst_port[0]];
+ *(uint64_t *)ð_hdr[1]->dst_addr = dest_eth_addr[dst_port[1]];
+ *(uint64_t *)ð_hdr[2]->dst_addr = dest_eth_addr[dst_port[2]];
+ *(uint64_t *)ð_hdr[3]->dst_addr = dest_eth_addr[dst_port[3]];
+ *(uint64_t *)ð_hdr[4]->dst_addr = dest_eth_addr[dst_port[4]];
+ *(uint64_t *)ð_hdr[5]->dst_addr = dest_eth_addr[dst_port[5]];
+ *(uint64_t *)ð_hdr[6]->dst_addr = dest_eth_addr[dst_port[6]];
+ *(uint64_t *)ð_hdr[7]->dst_addr = dest_eth_addr[dst_port[7]];
/* src addr */
- rte_ether_addr_copy(&ports_eth_addr[dst_port[0]], ð_hdr[0]->s_addr);
- rte_ether_addr_copy(&ports_eth_addr[dst_port[1]], ð_hdr[1]->s_addr);
- rte_ether_addr_copy(&ports_eth_addr[dst_port[2]], ð_hdr[2]->s_addr);
- rte_ether_addr_copy(&ports_eth_addr[dst_port[3]], ð_hdr[3]->s_addr);
- rte_ether_addr_copy(&ports_eth_addr[dst_port[4]], ð_hdr[4]->s_addr);
- rte_ether_addr_copy(&ports_eth_addr[dst_port[5]], ð_hdr[5]->s_addr);
- rte_ether_addr_copy(&ports_eth_addr[dst_port[6]], ð_hdr[6]->s_addr);
- rte_ether_addr_copy(&ports_eth_addr[dst_port[7]], ð_hdr[7]->s_addr);
+ rte_ether_addr_copy(&ports_eth_addr[dst_port[0]], ð_hdr[0]->src_addr);
+ rte_ether_addr_copy(&ports_eth_addr[dst_port[1]], ð_hdr[1]->src_addr);
+ rte_ether_addr_copy(&ports_eth_addr[dst_port[2]], ð_hdr[2]->src_addr);
+ rte_ether_addr_copy(&ports_eth_addr[dst_port[3]], ð_hdr[3]->src_addr);
+ rte_ether_addr_copy(&ports_eth_addr[dst_port[4]], ð_hdr[4]->src_addr);
+ rte_ether_addr_copy(&ports_eth_addr[dst_port[5]], ð_hdr[5]->src_addr);
+ rte_ether_addr_copy(&ports_eth_addr[dst_port[6]], ð_hdr[6]->src_addr);
+ rte_ether_addr_copy(&ports_eth_addr[dst_port[7]], ð_hdr[7]->src_addr);
send_single_packet(m[0], dst_port[0]);
send_single_packet(m[1], dst_port[1]);
@@ -1268,11 +1268,11 @@ l3fwd_simple_forward(struct rte_mbuf *m, uint16_t portid)
++(ipv4_hdr->hdr_checksum);
#endif
/* dst addr */
- *(uint64_t *)ð_hdr->d_addr = dest_eth_addr[dst_port];
+ *(uint64_t *)ð_hdr->dst_addr = dest_eth_addr[dst_port];
/* src addr */
rte_ether_addr_copy(&ports_eth_addr[dst_port],
- ð_hdr->s_addr);
+ ð_hdr->src_addr);
send_single_packet(m, dst_port);
} else if (RTE_ETH_IS_IPV6_HDR(m->packet_type)) {
@@ -1290,11 +1290,11 @@ l3fwd_simple_forward(struct rte_mbuf *m, uint16_t portid)
dst_port = portid;
/* dst addr */
- *(uint64_t *)ð_hdr->d_addr = dest_eth_addr[dst_port];
+ *(uint64_t *)ð_hdr->dst_addr = dest_eth_addr[dst_port];
/* src addr */
rte_ether_addr_copy(&ports_eth_addr[dst_port],
- ð_hdr->s_addr);
+ ð_hdr->src_addr);
send_single_packet(m, dst_port);
} else
diff --git a/examples/ptpclient/ptpclient.c b/examples/ptpclient/ptpclient.c
index 4f32ade7fb..61e4ee0ea1 100644
--- a/examples/ptpclient/ptpclient.c
+++ b/examples/ptpclient/ptpclient.c
@@ -426,10 +426,10 @@ parse_fup(struct ptpv2_data_slave_ordinary *ptp_data)
created_pkt->data_len = pkt_size;
created_pkt->pkt_len = pkt_size;
eth_hdr = rte_pktmbuf_mtod(created_pkt, struct rte_ether_hdr *);
- rte_ether_addr_copy(ð_addr, ð_hdr->s_addr);
+ rte_ether_addr_copy(ð_addr, ð_hdr->src_addr);
/* Set multicast address 01-1B-19-00-00-00. */
- rte_ether_addr_copy(ð_multicast, ð_hdr->d_addr);
+ rte_ether_addr_copy(ð_multicast, ð_hdr->dst_addr);
eth_hdr->ether_type = htons(PTP_PROTOCOL);
ptp_msg = (struct ptp_message *)
@@ -449,14 +449,14 @@ parse_fup(struct ptpv2_data_slave_ordinary *ptp_data)
client_clkid =
&ptp_msg->delay_req.hdr.source_port_id.clock_id;
- client_clkid->id[0] = eth_hdr->s_addr.addr_bytes[0];
- client_clkid->id[1] = eth_hdr->s_addr.addr_bytes[1];
- client_clkid->id[2] = eth_hdr->s_addr.addr_bytes[2];
+ client_clkid->id[0] = eth_hdr->src_addr.addr_bytes[0];
+ client_clkid->id[1] = eth_hdr->src_addr.addr_bytes[1];
+ client_clkid->id[2] = eth_hdr->src_addr.addr_bytes[2];
client_clkid->id[3] = 0xFF;
client_clkid->id[4] = 0xFE;
- client_clkid->id[5] = eth_hdr->s_addr.addr_bytes[3];
- client_clkid->id[6] = eth_hdr->s_addr.addr_bytes[4];
- client_clkid->id[7] = eth_hdr->s_addr.addr_bytes[5];
+ client_clkid->id[5] = eth_hdr->src_addr.addr_bytes[3];
+ client_clkid->id[6] = eth_hdr->src_addr.addr_bytes[4];
+ client_clkid->id[7] = eth_hdr->src_addr.addr_bytes[5];
rte_memcpy(&ptp_data->client_clock_id,
client_clkid,
diff --git a/examples/vhost/main.c b/examples/vhost/main.c
index d0bf1f31e3..b24fd82a6e 100644
--- a/examples/vhost/main.c
+++ b/examples/vhost/main.c
@@ -757,7 +757,7 @@ link_vmdq(struct vhost_dev *vdev, struct rte_mbuf *m)
/* Learn MAC address of guest device from packet */
pkt_hdr = rte_pktmbuf_mtod(m, struct rte_ether_hdr *);
- if (find_vhost_dev(&pkt_hdr->s_addr)) {
+ if (find_vhost_dev(&pkt_hdr->src_addr)) {
RTE_LOG(ERR, VHOST_DATA,
"(%d) device is using a registered MAC!\n",
vdev->vid);
@@ -765,7 +765,8 @@ link_vmdq(struct vhost_dev *vdev, struct rte_mbuf *m)
}
for (i = 0; i < RTE_ETHER_ADDR_LEN; i++)
- vdev->mac_address.addr_bytes[i] = pkt_hdr->s_addr.addr_bytes[i];
+ vdev->mac_address.addr_bytes[i] =
+ pkt_hdr->src_addr.addr_bytes[i];
/* vlan_tag currently uses the device_id. */
vdev->vlan_tag = vlan_tags[vdev->vid];
@@ -945,7 +946,7 @@ virtio_tx_local(struct vhost_dev *vdev, struct rte_mbuf *m)
uint16_t lcore_id = rte_lcore_id();
pkt_hdr = rte_pktmbuf_mtod(m, struct rte_ether_hdr *);
- dst_vdev = find_vhost_dev(&pkt_hdr->d_addr);
+ dst_vdev = find_vhost_dev(&pkt_hdr->dst_addr);
if (!dst_vdev)
return -1;
@@ -993,7 +994,7 @@ find_local_dest(struct vhost_dev *vdev, struct rte_mbuf *m,
struct rte_ether_hdr *pkt_hdr =
rte_pktmbuf_mtod(m, struct rte_ether_hdr *);
- dst_vdev = find_vhost_dev(&pkt_hdr->d_addr);
+ dst_vdev = find_vhost_dev(&pkt_hdr->dst_addr);
if (!dst_vdev)
return 0;
@@ -1076,7 +1077,7 @@ virtio_tx_route(struct vhost_dev *vdev, struct rte_mbuf *m, uint16_t vlan_tag)
nh = rte_pktmbuf_mtod(m, struct rte_ether_hdr *);
- if (unlikely(rte_is_broadcast_ether_addr(&nh->d_addr))) {
+ if (unlikely(rte_is_broadcast_ether_addr(&nh->dst_addr))) {
struct vhost_dev *vdev2;
TAILQ_FOREACH(vdev2, &vhost_dev_list, global_vdev_entry) {
diff --git a/examples/vmdq/main.c b/examples/vmdq/main.c
index 755dcafa2f..ee7f4324e1 100644
--- a/examples/vmdq/main.c
+++ b/examples/vmdq/main.c
@@ -461,11 +461,11 @@ update_mac_address(struct rte_mbuf *m, unsigned dst_port)
eth = rte_pktmbuf_mtod(m, struct rte_ether_hdr *);
/* 02:00:00:00:00:xx */
- tmp = ð->d_addr.addr_bytes[0];
+ tmp = ð->dst_addr.addr_bytes[0];
*((uint64_t *)tmp) = 0x000000000002 + ((uint64_t)dst_port << 40);
/* src addr */
- rte_ether_addr_copy(&vmdq_ports_eth_addr[dst_port], ð->s_addr);
+ rte_ether_addr_copy(&vmdq_ports_eth_addr[dst_port], ð->src_addr);
}
/* When we receive a HUP signal, print out our stats */
diff --git a/examples/vmdq_dcb/main.c b/examples/vmdq_dcb/main.c
index 6d3c918d6d..14c20e6a8b 100644
--- a/examples/vmdq_dcb/main.c
+++ b/examples/vmdq_dcb/main.c
@@ -512,11 +512,11 @@ update_mac_address(struct rte_mbuf *m, unsigned dst_port)
eth = rte_pktmbuf_mtod(m, struct rte_ether_hdr *);
/* 02:00:00:00:00:xx */
- tmp = ð->d_addr.addr_bytes[0];
+ tmp = ð->dst_addr.addr_bytes[0];
*((uint64_t *)tmp) = 0x000000000002 + ((uint64_t)dst_port << 40);
/* src addr */
- rte_ether_addr_copy(&vmdq_ports_eth_addr[dst_port], ð->s_addr);
+ rte_ether_addr_copy(&vmdq_ports_eth_addr[dst_port], ð->src_addr);
}
/* When we receive a HUP signal, print out our stats */
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 7b1ed7f110..a89945061a 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -785,8 +785,8 @@ struct rte_flow_item_eth {
/** Default mask for RTE_FLOW_ITEM_TYPE_ETH. */
#ifndef __cplusplus
static const struct rte_flow_item_eth rte_flow_item_eth_mask = {
- .hdr.d_addr.addr_bytes = "\xff\xff\xff\xff\xff\xff",
- .hdr.s_addr.addr_bytes = "\xff\xff\xff\xff\xff\xff",
+ .hdr.dst_addr.addr_bytes = "\xff\xff\xff\xff\xff\xff",
+ .hdr.src_addr.addr_bytes = "\xff\xff\xff\xff\xff\xff",
.hdr.ether_type = RTE_BE16(0x0000),
};
#endif
diff --git a/lib/gro/gro_tcp4.c b/lib/gro/gro_tcp4.c
index feb5855144..aff22178e3 100644
--- a/lib/gro/gro_tcp4.c
+++ b/lib/gro/gro_tcp4.c
@@ -243,8 +243,8 @@ gro_tcp4_reassemble(struct rte_mbuf *pkt,
ip_id = is_atomic ? 0 : rte_be_to_cpu_16(ipv4_hdr->packet_id);
sent_seq = rte_be_to_cpu_32(tcp_hdr->sent_seq);
- rte_ether_addr_copy(&(eth_hdr->s_addr), &(key.eth_saddr));
- rte_ether_addr_copy(&(eth_hdr->d_addr), &(key.eth_daddr));
+ rte_ether_addr_copy(&(eth_hdr->src_addr), &(key.eth_saddr));
+ rte_ether_addr_copy(&(eth_hdr->dst_addr), &(key.eth_daddr));
key.ip_src_addr = ipv4_hdr->src_addr;
key.ip_dst_addr = ipv4_hdr->dst_addr;
key.src_port = tcp_hdr->src_port;
diff --git a/lib/gro/gro_udp4.c b/lib/gro/gro_udp4.c
index b8301296df..e78dda7874 100644
--- a/lib/gro/gro_udp4.c
+++ b/lib/gro/gro_udp4.c
@@ -238,8 +238,8 @@ gro_udp4_reassemble(struct rte_mbuf *pkt,
is_last_frag = ((frag_offset & RTE_IPV4_HDR_MF_FLAG) == 0) ? 1 : 0;
frag_offset = (uint16_t)(frag_offset & RTE_IPV4_HDR_OFFSET_MASK) << 3;
- rte_ether_addr_copy(&(eth_hdr->s_addr), &(key.eth_saddr));
- rte_ether_addr_copy(&(eth_hdr->d_addr), &(key.eth_daddr));
+ rte_ether_addr_copy(&(eth_hdr->src_addr), &(key.eth_saddr));
+ rte_ether_addr_copy(&(eth_hdr->dst_addr), &(key.eth_daddr));
key.ip_src_addr = ipv4_hdr->src_addr;
key.ip_dst_addr = ipv4_hdr->dst_addr;
key.ip_id = ip_id;
diff --git a/lib/gro/gro_vxlan_tcp4.c b/lib/gro/gro_vxlan_tcp4.c
index f3b6e603b9..2005899afe 100644
--- a/lib/gro/gro_vxlan_tcp4.c
+++ b/lib/gro/gro_vxlan_tcp4.c
@@ -358,8 +358,8 @@ gro_vxlan_tcp4_reassemble(struct rte_mbuf *pkt,
sent_seq = rte_be_to_cpu_32(tcp_hdr->sent_seq);
- rte_ether_addr_copy(&(eth_hdr->s_addr), &(key.inner_key.eth_saddr));
- rte_ether_addr_copy(&(eth_hdr->d_addr), &(key.inner_key.eth_daddr));
+ rte_ether_addr_copy(&(eth_hdr->src_addr), &(key.inner_key.eth_saddr));
+ rte_ether_addr_copy(&(eth_hdr->dst_addr), &(key.inner_key.eth_daddr));
key.inner_key.ip_src_addr = ipv4_hdr->src_addr;
key.inner_key.ip_dst_addr = ipv4_hdr->dst_addr;
key.inner_key.recv_ack = tcp_hdr->recv_ack;
@@ -368,8 +368,8 @@ gro_vxlan_tcp4_reassemble(struct rte_mbuf *pkt,
key.vxlan_hdr.vx_flags = vxlan_hdr->vx_flags;
key.vxlan_hdr.vx_vni = vxlan_hdr->vx_vni;
- rte_ether_addr_copy(&(outer_eth_hdr->s_addr), &(key.outer_eth_saddr));
- rte_ether_addr_copy(&(outer_eth_hdr->d_addr), &(key.outer_eth_daddr));
+ rte_ether_addr_copy(&(outer_eth_hdr->src_addr), &(key.outer_eth_saddr));
+ rte_ether_addr_copy(&(outer_eth_hdr->dst_addr), &(key.outer_eth_daddr));
key.outer_ip_src_addr = outer_ipv4_hdr->src_addr;
key.outer_ip_dst_addr = outer_ipv4_hdr->dst_addr;
key.outer_src_port = udp_hdr->src_port;
diff --git a/lib/gro/gro_vxlan_udp4.c b/lib/gro/gro_vxlan_udp4.c
index 37476361d5..4767c910bb 100644
--- a/lib/gro/gro_vxlan_udp4.c
+++ b/lib/gro/gro_vxlan_udp4.c
@@ -338,16 +338,16 @@ gro_vxlan_udp4_reassemble(struct rte_mbuf *pkt,
is_last_frag = ((frag_offset & RTE_IPV4_HDR_MF_FLAG) == 0) ? 1 : 0;
frag_offset = (uint16_t)(frag_offset & RTE_IPV4_HDR_OFFSET_MASK) << 3;
- rte_ether_addr_copy(&(eth_hdr->s_addr), &(key.inner_key.eth_saddr));
- rte_ether_addr_copy(&(eth_hdr->d_addr), &(key.inner_key.eth_daddr));
+ rte_ether_addr_copy(&(eth_hdr->src_addr), &(key.inner_key.eth_saddr));
+ rte_ether_addr_copy(&(eth_hdr->dst_addr), &(key.inner_key.eth_daddr));
key.inner_key.ip_src_addr = ipv4_hdr->src_addr;
key.inner_key.ip_dst_addr = ipv4_hdr->dst_addr;
key.inner_key.ip_id = ip_id;
key.vxlan_hdr.vx_flags = vxlan_hdr->vx_flags;
key.vxlan_hdr.vx_vni = vxlan_hdr->vx_vni;
- rte_ether_addr_copy(&(outer_eth_hdr->s_addr), &(key.outer_eth_saddr));
- rte_ether_addr_copy(&(outer_eth_hdr->d_addr), &(key.outer_eth_daddr));
+ rte_ether_addr_copy(&(outer_eth_hdr->src_addr), &(key.outer_eth_saddr));
+ rte_ether_addr_copy(&(outer_eth_hdr->dst_addr), &(key.outer_eth_daddr));
key.outer_ip_src_addr = outer_ipv4_hdr->src_addr;
key.outer_ip_dst_addr = outer_ipv4_hdr->dst_addr;
/* Note: It is unnecessary to save outer_src_port here because it can
diff --git a/lib/net/rte_arp.c b/lib/net/rte_arp.c
index 5c1e27b8c0..9f7eb6b375 100644
--- a/lib/net/rte_arp.c
+++ b/lib/net/rte_arp.c
@@ -29,8 +29,8 @@ rte_net_make_rarp_packet(struct rte_mempool *mpool,
}
/* Ethernet header. */
- memset(eth_hdr->d_addr.addr_bytes, 0xff, RTE_ETHER_ADDR_LEN);
- rte_ether_addr_copy(mac, ð_hdr->s_addr);
+ memset(eth_hdr->dst_addr.addr_bytes, 0xff, RTE_ETHER_ADDR_LEN);
+ rte_ether_addr_copy(mac, ð_hdr->src_addr);
eth_hdr->ether_type = RTE_BE16(RTE_ETHER_TYPE_RARP);
/* RARP header. */
diff --git a/lib/net/rte_ether.h b/lib/net/rte_ether.h
index 5f38b41dd4..b83e0d3fce 100644
--- a/lib/net/rte_ether.h
+++ b/lib/net/rte_ether.h
@@ -266,34 +266,16 @@ rte_ether_format_addr(char *buf, uint16_t size,
int
rte_ether_unformat_addr(const char *str, struct rte_ether_addr *eth_addr);
-/* Windows Sockets headers contain `#define s_addr S_un.S_addr`.
- * Temporarily disable this macro to avoid conflict at definition.
- * Place source MAC address in both `s_addr` and `S_un.S_addr` fields,
- * so that access works either directly or through the macro.
- */
-#pragma push_macro("s_addr")
-#ifdef s_addr
-#undef s_addr
-#endif
-
/**
* Ethernet header: Contains the destination address, source address
* and frame type.
*/
struct rte_ether_hdr {
- struct rte_ether_addr d_addr; /**< Destination address. */
- RTE_STD_C11
- union {
- struct rte_ether_addr s_addr; /**< Source address. */
- struct {
- struct rte_ether_addr S_addr;
- } S_un; /**< Do not use directly; use s_addr instead.*/
- };
+ struct rte_ether_addr dst_addr; /**< Destination address. */
+ struct rte_ether_addr src_addr; /**< Source address. */
rte_be16_t ether_type; /**< Frame type. */
} __rte_aligned(2);
-#pragma pop_macro("s_addr")
-
/**
* Ethernet VLAN Header.
* Contains the 16-bit VLAN Tag Control Identifier and the Ethernet type
diff --git a/lib/pipeline/rte_table_action.c b/lib/pipeline/rte_table_action.c
index ad7904c0ee..4b0316bfed 100644
--- a/lib/pipeline/rte_table_action.c
+++ b/lib/pipeline/rte_table_action.c
@@ -615,8 +615,8 @@ encap_ether_apply(void *data,
RTE_ETHER_TYPE_IPV6;
/* Ethernet */
- rte_ether_addr_copy(&p->ether.ether.da, &d->ether.d_addr);
- rte_ether_addr_copy(&p->ether.ether.sa, &d->ether.s_addr);
+ rte_ether_addr_copy(&p->ether.ether.da, &d->ether.dst_addr);
+ rte_ether_addr_copy(&p->ether.ether.sa, &d->ether.src_addr);
d->ether.ether_type = rte_htons(ethertype);
return 0;
@@ -633,8 +633,8 @@ encap_vlan_apply(void *data,
RTE_ETHER_TYPE_IPV6;
/* Ethernet */
- rte_ether_addr_copy(&p->vlan.ether.da, &d->ether.d_addr);
- rte_ether_addr_copy(&p->vlan.ether.sa, &d->ether.s_addr);
+ rte_ether_addr_copy(&p->vlan.ether.da, &d->ether.dst_addr);
+ rte_ether_addr_copy(&p->vlan.ether.sa, &d->ether.src_addr);
d->ether.ether_type = rte_htons(RTE_ETHER_TYPE_VLAN);
/* VLAN */
@@ -657,8 +657,8 @@ encap_qinq_apply(void *data,
RTE_ETHER_TYPE_IPV6;
/* Ethernet */
- rte_ether_addr_copy(&p->qinq.ether.da, &d->ether.d_addr);
- rte_ether_addr_copy(&p->qinq.ether.sa, &d->ether.s_addr);
+ rte_ether_addr_copy(&p->qinq.ether.da, &d->ether.dst_addr);
+ rte_ether_addr_copy(&p->qinq.ether.sa, &d->ether.src_addr);
d->ether.ether_type = rte_htons(RTE_ETHER_TYPE_QINQ);
/* SVLAN */
@@ -683,8 +683,8 @@ encap_qinq_pppoe_apply(void *data,
struct encap_qinq_pppoe_data *d = data;
/* Ethernet */
- rte_ether_addr_copy(&p->qinq.ether.da, &d->ether.d_addr);
- rte_ether_addr_copy(&p->qinq.ether.sa, &d->ether.s_addr);
+ rte_ether_addr_copy(&p->qinq.ether.da, &d->ether.dst_addr);
+ rte_ether_addr_copy(&p->qinq.ether.sa, &d->ether.src_addr);
d->ether.ether_type = rte_htons(RTE_ETHER_TYPE_VLAN);
/* SVLAN */
@@ -719,8 +719,8 @@ encap_mpls_apply(void *data,
uint32_t i;
/* Ethernet */
- rte_ether_addr_copy(&p->mpls.ether.da, &d->ether.d_addr);
- rte_ether_addr_copy(&p->mpls.ether.sa, &d->ether.s_addr);
+ rte_ether_addr_copy(&p->mpls.ether.da, &d->ether.dst_addr);
+ rte_ether_addr_copy(&p->mpls.ether.sa, &d->ether.src_addr);
d->ether.ether_type = rte_htons(ethertype);
/* MPLS */
@@ -746,8 +746,8 @@ encap_pppoe_apply(void *data,
struct encap_pppoe_data *d = data;
/* Ethernet */
- rte_ether_addr_copy(&p->pppoe.ether.da, &d->ether.d_addr);
- rte_ether_addr_copy(&p->pppoe.ether.sa, &d->ether.s_addr);
+ rte_ether_addr_copy(&p->pppoe.ether.da, &d->ether.dst_addr);
+ rte_ether_addr_copy(&p->pppoe.ether.sa, &d->ether.src_addr);
d->ether.ether_type = rte_htons(RTE_ETHER_TYPE_PPPOE_SESSION);
/* PPPoE and PPP*/
@@ -777,9 +777,9 @@ encap_vxlan_apply(void *data,
/* Ethernet */
rte_ether_addr_copy(&p->vxlan.ether.da,
- &d->ether.d_addr);
+ &d->ether.dst_addr);
rte_ether_addr_copy(&p->vxlan.ether.sa,
- &d->ether.s_addr);
+ &d->ether.src_addr);
d->ether.ether_type = rte_htons(RTE_ETHER_TYPE_VLAN);
/* VLAN */
@@ -818,9 +818,9 @@ encap_vxlan_apply(void *data,
/* Ethernet */
rte_ether_addr_copy(&p->vxlan.ether.da,
- &d->ether.d_addr);
+ &d->ether.dst_addr);
rte_ether_addr_copy(&p->vxlan.ether.sa,
- &d->ether.s_addr);
+ &d->ether.src_addr);
d->ether.ether_type = rte_htons(RTE_ETHER_TYPE_IPV4);
/* IPv4*/
@@ -855,9 +855,9 @@ encap_vxlan_apply(void *data,
/* Ethernet */
rte_ether_addr_copy(&p->vxlan.ether.da,
- &d->ether.d_addr);
+ &d->ether.dst_addr);
rte_ether_addr_copy(&p->vxlan.ether.sa,
- &d->ether.s_addr);
+ &d->ether.src_addr);
d->ether.ether_type = rte_htons(RTE_ETHER_TYPE_VLAN);
/* VLAN */
@@ -896,9 +896,9 @@ encap_vxlan_apply(void *data,
/* Ethernet */
rte_ether_addr_copy(&p->vxlan.ether.da,
- &d->ether.d_addr);
+ &d->ether.dst_addr);
rte_ether_addr_copy(&p->vxlan.ether.sa,
- &d->ether.s_addr);
+ &d->ether.src_addr);
d->ether.ether_type = rte_htons(RTE_ETHER_TYPE_IPV6);
/* IPv6*/
--
2.29.3
^ permalink raw reply [relevance 1%]
* Re: [dpdk-dev] [EXT] [PATCH v9] bbdev: add device info related to data endianness assumption
@ 2021-10-07 18:58 0% ` Chautru, Nicolas
2021-10-08 4:34 0% ` Nipun Gupta
0 siblings, 1 reply; 200+ results
From: Chautru, Nicolas @ 2021-10-07 18:58 UTC (permalink / raw)
To: Nipun Gupta, Akhil Goyal, dev, trix
Cc: thomas, Zhang, Mingshan, Joshi, Arun, Hemant Agrawal, david.marchand
Hi Nipun,
> -----Original Message-----
> From: Nipun Gupta <nipun.gupta@nxp.com>
> Sent: Thursday, October 7, 2021 9:49 AM
> To: Chautru, Nicolas <nicolas.chautru@intel.com>; Akhil Goyal
> <gakhil@marvell.com>; dev@dpdk.org; trix@redhat.com
> Cc: thomas@monjalon.net; Zhang, Mingshan <mingshan.zhang@intel.com>;
> Joshi, Arun <arun.joshi@intel.com>; Hemant Agrawal
> <hemant.agrawal@nxp.com>; david.marchand@redhat.com
> Subject: RE: [EXT] [PATCH v9] bbdev: add device info related to data
> endianness assumption
>
>
>
> > -----Original Message-----
> > From: Chautru, Nicolas <nicolas.chautru@intel.com>
> > Sent: Thursday, October 7, 2021 9:12 PM
> > To: Akhil Goyal <gakhil@marvell.com>; dev@dpdk.org; Nipun Gupta
> > <nipun.gupta@nxp.com>; trix@redhat.com
> > Cc: thomas@monjalon.net; Zhang, Mingshan
> <mingshan.zhang@intel.com>;
> > Joshi, Arun <arun.joshi@intel.com>; Hemant Agrawal
> > <hemant.agrawal@nxp.com>; david.marchand@redhat.com
> > Subject: RE: [EXT] [PATCH v9] bbdev: add device info related to data
> > endianness assumption
> >
> > Hi Akhil,
> >
> >
> > > -----Original Message-----
> > > From: Akhil Goyal <gakhil@marvell.com>
> > > Sent: Thursday, October 7, 2021 6:14 AM
> > > To: Chautru, Nicolas <nicolas.chautru@intel.com>; dev@dpdk.org;
> > > nipun.gupta@nxp.com; trix@redhat.com
> > > Cc: thomas@monjalon.net; Zhang, Mingshan
> <mingshan.zhang@intel.com>;
> > > Joshi, Arun <arun.joshi@intel.com>; hemant.agrawal@nxp.com;
> > > david.marchand@redhat.com
> > > Subject: RE: [EXT] [PATCH v9] bbdev: add device info related to data
> > > endianness assumption
> > >
> > > > Subject: [EXT] [PATCH v9] bbdev: add device info related to data
> > > > endianness assumption
> > > >
> > > Title is too long.
> > > bbdev: add dev info for data endianness
> >
> > OK
> >
> > >
> > > > Adding device information to capture explicitly the assumption of
> > > > the input/output data byte endianness being processed.
> > > >
> > > > Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
> > > > ---
> > > > doc/guides/rel_notes/release_21_11.rst | 1 +
> > > > drivers/baseband/acc100/rte_acc100_pmd.c | 1 +
> > > > drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c | 1 +
> > > > drivers/baseband/fpga_lte_fec/fpga_lte_fec.c | 1 +
> > > > drivers/baseband/turbo_sw/bbdev_turbo_software.c | 1 +
> > > > lib/bbdev/rte_bbdev.h | 8 ++++++++
> > > > 6 files changed, 13 insertions(+)
> > > >
> > > > diff --git a/doc/guides/rel_notes/release_21_11.rst
> > > > b/doc/guides/rel_notes/release_21_11.rst
> > > > index a8900a3..f0b3006 100644
> > > > --- a/doc/guides/rel_notes/release_21_11.rst
> > > > +++ b/doc/guides/rel_notes/release_21_11.rst
> > > > @@ -191,6 +191,7 @@ API Changes
> > > >
> > > > * bbdev: Added capability related to more comprehensive CRC
> options.
> > > >
> > > > +* bbdev: Added device info related to data byte endianness
> > > > +processing
> > > > assumption.
> > >
> > > It is not clear from the description or the release notes, what the
> > > application is supposed to do based on the new dev_info field set
> > > and how the driver determine what value to set?
> > > Isn't there a standard from the application stand point that the
> > > input/output data Should be in BE or in LE like in case of IP packets which
> are always in BE?
> > > I mean why is it dependent on the PMD which is processing it?
> > > Whatever application understands, PMD should comply with that and do
> > > internal Swapping if it does not support it.
> > > Am I missing something?
> >
> > This is really to allow Nipin to add his own NXP la12xx PMD, which
> > appears to have different assumption on endianness.
> > All existing processing is done in LE by default by the existing PMDs
> > and the existing ecosystem.
> > I cannot comment on why they would want to do that for the la12xx
> > specifically, I could only speculate but here trying to help to find
> > the best way for the new PMD to be supported.
> > So here this suggested change is purely about exposing different
> > assumption for the PMDs, so that this new PMD can still be supported
> > under this API even though this is in effect incompatible with existing
> ecosystem.
> > In case the application has different assumption that what the PMD
> > does, then byte swapping would have to be done in the application,
> > more likely I assume that la12xx has its own ecosystem with different
> > endianness required for other reasons.
> > The option you are suggesting would be to put the burden on the PMD
> > but I doubt there is an actual usecase for that. I assume they assume
> > different endianness for other specific reason, not necessary to be
> > compatible with existing ecosystem.
> > Niping, Hemant, feel free to comment back, from previous discussion I
> > believe this is what you wanted to do. Unsure of the reason, feel free
> > to share more details or not.
>
> Akhil/Nicolas,
>
> As Hemant mentioned on v4 (previously asked by Dave)
>
> "---
> If we go back to the data providing source i.e. FAPI interface, it is
> implementation specific, as per SCF222.
>
> Our customers do use BE data in network and at FAPI interface.
>
> In LA12xx, at present, we use u8 Big-endian data for processing to FECA
> engine. We do see that other drivers in DPDK are using Little Endian *(with
> u32 data)* but standards is open for both.
> "---
>
> Standard is not specific to endianness and is open for implementation.
> So it does not makes a reason to have one endianness as default and other
> managed in the PMD, and the current change seems right.
>
> Yes endianness assumption is taken in the test vector input/output data, but
> this should be acceptable as it does not impact the PMD's and end user
> applications in general.
I want clarify that this would impact the application in case user wanted to switch between 2 such hw accelator.
Ie. you cannot switch the 2 solutions, they are incompatible except if you explicitly do the byteswap in the application (as is done in bbdev-test).
Not necessarily a problem in case they address 2 different ecosystems but capturing the implication to be explicit. Ie each device expose the assumptions expected by the application and it is up to the application the bbdev api to satisfy the relared assumptions.
>
> BTW Nicolos, my name is Nipun :)
My bad!
I am marking this patch as obsolete since you have included it in your serie.
>
> >
> >
> > >
> > > >
> > > > ABI Changes
> > > > -----------
> > > > diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
> > > > b/drivers/baseband/acc100/rte_acc100_pmd.c
> > > > index 4e2feef..eb2c6c1 100644
> > > > --- a/drivers/baseband/acc100/rte_acc100_pmd.c
> > > > +++ b/drivers/baseband/acc100/rte_acc100_pmd.c
> > > > @@ -1089,6 +1089,7 @@
> > > > #else
> > > > dev_info->harq_buffer_size = 0;
> > > > #endif
> > > > + dev_info->data_endianness = RTE_BBDEV_LITTLE_ENDIAN;
> > > > acc100_check_ir(d);
> > > > }
> > > >
> > > > diff --git a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
> > > > b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
> > > > index 6485cc8..c7f15c0 100644
> > > > --- a/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
> > > > +++ b/drivers/baseband/fpga_5gnr_fec/rte_fpga_5gnr_fec.c
> > > > @@ -372,6 +372,7 @@
> > > > dev_info->default_queue_conf = default_queue_conf;
> > > > dev_info->capabilities = bbdev_capabilities;
> > > > dev_info->cpu_flag_reqs = NULL;
> > > > + dev_info->data_endianness = RTE_BBDEV_LITTLE_ENDIAN;
> > > >
> > > > /* Calculates number of queues assigned to device */
> > > > dev_info->max_num_queues = 0;
> > > > diff --git a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
> > > > b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
> > > > index 350c424..72e213e 100644
> > > > --- a/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
> > > > +++ b/drivers/baseband/fpga_lte_fec/fpga_lte_fec.c
> > > > @@ -644,6 +644,7 @@ struct __rte_cache_aligned fpga_queue {
> > > > dev_info->default_queue_conf = default_queue_conf;
> > > > dev_info->capabilities = bbdev_capabilities;
> > > > dev_info->cpu_flag_reqs = NULL;
> > > > + dev_info->data_endianness = RTE_BBDEV_LITTLE_ENDIAN;
> > > >
> > > > /* Calculates number of queues assigned to device */
> > > > dev_info->max_num_queues = 0;
> > > > diff --git a/drivers/baseband/turbo_sw/bbdev_turbo_software.c
> > > > b/drivers/baseband/turbo_sw/bbdev_turbo_software.c
> > > > index e1db2bf..0cab91a 100644
> > > > --- a/drivers/baseband/turbo_sw/bbdev_turbo_software.c
> > > > +++ b/drivers/baseband/turbo_sw/bbdev_turbo_software.c
> > > > @@ -253,6 +253,7 @@ struct turbo_sw_queue {
> > > > dev_info->capabilities = bbdev_capabilities;
> > > > dev_info->min_alignment = 64;
> > > > dev_info->harq_buffer_size = 0;
> > > > + dev_info->data_endianness = RTE_BBDEV_LITTLE_ENDIAN;
> > > >
> > > > rte_bbdev_log_debug("got device info from %u\n", dev->data-
> > > > >dev_id);
> > > > }
> > > > diff --git a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h index
> > > > 3ebf62e..b3f3000 100644
> > > > --- a/lib/bbdev/rte_bbdev.h
> > > > +++ b/lib/bbdev/rte_bbdev.h
> > > > @@ -49,6 +49,12 @@ enum rte_bbdev_state {
> > > > RTE_BBDEV_INITIALIZED
> > > > };
> > > >
> > > > +/** Definitions of device data byte endianness types */ enum
> > > > +rte_bbdev_endianness {
> > > > + RTE_BBDEV_BIG_ENDIAN, /**< Data with byte-endianness BE */
> > > > + RTE_BBDEV_LITTLE_ENDIAN, /**< Data with byte-endianness LE */ };
> > > If at all be need this dev_info field, as Tom suggested we should
> > > use RTE_BIG/LITTLE_ENDIAN.
> >
> > See separate comment on my reply to Tom:
> > I considered this but the usage is different, these are build time
> > #define, and really would bring confusion here.
> > Note that there are not really the endianness of the system itself but
> > specific to the bbdev data output going through signal processing.
> > I thought it was more explicit and less confusing this way, feel free
> > to comment back.
> > NXP would know best why a different endianness would be required in the
> PMD.
>
> Please see previous comment for endianness support.
> I agree with the RTE_ prefix we can add it as it is for the application interface.
>
> >
> > >
> > > > +
> > > > /**
> > > > * Get the total number of devices that have been successfully
> initialised.
> > > > *
> > > > @@ -309,6 +315,8 @@ struct rte_bbdev_driver_info {
> > > > uint16_t min_alignment;
> > > > /** HARQ memory available in kB */
> > > > uint32_t harq_buffer_size;
> > > > + /** Byte endianness assumption for input/output data */
> > > > + enum rte_bbdev_endianness data_endianness;
> > >
> > > We should define how the input and output data are expected from the
> app.
> > > If need be, we can define a simple ``bool swap`` instead of an enum.
> >
> > This could be done as well. Default no swap, and swap required for the
> > new PMD.
> > I will let Nipin/Hemant comment back.
>
> Again endianness is implementation specific and not standard for 5G
> processing, unlike it is for network packet.
>
> Regards,
> Nipun
>
> >
> > >
> > > > /** Default queue configuration used if none is supplied */
> > > > struct rte_bbdev_queue_conf default_queue_conf;
> > > > /** Device operation capabilities */
> > > > --
> > > > 1.8.3.1
^ permalink raw reply [relevance 0%]
Results 2801-3000 of ~18000 next (older) | prev (newer) | reverse | sort options + mbox downloads above
-- links below jump to the message on this page --
2021-03-18 6:34 [dpdk-dev] [PATCH 1/6] baseband: introduce NXP LA12xx driver Hemant Agrawal
2021-10-11 4:32 ` [dpdk-dev] [PATCH v10 0/8] baseband: add " nipun.gupta
2021-10-11 4:32 4% ` [dpdk-dev] [PATCH v10 1/8] bbdev: add device info related to data endianness nipun.gupta
2021-05-27 15:28 [dpdk-dev] [PATCH] net: introduce IPv4 ihl and version fields Gregory Etelson
2021-10-12 12:29 4% ` [dpdk-dev] [PATCH v5] " Gregory Etelson
2021-10-13 17:13 ` [dpdk-dev] [PATCH v6 0/2] " Gregory Etelson
2021-10-13 17:13 4% ` [dpdk-dev] [PATCH v6 2/2] " Gregory Etelson
2021-10-14 17:41 ` [dpdk-dev] [PATCH v7 0/2] " Gregory Etelson
2021-10-14 17:41 4% ` [dpdk-dev] [PATCH v7 2/2] " Gregory Etelson
2021-10-14 18:16 0% ` Ajit Khaparde
2021-06-01 1:56 [dpdk-dev] [PATCH v1 0/2] relative path support for ABI compatibility check Feifei Wang
2021-08-11 6:17 ` [dpdk-dev] [PATCH v2 0/1] " Feifei Wang
2021-08-11 6:17 ` [dpdk-dev] [PATCH v2 1/1] devtools: add " Feifei Wang
2021-10-15 10:02 4% ` [dpdk-dev] 回复: " Feifei Wang
2021-07-02 13:18 [dpdk-dev] [PATCH] dmadev: introduce DMA device library Chengwen Feng
2021-10-09 9:33 3% ` [dpdk-dev] [PATCH v24 0/6] support dmadev Chengwen Feng
2021-07-05 8:04 [dpdk-dev] [RFC PATCH v4 0/3] Add PIE support for HQoS library Liguzinski, WojciechX
2021-09-07 7:33 ` [dpdk-dev] [RFC PATCH v5 0/5] " Liguzinski, WojciechX
2021-09-07 7:33 ` [dpdk-dev] [RFC PATCH v5 1/5] sched: add PIE based congestion management Liguzinski, WojciechX
2021-09-07 19:14 ` Stephen Hemminger
2021-10-14 15:13 3% ` Liguzinski, WojciechX
2021-07-12 16:17 [dpdk-dev] [PATCH] ethdev: fix representor port ID search by name Andrew Rybchenko
2021-09-13 11:26 ` [dpdk-dev] [PATCH v5] " Andrew Rybchenko
2021-10-01 11:39 ` Andrew Rybchenko
2021-10-08 8:39 0% ` Xueming(Steven) Li
2021-10-08 9:27 4% ` [dpdk-dev] [PATCH v6] " Andrew Rybchenko
2021-10-11 12:30 4% ` [dpdk-dev] [PATCH v7] " Andrew Rybchenko
2021-10-11 12:53 4% ` [dpdk-dev] [PATCH v8] " Andrew Rybchenko
2021-07-13 13:35 [dpdk-dev] [PATCH 00/10] new features for ipsec and security libraries Radu Nicolau
2021-10-11 11:29 ` [dpdk-dev] [PATCH v8 " Radu Nicolau
2021-10-11 11:29 5% ` [dpdk-dev] [PATCH v8 01/10] security: add ESN field to ipsec_xform Radu Nicolau
2021-10-12 10:23 0% ` Ananyev, Konstantin
2021-10-11 11:29 5% ` [dpdk-dev] [PATCH v8 03/10] security: add UDP params for IPsec NAT-T Radu Nicolau
2021-10-12 10:24 0% ` Ananyev, Konstantin
2021-10-13 12:13 ` [dpdk-dev] [PATCH v9 00/10] new features for ipsec and security libraries Radu Nicolau
2021-10-13 12:13 5% ` [dpdk-dev] [PATCH v9 01/10] security: add ESN field to ipsec_xform Radu Nicolau
2021-10-13 12:13 5% ` [dpdk-dev] [PATCH v9 03/10] security: add UDP params for IPsec NAT-T Radu Nicolau
2021-10-14 16:03 ` [dpdk-dev] [PATCH v10 0/9] new features for ipsec and security libraries Radu Nicolau
2021-10-14 16:03 5% ` [dpdk-dev] [PATCH v10 1/9] security: add ESN field to ipsec_xform Radu Nicolau
2021-10-14 16:03 5% ` [dpdk-dev] [PATCH v10 3/9] security: add UDP params for IPsec NAT-T Radu Nicolau
2021-07-31 18:13 [dpdk-dev] [PATCH 0/4] cryptodev and security ABI improvements Akhil Goyal
2021-10-08 20:45 3% ` [dpdk-dev] [PATCH v2 1/3] cryptodev: remove LIST_END enumerators Akhil Goyal
2021-10-08 20:45 3% ` [dpdk-dev] [PATCH v2 3/3] security: add reserved bitfields Akhil Goyal
2021-10-11 8:31 0% ` Thomas Monjalon
2021-10-11 16:58 0% ` [dpdk-dev] [EXT] " Akhil Goyal
2021-10-11 22:15 3% ` Stephen Hemminger
2021-10-12 8:31 0% ` Kinsella, Ray
2021-10-12 6:59 0% ` Thomas Monjalon
2021-10-12 8:53 0% ` Kinsella, Ray
2021-10-12 8:50 0% ` [dpdk-dev] " Kinsella, Ray
2021-10-11 10:46 0% ` [dpdk-dev] [PATCH v2 1/3] cryptodev: remove LIST_END enumerators Zhang, Roy Fan
2021-10-12 9:55 3% ` Kinsella, Ray
2021-10-12 10:19 4% ` [dpdk-dev] [EXT] " Akhil Goyal
2021-10-12 10:50 0% ` Anoob Joseph
2021-10-12 11:28 0% ` Kinsella, Ray
2021-10-12 11:34 0% ` Anoob Joseph
2021-10-12 11:52 0% ` Thomas Monjalon
2021-10-12 13:38 0% ` Anoob Joseph
2021-10-12 13:54 0% ` Thomas Monjalon
2021-10-12 14:18 0% ` Anoob Joseph
2021-10-12 14:47 0% ` Kinsella, Ray
2021-10-12 15:06 0% ` Thomas Monjalon
2021-10-13 5:36 0% ` Anoob Joseph
2021-10-13 7:02 3% ` Thomas Monjalon
2021-10-13 7:04 0% ` Anoob Joseph
2021-10-13 8:39 3% ` Kinsella, Ray
2021-08-13 16:51 [dpdk-dev] [PATCH v1 0/6] bbdev update related to CRC usage Nicolas Chautru
2021-08-13 16:51 ` [dpdk-dev] [PATCH v1 1/6] bbdev: add capability for CRC16 check Nicolas Chautru
2021-10-11 20:17 3% ` Thomas Monjalon
2021-10-11 20:38 0% ` Chautru, Nicolas
2021-10-12 6:53 3% ` Thomas Monjalon
2021-10-12 16:36 4% ` Chautru, Nicolas
2021-10-12 16:59 0% ` Thomas Monjalon
2021-08-19 21:31 [dpdk-dev] [PATCH v14 0/9] eal: Add EAL API for threading Narcisa Ana Maria Vasile
2021-10-08 22:40 3% ` [dpdk-dev] [PATCH v15 " Narcisa Ana Maria Vasile
2021-10-09 7:41 3% ` [dpdk-dev] [PATCH v16 " Narcisa Ana Maria Vasile
2021-08-26 14:57 [dpdk-dev] [RFC 0/7] make rte_intr_handle internal Harman Kalra
2021-10-05 12:14 ` [dpdk-dev] [PATCH v2 0/6] " Harman Kalra
2021-10-05 12:14 ` [dpdk-dev] [PATCH v2 1/6] eal/interrupts: implement get set APIs Harman Kalra
2021-10-14 7:31 3% ` David Marchand
2021-10-05 12:14 ` [dpdk-dev] [PATCH v2 2/6] eal/interrupts: avoid direct access to interrupt handle Harman Kalra
2021-10-14 0:59 3% ` Dmitry Kozlyuk
2021-10-14 17:31 0% ` [dpdk-dev] [EXT] " Harman Kalra
2021-10-14 17:53 0% ` Dmitry Kozlyuk
2021-10-13 17:57 ` [dpdk-dev] [EXT] Re: [PATCH v1 2/7] eal/interrupts: implement get set APIs Harman Kalra
2021-10-13 18:52 ` Thomas Monjalon
2021-10-14 8:22 ` Thomas Monjalon
2021-10-14 9:31 ` Harman Kalra
2021-10-14 9:37 3% ` David Marchand
2021-08-27 6:56 [dpdk-dev] [PATCH 00/38] net/sfc: support port representors Andrew Rybchenko
2021-10-11 14:48 ` [dpdk-dev] [PATCH v2 " Andrew Rybchenko
2021-10-11 14:48 2% ` [dpdk-dev] [PATCH v2 01/38] common/sfc_efx/base: update MCDI headers Andrew Rybchenko
2021-08-29 12:51 [dpdk-dev] [PATCH 0/8] cryptodev: hide internal strutures Akhil Goyal
2021-10-11 12:43 ` [dpdk-dev] [PATCH v2 0/5] cryptodev: hide internal structures Akhil Goyal
2021-10-11 12:43 2% ` [dpdk-dev] [PATCH v2 3/5] cryptodev: move inline APIs into separate structure Akhil Goyal
2021-10-11 14:45 0% ` Zhang, Roy Fan
2021-10-11 12:43 3% ` [dpdk-dev] [PATCH v2 4/5] cryptodev: update fast path APIs to use new flat array Akhil Goyal
2021-10-11 14:54 0% ` Zhang, Roy Fan
2021-09-01 5:30 [dpdk-dev] [PATCH 0/2] *** support IOMMU for DMA device *** Xuan Ding
2021-10-11 7:59 3% ` [dpdk-dev] [PATCH v7 0/2] Support IOMMU for DMA device Xuan Ding
2021-09-01 12:20 [dpdk-dev] [PATCH] pipeline: remove experimental tag from API Jasvinder Singh
2021-09-27 10:17 ` Thomas Monjalon
2021-10-12 20:34 ` Dumitrescu, Cristian
2021-10-12 21:52 ` Thomas Monjalon
2021-10-13 8:51 3% ` Kinsella, Ray
2021-10-13 9:40 0% ` Thomas Monjalon
2021-10-13 9:43 4% ` Kinsella, Ray
2021-10-13 9:49 0% ` Thomas Monjalon
2021-10-13 10:02 4% ` Kinsella, Ray
2021-10-13 11:11 0% ` Bruce Richardson
2021-10-13 11:42 0% ` Kinsella, Ray
2021-10-13 11:58 0% ` Thomas Monjalon
2021-09-03 0:47 [dpdk-dev] [PATCH 0/5] Packet capture framework enhancements Stephen Hemminger
2021-10-12 10:21 ` [dpdk-dev] [PATCH v12 00/12] Packet capture framework update Pattan, Reshma
2021-10-12 15:44 ` Stephen Hemminger
2021-10-12 15:48 ` Thomas Monjalon
2021-10-12 18:00 3% ` Stephen Hemminger
2021-10-12 18:22 0% ` Thomas Monjalon
2021-10-13 8:44 0% ` Pattan, Reshma
2021-09-09 17:56 [dpdk-dev] [PATCH 00/18] comment spelling errors Stephen Hemminger
2021-10-14 21:56 ` [dpdk-dev] [PATCH v3 00/18] fix " Stephen Hemminger
2021-10-14 21:56 4% ` [dpdk-dev] [PATCH v3 08/18] eal: fix typos in comments Stephen Hemminger
2021-09-10 2:23 [dpdk-dev] [PATCH 0/8] Removal of PCI bus ABIs Chenbo Xia
2021-09-18 2:24 ` [dpdk-dev] [PATCH v2 0/7] " Chenbo Xia
2021-09-29 7:38 ` Xia, Chenbo
2021-09-30 8:45 ` David Marchand
2021-10-04 13:37 ` David Marchand
2021-10-04 15:56 ` Harris, James R
2021-10-06 4:25 ` Xia, Chenbo
2021-10-08 6:15 4% ` Liu, Changpeng
2021-10-08 7:08 0% ` David Marchand
2021-10-08 7:44 0% ` Liu, Changpeng
2021-10-11 6:58 0% ` Xia, Chenbo
2021-10-12 7:04 ` Thomas Monjalon
2021-10-12 16:59 ` Walker, Benjamin
2021-10-12 18:43 ` Thomas Monjalon
2021-10-12 19:26 3% ` Walker, Benjamin
2021-10-12 21:50 3% ` Thomas Monjalon
2021-10-13 17:56 5% ` Walker, Benjamin
2021-10-13 18:59 3% ` Thomas Monjalon
2021-10-13 22:48 3% ` Walker, Benjamin
2021-10-14 6:41 0% ` Thomas Monjalon
2021-10-14 2:21 4% ` Xia, Chenbo
2021-10-14 6:41 0% ` Thomas Monjalon
2021-10-14 7:00 3% ` Xia, Chenbo
2021-10-14 7:07 0% ` Thomas Monjalon
2021-10-14 8:07 3% ` Xia, Chenbo
2021-10-14 8:25 0% ` Thomas Monjalon
2021-09-10 14:16 [dpdk-dev] [RFC 1/3] ethdev: update modify field flow action Viacheslav Ovsiienko
2021-10-10 23:45 ` [dpdk-dev] [PATCH v2 0/5] " Viacheslav Ovsiienko
2021-10-10 23:45 8% ` [dpdk-dev] [PATCH v2 1/5] " Viacheslav Ovsiienko
2021-10-11 9:54 3% ` Andrew Rybchenko
2021-10-12 8:06 ` [dpdk-dev] [PATCH v3 0/5] " Viacheslav Ovsiienko
2021-10-12 8:06 3% ` [dpdk-dev] [PATCH v3 1/5] " Viacheslav Ovsiienko
2021-10-12 20:25 ` [dpdk-dev] [PATCH v5 0/5] " Viacheslav Ovsiienko
2021-10-12 20:25 3% ` [dpdk-dev] [PATCH v5 1/5] " Viacheslav Ovsiienko
2021-10-13 18:45 ` [dpdk-dev] [PATCH v6 0/5] " Viacheslav Ovsiienko
2021-10-13 18:45 3% ` [dpdk-dev] [PATCH v6 1/5] " Viacheslav Ovsiienko
2021-10-14 12:08 3% ` Ferruh Yigit
2021-10-14 20:07 0% ` Slava Ovsiienko
2021-09-17 2:15 [dpdk-dev] [PATCH v2 2/2] app/test: Delete cmdline free function zhihongx.peng
2021-10-08 6:41 4% ` [dpdk-dev] [PATCH v3 1/2] lib/cmdline: release cl when cmdline exit zhihongx.peng
2021-10-11 5:20 0% ` Peng, ZhihongX
2021-10-11 8:25 0% ` Dmitry Kozlyuk
2021-10-13 1:53 0% ` Peng, ZhihongX
2021-10-13 2:36 4% ` Dmitry Kozlyuk
2021-10-13 3:12 0% ` Peng, ZhihongX
2021-10-13 1:52 4% ` [dpdk-dev] [PATCH v4 " zhihongx.peng
2021-09-22 18:04 [dpdk-dev] [PATCH 0/3] ethdev: introduce configurable flexible item Viacheslav Ovsiienko
2021-10-12 10:49 ` [dpdk-dev] [PATCH v4 0/5] ethdev: update modify field flow action Viacheslav Ovsiienko
2021-10-12 10:49 3% ` [dpdk-dev] [PATCH v4 1/5] " Viacheslav Ovsiienko
2021-09-23 9:45 [dpdk-dev] [RFC PATCH v8 0/5] Add PIE support for HQoS library Liguzinski, WojciechX
2021-10-11 7:55 3% ` [dpdk-dev] [PATCH v9 " Liguzinski, WojciechX
2021-10-14 11:34 3% ` [dpdk-dev] [PATCH v10 " Liguzinski, WojciechX
2021-10-14 12:38 3% ` [dpdk-dev] [PATCH v11 " Liguzinski, WojciechX
2021-10-14 15:11 3% ` [dpdk-dev] [PATCH v12 " Liguzinski, WojciechX
2021-10-14 15:33 3% ` [dpdk-dev] [PATCH v13 " Liguzinski, WojciechX
2021-10-15 8:16 3% ` [dpdk-dev] [PATCH v14 " Liguzinski, WojciechX
2021-10-15 13:56 0% ` Dumitrescu, Cristian
2021-09-29 14:52 [dpdk-dev] [PATCH 0/4] net/mlx5: implicit mempool registration dkozlyuk
2021-10-12 0:04 ` [dpdk-dev] [PATCH v3 " Dmitry Kozlyuk
2021-10-12 0:04 4% ` [dpdk-dev] [PATCH v3 2/4] mempool: add non-IO flag Dmitry Kozlyuk
2021-10-12 3:37 0% ` Jerin Jacob
2021-10-12 6:42 0% ` Andrew Rybchenko
2021-10-13 11:01 ` [dpdk-dev] [PATCH v4 0/4] net/mlx5: implicit mempool registration Dmitry Kozlyuk
2021-10-13 11:01 4% ` [dpdk-dev] [PATCH v4 2/4] mempool: add non-IO flag Dmitry Kozlyuk
2021-10-15 9:01 0% ` Andrew Rybchenko
2021-09-30 14:50 [dpdk-dev] [PATCH 0/3] crypto/security session framework rework Akhil Goyal
2021-10-13 19:22 ` [dpdk-dev] [PATCH v2 0/7] " Akhil Goyal
2021-10-13 19:22 1% ` [dpdk-dev] [PATCH v2 1/7] security: rework session framework Akhil Goyal
2021-10-13 19:22 1% ` [dpdk-dev] [PATCH v2 5/7] cryptodev: " Akhil Goyal
2021-10-01 13:47 [dpdk-dev] [PATCH v1 00/12] ethdev: rework transfer flow API Andrew Rybchenko
2021-10-13 16:42 ` [dpdk-dev] [PATCH v4 " Ivan Malov
2021-10-13 16:42 4% ` [dpdk-dev] [PATCH v4 01/12] ethdev: add port representor item to " Ivan Malov
2021-10-13 16:42 4% ` [dpdk-dev] [PATCH v4 02/12] ethdev: add represented port " Ivan Malov
2021-10-13 16:42 4% ` [dpdk-dev] [PATCH v4 03/12] ethdev: add port representor action " Ivan Malov
2021-10-13 16:42 4% ` [dpdk-dev] [PATCH v4 04/12] ethdev: add represented port " Ivan Malov
2021-10-13 16:42 3% ` [dpdk-dev] [PATCH v4 05/12] ethdev: deprecate hard-to-use or ambiguous items and actions Ivan Malov
2021-10-13 16:42 3% ` [dpdk-dev] [PATCH v4 06/12] ethdev: deprecate direction attributes in transfer flows Ivan Malov
2021-10-13 16:57 ` [dpdk-dev] [PATCH v4 00/12] ethdev: rework transfer flow API Ivan Malov
2021-10-13 16:57 4% ` [dpdk-dev] [PATCH v5 01/12] ethdev: add port representor item to " Ivan Malov
2021-10-13 16:57 4% ` [dpdk-dev] [PATCH v5 02/12] ethdev: add represented port " Ivan Malov
2021-10-13 16:57 4% ` [dpdk-dev] [PATCH v5 03/12] ethdev: add port representor action " Ivan Malov
2021-10-13 16:57 4% ` [dpdk-dev] [PATCH v5 04/12] ethdev: add represented port " Ivan Malov
2021-10-13 16:57 3% ` [dpdk-dev] [PATCH v5 05/12] ethdev: deprecate hard-to-use or ambiguous items and actions Ivan Malov
2021-10-13 16:57 3% ` [dpdk-dev] [PATCH v5 06/12] ethdev: deprecate direction attributes in transfer flows Ivan Malov
2021-10-13 17:02 ` [dpdk-dev] [PATCH v6 00/12] ethdev: rework transfer flow API Ivan Malov
2021-10-13 17:02 4% ` [dpdk-dev] [PATCH v6 01/12] ethdev: add port representor item to " Ivan Malov
2021-10-13 17:02 4% ` [dpdk-dev] [PATCH v6 02/12] ethdev: add represented port " Ivan Malov
2021-10-13 17:02 4% ` [dpdk-dev] [PATCH v6 03/12] ethdev: add port representor action " Ivan Malov
2021-10-13 17:02 4% ` [dpdk-dev] [PATCH v6 04/12] ethdev: add represented port " Ivan Malov
2021-10-13 17:02 3% ` [dpdk-dev] [PATCH v6 05/12] ethdev: deprecate hard-to-use or ambiguous items and actions Ivan Malov
2021-10-13 17:02 3% ` [dpdk-dev] [PATCH v6 06/12] ethdev: deprecate direction attributes in transfer flows Ivan Malov
2021-10-13 17:34 ` [dpdk-dev] [PATCH v7 00/12] ethdev: rework transfer flow API Ivan Malov
2021-10-13 17:34 4% ` [dpdk-dev] [PATCH v7 01/12] ethdev: add port representor item to " Ivan Malov
2021-10-13 17:34 4% ` [dpdk-dev] [PATCH v7 02/12] ethdev: add represented port " Ivan Malov
2021-10-13 17:34 4% ` [dpdk-dev] [PATCH v7 03/12] ethdev: add port representor action " Ivan Malov
2021-10-13 17:34 4% ` [dpdk-dev] [PATCH v7 04/12] ethdev: add represented port " Ivan Malov
2021-10-13 17:34 3% ` [dpdk-dev] [PATCH v7 05/12] ethdev: deprecate hard-to-use or ambiguous items and actions Ivan Malov
2021-10-13 17:34 3% ` [dpdk-dev] [PATCH v7 06/12] ethdev: deprecate direction attributes in transfer flows Ivan Malov
2021-10-01 16:33 [dpdk-dev] [PATCH v2 0/2] net: Windows compatibility renaming Dmitry Kozlyuk
2021-10-07 22:07 ` [dpdk-dev] [PATCH v3 " Dmitry Kozlyuk
2021-10-07 22:07 1% ` [dpdk-dev] [PATCH v3 1/2] net: rename Ethernet header fields Dmitry Kozlyuk
2021-10-03 8:26 [dpdk-dev] [PATCH v2 01/13] eventdev: make driver interface as internal pbhagavatula
2021-10-06 6:49 ` [dpdk-dev] [PATCH v3 01/14] " pbhagavatula
2021-10-06 6:50 ` [dpdk-dev] [PATCH v3 04/14] eventdev: move inline APIs into separate structure pbhagavatula
2021-10-14 9:20 0% ` Jerin Jacob
2021-10-06 6:50 ` [dpdk-dev] [PATCH v3 14/14] eventdev: mark trace variables as internal pbhagavatula
2021-10-06 7:11 ` David Marchand
2021-10-14 9:28 0% ` Jerin Jacob
2021-10-14 9:08 3% ` [dpdk-dev] [PATCH v3 01/14] eventdev: make driver interface " Jerin Jacob
2021-10-04 13:29 [dpdk-dev] [PATCH v2] ci: update machine meson option to platform Juraj Linkeš
2021-10-11 13:40 4% ` [dpdk-dev] [PATCH v3] " Juraj Linkeš
2021-10-14 12:26 0% ` Aaron Conole
2021-10-04 13:55 [dpdk-dev] [PATCH v4 0/7] hide eth dev related structures Konstantin Ananyev
2021-10-07 11:27 ` [dpdk-dev] [PATCH v5 " Konstantin Ananyev
2021-10-07 11:27 ` [dpdk-dev] [PATCH v5 2/7] ethdev: allocate max space for internal queue array Konstantin Ananyev
2021-10-11 9:20 ` Andrew Rybchenko
2021-10-11 16:25 3% ` Ananyev, Konstantin
2021-10-11 17:15 0% ` Andrew Rybchenko
2021-10-11 23:06 0% ` Ananyev, Konstantin
2021-10-12 5:47 0% ` Andrew Rybchenko
2021-10-07 11:27 ` [dpdk-dev] [PATCH v5 3/7] ethdev: change input parameters for rx_queue_count Konstantin Ananyev
2021-10-11 8:06 0% ` Andrew Rybchenko
2021-10-12 17:59 0% ` Hyong Youb Kim (hyonkim)
2021-10-07 11:27 ` [dpdk-dev] [PATCH v5 4/7] ethdev: copy fast-path API into separate structure Konstantin Ananyev
2021-10-09 12:05 0% ` fengchengwen
2021-10-11 1:18 0% ` fengchengwen
2021-10-11 8:35 0% ` Andrew Rybchenko
2021-10-11 15:15 0% ` Ananyev, Konstantin
2021-10-11 8:25 0% ` Andrew Rybchenko
2021-10-11 16:52 0% ` Ananyev, Konstantin
2021-10-11 17:22 0% ` Andrew Rybchenko
2021-10-07 11:27 ` [dpdk-dev] [PATCH v5 5/7] ethdev: make fast-path functions to use new flat array Konstantin Ananyev
2021-10-11 9:02 0% ` Andrew Rybchenko
2021-10-11 15:47 0% ` Ananyev, Konstantin
2021-10-11 17:03 0% ` Andrew Rybchenko
2021-10-08 18:13 0% ` [dpdk-dev] [PATCH v5 0/7] hide eth dev related structures Slava Ovsiienko
2021-10-11 9:22 0% ` Andrew Rybchenko
2021-10-05 9:16 [dpdk-dev] [PATCH] sort symbols map David Marchand
2021-10-11 11:36 0% ` Dumitrescu, Cristian
2021-10-05 20:15 [dpdk-dev] [PATCH v4 0/2] cmdline: reduce ABI Dmitry Kozlyuk
2021-10-07 22:10 4% ` [dpdk-dev] [PATCH v5 " Dmitry Kozlyuk
2021-10-07 22:10 4% ` [dpdk-dev] [PATCH v5 1/2] cmdline: make struct cmdline opaque Dmitry Kozlyuk
2021-10-07 22:10 3% ` [dpdk-dev] [PATCH v5 2/2] cmdline: make struct rdline opaque Dmitry Kozlyuk
2021-10-06 20:58 [dpdk-dev] [PATCH v9] bbdev: add device info related to data endianness assumption Nicolas Chautru
2021-10-06 20:58 ` Nicolas Chautru
2021-10-07 13:13 ` [dpdk-dev] [EXT] " Akhil Goyal
2021-10-07 15:41 ` Chautru, Nicolas
2021-10-07 16:49 ` Nipun Gupta
2021-10-07 18:58 0% ` Chautru, Nicolas
2021-10-08 4:34 0% ` Nipun Gupta
2021-10-07 12:57 [dpdk-dev] [PATCH v1] eventdev/rx-adapter: add telemetry callbacks Ganapati Kundapura
2021-10-11 16:14 3% ` Jerin Jacob
2021-10-12 8:35 3% ` Kundapura, Ganapati
2021-10-12 8:47 4% ` Jerin Jacob
2021-10-12 9:10 3% ` Thomas Monjalon
2021-10-12 9:26 0% ` Jerin Jacob
2021-10-12 10:05 3% ` Kinsella, Ray
2021-10-12 10:29 0% ` Kundapura, Ganapati
2021-10-12 10:25 [dpdk-dev] [PATCH v3] eventdev/rx_adapter: " Ganapati Kundapura
2021-10-13 7:57 ` [dpdk-dev] [PATCH v4] " Ganapati Kundapura
2021-10-13 12:09 ` Naga Harish K, S V
2021-10-14 8:25 4% ` Jerin Jacob
2021-10-13 8:03 [dpdk-dev] [PATCH v1 0/1] ci: enable DPDK GHA for arm64 with self-hosted runners Serena He
2021-10-13 8:03 7% ` [dpdk-dev] [PATCH v1 1/1] " Serena He
2021-10-13 11:32 0% ` Michael Santana
2021-10-14 7:04 0% ` Serena He
2021-10-13 8:57 11% [dpdk-dev] [PATCH] mempool: fix name size in mempool structure Andrew Rybchenko
2021-10-13 11:07 4% ` David Marchand
2021-10-13 11:14 0% ` Andrew Rybchenko
2021-10-13 17:30 0% ` Honnappa Nagarahalli
2021-10-13 20:58 0% ` Thomas Monjalon
[not found] <0211007112750.25526-1-konstantin.ananyev@intel.com>
2021-10-13 13:36 4% ` [dpdk-dev] [PATCH v6 0/6] hide eth dev related structures Konstantin Ananyev
2021-10-13 13:37 6% ` [dpdk-dev] [PATCH v6 2/6] ethdev: change input parameters for rx_queue_count Konstantin Ananyev
2021-10-13 13:37 2% ` [dpdk-dev] [PATCH v6 3/6] ethdev: copy fast-path API into separate structure Konstantin Ananyev
2021-10-13 14:25 0% ` Andrew Rybchenko
2021-10-13 13:37 2% ` [dpdk-dev] [PATCH v6 4/6] ethdev: make fast-path functions to use new flat array Konstantin Ananyev
2021-10-13 13:37 8% ` [dpdk-dev] [PATCH v6 6/6] ethdev: hide eth dev related structures Konstantin Ananyev
2021-10-13 20:16 0% ` [dpdk-dev] [PATCH v6 0/6] " Ferruh Yigit
2021-10-14 10:12 0% ` [dpdk-dev] 回复: " Feifei Wang
2021-10-13 19:27 [dpdk-dev] [PATCH v2] test/hash: fix buffer overflow Vladimir Medvedkin
2021-10-14 17:48 ` [dpdk-dev] [PATCH v3] " Vladimir Medvedkin
2021-10-15 9:33 ` David Marchand
2021-10-15 13:02 3% ` Medvedkin, Vladimir
2021-10-14 20:55 11% [dpdk-dev] [PATCH] ring: fix size of name array in ring structure Honnappa Nagarahalli
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).