* Re: [EXT] Re: [PATCH] cryptodev: add missing algorithm strings
@ 2022-11-02 12:13 4% ` David Marchand
2022-11-02 12:31 0% ` Akhil Goyal
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2022-11-02 12:13 UTC (permalink / raw)
To: Akhil Goyal
Cc: Kevin Traynor, Volodymyr Fialko, dev, Ravi Kumar, Ali Alnubani,
Jerin Jacob Kollanukkaran, Anoob Joseph, Thomas Monjalon
On Wed, Nov 2, 2022 at 11:58 AM Akhil Goyal <gakhil@marvell.com> wrote:
> > This is being flagged as an ABI break for 21.11.3 [1]. I don't see it
> > mentioned in the commit message or discussed, is it ok for main branch?
>
> Ok, we can keep it to main only.
> But it will be an issue on 21.11.
>
> >
> > Thanks to Ali for reporting. I will revert on 21.11 branch.
> >
> > [1]
> > 1 Changed variable:
> >
> > [C] 'const char* rte_crypto_auth_algorithm_strings[]' was changed at
> > rte_crypto_sym.h:372:1:
> > size of symbol changed from 168 to 232
My two cents.
We have a algo "string to num" helper (rte_cryptodev_get_auth_algo_enum).
This code is not performance sensitive, is it?
If we add the, opposite, "num to string" helper, we can hide the
rte_crypto_auth_algorithm_strings symbol from the public ABI and avoid
this kind of issues in the future.
And looking at lib/crypto map, there are other arrays (*_strings
symbols) that are subject to similar "extending" issues.
We are late in the release for adding new API though such helpers
would be really simple.
Hiding such symbols is something to consider before entering ABI freeze.
--
David Marchand
^ permalink raw reply [relevance 4%]
* RE: [EXT] Re: [PATCH] cryptodev: add missing algorithm strings
2022-11-02 12:13 4% ` David Marchand
@ 2022-11-02 12:31 0% ` Akhil Goyal
0 siblings, 0 replies; 200+ results
From: Akhil Goyal @ 2022-11-02 12:31 UTC (permalink / raw)
To: David Marchand
Cc: Kevin Traynor, Volodymyr Fialko, dev, Ravi Kumar, Ali Alnubani,
Jerin Jacob Kollanukkaran, Anoob Joseph, Thomas Monjalon
> Subject: Re: [EXT] Re: [PATCH] cryptodev: add missing algorithm strings
>
> On Wed, Nov 2, 2022 at 11:58 AM Akhil Goyal <gakhil@marvell.com> wrote:
> > > This is being flagged as an ABI break for 21.11.3 [1]. I don't see it
> > > mentioned in the commit message or discussed, is it ok for main branch?
> >
> > Ok, we can keep it to main only.
> > But it will be an issue on 21.11.
> >
> > >
> > > Thanks to Ali for reporting. I will revert on 21.11 branch.
> > >
> > > [1]
> > > 1 Changed variable:
> > >
> > > [C] 'const char* rte_crypto_auth_algorithm_strings[]' was changed at
> > > rte_crypto_sym.h:372:1:
> > > size of symbol changed from 168 to 232
>
> My two cents.
>
> We have a algo "string to num" helper (rte_cryptodev_get_auth_algo_enum).
>
> This code is not performance sensitive, is it?
> If we add the, opposite, "num to string" helper, we can hide the
> rte_crypto_auth_algorithm_strings symbol from the public ABI and avoid
> this kind of issues in the future.
>
> And looking at lib/crypto map, there are other arrays (*_strings
> symbols) that are subject to similar "extending" issues.
>
> We are late in the release for adding new API though such helpers
> would be really simple.
> Hiding such symbols is something to consider before entering ABI freeze.
>
Agreed, but it is quite late for this cycle.
We can plan these helper APIs for next release cycle and remove these symbols in 23.11.
^ permalink raw reply [relevance 0%]
* Re: [PATCH v2 3/3] mempool: use cache for frequently updated statistics
@ 2022-11-02 17:55 0% ` Mattias Rönnblom
0 siblings, 0 replies; 200+ results
From: Mattias Rönnblom @ 2022-11-02 17:55 UTC (permalink / raw)
To: Morten Brørup, olivier.matz, andrew.rybchenko, stephen,
jerinj, bruce.richardson, thomas
Cc: dev
On 2022-11-02 10:29, Morten Brørup wrote:
>> From: Mattias Rönnblom [mailto:hofors@lysator.liu.se]
>> Sent: Wednesday, 2 November 2022 09.01
>>
>> On 2022-10-31 12:26, Morten Brørup wrote:
>
> [...]
>
>>> +++ b/lib/mempool/rte_mempool.h
>>> @@ -86,6 +86,21 @@ struct rte_mempool_cache {
>>> uint32_t size; /**< Size of the cache */
>>> uint32_t flushthresh; /**< Threshold before we flush excess
>> elements */
>>> uint32_t len; /**< Current cache count */
>>> + uint32_t unused0;
>>> +#ifdef RTE_LIBRTE_MEMPOOL_STATS
>>> + /*
>>> + * Alternative location for the most frequently updated mempool
>> statistics (per-lcore),
>>> + * providing faster update access when using a mempool cache.
>>> + */
>>> + struct {
>>> + uint64_t put_bulk; /**< Number of puts. */
>>> + uint64_t put_objs; /**< Number of objects
>> successfully put. */
>>> + uint64_t get_success_bulk; /**< Successful allocation
>> number. */
>>> + uint64_t get_success_objs; /**< Objects successfully
>> allocated. */
>>> + } stats; /**< Statistics */
>>> +#else
>>> + uint64_t unused1[4];
>>
>> Are a particular DPDK version supposed to be ABI compatible with
>> itself,
>> with different configuration options? E.g., with and without
>> RTE_LIBRTE_MEMPOOL_STATS. Is that why you have those 4 unused
>> uint64_ts?
>
> Valid point: There was no ABI compatibility between with and without RTE_LIBRTE_MEMPOOL_STATS before this patch, so there is no need to add partial ABI compatibility here.
>
> The #else part of this structure should be removed.
>
> Does anyone disagree?
>
>>> +#endif
>
I have no opinion on that matter, but I have another question: if you
remove 'unused1', should you also remove the unused0 field?
^ permalink raw reply [relevance 0%]
* [PATCH 0/2] ABI check updates
@ 2022-11-03 15:47 9% David Marchand
2022-11-03 15:47 21% ` [PATCH 1/2] devtools: unify configuration for ABI check David Marchand
2022-11-03 15:47 41% ` [PATCH 2/2] devtools: stop depending on libabigail xml format David Marchand
0 siblings, 2 replies; 200+ results
From: David Marchand @ 2022-11-03 15:47 UTC (permalink / raw)
To: dev; +Cc: thomas, ci
This series moves ABI exceptions in a single configuration file and
simplifies the ABI check so that no artefact depending on libabigail
version is stored in the CI.
--
David Marchand
David Marchand (2):
devtools: unify configuration for ABI check
devtools: stop depending on libabigail xml format
.ci/linux-build.sh | 4 ----
.github/workflows/build.yml | 2 +-
MAINTAINERS | 1 -
devtools/check-abi.sh | 17 +++++++++++------
devtools/gen-abi.sh | 26 --------------------------
devtools/libabigail.abignore | 12 +++++++++---
devtools/test-meson-builds.sh | 5 -----
7 files changed, 21 insertions(+), 46 deletions(-)
delete mode 100755 devtools/gen-abi.sh
--
2.38.1
^ permalink raw reply [relevance 9%]
* [PATCH 1/2] devtools: unify configuration for ABI check
2022-11-03 15:47 9% [PATCH 0/2] ABI check updates David Marchand
@ 2022-11-03 15:47 21% ` David Marchand
2022-11-03 15:47 41% ` [PATCH 2/2] devtools: stop depending on libabigail xml format David Marchand
1 sibling, 0 replies; 200+ results
From: David Marchand @ 2022-11-03 15:47 UTC (permalink / raw)
To: dev; +Cc: thomas, ci
We have been skipping removed libraries in the ABI check by updating the
check-abi.sh script itself.
See, for example, commit 33584c19ddc2 ("raw/dpaa2_qdma: remove driver").
Having two places for exception is a bit confusing, and those exceptions
are best placed in a single configuration file out of the check script.
Besides, a next patch will switch the check from comparing ABI xml files
to directly comparing .so files. In this mode, libabigail does not
support the soname_regexp syntax used for the mlx glue libraries.
Let's handle these special cases in libabigail.abignore using comments.
Taking the raw/dpaa2_qdma driver as an example, it would be possible to
skip it by adding:
; SKIP_LIBRARY=librte_net_mlx4_glue
+; SKIP_LIBRARY=librte_raw_dpaa2_qdma
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
devtools/check-abi.sh | 4 ++++
devtools/libabigail.abignore | 12 +++++++++---
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
index c583eae2fd..b1bf633f2a 100755
--- a/devtools/check-abi.sh
+++ b/devtools/check-abi.sh
@@ -37,6 +37,10 @@ fi
error=
for dump in $(find $refdir -name "*.dump"); do
name=$(basename $dump)
+ if grep -q "; SKIP_LIBRARY=${name%.dump}\>" $(dirname $0)/libabigail.abignore; then
+ echo "Skipped $name" >&2
+ continue
+ fi
dump2=$(find $newdir -name $name)
if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
echo "Error: cannot find $name in $newdir" >&2
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 7a93de3ba1..3ff51509de 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -16,9 +16,15 @@
[suppress_variable]
name_regexp = _pmd_info$
-; Ignore changes on soname for mlx glue internal drivers
-[suppress_file]
- soname_regexp = ^librte_.*mlx.*glue\.
+;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
+; Special rules to skip libraries ;
+;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
+;
+; This is not a libabigail rule (see check-abi.sh).
+; This is used for driver removal and other special cases like mlx glue libs.
+;
+; SKIP_LIBRARY=librte_common_mlx5_glue
+; SKIP_LIBRARY=librte_net_mlx4_glue
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Experimental APIs exceptions ;
--
2.38.1
^ permalink raw reply [relevance 21%]
* [PATCH 2/2] devtools: stop depending on libabigail xml format
2022-11-03 15:47 9% [PATCH 0/2] ABI check updates David Marchand
2022-11-03 15:47 21% ` [PATCH 1/2] devtools: unify configuration for ABI check David Marchand
@ 2022-11-03 15:47 41% ` David Marchand
1 sibling, 0 replies; 200+ results
From: David Marchand @ 2022-11-03 15:47 UTC (permalink / raw)
To: dev; +Cc: thomas, ci, Aaron Conole, Michael Santana, Bruce Richardson
A ABI reference depends on:
- DPDK build options,
- toolchain compiler and versions,
- libabigail version.
The reason for the latter point is that, when the ABI reference was
generated, ABI xml files were dumped in a format depending on the
libabigail version.
Those xml files were then later used to compare against modified
code.
There are a few disadvantages with this method:
- since the xml files are dependent on the libabigail version, when
updating CI environments, a change in the libabigail package requires
regenerating the ABI references,
- comparing xml files with abidiff is not well tested, as we (DPDK)
uncovered bugs in libabigail that were not hit with comparing .so,
Switch to comparing .so directly, remove this dependence and update GHA
script.
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
.ci/linux-build.sh | 4 ----
.github/workflows/build.yml | 2 +-
MAINTAINERS | 1 -
devtools/check-abi.sh | 15 ++++++++-------
devtools/gen-abi.sh | 26 --------------------------
devtools/test-meson-builds.sh | 5 -----
6 files changed, 9 insertions(+), 44 deletions(-)
delete mode 100755 devtools/gen-abi.sh
diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
index baec65a914..ce91b0af04 100755
--- a/.ci/linux-build.sh
+++ b/.ci/linux-build.sh
@@ -143,8 +143,6 @@ fi
if [ "$ABI_CHECKS" = "true" ]; then
if [ "$(cat libabigail/VERSION 2>/dev/null)" != "$LIBABIGAIL_VERSION" ]; then
rm -rf libabigail
- # if we change libabigail, invalidate existing abi cache
- rm -rf reference
fi
if [ ! -d libabigail ]; then
@@ -166,7 +164,6 @@ if [ "$ABI_CHECKS" = "true" ]; then
meson $OPTS -Dexamples= $refsrcdir $refsrcdir/build
ninja -C $refsrcdir/build
DESTDIR=$(pwd)/reference ninja -C $refsrcdir/build install
- devtools/gen-abi.sh reference
find reference/usr/local -name '*.a' -delete
rm -rf reference/usr/local/bin
rm -rf reference/usr/local/share
@@ -174,7 +171,6 @@ if [ "$ABI_CHECKS" = "true" ]; then
fi
DESTDIR=$(pwd)/install ninja -C build install
- devtools/gen-abi.sh install
devtools/check-abi.sh reference install ${ABI_CHECKS_WARN_ONLY:-}
fi
diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
index a595c12354..b23f8805cb 100644
--- a/.github/workflows/build.yml
+++ b/.github/workflows/build.yml
@@ -71,7 +71,7 @@ jobs:
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 }}'
+ echo 'abi-${{ matrix.config.os }}-${{ matrix.config.compiler }}-${{ matrix.config.cross }}-${{ env.REF_GIT_TAG }}'
- name: Retrieve ccache cache
uses: actions/cache@v2
with:
diff --git a/MAINTAINERS b/MAINTAINERS
index 1c9922123e..9bafec37e7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -90,7 +90,6 @@ F: devtools/check-spdx-tag.sh
F: devtools/check-symbol-change.sh
F: devtools/check-symbol-maps.sh
F: devtools/checkpatches.sh
-F: devtools/gen-abi.sh
F: devtools/get-maintainer.sh
F: devtools/git-log-fixes.sh
F: devtools/load-devel-config
diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
index b1bf633f2a..078de43629 100755
--- a/devtools/check-abi.sh
+++ b/devtools/check-abi.sh
@@ -35,21 +35,22 @@ else
fi
error=
-for dump in $(find $refdir -name "*.dump"); do
- name=$(basename $dump)
- if grep -q "; SKIP_LIBRARY=${name%.dump}\>" $(dirname $0)/libabigail.abignore; then
+for lib in $(find $refdir -name "*.so.*" -a ! -type l); do
+ name=$(basename $lib)
+ if grep -q "; SKIP_LIBRARY=${name%.so.*}\>" $(dirname $0)/libabigail.abignore; then
echo "Skipped $name" >&2
continue
fi
- dump2=$(find $newdir -name $name)
- if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
+ # Look for a library with the same major ABI version
+ lib2=$(find $newdir -name "${name%.*}.*" -a ! -type l)
+ if [ -z "$lib2" ] || [ ! -e "$lib2" ]; then
echo "Error: cannot find $name in $newdir" >&2
error=1
continue
fi
- abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
+ abidiff $ABIDIFF_OPTIONS $lib $lib2 || {
abiret=$?
- echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'" >&2
+ echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $lib $lib2'" >&2
error=1
echo
if [ $(($abiret & 3)) -ne 0 ]; then
diff --git a/devtools/gen-abi.sh b/devtools/gen-abi.sh
deleted file mode 100755
index f15a3b9aaf..0000000000
--- a/devtools/gen-abi.sh
+++ /dev/null
@@ -1,26 +0,0 @@
-#!/bin/sh -e
-# SPDX-License-Identifier: BSD-3-Clause
-# Copyright (c) 2019 Red Hat, Inc.
-
-if [ $# != 1 ]; then
- echo "Usage: $0 installdir" >&2
- exit 1
-fi
-
-installdir=$1
-if [ ! -d $installdir ]; then
- echo "Error: install directory '$installdir' does not exist." >&2
- exit 1
-fi
-
-dumpdir=$installdir/dump
-rm -rf $dumpdir
-mkdir -p $dumpdir
-for f in $(find $installdir -name "*.so.*"); do
- if test -L $f; then
- continue
- fi
-
- libname=$(basename $f)
- abidw --out-file $dumpdir/${libname%.so*}.dump $f
-done
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index 3a308bc9af..971650e621 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -188,7 +188,6 @@ build () # <directory> <target cc | cross file> <ABI check> [meson options]
-Dexamples= $*
compile $abirefdir/build
install_target $abirefdir/build $abirefdir/$targetdir
- $srcdir/devtools/gen-abi.sh $abirefdir/$targetdir
# save disk space by removing static libs and apps
find $abirefdir/$targetdir/usr/local -name '*.a' -delete
@@ -199,10 +198,6 @@ build () # <directory> <target cc | cross file> <ABI check> [meson options]
install_target $builds_dir/$targetdir \
$(readlink -f $builds_dir/$targetdir/install)
echo "Checking ABI compatibility of $targetdir" >&$verbose
- echo $srcdir/devtools/gen-abi.sh \
- $(readlink -f $builds_dir/$targetdir/install) >&$veryverbose
- $srcdir/devtools/gen-abi.sh \
- $(readlink -f $builds_dir/$targetdir/install) >&$veryverbose
echo $srcdir/devtools/check-abi.sh $abirefdir/$targetdir \
$(readlink -f $builds_dir/$targetdir/install) >&$veryverbose
$srcdir/devtools/check-abi.sh $abirefdir/$targetdir \
--
2.38.1
^ permalink raw reply [relevance 41%]
* RE: FW: [PATCH v4 3/3] mempool: use cache for frequently updated stats
@ 2022-11-08 17:38 3% ` Konstantin Ananyev
2022-11-09 5:03 4% ` Morten Brørup
0 siblings, 1 reply; 200+ results
From: Konstantin Ananyev @ 2022-11-08 17:38 UTC (permalink / raw)
To: Bruce Richardson, Thomas Monjalon
Cc: Morten Brørup, andrew.rybchenko, olivier.matz,
david.marchand, dev, hofors, mattias.ronnblom, stephen, jerinj
>
> On Tue, Nov 08, 2022 at 04:51:11PM +0100, Thomas Monjalon wrote:
> > 08/11/2022 15:30, Morten Brørup:
> > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > 08/11/2022 12:25, Morten Brørup:
> > > > > From: Morten Brørup
> > > > > > From: Konstantin Ananyev [mailto:konstantin.ananyev@huawei.com]
> > > > > > Sent: Tuesday, 8 November 2022 10.20
> > > > > > > +#ifdef RTE_LIBRTE_MEMPOOL_STATS
> > > > > > > +#define RTE_MEMPOOL_CACHE_STAT_ADD(cache, name, n) (cache)-
> > > > >stats.name += n
> > > > > >
> > > > > > As Andrew already pointed, it needs to be: ((cache)->stats.name +=
> > > > (n))
> > > > > > Apart from that, LGTM.
> > > > > > Series-Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
> > > > >
> > > > > @Thomas, this series should be ready to apply... it now has been:
> > > > > Reviewed-by: (mempool maintainer) Andrew Rybchenko
> > > > <andrew.rybchenko@oktetlabs.ru>
> > > > > Reviewed-By: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
> > > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
> > > >
> > > > Being acked does not mean it is good to apply in -rc3.
> > >
> > > I understand that the RFC/v1 of this series was formally too late to make it in 22.11, so I will not complain loudly if you choose to
> omit it for 22.11.
> > >
> > > With two independent reviews, including from a mempool maintainer, I still have some hope. Also considering the risk assessment
> below. ;-)
> > >
> > > > Please tell what is the benefit for 22.11 (before/after and condition).
> > >
> > > Short version: With this series, mempool statistics can be used in production. Without it, the performance cost
> (mempool_perf_autotest: -74 %) is prohibitive!
> > >
> > > Long version:
> > >
> > > The patch series provides significantly higher performance for mempool statistics, which are readable through
> rte_mempool_dump(FILE *f, struct rte_mempool *mp).
> > >
> > > Without this series, you have to set RTE_LIBRTE_MEMPOOL_DEBUG at build time to get mempool statistics.
> RTE_LIBRTE_MEMPOOL_DEBUG also enables protective cookies before and after each mempool object, which are all verified on
> get/put from the mempool. According to mempool_perf_autotest, the performance cost of mempool statistics (by setting
> RTE_LIBRTE_MEMPOOL_DEBUG) is a 74 % decrease in rate_persec for mempools with cache (i.e. mbuf pools). Prohibitive for use in
> production!
> > >
> > > With this series, the performance cost of mempool statistics (by setting RTE_LIBRTE_MEMPOOL_STATS) in
> mempool_perf_autotest is only 6.7 %, so mempool statistics can be used in production.
> > >
> > > > Note there is a real risk doing such change that late.
> > >
> > > Risk assessment:
> > >
> > > The patch series has zero effect unless either RTE_LIBRTE_MEMPOOL_DEBUG or RTE_LIBRTE_MEMPOOL_STATS are set when
> building. They are not set in the default build.
> >
> > If theses build flags are not set, there is no risk and no benefit.
> > But if they are set, there is a risk of regression,
> > for the benefit of an increased performance of a debug feature.
> > I would say it is better to avoid any functional regression in a debug feature
> > at this stage.
> > Any other opinion?
> >
> While I agree that we should avoid any functional regression, I wonder how
> widely used the debug feature is, and how big the risk of a regression is?
> Even if there is one, having a regression in a debug feature is a lot less
> serious than having one in something which goes into production.
>
Unless it introduces an ABI breakage (as I understand it doesn't), I'll wait till 23.03.
Just in case.
BTW, as a side thought - if the impact is really that small now, would it make sense to make
it run-time option, instead of compile-time one?
Konstantin
^ permalink raw reply [relevance 3%]
* RE: FW: [PATCH v4 3/3] mempool: use cache for frequently updated stats
2022-11-08 17:38 3% ` Konstantin Ananyev
@ 2022-11-09 5:03 4% ` Morten Brørup
2022-11-09 8:21 0% ` Mattias Rönnblom
0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2022-11-09 5:03 UTC (permalink / raw)
To: Konstantin Ananyev, Bruce Richardson, Thomas Monjalon
Cc: andrew.rybchenko, olivier.matz, david.marchand, dev, hofors,
mattias.ronnblom, stephen, jerinj
> From: Konstantin Ananyev [mailto:konstantin.ananyev@huawei.com]
> Sent: Tuesday, 8 November 2022 18.38
> >
> > On Tue, Nov 08, 2022 at 04:51:11PM +0100, Thomas Monjalon wrote:
> > > 08/11/2022 15:30, Morten Brørup:
> > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > > > 08/11/2022 12:25, Morten Brørup:
> > > > > > From: Morten Brørup
> > > > > > > From: Konstantin Ananyev
> [mailto:konstantin.ananyev@huawei.com]
> > > > > > > Sent: Tuesday, 8 November 2022 10.20
> > > > > > > > +#ifdef RTE_LIBRTE_MEMPOOL_STATS
> > > > > > > > +#define RTE_MEMPOOL_CACHE_STAT_ADD(cache, name, n)
> (cache)-
> > > > > >stats.name += n
> > > > > > >
> > > > > > > As Andrew already pointed, it needs to be: ((cache)-
> >stats.name +=
> > > > > (n))
> > > > > > > Apart from that, LGTM.
> > > > > > > Series-Acked-by: Konstantin Ananyev
> <konstantin.ananyev@huawei.com>
> > > > > >
> > > > > > @Thomas, this series should be ready to apply... it now has
> been:
> > > > > > Reviewed-by: (mempool maintainer) Andrew Rybchenko
> > > > > <andrew.rybchenko@oktetlabs.ru>
> > > > > > Reviewed-By: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
> > > > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
> > > > >
> > > > > Being acked does not mean it is good to apply in -rc3.
> > > >
> > > > I understand that the RFC/v1 of this series was formally too late
> to make it in 22.11, so I will not complain loudly if you choose to
> > omit it for 22.11.
> > > >
> > > > With two independent reviews, including from a mempool
> maintainer, I still have some hope. Also considering the risk
> assessment
> > below. ;-)
> > > >
> > > > > Please tell what is the benefit for 22.11 (before/after and
> condition).
> > > >
> > > > Short version: With this series, mempool statistics can be used
> in production. Without it, the performance cost
> > (mempool_perf_autotest: -74 %) is prohibitive!
> > > >
> > > > Long version:
> > > >
> > > > The patch series provides significantly higher performance for
> mempool statistics, which are readable through
> > rte_mempool_dump(FILE *f, struct rte_mempool *mp).
> > > >
> > > > Without this series, you have to set RTE_LIBRTE_MEMPOOL_DEBUG at
> build time to get mempool statistics.
> > RTE_LIBRTE_MEMPOOL_DEBUG also enables protective cookies before and
> after each mempool object, which are all verified on
> > get/put from the mempool. According to mempool_perf_autotest, the
> performance cost of mempool statistics (by setting
> > RTE_LIBRTE_MEMPOOL_DEBUG) is a 74 % decrease in rate_persec for
> mempools with cache (i.e. mbuf pools). Prohibitive for use in
> > production!
> > > >
> > > > With this series, the performance cost of mempool statistics (by
> setting RTE_LIBRTE_MEMPOOL_STATS) in
> > mempool_perf_autotest is only 6.7 %, so mempool statistics can be
> used in production.
> > > >
> > > > > Note there is a real risk doing such change that late.
> > > >
> > > > Risk assessment:
> > > >
> > > > The patch series has zero effect unless either
> RTE_LIBRTE_MEMPOOL_DEBUG or RTE_LIBRTE_MEMPOOL_STATS are set when
> > building. They are not set in the default build.
> > >
> > > If theses build flags are not set, there is no risk and no benefit.
> > > But if they are set, there is a risk of regression,
> > > for the benefit of an increased performance of a debug feature.
> > > I would say it is better to avoid any functional regression in a
> debug feature
> > > at this stage.
> > > Any other opinion?
> > >
> > While I agree that we should avoid any functional regression, I
> wonder how
> > widely used the debug feature is, and how big the risk of a
> regression is?
> > Even if there is one, having a regression in a debug feature is a lot
> less
> > serious than having one in something which goes into production.
> >
>
> Unless it introduces an ABI breakage (as I understand it doesn't), I'll
> wait till 23.03.
> Just in case.
If built (both before and after this series) without RTE_LIBRTE_MEMPOOL_DEBUG (and without RTE_LIBRTE_MEMPOOL_STATS, which is introduced by the series), there is no ABI breakage.
If built (both before and after this series) with RTE_LIBRTE_MEMPOOL_DEBUG (and without RTE_LIBRTE_MEMPOOL_STATS), the ABI differs between before and after this series: The stats array disappears from struct rte_mempool, and the output from rte_mempool_dump() does not include the statistics.
If built (both before and after this series) with RTE_LIBRTE_MEMPOOL_DEBUG (and with RTE_LIBRTE_MEMPOOL_STATS), the ABI also differs between before and after this series: The size of the stats array in struct rte_mempool grows by one element.
> BTW, as a side thought - if the impact is really that small now, would
> it make sense to make
> it run-time option, instead of compile-time one?
The mempool get/put functions are very lean when built without STATS or DEBUG. With a runtime option, the resulting code would be slightly longer, and only one additional conditional would be hit in the common case (i.e. when the objects don't miss the mempool cache). So with stats disabled (at runtime), it would only add a very small performance cost. However, checking the value of the enabled/disabled variable can cause a CPU cache miss, which has a performance cost. And the enabled/disabled variable should definitely be global - if it is per mempool, it will cause many CPU cache misses (because the common case doesn't touch the mempool structure, only the mempool cache structure).
Also, checking the runtime option should have unlikely(), so the performance cost of the stats (when enabled at runtime) is also higher than with a build time option. (Yes, dynamic branch prediction will alleviate most of this, but it will consume entries in the branch predictor table - these are inlined functions. Just like we always try to avoid cache misses in DPDK, we should also try to conserve branch predictor table entries. I hate the argument that branch prediction fixes conditionals, especially if they are weird or could have been avoided.)
In the cost/benefit analysis, we need to consider that these statistics are not fill/emptiness level status or similar, but only debug counters (number of get/put transactions and objects), so we need to ask ourselves this question: How many users are interested in these statistics for production and are unable to build their application with RTE_LIBRTE_MEMPOOL_STATS?
For example, we (SmartShare Systems) are only interested in them for application profiling purposes... trying to improve the performance by striving for a higher number of objects per burst in every pipeline stage.
> Konstantin
^ permalink raw reply [relevance 4%]
* Re: FW: [PATCH v4 3/3] mempool: use cache for frequently updated stats
2022-11-09 5:03 4% ` Morten Brørup
@ 2022-11-09 8:21 0% ` Mattias Rönnblom
2022-11-09 10:19 4% ` Konstantin Ananyev
0 siblings, 1 reply; 200+ results
From: Mattias Rönnblom @ 2022-11-09 8:21 UTC (permalink / raw)
To: Morten Brørup, Konstantin Ananyev, Bruce Richardson,
Thomas Monjalon
Cc: andrew.rybchenko, olivier.matz, david.marchand, dev, hofors,
stephen, jerinj
On 2022-11-09 06:03, Morten Brørup wrote:
>> From: Konstantin Ananyev [mailto:konstantin.ananyev@huawei.com]
>> Sent: Tuesday, 8 November 2022 18.38
>>>
>>> On Tue, Nov 08, 2022 at 04:51:11PM +0100, Thomas Monjalon wrote:
>>>> 08/11/2022 15:30, Morten Brørup:
>>>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
>>>>>> 08/11/2022 12:25, Morten Brørup:
>>>>>>> From: Morten Brørup
>>>>>>>> From: Konstantin Ananyev
>> [mailto:konstantin.ananyev@huawei.com]
>>>>>>>> Sent: Tuesday, 8 November 2022 10.20
>>>>>>>>> +#ifdef RTE_LIBRTE_MEMPOOL_STATS
>>>>>>>>> +#define RTE_MEMPOOL_CACHE_STAT_ADD(cache, name, n)
>> (cache)-
>>>>>>> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-27a859e7ec13035a&q=1&e=a120e28e-caa7-4783-9686-5868c871553d&u=http%3A%2F%2Fstats.name%2F += n
>>>>>>>>
>>>>>>>> As Andrew already pointed, it needs to be: ((cache)-
>>> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-27a859e7ec13035a&q=1&e=a120e28e-caa7-4783-9686-5868c871553d&u=http%3A%2F%2Fstats.name%2F +=
>>>>>> (n))
>>>>>>>> Apart from that, LGTM.
>>>>>>>> Series-Acked-by: Konstantin Ananyev
>> <konstantin.ananyev@huawei.com>
>>>>>>>
>>>>>>> @Thomas, this series should be ready to apply... it now has
>> been:
>>>>>>> Reviewed-by: (mempool maintainer) Andrew Rybchenko
>>>>>> <andrew.rybchenko@oktetlabs.ru>
>>>>>>> Reviewed-By: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
>>>>>>> Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
>>>>>>
>>>>>> Being acked does not mean it is good to apply in -rc3.
>>>>>
>>>>> I understand that the RFC/v1 of this series was formally too late
>> to make it in 22.11, so I will not complain loudly if you choose to
>>> omit it for 22.11.
>>>>>
>>>>> With two independent reviews, including from a mempool
>> maintainer, I still have some hope. Also considering the risk
>> assessment
>>> below. ;-)
>>>>>
>>>>>> Please tell what is the benefit for 22.11 (before/after and
>> condition).
>>>>>
>>>>> Short version: With this series, mempool statistics can be used
>> in production. Without it, the performance cost
>>> (mempool_perf_autotest: -74 %) is prohibitive!
>>>>>
>>>>> Long version:
>>>>>
>>>>> The patch series provides significantly higher performance for
>> mempool statistics, which are readable through
>>> rte_mempool_dump(FILE *f, struct rte_mempool *mp).
>>>>>
>>>>> Without this series, you have to set RTE_LIBRTE_MEMPOOL_DEBUG at
>> build time to get mempool statistics.
>>> RTE_LIBRTE_MEMPOOL_DEBUG also enables protective cookies before and
>> after each mempool object, which are all verified on
>>> get/put from the mempool. According to mempool_perf_autotest, the
>> performance cost of mempool statistics (by setting
>>> RTE_LIBRTE_MEMPOOL_DEBUG) is a 74 % decrease in rate_persec for
>> mempools with cache (i.e. mbuf pools). Prohibitive for use in
>>> production!
>>>>>
>>>>> With this series, the performance cost of mempool statistics (by
>> setting RTE_LIBRTE_MEMPOOL_STATS) in
>>> mempool_perf_autotest is only 6.7 %, so mempool statistics can be
>> used in production.
>>>>>
>>>>>> Note there is a real risk doing such change that late.
>>>>>
>>>>> Risk assessment:
>>>>>
>>>>> The patch series has zero effect unless either
>> RTE_LIBRTE_MEMPOOL_DEBUG or RTE_LIBRTE_MEMPOOL_STATS are set when
>>> building. They are not set in the default build.
>>>>
>>>> If theses build flags are not set, there is no risk and no benefit.
>>>> But if they are set, there is a risk of regression,
>>>> for the benefit of an increased performance of a debug feature.
>>>> I would say it is better to avoid any functional regression in a
>> debug feature
>>>> at this stage.
>>>> Any other opinion?
>>>>
>>> While I agree that we should avoid any functional regression, I
>> wonder how
>>> widely used the debug feature is, and how big the risk of a
>> regression is?
>>> Even if there is one, having a regression in a debug feature is a lot
>> less
>>> serious than having one in something which goes into production.
>>>
>>
>> Unless it introduces an ABI breakage (as I understand it doesn't), I'll
>> wait till 23.03.
>> Just in case.
>
> If built (both before and after this series) without RTE_LIBRTE_MEMPOOL_DEBUG (and without RTE_LIBRTE_MEMPOOL_STATS, which is introduced by the series), there is no ABI breakage.
>
> If built (both before and after this series) with RTE_LIBRTE_MEMPOOL_DEBUG (and without RTE_LIBRTE_MEMPOOL_STATS), the ABI differs between before and after this series: The stats array disappears from struct rte_mempool, and the output from rte_mempool_dump() does not include the statistics.
>
> If built (both before and after this series) with RTE_LIBRTE_MEMPOOL_DEBUG (and with RTE_LIBRTE_MEMPOOL_STATS), the ABI also differs between before and after this series: The size of the stats array in struct rte_mempool grows by one element.
>
>> BTW, as a side thought - if the impact is really that small now, would
>> it make sense to make
>> it run-time option, instead of compile-time one?
>
> The mempool get/put functions are very lean when built without STATS or DEBUG. With a runtime option, the resulting code would be slightly longer, and only one additional conditional would be hit in the common case (i.e. when the objects don't miss the mempool cache). So with stats disabled (at runtime), it would only add a very small performance cost. However, checking the value of the enabled/disabled variable can cause a CPU cache miss, which has a performance cost. And the enabled/disabled variable should definitely be global - if it is per mempool, it will cause many CPU cache misses (because the common case doesn't touch the mempool structure, only the mempool cache structure).
>
It's not totally obvious that a conditional is better than just always
performing these simple arithmetic operations, even if you don't know if
you need the result (i.e., if stats is enabled or not), especially since
they operate on a cache line that is very likely already owned by the
core running the core (since the 'len' fields is frequently used).
> Also, checking the runtime option should have unlikely(), so the performance cost of the stats (when enabled at runtime) is also higher than with a build time option. (Yes, dynamic branch prediction will alleviate most of this, but it will consume entries in the branch predictor table - these are inlined functions. Just like we always try to avoid cache misses in DPDK, we should also try to conserve branch predictor table entries. I hate the argument that branch prediction fixes conditionals, especially if they are weird or could have been avoided.)
>
> In the cost/benefit analysis, we need to consider that these statistics are not fill/emptiness level status or similar, but only debug counters (number of get/put transactions and objects), so we need to ask ourselves this question: How many users are interested in these statistics for production and are unable to build their application with RTE_LIBRTE_MEMPOOL_STATS?
>
> For example, we (SmartShare Systems) are only interested in them for application profiling purposes... trying to improve the performance by striving for a higher number of objects per burst in every pipeline stage.
>
>> Konstantin
^ permalink raw reply [relevance 0%]
* RE: FW: [PATCH v4 3/3] mempool: use cache for frequently updated stats
2022-11-09 8:21 0% ` Mattias Rönnblom
@ 2022-11-09 10:19 4% ` Konstantin Ananyev
2022-11-09 11:42 0% ` Morten Brørup
0 siblings, 1 reply; 200+ results
From: Konstantin Ananyev @ 2022-11-09 10:19 UTC (permalink / raw)
To: Mattias Rönnblom, Morten Brørup, Bruce Richardson,
Thomas Monjalon
Cc: andrew.rybchenko, olivier.matz, david.marchand, dev, hofors,
stephen, jerinj
> On 2022-11-09 06:03, Morten Brørup wrote:
> >> From: Konstantin Ananyev [mailto:konstantin.ananyev@huawei.com]
> >> Sent: Tuesday, 8 November 2022 18.38
> >>>
> >>> On Tue, Nov 08, 2022 at 04:51:11PM +0100, Thomas Monjalon wrote:
> >>>> 08/11/2022 15:30, Morten Brørup:
> >>>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> >>>>>> 08/11/2022 12:25, Morten Brørup:
> >>>>>>> From: Morten Brørup
> >>>>>>>> From: Konstantin Ananyev
> >> [mailto:konstantin.ananyev@huawei.com]
> >>>>>>>> Sent: Tuesday, 8 November 2022 10.20
> >>>>>>>>> +#ifdef RTE_LIBRTE_MEMPOOL_STATS
> >>>>>>>>> +#define RTE_MEMPOOL_CACHE_STAT_ADD(cache, name, n)
> >> (cache)-
> >>>>>>> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-27a859e7ec13035a&q=1&e=a120e28e-
> caa7-4783-9686-5868c871553d&u=http%3A%2F%2Fstats.name%2F += n
> >>>>>>>>
> >>>>>>>> As Andrew already pointed, it needs to be: ((cache)-
> >>> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-27a859e7ec13035a&q=1&e=a120e28e-caa7-
> 4783-9686-5868c871553d&u=http%3A%2F%2Fstats.name%2F +=
> >>>>>> (n))
> >>>>>>>> Apart from that, LGTM.
> >>>>>>>> Series-Acked-by: Konstantin Ananyev
> >> <konstantin.ananyev@huawei.com>
> >>>>>>>
> >>>>>>> @Thomas, this series should be ready to apply... it now has
> >> been:
> >>>>>>> Reviewed-by: (mempool maintainer) Andrew Rybchenko
> >>>>>> <andrew.rybchenko@oktetlabs.ru>
> >>>>>>> Reviewed-By: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
> >>>>>>> Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
> >>>>>>
> >>>>>> Being acked does not mean it is good to apply in -rc3.
> >>>>>
> >>>>> I understand that the RFC/v1 of this series was formally too late
> >> to make it in 22.11, so I will not complain loudly if you choose to
> >>> omit it for 22.11.
> >>>>>
> >>>>> With two independent reviews, including from a mempool
> >> maintainer, I still have some hope. Also considering the risk
> >> assessment
> >>> below. ;-)
> >>>>>
> >>>>>> Please tell what is the benefit for 22.11 (before/after and
> >> condition).
> >>>>>
> >>>>> Short version: With this series, mempool statistics can be used
> >> in production. Without it, the performance cost
> >>> (mempool_perf_autotest: -74 %) is prohibitive!
> >>>>>
> >>>>> Long version:
> >>>>>
> >>>>> The patch series provides significantly higher performance for
> >> mempool statistics, which are readable through
> >>> rte_mempool_dump(FILE *f, struct rte_mempool *mp).
> >>>>>
> >>>>> Without this series, you have to set RTE_LIBRTE_MEMPOOL_DEBUG at
> >> build time to get mempool statistics.
> >>> RTE_LIBRTE_MEMPOOL_DEBUG also enables protective cookies before and
> >> after each mempool object, which are all verified on
> >>> get/put from the mempool. According to mempool_perf_autotest, the
> >> performance cost of mempool statistics (by setting
> >>> RTE_LIBRTE_MEMPOOL_DEBUG) is a 74 % decrease in rate_persec for
> >> mempools with cache (i.e. mbuf pools). Prohibitive for use in
> >>> production!
> >>>>>
> >>>>> With this series, the performance cost of mempool statistics (by
> >> setting RTE_LIBRTE_MEMPOOL_STATS) in
> >>> mempool_perf_autotest is only 6.7 %, so mempool statistics can be
> >> used in production.
> >>>>>
> >>>>>> Note there is a real risk doing such change that late.
> >>>>>
> >>>>> Risk assessment:
> >>>>>
> >>>>> The patch series has zero effect unless either
> >> RTE_LIBRTE_MEMPOOL_DEBUG or RTE_LIBRTE_MEMPOOL_STATS are set when
> >>> building. They are not set in the default build.
> >>>>
> >>>> If theses build flags are not set, there is no risk and no benefit.
> >>>> But if they are set, there is a risk of regression,
> >>>> for the benefit of an increased performance of a debug feature.
> >>>> I would say it is better to avoid any functional regression in a
> >> debug feature
> >>>> at this stage.
> >>>> Any other opinion?
> >>>>
> >>> While I agree that we should avoid any functional regression, I
> >> wonder how
> >>> widely used the debug feature is, and how big the risk of a
> >> regression is?
> >>> Even if there is one, having a regression in a debug feature is a lot
> >> less
> >>> serious than having one in something which goes into production.
> >>>
> >>
> >> Unless it introduces an ABI breakage (as I understand it doesn't), I'll
> >> wait till 23.03.
> >> Just in case.
> >
> > If built (both before and after this series) without RTE_LIBRTE_MEMPOOL_DEBUG (and without RTE_LIBRTE_MEMPOOL_STATS,
> which is introduced by the series), there is no ABI breakage.
> >
> > If built (both before and after this series) with RTE_LIBRTE_MEMPOOL_DEBUG (and without RTE_LIBRTE_MEMPOOL_STATS), the
> ABI differs between before and after this series: The stats array disappears from struct rte_mempool, and the output from
> rte_mempool_dump() does not include the statistics.
> >
Can we probably always enable RTE_LIBRTE_MEMPOOL_STATS when RTE_LIBRTE_MEMPOOL_DEBUG is on?
> > If built (both before and after this series) with RTE_LIBRTE_MEMPOOL_DEBUG (and with RTE_LIBRTE_MEMPOOL_STATS), the ABI
> also differs between before and after this series: The size of the stats array in struct rte_mempool grows by one element.
Ah yes, missed that one.
So the question is then - does it count as formal ABI breakage or not?
If yes, then probably better to go ahead with these changes for 22.11
(it sounds too prohibitive to wait for an year here).
Or at least take in the part that introduce the ABI breakage.
If not, probably not bit deal to wait till 23.03.
> >> BTW, as a side thought - if the impact is really that small now, would
> >> it make sense to make
> >> it run-time option, instead of compile-time one?
> >
> > The mempool get/put functions are very lean when built without STATS or DEBUG. With a runtime option, the resulting code would
> be slightly longer, and only one additional conditional would be hit in the common case (i.e. when the objects don't miss the mempool
> cache). So with stats disabled (at runtime), it would only add a very small performance cost. However, checking the value of the
> enabled/disabled variable can cause a CPU cache miss, which has a performance cost. And the enabled/disabled variable should
> definitely be global - if it is per mempool, it will cause many CPU cache misses (because the common case doesn't touch the mempool
> structure, only the mempool cache structure).
> >
Yes, either a global one, or put it into both structs: rte_mempool_cache and rte_mempool.
> It's not totally obvious that a conditional is better than just always
> performing these simple arithmetic operations, even if you don't know if
> you need the result (i.e., if stats is enabled or not), especially since
> they operate on a cache line that is very likely already owned by the
> core running the core (since the 'len' fields is frequently used).
Yep, that's another option - always update the cache part.
> > Also, checking the runtime option should have unlikely(), so the performance cost of the stats (when enabled at runtime) is also
> higher than with a build time option. (Yes, dynamic branch prediction will alleviate most of this, but it will consume entries in the
> branch predictor table - these are inlined functions. Just like we always try to avoid cache misses in DPDK, we should also try to
> conserve branch predictor table entries. I hate the argument that branch prediction fixes conditionals, especially if they are weird or
> could have been avoided.)
> >
> > In the cost/benefit analysis, we need to consider that these statistics are not fill/emptiness level status or similar, but only debug
> counters (number of get/put transactions and objects), so we need to ask ourselves this question: How many users are interested in
> these statistics for production and are unable to build their application with RTE_LIBRTE_MEMPOOL_STATS?
Obviously, I don't have such stats.
From my perspective - I am ok to spend few extra cycles to avoid building separate binary.
Again, I guess that with global switch the impact will be negligible.
But anyway, it will require even more changes and another ABI breakage (as stats should always be included),
so it definitely out of scope for this release.
> > For example, we (SmartShare Systems) are only interested in them for application profiling purposes... trying to improve the
> performance by striving for a higher number of objects per burst in every pipeline stage.
> >
> >> Konstantin
^ permalink raw reply [relevance 4%]
* RE: FW: [PATCH v4 3/3] mempool: use cache for frequently updated stats
2022-11-09 10:19 4% ` Konstantin Ananyev
@ 2022-11-09 11:42 0% ` Morten Brørup
0 siblings, 0 replies; 200+ results
From: Morten Brørup @ 2022-11-09 11:42 UTC (permalink / raw)
To: Konstantin Ananyev, Mattias Rönnblom, Bruce Richardson,
Thomas Monjalon
Cc: andrew.rybchenko, olivier.matz, david.marchand, dev, hofors,
stephen, jerinj
> From: Konstantin Ananyev [mailto:konstantin.ananyev@huawei.com]
> Sent: Wednesday, 9 November 2022 11.20
>
> > On 2022-11-09 06:03, Morten Brørup wrote:
> > >> From: Konstantin Ananyev [mailto:konstantin.ananyev@huawei.com]
> > >> Sent: Tuesday, 8 November 2022 18.38
> > >>>
> > >>> On Tue, Nov 08, 2022 at 04:51:11PM +0100, Thomas Monjalon wrote:
> > >>>> 08/11/2022 15:30, Morten Brørup:
> > >>>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > >>>>>> 08/11/2022 12:25, Morten Brørup:
> > >>>>>>> From: Morten Brørup
> > >>>>>>>> From: Konstantin Ananyev
> > >> [mailto:konstantin.ananyev@huawei.com]
> > >>>>>>>> Sent: Tuesday, 8 November 2022 10.20
> > >>>>>>>>> +#ifdef RTE_LIBRTE_MEMPOOL_STATS
> > >>>>>>>>> +#define RTE_MEMPOOL_CACHE_STAT_ADD(cache, name, n)
> > >> (cache)-
> > >>>>>>> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-
> 313273af-454445555731-27a859e7ec13035a&q=1&e=a120e28e-
> > caa7-4783-9686-5868c871553d&u=http%3A%2F%2Fstats.name%2F += n
> > >>>>>>>>
> > >>>>>>>> As Andrew already pointed, it needs to be: ((cache)-
> > >>> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-
> 454445555731-27a859e7ec13035a&q=1&e=a120e28e-caa7-
> > 4783-9686-5868c871553d&u=http%3A%2F%2Fstats.name%2F +=
> > >>>>>> (n))
> > >>>>>>>> Apart from that, LGTM.
> > >>>>>>>> Series-Acked-by: Konstantin Ananyev
> > >> <konstantin.ananyev@huawei.com>
> > >>>>>>>
> > >>>>>>> @Thomas, this series should be ready to apply... it now has
> > >> been:
> > >>>>>>> Reviewed-by: (mempool maintainer) Andrew Rybchenko
> > >>>>>> <andrew.rybchenko@oktetlabs.ru>
> > >>>>>>> Reviewed-By: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
> > >>>>>>> Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
> > >>>>>>
> > >>>>>> Being acked does not mean it is good to apply in -rc3.
> > >>>>>
> > >>>>> I understand that the RFC/v1 of this series was formally too
> late
> > >> to make it in 22.11, so I will not complain loudly if you choose
> to
> > >>> omit it for 22.11.
> > >>>>>
> > >>>>> With two independent reviews, including from a mempool
> > >> maintainer, I still have some hope. Also considering the risk
> > >> assessment
> > >>> below. ;-)
> > >>>>>
> > >>>>>> Please tell what is the benefit for 22.11 (before/after and
> > >> condition).
> > >>>>>
> > >>>>> Short version: With this series, mempool statistics can be used
> > >> in production. Without it, the performance cost
> > >>> (mempool_perf_autotest: -74 %) is prohibitive!
> > >>>>>
> > >>>>> Long version:
> > >>>>>
> > >>>>> The patch series provides significantly higher performance for
> > >> mempool statistics, which are readable through
> > >>> rte_mempool_dump(FILE *f, struct rte_mempool *mp).
> > >>>>>
> > >>>>> Without this series, you have to set RTE_LIBRTE_MEMPOOL_DEBUG
> at
> > >> build time to get mempool statistics.
> > >>> RTE_LIBRTE_MEMPOOL_DEBUG also enables protective cookies before
> and
> > >> after each mempool object, which are all verified on
> > >>> get/put from the mempool. According to mempool_perf_autotest, the
> > >> performance cost of mempool statistics (by setting
> > >>> RTE_LIBRTE_MEMPOOL_DEBUG) is a 74 % decrease in rate_persec for
> > >> mempools with cache (i.e. mbuf pools). Prohibitive for use in
> > >>> production!
> > >>>>>
> > >>>>> With this series, the performance cost of mempool statistics
> (by
> > >> setting RTE_LIBRTE_MEMPOOL_STATS) in
> > >>> mempool_perf_autotest is only 6.7 %, so mempool statistics can be
> > >> used in production.
> > >>>>>
> > >>>>>> Note there is a real risk doing such change that late.
> > >>>>>
> > >>>>> Risk assessment:
> > >>>>>
> > >>>>> The patch series has zero effect unless either
> > >> RTE_LIBRTE_MEMPOOL_DEBUG or RTE_LIBRTE_MEMPOOL_STATS are set when
> > >>> building. They are not set in the default build.
> > >>>>
> > >>>> If theses build flags are not set, there is no risk and no
> benefit.
> > >>>> But if they are set, there is a risk of regression,
> > >>>> for the benefit of an increased performance of a debug feature.
> > >>>> I would say it is better to avoid any functional regression in a
> > >> debug feature
> > >>>> at this stage.
> > >>>> Any other opinion?
> > >>>>
> > >>> While I agree that we should avoid any functional regression, I
> > >> wonder how
> > >>> widely used the debug feature is, and how big the risk of a
> > >> regression is?
> > >>> Even if there is one, having a regression in a debug feature is a
> lot
> > >> less
> > >>> serious than having one in something which goes into production.
> > >>>
> > >>
> > >> Unless it introduces an ABI breakage (as I understand it doesn't),
> I'll
> > >> wait till 23.03.
> > >> Just in case.
> > >
> > > If built (both before and after this series) without
> RTE_LIBRTE_MEMPOOL_DEBUG (and without RTE_LIBRTE_MEMPOOL_STATS,
> > which is introduced by the series), there is no ABI breakage.
> > >
> > > If built (both before and after this series) with
> RTE_LIBRTE_MEMPOOL_DEBUG (and without RTE_LIBRTE_MEMPOOL_STATS), the
> > ABI differs between before and after this series: The stats array
> disappears from struct rte_mempool, and the output from
> > rte_mempool_dump() does not include the statistics.
> > >
>
> Can we probably always enable RTE_LIBRTE_MEMPOOL_STATS when
> RTE_LIBRTE_MEMPOOL_DEBUG is on?
That would fix the rte_mempool_dump() API breakage, yes.
But since it's only a partial fix, I don't think we should do it.
>
> > > If built (both before and after this series) with
> RTE_LIBRTE_MEMPOOL_DEBUG (and with RTE_LIBRTE_MEMPOOL_STATS), the ABI
> > also differs between before and after this series: The size of the
> stats array in struct rte_mempool grows by one element.
>
> Ah yes, missed that one.
> So the question is then - does it count as formal ABI breakage or not?
Yes, this is a key question!
However, performance improvements are not accepted as LTS patches, so not including it in -rc3 will make it useless until 23.11. (At least for users deploying only LTS releases.)
> If yes, then probably better to go ahead with these changes for 22.11
> (it sounds too prohibitive to wait for an year here).
> Or at least take in the part that introduce the ABI breakage.
Without the 3rd patch in the series, the performance is not fully optimized. (Remember: Only relevant when built with RTE_LIBRTE_MEMPOOL_STATS.)
> If not, probably not bit deal to wait till 23.03.
>
> > >> BTW, as a side thought - if the impact is really that small now,
> would
> > >> it make sense to make
> > >> it run-time option, instead of compile-time one?
> > >
> > > The mempool get/put functions are very lean when built without
> STATS or DEBUG. With a runtime option, the resulting code would
> > be slightly longer, and only one additional conditional would be hit
> in the common case (i.e. when the objects don't miss the mempool
> > cache). So with stats disabled (at runtime), it would only add a very
> small performance cost. However, checking the value of the
> > enabled/disabled variable can cause a CPU cache miss, which has a
> performance cost. And the enabled/disabled variable should
> > definitely be global - if it is per mempool, it will cause many CPU
> cache misses (because the common case doesn't touch the mempool
> > structure, only the mempool cache structure).
> > >
>
> Yes, either a global one, or put it into both structs:
> rte_mempool_cache and rte_mempool.
That is doable. There is room for it in rte_mempool_cache, and it can be a flag in rte_mempool.
>
> > It's not totally obvious that a conditional is better than just
> always
> > performing these simple arithmetic operations, even if you don't know
> if
> > you need the result (i.e., if stats is enabled or not), especially
> since
> > they operate on a cache line that is very likely already owned by the
> > core running the core (since the 'len' fields is frequently used).
>
> Yep, that's another option - always update the cache part.
Yes, always updating the rte_mempool_cache stats to avoid the conditional in the likely code path seems like a viable concept.
(And for now, we can ignore that 64 bit stats are somewhat more costly on 32 bit architectures if tearing must be avoided. I say that we can ignore it for now, because this kind of tearing is ignored for 64 bit stats everywhere in DPDK, so it should be ignorable here too.)
>
> > > Also, checking the runtime option should have unlikely(), so the
> performance cost of the stats (when enabled at runtime) is also
> > higher than with a build time option. (Yes, dynamic branch prediction
> will alleviate most of this, but it will consume entries in the
> > branch predictor table - these are inlined functions. Just like we
> always try to avoid cache misses in DPDK, we should also try to
> > conserve branch predictor table entries. I hate the argument that
> branch prediction fixes conditionals, especially if they are weird or
> > could have been avoided.)
> > >
> > > In the cost/benefit analysis, we need to consider that these
> statistics are not fill/emptiness level status or similar, but only
> debug
> > counters (number of get/put transactions and objects), so we need to
> ask ourselves this question: How many users are interested in
> > these statistics for production and are unable to build their
> application with RTE_LIBRTE_MEMPOOL_STATS?
>
> Obviously, I don't have such stats.
> From my perspective - I am ok to spend few extra cycles to avoid
> building separate binary.
> Again, I guess that with global switch the impact will be negligible.
> But anyway, it will require even more changes and another ABI breakage
> (as stats should always be included),
> so it definitely out of scope for this release.
Agree. This series can be tweaked further, as the discussion clearly shows.
However, time is about to run out on. If we want to include it 22.11, we should take it into -rc3 without any of the discussed modifications (except fixing the macro to satisfy checkpatch).
Furthermore, the discussed modifications - various ways of handling a runtime option - will introduce some performance degradation with the default build configuration. Regardless how small we think the performance degradation is, I would hesitate to introduce a performance degradation in -rc3.
The current patch series has zero performance effect with the default build configuration.
>
> > > For example, we (SmartShare Systems) are only interested in them
> for application profiling purposes... trying to improve the
> > performance by striving for a higher number of objects per burst in
> every pipeline stage.
> > >
> > >> Konstantin
^ permalink raw reply [relevance 0%]
* RE: [RFC] mempool: zero-copy cache put bulk
@ 2022-11-09 17:57 3% ` Honnappa Nagarahalli
2022-11-09 20:36 0% ` Morten Brørup
0 siblings, 1 reply; 200+ results
From: Honnappa Nagarahalli @ 2022-11-09 17:57 UTC (permalink / raw)
To: Morten Brørup, dev, olivier.matz, andrew.rybchenko,
Kamalakshitha Aligeri
Cc: nd, nd
<snip>
>
> > From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com]
> > Sent: Sunday, 6 November 2022 00.11
> >
> > + Akshitha, she is working on similar patch
> >
> > Few comments inline
> >
> > > From: Morten Brørup <mb@smartsharesystems.com>
> > > Sent: Saturday, November 5, 2022 8:40 AM
> > >
> > > Zero-copy access to the mempool cache is beneficial for PMD
> > performance,
> > > and must be provided by the mempool library to fix [Bug 1052]
> > > without
> > a
> > > performance regression.
> > >
> > > [Bug 1052]: https://bugs.dpdk.org/show_bug.cgi?id=1052
> > >
> > >
> > > This RFC offers a conceptual zero-copy put function, where the
> > application
> > > promises to store some objects, and in return gets an address where
> > to store
> > > them.
> > >
> > > I would like some early feedback.
> > >
> > > Notes:
> > > * Allowing the 'cache' parameter to be NULL, and getting it from the
> > > mempool instead, was inspired by rte_mempool_cache_flush().
> > I am not sure why the 'cache' parameter is required for this API. This
> > API should take the mem pool as the parameter.
> >
> > We have based our API on 'rte_mempool_do_generic_put' and removed
> the
> > 'cache' parameter.
>
> I thoroughly considered omitting the 'cache' parameter, but included it for
> two reasons:
>
> 1. The function is a "mempool cache" function (i.e. primarily working on the
> mempool cache), not a "mempool" function.
>
> So it is appropriate to have a pointer directly to the structure it is working on.
> Following this through, I also made 'cache' the first parameter and 'mp' the
> second, like in rte_mempool_cache_flush().
I am wondering if the PMD should be aware of the cache or not. For ex: in the case of pipeline mode, the RX and TX side of the PMD are running on different cores.
However, since the rte_mempool_cache_flush API is provided, may be that decision is already done? Interestingly, rte_mempool_cache_flush is called by just a single PMD.
So, the question is, should we allow zero-copy only for per-core cache or for other cases as well.
>
> 2. In most cases, the function only accesses the mempool structure in order to
> get the cache pointer. Skipping this step improves performance.
>
> And since the cache is created along with the mempool itself (and thus never
> changes for a mempool), it would be safe for the PMD to store the 'cache'
> pointer along with the 'mp' pointer in the PMD's queue structure.
Agreed
>
> E.g. in the i40e PMD the i40e_rx_queue structure could include a "struct
> rte_mempool_cache *cache" field, which could be used i40e_rxq_rearm() [1]
> instead of "cache = rte_mempool_default_cache(rxq->mp, rte_lcore_id())".
>
> [1] https://elixir.bootlin.com/dpdk/v22.11-
> rc2/source/drivers/net/i40e/i40e_rxtx_vec_avx512.c#L31
>
> > This new API, on success, returns the pointer to memory where the
> > objects are copied. On failure it returns NULL and the caller has to
> > call 'rte_mempool_ops_enqueue_bulk'. Alternatively, the new API could
> > do this as well and PMD does not need to do anything if it gets a NULL
> > pointer.
>
> Yes, we agree about these two details:
>
> 1. The function should return a pointer, not an integer.
> It would be a waste to use a another CPU register to convey a success/error
> integer value, when the success/failure information is just as easily conveyed
> by the pointer return value (non-NULL/NULL), and rte_errno for various error
> values in the unlikely cases.
>
> 2. The function should leave it up to the PMD what to do if direct access to
> the cache is unavailable.
Just wondering about the advantage of this. I do not think PMD's have much of a choice other than calling 'rte_mempool_ops_enqueue_bulk'
>
> >
> > We should think about providing similar API on the RX side to keep it
> > symmetric.
>
> I sent an RFC for that too:
> http://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35D87488@
> smartserver.smartshare.dk/T/#u
>
>
> >
> > > * Asserting that the 'mp' parameter is not NULL is not done by other
> > > functions, so I omitted it here too.
> > >
> > > NB: Please ignore formatting. Also, this code has not even been
> > compile
> > > tested.
> > We are little bit ahead, tested the changes with i40e PF PMD, wrote
> > unit test cases, going through internal review, will send out RFC on
> > Monday
>
> Sounds good. Looking forward to review.
>
> >
> > >
> > > /**
> > > * Promise to put objects in a mempool via zero-copy access to a
> > user-owned
> > > mempool cache.
> > > *
> > > * @param cache
> > > * A pointer to the mempool cache.
> > > * @param mp
> > > * A pointer to the mempool.
> > > * @param n
> > > * The number of objects to be put in the mempool cache.
> > > * @return
> > > * The pointer to where to put the objects in the mempool cache.
> > > * NULL on error
> > > * with rte_errno set appropriately.
> > > */
> > > static __rte_always_inline void *
> > > rte_mempool_cache_put_bulk_promise(struct rte_mempool_cache
> *cache,
> > > struct rte_mempool *mp,
> > > unsigned int n)
> > > {
> > > void **cache_objs;
> > >
> > > if (cache == NULL)
> > > cache = rte_mempool_default_cache(mp, rte_lcore_id());
Any reason we need this? If we are expecting the PMD to store the pointer to cache and a NULL is passed, it would mean it is a mempool with no per-core cache?
We could also leave the NULL check to the PMD.
> > > if (cache == NULL) {
> > > rte_errno = EINVAL;
> > > return NULL;
> > > }
> > >
> > > rte_mempool_trace_cache_put_bulk_promise(cache, mp, n);
> > >
> > > /* The request itself is too big for the cache */
> > > if (unlikely(n > cache->flushthresh)) {
> > > rte_errno = EINVAL;
> > > return NULL;
> > > }
> > >
> > > /*
> > > * The cache follows the following algorithm:
> > > * 1. If the objects cannot be added to the cache without
> > crossing
> > > * the flush threshold, flush the cache to the backend.
> > > * 2. Add the objects to the cache.
> > > */
> > >
> > > if (cache->len + n <= cache->flushthresh) {
> > > cache_objs = &cache->objs[cache->len];
> > > cache->len += n;
> > > } else {
> > > cache_objs = &cache->objs[0];
> > > rte_mempool_ops_enqueue_bulk(mp, cache_objs, cache->len);
> > > cache->len = n;
> > > }
> > >
> > > RTE_MEMPOOL_CACHE_STAT_ADD(cache, put_bulk, 1);
> > > RTE_MEMPOOL_CACHE_STAT_ADD(cache, put_objs, n);
These are new stats. Do these break ABI compatibility (though these are under DEBUG flag)?
> > >
> > > return cache_objs;
> > > }
> > >
> > >
> > > Med venlig hilsen / Kind regards,
> > > -Morten Brørup
> > >
> >
^ permalink raw reply [relevance 3%]
* RE: [RFC] mempool: zero-copy cache put bulk
2022-11-09 17:57 3% ` Honnappa Nagarahalli
@ 2022-11-09 20:36 0% ` Morten Brørup
2022-11-09 22:45 0% ` Honnappa Nagarahalli
0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2022-11-09 20:36 UTC (permalink / raw)
To: Honnappa Nagarahalli, dev, olivier.matz, andrew.rybchenko,
Kamalakshitha Aligeri, Bruce Richardson
Cc: nd
+To: Bruce also showed interest in this topic, and might have more insights.
> From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com]
> Sent: Wednesday, 9 November 2022 18.58
>
> <snip>
>
> >
> > > From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com]
> > > Sent: Sunday, 6 November 2022 00.11
> > >
> > > + Akshitha, she is working on similar patch
> > >
> > > Few comments inline
> > >
> > > > From: Morten Brørup <mb@smartsharesystems.com>
> > > > Sent: Saturday, November 5, 2022 8:40 AM
> > > >
> > > > Zero-copy access to the mempool cache is beneficial for PMD
> > > performance,
> > > > and must be provided by the mempool library to fix [Bug 1052]
> > > > without
> > > a
> > > > performance regression.
> > > >
> > > > [Bug 1052]: https://bugs.dpdk.org/show_bug.cgi?id=1052
> > > >
> > > >
> > > > This RFC offers a conceptual zero-copy put function, where the
> > > application
> > > > promises to store some objects, and in return gets an address
> where
> > > to store
> > > > them.
> > > >
> > > > I would like some early feedback.
> > > >
> > > > Notes:
> > > > * Allowing the 'cache' parameter to be NULL, and getting it from
> the
> > > > mempool instead, was inspired by rte_mempool_cache_flush().
> > > I am not sure why the 'cache' parameter is required for this API.
> This
> > > API should take the mem pool as the parameter.
> > >
> > > We have based our API on 'rte_mempool_do_generic_put' and removed
> > the
> > > 'cache' parameter.
> >
> > I thoroughly considered omitting the 'cache' parameter, but included
> it for
> > two reasons:
> >
> > 1. The function is a "mempool cache" function (i.e. primarily working
> on the
> > mempool cache), not a "mempool" function.
> >
> > So it is appropriate to have a pointer directly to the structure it
> is working on.
> > Following this through, I also made 'cache' the first parameter and
> 'mp' the
> > second, like in rte_mempool_cache_flush().
> I am wondering if the PMD should be aware of the cache or not. For ex:
> in the case of pipeline mode, the RX and TX side of the PMD are running
> on different cores.
In that example, the PMD can store two cache pointers, one for each of the RX and TX side.
And if the PMD is unaware of the cache pointer, it can look it up at runtime using rte_lcore_id(), like it does in the current Intel PMDs.
> However, since the rte_mempool_cache_flush API is provided, may be that
> decision is already done? Interestingly, rte_mempool_cache_flush is
> called by just a single PMD.
I intentionally aligned this RFC with rte_mempool_cache_flush() to maintain consistency.
However, the API is not set in stone. It should always be acceptable to consider improved alternatives.
>
> So, the question is, should we allow zero-copy only for per-core cache
> or for other cases as well.
I suppose that the mempool library was designed to have a mempool associated with exactly one mempool cache per core. (Alternatively, the mempool can be configured with no mempool caches at all.)
We should probably stay loyal to that design concept, and only allow zero-copy for per-core cache.
If you can come up with an example of the opposite, I would like to explore that option too... I can't think of a good example myself, and perhaps I'm overlooking a relevant use case.
>
> >
> > 2. In most cases, the function only accesses the mempool structure in
> order to
> > get the cache pointer. Skipping this step improves performance.
> >
> > And since the cache is created along with the mempool itself (and
> thus never
> > changes for a mempool), it would be safe for the PMD to store the
> 'cache'
> > pointer along with the 'mp' pointer in the PMD's queue structure.
> Agreed
>
> >
> > E.g. in the i40e PMD the i40e_rx_queue structure could include a
> "struct
> > rte_mempool_cache *cache" field, which could be used i40e_rxq_rearm()
> [1]
> > instead of "cache = rte_mempool_default_cache(rxq->mp,
> rte_lcore_id())".
> >
> > [1] https://elixir.bootlin.com/dpdk/v22.11-
> > rc2/source/drivers/net/i40e/i40e_rxtx_vec_avx512.c#L31
> >
> > > This new API, on success, returns the pointer to memory where the
> > > objects are copied. On failure it returns NULL and the caller has
> to
> > > call 'rte_mempool_ops_enqueue_bulk'. Alternatively, the new API
> could
> > > do this as well and PMD does not need to do anything if it gets a
> NULL
> > > pointer.
> >
> > Yes, we agree about these two details:
> >
> > 1. The function should return a pointer, not an integer.
> > It would be a waste to use a another CPU register to convey a
> success/error
> > integer value, when the success/failure information is just as easily
> conveyed
> > by the pointer return value (non-NULL/NULL), and rte_errno for
> various error
> > values in the unlikely cases.
> >
> > 2. The function should leave it up to the PMD what to do if direct
> access to
> > the cache is unavailable.
> Just wondering about the advantage of this. I do not think PMD's have
> much of a choice other than calling 'rte_mempool_ops_enqueue_bulk'
I agree, but that was not my point. Let me try to rephrase:
The PMD is more likely to know how to efficiently build the array of mbufs to pass to rte_mempool_ops_enqueue_bulk() than the mempool library - many PMDs already implement a variety of vector instruction variants to do exactly that. So we should not try to be clever and add a fallback path - this job belongs in the PMD.
The PMD might not even have the array of mbufs lined up when calling rte_mempool_cache_put_bulk_promise(). The PMD could have an array of internal structures, where the mbuf pointer is an element in that structure.
>
> >
> > >
> > > We should think about providing similar API on the RX side to keep
> it
> > > symmetric.
> >
> > I sent an RFC for that too:
> > http://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35D87488@
> > smartserver.smartshare.dk/T/#u
> >
> >
> > >
> > > > * Asserting that the 'mp' parameter is not NULL is not done by
> other
> > > > functions, so I omitted it here too.
> > > >
> > > > NB: Please ignore formatting. Also, this code has not even been
> > > compile
> > > > tested.
> > > We are little bit ahead, tested the changes with i40e PF PMD, wrote
> > > unit test cases, going through internal review, will send out RFC
> on
> > > Monday
> >
> > Sounds good. Looking forward to review.
> >
> > >
> > > >
> > > > /**
> > > > * Promise to put objects in a mempool via zero-copy access to a
> > > user-owned
> > > > mempool cache.
> > > > *
> > > > * @param cache
> > > > * A pointer to the mempool cache.
> > > > * @param mp
> > > > * A pointer to the mempool.
> > > > * @param n
> > > > * The number of objects to be put in the mempool cache.
> > > > * @return
> > > > * The pointer to where to put the objects in the mempool
> cache.
> > > > * NULL on error
> > > > * with rte_errno set appropriately.
> > > > */
> > > > static __rte_always_inline void *
> > > > rte_mempool_cache_put_bulk_promise(struct rte_mempool_cache
> > *cache,
> > > > struct rte_mempool *mp,
> > > > unsigned int n)
> > > > {
> > > > void **cache_objs;
> > > >
> > > > if (cache == NULL)
> > > > cache = rte_mempool_default_cache(mp, rte_lcore_id());
> Any reason we need this? If we are expecting the PMD to store the
> pointer to cache and a NULL is passed, it would mean it is a mempool
> with no per-core cache?
> We could also leave the NULL check to the PMD.
Personally, I would strongly prefer requiring the cache pointer to be valid, and use RTE_ASSERT() here, instead of allowing a NULL pointer as a special case to look it up inside the function. I consider this special NULL case useless bloat, which does not belong in a fast path library function.
But I copied this approach from rte_mempool_cache_flush().
We could expose an "unsafe" function where is not allowed to pass NULL pointers, and a "safe" function (fixing the cache pointer if NULL) for consistency.
If the rte_mempool_cache_flush() function is popular, we could also expose an "unsafe" variant where passing NULL pointers are disallowed.
I wonder if there are any examples of such safe/unsafe variants in DPDK? It would be nice with a common naming convention for such function variants.
>
> > > > if (cache == NULL) {
> > > > rte_errno = EINVAL;
> > > > return NULL;
> > > > }
> > > >
> > > > rte_mempool_trace_cache_put_bulk_promise(cache, mp, n);
> > > >
> > > > /* The request itself is too big for the cache */
> > > > if (unlikely(n > cache->flushthresh)) {
> > > > rte_errno = EINVAL;
> > > > return NULL;
> > > > }
> > > >
> > > > /*
> > > > * The cache follows the following algorithm:
> > > > * 1. If the objects cannot be added to the cache without
> > > crossing
> > > > * the flush threshold, flush the cache to the backend.
> > > > * 2. Add the objects to the cache.
> > > > */
> > > >
> > > > if (cache->len + n <= cache->flushthresh) {
> > > > cache_objs = &cache->objs[cache->len];
> > > > cache->len += n;
> > > > } else {
> > > > cache_objs = &cache->objs[0];
> > > > rte_mempool_ops_enqueue_bulk(mp, cache_objs, cache->len);
> > > > cache->len = n;
> > > > }
> > > >
> > > > RTE_MEMPOOL_CACHE_STAT_ADD(cache, put_bulk, 1);
> > > > RTE_MEMPOOL_CACHE_STAT_ADD(cache, put_objs, n);
> These are new stats. Do these break ABI compatibility (though these are
> under DEBUG flag)?
They are not mempool cache stats, they are only kept in the cache structure to provide alternative (i.e. faster) update access to some (i.e. the most often updated) of the existing mempool stats. The patch is [1], and part of a series currently being discussed if should go into 22.11-rc3 or not [2].
[1]: https://patchwork.dpdk.org/project/dpdk/patch/20221109181852.109856-3-mb@smartsharesystems.com/
[2]: http://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35D874A6@smartserver.smartshare.dk/T/#m41bf4e8bd886db49f11c8dbd63741b353277082f
>
> > > >
> > > > return cache_objs;
> > > > }
> > > >
> > > >
> > > > Med venlig hilsen / Kind regards,
> > > > -Morten Brørup
> > > >
> > >
>
^ permalink raw reply [relevance 0%]
* RE: [RFC] mempool: zero-copy cache put bulk
2022-11-09 20:36 0% ` Morten Brørup
@ 2022-11-09 22:45 0% ` Honnappa Nagarahalli
2022-11-10 10:15 0% ` Morten Brørup
0 siblings, 1 reply; 200+ results
From: Honnappa Nagarahalli @ 2022-11-09 22:45 UTC (permalink / raw)
To: Morten Brørup, dev, olivier.matz, andrew.rybchenko,
Kamalakshitha Aligeri, Bruce Richardson
Cc: nd, nd
<snip>
>
> +To: Bruce also showed interest in this topic, and might have more insights.
>
> > From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com]
> > Sent: Wednesday, 9 November 2022 18.58
> >
> > <snip>
> >
> > >
> > > > From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com]
> > > > Sent: Sunday, 6 November 2022 00.11
> > > >
> > > > + Akshitha, she is working on similar patch
> > > >
> > > > Few comments inline
> > > >
> > > > > From: Morten Brørup <mb@smartsharesystems.com>
> > > > > Sent: Saturday, November 5, 2022 8:40 AM
> > > > >
> > > > > Zero-copy access to the mempool cache is beneficial for PMD
> > > > performance,
> > > > > and must be provided by the mempool library to fix [Bug 1052]
> > > > > without
> > > > a
> > > > > performance regression.
> > > > >
> > > > > [Bug 1052]: https://bugs.dpdk.org/show_bug.cgi?id=1052
> > > > >
> > > > >
> > > > > This RFC offers a conceptual zero-copy put function, where the
> > > > application
> > > > > promises to store some objects, and in return gets an address
> > where
> > > > to store
> > > > > them.
> > > > >
> > > > > I would like some early feedback.
> > > > >
> > > > > Notes:
> > > > > * Allowing the 'cache' parameter to be NULL, and getting it from
> > the
> > > > > mempool instead, was inspired by rte_mempool_cache_flush().
> > > > I am not sure why the 'cache' parameter is required for this API.
> > This
> > > > API should take the mem pool as the parameter.
> > > >
> > > > We have based our API on 'rte_mempool_do_generic_put' and removed
> > > the
> > > > 'cache' parameter.
> > >
> > > I thoroughly considered omitting the 'cache' parameter, but included
> > it for
> > > two reasons:
> > >
> > > 1. The function is a "mempool cache" function (i.e. primarily
> > > working
> > on the
> > > mempool cache), not a "mempool" function.
> > >
> > > So it is appropriate to have a pointer directly to the structure it
> > is working on.
> > > Following this through, I also made 'cache' the first parameter and
> > 'mp' the
> > > second, like in rte_mempool_cache_flush().
> > I am wondering if the PMD should be aware of the cache or not. For ex:
> > in the case of pipeline mode, the RX and TX side of the PMD are
> > running on different cores.
>
> In that example, the PMD can store two cache pointers, one for each of the
> RX and TX side.
I did not understand this. If RX core and TX core have their own per-core caches the logic would not work. For ex: the RX core cache would not get filled.
In the case of pipeline mode, there will not be a per-core cache. The buffers would be allocated and freed from a global ring or a global lockless stack.
>
> And if the PMD is unaware of the cache pointer, it can look it up at runtime
> using rte_lcore_id(), like it does in the current Intel PMDs.
>
> > However, since the rte_mempool_cache_flush API is provided, may be
> > that decision is already done? Interestingly, rte_mempool_cache_flush
> > is called by just a single PMD.
>
> I intentionally aligned this RFC with rte_mempool_cache_flush() to maintain
> consistency.
>
> However, the API is not set in stone. It should always be acceptable to
> consider improved alternatives.
>
> >
> > So, the question is, should we allow zero-copy only for per-core cache
> > or for other cases as well.
>
> I suppose that the mempool library was designed to have a mempool
> associated with exactly one mempool cache per core. (Alternatively, the
> mempool can be configured with no mempool caches at all.)
>
> We should probably stay loyal to that design concept, and only allow zero-
> copy for per-core cache.
>
> If you can come up with an example of the opposite, I would like to explore
> that option too... I can't think of a good example myself, and perhaps I'm
> overlooking a relevant use case.
The use case I am talking about is the pipeline mode as I mentioned above. Let me know if you agree.
>
> >
> > >
> > > 2. In most cases, the function only accesses the mempool structure
> > > in
> > order to
> > > get the cache pointer. Skipping this step improves performance.
> > >
> > > And since the cache is created along with the mempool itself (and
> > thus never
> > > changes for a mempool), it would be safe for the PMD to store the
> > 'cache'
> > > pointer along with the 'mp' pointer in the PMD's queue structure.
> > Agreed
> >
> > >
> > > E.g. in the i40e PMD the i40e_rx_queue structure could include a
> > "struct
> > > rte_mempool_cache *cache" field, which could be used
> > > i40e_rxq_rearm()
> > [1]
> > > instead of "cache = rte_mempool_default_cache(rxq->mp,
> > rte_lcore_id())".
> > >
> > > [1] https://elixir.bootlin.com/dpdk/v22.11-
> > > rc2/source/drivers/net/i40e/i40e_rxtx_vec_avx512.c#L31
> > >
> > > > This new API, on success, returns the pointer to memory where the
> > > > objects are copied. On failure it returns NULL and the caller has
> > to
> > > > call 'rte_mempool_ops_enqueue_bulk'. Alternatively, the new API
> > could
> > > > do this as well and PMD does not need to do anything if it gets a
> > NULL
> > > > pointer.
> > >
> > > Yes, we agree about these two details:
> > >
> > > 1. The function should return a pointer, not an integer.
> > > It would be a waste to use a another CPU register to convey a
> > success/error
> > > integer value, when the success/failure information is just as
> > > easily
> > conveyed
> > > by the pointer return value (non-NULL/NULL), and rte_errno for
> > various error
> > > values in the unlikely cases.
> > >
> > > 2. The function should leave it up to the PMD what to do if direct
> > access to
> > > the cache is unavailable.
> > Just wondering about the advantage of this. I do not think PMD's have
> > much of a choice other than calling 'rte_mempool_ops_enqueue_bulk'
>
> I agree, but that was not my point. Let me try to rephrase:
>
> The PMD is more likely to know how to efficiently build the array of mbufs to
> pass to rte_mempool_ops_enqueue_bulk() than the mempool library - many
> PMDs already implement a variety of vector instruction variants to do exactly
> that. So we should not try to be clever and add a fallback path - this job
> belongs in the PMD.
>
> The PMD might not even have the array of mbufs lined up when calling
> rte_mempool_cache_put_bulk_promise(). The PMD could have an array of
> internal structures, where the mbuf pointer is an element in that structure.
Agree, you are correct. We should leave it to PMD to handle the failure case.
>
> >
> > >
> > > >
> > > > We should think about providing similar API on the RX side to
> > > > keep
> > it
> > > > symmetric.
> > >
> > > I sent an RFC for that too:
> > >
> http://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35D87488@
> > > smartserver.smartshare.dk/T/#u
> > >
> > >
> > > >
> > > > > * Asserting that the 'mp' parameter is not NULL is not done by
> > other
> > > > > functions, so I omitted it here too.
> > > > >
> > > > > NB: Please ignore formatting. Also, this code has not even been
> > > > compile
> > > > > tested.
> > > > We are little bit ahead, tested the changes with i40e PF PMD,
> > > > wrote unit test cases, going through internal review, will send
> > > > out RFC
> > on
> > > > Monday
> > >
> > > Sounds good. Looking forward to review.
> > >
> > > >
> > > > >
> > > > > /**
> > > > > * Promise to put objects in a mempool via zero-copy access to a
> > > > user-owned
> > > > > mempool cache.
> > > > > *
> > > > > * @param cache
> > > > > * A pointer to the mempool cache.
> > > > > * @param mp
> > > > > * A pointer to the mempool.
> > > > > * @param n
> > > > > * The number of objects to be put in the mempool cache.
> > > > > * @return
> > > > > * The pointer to where to put the objects in the mempool
> > cache.
> > > > > * NULL on error
> > > > > * with rte_errno set appropriately.
> > > > > */
> > > > > static __rte_always_inline void *
> > > > > rte_mempool_cache_put_bulk_promise(struct rte_mempool_cache
> > > *cache,
> > > > > struct rte_mempool *mp,
> > > > > unsigned int n)
> > > > > {
> > > > > void **cache_objs;
> > > > >
> > > > > if (cache == NULL)
> > > > > cache = rte_mempool_default_cache(mp, rte_lcore_id());
> > Any reason we need this? If we are expecting the PMD to store the
> > pointer to cache and a NULL is passed, it would mean it is a mempool
> > with no per-core cache?
> > We could also leave the NULL check to the PMD.
>
> Personally, I would strongly prefer requiring the cache pointer to be valid,
> and use RTE_ASSERT() here, instead of allowing a NULL pointer as a special
> case to look it up inside the function. I consider this special NULL case useless
> bloat, which does not belong in a fast path library function.
>
> But I copied this approach from rte_mempool_cache_flush().
The API definition does not bind it to do this check. We might be able to delete the check in rte_mempool_cache_flush.
>
> We could expose an "unsafe" function where is not allowed to pass NULL
> pointers, and a "safe" function (fixing the cache pointer if NULL) for
> consistency.
>
> If the rte_mempool_cache_flush() function is popular, we could also expose
> an "unsafe" variant where passing NULL pointers are disallowed.
>
> I wonder if there are any examples of such safe/unsafe variants in DPDK? It
> would be nice with a common naming convention for such function variants.
>
> >
> > > > > if (cache == NULL) {
> > > > > rte_errno = EINVAL;
> > > > > return NULL;
> > > > > }
> > > > >
> > > > > rte_mempool_trace_cache_put_bulk_promise(cache, mp, n);
> > > > >
> > > > > /* The request itself is too big for the cache */
> > > > > if (unlikely(n > cache->flushthresh)) {
> > > > > rte_errno = EINVAL;
> > > > > return NULL;
> > > > > }
> > > > >
> > > > > /*
> > > > > * The cache follows the following algorithm:
> > > > > * 1. If the objects cannot be added to the cache without
> > > > crossing
> > > > > * the flush threshold, flush the cache to the backend.
> > > > > * 2. Add the objects to the cache.
> > > > > */
> > > > >
> > > > > if (cache->len + n <= cache->flushthresh) {
> > > > > cache_objs = &cache->objs[cache->len];
> > > > > cache->len += n;
> > > > > } else {
> > > > > cache_objs = &cache->objs[0];
> > > > > rte_mempool_ops_enqueue_bulk(mp, cache_objs, cache->len);
> > > > > cache->len = n;
> > > > > }
> > > > >
> > > > > RTE_MEMPOOL_CACHE_STAT_ADD(cache, put_bulk, 1);
> > > > > RTE_MEMPOOL_CACHE_STAT_ADD(cache, put_objs, n);
> > These are new stats. Do these break ABI compatibility (though these
> > are under DEBUG flag)?
>
> They are not mempool cache stats, they are only kept in the cache structure
> to provide alternative (i.e. faster) update access to some (i.e. the most often
> updated) of the existing mempool stats. The patch is [1], and part of a series
> currently being discussed if should go into 22.11-rc3 or not [2].
>
> [1]:
> https://patchwork.dpdk.org/project/dpdk/patch/20221109181852.109856-3-
> mb@smartsharesystems.com/
> [2]:
> http://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35D874A6
> @smartserver.smartshare.dk/T/#m41bf4e8bd886db49f11c8dbd63741b35327
> 7082f
>
> >
> > > > >
> > > > > return cache_objs;
> > > > > }
> > > > >
> > > > >
> > > > > Med venlig hilsen / Kind regards, -Morten Brørup
> > > > >
> > > >
> >
^ permalink raw reply [relevance 0%]
* RE: [RFC] mempool: zero-copy cache put bulk
2022-11-09 22:45 0% ` Honnappa Nagarahalli
@ 2022-11-10 10:15 0% ` Morten Brørup
0 siblings, 0 replies; 200+ results
From: Morten Brørup @ 2022-11-10 10:15 UTC (permalink / raw)
To: Honnappa Nagarahalli, dev, olivier.matz, andrew.rybchenko,
Kamalakshitha Aligeri, Bruce Richardson
Cc: nd, nd
> From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com]
> Sent: Wednesday, 9 November 2022 23.46
> >
> > +To: Bruce also showed interest in this topic, and might have more
> insights.
> >
> > > From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com]
> > > Sent: Wednesday, 9 November 2022 18.58
> > >
> > > <snip>
> > >
> > > >
> > > > > From: Honnappa Nagarahalli
> [mailto:Honnappa.Nagarahalli@arm.com]
> > > > > Sent: Sunday, 6 November 2022 00.11
> > > > >
> > > > > + Akshitha, she is working on similar patch
> > > > >
> > > > > Few comments inline
> > > > >
> > > > > > From: Morten Brørup <mb@smartsharesystems.com>
> > > > > > Sent: Saturday, November 5, 2022 8:40 AM
> > > > > >
> > > > > > Zero-copy access to the mempool cache is beneficial for PMD
> > > > > performance,
> > > > > > and must be provided by the mempool library to fix [Bug 1052]
> > > > > > without
> > > > > a
> > > > > > performance regression.
> > > > > >
> > > > > > [Bug 1052]: https://bugs.dpdk.org/show_bug.cgi?id=1052
> > > > > >
> > > > > >
> > > > > > This RFC offers a conceptual zero-copy put function, where
> the
> > > > > application
> > > > > > promises to store some objects, and in return gets an address
> > > where
> > > > > to store
> > > > > > them.
> > > > > >
> > > > > > I would like some early feedback.
> > > > > >
> > > > > > Notes:
> > > > > > * Allowing the 'cache' parameter to be NULL, and getting it
> from
> > > the
> > > > > > mempool instead, was inspired by rte_mempool_cache_flush().
> > > > > I am not sure why the 'cache' parameter is required for this
> API.
> > > This
> > > > > API should take the mem pool as the parameter.
> > > > >
> > > > > We have based our API on 'rte_mempool_do_generic_put' and
> removed
> > > > the
> > > > > 'cache' parameter.
> > > >
> > > > I thoroughly considered omitting the 'cache' parameter, but
> included
> > > it for
> > > > two reasons:
> > > >
> > > > 1. The function is a "mempool cache" function (i.e. primarily
> > > > working
> > > on the
> > > > mempool cache), not a "mempool" function.
> > > >
> > > > So it is appropriate to have a pointer directly to the structure
> it
> > > is working on.
> > > > Following this through, I also made 'cache' the first parameter
> and
> > > 'mp' the
> > > > second, like in rte_mempool_cache_flush().
> > > I am wondering if the PMD should be aware of the cache or not. For
> ex:
> > > in the case of pipeline mode, the RX and TX side of the PMD are
> > > running on different cores.
> >
> > In that example, the PMD can store two cache pointers, one for each
> of the
> > RX and TX side.
> I did not understand this. If RX core and TX core have their own per-
> core caches the logic would not work. For ex: the RX core cache would
> not get filled.
>
> In the case of pipeline mode, there will not be a per-core cache. The
> buffers would be allocated and freed from a global ring or a global
> lockless stack.
Aha... Now I understand what you mean: You are referring to use cases where the mempool is configured to *not* have a mempool cache.
For a mempool without a mempool cache, the proposed "mempool cache" zero-copy functions can obviously not be used.
We need "mempool" zero-copy functions for the mempools that have no mempool cache.
However, those functions depend on the mempool's underlying backing store.
E.g. zero-copy access to a ring has certain requirements [1].
[1]: http://doc.dpdk.org/guides/prog_guide/ring_lib.html#ring-peek-zero-copy-api
For a stack, I think it is possible to locklessly zero-copy pop objects. But it is impossible to locklessly zero-copy push elements to a stack; another thread can race to pop some objects from the stack before the pushing thread has finished writing them into the stack.
Furthermore, the ring zero-copy get function cannot return a consecutive array of objects when wrapping, and PMD functions using vector instructions usually rely on handling chunks of e.g. 8 objects.
Just for a second, let me theorize into the absurd: Even worse, if a mempool's underlying backing store does not use an array of pointers as its internal storage structure, it is impossible to use a pointer to an array of pointers for zero-copy transactions. E.g. if the backing store uses a list or a tree structure for its storage, a pointer to somewhere in the list or tree structure is not an array of objects pointers.
Anyway, we could consider designing a generic API for zero-copy mempool get/put; but it should be compatible with all underlying backing stores - or return failure, so the PMD can fall back to the standard functions, if the mempool is in a state where zero-copy access to a contiguous burst cannot be provided. E.g. zero-copy get from a ring can return failure when zero-copy access to the ring is temporarily unavailable due to being at a point where it would wrap.
Here is a conceptual proposal for such an API.
/* Mempool zero-copy transaction state. Opaque outside the mempool API. */
struct rte_mempool_zc_transaction_state {
char opaque[RTE_CACHE_LINE_SIZE];
};
/** Start zero-copy get/put bulk transaction.
*
* @param[in] mp
* Pointer to the mempool.
* @param[out] obj_table_ptr
* Where to store the pointer to
* the zero-copy array of objects in the mempool.
* @param[in] n
* Number of objects in the transaction.
* @param[in] cache
* Pointer to the mempool cache. May be NULL if unknown.
* @param[out] transaction
* Where to store the opaque transaction information.
* Used internally by the mempool library.
* @return
* - 1: Transaction completed;
* '_finish' must not be called.
* - 0: Transaction started;
* '_finish' must be called to complete the transaction.
* - <0: Error; failure code.
*/
static __rte_always_inline int
rte_mempool_get/put_zc_bulk_start(
struct rte_mempool *mp,
void ***obj_table_ptr,
unsigned int n,
struct rte_mempool_cache *cache,
rte_mempool_zc_transaction_state *transaction);
/** Finish zero-copy get/put bulk transaction.
*
* @param[in] mp
* Pointer to mempool.
* @param[in] obj_table_ptr
* Pointer to the zero-copy array of objects in the mempool,
* returned by the 'start' function.
* @param[in] n
* Number of objects in the transaction.
* Must be the same as for the 'start' function.
* @param[in] transaction
* Opaque transaction information,
* returned by the 'start' function.
* Used internally by the mempool library.
*/
static __rte_always_inline void
rte_mempool_get/put_zc_bulk_finish(
struct rte_mempool *mp,
void **obj_table,
unsigned int n,
rte_mempool_zc_transaction_state *transaction);
Note that these are *bulk* functions, so 'n' has to remain the same for a 'finish' call as it was for the 'start' call of a transaction.
And then the underlying backing stores would need to provide callbacks that implement these functions, if they offer zero-copy functionality.
The mempool implementation of these could start by checking for a mempool cache, and use the "mempool cache" zero-copy if present.
Some internal state information (from the mempool library or the underlying mempool backing store) may need to be carried over from the 'start' to the 'finish' function, so I have added a transaction state parameter. The transaction state must be held by the application for thread safety reasons. Think of this like the 'flags' parameter to the Linux kernel's spin_lock_irqsave/irqrestore() functions.
We could omit the 'obj_table' and 'n' parameters from the 'finish' functions and store them in the transaction state if needed; but we might possibly achieve higher performance by passing them as parameters instead.
>
> >
> > And if the PMD is unaware of the cache pointer, it can look it up at
> runtime
> > using rte_lcore_id(), like it does in the current Intel PMDs.
> >
> > > However, since the rte_mempool_cache_flush API is provided, may be
> > > that decision is already done? Interestingly,
> rte_mempool_cache_flush
> > > is called by just a single PMD.
> >
> > I intentionally aligned this RFC with rte_mempool_cache_flush() to
> maintain
> > consistency.
> >
> > However, the API is not set in stone. It should always be acceptable
> to
> > consider improved alternatives.
> >
> > >
> > > So, the question is, should we allow zero-copy only for per-core
> cache
> > > or for other cases as well.
> >
> > I suppose that the mempool library was designed to have a mempool
> > associated with exactly one mempool cache per core. (Alternatively,
> the
> > mempool can be configured with no mempool caches at all.)
> >
> > We should probably stay loyal to that design concept, and only allow
> zero-
> > copy for per-core cache.
> >
> > If you can come up with an example of the opposite, I would like to
> explore
> > that option too... I can't think of a good example myself, and
> perhaps I'm
> > overlooking a relevant use case.
> The use case I am talking about is the pipeline mode as I mentioned
> above. Let me know if you agree.
I see what you mean, and I don't object. :-)
However, I still think the "mempool cache" zero-copy functions could be useful.
They would be needed for the generic "mempool" zero-copy functions anyway.
And the "mempool cache" zero-copy functions are much simpler to design, implement and use than the "mempool" zero-copy functions, so it is a good first step.
>
> >
> > >
> > > >
> > > > 2. In most cases, the function only accesses the mempool
> structure
> > > > in
> > > order to
> > > > get the cache pointer. Skipping this step improves performance.
> > > >
> > > > And since the cache is created along with the mempool itself (and
> > > thus never
> > > > changes for a mempool), it would be safe for the PMD to store the
> > > 'cache'
> > > > pointer along with the 'mp' pointer in the PMD's queue structure.
> > > Agreed
> > >
> > > >
> > > > E.g. in the i40e PMD the i40e_rx_queue structure could include a
> > > "struct
> > > > rte_mempool_cache *cache" field, which could be used
> > > > i40e_rxq_rearm()
> > > [1]
> > > > instead of "cache = rte_mempool_default_cache(rxq->mp,
> > > rte_lcore_id())".
> > > >
> > > > [1] https://elixir.bootlin.com/dpdk/v22.11-
> > > > rc2/source/drivers/net/i40e/i40e_rxtx_vec_avx512.c#L31
> > > >
> > > > > This new API, on success, returns the pointer to memory where
> the
> > > > > objects are copied. On failure it returns NULL and the caller
> has
> > > to
> > > > > call 'rte_mempool_ops_enqueue_bulk'. Alternatively, the new API
> > > could
> > > > > do this as well and PMD does not need to do anything if it gets
> a
> > > NULL
> > > > > pointer.
> > > >
> > > > Yes, we agree about these two details:
> > > >
> > > > 1. The function should return a pointer, not an integer.
> > > > It would be a waste to use a another CPU register to convey a
> > > success/error
> > > > integer value, when the success/failure information is just as
> > > > easily
> > > conveyed
> > > > by the pointer return value (non-NULL/NULL), and rte_errno for
> > > various error
> > > > values in the unlikely cases.
> > > >
> > > > 2. The function should leave it up to the PMD what to do if
> direct
> > > access to
> > > > the cache is unavailable.
> > > Just wondering about the advantage of this. I do not think PMD's
> have
> > > much of a choice other than calling 'rte_mempool_ops_enqueue_bulk'
> >
> > I agree, but that was not my point. Let me try to rephrase:
> >
> > The PMD is more likely to know how to efficiently build the array of
> mbufs to
> > pass to rte_mempool_ops_enqueue_bulk() than the mempool library -
> many
> > PMDs already implement a variety of vector instruction variants to do
> exactly
> > that. So we should not try to be clever and add a fallback path -
> this job
> > belongs in the PMD.
> >
> > The PMD might not even have the array of mbufs lined up when calling
> > rte_mempool_cache_put_bulk_promise(). The PMD could have an array of
> > internal structures, where the mbuf pointer is an element in that
> structure.
> Agree, you are correct. We should leave it to PMD to handle the failure
> case.
>
> >
> > >
> > > >
> > > > >
> > > > > We should think about providing similar API on the RX side to
> > > > > keep
> > > it
> > > > > symmetric.
> > > >
> > > > I sent an RFC for that too:
> > > >
> > http://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35D87488@
> > > > smartserver.smartshare.dk/T/#u
> > > >
> > > >
> > > > >
> > > > > > * Asserting that the 'mp' parameter is not NULL is not done
> by
> > > other
> > > > > > functions, so I omitted it here too.
> > > > > >
> > > > > > NB: Please ignore formatting. Also, this code has not even
> been
> > > > > compile
> > > > > > tested.
> > > > > We are little bit ahead, tested the changes with i40e PF PMD,
> > > > > wrote unit test cases, going through internal review, will send
> > > > > out RFC
> > > on
> > > > > Monday
> > > >
> > > > Sounds good. Looking forward to review.
> > > >
> > > > >
> > > > > >
> > > > > > /**
> > > > > > * Promise to put objects in a mempool via zero-copy access
> to a
> > > > > user-owned
> > > > > > mempool cache.
> > > > > > *
> > > > > > * @param cache
> > > > > > * A pointer to the mempool cache.
> > > > > > * @param mp
> > > > > > * A pointer to the mempool.
> > > > > > * @param n
> > > > > > * The number of objects to be put in the mempool cache.
> > > > > > * @return
> > > > > > * The pointer to where to put the objects in the mempool
> > > cache.
> > > > > > * NULL on error
> > > > > > * with rte_errno set appropriately.
> > > > > > */
> > > > > > static __rte_always_inline void *
> > > > > > rte_mempool_cache_put_bulk_promise(struct rte_mempool_cache
> > > > *cache,
> > > > > > struct rte_mempool *mp,
> > > > > > unsigned int n)
> > > > > > {
> > > > > > void **cache_objs;
> > > > > >
> > > > > > if (cache == NULL)
> > > > > > cache = rte_mempool_default_cache(mp,
> rte_lcore_id());
> > > Any reason we need this? If we are expecting the PMD to store the
> > > pointer to cache and a NULL is passed, it would mean it is a
> mempool
> > > with no per-core cache?
> > > We could also leave the NULL check to the PMD.
> >
> > Personally, I would strongly prefer requiring the cache pointer to be
> valid,
> > and use RTE_ASSERT() here, instead of allowing a NULL pointer as a
> special
> > case to look it up inside the function. I consider this special NULL
> case useless
> > bloat, which does not belong in a fast path library function.
> >
> > But I copied this approach from rte_mempool_cache_flush().
> The API definition does not bind it to do this check. We might be able
> to delete the check in rte_mempool_cache_flush.
>
> >
> > We could expose an "unsafe" function where is not allowed to pass
> NULL
> > pointers, and a "safe" function (fixing the cache pointer if NULL)
> for
> > consistency.
> >
> > If the rte_mempool_cache_flush() function is popular, we could also
> expose
> > an "unsafe" variant where passing NULL pointers are disallowed.
> >
> > I wonder if there are any examples of such safe/unsafe variants in
> DPDK? It
> > would be nice with a common naming convention for such function
> variants.
> >
> > >
> > > > > > if (cache == NULL) {
> > > > > > rte_errno = EINVAL;
> > > > > > return NULL;
> > > > > > }
> > > > > >
> > > > > > rte_mempool_trace_cache_put_bulk_promise(cache, mp, n);
> > > > > >
> > > > > > /* The request itself is too big for the cache */
> > > > > > if (unlikely(n > cache->flushthresh)) {
> > > > > > rte_errno = EINVAL;
> > > > > > return NULL;
> > > > > > }
> > > > > >
> > > > > > /*
> > > > > > * The cache follows the following algorithm:
> > > > > > * 1. If the objects cannot be added to the cache
> without
> > > > > crossing
> > > > > > * the flush threshold, flush the cache to the
> backend.
> > > > > > * 2. Add the objects to the cache.
> > > > > > */
> > > > > >
> > > > > > if (cache->len + n <= cache->flushthresh) {
> > > > > > cache_objs = &cache->objs[cache->len];
> > > > > > cache->len += n;
> > > > > > } else {
> > > > > > cache_objs = &cache->objs[0];
> > > > > > rte_mempool_ops_enqueue_bulk(mp, cache_objs, cache-
> >len);
> > > > > > cache->len = n;
> > > > > > }
> > > > > >
> > > > > > RTE_MEMPOOL_CACHE_STAT_ADD(cache, put_bulk, 1);
> > > > > > RTE_MEMPOOL_CACHE_STAT_ADD(cache, put_objs, n);
> > > These are new stats. Do these break ABI compatibility (though these
> > > are under DEBUG flag)?
> >
> > They are not mempool cache stats, they are only kept in the cache
> structure
> > to provide alternative (i.e. faster) update access to some (i.e. the
> most often
> > updated) of the existing mempool stats. The patch is [1], and part of
> a series
> > currently being discussed if should go into 22.11-rc3 or not [2].
> >
> > [1]:
> > https://patchwork.dpdk.org/project/dpdk/patch/20221109181852.109856-
> 3-
> > mb@smartsharesystems.com/
> > [2]:
> > http://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35D874A6
> > @smartserver.smartshare.dk/T/#m41bf4e8bd886db49f11c8dbd63741b35327
> > 7082f
> >
> > >
> > > > > >
> > > > > > return cache_objs;
> > > > > > }
> > > > > >
> > > > > >
> > > > > > Med venlig hilsen / Kind regards, -Morten Brørup
> > > > > >
> > > > >
> > >
>
^ permalink raw reply [relevance 0%]
* Re: [PATCH] doc: fix typos 'depreciated' instead of 'deprecated'
@ 2022-11-15 16:13 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2022-11-15 16:13 UTC (permalink / raw)
To: Stephen Coleman; +Cc: dev, Ray Kinsella
19/04/2022 17:44, Ray Kinsella:
>
> Stephen Coleman <omegacoleman@gmail.com> writes:
>
> > From 1871ee6f7b98ef89b7c4893d90b5ea264660c201 Mon Sep 17 00:00:00 2001
> > From: youcai <omegacoleman@gmail.com>
> > Date: Tue, 19 Apr 2022 14:38:36 +0800
> > Subject: [PATCH] doc: fix typos 'depreciated' instead of 'deprecated'
> > Cc: Ray Kinsella <mdr@ashroe.eu>
> >
> > Same issue was fixed in ABI policy in ec5c0f8, but more of this
> > misuse persist in comments and docs. 'depreciated' means diminish
> > in value over a period of time. It should not appear here.
> >
> > Signed-off-by: youcai <omegacoleman@gmail.com>
> > ---
> > doc/guides/contributing/abi_policy.rst | 2 +-
> > doc/guides/contributing/abi_versioning.rst | 2 +-
> > lib/kni/rte_kni.h | 4 ++--
> > 3 files changed, 4 insertions(+), 4 deletions(-)
> >
> Acked-by: Ray Kinsella <mdr@ashroe.eu>
Applied, sorry for the delay, the patch was corrupted.
^ permalink raw reply [relevance 0%]
* RE: Regarding User Data in DPDK ACL Library.
@ 2022-11-18 10:30 3% ` Konstantin Ananyev
2022-11-19 13:13 0% ` venkatesh bs
2022-11-21 5:40 0% ` Honnappa Nagarahalli
0 siblings, 2 replies; 200+ results
From: Konstantin Ananyev @ 2022-11-18 10:30 UTC (permalink / raw)
To: Stephen Hemminger, venkatesh bs; +Cc: users, dev
> On Thu, 17 Nov 2022 19:28:12 +0530
> venkatesh bs <venki.bsv@gmail.com> wrote:
>
> > Hi DPDK Team,
> >
> > After the ACL match for highest priority DPDK Classification API returns
> > User Data Which is as mentioned below in the document.
> >
> > 53. Packet Classification and Access Control — Data Plane Development Kit
> > 22.11.0-rc2 documentation (dpdk.org)
> >
> >
> > - *userdata*: A user-defined value. For each category, a successful
> > match returns the userdata field of the highest priority matched rule. When
> > no rules match, returned value is zero
> >
> > I Wonder Why User Data Support does not returns 64 bit values,
As I remember if first version of ACL code it was something about space savings
to improve performance...
Now I think it is more just a historical reason.
It would be good to change userdata to 64bit, but I presume it will be ABI breakage.
> Always its
> > possible that User Data in Application Can be 64bit long, But since 64 bit
> > User data can't be returned by DPDK ACL Library, Application should have
> > the conversion algorithm from 64 to 32 bit during Rule add and vice versa
> > after classification.
> >
> > I Wonder if anyone would have faced this issue, Please suggest any
> > suggestions if somewhere am wrong in understanding/Possible Solution if
> > someone has already gone through this issue.
> >
> > Thanks In Advance.
> > Regards,
> > Venkatesh B Siddappa.
>
> It looks like all users of this API use the userdata to be the index
> into a table of application specific rules.
Yes, that's the most common way.
Another one would be always (build/search) acl rules with two categories:
rule for both categories will be identical, while data different (low/ho 32bits),
but that's a bit too awkward from my perspective.
^ permalink raw reply [relevance 3%]
* Re: Regarding User Data in DPDK ACL Library.
2022-11-18 10:30 3% ` Konstantin Ananyev
@ 2022-11-19 13:13 0% ` venkatesh bs
2022-11-21 5:40 0% ` Honnappa Nagarahalli
1 sibling, 0 replies; 200+ results
From: venkatesh bs @ 2022-11-19 13:13 UTC (permalink / raw)
To: Konstantin Ananyev; +Cc: Stephen Hemminger, users, dev
[-- Attachment #1: Type: text/plain, Size: 2276 bytes --]
Hi konstantin, @stephen@networkplumber.org <stephen@networkplumber.org>
Thanks for the reply and your suggestions. I will try to see what can best
fit into my application.
Thanks & Regards,
Venkatesh.
On Fri, Nov 18, 2022 at 4:01 PM Konstantin Ananyev <
konstantin.ananyev@huawei.com> wrote:
>
>
> > On Thu, 17 Nov 2022 19:28:12 +0530
> > venkatesh bs <venki.bsv@gmail.com> wrote:
> >
> > > Hi DPDK Team,
> > >
> > > After the ACL match for highest priority DPDK Classification API
> returns
> > > User Data Which is as mentioned below in the document.
> > >
> > > 53. Packet Classification and Access Control — Data Plane Development
> Kit
> > > 22.11.0-rc2 documentation (dpdk.org)
> > >
> > >
> > > - *userdata*: A user-defined value. For each category, a successful
> > > match returns the userdata field of the highest priority matched
> rule. When
> > > no rules match, returned value is zero
> > >
> > > I Wonder Why User Data Support does not returns 64 bit values,
>
> As I remember if first version of ACL code it was something about space
> savings
> to improve performance...
> Now I think it is more just a historical reason.
> It would be good to change userdata to 64bit, but I presume it will be ABI
> breakage.
>
> > Always its
> > > possible that User Data in Application Can be 64bit long, But since 64
> bit
> > > User data can't be returned by DPDK ACL Library, Application should
> have
> > > the conversion algorithm from 64 to 32 bit during Rule add and vice
> versa
> > > after classification.
> > >
> > > I Wonder if anyone would have faced this issue, Please suggest any
> > > suggestions if somewhere am wrong in understanding/Possible Solution if
> > > someone has already gone through this issue.
> > >
> > > Thanks In Advance.
> > > Regards,
> > > Venkatesh B Siddappa.
> >
> > It looks like all users of this API use the userdata to be the index
> > into a table of application specific rules.
>
> Yes, that's the most common way.
> Another one would be always (build/search) acl rules with two categories:
> rule for both categories will be identical, while data different (low/ho
> 32bits),
> but that's a bit too awkward from my perspective.
>
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 3115 bytes --]
^ permalink raw reply [relevance 0%]
* RE: Regarding User Data in DPDK ACL Library.
2022-11-18 10:30 3% ` Konstantin Ananyev
2022-11-19 13:13 0% ` venkatesh bs
@ 2022-11-21 5:40 0% ` Honnappa Nagarahalli
2022-11-21 14:15 0% ` Konstantin Ananyev
1 sibling, 1 reply; 200+ results
From: Honnappa Nagarahalli @ 2022-11-21 5:40 UTC (permalink / raw)
To: Konstantin Ananyev, Stephen Hemminger, venkatesh bs; +Cc: users, dev, nd, nd
<snip>
>
>
> > On Thu, 17 Nov 2022 19:28:12 +0530
> > venkatesh bs <venki.bsv@gmail.com> wrote:
> >
> > > Hi DPDK Team,
> > >
> > > After the ACL match for highest priority DPDK Classification API
> > > returns User Data Which is as mentioned below in the document.
> > >
> > > 53. Packet Classification and Access Control — Data Plane
> > > Development Kit
> > > 22.11.0-rc2 documentation (dpdk.org)
> > >
> > >
> > > - *userdata*: A user-defined value. For each category, a successful
> > > match returns the userdata field of the highest priority matched rule.
> When
> > > no rules match, returned value is zero
> > >
> > > I Wonder Why User Data Support does not returns 64 bit values,
>
> As I remember if first version of ACL code it was something about space
> savings to improve performance...
> Now I think it is more just a historical reason.
> It would be good to change userdata to 64bit, but I presume it will be ABI
> breakage.
Agree. We should support 64b and even 128b (since architectures support 128b atomic operations). This reduces required memory barriers required if the data size <= the size of atomic operations.
>
> > Always its
> > > possible that User Data in Application Can be 64bit long, But since
> > > 64 bit User data can't be returned by DPDK ACL Library, Application
> > > should have the conversion algorithm from 64 to 32 bit during Rule
> > > add and vice versa after classification.
> > >
> > > I Wonder if anyone would have faced this issue, Please suggest any
> > > suggestions if somewhere am wrong in understanding/Possible Solution
> > > if someone has already gone through this issue.
> > >
> > > Thanks In Advance.
> > > Regards,
> > > Venkatesh B Siddappa.
> >
> > It looks like all users of this API use the userdata to be the index
> > into a table of application specific rules.
>
> Yes, that's the most common way.
> Another one would be always (build/search) acl rules with two categories:
> rule for both categories will be identical, while data different (low/ho 32bits),
> but that's a bit too awkward from my perspective.
>
>
>
^ permalink raw reply [relevance 0%]
* RE: Regarding User Data in DPDK ACL Library.
2022-11-21 5:40 0% ` Honnappa Nagarahalli
@ 2022-11-21 14:15 0% ` Konstantin Ananyev
2022-11-21 16:56 0% ` Honnappa Nagarahalli
0 siblings, 1 reply; 200+ results
From: Konstantin Ananyev @ 2022-11-21 14:15 UTC (permalink / raw)
To: Honnappa Nagarahalli, Stephen Hemminger, venkatesh bs; +Cc: users, dev, nd, nd
> > > On Thu, 17 Nov 2022 19:28:12 +0530
> > > venkatesh bs <venki.bsv@gmail.com> wrote:
> > >
> > > > Hi DPDK Team,
> > > >
> > > > After the ACL match for highest priority DPDK Classification API
> > > > returns User Data Which is as mentioned below in the document.
> > > >
> > > > 53. Packet Classification and Access Control — Data Plane
> > > > Development Kit
> > > > 22.11.0-rc2 documentation (dpdk.org)
> > > >
> > > >
> > > > - *userdata*: A user-defined value. For each category, a successful
> > > > match returns the userdata field of the highest priority matched rule.
> > When
> > > > no rules match, returned value is zero
> > > >
> > > > I Wonder Why User Data Support does not returns 64 bit values,
> >
> > As I remember if first version of ACL code it was something about space
> > savings to improve performance...
> > Now I think it is more just a historical reason.
> > It would be good to change userdata to 64bit, but I presume it will be ABI
> > breakage.
> Agree. We should support 64b and even 128b (since architectures support 128b atomic operations). This reduces required memory
> barriers required if the data size <= the size of atomic operations.
Hmm... sorry, didn’t get you here.
I do understand the user intention to save pointer to arbitrary memory location as user-data (64-bit).
But how does the size of atomic mem-ops relate?
Konstantin
^ permalink raw reply [relevance 0%]
* RE: Regarding User Data in DPDK ACL Library.
2022-11-21 14:15 0% ` Konstantin Ananyev
@ 2022-11-21 16:56 0% ` Honnappa Nagarahalli
2022-11-22 13:38 0% ` Konstantin Ananyev
0 siblings, 1 reply; 200+ results
From: Honnappa Nagarahalli @ 2022-11-21 16:56 UTC (permalink / raw)
To: Konstantin Ananyev, Stephen Hemminger, venkatesh bs; +Cc: users, dev, nd, nd
<snip>
>
> > > > On Thu, 17 Nov 2022 19:28:12 +0530 venkatesh bs
> > > > <venki.bsv@gmail.com> wrote:
> > > >
> > > > > Hi DPDK Team,
> > > > >
> > > > > After the ACL match for highest priority DPDK Classification API
> > > > > returns User Data Which is as mentioned below in the document.
> > > > >
> > > > > 53. Packet Classification and Access Control — Data Plane
> > > > > Development Kit
> > > > > 22.11.0-rc2 documentation (dpdk.org)
> > > > >
> > > > >
> > > > > - *userdata*: A user-defined value. For each category, a successful
> > > > > match returns the userdata field of the highest priority matched
> rule.
> > > When
> > > > > no rules match, returned value is zero
> > > > >
> > > > > I Wonder Why User Data Support does not returns 64 bit values,
> > >
> > > As I remember if first version of ACL code it was something about
> > > space savings to improve performance...
> > > Now I think it is more just a historical reason.
> > > It would be good to change userdata to 64bit, but I presume it will
> > > be ABI breakage.
> > Agree. We should support 64b and even 128b (since architectures
> > support 128b atomic operations). This reduces required memory barriers
> required if the data size <= the size of atomic operations.
>
> Hmm... sorry, didn’t get you here.
> I do understand the user intention to save pointer to arbitrary memory
> location as user-data (64-bit).
> But how does the size of atomic mem-ops relate?
> Konstantin
What I meant is, if your data fits within 64b or 128b, having another indirection requires:
1) one additional memory operation to store the data (the first one being the store to the index)
2) on the control plane, we would need a release barrier between 'store data' and 'store index' (not a significant issue). On the data plane, we could use relaxed ordering between 'load index' and 'load data', so we do not need a barrier here.
So, looks like there is no barrier over-head on the data plane, but overhead of one additional memory operation.
^ permalink raw reply [relevance 0%]
* [PATCH] net/nfp: update descriptors logic
@ 2022-11-22 13:09 3% Niklas Söderlund
0 siblings, 0 replies; 200+ results
From: Niklas Söderlund @ 2022-11-22 13:09 UTC (permalink / raw)
To: dev; +Cc: oss-drivers, Jin Liu, Chaoyong He, Niklas Söderlund
From: Jin Liu <jin.liu@corigine.com>
The minimum value of TX/RX descriptors for NFP3800 card is not same
with NFP4000 card, the minimum value of NFP4000 card is 256 while
NFP3800 card is 512, add the minimum descriptor macro for NFP3800
card.
Modify the logic of get descriptor value, assign the value of descriptor
for the corresponding network card according to its type.
In TX stage, firmware with NFD3 use one descriptor per packet while
firmware with NFDk use two descriptors. In order to be consistent
with the kernel driver, the number of descriptor of firmware with
NFDk should be divided by 2.
Signed-off-by: Jin Liu <jin.liu@corigine.com>
Reviewed-by: Chaoyong He <chaoyong.he@corigine.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@corigine.com>
Signed-off-by: Niklas Söderlund <niklas.soderlund@corigine.com>
---
drivers/net/nfp/nfp_common.c | 86 ++++++++++++++++++++++++++++++++++--
drivers/net/nfp/nfp_common.h | 6 +++
drivers/net/nfp/nfp_rxtx.c | 51 ++++++++++++++-------
drivers/net/nfp/nfp_rxtx.h | 3 ++
4 files changed, 127 insertions(+), 19 deletions(-)
diff --git a/drivers/net/nfp/nfp_common.c b/drivers/net/nfp/nfp_common.c
index 71711bfa228e..4defd6d93871 100644
--- a/drivers/net/nfp/nfp_common.c
+++ b/drivers/net/nfp/nfp_common.c
@@ -697,13 +697,91 @@ nfp_net_stats_reset(struct rte_eth_dev *dev)
return 0;
}
+int
+nfp_net_rx_desc_limits(struct nfp_net_hw *hw,
+ uint16_t *min_rx_desc,
+ uint16_t *max_rx_desc)
+{
+ *max_rx_desc = NFP_NET_MAX_RX_DESC;
+
+ switch (hw->device_id) {
+ case PCI_DEVICE_ID_NFP3800_PF_NIC:
+ case PCI_DEVICE_ID_NFP3800_VF_NIC:
+ *min_rx_desc = NFP3800_NET_MIN_RX_DESC;
+ return 0;
+ case PCI_DEVICE_ID_NFP4000_PF_NIC:
+ case PCI_DEVICE_ID_NFP6000_PF_NIC:
+ case PCI_DEVICE_ID_NFP6000_VF_NIC:
+ *min_rx_desc = NFP_NET_MIN_RX_DESC;
+ return 0;
+ default:
+ PMD_DRV_LOG(ERR, "Unknown NFP device id.");
+ return -EINVAL;
+ }
+}
+
+int
+nfp_net_tx_desc_limits(struct nfp_net_hw *hw,
+ uint16_t *min_tx_desc,
+ uint16_t *max_tx_desc)
+{
+ uint16_t tx_dpp;
+
+ switch (NFD_CFG_CLASS_VER_of(hw->ver)) {
+ case NFP_NET_CFG_VERSION_DP_NFD3:
+ tx_dpp = NFD3_TX_DESC_PER_SIMPLE_PKT;
+ break;
+ case NFP_NET_CFG_VERSION_DP_NFDK:
+ if (NFD_CFG_MAJOR_VERSION_of(hw->ver) < 5) {
+ PMD_DRV_LOG(ERR, "NFDK must use ABI 5 or newer, found: %d",
+ NFD_CFG_MAJOR_VERSION_of(hw->ver));
+ return -EINVAL;
+ }
+ tx_dpp = NFDK_TX_DESC_PER_SIMPLE_PKT;
+ break;
+ default:
+ PMD_DRV_LOG(ERR, "The version of firmware is not correct.");
+ return -EINVAL;
+ }
+
+ *max_tx_desc = NFP_NET_MAX_TX_DESC / tx_dpp;
+
+ switch (hw->device_id) {
+ case PCI_DEVICE_ID_NFP3800_PF_NIC:
+ case PCI_DEVICE_ID_NFP3800_VF_NIC:
+ *min_tx_desc = NFP3800_NET_MIN_TX_DESC / tx_dpp;
+ return 0;
+ case PCI_DEVICE_ID_NFP4000_PF_NIC:
+ case PCI_DEVICE_ID_NFP6000_PF_NIC:
+ case PCI_DEVICE_ID_NFP6000_VF_NIC:
+ *min_tx_desc = NFP_NET_MIN_TX_DESC / tx_dpp;
+ return 0;
+ default:
+ PMD_DRV_LOG(ERR, "Unknown NFP device id.");
+ return -EINVAL;
+ }
+}
+
int
nfp_net_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
{
+ int ret;
+ uint16_t min_rx_desc;
+ uint16_t max_rx_desc;
+ uint16_t min_tx_desc;
+ uint16_t max_tx_desc;
struct nfp_net_hw *hw;
hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ ret = nfp_net_rx_desc_limits(hw, &min_rx_desc, &max_rx_desc);
+ if (ret != 0)
+ return ret;
+
+ ret = nfp_net_tx_desc_limits(hw, &min_tx_desc, &max_tx_desc);
+ if (ret != 0)
+ return ret;
+
dev_info->max_rx_queues = (uint16_t)hw->max_rx_queues;
dev_info->max_tx_queues = (uint16_t)hw->max_tx_queues;
dev_info->min_rx_bufsize = RTE_ETHER_MIN_MTU;
@@ -764,14 +842,14 @@ nfp_net_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
};
dev_info->rx_desc_lim = (struct rte_eth_desc_lim) {
- .nb_max = NFP_NET_MAX_RX_DESC,
- .nb_min = NFP_NET_MIN_RX_DESC,
+ .nb_max = max_rx_desc,
+ .nb_min = min_rx_desc,
.nb_align = NFP_ALIGN_RING_DESC,
};
dev_info->tx_desc_lim = (struct rte_eth_desc_lim) {
- .nb_max = NFP_NET_MAX_TX_DESC,
- .nb_min = NFP_NET_MIN_TX_DESC,
+ .nb_max = max_tx_desc,
+ .nb_min = min_tx_desc,
.nb_align = NFP_ALIGN_RING_DESC,
.nb_seg_max = NFP_TX_MAX_SEG,
.nb_mtu_seg_max = NFP_TX_MAX_MTU_SEG,
diff --git a/drivers/net/nfp/nfp_common.h b/drivers/net/nfp/nfp_common.h
index 36c19b47e4d5..a871e437e4d2 100644
--- a/drivers/net/nfp/nfp_common.h
+++ b/drivers/net/nfp/nfp_common.h
@@ -447,6 +447,12 @@ void nfp_net_close_rx_queue(struct rte_eth_dev *dev);
void nfp_net_stop_tx_queue(struct rte_eth_dev *dev);
void nfp_net_close_tx_queue(struct rte_eth_dev *dev);
int nfp_net_set_vxlan_port(struct nfp_net_hw *hw, size_t idx, uint16_t port);
+int nfp_net_rx_desc_limits(struct nfp_net_hw *hw,
+ uint16_t *min_rx_desc,
+ uint16_t *max_rx_desc);
+int nfp_net_tx_desc_limits(struct nfp_net_hw *hw,
+ uint16_t *min_tx_desc,
+ uint16_t *max_tx_desc);
#define NFP_NET_DEV_PRIVATE_TO_HW(adapter)\
(&((struct nfp_net_adapter *)adapter)->hw)
diff --git a/drivers/net/nfp/nfp_rxtx.c b/drivers/net/nfp/nfp_rxtx.c
index 01cffdfde0b4..0de7312e217d 100644
--- a/drivers/net/nfp/nfp_rxtx.c
+++ b/drivers/net/nfp/nfp_rxtx.c
@@ -439,6 +439,9 @@ nfp_net_rx_queue_setup(struct rte_eth_dev *dev,
const struct rte_eth_rxconf *rx_conf,
struct rte_mempool *mp)
{
+ int ret;
+ uint16_t min_rx_desc;
+ uint16_t max_rx_desc;
const struct rte_memzone *tz;
struct nfp_net_rxq *rxq;
struct nfp_net_hw *hw;
@@ -448,11 +451,14 @@ nfp_net_rx_queue_setup(struct rte_eth_dev *dev,
PMD_INIT_FUNC_TRACE();
+ ret = nfp_net_rx_desc_limits(hw, &min_rx_desc, &max_rx_desc);
+ if (ret != 0)
+ return ret;
+
/* Validating number of descriptors */
rx_desc_sz = nb_desc * sizeof(struct nfp_net_rx_desc);
if (rx_desc_sz % NFP_ALIGN_RING_DESC != 0 ||
- nb_desc > NFP_NET_MAX_RX_DESC ||
- nb_desc < NFP_NET_MIN_RX_DESC) {
+ nb_desc > max_rx_desc || nb_desc < min_rx_desc) {
PMD_DRV_LOG(ERR, "Wrong nb_desc value");
return -EINVAL;
}
@@ -502,7 +508,7 @@ nfp_net_rx_queue_setup(struct rte_eth_dev *dev,
*/
tz = rte_eth_dma_zone_reserve(dev, "rx_ring", queue_idx,
sizeof(struct nfp_net_rx_desc) *
- NFP_NET_MAX_RX_DESC, NFP_MEMZONE_ALIGN,
+ max_rx_desc, NFP_MEMZONE_ALIGN,
socket_id);
if (tz == NULL) {
@@ -628,6 +634,9 @@ nfp_net_nfd3_tx_queue_setup(struct rte_eth_dev *dev, uint16_t queue_idx,
uint16_t nb_desc, unsigned int socket_id,
const struct rte_eth_txconf *tx_conf)
{
+ int ret;
+ uint16_t min_tx_desc;
+ uint16_t max_tx_desc;
const struct rte_memzone *tz;
struct nfp_net_txq *txq;
uint16_t tx_free_thresh;
@@ -638,11 +647,14 @@ nfp_net_nfd3_tx_queue_setup(struct rte_eth_dev *dev, uint16_t queue_idx,
PMD_INIT_FUNC_TRACE();
+ ret = nfp_net_tx_desc_limits(hw, &min_tx_desc, &max_tx_desc);
+ if (ret != 0)
+ return ret;
+
/* Validating number of descriptors */
tx_desc_sz = nb_desc * sizeof(struct nfp_net_nfd3_tx_desc);
- if (tx_desc_sz % NFP_ALIGN_RING_DESC != 0 ||
- nb_desc > NFP_NET_MAX_TX_DESC ||
- nb_desc < NFP_NET_MIN_TX_DESC) {
+ if ((NFD3_TX_DESC_PER_SIMPLE_PKT * tx_desc_sz) % NFP_ALIGN_RING_DESC != 0 ||
+ nb_desc > max_tx_desc || nb_desc < min_tx_desc) {
PMD_DRV_LOG(ERR, "Wrong nb_desc value");
return -EINVAL;
}
@@ -688,7 +700,8 @@ nfp_net_nfd3_tx_queue_setup(struct rte_eth_dev *dev, uint16_t queue_idx,
*/
tz = rte_eth_dma_zone_reserve(dev, "tx_ring", queue_idx,
sizeof(struct nfp_net_nfd3_tx_desc) *
- NFP_NET_MAX_TX_DESC, NFP_MEMZONE_ALIGN,
+ NFD3_TX_DESC_PER_SIMPLE_PKT *
+ max_tx_desc, NFP_MEMZONE_ALIGN,
socket_id);
if (tz == NULL) {
PMD_DRV_LOG(ERR, "Error allocating tx dma");
@@ -697,7 +710,7 @@ nfp_net_nfd3_tx_queue_setup(struct rte_eth_dev *dev, uint16_t queue_idx,
return -ENOMEM;
}
- txq->tx_count = nb_desc;
+ txq->tx_count = nb_desc * NFD3_TX_DESC_PER_SIMPLE_PKT;
txq->tx_free_thresh = tx_free_thresh;
txq->tx_pthresh = tx_conf->tx_thresh.pthresh;
txq->tx_hthresh = tx_conf->tx_thresh.hthresh;
@@ -716,7 +729,7 @@ nfp_net_nfd3_tx_queue_setup(struct rte_eth_dev *dev, uint16_t queue_idx,
/* mbuf pointers array for referencing mbufs linked to TX descriptors */
txq->txbufs = rte_zmalloc_socket("txq->txbufs",
- sizeof(*txq->txbufs) * nb_desc,
+ sizeof(*txq->txbufs) * txq->tx_count,
RTE_CACHE_LINE_SIZE, socket_id);
if (txq->txbufs == NULL) {
nfp_net_tx_queue_release(dev, queue_idx);
@@ -735,7 +748,7 @@ nfp_net_nfd3_tx_queue_setup(struct rte_eth_dev *dev, uint16_t queue_idx,
* of descriptors in log2 format
*/
nn_cfg_writeq(hw, NFP_NET_CFG_TXR_ADDR(queue_idx), txq->dma);
- nn_cfg_writeb(hw, NFP_NET_CFG_TXR_SZ(queue_idx), rte_log2_u32(nb_desc));
+ nn_cfg_writeb(hw, NFP_NET_CFG_TXR_SZ(queue_idx), rte_log2_u32(txq->tx_count));
return 0;
}
@@ -760,7 +773,8 @@ nfp_net_nfd3_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts, uint16_t nb_pk
PMD_TX_LOG(DEBUG, "working for queue %u at pos %d and %u packets",
txq->qidx, txq->wr_p, nb_pkts);
- if ((nfp_net_nfd3_free_tx_desc(txq) < nb_pkts) || (nfp_net_nfd3_txq_full(txq)))
+ if (nfp_net_nfd3_free_tx_desc(txq) < NFD3_TX_DESC_PER_SIMPLE_PKT * nb_pkts ||
+ nfp_net_nfd3_txq_full(txq))
nfp_net_tx_free_bufs(txq);
free_descs = (uint16_t)nfp_net_nfd3_free_tx_desc(txq);
@@ -879,6 +893,9 @@ nfp_net_nfdk_tx_queue_setup(struct rte_eth_dev *dev,
unsigned int socket_id,
const struct rte_eth_txconf *tx_conf)
{
+ int ret;
+ uint16_t min_tx_desc;
+ uint16_t max_tx_desc;
const struct rte_memzone *tz;
struct nfp_net_txq *txq;
uint16_t tx_free_thresh;
@@ -889,11 +906,15 @@ nfp_net_nfdk_tx_queue_setup(struct rte_eth_dev *dev,
PMD_INIT_FUNC_TRACE();
+ ret = nfp_net_tx_desc_limits(hw, &min_tx_desc, &max_tx_desc);
+ if (ret != 0)
+ return ret;
+
/* Validating number of descriptors */
tx_desc_sz = nb_desc * sizeof(struct nfp_net_nfdk_tx_desc);
- if (((NFDK_TX_DESC_PER_SIMPLE_PKT * tx_desc_sz) % NFP_ALIGN_RING_DESC) != 0 ||
- ((NFDK_TX_DESC_PER_SIMPLE_PKT * nb_desc) % NFDK_TX_DESC_BLOCK_CNT) != 0 ||
- nb_desc > NFP_NET_MAX_TX_DESC || nb_desc < NFP_NET_MIN_TX_DESC) {
+ if ((NFDK_TX_DESC_PER_SIMPLE_PKT * tx_desc_sz) % NFP_ALIGN_RING_DESC != 0 ||
+ (NFDK_TX_DESC_PER_SIMPLE_PKT * nb_desc) % NFDK_TX_DESC_BLOCK_CNT != 0 ||
+ nb_desc > max_tx_desc || nb_desc < min_tx_desc) {
PMD_DRV_LOG(ERR, "Wrong nb_desc value");
return -EINVAL;
}
@@ -938,7 +959,7 @@ nfp_net_nfdk_tx_queue_setup(struct rte_eth_dev *dev,
tz = rte_eth_dma_zone_reserve(dev, "tx_ring", queue_idx,
sizeof(struct nfp_net_nfdk_tx_desc) *
NFDK_TX_DESC_PER_SIMPLE_PKT *
- NFP_NET_MAX_TX_DESC, NFP_MEMZONE_ALIGN,
+ max_tx_desc, NFP_MEMZONE_ALIGN,
socket_id);
if (tz == NULL) {
PMD_DRV_LOG(ERR, "Error allocating tx dma");
diff --git a/drivers/net/nfp/nfp_rxtx.h b/drivers/net/nfp/nfp_rxtx.h
index ced05fde908d..4f0de5e93227 100644
--- a/drivers/net/nfp/nfp_rxtx.h
+++ b/drivers/net/nfp/nfp_rxtx.h
@@ -31,9 +31,11 @@
*/
#define NFP_NET_MAX_TX_DESC (32 * 1024)
#define NFP_NET_MIN_TX_DESC 256
+#define NFP3800_NET_MIN_TX_DESC 512
#define NFP_NET_MAX_RX_DESC (32 * 1024)
#define NFP_NET_MIN_RX_DESC 256
+#define NFP3800_NET_MIN_RX_DESC 512
/* Descriptor alignment */
#define NFP_ALIGN_RING_DESC 128
@@ -57,6 +59,7 @@
#define NFDK_DESC_TX_DMA_LEN_HEAD 0x0fff
#define NFDK_DESC_TX_TYPE_HEAD 0xf000
#define NFDK_DESC_TX_DMA_LEN 0x3fff
+#define NFD3_TX_DESC_PER_SIMPLE_PKT 1
#define NFDK_TX_DESC_PER_SIMPLE_PKT 2
#define NFDK_DESC_TX_TYPE_TSO 2
#define NFDK_DESC_TX_TYPE_SIMPLE 8
--
2.38.1
^ permalink raw reply [relevance 3%]
* RE: Regarding User Data in DPDK ACL Library.
2022-11-21 16:56 0% ` Honnappa Nagarahalli
@ 2022-11-22 13:38 0% ` Konstantin Ananyev
2022-11-22 15:53 0% ` Honnappa Nagarahalli
0 siblings, 1 reply; 200+ results
From: Konstantin Ananyev @ 2022-11-22 13:38 UTC (permalink / raw)
To: Honnappa Nagarahalli, Stephen Hemminger, venkatesh bs; +Cc: users, dev, nd, nd
> -----Original Message-----
> From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> Sent: Monday, November 21, 2022 4:57 PM
> To: Konstantin Ananyev <konstantin.ananyev@huawei.com>; Stephen Hemminger <stephen@networkplumber.org>; venkatesh bs
> <venki.bsv@gmail.com>
> Cc: users@dpdk.org; dev@dpdk.org; nd <nd@arm.com>; nd <nd@arm.com>
> Subject: RE: Regarding User Data in DPDK ACL Library.
>
> <snip>
> >
> > > > > On Thu, 17 Nov 2022 19:28:12 +0530 venkatesh bs
> > > > > <venki.bsv@gmail.com> wrote:
> > > > >
> > > > > > Hi DPDK Team,
> > > > > >
> > > > > > After the ACL match for highest priority DPDK Classification API
> > > > > > returns User Data Which is as mentioned below in the document.
> > > > > >
> > > > > > 53. Packet Classification and Access Control — Data Plane
> > > > > > Development Kit
> > > > > > 22.11.0-rc2 documentation (dpdk.org)
> > > > > >
> > > > > >
> > > > > > - *userdata*: A user-defined value. For each category, a successful
> > > > > > match returns the userdata field of the highest priority matched
> > rule.
> > > > When
> > > > > > no rules match, returned value is zero
> > > > > >
> > > > > > I Wonder Why User Data Support does not returns 64 bit values,
> > > >
> > > > As I remember if first version of ACL code it was something about
> > > > space savings to improve performance...
> > > > Now I think it is more just a historical reason.
> > > > It would be good to change userdata to 64bit, but I presume it will
> > > > be ABI breakage.
> > > Agree. We should support 64b and even 128b (since architectures
> > > support 128b atomic operations). This reduces required memory barriers
> > required if the data size <= the size of atomic operations.
> >
> > Hmm... sorry, didn’t get you here.
> > I do understand the user intention to save pointer to arbitrary memory
> > location as user-data (64-bit).
> > But how does the size of atomic mem-ops relate?
> > Konstantin
> What I meant is, if your data fits within 64b or 128b, having another indirection requires:
>
> 1) one additional memory operation to store the data (the first one being the store to the index)
> 2) on the control plane, we would need a release barrier between 'store data' and 'store index' (not a significant issue). On the data
> plane, we could use relaxed ordering between 'load index' and 'load data', so we do not need a barrier here.
>
> So, looks like there is no barrier over-head on the data plane, but overhead of one additional memory operation.
ACL doesn't provide ability to dynamically update the rules or associated user-data.
Whole ACL table has to be rebuild.
Konstantin
^ permalink raw reply [relevance 0%]
* RE: Regarding User Data in DPDK ACL Library.
2022-11-22 13:38 0% ` Konstantin Ananyev
@ 2022-11-22 15:53 0% ` Honnappa Nagarahalli
0 siblings, 0 replies; 200+ results
From: Honnappa Nagarahalli @ 2022-11-22 15:53 UTC (permalink / raw)
To: Konstantin Ananyev, Stephen Hemminger, venkatesh bs; +Cc: users, dev, nd, nd
<snip>
> > >
> > > > > > On Thu, 17 Nov 2022 19:28:12 +0530 venkatesh bs
> > > > > > <venki.bsv@gmail.com> wrote:
> > > > > >
> > > > > > > Hi DPDK Team,
> > > > > > >
> > > > > > > After the ACL match for highest priority DPDK Classification
> > > > > > > API returns User Data Which is as mentioned below in the document.
> > > > > > >
> > > > > > > 53. Packet Classification and Access Control — Data Plane
> > > > > > > Development Kit
> > > > > > > 22.11.0-rc2 documentation (dpdk.org)
> > > > > > >
> > > > > > >
> > > > > > > - *userdata*: A user-defined value. For each category, a successful
> > > > > > > match returns the userdata field of the highest priority
> > > > > > > matched
> > > rule.
> > > > > When
> > > > > > > no rules match, returned value is zero
> > > > > > >
> > > > > > > I Wonder Why User Data Support does not returns 64 bit
> > > > > > > values,
> > > > >
> > > > > As I remember if first version of ACL code it was something
> > > > > about space savings to improve performance...
> > > > > Now I think it is more just a historical reason.
> > > > > It would be good to change userdata to 64bit, but I presume it
> > > > > will be ABI breakage.
> > > > Agree. We should support 64b and even 128b (since architectures
> > > > support 128b atomic operations). This reduces required memory
> > > > barriers
> > > required if the data size <= the size of atomic operations.
> > >
> > > Hmm... sorry, didn’t get you here.
> > > I do understand the user intention to save pointer to arbitrary
> > > memory location as user-data (64-bit).
> > > But how does the size of atomic mem-ops relate?
> > > Konstantin
> > What I meant is, if your data fits within 64b or 128b, having another
> indirection requires:
> >
> > 1) one additional memory operation to store the data (the first one
> > being the store to the index)
> > 2) on the control plane, we would need a release barrier between
> > 'store data' and 'store index' (not a significant issue). On the data plane, we
> could use relaxed ordering between 'load index' and 'load data', so we do not
> need a barrier here.
> >
> > So, looks like there is no barrier over-head on the data plane, but overhead of
> one additional memory operation.
>
> ACL doesn't provide ability to dynamically update the rules or associated user-
> data.
> Whole ACL table has to be rebuild.
Ok, then the ordering does not matter, all the loads on the data plane should be relaxed and not atomic (searching through the code does not show any).
> Konstantin
>
>
^ permalink raw reply [relevance 0%]
* [PATCH v1] doc: update release notes for 22.11
@ 2022-11-24 16:56 3% John McNamara
0 siblings, 0 replies; 200+ results
From: John McNamara @ 2022-11-24 16:56 UTC (permalink / raw)
To: dev; +Cc: thomas, John McNamara
Fix grammar, spelling and formatting of DPDK 22.11 release notes.
Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
doc/guides/rel_notes/release_22_11.rst | 92 +++++++++++++-------------
1 file changed, 46 insertions(+), 46 deletions(-)
diff --git a/doc/guides/rel_notes/release_22_11.rst b/doc/guides/rel_notes/release_22_11.rst
index f427deab31..99e1b06d08 100644
--- a/doc/guides/rel_notes/release_22_11.rst
+++ b/doc/guides/rel_notes/release_22_11.rst
@@ -58,34 +58,34 @@ New Features
* **Added initial LoongArch architecture support.**
Added EAL implementation for LoongArch architecture.
- The initial devices the porting was tested on included Loongson 3A5000,
+ The initial port was tested on Loongson 3A5000,
Loongson 3C5000 and Loongson 3C5000L.
In theory this implementation should work with any target based on
``LoongArch`` ISA.
* **Added support for multiple mbuf pools per ethdev Rx queue.**
- The capability allows application to provide many mempools
- of different size, and PMD and/or NIC to choose a memory pool
- based on the packet's length and/or Rx buffers availability.
+ Added a capability which allows an application to provide many mempools
+ of different size, and PMDs and/or NICs to choose a memory pool
+ based on the packet's length and/or Rx buffer availability.
* **Added support for congestion management in ethdev.**
Added new API functions ``rte_eth_cman_config_init()``,
- ``rte_eth_cman_config_get()``, ``rte_eth_cman_config_set()``,
- ``rte_eth_cman_info_get()`` to support congestion management.
+ ``rte_eth_cman_config_get()``, ``rte_eth_cman_config_set()``
+ and ``rte_eth_cman_info_get()`` to support congestion management.
* **Added protocol header based buffer split.**
* Added ``rte_eth_buffer_split_get_supported_hdr_ptypes()`` to get supported
header protocols to split at.
- * Supported protocol-based buffer split using added ``proto_hdr``
- in structure ``rte_eth_rxseg_split``.
+ * Added support for protocol-based buffer split using new ``proto_hdr``
+ field in structure ``rte_eth_rxseg_split``.
* **Added proactive error handling mode for ethdev.**
Added proactive error handling mode for ethdev,
- and three events were introduced: ``RTE_ETH_EVENT_ERR_RECOVERING``
+ and introduced three new events: ``RTE_ETH_EVENT_ERR_RECOVERING``
to report that the port is recovering from an error,
``RTE_ETH_EVENT_RECOVER_SUCCESS`` and ``RTE_ETH_EVENT_RECOVER_FAILED``.
@@ -118,32 +118,32 @@ New Features
Added connection tracking action number hint to ``rte_flow_configure``
and ``rte_flow_info_get``.
- PMD can prepare the connection tracking resources according to the hint.
+ The PMD can prepare the connection tracking resources according to the hint.
* **Added support for queue-based async query in flow API.**
- Added new function ``rte_flow_async_action_handle_query()``,
+ Added new function ``rte_flow_async_action_handle_query()``
to query the action asynchronously.
* **Extended metering and marking support in the flow API.**
- * Added METER_COLOR item to match color marker set by a meter.
+ * Added ``METER_COLOR`` item to match color marker set by a meter.
* Added ability to set color marker via modify field flow API.
- * Added meter API to get a pointer to profile/policy by their ID.
- * Added METER_MARK action for metering with lockless profile/policy access.
+ * Added meter API to get a pointer to the profile/policy by their ID.
+ * Added ``METER_MARK`` action for metering with lockless profile/policy access.
* **Added flow offload action to route packets to kernel.**
- Added new flow action which allows application to re-route packets
+ Added new flow action which allows an application to re-route packets
directly to the kernel without software involvement.
* **Updated AF_XDP driver.**
- * Made compatible with libbpf v0.8.0 (when used with libxdp).
+ * Updated AF_XDP driver to make it compatible with libbpf v0.8.0 (when used with libxdp).
* **Updated AMD Pensando ionic driver.**
- * Updated to reflect that Pensando has been acquired by AMD.
+ * Updated ionic driver to reflect that Pensando has been acquired by AMD.
* Enhanced data path to provide substantial performance improvements.
* Added support for mbuf fast free.
* Added support for advertising packet types.
@@ -151,7 +151,7 @@ New Features
* Added Q-in-CMB feature controlled by device option ``ionic_cmb``.
* Added optimized handlers for non-scattered Rx and Tx.
-* **Added GVE net PMD**
+* **Added GVE net PMD.**
* Added the new ``gve`` net driver for Google Virtual Ethernet devices.
* See the :doc:`../nics/gve` NIC guide for more details on this new driver.
@@ -172,25 +172,25 @@ New Features
* **Updated Marvell cnxk driver.**
- * Added support for flow action REPRESENTED_PORT.
+ * Added support for flow action ``REPRESENTED_PORT``.
* Added support for congestion management.
* **Added Microsoft mana driver.**
- Disabled by default because of missing dependency.
+ The driver has been disabled by default because of a, currently, missing dependency.
* **Updated Netronome nfp driver.**
Added flow API support:
- * Added the support of flower firmware.
+ * Added support for the flower firmware.
* Added the flower service infrastructure.
* Added the control message interactive channels between PMD and firmware.
- * Added the support of representor port.
+ * Added support for a representor port.
* **Updated NVIDIA mlx5 driver.**
- * Added full support for queue-based async HW steering.
+ * Added full support for queue-based async hardware steering.
- Support of FDB.
- Support of control flow and isolate mode.
@@ -202,7 +202,7 @@ New Features
* **Updated NXP dpaa2 driver.**
- * Added support for flow action REPRESENTED_PORT.
+ * Added support for flow action ``REPRESENTED_PORT``.
* **Updated Wangxun ngbe driver.**
@@ -216,8 +216,8 @@ New Features
* **Added non-blocking notify API to vhost library.**
Added ``rte_vhost_vring_call_nonblock`` API to notify the guest that
- used descriptors have been added to the vring in non-blocking way.
- User should check the return value of this API and try again if needed.
+ used descriptors have been added to the vring in n aon-blocking way.
+ The user should check the return value of this API and try again if needed.
* **Added support for MACsec in rte_security.**
@@ -237,7 +237,7 @@ New Features
* **Updated Marvell cnxk crypto driver.**
- * Added AES-CCM support in lookaside protocol (IPsec) for CN9K & CN10K.
+ * Added AES-CCM support in lookaside protocol (IPsec) for CN9K and CN10K.
* Added AES & DES DOCSIS algorithm support in lookaside crypto for CN9K.
* **Updated aesni_mb crypto driver.**
@@ -259,7 +259,7 @@ New Features
* **Added bbdev operation for FFT processing.**
Added a new operation type in bbdev for FFT processing with new functions
- ``rte_bbdev_enqueue_fft_ops``, ``rte_bbdev_dequeue_fft_ops``,
+ ``rte_bbdev_enqueue_fft_ops`` and ``rte_bbdev_dequeue_fft_ops``,
and related structures.
* **Added Intel ACC200 bbdev driver.**
@@ -285,13 +285,13 @@ New Features
* **Added event crypto adapter vectorization support.**
- Added support to aggregate crypto operations processed by event crypto adapter
- into single event containing ``rte_event_vector``
+ Added support for aggregating crypto operations processed by event crypto adapter
+ into a single event containing ``rte_event_vector``
whose event type is ``RTE_EVENT_TYPE_CRYPTODEV_VECTOR``.
* **Added NitroSketch in membership library.**
- Added a new data structure called sketch into membership library,
+ Added a new data structure called sketch into the membership library,
to profile the traffic efficiently.
NitroSketch provides high-fidelity approximate measurements
and appears as a promising alternative to traditional approaches
@@ -320,7 +320,7 @@ New Features
Added support for asymmetric crypto algorithms.
See the :doc:`../sample_app_ug/fips_validation` for more details.
-* **Rewritten pmdinfo script.**
+* **Rewrote pmdinfo script.**
The ``dpdk-pmdinfo.py`` script was rewritten to produce valid JSON only.
PCI-IDs parsing has been removed.
@@ -347,16 +347,16 @@ Removed Items
* mem: Removed not implemented and deprecated ``rte_malloc_set_limit``.
* ethdev: removed ``RTE_FLOW_ITEM_TYPE_PF``;
- use ``RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT``.
+ use ``RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT`` instead.
* ethdev: removed ``RTE_FLOW_ITEM_TYPE_VF``;
- use ``RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT``.
+ use ``RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT`` instead.
* ethdev: removed ``RTE_FLOW_ITEM_TYPE_PHY_PORT``;
- use ``RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT``.
+ use ``RTE_FLOW_ITEM_TYPE_REPRESENTED_PORT`` instead.
* ethdev: removed ``RTE_FLOW_ACTION_TYPE_PHY_PORT``;
- use ``RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT``.
+ use ``RTE_FLOW_ACTION_TYPE_REPRESENTED_PORT`` instead.
* ethdev: removed ``OF_SET_MPLS_TTL``, ``OF_DEC_MPLS_TTL``,
``OF_SET_NW_TTL``, ``OF_COPY_TTL_OUT`` and ``OF_COPY_TTL_IN``
@@ -382,30 +382,30 @@ API Changes
Also, make sure to start the actual text at the margin.
=======================================================
-* eal: RTE_FUNC_PTR_OR_* macros have been marked deprecated and will be removed
+* eal: ``RTE_FUNC_PTR_OR_*`` macros have been marked deprecated and will be removed
in the future. Applications can use ``devtools/cocci/func_or_ret.cocci``
to update their code.
-* eal: Updated ``rte_eal_remote_launch`` so it returns -EPIPE in case of
+* eal: Updated ``rte_eal_remote_launch`` so it returns ``-EPIPE`` in case of
a read or write error on the pipe, instead of calling ``rte_panic``.
-* eal: Updated return types for rte_{bsf,fls} inline functions
+* eal: Updated return types for ``rte_{bsf,fls}`` inline functions
to be consistently ``uint32_t``.
-* mempool: Deprecated helper macro ``MEMPOOL_HEADER_SIZE()`` is removed.
+* mempool: Deprecated helper macro ``MEMPOOL_HEADER_SIZE()`` has been removed.
The replacement macro ``RTE_MEMPOOL_HEADER_SIZE()`` is internal only.
* mempool: Deprecated macro to register mempool driver
- ``MEMPOOL_REGISTER_OPS()`` is removed. Use replacement macro
+ ``MEMPOOL_REGISTER_OPS()`` has been removed. Use replacement macro
``RTE_MEMPOOL_REGISTER_OPS()`` instead.
* mempool: Deprecated macros ``MEMPOOL_PG_NUM_DEFAULT`` and
- ``MEMPOOL_PG_SHIFT_MAX`` are removed. These macros are not used and
+ ``MEMPOOL_PG_SHIFT_MAX`` have been removed. These macros are not used and
not required any more.
* mbuf: Removed deprecated ``PKT_*`` flags.
Use corresponding flags with ``RTE_MBUF_F_`` prefix instead.
- Application can use ``devtools/cocci/prefix_mbuf_offload_flags.cocci``
+ Applications can use ``devtools/cocci/prefix_mbuf_offload_flags.cocci``
to replace all occurrences of old mbuf flags in C code.
* bus: Changed the device numa node to -1 when NUMA information is unavailable.
@@ -502,7 +502,7 @@ API Changes
from experimental to stable.
* ethdev: Banned the use of attributes ``ingress``/``egress`` in "transfer"
- flows, as the final step of deprecation process that had been started
+ flows, as the final step of the deprecation process that had been started
in DPDK 21.11. See items ``PORT_REPRESENTOR``, ``REPRESENTED_PORT``.
* vhost: Promoted ``rte_vhost_vring_stats_get()``,
@@ -523,7 +523,7 @@ API Changes
The API ``rte_security_session_create`` was updated to take only one mempool
which has enough space to hold session and driver private data.
-* security: MACsec support is added which resulted in updates
+* security: MACsec support has been added which resulted in updates
to structures ``rte_security_macsec_xform``, ``rte_security_macsec_stats``
and security capability structure ``rte_security_capability``
to accommodate MACsec capabilities.
@@ -605,7 +605,7 @@ ABI Changes
to ``rte_event_queue_conf`` structure.
* eventdev: The field ``*u64s`` in the structure ``rte_event_vector`` is replaced
- with ``u64s`` as the field is supposed to hold array of uint64_t values.
+ with ``u64s`` as the field is supposed to hold an array of ``uint64_t`` values.
* eventdev: The structure ``rte_event_vector`` was updated to include a new bit
field ``elem_offset:12``. The bits are taken from the bitfield ``rsvd:15``.
--
2.31.1
^ permalink raw reply [relevance 3%]
* DPDK 22.11 released
@ 2022-11-27 22:22 4% Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2022-11-27 22:22 UTC (permalink / raw)
To: announce
A new major release is available:
https://fast.dpdk.org/rel/dpdk-22.11.tar.xz
It was a comfortable release cycle:
1387 commits from 193 authors
1902 files changed, 137224 insertions(+), 61256 deletions(-)
The branch 22.11 should be supported for at least two years, maybe more,
making it recommended for system integration and deployment.
The new major ABI version is 23.
The next releases 23.03 and 23.07 will be ABI-compatible with 22.11.
Below are some new features:
- LoongArch build
- Intel uncore frequency control
- mempool optimizations
- new mbuf layout for IOVA-as-VA build
- multiple mbuf pools per Rx queue
- Rx buffer split based on protocol
- hardware congestion management
- hairpin memory configuration
- proactive NIC error handling
- Rx/Tx descriptor dump
- flow API extensions
- GVE (Google Virtual Ethernet)
- IDPF (Intel Infrastructure DataPath Function)
- UADK supporting HiSilicon crypto
- MACsec processing offload
- ShangMi crypto algorithms
- baseband FFT operations
- eventdev Tx queue start/stop
- eventdev crypto vectorization
- NitroSketch membership
- DTS introduction in DPDK repository
More details in the release notes:
https://doc.dpdk.org/guides/rel_notes/release_22_11.html
There are 74 new contributors (including authors, reviewers and testers).
Welcome to Abdullah Sevincer, Abhishek Maheshwari, Alan Liu,
Aleksandr Miloshenko, Alex Vesker, Alexander Chernavin, Allen Hubbe,
Amit Prakash Shukla, Anatolii Gerasymenko, Arkadiusz Kubalewski,
Arshdeep Kaur, Benjamin Le Berre, Bhagyada Modali, David MacDougal,
Dawid Zielinski, Dexia Li, Dukai Yuan, Erez Shitrit, Fei Qin, Frank Du,
Gal Shalom, Grzegorz Siwik, Hamdan Igbaria, Hamza Khan, Henning Schild,
Huang Wei, Huzaifa Rahman, James Hershaw, Jeremy Spewock, Jin Ling,
Joey Xing, Jun Qiu, Kaiwen Deng, Karen Sornek, Ke Xu, Kevin O'Sullivan,
Lei Cai, Lei Ji, Leszek Zygo, Long Wu, Lukasz Czapnik, Lukasz Kupczak,
Mah Yock Gen, Mandal Purna Chandra, Mao YingMing, Marcin Szycik,
Michael Savisko, Min Zhou, Mingjin Ye, Mingshan Zhang, Mário Kuka,
Piotr Gardocki, Qingmin Liu, R Mohamed Shah, Roman Storozhenko,
Sathesh Edara, Sergey Temerkhanov, Shiqi Liu, Stephen Coleman,
Steven Zou, Sunil Uttarwar, Sunyang Wu, Sylvia Grundwürmer,
Tadhg Kearney, Taekyung Kim, Taripin Samuel, Tomasz Jonak,
Tomasz Zawadzki, Tsotne Chakhvadze, Usman Tanveer, Wiktor Pilarczyk,
Yaqi Tang, Yi Li and Zhangfei Gao.
Below is the number of commits per employer (with authors count):
456 Intel (65)
227 Marvell (29)
179 NVIDIA (28)
83 Corigine (6)
81 Red Hat (5)
60 Huawei (6)
58 AMD (5)
55 Microsoft (4)
53 OKTET Labs (2)
19 NXP (5)
14 Ericsson (1)
13 6WIND (2)
...
A big thank to all courageous people who took on the non rewarding task
of reviewing other's job.
Based on Reviewed-by and Acked-by tags, the top non-PMD reviewers are:
53 Akhil Goyal <gakhil@marvell.com>
45 Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
36 Morten Brørup <mb@smartsharesystems.com>
34 Niklas Söderlund <niklas.soderlund@corigine.com>
34 Bruce Richardson <bruce.richardson@intel.com>
33 David Marchand <david.marchand@redhat.com>
31 Ori Kam <orika@nvidia.com>
25 Maxime Coquelin <maxime.coquelin@redhat.com>
21 Jerin Jacob <jerinj@marvell.com>
20 Chengwen Feng <fengchengwen@huawei.com>
The next version will be 23.03 in March.
The new features for 23.03 can be submitted during the next 4 weeks:
http://core.dpdk.org/roadmap#dates
Please share your roadmap.
Thanks everyone
^ permalink raw reply [relevance 4%]
* [PATCH] version: 23.03-rc0
@ 2022-11-28 8:33 11% David Marchand
2022-12-01 15:37 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2022-11-28 8:33 UTC (permalink / raw)
To: dev; +Cc: thomas, ci
Start a new release cycle with empty release notes.
Bump version and ABI minor.
libabigail 2.0 had some issues that have been fixed in 2.1, let's bump
to this version and enable ABI checks.
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
For CI guys: it is time to enable ABI checks again.
---
.github/workflows/build.yml | 6 +-
.travis.yml | 23 ++++-
ABI_VERSION | 2 +-
VERSION | 2 +-
doc/guides/rel_notes/index.rst | 1 +
doc/guides/rel_notes/release_23_03.rst | 138 +++++++++++++++++++++++++
6 files changed, 165 insertions(+), 7 deletions(-)
create mode 100644 doc/guides/rel_notes/release_23_03.rst
diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
index 82d83f4030..9527ad1f8c 100644
--- a/.github/workflows/build.yml
+++ b/.github/workflows/build.yml
@@ -21,11 +21,11 @@ jobs:
BUILD_DOCS: ${{ contains(matrix.config.checks, 'doc') }}
CC: ccache ${{ matrix.config.compiler }}
DEF_LIB: ${{ matrix.config.library }}
- LIBABIGAIL_VERSION: libabigail-1.8
+ LIBABIGAIL_VERSION: libabigail-2.1
MINGW: ${{ matrix.config.cross == 'mingw' }}
MINI: ${{ matrix.config.mini != '' }}
PPC64LE: ${{ matrix.config.cross == 'ppc64le' }}
- REF_GIT_TAG: none
+ REF_GIT_TAG: v22.11
RISCV64: ${{ matrix.config.cross == 'riscv64' }}
RUN_TESTS: ${{ contains(matrix.config.checks, 'tests') }}
@@ -38,7 +38,7 @@ jobs:
mini: mini
- os: ubuntu-20.04
compiler: gcc
- checks: doc+tests
+ checks: abi+doc+tests
- os: ubuntu-20.04
compiler: clang
checks: asan+doc+tests
diff --git a/.travis.yml b/.travis.yml
index 4bb5bf629e..b99444620f 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -41,8 +41,8 @@ script: ./.ci/${TRAVIS_OS_NAME}-build.sh
env:
global:
- - LIBABIGAIL_VERSION=libabigail-1.8
- - REF_GIT_TAG=none
+ - LIBABIGAIL_VERSION=libabigail-2.1
+ - REF_GIT_TAG=v22.11
jobs:
include:
@@ -61,6 +61,14 @@ jobs:
packages:
- *required_packages
- *doc_packages
+ - env: DEF_LIB="shared" ABI_CHECKS=true
+ arch: amd64
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - *required_packages
+ - *libabigail_build_packages
# x86_64 clang jobs
- env: DEF_LIB="static"
arch: amd64
@@ -137,6 +145,17 @@ jobs:
packages:
- *required_packages
- *doc_packages
+ - env: DEF_LIB="shared" ABI_CHECKS=true
+ dist: focal
+ arch: arm64-graviton2
+ virt: vm
+ group: edge
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - *required_packages
+ - *libabigail_build_packages
# aarch64 clang jobs
- env: DEF_LIB="static"
dist: focal
diff --git a/ABI_VERSION b/ABI_VERSION
index 919c868b57..a12b18e437 100644
--- a/ABI_VERSION
+++ b/ABI_VERSION
@@ -1 +1 @@
-23.0
+23.1
diff --git a/VERSION b/VERSION
index 7af24b7ddb..61240e02c2 100644
--- a/VERSION
+++ b/VERSION
@@ -1 +1 @@
-22.11.0
+23.03.0-rc0
diff --git a/doc/guides/rel_notes/index.rst b/doc/guides/rel_notes/index.rst
index f6782b91db..57475a8158 100644
--- a/doc/guides/rel_notes/index.rst
+++ b/doc/guides/rel_notes/index.rst
@@ -8,6 +8,7 @@ Release Notes
:maxdepth: 1
:numbered:
+ release_23_03
release_22_11
release_22_07
release_22_03
diff --git a/doc/guides/rel_notes/release_23_03.rst b/doc/guides/rel_notes/release_23_03.rst
new file mode 100644
index 0000000000..b8c5b68d6c
--- /dev/null
+++ b/doc/guides/rel_notes/release_23_03.rst
@@ -0,0 +1,138 @@
+.. SPDX-License-Identifier: BSD-3-Clause
+ Copyright 2022 The DPDK contributors
+
+.. include:: <isonum.txt>
+
+DPDK Release 23.03
+==================
+
+.. **Read this first.**
+
+ The text in the sections below explains how to update the release notes.
+
+ Use proper spelling, capitalization and punctuation in all sections.
+
+ Variable and config names should be quoted as fixed width text:
+ ``LIKE_THIS``.
+
+ Build the docs and view the output file to ensure the changes are correct::
+
+ ninja -C build doc
+ xdg-open build/doc/guides/html/rel_notes/release_23_03.html
+
+
+New Features
+------------
+
+.. This section should contain new features added in this release.
+ Sample format:
+
+ * **Add a title in the past tense with a full stop.**
+
+ Add a short 1-2 sentence description in the past tense.
+ The description should be enough to allow someone scanning
+ the release notes to understand the new feature.
+
+ If the feature adds a lot of sub-features you can use a bullet list
+ like this:
+
+ * Added feature foo to do something.
+ * Enhanced feature bar to do something else.
+
+ Refer to the previous release notes for examples.
+
+ Suggested order in release notes items:
+ * Core libs (EAL, mempool, ring, mbuf, buses)
+ * Device abstraction libs and PMDs (ordered alphabetically by vendor name)
+ - ethdev (lib, PMDs)
+ - cryptodev (lib, PMDs)
+ - eventdev (lib, PMDs)
+ - etc
+ * Other libs
+ * Apps, Examples, Tools (if significant)
+
+ This section is a comment. Do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =======================================================
+
+
+Removed Items
+-------------
+
+.. This section should contain removed items in this release. Sample format:
+
+ * Add a short 1-2 sentence description of the removed item
+ in the past tense.
+
+ This section is a comment. Do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =======================================================
+
+
+API Changes
+-----------
+
+.. This section should contain API changes. Sample format:
+
+ * sample: Add a short 1-2 sentence description of the API change
+ which was announced in the previous releases and made in this release.
+ Start with a scope label like "ethdev:".
+ Use fixed width quotes for ``function_names`` or ``struct_names``.
+ Use the past tense.
+
+ This section is a comment. Do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =======================================================
+
+
+ABI Changes
+-----------
+
+.. This section should contain ABI changes. Sample format:
+
+ * sample: Add a short 1-2 sentence description of the ABI change
+ which was announced in the previous releases and made in this release.
+ Start with a scope label like "ethdev:".
+ Use fixed width quotes for ``function_names`` or ``struct_names``.
+ Use the past tense.
+
+ This section is a comment. Do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =======================================================
+
+* No ABI change that would break compatibility with 22.11.
+
+
+Known Issues
+------------
+
+.. This section should contain new known issues in this release. Sample format:
+
+ * **Add title in present tense with full stop.**
+
+ Add a short 1-2 sentence description of the known issue
+ in the present tense. Add information on any known workarounds.
+
+ This section is a comment. Do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =======================================================
+
+
+Tested Platforms
+----------------
+
+.. This section should contain a list of platforms that were tested
+ with this release.
+
+ The format is:
+
+ * <vendor> platform with <vendor> <type of devices> combinations
+
+ * List of CPU
+ * List of OS
+ * List of devices
+ * Other relevant details...
+
+ This section is a comment. Do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =======================================================
--
2.38.1
^ permalink raw reply [relevance 11%]
* Re: [PATCH] drivers: fix symbol exports when map is omitted
@ 2022-11-29 18:23 3% ` Ferruh Yigit
2022-11-30 7:13 4% ` David Marchand
2022-12-02 11:09 3% ` [PATCH v4 1/2] " David Marchand
1 sibling, 1 reply; 200+ results
From: Ferruh Yigit @ 2022-11-29 18:23 UTC (permalink / raw)
To: David Marchand, dev
Cc: stable, Luca Boccassi, Bruce Richardson, Abdullah Ömer Yamaç
On 11/29/2022 2:00 PM, David Marchand wrote:
> ld exports any global symbol by default if no version script is passed.
> As a consequence, the incriminated change let any public symbol leak
> out of the driver shared libraries.
>
> Hide again those symbols by providing a default map file which
> unexports any global symbol using a local: * catchall statement.
>
I assume this will cause warnings for ABI check scripts, how can we
prevent the warnings?
> The check on symbols is skipped for this default map file as it is
> intentionnally an empty map (see commit b67bdda86cd4 ("devtools: catch
> empty symbol maps")) and there is nothing to check in it.
>
How it is skipped, './devtools/check-symbol-maps.sh' still complains
about 'drivers/version.map' for me.
> While at it, move Windows specific objects where needed for better
> readability.
>
+1
> Fixes: 7dde9c844a37 ("drivers: omit symbol map when unneeded")
> Cc: stable@dpdk.org
>
> Reported-by: Luca Boccassi <luca.boccassi@microsoft.com>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
Not tested on Windows, but for Linux:
Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
^ permalink raw reply [relevance 3%]
* Re: [PATCH] drivers: fix symbol exports when map is omitted
2022-11-29 18:23 3% ` Ferruh Yigit
@ 2022-11-30 7:13 4% ` David Marchand
2022-11-30 8:27 0% ` David Marchand
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2022-11-30 7:13 UTC (permalink / raw)
To: Ferruh Yigit, Thomas Monjalon
Cc: dev, stable, Luca Boccassi, Bruce Richardson,
Abdullah Ömer Yamaç
On Tue, Nov 29, 2022 at 7:23 PM Ferruh Yigit <ferruh.yigit@amd.com> wrote:
>
> On 11/29/2022 2:00 PM, David Marchand wrote:
> > ld exports any global symbol by default if no version script is passed.
> > As a consequence, the incriminated change let any public symbol leak
> > out of the driver shared libraries.
> >
> > Hide again those symbols by providing a default map file which
> > unexports any global symbol using a local: * catchall statement.
> >
>
> I assume this will cause warnings for ABI check scripts, how can we
> prevent the warnings?
Indeed.
Some options:
- add exhaustive suppression rules in devtools/libabigail.abignore,
- retag the v22.11 release with this fix, but we already announced it
and people started downloading the tarball,
- release a .1 version and compare ABI against it (either in the main
repo, or in the 22.11 stable branch, through for the ABI check in GHA,
it would be simpler to have the tag in the main repo..),
Do you have other ideas?
>
> > The check on symbols is skipped for this default map file as it is
> > intentionnally an empty map (see commit b67bdda86cd4 ("devtools: catch
> > empty symbol maps")) and there is nothing to check in it.
> >
>
> How it is skipped, './devtools/check-symbol-maps.sh' still complains
> about 'drivers/version.map' for me.
I had considered the call check-symbols.sh during build.
But it is true that if you call check-symbol-maps.sh alone, we will
get a warning.
I will exclude it in v2.
>
> > While at it, move Windows specific objects where needed for better
> > readability.
> >
>
> +1
>
> > Fixes: 7dde9c844a37 ("drivers: omit symbol map when unneeded")
> > Cc: stable@dpdk.org
> >
> > Reported-by: Luca Boccassi <luca.boccassi@microsoft.com>
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
>
>
> Not tested on Windows, but for Linux:
> Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
UNH Windows tests look fine.
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [PATCH] drivers: fix symbol exports when map is omitted
2022-11-30 7:13 4% ` David Marchand
@ 2022-11-30 8:27 0% ` David Marchand
2022-11-30 9:19 0% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2022-11-30 8:27 UTC (permalink / raw)
To: Ferruh Yigit, Thomas Monjalon
Cc: dev, stable, Luca Boccassi, Bruce Richardson,
Abdullah Ömer Yamaç
On Wed, Nov 30, 2022 at 8:13 AM David Marchand
<david.marchand@redhat.com> wrote:
> > I assume this will cause warnings for ABI check scripts, how can we
> > prevent the warnings?
>
> Indeed.
>
> Some options:
> - add exhaustive suppression rules in devtools/libabigail.abignore,
> - retag the v22.11 release with this fix, but we already announced it
> and people started downloading the tarball,
> - release a .1 version and compare ABI against it (either in the main
> repo, or in the 22.11 stable branch, through for the ABI check in GHA,
> it would be simpler to have the tag in the main repo..),
(let's forget about my concern on GHA, we have the REF_GIT_REPO param,
so we can point at the dpdk-stable repo, and go with a "normal"
release in 22.11 stable branch)
>
> Do you have other ideas?
>
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [PATCH] drivers: fix symbol exports when map is omitted
2022-11-30 8:27 0% ` David Marchand
@ 2022-11-30 9:19 0% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2022-11-30 9:19 UTC (permalink / raw)
To: David Marchand, Thomas Monjalon
Cc: dev, stable, Luca Boccassi, Bruce Richardson,
Abdullah Ömer Yamaç
On 11/30/2022 8:27 AM, David Marchand wrote:
> On Wed, Nov 30, 2022 at 8:13 AM David Marchand
> <david.marchand@redhat.com> wrote:
>>> I assume this will cause warnings for ABI check scripts, how can we
>>> prevent the warnings?
>>
>> Indeed.
>>
>> Some options:
>> - add exhaustive suppression rules in devtools/libabigail.abignore,
>> - retag the v22.11 release with this fix, but we already announced it
>> and people started downloading the tarball,
>> - release a .1 version and compare ABI against it (either in the main
>> repo, or in the 22.11 stable branch, through for the ABI check in GHA,
>> it would be simpler to have the tag in the main repo..),
>
> (let's forget about my concern on GHA, we have the REF_GIT_REPO param,
> so we can point at the dpdk-stable repo, and go with a "normal"
> release in 22.11 stable branch)
>
OK to have v22.11.1 stable release with this fix.
^ permalink raw reply [relevance 0%]
* help with pthread_t deprecation / api changes
@ 2022-11-30 22:54 4% Tyler Retzlaff
2022-12-02 1:12 0% ` Tyler Retzlaff
0 siblings, 1 reply; 200+ results
From: Tyler Retzlaff @ 2022-11-30 22:54 UTC (permalink / raw)
To: dev; +Cc: thomas
hi folks,
i'd like to continue work moving to our platform abstracted rte_thread
but ran into a hiccup. for some recent and not so recent apis it appears
they managed to slip in without ever being __experimental.
as a function of the dpdk project api/abi policy this means we can't
change or remove some of these functions without following the
deprecation process.
the apis that are causing me immediate difficulty are
rte_thread_setname and rte_ctrl_thread_create.
i think the least painful path forward to deprecating and removing these
apis is probably just to introduce the replacements with new names.
1. introduce functions with the following names marked as
__experimental.
rte_control_thread_create(rte_thread_t *, ...)
rte_thread_set_name(rte_thread_t, ...)
rte_thread_get_name(rte_thread_t, ...)
along with the new functions, new unit tests will be included.
2. update dpdk internal implementation to use the new functions.
3. immediately remove the following functions from the public headers
and issue an api deprecation notice for the functions not marked
experimental.
rte_ctrl_thread_create(pthread_t *, ...)
rte_thread_setname(pthread_t *, ...)
4. when the new functions have their __experimental marking removed
issue an abi deprecation notice for the functions from (2).
i'm open to feedback/suggestions of a better approach if anyone has one
to offer.
thanks!
^ permalink raw reply [relevance 4%]
* Re: [PATCH] version: 23.03-rc0
2022-11-28 8:33 11% [PATCH] version: 23.03-rc0 David Marchand
@ 2022-12-01 15:37 0% ` Thomas Monjalon
2022-12-01 15:50 0% ` David Marchand
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-12-01 15:37 UTC (permalink / raw)
To: David Marchand; +Cc: dev, ci
28/11/2022 09:33, David Marchand:
> Start a new release cycle with empty release notes.
> Bump version and ABI minor.
> libabigail 2.0 had some issues that have been fixed in 2.1, let's bump
> to this version and enable ABI checks.
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
^ permalink raw reply [relevance 0%]
* Re: [PATCH] version: 23.03-rc0
2022-12-01 15:37 0% ` Thomas Monjalon
@ 2022-12-01 15:50 0% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2022-12-01 15:50 UTC (permalink / raw)
To: dev; +Cc: Thomas Monjalon
On Thu, Dec 1, 2022 at 4:37 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 28/11/2022 09:33, David Marchand:
> > Start a new release cycle with empty release notes.
> > Bump version and ABI minor.
> > libabigail 2.0 had some issues that have been fixed in 2.1, let's bump
> > to this version and enable ABI checks.
> >
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
> Acked-by: Thomas Monjalon <thomas@monjalon.net>
Applied.
Here we go with a new release.
The proposed dates for the main milestones are:
Proposal deadline (RFC/v1 patches): 25 December 2022
API freeze (-rc1): 8 February 2023
PMD features freeze (-rc2): 1 March 2023
Builtin applications features freeze (-rc3): 8 March 2023
Release: 20 March 2023
Don't forget to send your roadmaps!
--
David Marchand
^ permalink raw reply [relevance 0%]
* DPDK Release Status Meeting 2022-12-01
@ 2022-12-01 19:01 3% Mcnamara, John
0 siblings, 0 replies; 200+ results
From: Mcnamara, John @ 2022-12-01 19:01 UTC (permalink / raw)
To: dev; +Cc: thomas, david.marchand
[-- Attachment #1: Type: text/plain, Size: 2871 bytes --]
Release status meeting minutes 2022-12-01
=========================================
Agenda:
* Release Dates
* Subtrees
* Roadmaps
* LTS
* Defects
* Opens
Participants:
* ARM [No]
* Canonical [No]
* Debian/Microsoft
* Intel
* Marvell [No]
* Nvidia
* Red Hat
* Xilinx/AMD
Release Dates
-------------
The following are the proposed current dates for 23.03:
* V1: 25 December 2022
* RC1: 8 February 2023
* RC2: 1 March 2023
* RC3: 8 March 2023
* Release: 20 March 2023
Subtrees
--------
* next-net
* No update.
* next-net-intel
* No update.
* next-net-mlx
* No update.
* next-net-mvl
* No update.
* next-eventdev
* No update.
* next-virtio
* No update.
* next-crypto
* No update.
* main
* 22.11 released.
* We are looking for a new shared maintainer for next-net
* There is an ABI breakage issue
* Will be fixed in release 22.11.1 on stable.
* Call for roadmaps for 23.03
Proposed Schedule for 2023
--------------------------
See also http://core.dpdk.org/roadmap/#dates
23.03
* Proposal deadline (RFC/v1 patches): 25 December 2022
* API freeze (-rc1): 8 February 2023
* PMD features freeze (-rc2): 1 March 2023
* Builtin applications features freeze (-rc3): 8 March 2023
* Release: 20 March 2023
23.07
* Proposal deadline (RFC/v1 patches): 15 April 2023
* API freeze (-rc1): 31 May 2023
* PMD features freeze (-rc2): 21 June 2023
* Builtin applications features freeze (-rc3): 28 June 2023
* Release: 12 July 2023
23.11
* Proposal deadline (RFC/v1 patches): 12 August 2023
* API freeze (-rc1): 29 September 2023
* PMD features freeze (-rc2): 20 October 2023
* Builtin applications features freeze (-rc3): 27 October 2023
* Release: 15 November 2023
LTS
---
Next releases will be:
* 21.11.3
* Backport patches have been sent.
* Merging of 22.11 patches in progress.
* 20.11.7
* Backport patches have been sent.
* Merging of 22.11 patches in progress.
* 19.11.14
* Backport patches have been sent.
* Merging of 22.11 patches in progress.
* Distros
* v20.11 in Debian 11
* Ubuntu 22.04 contains 21.11
Defects
-------
* Bugzilla links, 'Bugs', added for hosted projects
* https://www.dpdk.org/hosted-projects/
DPDK Release Status Meetings
----------------------------
The DPDK Release Status Meeting is intended for DPDK Committers to discuss the
status of the master tree and sub-trees, and for project managers to track
progress or milestone dates.
The meeting occurs on every Thursday at 9:30 UTC over Jitsi on https://meet.jit.si/DPDK
You don't need an invite to join the meeting but if you want a calendar reminder just
send an email to "John McNamara john.mcnamara@intel.com" for the invite.
[-- Attachment #2: Type: text/html, Size: 15674 bytes --]
^ permalink raw reply [relevance 3%]
* Re: help with pthread_t deprecation / api changes
2022-11-30 22:54 4% help with pthread_t deprecation / api changes Tyler Retzlaff
@ 2022-12-02 1:12 0% ` Tyler Retzlaff
2022-12-02 8:03 0% ` Morten Brørup
0 siblings, 1 reply; 200+ results
From: Tyler Retzlaff @ 2022-12-02 1:12 UTC (permalink / raw)
To: dev, thomas, david.marchand, mb, stephen
On Wed, Nov 30, 2022 at 02:54:27PM -0800, Tyler Retzlaff wrote:
> hi folks,
>
> i'd like to continue work moving to our platform abstracted rte_thread
> but ran into a hiccup. for some recent and not so recent apis it appears
> they managed to slip in without ever being __experimental.
>
> as a function of the dpdk project api/abi policy this means we can't
> change or remove some of these functions without following the
> deprecation process.
>
> the apis that are causing me immediate difficulty are
> rte_thread_setname and rte_ctrl_thread_create.
after looking in more detail at our current implementations of these
functions i would like to backtrack a little and limit the scope of
discussion to rte_thread_setname and rte_thread_getname.
as eal functions they aren't doing a good job in abstracting the
environment for applications, meaning an application would have to wrap
their use in platform conditional checks.
current status.
rte_thread_getname
* freebsd, no implementation and it appears no possible support
* linux, implementation conditional on __GLIBC_PREREQ(2, 12)
* windows, can be implemented but isn't, noop success
* fortunately is marked __rte_experimental
* called in 1 place only from eal (logging)
i would propose to present a consistent abstraction the best thing to do
here is just remove rte_thread_getname. providing a version that
requires an application to do conditional dances / compilation based on
platform gains nothing.
rte_thread_setname
* freebsd, implemented, imposes no limit on name length, suppresses errors
* linux, implementation conditional on __GLIBC_PREREQ(2, 12), imposes
limit of 16 (including terminating NUL) on name length, may return an
error
* windows, can be implemented, no explicit limit on name length, may
return errors
* unfortunately not marked __rte_experimental
i would propose to provide a replacement with the name
rte_thread_set_name with more consistent behavior across the 3 platforms.
* returns errors for platforms that return errors, but the caller
is free to ignore them.
* explicit limit of 16 (including terminating NUL) on name length,
names that are provided that exceed the limit are truncated without
error.
your feedback would be appreciated.
thanks
> i think the least painful path forward to deprecating and removing these
> apis is probably just to introduce the replacements with new names.
>
> 1. introduce functions with the following names marked as
> __experimental.
>
> rte_control_thread_create(rte_thread_t *, ...)
> rte_thread_set_name(rte_thread_t, ...)
> rte_thread_get_name(rte_thread_t, ...)
>
> along with the new functions, new unit tests will be included.
>
> 2. update dpdk internal implementation to use the new functions.
>
> 3. immediately remove the following functions from the public headers
> and issue an api deprecation notice for the functions not marked
> experimental.
>
> rte_ctrl_thread_create(pthread_t *, ...)
> rte_thread_setname(pthread_t *, ...)
>
> 4. when the new functions have their __experimental marking removed
> issue an abi deprecation notice for the functions from (2).
>
> i'm open to feedback/suggestions of a better approach if anyone has one
> to offer.
>
> thanks!
^ permalink raw reply [relevance 0%]
* RE: help with pthread_t deprecation / api changes
2022-12-02 1:12 0% ` Tyler Retzlaff
@ 2022-12-02 8:03 0% ` Morten Brørup
0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2022-12-02 8:03 UTC (permalink / raw)
To: Tyler Retzlaff, dev, thomas, david.marchand, stephen, Bruce Richardson
+Bruce, FreeBSD EAL maintainer
> From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> Sent: Friday, 2 December 2022 02.12
>
> On Wed, Nov 30, 2022 at 02:54:27PM -0800, Tyler Retzlaff wrote:
> > hi folks,
> >
> > i'd like to continue work moving to our platform abstracted
> rte_thread
> > but ran into a hiccup. for some recent and not so recent apis it
> appears
> > they managed to slip in without ever being __experimental.
> >
> > as a function of the dpdk project api/abi policy this means we can't
> > change or remove some of these functions without following the
> > deprecation process.
> >
> > the apis that are causing me immediate difficulty are
> > rte_thread_setname and rte_ctrl_thread_create.
>
> after looking in more detail at our current implementations of these
> functions i would like to backtrack a little and limit the scope of
> discussion to rte_thread_setname and rte_thread_getname.
>
> as eal functions they aren't doing a good job in abstracting the
> environment for applications, meaning an application would have to wrap
> their use in platform conditional checks.
<rant>
This is one of the consequences of a bloated EAL.
How is an application supposed to run on top of an EAL that isn't fully implemented by the underlying environments?
I have complained about this before, but am not afraid to repeat it:
I wish the EAL wasn't treated as some catch-all library where it is easy to throw in new features, which really belong in separate libraries!
</rant>
>
> current status.
>
> rte_thread_getname
> * freebsd, no implementation and it appears no possible support
> * linux, implementation conditional on __GLIBC_PREREQ(2, 12)
> * windows, can be implemented but isn't, noop success
> * fortunately is marked __rte_experimental
> * called in 1 place only from eal (logging)
>
> i would propose to present a consistent abstraction the best thing to
> do
> here is just remove rte_thread_getname. providing a version that
> requires an application to do conditional dances / compilation based on
> platform gains nothing.
My initial thought was that it should be provided for symmetry reasons.
However, thinking about it, it is probably only used for debugging, trace, and similar. It is probably not used in any meaningful way by applications. So I won't oppose to removing it.
Alternatively:
If some execution environment doesn't support thread names, it could return a string that makes it possible for a human to identify the thread, e.g. the tread id. Again, this is assuming that it is only used for debugging, trace, and similar.
>
> rte_thread_setname
> * freebsd, implemented, imposes no limit on name length, suppresses
> errors
> * linux, implementation conditional on __GLIBC_PREREQ(2, 12), imposes
> limit of 16 (including terminating NUL) on name length, may return
> an
> error
> * windows, can be implemented, no explicit limit on name length, may
> return errors
> * unfortunately not marked __rte_experimental
>
> i would propose to provide a replacement with the name
> rte_thread_set_name with more consistent behavior across the 3
> platforms.
>
> * returns errors for platforms that return errors, but the caller
> is free to ignore them.
> * explicit limit of 16 (including terminating NUL) on name length,
> names that are provided that exceed the limit are truncated without
> error.
The function should not silently modify the provided data (i.e. truncate the name). I would prefer doing both: Return ERANGE (like pthread_setname_np()), but use the truncated name anyway. Then the application can choose to ignore or deal with the return code.
^ permalink raw reply [relevance 0%]
* DPDK 22.11.1 released
@ 2022-12-02 9:46 4% David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2022-12-02 9:46 UTC (permalink / raw)
To: announce
Hi all,
Here is a new 22.11 release:
https://fast.dpdk.org/rel/dpdk-${stable_release}.tar.xz
The git tree is at:
https://dpdk.org/browse/dpdk-stable/?h=22.11
This LTS release contains one fix on the drivers ABI for the 22.11
release.
This 22.11.1 release should be used instead of the 22.11.0.
It will serve as the ABI reference for the 22.11 LTS branch and
later main releases (23.03 and 23.07).
--
David Marchand
---
VERSION | 2 +-
devtools/check-symbol-maps.sh | 2 +-
doc/guides/rel_notes/release_22_11.rst | 9 +++++++++
drivers/meson.build | 68 +++++++++++++++++++++++++++++++++++++-------------------------------
drivers/version.map | 3 +++
5 files changed, 51 insertions(+), 33 deletions(-)
David Marchand (2):
drivers: fix symbol exports when map is omitted
version: 22.11.1
^ permalink raw reply [relevance 4%]
* [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
2022-11-29 18:23 3% ` Ferruh Yigit
@ 2022-12-02 11:09 3% ` David Marchand
2022-12-02 13:39 0% ` Aaron Conole
1 sibling, 1 reply; 200+ results
From: David Marchand @ 2022-12-02 11:09 UTC (permalink / raw)
To: dev
Cc: ferruh.yigit, stable, Luca Boccassi, Bruce Richardson,
Aaron Conole, Michael Santana, Thomas Monjalon,
Abdullah Ömer Yamaç
ld exports any global symbol by default if no version script is passed.
As a consequence, the incriminated change let any public symbol leak
out of the driver shared libraries.
Hide again those symbols by providing a default map file which
unexports any global symbol using a local: * catch-all statement.
The checks are skipped for this default map file as it is intentionnally
an empty map (see commit b67bdda86cd4 ("devtools: catch empty symbol
maps")) and there is nothing else to check in this map.
This change impacts the exported symbols, hence, bump the version in the
ABI check to the v22.11.1 from the 22.11 LTS branch.
Fixes: 7dde9c844a37 ("drivers: omit symbol map when unneeded")
Cc: stable@dpdk.org
Reported-by: Luca Boccassi <luca.boccassi@microsoft.com>
Signed-off-by: David Marchand <david.marchand@redhat.com>
Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
Reviewed-by: Bruce Richardson <bruce.richardson@intel.com>
---
Changes since v3:
- updated ABI reference now that 22.11.1 is released,
Changes since v2:
- separated the Windows cleanup in next patch,
Changes since v1:
- excluded drivers/version.map from maps checked by default in
check-symbol-maps.sh,
---
.github/workflows/build.yml | 3 +-
.travis.yml | 3 +-
devtools/check-symbol-maps.sh | 2 +-
drivers/meson.build | 68 +++++++++++++++++++----------------
drivers/version.map | 3 ++
5 files changed, 45 insertions(+), 34 deletions(-)
create mode 100644 drivers/version.map
diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
index 9527ad1f8c..6bad94098e 100644
--- a/.github/workflows/build.yml
+++ b/.github/workflows/build.yml
@@ -25,7 +25,8 @@ jobs:
MINGW: ${{ matrix.config.cross == 'mingw' }}
MINI: ${{ matrix.config.mini != '' }}
PPC64LE: ${{ matrix.config.cross == 'ppc64le' }}
- REF_GIT_TAG: v22.11
+ REF_GIT_REPO: https://dpdk.org/git/dpdk-stable
+ REF_GIT_TAG: v22.11.1
RISCV64: ${{ matrix.config.cross == 'riscv64' }}
RUN_TESTS: ${{ contains(matrix.config.checks, 'tests') }}
diff --git a/.travis.yml b/.travis.yml
index b99444620f..0936788dc7 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -42,7 +42,8 @@ script: ./.ci/${TRAVIS_OS_NAME}-build.sh
env:
global:
- LIBABIGAIL_VERSION=libabigail-2.1
- - REF_GIT_TAG=v22.11
+ - REF_GIT_REPO=https://dpdk.org/git/dpdk-stable
+ - REF_GIT_TAG=v22.11.1
jobs:
include:
diff --git a/devtools/check-symbol-maps.sh b/devtools/check-symbol-maps.sh
index 0a6062de26..8c116bfa9c 100755
--- a/devtools/check-symbol-maps.sh
+++ b/devtools/check-symbol-maps.sh
@@ -8,7 +8,7 @@ cd $(dirname $0)/..
export LC_ALL=C
if [ $# = 0 ] ; then
- set -- $(find lib drivers -name '*.map')
+ set -- $(find lib drivers -name '*.map' -a ! -path drivers/version.map)
fi
ret=0
diff --git a/drivers/meson.build b/drivers/meson.build
index c4ff3ff1ba..5188302057 100644
--- a/drivers/meson.build
+++ b/drivers/meson.build
@@ -210,40 +210,46 @@ foreach subpath:subdirs
lk_deps = []
lk_args = []
- if fs.is_file(version_map)
- def_file = custom_target(lib_name + '_def',
- command: [map_to_win_cmd, '@INPUT@', '@OUTPUT@'],
- input: version_map,
- output: '@0@_exports.def'.format(lib_name))
-
- mingw_map = custom_target(lib_name + '_mingw',
- command: [map_to_win_cmd, '@INPUT@', '@OUTPUT@'],
- input: version_map,
- output: '@0@_mingw.map'.format(lib_name))
-
- lk_deps = [version_map, def_file, mingw_map]
- if is_windows
- if is_ms_linker
- lk_args = ['-Wl,/def:' + def_file.full_path()]
- if meson.version().version_compare('<0.54.0')
- lk_args += ['-Wl,/implib:drivers\\' + implib]
- endif
- else
- lk_args = ['-Wl,--version-script=' + mingw_map.full_path()]
+ if not fs.is_file(version_map)
+ version_map = '@0@/version.map'.format(meson.current_source_dir())
+ lk_deps += [version_map]
+ else
+ lk_deps += [version_map]
+ if not is_windows and developer_mode
+ # on unix systems check the output of the
+ # check-symbols.sh script, using it as a
+ # dependency of the .so build
+ lk_deps += custom_target(lib_name + '.sym_chk',
+ command: [check_symbols, version_map, '@INPUT@'],
+ capture: true,
+ input: static_lib,
+ output: lib_name + '.sym_chk')
+ endif
+ endif
+
+ def_file = custom_target(lib_name + '_def',
+ command: [map_to_win_cmd, '@INPUT@', '@OUTPUT@'],
+ input: version_map,
+ output: '@0@_exports.def'.format(lib_name))
+
+ mingw_map = custom_target(lib_name + '_mingw',
+ command: [map_to_win_cmd, '@INPUT@', '@OUTPUT@'],
+ input: version_map,
+ output: '@0@_mingw.map'.format(lib_name))
+
+ lk_deps += [def_file, mingw_map]
+
+ if is_windows
+ if is_ms_linker
+ lk_args = ['-Wl,/def:' + def_file.full_path()]
+ if meson.version().version_compare('<0.54.0')
+ lk_args += ['-Wl,/implib:drivers\\' + implib]
endif
else
- lk_args = ['-Wl,--version-script=' + version_map]
- if developer_mode
- # on unix systems check the output of the
- # check-symbols.sh script, using it as a
- # dependency of the .so build
- lk_deps += custom_target(lib_name + '.sym_chk',
- command: [check_symbols, version_map, '@INPUT@'],
- capture: true,
- input: static_lib,
- output: lib_name + '.sym_chk')
- endif
+ lk_args = ['-Wl,--version-script=' + mingw_map.full_path()]
endif
+ else
+ lk_args = ['-Wl,--version-script=' + version_map]
endif
shared_lib = shared_library(lib_name, sources,
diff --git a/drivers/version.map b/drivers/version.map
new file mode 100644
index 0000000000..78c3585d7c
--- /dev/null
+++ b/drivers/version.map
@@ -0,0 +1,3 @@
+DPDK_23 {
+ local: *;
+};
--
2.38.1
^ permalink raw reply [relevance 3%]
* Re: [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
2022-12-02 11:09 3% ` [PATCH v4 1/2] " David Marchand
@ 2022-12-02 13:39 0% ` Aaron Conole
2022-12-05 10:23 3% ` David Marchand
0 siblings, 1 reply; 200+ results
From: Aaron Conole @ 2022-12-02 13:39 UTC (permalink / raw)
To: David Marchand
Cc: dev, ferruh.yigit, stable, Luca Boccassi, Bruce Richardson,
Michael Santana, Thomas Monjalon, Abdullah Ömer Yamaç
David Marchand <david.marchand@redhat.com> writes:
> ld exports any global symbol by default if no version script is passed.
> As a consequence, the incriminated change let any public symbol leak
> out of the driver shared libraries.
>
> Hide again those symbols by providing a default map file which
> unexports any global symbol using a local: * catch-all statement.
>
> The checks are skipped for this default map file as it is intentionnally
> an empty map (see commit b67bdda86cd4 ("devtools: catch empty symbol
> maps")) and there is nothing else to check in this map.
>
> This change impacts the exported symbols, hence, bump the version in the
> ABI check to the v22.11.1 from the 22.11 LTS branch.
>
> Fixes: 7dde9c844a37 ("drivers: omit symbol map when unneeded")
> Cc: stable@dpdk.org
>
> Reported-by: Luca Boccassi <luca.boccassi@microsoft.com>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
> Reviewed-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
Acked-by: Aaron Conole <aconole@redhat.com>
^ permalink raw reply [relevance 0%]
* mbuf performance optimization
@ 2022-12-03 17:13 3% Morten Brørup
0 siblings, 0 replies; 200+ results
From: Morten Brørup @ 2022-12-03 17:13 UTC (permalink / raw)
To: olivier.matz, Shijith Thotton, thomas, andrew.rybchenko,
honnappa.nagarahalli, bruce.richardson
Cc: dev
I have been playing around with the idea to make some changes to avoid using the mbuf's 2nd cache line in many common cases, which would reduce the cache pressure significantly, and thus improve performance. I would like to discuss if it is doable. (And let's just assume that ABI breakage is an acceptable tradeoff.)
Move 'tx_offload' to the 1st cache line
---------------------------------------
Under all circumstances:
We would need to move the 'tx_offload' field to the 1st cache line. This field is set by the application's packet forwarding pipeline stage, and read by the PMD TX function. In most cases, these two stages directly follow each other.
This also means that we must make room for it by moving a 64 bit field from the 1st to the 2nd cache line. It could be the 'next' or the 'pool' field, as discussed below.
The 'next' field - make it conditional
--------------------------------------
Optimization for (1) non-segmented packets:
We could avoid touching the 'next' field by making the 'next' field depend on something in the first cache line. E.g.:
- Use the 'ol_flags' field. Add a RTE_MBUF_F_MORE_SEGS flag, to be set/cleared when setting/clearing the 'next' field.
- Use the 'nb_segs' field. Set the 'nb_segs' field to a value >1 when setting the 'next' field, and set it to 1 when clearing the 'next' field.
The 'pool' field - use it less frequently
-----------------------------------------
Optimizations for (2) single-mempool TX queues and (3) single-mempool applications:
The 'pool' field seems to be only used by when a PMD frees a burst of mbufs that it has finished transmitting. Please correct me if I am wrong here.
We could introduce a sibling to RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE, with the only requirement that the mbufs come from the same mempool. When set, only the first mbuf in a burst gets its 'pool' field read, thus avoiding reading it in the remaining mbufs in the burst.
For single-mempool applications, we could introduce a global 'mbuf_pool' variable, to be used instead of the mbuf's 'pool' field, if set.
Med venlig hilsen / Kind regards,
-Morten Brørup
^ permalink raw reply [relevance 3%]
* Re: [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
2022-12-02 13:39 0% ` Aaron Conole
@ 2022-12-05 10:23 3% ` David Marchand
2022-12-05 10:43 0% ` [EXT] " Akhil Goyal
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2022-12-05 10:23 UTC (permalink / raw)
To: David Marchand, ci, Thomas Monjalon, Ferruh Yigit,
Andrew Rybchenko, Ajit Khaparde, Qi Zhang,
Jerin Jacob Kollanukkaran, Raslan Darawsheh, Maxime Coquelin,
Xia, Chenbo, Akhil Goyal, Luca Boccassi, Kevin Traynor,
Christian Ehrhardt, Xueming(Steven) Li
Cc: dev, stable, Bruce Richardson, Michael Santana,
Abdullah Ömer Yamaç,
Aaron Conole
On Fri, Dec 2, 2022 at 2:39 PM Aaron Conole <aconole@redhat.com> wrote:
>
> David Marchand <david.marchand@redhat.com> writes:
>
> > ld exports any global symbol by default if no version script is passed.
> > As a consequence, the incriminated change let any public symbol leak
> > out of the driver shared libraries.
> >
> > Hide again those symbols by providing a default map file which
> > unexports any global symbol using a local: * catch-all statement.
> >
> > The checks are skipped for this default map file as it is intentionnally
> > an empty map (see commit b67bdda86cd4 ("devtools: catch empty symbol
> > maps")) and there is nothing else to check in this map.
> >
> > This change impacts the exported symbols, hence, bump the version in the
> > ABI check to the v22.11.1 from the 22.11 LTS branch.
> >
> > Fixes: 7dde9c844a37 ("drivers: omit symbol map when unneeded")
> > Cc: stable@dpdk.org
> >
> > Reported-by: Luca Boccassi <luca.boccassi@microsoft.com>
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
> > Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
> > Reviewed-by: Bruce Richardson <bruce.richardson@intel.com>
> Acked-by: Aaron Conole <aconole@redhat.com>
Series applied.
Please, maintainers and CI teams, when you enable ABI checks in the
main branch, or in the 22.11 LTS branch, use the dpdk-stable 22.11.1
tag as a reference.
Thanks.
--
David Marchand
^ permalink raw reply [relevance 3%]
* RE: [EXT] Re: [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
2022-12-05 10:23 3% ` David Marchand
@ 2022-12-05 10:43 0% ` Akhil Goyal
2022-12-05 12:36 0% ` David Marchand
0 siblings, 1 reply; 200+ results
From: Akhil Goyal @ 2022-12-05 10:43 UTC (permalink / raw)
To: David Marchand, ci, Thomas Monjalon, Ferruh Yigit,
Andrew Rybchenko, Ajit Khaparde, Qi Zhang,
Jerin Jacob Kollanukkaran, Raslan Darawsheh, Maxime Coquelin,
Xia, Chenbo, Luca Boccassi, Kevin Traynor, Christian Ehrhardt,
Xueming(Steven) Li
Cc: dev, stable, Bruce Richardson, Michael Santana,
Abdullah Ömer Yamaç,
Aaron Conole
> On Fri, Dec 2, 2022 at 2:39 PM Aaron Conole <aconole@redhat.com> wrote:
> >
> > David Marchand <david.marchand@redhat.com> writes:
> >
> > > ld exports any global symbol by default if no version script is passed.
> > > As a consequence, the incriminated change let any public symbol leak
> > > out of the driver shared libraries.
> > >
> > > Hide again those symbols by providing a default map file which
> > > unexports any global symbol using a local: * catch-all statement.
> > >
> > > The checks are skipped for this default map file as it is intentionnally
> > > an empty map (see commit b67bdda86cd4 ("devtools: catch empty symbol
> > > maps")) and there is nothing else to check in this map.
> > >
> > > This change impacts the exported symbols, hence, bump the version in the
> > > ABI check to the v22.11.1 from the 22.11 LTS branch.
> > >
> > > Fixes: 7dde9c844a37 ("drivers: omit symbol map when unneeded")
> > > Cc: stable@dpdk.org
> > >
> > > Reported-by: Luca Boccassi <luca.boccassi@microsoft.com>
> > > Signed-off-by: David Marchand <david.marchand@redhat.com>
> > > Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
> > > Reviewed-by: Bruce Richardson <bruce.richardson@intel.com>
> > Acked-by: Aaron Conole <aconole@redhat.com>
>
> Series applied.
>
> Please, maintainers and CI teams, when you enable ABI checks in the
> main branch, or in the 22.11 LTS branch, use the dpdk-stable 22.11.1
> tag as a reference.
> Thanks.
Should we also add a tag on main repo, as new development does not happen
on stable tree?
Regards,
Akhil
^ permalink raw reply [relevance 0%]
* Re: [EXT] Re: [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
2022-12-05 10:43 0% ` [EXT] " Akhil Goyal
@ 2022-12-05 12:36 0% ` David Marchand
2022-12-05 13:47 0% ` Akhil Goyal
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2022-12-05 12:36 UTC (permalink / raw)
To: Akhil Goyal
Cc: ci, Thomas Monjalon, Ferruh Yigit, Andrew Rybchenko,
Ajit Khaparde, Qi Zhang, Jerin Jacob Kollanukkaran,
Raslan Darawsheh, Maxime Coquelin, Xia, Chenbo, Luca Boccassi,
Kevin Traynor, Christian Ehrhardt, Xueming(Steven) Li, dev,
stable, Bruce Richardson, Michael Santana,
Abdullah Ömer Yamaç,
Aaron Conole
On Mon, Dec 5, 2022 at 11:44 AM Akhil Goyal <gakhil@marvell.com> wrote:
> > Please, maintainers and CI teams, when you enable ABI checks in the
> > main branch, or in the 22.11 LTS branch, use the dpdk-stable 22.11.1
> > tag as a reference.
> > Thanks.
>
> Should we also add a tag on main repo, as new development does not happen
> on stable tree?
You can fetch the v22.11.1 tag from the stable tree.
--
David Marchand
^ permalink raw reply [relevance 0%]
* RE: [EXT] Re: [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
2022-12-05 12:36 0% ` David Marchand
@ 2022-12-05 13:47 0% ` Akhil Goyal
2022-12-05 15:37 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Akhil Goyal @ 2022-12-05 13:47 UTC (permalink / raw)
To: David Marchand
Cc: ci, Thomas Monjalon, Ferruh Yigit, Andrew Rybchenko,
Ajit Khaparde, Qi Zhang, Jerin Jacob Kollanukkaran,
Raslan Darawsheh, Maxime Coquelin, Xia, Chenbo, Luca Boccassi,
Kevin Traynor, Christian Ehrhardt, Xueming(Steven) Li, dev,
stable, Bruce Richardson, Michael Santana,
Abdullah Ömer Yamaç,
Aaron Conole
> On Mon, Dec 5, 2022 at 11:44 AM Akhil Goyal <gakhil@marvell.com> wrote:
> > > Please, maintainers and CI teams, when you enable ABI checks in the
> > > main branch, or in the 22.11 LTS branch, use the dpdk-stable 22.11.1
> > > tag as a reference.
> > > Thanks.
> >
> > Should we also add a tag on main repo, as new development does not happen
> > on stable tree?
>
> You can fetch the v22.11.1 tag from the stable tree.
Yes, that is an obvious option.
But adding a tag on same repo is more convenient from developer point of view.
However, it is my personal view, others may differ.
-Akhil
^ permalink raw reply [relevance 0%]
* Re: [EXT] Re: [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
2022-12-05 13:47 0% ` Akhil Goyal
@ 2022-12-05 15:37 0% ` Thomas Monjalon
2022-12-05 16:26 0% ` Akhil Goyal
2022-12-06 10:12 0% ` Ferruh Yigit
0 siblings, 2 replies; 200+ results
From: Thomas Monjalon @ 2022-12-05 15:37 UTC (permalink / raw)
To: David Marchand, Akhil Goyal
Cc: ci, Ferruh Yigit, Andrew Rybchenko, Ajit Khaparde, Qi Zhang,
Jerin Jacob Kollanukkaran, Raslan Darawsheh, Maxime Coquelin,
Xia, Chenbo, Luca Boccassi, Kevin Traynor, Christian Ehrhardt,
Xueming(Steven) Li, dev, stable, Bruce Richardson,
Michael Santana, Abdullah Ömer Yamaç,
Aaron Conole
05/12/2022 14:47, Akhil Goyal:
> > On Mon, Dec 5, 2022 at 11:44 AM Akhil Goyal <gakhil@marvell.com> wrote:
> > > > Please, maintainers and CI teams, when you enable ABI checks in the
> > > > main branch, or in the 22.11 LTS branch, use the dpdk-stable 22.11.1
> > > > tag as a reference.
> > > > Thanks.
> > >
> > > Should we also add a tag on main repo, as new development does not happen
> > > on stable tree?
> >
> > You can fetch the v22.11.1 tag from the stable tree.
> Yes, that is an obvious option.
> But adding a tag on same repo is more convenient from developer point of view.
> However, it is my personal view, others may differ.
From developer point of view, you should use devtools/test-meson-builds.sh
which does the "git clone" for you.
This is what I have in ~/.config/dpdk/devel.config
export DPDK_ABI_REF_DIR=$root/dpdk-build/abiref
export DPDK_ABI_REF_VERSION=v22.11.1
^ permalink raw reply [relevance 0%]
* RE: [EXT] Re: [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
2022-12-05 15:37 0% ` Thomas Monjalon
@ 2022-12-05 16:26 0% ` Akhil Goyal
2022-12-06 10:12 0% ` Ferruh Yigit
1 sibling, 0 replies; 200+ results
From: Akhil Goyal @ 2022-12-05 16:26 UTC (permalink / raw)
To: Thomas Monjalon, David Marchand
Cc: ci, Ferruh Yigit, Andrew Rybchenko, Ajit Khaparde, Qi Zhang,
Jerin Jacob Kollanukkaran, Raslan Darawsheh, Maxime Coquelin,
Xia, Chenbo, Luca Boccassi, Kevin Traynor, Christian Ehrhardt,
Xueming(Steven) Li, dev, stable, Bruce Richardson,
Michael Santana, Abdullah Ömer Yamaç,
Aaron Conole
> 05/12/2022 14:47, Akhil Goyal:
> > > On Mon, Dec 5, 2022 at 11:44 AM Akhil Goyal <gakhil@marvell.com> wrote:
> > > > > Please, maintainers and CI teams, when you enable ABI checks in the
> > > > > main branch, or in the 22.11 LTS branch, use the dpdk-stable 22.11.1
> > > > > tag as a reference.
> > > > > Thanks.
> > > >
> > > > Should we also add a tag on main repo, as new development does not
> happen
> > > > on stable tree?
> > >
> > > You can fetch the v22.11.1 tag from the stable tree.
> > Yes, that is an obvious option.
> > But adding a tag on same repo is more convenient from developer point of
> view.
> > However, it is my personal view, others may differ.
>
> From developer point of view, you should use devtools/test-meson-builds.sh
> which does the "git clone" for you.
>
> This is what I have in ~/.config/dpdk/devel.config
> export DPDK_ABI_REF_DIR=$root/dpdk-build/abiref
> export DPDK_ABI_REF_VERSION=v22.11.1
Ok got it, thanks.
^ permalink raw reply [relevance 0%]
* Re: [PATCH 3/3] eal: deprecate pthread control thread create API
@ 2022-12-06 0:24 3% ` Tyler Retzlaff
0 siblings, 0 replies; 200+ results
From: Tyler Retzlaff @ 2022-12-06 0:24 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev, thomas, david.marchand, olivier.matz
On Mon, Dec 05, 2022 at 01:18:05PM -0800, Stephen Hemminger wrote:
> On Mon, 5 Dec 2022 12:24:28 -0800
> Tyler Retzlaff <roretzla@linux.microsoft.com> wrote:
>
> > +
> > +* eal: The function ``rte_ctrl_thread_create`` will be removed and
> > + replaced by the new ``rte_control_thread_create``api, continuing the
> > + effort to decouple eal from platform-specific thread implementations.
>
> If you want to change this (which is a good idea)
> then mark the function with __rte_deprecated now, and cleanup all the examples
> and test programs please.
i would like to mark it deprecated now but it seems the policy governing
abi replacement prevent me from doing so.
```
3.3.3. New API replacing previous one
If a new API proposed functionally replaces an existing one, when the
new API becomes non-experimental then the old one is marked with
__rte_deprecated. Deprecated APIs are removed completely just after the
next LTS.
```
as i interpreted this i am not permitted to mark the old api
__rte_deprecated until the new api is no longer marked
__rte_experimental.
of course i'm happy to skip marking the new api __rte_experimental if
people find that a satisfactory solution?
let me know.
^ permalink raw reply [relevance 3%]
* Re: [EXT] Re: [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
2022-12-05 15:37 0% ` Thomas Monjalon
2022-12-05 16:26 0% ` Akhil Goyal
@ 2022-12-06 10:12 0% ` Ferruh Yigit
1 sibling, 1 reply; 200+ results
From: Ferruh Yigit @ 2022-12-06 10:12 UTC (permalink / raw)
To: Thomas Monjalon, David Marchand, Akhil Goyal
Cc: ci, Andrew Rybchenko, Ajit Khaparde, Qi Zhang,
Jerin Jacob Kollanukkaran, Raslan Darawsheh, Maxime Coquelin,
Xia, Chenbo, Luca Boccassi, Kevin Traynor, Christian Ehrhardt,
Xueming(Steven) Li, dev, stable, Bruce Richardson,
Michael Santana, Abdullah Ömer Yamaç,
Aaron Conole
On 12/5/2022 3:37 PM, Thomas Monjalon wrote:
> 05/12/2022 14:47, Akhil Goyal:
>>> On Mon, Dec 5, 2022 at 11:44 AM Akhil Goyal <gakhil@marvell.com> wrote:
>>>>> Please, maintainers and CI teams, when you enable ABI checks in the
>>>>> main branch, or in the 22.11 LTS branch, use the dpdk-stable 22.11.1
>>>>> tag as a reference.
>>>>> Thanks.
>>>>
>>>> Should we also add a tag on main repo, as new development does not happen
>>>> on stable tree?
>>>
>>> You can fetch the v22.11.1 tag from the stable tree.
>> Yes, that is an obvious option.
>> But adding a tag on same repo is more convenient from developer point of view.
>> However, it is my personal view, others may differ.
>
> From developer point of view, you should use devtools/test-meson-builds.sh
> which does the "git clone" for you.
>
> This is what I have in ~/.config/dpdk/devel.config
> export DPDK_ABI_REF_DIR=$root/dpdk-build/abiref
> export DPDK_ABI_REF_VERSION=v22.11.1
>
Does it help to update 'test-meson-builds.sh' to use an environment
variable to select which repo to clone?
If so, I can send a patch for it.
^ permalink raw reply [relevance 0%]
* [PATCH] devtools: update Meson setup command
@ 2022-12-06 10:16 4% Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2022-12-06 10:16 UTC (permalink / raw)
To: dev; +Cc: Aaron Conole, Michael Santana, Bruce Richardson
The command "meson build" causes a deprecation warning with meson 0.64:
WARNING: Running the setup command as `meson [options]` instead of
`meson setup [options]` is ambiguous and deprecated.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
.ci/linux-build.sh | 2 +-
devtools/test-meson-builds.sh | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
index baec65a914..5225dc71c4 100755
--- a/.ci/linux-build.sh
+++ b/.ci/linux-build.sh
@@ -163,7 +163,7 @@ if [ "$ABI_CHECKS" = "true" ]; then
if [ ! -d reference ]; then
refsrcdir=$(readlink -f $(pwd)/../dpdk-$REF_GIT_TAG)
git clone --single-branch -b "$REF_GIT_TAG" $REF_GIT_REPO $refsrcdir
- meson $OPTS -Dexamples= $refsrcdir $refsrcdir/build
+ meson setup $OPTS -Dexamples= $refsrcdir $refsrcdir/build
ninja -C $refsrcdir/build
DESTDIR=$(pwd)/reference ninja -C $refsrcdir/build install
devtools/gen-abi.sh reference
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index 3a308bc9af..7efd5576fc 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -124,8 +124,8 @@ config () # <dir> <builddir> <meson options>
options="$options -D$option"
done
options="$options $*"
- echo "$MESON $options $dir $builddir" >&$verbose
- $MESON $options $dir $builddir
+ echo "$MESON setup $options $dir $builddir" >&$verbose
+ $MESON setup $options $dir $builddir
}
compile () # <builddir>
--
2.38.1
^ permalink raw reply [relevance 4%]
* 21.11.3 patches review and test
@ 2022-12-06 11:29 1% Kevin Traynor
2022-12-13 11:48 0% ` Christian Ehrhardt
2022-12-16 7:55 0% ` YangHang Liu
0 siblings, 2 replies; 200+ results
From: Kevin Traynor @ 2022-12-06 11:29 UTC (permalink / raw)
To: stable
Cc: dev, Abhishek Marathe, Ali Alnubani, benjamin.walker,
David Christensen, Hemant Agrawal, Ian Stokes, Jerin Jacob,
John McNamara, Ju-Hyoung Lee, Kevin Traynor, Luca Boccassi,
Pei Zhang, qian.q.xu, Raslan Darawsheh, Thomas Monjalon,
yanghliu, yuan.peng, zhaoyan.chen
Hi all,
Here is a list of patches targeted for stable release 21.11.3.
The planned date for the final release is 19th December.
Please help with testing and validation of your use cases and report
any issues/results with reply-all to this mail. For the final release
the fixes and reported validations will be added to the release notes.
A release candidate tarball can be found at:
https://dpdk.org/browse/dpdk-stable/tag/?id=v21.11.3-rc1
These patches are located at branch 21.11 of dpdk-stable repo:
https://dpdk.org/browse/dpdk-stable/
Thanks.
Kevin
---
Abdullah Sevincer (1):
event/dlb2: handle enqueuing more than maximum depth
Abhimanyu Saini (1):
common/sfc_efx/base: remove VQ index check during VQ start
Aleksandr Miloshenko (1):
net/iavf: fix Tx done descriptors cleanup
Alex Kiselev (1):
net/tap: fix overflow of network interface index
Alexander Chernavin (1):
net/virtio: fix crash when configured twice
Alexander Kozyrev (3):
net/mlx5: fix shared Rx queue config reuse
net/mlx5: fix first segment inline length
net/mlx5: fix indexed pool local cache crash
Ali Alnubani (1):
examples/l2fwd-crypto: fix typo in error message
Amit Prakash Shukla (6):
net/mvneta: fix build with GCC 12
test/ipsec: fix build with GCC 12
ipsec: fix build with GCC 12
crypto/qat: fix build with GCC 12
net/i40e: fix build with MinGW GCC 12
net/qede/base: fix 32-bit build with GCC 12
Andrew Boyer (5):
net/ionic: fix endianness for Rx and Tx
net/ionic: fix endianness for RSS
net/ionic: fix adapter name for logging
net/ionic: fix Rx filter save
net/ionic: fix reported error stats
Anoob Joseph (1):
test/crypto: fix PDCP vectors
Apeksha Gupta (2):
net/enetfec: fix restart
net/enetfec: fix buffer leak
Arek Kusztal (1):
common/qat: fix VF to PF answer
Ashwin Sekhar T K (1):
mempool/cnxk: fix destroying empty pool
Ben Magistro (1):
doc: fix dumpcap interface parameter option
Benjamin Le Berre (1):
net/bnxt: fix error code during MTU change
Bhagyada Modali (9):
net/axgbe: fix scattered Rx
net/axgbe: fix mbuf lengths in scattered Rx
net/axgbe: fix length of each segment in scattered Rx
net/axgbe: fix checksum and RSS in scattered Rx
net/axgbe: optimise scattered Rx
net/axgbe: remove freeing buffer in scattered Rx
net/axgbe: reset end of packet in scattered Rx
net/axgbe: clear buffer on scattered Rx chaining failure
net/axgbe: save segment data in scattered Rx
Bing Zhao (2):
net/mlx5: fix build with recent compilers
bus/auxiliary: prevent device from being probed again
Brian Dooley (1):
crypto/qat: fix null hash algorithm digest size
Changpeng Liu (1):
vhost: add non-blocking API for posting interrupt
Chaoyong He (1):
net/nfp: fix Rx descriptor DMA address
Chengwen Feng (8):
net/hns3: fix crash in SVE Tx
net/hns3: fix next-to-use overflow in SVE Tx
net/hns3: fix next-to-use overflow in simple Tx
net/hns3: fix crash when secondary process access FW
net/hns3: revert Tx performance optimization
net/hns3: revert fix mailbox communication with HW
net/hns3: fix VF mailbox message handling
app/testpmd: remove jumbo offload
Ciara Power (1):
test/crypto: fix wireless auth digest segment
Conor Walsh (1):
doc: fix reference to dma application example
Dariusz Sosnowski (1):
net/mlx5: fix hairpin split with set VLAN VID action
David Marchand (23):
vhost: fix virtqueue use after free on NUMA reallocation
app/testpmd: restore ixgbe bypass commands
net/failsafe: fix interrupt handle leak
net/bnxt: fix build with GCC 13
trace: fix mode for new trace point
trace: fix mode change
trace: fix leak with regexp
trace: fix dynamically enabling trace points
trace: fix race in debug dump
ci: bump versions of actions in GHA
ci: update to new API for step outputs in GHA
service: fix build with clang 15
vhost: fix build with clang 15
bus/dpaa: fix build with clang 15
net/atlantic: fix build with clang 15
net/dpaa2: fix build with clang 15
app/testpmd: fix build with clang 15
app/testpmd: fix build with clang 15 in flow code
test/efd: fix build with clang 15
test/member: fix build with clang 15
test/event: fix build with clang 15
ci: enable ABI check in GHA
trace: fix metadata dump
Dmitry Kozlyuk (4):
build: enable developer mode for all working trees
eal: fix side effect in some pointer arithmetic macros
mempool: make event callbacks process-private
common/mlx5: fix multi-process mempool registration
Dong Zhou (1):
net/mlx5: fix thread workspace memory leak
Dongdong Liu (2):
doc: fix application name in procinfo guide
doc: document device dump in procinfo guide
Erik Gabriel Carrillo (1):
service: fix early move to inactive status
Fidaullah Noonari (1):
malloc: fix storage size for some allocations
Frank Du (1):
net/ice: fix interrupt handler unregister
Gagandeep Singh (5):
net/dpaa: fix buffer freeing in slow path
net/dpaa: use internal mempool for SG table
net/dpaa: fix buffer freeing on SG Tx
net/dpaa2: use internal mempool for SG table
net/dpaa2: fix buffer freeing on SG Tx
Ganapati Kundapura (1):
eventdev/crypto: fix multi-process
Gregory Etelson (6):
net/mlx5: fix RSS expansion buffer size
app/testpmd: fix MAC header in checksum forward engine
common/mlx5: fix shared mempool subscription
net/mlx5: fix port initialization with small LRO
net/mlx5: fix maximum LRO message size
doc: add LRO size limitation in mlx5 guide
Haiyue Wang (1):
ring: fix description
Hamza Khan (1):
examples/vm_power_manager: use safe list iterator
Hanumanth Pothula (1):
net/cnxk: fix DF bit in vector mode
Hernan Vargas (14):
baseband/acc100: fix memory leak
baseband/acc100: check turbo dec/enc input
baseband/acc100: add null checks
baseband/acc100: fix input length for CRC24B
baseband/acc100: fix clearing PF IR outside handler
baseband/acc100: fix device minimum alignment
baseband/acc100: fix close cleanup
baseband/acc100: add LDPC encoder padding function
baseband/acc100: check AQ availability
baseband/acc100: fix ring availability calculation
baseband/acc100: enforce additional check on FCW
baseband/acc100: fix null HARQ input case
baseband/acc100: fix ring/queue allocation
baseband/acc100: fix double MSI intr in TB mode
Huisong Li (18):
net/hns3: fix Rx with PTP
net/hns3: delete unused markup
net/hns3: fix clearing hardware MAC statistics
net/hns3: fix RSS filter restore
net/hns3: fix RSS flow rule restore
net/hns3: move flow direction rule recovery
net/hns3: fix packet type for GENEVE
net/hns3: fix IPv4 and IPv6 RSS
net/hns3: fix typos in IPv6 SCTP fields
net/hns3: fix IPv4 RSS
net/hns3: add L3 and L4 RSS types
net/bonding: fix slave device Rx/Tx offload configuration
net/bonding: fix dropping valid MAC packets
net/bonding: fix mbuf fast free handling
net/hns3: extract functions to create RSS and FDIR flow rule
net/hns3: fix RSS rule restore
net/hns3: fix lock protection of RSS flow rule
net/hns3: fix restore filter function input
Huzaifa Rahman (1):
net/memif: fix crash with different number of Rx/Tx queues
Ilya Maximets (1):
doc: fix support table for Ethernet/VLAN flow items
Ivan Malov (3):
common/sfc_efx/base: fix maximum Tx data count
net/bonding: fix descriptor limit reporting
net/bonding: fix flow flush order on close
James Hershaw (1):
net/nfp: improve HW info header log readability
Jeremy Spewock (1):
test/ipsec: skip if no compatible device
Jerin Jacob (2):
eal: fix doxygen comments for UUID
power: fix some doxygen comments
Jiawei Wang (4):
net/mlx5: fix modify action with tunnel decapsulation
net/mlx5: fix tunnel header with IPIP offload
net/mlx5: fix source port checking in sample flow rule
net/mlx5: fix mirror flow validation with ASO action
Jiawen Wu (6):
net/txgbe: fix IPv6 flow rule
net/txgbe: remove semaphore between SW/FW
net/txgbe: rename some extended statistics
net/ngbe: rename some extended statistics
net/ngbe: remove semaphore between SW/FW
net/ngbe: fix maximum frame size
Jie Hai (1):
net/hns3: fix minimum Tx frame length
Jie Wang (1):
net/i40e: fix jumbo frame Rx with X722
Jun Qiu (3):
gro: trim tail padding bytes
net/bonding: fix Tx hash for TCP
hash: fix RCU configuration memory leak
Kai Ji (1):
test/crypto: fix bitwise operator in a SNOW3G case
Kalesh AP (2):
net/bnxt: remove unnecessary check
net/bnxt: fix representor info freeing
Ke Zhang (2):
net/i40e: fix VF representor release
net/iavf: fix L3 checksum Tx offload flag
Kevin Liu (2):
net/iavf: check illegal packet sizes
net/ice: check illegal packet sizes
Kevin Traynor (1):
Revert "cryptodev: fix missing SHA3 algorithm strings"
Kumara Parameshwaran (1):
gro: check payload length after trim
Long Li (2):
net/mlx4: fix Verbs FD leak in secondary process
net/mlx5: fix Verbs FD leak in secondary process
Long Wu (1):
net/nfp: fix memory leak in Rx
Luca Boccassi (1):
drivers: fix typos found by Lintian
Mao YingMing (1):
net/bnxt: fix null pointer dereference in LED config
Mattias Rönnblom (3):
net: accept unaligned data in checksum routines
event/dsw: fix flow migration
doc: fix event timer adapter guide
Maxime Coquelin (1):
vhost: fix build with GCC 12
Megha Ajmera (2):
sched: fix subport profile configuration
examples/qos_sched: fix number of subport profiles
Michael Baum (5):
net/mlx5: fix null check in devargs parsing
doc: fix underlines in testpmd guide
doc: fix colons in testpmd aged flow rules
net/mlx5: fix race condition in counter pool resizing
net/mlx5: fix port event cleaning order
Mingjin Ye (4):
net/ice: support VXLAN-GPE tunnel offload
net/i40e: fix pctype configuration for X722
net/ice: fix scalar Rx path segment
net/ice: fix scalar Tx path segment
Mário Kuka (1):
pcapng: fix write more packets than IOV_MAX limit
Naga Harish K S V (4):
eventdev/eth_tx: add spinlock for adapter start/stop
eventdev/eth_tx: fix adapter stop
timer: fix stopping all timers
eventdev/eth_tx: fix queue delete
Nithin Dabilpuram (3):
examples/ipsec-secgw: use Tx checksum offload conditionally
examples/l3fwd: fix MTU configuration with event mode
net/cnxk: fix later skip to include mbuf private data
Olivier Matz (7):
cryptodev: fix unduly newlines in logs
mem: fix API doc about allocation on secondary processes
event/sw: fix flow ID init in self test
event/sw: fix log in self test
net/ixgbe: fix broadcast Rx on VF after promisc removal
net/ixgbe: fix unexpected VLAN Rx in promisc mode on VF
net/ixgbevf: fix promiscuous and allmulti
Pablo de Lara (1):
examples/fips_validation: fix typo in error log
Pavan Nikhilesh (3):
event/cnxk: fix missing xstats operations
event/cnxk: fix mbuf offset calculation
event/cnxk: fix missing mempool cookie marking
Peng Zhang (3):
net/nfp: compose firmware file name with new hwinfo
buildtools: fix NUMA nodes count
net/nfp: fix internal buffer size and MTU check
Qi Zhang (12):
net/ice/base: fix division during E822 PTP init
net/ice/base: fix 100M speed capability
net/ice/base: fix DSCP PFC TLV creation
net/ice/base: fix media type of PHY 10G SFI C2C
net/ice/base: fix function descriptions for parser
net/ice/base: fix endian format
net/ice/base: fix array overflow in add switch recipe
net/ice/base: fix bit finding range over ptype bitmap
net/ice/base: fix add MAC rule
net/ice/base: fix double VLAN in promiscuous mode
net/ice/base: ignore promiscuous already exist
net/ice/base: fix input set of GTPoGRE
Qiming Yang (1):
app/testpmd: skip port reset in secondary process
Radu Nicolau (5):
net/iavf: update IPsec ESN values when updating session
net/iavf: fix IPsec flow create error check
net/iavf: fix SPI check
net/iavf: fix queue stop for large VF
examples/ipsec-secgw: fix Tx checksum offload flag
Raja Zidane (1):
net/mlx5: fix Tx check for hardware descriptor length
Rohit Raj (1):
net/dpaa: fix jumbo packet Rx in case of VSP
Satha Rao (1):
common/cnxk: fix schedule weight update
Satheesh Paul (3):
common/cnxk: fix log level during MCAM allocation
common/cnxk: fix missing flow counter reset
common/cnxk: fix printing disabled MKEX registers
Shiqi Liu (2):
node: check Rx element allocation
dma/idxd: check DSA device allocation
Shun Hao (4):
net/mlx5: fix meter profile delete after disable
net/mlx5: fix action flag data type
net/mlx5: fix drop action validation
net/mlx5: fix assert when creating meter policy
Stephen Coleman (1):
doc: fix typo depreciated instead of deprecated
Stephen Hemminger (8):
event/sw: fix device name in dump
eal: fix data race in multi-process support
pdump: do not allow enable/disable in primary process
app/dumpcap: fix crash on cleanup
app/dumpcap: fix pathname for output file
app/testpmd: make quit flag volatile
ring: remove leftover comment about watermark
doc: avoid meson deprecation in setup
Steve Yang (1):
net/iavf: fix pattern check for flow director parser
Steven Zou (1):
common/iavf: avoid copy in async mode
Sunyang Wu (1):
test/crypto: fix debug messages
Taekyung Kim (1):
vdpa/ifc: handle data path update failure
Tal Shnaiderman (1):
net/mlx5: fix thread termination check on Windows
Thomas Monjalon (2):
drivers: remove unused build variable
doc: add Rx buffer split capability for mlx5
Ting Xu (1):
net/ice/base: fix inner symmetric RSS hash in raw flow
Tomasz Jonak (1):
net/ice: fix null function pointer call
Vanshika Shukla (1):
net/dpaa2: fix DPDMUX error behaviour
Viacheslav Ovsiienko (3):
net/mlx5: fix check for orphan wait descriptor
net/mlx5: fix single not inline packet storing
net/mlx5: fix inline length exceeding descriptor limit
Vladimir Medvedkin (2):
test/hash: remove dead code in extendable bucket test
test/hash: fix bulk lookup check
Volodymyr Fialko (3):
cryptodev: fix missing SHA3 algorithm strings
eventdev: fix name of Rx conf type in documentation
app/eventdev: fix limits in error message
Wenwu Ma (1):
examples/vhost: fix use after free
Wenzhuo Lu (1):
net/iavf: fix VLAN offload
Yi Li (1):
doc: fix maximum packet size of virtio driver
Yiding Zhou (4):
net/iavf: fix VLAN insertion
net/iavf: revert VLAN insertion fix
net/ice/base: fix duplicate flow rules
net/iavf: add thread for event callbacks
Yunjian Wang (2):
net/bonding: fix array overflow in Rx burst
net/bonding: fix double slave link status query
Zhichao Zeng (3):
net/ice: fix RSS hash update
net/iavf: fix processing VLAN TCI in SSE path
net/iavf: fix outer checksum flags
Zhirun Yan (1):
graph: fix node objects allocation
^ permalink raw reply [relevance 1%]
* [PATCH 2/2] devtools: configure source repo to use as ABI reference
@ 2022-12-06 12:23 17% ` Ferruh Yigit
2022-12-08 18:14 7% ` [EXT] " Akhil Goyal
2022-12-09 8:22 8% ` David Marchand
1 sibling, 2 replies; 200+ results
From: Ferruh Yigit @ 2022-12-06 12:23 UTC (permalink / raw)
To: Thomas Monjalon, Bruce Richardson; +Cc: David Marchand, dev
By default 'test-meson-builds.sh' script clones the repository which the
script is in, and selects a configured branch ('DPDK_ABI_REF_VERSION')
as a reference for ABI check.
This patch enables selecting different repository to close for reference
using 'DPDK_ABI_REF_SRC' environment variable.
It is possible to put these variables to 'devel.config' config file, or
provide via command line, like:
`
DPDK_ABI_REF_SRC=~/dpdk-stable/ \
DPDK_ABI_REF_VERSION=v22.11.1 \
DPDK_ABI_REF_DIR=/tmp/dpdk-abiref \
./devtools/test-meson-builds.sh
`
When 'DPDK_ABI_REF_SRC' is not defined, script behaves as it did
previously.
Other alternative to using 'DPDK_ABI_REF_SRC' variable is adding that
other repo as a new 'remote' to the exiting git repository.
Signed-off-by: Ferruh Yigit <ferruh.yigit@amd.com>
---
devtools/test-meson-builds.sh | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index bbe90e2bde2e..8a0ed92fcf0a 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -18,6 +18,7 @@ srcdir=$(dirname $(readlink -f $0))/..
#
# - DPDK_MESON_OPTIONS
#
+# - DPDK_ABI_REF_SRC
# - DPDK_ABI_REF_DIR
# - DPDK_ABI_REF_VERSION
#
@@ -185,12 +186,13 @@ build () # <directory> <target cc | cross file> <ABI check> [meson options]
if [ -n "$DPDK_ABI_REF_VERSION" -a "$abicheck" = ABI ] ; then
abirefdir=${DPDK_ABI_REF_DIR:-reference}/$DPDK_ABI_REF_VERSION
if [ ! -d $abirefdir/$targetdir ]; then
+ abirefsrc=${DPDK_ABI_REF_SRC:-$srcdir}
# clone current sources
if [ ! -d $abirefdir/src ]; then
git clone --local --no-hardlinks \
--single-branch \
-b $DPDK_ABI_REF_VERSION \
- $srcdir $abirefdir/src
+ $abirefsrc $abirefdir/src
fi
rm -rf $abirefdir/build
--
2.25.1
^ permalink raw reply [relevance 17%]
* Re: [PATCH v2 1/3] eal: add rte control thread create API
@ 2022-12-07 16:38 3% ` Tyler Retzlaff
2022-12-08 21:59 0% ` Mattias Rönnblom
0 siblings, 1 reply; 200+ results
From: Tyler Retzlaff @ 2022-12-07 16:38 UTC (permalink / raw)
To: Mattias Rönnblom
Cc: dev, thomas, david.marchand, stephen, olivier.matz, mb
On Wed, Dec 07, 2022 at 10:13:39AM +0100, Mattias Rönnblom wrote:
> On 2022-12-06 18:28, Tyler Retzlaff wrote:
> >Add rte_control_thread_create API as a replacement for
> >rte_ctrl_thread_create to allow deprecation of the use of platform
> >specific types in DPDK public API.
> >
> >Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> >---
> > lib/eal/common/eal_common_thread.c | 93 ++++++++++++++++++++++++++++++++++----
> > lib/eal/include/rte_thread.h | 29 ++++++++++++
> > lib/eal/version.map | 3 ++
> > 3 files changed, 117 insertions(+), 8 deletions(-)
> >
> >diff --git a/lib/eal/common/eal_common_thread.c b/lib/eal/common/eal_common_thread.c
> >index c5d8b43..7950b50 100644
> >--- a/lib/eal/common/eal_common_thread.c
> >+++ b/lib/eal/common/eal_common_thread.c
> >@@ -234,7 +234,10 @@ enum __rte_ctrl_thread_status {
> > };
> > struct rte_thread_ctrl_params {
> >- void *(*start_routine)(void *);
> >+ union {
> >+ void *(*start_routine)(void *);
> >+ rte_thread_func thread_func;
>
> To be consistent with function naming scheme, where "ctrl" is the
> old API, and "control" the new, you could call the start functions
> something with "ctrl" and "control" as well.
i'll make this change in v3.
>
> Maybe it's worth mentioning that fact somewhere in the beginning of
> the file, as a comment (i.e., that "ctrl" denotes the old API).
i'll make this change in v3.
>
> >+ } u;
> > void *arg;
> > int ret;
>
> Why is 'ret' needed? (This question is unrelated to your patch.)
i'm not the original author so difficult to answer authoritatively. but
if i have to speculate i'd say it might be to work around the windows
pthread_join stub being implemented as a noop. specifically it didn't
communicate the return value from the start_routine.
the recently added rte_thread_join addresses this (which
rte_control_thread_create uses) and could remove ret parameter and to
avoid touching the new function implementation in the future it can not
use ret now.
i'll make this change in v3.
for the original function i will leave the code as is to minimize the
diff. when rte_ctrl_thread_create is removed i'll make a note to
eliminate the ret parameter as well.
>
> > /* Control thread status.
> >@@ -243,14 +246,12 @@ struct rte_thread_ctrl_params {
> > enum __rte_ctrl_thread_status ctrl_thread_status;
> > };
> >-static void *ctrl_thread_init(void *arg)
> >+static int ctrl_thread_init(void *arg)
> > {
> > struct internal_config *internal_conf =
> > eal_get_internal_configuration();
> > rte_cpuset_t *cpuset = &internal_conf->ctrl_cpuset;
> > struct rte_thread_ctrl_params *params = arg;
> >- void *(*start_routine)(void *) = params->start_routine;
> >- void *routine_arg = params->arg;
> > __rte_thread_init(rte_lcore_id(), cpuset);
> > params->ret = pthread_setaffinity_np(pthread_self(), sizeof(*cpuset),
> >@@ -258,13 +259,35 @@ static void *ctrl_thread_init(void *arg)
> > if (params->ret != 0) {
> > __atomic_store_n(¶ms->ctrl_thread_status,
> > CTRL_THREAD_ERROR, __ATOMIC_RELEASE);
> >- return NULL;
> >+ return params->ret;
> > }
> > __atomic_store_n(¶ms->ctrl_thread_status,
> > CTRL_THREAD_RUNNING, __ATOMIC_RELEASE);
> >- return start_routine(routine_arg);
> >+ return 0;
> >+}
> >+
> >+static void *ctrl_thread_start(void *arg)
> >+{
> >+ struct rte_thread_ctrl_params *params = arg;
> >+ void *(*start_routine)(void *) = params->u.start_routine;
> >+
> >+ if (ctrl_thread_init(arg) != 0)
> >+ return NULL;
> >+
> >+ return start_routine(params->arg);
> >+}
> >+
> >+static uint32_t control_thread_start(void *arg)
> >+{
> >+ struct rte_thread_ctrl_params *params = arg;
> >+ rte_thread_func start_routine = params->u.thread_func;
> >+
> >+ if (ctrl_thread_init(arg) != 0)
> >+ return params->ret;
> >+
> >+ return start_routine(params->arg);
> > }
> > int
> >@@ -280,12 +303,12 @@ static void *ctrl_thread_init(void *arg)
> > if (!params)
> > return -ENOMEM;
> >- params->start_routine = start_routine;
> >+ params->u.start_routine = start_routine;
> > params->arg = arg;
> > params->ret = 0;
> > params->ctrl_thread_status = CTRL_THREAD_LAUNCHING;
> >- ret = pthread_create(thread, attr, ctrl_thread_init, (void *)params);
> >+ ret = pthread_create(thread, attr, ctrl_thread_start, (void *)params);
> > if (ret != 0) {
> > free(params);
> > return -ret;
> >@@ -322,6 +345,60 @@ static void *ctrl_thread_init(void *arg)
> > }
> > int
> >+rte_control_thread_create(rte_thread_t *thread, const char *name,
> >+ const rte_thread_attr_t *attr,
> >+ rte_thread_func start_routine, void *arg)
> >+{
> >+ struct rte_thread_ctrl_params *params;
> >+ enum __rte_ctrl_thread_status ctrl_thread_status;
> >+ int ret;
> >+
> >+ params = malloc(sizeof(*params));
> >+ if (!params)
>
> params == NULL
copied from original code, i'll fix the style in the new function to
comply with the dpdk coding standard.
i'll fix in v3.
>
> >+ return -ENOMEM;
> >+
> >+ params->u.thread_func = start_routine;
> >+ params->arg = arg;
> >+ params->ret = 0;
> >+ params->ctrl_thread_status = CTRL_THREAD_LAUNCHING;
> >+
> >+ ret = rte_thread_create(thread, attr, control_thread_start, params);
> >+ if (ret != 0) {
> >+ free(params);
> >+ return -ret;
> >+ }
> >+
> >+ if (name != NULL) {
> >+ ret = rte_thread_setname((pthread_t)thread->opaque_id, name);
> >+ if (ret < 0)
> >+ RTE_LOG(DEBUG, EAL,
> >+ "Cannot set name for ctrl thread\n");
> >+ }
> >+
> >+ /* Wait for the control thread to initialize successfully */
> >+ while ((ctrl_thread_status =
> >+ __atomic_load_n(¶ms->ctrl_thread_status,
> >+ __ATOMIC_ACQUIRE)) == CTRL_THREAD_LAUNCHING) {
> >+ /* Yield the CPU. Using sched_yield call requires maintaining
> >+ * another implementation for Windows as sched_yield is not
> >+ * supported on Windows.
> >+ */
>
> sched_yield() also doesn't necessarily yield the CPU.
copied from original code and understood, but are you requesting a
change here or just a comment correction? can you offer wording you
would find suitable?
>
> >+ rte_delay_us_sleep(1);
> >+ }
> >+
> >+ /* Check if the control thread encountered an error */
> >+ if (ctrl_thread_status == CTRL_THREAD_ERROR) {
> >+ /* ctrl thread is exiting */
> >+ rte_thread_join(*thread, NULL);
> >+ }
> >+
> >+ ret = params->ret;
> >+ free(params);
> >+
> >+ return ret;
> >+}
> >+
> >+int
> > rte_thread_register(void)
> > {
> > unsigned int lcore_id;
> >diff --git a/lib/eal/include/rte_thread.h b/lib/eal/include/rte_thread.h
> >index b9edf70..ae7afbe 100644
> >--- a/lib/eal/include/rte_thread.h
> >+++ b/lib/eal/include/rte_thread.h
> >@@ -95,6 +95,35 @@ int rte_thread_create(rte_thread_t *thread_id,
> > rte_thread_func thread_func, void *arg);
> > /**
> >+ * Create a control thread.
> >+ *
> >+ * Creates a control thread with the given name and attributes. The
> >+ * affinity of the new thread is based on the CPU affinity retrieved
> >+ * at the time rte_eal_init() was called, the dataplane and service
> >+ * lcores are then excluded. If setting the name of the thread fails,
>
> "the EAL threads are then excluded"
i'll modify in v3.
>
> >+ * the error is ignored and a debug message is logged.
> >+ *
> >+ * @param thread
> >+ * Filled with the thread id of the new created thread.
> >+ * @param name
> >+ * The name of the control thread (max 16 characters including '\0').
>
> Is there a constant for this limit?
i have a series introducing rte_lcore_{set,get}_name api that introduces
a constant (probably i'll post it today). as of this series there is no
constant.
>
> >+ * @param thread_attr
> >+ * Attributes for the new thread.
> >+ * @param thread_func
> >+ * Function to be executed by the new thread.
> >+ * @param arg
> >+ * Argument passed to start_routine.
> >+ * @return
> >+ * On success, returns 0; on error, it returns a negative value
> >+ * corresponding to the error number.
>
> List the possible error codes.
i would like to see the range of codes be part of the api & abi i've
received resistance to the idea. for now i'll nack this comment which
leaves it consistent with other apis documentation.
>
> >+ */
> >+__rte_experimental
> >+int
> >+rte_control_thread_create(rte_thread_t *thread, const char *name,
> >+ const rte_thread_attr_t *thread_attr,
> >+ rte_thread_func thread_func, void *arg);
> >+
> >+/**
> > * @warning
> > * @b EXPERIMENTAL: this API may change without prior notice.
> > *
> >diff --git a/lib/eal/version.map b/lib/eal/version.map
> >index 7ad12a7..8f9eeb9 100644
> >--- a/lib/eal/version.map
> >+++ b/lib/eal/version.map
> >@@ -440,6 +440,9 @@ EXPERIMENTAL {
> > rte_thread_detach;
> > rte_thread_equal;
> > rte_thread_join;
> >+
> >+ # added in 23.03
> >+ rte_control_thread_create;
> > };
> > INTERNAL {
^ permalink raw reply [relevance 3%]
* Re: [EXT] Re: [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
@ 2022-12-07 18:00 5% ` Patrick Robb
2022-12-08 13:22 3% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Patrick Robb @ 2022-12-07 18:00 UTC (permalink / raw)
To: Ferruh Yigit
Cc: David Marchand, Thomas Monjalon, Akhil Goyal, ci,
Andrew Rybchenko, Ajit Khaparde, Qi Zhang,
Jerin Jacob Kollanukkaran, Raslan Darawsheh, Maxime Coquelin,
Xia, Chenbo, Luca Boccassi, Kevin Traynor, Christian Ehrhardt,
Xueming(Steven) Li, dev, stable, Bruce Richardson,
Michael Santana, Abdullah Ömer Yamaç,
Aaron Conole
[-- Attachment #1: Type: text/plain, Size: 2456 bytes --]
Hello,
Community Lab team members are wondering whether it is possible to bump
v22.11 to include at least this patch. We have an existing codebase which
relies on a vXX.XX scheme for producing ABI references. We parse that out
at different places in our code, so fixing this to handle vXX.XX.X will
require some changes on our end. We can do that, but it puts the timeline
on turning on ABI testing at the community lab back some. A v22.11 tagged
release with this patch would allow for us to turn on ABI testing
immediately. There was also a suggestion that having the "base" tag (like
the simple v22.11) point to the latest revision is a more standard version
naming approach and may be more intuitive than what is being used currently.
If that is not possible, we will update our code to be able to refer to a
vXX.XX.X tag for producing the ABI reference. If we adopt this approach, we
would like to request that with future releases, a "vXX.XX.0" tag could
always be made available for us to produce ABI references from. That way,
we can prepare for turning on ABI testing knowing beforehand the tag name
we will be using.
On Tue, Dec 6, 2022 at 7:25 AM Ferruh Yigit <ferruh.yigit@amd.com> wrote:
> On 12/6/2022 10:18 AM, David Marchand wrote:
> > On Tue, Dec 6, 2022 at 11:13 AM Ferruh Yigit <ferruh.yigit@amd.com>
> wrote:
> >> On 12/5/2022 3:37 PM, Thomas Monjalon wrote:
> >>> 05/12/2022 14:47, Akhil Goyal:
> >>>> But adding a tag on same repo is more convenient from developer point
> of view.
> >>>> However, it is my personal view, others may differ.
> >>>
> >>> From developer point of view, you should use
> devtools/test-meson-builds.sh
> >>> which does the "git clone" for you.
> >>>
> >>> This is what I have in ~/.config/dpdk/devel.config
> >>> export DPDK_ABI_REF_DIR=$root/dpdk-build/abiref
> >>> export DPDK_ABI_REF_VERSION=v22.11.1
> >>>
> >>
> >> Does it help to update 'test-meson-builds.sh' to use an environment
> >> variable to select which repo to clone?
> >> If so, I can send a patch for it.
> >
> > I was wondering too...
> > I would expect most maintainers have the stable repo in their config
> > but it would not hurt to handle the case when they don't for others.
> >
> > +1
> >
> >
>
> Sent following if it helps:
> https://patches.dpdk.org/project/dpdk/list/?series=26015
>
--
Patrick Robb
Technical Service Manager
UNH InterOperability Laboratory
21 Madbury Rd, Suite 100, Durham, NH 03824
www.iol.unh.edu
[-- Attachment #2: Type: text/html, Size: 5075 bytes --]
^ permalink raw reply [relevance 5%]
* Re: [EXT] Re: [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
2022-12-07 18:00 5% ` Patrick Robb
@ 2022-12-08 13:22 3% ` Thomas Monjalon
2022-12-08 16:06 0% ` Patrick Robb
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-12-08 13:22 UTC (permalink / raw)
To: Patrick Robb
Cc: Ferruh Yigit, David Marchand, Akhil Goyal, ci, Andrew Rybchenko,
Ajit Khaparde, Qi Zhang, Jerin Jacob Kollanukkaran,
Raslan Darawsheh, Maxime Coquelin, Xia, Chenbo, Luca Boccassi,
Kevin Traynor, Christian Ehrhardt, Xueming(Steven) Li, dev,
stable, Bruce Richardson, Michael Santana,
Abdullah Ömer Yamaç,
Aaron Conole
I'm sorry Patrick that it gives you more work.
Your proposals below don't look possible because a tag is something fixed forever.
We had an ABI issue in the initial tag so we cannot use the tag v22.11 as planned.
I don't see how we can better plan except having more tests on release candidates.
07/12/2022 19:00, Patrick Robb:
> Hello,
>
> Community Lab team members are wondering whether it is possible to bump
> v22.11 to include at least this patch. We have an existing codebase which
> relies on a vXX.XX scheme for producing ABI references. We parse that out
> at different places in our code, so fixing this to handle vXX.XX.X will
> require some changes on our end. We can do that, but it puts the timeline
> on turning on ABI testing at the community lab back some. A v22.11 tagged
> release with this patch would allow for us to turn on ABI testing
> immediately. There was also a suggestion that having the "base" tag (like
> the simple v22.11) point to the latest revision is a more standard version
> naming approach and may be more intuitive than what is being used currently.
>
> If that is not possible, we will update our code to be able to refer to a
> vXX.XX.X tag for producing the ABI reference. If we adopt this approach, we
> would like to request that with future releases, a "vXX.XX.0" tag could
> always be made available for us to produce ABI references from. That way,
> we can prepare for turning on ABI testing knowing beforehand the tag name
> we will be using.
>
> On Tue, Dec 6, 2022 at 7:25 AM Ferruh Yigit <ferruh.yigit@amd.com> wrote:
>
> > On 12/6/2022 10:18 AM, David Marchand wrote:
> > > On Tue, Dec 6, 2022 at 11:13 AM Ferruh Yigit <ferruh.yigit@amd.com>
> > wrote:
> > >> On 12/5/2022 3:37 PM, Thomas Monjalon wrote:
> > >>> 05/12/2022 14:47, Akhil Goyal:
> > >>>> But adding a tag on same repo is more convenient from developer point
> > of view.
> > >>>> However, it is my personal view, others may differ.
> > >>>
> > >>> From developer point of view, you should use
> > devtools/test-meson-builds.sh
> > >>> which does the "git clone" for you.
> > >>>
> > >>> This is what I have in ~/.config/dpdk/devel.config
> > >>> export DPDK_ABI_REF_DIR=$root/dpdk-build/abiref
> > >>> export DPDK_ABI_REF_VERSION=v22.11.1
> > >>>
> > >>
> > >> Does it help to update 'test-meson-builds.sh' to use an environment
> > >> variable to select which repo to clone?
> > >> If so, I can send a patch for it.
> > >
> > > I was wondering too...
> > > I would expect most maintainers have the stable repo in their config
> > > but it would not hurt to handle the case when they don't for others.
> > >
> > > +1
> >
> > Sent following if it helps:
> > https://patches.dpdk.org/project/dpdk/list/?series=26015
^ permalink raw reply [relevance 3%]
* Re: [EXT] Re: [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
2022-12-08 13:22 3% ` Thomas Monjalon
@ 2022-12-08 16:06 0% ` Patrick Robb
0 siblings, 0 replies; 200+ results
From: Patrick Robb @ 2022-12-08 16:06 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Ferruh Yigit, David Marchand, Akhil Goyal, ci, Andrew Rybchenko,
Ajit Khaparde, Qi Zhang, Jerin Jacob Kollanukkaran,
Raslan Darawsheh, Maxime Coquelin, Xia, Chenbo, Luca Boccassi,
Kevin Traynor, Christian Ehrhardt, Xueming(Steven) Li, dev,
stable, Bruce Richardson, Michael Santana,
Abdullah Ömer Yamaç,
Aaron Conole
[-- Attachment #1: Type: text/plain, Size: 3201 bytes --]
Thomas - thanks for the response. We will proceed with making the necessary
changes for using v22.11.1.
On Thu, Dec 8, 2022 at 8:22 AM Thomas Monjalon <thomas@monjalon.net> wrote:
> I'm sorry Patrick that it gives you more work.
> Your proposals below don't look possible because a tag is something fixed
> forever.
> We had an ABI issue in the initial tag so we cannot use the tag v22.11 as
> planned.
> I don't see how we can better plan except having more tests on release
> candidates.
>
>
> 07/12/2022 19:00, Patrick Robb:
> > Hello,
> >
> > Community Lab team members are wondering whether it is possible to bump
> > v22.11 to include at least this patch. We have an existing codebase which
> > relies on a vXX.XX scheme for producing ABI references. We parse that out
> > at different places in our code, so fixing this to handle vXX.XX.X will
> > require some changes on our end. We can do that, but it puts the timeline
> > on turning on ABI testing at the community lab back some. A v22.11 tagged
> > release with this patch would allow for us to turn on ABI testing
> > immediately. There was also a suggestion that having the "base" tag (like
> > the simple v22.11) point to the latest revision is a more standard
> version
> > naming approach and may be more intuitive than what is being used
> currently.
> >
> > If that is not possible, we will update our code to be able to refer to a
> > vXX.XX.X tag for producing the ABI reference. If we adopt this approach,
> we
> > would like to request that with future releases, a "vXX.XX.0" tag could
> > always be made available for us to produce ABI references from. That way,
> > we can prepare for turning on ABI testing knowing beforehand the tag name
> > we will be using.
> >
> > On Tue, Dec 6, 2022 at 7:25 AM Ferruh Yigit <ferruh.yigit@amd.com>
> wrote:
> >
> > > On 12/6/2022 10:18 AM, David Marchand wrote:
> > > > On Tue, Dec 6, 2022 at 11:13 AM Ferruh Yigit <ferruh.yigit@amd.com>
> > > wrote:
> > > >> On 12/5/2022 3:37 PM, Thomas Monjalon wrote:
> > > >>> 05/12/2022 14:47, Akhil Goyal:
> > > >>>> But adding a tag on same repo is more convenient from developer
> point
> > > of view.
> > > >>>> However, it is my personal view, others may differ.
> > > >>>
> > > >>> From developer point of view, you should use
> > > devtools/test-meson-builds.sh
> > > >>> which does the "git clone" for you.
> > > >>>
> > > >>> This is what I have in ~/.config/dpdk/devel.config
> > > >>> export DPDK_ABI_REF_DIR=$root/dpdk-build/abiref
> > > >>> export DPDK_ABI_REF_VERSION=v22.11.1
> > > >>>
> > > >>
> > > >> Does it help to update 'test-meson-builds.sh' to use an environment
> > > >> variable to select which repo to clone?
> > > >> If so, I can send a patch for it.
> > > >
> > > > I was wondering too...
> > > > I would expect most maintainers have the stable repo in their config
> > > > but it would not hurt to handle the case when they don't for others.
> > > >
> > > > +1
> > >
> > > Sent following if it helps:
> > > https://patches.dpdk.org/project/dpdk/list/?series=26015
>
>
>
>
>
>
--
Patrick Robb
Technical Service Manager
UNH InterOperability Laboratory
21 Madbury Rd, Suite 100, Durham, NH 03824
www.iol.unh.edu
[-- Attachment #2: Type: text/html, Size: 6221 bytes --]
^ permalink raw reply [relevance 0%]
* RE: [EXT] [PATCH 2/2] devtools: configure source repo to use as ABI reference
2022-12-06 12:23 17% ` [PATCH 2/2] devtools: configure source repo to use as ABI reference Ferruh Yigit
@ 2022-12-08 18:14 7% ` Akhil Goyal
2022-12-08 19:43 4% ` Thomas Monjalon
2022-12-09 8:22 8% ` David Marchand
1 sibling, 1 reply; 200+ results
From: Akhil Goyal @ 2022-12-08 18:14 UTC (permalink / raw)
To: Ferruh Yigit, Thomas Monjalon, Bruce Richardson; +Cc: David Marchand, dev
> By default 'test-meson-builds.sh' script clones the repository which the
> script is in, and selects a configured branch ('DPDK_ABI_REF_VERSION')
> as a reference for ABI check.
>
> This patch enables selecting different repository to close for reference
> using 'DPDK_ABI_REF_SRC' environment variable.
>
> It is possible to put these variables to 'devel.config' config file, or
> provide via command line, like:
> `
> DPDK_ABI_REF_SRC=~/dpdk-stable/ \
> DPDK_ABI_REF_VERSION=v22.11.1 \
> DPDK_ABI_REF_DIR=/tmp/dpdk-abiref \
> ./devtools/test-meson-builds.sh
> `
>
> When 'DPDK_ABI_REF_SRC' is not defined, script behaves as it did
> previously.
>
> Other alternative to using 'DPDK_ABI_REF_SRC' variable is adding that
> other repo as a new 'remote' to the exiting git repository.
>
> Signed-off-by: Ferruh Yigit <ferruh.yigit@amd.com>
> ---
Acked-by: Akhil Goyal <gakhil@marvell.com>
Worked for me, but I still needed to clone the dpdk-stable repo manually.
I was hoping, test-meson-build.sh would do that by itself.
Had it been a tag in same repo, it would have been straight forward as before.
I would still suggest to add a tag v22.11.1 in main branch and all can use that instead of v22.11.
The fix that we are talking about is a mandatory one for each one to use for ABI checks,
dpdk-stable patches are not mandatory for the users.
-Akhil
^ permalink raw reply [relevance 7%]
* Re: [EXT] [PATCH 2/2] devtools: configure source repo to use as ABI reference
2022-12-08 18:14 7% ` [EXT] " Akhil Goyal
@ 2022-12-08 19:43 4% ` Thomas Monjalon
2022-12-09 4:16 4% ` Akhil Goyal
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-12-08 19:43 UTC (permalink / raw)
To: Ferruh Yigit, Bruce Richardson, Akhil Goyal; +Cc: David Marchand, dev
08/12/2022 19:14, Akhil Goyal:
> > By default 'test-meson-builds.sh' script clones the repository which the
> > script is in, and selects a configured branch ('DPDK_ABI_REF_VERSION')
> > as a reference for ABI check.
> >
> > This patch enables selecting different repository to close for reference
> > using 'DPDK_ABI_REF_SRC' environment variable.
> >
> > It is possible to put these variables to 'devel.config' config file, or
> > provide via command line, like:
> > `
> > DPDK_ABI_REF_SRC=~/dpdk-stable/ \
> > DPDK_ABI_REF_VERSION=v22.11.1 \
> > DPDK_ABI_REF_DIR=/tmp/dpdk-abiref \
> > ./devtools/test-meson-builds.sh
> > `
> >
> > When 'DPDK_ABI_REF_SRC' is not defined, script behaves as it did
> > previously.
> >
> > Other alternative to using 'DPDK_ABI_REF_SRC' variable is adding that
> > other repo as a new 'remote' to the exiting git repository.
> >
> > Signed-off-by: Ferruh Yigit <ferruh.yigit@amd.com>
> > ---
>
> Acked-by: Akhil Goyal <gakhil@marvell.com>
>
> Worked for me, but I still needed to clone the dpdk-stable repo manually.
> I was hoping, test-meson-build.sh would do that by itself.
> Had it been a tag in same repo, it would have been straight forward as before.
> I would still suggest to add a tag v22.11.1 in main branch and all can use that instead of v22.11.
First, v22.11.1 exists already in dpdk-stable.
Second, vXX.YY.z tags are supposed to be only in dpdk-stable.
> The fix that we are talking about is a mandatory one for each one to use for ABI checks,
> dpdk-stable patches are not mandatory for the users.
You could have dpdk-stable as a remote in your main DPDK directory.
If you don't want to do that, you could refer to the commit SHA1 of the fix I think.
^ permalink raw reply [relevance 4%]
* Re: [PATCH v2 1/3] eal: add rte control thread create API
2022-12-07 16:38 3% ` Tyler Retzlaff
@ 2022-12-08 21:59 0% ` Mattias Rönnblom
0 siblings, 0 replies; 200+ results
From: Mattias Rönnblom @ 2022-12-08 21:59 UTC (permalink / raw)
To: Tyler Retzlaff; +Cc: dev, thomas, david.marchand, stephen, olivier.matz, mb
On 2022-12-07 17:38, Tyler Retzlaff wrote:
> On Wed, Dec 07, 2022 at 10:13:39AM +0100, Mattias Rönnblom wrote:
>> On 2022-12-06 18:28, Tyler Retzlaff wrote:
>>> Add rte_control_thread_create API as a replacement for
>>> rte_ctrl_thread_create to allow deprecation of the use of platform
>>> specific types in DPDK public API.
>>>
>>> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
>>> ---
>>> lib/eal/common/eal_common_thread.c | 93 ++++++++++++++++++++++++++++++++++----
>>> lib/eal/include/rte_thread.h | 29 ++++++++++++
>>> lib/eal/version.map | 3 ++
>>> 3 files changed, 117 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/lib/eal/common/eal_common_thread.c b/lib/eal/common/eal_common_thread.c
>>> index c5d8b43..7950b50 100644
>>> --- a/lib/eal/common/eal_common_thread.c
>>> +++ b/lib/eal/common/eal_common_thread.c
>>> @@ -234,7 +234,10 @@ enum __rte_ctrl_thread_status {
>>> };
>>> struct rte_thread_ctrl_params {
>>> - void *(*start_routine)(void *);
>>> + union {
>>> + void *(*start_routine)(void *);
>>> + rte_thread_func thread_func;
>>
>> To be consistent with function naming scheme, where "ctrl" is the
>> old API, and "control" the new, you could call the start functions
>> something with "ctrl" and "control" as well.
>
> i'll make this change in v3.
>
>>
>> Maybe it's worth mentioning that fact somewhere in the beginning of
>> the file, as a comment (i.e., that "ctrl" denotes the old API).
>
> i'll make this change in v3.
>
>>
>>> + } u;
>>> void *arg;
>>> int ret;
>>
>> Why is 'ret' needed? (This question is unrelated to your patch.)
>
> i'm not the original author so difficult to answer authoritatively. but
> if i have to speculate i'd say it might be to work around the windows
> pthread_join stub being implemented as a noop. specifically it didn't
> communicate the return value from the start_routine.
>
> the recently added rte_thread_join addresses this (which
> rte_control_thread_create uses) and could remove ret parameter and to
> avoid touching the new function implementation in the future it can not
> use ret now.
>
> i'll make this change in v3.
>
> for the original function i will leave the code as is to minimize the
> diff. when rte_ctrl_thread_create is removed i'll make a note to
> eliminate the ret parameter as well.
>
I would focus on minimizing the complexity of the end result, rather
than the size of the patch.
>>
>>> /* Control thread status.
>>> @@ -243,14 +246,12 @@ struct rte_thread_ctrl_params {
>>> enum __rte_ctrl_thread_status ctrl_thread_status;
>>> };
>>> -static void *ctrl_thread_init(void *arg)
>>> +static int ctrl_thread_init(void *arg)
>>> {
>>> struct internal_config *internal_conf =
>>> eal_get_internal_configuration();
>>> rte_cpuset_t *cpuset = &internal_conf->ctrl_cpuset;
>>> struct rte_thread_ctrl_params *params = arg;
>>> - void *(*start_routine)(void *) = params->start_routine;
>>> - void *routine_arg = params->arg;
>>> __rte_thread_init(rte_lcore_id(), cpuset);
>>> params->ret = pthread_setaffinity_np(pthread_self(), sizeof(*cpuset),
>>> @@ -258,13 +259,35 @@ static void *ctrl_thread_init(void *arg)
>>> if (params->ret != 0) {
>>> __atomic_store_n(¶ms->ctrl_thread_status,
>>> CTRL_THREAD_ERROR, __ATOMIC_RELEASE);
>>> - return NULL;
>>> + return params->ret;
>>> }
>>> __atomic_store_n(¶ms->ctrl_thread_status,
>>> CTRL_THREAD_RUNNING, __ATOMIC_RELEASE);
>>> - return start_routine(routine_arg);
>>> + return 0;
>>> +}
>>> +
>>> +static void *ctrl_thread_start(void *arg)
>>> +{
>>> + struct rte_thread_ctrl_params *params = arg;
>>> + void *(*start_routine)(void *) = params->u.start_routine;
>>> +
>>> + if (ctrl_thread_init(arg) != 0)
>>> + return NULL;
>>> +
>>> + return start_routine(params->arg);
>>> +}
>>> +
>>> +static uint32_t control_thread_start(void *arg)
>>> +{
>>> + struct rte_thread_ctrl_params *params = arg;
>>> + rte_thread_func start_routine = params->u.thread_func;
>>> +
>>> + if (ctrl_thread_init(arg) != 0)
>>> + return params->ret;
>>> +
>>> + return start_routine(params->arg);
>>> }
>>> int
>>> @@ -280,12 +303,12 @@ static void *ctrl_thread_init(void *arg)
>>> if (!params)
>>> return -ENOMEM;
>>> - params->start_routine = start_routine;
>>> + params->u.start_routine = start_routine;
>>> params->arg = arg;
>>> params->ret = 0;
>>> params->ctrl_thread_status = CTRL_THREAD_LAUNCHING;
>>> - ret = pthread_create(thread, attr, ctrl_thread_init, (void *)params);
>>> + ret = pthread_create(thread, attr, ctrl_thread_start, (void *)params);
>>> if (ret != 0) {
>>> free(params);
>>> return -ret;
>>> @@ -322,6 +345,60 @@ static void *ctrl_thread_init(void *arg)
>>> }
>>> int
>>> +rte_control_thread_create(rte_thread_t *thread, const char *name,
>>> + const rte_thread_attr_t *attr,
>>> + rte_thread_func start_routine, void *arg)
>>> +{
>>> + struct rte_thread_ctrl_params *params;
>>> + enum __rte_ctrl_thread_status ctrl_thread_status;
>>> + int ret;
>>> +
>>> + params = malloc(sizeof(*params));
>>> + if (!params)
>>
>> params == NULL
>
> copied from original code, i'll fix the style in the new function to
> comply with the dpdk coding standard.
>
> i'll fix in v3.
>
>>
>>> + return -ENOMEM;
>>> +
>>> + params->u.thread_func = start_routine;
>>> + params->arg = arg;
>>> + params->ret = 0;
>>> + params->ctrl_thread_status = CTRL_THREAD_LAUNCHING;
>>> +
>>> + ret = rte_thread_create(thread, attr, control_thread_start, params);
>>> + if (ret != 0) {
>>> + free(params);
>>> + return -ret;
>>> + }
>>> +
>>> + if (name != NULL) {
>>> + ret = rte_thread_setname((pthread_t)thread->opaque_id, name);
>>> + if (ret < 0)
>>> + RTE_LOG(DEBUG, EAL,
>>> + "Cannot set name for ctrl thread\n");
>>> + }
>>> +
>>> + /* Wait for the control thread to initialize successfully */
>>> + while ((ctrl_thread_status =
>>> + __atomic_load_n(¶ms->ctrl_thread_status,
>>> + __ATOMIC_ACQUIRE)) == CTRL_THREAD_LAUNCHING) {
>>> + /* Yield the CPU. Using sched_yield call requires maintaining
>>> + * another implementation for Windows as sched_yield is not
>>> + * supported on Windows.
>>> + */
>>
>> sched_yield() also doesn't necessarily yield the CPU.
>
> copied from original code and understood, but are you requesting a
> change here or just a comment correction? can you offer wording you
> would find suitable?
>
I would just remove the comment.
"Yield the CPU. sched_yield() may seem like a natural choice here, but
does not guarantee that a context switch will actually occur, and also
does not exist on Windows."
>>
>>> + rte_delay_us_sleep(1);
>>> + }
>>> +
>>> + /* Check if the control thread encountered an error */
>>> + if (ctrl_thread_status == CTRL_THREAD_ERROR) {
>>> + /* ctrl thread is exiting */
>>> + rte_thread_join(*thread, NULL);
>>> + }
>>> +
>>> + ret = params->ret;
>>> + free(params);
>>> +
>>> + return ret;
>>> +}
>>> +
>>> +int
>>> rte_thread_register(void)
>>> {
>>> unsigned int lcore_id;
>>> diff --git a/lib/eal/include/rte_thread.h b/lib/eal/include/rte_thread.h
>>> index b9edf70..ae7afbe 100644
>>> --- a/lib/eal/include/rte_thread.h
>>> +++ b/lib/eal/include/rte_thread.h
>>> @@ -95,6 +95,35 @@ int rte_thread_create(rte_thread_t *thread_id,
>>> rte_thread_func thread_func, void *arg);
>>> /**
>>> + * Create a control thread.
>>> + *
>>> + * Creates a control thread with the given name and attributes. The
>>> + * affinity of the new thread is based on the CPU affinity retrieved
>>> + * at the time rte_eal_init() was called, the dataplane and service
>>> + * lcores are then excluded. If setting the name of the thread fails,
>>
>> "the EAL threads are then excluded"
>
> i'll modify in v3.
>
>>
>>> + * the error is ignored and a debug message is logged.
>>> + *
>>> + * @param thread
>>> + * Filled with the thread id of the new created thread.
>>> + * @param name
>>> + * The name of the control thread (max 16 characters including '\0').
>>
>> Is there a constant for this limit?
>
> i have a series introducing rte_lcore_{set,get}_name api that introduces
> a constant (probably i'll post it today). as of this series there is no
> constant.
>
>>
>>> + * @param thread_attr
>>> + * Attributes for the new thread.
>>> + * @param thread_func
>>> + * Function to be executed by the new thread.
>>> + * @param arg
>>> + * Argument passed to start_routine.
>>> + * @return
>>> + * On success, returns 0; on error, it returns a negative value
>>> + * corresponding to the error number.
>>
>> List the possible error codes.
>
> i would like to see the range of codes be part of the api & abi i've
> received resistance to the idea. for now i'll nack this comment which
> leaves it consistent with other apis documentation.
>>
>>> + */
>>> +__rte_experimental
>>> +int
>>> +rte_control_thread_create(rte_thread_t *thread, const char *name,
>>> + const rte_thread_attr_t *thread_attr,
>>> + rte_thread_func thread_func, void *arg);
>>> +
>>> +/**
>>> * @warning
>>> * @b EXPERIMENTAL: this API may change without prior notice.
>>> *
>>> diff --git a/lib/eal/version.map b/lib/eal/version.map
>>> index 7ad12a7..8f9eeb9 100644
>>> --- a/lib/eal/version.map
>>> +++ b/lib/eal/version.map
>>> @@ -440,6 +440,9 @@ EXPERIMENTAL {
>>> rte_thread_detach;
>>> rte_thread_equal;
>>> rte_thread_join;
>>> +
>>> + # added in 23.03
>>> + rte_control_thread_create;
>>> };
>>> INTERNAL {
^ permalink raw reply [relevance 0%]
* RE: [EXT] [PATCH 2/2] devtools: configure source repo to use as ABI reference
2022-12-08 19:43 4% ` Thomas Monjalon
@ 2022-12-09 4:16 4% ` Akhil Goyal
0 siblings, 0 replies; 200+ results
From: Akhil Goyal @ 2022-12-09 4:16 UTC (permalink / raw)
To: Thomas Monjalon, Ferruh Yigit, Bruce Richardson; +Cc: David Marchand, dev
> 08/12/2022 19:14, Akhil Goyal:
> > > By default 'test-meson-builds.sh' script clones the repository which the
> > > script is in, and selects a configured branch ('DPDK_ABI_REF_VERSION')
> > > as a reference for ABI check.
> > >
> > > This patch enables selecting different repository to close for reference
> > > using 'DPDK_ABI_REF_SRC' environment variable.
> > >
> > > It is possible to put these variables to 'devel.config' config file, or
> > > provide via command line, like:
> > > `
> > > DPDK_ABI_REF_SRC=~/dpdk-stable/ \
> > > DPDK_ABI_REF_VERSION=v22.11.1 \
> > > DPDK_ABI_REF_DIR=/tmp/dpdk-abiref \
> > > ./devtools/test-meson-builds.sh
> > > `
> > >
> > > When 'DPDK_ABI_REF_SRC' is not defined, script behaves as it did
> > > previously.
> > >
> > > Other alternative to using 'DPDK_ABI_REF_SRC' variable is adding that
> > > other repo as a new 'remote' to the exiting git repository.
> > >
> > > Signed-off-by: Ferruh Yigit <ferruh.yigit@amd.com>
> > > ---
> >
> > Acked-by: Akhil Goyal <gakhil@marvell.com>
> >
> > Worked for me, but I still needed to clone the dpdk-stable repo manually.
> > I was hoping, test-meson-build.sh would do that by itself.
> > Had it been a tag in same repo, it would have been straight forward as before.
> > I would still suggest to add a tag v22.11.1 in main branch and all can use that
> instead of v22.11.
>
> First, v22.11.1 exists already in dpdk-stable.
> Second, vXX.YY.z tags are supposed to be only in dpdk-stable.
May be some other tag name we can think. v22.11.hotfix or something better.
I was just asking to give a name to commit, and NOT updating the VERSION file.
>
> > The fix that we are talking about is a mandatory one for each one to use for
> ABI checks,
> > dpdk-stable patches are not mandatory for the users.
>
> You could have dpdk-stable as a remote in your main DPDK directory.
> If you don't want to do that, you could refer to the commit SHA1 of the fix I
> think.
>
Adding remote did not solve the issue as the commits are different(version commit).
I cloned stable repo separately and it worked for me.
Since you refer to use commit SHA, why not give it a name, remembering SHA is not easy.
-Akhil
^ permalink raw reply [relevance 4%]
* Re: [PATCH 2/2] devtools: configure source repo to use as ABI reference
2022-12-06 12:23 17% ` [PATCH 2/2] devtools: configure source repo to use as ABI reference Ferruh Yigit
2022-12-08 18:14 7% ` [EXT] " Akhil Goyal
@ 2022-12-09 8:22 8% ` David Marchand
2022-12-09 8:44 4% ` Ferruh Yigit
1 sibling, 1 reply; 200+ results
From: David Marchand @ 2022-12-09 8:22 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: Thomas Monjalon, Bruce Richardson, dev, Akhil Goyal
On Tue, Dec 6, 2022 at 1:24 PM Ferruh Yigit <ferruh.yigit@amd.com> wrote:
>
> By default 'test-meson-builds.sh' script clones the repository which the
> script is in, and selects a configured branch ('DPDK_ABI_REF_VERSION')
> as a reference for ABI check.
>
> This patch enables selecting different repository to close for reference
> using 'DPDK_ABI_REF_SRC' environment variable.
>
> It is possible to put these variables to 'devel.config' config file, or
> provide via command line, like:
> `
> DPDK_ABI_REF_SRC=~/dpdk-stable/ \
DPDK_ABI_REF_SRC could be passed as a remote repository.
This should remove the need for any "git remote" configuration.
$ DPDK_ABI_REF_SRC=https://dpdk.org/git/dpdk-stable
DPDK_ABI_REF_VERSION=v22.11.1 ./devtools/test-meson-builds.sh
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index 406bf4e184..48f4e52df3 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -18,8 +18,8 @@ srcdir=$(dirname $(readlink -f $0))/..
#
# - DPDK_MESON_OPTIONS
#
-# - DPDK_ABI_REF_SRC
# - DPDK_ABI_REF_DIR
+# - DPDK_ABI_REF_SRC
# - DPDK_ABI_REF_VERSION
#
# - DPDK_BUILD_TEST_EXAMPLES
@@ -186,10 +186,14 @@ build () # <directory> <target cc | cross file>
<ABI check> [meson options]
if [ -n "$DPDK_ABI_REF_VERSION" -a "$abicheck" = ABI ] ; then
abirefdir=${DPDK_ABI_REF_DIR:-reference}/$DPDK_ABI_REF_VERSION
if [ ! -d $abirefdir/$targetdir ]; then
- abirefsrc=${DPDK_ABI_REF_SRC:-$srcdir}
# clone current sources
if [ ! -d $abirefdir/src ]; then
- git clone --local --no-hardlinks \
+ abirefsrc=${DPDK_ABI_REF_SRC:-$srcdir}
+ abirefcloneopts=
+ if [ -d $abirefsrc ]; then
+ abirefcloneopts="--local --no-hardlinks"
+ fi
+ git clone $abirefcloneopts \
--single-branch \
-b $DPDK_ABI_REF_VERSION \
$abirefsrc $abirefdir/src
> DPDK_ABI_REF_VERSION=v22.11.1 \
> DPDK_ABI_REF_DIR=/tmp/dpdk-abiref \
> ./devtools/test-meson-builds.sh
> `
>
> When 'DPDK_ABI_REF_SRC' is not defined, script behaves as it did
> previously.
>
> Other alternative to using 'DPDK_ABI_REF_SRC' variable is adding that
> other repo as a new 'remote' to the exiting git repository.
--
David Marchand
^ permalink raw reply [relevance 8%]
* Re: [PATCH 2/2] devtools: configure source repo to use as ABI reference
2022-12-09 8:22 8% ` David Marchand
@ 2022-12-09 8:44 4% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2022-12-09 8:44 UTC (permalink / raw)
To: David Marchand; +Cc: Thomas Monjalon, Bruce Richardson, dev, Akhil Goyal
On 12/9/2022 8:22 AM, David Marchand wrote:
> On Tue, Dec 6, 2022 at 1:24 PM Ferruh Yigit <ferruh.yigit@amd.com> wrote:
>>
>> By default 'test-meson-builds.sh' script clones the repository which the
>> script is in, and selects a configured branch ('DPDK_ABI_REF_VERSION')
>> as a reference for ABI check.
>>
>> This patch enables selecting different repository to close for reference
>> using 'DPDK_ABI_REF_SRC' environment variable.
>>
>> It is possible to put these variables to 'devel.config' config file, or
>> provide via command line, like:
>> `
>> DPDK_ABI_REF_SRC=~/dpdk-stable/ \
>
> DPDK_ABI_REF_SRC could be passed as a remote repository.
> This should remove the need for any "git remote" configuration.
>
> $ DPDK_ABI_REF_SRC=https://dpdk.org/git/dpdk-stable
> DPDK_ABI_REF_VERSION=v22.11.1 ./devtools/test-meson-builds.sh
>
+1 to 'DPDK_ABI_REF_SRC' accept either folder or remote git repo.
Can you send a v2 with your sign off added, or do you want me send a v2?
>
> diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
> index 406bf4e184..48f4e52df3 100755
> --- a/devtools/test-meson-builds.sh
> +++ b/devtools/test-meson-builds.sh
> @@ -18,8 +18,8 @@ srcdir=$(dirname $(readlink -f $0))/..
> #
> # - DPDK_MESON_OPTIONS
> #
> -# - DPDK_ABI_REF_SRC
> # - DPDK_ABI_REF_DIR
> +# - DPDK_ABI_REF_SRC
> # - DPDK_ABI_REF_VERSION
> #
> # - DPDK_BUILD_TEST_EXAMPLES
> @@ -186,10 +186,14 @@ build () # <directory> <target cc | cross file>
> <ABI check> [meson options]
> if [ -n "$DPDK_ABI_REF_VERSION" -a "$abicheck" = ABI ] ; then
> abirefdir=${DPDK_ABI_REF_DIR:-reference}/$DPDK_ABI_REF_VERSION
> if [ ! -d $abirefdir/$targetdir ]; then
> - abirefsrc=${DPDK_ABI_REF_SRC:-$srcdir}
> # clone current sources
> if [ ! -d $abirefdir/src ]; then
> - git clone --local --no-hardlinks \
> + abirefsrc=${DPDK_ABI_REF_SRC:-$srcdir}
> + abirefcloneopts=
> + if [ -d $abirefsrc ]; then
> + abirefcloneopts="--local --no-hardlinks"
> + fi
> + git clone $abirefcloneopts \
> --single-branch \
> -b $DPDK_ABI_REF_VERSION \
> $abirefsrc $abirefdir/src
>
>
>> DPDK_ABI_REF_VERSION=v22.11.1 \
>> DPDK_ABI_REF_DIR=/tmp/dpdk-abiref \
>> ./devtools/test-meson-builds.sh
>> `
>>
>> When 'DPDK_ABI_REF_SRC' is not defined, script behaves as it did
>> previously.
>>
>> Other alternative to using 'DPDK_ABI_REF_SRC' variable is adding that
>> other repo as a new 'remote' to the exiting git repository.
>
>
>
^ permalink raw reply [relevance 4%]
* [PATCH v2 2/2] devtools: configure source repo to use as ABI reference
@ 2022-12-09 9:02 13% ` David Marchand
2022-12-21 15:02 4% ` David Marchand
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2022-12-09 9:02 UTC (permalink / raw)
To: dev; +Cc: thomas, bruce.richardson, gakhil, Ferruh Yigit
From: Ferruh Yigit <ferruh.yigit@amd.com>
By default 'test-meson-builds.sh' script clones the repository which the
script is in, and selects a configured branch ('DPDK_ABI_REF_VERSION')
as a reference for ABI check.
This patch enables selecting different repository to clone for reference
using 'DPDK_ABI_REF_SRC' environment variable.
'DPDK_ABI_REF_SRC' may refer to a directory containing a cloned git
repository, or a remote git repository.
It is possible to put these variables to 'devel.config' config file, or
provide via command line, like:
`
DPDK_ABI_REF_SRC=https://dpdk.org/git/dpdk-stable \
DPDK_ABI_REF_VERSION=v22.11.1 \
DPDK_ABI_REF_DIR=/tmp/dpdk-abiref \
./devtools/test-meson-builds.sh
`
When 'DPDK_ABI_REF_SRC' is not defined, script behaves as it did
previously.
Other alternative to using 'DPDK_ABI_REF_SRC' variable is adding that
other repo as a new 'remote' to the exiting git repository.
Signed-off-by: Ferruh Yigit <ferruh.yigit@amd.com>
Acked-by: Akhil Goyal <gakhil@marvell.com>
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
Changes since v1:
- expanded DPDK_ABI_REF_SRC usage to "non-local" sources,
---
devtools/test-meson-builds.sh | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index 02541c19aa..48f4e52df3 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -19,6 +19,7 @@ srcdir=$(dirname $(readlink -f $0))/..
# - DPDK_MESON_OPTIONS
#
# - DPDK_ABI_REF_DIR
+# - DPDK_ABI_REF_SRC
# - DPDK_ABI_REF_VERSION
#
# - DPDK_BUILD_TEST_EXAMPLES
@@ -187,10 +188,15 @@ build () # <directory> <target cc | cross file> <ABI check> [meson options]
if [ ! -d $abirefdir/$targetdir ]; then
# clone current sources
if [ ! -d $abirefdir/src ]; then
- git clone --local --no-hardlinks \
+ abirefsrc=${DPDK_ABI_REF_SRC:-$srcdir}
+ abirefcloneopts=
+ if [ -d $abirefsrc ]; then
+ abirefcloneopts="--local --no-hardlinks"
+ fi
+ git clone $abirefcloneopts \
--single-branch \
-b $DPDK_ABI_REF_VERSION \
- $srcdir $abirefdir/src
+ $abirefsrc $abirefdir/src
fi
rm -rf $abirefdir/build
--
2.38.1
^ permalink raw reply [relevance 13%]
* [PATCH V2 00/11] telemetry: add u32 value type and hex integer string API
@ 2022-12-09 11:04 3% ` Huisong Li
2022-12-09 18:24 0% ` Morten Brørup
2022-12-11 9:02 0% ` fengchengwen
2022-12-12 6:42 3% ` [PATCH V3 " Huisong Li
` (5 subsequent siblings)
6 siblings, 2 replies; 200+ results
From: Huisong Li @ 2022-12-09 11:04 UTC (permalink / raw)
To: dev
Cc: bruce.richardson, mb, ciara.power, liudongdong3, huangdaode,
fengchengwen, lihuisong
Some lib telemetry interfaces add the 'u32' and 'u64' data by the
rte_tel_data_add_dict/array_int API. This may cause data conversion
error or data truncation.
The 'u32' data can not be assigned to signed 32-bit integer. However,
assigning to u64 is very wasteful, after all, the buffer capacity of
each transfer is limited. So it is necessary for 'u32' data to add
usigned 32-bit integer type and a series of 'u32' operation APIs.
This patchset uses the new 'u32' API to resolve the problem of data
conversion error, and use the 'u64' API to add 'u64' data.
In addition, this patchset introduces two APIs to store u32 and u64
values as hexadecimal encoded strings in telemetry library.
---
-v2:
- fix ABI break warning.
- introduce two APIs to store u32 and u64 values as hexadecimal
encoded strings.
Huisong Li (11):
telemetry: move to header to controllable range
telemetry: add u32 value type
test: add test cases for adding u32 value API
ethdev: fix possible data truncation and conversion error
mempool: fix possible data truncation and conversion error
cryptodev: fix possible data conversion error
mem: possible data truncation and conversion error
telemetry: refactor mapping betwween value and array type
telemetry: support adding integer value as hexadecimal
test: add test cases for adding hex integer values API
ethdev: display capability values in hexadecimal format
app/test/test_telemetry_data.c | 249 ++++++++++++++++++++++++++++-
app/test/test_telemetry_json.c | 23 ++-
lib/cryptodev/rte_cryptodev.c | 2 +-
lib/eal/common/eal_common_memory.c | 14 +-
lib/ethdev/rte_ethdev.c | 13 +-
lib/mempool/rte_mempool.c | 24 +--
lib/telemetry/rte_telemetry.h | 112 ++++++++++++-
lib/telemetry/telemetry.c | 25 ++-
lib/telemetry/telemetry_data.c | 122 ++++++++++++--
lib/telemetry/telemetry_data.h | 2 +
lib/telemetry/telemetry_json.h | 29 ++++
lib/telemetry/version.map | 14 ++
12 files changed, 581 insertions(+), 48 deletions(-)
--
2.33.0
^ permalink raw reply [relevance 3%]
* Re: help with pthread_t deprecation / api changes
@ 2022-12-09 16:48 3% ` Stephen Hemminger
2022-12-09 20:06 0% ` Tyler Retzlaff
2022-12-09 21:14 0% ` Thomas Monjalon
0 siblings, 2 replies; 200+ results
From: Stephen Hemminger @ 2022-12-09 16:48 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Morten Brørup, Tyler Retzlaff, dev, david.marchand,
Bruce Richardson
On Fri, 09 Dec 2022 08:53:57 +0100
Thomas Monjalon <thomas@monjalon.net> wrote:
> > > If some execution environment doesn't support thread names, it could return a string that makes it possible for a human to identify the thread, e.g. the tread id. Again, this is assuming that it is only used for debugging, trace, and similar.
> >
> > i think this raises a good question. is the purpose of setting a thread name
> > meant to be something we can use from the application or is it something that
> > is for debugging diagnostics and may be a best effort?
>
> I think yes it is only for debugging.
> So best effort looks to be a good approach.
> I'm not sure you need to replace the functions.
> Can you just complete the implementations?
Surprisingly, thread names are not preserved in core dumps.
The core dump standard used by Linux does not put thread name in the image.
Since this is a ELF ABI unlikely to be ever be added.
^ permalink raw reply [relevance 3%]
* RE: [PATCH V2 00/11] telemetry: add u32 value type and hex integer string API
2022-12-09 11:04 3% ` [PATCH V2 00/11] telemetry: add u32 value type and hex integer string API Huisong Li
@ 2022-12-09 18:24 0% ` Morten Brørup
2022-12-12 6:23 0% ` lihuisong (C)
2022-12-11 9:02 0% ` fengchengwen
1 sibling, 1 reply; 200+ results
From: Morten Brørup @ 2022-12-09 18:24 UTC (permalink / raw)
To: Huisong Li, dev
Cc: bruce.richardson, ciara.power, liudongdong3, huangdaode, fengchengwen
> From: Huisong Li [mailto:lihuisong@huawei.com]
> Sent: Friday, 9 December 2022 12.05
>
> Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> rte_tel_data_add_dict/array_int API. This may cause data conversion
> error or data truncation.
>
> The 'u32' data can not be assigned to signed 32-bit integer. However,
> assigning to u64 is very wasteful, after all, the buffer capacity of
> each transfer is limited. So it is necessary for 'u32' data to add
> usigned 32-bit integer type and a series of 'u32' operation APIs.
>
> This patchset uses the new 'u32' API to resolve the problem of data
> conversion error, and use the 'u64' API to add 'u64' data.
>
> In addition, this patchset introduces two APIs to store u32 and u64
> values as hexadecimal encoded strings in telemetry library.
>
> ---
> -v2:
> - fix ABI break warning.
> - introduce two APIs to store u32 and u64 values as hexadecimal
> encoded strings.
Looks good.
Personally, I would prefer rte_tel_data_add_{dict|array}_u32_hex() over _hex_u32_str(), and similar for u64; but it is a matter of taste, so feel free to change or keep your own suggested names.
In the eal_common_memory.c patch, in rte_tel_data_add_dict_u32(d, "Head id", heap_id);, consider fixing the old typo too, it should be "Heap_id", not "Head id". On the other hand, it will change the JSON output, so perhaps it will be considered an API breakage?
Series-acked-by: Morten Brørup <mb@smartsharesystems.com>
^ permalink raw reply [relevance 0%]
* Re: help with pthread_t deprecation / api changes
2022-12-09 16:48 3% ` Stephen Hemminger
@ 2022-12-09 20:06 0% ` Tyler Retzlaff
2022-12-09 21:14 0% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Tyler Retzlaff @ 2022-12-09 20:06 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Thomas Monjalon, Morten Brørup, dev, david.marchand,
Bruce Richardson
hey,
combining the reply to both Thomas and Stephen since i think this series
http://mails.dpdk.org/archives/dev/2022-December/257238.html addresses
both feedback comments.
On Fri, Dec 09, 2022 at 08:48:14AM -0800, Stephen Hemminger wrote:
> On Fri, 09 Dec 2022 08:53:57 +0100
> Thomas Monjalon <thomas@monjalon.net> wrote:
>
> > > > If some execution environment doesn't support thread names, it could return a string that makes it possible for a human to identify the thread, e.g. the tread id. Again, this is assuming that it is only used for debugging, trace, and similar.
> > >
> > > i think this raises a good question. is the purpose of setting a thread name
> > > meant to be something we can use from the application or is it something that
> > > is for debugging diagnostics and may be a best effort?
> >
> Thomas Monjalon <thomas@monjalon.net> wrote:
> I think yes it is only for debugging.
> So best effort looks to be a good approach.
> I'm not sure you need to replace the functions.
> Can you just complete the implementations?
the patch series put forward allows a set / get name per-lcore, where
you get implicit (but not exposed via the eal api) call to underlying
platform thread setname.
the intent here is if you have it and it works you'll get it and if you
don't you won't but the eal doesn't force the application to deal with it
conditionally on a per-platform basis.
> Stephen wrote:
>
> Surprisingly, thread names are not preserved in core dumps.
> The core dump standard used by Linux does not put thread name in the image.
> Since this is a ELF ABI unlikely to be ever be added.
the patchset addresses this by actually keeping a copy of the name set,
so it will be available in the coredump.
the intent here is to make it available for use by the application i.e.
get that works on all platforms, but also you can actually pull the name
out under a debugger or a dump and does not require any conditional
dancing per-platform by the application.
as an aside there are 2 series up for review that finally clean the
remaining platform-specific thread references from the eal public
interface.
http://mails.dpdk.org/archives/dev/2022-December/257238.html
http://mails.dpdk.org/archives/dev/2022-December/257413.html
the set get name api patch series i'm preparing a v2 for due to some
minor things caught by the ci and an issue with mingw but otherwise if
we can get these in it will unblock a lot of the internal detail
cleanups we've been trying to accomplish.
really appreciate it guys.
thanks.
^ permalink raw reply [relevance 0%]
* Re: help with pthread_t deprecation / api changes
2022-12-09 16:48 3% ` Stephen Hemminger
2022-12-09 20:06 0% ` Tyler Retzlaff
@ 2022-12-09 21:14 0% ` Thomas Monjalon
2022-12-09 22:38 0% ` Stephen Hemminger
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-12-09 21:14 UTC (permalink / raw)
To: Stephen Hemminger, Tyler Retzlaff
Cc: Morten Brørup, dev, david.marchand, Bruce Richardson
09/12/2022 17:48, Stephen Hemminger:
> On Fri, 09 Dec 2022 08:53:57 +0100
> Thomas Monjalon <thomas@monjalon.net> wrote:
>
> > > > If some execution environment doesn't support thread names, it could return a string that makes it possible for a human to identify the thread, e.g. the tread id. Again, this is assuming that it is only used for debugging, trace, and similar.
> > >
> > > i think this raises a good question. is the purpose of setting a thread name
> > > meant to be something we can use from the application or is it something that
> > > is for debugging diagnostics and may be a best effort?
> >
> > I think yes it is only for debugging.
> > So best effort looks to be a good approach.
> > I'm not sure you need to replace the functions.
> > Can you just complete the implementations?
>
>
> Surprisingly, thread names are not preserved in core dumps.
> The core dump standard used by Linux does not put thread name in the image.
> Since this is a ELF ABI unlikely to be ever be added.
What is missing exactly to have thread name in the core dump?
^ permalink raw reply [relevance 0%]
* Re: help with pthread_t deprecation / api changes
2022-12-09 21:14 0% ` Thomas Monjalon
@ 2022-12-09 22:38 0% ` Stephen Hemminger
2022-12-09 23:55 0% ` Tyler Retzlaff
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2022-12-09 22:38 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Tyler Retzlaff, Morten Brørup, dev, david.marchand,
Bruce Richardson
On Fri, 09 Dec 2022 22:14:33 +0100
Thomas Monjalon <thomas@monjalon.net> wrote:
> 09/12/2022 17:48, Stephen Hemminger:
> > On Fri, 09 Dec 2022 08:53:57 +0100
> > Thomas Monjalon <thomas@monjalon.net> wrote:
> >
> > > > > If some execution environment doesn't support thread names, it could return a string that makes it possible for a human to identify the thread, e.g. the tread id. Again, this is assuming that it is only used for debugging, trace, and similar.
> > > >
> > > > i think this raises a good question. is the purpose of setting a thread name
> > > > meant to be something we can use from the application or is it something that
> > > > is for debugging diagnostics and may be a best effort?
> > >
> > > I think yes it is only for debugging.
> > > So best effort looks to be a good approach.
> > > I'm not sure you need to replace the functions.
> > > Can you just complete the implementations?
> >
> >
> > Surprisingly, thread names are not preserved in core dumps.
> > The core dump standard used by Linux does not put thread name in the image.
> > Since this is a ELF ABI unlikely to be ever be added.
>
> What is missing exactly to have thread name in the core dump?
>
>
Linux core dump file format is ELF.
The thread info is storewd in the file notes as NT_PRPSINFO
which contains info but not the thread name. In the kernel
thread name is under comm.
typedef struct prpsinfo { /* Information about process */
unsigned char pr_state; /* Numeric process state */
char pr_sname; /* Char for pr_state */
unsigned char pr_zomb; /* Zombie */
signed char pr_nice; /* Nice val */
unsigned long pr_flag; /* Flags */
uint32_t pr_uid; /* User ID */
uint32_t pr_gid; /* Group ID */
pid_t pr_pid; /* Process ID */
pid_t pr_ppid; /* Parent's process ID */
pid_t pr_pgrp; /* Group ID */
pid_t pr_sid; /* Session ID */
char pr_fname[16]; /* Filename of executable */
char pr_psargs[80]; /* Initial part of arg list */
} prpsinfo;
Stack Overflow leads to this pages
https://www.gabriel.urdhr.fr/2015/05/29/core-file/
https://uhlo.blogspot.com/2012/05/brief-look-into-core-dumps.html
Only know this because of investigating how to get thread names
to show up in Azure with Watson.
^ permalink raw reply [relevance 0%]
* Re: help with pthread_t deprecation / api changes
2022-12-09 22:38 0% ` Stephen Hemminger
@ 2022-12-09 23:55 0% ` Tyler Retzlaff
0 siblings, 0 replies; 200+ results
From: Tyler Retzlaff @ 2022-12-09 23:55 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Thomas Monjalon, Morten Brørup, dev, david.marchand,
Bruce Richardson
On Fri, Dec 09, 2022 at 02:38:49PM -0800, Stephen Hemminger wrote:
> On Fri, 09 Dec 2022 22:14:33 +0100
> Thomas Monjalon <thomas@monjalon.net> wrote:
>
> > 09/12/2022 17:48, Stephen Hemminger:
> > > On Fri, 09 Dec 2022 08:53:57 +0100
> > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > >
> > > > > > If some execution environment doesn't support thread names, it could return a string that makes it possible for a human to identify the thread, e.g. the tread id. Again, this is assuming that it is only used for debugging, trace, and similar.
> > > > >
> > > > > i think this raises a good question. is the purpose of setting a thread name
> > > > > meant to be something we can use from the application or is it something that
> > > > > is for debugging diagnostics and may be a best effort?
> > > >
> > > > I think yes it is only for debugging.
> > > > So best effort looks to be a good approach.
> > > > I'm not sure you need to replace the functions.
> > > > Can you just complete the implementations?
> > >
> > >
> > > Surprisingly, thread names are not preserved in core dumps.
> > > The core dump standard used by Linux does not put thread name in the image.
> > > Since this is a ELF ABI unlikely to be ever be added.
> >
> > What is missing exactly to have thread name in the core dump?
> >
> >
>
> Linux core dump file format is ELF.
> The thread info is storewd in the file notes as NT_PRPSINFO
> which contains info but not the thread name. In the kernel
> thread name is under comm.
>
>
> typedef struct prpsinfo { /* Information about process */
> unsigned char pr_state; /* Numeric process state */
> char pr_sname; /* Char for pr_state */
> unsigned char pr_zomb; /* Zombie */
> signed char pr_nice; /* Nice val */
> unsigned long pr_flag; /* Flags */
>
> uint32_t pr_uid; /* User ID */
> uint32_t pr_gid; /* Group ID */
>
> pid_t pr_pid; /* Process ID */
> pid_t pr_ppid; /* Parent's process ID */
> pid_t pr_pgrp; /* Group ID */
> pid_t pr_sid; /* Session ID */
> char pr_fname[16]; /* Filename of executable */
> char pr_psargs[80]; /* Initial part of arg list */
> } prpsinfo;
>
>
> Stack Overflow leads to this pages
> https://www.gabriel.urdhr.fr/2015/05/29/core-file/
> https://uhlo.blogspot.com/2012/05/brief-look-into-core-dumps.html
>
> Only know this because of investigating how to get thread names
> to show up in Azure with Watson.
from a dpdk specific perspective if we want to consistently have a
thread name in a dump / coredump then we have a better chance of
success just storing it in our applications namespace ourselves.
relying on platform-specific facilities to preserve it seems hit and
miss at best.
^ permalink raw reply [relevance 0%]
* Re: [PATCH V2 00/11] telemetry: add u32 value type and hex integer string API
2022-12-09 11:04 3% ` [PATCH V2 00/11] telemetry: add u32 value type and hex integer string API Huisong Li
2022-12-09 18:24 0% ` Morten Brørup
@ 2022-12-11 9:02 0% ` fengchengwen
1 sibling, 0 replies; 200+ results
From: fengchengwen @ 2022-12-11 9:02 UTC (permalink / raw)
To: Huisong Li, dev
Cc: bruce.richardson, mb, ciara.power, liudongdong3, huangdaode
LGTM
Series-acked-by: Chengwen Feng <fengchengwen@huawei.com>
On 2022/12/9 19:04, Huisong Li wrote:
> Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> rte_tel_data_add_dict/array_int API. This may cause data conversion
> error or data truncation.
>
> The 'u32' data can not be assigned to signed 32-bit integer. However,
> assigning to u64 is very wasteful, after all, the buffer capacity of
> each transfer is limited. So it is necessary for 'u32' data to add
> usigned 32-bit integer type and a series of 'u32' operation APIs.
>
> This patchset uses the new 'u32' API to resolve the problem of data
> conversion error, and use the 'u64' API to add 'u64' data.
>
> In addition, this patchset introduces two APIs to store u32 and u64
> values as hexadecimal encoded strings in telemetry library.
>
> ---
> -v2:
> - fix ABI break warning.
> - introduce two APIs to store u32 and u64 values as hexadecimal
> encoded strings.
>
> Huisong Li (11):
> telemetry: move to header to controllable range
> telemetry: add u32 value type
> test: add test cases for adding u32 value API
> ethdev: fix possible data truncation and conversion error
> mempool: fix possible data truncation and conversion error
> cryptodev: fix possible data conversion error
> mem: possible data truncation and conversion error
> telemetry: refactor mapping betwween value and array type
> telemetry: support adding integer value as hexadecimal
> test: add test cases for adding hex integer values API
> ethdev: display capability values in hexadecimal format
>
> app/test/test_telemetry_data.c | 249 ++++++++++++++++++++++++++++-
> app/test/test_telemetry_json.c | 23 ++-
> lib/cryptodev/rte_cryptodev.c | 2 +-
> lib/eal/common/eal_common_memory.c | 14 +-
> lib/ethdev/rte_ethdev.c | 13 +-
> lib/mempool/rte_mempool.c | 24 +--
> lib/telemetry/rte_telemetry.h | 112 ++++++++++++-
> lib/telemetry/telemetry.c | 25 ++-
> lib/telemetry/telemetry_data.c | 122 ++++++++++++--
> lib/telemetry/telemetry_data.h | 2 +
> lib/telemetry/telemetry_json.h | 29 ++++
> lib/telemetry/version.map | 14 ++
> 12 files changed, 581 insertions(+), 48 deletions(-)
>
^ permalink raw reply [relevance 0%]
* Re: [PATCH V2 00/11] telemetry: add u32 value type and hex integer string API
2022-12-09 18:24 0% ` Morten Brørup
@ 2022-12-12 6:23 0% ` lihuisong (C)
0 siblings, 0 replies; 200+ results
From: lihuisong (C) @ 2022-12-12 6:23 UTC (permalink / raw)
To: Morten Brørup, dev
Cc: bruce.richardson, ciara.power, liudongdong3, huangdaode, fengchengwen
在 2022/12/10 2:24, Morten Brørup 写道:
>> From: Huisong Li [mailto:lihuisong@huawei.com]
>> Sent: Friday, 9 December 2022 12.05
>>
>> Some lib telemetry interfaces add the 'u32' and 'u64' data by the
>> rte_tel_data_add_dict/array_int API. This may cause data conversion
>> error or data truncation.
>>
>> The 'u32' data can not be assigned to signed 32-bit integer. However,
>> assigning to u64 is very wasteful, after all, the buffer capacity of
>> each transfer is limited. So it is necessary for 'u32' data to add
>> usigned 32-bit integer type and a series of 'u32' operation APIs.
>>
>> This patchset uses the new 'u32' API to resolve the problem of data
>> conversion error, and use the 'u64' API to add 'u64' data.
>>
>> In addition, this patchset introduces two APIs to store u32 and u64
>> values as hexadecimal encoded strings in telemetry library.
>>
>> ---
>> -v2:
>> - fix ABI break warning.
>> - introduce two APIs to store u32 and u64 values as hexadecimal
>> encoded strings.
> Looks good.
>
> Personally, I would prefer rte_tel_data_add_{dict|array}_u32_hex() over _hex_u32_str(), and similar for u64; but it is a matter of taste, so feel free to change or keep your own suggested names.
I think this name can represent the type of value stored in dict or
array.😁
>
> In the eal_common_memory.c patch, in rte_tel_data_add_dict_u32(d, "Head id", heap_id);, consider fixing the old typo too, it should be "Heap_id", not "Head id". On the other hand, it will change the JSON output, so perhaps it will be considered an API breakage?
Yes, you are right. I'll try fix it in another patch.
>
>
> Series-acked-by: Morten Brørup <mb@smartsharesystems.com>
>
>
> .
^ permalink raw reply [relevance 0%]
* [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API
2022-12-09 11:04 3% ` [PATCH V2 00/11] telemetry: add u32 value type and hex integer string API Huisong Li
@ 2022-12-12 6:42 3% ` Huisong Li
2022-12-12 10:31 0% ` Bruce Richardson
2022-12-13 10:15 3% ` [PATCH V4 0/9] telemetry: fix data truncation and conversion error and add hex integer API Huisong Li
` (4 subsequent siblings)
6 siblings, 1 reply; 200+ results
From: Huisong Li @ 2022-12-12 6:42 UTC (permalink / raw)
To: dev
Cc: bruce.richardson, mb, ciara.power, liudongdong3, huangdaode,
fengchengwen, lihuisong
Some lib telemetry interfaces add the 'u32' and 'u64' data by the
rte_tel_data_add_dict/array_int API. This may cause data conversion
error or data truncation.
The 'u32' data can not be assigned to signed 32-bit integer. However,
assigning to u64 is very wasteful, after all, the buffer capacity of
each transfer is limited. So it is necessary for 'u32' data to add
usigned 32-bit integer type and a series of 'u32' operation APIs.
This patchset uses the new 'u32' API to resolve the problem of data
conversion error, and use the 'u64' API to add 'u64' data.
In addition, this patchset introduces two APIs to store u32 and u64
values as hexadecimal encoded strings in telemetry library.
---
-v3: fix a misspelling mistake in commit log.
-v2:
- fix ABI break warning.
- introduce two APIs to store u32 and u64 values as hexadecimal
encoded strings.
Huisong Li (11):
telemetry: move to header to controllable range
telemetry: add u32 value type
test: add test cases for adding u32 value API
ethdev: fix possible data truncation and conversion error
mempool: fix possible data truncation and conversion error
cryptodev: fix possible data conversion error
mem: possible data truncation and conversion error
telemetry: refactor mapping betwween value and array type
telemetry: support adding integer value as hexadecimal
test: add test cases for adding hex integer values API
ethdev: display capability values in hexadecimal format
app/test/test_telemetry_data.c | 249 ++++++++++++++++++++++++++++-
app/test/test_telemetry_json.c | 23 ++-
lib/cryptodev/rte_cryptodev.c | 2 +-
lib/eal/common/eal_common_memory.c | 14 +-
lib/ethdev/rte_ethdev.c | 13 +-
lib/mempool/rte_mempool.c | 24 +--
lib/telemetry/rte_telemetry.h | 112 ++++++++++++-
lib/telemetry/telemetry.c | 25 ++-
lib/telemetry/telemetry_data.c | 122 ++++++++++++--
lib/telemetry/telemetry_data.h | 2 +
lib/telemetry/telemetry_json.h | 29 ++++
lib/telemetry/version.map | 14 ++
12 files changed, 581 insertions(+), 48 deletions(-)
--
2.33.0
^ permalink raw reply [relevance 3%]
* Re: [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API
2022-12-12 6:42 3% ` [PATCH V3 " Huisong Li
@ 2022-12-12 10:31 0% ` Bruce Richardson
2022-12-12 11:02 0% ` Morten Brørup
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2022-12-12 10:31 UTC (permalink / raw)
To: Huisong Li; +Cc: dev, mb, ciara.power, liudongdong3, huangdaode, fengchengwen
On Mon, Dec 12, 2022 at 02:42:55PM +0800, Huisong Li wrote:
> Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> rte_tel_data_add_dict/array_int API. This may cause data conversion error
> or data truncation.
>
> The 'u32' data can not be assigned to signed 32-bit integer. However,
> assigning to u64 is very wasteful, after all, the buffer capacity of each
> transfer is limited. So it is necessary for 'u32' data to add usigned
> 32-bit integer type and a series of 'u32' operation APIs.
>
> This patchset uses the new 'u32' API to resolve the problem of data
> conversion error, and use the 'u64' API to add 'u64' data.
>
> In addition, this patchset introduces two APIs to store u32 and u64
> values as hexadecimal encoded strings in telemetry library.
>
> --- -v3: fix a misspelling mistake in commit log. -v2: - fix ABI break
> warning. - introduce two APIs to store u32 and u64 values as hexadecimal
> encoded strings.
>
I'm not convinced about adding the u32 value generically to the telemetry
lib - except in the case of having explicit function calls for u32 vs u64
hex strings. Having a u32 type doesn't gain us any space internally over a
u64 value, since all values are in a union type. Also, for output as json,
the numeric values are all output as decimal values, meaning that the value
1 appears as the same size in the output string whether it is a u32 or u64
type. Now, it may save space in a future binary output format, but even
then it still may not do so.
Therefore, I'd tend to keep the existing u64 type as-is, and instead only
add the functions for outputting hex values. Those hex output functions
could take an additional parameter indicating the desired hex output
length, as there could well be cases where we want just 16-bit hex value
too.
/Bruce
^ permalink raw reply [relevance 0%]
* RE: [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API
2022-12-12 10:31 0% ` Bruce Richardson
@ 2022-12-12 11:02 0% ` Morten Brørup
2022-12-12 11:20 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2022-12-12 11:02 UTC (permalink / raw)
To: Bruce Richardson, Huisong Li
Cc: dev, ciara.power, liudongdong3, huangdaode, fengchengwen
> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Monday, 12 December 2022 11.32
>
> On Mon, Dec 12, 2022 at 02:42:55PM +0800, Huisong Li wrote:
> > Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> > rte_tel_data_add_dict/array_int API. This may cause data conversion
> error
> > or data truncation.
> >
> > The 'u32' data can not be assigned to signed 32-bit integer. However,
> > assigning to u64 is very wasteful, after all, the buffer capacity of
> each
> > transfer is limited. So it is necessary for 'u32' data to add usigned
> > 32-bit integer type and a series of 'u32' operation APIs.
> >
> > This patchset uses the new 'u32' API to resolve the problem of data
> > conversion error, and use the 'u64' API to add 'u64' data.
> >
> > In addition, this patchset introduces two APIs to store u32 and u64
> > values as hexadecimal encoded strings in telemetry library.
> >
> > --- -v3: fix a misspelling mistake in commit log. -v2: - fix ABI
> break
> > warning. - introduce two APIs to store u32 and u64 values as
> hexadecimal
> > encoded strings.
> >
> I'm not convinced about adding the u32 value generically to the
> telemetry
> lib - except in the case of having explicit function calls for u32 vs
> u64
> hex strings. Having a u32 type doesn't gain us any space internally
> over a
> u64 value, since all values are in a union type. Also, for output as
> json,
> the numeric values are all output as decimal values, meaning that the
> value
> 1 appears as the same size in the output string whether it is a u32 or
> u64
> type. Now, it may save space in a future binary output format, but even
> then it still may not do so.
I agree that a u32 doesn't gain any space internally.
However, many SNMP counters are unsigned 32 bit, and expected to wrap around as such.
So I suppose the u32 type might be useful for SNMP, if obtained through the telemetry library.
Alternatively, we could somehow reuse the u64 type and require the application to pass (value & UINT32_MAX) to the u64 functions. To make this easy to use, we should add some wrappers to do it for the application. And eventually we would probably end up with something very similar to this patch.
>
> Therefore, I'd tend to keep the existing u64 type as-is, and instead
> only
> add the functions for outputting hex values. Those hex output functions
> could take an additional parameter indicating the desired hex output
> length, as there could well be cases where we want just 16-bit hex
> value
> too.
The way I read the patch series, the hex output length is not fixed, but an u64 value of 5 will be output as 0x5, not 0x0000000000000005.
So the only benefit of having both u32_hex and u64_hex functions is to avoid type promotion from uint32_t to uint64_t on input for 32 bit values.
Instead of passing a 3rd parameter or adding u16_hex functions, we could consider just having one set of hex functions using uint64_t for the value, and rely on type promotion for 32 and 16 bit values.
^ permalink raw reply [relevance 0%]
* Re: [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API
2022-12-12 11:02 0% ` Morten Brørup
@ 2022-12-12 11:20 0% ` Bruce Richardson
2022-12-12 12:03 3% ` Morten Brørup
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2022-12-12 11:20 UTC (permalink / raw)
To: Morten Brørup
Cc: Huisong Li, dev, ciara.power, liudongdong3, huangdaode, fengchengwen
On Mon, Dec 12, 2022 at 12:02:32PM +0100, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Monday, 12 December 2022 11.32
> >
> > On Mon, Dec 12, 2022 at 02:42:55PM +0800, Huisong Li wrote:
> > > Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> > > rte_tel_data_add_dict/array_int API. This may cause data conversion
> > error
> > > or data truncation.
> > >
> > > The 'u32' data can not be assigned to signed 32-bit integer. However,
> > > assigning to u64 is very wasteful, after all, the buffer capacity of
> > each
> > > transfer is limited. So it is necessary for 'u32' data to add usigned
> > > 32-bit integer type and a series of 'u32' operation APIs.
> > >
> > > This patchset uses the new 'u32' API to resolve the problem of data
> > > conversion error, and use the 'u64' API to add 'u64' data.
> > >
> > > In addition, this patchset introduces two APIs to store u32 and u64
> > > values as hexadecimal encoded strings in telemetry library.
> > >
> > > --- -v3: fix a misspelling mistake in commit log. -v2: - fix ABI
> > break
> > > warning. - introduce two APIs to store u32 and u64 values as
> > hexadecimal
> > > encoded strings.
> > >
> > I'm not convinced about adding the u32 value generically to the
> > telemetry
> > lib - except in the case of having explicit function calls for u32 vs
> > u64
> > hex strings. Having a u32 type doesn't gain us any space internally
> > over a
> > u64 value, since all values are in a union type. Also, for output as
> > json,
> > the numeric values are all output as decimal values, meaning that the
> > value
> > 1 appears as the same size in the output string whether it is a u32 or
> > u64
> > type. Now, it may save space in a future binary output format, but even
> > then it still may not do so.
>
> I agree that a u32 doesn't gain any space internally.
>
> However, many SNMP counters are unsigned 32 bit, and expected to wrap around as such.
>
> So I suppose the u32 type might be useful for SNMP, if obtained through the telemetry library.
>
> Alternatively, we could somehow reuse the u64 type and require the application to pass (value & UINT32_MAX) to the u64 functions. To make this easy to use, we should add some wrappers to do it for the application. And eventually we would probably end up with something very similar to this patch.
>
I think just using the u64 functions is probably simplest and best right
now. If we add support for something like snmp then yes, it would make
sense to explicitly add it, but it seems like a lot of extra code for
little or no benefit until we support something like that.
> >
> > Therefore, I'd tend to keep the existing u64 type as-is, and instead
> > only
> > add the functions for outputting hex values. Those hex output functions
> > could take an additional parameter indicating the desired hex output
> > length, as there could well be cases where we want just 16-bit hex
> > value
> > too.
>
> The way I read the patch series, the hex output length is not fixed, but an u64 value of 5 will be output as 0x5, not 0x0000000000000005.
>
> So the only benefit of having both u32_hex and u64_hex functions is to avoid type promotion from uint32_t to uint64_t on input for 32 bit values.
>
> Instead of passing a 3rd parameter or adding u16_hex functions, we could consider just having one set of hex functions using uint64_t for the value, and rely on type promotion for 32 and 16 bit values.
>
+1 to having only a single hex function, and I think type promotion should
work fine.
However, I still think it might be worthwhile allowing the user to pass in
a min output length parameter too. I find for many hex strings having the
leading zeros to explicitly show the length can be useful. The value "0"
could cover the current behaviour of no-padding, otherwise the parameter
should indicate the number of bits to be displayed. (If we want to lock it
down we can use an enum parameter rather than int to limit it to 0, 8, 16,
32 or 64 bit displayed values).
All that said, I'm not massively concerned if we want to just keep the
current approach of always just printing without any leading zeros. It's a
nice-to-have only for me.
/Bruce
^ permalink raw reply [relevance 0%]
* RE: [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API
2022-12-12 11:20 0% ` Bruce Richardson
@ 2022-12-12 12:03 3% ` Morten Brørup
2022-12-12 12:16 3% ` Bruce Richardson
2022-12-13 3:02 0% ` lihuisong (C)
0 siblings, 2 replies; 200+ results
From: Morten Brørup @ 2022-12-12 12:03 UTC (permalink / raw)
To: Bruce Richardson, Huisong Li
Cc: dev, ciara.power, liudongdong3, huangdaode, fengchengwen
> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Monday, 12 December 2022 12.21
>
> On Mon, Dec 12, 2022 at 12:02:32PM +0100, Morten Brørup wrote:
> > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > Sent: Monday, 12 December 2022 11.32
> > >
> > > On Mon, Dec 12, 2022 at 02:42:55PM +0800, Huisong Li wrote:
> > > > Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> > > > rte_tel_data_add_dict/array_int API. This may cause data
> conversion
> > > error
> > > > or data truncation.
> > > >
> > > > The 'u32' data can not be assigned to signed 32-bit integer.
> However,
> > > > assigning to u64 is very wasteful, after all, the buffer capacity
> of
> > > each
> > > > transfer is limited. So it is necessary for 'u32' data to add
> usigned
> > > > 32-bit integer type and a series of 'u32' operation APIs.
> > > >
> > > > This patchset uses the new 'u32' API to resolve the problem of
> data
> > > > conversion error, and use the 'u64' API to add 'u64' data.
> > > >
> > > > In addition, this patchset introduces two APIs to store u32 and
> u64
> > > > values as hexadecimal encoded strings in telemetry library.
> > > >
> > > > --- -v3: fix a misspelling mistake in commit log. -v2: - fix ABI
> > > break
> > > > warning. - introduce two APIs to store u32 and u64 values as
> > > hexadecimal
> > > > encoded strings.
> > > >
> > > I'm not convinced about adding the u32 value generically to the
> > > telemetry
> > > lib - except in the case of having explicit function calls for u32
> vs
> > > u64
> > > hex strings. Having a u32 type doesn't gain us any space internally
> > > over a
> > > u64 value, since all values are in a union type. Also, for output
> as
> > > json,
> > > the numeric values are all output as decimal values, meaning that
> the
> > > value
> > > 1 appears as the same size in the output string whether it is a u32
> or
> > > u64
> > > type. Now, it may save space in a future binary output format, but
> even
> > > then it still may not do so.
> >
> > I agree that a u32 doesn't gain any space internally.
> >
> > However, many SNMP counters are unsigned 32 bit, and expected to wrap
> around as such.
> >
> > So I suppose the u32 type might be useful for SNMP, if obtained
> through the telemetry library.
> >
> > Alternatively, we could somehow reuse the u64 type and require the
> application to pass (value & UINT32_MAX) to the u64 functions. To make
> this easy to use, we should add some wrappers to do it for the
> application. And eventually we would probably end up with something
> very similar to this patch.
> >
>
> I think just using the u64 functions is probably simplest and best
> right
> now. If we add support for something like snmp then yes, it would make
> sense to explicitly add it, but it seems like a lot of extra code for
> little or no benefit until we support something like that.
<rant>
If we wanted to fix this generally, we should rely on type promotion, so the existing _int function should be updated to take an int64_t value, and the _u64 function should be renamed to _uint (and still take an uint64_t value). However, that would break the ABI, and would need to go through some process for that. So let's not change this now.
</rant>
I tend to agree with Bruce on this: Let's get rid of the new u32 functions, and rely on the u64 functions for that instead.
>
> > >
> > > Therefore, I'd tend to keep the existing u64 type as-is, and
> instead
> > > only
> > > add the functions for outputting hex values. Those hex output
> functions
> > > could take an additional parameter indicating the desired hex
> output
> > > length, as there could well be cases where we want just 16-bit hex
> > > value
> > > too.
> >
> > The way I read the patch series, the hex output length is not fixed,
> but an u64 value of 5 will be output as 0x5, not 0x0000000000000005.
> >
> > So the only benefit of having both u32_hex and u64_hex functions is
> to avoid type promotion from uint32_t to uint64_t on input for 32 bit
> values.
> >
> > Instead of passing a 3rd parameter or adding u16_hex functions, we
> could consider just having one set of hex functions using uint64_t for
> the value, and rely on type promotion for 32 and 16 bit values.
> >
>
> +1 to having only a single hex function, and I think type promotion
> should
> work fine.
>
> However, I still think it might be worthwhile allowing the user to pass
> in
> a min output length parameter too. I find for many hex strings having
> the
> leading zeros to explicitly show the length can be useful. The value
> "0"
> could cover the current behaviour of no-padding, otherwise the
> parameter
> should indicate the number of bits to be displayed. (If we want to lock
> it
> down we can use an enum parameter rather than int to limit it to 0, 8,
> 16,
> 32 or 64 bit displayed values).
An extra parameter for minimum output length (in number of input bits) would be very nice, and makes avoids a set of functions for each bit width.
(I don't think it should be lock it down to some special bit lengths; there is no need to prevent 24 bit or other exotic bit widths.)
Something like this:
char str[64]; // Big enough length.
if (bits != 0) {
char format[16]; // Big enough length.
sprintf(format, "0x0%u%" PRIx64, (bits + 3) / 4);
sprintf(str, format, value);
} else {
sprintf(str, "0x%" PRIx64, value);
}
>
> All that said, I'm not massively concerned if we want to just keep the
> current approach of always just printing without any leading zeros.
> It's a
> nice-to-have only for me.
>
> /Bruce
^ permalink raw reply [relevance 3%]
* Re: [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API
2022-12-12 12:03 3% ` Morten Brørup
@ 2022-12-12 12:16 3% ` Bruce Richardson
2022-12-13 11:00 0% ` Morten Brørup
2022-12-13 17:12 3% ` Bruce Richardson
2022-12-13 3:02 0% ` lihuisong (C)
1 sibling, 2 replies; 200+ results
From: Bruce Richardson @ 2022-12-12 12:16 UTC (permalink / raw)
To: Morten Brørup
Cc: Huisong Li, dev, ciara.power, liudongdong3, huangdaode, fengchengwen
On Mon, Dec 12, 2022 at 01:03:52PM +0100, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Monday, 12 December 2022 12.21
> >
> > On Mon, Dec 12, 2022 at 12:02:32PM +0100, Morten Brørup wrote:
> > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > > Sent: Monday, 12 December 2022 11.32
> > > >
> > > > On Mon, Dec 12, 2022 at 02:42:55PM +0800, Huisong Li wrote:
> > > > > Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> > > > > rte_tel_data_add_dict/array_int API. This may cause data
> > conversion
> > > > error
> > > > > or data truncation.
> > > > >
> > > > > The 'u32' data can not be assigned to signed 32-bit integer.
> > However,
> > > > > assigning to u64 is very wasteful, after all, the buffer capacity
> > of
> > > > each
> > > > > transfer is limited. So it is necessary for 'u32' data to add
> > usigned
> > > > > 32-bit integer type and a series of 'u32' operation APIs.
> > > > >
> > > > > This patchset uses the new 'u32' API to resolve the problem of
> > data
> > > > > conversion error, and use the 'u64' API to add 'u64' data.
> > > > >
> > > > > In addition, this patchset introduces two APIs to store u32 and
> > u64
> > > > > values as hexadecimal encoded strings in telemetry library.
> > > > >
> > > > > --- -v3: fix a misspelling mistake in commit log. -v2: - fix ABI
> > > > break
> > > > > warning. - introduce two APIs to store u32 and u64 values as
> > > > hexadecimal
> > > > > encoded strings.
> > > > >
> > > > I'm not convinced about adding the u32 value generically to the
> > > > telemetry
> > > > lib - except in the case of having explicit function calls for u32
> > vs
> > > > u64
> > > > hex strings. Having a u32 type doesn't gain us any space internally
> > > > over a
> > > > u64 value, since all values are in a union type. Also, for output
> > as
> > > > json,
> > > > the numeric values are all output as decimal values, meaning that
> > the
> > > > value
> > > > 1 appears as the same size in the output string whether it is a u32
> > or
> > > > u64
> > > > type. Now, it may save space in a future binary output format, but
> > even
> > > > then it still may not do so.
> > >
> > > I agree that a u32 doesn't gain any space internally.
> > >
> > > However, many SNMP counters are unsigned 32 bit, and expected to wrap
> > around as such.
> > >
> > > So I suppose the u32 type might be useful for SNMP, if obtained
> > through the telemetry library.
> > >
> > > Alternatively, we could somehow reuse the u64 type and require the
> > application to pass (value & UINT32_MAX) to the u64 functions. To make
> > this easy to use, we should add some wrappers to do it for the
> > application. And eventually we would probably end up with something
> > very similar to this patch.
> > >
> >
> > I think just using the u64 functions is probably simplest and best
> > right
> > now. If we add support for something like snmp then yes, it would make
> > sense to explicitly add it, but it seems like a lot of extra code for
> > little or no benefit until we support something like that.
>
> <rant>
> If we wanted to fix this generally, we should rely on type promotion, so the existing _int function should be updated to take an int64_t value, and the _u64 function should be renamed to _uint (and still take an uint64_t value). However, that would break the ABI, and would need to go through some process for that. So let's not change this now.
> </rant>
Yes, not making "int" an "i64" type was a poor design decision on my part
in the earlier versions. Thankfully negative values are rarely needed
beyond the range of 32-bits, but we should probably look to update this as
you suggest at the next ABI break window.
>
> I tend to agree with Bruce on this: Let's get rid of the new u32 functions, and rely on the u64 functions for that instead.
>
> >
> > > >
> > > > Therefore, I'd tend to keep the existing u64 type as-is, and
> > instead
> > > > only
> > > > add the functions for outputting hex values. Those hex output
> > functions
> > > > could take an additional parameter indicating the desired hex
> > output
> > > > length, as there could well be cases where we want just 16-bit hex
> > > > value
> > > > too.
> > >
> > > The way I read the patch series, the hex output length is not fixed,
> > but an u64 value of 5 will be output as 0x5, not 0x0000000000000005.
> > >
> > > So the only benefit of having both u32_hex and u64_hex functions is
> > to avoid type promotion from uint32_t to uint64_t on input for 32 bit
> > values.
> > >
> > > Instead of passing a 3rd parameter or adding u16_hex functions, we
> > could consider just having one set of hex functions using uint64_t for
> > the value, and rely on type promotion for 32 and 16 bit values.
> > >
> >
> > +1 to having only a single hex function, and I think type promotion
> > should
> > work fine.
> >
> > However, I still think it might be worthwhile allowing the user to pass
> > in
> > a min output length parameter too. I find for many hex strings having
> > the
> > leading zeros to explicitly show the length can be useful. The value
> > "0"
> > could cover the current behaviour of no-padding, otherwise the
> > parameter
> > should indicate the number of bits to be displayed. (If we want to lock
> > it
> > down we can use an enum parameter rather than int to limit it to 0, 8,
> > 16,
> > 32 or 64 bit displayed values).
>
> An extra parameter for minimum output length (in number of input bits) would be very nice, and makes avoids a set of functions for each bit width.
>
> (I don't think it should be lock it down to some special bit lengths; there is no need to prevent 24 bit or other exotic bit widths.)
>
> Something like this:
>
> char str[64]; // Big enough length.
> if (bits != 0) {
> char format[16]; // Big enough length.
> sprintf(format, "0x0%u%" PRIx64, (bits + 3) / 4);
> sprintf(str, format, value);
> } else {
> sprintf(str, "0x%" PRIx64, value);
> }
>
LGTM.
^ permalink raw reply [relevance 3%]
* [PATCH] cryptodev: add algo enums to string conversion APIs
@ 2022-12-12 15:10 2% Akhil Goyal
2022-12-13 7:31 0% ` Ruifeng Wang
` (4 more replies)
0 siblings, 5 replies; 200+ results
From: Akhil Goyal @ 2022-12-12 15:10 UTC (permalink / raw)
To: dev
Cc: ciara.power, fanzhang.oss, kai.ji, pablo.de.lara.guarch,
hemant.agrawal, matan, g.singh, ruifeng.wang, anoobj,
radu.nicolau, vfialko, ktraynor, david.marchand, thomas,
Akhil Goyal
Symmetric/Asymmetric algorithm strings are accessed by application
using arrays in cryptodev lib, which hampers new algorithms addition
in the array due to ABI breakage.
These arrays are now deprecated and will be removed in next ABI break
release.
New APIs are added for getting the algorithm strings based on enum values.
Signed-off-by: Akhil Goyal <gakhil@marvell.com>
---
app/test-crypto-perf/cperf_options_parsing.c | 6 +-
app/test/test_cryptodev_asym.c | 2 +-
app/test/test_cryptodev_security_ipsec.c | 8 +-
doc/guides/rel_notes/deprecation.rst | 7 +
drivers/crypto/openssl/rte_openssl_pmd_ops.c | 2 +-
drivers/crypto/qat/qat_sym_session.c | 7 +-
examples/l2fwd-crypto/main.c | 12 +-
lib/cryptodev/cryptodev_trace_points.c | 12 ++
lib/cryptodev/rte_crypto_asym.h | 1 +
lib/cryptodev/rte_crypto_sym.h | 3 +
lib/cryptodev/rte_cryptodev.c | 182 ++++++++++++++++++-
lib/cryptodev/rte_cryptodev.h | 52 ++++++
lib/cryptodev/rte_cryptodev_trace.h | 32 ++++
lib/cryptodev/version.map | 10 +
14 files changed, 309 insertions(+), 27 deletions(-)
diff --git a/app/test-crypto-perf/cperf_options_parsing.c b/app/test-crypto-perf/cperf_options_parsing.c
index bc5e312c81..f8ddb6ac56 100644
--- a/app/test-crypto-perf/cperf_options_parsing.c
+++ b/app/test-crypto-perf/cperf_options_parsing.c
@@ -1373,7 +1373,7 @@ cperf_options_dump(struct cperf_options *opts)
opts->op_type == CPERF_CIPHER_THEN_AUTH ||
opts->op_type == CPERF_AUTH_THEN_CIPHER) {
printf("# auth algorithm: %s\n",
- rte_crypto_auth_algorithm_strings[opts->auth_algo]);
+ rte_cryptodev_get_auth_algo_string(opts->auth_algo));
printf("# auth operation: %s\n",
rte_crypto_auth_operation_strings[opts->auth_op]);
printf("# auth key size: %u\n", opts->auth_key_sz);
@@ -1386,7 +1386,7 @@ cperf_options_dump(struct cperf_options *opts)
opts->op_type == CPERF_CIPHER_THEN_AUTH ||
opts->op_type == CPERF_AUTH_THEN_CIPHER) {
printf("# cipher algorithm: %s\n",
- rte_crypto_cipher_algorithm_strings[opts->cipher_algo]);
+ rte_cryptodev_get_cipher_algo_string(opts->cipher_algo));
printf("# cipher operation: %s\n",
rte_crypto_cipher_operation_strings[opts->cipher_op]);
printf("# cipher key size: %u\n", opts->cipher_key_sz);
@@ -1396,7 +1396,7 @@ cperf_options_dump(struct cperf_options *opts)
if (opts->op_type == CPERF_AEAD) {
printf("# aead algorithm: %s\n",
- rte_crypto_aead_algorithm_strings[opts->aead_algo]);
+ rte_cryptodev_get_aead_algo_string(opts->aead_algo));
printf("# aead operation: %s\n",
rte_crypto_aead_operation_strings[opts->aead_op]);
printf("# aead key size: %u\n", opts->aead_key_sz);
diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index c58c7f488b..5b16dcab56 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -974,7 +974,7 @@ static inline void print_asym_capa(
int i = 0;
printf("\nxform type: %s\n===================\n",
- rte_crypto_asym_xform_strings[capa->xform_type]);
+ rte_cryptodev_asym_get_xform_string(capa->xform_type));
printf("operation supported -");
for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
diff --git a/app/test/test_cryptodev_security_ipsec.c b/app/test/test_cryptodev_security_ipsec.c
index 833be94c09..417ff10a1b 100644
--- a/app/test/test_cryptodev_security_ipsec.c
+++ b/app/test/test_cryptodev_security_ipsec.c
@@ -625,20 +625,20 @@ test_ipsec_display_alg(const struct crypto_param *param1,
{
if (param1->type == RTE_CRYPTO_SYM_XFORM_AEAD) {
printf("\t%s [%d]",
- rte_crypto_aead_algorithm_strings[param1->alg.aead],
+ rte_cryptodev_get_aead_algo_string(param1->alg.aead),
param1->key_length * 8);
} else if (param1->type == RTE_CRYPTO_SYM_XFORM_AUTH) {
printf("\t%s",
- rte_crypto_auth_algorithm_strings[param1->alg.auth]);
+ rte_cryptodev_get_auth_algo_string(param1->alg.auth));
if (param1->alg.auth != RTE_CRYPTO_AUTH_NULL)
printf(" [%dB ICV]", param1->digest_length);
} else {
printf("\t%s",
- rte_crypto_cipher_algorithm_strings[param1->alg.cipher]);
+ rte_cryptodev_get_cipher_algo_string(param1->alg.cipher));
if (param1->alg.cipher != RTE_CRYPTO_CIPHER_NULL)
printf(" [%d]", param1->key_length * 8);
printf(" %s",
- rte_crypto_auth_algorithm_strings[param2->alg.auth]);
+ rte_cryptodev_get_auth_algo_string(param2->alg.auth));
if (param2->alg.auth != RTE_CRYPTO_AUTH_NULL)
printf(" [%dB ICV]", param2->digest_length);
}
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index b9b02dcef0..e18ac344ef 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -114,6 +114,13 @@ Deprecation Notices
which got error interrupt to the application,
so that application can reset that particular queue pair.
+* cryptodev: The arrays of algorithm strings ``rte_crypto_cipher_algorithm_strings``,
+ ``rte_crypto_auth_algorithm_strings``, ``rte_crypto_aead_algorithm_strings`` and
+ ``rte_crypto_asym_xform_strings`` are deprecated and will be removed in DPDK 23.11.
+ Application can use the new APIs ``rte_cryptodev_get_cipher_algo_string``,
+ ``rte_cryptodev_get_auth_algo_string``, ``rte_cryptodev_get_aead_algo_string`` and
+ ``rte_cryptodev_asym_get_xform_string`` respectively.
+
* flow_classify: The flow_classify library and example have no maintainer.
The library is experimental and, as such, it could be removed from DPDK.
Its removal has been postponed to let potential users report interest
diff --git a/drivers/crypto/openssl/rte_openssl_pmd_ops.c b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
index defed4429e..29ad1b9505 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd_ops.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
@@ -823,7 +823,7 @@ static int openssl_set_asym_session_parameters(
if ((xform->xform_type != RTE_CRYPTO_ASYM_XFORM_DH) &&
(xform->next != NULL)) {
OPENSSL_LOG(ERR, "chained xfrms are not supported on %s",
- rte_crypto_asym_xform_strings[xform->xform_type]);
+ rte_cryptodev_asym_get_xform_string(xform->xform_type));
return ret;
}
diff --git a/drivers/crypto/qat/qat_sym_session.c b/drivers/crypto/qat/qat_sym_session.c
index 0ebc66f89e..714002dce3 100644
--- a/drivers/crypto/qat/qat_sym_session.c
+++ b/drivers/crypto/qat/qat_sym_session.c
@@ -436,8 +436,8 @@ qat_sym_session_configure_cipher(struct rte_cryptodev *dev,
if (!qat_is_cipher_alg_supported(
cipher_xform->algo, internals)) {
QAT_LOG(ERR, "%s not supported on this device",
- rte_crypto_cipher_algorithm_strings
- [cipher_xform->algo]);
+ rte_cryptodev_get_cipher_algo_string(
+ cipher_xform->algo));
ret = -ENOTSUP;
goto error_out;
}
@@ -772,8 +772,7 @@ qat_sym_session_configure_auth(struct rte_cryptodev *dev,
case RTE_CRYPTO_AUTH_ZUC_EIA3:
if (!qat_is_auth_alg_supported(auth_xform->algo, internals)) {
QAT_LOG(ERR, "%s not supported on this device",
- rte_crypto_auth_algorithm_strings
- [auth_xform->algo]);
+ rte_cryptodev_get_auth_algo_string(auth_xform->algo));
return -ENOTSUP;
}
session->qat_hash_alg = ICP_QAT_HW_AUTH_ALGO_ZUC_3G_128_EIA3;
diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index b13e5c526e..efe7eea2a7 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -1536,7 +1536,7 @@ display_cipher_info(struct l2fwd_crypto_options *options)
{
printf("\n---- Cipher information ---\n");
printf("Algorithm: %s\n",
- rte_crypto_cipher_algorithm_strings[options->cipher_xform.cipher.algo]);
+ rte_cryptodev_get_cipher_algo_string(options->cipher_xform.cipher.algo));
rte_hexdump(stdout, "Cipher key:",
options->cipher_xform.cipher.key.data,
options->cipher_xform.cipher.key.length);
@@ -1548,7 +1548,7 @@ display_auth_info(struct l2fwd_crypto_options *options)
{
printf("\n---- Authentication information ---\n");
printf("Algorithm: %s\n",
- rte_crypto_auth_algorithm_strings[options->auth_xform.auth.algo]);
+ rte_cryptodev_get_auth_algo_string(options->auth_xform.auth.algo));
rte_hexdump(stdout, "Auth key:",
options->auth_xform.auth.key.data,
options->auth_xform.auth.key.length);
@@ -1560,7 +1560,7 @@ display_aead_info(struct l2fwd_crypto_options *options)
{
printf("\n---- AEAD information ---\n");
printf("Algorithm: %s\n",
- rte_crypto_aead_algorithm_strings[options->aead_xform.aead.algo]);
+ rte_cryptodev_get_aead_algo_string(options->aead_xform.aead.algo));
rte_hexdump(stdout, "AEAD key:",
options->aead_xform.aead.key.data,
options->aead_xform.aead.key.length);
@@ -1864,7 +1864,7 @@ check_device_support_cipher_algo(const struct l2fwd_crypto_options *options,
if (cap->op == RTE_CRYPTO_OP_TYPE_UNDEFINED) {
printf("Algorithm %s not supported by cryptodev %u"
" or device not of preferred type (%s)\n",
- rte_crypto_cipher_algorithm_strings[opt_cipher_algo],
+ rte_cryptodev_get_cipher_algo_string(opt_cipher_algo),
cdev_id,
options->string_type);
return NULL;
@@ -1898,7 +1898,7 @@ check_device_support_auth_algo(const struct l2fwd_crypto_options *options,
if (cap->op == RTE_CRYPTO_OP_TYPE_UNDEFINED) {
printf("Algorithm %s not supported by cryptodev %u"
" or device not of preferred type (%s)\n",
- rte_crypto_auth_algorithm_strings[opt_auth_algo],
+ rte_cryptodev_get_auth_algo_string(opt_auth_algo),
cdev_id,
options->string_type);
return NULL;
@@ -1932,7 +1932,7 @@ check_device_support_aead_algo(const struct l2fwd_crypto_options *options,
if (cap->op == RTE_CRYPTO_OP_TYPE_UNDEFINED) {
printf("Algorithm %s not supported by cryptodev %u"
" or device not of preferred type (%s)\n",
- rte_crypto_aead_algorithm_strings[opt_aead_algo],
+ rte_cryptodev_get_aead_algo_string(opt_aead_algo),
cdev_id,
options->string_type);
return NULL;
diff --git a/lib/cryptodev/cryptodev_trace_points.c b/lib/cryptodev/cryptodev_trace_points.c
index 63a81511a9..4980bcc9be 100644
--- a/lib/cryptodev/cryptodev_trace_points.c
+++ b/lib/cryptodev/cryptodev_trace_points.c
@@ -72,6 +72,15 @@ RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_auth_algo_enum,
RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_cipher_algo_enum,
lib.cryptodev.get.cipher.algo.enum)
+RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_aead_algo_string,
+ lib.cryptodev.get.aead.algo.string)
+
+RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_auth_algo_string,
+ lib.cryptodev.get.auth.algo.string)
+
+RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_cipher_algo_string,
+ lib.cryptodev.get.cipher.algo.string)
+
RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_dev_id,
lib.cryptodev.get.dev.id)
@@ -126,6 +135,9 @@ RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_get_private_session_size,
RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_get_xform_enum,
lib.cryptodev.asym.get.xform.enum)
+RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_get_xform_string,
+ lib.cryptodev.asym.get.xform.string)
+
RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_xform_capability_check_modlen,
lib.cryptodev.asym.xform.capability.check.modlen)
diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 38c8b60779..989f38323f 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -30,6 +30,7 @@ extern "C" {
struct rte_cryptodev_asym_session;
/** asym xform type name strings */
+__rte_deprecated
extern const char *
rte_crypto_asym_xform_strings[];
diff --git a/lib/cryptodev/rte_crypto_sym.h b/lib/cryptodev/rte_crypto_sym.h
index 33b4966e16..dc847da7b8 100644
--- a/lib/cryptodev/rte_crypto_sym.h
+++ b/lib/cryptodev/rte_crypto_sym.h
@@ -177,6 +177,7 @@ enum rte_crypto_cipher_algorithm {
};
/** Cipher algorithm name strings */
+__rte_deprecated
extern const char *
rte_crypto_cipher_algorithm_strings[];
@@ -378,6 +379,7 @@ enum rte_crypto_auth_algorithm {
};
/** Authentication algorithm name strings */
+__rte_deprecated
extern const char *
rte_crypto_auth_algorithm_strings[];
@@ -482,6 +484,7 @@ enum rte_crypto_aead_algorithm {
};
/** AEAD algorithm name strings */
+__rte_deprecated
extern const char *
rte_crypto_aead_algorithm_strings[];
diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index 2165a0688c..1e98f13dac 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -64,9 +64,11 @@ struct rte_cryptodev_callback {
};
/**
+ * @deprecated
* The crypto cipher algorithm strings identifiers.
* It could be used in application command line.
*/
+__rte_deprecated
const char *
rte_crypto_cipher_algorithm_strings[] = {
[RTE_CRYPTO_CIPHER_3DES_CBC] = "3des-cbc",
@@ -95,6 +97,39 @@ rte_crypto_cipher_algorithm_strings[] = {
[RTE_CRYPTO_CIPHER_SM4_CTR] = "sm4-ctr"
};
+/**
+ * The crypto cipher algorithm strings identifiers.
+ * Not to be used in application directly.
+ * Application can use rte_cryptodev_get_cipher_algo_string().
+ */
+static const char *
+crypto_cipher_algorithm_strings[] = {
+ [RTE_CRYPTO_CIPHER_3DES_CBC] = "3des-cbc",
+ [RTE_CRYPTO_CIPHER_3DES_ECB] = "3des-ecb",
+ [RTE_CRYPTO_CIPHER_3DES_CTR] = "3des-ctr",
+
+ [RTE_CRYPTO_CIPHER_AES_CBC] = "aes-cbc",
+ [RTE_CRYPTO_CIPHER_AES_CTR] = "aes-ctr",
+ [RTE_CRYPTO_CIPHER_AES_DOCSISBPI] = "aes-docsisbpi",
+ [RTE_CRYPTO_CIPHER_AES_ECB] = "aes-ecb",
+ [RTE_CRYPTO_CIPHER_AES_F8] = "aes-f8",
+ [RTE_CRYPTO_CIPHER_AES_XTS] = "aes-xts",
+
+ [RTE_CRYPTO_CIPHER_ARC4] = "arc4",
+
+ [RTE_CRYPTO_CIPHER_DES_CBC] = "des-cbc",
+ [RTE_CRYPTO_CIPHER_DES_DOCSISBPI] = "des-docsisbpi",
+
+ [RTE_CRYPTO_CIPHER_NULL] = "null",
+
+ [RTE_CRYPTO_CIPHER_KASUMI_F8] = "kasumi-f8",
+ [RTE_CRYPTO_CIPHER_SNOW3G_UEA2] = "snow3g-uea2",
+ [RTE_CRYPTO_CIPHER_ZUC_EEA3] = "zuc-eea3",
+ [RTE_CRYPTO_CIPHER_SM4_ECB] = "sm4-ecb",
+ [RTE_CRYPTO_CIPHER_SM4_CBC] = "sm4-cbc",
+ [RTE_CRYPTO_CIPHER_SM4_CTR] = "sm4-ctr"
+};
+
/**
* The crypto cipher operation strings identifiers.
* It could be used in application command line.
@@ -106,9 +141,11 @@ rte_crypto_cipher_operation_strings[] = {
};
/**
+ * @deprecated
* The crypto auth algorithm strings identifiers.
* It could be used in application command line.
*/
+__rte_deprecated
const char *
rte_crypto_auth_algorithm_strings[] = {
[RTE_CRYPTO_AUTH_AES_CBC_MAC] = "aes-cbc-mac",
@@ -149,9 +186,55 @@ rte_crypto_auth_algorithm_strings[] = {
};
/**
+ * The crypto auth algorithm strings identifiers.
+ * Not to be used in application directly.
+ * Application can use rte_cryptodev_get_auth_algo_string().
+ */
+static const char *
+crypto_auth_algorithm_strings[] = {
+ [RTE_CRYPTO_AUTH_AES_CBC_MAC] = "aes-cbc-mac",
+ [RTE_CRYPTO_AUTH_AES_CMAC] = "aes-cmac",
+ [RTE_CRYPTO_AUTH_AES_GMAC] = "aes-gmac",
+ [RTE_CRYPTO_AUTH_AES_XCBC_MAC] = "aes-xcbc-mac",
+
+ [RTE_CRYPTO_AUTH_MD5] = "md5",
+ [RTE_CRYPTO_AUTH_MD5_HMAC] = "md5-hmac",
+
+ [RTE_CRYPTO_AUTH_NULL] = "null",
+
+ [RTE_CRYPTO_AUTH_SHA1] = "sha1",
+ [RTE_CRYPTO_AUTH_SHA1_HMAC] = "sha1-hmac",
+
+ [RTE_CRYPTO_AUTH_SHA224] = "sha2-224",
+ [RTE_CRYPTO_AUTH_SHA224_HMAC] = "sha2-224-hmac",
+ [RTE_CRYPTO_AUTH_SHA256] = "sha2-256",
+ [RTE_CRYPTO_AUTH_SHA256_HMAC] = "sha2-256-hmac",
+ [RTE_CRYPTO_AUTH_SHA384] = "sha2-384",
+ [RTE_CRYPTO_AUTH_SHA384_HMAC] = "sha2-384-hmac",
+ [RTE_CRYPTO_AUTH_SHA512] = "sha2-512",
+ [RTE_CRYPTO_AUTH_SHA512_HMAC] = "sha2-512-hmac",
+
+ [RTE_CRYPTO_AUTH_SHA3_224] = "sha3-224",
+ [RTE_CRYPTO_AUTH_SHA3_224_HMAC] = "sha3-224-hmac",
+ [RTE_CRYPTO_AUTH_SHA3_256] = "sha3-256",
+ [RTE_CRYPTO_AUTH_SHA3_256_HMAC] = "sha3-256-hmac",
+ [RTE_CRYPTO_AUTH_SHA3_384] = "sha3-384",
+ [RTE_CRYPTO_AUTH_SHA3_384_HMAC] = "sha3-384-hmac",
+ [RTE_CRYPTO_AUTH_SHA3_512] = "sha3-512",
+ [RTE_CRYPTO_AUTH_SHA3_512_HMAC] = "sha3-512-hmac",
+
+ [RTE_CRYPTO_AUTH_KASUMI_F9] = "kasumi-f9",
+ [RTE_CRYPTO_AUTH_SNOW3G_UIA2] = "snow3g-uia2",
+ [RTE_CRYPTO_AUTH_ZUC_EIA3] = "zuc-eia3",
+ [RTE_CRYPTO_AUTH_SM3] = "sm3"
+};
+
+/**
+ * @deprecated
* The crypto AEAD algorithm strings identifiers.
* It could be used in application command line.
*/
+__rte_deprecated
const char *
rte_crypto_aead_algorithm_strings[] = {
[RTE_CRYPTO_AEAD_AES_CCM] = "aes-ccm",
@@ -159,6 +242,19 @@ rte_crypto_aead_algorithm_strings[] = {
[RTE_CRYPTO_AEAD_CHACHA20_POLY1305] = "chacha20-poly1305"
};
+/**
+ * The crypto AEAD algorithm strings identifiers.
+ * Not to be used in application directly.
+ * Application can use rte_cryptodev_get_aead_algo_string().
+ */
+static const char *
+crypto_aead_algorithm_strings[] = {
+ [RTE_CRYPTO_AEAD_AES_CCM] = "aes-ccm",
+ [RTE_CRYPTO_AEAD_AES_GCM] = "aes-gcm",
+ [RTE_CRYPTO_AEAD_CHACHA20_POLY1305] = "chacha20-poly1305"
+};
+
+
/**
* The crypto AEAD operation strings identifiers.
* It could be used in application command line.
@@ -170,8 +266,10 @@ rte_crypto_aead_operation_strings[] = {
};
/**
+ * @deprecated
* Asymmetric crypto transform operation strings identifiers.
*/
+__rte_deprecated
const char *rte_crypto_asym_xform_strings[] = {
[RTE_CRYPTO_ASYM_XFORM_NONE] = "none",
[RTE_CRYPTO_ASYM_XFORM_RSA] = "rsa",
@@ -183,6 +281,22 @@ const char *rte_crypto_asym_xform_strings[] = {
[RTE_CRYPTO_ASYM_XFORM_ECPM] = "ecpm",
};
+/**
+ * Asymmetric crypto transform operation strings identifiers.
+ * Not to be used in application directly.
+ * Application can use rte_cryptodev_asym_get_xform_string().
+ */
+static const char *crypto_asym_xform_strings[] = {
+ [RTE_CRYPTO_ASYM_XFORM_NONE] = "none",
+ [RTE_CRYPTO_ASYM_XFORM_RSA] = "rsa",
+ [RTE_CRYPTO_ASYM_XFORM_MODEX] = "modexp",
+ [RTE_CRYPTO_ASYM_XFORM_MODINV] = "modinv",
+ [RTE_CRYPTO_ASYM_XFORM_DH] = "dh",
+ [RTE_CRYPTO_ASYM_XFORM_DSA] = "dsa",
+ [RTE_CRYPTO_ASYM_XFORM_ECDSA] = "ecdsa",
+ [RTE_CRYPTO_ASYM_XFORM_ECPM] = "ecpm",
+};
+
/**
* Asymmetric crypto operation strings identifiers.
*/
@@ -227,8 +341,8 @@ rte_cryptodev_get_cipher_algo_enum(enum rte_crypto_cipher_algorithm *algo_enum,
unsigned int i;
int ret = -1; /* Invalid string */
- for (i = 1; i < RTE_DIM(rte_crypto_cipher_algorithm_strings); i++) {
- if (strcmp(algo_string, rte_crypto_cipher_algorithm_strings[i]) == 0) {
+ for (i = 1; i < RTE_DIM(crypto_cipher_algorithm_strings); i++) {
+ if (strcmp(algo_string, crypto_cipher_algorithm_strings[i]) == 0) {
*algo_enum = (enum rte_crypto_cipher_algorithm) i;
ret = 0;
break;
@@ -247,8 +361,8 @@ rte_cryptodev_get_auth_algo_enum(enum rte_crypto_auth_algorithm *algo_enum,
unsigned int i;
int ret = -1; /* Invalid string */
- for (i = 1; i < RTE_DIM(rte_crypto_auth_algorithm_strings); i++) {
- if (strcmp(algo_string, rte_crypto_auth_algorithm_strings[i]) == 0) {
+ for (i = 1; i < RTE_DIM(crypto_auth_algorithm_strings); i++) {
+ if (strcmp(algo_string, crypto_auth_algorithm_strings[i]) == 0) {
*algo_enum = (enum rte_crypto_auth_algorithm) i;
ret = 0;
break;
@@ -267,8 +381,8 @@ rte_cryptodev_get_aead_algo_enum(enum rte_crypto_aead_algorithm *algo_enum,
unsigned int i;
int ret = -1; /* Invalid string */
- for (i = 1; i < RTE_DIM(rte_crypto_aead_algorithm_strings); i++) {
- if (strcmp(algo_string, rte_crypto_aead_algorithm_strings[i]) == 0) {
+ for (i = 1; i < RTE_DIM(crypto_aead_algorithm_strings); i++) {
+ if (strcmp(algo_string, crypto_aead_algorithm_strings[i]) == 0) {
*algo_enum = (enum rte_crypto_aead_algorithm) i;
ret = 0;
break;
@@ -287,9 +401,9 @@ rte_cryptodev_asym_get_xform_enum(enum rte_crypto_asym_xform_type *xform_enum,
unsigned int i;
int ret = -1; /* Invalid string */
- for (i = 1; i < RTE_DIM(rte_crypto_asym_xform_strings); i++) {
+ for (i = 1; i < RTE_DIM(crypto_asym_xform_strings); i++) {
if (strcmp(xform_string,
- rte_crypto_asym_xform_strings[i]) == 0) {
+ crypto_asym_xform_strings[i]) == 0) {
*xform_enum = (enum rte_crypto_asym_xform_type) i;
ret = 0;
break;
@@ -301,6 +415,58 @@ rte_cryptodev_asym_get_xform_enum(enum rte_crypto_asym_xform_type *xform_enum,
return ret;
}
+const char *
+rte_cryptodev_get_cipher_algo_string(enum rte_crypto_cipher_algorithm algo_enum)
+{
+ const char *alg_str = NULL;
+
+ if (algo_enum < RTE_DIM(crypto_cipher_algorithm_strings))
+ alg_str = crypto_cipher_algorithm_strings[algo_enum];
+
+ rte_cryptodev_trace_get_cipher_algo_string(algo_enum, alg_str);
+
+ return alg_str;
+}
+
+const char *
+rte_cryptodev_get_auth_algo_string(enum rte_crypto_auth_algorithm algo_enum)
+{
+ const char *alg_str = NULL;
+
+ if (algo_enum < RTE_DIM(crypto_auth_algorithm_strings))
+ alg_str = crypto_auth_algorithm_strings[algo_enum];
+
+ rte_cryptodev_trace_get_auth_algo_string(algo_enum, alg_str);
+
+ return alg_str;
+}
+
+const char *
+rte_cryptodev_get_aead_algo_string(enum rte_crypto_aead_algorithm algo_enum)
+{
+ const char *alg_str = NULL;
+
+ if (algo_enum < RTE_DIM(crypto_aead_algorithm_strings))
+ alg_str = crypto_aead_algorithm_strings[algo_enum];
+
+ rte_cryptodev_trace_get_aead_algo_string(algo_enum, alg_str);
+
+ return alg_str;
+}
+
+const char *
+rte_cryptodev_asym_get_xform_string(enum rte_crypto_asym_xform_type xform_enum)
+{
+ const char *xform_str = NULL;
+
+ if (xform_enum < RTE_DIM(crypto_asym_xform_strings))
+ xform_str = crypto_asym_xform_strings[xform_enum];
+
+ rte_cryptodev_trace_asym_get_xform_string(xform_enum, xform_str);
+
+ return xform_str;
+}
+
/**
* The crypto auth operation strings identifiers.
* It could be used in application command line.
diff --git a/lib/cryptodev/rte_cryptodev.h b/lib/cryptodev/rte_cryptodev.h
index 86d792e2e7..8f41a009e3 100644
--- a/lib/cryptodev/rte_cryptodev.h
+++ b/lib/cryptodev/rte_cryptodev.h
@@ -406,6 +406,58 @@ int
rte_cryptodev_asym_get_xform_enum(enum rte_crypto_asym_xform_type *xform_enum,
const char *xform_string);
+/**
+ * Provide the cipher algorithm string, given an algorithm enum.
+ *
+ * @param algo_enum cipher algorithm enum
+ *
+ * @return
+ * - Return NULL if enum is not valid
+ * - Return algo_string corresponding to enum
+ */
+__rte_experimental
+const char *
+rte_cryptodev_get_cipher_algo_string(enum rte_crypto_cipher_algorithm algo_enum);
+
+/**
+ * Provide the authentication algorithm string, given an algorithm enum.
+ *
+ * @param algo_enum auth algorithm enum
+ *
+ * @return
+ * - Return NULL if enum is not valid
+ * - Return algo_string corresponding to enum
+ */
+__rte_experimental
+const char *
+rte_cryptodev_get_auth_algo_string(enum rte_crypto_auth_algorithm algo_enum);
+
+/**
+ * Provide the AEAD algorithm string, given an algorithm enum.
+ *
+ * @param algo_enum AEAD algorithm enum
+ *
+ * @return
+ * - Return NULL if enum is not valid
+ * - Return algo_string corresponding to enum
+ */
+__rte_experimental
+const char *
+rte_cryptodev_get_aead_algo_string(enum rte_crypto_aead_algorithm algo_enum);
+
+/**
+ * Provide the Asymmetric xform string, given an xform enum.
+ *
+ * @param xform_enum xform type enum
+ *
+ * @return
+ * - Return NULL, if enum is not valid.
+ * - Return xform string, for valid enum.
+ */
+__rte_experimental
+const char *
+rte_cryptodev_asym_get_xform_string(enum rte_crypto_asym_xform_type xform_enum);
+
/** Macro used at end of crypto PMD list */
#define RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST() \
diff --git a/lib/cryptodev/rte_cryptodev_trace.h b/lib/cryptodev/rte_cryptodev_trace.h
index 6c214ce6ea..5e694379b1 100644
--- a/lib/cryptodev/rte_cryptodev_trace.h
+++ b/lib/cryptodev/rte_cryptodev_trace.h
@@ -189,6 +189,30 @@ RTE_TRACE_POINT(
rte_trace_point_emit_int(ret);
)
+RTE_TRACE_POINT(
+ rte_cryptodev_trace_get_aead_algo_string,
+ RTE_TRACE_POINT_ARGS(enum rte_crypto_aead_algorithm algo_enum,
+ const char *algo_string),
+ rte_trace_point_emit_int(algo_enum);
+ rte_trace_point_emit_string(algo_string);
+)
+
+RTE_TRACE_POINT(
+ rte_cryptodev_trace_get_auth_algo_string,
+ RTE_TRACE_POINT_ARGS(enum rte_crypto_auth_algorithm algo_enum,
+ const char *algo_string),
+ rte_trace_point_emit_int(algo_enum);
+ rte_trace_point_emit_string(algo_string);
+)
+
+RTE_TRACE_POINT(
+ rte_cryptodev_trace_get_cipher_algo_string,
+ RTE_TRACE_POINT_ARGS(enum rte_crypto_cipher_algorithm algo_enum,
+ const char *algo_string),
+ rte_trace_point_emit_int(algo_enum);
+ rte_trace_point_emit_string(algo_string);
+)
+
RTE_TRACE_POINT(
rte_cryptodev_trace_get_dev_id,
RTE_TRACE_POINT_ARGS(const char *name, int ret),
@@ -351,6 +375,14 @@ RTE_TRACE_POINT(
rte_trace_point_emit_int(ret);
)
+RTE_TRACE_POINT(
+ rte_cryptodev_trace_asym_get_xform_string,
+ RTE_TRACE_POINT_ARGS(enum rte_crypto_asym_xform_type xform_enum,
+ const char *xform_string),
+ rte_trace_point_emit_int(xform_enum);
+ rte_trace_point_emit_string(xform_string);
+)
+
RTE_TRACE_POINT(
rte_cryptodev_trace_asym_xform_capability_check_modlen,
RTE_TRACE_POINT_ARGS(const void *capability, uint16_t modlen, int ret),
diff --git a/lib/cryptodev/version.map b/lib/cryptodev/version.map
index 00c99fb45c..372d042931 100644
--- a/lib/cryptodev/version.map
+++ b/lib/cryptodev/version.map
@@ -150,11 +150,21 @@ EXPERIMENTAL {
__rte_cryptodev_trace_sym_session_get_user_data;
__rte_cryptodev_trace_sym_session_set_user_data;
__rte_cryptodev_trace_count;
+
+ # added 23.03
+ rte_cryptodev_asym_get_xform_string;
+ rte_cryptodev_get_aead_algo_string;
+ rte_cryptodev_get_auth_algo_string;
+ rte_cryptodev_get_cipher_algo_string;
};
INTERNAL {
global:
+ __rte_cryptodev_trace_asym_get_xform_string;
+ __rte_cryptodev_trace_get_aead_algo_string;
+ __rte_cryptodev_trace_get_auth_algo_string;
+ __rte_cryptodev_trace_get_cipher_algo_string;
cryptodev_fp_ops_reset;
cryptodev_fp_ops_set;
rte_cryptodev_allocate_driver;
--
2.25.1
^ permalink raw reply [relevance 2%]
* Re: [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API
2022-12-12 12:03 3% ` Morten Brørup
2022-12-12 12:16 3% ` Bruce Richardson
@ 2022-12-13 3:02 0% ` lihuisong (C)
1 sibling, 0 replies; 200+ results
From: lihuisong (C) @ 2022-12-13 3:02 UTC (permalink / raw)
To: Morten Brørup, Bruce Richardson
Cc: dev, ciara.power, liudongdong3, huangdaode, fengchengwen
在 2022/12/12 20:03, Morten Brørup 写道:
>> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
>> Sent: Monday, 12 December 2022 12.21
>>
>> On Mon, Dec 12, 2022 at 12:02:32PM +0100, Morten Brørup wrote:
>>>> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
>>>> Sent: Monday, 12 December 2022 11.32
>>>>
>>>> On Mon, Dec 12, 2022 at 02:42:55PM +0800, Huisong Li wrote:
>>>>> Some lib telemetry interfaces add the 'u32' and 'u64' data by the
>>>>> rte_tel_data_add_dict/array_int API. This may cause data
>> conversion
>>>> error
>>>>> or data truncation.
>>>>>
>>>>> The 'u32' data can not be assigned to signed 32-bit integer.
>> However,
>>>>> assigning to u64 is very wasteful, after all, the buffer capacity
>> of
>>>> each
>>>>> transfer is limited. So it is necessary for 'u32' data to add
>> usigned
>>>>> 32-bit integer type and a series of 'u32' operation APIs.
>>>>>
>>>>> This patchset uses the new 'u32' API to resolve the problem of
>> data
>>>>> conversion error, and use the 'u64' API to add 'u64' data.
>>>>>
>>>>> In addition, this patchset introduces two APIs to store u32 and
>> u64
>>>>> values as hexadecimal encoded strings in telemetry library.
>>>>>
>>>>> --- -v3: fix a misspelling mistake in commit log. -v2: - fix ABI
>>>> break
>>>>> warning. - introduce two APIs to store u32 and u64 values as
>>>> hexadecimal
>>>>> encoded strings.
>>>>>
>>>> I'm not convinced about adding the u32 value generically to the
>>>> telemetry
>>>> lib - except in the case of having explicit function calls for u32
>> vs
>>>> u64
>>>> hex strings. Having a u32 type doesn't gain us any space internally
>>>> over a
>>>> u64 value, since all values are in a union type. Also, for output
>> as
>>>> json,
>>>> the numeric values are all output as decimal values, meaning that
>> the
>>>> value
>>>> 1 appears as the same size in the output string whether it is a u32
>> or
>>>> u64
>>>> type. Now, it may save space in a future binary output format, but
>> even
>>>> then it still may not do so.
>>> I agree that a u32 doesn't gain any space internally.
>>>
>>> However, many SNMP counters are unsigned 32 bit, and expected to wrap
>> around as such.
>>> So I suppose the u32 type might be useful for SNMP, if obtained
>> through the telemetry library.
>>> Alternatively, we could somehow reuse the u64 type and require the
>> application to pass (value & UINT32_MAX) to the u64 functions. To make
>> this easy to use, we should add some wrappers to do it for the
>> application. And eventually we would probably end up with something
>> very similar to this patch.
>> I think just using the u64 functions is probably simplest and best
>> right
>> now. If we add support for something like snmp then yes, it would make
>> sense to explicitly add it, but it seems like a lot of extra code for
>> little or no benefit until we support something like that.
> <rant>
> If we wanted to fix this generally, we should rely on type promotion, so the existing _int function should be updated to take an int64_t value, and the _u64 function should be renamed to _uint (and still take an uint64_t value). However, that would break the ABI, and would need to go through some process for that. So let's not change this now.
> </rant>
>
> I tend to agree with Bruce on this: Let's get rid of the new u32 functions, and rely on the u64 functions for that instead.
All right. Let's drop the new u32 functions.
>
>>>> Therefore, I'd tend to keep the existing u64 type as-is, and
>> instead
>>>> only
>>>> add the functions for outputting hex values. Those hex output
>> functions
>>>> could take an additional parameter indicating the desired hex
>> output
>>>> length, as there could well be cases where we want just 16-bit hex
>>>> value
>>>> too.
>>> The way I read the patch series, the hex output length is not fixed,
>> but an u64 value of 5 will be output as 0x5, not 0x0000000000000005.
>>> So the only benefit of having both u32_hex and u64_hex functions is
>> to avoid type promotion from uint32_t to uint64_t on input for 32 bit
>> values.
>>> Instead of passing a 3rd parameter or adding u16_hex functions, we
>> could consider just having one set of hex functions using uint64_t for
>> the value, and rely on type promotion for 32 and 16 bit values.
>> +1 to having only a single hex function, and I think type promotion
>> should
>> work fine.
>>
>> However, I still think it might be worthwhile allowing the user to pass
>> in
>> a min output length parameter too. I find for many hex strings having
>> the
>> leading zeros to explicitly show the length can be useful. The value
>> "0"
>> could cover the current behaviour of no-padding, otherwise the
>> parameter
>> should indicate the number of bits to be displayed. (If we want to lock
>> it
>> down we can use an enum parameter rather than int to limit it to 0, 8,
>> 16,
>> 32 or 64 bit displayed values).
> An extra parameter for minimum output length (in number of input bits) would be very nice, and makes avoids a set of functions for each bit width.
>
> (I don't think it should be lock it down to some special bit lengths; there is no need to prevent 24 bit or other exotic bit widths.)
>
> Something like this:
>
> char str[64]; // Big enough length.
> if (bits != 0) {
> char format[16]; // Big enough length.
> sprintf(format, "0x0%u%" PRIx64, (bits + 3) / 4);
> sprintf(str, format, value);
> } else {
> sprintf(str, "0x%" PRIx64, value);
> }
Fix it in v4.
>> All that said, I'm not massively concerned if we want to just keep the
>> current approach of always just printing without any leading zeros.
>> It's a
>> nice-to-have only for me.
>>
>> /Bruce
>
> .
^ permalink raw reply [relevance 0%]
* RE: [PATCH] cryptodev: add algo enums to string conversion APIs
2022-12-12 15:10 2% [PATCH] cryptodev: add algo enums to string conversion APIs Akhil Goyal
@ 2022-12-13 7:31 0% ` Ruifeng Wang
2022-12-13 7:37 0% ` Anoob Joseph
` (3 subsequent siblings)
4 siblings, 0 replies; 200+ results
From: Ruifeng Wang @ 2022-12-13 7:31 UTC (permalink / raw)
To: Akhil Goyal, dev
Cc: ciara.power, fanzhang.oss, kai.ji, pablo.de.lara.guarch,
hemant.agrawal, matan, g.singh, anoobj, radu.nicolau, vfialko,
ktraynor, david.marchand, thomas, nd
> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Monday, December 12, 2022 11:10 PM
> To: dev@dpdk.org
> Cc: ciara.power@intel.com; fanzhang.oss@gmail.com; kai.ji@intel.com;
> pablo.de.lara.guarch@intel.com; hemant.agrawal@nxp.com; matan@nvidia.com; g.singh@nxp.com;
> Ruifeng Wang <Ruifeng.Wang@arm.com>; anoobj@marvell.com; radu.nicolau@intel.com;
> vfialko@marvell.com; ktraynor@redhat.com; david.marchand@redhat.com; thomas@monjalon.net;
> Akhil Goyal <gakhil@marvell.com>
> Subject: [PATCH] cryptodev: add algo enums to string conversion APIs
>
> Symmetric/Asymmetric algorithm strings are accessed by application using arrays in
> cryptodev lib, which hampers new algorithms addition in the array due to ABI breakage.
> These arrays are now deprecated and will be removed in next ABI break release.
> New APIs are added for getting the algorithm strings based on enum values.
>
> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> ---
> app/test-crypto-perf/cperf_options_parsing.c | 6 +-
> app/test/test_cryptodev_asym.c | 2 +-
> app/test/test_cryptodev_security_ipsec.c | 8 +-
> doc/guides/rel_notes/deprecation.rst | 7 +
> drivers/crypto/openssl/rte_openssl_pmd_ops.c | 2 +-
> drivers/crypto/qat/qat_sym_session.c | 7 +-
> examples/l2fwd-crypto/main.c | 12 +-
> lib/cryptodev/cryptodev_trace_points.c | 12 ++
> lib/cryptodev/rte_crypto_asym.h | 1 +
> lib/cryptodev/rte_crypto_sym.h | 3 +
> lib/cryptodev/rte_cryptodev.c | 182 ++++++++++++++++++-
> lib/cryptodev/rte_cryptodev.h | 52 ++++++
> lib/cryptodev/rte_cryptodev_trace.h | 32 ++++
> lib/cryptodev/version.map | 10 +
> 14 files changed, 309 insertions(+), 27 deletions(-)
>
Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
^ permalink raw reply [relevance 0%]
* RE: [PATCH] cryptodev: add algo enums to string conversion APIs
2022-12-12 15:10 2% [PATCH] cryptodev: add algo enums to string conversion APIs Akhil Goyal
2022-12-13 7:31 0% ` Ruifeng Wang
@ 2022-12-13 7:37 0% ` Anoob Joseph
2022-12-13 8:22 0% ` Power, Ciara
` (2 subsequent siblings)
4 siblings, 0 replies; 200+ results
From: Anoob Joseph @ 2022-12-13 7:37 UTC (permalink / raw)
To: Akhil Goyal, dev
Cc: ciara.power, fanzhang.oss, kai.ji, pablo.de.lara.guarch,
hemant.agrawal, matan, g.singh, ruifeng.wang, radu.nicolau,
Volodymyr Fialko, ktraynor, david.marchand, thomas, Akhil Goyal
>
> Symmetric/Asymmetric algorithm strings are accessed by application using
> arrays in cryptodev lib, which hampers new algorithms addition in the array
> due to ABI breakage.
> These arrays are now deprecated and will be removed in next ABI break
> release.
> New APIs are added for getting the algorithm strings based on enum values.
>
> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
Acked-by: Anoob Joseph <anoobj@marvell.com>
^ permalink raw reply [relevance 0%]
* RE: [PATCH] cryptodev: add algo enums to string conversion APIs
2022-12-12 15:10 2% [PATCH] cryptodev: add algo enums to string conversion APIs Akhil Goyal
2022-12-13 7:31 0% ` Ruifeng Wang
2022-12-13 7:37 0% ` Anoob Joseph
@ 2022-12-13 8:22 0% ` Power, Ciara
2022-12-14 9:32 0% ` Zhang, Fan
2023-01-04 6:18 2% ` [PATCH v2] " Akhil Goyal
4 siblings, 0 replies; 200+ results
From: Power, Ciara @ 2022-12-13 8:22 UTC (permalink / raw)
To: Akhil Goyal, dev
Cc: fanzhang.oss, Ji, Kai, De Lara Guarch, Pablo, hemant.agrawal,
matan, g.singh, ruifeng.wang, anoobj, Nicolau, Radu, vfialko,
ktraynor, david.marchand, thomas
Hi Akhil,
> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Monday 12 December 2022 15:10
> To: dev@dpdk.org
> Cc: Power, Ciara <ciara.power@intel.com>; fanzhang.oss@gmail.com; Ji, Kai
> <kai.ji@intel.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; hemant.agrawal@nxp.com;
> matan@nvidia.com; g.singh@nxp.com; ruifeng.wang@arm.com;
> anoobj@marvell.com; Nicolau, Radu <radu.nicolau@intel.com>;
> vfialko@marvell.com; ktraynor@redhat.com; david.marchand@redhat.com;
> thomas@monjalon.net; Akhil Goyal <gakhil@marvell.com>
> Subject: [PATCH] cryptodev: add algo enums to string conversion APIs
>
> Symmetric/Asymmetric algorithm strings are accessed by application using
> arrays in cryptodev lib, which hampers new algorithms addition in the array
> due to ABI breakage.
> These arrays are now deprecated and will be removed in next ABI break
> release.
> New APIs are added for getting the algorithm strings based on enum values.
>
> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> ---
<snip>
Acked-by: Ciara Power <ciara.power@intel.com>
^ permalink raw reply [relevance 0%]
* [PATCH V4 0/9] telemetry: fix data truncation and conversion error and add hex integer API
2022-12-09 11:04 3% ` [PATCH V2 00/11] telemetry: add u32 value type and hex integer string API Huisong Li
2022-12-12 6:42 3% ` [PATCH V3 " Huisong Li
@ 2022-12-13 10:15 3% ` Huisong Li
2022-12-14 12:32 3% ` [PATCH V5 0/8] " Huisong Li
` (3 subsequent siblings)
6 siblings, 0 replies; 200+ results
From: Huisong Li @ 2022-12-13 10:15 UTC (permalink / raw)
To: dev
Cc: bruce.richardson, mb, andrew.rybchenko, huangdaode, liudongdong3,
fengchengwen, lihuisong
Some lib telemetry interfaces add the 'u32' and 'u64' data by the
rte_tel_data_add_dict/array_int API. This may cause data conversion
error or data truncation. This patch series uses 'u64' functions to
do this.
In addition, this patch series introduces two APIs to store unsigned
integer values as hexadecimal encoded strings in telemetry library.
---
-v4:
- remove 'u32' value type.
- add padding zero for hexadecimal value
-v3: fix a misspelling mistake in commit log.
-v2:
- fix ABI break warning.
- introduce two APIs to store u32 and u64 values as hexadecimal
encoded strings.
Huisong Li (9):
telemetry: move to header to controllable range
ethdev: fix possible data truncation and conversion error
mempool: fix possible data truncation and conversion error
cryptodev: fix possible data conversion error
mem: possible data truncation and conversion error
telemetry: refactor mapping between value and array type
telemetry: support adding integer value as hexadecimal
test: add test cases for adding hex integer value API
ethdev: display capability values in hexadecimal format
app/test/test_telemetry_data.c | 158 +++++++++++++++++++++++++++++
lib/cryptodev/rte_cryptodev.c | 2 +-
lib/eal/common/eal_common_memory.c | 10 +-
lib/ethdev/rte_ethdev.c | 19 ++--
lib/mempool/rte_mempool.c | 24 ++---
lib/telemetry/rte_telemetry.h | 55 +++++++++-
lib/telemetry/telemetry_data.c | 86 ++++++++++++++--
lib/telemetry/version.map | 9 ++
8 files changed, 327 insertions(+), 36 deletions(-)
--
2.33.0
^ permalink raw reply [relevance 3%]
* RE: [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API
2022-12-12 12:16 3% ` Bruce Richardson
@ 2022-12-13 11:00 0% ` Morten Brørup
2022-12-13 17:12 3% ` Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Morten Brørup @ 2022-12-13 11:00 UTC (permalink / raw)
To: Bruce Richardson, Huisong Li
Cc: dev, ciara.power, liudongdong3, huangdaode, fengchengwen
Med venlig hilsen / Kind regards,
-Morten Brørup
> -----Original Message-----
> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Monday, 12 December 2022 13.16
> To: Morten Brørup
> Cc: Huisong Li; dev@dpdk.org; ciara.power@intel.com;
> liudongdong3@huawei.com; huangdaode@huawei.com; fengchengwen@huawei.com
> Subject: Re: [PATCH V3 00/11] telemetry: add u32 value type and hex
> integer string API
>
> On Mon, Dec 12, 2022 at 01:03:52PM +0100, Morten Brørup wrote:
> > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > Sent: Monday, 12 December 2022 12.21
> > >
> > > On Mon, Dec 12, 2022 at 12:02:32PM +0100, Morten Brørup wrote:
> > > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > > > Sent: Monday, 12 December 2022 11.32
> > > > >
> > > > > On Mon, Dec 12, 2022 at 02:42:55PM +0800, Huisong Li wrote:
> > > > > > Some lib telemetry interfaces add the 'u32' and 'u64' data by
> the
> > > > > > rte_tel_data_add_dict/array_int API. This may cause data
> > > conversion
> > > > > error
> > > > > > or data truncation.
> > > > > >
> > > > > > The 'u32' data can not be assigned to signed 32-bit integer.
> > > However,
> > > > > > assigning to u64 is very wasteful, after all, the buffer
> capacity
> > > of
> > > > > each
> > > > > > transfer is limited. So it is necessary for 'u32' data to add
> > > usigned
> > > > > > 32-bit integer type and a series of 'u32' operation APIs.
> > > > > >
> > > > > > This patchset uses the new 'u32' API to resolve the problem
> of
> > > data
> > > > > > conversion error, and use the 'u64' API to add 'u64' data.
> > > > > >
> > > > > > In addition, this patchset introduces two APIs to store u32
> and
> > > u64
> > > > > > values as hexadecimal encoded strings in telemetry library.
> > > > > >
> > > > > > --- -v3: fix a misspelling mistake in commit log. -v2: - fix
> ABI
> > > > > break
> > > > > > warning. - introduce two APIs to store u32 and u64 values as
> > > > > hexadecimal
> > > > > > encoded strings.
> > > > > >
> > > > > I'm not convinced about adding the u32 value generically to the
> > > > > telemetry
> > > > > lib - except in the case of having explicit function calls for
> u32
> > > vs
> > > > > u64
> > > > > hex strings. Having a u32 type doesn't gain us any space
> internally
> > > > > over a
> > > > > u64 value, since all values are in a union type. Also, for
> output
> > > as
> > > > > json,
> > > > > the numeric values are all output as decimal values, meaning
> that
> > > the
> > > > > value
> > > > > 1 appears as the same size in the output string whether it is a
> u32
> > > or
> > > > > u64
> > > > > type. Now, it may save space in a future binary output format,
> but
> > > even
> > > > > then it still may not do so.
> > > >
> > > > I agree that a u32 doesn't gain any space internally.
> > > >
> > > > However, many SNMP counters are unsigned 32 bit, and expected to
> wrap
> > > around as such.
> > > >
> > > > So I suppose the u32 type might be useful for SNMP, if obtained
> > > through the telemetry library.
> > > >
> > > > Alternatively, we could somehow reuse the u64 type and require
> the
> > > application to pass (value & UINT32_MAX) to the u64 functions. To
> make
> > > this easy to use, we should add some wrappers to do it for the
> > > application. And eventually we would probably end up with something
> > > very similar to this patch.
> > > >
> > >
> > > I think just using the u64 functions is probably simplest and best
> > > right
> > > now. If we add support for something like snmp then yes, it would
> make
> > > sense to explicitly add it, but it seems like a lot of extra code
> for
> > > little or no benefit until we support something like that.
> >
> > <rant>
> > If we wanted to fix this generally, we should rely on type promotion,
> so the existing _int function should be updated to take an int64_t
> value, and the _u64 function should be renamed to _uint (and still take
> an uint64_t value). However, that would break the ABI, and would need
> to go through some process for that. So let's not change this now.
> > </rant>
>
> Yes, not making "int" an "i64" type was a poor design decision on my
> part
> in the earlier versions. Thankfully negative values are rarely needed
> beyond the range of 32-bits, but we should probably look to update this
> as
> you suggest at the next ABI break window.
>
> >
> > I tend to agree with Bruce on this: Let's get rid of the new u32
> functions, and rely on the u64 functions for that instead.
> >
> > >
> > > > >
> > > > > Therefore, I'd tend to keep the existing u64 type as-is, and
> > > instead
> > > > > only
> > > > > add the functions for outputting hex values. Those hex output
> > > functions
> > > > > could take an additional parameter indicating the desired hex
> > > output
> > > > > length, as there could well be cases where we want just 16-bit
> hex
> > > > > value
> > > > > too.
> > > >
> > > > The way I read the patch series, the hex output length is not
> fixed,
> > > but an u64 value of 5 will be output as 0x5, not
> 0x0000000000000005.
> > > >
> > > > So the only benefit of having both u32_hex and u64_hex functions
> is
> > > to avoid type promotion from uint32_t to uint64_t on input for 32
> bit
> > > values.
> > > >
> > > > Instead of passing a 3rd parameter or adding u16_hex functions,
> we
> > > could consider just having one set of hex functions using uint64_t
> for
> > > the value, and rely on type promotion for 32 and 16 bit values.
> > > >
> > >
> > > +1 to having only a single hex function, and I think type promotion
> > > should
> > > work fine.
> > >
> > > However, I still think it might be worthwhile allowing the user to
> pass
> > > in
> > > a min output length parameter too. I find for many hex strings
> having
> > > the
> > > leading zeros to explicitly show the length can be useful. The
> value
> > > "0"
> > > could cover the current behaviour of no-padding, otherwise the
> > > parameter
> > > should indicate the number of bits to be displayed. (If we want to
> lock
> > > it
> > > down we can use an enum parameter rather than int to limit it to 0,
> 8,
> > > 16,
> > > 32 or 64 bit displayed values).
> >
> > An extra parameter for minimum output length (in number of input
> bits) would be very nice, and makes avoids a set of functions for each
> bit width.
> >
> > (I don't think it should be lock it down to some special bit lengths;
> there is no need to prevent 24 bit or other exotic bit widths.)
> >
> > Something like this:
> >
> > char str[64]; // Big enough length.
> > if (bits != 0) {
> > char format[16]; // Big enough length.
> > sprintf(format, "0x0%u%" PRIx64, (bits + 3) / 4);
> > sprintf(str, format, value);
> > } else {
> > sprintf(str, "0x%" PRIx64, value);
> > }
> >
>
> LGTM.
From a higher level perspective, I'm wondering why passing an uint32_t as x to rte_tel_data_add_{dict|array}_int(struct rte_tel_data *d, int x) doesn't produce a compiler warning about risky type conversion. And similarly passing a signed value to the _u64 functions.
Wouldn't it make sense to wrap these functions in a macro, so -Wconversion could be enabled when they are used? (I guess -Wconversion is default disabled when building DPDK.)
-Morten
^ permalink raw reply [relevance 0%]
* Re: 21.11.3 patches review and test
2022-12-06 11:29 1% 21.11.3 patches review and test Kevin Traynor
@ 2022-12-13 11:48 0% ` Christian Ehrhardt
2022-12-16 7:55 0% ` YangHang Liu
1 sibling, 0 replies; 200+ results
From: Christian Ehrhardt @ 2022-12-13 11:48 UTC (permalink / raw)
To: Kevin Traynor
Cc: stable, dev, Abhishek Marathe, Ali Alnubani, benjamin.walker,
David Christensen, Hemant Agrawal, Ian Stokes, Jerin Jacob,
John McNamara, Ju-Hyoung Lee, Luca Boccassi, Pei Zhang,
qian.q.xu, Raslan Darawsheh, Thomas Monjalon, yanghliu,
yuan.peng, zhaoyan.chen
On Tue, Dec 6, 2022 at 12:30 PM Kevin Traynor <ktraynor@redhat.com> wrote:
>
> Hi all,
>
> Here is a list of patches targeted for stable release 21.11.3.
>
> The planned date for the final release is 19th December.
>
> Please help with testing and validation of your use cases and report
> any issues/results with reply-all to this mail. For the final release
> the fixes and reported validations will be added to the release notes.
>
> A release candidate tarball can be found at:
>
> https://dpdk.org/browse/dpdk-stable/tag/?id=v21.11.3-rc1
>
> These patches are located at branch 21.11 of dpdk-stable repo:
> https://dpdk.org/browse/dpdk-stable/
Hi Kevin,
testing 22.11.3 builds and a bunch of workloads and stressing things
under Ubuntu 22.04.
TL;DR: for what I ran all LGTM, no regressions found (but I only have
a small subset of HW and use cases, I hope others will reply as well
later this week).
V: 21.11.3~rc1-0ubuntu0.22.04.1~jammyppa1
1.0.0 (08:19:13): phys (BM) tests
1.1.0 (08:19:13): initialize environment
1.1.1 (08:21:02): testpmd => Pass
1.1.2 (08:23:07): check testpmd output => Pass
2.0.0 (08:23:07): prep virtual test environment
1.0.0 (08:25:37): virt tests
1.1.0 (08:25:37): initialize environment
3.0.0 (08:27:02): performance tests
3.1.0 (08:27:02): prep benchmarks
3.2.0 (08:27:24): performance tests
3.2.1 (08:27:32): test guest-openvswitch for OVS-5CPU => Pass
3.2.2 (08:46:45): test guest-dpdk-vhost-user-client-multiq for
OVSDPDK-VUC => Pass
4.0.0 (09:06:10): VUC endurance checks
4.1.0 (09:06:10): prep VUC endurance tests
4.1.1 (09:18:48): start stop guests (client) => Pass
4.1.2 (10:31:22): add/remove ports (client) => Pass
4.2.0 (10:40:52): Final cleanup
> Thanks.
>
> Kevin
>
> ---
> Abdullah Sevincer (1):
> event/dlb2: handle enqueuing more than maximum depth
>
> Abhimanyu Saini (1):
> common/sfc_efx/base: remove VQ index check during VQ start
>
> Aleksandr Miloshenko (1):
> net/iavf: fix Tx done descriptors cleanup
>
> Alex Kiselev (1):
> net/tap: fix overflow of network interface index
>
> Alexander Chernavin (1):
> net/virtio: fix crash when configured twice
>
> Alexander Kozyrev (3):
> net/mlx5: fix shared Rx queue config reuse
> net/mlx5: fix first segment inline length
> net/mlx5: fix indexed pool local cache crash
>
> Ali Alnubani (1):
> examples/l2fwd-crypto: fix typo in error message
>
> Amit Prakash Shukla (6):
> net/mvneta: fix build with GCC 12
> test/ipsec: fix build with GCC 12
> ipsec: fix build with GCC 12
> crypto/qat: fix build with GCC 12
> net/i40e: fix build with MinGW GCC 12
> net/qede/base: fix 32-bit build with GCC 12
>
> Andrew Boyer (5):
> net/ionic: fix endianness for Rx and Tx
> net/ionic: fix endianness for RSS
> net/ionic: fix adapter name for logging
> net/ionic: fix Rx filter save
> net/ionic: fix reported error stats
>
> Anoob Joseph (1):
> test/crypto: fix PDCP vectors
>
> Apeksha Gupta (2):
> net/enetfec: fix restart
> net/enetfec: fix buffer leak
>
> Arek Kusztal (1):
> common/qat: fix VF to PF answer
>
> Ashwin Sekhar T K (1):
> mempool/cnxk: fix destroying empty pool
>
> Ben Magistro (1):
> doc: fix dumpcap interface parameter option
>
> Benjamin Le Berre (1):
> net/bnxt: fix error code during MTU change
>
> Bhagyada Modali (9):
> net/axgbe: fix scattered Rx
> net/axgbe: fix mbuf lengths in scattered Rx
> net/axgbe: fix length of each segment in scattered Rx
> net/axgbe: fix checksum and RSS in scattered Rx
> net/axgbe: optimise scattered Rx
> net/axgbe: remove freeing buffer in scattered Rx
> net/axgbe: reset end of packet in scattered Rx
> net/axgbe: clear buffer on scattered Rx chaining failure
> net/axgbe: save segment data in scattered Rx
>
> Bing Zhao (2):
> net/mlx5: fix build with recent compilers
> bus/auxiliary: prevent device from being probed again
>
> Brian Dooley (1):
> crypto/qat: fix null hash algorithm digest size
>
> Changpeng Liu (1):
> vhost: add non-blocking API for posting interrupt
>
> Chaoyong He (1):
> net/nfp: fix Rx descriptor DMA address
>
> Chengwen Feng (8):
> net/hns3: fix crash in SVE Tx
> net/hns3: fix next-to-use overflow in SVE Tx
> net/hns3: fix next-to-use overflow in simple Tx
> net/hns3: fix crash when secondary process access FW
> net/hns3: revert Tx performance optimization
> net/hns3: revert fix mailbox communication with HW
> net/hns3: fix VF mailbox message handling
> app/testpmd: remove jumbo offload
>
> Ciara Power (1):
> test/crypto: fix wireless auth digest segment
>
> Conor Walsh (1):
> doc: fix reference to dma application example
>
> Dariusz Sosnowski (1):
> net/mlx5: fix hairpin split with set VLAN VID action
>
> David Marchand (23):
> vhost: fix virtqueue use after free on NUMA reallocation
> app/testpmd: restore ixgbe bypass commands
> net/failsafe: fix interrupt handle leak
> net/bnxt: fix build with GCC 13
> trace: fix mode for new trace point
> trace: fix mode change
> trace: fix leak with regexp
> trace: fix dynamically enabling trace points
> trace: fix race in debug dump
> ci: bump versions of actions in GHA
> ci: update to new API for step outputs in GHA
> service: fix build with clang 15
> vhost: fix build with clang 15
> bus/dpaa: fix build with clang 15
> net/atlantic: fix build with clang 15
> net/dpaa2: fix build with clang 15
> app/testpmd: fix build with clang 15
> app/testpmd: fix build with clang 15 in flow code
> test/efd: fix build with clang 15
> test/member: fix build with clang 15
> test/event: fix build with clang 15
> ci: enable ABI check in GHA
> trace: fix metadata dump
>
> Dmitry Kozlyuk (4):
> build: enable developer mode for all working trees
> eal: fix side effect in some pointer arithmetic macros
> mempool: make event callbacks process-private
> common/mlx5: fix multi-process mempool registration
>
> Dong Zhou (1):
> net/mlx5: fix thread workspace memory leak
>
> Dongdong Liu (2):
> doc: fix application name in procinfo guide
> doc: document device dump in procinfo guide
>
> Erik Gabriel Carrillo (1):
> service: fix early move to inactive status
>
> Fidaullah Noonari (1):
> malloc: fix storage size for some allocations
>
> Frank Du (1):
> net/ice: fix interrupt handler unregister
>
> Gagandeep Singh (5):
> net/dpaa: fix buffer freeing in slow path
> net/dpaa: use internal mempool for SG table
> net/dpaa: fix buffer freeing on SG Tx
> net/dpaa2: use internal mempool for SG table
> net/dpaa2: fix buffer freeing on SG Tx
>
> Ganapati Kundapura (1):
> eventdev/crypto: fix multi-process
>
> Gregory Etelson (6):
> net/mlx5: fix RSS expansion buffer size
> app/testpmd: fix MAC header in checksum forward engine
> common/mlx5: fix shared mempool subscription
> net/mlx5: fix port initialization with small LRO
> net/mlx5: fix maximum LRO message size
> doc: add LRO size limitation in mlx5 guide
>
> Haiyue Wang (1):
> ring: fix description
>
> Hamza Khan (1):
> examples/vm_power_manager: use safe list iterator
>
> Hanumanth Pothula (1):
> net/cnxk: fix DF bit in vector mode
>
> Hernan Vargas (14):
> baseband/acc100: fix memory leak
> baseband/acc100: check turbo dec/enc input
> baseband/acc100: add null checks
> baseband/acc100: fix input length for CRC24B
> baseband/acc100: fix clearing PF IR outside handler
> baseband/acc100: fix device minimum alignment
> baseband/acc100: fix close cleanup
> baseband/acc100: add LDPC encoder padding function
> baseband/acc100: check AQ availability
> baseband/acc100: fix ring availability calculation
> baseband/acc100: enforce additional check on FCW
> baseband/acc100: fix null HARQ input case
> baseband/acc100: fix ring/queue allocation
> baseband/acc100: fix double MSI intr in TB mode
>
> Huisong Li (18):
> net/hns3: fix Rx with PTP
> net/hns3: delete unused markup
> net/hns3: fix clearing hardware MAC statistics
> net/hns3: fix RSS filter restore
> net/hns3: fix RSS flow rule restore
> net/hns3: move flow direction rule recovery
> net/hns3: fix packet type for GENEVE
> net/hns3: fix IPv4 and IPv6 RSS
> net/hns3: fix typos in IPv6 SCTP fields
> net/hns3: fix IPv4 RSS
> net/hns3: add L3 and L4 RSS types
> net/bonding: fix slave device Rx/Tx offload configuration
> net/bonding: fix dropping valid MAC packets
> net/bonding: fix mbuf fast free handling
> net/hns3: extract functions to create RSS and FDIR flow rule
> net/hns3: fix RSS rule restore
> net/hns3: fix lock protection of RSS flow rule
> net/hns3: fix restore filter function input
>
> Huzaifa Rahman (1):
> net/memif: fix crash with different number of Rx/Tx queues
>
> Ilya Maximets (1):
> doc: fix support table for Ethernet/VLAN flow items
>
> Ivan Malov (3):
> common/sfc_efx/base: fix maximum Tx data count
> net/bonding: fix descriptor limit reporting
> net/bonding: fix flow flush order on close
>
> James Hershaw (1):
> net/nfp: improve HW info header log readability
>
> Jeremy Spewock (1):
> test/ipsec: skip if no compatible device
>
> Jerin Jacob (2):
> eal: fix doxygen comments for UUID
> power: fix some doxygen comments
>
> Jiawei Wang (4):
> net/mlx5: fix modify action with tunnel decapsulation
> net/mlx5: fix tunnel header with IPIP offload
> net/mlx5: fix source port checking in sample flow rule
> net/mlx5: fix mirror flow validation with ASO action
>
> Jiawen Wu (6):
> net/txgbe: fix IPv6 flow rule
> net/txgbe: remove semaphore between SW/FW
> net/txgbe: rename some extended statistics
> net/ngbe: rename some extended statistics
> net/ngbe: remove semaphore between SW/FW
> net/ngbe: fix maximum frame size
>
> Jie Hai (1):
> net/hns3: fix minimum Tx frame length
>
> Jie Wang (1):
> net/i40e: fix jumbo frame Rx with X722
>
> Jun Qiu (3):
> gro: trim tail padding bytes
> net/bonding: fix Tx hash for TCP
> hash: fix RCU configuration memory leak
>
> Kai Ji (1):
> test/crypto: fix bitwise operator in a SNOW3G case
>
> Kalesh AP (2):
> net/bnxt: remove unnecessary check
> net/bnxt: fix representor info freeing
>
> Ke Zhang (2):
> net/i40e: fix VF representor release
> net/iavf: fix L3 checksum Tx offload flag
>
> Kevin Liu (2):
> net/iavf: check illegal packet sizes
> net/ice: check illegal packet sizes
>
> Kevin Traynor (1):
> Revert "cryptodev: fix missing SHA3 algorithm strings"
>
> Kumara Parameshwaran (1):
> gro: check payload length after trim
>
> Long Li (2):
> net/mlx4: fix Verbs FD leak in secondary process
> net/mlx5: fix Verbs FD leak in secondary process
>
> Long Wu (1):
> net/nfp: fix memory leak in Rx
>
> Luca Boccassi (1):
> drivers: fix typos found by Lintian
>
> Mao YingMing (1):
> net/bnxt: fix null pointer dereference in LED config
>
> Mattias Rönnblom (3):
> net: accept unaligned data in checksum routines
> event/dsw: fix flow migration
> doc: fix event timer adapter guide
>
> Maxime Coquelin (1):
> vhost: fix build with GCC 12
>
> Megha Ajmera (2):
> sched: fix subport profile configuration
> examples/qos_sched: fix number of subport profiles
>
> Michael Baum (5):
> net/mlx5: fix null check in devargs parsing
> doc: fix underlines in testpmd guide
> doc: fix colons in testpmd aged flow rules
> net/mlx5: fix race condition in counter pool resizing
> net/mlx5: fix port event cleaning order
>
> Mingjin Ye (4):
> net/ice: support VXLAN-GPE tunnel offload
> net/i40e: fix pctype configuration for X722
> net/ice: fix scalar Rx path segment
> net/ice: fix scalar Tx path segment
>
> Mário Kuka (1):
> pcapng: fix write more packets than IOV_MAX limit
>
> Naga Harish K S V (4):
> eventdev/eth_tx: add spinlock for adapter start/stop
> eventdev/eth_tx: fix adapter stop
> timer: fix stopping all timers
> eventdev/eth_tx: fix queue delete
>
> Nithin Dabilpuram (3):
> examples/ipsec-secgw: use Tx checksum offload conditionally
> examples/l3fwd: fix MTU configuration with event mode
> net/cnxk: fix later skip to include mbuf private data
>
> Olivier Matz (7):
> cryptodev: fix unduly newlines in logs
> mem: fix API doc about allocation on secondary processes
> event/sw: fix flow ID init in self test
> event/sw: fix log in self test
> net/ixgbe: fix broadcast Rx on VF after promisc removal
> net/ixgbe: fix unexpected VLAN Rx in promisc mode on VF
> net/ixgbevf: fix promiscuous and allmulti
>
> Pablo de Lara (1):
> examples/fips_validation: fix typo in error log
>
> Pavan Nikhilesh (3):
> event/cnxk: fix missing xstats operations
> event/cnxk: fix mbuf offset calculation
> event/cnxk: fix missing mempool cookie marking
>
> Peng Zhang (3):
> net/nfp: compose firmware file name with new hwinfo
> buildtools: fix NUMA nodes count
> net/nfp: fix internal buffer size and MTU check
>
> Qi Zhang (12):
> net/ice/base: fix division during E822 PTP init
> net/ice/base: fix 100M speed capability
> net/ice/base: fix DSCP PFC TLV creation
> net/ice/base: fix media type of PHY 10G SFI C2C
> net/ice/base: fix function descriptions for parser
> net/ice/base: fix endian format
> net/ice/base: fix array overflow in add switch recipe
> net/ice/base: fix bit finding range over ptype bitmap
> net/ice/base: fix add MAC rule
> net/ice/base: fix double VLAN in promiscuous mode
> net/ice/base: ignore promiscuous already exist
> net/ice/base: fix input set of GTPoGRE
>
> Qiming Yang (1):
> app/testpmd: skip port reset in secondary process
>
> Radu Nicolau (5):
> net/iavf: update IPsec ESN values when updating session
> net/iavf: fix IPsec flow create error check
> net/iavf: fix SPI check
> net/iavf: fix queue stop for large VF
> examples/ipsec-secgw: fix Tx checksum offload flag
>
> Raja Zidane (1):
> net/mlx5: fix Tx check for hardware descriptor length
>
> Rohit Raj (1):
> net/dpaa: fix jumbo packet Rx in case of VSP
>
> Satha Rao (1):
> common/cnxk: fix schedule weight update
>
> Satheesh Paul (3):
> common/cnxk: fix log level during MCAM allocation
> common/cnxk: fix missing flow counter reset
> common/cnxk: fix printing disabled MKEX registers
>
> Shiqi Liu (2):
> node: check Rx element allocation
> dma/idxd: check DSA device allocation
>
> Shun Hao (4):
> net/mlx5: fix meter profile delete after disable
> net/mlx5: fix action flag data type
> net/mlx5: fix drop action validation
> net/mlx5: fix assert when creating meter policy
>
> Stephen Coleman (1):
> doc: fix typo depreciated instead of deprecated
>
> Stephen Hemminger (8):
> event/sw: fix device name in dump
> eal: fix data race in multi-process support
> pdump: do not allow enable/disable in primary process
> app/dumpcap: fix crash on cleanup
> app/dumpcap: fix pathname for output file
> app/testpmd: make quit flag volatile
> ring: remove leftover comment about watermark
> doc: avoid meson deprecation in setup
>
> Steve Yang (1):
> net/iavf: fix pattern check for flow director parser
>
> Steven Zou (1):
> common/iavf: avoid copy in async mode
>
> Sunyang Wu (1):
> test/crypto: fix debug messages
>
> Taekyung Kim (1):
> vdpa/ifc: handle data path update failure
>
> Tal Shnaiderman (1):
> net/mlx5: fix thread termination check on Windows
>
> Thomas Monjalon (2):
> drivers: remove unused build variable
> doc: add Rx buffer split capability for mlx5
>
> Ting Xu (1):
> net/ice/base: fix inner symmetric RSS hash in raw flow
>
> Tomasz Jonak (1):
> net/ice: fix null function pointer call
>
> Vanshika Shukla (1):
> net/dpaa2: fix DPDMUX error behaviour
>
> Viacheslav Ovsiienko (3):
> net/mlx5: fix check for orphan wait descriptor
> net/mlx5: fix single not inline packet storing
> net/mlx5: fix inline length exceeding descriptor limit
>
> Vladimir Medvedkin (2):
> test/hash: remove dead code in extendable bucket test
> test/hash: fix bulk lookup check
>
> Volodymyr Fialko (3):
> cryptodev: fix missing SHA3 algorithm strings
> eventdev: fix name of Rx conf type in documentation
> app/eventdev: fix limits in error message
>
> Wenwu Ma (1):
> examples/vhost: fix use after free
>
> Wenzhuo Lu (1):
> net/iavf: fix VLAN offload
>
> Yi Li (1):
> doc: fix maximum packet size of virtio driver
>
> Yiding Zhou (4):
> net/iavf: fix VLAN insertion
> net/iavf: revert VLAN insertion fix
> net/ice/base: fix duplicate flow rules
> net/iavf: add thread for event callbacks
>
> Yunjian Wang (2):
> net/bonding: fix array overflow in Rx burst
> net/bonding: fix double slave link status query
>
> Zhichao Zeng (3):
> net/ice: fix RSS hash update
> net/iavf: fix processing VLAN TCI in SSE path
> net/iavf: fix outer checksum flags
>
> Zhirun Yan (1):
> graph: fix node objects allocation
>
--
Christian Ehrhardt
Senior Staff Engineer, Ubuntu Server
Canonical Ltd
^ permalink raw reply [relevance 0%]
* [PATCH] ci: drop Travis configuration
@ 2022-12-13 15:07 3% David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2022-12-13 15:07 UTC (permalink / raw)
To: dev; +Cc: Honnappa.Nagarahalli, thomas, Aaron Conole, Michael Santana
We stopped using Travis in the main branch and in the public CI in favor
of GHA more than a year ago.
The UNH community lab now covers testing native compilation and unit
tests for ARM platforms.
We decided to stop maintaining the configuration in our repository with
the argument that "if it is not tested, it is broken".
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
.ci/linux-build.sh | 19 ---
.travis.yml | 172 ----------------------------
MAINTAINERS | 1 -
devtools/check-spdx-tag.sh | 2 +-
doc/guides/contributing/patches.rst | 4 -
5 files changed, 1 insertion(+), 197 deletions(-)
delete mode 100644 .travis.yml
diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
index 5225dc71c4..ab0994388a 100755
--- a/.ci/linux-build.sh
+++ b/.ci/linux-build.sh
@@ -9,25 +9,6 @@ fi
# Builds are run as root in containers, no need for sudo
[ "$(id -u)" != '0' ] || alias sudo=
-on_error() {
- if [ $? = 0 ]; then
- exit
- fi
- FILES_TO_PRINT="build/meson-logs/testlog.txt"
- FILES_TO_PRINT="$FILES_TO_PRINT build/.ninja_log"
- FILES_TO_PRINT="$FILES_TO_PRINT build/meson-logs/meson-log.txt"
- FILES_TO_PRINT="$FILES_TO_PRINT build/gdb.log"
-
- for pr_file in $FILES_TO_PRINT; do
- if [ -e "$pr_file" ]; then
- cat "$pr_file"
- fi
- done
-}
-# We capture the error logs as artifacts in Github Actions, no need to dump
-# them via a EXIT handler.
-[ -n "$GITHUB_WORKFLOW" ] || trap on_error EXIT
-
install_libabigail() {
version=$1
instdir=$2
diff --git a/.travis.yml b/.travis.yml
deleted file mode 100644
index 0936788dc7..0000000000
--- a/.travis.yml
+++ /dev/null
@@ -1,172 +0,0 @@
-# default values for all jobs
-language: c
-cache:
- ccache: true
- directories:
- - libabigail
- - reference
-
-dist: bionic
-
-os: linux
-
-addons:
- apt:
- update: true
- packages: &required_packages
- - [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]
-
-_aarch64_packages: &aarch64_packages
- - *required_packages
- - [gcc-aarch64-linux-gnu, libc6-dev-arm64-cross, pkg-config-aarch64-linux-gnu]
-
-_aarch64_clang_packages: &aarch64_clang_packages
- - *required_packages
- - [libgcc-7-dev-arm64-cross, libatomic1-arm64-cross, libc6-dev-arm64-cross, pkg-config-aarch64-linux-gnu]
-
-_libabigail_build_packages: &libabigail_build_packages
- - [autoconf, automake, libtool, pkg-config, libxml2-dev, libdw-dev]
-
-_build_32b_packages: &build_32b_packages
- - *required_packages
- - [gcc-multilib]
-
-_doc_packages: &doc_packages
- - [doxygen, graphviz, python3-sphinx]
-
-before_install: ./.ci/${TRAVIS_OS_NAME}-setup.sh
-script: ./.ci/${TRAVIS_OS_NAME}-build.sh
-
-env:
- global:
- - LIBABIGAIL_VERSION=libabigail-2.1
- - REF_GIT_REPO=https://dpdk.org/git/dpdk-stable
- - REF_GIT_TAG=v22.11.1
-
-jobs:
- include:
- # x86_64 gcc jobs
- - env: DEF_LIB="static"
- arch: amd64
- compiler: gcc
- - env: DEF_LIB="shared" RUN_TESTS=true
- arch: amd64
- compiler: gcc
- - env: DEF_LIB="shared" BUILD_DOCS=true
- arch: amd64
- compiler: gcc
- addons:
- apt:
- packages:
- - *required_packages
- - *doc_packages
- - env: DEF_LIB="shared" ABI_CHECKS=true
- arch: amd64
- compiler: gcc
- addons:
- apt:
- packages:
- - *required_packages
- - *libabigail_build_packages
- # x86_64 clang jobs
- - env: DEF_LIB="static"
- arch: amd64
- compiler: clang
- - env: DEF_LIB="shared" RUN_TESTS=true
- arch: amd64
- compiler: clang
- - env: DEF_LIB="shared" BUILD_DOCS=true
- arch: amd64
- compiler: clang
- addons:
- apt:
- packages:
- - *required_packages
- - *doc_packages
- # x86_64 cross-compiling 32-bits jobs
- - env: DEF_LIB="static" BUILD_32BIT=true
- arch: amd64
- compiler: gcc
- addons:
- apt:
- packages:
- - *build_32b_packages
- # x86_64 cross-compiling aarch64 jobs
- - env: DEF_LIB="static" AARCH64=true
- arch: amd64
- compiler: gcc
- addons:
- apt:
- packages:
- - *aarch64_packages
- - env: DEF_LIB="shared" AARCH64=true
- arch: amd64
- compiler: gcc
- addons:
- apt:
- packages:
- - *aarch64_packages
- - env: DEF_LIB="static" AARCH64=true
- arch: amd64
- compiler: clang
- addons:
- apt:
- packages:
- - *aarch64_clang_packages
- - env: DEF_LIB="shared" AARCH64=true
- arch: amd64
- compiler: clang
- addons:
- apt:
- packages:
- - *aarch64_clang_packages
- # aarch64 gcc jobs
- - env: DEF_LIB="static"
- dist: focal
- arch: arm64-graviton2
- virt: vm
- group: edge
- compiler: gcc
- - env: DEF_LIB="shared" RUN_TESTS=true
- dist: focal
- arch: arm64-graviton2
- virt: vm
- group: edge
- compiler: gcc
- - env: DEF_LIB="shared" BUILD_DOCS=true
- dist: focal
- arch: arm64-graviton2
- virt: vm
- group: edge
- compiler: gcc
- addons:
- apt:
- packages:
- - *required_packages
- - *doc_packages
- - env: DEF_LIB="shared" ABI_CHECKS=true
- dist: focal
- arch: arm64-graviton2
- virt: vm
- group: edge
- compiler: gcc
- addons:
- apt:
- packages:
- - *required_packages
- - *libabigail_build_packages
- # aarch64 clang jobs
- - env: DEF_LIB="static"
- dist: focal
- arch: arm64-graviton2
- virt: vm
- group: edge
- compiler: clang
- - env: DEF_LIB="shared" RUN_TESTS=true
- dist: focal
- arch: arm64-graviton2
- virt: vm
- group: edge
- compiler: clang
diff --git a/MAINTAINERS b/MAINTAINERS
index 3dc3f5b348..9a0f416d2e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -131,7 +131,6 @@ F: devtools/check-meson.py
Public CI
M: Aaron Conole <aconole@redhat.com>
M: Michael Santana <maicolgabriel@hotmail.com>
-F: .travis.yml
F: .github/workflows/build.yml
F: .ci/
diff --git a/devtools/check-spdx-tag.sh b/devtools/check-spdx-tag.sh
index 89b2d643a4..7624778a8c 100755
--- a/devtools/check-spdx-tag.sh
+++ b/devtools/check-spdx-tag.sh
@@ -20,7 +20,7 @@ check_spdx() {
echo "--------------------------"
fi
git grep -L SPDX-License-Identifier -- \
- ':^.git*' ':^.mailmap' ':^.ci/*' ':^.travis.yml' \
+ ':^.git*' ':^.mailmap' ':^.ci/*' \
':^README' ':^MAINTAINERS' ':^VERSION' ':^ABI_VERSION' \
':^*/Kbuild' ':^*/README' \
':^license/' ':^config/' ':^buildtools/' ':^*/poetry.lock' \
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index b3eaf7df03..e286d9e6d5 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -35,10 +35,6 @@ It is also worth registering for the DPDK `Patchwork <https://patches.dpdk.org/p
If you are using the GitHub service, pushing to a branch will trigger GitHub
Actions to automatically build your changes and run unit tests and ABI checks.
-Additionally, a Travis configuration is available in DPDK but Travis free usage
-is limited to a few builds.
-You can link your repository to the ``travis-ci.com`` build service.
-
The development process requires some familiarity with the ``git`` version control system.
Refer to the `Pro Git Book <http://www.git-scm.com/book/>`_ for further information.
--
2.38.1
^ permalink raw reply [relevance 3%]
* Re: [PATCH 2/4] eal: allow applications to report their cpu usage
@ 2022-12-13 15:49 3% ` Robin Jarry
2022-12-13 16:39 0% ` Morten Brørup
2022-12-13 17:45 0% ` Tyler Retzlaff
0 siblings, 2 replies; 200+ results
From: Robin Jarry @ 2022-12-13 15:49 UTC (permalink / raw)
To: dev; +Cc: Morten Brørup, Kevin Laatz
Robin Jarry, Dec 07, 2022 at 17:21:
> Allow applications to register a callback that will be invoked in
> rte_lcore_dump() and when requesting lcore info in the telemetry API.
>
> The callback is expected to return the number of TSC cycles that have
> passed since application start and the number of these cycles that were
> spent doing busy work.
>
> Signed-off-by: Robin Jarry <rjarry@redhat.com>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> ---
> v3 -> v4: Changed nomenclature: CPU cycles -> TSC cycles
As you may have noticed, I forgot to add -v4 for that iteration...
> diff --git a/lib/eal/include/rte_lcore.h b/lib/eal/include/rte_lcore.h
> index 6938c3fd7b81..df7f0a8e07c6 100644
> --- a/lib/eal/include/rte_lcore.h
> +++ b/lib/eal/include/rte_lcore.h
> @@ -328,6 +328,35 @@ typedef int (*rte_lcore_iterate_cb)(unsigned int lcore_id, void *arg);
> int
> rte_lcore_iterate(rte_lcore_iterate_cb cb, void *arg);
>
> +/**
> + * Callback to allow applications to report CPU usage.
> + *
> + * @param [in] lcore_id
> + * The lcore to consider.
> + * @param [out] busy_cycles
> + * The amount of busy time since application start, in TSC cycles.
> + * @param [out] total_cycles
> + * The total amount of time since application start, in TSC cycles.
> + * @return
> + * - 0 if both busy and total were set correctly.
> + * - a negative value if the information is not available or if any error occurred.
> + */
> +typedef int (*rte_lcore_usage_cb)(
> + unsigned int lcore_id, uint64_t *busy_cycles, uint64_t *total_cycles);
Instead of two uint64_t pointers, I was thinking a better approach would
be to pass a pointer to a struct containing these two fields. That way
it leaves room for adding more counters if need be. And do so without
breaking the ABI.
Thoughts?
^ permalink raw reply [relevance 3%]
* RE: [PATCH 2/4] eal: allow applications to report their cpu usage
2022-12-13 15:49 3% ` Robin Jarry
@ 2022-12-13 16:39 0% ` Morten Brørup
2022-12-13 17:45 0% ` Tyler Retzlaff
1 sibling, 0 replies; 200+ results
From: Morten Brørup @ 2022-12-13 16:39 UTC (permalink / raw)
To: Robin Jarry, dev; +Cc: Kevin Laatz, mattias.ronnblom
> From: Robin Jarry [mailto:rjarry@redhat.com]
> Sent: Tuesday, 13 December 2022 16.50
>
> Robin Jarry, Dec 07, 2022 at 17:21:
> > Allow applications to register a callback that will be invoked in
> > rte_lcore_dump() and when requesting lcore info in the telemetry API.
> >
> > The callback is expected to return the number of TSC cycles that have
> > passed since application start and the number of these cycles that
> were
> > spent doing busy work.
> >
> > Signed-off-by: Robin Jarry <rjarry@redhat.com>
> > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > ---
> > v3 -> v4: Changed nomenclature: CPU cycles -> TSC cycles
>
> As you may have noticed, I forgot to add -v4 for that iteration...
>
> > diff --git a/lib/eal/include/rte_lcore.h
> b/lib/eal/include/rte_lcore.h
> > index 6938c3fd7b81..df7f0a8e07c6 100644
> > --- a/lib/eal/include/rte_lcore.h
> > +++ b/lib/eal/include/rte_lcore.h
> > @@ -328,6 +328,35 @@ typedef int (*rte_lcore_iterate_cb)(unsigned int
> lcore_id, void *arg);
> > int
> > rte_lcore_iterate(rte_lcore_iterate_cb cb, void *arg);
> >
> > +/**
> > + * Callback to allow applications to report CPU usage.
> > + *
> > + * @param [in] lcore_id
> > + * The lcore to consider.
> > + * @param [out] busy_cycles
> > + * The amount of busy time since application start, in TSC cycles.
> > + * @param [out] total_cycles
> > + * The total amount of time since application start, in TSC
> cycles.
> > + * @return
> > + * - 0 if both busy and total were set correctly.
> > + * - a negative value if the information is not available or if
> any error occurred.
> > + */
> > +typedef int (*rte_lcore_usage_cb)(
> > + unsigned int lcore_id, uint64_t *busy_cycles, uint64_t
> *total_cycles);
>
> Instead of two uint64_t pointers, I was thinking a better approach
> would
> be to pass a pointer to a struct containing these two fields. That way
> it leaves room for adding more counters if need be. And do so without
> breaking the ABI.
>
> Thoughts?
I like the idea.
For compatibility between newer DPDK libraries (with more fields) and older applications, the callback should return an indication of how much of the structure it has filled, so DPDK knows that some fields are unfilled.
The simplest method would be that the callback returns the number of bytes of the structure filled instead of 0 on success. However, that would not allow for holes in the returned structure.
Alternatively, a bitfield can be the first field in the structure, each bit representing a data field in the structure. That would allow flexibility to fill any of up to 64 fields. So with total_cycles and busy_cycles as data fields, the returned structure would contain e.g. {3, 1000, 900}. (As a personal preference, I would put total_cycles before busy_cycles in such a structure.)
And I'm not saying that fields must be uint64_t; they can be any size.
On the other hand, I might be suggesting too much flexibility with the bitfield proposal. Perhaps the simple method suffices. And perhaps only uint64_t fields suffice.
-Morten
^ permalink raw reply [relevance 0%]
* Re: [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API
2022-12-12 12:16 3% ` Bruce Richardson
2022-12-13 11:00 0% ` Morten Brørup
@ 2022-12-13 17:12 3% ` Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Bruce Richardson @ 2022-12-13 17:12 UTC (permalink / raw)
To: Morten Brørup
Cc: Huisong Li, dev, ciara.power, liudongdong3, huangdaode, fengchengwen
On Mon, Dec 12, 2022 at 12:16:07PM +0000, Bruce Richardson wrote:
> On Mon, Dec 12, 2022 at 01:03:52PM +0100, Morten Brørup wrote:
> > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > Sent: Monday, 12 December 2022 12.21
> > >
> > > On Mon, Dec 12, 2022 at 12:02:32PM +0100, Morten Brørup wrote:
> > > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > > > Sent: Monday, 12 December 2022 11.32
> > > > >
> > > > > On Mon, Dec 12, 2022 at 02:42:55PM +0800, Huisong Li wrote:
> > > > > > Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> > > > > > rte_tel_data_add_dict/array_int API. This may cause data
> > > conversion
> > > > > error
> > > > > > or data truncation.
> > > > > >
> > > > > > The 'u32' data can not be assigned to signed 32-bit integer.
> > > However,
> > > > > > assigning to u64 is very wasteful, after all, the buffer capacity
> > > of
> > > > > each
> > > > > > transfer is limited. So it is necessary for 'u32' data to add
> > > usigned
> > > > > > 32-bit integer type and a series of 'u32' operation APIs.
> > > > > >
> > > > > > This patchset uses the new 'u32' API to resolve the problem of
> > > data
> > > > > > conversion error, and use the 'u64' API to add 'u64' data.
> > > > > >
> > > > > > In addition, this patchset introduces two APIs to store u32 and
> > > u64
> > > > > > values as hexadecimal encoded strings in telemetry library.
> > > > > >
> > > > > > --- -v3: fix a misspelling mistake in commit log. -v2: - fix ABI
> > > > > break
> > > > > > warning. - introduce two APIs to store u32 and u64 values as
> > > > > hexadecimal
> > > > > > encoded strings.
> > > > > >
> > > > > I'm not convinced about adding the u32 value generically to the
> > > > > telemetry
> > > > > lib - except in the case of having explicit function calls for u32
> > > vs
> > > > > u64
> > > > > hex strings. Having a u32 type doesn't gain us any space internally
> > > > > over a
> > > > > u64 value, since all values are in a union type. Also, for output
> > > as
> > > > > json,
> > > > > the numeric values are all output as decimal values, meaning that
> > > the
> > > > > value
> > > > > 1 appears as the same size in the output string whether it is a u32
> > > or
> > > > > u64
> > > > > type. Now, it may save space in a future binary output format, but
> > > even
> > > > > then it still may not do so.
> > > >
> > > > I agree that a u32 doesn't gain any space internally.
> > > >
> > > > However, many SNMP counters are unsigned 32 bit, and expected to wrap
> > > around as such.
> > > >
> > > > So I suppose the u32 type might be useful for SNMP, if obtained
> > > through the telemetry library.
> > > >
> > > > Alternatively, we could somehow reuse the u64 type and require the
> > > application to pass (value & UINT32_MAX) to the u64 functions. To make
> > > this easy to use, we should add some wrappers to do it for the
> > > application. And eventually we would probably end up with something
> > > very similar to this patch.
> > > >
> > >
> > > I think just using the u64 functions is probably simplest and best
> > > right
> > > now. If we add support for something like snmp then yes, it would make
> > > sense to explicitly add it, but it seems like a lot of extra code for
> > > little or no benefit until we support something like that.
> >
> > <rant>
> > If we wanted to fix this generally, we should rely on type promotion, so the existing _int function should be updated to take an int64_t value, and the _u64 function should be renamed to _uint (and still take an uint64_t value). However, that would break the ABI, and would need to go through some process for that. So let's not change this now.
> > </rant>
>
> Yes, not making "int" an "i64" type was a poor design decision on my part
> in the earlier versions. Thankfully negative values are rarely needed
> beyond the range of 32-bits, but we should probably look to update this as
> you suggest at the next ABI break window.
>
Actually, most of the work for this can be done without affecting ABI, I
believe, and for the two functions that would be affected, function
versioning could be used to cover those. I think it's better to make the
change now using versioning rather than waiting, as it's likely to be
forgotten if we wait.
I'll work up a patchset for this so we can review and discuss...
/Bruce
^ permalink raw reply [relevance 3%]
* Re: [PATCH 2/4] eal: allow applications to report their cpu usage
2022-12-13 15:49 3% ` Robin Jarry
2022-12-13 16:39 0% ` Morten Brørup
@ 2022-12-13 17:45 0% ` Tyler Retzlaff
1 sibling, 0 replies; 200+ results
From: Tyler Retzlaff @ 2022-12-13 17:45 UTC (permalink / raw)
To: Robin Jarry; +Cc: dev, Morten Brørup, Kevin Laatz
On Tue, Dec 13, 2022 at 04:49:31PM +0100, Robin Jarry wrote:
> Robin Jarry, Dec 07, 2022 at 17:21:
> > Allow applications to register a callback that will be invoked in
> > rte_lcore_dump() and when requesting lcore info in the telemetry API.
> >
> > The callback is expected to return the number of TSC cycles that have
> > passed since application start and the number of these cycles that were
> > spent doing busy work.
> >
> > Signed-off-by: Robin Jarry <rjarry@redhat.com>
> > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > ---
> > v3 -> v4: Changed nomenclature: CPU cycles -> TSC cycles
>
> As you may have noticed, I forgot to add -v4 for that iteration...
>
> > diff --git a/lib/eal/include/rte_lcore.h b/lib/eal/include/rte_lcore.h
> > index 6938c3fd7b81..df7f0a8e07c6 100644
> > --- a/lib/eal/include/rte_lcore.h
> > +++ b/lib/eal/include/rte_lcore.h
> > @@ -328,6 +328,35 @@ typedef int (*rte_lcore_iterate_cb)(unsigned int lcore_id, void *arg);
> > int
> > rte_lcore_iterate(rte_lcore_iterate_cb cb, void *arg);
> >
> > +/**
> > + * Callback to allow applications to report CPU usage.
> > + *
> > + * @param [in] lcore_id
> > + * The lcore to consider.
> > + * @param [out] busy_cycles
> > + * The amount of busy time since application start, in TSC cycles.
> > + * @param [out] total_cycles
> > + * The total amount of time since application start, in TSC cycles.
> > + * @return
> > + * - 0 if both busy and total were set correctly.
> > + * - a negative value if the information is not available or if any error occurred.
> > + */
> > +typedef int (*rte_lcore_usage_cb)(
> > + unsigned int lcore_id, uint64_t *busy_cycles, uint64_t *total_cycles);
>
> Instead of two uint64_t pointers, I was thinking a better approach would
> be to pass a pointer to a struct containing these two fields. That way
> it leaves room for adding more counters if need be. And do so without
> breaking the ABI.
>
> Thoughts?
yes, please.
^ permalink raw reply [relevance 0%]
* [RFC PATCH 0/7] Standardize telemetry int types
@ 2022-12-13 18:27 4% Bruce Richardson
2022-12-13 18:27 3% ` [RFC PATCH 6/7] telemetry: make internal int representation 64-bits Bruce Richardson
` (4 more replies)
0 siblings, 5 replies; 200+ results
From: Bruce Richardson @ 2022-12-13 18:27 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson
Rather than having 64-bit unsigned types and 32-bit signed types
supported by the telemetry lib, we should support 64-bit values
for both types. On the naming side, since both are 64-bit, we
should no longer call the unsigned value u64 - "uint" is better.
This patchset implements these changes as far as is possible while
still keeping API and ABI compatibility.
* Internal structures and functions are updated to use 64-bit ints
* Internal functions are renamed from u64 to uint
* Public enum values are renamed from u64 to uint, and a macro is
added to ensure that older code still compiles
* The public add_*_int functions are changed to take a 64-bit value
rather than a 32-bit one. Since this would be an ABI break, we
use function versioning to ensure older code still calls into
a wrapper function which takes a 32-bit value.
Finally, the patchset also contains a couple of other small cleanups
to the telemetry code that were seen in passing when making these
changes.
Bruce Richardson (7):
telemetry: rename unsigned 64-bit enum value to uint
telemetry: add uint type as alias for u64
telemetry: remove RTE prefix from internal enum values
telemetry: make array initialization more robust
telemetry: update json functions to use int/uint in names
telemetry: make internal int representation 64-bits
telemetry: change public API to use 64-bit signed values
app/test/test_telemetry_data.c | 10 +--
app/test/test_telemetry_json.c | 9 +-
drivers/net/cnxk/cnxk_ethdev_sec_telemetry.c | 4 +-
drivers/net/cnxk/cnxk_ethdev_telemetry.c | 2 +-
lib/cryptodev/rte_cryptodev.c | 2 +-
lib/ethdev/rte_ethdev.c | 2 +-
lib/ethdev/sff_telemetry.c | 2 +-
lib/ipsec/ipsec_telemetry.c | 2 +-
lib/security/rte_security.c | 4 +-
lib/telemetry/meson.build | 1 +
lib/telemetry/rte_telemetry.h | 46 +++++++++-
lib/telemetry/telemetry.c | 56 ++++++------
lib/telemetry/telemetry_data.c | 95 ++++++++++++++------
lib/telemetry/telemetry_data.h | 24 +++--
lib/telemetry/telemetry_json.h | 16 ++--
lib/telemetry/version.map | 14 +++
16 files changed, 192 insertions(+), 97 deletions(-)
--
2.34.1
^ permalink raw reply [relevance 4%]
* [RFC PATCH 6/7] telemetry: make internal int representation 64-bits
2022-12-13 18:27 4% [RFC PATCH 0/7] Standardize telemetry int types Bruce Richardson
@ 2022-12-13 18:27 3% ` Bruce Richardson
2022-12-13 18:27 3% ` [RFC PATCH 7/7] telemetry: change public API to use 64-bit signed values Bruce Richardson
` (3 subsequent siblings)
4 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2022-12-13 18:27 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson, Morten Brørup
The internal storage for int values can be expanded from 32-bit to
64-bit without affecting the external ABI.
Suggested-by: Morten Brørup <mb@smartsharesystems.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
lib/telemetry/telemetry_data.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/telemetry/telemetry_data.h b/lib/telemetry/telemetry_data.h
index 8db6875a81..205509c5a2 100644
--- a/lib/telemetry/telemetry_data.h
+++ b/lib/telemetry/telemetry_data.h
@@ -28,7 +28,7 @@ struct container {
*/
union tel_value {
char sval[RTE_TEL_MAX_STRING_LEN];
- int ival;
+ int64_t ival;
uint64_t uval;
struct container container;
};
--
2.34.1
^ permalink raw reply [relevance 3%]
* [RFC PATCH 7/7] telemetry: change public API to use 64-bit signed values
2022-12-13 18:27 4% [RFC PATCH 0/7] Standardize telemetry int types Bruce Richardson
2022-12-13 18:27 3% ` [RFC PATCH 6/7] telemetry: make internal int representation 64-bits Bruce Richardson
@ 2022-12-13 18:27 3% ` Bruce Richardson
2022-12-13 20:19 3% ` Morten Brørup
` (2 subsequent siblings)
4 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2022-12-13 18:27 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson, Morten Brørup
While the unsigned values added to telemetry dicts/arrays were up to
64-bits in size, the sized values were only up to 32-bits. We can
standardize the API by having both int and uint functions take 64-bit
values. For ABI compatibility, we use function versioning to ensure
older binaries can still use the older functions taking a 32-bit
parameter.
Suggested-by: Morten Brørup <mb@smartsharesystems.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
lib/telemetry/meson.build | 1 +
lib/telemetry/rte_telemetry.h | 4 ++--
lib/telemetry/telemetry_data.c | 33 +++++++++++++++++++++++++++++----
lib/telemetry/telemetry_data.h | 6 ++++++
lib/telemetry/version.map | 7 +++++++
5 files changed, 45 insertions(+), 6 deletions(-)
diff --git a/lib/telemetry/meson.build b/lib/telemetry/meson.build
index f84c9aa3be..73750d9ef4 100644
--- a/lib/telemetry/meson.build
+++ b/lib/telemetry/meson.build
@@ -6,3 +6,4 @@ includes = [global_inc]
sources = files('telemetry.c', 'telemetry_data.c', 'telemetry_legacy.c')
headers = files('rte_telemetry.h')
includes += include_directories('../metrics')
+use_function_versioning = true
diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
index 60877dae0a..baa7b21f6b 100644
--- a/lib/telemetry/rte_telemetry.h
+++ b/lib/telemetry/rte_telemetry.h
@@ -120,7 +120,7 @@ rte_tel_data_add_array_string(struct rte_tel_data *d, const char *str);
* 0 on success, negative errno on error
*/
int
-rte_tel_data_add_array_int(struct rte_tel_data *d, int x);
+rte_tel_data_add_array_int(struct rte_tel_data *d, int64_t x);
/**
* Add an unsigned value to an array.
@@ -208,7 +208,7 @@ rte_tel_data_add_dict_string(struct rte_tel_data *d, const char *name,
* 0 on success, negative errno on error, E2BIG on string truncation of name.
*/
int
-rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val);
+rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int64_t val);
/**
* Add an unsigned value to a dictionary.
diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index 9a180937fd..ac7be795df 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -8,6 +8,7 @@
#undef RTE_USE_LIBBSD
#include <stdbool.h>
+#include <rte_function_versioning.h>
#include <rte_string_fns.h>
#include "telemetry_data.h"
@@ -58,8 +59,8 @@ rte_tel_data_add_array_string(struct rte_tel_data *d, const char *str)
return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
}
-int
-rte_tel_data_add_array_int(struct rte_tel_data *d, int x)
+int __vsym
+rte_tel_data_add_array_int_v24(struct rte_tel_data *d, int64_t x)
{
if (d->type != TEL_ARRAY_INT)
return -EINVAL;
@@ -69,6 +70,18 @@ rte_tel_data_add_array_int(struct rte_tel_data *d, int x)
return 0;
}
+int __vsym
+rte_tel_data_add_array_int_v23(struct rte_tel_data *d, int x)
+{
+ return rte_tel_data_add_array_int_v24(d, x);
+}
+
+/* mark the v23 function as the older version, and v24 as the default version */
+VERSION_SYMBOL(rte_tel_data_add_array_int, _v23, 23);
+BIND_DEFAULT_SYMBOL(rte_tel_data_add_array_int, _v24, 24);
+MAP_STATIC_SYMBOL(int rte_tel_data_add_array_int(struct rte_tel_data *d,
+ int64_t x), rte_tel_data_add_array_int_v24);
+
int
rte_tel_data_add_array_uint(struct rte_tel_data *d, uint64_t x)
{
@@ -146,8 +159,8 @@ rte_tel_data_add_dict_string(struct rte_tel_data *d, const char *name,
return 0;
}
-int
-rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val)
+int __vsym
+rte_tel_data_add_dict_int_v24(struct rte_tel_data *d, const char *name, int64_t val)
{
struct tel_dict_entry *e = &d->data.dict[d->data_len];
if (d->type != TEL_DICT)
@@ -165,6 +178,18 @@ rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val)
return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
}
+int __vsym
+rte_tel_data_add_dict_int_v23(struct rte_tel_data *d, const char *name, int val)
+{
+ return rte_tel_data_add_dict_int_v24(d, name, val);
+}
+
+/* mark the v23 function as the older version, and v24 as the default version */
+VERSION_SYMBOL(rte_tel_data_add_dict_int, _v23, 23);
+BIND_DEFAULT_SYMBOL(rte_tel_data_add_dict_int, _v24, 24);
+MAP_STATIC_SYMBOL(int rte_tel_data_add_dict_int(struct rte_tel_data *d,
+ const char *name, int64_t val), rte_tel_data_add_dict_int_v24);
+
int
rte_tel_data_add_dict_uint(struct rte_tel_data *d,
const char *name, uint64_t val)
diff --git a/lib/telemetry/telemetry_data.h b/lib/telemetry/telemetry_data.h
index 205509c5a2..53e4cabea5 100644
--- a/lib/telemetry/telemetry_data.h
+++ b/lib/telemetry/telemetry_data.h
@@ -49,4 +49,10 @@ struct rte_tel_data {
} data; /* data container */
};
+/* versioned functions */
+int rte_tel_data_add_array_int_v23(struct rte_tel_data *d, int val);
+int rte_tel_data_add_array_int_v24(struct rte_tel_data *d, int64_t val);
+int rte_tel_data_add_dict_int_v23(struct rte_tel_data *d, const char *name, int val);
+int rte_tel_data_add_dict_int_v24(struct rte_tel_data *d, const char *name, int64_t val);
+
#endif
diff --git a/lib/telemetry/version.map b/lib/telemetry/version.map
index 0f70d82dfc..85df19c4d8 100644
--- a/lib/telemetry/version.map
+++ b/lib/telemetry/version.map
@@ -19,6 +19,13 @@ DPDK_23 {
local: *;
};
+DPDK_24 {
+ global:
+
+ rte_tel_data_add_array_int;
+ rte_tel_data_add_dict_int;
+} DPDK_23;
+
EXPERIMENTAL {
global:
--
2.34.1
^ permalink raw reply [relevance 3%]
* RE: [RFC PATCH 7/7] telemetry: change public API to use 64-bit signed values
2022-12-13 18:27 3% ` [RFC PATCH 7/7] telemetry: change public API to use 64-bit signed values Bruce Richardson
@ 2022-12-13 20:19 3% ` Morten Brørup
2022-12-14 17:53 0% ` Tyler Retzlaff
0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2022-12-13 20:19 UTC (permalink / raw)
To: Bruce Richardson, dev
> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Tuesday, 13 December 2022 19.28
>
> While the unsigned values added to telemetry dicts/arrays were up to
> 64-bits in size, the sized values were only up to 32-bits. We can
> standardize the API by having both int and uint functions take 64-bit
> values. For ABI compatibility, we use function versioning to ensure
> older binaries can still use the older functions taking a 32-bit
> parameter.
>
> Suggested-by: Morten Brørup <mb@smartsharesystems.com>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
Excellent example of how to use function versioning for ABI compatibility.
Series-acked-by: Morten Brørup <mb@smartsharesystems.com>
^ permalink raw reply [relevance 3%]
* Re: [PATCH] cryptodev: add algo enums to string conversion APIs
2022-12-12 15:10 2% [PATCH] cryptodev: add algo enums to string conversion APIs Akhil Goyal
` (2 preceding siblings ...)
2022-12-13 8:22 0% ` Power, Ciara
@ 2022-12-14 9:32 0% ` Zhang, Fan
2023-01-04 6:18 2% ` [PATCH v2] " Akhil Goyal
4 siblings, 0 replies; 200+ results
From: Zhang, Fan @ 2022-12-14 9:32 UTC (permalink / raw)
To: Akhil Goyal, dev
Cc: ciara.power, kai.ji, pablo.de.lara.guarch, hemant.agrawal, matan,
g.singh, ruifeng.wang, anoobj, radu.nicolau, vfialko, ktraynor,
david.marchand, thomas
On 12/12/2022 3:10 PM, Akhil Goyal wrote:
> Symmetric/Asymmetric algorithm strings are accessed by application
> using arrays in cryptodev lib, which hampers new algorithms addition
> in the array due to ABI breakage.
> These arrays are now deprecated and will be removed in next ABI break
> release.
> New APIs are added for getting the algorithm strings based on enum values.
>
> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> ---
> app/test-crypto-perf/cperf_options_parsing.c | 6 +-
> app/test/test_cryptodev_asym.c | 2 +-
> app/test/test_cryptodev_security_ipsec.c | 8 +-
> doc/guides/rel_notes/deprecation.rst | 7 +
> drivers/crypto/openssl/rte_openssl_pmd_ops.c | 2 +-
> drivers/crypto/qat/qat_sym_session.c | 7 +-
> examples/l2fwd-crypto/main.c | 12 +-
> lib/cryptodev/cryptodev_trace_points.c | 12 ++
> lib/cryptodev/rte_crypto_asym.h | 1 +
> lib/cryptodev/rte_crypto_sym.h | 3 +
> lib/cryptodev/rte_cryptodev.c | 182 ++++++++++++++++++-
> lib/cryptodev/rte_cryptodev.h | 52 ++++++
> lib/cryptodev/rte_cryptodev_trace.h | 32 ++++
> lib/cryptodev/version.map | 10 +
> 14 files changed, 309 insertions(+), 27 deletions(-)
Acked-by: Fan Zhang <fanzhang.oss@gmail.com>
^ permalink raw reply [relevance 0%]
* [PATCH V5 0/8] telemetry: fix data truncation and conversion error and add hex integer API
` (2 preceding siblings ...)
2022-12-13 10:15 3% ` [PATCH V4 0/9] telemetry: fix data truncation and conversion error and add hex integer API Huisong Li
@ 2022-12-14 12:32 3% ` Huisong Li
2022-12-15 10:31 3% ` [PATCH V6 " Huisong Li
` (2 subsequent siblings)
6 siblings, 0 replies; 200+ results
From: Huisong Li @ 2022-12-14 12:32 UTC (permalink / raw)
To: dev
Cc: bruce.richardson, mb, andrew.rybchenko, huangdaode, liudongdong3,
fengchengwen, lihuisong
Some lib telemetry interfaces add the 'u32' and 'u64' data by the
rte_tel_data_add_dict/array_int API. This may cause data conversion
error or data truncation. This patch series uses 'u64' functions to
do this.
In addition, this patch series introduces two APIs to store unsigned
integer values as hexadecimal encoded strings in telemetry library.
---
-v5:
- drop a refactor patch.
- no limit the bit width for xxx_uint_hex API.
-v4:
- remove 'u32' value type.
- add padding zero for hexadecimal value
-v3: fix a misspelling mistake in commit log.
-v2:
- fix ABI break warning.
- introduce two APIs to store u32 and u64 values as hexadecimal
encoded strings.
Huisong Li (8):
telemetry: move to header to controllable range
ethdev: fix possible data truncation and conversion error
mempool: fix possible data truncation and conversion error
cryptodev: fix possible data conversion error
mem: possible data truncation and conversion error
telemetry: support adding integer value as hexadecimal
test: add test cases for adding hex integer value API
ethdev: display capability values in hexadecimal format
app/test/test_telemetry_data.c | 150 +++++++++++++++++++++++++++++
lib/cryptodev/rte_cryptodev.c | 2 +-
lib/eal/common/eal_common_memory.c | 10 +-
lib/ethdev/rte_ethdev.c | 19 ++--
lib/mempool/rte_mempool.c | 24 ++---
lib/telemetry/rte_telemetry.h | 52 +++++++++-
lib/telemetry/telemetry_data.c | 74 ++++++++++++++
lib/telemetry/version.map | 9 ++
8 files changed, 310 insertions(+), 30 deletions(-)
--
2.33.0
^ permalink raw reply [relevance 3%]
* Re: [RFC PATCH 7/7] telemetry: change public API to use 64-bit signed values
2022-12-13 20:19 3% ` Morten Brørup
@ 2022-12-14 17:53 0% ` Tyler Retzlaff
2022-12-15 2:39 0% ` lihuisong (C)
0 siblings, 1 reply; 200+ results
From: Tyler Retzlaff @ 2022-12-14 17:53 UTC (permalink / raw)
To: Morten Brørup; +Cc: Bruce Richardson, dev
On Tue, Dec 13, 2022 at 09:19:45PM +0100, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Tuesday, 13 December 2022 19.28
> >
> > While the unsigned values added to telemetry dicts/arrays were up to
> > 64-bits in size, the sized values were only up to 32-bits. We can
> > standardize the API by having both int and uint functions take 64-bit
> > values. For ABI compatibility, we use function versioning to ensure
> > older binaries can still use the older functions taking a 32-bit
> > parameter.
> >
> > Suggested-by: Morten Brørup <mb@smartsharesystems.com>
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > ---
>
> Excellent example of how to use function versioning for ABI compatibility.
>
> Series-acked-by: Morten Brørup <mb@smartsharesystems.com>
>
minor comments that can be optionally addressed. lgtm
Series-acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
^ permalink raw reply [relevance 0%]
* Re: [RFC PATCH 7/7] telemetry: change public API to use 64-bit signed values
2022-12-14 17:53 0% ` Tyler Retzlaff
@ 2022-12-15 2:39 0% ` lihuisong (C)
0 siblings, 0 replies; 200+ results
From: lihuisong (C) @ 2022-12-15 2:39 UTC (permalink / raw)
To: dev
在 2022/12/15 1:53, Tyler Retzlaff 写道:
> On Tue, Dec 13, 2022 at 09:19:45PM +0100, Morten Brørup wrote:
>>> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
>>> Sent: Tuesday, 13 December 2022 19.28
>>>
>>> While the unsigned values added to telemetry dicts/arrays were up to
>>> 64-bits in size, the sized values were only up to 32-bits. We can
>>> standardize the API by having both int and uint functions take 64-bit
>>> values. For ABI compatibility, we use function versioning to ensure
>>> older binaries can still use the older functions taking a 32-bit
>>> parameter.
>>>
>>> Suggested-by: Morten Brørup <mb@smartsharesystems.com>
>>> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
>>> ---
>> Excellent example of how to use function versioning for ABI compatibility.
>>
>> Series-acked-by: Morten Brørup <mb@smartsharesystems.com>
>>
> minor comments that can be optionally addressed. lgtm
>
> Series-acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> .
LGTM
Series-acked-by: Huisong Li <lihuisong@huawei.com>
But I feel this patchset needs to be applied after the following patchset:
http://patches.dpdk.org/project/dpdk/list/?series=26124
The above patchset fixes some problems about possible data truncation and
conversion error, and will backport to stable branch.
^ permalink raw reply [relevance 0%]
* [PATCH V6 0/8] telemetry: fix data truncation and conversion error and add hex integer API
` (3 preceding siblings ...)
2022-12-14 12:32 3% ` [PATCH V5 0/8] " Huisong Li
@ 2022-12-15 10:31 3% ` Huisong Li
2022-12-16 1:54 3% ` [PATCH V7 " Huisong Li
2022-12-19 7:06 3% ` [PATCH V8 " Huisong Li
6 siblings, 0 replies; 200+ results
From: Huisong Li @ 2022-12-15 10:31 UTC (permalink / raw)
To: dev
Cc: bruce.richardson, mb, andrew.rybchenko, huangdaode, liudongdong3,
fengchengwen, lihuisong
Some lib telemetry interfaces add the 'u32' and 'u64' data by the
rte_tel_data_add_dict/array_int API. This may cause data conversion
error or data truncation. This patch series uses 'u64' functions to
do this.
In addition, this patch series introduces two APIs to store unsigned
integer values as hexadecimal encoded strings in telemetry library.
---
-v6: fix code alignment to keep in line with codes in the file
-v5:
- drop a refactor patch.
- no limit the bit width for xxx_uint_hex API.
-v4:
- remove 'u32' value type.
- add padding zero for hexadecimal value
-v3: fix a misspelling mistake in commit log.
-v2:
- fix ABI break warning.
- introduce two APIs to store u32 and u64 values as hexadecimal
encoded strings.
Huisong Li (8):
telemetry: move to header to controllable range
ethdev: fix possible data truncation and conversion error
mempool: fix possible data truncation and conversion error
cryptodev: fix possible data conversion error
mem: possible data truncation and conversion error
telemetry: support adding integer value as hexadecimal
test: add test cases for adding hex integer value API
ethdev: display capability values in hexadecimal format
app/test/test_telemetry_data.c | 150 +++++++++++++++++++++++++++++
lib/cryptodev/rte_cryptodev.c | 2 +-
lib/eal/common/eal_common_memory.c | 10 +-
lib/ethdev/rte_ethdev.c | 19 ++--
lib/mempool/rte_mempool.c | 24 ++---
lib/telemetry/rte_telemetry.h | 52 +++++++++-
lib/telemetry/telemetry_data.c | 72 ++++++++++++++
lib/telemetry/version.map | 9 ++
8 files changed, 308 insertions(+), 30 deletions(-)
--
2.33.0
^ permalink raw reply [relevance 3%]
* Re: [RFC PATCH 2/7] telemetry: add uint type as alias for u64
@ 2022-12-15 13:58 4% ` Bruce Richardson
2022-12-19 10:37 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2022-12-15 13:58 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: Tyler Retzlaff, dev, Morten Brørup, david.marchand
On Thu, Dec 15, 2022 at 02:36:51PM +0100, Thomas Monjalon wrote:
> 15/12/2022 10:44, Bruce Richardson:
> > On Wed, Dec 14, 2022 at 09:38:45AM -0800, Tyler Retzlaff wrote:
> > > On Tue, Dec 13, 2022 at 06:27:25PM +0000, Bruce Richardson wrote:
> > > > For future standardization on the "uint" name for unsigned values rather
> > > > than the existing "u64" one, we can for now:
> > > > * rename all internal values to use uint rather than u64
> > > > * add new function names to alias the existing u64 ones
> > > >
> > > > Suggested-by: Morten Brørup <mb@smartsharesystems.com>
> > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > > ---
> > > > lib/telemetry/rte_telemetry.h | 36 ++++++++++++++++++++++++++++++++++
> > > > lib/telemetry/telemetry.c | 16 +++++++--------
> > > > lib/telemetry/telemetry_data.c | 28 ++++++++++++++++++--------
> > > > lib/telemetry/telemetry_data.h | 4 ++--
> > > > lib/telemetry/version.map | 7 +++++++
> > > > 5 files changed, 73 insertions(+), 18 deletions(-)
> > > >
> > > > diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
> > > > index c2ad65effe..60877dae0a 100644
> > > > --- a/lib/telemetry/rte_telemetry.h
> > > > +++ b/lib/telemetry/rte_telemetry.h
> > > > @@ -8,6 +8,8 @@
> > > > #ifndef _RTE_TELEMETRY_H_
> > > > #define _RTE_TELEMETRY_H_
> > > >
> > > > +#include <rte_compat.h>
> > > > +
> > > > #ifdef __cplusplus
> > > > extern "C" {
> > > > #endif
> > > > @@ -121,6 +123,22 @@ int
> > > > rte_tel_data_add_array_int(struct rte_tel_data *d, int x);
> > > >
> > > > /**
> > >
> > > when adding __rte_experimental api i have been asked to add the
> > > following boilerplate documentation block. i'm not pushing it, just
> > > recalling it is what i get asked for, so in case it's something we do?
> > > see lib/eal/include/rte_thread.h as an example
> > >
> > >
> > > ```
> > > * @warning
> > > * @b EXPERIMENTAL: this API may change without prior notice.
> > > ```
> > >
> >
> > Ok, thanks for the notice.
> >
> > Actually, related to this, since we are adding these functions as aliases
> > for existing stable functions, I would like to see these being added not as
> > experimental. The reason for that, is that while they are experimental, we
> > cannot feasibly mark the old function names as deprecated. :-(
> >
> > Adding Thomas and David on CC for their thoughts.
>
> Is it related to telemetry?
>
> In general, yes we cannot deprecate something if there is no stable replacement.
> The recommended step is to introduce a new experimental API
> and deprecate the old one when the new API is stable.
>
Yes, understood.
What we are really trying to do here is to rename an API, by process of
adding the new API and then marking the old one as deprecated. The small
issue is that adding the new one it is by default experimental, meaning we
need to wait for deprecating old one. Ideally, as soon as the new API is
added, we would like to point people to use that, but can't really do so
while it is experimental.
---
By way of explicit detail, Morten pointed out the inconsistency in the
telemetry APIs and types:
* we have add_*_int, which takes a 32-bit signed value
* we have add_*_u64 which takes 64-bit unsigned (as name suggests).
The ideal end-state is to always use 64-bit values (since there is no space
saving from 32-bit as a union is used), and just name everything as "int"
or "uint" for signed/unsigned. The two big steps here are:
* expanding type of the "int" functions to take 64-bit parameters - this is
ABI change but not API one, since existing code will happily promote
values on compile. Therefore, we just use ABI versioning to have a 32-bit
version for older linked binaries.
* the rename of the rte_tel_data_add_array_u64 and
rte_tel_data_add_dict_u64 to *_uint variants. Though keeping
compatibility is easier, as we can just add new functions, the overall
process is slower since the new functions technically should be added as
experimental - hence the email. For the case of function renaming, do we
still need to have the "renamed" versions as experimental initially?
Given where we are in the overall DPDK releases cycle, it's not a major
issue either way, I just would like some clarity. My main concern with
having it spread over a couple of releases, is that it's more likely a step
will be missed/forgotten somewhere along the way!
/Bruce
^ permalink raw reply [relevance 4%]
* [PATCH V7 0/8] telemetry: fix data truncation and conversion error and add hex integer API
` (4 preceding siblings ...)
2022-12-15 10:31 3% ` [PATCH V6 " Huisong Li
@ 2022-12-16 1:54 3% ` Huisong Li
2022-12-19 7:06 3% ` [PATCH V8 " Huisong Li
6 siblings, 0 replies; 200+ results
From: Huisong Li @ 2022-12-16 1:54 UTC (permalink / raw)
To: dev
Cc: bruce.richardson, mb, andrew.rybchenko, huangdaode, liudongdong3,
fengchengwen, lihuisong
Some lib telemetry interfaces add the 'u32' and 'u64' data by the
rte_tel_data_add_dict/array_int API. This may cause data conversion
error or data truncation. This patch series uses 'u64' functions to
do this.
In addition, this patch series introduces two APIs to store unsigned
integer values as hexadecimal encoded strings in telemetry library.
---
-v7: replace sprintf with snprintf in patch 6/8
-v6: fix code alignment to keep in line with codes in the file
-v5:
- drop a refactor patch.
- no limit the bit width for xxx_uint_hex API.
-v4:
- remove 'u32' value type.
- add padding zero for hexadecimal value
-v3: fix a misspelling mistake in commit log.
-v2:
- fix ABI break warning.
- introduce two APIs to store u32 and u64 values as hexadecimal
encoded strings.
Huisong Li (8):
telemetry: move to header to controllable range
ethdev: fix possible data truncation and conversion error
mempool: fix possible data truncation and conversion error
cryptodev: fix possible data conversion error
mem: possible data truncation and conversion error
telemetry: support adding integer value as hexadecimal
test: add test cases for adding hex integer value API
ethdev: display capability values in hexadecimal format
app/test/test_telemetry_data.c | 150 +++++++++++++++++++++++++++++
lib/cryptodev/rte_cryptodev.c | 2 +-
lib/eal/common/eal_common_memory.c | 10 +-
lib/ethdev/rte_ethdev.c | 19 ++--
lib/mempool/rte_mempool.c | 24 ++---
lib/telemetry/rte_telemetry.h | 52 +++++++++-
lib/telemetry/telemetry_data.c | 73 ++++++++++++++
lib/telemetry/version.map | 9 ++
8 files changed, 309 insertions(+), 30 deletions(-)
--
2.33.0
^ permalink raw reply [relevance 3%]
* Re: 21.11.3 patches review and test
2022-12-06 11:29 1% 21.11.3 patches review and test Kevin Traynor
2022-12-13 11:48 0% ` Christian Ehrhardt
@ 2022-12-16 7:55 0% ` YangHang Liu
1 sibling, 0 replies; 200+ results
From: YangHang Liu @ 2022-12-16 7:55 UTC (permalink / raw)
To: Kevin Traynor
Cc: stable, dev, Abhishek Marathe, Ali Alnubani, benjamin.walker,
David Christensen, Hemant Agrawal, Ian Stokes, Jerin Jacob,
John McNamara, Ju-Hyoung Lee, Luca Boccassi, Pei Zhang,
qian.q.xu, Raslan Darawsheh, Thomas Monjalon, yuan.peng,
zhaoyan.chen, Chao Yang
[-- Attachment #1: Type: text/plain, Size: 19006 bytes --]
Hi Kevin,
RedHat QE does not find new issues about the 21.11.3 dpdk during the tests.
We tested below 17 scenarios and all got PASS on RHEL8:
- Guest with device assignment(PF) throughput testing(1G hugepage size):
PASS
- Guest with device assignment(PF) throughput testing(2M hugepage size)
: PASS
- Guest with device assignment(VF) throughput testing: PASS
- PVP (host dpdk testpmd as vswitch) 1Q: throughput testing: PASS
- PVP vhost-user 2Q throughput testing: PASS
- PVP vhost-user 1Q - cross numa node throughput testing: PASS
- Guest with vhost-user 2 queues throughput testing: PASS
- vhost-user reconnect with dpdk-client, qemu-server: qemu reconnect:
PASS
- vhost-user reconnect with dpdk-client, qemu-server: ovs reconnect: PASS
- PVP 1Q live migration testing: PASS
- PVP 1Q cross numa node live migration testing: PASS
- Guest with ovs+dpdk+vhost-user 1Q live migration testing: PASS
- Guest with ovs+dpdk+vhost-user 1Q live migration testing (2M): PASS
- Guest with ovs+dpdk+vhost-user 2Q live migration testing: PASS
- Guest with ovs+dpdk+vhost-user 4Q live migration testing: PASS
- Host PF + DPDK testing: PASS
- Host VF + DPDK testing: PASS
Versions:
- kernel 4.18
- qemu-kvm-6.2
- DPDK
- commit 0bb6905a88784306878d9fceb0aa1c1ec68d1397 (tag: v21.11.3-rc1)
Author: Kevin Traynor <ktraynor@redhat.com>
Date: Mon Dec 5 11:53:33 2022 +0000
version: 21.11.3-rc1
Signed-off-by: Kevin Traynor <ktraynor@redhat.com>
NICs: X540-AT2 NIC(ixgbe, 10G)
Best Regards,
YangHang Liu
On Tue, Dec 6, 2022 at 7:29 PM Kevin Traynor <ktraynor@redhat.com> wrote:
> Hi all,
>
> Here is a list of patches targeted for stable release 21.11.3.
>
> The planned date for the final release is 19th December.
>
> Please help with testing and validation of your use cases and report
> any issues/results with reply-all to this mail. For the final release
> the fixes and reported validations will be added to the release notes.
>
> A release candidate tarball can be found at:
>
> https://dpdk.org/browse/dpdk-stable/tag/?id=v21.11.3-rc1
>
> These patches are located at branch 21.11 of dpdk-stable repo:
> https://dpdk.org/browse/dpdk-stable/
>
> Thanks.
>
> Kevin
>
> ---
> Abdullah Sevincer (1):
> event/dlb2: handle enqueuing more than maximum depth
>
> Abhimanyu Saini (1):
> common/sfc_efx/base: remove VQ index check during VQ start
>
> Aleksandr Miloshenko (1):
> net/iavf: fix Tx done descriptors cleanup
>
> Alex Kiselev (1):
> net/tap: fix overflow of network interface index
>
> Alexander Chernavin (1):
> net/virtio: fix crash when configured twice
>
> Alexander Kozyrev (3):
> net/mlx5: fix shared Rx queue config reuse
> net/mlx5: fix first segment inline length
> net/mlx5: fix indexed pool local cache crash
>
> Ali Alnubani (1):
> examples/l2fwd-crypto: fix typo in error message
>
> Amit Prakash Shukla (6):
> net/mvneta: fix build with GCC 12
> test/ipsec: fix build with GCC 12
> ipsec: fix build with GCC 12
> crypto/qat: fix build with GCC 12
> net/i40e: fix build with MinGW GCC 12
> net/qede/base: fix 32-bit build with GCC 12
>
> Andrew Boyer (5):
> net/ionic: fix endianness for Rx and Tx
> net/ionic: fix endianness for RSS
> net/ionic: fix adapter name for logging
> net/ionic: fix Rx filter save
> net/ionic: fix reported error stats
>
> Anoob Joseph (1):
> test/crypto: fix PDCP vectors
>
> Apeksha Gupta (2):
> net/enetfec: fix restart
> net/enetfec: fix buffer leak
>
> Arek Kusztal (1):
> common/qat: fix VF to PF answer
>
> Ashwin Sekhar T K (1):
> mempool/cnxk: fix destroying empty pool
>
> Ben Magistro (1):
> doc: fix dumpcap interface parameter option
>
> Benjamin Le Berre (1):
> net/bnxt: fix error code during MTU change
>
> Bhagyada Modali (9):
> net/axgbe: fix scattered Rx
> net/axgbe: fix mbuf lengths in scattered Rx
> net/axgbe: fix length of each segment in scattered Rx
> net/axgbe: fix checksum and RSS in scattered Rx
> net/axgbe: optimise scattered Rx
> net/axgbe: remove freeing buffer in scattered Rx
> net/axgbe: reset end of packet in scattered Rx
> net/axgbe: clear buffer on scattered Rx chaining failure
> net/axgbe: save segment data in scattered Rx
>
> Bing Zhao (2):
> net/mlx5: fix build with recent compilers
> bus/auxiliary: prevent device from being probed again
>
> Brian Dooley (1):
> crypto/qat: fix null hash algorithm digest size
>
> Changpeng Liu (1):
> vhost: add non-blocking API for posting interrupt
>
> Chaoyong He (1):
> net/nfp: fix Rx descriptor DMA address
>
> Chengwen Feng (8):
> net/hns3: fix crash in SVE Tx
> net/hns3: fix next-to-use overflow in SVE Tx
> net/hns3: fix next-to-use overflow in simple Tx
> net/hns3: fix crash when secondary process access FW
> net/hns3: revert Tx performance optimization
> net/hns3: revert fix mailbox communication with HW
> net/hns3: fix VF mailbox message handling
> app/testpmd: remove jumbo offload
>
> Ciara Power (1):
> test/crypto: fix wireless auth digest segment
>
> Conor Walsh (1):
> doc: fix reference to dma application example
>
> Dariusz Sosnowski (1):
> net/mlx5: fix hairpin split with set VLAN VID action
>
> David Marchand (23):
> vhost: fix virtqueue use after free on NUMA reallocation
> app/testpmd: restore ixgbe bypass commands
> net/failsafe: fix interrupt handle leak
> net/bnxt: fix build with GCC 13
> trace: fix mode for new trace point
> trace: fix mode change
> trace: fix leak with regexp
> trace: fix dynamically enabling trace points
> trace: fix race in debug dump
> ci: bump versions of actions in GHA
> ci: update to new API for step outputs in GHA
> service: fix build with clang 15
> vhost: fix build with clang 15
> bus/dpaa: fix build with clang 15
> net/atlantic: fix build with clang 15
> net/dpaa2: fix build with clang 15
> app/testpmd: fix build with clang 15
> app/testpmd: fix build with clang 15 in flow code
> test/efd: fix build with clang 15
> test/member: fix build with clang 15
> test/event: fix build with clang 15
> ci: enable ABI check in GHA
> trace: fix metadata dump
>
> Dmitry Kozlyuk (4):
> build: enable developer mode for all working trees
> eal: fix side effect in some pointer arithmetic macros
> mempool: make event callbacks process-private
> common/mlx5: fix multi-process mempool registration
>
> Dong Zhou (1):
> net/mlx5: fix thread workspace memory leak
>
> Dongdong Liu (2):
> doc: fix application name in procinfo guide
> doc: document device dump in procinfo guide
>
> Erik Gabriel Carrillo (1):
> service: fix early move to inactive status
>
> Fidaullah Noonari (1):
> malloc: fix storage size for some allocations
>
> Frank Du (1):
> net/ice: fix interrupt handler unregister
>
> Gagandeep Singh (5):
> net/dpaa: fix buffer freeing in slow path
> net/dpaa: use internal mempool for SG table
> net/dpaa: fix buffer freeing on SG Tx
> net/dpaa2: use internal mempool for SG table
> net/dpaa2: fix buffer freeing on SG Tx
>
> Ganapati Kundapura (1):
> eventdev/crypto: fix multi-process
>
> Gregory Etelson (6):
> net/mlx5: fix RSS expansion buffer size
> app/testpmd: fix MAC header in checksum forward engine
> common/mlx5: fix shared mempool subscription
> net/mlx5: fix port initialization with small LRO
> net/mlx5: fix maximum LRO message size
> doc: add LRO size limitation in mlx5 guide
>
> Haiyue Wang (1):
> ring: fix description
>
> Hamza Khan (1):
> examples/vm_power_manager: use safe list iterator
>
> Hanumanth Pothula (1):
> net/cnxk: fix DF bit in vector mode
>
> Hernan Vargas (14):
> baseband/acc100: fix memory leak
> baseband/acc100: check turbo dec/enc input
> baseband/acc100: add null checks
> baseband/acc100: fix input length for CRC24B
> baseband/acc100: fix clearing PF IR outside handler
> baseband/acc100: fix device minimum alignment
> baseband/acc100: fix close cleanup
> baseband/acc100: add LDPC encoder padding function
> baseband/acc100: check AQ availability
> baseband/acc100: fix ring availability calculation
> baseband/acc100: enforce additional check on FCW
> baseband/acc100: fix null HARQ input case
> baseband/acc100: fix ring/queue allocation
> baseband/acc100: fix double MSI intr in TB mode
>
> Huisong Li (18):
> net/hns3: fix Rx with PTP
> net/hns3: delete unused markup
> net/hns3: fix clearing hardware MAC statistics
> net/hns3: fix RSS filter restore
> net/hns3: fix RSS flow rule restore
> net/hns3: move flow direction rule recovery
> net/hns3: fix packet type for GENEVE
> net/hns3: fix IPv4 and IPv6 RSS
> net/hns3: fix typos in IPv6 SCTP fields
> net/hns3: fix IPv4 RSS
> net/hns3: add L3 and L4 RSS types
> net/bonding: fix slave device Rx/Tx offload configuration
> net/bonding: fix dropping valid MAC packets
> net/bonding: fix mbuf fast free handling
> net/hns3: extract functions to create RSS and FDIR flow rule
> net/hns3: fix RSS rule restore
> net/hns3: fix lock protection of RSS flow rule
> net/hns3: fix restore filter function input
>
> Huzaifa Rahman (1):
> net/memif: fix crash with different number of Rx/Tx queues
>
> Ilya Maximets (1):
> doc: fix support table for Ethernet/VLAN flow items
>
> Ivan Malov (3):
> common/sfc_efx/base: fix maximum Tx data count
> net/bonding: fix descriptor limit reporting
> net/bonding: fix flow flush order on close
>
> James Hershaw (1):
> net/nfp: improve HW info header log readability
>
> Jeremy Spewock (1):
> test/ipsec: skip if no compatible device
>
> Jerin Jacob (2):
> eal: fix doxygen comments for UUID
> power: fix some doxygen comments
>
> Jiawei Wang (4):
> net/mlx5: fix modify action with tunnel decapsulation
> net/mlx5: fix tunnel header with IPIP offload
> net/mlx5: fix source port checking in sample flow rule
> net/mlx5: fix mirror flow validation with ASO action
>
> Jiawen Wu (6):
> net/txgbe: fix IPv6 flow rule
> net/txgbe: remove semaphore between SW/FW
> net/txgbe: rename some extended statistics
> net/ngbe: rename some extended statistics
> net/ngbe: remove semaphore between SW/FW
> net/ngbe: fix maximum frame size
>
> Jie Hai (1):
> net/hns3: fix minimum Tx frame length
>
> Jie Wang (1):
> net/i40e: fix jumbo frame Rx with X722
>
> Jun Qiu (3):
> gro: trim tail padding bytes
> net/bonding: fix Tx hash for TCP
> hash: fix RCU configuration memory leak
>
> Kai Ji (1):
> test/crypto: fix bitwise operator in a SNOW3G case
>
> Kalesh AP (2):
> net/bnxt: remove unnecessary check
> net/bnxt: fix representor info freeing
>
> Ke Zhang (2):
> net/i40e: fix VF representor release
> net/iavf: fix L3 checksum Tx offload flag
>
> Kevin Liu (2):
> net/iavf: check illegal packet sizes
> net/ice: check illegal packet sizes
>
> Kevin Traynor (1):
> Revert "cryptodev: fix missing SHA3 algorithm strings"
>
> Kumara Parameshwaran (1):
> gro: check payload length after trim
>
> Long Li (2):
> net/mlx4: fix Verbs FD leak in secondary process
> net/mlx5: fix Verbs FD leak in secondary process
>
> Long Wu (1):
> net/nfp: fix memory leak in Rx
>
> Luca Boccassi (1):
> drivers: fix typos found by Lintian
>
> Mao YingMing (1):
> net/bnxt: fix null pointer dereference in LED config
>
> Mattias Rönnblom (3):
> net: accept unaligned data in checksum routines
> event/dsw: fix flow migration
> doc: fix event timer adapter guide
>
> Maxime Coquelin (1):
> vhost: fix build with GCC 12
>
> Megha Ajmera (2):
> sched: fix subport profile configuration
> examples/qos_sched: fix number of subport profiles
>
> Michael Baum (5):
> net/mlx5: fix null check in devargs parsing
> doc: fix underlines in testpmd guide
> doc: fix colons in testpmd aged flow rules
> net/mlx5: fix race condition in counter pool resizing
> net/mlx5: fix port event cleaning order
>
> Mingjin Ye (4):
> net/ice: support VXLAN-GPE tunnel offload
> net/i40e: fix pctype configuration for X722
> net/ice: fix scalar Rx path segment
> net/ice: fix scalar Tx path segment
>
> Mário Kuka (1):
> pcapng: fix write more packets than IOV_MAX limit
>
> Naga Harish K S V (4):
> eventdev/eth_tx: add spinlock for adapter start/stop
> eventdev/eth_tx: fix adapter stop
> timer: fix stopping all timers
> eventdev/eth_tx: fix queue delete
>
> Nithin Dabilpuram (3):
> examples/ipsec-secgw: use Tx checksum offload conditionally
> examples/l3fwd: fix MTU configuration with event mode
> net/cnxk: fix later skip to include mbuf private data
>
> Olivier Matz (7):
> cryptodev: fix unduly newlines in logs
> mem: fix API doc about allocation on secondary processes
> event/sw: fix flow ID init in self test
> event/sw: fix log in self test
> net/ixgbe: fix broadcast Rx on VF after promisc removal
> net/ixgbe: fix unexpected VLAN Rx in promisc mode on VF
> net/ixgbevf: fix promiscuous and allmulti
>
> Pablo de Lara (1):
> examples/fips_validation: fix typo in error log
>
> Pavan Nikhilesh (3):
> event/cnxk: fix missing xstats operations
> event/cnxk: fix mbuf offset calculation
> event/cnxk: fix missing mempool cookie marking
>
> Peng Zhang (3):
> net/nfp: compose firmware file name with new hwinfo
> buildtools: fix NUMA nodes count
> net/nfp: fix internal buffer size and MTU check
>
> Qi Zhang (12):
> net/ice/base: fix division during E822 PTP init
> net/ice/base: fix 100M speed capability
> net/ice/base: fix DSCP PFC TLV creation
> net/ice/base: fix media type of PHY 10G SFI C2C
> net/ice/base: fix function descriptions for parser
> net/ice/base: fix endian format
> net/ice/base: fix array overflow in add switch recipe
> net/ice/base: fix bit finding range over ptype bitmap
> net/ice/base: fix add MAC rule
> net/ice/base: fix double VLAN in promiscuous mode
> net/ice/base: ignore promiscuous already exist
> net/ice/base: fix input set of GTPoGRE
>
> Qiming Yang (1):
> app/testpmd: skip port reset in secondary process
>
> Radu Nicolau (5):
> net/iavf: update IPsec ESN values when updating session
> net/iavf: fix IPsec flow create error check
> net/iavf: fix SPI check
> net/iavf: fix queue stop for large VF
> examples/ipsec-secgw: fix Tx checksum offload flag
>
> Raja Zidane (1):
> net/mlx5: fix Tx check for hardware descriptor length
>
> Rohit Raj (1):
> net/dpaa: fix jumbo packet Rx in case of VSP
>
> Satha Rao (1):
> common/cnxk: fix schedule weight update
>
> Satheesh Paul (3):
> common/cnxk: fix log level during MCAM allocation
> common/cnxk: fix missing flow counter reset
> common/cnxk: fix printing disabled MKEX registers
>
> Shiqi Liu (2):
> node: check Rx element allocation
> dma/idxd: check DSA device allocation
>
> Shun Hao (4):
> net/mlx5: fix meter profile delete after disable
> net/mlx5: fix action flag data type
> net/mlx5: fix drop action validation
> net/mlx5: fix assert when creating meter policy
>
> Stephen Coleman (1):
> doc: fix typo depreciated instead of deprecated
>
> Stephen Hemminger (8):
> event/sw: fix device name in dump
> eal: fix data race in multi-process support
> pdump: do not allow enable/disable in primary process
> app/dumpcap: fix crash on cleanup
> app/dumpcap: fix pathname for output file
> app/testpmd: make quit flag volatile
> ring: remove leftover comment about watermark
> doc: avoid meson deprecation in setup
>
> Steve Yang (1):
> net/iavf: fix pattern check for flow director parser
>
> Steven Zou (1):
> common/iavf: avoid copy in async mode
>
> Sunyang Wu (1):
> test/crypto: fix debug messages
>
> Taekyung Kim (1):
> vdpa/ifc: handle data path update failure
>
> Tal Shnaiderman (1):
> net/mlx5: fix thread termination check on Windows
>
> Thomas Monjalon (2):
> drivers: remove unused build variable
> doc: add Rx buffer split capability for mlx5
>
> Ting Xu (1):
> net/ice/base: fix inner symmetric RSS hash in raw flow
>
> Tomasz Jonak (1):
> net/ice: fix null function pointer call
>
> Vanshika Shukla (1):
> net/dpaa2: fix DPDMUX error behaviour
>
> Viacheslav Ovsiienko (3):
> net/mlx5: fix check for orphan wait descriptor
> net/mlx5: fix single not inline packet storing
> net/mlx5: fix inline length exceeding descriptor limit
>
> Vladimir Medvedkin (2):
> test/hash: remove dead code in extendable bucket test
> test/hash: fix bulk lookup check
>
> Volodymyr Fialko (3):
> cryptodev: fix missing SHA3 algorithm strings
> eventdev: fix name of Rx conf type in documentation
> app/eventdev: fix limits in error message
>
> Wenwu Ma (1):
> examples/vhost: fix use after free
>
> Wenzhuo Lu (1):
> net/iavf: fix VLAN offload
>
> Yi Li (1):
> doc: fix maximum packet size of virtio driver
>
> Yiding Zhou (4):
> net/iavf: fix VLAN insertion
> net/iavf: revert VLAN insertion fix
> net/ice/base: fix duplicate flow rules
> net/iavf: add thread for event callbacks
>
> Yunjian Wang (2):
> net/bonding: fix array overflow in Rx burst
> net/bonding: fix double slave link status query
>
> Zhichao Zeng (3):
> net/ice: fix RSS hash update
> net/iavf: fix processing VLAN TCI in SSE path
> net/iavf: fix outer checksum flags
>
> Zhirun Yan (1):
> graph: fix node objects allocation
>
>
[-- Attachment #2: Type: text/html, Size: 22341 bytes --]
^ permalink raw reply [relevance 0%]
* [PATCH V8 0/8] telemetry: fix data truncation and conversion error and add hex integer API
` (5 preceding siblings ...)
2022-12-16 1:54 3% ` [PATCH V7 " Huisong Li
@ 2022-12-19 7:06 3% ` Huisong Li
2023-01-16 12:06 0% ` lihuisong (C)
6 siblings, 1 reply; 200+ results
From: Huisong Li @ 2022-12-19 7:06 UTC (permalink / raw)
To: dev
Cc: bruce.richardson, mb, andrew.rybchenko, huangdaode, liudongdong3,
fengchengwen, lihuisong
Some lib telemetry interfaces add the 'u32' and 'u64' data by the
rte_tel_data_add_dict/array_int API. This may cause data conversion
error or data truncation. This patch series uses 'u64' functions to
do this.
In addition, this patch series introduces two APIs to store unsigned
integer values as hexadecimal encoded strings in telemetry library.
---
-v8: fix the coding style in patch 7/8
-v7: replace sprintf with snprintf in patch 6/8
-v6: fix code alignment to keep in line with codes in the file
-v5:
- drop a refactor patch.
- no limit the bit width for xxx_uint_hex API.
-v4:
- remove 'u32' value type.
- add padding zero for hexadecimal value
-v3: fix a misspelling mistake in commit log.
-v2:
- fix ABI break warning.
- introduce two APIs to store u32 and u64 values as hexadecimal
encoded strings.
Huisong Li (8):
telemetry: move to header to controllable range
ethdev: fix possible data truncation and conversion error
mempool: fix possible data truncation and conversion error
cryptodev: fix possible data conversion error
mem: possible data truncation and conversion error
telemetry: support adding integer value as hexadecimal
test: add test cases for adding hex integer value API
ethdev: display capability values in hexadecimal format
app/test/test_telemetry_data.c | 150 +++++++++++++++++++++++++++++
lib/cryptodev/rte_cryptodev.c | 2 +-
lib/eal/common/eal_common_memory.c | 10 +-
lib/ethdev/rte_ethdev.c | 19 ++--
lib/mempool/rte_mempool.c | 24 ++---
lib/telemetry/rte_telemetry.h | 52 +++++++++-
lib/telemetry/telemetry_data.c | 73 ++++++++++++++
lib/telemetry/version.map | 9 ++
8 files changed, 309 insertions(+), 30 deletions(-)
--
2.33.0
^ permalink raw reply [relevance 3%]
* Re: [RFC PATCH 2/7] telemetry: add uint type as alias for u64
2022-12-15 13:58 4% ` Bruce Richardson
@ 2022-12-19 10:37 0% ` Thomas Monjalon
2022-12-19 13:22 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-12-19 10:37 UTC (permalink / raw)
To: Bruce Richardson; +Cc: Tyler Retzlaff, dev, Morten Brørup, david.marchand
15/12/2022 14:58, Bruce Richardson:
> On Thu, Dec 15, 2022 at 02:36:51PM +0100, Thomas Monjalon wrote:
> > 15/12/2022 10:44, Bruce Richardson:
> > > On Wed, Dec 14, 2022 at 09:38:45AM -0800, Tyler Retzlaff wrote:
> > > > On Tue, Dec 13, 2022 at 06:27:25PM +0000, Bruce Richardson wrote:
> > > > > For future standardization on the "uint" name for unsigned values rather
> > > > > than the existing "u64" one, we can for now:
> > > > > * rename all internal values to use uint rather than u64
> > > > > * add new function names to alias the existing u64 ones
> > > > >
> > > > > Suggested-by: Morten Brørup <mb@smartsharesystems.com>
> > > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > >
> > > > when adding __rte_experimental api i have been asked to add the
> > > > following boilerplate documentation block. i'm not pushing it, just
> > > > recalling it is what i get asked for, so in case it's something we do?
> > > > see lib/eal/include/rte_thread.h as an example
> > > >
> > > >
> > > > ```
> > > > * @warning
> > > > * @b EXPERIMENTAL: this API may change without prior notice.
> > > > ```
> > > >
> > >
> > > Ok, thanks for the notice.
> > >
> > > Actually, related to this, since we are adding these functions as aliases
> > > for existing stable functions, I would like to see these being added not as
> > > experimental. The reason for that, is that while they are experimental, we
> > > cannot feasibly mark the old function names as deprecated. :-(
> > >
> > > Adding Thomas and David on CC for their thoughts.
> >
> > Is it related to telemetry?
> >
> > In general, yes we cannot deprecate something if there is no stable replacement.
> > The recommended step is to introduce a new experimental API
> > and deprecate the old one when the new API is stable.
> >
> Yes, understood.
> What we are really trying to do here is to rename an API, by process of
> adding the new API and then marking the old one as deprecated. The small
> issue is that adding the new one it is by default experimental, meaning we
> need to wait for deprecating old one. Ideally, as soon as the new API is
> added, we would like to point people to use that, but can't really do so
> while it is experimental.
>
> ---
>
> By way of explicit detail, Morten pointed out the inconsistency in the
> telemetry APIs and types:
>
> * we have add_*_int, which takes a 32-bit signed value
> * we have add_*_u64 which takes 64-bit unsigned (as name suggests).
>
> The ideal end-state is to always use 64-bit values (since there is no space
> saving from 32-bit as a union is used), and just name everything as "int"
> or "uint" for signed/unsigned. The two big steps here are:
>
> * expanding type of the "int" functions to take 64-bit parameters - this is
> ABI change but not API one, since existing code will happily promote
> values on compile. Therefore, we just use ABI versioning to have a 32-bit
> version for older linked binaries.
> * the rename of the rte_tel_data_add_array_u64 and
> rte_tel_data_add_dict_u64 to *_uint variants. Though keeping
> compatibility is easier, as we can just add new functions, the overall
> process is slower since the new functions technically should be added as
> experimental - hence the email. For the case of function renaming, do we
> still need to have the "renamed" versions as experimental initially?
If a function is simply renamed, I think there is no need for the experimental step.
Would we keep an alias with the old name for some time?
^ permalink raw reply [relevance 0%]
* Re: [RFC PATCH 2/7] telemetry: add uint type as alias for u64
2022-12-19 10:37 0% ` Thomas Monjalon
@ 2022-12-19 13:22 0% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2022-12-19 13:22 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: Tyler Retzlaff, dev, Morten Brørup, david.marchand
On Mon, Dec 19, 2022 at 11:37:19AM +0100, Thomas Monjalon wrote:
> 15/12/2022 14:58, Bruce Richardson:
> > On Thu, Dec 15, 2022 at 02:36:51PM +0100, Thomas Monjalon wrote:
> > > 15/12/2022 10:44, Bruce Richardson:
> > > > On Wed, Dec 14, 2022 at 09:38:45AM -0800, Tyler Retzlaff wrote:
> > > > > On Tue, Dec 13, 2022 at 06:27:25PM +0000, Bruce Richardson wrote:
> > > > > > For future standardization on the "uint" name for unsigned values rather
> > > > > > than the existing "u64" one, we can for now:
> > > > > > * rename all internal values to use uint rather than u64
> > > > > > * add new function names to alias the existing u64 ones
> > > > > >
> > > > > > Suggested-by: Morten Brørup <mb@smartsharesystems.com>
> > > > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > > >
> > > > > when adding __rte_experimental api i have been asked to add the
> > > > > following boilerplate documentation block. i'm not pushing it, just
> > > > > recalling it is what i get asked for, so in case it's something we do?
> > > > > see lib/eal/include/rte_thread.h as an example
> > > > >
> > > > >
> > > > > ```
> > > > > * @warning
> > > > > * @b EXPERIMENTAL: this API may change without prior notice.
> > > > > ```
> > > > >
> > > >
> > > > Ok, thanks for the notice.
> > > >
> > > > Actually, related to this, since we are adding these functions as aliases
> > > > for existing stable functions, I would like to see these being added not as
> > > > experimental. The reason for that, is that while they are experimental, we
> > > > cannot feasibly mark the old function names as deprecated. :-(
> > > >
> > > > Adding Thomas and David on CC for their thoughts.
> > >
> > > Is it related to telemetry?
> > >
> > > In general, yes we cannot deprecate something if there is no stable replacement.
> > > The recommended step is to introduce a new experimental API
> > > and deprecate the old one when the new API is stable.
> > >
> > Yes, understood.
> > What we are really trying to do here is to rename an API, by process of
> > adding the new API and then marking the old one as deprecated. The small
> > issue is that adding the new one it is by default experimental, meaning we
> > need to wait for deprecating old one. Ideally, as soon as the new API is
> > added, we would like to point people to use that, but can't really do so
> > while it is experimental.
> >
> > ---
> >
> > By way of explicit detail, Morten pointed out the inconsistency in the
> > telemetry APIs and types:
> >
> > * we have add_*_int, which takes a 32-bit signed value
> > * we have add_*_u64 which takes 64-bit unsigned (as name suggests).
> >
> > The ideal end-state is to always use 64-bit values (since there is no space
> > saving from 32-bit as a union is used), and just name everything as "int"
> > or "uint" for signed/unsigned. The two big steps here are:
> >
> > * expanding type of the "int" functions to take 64-bit parameters - this is
> > ABI change but not API one, since existing code will happily promote
> > values on compile. Therefore, we just use ABI versioning to have a 32-bit
> > version for older linked binaries.
> > * the rename of the rte_tel_data_add_array_u64 and
> > rte_tel_data_add_dict_u64 to *_uint variants. Though keeping
> > compatibility is easier, as we can just add new functions, the overall
> > process is slower since the new functions technically should be added as
> > experimental - hence the email. For the case of function renaming, do we
> > still need to have the "renamed" versions as experimental initially?
>
> If a function is simply renamed, I think there is no need for the experimental step.
> Would we keep an alias with the old name for some time?
>
Yes, the old name should go through the deprecation process. No
hurry with removal.
/Bruce
^ permalink raw reply [relevance 0%]
* DPDK 21.11.3 released
@ 2022-12-20 16:22 1% Kevin Traynor
0 siblings, 0 replies; 200+ results
From: Kevin Traynor @ 2022-12-20 16:22 UTC (permalink / raw)
To: ktraynor, kevin, announce
Hi all,
Here is a new stable release:
https://fast.dpdk.org/rel/dpdk-21.11.3.tar.xz
The git tree is at:
https://dpdk.org/browse/dpdk-stable/?h=21.11
Release notes can be found here:
http://doc.dpdk.org/guides-21.11/rel_notes/release_21_11.html#id5
This LTS release contains ~300 fixes from main branch
up to DPDK 22.11.
Thanks to the authors who helped with backports and to the
following who helped with validation:
Ubuntu, Intel, Nvidia and Red Hat.
Kevin.
---
.github/workflows/build.yml | 23 +-
VERSION | 2 +-
app/dumpcap/main.c | 10 +-
app/test-eventdev/test_pipeline_common.c | 4 +-
app/test-pmd/cmdline.c | 62 +++-
app/test-pmd/config.c | 4 -
app/test-pmd/csumonly.c | 6 +
app/test-pmd/meson.build | 1 +
app/test-pmd/noisy_vnf.c | 2 +-
app/test-pmd/testpmd.c | 25 +-
app/test-pmd/testpmd.h | 4 +-
app/test/test_common.c | 56 ++-
app/test/test_cryptodev.c | 20 +-
app/test/test_cryptodev_asym.c | 4 +-
.../test_cryptodev_security_pdcp_test_vectors.h | 280 +++++++--------
app/test/test_efd_perf.c | 1 -
app/test/test_event_timer_adapter.c | 2 -
app/test/test_hash_perf.c | 11 +-
app/test/test_hash_readwrite_lf_perf.c | 1 -
app/test/test_ipsec.c | 9 +-
app/test/test_member.c | 1 -
app/test/test_member_perf.c | 1 -
app/test/test_pcapng.c | 42 ++-
app/test/test_trace.c | 55 +--
app/test/test_trace.h | 2 +
buildtools/get-numa-count.py | 3 +-
devtools/checkpatches.sh | 37 +-
doc/guides/contributing/abi_policy.rst | 2 +-
doc/guides/contributing/abi_versioning.rst | 2 +-
doc/guides/cryptodevs/armv8.rst | 2 +-
doc/guides/cryptodevs/bcmfs.rst | 2 +-
doc/guides/freebsd_gsg/build_dpdk.rst | 2 +-
doc/guides/gpus/cuda.rst | 4 +-
doc/guides/howto/openwrt.rst | 2 +-
doc/guides/linux_gsg/build_dpdk.rst | 8 +-
.../linux_gsg/cross_build_dpdk_for_arm64.rst | 12 +-
doc/guides/nics/ark.rst | 2 +-
doc/guides/nics/features.rst | 2 +-
doc/guides/nics/features/bnxt.ini | 4 +-
doc/guides/nics/features/cxgbe.ini | 4 +-
doc/guides/nics/features/default.ini | 1 +
doc/guides/nics/features/dpaa2.ini | 4 +-
doc/guides/nics/features/e1000.ini | 2 +-
doc/guides/nics/features/enic.ini | 4 +-
doc/guides/nics/features/hinic.ini | 2 +-
doc/guides/nics/features/hns3.ini | 4 +-
doc/guides/nics/features/i40e.ini | 4 +-
doc/guides/nics/features/iavf.ini | 4 +-
doc/guides/nics/features/ice.ini | 4 +-
doc/guides/nics/features/igc.ini | 2 +-
doc/guides/nics/features/ipn3ke.ini | 4 +-
doc/guides/nics/features/ixgbe.ini | 4 +-
doc/guides/nics/features/mlx4.ini | 4 +-
doc/guides/nics/features/mlx5.ini | 1 +
doc/guides/nics/features/mvpp2.ini | 4 +-
doc/guides/nics/features/tap.ini | 4 +-
doc/guides/nics/features/txgbe.ini | 4 +-
doc/guides/nics/intel_vf.rst | 17 +
doc/guides/nics/mlx5.rst | 2 +
doc/guides/nics/mvneta.rst | 2 +-
doc/guides/nics/mvpp2.rst | 2 +-
doc/guides/nics/virtio.rst | 2 +-
doc/guides/platform/bluefield.rst | 4 +-
doc/guides/platform/cnxk.rst | 4 +-
doc/guides/platform/octeontx.rst | 8 +-
doc/guides/prog_guide/build-sdk-meson.rst | 39 +-
doc/guides/prog_guide/event_timer_adapter.rst | 15 +-
doc/guides/prog_guide/lto.rst | 2 +-
doc/guides/prog_guide/profile_app.rst | 4 +-
doc/guides/prog_guide/ring_lib.rst | 2 +-
doc/guides/prog_guide/trace_lib.rst | 14 +-
doc/guides/prog_guide/vhost_lib.rst | 6 +
doc/guides/rel_notes/release_21_11.rst | 391 +++++++++++++++++++++
doc/guides/sample_app_ug/dma.rst | 2 +-
doc/guides/sample_app_ug/vm_power_management.rst | 4 +-
doc/guides/testpmd_app_ug/run_app.rst | 1 +
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 12 +-
doc/guides/tools/dumpcap.rst | 4 +-
doc/guides/tools/proc_info.rst | 22 +-
doc/guides/windows_gsg/build_dpdk.rst | 4 +-
drivers/baseband/acc100/rte_acc100_pmd.c | 324 +++++++++++------
drivers/baseband/acc100/rte_acc100_pmd.h | 2 +
drivers/bus/auxiliary/auxiliary_common.c | 6 +
drivers/bus/dpaa/base/qbman/bman.h | 4 +-
drivers/common/cnxk/roc_nix_tm_ops.c | 60 ++--
drivers/common/cnxk/roc_npc_mcam.c | 4 +-
drivers/common/cnxk/roc_npc_mcam_dump.c | 6 +-
drivers/common/cnxk/roc_npc_utils.c | 2 +-
drivers/common/iavf/iavf_adminq.c | 3 +-
drivers/common/mlx5/mlx5_common.c | 21 +-
drivers/common/mlx5/mlx5_common_mr.c | 1 -
drivers/common/mlx5/mlx5_common_mr.h | 1 -
drivers/common/qat/qat_pf2vf.c | 4 +-
drivers/common/sfc_efx/base/ef10_nic.c | 2 +-
drivers/common/sfc_efx/base/rhead_virtio.c | 12 +-
drivers/compress/mlx5/meson.build | 1 -
drivers/crypto/mlx5/meson.build | 1 -
drivers/crypto/qat/qat_sym_session.c | 23 +-
drivers/dma/idxd/idxd_bus.c | 4 +
drivers/event/cnxk/cn10k_eventdev.c | 4 +
drivers/event/cnxk/cn9k_eventdev.c | 4 +
drivers/event/cnxk/cnxk_tim_worker.h | 1 +
drivers/event/dlb2/dlb2.c | 8 +-
drivers/event/dsw/dsw_evdev.h | 8 +-
drivers/event/dsw/dsw_event.c | 315 ++++++++++++-----
drivers/event/sw/sw_evdev.c | 4 +-
drivers/event/sw/sw_evdev_selftest.c | 7 +-
drivers/mempool/cnxk/cnxk_mempool_ops.c | 8 +
drivers/net/atlantic/atl_rxtx.c | 5 +-
drivers/net/axgbe/axgbe_rxtx.c | 133 ++++---
drivers/net/axgbe/axgbe_rxtx.h | 6 +
drivers/net/bnxt/bnxt_ethdev.c | 7 +-
drivers/net/bnxt/bnxt_hwrm.c | 2 +-
drivers/net/bnxt/tf_ulp/ulp_flow_db.h | 4 +-
drivers/net/bonding/rte_eth_bond_api.c | 5 +
drivers/net/bonding/rte_eth_bond_pmd.c | 102 +++---
drivers/net/cnxk/cn10k_rx.h | 12 +-
drivers/net/cnxk/cn10k_tx.h | 8 +-
drivers/net/cnxk/cn9k_tx.h | 8 +-
drivers/net/cnxk/cnxk_ethdev.c | 2 +-
drivers/net/dpaa/dpaa_ethdev.c | 23 +-
drivers/net/dpaa/dpaa_ethdev.h | 19 +
drivers/net/dpaa/dpaa_flow.c | 13 +-
drivers/net/dpaa/dpaa_flow.h | 5 +-
drivers/net/dpaa/dpaa_rxtx.c | 87 +++--
drivers/net/dpaa2/dpaa2_ethdev.c | 19 +
drivers/net/dpaa2/dpaa2_ethdev.h | 21 ++
drivers/net/dpaa2/dpaa2_mux.c | 2 +-
drivers/net/dpaa2/dpaa2_rxtx.c | 111 ++++--
drivers/net/enetfec/enet_ethdev.c | 4 +
drivers/net/enetfec/enet_rxtx.c | 29 +-
drivers/net/failsafe/failsafe_ops.c | 32 +-
drivers/net/hns3/hns3_cmd.h | 6 +
drivers/net/hns3/hns3_ethdev.c | 30 +-
drivers/net/hns3/hns3_ethdev.h | 3 +-
drivers/net/hns3/hns3_ethdev_vf.c | 25 +-
drivers/net/hns3/hns3_fdir.c | 3 +
drivers/net/hns3/hns3_flow.c | 259 ++++++++------
drivers/net/hns3/hns3_flow.h | 1 +
drivers/net/hns3/hns3_mbx.c | 8 +-
drivers/net/hns3/hns3_ptp.c | 1 -
drivers/net/hns3/hns3_rss.c | 291 ++++++++++-----
drivers/net/hns3/hns3_rss.h | 3 +-
drivers/net/hns3/hns3_rxtx.c | 125 +++----
drivers/net/hns3/hns3_rxtx_vec.c | 20 +-
drivers/net/hns3/hns3_rxtx_vec_sve.c | 13 +-
drivers/net/hns3/hns3_stats.c | 26 +-
drivers/net/i40e/i40e_ethdev.c | 45 +--
drivers/net/i40e/i40e_hash.c | 10 +-
drivers/net/i40e/i40e_vf_representor.c | 4 +-
drivers/net/iavf/iavf_ethdev.c | 1 +
drivers/net/iavf/iavf_fdir.c | 32 ++
drivers/net/iavf/iavf_ipsec_crypto.c | 29 +-
drivers/net/iavf/iavf_rxtx.c | 58 ++-
drivers/net/iavf/iavf_rxtx.h | 2 +
drivers/net/iavf/iavf_rxtx_vec_avx2.c | 118 +++++--
drivers/net/iavf/iavf_rxtx_vec_avx512.c | 133 +++++--
drivers/net/iavf/iavf_rxtx_vec_sse.c | 170 +++++++--
drivers/net/ice/base/ice_bst_tcam.c | 6 +-
drivers/net/ice/base/ice_common.c | 12 +-
drivers/net/ice/base/ice_dcb.c | 2 +-
drivers/net/ice/base/ice_flg_rd.c | 4 +-
drivers/net/ice/base/ice_flow.c | 16 +-
drivers/net/ice/base/ice_imem.c | 4 +-
drivers/net/ice/base/ice_metainit.c | 4 +-
drivers/net/ice/base/ice_mk_grp.c | 4 +-
drivers/net/ice/base/ice_parser.c | 7 +-
drivers/net/ice/base/ice_pg_cam.c | 12 +-
drivers/net/ice/base/ice_proto_grp.c | 4 +-
drivers/net/ice/base/ice_ptp_hw.c | 56 +--
drivers/net/ice/base/ice_ptype_mk.c | 4 +-
drivers/net/ice/base/ice_sched.c | 24 +-
drivers/net/ice/base/ice_switch.c | 15 +-
drivers/net/ice/base/ice_type.h | 30 +-
drivers/net/ice/base/ice_xlt_kb.c | 10 +-
drivers/net/ice/ice_ethdev.c | 19 +-
drivers/net/ice/ice_rxtx.c | 44 ++-
drivers/net/ice/ice_rxtx.h | 2 +
drivers/net/ionic/ionic_dev.c | 5 +-
drivers/net/ionic/ionic_lif.c | 6 +-
drivers/net/ionic/ionic_rx_filter.c | 2 +-
drivers/net/ionic/ionic_rxtx.c | 29 +-
drivers/net/ixgbe/ixgbe_ethdev.c | 12 +-
drivers/net/ixgbe/ixgbe_pf.c | 8 +-
drivers/net/memif/rte_eth_memif.c | 8 +-
drivers/net/mlx4/mlx4.c | 9 +-
drivers/net/mlx4/mlx4_mp.c | 7 +-
drivers/net/mlx5/linux/mlx5_ethdev_os.c | 22 +-
drivers/net/mlx5/linux/mlx5_mp_os.c | 6 +-
drivers/net/mlx5/linux/mlx5_os.c | 13 +-
drivers/net/mlx5/mlx5.c | 32 +-
drivers/net/mlx5/mlx5.h | 7 +-
drivers/net/mlx5/mlx5_devx.c | 3 +-
drivers/net/mlx5/mlx5_flow.c | 101 ++++--
drivers/net/mlx5/mlx5_flow.h | 82 +++--
drivers/net/mlx5/mlx5_flow_dv.c | 193 +++++-----
drivers/net/mlx5/mlx5_flow_meter.c | 3 +-
drivers/net/mlx5/mlx5_flow_verbs.c | 23 +-
drivers/net/mlx5/mlx5_rxq.c | 15 +-
drivers/net/mlx5/mlx5_trigger.c | 16 +
drivers/net/mlx5/mlx5_tx.h | 108 +++---
drivers/net/mlx5/mlx5_utils.c | 2 +-
drivers/net/mlx5/windows/mlx5_flow_os.c | 2 +-
drivers/net/mvneta/mvneta_rxtx.c | 4 +
drivers/net/nfp/nfp_common.c | 6 +-
drivers/net/nfp/nfp_ethdev.c | 12 +-
drivers/net/nfp/nfp_ethdev_vf.c | 1 -
drivers/net/nfp/nfp_rxtx.c | 12 +-
drivers/net/nfp/nfpcore/nfp_hwinfo.c | 2 +-
drivers/net/ngbe/base/ngbe_eeprom.c | 32 --
drivers/net/ngbe/base/ngbe_regs.h | 2 +-
drivers/net/ngbe/base/ngbe_type.h | 7 +-
drivers/net/ngbe/ngbe_ethdev.c | 20 +-
drivers/net/qede/base/ecore_init_fw_funcs.c | 2 +-
drivers/net/qede/base/ecore_int.c | 4 +-
drivers/net/tap/tap_flow.c | 2 +-
drivers/net/tap/tap_tcmsgs.c | 18 +-
drivers/net/tap/tap_tcmsgs.h | 16 +-
drivers/net/txgbe/base/txgbe_eeprom.c | 32 --
drivers/net/txgbe/base/txgbe_type.h | 4 +-
drivers/net/txgbe/txgbe_ethdev.c | 11 +-
drivers/net/txgbe/txgbe_flow.c | 33 +-
drivers/net/virtio/virtio_ethdev.c | 7 +
drivers/vdpa/ifc/ifcvf_vdpa.c | 27 +-
drivers/vdpa/sfc/meson.build | 1 -
examples/fips_validation/main.c | 4 +-
examples/ipsec-secgw/ipsec-secgw.c | 21 +-
examples/ipsec-secgw/sa.c | 52 ++-
examples/l2fwd-crypto/main.c | 2 +-
examples/l3fwd/l3fwd.h | 5 +
examples/l3fwd/l3fwd_event.c | 6 +
examples/l3fwd/main.c | 4 +-
examples/qos_sched/cfg_file.c | 2 +-
examples/qos_sched/profile.cfg | 2 -
examples/vhost/main.c | 21 +-
examples/vm_power_manager/channel_manager.c | 19 +-
lib/cryptodev/cryptodev_pmd.c | 4 +-
lib/cryptodev/cryptodev_pmd.h | 2 +-
lib/cryptodev/rte_cryptodev.c | 20 +-
lib/eal/common/eal_common_proc.c | 17 +-
lib/eal/common/eal_common_trace.c | 69 ++--
lib/eal/common/eal_common_trace_ctf.c | 3 -
lib/eal/common/eal_common_trace_utils.c | 11 +-
lib/eal/common/eal_trace.h | 3 +-
lib/eal/common/malloc_heap.c | 2 +-
lib/eal/common/malloc_mp.c | 2 +-
lib/eal/common/rte_service.c | 13 +-
lib/eal/include/rte_bitmap.h | 2 -
lib/eal/include/rte_common.h | 4 +-
lib/eal/include/rte_hexdump.h | 4 -
lib/eal/include/rte_memzone.h | 3 -
lib/eal/include/rte_uuid.h | 4 +-
lib/eventdev/rte_event_crypto_adapter.c | 30 +-
lib/eventdev/rte_event_eth_rx_adapter.h | 2 +-
lib/eventdev/rte_event_eth_tx_adapter.c | 15 +-
lib/fib/rte_fib.h | 2 -
lib/fib/rte_fib6.h | 2 -
lib/graph/rte_graph_worker.h | 4 +-
lib/gro/gro_tcp4.c | 8 +-
lib/gro/gro_udp4.c | 6 +-
lib/hash/rte_cuckoo_hash.c | 1 +
lib/hash/rte_thash.h | 2 -
lib/ipsec/esp_outb.c | 8 +-
lib/ipsec/rte_ipsec_sad.h | 2 -
lib/kni/rte_kni.h | 4 +-
lib/lpm/rte_lpm.h | 2 -
lib/lpm/rte_lpm6.h | 2 -
lib/mbuf/rte_mbuf.h | 3 -
lib/mempool/rte_mempool.c | 55 +--
lib/mempool/rte_mempool.h | 3 +-
lib/net/rte_ip.h | 17 +-
lib/node/ethdev_ctrl.c | 2 +
lib/pcapng/rte_pcapng.c | 47 ++-
lib/pdump/rte_pdump.c | 6 +
lib/power/rte_power.h | 55 ---
lib/reorder/rte_reorder.h | 2 -
lib/rib/rte_rib.h | 2 -
lib/rib/rte_rib6.h | 2 -
lib/ring/rte_ring.h | 15 +-
lib/ring/rte_ring_core.h | 4 +-
lib/ring/rte_ring_elem.h | 1 -
lib/ring/rte_ring_elem_pvt.h | 10 +
lib/sched/rte_sched.c | 2 -
lib/timer/rte_timer.c | 13 +-
lib/vhost/rte_vhost.h | 15 +
lib/vhost/rte_vhost_async.h | 18 +-
lib/vhost/version.map | 1 +
lib/vhost/vhost.c | 30 ++
lib/vhost/vhost_user.c | 1 +
lib/vhost/virtio_net.c | 12 +-
meson.build | 2 +-
291 files changed, 3988 insertions(+), 2219 deletions(-)
Abdullah Sevincer (1):
event/dlb2: handle enqueuing more than maximum depth
Abhimanyu Saini (1):
common/sfc_efx/base: remove VQ index check during VQ start
Aleksandr Miloshenko (1):
net/iavf: fix Tx done descriptors cleanup
Alex Kiselev (1):
net/tap: fix overflow of network interface index
Alexander Chernavin (1):
net/virtio: fix crash when configured twice
Alexander Kozyrev (3):
net/mlx5: fix shared Rx queue config reuse
net/mlx5: fix first segment inline length
net/mlx5: fix indexed pool local cache crash
Ali Alnubani (2):
examples/l2fwd-crypto: fix typo in error message
lib: remove empty return types from doxygen comments
Amit Prakash Shukla (6):
net/mvneta: fix build with GCC 12
test/ipsec: fix build with GCC 12
ipsec: fix build with GCC 12
crypto/qat: fix build with GCC 12
net/i40e: fix build with MinGW GCC 12
net/qede/base: fix 32-bit build with GCC 12
Andrew Boyer (5):
net/ionic: fix endianness for Rx and Tx
net/ionic: fix endianness for RSS
net/ionic: fix adapter name for logging
net/ionic: fix Rx filter save
net/ionic: fix reported error stats
Anoob Joseph (1):
test/crypto: fix PDCP vectors
Apeksha Gupta (2):
net/enetfec: fix restart
net/enetfec: fix buffer leak
Arek Kusztal (1):
common/qat: fix VF to PF answer
Ashwin Sekhar T K (1):
mempool/cnxk: fix destroying empty pool
Ben Magistro (1):
doc: fix dumpcap interface parameter option
Benjamin Le Berre (1):
net/bnxt: fix error code during MTU change
Bhagyada Modali (9):
net/axgbe: fix scattered Rx
net/axgbe: fix mbuf lengths in scattered Rx
net/axgbe: fix length of each segment in scattered Rx
net/axgbe: fix checksum and RSS in scattered Rx
net/axgbe: optimise scattered Rx
net/axgbe: remove freeing buffer in scattered Rx
net/axgbe: reset end of packet in scattered Rx
net/axgbe: clear buffer on scattered Rx chaining failure
net/axgbe: save segment data in scattered Rx
Bing Zhao (2):
net/mlx5: fix build with recent compilers
bus/auxiliary: prevent device from being probed again
Brian Dooley (1):
crypto/qat: fix null hash algorithm digest size
Changpeng Liu (1):
vhost: add non-blocking API for posting interrupt
Chaoyong He (1):
net/nfp: fix Rx descriptor DMA address
Chengwen Feng (8):
net/hns3: fix crash in SVE Tx
net/hns3: fix next-to-use overflow in SVE Tx
net/hns3: fix next-to-use overflow in simple Tx
net/hns3: fix crash when secondary process access FW
net/hns3: revert Tx performance optimization
net/hns3: revert fix mailbox communication with HW
net/hns3: fix VF mailbox message handling
app/testpmd: remove jumbo offload
Ciara Power (1):
test/crypto: fix wireless auth digest segment
Conor Walsh (1):
doc: fix reference to dma application example
Dariusz Sosnowski (1):
net/mlx5: fix hairpin split with set VLAN VID action
David Marchand (23):
vhost: fix virtqueue use after free on NUMA reallocation
app/testpmd: restore ixgbe bypass commands
net/failsafe: fix interrupt handle leak
net/bnxt: fix build with GCC 13
trace: fix mode for new trace point
trace: fix mode change
trace: fix leak with regexp
trace: fix dynamically enabling trace points
trace: fix race in debug dump
ci: bump versions of actions in GHA
ci: update to new API for step outputs in GHA
service: fix build with clang 15
vhost: fix build with clang 15
bus/dpaa: fix build with clang 15
net/atlantic: fix build with clang 15
net/dpaa2: fix build with clang 15
app/testpmd: fix build with clang 15
app/testpmd: fix build with clang 15 in flow code
test/efd: fix build with clang 15
test/member: fix build with clang 15
test/event: fix build with clang 15
ci: enable ABI check in GHA
trace: fix metadata dump
Dmitry Kozlyuk (4):
build: enable developer mode for all working trees
eal: fix side effect in some pointer arithmetic macros
mempool: make event callbacks process-private
common/mlx5: fix multi-process mempool registration
Dong Zhou (1):
net/mlx5: fix thread workspace memory leak
Dongdong Liu (2):
doc: fix application name in procinfo guide
doc: document device dump in procinfo guide
Erik Gabriel Carrillo (1):
service: fix early move to inactive status
Fidaullah Noonari (1):
malloc: fix storage size for some allocations
Frank Du (1):
net/ice: fix interrupt handler unregister
Gagandeep Singh (5):
net/dpaa: fix buffer freeing in slow path
net/dpaa: use internal mempool for SG table
net/dpaa: fix buffer freeing on SG Tx
net/dpaa2: use internal mempool for SG table
net/dpaa2: fix buffer freeing on SG Tx
Ganapati Kundapura (1):
eventdev/crypto: fix multi-process
Gregory Etelson (6):
net/mlx5: fix RSS expansion buffer size
app/testpmd: fix MAC header in checksum forward engine
common/mlx5: fix shared mempool subscription
net/mlx5: fix port initialization with small LRO
net/mlx5: fix maximum LRO message size
doc: add LRO size limitation in mlx5 guide
Haiyue Wang (1):
ring: fix description
Hamza Khan (1):
examples/vm_power_manager: use safe list iterator
Hanumanth Pothula (1):
net/cnxk: fix DF bit in vector mode
Hernan Vargas (14):
baseband/acc100: fix memory leak
baseband/acc100: check turbo dec/enc input
baseband/acc100: add null checks
baseband/acc100: fix input length for CRC24B
baseband/acc100: fix clearing PF IR outside handler
baseband/acc100: fix device minimum alignment
baseband/acc100: fix close cleanup
baseband/acc100: add LDPC encoder padding function
baseband/acc100: check AQ availability
baseband/acc100: fix ring availability calculation
baseband/acc100: enforce additional check on FCW
baseband/acc100: fix null HARQ input case
baseband/acc100: fix ring/queue allocation
baseband/acc100: fix double MSI intr in TB mode
Huisong Li (18):
net/hns3: fix Rx with PTP
net/hns3: delete unused markup
net/hns3: fix clearing hardware MAC statistics
net/hns3: fix RSS filter restore
net/hns3: fix RSS flow rule restore
net/hns3: move flow direction rule recovery
net/hns3: fix packet type for GENEVE
net/hns3: fix IPv4 and IPv6 RSS
net/hns3: fix typos in IPv6 SCTP fields
net/hns3: fix IPv4 RSS
net/hns3: add L3 and L4 RSS types
net/bonding: fix slave device Rx/Tx offload configuration
net/bonding: fix dropping valid MAC packets
net/bonding: fix mbuf fast free handling
net/hns3: extract functions to create RSS and FDIR flow rule
net/hns3: fix RSS rule restore
net/hns3: fix lock protection of RSS flow rule
net/hns3: fix restore filter function input
Huzaifa Rahman (1):
net/memif: fix crash with different number of Rx/Tx queues
Ilya Maximets (1):
doc: fix support table for Ethernet/VLAN flow items
Ivan Malov (4):
common/sfc_efx/base: fix maximum Tx data count
net/bonding: fix descriptor limit reporting
net/bonding: fix flow flush order on close
net/bonding: set initial value of descriptor count alignment
James Hershaw (1):
net/nfp: improve HW info header log readability
Jeremy Spewock (1):
test/ipsec: skip if no compatible device
Jerin Jacob (2):
eal: fix doxygen comments for UUID
power: fix some doxygen comments
Jiawei Wang (4):
net/mlx5: fix modify action with tunnel decapsulation
net/mlx5: fix tunnel header with IPIP offload
net/mlx5: fix source port checking in sample flow rule
net/mlx5: fix mirror flow validation with ASO action
Jiawen Wu (6):
net/txgbe: fix IPv6 flow rule
net/txgbe: remove semaphore between SW/FW
net/txgbe: rename some extended statistics
net/ngbe: rename some extended statistics
net/ngbe: remove semaphore between SW/FW
net/ngbe: fix maximum frame size
Jie Hai (1):
net/hns3: fix minimum Tx frame length
Jie Wang (1):
net/i40e: fix jumbo frame Rx with X722
Jun Qiu (3):
gro: trim tail padding bytes
net/bonding: fix Tx hash for TCP
hash: fix RCU configuration memory leak
Kai Ji (1):
test/crypto: fix bitwise operator in a SNOW3G case
Kalesh AP (2):
net/bnxt: remove unnecessary check
net/bnxt: fix representor info freeing
Ke Zhang (2):
net/i40e: fix VF representor release
net/iavf: fix L3 checksum Tx offload flag
Kevin Liu (2):
net/iavf: check illegal packet sizes
net/ice: check illegal packet sizes
Kevin Traynor (9):
Revert "cryptodev: fix missing SHA3 algorithm strings"
version: 21.11.3-rc1
Revert "net/i40e: fix jumbo frame Rx with X722"
Revert "net/i40e: fix max frame size config at port level"
Revert "net/i40e: enable maximum frame size at port level"
Revert "net/iavf: add thread for event callbacks"
vhost: fix doxygen warnings
ring: squash gcc 12.2.1 warnings
version: 21.11.3
Kumara Parameshwaran (1):
gro: check payload length after trim
Long Li (2):
net/mlx4: fix Verbs FD leak in secondary process
net/mlx5: fix Verbs FD leak in secondary process
Long Wu (1):
net/nfp: fix memory leak in Rx
Luca Boccassi (1):
drivers: fix typos found by Lintian
Mao YingMing (1):
net/bnxt: fix null pointer dereference in LED config
Mattias Rönnblom (3):
net: accept unaligned data in checksum routines
event/dsw: fix flow migration
doc: fix event timer adapter guide
Maxime Coquelin (1):
vhost: fix build with GCC 12
Megha Ajmera (2):
sched: fix subport profile configuration
examples/qos_sched: fix number of subport profiles
Michael Baum (5):
net/mlx5: fix null check in devargs parsing
doc: fix underlines in testpmd guide
doc: fix colons in testpmd aged flow rules
net/mlx5: fix race condition in counter pool resizing
net/mlx5: fix port event cleaning order
Mingjin Ye (4):
net/ice: support VXLAN-GPE tunnel offload
net/i40e: fix pctype configuration for X722
net/ice: fix scalar Rx path segment
net/ice: fix scalar Tx path segment
Mário Kuka (1):
pcapng: fix write more packets than IOV_MAX limit
Naga Harish K S V (4):
eventdev/eth_tx: add spinlock for adapter start/stop
eventdev/eth_tx: fix adapter stop
timer: fix stopping all timers
eventdev/eth_tx: fix queue delete
Nithin Dabilpuram (3):
examples/ipsec-secgw: use Tx checksum offload conditionally
examples/l3fwd: fix MTU configuration with event mode
net/cnxk: fix later skip to include mbuf private data
Olivier Matz (8):
cryptodev: fix unduly newlines in logs
mem: fix API doc about allocation on secondary processes
event/sw: fix flow ID init in self test
event/sw: fix log in self test
net/ixgbe: fix broadcast Rx on VF after promisc removal
net/ixgbe: fix unexpected VLAN Rx in promisc mode on VF
net/ixgbevf: fix promiscuous and allmulti
devtools: fix checkpatch header retrieval from stdin
Pablo de Lara (1):
examples/fips_validation: fix typo in error log
Pavan Nikhilesh (3):
event/cnxk: fix missing xstats operations
event/cnxk: fix mbuf offset calculation
event/cnxk: fix missing mempool cookie marking
Peng Zhang (3):
net/nfp: compose firmware file name with new hwinfo
buildtools: fix NUMA nodes count
net/nfp: fix internal buffer size and MTU check
Qi Zhang (12):
net/ice/base: fix division during E822 PTP init
net/ice/base: fix 100M speed capability
net/ice/base: fix DSCP PFC TLV creation
net/ice/base: fix media type of PHY 10G SFI C2C
net/ice/base: fix function descriptions for parser
net/ice/base: fix endian format
net/ice/base: fix array overflow in add switch recipe
net/ice/base: fix bit finding range over ptype bitmap
net/ice/base: fix add MAC rule
net/ice/base: fix double VLAN in promiscuous mode
net/ice/base: ignore promiscuous already exist
net/ice/base: fix input set of GTPoGRE
Qiming Yang (1):
app/testpmd: skip port reset in secondary process
Radu Nicolau (6):
net/iavf: update IPsec ESN values when updating session
net/iavf: fix IPsec flow create error check
net/iavf: fix SPI check
net/iavf: fix queue stop for large VF
examples/ipsec-secgw: fix Tx checksum offload flag
examples/ipsec-secgw: fix Tx checksum offload flag
Raja Zidane (1):
net/mlx5: fix Tx check for hardware descriptor length
Rohit Raj (1):
net/dpaa: fix jumbo packet Rx in case of VSP
Satha Rao (1):
common/cnxk: fix schedule weight update
Satheesh Paul (3):
common/cnxk: fix log level during MCAM allocation
common/cnxk: fix missing flow counter reset
common/cnxk: fix printing disabled MKEX registers
Shiqi Liu (2):
node: check Rx element allocation
dma/idxd: check DSA device allocation
Shun Hao (4):
net/mlx5: fix meter profile delete after disable
net/mlx5: fix action flag data type
net/mlx5: fix drop action validation
net/mlx5: fix assert when creating meter policy
Stephen Coleman (1):
doc: fix typo depreciated instead of deprecated
Stephen Hemminger (8):
event/sw: fix device name in dump
eal: fix data race in multi-process support
pdump: do not allow enable/disable in primary process
app/dumpcap: fix crash on cleanup
app/dumpcap: fix pathname for output file
app/testpmd: make quit flag volatile
ring: remove leftover comment about watermark
doc: avoid meson deprecation in setup
Steve Yang (1):
net/iavf: fix pattern check for flow director parser
Steven Zou (1):
common/iavf: avoid copy in async mode
Sunyang Wu (1):
test/crypto: fix debug messages
Taekyung Kim (1):
vdpa/ifc: handle data path update failure
Tal Shnaiderman (1):
net/mlx5: fix thread termination check on Windows
Thomas Monjalon (2):
drivers: remove unused build variable
doc: add Rx buffer split capability for mlx5
Ting Xu (1):
net/ice/base: fix inner symmetric RSS hash in raw flow
Tomasz Jonak (1):
net/ice: fix null function pointer call
Vanshika Shukla (1):
net/dpaa2: fix DPDMUX error behaviour
Viacheslav Ovsiienko (3):
net/mlx5: fix check for orphan wait descriptor
net/mlx5: fix single not inline packet storing
net/mlx5: fix inline length exceeding descriptor limit
Vladimir Medvedkin (2):
test/hash: remove dead code in extendable bucket test
test/hash: fix bulk lookup check
Volodymyr Fialko (3):
cryptodev: fix missing SHA3 algorithm strings
eventdev: fix name of Rx conf type in documentation
app/eventdev: fix limits in error message
Wenwu Ma (1):
examples/vhost: fix use after free
Wenzhuo Lu (1):
net/iavf: fix VLAN offload
Yi Li (1):
doc: fix maximum packet size of virtio driver
Yiding Zhou (4):
net/iavf: fix VLAN insertion
net/iavf: revert VLAN insertion fix
net/ice/base: fix duplicate flow rules
net/iavf: add thread for event callbacks
Yunjian Wang (2):
net/bonding: fix array overflow in Rx burst
net/bonding: fix double slave link status query
Zhichao Zeng (3):
net/ice: fix RSS hash update
net/iavf: fix processing VLAN TCI in SSE path
net/iavf: fix outer checksum flags
Zhirun Yan (1):
graph: fix node objects allocation
^ permalink raw reply [relevance 1%]
* Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
@ 2022-12-21 9:12 4% ` Jerin Jacob
2022-12-21 9:32 3% ` Rongwei Liu
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2022-12-21 9:12 UTC (permalink / raw)
To: Rongwei Liu
Cc: matan, viacheslavo, orika, thomas, Ferruh Yigit,
Andrew Rybchenko, dev, rasland
On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu <rongweil@nvidia.com> wrote:
>
> Users may want to change the DPDK process to different versions
Different version of DPDK? If there is any ABI change how to support this?
> such as hot upgrade.
> There is a strong requirement to simplify the logic and shorten the
> traffic downtime as much as possible.
>
> This update introduces new rte_eth process role definitions: active
> or standby.
>
> The active role means rules are programmed to HW immediately, and no
Why it has to be specific only to rte_flow rule? If it spedieic to
rte_flow, why it is in rte_eth_process_ name space?
Also, if we are moving the standby, What about the rule whose ABI is
changed between versions?
> behavior changed. This is the default state.
> The standby role means rules are queued in the HW. If no active roles
> alive or back to active, the rules are effective immediately.
>
> Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
> ---
> doc/guides/nics/mlx5.rst | 10 ++++
> doc/guides/rel_notes/release_22_03.rst | 5 ++
> lib/ethdev/ethdev_driver.h | 63 ++++++++++++++++++++++++++
> lib/ethdev/rte_ethdev.c | 41 +++++++++++++++++
> lib/ethdev/rte_ethdev.h | 7 ++-
> lib/ethdev/version.map | 3 ++
> 6 files changed, 128 insertions(+), 1 deletion(-)
>
> diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
> index 51f51259e3..de1fdac0a1 100644
> --- a/doc/guides/nics/mlx5.rst
> +++ b/doc/guides/nics/mlx5.rst
> @@ -2001,3 +2001,13 @@ where:
> * ``sw_queue_id``: queue index in range [64536, 65535].
> This range is the highest 1000 numbers.
> * ``hw_queue_id``: queue index given by HW in queue creation.
> +
> +ethdev set process active or standby
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +User should only program group 0 (fdb_def_rule_en=0) when ``rte_eth_process_set_active``
> +has been called and set to a standby role.
> +Group 0 is shared across different DPDK processes while the other groups are limited
> +to the current process scope.
> +The process can't move from active to standby role if preceding active application's
> +rules are still present and vice versa.
> diff --git a/doc/guides/rel_notes/release_22_03.rst b/doc/guides/rel_notes/release_22_03.rst
> index 0923707cb8..6fa48106c4 100644
> --- a/doc/guides/rel_notes/release_22_03.rst
> +++ b/doc/guides/rel_notes/release_22_03.rst
> @@ -207,6 +207,11 @@ API Changes
> * ethdev: Old public macros and enumeration constants without ``RTE_ETH_`` prefix,
> which are kept for backward compatibility, are marked as deprecated.
>
> +* ethdev: added a new experimental api:
> +
> + The new API ``rte_eth_process_set_active()`` was added.
> + If ``RTE_ETH_CAPA_PROCESS_SET_ROLE`` is not advertised, this new api is not supported.
> +
> * cryptodev: The asymmetric session handling was modified to use a single
> mempool object. An API ``rte_cryptodev_asym_session_pool_create`` was added
> to create a mempool with element size big enough to hold the generic asymmetric
> diff --git a/lib/ethdev/ethdev_driver.h b/lib/ethdev/ethdev_driver.h
> index 6a550cfc83..3c583bc39d 100644
> --- a/lib/ethdev/ethdev_driver.h
> +++ b/lib/ethdev/ethdev_driver.h
> @@ -179,6 +179,16 @@ struct rte_eth_dev_data {
> pthread_mutex_t flow_ops_mutex; /**< rte_flow ops mutex */
> } __rte_cache_aligned;
>
> +/**@{@name Different rte_eth role flag definitions which will be used
> + * when miagrating DPDK to a different version.
> + */
> +/*
> + * Traffic coming from NIC domain rules will reach
> + * both active and standby processes.
> + */
> +#define RTE_ETH_PROCESS_NIC_DUP_WITH_STANDBY RTE_BIT32(0),
> +/**@}*/
> +
> /**
> * @internal
> * The pool of *rte_eth_dev* structures. The size of the pool
> @@ -1087,6 +1097,22 @@ typedef const uint32_t *(*eth_buffer_split_supported_hdr_ptypes_get_t)(struct rt
> */
> typedef int (*eth_dev_priv_dump_t)(struct rte_eth_dev *dev, FILE *file);
>
> +/**
> + * @internal
> + * Set rte_eth process to active or standby role.
> + *
> + * @param dev
> + * Port (ethdev) handle.
> + * @param active
> + * Device (role) active or not (standby).
> + * @param flag
> + * Role specific flag.
> + *
> + * @return
> + * Negative value on error, 0 on success.
> + */
> +typedef int (*eth_process_set_active_t)(struct rte_eth_dev *dev, bool active, uint32_t flag);
> +
> /**
> * @internal Set Rx queue available descriptors threshold.
> * @see rte_eth_rx_avail_thresh_set()
> @@ -1403,6 +1429,8 @@ struct eth_dev_ops {
> eth_cman_config_set_t cman_config_set;
> /** Retrieve congestion management configuration */
> eth_cman_config_get_t cman_config_get;
> + /** Set the whole rte_eth process to active or standby role. */
> + eth_process_set_active_t eth_process_set_active;
> };
>
> /**
> @@ -2046,6 +2074,41 @@ struct rte_eth_fdir_conf {
> struct rte_eth_fdir_flex_conf flex_conf;
> };
>
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice
> + *
> + * Set the rte_eth process to the active or standby role which affects
> + * the flow rules offloading. It doesn't allow multiple processes to be the
> + * same role unless no offload rules are set.
> + * The active process flow rules are effective immediately while the standby
> + * process rules will be matched (active) when the process becomes active or
> + * when the traffic is not matched by the active process rules.
> + * The active application will always receive traffic while the standby
> + * application will receive traffic when no matching rules are present from
> + * the active application.
> + *
> + * The application is active by default if this API is not called.
> + *
> + * When a process transforms from a standby to a active role, all preceding
> + * flow rules which are queued by hardware will be effective immediately.
> + * Before role transition, all the rules set by the active process should be
> + * flushed first.
> + *
> + * When role flag "RTE_ETH_PROCESS_NIC_DUP_WITH_STANDBY" is set, NIC domain
> + * flow rules are effective immediately even if a process is standby role.
> + *
> + * @param active
> + * Process active (role) or not (standby).
> + * @param flag
> + * The role flag.
> + * @return
> + * - (>=0) Number of rte devices which have been switched successfully.
> + * - (-EINVAL) if bad parameter.
> + */
> +__rte_experimental
> +int rte_eth_process_set_active(bool active, uint32_t flag);
> +
> #ifdef __cplusplus
> }
> #endif
> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
> index 5d5e18db1e..f19da75bfe 100644
> --- a/lib/ethdev/rte_ethdev.c
> +++ b/lib/ethdev/rte_ethdev.c
> @@ -6318,6 +6318,47 @@ rte_eth_buffer_split_get_supported_hdr_ptypes(uint16_t port_id, uint32_t *ptypes
> return j;
> }
>
> +int rte_eth_process_set_active(bool active, uint32_t flag)
> +{
> + struct rte_eth_dev_info dev_info = {0};
> + uint32_t flags[RTE_MAX_ETHPORTS];
> + struct rte_eth_dev *dev;
> + uint16_t port_id;
> + int ret = 0;
> +
> + /* Check if all devices support. */
> + RTE_ETH_FOREACH_DEV(port_id) {
> + dev = &rte_eth_devices[port_id];
> + if (*dev->dev_ops->dev_infos_get == NULL ||
> + *dev->dev_ops->eth_process_set_active == NULL)
> + return -ENOTSUP;
> + if ((*dev->dev_ops->dev_infos_get)(dev, &dev_info))
> + return -EINVAL;
> + if (!(dev_info.dev_capa & RTE_ETH_CAPA_PROCESS_SET_ROLE))
> + return -ENOTSUP;
> + }
> + RTE_ETH_FOREACH_DEV(port_id) {
> + dev = &rte_eth_devices[port_id];
> + if ((*dev->dev_ops->dev_infos_get)(dev, &dev_info))
> + goto err;
> + flags[port_id] = dev_info.eth_process_flag;
> + if ((*dev->dev_ops->eth_process_set_active)(dev, active, flag) < 0)
> + goto err;
> + ret++;
> + }
> + return ret;
> +err:
> + if (!ret)
> + return 0;
> + RTE_ETH_FOREACH_DEV(port_id) {
> + dev = &rte_eth_devices[port_id];
> + (*dev->dev_ops->eth_process_set_active)(dev, !active, flags[port_id]);
> + if (--ret == 0)
> + break;
> + }
> + return 0;
> +}
> +
> RTE_LOG_REGISTER_DEFAULT(rte_eth_dev_logtype, INFO);
>
> RTE_INIT(ethdev_init_telemetry)
> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> index c129ca1eaf..d29f051d6f 100644
> --- a/lib/ethdev/rte_ethdev.h
> +++ b/lib/ethdev/rte_ethdev.h
> @@ -1606,6 +1606,8 @@ struct rte_eth_conf {
> #define RTE_ETH_DEV_CAPA_FLOW_RULE_KEEP RTE_BIT64(3)
> /** Device supports keeping shared flow objects across restart. */
> #define RTE_ETH_DEV_CAPA_FLOW_SHARED_OBJECT_KEEP RTE_BIT64(4)
> +/**Device supports "rte_eth_process_set_active" callback. */
> +#define RTE_ETH_CAPA_PROCESS_SET_ROLE RTE_BIT64(5)
> /**@}*/
>
> /*
> @@ -1777,8 +1779,11 @@ struct rte_eth_dev_info {
> struct rte_eth_switch_info switch_info;
> /** Supported error handling mode. */
> enum rte_eth_err_handle_mode err_handle_mode;
> + /** Process specific role flag. */
> + uint32_t eth_process_flag;
>
> - uint64_t reserved_64s[2]; /**< Reserved for future fields */
> + uint32_t reserved_32s[1]; /**< Reserved for future fields */
> + uint64_t reserved_64s[1]; /**< Reserved for future fields */
> void *reserved_ptrs[2]; /**< Reserved for future fields */
> };
>
> diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map
> index 17201fbe0f..a5503f6fde 100644
> --- a/lib/ethdev/version.map
> +++ b/lib/ethdev/version.map
> @@ -298,6 +298,9 @@ EXPERIMENTAL {
> rte_flow_get_q_aged_flows;
> rte_mtr_meter_policy_get;
> rte_mtr_meter_profile_get;
> +
> + # added in 23.03
> + rte_eth_process_set_active;
> };
>
> INTERNAL {
> --
> 2.27.0
>
^ permalink raw reply [relevance 4%]
* RE: [RFC v3 2/2] ethdev: add API to set process to active or standby
2022-12-21 9:12 4% ` Jerin Jacob
@ 2022-12-21 9:32 3% ` Rongwei Liu
2022-12-21 10:59 5% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Rongwei Liu @ 2022-12-21 9:32 UTC (permalink / raw)
To: Jerin Jacob
Cc: Matan Azrad, Slava Ovsiienko, Ori Kam,
NBU-Contact-Thomas Monjalon (EXTERNAL),
Ferruh Yigit, Andrew Rybchenko, dev, Raslan Darawsheh
HI Jerin:
BR
Rongwei
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Wednesday, December 21, 2022 17:13
> To: Rongwei Liu <rongweil@nvidia.com>
> Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> <ferruh.yigit@amd.com>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> <rasland@nvidia.com>
> Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
>
> External email: Use caution opening links or attachments
>
>
> On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu <rongweil@nvidia.com> wrote:
> >
> > Users may want to change the DPDK process to different versions
>
> Different version of DPDK? If there is any ABI change how to support this?
>
There is a new member which was introduced into rte_eth_dev_info but it shouldn’t be ABI breaking since using reserved fields.
> > such as hot upgrade.
> > There is a strong requirement to simplify the logic and shorten the
> > traffic downtime as much as possible.
> >
> > This update introduces new rte_eth process role definitions: active or
> > standby.
> >
> > The active role means rules are programmed to HW immediately, and no
>
> Why it has to be specific only to rte_flow rule? If it spedieic to rte_flow, why it
> is in rte_eth_process_ name space?
For now, this design focuses on the flow rule offloading and traffic redirection.
When switching process version, it' important to make sure which application receives and handles the traffic.
The changing should be effective across all probing eth devices, that' why it was put under rte_eth_process_ (for all rte_eth_dev) name space.
>
> Also, if we are moving the standby, What about the rule whose ABI is changed
> between versions?
Like the comments mentioned: " Before role transition, all the rules set by the active process should be flushed first. "
> > behavior changed. This is the default state.
> > The standby role means rules are queued in the HW. If no active roles
> > alive or back to active, the rules are effective immediately.
> >
> > Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
> > ---
> > doc/guides/nics/mlx5.rst | 10 ++++
> > doc/guides/rel_notes/release_22_03.rst | 5 ++
> > lib/ethdev/ethdev_driver.h | 63 ++++++++++++++++++++++++++
> > lib/ethdev/rte_ethdev.c | 41 +++++++++++++++++
> > lib/ethdev/rte_ethdev.h | 7 ++-
> > lib/ethdev/version.map | 3 ++
> > 6 files changed, 128 insertions(+), 1 deletion(-)
> >
> > diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst index
> > 51f51259e3..de1fdac0a1 100644
> > --- a/doc/guides/nics/mlx5.rst
> > +++ b/doc/guides/nics/mlx5.rst
> > @@ -2001,3 +2001,13 @@ where:
> > * ``sw_queue_id``: queue index in range [64536, 65535].
> > This range is the highest 1000 numbers.
> > * ``hw_queue_id``: queue index given by HW in queue creation.
> > +
> > +ethdev set process active or standby
> > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > +
> > +User should only program group 0 (fdb_def_rule_en=0) when
> > +``rte_eth_process_set_active`` has been called and set to a standby role.
> > +Group 0 is shared across different DPDK processes while the other
> > +groups are limited to the current process scope.
> > +The process can't move from active to standby role if preceding
> > +active application's rules are still present and vice versa.
> > diff --git a/doc/guides/rel_notes/release_22_03.rst
> > b/doc/guides/rel_notes/release_22_03.rst
> > index 0923707cb8..6fa48106c4 100644
> > --- a/doc/guides/rel_notes/release_22_03.rst
> > +++ b/doc/guides/rel_notes/release_22_03.rst
> > @@ -207,6 +207,11 @@ API Changes
> > * ethdev: Old public macros and enumeration constants without
> ``RTE_ETH_`` prefix,
> > which are kept for backward compatibility, are marked as deprecated.
> >
> > +* ethdev: added a new experimental api:
> > +
> > + The new API ``rte_eth_process_set_active()`` was added.
> > + If ``RTE_ETH_CAPA_PROCESS_SET_ROLE`` is not advertised, this new api
> is not supported.
> > +
> > * cryptodev: The asymmetric session handling was modified to use a single
> > mempool object. An API ``rte_cryptodev_asym_session_pool_create`` was
> added
> > to create a mempool with element size big enough to hold the
> > generic asymmetric diff --git a/lib/ethdev/ethdev_driver.h
> > b/lib/ethdev/ethdev_driver.h index 6a550cfc83..3c583bc39d 100644
> > --- a/lib/ethdev/ethdev_driver.h
> > +++ b/lib/ethdev/ethdev_driver.h
> > @@ -179,6 +179,16 @@ struct rte_eth_dev_data {
> > pthread_mutex_t flow_ops_mutex; /**< rte_flow ops mutex */ }
> > __rte_cache_aligned;
> >
> > +/**@{@name Different rte_eth role flag definitions which will be used
> > + * when miagrating DPDK to a different version.
> > + */
> > +/*
> > + * Traffic coming from NIC domain rules will reach
> > + * both active and standby processes.
> > + */
> > +#define RTE_ETH_PROCESS_NIC_DUP_WITH_STANDBY RTE_BIT32(0),
> /**@}*/
> > +
> > /**
> > * @internal
> > * The pool of *rte_eth_dev* structures. The size of the pool @@
> > -1087,6 +1097,22 @@ typedef const uint32_t
> *(*eth_buffer_split_supported_hdr_ptypes_get_t)(struct rt
> > */
> > typedef int (*eth_dev_priv_dump_t)(struct rte_eth_dev *dev, FILE
> > *file);
> >
> > +/**
> > + * @internal
> > + * Set rte_eth process to active or standby role.
> > + *
> > + * @param dev
> > + * Port (ethdev) handle.
> > + * @param active
> > + * Device (role) active or not (standby).
> > + * @param flag
> > + * Role specific flag.
> > + *
> > + * @return
> > + * Negative value on error, 0 on success.
> > + */
> > +typedef int (*eth_process_set_active_t)(struct rte_eth_dev *dev, bool
> > +active, uint32_t flag);
> > +
> > /**
> > * @internal Set Rx queue available descriptors threshold.
> > * @see rte_eth_rx_avail_thresh_set() @@ -1403,6 +1429,8 @@ struct
> > eth_dev_ops {
> > eth_cman_config_set_t cman_config_set;
> > /** Retrieve congestion management configuration */
> > eth_cman_config_get_t cman_config_get;
> > + /** Set the whole rte_eth process to active or standby role. */
> > + eth_process_set_active_t eth_process_set_active;
> > };
> >
> > /**
> > @@ -2046,6 +2074,41 @@ struct rte_eth_fdir_conf {
> > struct rte_eth_fdir_flex_conf flex_conf; };
> >
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice
> > + *
> > + * Set the rte_eth process to the active or standby role which
> > +affects
> > + * the flow rules offloading. It doesn't allow multiple processes to
> > +be the
> > + * same role unless no offload rules are set.
> > + * The active process flow rules are effective immediately while the
> > +standby
> > + * process rules will be matched (active) when the process becomes
> > +active or
> > + * when the traffic is not matched by the active process rules.
> > + * The active application will always receive traffic while the
> > +standby
> > + * application will receive traffic when no matching rules are
> > +present from
> > + * the active application.
> > + *
> > + * The application is active by default if this API is not called.
> > + *
> > + * When a process transforms from a standby to a active role, all
> > +preceding
> > + * flow rules which are queued by hardware will be effective immediately.
> > + * Before role transition, all the rules set by the active process
> > +should be
> > + * flushed first.
> > + *
> > + * When role flag "RTE_ETH_PROCESS_NIC_DUP_WITH_STANDBY" is set,
> NIC
> > +domain
> > + * flow rules are effective immediately even if a process is standby role.
> > + *
> > + * @param active
> > + * Process active (role) or not (standby).
> > + * @param flag
> > + * The role flag.
> > + * @return
> > + * - (>=0) Number of rte devices which have been switched successfully.
> > + * - (-EINVAL) if bad parameter.
> > + */
> > +__rte_experimental
> > +int rte_eth_process_set_active(bool active, uint32_t flag);
> > +
> > #ifdef __cplusplus
> > }
> > #endif
> > diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c index
> > 5d5e18db1e..f19da75bfe 100644
> > --- a/lib/ethdev/rte_ethdev.c
> > +++ b/lib/ethdev/rte_ethdev.c
> > @@ -6318,6 +6318,47 @@
> rte_eth_buffer_split_get_supported_hdr_ptypes(uint16_t port_id, uint32_t
> *ptypes
> > return j;
> > }
> >
> > +int rte_eth_process_set_active(bool active, uint32_t flag) {
> > + struct rte_eth_dev_info dev_info = {0};
> > + uint32_t flags[RTE_MAX_ETHPORTS];
> > + struct rte_eth_dev *dev;
> > + uint16_t port_id;
> > + int ret = 0;
> > +
> > + /* Check if all devices support. */
> > + RTE_ETH_FOREACH_DEV(port_id) {
> > + dev = &rte_eth_devices[port_id];
> > + if (*dev->dev_ops->dev_infos_get == NULL ||
> > + *dev->dev_ops->eth_process_set_active == NULL)
> > + return -ENOTSUP;
> > + if ((*dev->dev_ops->dev_infos_get)(dev, &dev_info))
> > + return -EINVAL;
> > + if (!(dev_info.dev_capa & RTE_ETH_CAPA_PROCESS_SET_ROLE))
> > + return -ENOTSUP;
> > + }
> > + RTE_ETH_FOREACH_DEV(port_id) {
> > + dev = &rte_eth_devices[port_id];
> > + if ((*dev->dev_ops->dev_infos_get)(dev, &dev_info))
> > + goto err;
> > + flags[port_id] = dev_info.eth_process_flag;
> > + if ((*dev->dev_ops->eth_process_set_active)(dev, active, flag) < 0)
> > + goto err;
> > + ret++;
> > + }
> > + return ret;
> > +err:
> > + if (!ret)
> > + return 0;
> > + RTE_ETH_FOREACH_DEV(port_id) {
> > + dev = &rte_eth_devices[port_id];
> > + (*dev->dev_ops->eth_process_set_active)(dev, !active,
> flags[port_id]);
> > + if (--ret == 0)
> > + break;
> > + }
> > + return 0;
> > +}
> > +
> > RTE_LOG_REGISTER_DEFAULT(rte_eth_dev_logtype, INFO);
> >
> > RTE_INIT(ethdev_init_telemetry)
> > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h index
> > c129ca1eaf..d29f051d6f 100644
> > --- a/lib/ethdev/rte_ethdev.h
> > +++ b/lib/ethdev/rte_ethdev.h
> > @@ -1606,6 +1606,8 @@ struct rte_eth_conf {
> > #define RTE_ETH_DEV_CAPA_FLOW_RULE_KEEP RTE_BIT64(3)
> > /** Device supports keeping shared flow objects across restart. */
> > #define RTE_ETH_DEV_CAPA_FLOW_SHARED_OBJECT_KEEP RTE_BIT64(4)
> > +/**Device supports "rte_eth_process_set_active" callback. */ #define
> > +RTE_ETH_CAPA_PROCESS_SET_ROLE RTE_BIT64(5)
> > /**@}*/
> >
> > /*
> > @@ -1777,8 +1779,11 @@ struct rte_eth_dev_info {
> > struct rte_eth_switch_info switch_info;
> > /** Supported error handling mode. */
> > enum rte_eth_err_handle_mode err_handle_mode;
> > + /** Process specific role flag. */
> > + uint32_t eth_process_flag;
> >
> > - uint64_t reserved_64s[2]; /**< Reserved for future fields */
> > + uint32_t reserved_32s[1]; /**< Reserved for future fields */
> > + uint64_t reserved_64s[1]; /**< Reserved for future fields */
> > void *reserved_ptrs[2]; /**< Reserved for future fields */
> > };
> >
> > diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map index
> > 17201fbe0f..a5503f6fde 100644
> > --- a/lib/ethdev/version.map
> > +++ b/lib/ethdev/version.map
> > @@ -298,6 +298,9 @@ EXPERIMENTAL {
> > rte_flow_get_q_aged_flows;
> > rte_mtr_meter_policy_get;
> > rte_mtr_meter_profile_get;
> > +
> > + # added in 23.03
> > + rte_eth_process_set_active;
> > };
> >
> > INTERNAL {
> > --
> > 2.27.0
> >
^ permalink raw reply [relevance 3%]
* [RFC 2/5] ethdev: introduce the affinity field in Tx queue API
@ 2022-12-21 10:29 2% ` Jiawei Wang
2023-01-11 16:47 0% ` Ori Kam
2023-01-18 11:37 0% ` Thomas Monjalon
0 siblings, 2 replies; 200+ results
From: Jiawei Wang @ 2022-12-21 10:29 UTC (permalink / raw)
To: viacheslavo, orika, thomas, Aman Singh, Yuying Zhang,
Ferruh Yigit, Andrew Rybchenko
Cc: dev, rasland
For the multiple hardware ports connect to a single DPDK port (mhpsdp),
the previous patch introduces the new rte flow item to match the port
affinity of the received packets.
This patch adds the tx_affinity setting in Tx queue API, the affinity value
reflects packets be sent to which hardware port.
Adds the new tx_affinity field into the padding hole of rte_eth_txconf
structure, the size of rte_eth_txconf keeps the same. Adds a suppress
type for structure change in the ABI check file.
This patch adds the testpmd command line:
testpmd> port config (port_id) txq (queue_id) affinity (value)
For example, there're two hardware ports connects to a single DPDK
port (port id 0), and affinity 1 stood for hard port 1 and affinity
2 stood for hardware port 2, used the below command to config
tx affinity for each TxQ:
port config 0 txq 0 affinity 1
port config 0 txq 1 affinity 1
port config 0 txq 2 affinity 2
port config 0 txq 3 affinity 2
These commands config the TxQ index 0 and TxQ index 1 with affinity 1,
uses TxQ 0 or TxQ 1 send packets, these packets will be sent from the
hardware port 1, and similar with hardware port 2 if sending packets
with TxQ 2 or TxQ 3.
Signed-off-by: Jiawei Wang <jiaweiw@nvidia.com>
---
app/test-pmd/cmdline.c | 84 +++++++++++++++++++++
devtools/libabigail.abignore | 5 ++
doc/guides/rel_notes/release_22_03.rst | 4 +
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 13 ++++
lib/ethdev/rte_ethdev.h | 1 +
5 files changed, 107 insertions(+)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index b32dc8bfd4..683cae1cab 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -764,6 +764,10 @@ static void cmd_help_long_parsed(void *parsed_result,
"port cleanup (port_id) txq (queue_id) (free_cnt)\n"
" Cleanup txq mbufs for a specific Tx queue\n\n"
+
+ "port config <port_id> txq <queue_id> affinity <value>\n"
+ " Set the port affinity value "
+ "on a specific Tx queue\n\n"
);
}
@@ -12621,6 +12625,85 @@ static cmdline_parse_inst_t cmd_show_port_flow_transfer_proxy = {
}
};
+/* *** configure port txq affinity value *** */
+struct cmd_config_tx_affinity {
+ cmdline_fixed_string_t port;
+ cmdline_fixed_string_t config;
+ portid_t portid;
+ cmdline_fixed_string_t txq;
+ uint16_t qid;
+ cmdline_fixed_string_t affinity;
+ uint16_t value;
+};
+
+static void
+cmd_config_tx_affinity_parsed(void *parsed_result,
+ __rte_unused struct cmdline *cl,
+ __rte_unused void *data)
+{
+ struct cmd_config_tx_affinity *res = parsed_result;
+ struct rte_port *port;
+
+ if (port_id_is_invalid(res->portid, ENABLED_WARN))
+ return;
+
+ if (res->portid == (portid_t)RTE_PORT_ALL) {
+ printf("Invalid port id\n");
+ return;
+ }
+
+ port = &ports[res->portid];
+
+ if (strcmp(res->txq, "txq")) {
+ printf("Unknown parameter\n");
+ return;
+ }
+ if (tx_queue_id_is_invalid(res->qid))
+ return;
+
+ port->txq[res->qid].conf.tx_affinity = res->value;
+
+ cmd_reconfig_device_queue(res->portid, 0, 1);
+}
+
+cmdline_parse_token_string_t cmd_config_tx_affinity_port =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_tx_affinity,
+ port, "port");
+cmdline_parse_token_string_t cmd_config_tx_affinity_config =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_tx_affinity,
+ config, "config");
+cmdline_parse_token_num_t cmd_config_tx_affinity_portid =
+ TOKEN_NUM_INITIALIZER(struct cmd_config_tx_affinity,
+ portid, RTE_UINT16);
+cmdline_parse_token_string_t cmd_config_tx_affinity_txq =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_tx_affinity,
+ txq, "txq");
+cmdline_parse_token_num_t cmd_config_tx_affinity_qid =
+ TOKEN_NUM_INITIALIZER(struct cmd_config_tx_affinity,
+ qid, RTE_UINT16);
+cmdline_parse_token_string_t cmd_config_tx_affinity_affine =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_tx_affinity,
+ affinity, "affinity");
+cmdline_parse_token_num_t cmd_config_tx_affinity_value =
+ TOKEN_NUM_INITIALIZER(struct cmd_config_tx_affinity,
+ value, RTE_UINT16);
+
+static cmdline_parse_inst_t cmd_config_tx_affinity = {
+ .f = cmd_config_tx_affinity_parsed,
+ .data = (void *)0,
+ .help_str = "port config <port_id> txq <queue_id> affinity <value>",
+ .tokens = {
+ (void *)&cmd_config_tx_affinity_port,
+ (void *)&cmd_config_tx_affinity_config,
+ (void *)&cmd_config_tx_affinity_portid,
+ (void *)&cmd_config_tx_affinity_txq,
+ (void *)&cmd_config_tx_affinity_qid,
+ (void *)&cmd_config_tx_affinity_affine,
+ (void *)&cmd_config_tx_affinity_value,
+ NULL,
+ },
+};
+
/* ******************************************************************************** */
/* list of instructions */
@@ -12851,6 +12934,7 @@ static cmdline_parse_ctx_t builtin_ctx[] = {
(cmdline_parse_inst_t *)&cmd_show_capability,
(cmdline_parse_inst_t *)&cmd_set_flex_is_pattern,
(cmdline_parse_inst_t *)&cmd_set_flex_spec_pattern,
+ (cmdline_parse_inst_t *)&cmd_config_tx_affinity,
NULL,
};
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 7a93de3ba1..cbbde4ef05 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -20,6 +20,11 @@
[suppress_file]
soname_regexp = ^librte_.*mlx.*glue\.
+; Ignore fields inserted in middle padding of rte_eth_txconf
+[suppress_type]
+ name = rte_eth_txconf
+ has_data_member_inserted_between = {offset_after(tx_deferred_start), offset_of(offloads)}
+
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Experimental APIs exceptions ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
diff --git a/doc/guides/rel_notes/release_22_03.rst b/doc/guides/rel_notes/release_22_03.rst
index 8acd3174f6..0d81ae7bc3 100644
--- a/doc/guides/rel_notes/release_22_03.rst
+++ b/doc/guides/rel_notes/release_22_03.rst
@@ -212,6 +212,10 @@ API Changes
* ethdev: Old public macros and enumeration constants without ``RTE_ETH_`` prefix,
which are kept for backward compatibility, are marked as deprecated.
+* ethdev: added a new field:
+
+ - Tx affinity per-queue ``rte_eth_txconf.tx_affinity``
+
* cryptodev: The asymmetric session handling was modified to use a single
mempool object. An API ``rte_cryptodev_asym_session_pool_create`` was added
to create a mempool with element size big enough to hold the generic asymmetric
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index c0ace56c1f..0c3317ee06 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -1605,6 +1605,19 @@ Enable or disable a per queue Tx offloading only on a specific Tx queue::
This command should be run when the port is stopped, or else it will fail.
+config per queue Tx affinity
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Configure a affinity value per queue Tx offloading only on a specific Tx queue::
+
+ testpmd> port (port_id) txq (queue_id) affinity (value)
+
+* ``affinity``: reflects packet can be sent to which hardware port.
+ uses it on multiple hardware ports connect to
+ a single DPDK port (mhpsdp).
+
+This command should be run when the port is stopped, or else it will fail.
+
Config VXLAN Encap outer layers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index 882ca585f2..813dbb34b5 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -1138,6 +1138,7 @@ struct rte_eth_txconf {
less free descriptors than this value. */
uint8_t tx_deferred_start; /**< Do not start queue with rte_eth_dev_start(). */
+ uint8_t tx_affinity; /**< Drives the setting of affinity per-queue. */
/**
* Per-queue Tx offloads to be set using RTE_ETH_TX_OFFLOAD_* flags.
* Only offloads set on tx_queue_offload_capa or tx_offload_capa
--
2.18.1
^ permalink raw reply [relevance 2%]
* Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
2022-12-21 9:32 3% ` Rongwei Liu
@ 2022-12-21 10:59 5% ` Jerin Jacob
2022-12-21 12:05 5% ` Rongwei Liu
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2022-12-21 10:59 UTC (permalink / raw)
To: Rongwei Liu
Cc: Matan Azrad, Slava Ovsiienko, Ori Kam,
NBU-Contact-Thomas Monjalon (EXTERNAL),
Ferruh Yigit, Andrew Rybchenko, dev, Raslan Darawsheh
On Wed, Dec 21, 2022 at 3:02 PM Rongwei Liu <rongweil@nvidia.com> wrote:
>
> HI Jerin:
>
Hi Rongwei
> BR
> Rongwei
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Wednesday, December 21, 2022 17:13
> > To: Rongwei Liu <rongweil@nvidia.com>
> > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> > <ferruh.yigit@amd.com>; Andrew Rybchenko
> > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > <rasland@nvidia.com>
> > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu <rongweil@nvidia.com> wrote:
> > >
> > > Users may want to change the DPDK process to different versions
> >
> > Different version of DPDK? If there is any ABI change how to support this?
> >
> There is a new member which was introduced into rte_eth_dev_info but it shouldn’t be ABI breaking since using reserved fields.
That is just for rte_eth_dev_info. What about the ABI change in
different ethdev structure and rte_flow structures across different
DPDK ABI versions.
> > > such as hot upgrade.
> > > There is a strong requirement to simplify the logic and shorten the
> > > traffic downtime as much as possible.
> > >
> > > This update introduces new rte_eth process role definitions: active or
> > > standby.
> > >
> > > The active role means rules are programmed to HW immediately, and no
> >
> > Why it has to be specific only to rte_flow rule? If it spedieic to rte_flow, why it
> > is in rte_eth_process_ name space?
> For now, this design focuses on the flow rule offloading and traffic redirection.
> When switching process version, it' important to make sure which application receives and handles the traffic.
Changing the DPDK version runtime is just beyond rte_flow driver.
> The changing should be effective across all probing eth devices, that' why it was put under rte_eth_process_ (for all rte_eth_dev) name space.
> >
> > Also, if we are moving the standby, What about the rule whose ABI is changed
> > between versions?
>
> Like the comments mentioned: " Before role transition, all the rules set by the active process should be flushed first. "
What happens to rte_flow flow handles for existing ones which is
created with version X?
Also What if new version Y has ABI change in rte_flow_pattern and
rte_flow_action structure?
For me, If DPDK version change is needed, simply reload the
application. This API will soon bloat, and it will be a mess if to
start handling
Different DPDK version which is not ABI compatible at all.
> > > behavior changed. This is the default state.
> > > The standby role means rules are queued in the HW. If no active roles
> > > alive or back to active, the rules are effective immediately.
> > >
> > > Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
^ permalink raw reply [relevance 5%]
* RE: [RFC v3 2/2] ethdev: add API to set process to active or standby
2022-12-21 10:59 5% ` Jerin Jacob
@ 2022-12-21 12:05 5% ` Rongwei Liu
2022-12-21 12:44 0% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Rongwei Liu @ 2022-12-21 12:05 UTC (permalink / raw)
To: Jerin Jacob
Cc: Matan Azrad, Slava Ovsiienko, Ori Kam,
NBU-Contact-Thomas Monjalon (EXTERNAL),
Ferruh Yigit, Andrew Rybchenko, dev, Raslan Darawsheh
Hi Jerin:
BR
Rongwei
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Wednesday, December 21, 2022 19:00
> To: Rongwei Liu <rongweil@nvidia.com>
> Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> <ferruh.yigit@amd.com>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> <rasland@nvidia.com>
> Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
>
> External email: Use caution opening links or attachments
>
>
> On Wed, Dec 21, 2022 at 3:02 PM Rongwei Liu <rongweil@nvidia.com> wrote:
> >
> > HI Jerin:
> >
>
> Hi Rongwei
>
> > BR
> > Rongwei
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > Sent: Wednesday, December 21, 2022 17:13
> > > To: Rongwei Liu <rongweil@nvidia.com>
> > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> > > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> > > <ferruh.yigit@amd.com>; Andrew Rybchenko
> > > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > > <rasland@nvidia.com>
> > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active
> > > or standby
> > >
> > > External email: Use caution opening links or attachments
> > >
> > >
> > > On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu <rongweil@nvidia.com>
> wrote:
> > > >
> > > > Users may want to change the DPDK process to different versions
> > >
> > > Different version of DPDK? If there is any ABI change how to support this?
> > >
> > There is a new member which was introduced into rte_eth_dev_info but it
> shouldn’t be ABI breaking since using reserved fields.
>
> That is just for rte_eth_dev_info. What about the ABI change in different
> ethdev structure and rte_flow structures across different DPDK ABI versions.
>
Besides this, there is no other ABI changes dependency.
Assume there is a DPDK process A running with version v21.11 and plan to upgrade to
version v22.11. Let' call v22.11 as process B.
Now, process A has been running for long time and has lot of rules configured. It' "active" role per this API definition.
Process B starts and it should call this API and set itself to "standby" role and user can program the flow rules as they want
and different NIC vendors may have different recommendations. Nvidia suggests only program process B with group 0' rules now.
The user should sync all desired configurations from process A to process B, and process A starts to yield traffic like "delete all group 0
rules for Nvidia' NICs" or quit.
After that process B calls this API and set itself to "active" role, now the hot-upgrade finishes.
> > > > such as hot upgrade.
> > > > There is a strong requirement to simplify the logic and shorten
> > > > the traffic downtime as much as possible.
> > > >
> > > > This update introduces new rte_eth process role definitions:
> > > > active or standby.
> > > >
> > > > The active role means rules are programmed to HW immediately, and
> > > > no
> > >
> > > Why it has to be specific only to rte_flow rule? If it spedieic to
> > > rte_flow, why it is in rte_eth_process_ name space?
> > For now, this design focuses on the flow rule offloading and traffic
> redirection.
> > When switching process version, it' important to make sure which
> application receives and handles the traffic.
>
> Changing the DPDK version runtime is just beyond rte_flow driver.
It' not about changing DPDK version but upgrading DPDK from one PMD version to another one.
Does the preceding example answer your question?
>
> > The changing should be effective across all probing eth devices, that' why it
> was put under rte_eth_process_ (for all rte_eth_dev) name space.
> > >
> > > Also, if we are moving the standby, What about the rule whose ABI is
> > > changed between versions?
> >
> > Like the comments mentioned: " Before role transition, all the rules set by
> the active process should be flushed first. "
>
> What happens to rte_flow flow handles for existing ones which is created with
> version X?
> Also What if new version Y has ABI change in rte_flow_pattern and
> rte_flow_action structure?
>
> For me, If DPDK version change is needed, simply reload the application. This
> API will soon bloat, and it will be a mess if to start handling Different DPDK
> version which is not ABI compatible at all.
>
Yes, you are right. Reloading the application is the easiest way but it may have a long time
Window that traffic is lost. No traffic arrives at process A or process B.
We are trying to simplify the reloading logic and minimize the traffic down time as much as possible.
The approach may differentiate hugely between different NIC vendors, so I think it should be better if
DPDK can provide an abstract API.
If process A and process B are ABI different, it doesn't matter.
1. Call this API with process A means older ABI.
2. Call this API with process B means newer ABI.
It' have process concept and working scope.
>
>
>
> > > > behavior changed. This is the default state.
> > > > The standby role means rules are queued in the HW. If no active
> > > > roles alive or back to active, the rules are effective immediately.
> > > >
> > > > Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
^ permalink raw reply [relevance 5%]
* Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
2022-12-21 12:05 5% ` Rongwei Liu
@ 2022-12-21 12:44 0% ` Jerin Jacob
2022-12-21 12:50 4% ` Rongwei Liu
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2022-12-21 12:44 UTC (permalink / raw)
To: Rongwei Liu
Cc: Matan Azrad, Slava Ovsiienko, Ori Kam,
NBU-Contact-Thomas Monjalon (EXTERNAL),
Ferruh Yigit, Andrew Rybchenko, dev, Raslan Darawsheh
On Wed, Dec 21, 2022 at 5:35 PM Rongwei Liu <rongweil@nvidia.com> wrote:
>
> Hi Jerin:
>
> BR
> Rongwei
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Wednesday, December 21, 2022 19:00
> > To: Rongwei Liu <rongweil@nvidia.com>
> > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> > <ferruh.yigit@amd.com>; Andrew Rybchenko
> > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > <rasland@nvidia.com>
> > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Wed, Dec 21, 2022 at 3:02 PM Rongwei Liu <rongweil@nvidia.com> wrote:
> > >
> > > HI Jerin:
> > >
> >
> > Hi Rongwei
> >
> > > BR
> > > Rongwei
> > >
> > > > -----Original Message-----
> > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > Sent: Wednesday, December 21, 2022 17:13
> > > > To: Rongwei Liu <rongweil@nvidia.com>
> > > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> > > > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> > > > <ferruh.yigit@amd.com>; Andrew Rybchenko
> > > > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > > > <rasland@nvidia.com>
> > > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active
> > > > or standby
> > > >
> > > > External email: Use caution opening links or attachments
> > > >
> > > >
> > > > On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu <rongweil@nvidia.com>
> > wrote:
> > > > >
> > > > > Users may want to change the DPDK process to different versions
> > > >
> > > > Different version of DPDK? If there is any ABI change how to support this?
> > > >
> > > There is a new member which was introduced into rte_eth_dev_info but it
> > shouldn’t be ABI breaking since using reserved fields.
> >
> > That is just for rte_eth_dev_info. What about the ABI change in different
> > ethdev structure and rte_flow structures across different DPDK ABI versions.
> >
> Besides this, there is no other ABI changes dependency.
>
> Assume there is a DPDK process A running with version v21.11 and plan to upgrade to
> version v22.11. Let' call v22.11 as process B.
OK. That's a relief. I understand the use case now.
Why not simply use standard DPDK multiprocess model then.
Primary process act as server for slow path API. Secondary process can
come and go(aka can be updated at runtime)
and use as client to update rules via primary-secondray communication mechanism.
>
> Now, process A has been running for long time and has lot of rules configured. It' "active" role per this API definition.
> Process B starts and it should call this API and set itself to "standby" role and user can program the flow rules as they want
> and different NIC vendors may have different recommendations. Nvidia suggests only program process B with group 0' rules now.
>
> The user should sync all desired configurations from process A to process B, and process A starts to yield traffic like "delete all group 0
> rules for Nvidia' NICs" or quit.
> After that process B calls this API and set itself to "active" role, now the hot-upgrade finishes.
>
> > > > > such as hot upgrade.
> > > > > There is a strong requirement to simplify the logic and shorten
> > > > > the traffic downtime as much as possible.
> > > > >
> > > > > This update introduces new rte_eth process role definitions:
> > > > > active or standby.
> > > > >
> > > > > The active role means rules are programmed to HW immediately, and
> > > > > no
> > > >
> > > > Why it has to be specific only to rte_flow rule? If it spedieic to
> > > > rte_flow, why it is in rte_eth_process_ name space?
> > > For now, this design focuses on the flow rule offloading and traffic
> > redirection.
> > > When switching process version, it' important to make sure which
> > application receives and handles the traffic.
> >
> > Changing the DPDK version runtime is just beyond rte_flow driver.
>
> It' not about changing DPDK version but upgrading DPDK from one PMD version to another one.
> Does the preceding example answer your question?
> >
> > > The changing should be effective across all probing eth devices, that' why it
> > was put under rte_eth_process_ (for all rte_eth_dev) name space.
> > > >
> > > > Also, if we are moving the standby, What about the rule whose ABI is
> > > > changed between versions?
> > >
> > > Like the comments mentioned: " Before role transition, all the rules set by
> > the active process should be flushed first. "
> >
> > What happens to rte_flow flow handles for existing ones which is created with
> > version X?
> > Also What if new version Y has ABI change in rte_flow_pattern and
> > rte_flow_action structure?
> >
> > For me, If DPDK version change is needed, simply reload the application. This
> > API will soon bloat, and it will be a mess if to start handling Different DPDK
> > version which is not ABI compatible at all.
> >
> Yes, you are right. Reloading the application is the easiest way but it may have a long time
> Window that traffic is lost. No traffic arrives at process A or process B.
> We are trying to simplify the reloading logic and minimize the traffic down time as much as possible.
> The approach may differentiate hugely between different NIC vendors, so I think it should be better if
> DPDK can provide an abstract API.
>
> If process A and process B are ABI different, it doesn't matter.
> 1. Call this API with process A means older ABI.
> 2. Call this API with process B means newer ABI.
> It' have process concept and working scope.
>
> >
> >
> >
> > > > > behavior changed. This is the default state.
> > > > > The standby role means rules are queued in the HW. If no active
> > > > > roles alive or back to active, the rules are effective immediately.
> > > > >
> > > > > Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
^ permalink raw reply [relevance 0%]
* RE: [RFC v3 2/2] ethdev: add API to set process to active or standby
2022-12-21 12:44 0% ` Jerin Jacob
@ 2022-12-21 12:50 4% ` Rongwei Liu
2022-12-21 13:12 0% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Rongwei Liu @ 2022-12-21 12:50 UTC (permalink / raw)
To: Jerin Jacob
Cc: Matan Azrad, Slava Ovsiienko, Ori Kam,
NBU-Contact-Thomas Monjalon (EXTERNAL),
Ferruh Yigit, Andrew Rybchenko, dev, Raslan Darawsheh
HI Jerin:
BR
Rongwei
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Wednesday, December 21, 2022 20:45
> To: Rongwei Liu <rongweil@nvidia.com>
> Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> <ferruh.yigit@amd.com>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> <rasland@nvidia.com>
> Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
>
> External email: Use caution opening links or attachments
>
>
> On Wed, Dec 21, 2022 at 5:35 PM Rongwei Liu <rongweil@nvidia.com> wrote:
> >
> > Hi Jerin:
> >
> > BR
> > Rongwei
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > Sent: Wednesday, December 21, 2022 19:00
> > > To: Rongwei Liu <rongweil@nvidia.com>
> > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> > > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> > > <ferruh.yigit@amd.com>; Andrew Rybchenko
> > > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > > <rasland@nvidia.com>
> > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active
> > > or standby
> > >
> > > External email: Use caution opening links or attachments
> > >
> > >
> > > On Wed, Dec 21, 2022 at 3:02 PM Rongwei Liu <rongweil@nvidia.com>
> wrote:
> > > >
> > > > HI Jerin:
> > > >
> > >
> > > Hi Rongwei
> > >
> > > > BR
> > > > Rongwei
> > > >
> > > > > -----Original Message-----
> > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > Sent: Wednesday, December 21, 2022 17:13
> > > > > To: Rongwei Liu <rongweil@nvidia.com>
> > > > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>;
> > > > > NBU-Contact- Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>;
> > > > > Ferruh Yigit <ferruh.yigit@amd.com>; Andrew Rybchenko
> > > > > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > > > > <rasland@nvidia.com>
> > > > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to
> > > > > active or standby
> > > > >
> > > > > External email: Use caution opening links or attachments
> > > > >
> > > > >
> > > > > On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu
> > > > > <rongweil@nvidia.com>
> > > wrote:
> > > > > >
> > > > > > Users may want to change the DPDK process to different
> > > > > > versions
> > > > >
> > > > > Different version of DPDK? If there is any ABI change how to support
> this?
> > > > >
> > > > There is a new member which was introduced into rte_eth_dev_info
> > > > but it
> > > shouldn’t be ABI breaking since using reserved fields.
> > >
> > > That is just for rte_eth_dev_info. What about the ABI change in
> > > different ethdev structure and rte_flow structures across different DPDK
> ABI versions.
> > >
> > Besides this, there is no other ABI changes dependency.
> >
> > Assume there is a DPDK process A running with version v21.11 and plan
> > to upgrade to version v22.11. Let' call v22.11 as process B.
>
> OK. That's a relief. I understand the use case now.
>
> Why not simply use standard DPDK multiprocess model then.
> Primary process act as server for slow path API. Secondary process can come
> and go(aka can be updated at runtime) and use as client to update rules via
> primary-secondray communication mechanism.
>
Just image if process A and process B have ABI breakage like different rte_flow_item_*** and rte_flow_action_*** size and members.
How can we quickly accommodate primary/secondary to be ABI compatible across different versions?
It will be very huge effort and difficult to implement, at least in my opinion.
What do you think?
>
> >
> > Now, process A has been running for long time and has lot of rules
> configured. It' "active" role per this API definition.
> > Process B starts and it should call this API and set itself to
> > "standby" role and user can program the flow rules as they want and
> different NIC vendors may have different recommendations. Nvidia suggests
> only program process B with group 0' rules now.
> >
> > The user should sync all desired configurations from process A to
> > process B, and process A starts to yield traffic like "delete all group 0 rules
> for Nvidia' NICs" or quit.
> > After that process B calls this API and set itself to "active" role, now the hot-
> upgrade finishes.
> >
> > > > > > such as hot upgrade.
> > > > > > There is a strong requirement to simplify the logic and
> > > > > > shorten the traffic downtime as much as possible.
> > > > > >
> > > > > > This update introduces new rte_eth process role definitions:
> > > > > > active or standby.
> > > > > >
> > > > > > The active role means rules are programmed to HW immediately,
> > > > > > and no
> > > > >
> > > > > Why it has to be specific only to rte_flow rule? If it spedieic
> > > > > to rte_flow, why it is in rte_eth_process_ name space?
> > > > For now, this design focuses on the flow rule offloading and
> > > > traffic
> > > redirection.
> > > > When switching process version, it' important to make sure which
> > > application receives and handles the traffic.
> > >
> > > Changing the DPDK version runtime is just beyond rte_flow driver.
> >
> > It' not about changing DPDK version but upgrading DPDK from one PMD
> version to another one.
> > Does the preceding example answer your question?
> > >
> > > > The changing should be effective across all probing eth devices,
> > > > that' why it
> > > was put under rte_eth_process_ (for all rte_eth_dev) name space.
> > > > >
> > > > > Also, if we are moving the standby, What about the rule whose
> > > > > ABI is changed between versions?
> > > >
> > > > Like the comments mentioned: " Before role transition, all the
> > > > rules set by
> > > the active process should be flushed first. "
> > >
> > > What happens to rte_flow flow handles for existing ones which is
> > > created with version X?
> > > Also What if new version Y has ABI change in rte_flow_pattern and
> > > rte_flow_action structure?
> > >
> > > For me, If DPDK version change is needed, simply reload the
> > > application. This API will soon bloat, and it will be a mess if to
> > > start handling Different DPDK version which is not ABI compatible at all.
> > >
> > Yes, you are right. Reloading the application is the easiest way but
> > it may have a long time Window that traffic is lost. No traffic arrives at
> process A or process B.
> > We are trying to simplify the reloading logic and minimize the traffic down
> time as much as possible.
> > The approach may differentiate hugely between different NIC vendors,
> > so I think it should be better if DPDK can provide an abstract API.
> >
> > If process A and process B are ABI different, it doesn't matter.
> > 1. Call this API with process A means older ABI.
> > 2. Call this API with process B means newer ABI.
> > It' have process concept and working scope.
> >
> > >
> > >
> > >
> > > > > > behavior changed. This is the default state.
> > > > > > The standby role means rules are queued in the HW. If no
> > > > > > active roles alive or back to active, the rules are effective
> immediately.
> > > > > >
> > > > > > Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
^ permalink raw reply [relevance 4%]
* Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
2022-12-21 12:50 4% ` Rongwei Liu
@ 2022-12-21 13:12 0% ` Jerin Jacob
2022-12-21 14:33 3% ` Rongwei Liu
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2022-12-21 13:12 UTC (permalink / raw)
To: Rongwei Liu
Cc: Matan Azrad, Slava Ovsiienko, Ori Kam,
NBU-Contact-Thomas Monjalon (EXTERNAL),
Ferruh Yigit, Andrew Rybchenko, dev, Raslan Darawsheh
On Wed, Dec 21, 2022 at 6:20 PM Rongwei Liu <rongweil@nvidia.com> wrote:
>
> HI Jerin:
>
> BR
> Rongwei
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Wednesday, December 21, 2022 20:45
> > To: Rongwei Liu <rongweil@nvidia.com>
> > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> > <ferruh.yigit@amd.com>; Andrew Rybchenko
> > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > <rasland@nvidia.com>
> > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Wed, Dec 21, 2022 at 5:35 PM Rongwei Liu <rongweil@nvidia.com> wrote:
> > >
> > > Hi Jerin:
> > >
> > > BR
> > > Rongwei
> > >
> > > > -----Original Message-----
> > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > Sent: Wednesday, December 21, 2022 19:00
> > > > To: Rongwei Liu <rongweil@nvidia.com>
> > > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> > > > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> > > > <ferruh.yigit@amd.com>; Andrew Rybchenko
> > > > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > > > <rasland@nvidia.com>
> > > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active
> > > > or standby
> > > >
> > > > External email: Use caution opening links or attachments
> > > >
> > > >
> > > > On Wed, Dec 21, 2022 at 3:02 PM Rongwei Liu <rongweil@nvidia.com>
> > wrote:
> > > > >
> > > > > HI Jerin:
> > > > >
> > > >
> > > > Hi Rongwei
> > > >
> > > > > BR
> > > > > Rongwei
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > > Sent: Wednesday, December 21, 2022 17:13
> > > > > > To: Rongwei Liu <rongweil@nvidia.com>
> > > > > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > > > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>;
> > > > > > NBU-Contact- Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>;
> > > > > > Ferruh Yigit <ferruh.yigit@amd.com>; Andrew Rybchenko
> > > > > > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > > > > > <rasland@nvidia.com>
> > > > > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to
> > > > > > active or standby
> > > > > >
> > > > > > External email: Use caution opening links or attachments
> > > > > >
> > > > > >
> > > > > > On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu
> > > > > > <rongweil@nvidia.com>
> > > > wrote:
> > > > > > >
> > > > > > > Users may want to change the DPDK process to different
> > > > > > > versions
> > > > > >
> > > > > > Different version of DPDK? If there is any ABI change how to support
> > this?
> > > > > >
> > > > > There is a new member which was introduced into rte_eth_dev_info
> > > > > but it
> > > > shouldn’t be ABI breaking since using reserved fields.
> > > >
> > > > That is just for rte_eth_dev_info. What about the ABI change in
> > > > different ethdev structure and rte_flow structures across different DPDK
> > ABI versions.
> > > >
> > > Besides this, there is no other ABI changes dependency.
> > >
> > > Assume there is a DPDK process A running with version v21.11 and plan
> > > to upgrade to version v22.11. Let' call v22.11 as process B.
> >
> > OK. That's a relief. I understand the use case now.
> >
> > Why not simply use standard DPDK multiprocess model then.
> > Primary process act as server for slow path API. Secondary process can come
> > and go(aka can be updated at runtime) and use as client to update rules via
> > primary-secondray communication mechanism.
> >
> Just image if process A and process B have ABI breakage like different rte_flow_item_*** and rte_flow_action_*** size and members.
> How can we quickly accommodate primary/secondary to be ABI compatible across different versions?
> It will be very huge effort and difficult to implement, at least in my opinion.
> What do you think?
Yes. it difficult what ever approach we take,
On other hand, ethdev subsystem has other components like rte_tm and
other offload etc, We can not simply have rte_eth_process_set_active()
and things magical works across different DPDK versions. Example, if
rte_flow rule has meter action will depend on another HW piece in NIC
card for doing the metering but set by flow API.
IMO, Customer can simply use standard multiprocess model if version
are compatible without any special intelligence in application.
Otherwise they can reload and start the application again
or have special intelligence in application to cater the specific area
of API they need to leverage based on server and client DPDK versions.
> >
> > >
> > > Now, process A has been running for long time and has lot of rules
> > configured. It' "active" role per this API definition.
> > > Process B starts and it should call this API and set itself to
> > > "standby" role and user can program the flow rules as they want and
> > different NIC vendors may have different recommendations. Nvidia suggests
> > only program process B with group 0' rules now.
> > >
> > > The user should sync all desired configurations from process A to
> > > process B, and process A starts to yield traffic like "delete all group 0 rules
> > for Nvidia' NICs" or quit.
> > > After that process B calls this API and set itself to "active" role, now the hot-
> > upgrade finishes.
> > >
> > > > > > > such as hot upgrade.
> > > > > > > There is a strong requirement to simplify the logic and
> > > > > > > shorten the traffic downtime as much as possible.
> > > > > > >
> > > > > > > This update introduces new rte_eth process role definitions:
> > > > > > > active or standby.
> > > > > > >
> > > > > > > The active role means rules are programmed to HW immediately,
> > > > > > > and no
> > > > > >
> > > > > > Why it has to be specific only to rte_flow rule? If it spedieic
> > > > > > to rte_flow, why it is in rte_eth_process_ name space?
> > > > > For now, this design focuses on the flow rule offloading and
> > > > > traffic
> > > > redirection.
> > > > > When switching process version, it' important to make sure which
> > > > application receives and handles the traffic.
> > > >
> > > > Changing the DPDK version runtime is just beyond rte_flow driver.
> > >
> > > It' not about changing DPDK version but upgrading DPDK from one PMD
> > version to another one.
> > > Does the preceding example answer your question?
> > > >
> > > > > The changing should be effective across all probing eth devices,
> > > > > that' why it
> > > > was put under rte_eth_process_ (for all rte_eth_dev) name space.
> > > > > >
> > > > > > Also, if we are moving the standby, What about the rule whose
> > > > > > ABI is changed between versions?
> > > > >
> > > > > Like the comments mentioned: " Before role transition, all the
> > > > > rules set by
> > > > the active process should be flushed first. "
> > > >
> > > > What happens to rte_flow flow handles for existing ones which is
> > > > created with version X?
> > > > Also What if new version Y has ABI change in rte_flow_pattern and
> > > > rte_flow_action structure?
> > > >
> > > > For me, If DPDK version change is needed, simply reload the
> > > > application. This API will soon bloat, and it will be a mess if to
> > > > start handling Different DPDK version which is not ABI compatible at all.
> > > >
> > > Yes, you are right. Reloading the application is the easiest way but
> > > it may have a long time Window that traffic is lost. No traffic arrives at
> > process A or process B.
> > > We are trying to simplify the reloading logic and minimize the traffic down
> > time as much as possible.
> > > The approach may differentiate hugely between different NIC vendors,
> > > so I think it should be better if DPDK can provide an abstract API.
> > >
> > > If process A and process B are ABI different, it doesn't matter.
> > > 1. Call this API with process A means older ABI.
> > > 2. Call this API with process B means newer ABI.
> > > It' have process concept and working scope.
> > >
> > > >
> > > >
> > > >
> > > > > > > behavior changed. This is the default state.
> > > > > > > The standby role means rules are queued in the HW. If no
> > > > > > > active roles alive or back to active, the rules are effective
> > immediately.
> > > > > > >
> > > > > > > Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
^ permalink raw reply [relevance 0%]
* RE: [RFC v3 2/2] ethdev: add API to set process to active or standby
2022-12-21 13:12 0% ` Jerin Jacob
@ 2022-12-21 14:33 3% ` Rongwei Liu
2022-12-26 16:44 4% ` Ori Kam
0 siblings, 1 reply; 200+ results
From: Rongwei Liu @ 2022-12-21 14:33 UTC (permalink / raw)
To: Jerin Jacob
Cc: Matan Azrad, Slava Ovsiienko, Ori Kam,
NBU-Contact-Thomas Monjalon (EXTERNAL),
Ferruh Yigit, Andrew Rybchenko, dev, Raslan Darawsheh
HI Jerin:
BR
Rongwei
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Wednesday, December 21, 2022 21:12
> To: Rongwei Liu <rongweil@nvidia.com>
> Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> <ferruh.yigit@amd.com>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> <rasland@nvidia.com>
> Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
>
> External email: Use caution opening links or attachments
>
>
> On Wed, Dec 21, 2022 at 6:20 PM Rongwei Liu <rongweil@nvidia.com> wrote:
> >
> > HI Jerin:
> >
> > BR
> > Rongwei
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > Sent: Wednesday, December 21, 2022 20:45
> > > To: Rongwei Liu <rongweil@nvidia.com>
> > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> > > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> > > <ferruh.yigit@amd.com>; Andrew Rybchenko
> > > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > > <rasland@nvidia.com>
> > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active
> > > or standby
> > >
> > > External email: Use caution opening links or attachments
> > >
> > >
> > > On Wed, Dec 21, 2022 at 5:35 PM Rongwei Liu <rongweil@nvidia.com>
> wrote:
> > > >
> > > > Hi Jerin:
> > > >
> > > > BR
> > > > Rongwei
> > > >
> > > > > -----Original Message-----
> > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > Sent: Wednesday, December 21, 2022 19:00
> > > > > To: Rongwei Liu <rongweil@nvidia.com>
> > > > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>;
> > > > > NBU-Contact- Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>;
> > > > > Ferruh Yigit <ferruh.yigit@amd.com>; Andrew Rybchenko
> > > > > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > > > > <rasland@nvidia.com>
> > > > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to
> > > > > active or standby
> > > > >
> > > > > External email: Use caution opening links or attachments
> > > > >
> > > > >
> > > > > On Wed, Dec 21, 2022 at 3:02 PM Rongwei Liu
> > > > > <rongweil@nvidia.com>
> > > wrote:
> > > > > >
> > > > > > HI Jerin:
> > > > > >
> > > > >
> > > > > Hi Rongwei
> > > > >
> > > > > > BR
> > > > > > Rongwei
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > > > Sent: Wednesday, December 21, 2022 17:13
> > > > > > > To: Rongwei Liu <rongweil@nvidia.com>
> > > > > > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > > > > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>;
> > > > > > > NBU-Contact- Thomas Monjalon (EXTERNAL)
> > > > > > > <thomas@monjalon.net>; Ferruh Yigit <ferruh.yigit@amd.com>;
> > > > > > > Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>;
> > > > > > > dev@dpdk.org; Raslan Darawsheh <rasland@nvidia.com>
> > > > > > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to
> > > > > > > active or standby
> > > > > > >
> > > > > > > External email: Use caution opening links or attachments
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu
> > > > > > > <rongweil@nvidia.com>
> > > > > wrote:
> > > > > > > >
> > > > > > > > Users may want to change the DPDK process to different
> > > > > > > > versions
> > > > > > >
> > > > > > > Different version of DPDK? If there is any ABI change how to
> > > > > > > support
> > > this?
> > > > > > >
> > > > > > There is a new member which was introduced into
> > > > > > rte_eth_dev_info but it
> > > > > shouldn’t be ABI breaking since using reserved fields.
> > > > >
> > > > > That is just for rte_eth_dev_info. What about the ABI change in
> > > > > different ethdev structure and rte_flow structures across
> > > > > different DPDK
> > > ABI versions.
> > > > >
> > > > Besides this, there is no other ABI changes dependency.
> > > >
> > > > Assume there is a DPDK process A running with version v21.11 and
> > > > plan to upgrade to version v22.11. Let' call v22.11 as process B.
> > >
> > > OK. That's a relief. I understand the use case now.
> > >
> > > Why not simply use standard DPDK multiprocess model then.
> > > Primary process act as server for slow path API. Secondary process
> > > can come and go(aka can be updated at runtime) and use as client to
> > > update rules via primary-secondray communication mechanism.
> > >
> > Just image if process A and process B have ABI breakage like different
> rte_flow_item_*** and rte_flow_action_*** size and members.
> > How can we quickly accommodate primary/secondary to be ABI compatible
> across different versions?
> > It will be very huge effort and difficult to implement, at least in my opinion.
> > What do you think?
>
> Yes. it difficult what ever approach we take, On other hand, ethdev subsystem
> has other components like rte_tm and other offload etc, We can not simply
> have rte_eth_process_set_active() and things magical works across different
> DPDK versions. Example, if rte_flow rule has meter action will depend on
> another HW piece in NIC card for doing the metering but set by flow API.
> IMO, Customer can simply use standard multiprocess model if version are
> compatible without any special intelligence in application.
> Otherwise they can reload and start the application again or have special
> intelligence in application to cater the specific area of API they need to
> leverage based on server and client DPDK versions.
Thanks for the message.
IMO, we are trying to eliminate the version/ABI dependency with this new added API.
For example, if meter action is in the flow rules:
1. Process A have rules like "eth / ipv4 src 1.1.1.1 / meter / queue / end"
2. Process B starts with "rte_eth_process_set_active(false, flags)"
Just give Nvidia' hardware as example (other NIC vendors may not care if group 0 or not)
If the process A' rules are in group 0, users should set them one by one to process B.
Then either flush process A' rules or quit process A, then process B calls with "rte_eth_process_set_active(true, flags)"
All is set.
It will avoid complex operations with client/server model and avoid user mis-operation too.
We should avoid reload as much as possible since reloading is very time consuming and may take up to few seconds.
In this time slot, there is no application to handle the traffic, and everything is lost.
For end user especially cloud service providers, they are sensitive to the traffic down time.
>
>
> > >
> > > >
> > > > Now, process A has been running for long time and has lot of rules
> > > configured. It' "active" role per this API definition.
> > > > Process B starts and it should call this API and set itself to
> > > > "standby" role and user can program the flow rules as they want
> > > > and
> > > different NIC vendors may have different recommendations. Nvidia
> > > suggests only program process B with group 0' rules now.
> > > >
> > > > The user should sync all desired configurations from process A to
> > > > process B, and process A starts to yield traffic like "delete all
> > > > group 0 rules
> > > for Nvidia' NICs" or quit.
> > > > After that process B calls this API and set itself to "active"
> > > > role, now the hot-
> > > upgrade finishes.
> > > >
> > > > > > > > such as hot upgrade.
> > > > > > > > There is a strong requirement to simplify the logic and
> > > > > > > > shorten the traffic downtime as much as possible.
> > > > > > > >
> > > > > > > > This update introduces new rte_eth process role definitions:
> > > > > > > > active or standby.
> > > > > > > >
> > > > > > > > The active role means rules are programmed to HW
> > > > > > > > immediately, and no
> > > > > > >
> > > > > > > Why it has to be specific only to rte_flow rule? If it
> > > > > > > spedieic to rte_flow, why it is in rte_eth_process_ name space?
> > > > > > For now, this design focuses on the flow rule offloading and
> > > > > > traffic
> > > > > redirection.
> > > > > > When switching process version, it' important to make sure
> > > > > > which
> > > > > application receives and handles the traffic.
> > > > >
> > > > > Changing the DPDK version runtime is just beyond rte_flow driver.
> > > >
> > > > It' not about changing DPDK version but upgrading DPDK from one
> > > > PMD
> > > version to another one.
> > > > Does the preceding example answer your question?
> > > > >
> > > > > > The changing should be effective across all probing eth
> > > > > > devices, that' why it
> > > > > was put under rte_eth_process_ (for all rte_eth_dev) name space.
> > > > > > >
> > > > > > > Also, if we are moving the standby, What about the rule
> > > > > > > whose ABI is changed between versions?
> > > > > >
> > > > > > Like the comments mentioned: " Before role transition, all the
> > > > > > rules set by
> > > > > the active process should be flushed first. "
> > > > >
> > > > > What happens to rte_flow flow handles for existing ones which
> > > > > is created with version X?
> > > > > Also What if new version Y has ABI change in rte_flow_pattern
> > > > > and rte_flow_action structure?
> > > > >
> > > > > For me, If DPDK version change is needed, simply reload the
> > > > > application. This API will soon bloat, and it will be a mess if
> > > > > to start handling Different DPDK version which is not ABI compatible at
> all.
> > > > >
> > > > Yes, you are right. Reloading the application is the easiest way
> > > > but it may have a long time Window that traffic is lost. No
> > > > traffic arrives at
> > > process A or process B.
> > > > We are trying to simplify the reloading logic and minimize the
> > > > traffic down
> > > time as much as possible.
> > > > The approach may differentiate hugely between different NIC
> > > > vendors, so I think it should be better if DPDK can provide an abstract API.
> > > >
> > > > If process A and process B are ABI different, it doesn't matter.
> > > > 1. Call this API with process A means older ABI.
> > > > 2. Call this API with process B means newer ABI.
> > > > It' have process concept and working scope.
> > > >
> > > > >
> > > > >
> > > > >
> > > > > > > > behavior changed. This is the default state.
> > > > > > > > The standby role means rules are queued in the HW. If no
> > > > > > > > active roles alive or back to active, the rules are
> > > > > > > > effective
> > > immediately.
> > > > > > > >
> > > > > > > > Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
^ permalink raw reply [relevance 3%]
* Re: [PATCH v2 2/2] devtools: configure source repo to use as ABI reference
2022-12-09 9:02 13% ` [PATCH v2 2/2] devtools: configure source repo to use as ABI reference David Marchand
@ 2022-12-21 15:02 4% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2022-12-21 15:02 UTC (permalink / raw)
To: dev; +Cc: thomas, bruce.richardson, gakhil, Ferruh Yigit
On Fri, Dec 9, 2022 at 10:02 AM David Marchand
<david.marchand@redhat.com> wrote:
>
> From: Ferruh Yigit <ferruh.yigit@amd.com>
>
> By default 'test-meson-builds.sh' script clones the repository which the
> script is in, and selects a configured branch ('DPDK_ABI_REF_VERSION')
> as a reference for ABI check.
>
> This patch enables selecting different repository to clone for reference
> using 'DPDK_ABI_REF_SRC' environment variable.
> 'DPDK_ABI_REF_SRC' may refer to a directory containing a cloned git
> repository, or a remote git repository.
>
> It is possible to put these variables to 'devel.config' config file, or
> provide via command line, like:
> `
> DPDK_ABI_REF_SRC=https://dpdk.org/git/dpdk-stable \
> DPDK_ABI_REF_VERSION=v22.11.1 \
> DPDK_ABI_REF_DIR=/tmp/dpdk-abiref \
> ./devtools/test-meson-builds.sh
> `
>
> When 'DPDK_ABI_REF_SRC' is not defined, script behaves as it did
> previously.
>
> Other alternative to using 'DPDK_ABI_REF_SRC' variable is adding that
> other repo as a new 'remote' to the exiting git repository.
>
> Signed-off-by: Ferruh Yigit <ferruh.yigit@amd.com>
> Acked-by: Akhil Goyal <gakhil@marvell.com>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
> Changes since v1:
> - expanded DPDK_ABI_REF_SRC usage to "non-local" sources,
Series applied, thanks.
--
David Marchand
^ permalink raw reply [relevance 4%]
* RE: [RFC v3 2/2] ethdev: add API to set process to active or standby
2022-12-21 14:33 3% ` Rongwei Liu
@ 2022-12-26 16:44 4% ` Ori Kam
2023-01-15 22:46 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Ori Kam @ 2022-12-26 16:44 UTC (permalink / raw)
To: Rongwei Liu, Jerin Jacob
Cc: Matan Azrad, Slava Ovsiienko,
NBU-Contact-Thomas Monjalon (EXTERNAL),
Ferruh Yigit, Andrew Rybchenko, dev, Raslan Darawsheh
Hi Rongwei and Jerin,
> -----Original Message-----
> From: Rongwei Liu <rongweil@nvidia.com>
> Sent: Wednesday, 21 December 2022 16:33
>
> HI Jerin:
>
> BR
> Rongwei
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Wednesday, December 21, 2022 21:12
> > To: Rongwei Liu <rongweil@nvidia.com>
> > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> > <ferruh.yigit@amd.com>; Andrew Rybchenko
> > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > <rasland@nvidia.com>
> > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active or
> standby
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Wed, Dec 21, 2022 at 6:20 PM Rongwei Liu <rongweil@nvidia.com>
> wrote:
> > >
> > > HI Jerin:
> > >
> > > BR
> > > Rongwei
> > >
> > > > -----Original Message-----
> > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > Sent: Wednesday, December 21, 2022 20:45
> > > > To: Rongwei Liu <rongweil@nvidia.com>
> > > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-
> Contact-
> > > > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> > > > <ferruh.yigit@amd.com>; Andrew Rybchenko
> > > > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > > > <rasland@nvidia.com>
> > > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active
> > > > or standby
> > > >
> > > > External email: Use caution opening links or attachments
> > > >
> > > >
> > > > On Wed, Dec 21, 2022 at 5:35 PM Rongwei Liu <rongweil@nvidia.com>
> > wrote:
> > > > >
> > > > > Hi Jerin:
> > > > >
> > > > > BR
> > > > > Rongwei
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > > Sent: Wednesday, December 21, 2022 19:00
> > > > > > To: Rongwei Liu <rongweil@nvidia.com>
> > > > > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > > > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>;
> > > > > > NBU-Contact- Thomas Monjalon (EXTERNAL)
> <thomas@monjalon.net>;
> > > > > > Ferruh Yigit <ferruh.yigit@amd.com>; Andrew Rybchenko
> > > > > > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan
> Darawsheh
> > > > > > <rasland@nvidia.com>
> > > > > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to
> > > > > > active or standby
> > > > > >
> > > > > > External email: Use caution opening links or attachments
> > > > > >
> > > > > >
> > > > > > On Wed, Dec 21, 2022 at 3:02 PM Rongwei Liu
> > > > > > <rongweil@nvidia.com>
> > > > wrote:
> > > > > > >
> > > > > > > HI Jerin:
> > > > > > >
> > > > > >
> > > > > > Hi Rongwei
> > > > > >
> > > > > > > BR
> > > > > > > Rongwei
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > > > > Sent: Wednesday, December 21, 2022 17:13
> > > > > > > > To: Rongwei Liu <rongweil@nvidia.com>
> > > > > > > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > > > > > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>;
> > > > > > > > NBU-Contact- Thomas Monjalon (EXTERNAL)
> > > > > > > > <thomas@monjalon.net>; Ferruh Yigit
> <ferruh.yigit@amd.com>;
> > > > > > > > Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>;
> > > > > > > > dev@dpdk.org; Raslan Darawsheh <rasland@nvidia.com>
> > > > > > > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to
> > > > > > > > active or standby
> > > > > > > >
> > > > > > > > External email: Use caution opening links or attachments
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu
> > > > > > > > <rongweil@nvidia.com>
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Users may want to change the DPDK process to different
> > > > > > > > > versions
> > > > > > > >
> > > > > > > > Different version of DPDK? If there is any ABI change how to
> > > > > > > > support
> > > > this?
> > > > > > > >
> > > > > > > There is a new member which was introduced into
> > > > > > > rte_eth_dev_info but it
> > > > > > shouldn’t be ABI breaking since using reserved fields.
> > > > > >
> > > > > > That is just for rte_eth_dev_info. What about the ABI change in
> > > > > > different ethdev structure and rte_flow structures across
> > > > > > different DPDK
> > > > ABI versions.
> > > > > >
> > > > > Besides this, there is no other ABI changes dependency.
> > > > >
> > > > > Assume there is a DPDK process A running with version v21.11 and
> > > > > plan to upgrade to version v22.11. Let' call v22.11 as process B.
> > > >
> > > > OK. That's a relief. I understand the use case now.
> > > >
> > > > Why not simply use standard DPDK multiprocess model then.
> > > > Primary process act as server for slow path API. Secondary process
> > > > can come and go(aka can be updated at runtime) and use as client to
> > > > update rules via primary-secondray communication mechanism.
> > > >
> > > Just image if process A and process B have ABI breakage like different
> > rte_flow_item_*** and rte_flow_action_*** size and members.
> > > How can we quickly accommodate primary/secondary to be ABI
> compatible
> > across different versions?
> > > It will be very huge effort and difficult to implement, at least in my
> opinion.
> > > What do you think?
> >
> > Yes. it difficult what ever approach we take, On other hand, ethdev
> subsystem
> > has other components like rte_tm and other offload etc, We can not simply
> > have rte_eth_process_set_active() and things magical works across
> different
> > DPDK versions. Example, if rte_flow rule has meter action will depend on
> > another HW piece in NIC card for doing the metering but set by flow API.
> > IMO, Customer can simply use standard multiprocess model if version are
> > compatible without any special intelligence in application.
> > Otherwise they can reload and start the application again or have special
> > intelligence in application to cater the specific area of API they need to
> > leverage based on server and client DPDK versions.
>
> Thanks for the message.
> IMO, we are trying to eliminate the version/ABI dependency with this new
> added API.
> For example, if meter action is in the flow rules:
> 1. Process A have rules like "eth / ipv4 src 1.1.1.1 / meter / queue / end"
> 2. Process B starts with "rte_eth_process_set_active(false, flags)"
>
> Just give Nvidia' hardware as example (other NIC vendors may not care if
> group 0 or not)
> If the process A' rules are in group 0, users should set them one by one to
> process B.
> Then either flush process A' rules or quit process A, then process B calls with
> "rte_eth_process_set_active(true, flags)"
> All is set.
> It will avoid complex operations with client/server model and avoid user mis-
> operation too.
> We should avoid reload as much as possible since reloading is very time
> consuming and may take up to few seconds.
> In this time slot, there is no application to handle the traffic, and everything is
> lost.
> For end user especially cloud service providers, they are sensitive to the
> traffic down time.
From my viewpoint the upgrade has nothing to do with DPDK as a library,
the upgrade may be because of application upgrade.
Unless I'm missing something, this API is not meant for API/ABI it is created
to allow minimum downtime when doing upgrade of the application.
Unless I'm missing something critical, since the upgrade in any case is not
only for the DPDK but the entire app, there isn't any ABI/API issue.
^ permalink raw reply [relevance 4%]
* [PATCH v2] cryptodev: add algo enums to string conversion APIs
2022-12-12 15:10 2% [PATCH] cryptodev: add algo enums to string conversion APIs Akhil Goyal
` (3 preceding siblings ...)
2022-12-14 9:32 0% ` Zhang, Fan
@ 2023-01-04 6:18 2% ` Akhil Goyal
2023-01-05 10:56 0% ` Akhil Goyal
4 siblings, 1 reply; 200+ results
From: Akhil Goyal @ 2023-01-04 6:18 UTC (permalink / raw)
To: dev
Cc: ciara.power, fanzhang.oss, kai.ji, pablo.de.lara.guarch,
hemant.agrawal, matan, g.singh, ruifeng.wang, anoobj,
radu.nicolau, vfialko, ktraynor, david.marchand, thomas,
Akhil Goyal
Symmetric/Asymmetric algorithm strings are accessed by application
using arrays in cryptodev lib, which hampers new algorithms addition
in the array due to ABI breakage.
These arrays are now deprecated and will be removed in next ABI break
release.
New APIs are added for getting the algorithm strings based on enum values.
Signed-off-by: Akhil Goyal <gakhil@marvell.com>
Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
Acked-by: Anoob Joseph <anoobj@marvell.com>
Acked-by: Ciara Power <ciara.power@intel.com>
Acked-by: Fan Zhang <fanzhang.oss@gmail.com>
---
Changes in v2: fixed Windows compilation
app/test-crypto-perf/cperf_options_parsing.c | 6 +-
app/test/test_cryptodev_asym.c | 2 +-
app/test/test_cryptodev_security_ipsec.c | 8 +-
doc/guides/rel_notes/deprecation.rst | 7 +
drivers/crypto/openssl/rte_openssl_pmd_ops.c | 2 +-
drivers/crypto/qat/qat_sym_session.c | 7 +-
examples/l2fwd-crypto/main.c | 12 +-
lib/cryptodev/cryptodev_trace_points.c | 12 ++
lib/cryptodev/rte_crypto_asym.h | 1 +
lib/cryptodev/rte_crypto_sym.h | 3 +
lib/cryptodev/rte_cryptodev.c | 183 ++++++++++++++++++-
lib/cryptodev/rte_cryptodev.h | 52 ++++++
lib/cryptodev/rte_cryptodev_trace.h | 32 ++++
lib/cryptodev/version.map | 10 +
14 files changed, 310 insertions(+), 27 deletions(-)
diff --git a/app/test-crypto-perf/cperf_options_parsing.c b/app/test-crypto-perf/cperf_options_parsing.c
index bc5e312c81..f8ddb6ac56 100644
--- a/app/test-crypto-perf/cperf_options_parsing.c
+++ b/app/test-crypto-perf/cperf_options_parsing.c
@@ -1373,7 +1373,7 @@ cperf_options_dump(struct cperf_options *opts)
opts->op_type == CPERF_CIPHER_THEN_AUTH ||
opts->op_type == CPERF_AUTH_THEN_CIPHER) {
printf("# auth algorithm: %s\n",
- rte_crypto_auth_algorithm_strings[opts->auth_algo]);
+ rte_cryptodev_get_auth_algo_string(opts->auth_algo));
printf("# auth operation: %s\n",
rte_crypto_auth_operation_strings[opts->auth_op]);
printf("# auth key size: %u\n", opts->auth_key_sz);
@@ -1386,7 +1386,7 @@ cperf_options_dump(struct cperf_options *opts)
opts->op_type == CPERF_CIPHER_THEN_AUTH ||
opts->op_type == CPERF_AUTH_THEN_CIPHER) {
printf("# cipher algorithm: %s\n",
- rte_crypto_cipher_algorithm_strings[opts->cipher_algo]);
+ rte_cryptodev_get_cipher_algo_string(opts->cipher_algo));
printf("# cipher operation: %s\n",
rte_crypto_cipher_operation_strings[opts->cipher_op]);
printf("# cipher key size: %u\n", opts->cipher_key_sz);
@@ -1396,7 +1396,7 @@ cperf_options_dump(struct cperf_options *opts)
if (opts->op_type == CPERF_AEAD) {
printf("# aead algorithm: %s\n",
- rte_crypto_aead_algorithm_strings[opts->aead_algo]);
+ rte_cryptodev_get_aead_algo_string(opts->aead_algo));
printf("# aead operation: %s\n",
rte_crypto_aead_operation_strings[opts->aead_op]);
printf("# aead key size: %u\n", opts->aead_key_sz);
diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index c58c7f488b..5b16dcab56 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -974,7 +974,7 @@ static inline void print_asym_capa(
int i = 0;
printf("\nxform type: %s\n===================\n",
- rte_crypto_asym_xform_strings[capa->xform_type]);
+ rte_cryptodev_asym_get_xform_string(capa->xform_type));
printf("operation supported -");
for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
diff --git a/app/test/test_cryptodev_security_ipsec.c b/app/test/test_cryptodev_security_ipsec.c
index 833be94c09..417ff10a1b 100644
--- a/app/test/test_cryptodev_security_ipsec.c
+++ b/app/test/test_cryptodev_security_ipsec.c
@@ -625,20 +625,20 @@ test_ipsec_display_alg(const struct crypto_param *param1,
{
if (param1->type == RTE_CRYPTO_SYM_XFORM_AEAD) {
printf("\t%s [%d]",
- rte_crypto_aead_algorithm_strings[param1->alg.aead],
+ rte_cryptodev_get_aead_algo_string(param1->alg.aead),
param1->key_length * 8);
} else if (param1->type == RTE_CRYPTO_SYM_XFORM_AUTH) {
printf("\t%s",
- rte_crypto_auth_algorithm_strings[param1->alg.auth]);
+ rte_cryptodev_get_auth_algo_string(param1->alg.auth));
if (param1->alg.auth != RTE_CRYPTO_AUTH_NULL)
printf(" [%dB ICV]", param1->digest_length);
} else {
printf("\t%s",
- rte_crypto_cipher_algorithm_strings[param1->alg.cipher]);
+ rte_cryptodev_get_cipher_algo_string(param1->alg.cipher));
if (param1->alg.cipher != RTE_CRYPTO_CIPHER_NULL)
printf(" [%d]", param1->key_length * 8);
printf(" %s",
- rte_crypto_auth_algorithm_strings[param2->alg.auth]);
+ rte_cryptodev_get_auth_algo_string(param2->alg.auth));
if (param2->alg.auth != RTE_CRYPTO_AUTH_NULL)
printf(" [%dB ICV]", param2->digest_length);
}
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index b9b02dcef0..e18ac344ef 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -114,6 +114,13 @@ Deprecation Notices
which got error interrupt to the application,
so that application can reset that particular queue pair.
+* cryptodev: The arrays of algorithm strings ``rte_crypto_cipher_algorithm_strings``,
+ ``rte_crypto_auth_algorithm_strings``, ``rte_crypto_aead_algorithm_strings`` and
+ ``rte_crypto_asym_xform_strings`` are deprecated and will be removed in DPDK 23.11.
+ Application can use the new APIs ``rte_cryptodev_get_cipher_algo_string``,
+ ``rte_cryptodev_get_auth_algo_string``, ``rte_cryptodev_get_aead_algo_string`` and
+ ``rte_cryptodev_asym_get_xform_string`` respectively.
+
* flow_classify: The flow_classify library and example have no maintainer.
The library is experimental and, as such, it could be removed from DPDK.
Its removal has been postponed to let potential users report interest
diff --git a/drivers/crypto/openssl/rte_openssl_pmd_ops.c b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
index defed4429e..29ad1b9505 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd_ops.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
@@ -823,7 +823,7 @@ static int openssl_set_asym_session_parameters(
if ((xform->xform_type != RTE_CRYPTO_ASYM_XFORM_DH) &&
(xform->next != NULL)) {
OPENSSL_LOG(ERR, "chained xfrms are not supported on %s",
- rte_crypto_asym_xform_strings[xform->xform_type]);
+ rte_cryptodev_asym_get_xform_string(xform->xform_type));
return ret;
}
diff --git a/drivers/crypto/qat/qat_sym_session.c b/drivers/crypto/qat/qat_sym_session.c
index 0ebc66f89e..714002dce3 100644
--- a/drivers/crypto/qat/qat_sym_session.c
+++ b/drivers/crypto/qat/qat_sym_session.c
@@ -436,8 +436,8 @@ qat_sym_session_configure_cipher(struct rte_cryptodev *dev,
if (!qat_is_cipher_alg_supported(
cipher_xform->algo, internals)) {
QAT_LOG(ERR, "%s not supported on this device",
- rte_crypto_cipher_algorithm_strings
- [cipher_xform->algo]);
+ rte_cryptodev_get_cipher_algo_string(
+ cipher_xform->algo));
ret = -ENOTSUP;
goto error_out;
}
@@ -772,8 +772,7 @@ qat_sym_session_configure_auth(struct rte_cryptodev *dev,
case RTE_CRYPTO_AUTH_ZUC_EIA3:
if (!qat_is_auth_alg_supported(auth_xform->algo, internals)) {
QAT_LOG(ERR, "%s not supported on this device",
- rte_crypto_auth_algorithm_strings
- [auth_xform->algo]);
+ rte_cryptodev_get_auth_algo_string(auth_xform->algo));
return -ENOTSUP;
}
session->qat_hash_alg = ICP_QAT_HW_AUTH_ALGO_ZUC_3G_128_EIA3;
diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index b13e5c526e..efe7eea2a7 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -1536,7 +1536,7 @@ display_cipher_info(struct l2fwd_crypto_options *options)
{
printf("\n---- Cipher information ---\n");
printf("Algorithm: %s\n",
- rte_crypto_cipher_algorithm_strings[options->cipher_xform.cipher.algo]);
+ rte_cryptodev_get_cipher_algo_string(options->cipher_xform.cipher.algo));
rte_hexdump(stdout, "Cipher key:",
options->cipher_xform.cipher.key.data,
options->cipher_xform.cipher.key.length);
@@ -1548,7 +1548,7 @@ display_auth_info(struct l2fwd_crypto_options *options)
{
printf("\n---- Authentication information ---\n");
printf("Algorithm: %s\n",
- rte_crypto_auth_algorithm_strings[options->auth_xform.auth.algo]);
+ rte_cryptodev_get_auth_algo_string(options->auth_xform.auth.algo));
rte_hexdump(stdout, "Auth key:",
options->auth_xform.auth.key.data,
options->auth_xform.auth.key.length);
@@ -1560,7 +1560,7 @@ display_aead_info(struct l2fwd_crypto_options *options)
{
printf("\n---- AEAD information ---\n");
printf("Algorithm: %s\n",
- rte_crypto_aead_algorithm_strings[options->aead_xform.aead.algo]);
+ rte_cryptodev_get_aead_algo_string(options->aead_xform.aead.algo));
rte_hexdump(stdout, "AEAD key:",
options->aead_xform.aead.key.data,
options->aead_xform.aead.key.length);
@@ -1864,7 +1864,7 @@ check_device_support_cipher_algo(const struct l2fwd_crypto_options *options,
if (cap->op == RTE_CRYPTO_OP_TYPE_UNDEFINED) {
printf("Algorithm %s not supported by cryptodev %u"
" or device not of preferred type (%s)\n",
- rte_crypto_cipher_algorithm_strings[opt_cipher_algo],
+ rte_cryptodev_get_cipher_algo_string(opt_cipher_algo),
cdev_id,
options->string_type);
return NULL;
@@ -1898,7 +1898,7 @@ check_device_support_auth_algo(const struct l2fwd_crypto_options *options,
if (cap->op == RTE_CRYPTO_OP_TYPE_UNDEFINED) {
printf("Algorithm %s not supported by cryptodev %u"
" or device not of preferred type (%s)\n",
- rte_crypto_auth_algorithm_strings[opt_auth_algo],
+ rte_cryptodev_get_auth_algo_string(opt_auth_algo),
cdev_id,
options->string_type);
return NULL;
@@ -1932,7 +1932,7 @@ check_device_support_aead_algo(const struct l2fwd_crypto_options *options,
if (cap->op == RTE_CRYPTO_OP_TYPE_UNDEFINED) {
printf("Algorithm %s not supported by cryptodev %u"
" or device not of preferred type (%s)\n",
- rte_crypto_aead_algorithm_strings[opt_aead_algo],
+ rte_cryptodev_get_aead_algo_string(opt_aead_algo),
cdev_id,
options->string_type);
return NULL;
diff --git a/lib/cryptodev/cryptodev_trace_points.c b/lib/cryptodev/cryptodev_trace_points.c
index 63a81511a9..4980bcc9be 100644
--- a/lib/cryptodev/cryptodev_trace_points.c
+++ b/lib/cryptodev/cryptodev_trace_points.c
@@ -72,6 +72,15 @@ RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_auth_algo_enum,
RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_cipher_algo_enum,
lib.cryptodev.get.cipher.algo.enum)
+RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_aead_algo_string,
+ lib.cryptodev.get.aead.algo.string)
+
+RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_auth_algo_string,
+ lib.cryptodev.get.auth.algo.string)
+
+RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_cipher_algo_string,
+ lib.cryptodev.get.cipher.algo.string)
+
RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_dev_id,
lib.cryptodev.get.dev.id)
@@ -126,6 +135,9 @@ RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_get_private_session_size,
RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_get_xform_enum,
lib.cryptodev.asym.get.xform.enum)
+RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_get_xform_string,
+ lib.cryptodev.asym.get.xform.string)
+
RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_xform_capability_check_modlen,
lib.cryptodev.asym.xform.capability.check.modlen)
diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 38c8b60779..989f38323f 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -30,6 +30,7 @@ extern "C" {
struct rte_cryptodev_asym_session;
/** asym xform type name strings */
+__rte_deprecated
extern const char *
rte_crypto_asym_xform_strings[];
diff --git a/lib/cryptodev/rte_crypto_sym.h b/lib/cryptodev/rte_crypto_sym.h
index 33b4966e16..dc847da7b8 100644
--- a/lib/cryptodev/rte_crypto_sym.h
+++ b/lib/cryptodev/rte_crypto_sym.h
@@ -177,6 +177,7 @@ enum rte_crypto_cipher_algorithm {
};
/** Cipher algorithm name strings */
+__rte_deprecated
extern const char *
rte_crypto_cipher_algorithm_strings[];
@@ -378,6 +379,7 @@ enum rte_crypto_auth_algorithm {
};
/** Authentication algorithm name strings */
+__rte_deprecated
extern const char *
rte_crypto_auth_algorithm_strings[];
@@ -482,6 +484,7 @@ enum rte_crypto_aead_algorithm {
};
/** AEAD algorithm name strings */
+__rte_deprecated
extern const char *
rte_crypto_aead_algorithm_strings[];
diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index 2165a0688c..742a4c512e 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -64,9 +64,11 @@ struct rte_cryptodev_callback {
};
/**
+ * @deprecated
* The crypto cipher algorithm strings identifiers.
* It could be used in application command line.
*/
+__rte_deprecated
const char *
rte_crypto_cipher_algorithm_strings[] = {
[RTE_CRYPTO_CIPHER_3DES_CBC] = "3des-cbc",
@@ -95,6 +97,39 @@ rte_crypto_cipher_algorithm_strings[] = {
[RTE_CRYPTO_CIPHER_SM4_CTR] = "sm4-ctr"
};
+/**
+ * The crypto cipher algorithm strings identifiers.
+ * Not to be used in application directly.
+ * Application can use rte_cryptodev_get_cipher_algo_string().
+ */
+static const char *
+crypto_cipher_algorithm_strings[] = {
+ [RTE_CRYPTO_CIPHER_3DES_CBC] = "3des-cbc",
+ [RTE_CRYPTO_CIPHER_3DES_ECB] = "3des-ecb",
+ [RTE_CRYPTO_CIPHER_3DES_CTR] = "3des-ctr",
+
+ [RTE_CRYPTO_CIPHER_AES_CBC] = "aes-cbc",
+ [RTE_CRYPTO_CIPHER_AES_CTR] = "aes-ctr",
+ [RTE_CRYPTO_CIPHER_AES_DOCSISBPI] = "aes-docsisbpi",
+ [RTE_CRYPTO_CIPHER_AES_ECB] = "aes-ecb",
+ [RTE_CRYPTO_CIPHER_AES_F8] = "aes-f8",
+ [RTE_CRYPTO_CIPHER_AES_XTS] = "aes-xts",
+
+ [RTE_CRYPTO_CIPHER_ARC4] = "arc4",
+
+ [RTE_CRYPTO_CIPHER_DES_CBC] = "des-cbc",
+ [RTE_CRYPTO_CIPHER_DES_DOCSISBPI] = "des-docsisbpi",
+
+ [RTE_CRYPTO_CIPHER_NULL] = "null",
+
+ [RTE_CRYPTO_CIPHER_KASUMI_F8] = "kasumi-f8",
+ [RTE_CRYPTO_CIPHER_SNOW3G_UEA2] = "snow3g-uea2",
+ [RTE_CRYPTO_CIPHER_ZUC_EEA3] = "zuc-eea3",
+ [RTE_CRYPTO_CIPHER_SM4_ECB] = "sm4-ecb",
+ [RTE_CRYPTO_CIPHER_SM4_CBC] = "sm4-cbc",
+ [RTE_CRYPTO_CIPHER_SM4_CTR] = "sm4-ctr"
+};
+
/**
* The crypto cipher operation strings identifiers.
* It could be used in application command line.
@@ -106,9 +141,11 @@ rte_crypto_cipher_operation_strings[] = {
};
/**
+ * @deprecated
* The crypto auth algorithm strings identifiers.
* It could be used in application command line.
*/
+__rte_deprecated
const char *
rte_crypto_auth_algorithm_strings[] = {
[RTE_CRYPTO_AUTH_AES_CBC_MAC] = "aes-cbc-mac",
@@ -149,9 +186,55 @@ rte_crypto_auth_algorithm_strings[] = {
};
/**
+ * The crypto auth algorithm strings identifiers.
+ * Not to be used in application directly.
+ * Application can use rte_cryptodev_get_auth_algo_string().
+ */
+static const char *
+crypto_auth_algorithm_strings[] = {
+ [RTE_CRYPTO_AUTH_AES_CBC_MAC] = "aes-cbc-mac",
+ [RTE_CRYPTO_AUTH_AES_CMAC] = "aes-cmac",
+ [RTE_CRYPTO_AUTH_AES_GMAC] = "aes-gmac",
+ [RTE_CRYPTO_AUTH_AES_XCBC_MAC] = "aes-xcbc-mac",
+
+ [RTE_CRYPTO_AUTH_MD5] = "md5",
+ [RTE_CRYPTO_AUTH_MD5_HMAC] = "md5-hmac",
+
+ [RTE_CRYPTO_AUTH_NULL] = "null",
+
+ [RTE_CRYPTO_AUTH_SHA1] = "sha1",
+ [RTE_CRYPTO_AUTH_SHA1_HMAC] = "sha1-hmac",
+
+ [RTE_CRYPTO_AUTH_SHA224] = "sha2-224",
+ [RTE_CRYPTO_AUTH_SHA224_HMAC] = "sha2-224-hmac",
+ [RTE_CRYPTO_AUTH_SHA256] = "sha2-256",
+ [RTE_CRYPTO_AUTH_SHA256_HMAC] = "sha2-256-hmac",
+ [RTE_CRYPTO_AUTH_SHA384] = "sha2-384",
+ [RTE_CRYPTO_AUTH_SHA384_HMAC] = "sha2-384-hmac",
+ [RTE_CRYPTO_AUTH_SHA512] = "sha2-512",
+ [RTE_CRYPTO_AUTH_SHA512_HMAC] = "sha2-512-hmac",
+
+ [RTE_CRYPTO_AUTH_SHA3_224] = "sha3-224",
+ [RTE_CRYPTO_AUTH_SHA3_224_HMAC] = "sha3-224-hmac",
+ [RTE_CRYPTO_AUTH_SHA3_256] = "sha3-256",
+ [RTE_CRYPTO_AUTH_SHA3_256_HMAC] = "sha3-256-hmac",
+ [RTE_CRYPTO_AUTH_SHA3_384] = "sha3-384",
+ [RTE_CRYPTO_AUTH_SHA3_384_HMAC] = "sha3-384-hmac",
+ [RTE_CRYPTO_AUTH_SHA3_512] = "sha3-512",
+ [RTE_CRYPTO_AUTH_SHA3_512_HMAC] = "sha3-512-hmac",
+
+ [RTE_CRYPTO_AUTH_KASUMI_F9] = "kasumi-f9",
+ [RTE_CRYPTO_AUTH_SNOW3G_UIA2] = "snow3g-uia2",
+ [RTE_CRYPTO_AUTH_ZUC_EIA3] = "zuc-eia3",
+ [RTE_CRYPTO_AUTH_SM3] = "sm3"
+};
+
+/**
+ * @deprecated
* The crypto AEAD algorithm strings identifiers.
* It could be used in application command line.
*/
+__rte_deprecated
const char *
rte_crypto_aead_algorithm_strings[] = {
[RTE_CRYPTO_AEAD_AES_CCM] = "aes-ccm",
@@ -159,6 +242,19 @@ rte_crypto_aead_algorithm_strings[] = {
[RTE_CRYPTO_AEAD_CHACHA20_POLY1305] = "chacha20-poly1305"
};
+/**
+ * The crypto AEAD algorithm strings identifiers.
+ * Not to be used in application directly.
+ * Application can use rte_cryptodev_get_aead_algo_string().
+ */
+static const char *
+crypto_aead_algorithm_strings[] = {
+ [RTE_CRYPTO_AEAD_AES_CCM] = "aes-ccm",
+ [RTE_CRYPTO_AEAD_AES_GCM] = "aes-gcm",
+ [RTE_CRYPTO_AEAD_CHACHA20_POLY1305] = "chacha20-poly1305"
+};
+
+
/**
* The crypto AEAD operation strings identifiers.
* It could be used in application command line.
@@ -170,8 +266,10 @@ rte_crypto_aead_operation_strings[] = {
};
/**
+ * @deprecated
* Asymmetric crypto transform operation strings identifiers.
*/
+__rte_deprecated
const char *rte_crypto_asym_xform_strings[] = {
[RTE_CRYPTO_ASYM_XFORM_NONE] = "none",
[RTE_CRYPTO_ASYM_XFORM_RSA] = "rsa",
@@ -183,6 +281,23 @@ const char *rte_crypto_asym_xform_strings[] = {
[RTE_CRYPTO_ASYM_XFORM_ECPM] = "ecpm",
};
+/**
+ * Asymmetric crypto transform operation strings identifiers.
+ * Not to be used in application directly.
+ * Application can use rte_cryptodev_asym_get_xform_string().
+ */
+static const char *
+crypto_asym_xform_strings[] = {
+ [RTE_CRYPTO_ASYM_XFORM_NONE] = "none",
+ [RTE_CRYPTO_ASYM_XFORM_RSA] = "rsa",
+ [RTE_CRYPTO_ASYM_XFORM_MODEX] = "modexp",
+ [RTE_CRYPTO_ASYM_XFORM_MODINV] = "modinv",
+ [RTE_CRYPTO_ASYM_XFORM_DH] = "dh",
+ [RTE_CRYPTO_ASYM_XFORM_DSA] = "dsa",
+ [RTE_CRYPTO_ASYM_XFORM_ECDSA] = "ecdsa",
+ [RTE_CRYPTO_ASYM_XFORM_ECPM] = "ecpm",
+};
+
/**
* Asymmetric crypto operation strings identifiers.
*/
@@ -227,8 +342,8 @@ rte_cryptodev_get_cipher_algo_enum(enum rte_crypto_cipher_algorithm *algo_enum,
unsigned int i;
int ret = -1; /* Invalid string */
- for (i = 1; i < RTE_DIM(rte_crypto_cipher_algorithm_strings); i++) {
- if (strcmp(algo_string, rte_crypto_cipher_algorithm_strings[i]) == 0) {
+ for (i = 1; i < RTE_DIM(crypto_cipher_algorithm_strings); i++) {
+ if (strcmp(algo_string, crypto_cipher_algorithm_strings[i]) == 0) {
*algo_enum = (enum rte_crypto_cipher_algorithm) i;
ret = 0;
break;
@@ -247,8 +362,8 @@ rte_cryptodev_get_auth_algo_enum(enum rte_crypto_auth_algorithm *algo_enum,
unsigned int i;
int ret = -1; /* Invalid string */
- for (i = 1; i < RTE_DIM(rte_crypto_auth_algorithm_strings); i++) {
- if (strcmp(algo_string, rte_crypto_auth_algorithm_strings[i]) == 0) {
+ for (i = 1; i < RTE_DIM(crypto_auth_algorithm_strings); i++) {
+ if (strcmp(algo_string, crypto_auth_algorithm_strings[i]) == 0) {
*algo_enum = (enum rte_crypto_auth_algorithm) i;
ret = 0;
break;
@@ -267,8 +382,8 @@ rte_cryptodev_get_aead_algo_enum(enum rte_crypto_aead_algorithm *algo_enum,
unsigned int i;
int ret = -1; /* Invalid string */
- for (i = 1; i < RTE_DIM(rte_crypto_aead_algorithm_strings); i++) {
- if (strcmp(algo_string, rte_crypto_aead_algorithm_strings[i]) == 0) {
+ for (i = 1; i < RTE_DIM(crypto_aead_algorithm_strings); i++) {
+ if (strcmp(algo_string, crypto_aead_algorithm_strings[i]) == 0) {
*algo_enum = (enum rte_crypto_aead_algorithm) i;
ret = 0;
break;
@@ -287,9 +402,9 @@ rte_cryptodev_asym_get_xform_enum(enum rte_crypto_asym_xform_type *xform_enum,
unsigned int i;
int ret = -1; /* Invalid string */
- for (i = 1; i < RTE_DIM(rte_crypto_asym_xform_strings); i++) {
+ for (i = 1; i < RTE_DIM(crypto_asym_xform_strings); i++) {
if (strcmp(xform_string,
- rte_crypto_asym_xform_strings[i]) == 0) {
+ crypto_asym_xform_strings[i]) == 0) {
*xform_enum = (enum rte_crypto_asym_xform_type) i;
ret = 0;
break;
@@ -301,6 +416,58 @@ rte_cryptodev_asym_get_xform_enum(enum rte_crypto_asym_xform_type *xform_enum,
return ret;
}
+const char *
+rte_cryptodev_get_cipher_algo_string(enum rte_crypto_cipher_algorithm algo_enum)
+{
+ const char *alg_str = NULL;
+
+ if ((unsigned int)algo_enum < RTE_DIM(crypto_cipher_algorithm_strings))
+ alg_str = crypto_cipher_algorithm_strings[algo_enum];
+
+ rte_cryptodev_trace_get_cipher_algo_string(algo_enum, alg_str);
+
+ return alg_str;
+}
+
+const char *
+rte_cryptodev_get_auth_algo_string(enum rte_crypto_auth_algorithm algo_enum)
+{
+ const char *alg_str = NULL;
+
+ if ((unsigned int)algo_enum < RTE_DIM(crypto_auth_algorithm_strings))
+ alg_str = crypto_auth_algorithm_strings[algo_enum];
+
+ rte_cryptodev_trace_get_auth_algo_string(algo_enum, alg_str);
+
+ return alg_str;
+}
+
+const char *
+rte_cryptodev_get_aead_algo_string(enum rte_crypto_aead_algorithm algo_enum)
+{
+ const char *alg_str = NULL;
+
+ if ((unsigned int)algo_enum < RTE_DIM(crypto_aead_algorithm_strings))
+ alg_str = crypto_aead_algorithm_strings[algo_enum];
+
+ rte_cryptodev_trace_get_aead_algo_string(algo_enum, alg_str);
+
+ return alg_str;
+}
+
+const char *
+rte_cryptodev_asym_get_xform_string(enum rte_crypto_asym_xform_type xform_enum)
+{
+ const char *xform_str = NULL;
+
+ if ((unsigned int)xform_enum < RTE_DIM(crypto_asym_xform_strings))
+ xform_str = crypto_asym_xform_strings[xform_enum];
+
+ rte_cryptodev_trace_asym_get_xform_string(xform_enum, xform_str);
+
+ return xform_str;
+}
+
/**
* The crypto auth operation strings identifiers.
* It could be used in application command line.
diff --git a/lib/cryptodev/rte_cryptodev.h b/lib/cryptodev/rte_cryptodev.h
index 86d792e2e7..8f41a009e3 100644
--- a/lib/cryptodev/rte_cryptodev.h
+++ b/lib/cryptodev/rte_cryptodev.h
@@ -406,6 +406,58 @@ int
rte_cryptodev_asym_get_xform_enum(enum rte_crypto_asym_xform_type *xform_enum,
const char *xform_string);
+/**
+ * Provide the cipher algorithm string, given an algorithm enum.
+ *
+ * @param algo_enum cipher algorithm enum
+ *
+ * @return
+ * - Return NULL if enum is not valid
+ * - Return algo_string corresponding to enum
+ */
+__rte_experimental
+const char *
+rte_cryptodev_get_cipher_algo_string(enum rte_crypto_cipher_algorithm algo_enum);
+
+/**
+ * Provide the authentication algorithm string, given an algorithm enum.
+ *
+ * @param algo_enum auth algorithm enum
+ *
+ * @return
+ * - Return NULL if enum is not valid
+ * - Return algo_string corresponding to enum
+ */
+__rte_experimental
+const char *
+rte_cryptodev_get_auth_algo_string(enum rte_crypto_auth_algorithm algo_enum);
+
+/**
+ * Provide the AEAD algorithm string, given an algorithm enum.
+ *
+ * @param algo_enum AEAD algorithm enum
+ *
+ * @return
+ * - Return NULL if enum is not valid
+ * - Return algo_string corresponding to enum
+ */
+__rte_experimental
+const char *
+rte_cryptodev_get_aead_algo_string(enum rte_crypto_aead_algorithm algo_enum);
+
+/**
+ * Provide the Asymmetric xform string, given an xform enum.
+ *
+ * @param xform_enum xform type enum
+ *
+ * @return
+ * - Return NULL, if enum is not valid.
+ * - Return xform string, for valid enum.
+ */
+__rte_experimental
+const char *
+rte_cryptodev_asym_get_xform_string(enum rte_crypto_asym_xform_type xform_enum);
+
/** Macro used at end of crypto PMD list */
#define RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST() \
diff --git a/lib/cryptodev/rte_cryptodev_trace.h b/lib/cryptodev/rte_cryptodev_trace.h
index 6c214ce6ea..5e694379b1 100644
--- a/lib/cryptodev/rte_cryptodev_trace.h
+++ b/lib/cryptodev/rte_cryptodev_trace.h
@@ -189,6 +189,30 @@ RTE_TRACE_POINT(
rte_trace_point_emit_int(ret);
)
+RTE_TRACE_POINT(
+ rte_cryptodev_trace_get_aead_algo_string,
+ RTE_TRACE_POINT_ARGS(enum rte_crypto_aead_algorithm algo_enum,
+ const char *algo_string),
+ rte_trace_point_emit_int(algo_enum);
+ rte_trace_point_emit_string(algo_string);
+)
+
+RTE_TRACE_POINT(
+ rte_cryptodev_trace_get_auth_algo_string,
+ RTE_TRACE_POINT_ARGS(enum rte_crypto_auth_algorithm algo_enum,
+ const char *algo_string),
+ rte_trace_point_emit_int(algo_enum);
+ rte_trace_point_emit_string(algo_string);
+)
+
+RTE_TRACE_POINT(
+ rte_cryptodev_trace_get_cipher_algo_string,
+ RTE_TRACE_POINT_ARGS(enum rte_crypto_cipher_algorithm algo_enum,
+ const char *algo_string),
+ rte_trace_point_emit_int(algo_enum);
+ rte_trace_point_emit_string(algo_string);
+)
+
RTE_TRACE_POINT(
rte_cryptodev_trace_get_dev_id,
RTE_TRACE_POINT_ARGS(const char *name, int ret),
@@ -351,6 +375,14 @@ RTE_TRACE_POINT(
rte_trace_point_emit_int(ret);
)
+RTE_TRACE_POINT(
+ rte_cryptodev_trace_asym_get_xform_string,
+ RTE_TRACE_POINT_ARGS(enum rte_crypto_asym_xform_type xform_enum,
+ const char *xform_string),
+ rte_trace_point_emit_int(xform_enum);
+ rte_trace_point_emit_string(xform_string);
+)
+
RTE_TRACE_POINT(
rte_cryptodev_trace_asym_xform_capability_check_modlen,
RTE_TRACE_POINT_ARGS(const void *capability, uint16_t modlen, int ret),
diff --git a/lib/cryptodev/version.map b/lib/cryptodev/version.map
index 00c99fb45c..372d042931 100644
--- a/lib/cryptodev/version.map
+++ b/lib/cryptodev/version.map
@@ -150,11 +150,21 @@ EXPERIMENTAL {
__rte_cryptodev_trace_sym_session_get_user_data;
__rte_cryptodev_trace_sym_session_set_user_data;
__rte_cryptodev_trace_count;
+
+ # added 23.03
+ rte_cryptodev_asym_get_xform_string;
+ rte_cryptodev_get_aead_algo_string;
+ rte_cryptodev_get_auth_algo_string;
+ rte_cryptodev_get_cipher_algo_string;
};
INTERNAL {
global:
+ __rte_cryptodev_trace_asym_get_xform_string;
+ __rte_cryptodev_trace_get_aead_algo_string;
+ __rte_cryptodev_trace_get_auth_algo_string;
+ __rte_cryptodev_trace_get_cipher_algo_string;
cryptodev_fp_ops_reset;
cryptodev_fp_ops_set;
rte_cryptodev_allocate_driver;
--
2.25.1
^ permalink raw reply [relevance 2%]
* RE: [PATCH v3 1/3] ethdev: enable direct rearm with separate API
@ 2023-01-04 10:11 4% ` Morten Brørup
0 siblings, 0 replies; 200+ results
From: Morten Brørup @ 2023-01-04 10:11 UTC (permalink / raw)
To: Feifei Wang, thomas, Ferruh Yigit, Andrew Rybchenko
Cc: dev, konstantin.v.ananyev, nd, Honnappa Nagarahalli, Ruifeng Wang, nd
> From: Feifei Wang [mailto:Feifei.Wang2@arm.com]
> Sent: Wednesday, 4 January 2023 09.51
>
> Hi, Morten
>
> > 发件人: Morten Brørup <mb@smartsharesystems.com>
> > 发送时间: Wednesday, January 4, 2023 4:22 PM
> >
> > > From: Feifei Wang [mailto:feifei.wang2@arm.com]
> > > Sent: Wednesday, 4 January 2023 08.31
> > >
> > > Add 'tx_fill_sw_ring' and 'rx_flush_descriptor' API into direct
> rearm
> > > mode for separate Rx and Tx Operation. And this can support
> different
> > > multiple sources in direct rearm mode. For examples, Rx driver is
> > > ixgbe, and Tx driver is i40e.
> > >
> > > Suggested-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > Suggested-by: Ruifeng Wang <ruifeng.wang@arm.com>
> > > Signed-off-by: Feifei Wang <feifei.wang2@arm.com>
> > > Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
> > > Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > ---
> >
> > This feature looks very promising for performance. I am pleased to
> see
> > progress on it.
> >
> Thanks very much for your reviewing.
>
> > Please confirm that the fast path functions are still thread safe,
> i.e. one EAL
> > thread may be calling rte_eth_rx_burst() while another EAL thread is
> calling
> > rte_eth_tx_burst().
> >
> For the multiple threads safe, like we say in cover letter, current
> direct-rearm support
> Rx and Tx in the same thread. If we consider multiple threads like
> 'pipeline model', there
> need to add 'lock' in the data path which can decrease the performance.
> Thus, the first step we do is try to enable direct-rearm in the single
> thread, and then we will consider
> to enable direct rearm in multiple threads and improve the performance.
OK, doing it in steps is a good idea for a feature like this - makes it easier to understand and review.
When proceeding to add support for the "pipeline model", perhaps the lockless principles from the rte_ring can be used in this feature too.
From a high level perspective, I'm somewhat worried that releasing a "work-in-progress" version of this feature in some DPDK version will cause API/ABI breakage discussions when progressing to the next steps of the implementation to make the feature more complete. Not only support for thread safety across simultaneous RX and TX, but also support for multiple mbuf pools per RX queue [1]. Marking the functions experimental should alleviate such discussions, but there is a risk of pushback to not break the API/ABI anyway.
[1]: https://elixir.bootlin.com/dpdk/v22.11.1/source/lib/ethdev/rte_ethdev.h#L1105
[...]
> > > --- a/lib/ethdev/ethdev_driver.h
> > > +++ b/lib/ethdev/ethdev_driver.h
> > > @@ -59,6 +59,10 @@ struct rte_eth_dev {
> > > eth_rx_descriptor_status_t rx_descriptor_status;
> > > /** Check the status of a Tx descriptor */
> > > eth_tx_descriptor_status_t tx_descriptor_status;
> > > + /** Fill Rx sw-ring with Tx buffers in direct rearm mode */
> > > + eth_tx_fill_sw_ring_t tx_fill_sw_ring;
> >
> > What is "Rx sw-ring"? Please confirm that this is not an Intel PMD
> specific
> > term and/or implementation detail, e.g. by providing a conceptual
> > implementation for a non-Intel PMD, e.g. mlx5.
> Rx sw_ring is used to store mbufs in intel PMD. This is the same as
> 'rxq->elts'
> in mlx5.
Sounds good.
Then all we need is consensus on a generic name for this, unless "Rx sw-ring" already is the generic name. (I'm not a PMD developer, so I might be completely off track here.) Naming is often debatable, so I'll stop talking about it now - I only wanted to highlight that we should avoid vendor-specific terms in public APIs intended to be implemented by multiple vendors. On the other hand... if no other vendors raise their voices before merging into the DPDK main repository, they forfeit their right to complain about it. ;-)
> Agree with that we need to providing a conceptual
> implementation for all PMDs.
My main point is that we should ensure that the feature is not too tightly coupled with the way Intel PMDs implement mbuf handling. Providing a conceptual implementation for a non-Intel PMD is one way of checking this.
The actual implementation in other PMDs could be left up to the various NIC vendors.
^ permalink raw reply [relevance 4%]
* RE: [PATCH v2] cryptodev: add algo enums to string conversion APIs
2023-01-04 6:18 2% ` [PATCH v2] " Akhil Goyal
@ 2023-01-05 10:56 0% ` Akhil Goyal
0 siblings, 0 replies; 200+ results
From: Akhil Goyal @ 2023-01-05 10:56 UTC (permalink / raw)
To: Akhil Goyal, dev
Cc: ciara.power, fanzhang.oss, kai.ji, pablo.de.lara.guarch,
hemant.agrawal, matan, g.singh, ruifeng.wang, Anoob Joseph,
radu.nicolau, Volodymyr Fialko, ktraynor, david.marchand, thomas
> Subject: [PATCH v2] cryptodev: add algo enums to string conversion APIs
>
> Symmetric/Asymmetric algorithm strings are accessed by application
> using arrays in cryptodev lib, which hampers new algorithms addition
> in the array due to ABI breakage.
> These arrays are now deprecated and will be removed in next ABI break
> release.
> New APIs are added for getting the algorithm strings based on enum values.
>
> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
> Acked-by: Anoob Joseph <anoobj@marvell.com>
> Acked-by: Ciara Power <ciara.power@intel.com>
> Acked-by: Fan Zhang <fanzhang.oss@gmail.com>
> ---
Applied to dpdk-next-crypto
^ permalink raw reply [relevance 0%]
* [PATCH] devtools: parallelize ABI check
@ 2023-01-07 13:39 33% Thomas Monjalon
2023-01-09 9:34 23% ` [PATCH v2] " Thomas Monjalon
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Thomas Monjalon @ 2023-01-07 13:39 UTC (permalink / raw)
Cc: dev, David Marchand
Generation and comparison of ABI dumps are done on multiple cores
thanks to xargs -P0.
It can accelerate this long step by 5 in my tests.
xargs reports a global error if one of the process has an error.
Running a shell function with xargs requires to export it with -f.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
devtools/check-abi.sh | 33 ++++++++++++++++++++-------------
devtools/gen-abi.sh | 5 +++--
2 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
index c583eae2fd..e2fa49217d 100755
--- a/devtools/check-abi.sh
+++ b/devtools/check-abi.sh
@@ -34,19 +34,10 @@ else
ABIDIFF_OPTIONS="$ABIDIFF_OPTIONS --headers-dir2 $incdir2"
fi
-error=
-for dump in $(find $refdir -name "*.dump"); do
- name=$(basename $dump)
- dump2=$(find $newdir -name $name)
- if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
- echo "Error: cannot find $name in $newdir" >&2
- error=1
- continue
- fi
- abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
+run_diff() { # <dump1> <dump2>
+ abidiff $ABIDIFF_OPTIONS $1 $2 || {
abiret=$?
- echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'" >&2
- error=1
+ echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $1 $2'" >&2
echo
if [ $(($abiret & 3)) -ne 0 ]; then
echo "ABIDIFF_ERROR|ABIDIFF_USAGE_ERROR, this could be a script or environment issue." >&2
@@ -58,7 +49,23 @@ for dump in $(find $refdir -name "*.dump"); do
echo "ABIDIFF_ABI_INCOMPATIBLE_CHANGE, this change breaks the ABI." >&2
fi
echo
+ return $abiret
}
-done
+}
+export -f run_diff
+
+error=
+for dump in $(find $refdir -name "*.dump"); do
+ name=$(basename $dump)
+ dump2=$(find $newdir -name $name)
+ if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
+ echo "Error: cannot find $name in $newdir" >&2
+ error=1
+ continue
+ fi
+ echo $dump $dump2
+done |
+xargs -n2 -P0 sh -c 'run_diff $0 $1' ||
+error=1
[ -z "$error" ] || [ -n "$warnonly" ]
diff --git a/devtools/gen-abi.sh b/devtools/gen-abi.sh
index f15a3b9aaf..61f7510ea1 100755
--- a/devtools/gen-abi.sh
+++ b/devtools/gen-abi.sh
@@ -22,5 +22,6 @@ for f in $(find $installdir -name "*.so.*"); do
fi
libname=$(basename $f)
- abidw --out-file $dumpdir/${libname%.so*}.dump $f
-done
+ echo $dumpdir/${libname%.so*}.dump $f
+done |
+xargs -n2 -P0 abidw --out-file
--
2.39.0
^ permalink raw reply [relevance 33%]
* [PATCH v2] devtools: parallelize ABI check
2023-01-07 13:39 33% [PATCH] devtools: parallelize ABI check Thomas Monjalon
@ 2023-01-09 9:34 23% ` Thomas Monjalon
2023-01-10 11:08 4% ` Ferruh Yigit
2023-01-11 13:16 33% ` [PATCH v3] " Thomas Monjalon
2023-01-11 19:53 33% ` [PATCH v4] " Thomas Monjalon
2 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2023-01-09 9:34 UTC (permalink / raw)
To: David Marchand; +Cc: dev
Generation and comparison of ABI dumps are done on multiple cores
thanks to xargs -P0.
It can accelerate this long step by 5 in my tests.
xargs reports a global error if one of the process has an error.
Running a shell function with xargs requires to export it with -f,
and that is a specific capability of bash.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
v2:
- find dump2 inside the function
- force bash because of export -f
---
devtools/check-abi.sh | 20 +++++++++++++-------
devtools/gen-abi.sh | 5 +++--
2 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
index c583eae2fd..4409f65ccd 100755
--- a/devtools/check-abi.sh
+++ b/devtools/check-abi.sh
@@ -1,4 +1,4 @@
-#!/bin/sh -e
+#!/bin/bash -e
# SPDX-License-Identifier: BSD-3-Clause
# Copyright (c) 2019 Red Hat, Inc.
@@ -34,19 +34,18 @@ else
ABIDIFF_OPTIONS="$ABIDIFF_OPTIONS --headers-dir2 $incdir2"
fi
-error=
-for dump in $(find $refdir -name "*.dump"); do
+run_diff() { # <dump1> <dir2>
+ dump=$1
+ newdir=$2
name=$(basename $dump)
dump2=$(find $newdir -name $name)
if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
echo "Error: cannot find $name in $newdir" >&2
- error=1
- continue
+ return 1
fi
abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
abiret=$?
echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'" >&2
- error=1
echo
if [ $(($abiret & 3)) -ne 0 ]; then
echo "ABIDIFF_ERROR|ABIDIFF_USAGE_ERROR, this could be a script or environment issue." >&2
@@ -58,7 +57,14 @@ for dump in $(find $refdir -name "*.dump"); do
echo "ABIDIFF_ABI_INCOMPATIBLE_CHANGE, this change breaks the ABI." >&2
fi
echo
+ return 1
}
-done
+}
+export -f run_diff
+
+error=
+find $refdir -name "*.dump" |
+xargs -n1 -P0 sh -c 'run_diff $0 '$newdir ||
+error=1
[ -z "$error" ] || [ -n "$warnonly" ]
diff --git a/devtools/gen-abi.sh b/devtools/gen-abi.sh
index f15a3b9aaf..61f7510ea1 100755
--- a/devtools/gen-abi.sh
+++ b/devtools/gen-abi.sh
@@ -22,5 +22,6 @@ for f in $(find $installdir -name "*.so.*"); do
fi
libname=$(basename $f)
- abidw --out-file $dumpdir/${libname%.so*}.dump $f
-done
+ echo $dumpdir/${libname%.so*}.dump $f
+done |
+xargs -n2 -P0 abidw --out-file
--
2.39.0
^ permalink raw reply [relevance 23%]
* Re: [PATCH v2] devtools: parallelize ABI check
2023-01-09 9:34 23% ` [PATCH v2] " Thomas Monjalon
@ 2023-01-10 11:08 4% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2023-01-10 11:08 UTC (permalink / raw)
To: Thomas Monjalon, David Marchand; +Cc: dev
On 1/9/2023 9:34 AM, Thomas Monjalon wrote:
> Generation and comparison of ABI dumps are done on multiple cores
> thanks to xargs -P0.
> It can accelerate this long step by 5 in my tests.
>
> xargs reports a global error if one of the process has an error.
>
> Running a shell function with xargs requires to export it with -f,
> and that is a specific capability of bash.
>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> ---
> v2:
> - find dump2 inside the function
> - force bash because of export -f
It reduces script runtime ~2mins in my test.
Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
^ permalink raw reply [relevance 4%]
* Re: [PATCH V4 0/5] app/testpmd: support mulitple process attach and detach port
@ 2023-01-10 16:51 3% ` Ferruh Yigit
2023-01-11 0:53 0% ` lihuisong (C)
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2023-01-10 16:51 UTC (permalink / raw)
To: Huisong Li, dev, andrew.rybchenko
Cc: thomas, liudongdong3, huangdaode, fengchengwen
On 12/6/2022 9:26 AM, Huisong Li wrote:
> This patchset fix some bugs and support attaching and detaching port
> in primary and secondary.
>
> ---
> -v4: fix a misspelling.
> -v3:
> 1) merge patch 1/6 and patch 2/6 into patch 1/5, and add modification
> for other bus type.
> 2) add a RTE_ETH_DEV_ALLOCATED state in rte_eth_dev_state to resolve
> the probelm in patch 2/5.
> -v2: resend due to CI unexplained failure.
>
> Huisong Li (5):
> drivers/bus: restore driver assignment at front of probing
> ethdev: fix skip valid port in probing callback
> app/testpmd: check the validity of the port
> app/testpmd: add attach and detach port for multiple process
> app/testpmd: stop forwarding in new or destroy event
>
Hi Huisong,
I haven't checked the patch in detail yet, but I can see it gives some
ABI compatibility warnings, is this expected:
1 function with some indirect sub-type change:
[C] 'function int dpaa_eth_eventq_attach(const rte_eth_dev*, int, u16,
const rte_event_eth_rx_adapter_queue_conf*)' at dpaa_ethdev.c:1149:1 has
some indirect sub-type changes:
parameter 1 of type 'const rte_eth_dev*' has sub-type changes:
in pointed to type 'const rte_eth_dev':
in unqualified underlying type 'struct rte_eth_dev' at
ethdev_driver.h:50:1:
type size hasn't changed
1 data member change:
type of 'rte_eth_dev_state state' changed:
type size hasn't changed
1 enumerator insertion:
'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
2 enumerator changes:
'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
to '2' at rte_ethdev.h:2000:1
'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2'
to '3' at rte_ethdev.h:2000:1
1 function with some indirect sub-type change:
[C] 'function int rte_pmd_i40e_set_switch_dev(uint16_t, rte_eth_dev*)'
at rte_pmd_i40e.c:3266:1 has some indirect sub-type changes:
parameter 2 of type 'rte_eth_dev*' has sub-type changes:
in pointed to type 'struct rte_eth_dev' at ethdev_driver.h:50:1:
type size hasn't changed
1 data member change:
type of 'rte_eth_dev_state state' changed:
type size hasn't changed
1 enumerator insertion:
'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
2 enumerator changes:
'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
to '2' at rte_ethdev.h:2000:1
'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2' to
'3' at rte_ethdev.h:2000:1
1 function with some indirect sub-type change:
[C] 'function rte_eth_dev* rte_eth_dev_allocate(const char*)' at
ethdev_driver.c:72:1 has some indirect sub-type changes:
return type changed:
in pointed to type 'struct rte_eth_dev' at ethdev_driver.h:50:1:
type size hasn't changed
1 data member change:
type of 'rte_eth_dev_state state' changed:
type size hasn't changed
1 enumerator insertion:
'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
2 enumerator changes:
'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
to '2' at rte_ethdev.h:2000:1
'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2' to
'3' at rte_ethdev.h:2000:1
... there are more warnings for same issue ...
^ permalink raw reply [relevance 3%]
* Re: RFC abstracting atomics
@ 2023-01-10 20:10 3% ` Tyler Retzlaff
2023-01-11 10:10 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Tyler Retzlaff @ 2023-01-10 20:10 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev
On Tue, Jan 10, 2023 at 09:16:48AM +0000, Bruce Richardson wrote:
> On Mon, Jan 09, 2023 at 02:56:04PM -0800, Tyler Retzlaff wrote:
> > hi folks,
> >
> > i would like to introduce a layer of abstraction that would allow
> > optional use of standard C11 atomics when the platform / toolchain
> > combination has them available.
> >
> > making the option usable would be a phased approach intended to focus
> > review and minimize dealing with churn on such a broad change.
> >
> > 1. provide an initial series to add the abstraction and the ability
> > control enablement with a meson option enable_stdatomics=false will
> > be the default.
> >
> > for all existing platform / toolchain combinations the default would
> > remain false. i.e. i have no plans to enable it for existing platforms
> > toolchain combinations but leaves a change of default open to the
> > community as a future discussion if it is desired.
> >
> > 2. once the initial abstraction is integrated a series will be introduced to
> > port the tree to the abstraction with enable_stdatomics=false. the goal
> > being low or no change to the current use of gcc builtin C++11 memory
> > model atomics.
> >
> > 3. once the tree is ported a final series will be introduced to introduce
> > the remaining change to allow the use of enable_stdatomics=true.
> >
> > would appreciate any assistance / suggestions you can provide to
> > introduce the abstraction smoothly.
> >
>
> Plan generally sounds ok. However, beyond point #3, would there then be
> plans to remove the option and always use stdatomics in future?
that is a discussion for the community i think on a per-platform /
per-toolchain basis. there is likely to be resistance which is why i'm
favoring the opt-in if you want model.
some potential arguments against switching.
* it's an abi break there is no way around it.
* old compiler x stdatomics implementation is less optimal than
old compiler x __atomics (potential argument).
* there's some "mixed" use of variables in the tree where sometimes we
operate on them as if they are atomic and sometimes not. the std
atomics apis doesn't support this sometimes atomic codegen you either
get atomic or you don't.
* direct use of atomics default to seq_cst ordering if the strengthening
of the ordering is not desired each variable needs to be hunted down
and explicitly returned to relaxed ordering access.
> To slightly expand the scope of the discussion - would it be worthwhile
> putting these abstractions in a new library in DPDK other than EAL, to
> start the process of splitting out some of the lower-level material from
> that library?
the abstraction as i have prototyped it is a set of conditionally
compiled macros where the macros mirror the standard c atomics for
naming and have been placed in include/generic/rte_atomics.h
i've no problem splitting it out into a separate library and then have
EAL depend on it, but it is currently header only so i'm not sure if it
is worth doing for that.
we can chew on that more in a couple days when i submit the base series
if you like.
>
> /Bruce
^ permalink raw reply [relevance 3%]
* Re: [PATCH V4 0/5] app/testpmd: support mulitple process attach and detach port
2023-01-10 16:51 3% ` Ferruh Yigit
@ 2023-01-11 0:53 0% ` lihuisong (C)
2023-01-11 10:27 3% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: lihuisong (C) @ 2023-01-11 0:53 UTC (permalink / raw)
To: Ferruh Yigit, dev, andrew.rybchenko
Cc: thomas, liudongdong3, huangdaode, fengchengwen
在 2023/1/11 0:51, Ferruh Yigit 写道:
> On 12/6/2022 9:26 AM, Huisong Li wrote:
>> This patchset fix some bugs and support attaching and detaching port
>> in primary and secondary.
>>
>> ---
>> -v4: fix a misspelling.
>> -v3:
>> 1) merge patch 1/6 and patch 2/6 into patch 1/5, and add modification
>> for other bus type.
>> 2) add a RTE_ETH_DEV_ALLOCATED state in rte_eth_dev_state to resolve
>> the probelm in patch 2/5.
>> -v2: resend due to CI unexplained failure.
>>
>> Huisong Li (5):
>> drivers/bus: restore driver assignment at front of probing
>> ethdev: fix skip valid port in probing callback
>> app/testpmd: check the validity of the port
>> app/testpmd: add attach and detach port for multiple process
>> app/testpmd: stop forwarding in new or destroy event
>>
> Hi Huisong,
>
> I haven't checked the patch in detail yet, but I can see it gives some
> ABI compatibility warnings, is this expected:
This is to be expected. Because we insert a device state,
RTE_ETH_DEV_ALLOCATED,
before RTE_ETH_DEV_ATTACHED for resolving the issue patch 2/5 mentioned.
We may have to announce it. What do you think?
>
> 1 function with some indirect sub-type change:
>
> [C] 'function int dpaa_eth_eventq_attach(const rte_eth_dev*, int, u16,
> const rte_event_eth_rx_adapter_queue_conf*)' at dpaa_ethdev.c:1149:1 has
> some indirect sub-type changes:
> parameter 1 of type 'const rte_eth_dev*' has sub-type changes:
> in pointed to type 'const rte_eth_dev':
> in unqualified underlying type 'struct rte_eth_dev' at
> ethdev_driver.h:50:1:
> type size hasn't changed
> 1 data member change:
> type of 'rte_eth_dev_state state' changed:
> type size hasn't changed
> 1 enumerator insertion:
> 'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
> 2 enumerator changes:
> 'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
> to '2' at rte_ethdev.h:2000:1
> 'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2'
> to '3' at rte_ethdev.h:2000:1
>
> 1 function with some indirect sub-type change:
>
> [C] 'function int rte_pmd_i40e_set_switch_dev(uint16_t, rte_eth_dev*)'
> at rte_pmd_i40e.c:3266:1 has some indirect sub-type changes:
> parameter 2 of type 'rte_eth_dev*' has sub-type changes:
> in pointed to type 'struct rte_eth_dev' at ethdev_driver.h:50:1:
> type size hasn't changed
> 1 data member change:
> type of 'rte_eth_dev_state state' changed:
> type size hasn't changed
> 1 enumerator insertion:
> 'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
> 2 enumerator changes:
> 'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
> to '2' at rte_ethdev.h:2000:1
> 'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2' to
> '3' at rte_ethdev.h:2000:1
>
> 1 function with some indirect sub-type change:
>
> [C] 'function rte_eth_dev* rte_eth_dev_allocate(const char*)' at
> ethdev_driver.c:72:1 has some indirect sub-type changes:
> return type changed:
> in pointed to type 'struct rte_eth_dev' at ethdev_driver.h:50:1:
> type size hasn't changed
> 1 data member change:
> type of 'rte_eth_dev_state state' changed:
> type size hasn't changed
> 1 enumerator insertion:
> 'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
> 2 enumerator changes:
> 'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
> to '2' at rte_ethdev.h:2000:1
> 'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2' to
> '3' at rte_ethdev.h:2000:1
>
> ... there are more warnings for same issue ...
>
> .
^ permalink raw reply [relevance 0%]
* Re: RFC abstracting atomics
2023-01-10 20:10 3% ` Tyler Retzlaff
@ 2023-01-11 10:10 0% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2023-01-11 10:10 UTC (permalink / raw)
To: Tyler Retzlaff; +Cc: dev
On Tue, Jan 10, 2023 at 12:10:33PM -0800, Tyler Retzlaff wrote:
> On Tue, Jan 10, 2023 at 09:16:48AM +0000, Bruce Richardson wrote:
> > On Mon, Jan 09, 2023 at 02:56:04PM -0800, Tyler Retzlaff wrote:
> > > hi folks,
> > >
> > > i would like to introduce a layer of abstraction that would allow
> > > optional use of standard C11 atomics when the platform / toolchain
> > > combination has them available.
> > >
> > > making the option usable would be a phased approach intended to focus
> > > review and minimize dealing with churn on such a broad change.
> > >
> > > 1. provide an initial series to add the abstraction and the ability
> > > control enablement with a meson option enable_stdatomics=false will
> > > be the default.
> > >
> > > for all existing platform / toolchain combinations the default would
> > > remain false. i.e. i have no plans to enable it for existing platforms
> > > toolchain combinations but leaves a change of default open to the
> > > community as a future discussion if it is desired.
> > >
> > > 2. once the initial abstraction is integrated a series will be introduced to
> > > port the tree to the abstraction with enable_stdatomics=false. the goal
> > > being low or no change to the current use of gcc builtin C++11 memory
> > > model atomics.
> > >
> > > 3. once the tree is ported a final series will be introduced to introduce
> > > the remaining change to allow the use of enable_stdatomics=true.
> > >
> > > would appreciate any assistance / suggestions you can provide to
> > > introduce the abstraction smoothly.
> > >
> >
> > Plan generally sounds ok. However, beyond point #3, would there then be
> > plans to remove the option and always use stdatomics in future?
>
> that is a discussion for the community i think on a per-platform /
> per-toolchain basis. there is likely to be resistance which is why i'm
> favoring the opt-in if you want model.
>
> some potential arguments against switching.
>
> * it's an abi break there is no way around it.
> * old compiler x stdatomics implementation is less optimal than
> old compiler x __atomics (potential argument).
> * there's some "mixed" use of variables in the tree where sometimes we
> operate on them as if they are atomic and sometimes not. the std
> atomics apis doesn't support this sometimes atomic codegen you either
> get atomic or you don't.
> * direct use of atomics default to seq_cst ordering if the strengthening
> of the ordering is not desired each variable needs to be hunted down
> and explicitly returned to relaxed ordering access.
>
> > To slightly expand the scope of the discussion - would it be worthwhile
> > putting these abstractions in a new library in DPDK other than EAL, to
> > start the process of splitting out some of the lower-level material from
> > that library?
>
> the abstraction as i have prototyped it is a set of conditionally
> compiled macros where the macros mirror the standard c atomics for
> naming and have been placed in include/generic/rte_atomics.h
>
> i've no problem splitting it out into a separate library and then have
> EAL depend on it, but it is currently header only so i'm not sure if it
> is worth doing for that.
>
> we can chew on that more in a couple days when i submit the base series
> if you like.
>
Thanks.
One additional point that just became clear to me when I started thinking
about upping our DPDK C-standard-baseline. We need to be careful what we
are considering when we up our C baseline. We can mandate a specific
compiler minimum and C version for compiling up DPDK itself, but I think we
should not mandate that for the end applications.
That means that our header files, such as atomics, should not require C99
or C11 even if the build of DPDK itself does. More specifically, even if we
bump DPDK minimum to C11, we should still allow apps to build using older
compiler settings.
Therefore, we probably need to maintain non-C11 atomics code paths in
headers beyond the point at which DPDK itself uses C11 as a code baseline.
/Bruce
^ permalink raw reply [relevance 0%]
* Re: [PATCH V4 0/5] app/testpmd: support mulitple process attach and detach port
2023-01-11 0:53 0% ` lihuisong (C)
@ 2023-01-11 10:27 3% ` Ferruh Yigit
2023-01-11 10:46 0% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2023-01-11 10:27 UTC (permalink / raw)
To: lihuisong (C), dev, andrew.rybchenko
Cc: thomas, liudongdong3, huangdaode, fengchengwen
On 1/11/2023 12:53 AM, lihuisong (C) wrote:
>
> 在 2023/1/11 0:51, Ferruh Yigit 写道:
>> On 12/6/2022 9:26 AM, Huisong Li wrote:
>>> This patchset fix some bugs and support attaching and detaching port
>>> in primary and secondary.
>>>
>>> ---
>>> -v4: fix a misspelling.
>>> -v3:
>>> 1) merge patch 1/6 and patch 2/6 into patch 1/5, and add
>>> modification
>>> for other bus type.
>>> 2) add a RTE_ETH_DEV_ALLOCATED state in rte_eth_dev_state to resolve
>>> the probelm in patch 2/5.
>>> -v2: resend due to CI unexplained failure.
>>>
>>> Huisong Li (5):
>>> drivers/bus: restore driver assignment at front of probing
>>> ethdev: fix skip valid port in probing callback
>>> app/testpmd: check the validity of the port
>>> app/testpmd: add attach and detach port for multiple process
>>> app/testpmd: stop forwarding in new or destroy event
>>>
>> Hi Huisong,
>>
>> I haven't checked the patch in detail yet, but I can see it gives some
>> ABI compatibility warnings, is this expected:
> This is to be expected. Because we insert a device state,
> RTE_ETH_DEV_ALLOCATED,
> before RTE_ETH_DEV_ATTACHED for resolving the issue patch 2/5 mentioned.
> We may have to announce it. What do you think?
If there is an actual ABI break, it can't go in this release, need to
wait LTS release and yes needs deprecation notice in advance.
But not all enum value change warnings are real break, need to
investigate all warnings one by one.
Need to investigate if old application & new dpdk library may cause any
unexpected behavior for application.
>>
>> 1 function with some indirect sub-type change:
>>
>> [C] 'function int dpaa_eth_eventq_attach(const rte_eth_dev*, int, u16,
>> const rte_event_eth_rx_adapter_queue_conf*)' at dpaa_ethdev.c:1149:1 has
>> some indirect sub-type changes:
>> parameter 1 of type 'const rte_eth_dev*' has sub-type changes:
>> in pointed to type 'const rte_eth_dev':
>> in unqualified underlying type 'struct rte_eth_dev' at
>> ethdev_driver.h:50:1:
>> type size hasn't changed
>> 1 data member change:
>> type of 'rte_eth_dev_state state' changed:
>> type size hasn't changed
>> 1 enumerator insertion:
>> 'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
>> 2 enumerator changes:
>> 'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
>> to '2' at rte_ethdev.h:2000:1
>> 'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2'
>> to '3' at rte_ethdev.h:2000:1
>>
>> 1 function with some indirect sub-type change:
>>
>> [C] 'function int rte_pmd_i40e_set_switch_dev(uint16_t, rte_eth_dev*)'
>> at rte_pmd_i40e.c:3266:1 has some indirect sub-type changes:
>> parameter 2 of type 'rte_eth_dev*' has sub-type changes:
>> in pointed to type 'struct rte_eth_dev' at ethdev_driver.h:50:1:
>> type size hasn't changed
>> 1 data member change:
>> type of 'rte_eth_dev_state state' changed:
>> type size hasn't changed
>> 1 enumerator insertion:
>> 'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
>> 2 enumerator changes:
>> 'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
>> to '2' at rte_ethdev.h:2000:1
>> 'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2' to
>> '3' at rte_ethdev.h:2000:1
>>
>> 1 function with some indirect sub-type change:
>>
>> [C] 'function rte_eth_dev* rte_eth_dev_allocate(const char*)' at
>> ethdev_driver.c:72:1 has some indirect sub-type changes:
>> return type changed:
>> in pointed to type 'struct rte_eth_dev' at ethdev_driver.h:50:1:
>> type size hasn't changed
>> 1 data member change:
>> type of 'rte_eth_dev_state state' changed:
>> type size hasn't changed
>> 1 enumerator insertion:
>> 'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
>> 2 enumerator changes:
>> 'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
>> to '2' at rte_ethdev.h:2000:1
>> 'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2' to
>> '3' at rte_ethdev.h:2000:1
>>
>> ... there are more warnings for same issue ...
>>
>> .
^ permalink raw reply [relevance 3%]
* Re: [PATCH V4 0/5] app/testpmd: support mulitple process attach and detach port
2023-01-11 10:27 3% ` Ferruh Yigit
@ 2023-01-11 10:46 0% ` Ferruh Yigit
2023-01-12 2:26 0% ` lihuisong (C)
2023-01-18 14:12 0% ` Thomas Monjalon
0 siblings, 2 replies; 200+ results
From: Ferruh Yigit @ 2023-01-11 10:46 UTC (permalink / raw)
To: lihuisong (C), dev, andrew.rybchenko
Cc: thomas, liudongdong3, huangdaode, fengchengwen
On 1/11/2023 10:27 AM, Ferruh Yigit wrote:
> On 1/11/2023 12:53 AM, lihuisong (C) wrote:
>>
>> 在 2023/1/11 0:51, Ferruh Yigit 写道:
>>> On 12/6/2022 9:26 AM, Huisong Li wrote:
>>>> This patchset fix some bugs and support attaching and detaching port
>>>> in primary and secondary.
>>>>
>>>> ---
>>>> -v4: fix a misspelling.
>>>> -v3:
>>>> 1) merge patch 1/6 and patch 2/6 into patch 1/5, and add
>>>> modification
>>>> for other bus type.
>>>> 2) add a RTE_ETH_DEV_ALLOCATED state in rte_eth_dev_state to resolve
>>>> the probelm in patch 2/5.
>>>> -v2: resend due to CI unexplained failure.
>>>>
>>>> Huisong Li (5):
>>>> drivers/bus: restore driver assignment at front of probing
>>>> ethdev: fix skip valid port in probing callback
>>>> app/testpmd: check the validity of the port
>>>> app/testpmd: add attach and detach port for multiple process
>>>> app/testpmd: stop forwarding in new or destroy event
>>>>
>>> Hi Huisong,
>>>
>>> I haven't checked the patch in detail yet, but I can see it gives some
>>> ABI compatibility warnings, is this expected:
>> This is to be expected. Because we insert a device state,
>> RTE_ETH_DEV_ALLOCATED,
>> before RTE_ETH_DEV_ATTACHED for resolving the issue patch 2/5 mentioned.
>> We may have to announce it. What do you think?
>
> If there is an actual ABI break, it can't go in this release, need to
> wait LTS release and yes needs deprecation notice in advance.
>
> But not all enum value change warnings are real break, need to
> investigate all warnings one by one.
> Need to investigate if old application & new dpdk library may cause any
> unexpected behavior for application.
>
OR, appending new enum item, `RTE_ETH_DEV_ALLOCATED`, to the end of the
enum solves the issue, although logically it won't look nice.
Perhaps order can be fixed in next LTS, to have more logical order, but
not quite sure if order worth the disturbance may cause in application.
>>>
>>> 1 function with some indirect sub-type change:
>>>
>>> [C] 'function int dpaa_eth_eventq_attach(const rte_eth_dev*, int, u16,
>>> const rte_event_eth_rx_adapter_queue_conf*)' at dpaa_ethdev.c:1149:1 has
>>> some indirect sub-type changes:
>>> parameter 1 of type 'const rte_eth_dev*' has sub-type changes:
>>> in pointed to type 'const rte_eth_dev':
>>> in unqualified underlying type 'struct rte_eth_dev' at
>>> ethdev_driver.h:50:1:
>>> type size hasn't changed
>>> 1 data member change:
>>> type of 'rte_eth_dev_state state' changed:
>>> type size hasn't changed
>>> 1 enumerator insertion:
>>> 'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
>>> 2 enumerator changes:
>>> 'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
>>> to '2' at rte_ethdev.h:2000:1
>>> 'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2'
>>> to '3' at rte_ethdev.h:2000:1
>>>
>>> 1 function with some indirect sub-type change:
>>>
>>> [C] 'function int rte_pmd_i40e_set_switch_dev(uint16_t, rte_eth_dev*)'
>>> at rte_pmd_i40e.c:3266:1 has some indirect sub-type changes:
>>> parameter 2 of type 'rte_eth_dev*' has sub-type changes:
>>> in pointed to type 'struct rte_eth_dev' at ethdev_driver.h:50:1:
>>> type size hasn't changed
>>> 1 data member change:
>>> type of 'rte_eth_dev_state state' changed:
>>> type size hasn't changed
>>> 1 enumerator insertion:
>>> 'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
>>> 2 enumerator changes:
>>> 'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
>>> to '2' at rte_ethdev.h:2000:1
>>> 'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2' to
>>> '3' at rte_ethdev.h:2000:1
>>>
>>> 1 function with some indirect sub-type change:
>>>
>>> [C] 'function rte_eth_dev* rte_eth_dev_allocate(const char*)' at
>>> ethdev_driver.c:72:1 has some indirect sub-type changes:
>>> return type changed:
>>> in pointed to type 'struct rte_eth_dev' at ethdev_driver.h:50:1:
>>> type size hasn't changed
>>> 1 data member change:
>>> type of 'rte_eth_dev_state state' changed:
>>> type size hasn't changed
>>> 1 enumerator insertion:
>>> 'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
>>> 2 enumerator changes:
>>> 'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
>>> to '2' at rte_ethdev.h:2000:1
>>> 'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2' to
>>> '3' at rte_ethdev.h:2000:1
>>>
>>> ... there are more warnings for same issue ...
>>>
>>> .
>
^ permalink raw reply [relevance 0%]
* [PATCH v3] devtools: parallelize ABI check
2023-01-07 13:39 33% [PATCH] devtools: parallelize ABI check Thomas Monjalon
2023-01-09 9:34 23% ` [PATCH v2] " Thomas Monjalon
@ 2023-01-11 13:16 33% ` Thomas Monjalon
2023-01-11 14:10 4% ` Bruce Richardson
2023-01-11 14:11 4% ` David Marchand
2023-01-11 19:53 33% ` [PATCH v4] " Thomas Monjalon
2 siblings, 2 replies; 200+ results
From: Thomas Monjalon @ 2023-01-11 13:16 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Ferruh Yigit
Generation and comparison of ABI dumps are done on multiple cores
thanks to xargs -P0.
It can accelerate this long step by 5 in my tests.
xargs reports a global error if one of the process has an error.
Running a shell function with xargs requires to export it with -f,
and that is a specific capability of bash.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
---
v2:
- find dump2 inside the function
- force bash because of export -f
v3:
- revert to POSIX sh
- use POSIX eval instead of export -f (issues on Ubuntu)
---
devtools/check-abi.sh | 21 +++++++++++++--------
devtools/gen-abi.sh | 5 +++--
2 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
index c583eae2fd..d58c867c60 100755
--- a/devtools/check-abi.sh
+++ b/devtools/check-abi.sh
@@ -34,19 +34,18 @@ else
ABIDIFF_OPTIONS="$ABIDIFF_OPTIONS --headers-dir2 $incdir2"
fi
-error=
-for dump in $(find $refdir -name "*.dump"); do
+export diff_func='run_diff() {
+ dump=$1
+ newdir=$2
name=$(basename $dump)
dump2=$(find $newdir -name $name)
if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
echo "Error: cannot find $name in $newdir" >&2
- error=1
- continue
- fi
+ return 1
+ fi;
abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
abiret=$?
- echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'" >&2
- error=1
+ echo "Error: ABI issue reported for abidiff $ABIDIFF_OPTIONS $dump $dump2" >&2
echo
if [ $(($abiret & 3)) -ne 0 ]; then
echo "ABIDIFF_ERROR|ABIDIFF_USAGE_ERROR, this could be a script or environment issue." >&2
@@ -58,7 +57,13 @@ for dump in $(find $refdir -name "*.dump"); do
echo "ABIDIFF_ABI_INCOMPATIBLE_CHANGE, this change breaks the ABI." >&2
fi
echo
+ return 1
}
-done
+}'
+
+error=
+find $refdir -name "*.dump" |
+xargs -n1 -P0 sh -c 'eval "$diff_func"; run_diff $0 '$newdir ||
+error=1
[ -z "$error" ] || [ -n "$warnonly" ]
diff --git a/devtools/gen-abi.sh b/devtools/gen-abi.sh
index f15a3b9aaf..61f7510ea1 100755
--- a/devtools/gen-abi.sh
+++ b/devtools/gen-abi.sh
@@ -22,5 +22,6 @@ for f in $(find $installdir -name "*.so.*"); do
fi
libname=$(basename $f)
- abidw --out-file $dumpdir/${libname%.so*}.dump $f
-done
+ echo $dumpdir/${libname%.so*}.dump $f
+done |
+xargs -n2 -P0 abidw --out-file
--
2.39.0
^ permalink raw reply [relevance 33%]
* Re: [PATCH v3] devtools: parallelize ABI check
2023-01-11 13:16 33% ` [PATCH v3] " Thomas Monjalon
@ 2023-01-11 14:10 4% ` Bruce Richardson
2023-01-11 14:11 4% ` David Marchand
1 sibling, 0 replies; 200+ results
From: Bruce Richardson @ 2023-01-11 14:10 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: David Marchand, dev, Ferruh Yigit
On Wed, Jan 11, 2023 at 02:16:52PM +0100, Thomas Monjalon wrote:
> Generation and comparison of ABI dumps are done on multiple cores
> thanks to xargs -P0.
> It can accelerate this long step by 5 in my tests.
>
> xargs reports a global error if one of the process has an error.
>
> Running a shell function with xargs requires to export it with -f,
> and that is a specific capability of bash.
>
Commit-log needs update based on changes in v3.
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
> ---
> v2:
> - find dump2 inside the function
> - force bash because of export -f
> v3:
> - revert to POSIX sh
> - use POSIX eval instead of export -f (issues on Ubuntu)
> ---
> devtools/check-abi.sh | 21 +++++++++++++--------
> devtools/gen-abi.sh | 5 +++--
> 2 files changed, 16 insertions(+), 10 deletions(-)
^ permalink raw reply [relevance 4%]
* Re: [PATCH v3] devtools: parallelize ABI check
2023-01-11 13:16 33% ` [PATCH v3] " Thomas Monjalon
2023-01-11 14:10 4% ` Bruce Richardson
@ 2023-01-11 14:11 4% ` David Marchand
2023-01-11 17:04 4% ` Thomas Monjalon
1 sibling, 1 reply; 200+ results
From: David Marchand @ 2023-01-11 14:11 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Ferruh Yigit
On Wed, Jan 11, 2023 at 2:16 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> Generation and comparison of ABI dumps are done on multiple cores
> thanks to xargs -P0.
> It can accelerate this long step by 5 in my tests.
>
> xargs reports a global error if one of the process has an error.
>
> Running a shell function with xargs requires to export it with -f,
> and that is a specific capability of bash.
>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
> ---
> v2:
> - find dump2 inside the function
> - force bash because of export -f
> v3:
> - revert to POSIX sh
> - use POSIX eval instead of export -f (issues on Ubuntu)
> ---
> devtools/check-abi.sh | 21 +++++++++++++--------
> devtools/gen-abi.sh | 5 +++--
> 2 files changed, 16 insertions(+), 10 deletions(-)
>
> diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
> index c583eae2fd..d58c867c60 100755
> --- a/devtools/check-abi.sh
> +++ b/devtools/check-abi.sh
> @@ -34,19 +34,18 @@ else
> ABIDIFF_OPTIONS="$ABIDIFF_OPTIONS --headers-dir2 $incdir2"
> fi
>
> -error=
> -for dump in $(find $refdir -name "*.dump"); do
> +export diff_func='run_diff() {
> + dump=$1
> + newdir=$2
> name=$(basename $dump)
> dump2=$(find $newdir -name $name)
> if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
> echo "Error: cannot find $name in $newdir" >&2
> - error=1
> - continue
> - fi
> + return 1
> + fi;
> abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
> abiret=$?
> - echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'" >&2
> - error=1
> + echo "Error: ABI issue reported for abidiff $ABIDIFF_OPTIONS $dump $dump2" >&2
> echo
> if [ $(($abiret & 3)) -ne 0 ]; then
> echo "ABIDIFF_ERROR|ABIDIFF_USAGE_ERROR, this could be a script or environment issue." >&2
> @@ -58,7 +57,13 @@ for dump in $(find $refdir -name "*.dump"); do
> echo "ABIDIFF_ABI_INCOMPATIBLE_CHANGE, this change breaks the ABI." >&2
> fi
> echo
> + return 1
> }
> -done
> +}'
> +
> +error=
> +find $refdir -name "*.dump" |
> +xargs -n1 -P0 sh -c 'eval "$diff_func"; run_diff $0 '$newdir ||
> +error=1
Do we need to pass $newdir ?
Like, for example, ABIDIFF_OPTIONS seems inherited, right?
Otherwise this trick looks to work.
--
David Marchand
^ permalink raw reply [relevance 4%]
* RE: [RFC 2/5] ethdev: introduce the affinity field in Tx queue API
2022-12-21 10:29 2% ` [RFC 2/5] ethdev: introduce the affinity field " Jiawei Wang
@ 2023-01-11 16:47 0% ` Ori Kam
2023-01-18 11:37 0% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Ori Kam @ 2023-01-11 16:47 UTC (permalink / raw)
To: Jiawei(Jonny) Wang, Slava Ovsiienko,
NBU-Contact-Thomas Monjalon (EXTERNAL),
Aman Singh, Yuying Zhang, Ferruh Yigit, Andrew Rybchenko
Cc: dev, Raslan Darawsheh
Hi Jiawei,
> -----Original Message-----
> From: Jiawei(Jonny) Wang <jiaweiw@nvidia.com>
> Sent: Wednesday, 21 December 2022 12:30
>
> For the multiple hardware ports connect to a single DPDK port (mhpsdp),
> the previous patch introduces the new rte flow item to match the port
> affinity of the received packets.
>
> This patch adds the tx_affinity setting in Tx queue API, the affinity value
> reflects packets be sent to which hardware port.
>
> Adds the new tx_affinity field into the padding hole of rte_eth_txconf
> structure, the size of rte_eth_txconf keeps the same. Adds a suppress
> type for structure change in the ABI check file.
>
> This patch adds the testpmd command line:
> testpmd> port config (port_id) txq (queue_id) affinity (value)
>
> For example, there're two hardware ports connects to a single DPDK
> port (port id 0), and affinity 1 stood for hard port 1 and affinity
> 2 stood for hardware port 2, used the below command to config
> tx affinity for each TxQ:
> port config 0 txq 0 affinity 1
> port config 0 txq 1 affinity 1
> port config 0 txq 2 affinity 2
> port config 0 txq 3 affinity 2
>
> These commands config the TxQ index 0 and TxQ
index 1 with affinity 1,
> uses TxQ 0 or TxQ 1 send packets, these packets will be sent from the
> hardware port 1, and similar with hardware port 2 if sending packets
> with TxQ 2 or TxQ 3.
>
> Signed-off-by: Jiawei Wang <jiaweiw@nvidia.com>
> ---
Acked-by: Ori Kam <orika@nvidia.com>
Best,
Ori
^ permalink raw reply [relevance 0%]
* Re: [PATCH v3] devtools: parallelize ABI check
2023-01-11 14:11 4% ` David Marchand
@ 2023-01-11 17:04 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2023-01-11 17:04 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Ferruh Yigit
11/01/2023 15:11, David Marchand:
> On Wed, Jan 11, 2023 at 2:16 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> > +find $refdir -name "*.dump" |
> > +xargs -n1 -P0 sh -c 'eval "$diff_func"; run_diff $0 '$newdir ||
> > +error=1
>
> Do we need to pass $newdir ?
> Like, for example, ABIDIFF_OPTIONS seems inherited, right?
Actually ABIDIFF_OPTIONS was empty when calling the function.
I'll pass it as well.
^ permalink raw reply [relevance 4%]
* [PATCH v4] devtools: parallelize ABI check
2023-01-07 13:39 33% [PATCH] devtools: parallelize ABI check Thomas Monjalon
2023-01-09 9:34 23% ` [PATCH v2] " Thomas Monjalon
2023-01-11 13:16 33% ` [PATCH v3] " Thomas Monjalon
@ 2023-01-11 19:53 33% ` Thomas Monjalon
2023-01-12 10:53 4% ` David Marchand
2023-01-18 14:29 4% ` David Marchand
2 siblings, 2 replies; 200+ results
From: Thomas Monjalon @ 2023-01-11 19:53 UTC (permalink / raw)
To: David Marchand; +Cc: dev, bruce.richardson, Ferruh Yigit
Generation and comparison of ABI dumps are done on multiple cores
thanks to xargs -P0.
It can accelerate this long step by 5 in my tests.
xargs reports a global error if one of the process has an error.
Running a shell function with xargs requires to export it.
POSIX shell does not support function export except using an "eval trick".
Required variables are also exported.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
---
v2:
- find dump2 inside the function
- force bash because of export -f
v3:
- revert to POSIX sh
- use POSIX eval instead of export -f (issues on Ubuntu)
v4:
- export all required variables
- remove useless stdout echo calls
---
devtools/check-abi.sh | 23 +++++++++++++----------
devtools/gen-abi.sh | 5 +++--
2 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
index c583eae2fd..31eceb42e6 100755
--- a/devtools/check-abi.sh
+++ b/devtools/check-abi.sh
@@ -34,20 +34,18 @@ else
ABIDIFF_OPTIONS="$ABIDIFF_OPTIONS --headers-dir2 $incdir2"
fi
-error=
-for dump in $(find $refdir -name "*.dump"); do
+export newdir ABIDIFF_OPTIONS
+export diff_func='run_diff() {
+ dump=$1
name=$(basename $dump)
dump2=$(find $newdir -name $name)
if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
echo "Error: cannot find $name in $newdir" >&2
- error=1
- continue
- fi
+ return 1
+ fi;
abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
abiret=$?
- echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'" >&2
- error=1
- echo
+ echo "Error: ABI issue reported for abidiff $ABIDIFF_OPTIONS $dump $dump2" >&2
if [ $(($abiret & 3)) -ne 0 ]; then
echo "ABIDIFF_ERROR|ABIDIFF_USAGE_ERROR, this could be a script or environment issue." >&2
fi
@@ -57,8 +55,13 @@ for dump in $(find $refdir -name "*.dump"); do
if [ $(($abiret & 8)) -ne 0 ]; then
echo "ABIDIFF_ABI_INCOMPATIBLE_CHANGE, this change breaks the ABI." >&2
fi
- echo
+ return 1
}
-done
+}'
+
+error=
+find $refdir -name "*.dump" |
+xargs -n1 -P0 sh -c 'eval "$diff_func"; run_diff $0' ||
+error=1
[ -z "$error" ] || [ -n "$warnonly" ]
diff --git a/devtools/gen-abi.sh b/devtools/gen-abi.sh
index f15a3b9aaf..61f7510ea1 100755
--- a/devtools/gen-abi.sh
+++ b/devtools/gen-abi.sh
@@ -22,5 +22,6 @@ for f in $(find $installdir -name "*.so.*"); do
fi
libname=$(basename $f)
- abidw --out-file $dumpdir/${libname%.so*}.dump $f
-done
+ echo $dumpdir/${libname%.so*}.dump $f
+done |
+xargs -n2 -P0 abidw --out-file
--
2.39.0
^ permalink raw reply [relevance 33%]
* Re: [PATCH V4 0/5] app/testpmd: support mulitple process attach and detach port
2023-01-11 10:46 0% ` Ferruh Yigit
@ 2023-01-12 2:26 0% ` lihuisong (C)
2023-01-18 14:12 0% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: lihuisong (C) @ 2023-01-12 2:26 UTC (permalink / raw)
To: Ferruh Yigit, dev, andrew.rybchenko
Cc: thomas, liudongdong3, huangdaode, fengchengwen
在 2023/1/11 18:46, Ferruh Yigit 写道:
> On 1/11/2023 10:27 AM, Ferruh Yigit wrote:
>> On 1/11/2023 12:53 AM, lihuisong (C) wrote:
>>> 在 2023/1/11 0:51, Ferruh Yigit 写道:
>>>> On 12/6/2022 9:26 AM, Huisong Li wrote:
>>>>> This patchset fix some bugs and support attaching and detaching port
>>>>> in primary and secondary.
>>>>>
>>>>> ---
>>>>> -v4: fix a misspelling.
>>>>> -v3:
>>>>> 1) merge patch 1/6 and patch 2/6 into patch 1/5, and add
>>>>> modification
>>>>> for other bus type.
>>>>> 2) add a RTE_ETH_DEV_ALLOCATED state in rte_eth_dev_state to resolve
>>>>> the probelm in patch 2/5.
>>>>> -v2: resend due to CI unexplained failure.
>>>>>
>>>>> Huisong Li (5):
>>>>> drivers/bus: restore driver assignment at front of probing
>>>>> ethdev: fix skip valid port in probing callback
>>>>> app/testpmd: check the validity of the port
>>>>> app/testpmd: add attach and detach port for multiple process
>>>>> app/testpmd: stop forwarding in new or destroy event
>>>>>
>>>> Hi Huisong,
>>>>
>>>> I haven't checked the patch in detail yet, but I can see it gives some
>>>> ABI compatibility warnings, is this expected:
>>> This is to be expected. Because we insert a device state,
>>> RTE_ETH_DEV_ALLOCATED,
>>> before RTE_ETH_DEV_ATTACHED for resolving the issue patch 2/5 mentioned.
>>> We may have to announce it. What do you think?
>> If there is an actual ABI break, it can't go in this release, need to
>> wait LTS release and yes needs deprecation notice in advance.
>>
>> But not all enum value change warnings are real break, need to
>> investigate all warnings one by one.
>> Need to investigate if old application & new dpdk library may cause any
>> unexpected behavior for application.
>>
> OR, appending new enum item, `RTE_ETH_DEV_ALLOCATED`, to the end of the
> enum solves the issue, although logically it won't look nice.
Thank you for your suggestion, Ferruh. It seems to be ok. I will fix it.
> Perhaps order can be fixed in next LTS, to have more logical order, but
> not quite sure if order worth the disturbance may cause in application.
Probably not worth it.
>>>> 1 function with some indirect sub-type change:
>>>>
>>>> [C] 'function int dpaa_eth_eventq_attach(const rte_eth_dev*, int, u16,
>>>> const rte_event_eth_rx_adapter_queue_conf*)' at dpaa_ethdev.c:1149:1 has
>>>> some indirect sub-type changes:
>>>> parameter 1 of type 'const rte_eth_dev*' has sub-type changes:
>>>> in pointed to type 'const rte_eth_dev':
>>>> in unqualified underlying type 'struct rte_eth_dev' at
>>>> ethdev_driver.h:50:1:
>>>> type size hasn't changed
>>>> 1 data member change:
>>>> type of 'rte_eth_dev_state state' changed:
>>>> type size hasn't changed
>>>> 1 enumerator insertion:
>>>> 'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
>>>> 2 enumerator changes:
>>>> 'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
>>>> to '2' at rte_ethdev.h:2000:1
>>>> 'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2'
>>>> to '3' at rte_ethdev.h:2000:1
>>>>
>>>> 1 function with some indirect sub-type change:
>>>>
>>>> [C] 'function int rte_pmd_i40e_set_switch_dev(uint16_t, rte_eth_dev*)'
>>>> at rte_pmd_i40e.c:3266:1 has some indirect sub-type changes:
>>>> parameter 2 of type 'rte_eth_dev*' has sub-type changes:
>>>> in pointed to type 'struct rte_eth_dev' at ethdev_driver.h:50:1:
>>>> type size hasn't changed
>>>> 1 data member change:
>>>> type of 'rte_eth_dev_state state' changed:
>>>> type size hasn't changed
>>>> 1 enumerator insertion:
>>>> 'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
>>>> 2 enumerator changes:
>>>> 'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
>>>> to '2' at rte_ethdev.h:2000:1
>>>> 'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2' to
>>>> '3' at rte_ethdev.h:2000:1
>>>>
>>>> 1 function with some indirect sub-type change:
>>>>
>>>> [C] 'function rte_eth_dev* rte_eth_dev_allocate(const char*)' at
>>>> ethdev_driver.c:72:1 has some indirect sub-type changes:
>>>> return type changed:
>>>> in pointed to type 'struct rte_eth_dev' at ethdev_driver.h:50:1:
>>>> type size hasn't changed
>>>> 1 data member change:
>>>> type of 'rte_eth_dev_state state' changed:
>>>> type size hasn't changed
>>>> 1 enumerator insertion:
>>>> 'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
>>>> 2 enumerator changes:
>>>> 'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
>>>> to '2' at rte_ethdev.h:2000:1
>>>> 'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2' to
>>>> '3' at rte_ethdev.h:2000:1
>>>>
>>>> ... there are more warnings for same issue ...
>>>>
>>>> .
> .
^ permalink raw reply [relevance 0%]
* Re: [PATCH v4] devtools: parallelize ABI check
2023-01-11 19:53 33% ` [PATCH v4] " Thomas Monjalon
@ 2023-01-12 10:53 4% ` David Marchand
2023-01-12 14:14 4% ` Ferruh Yigit
2023-01-18 14:29 4% ` David Marchand
1 sibling, 1 reply; 200+ results
From: David Marchand @ 2023-01-12 10:53 UTC (permalink / raw)
To: Thomas Monjalon, Ferruh Yigit; +Cc: dev, bruce.richardson
On Wed, Jan 11, 2023 at 8:53 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> Generation and comparison of ABI dumps are done on multiple cores
> thanks to xargs -P0.
> It can accelerate this long step by 5 in my tests.
>
> xargs reports a global error if one of the process has an error.
>
> Running a shell function with xargs requires to export it.
> POSIX shell does not support function export except using an "eval trick".
> Required variables are also exported.
>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
> diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
> index c583eae2fd..31eceb42e6 100755
> --- a/devtools/check-abi.sh
> +++ b/devtools/check-abi.sh
> @@ -34,20 +34,18 @@ else
> ABIDIFF_OPTIONS="$ABIDIFF_OPTIONS --headers-dir2 $incdir2"
> fi
>
> -error=
> -for dump in $(find $refdir -name "*.dump"); do
> +export newdir ABIDIFF_OPTIONS
> +export diff_func='run_diff() {
> + dump=$1
> name=$(basename $dump)
> dump2=$(find $newdir -name $name)
> if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
> echo "Error: cannot find $name in $newdir" >&2
> - error=1
> - continue
> - fi
> + return 1
> + fi;
No need for ; here.
This can be fixed when applying (I tested both your patch and with
this small fix).
> abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
> abiret=$?
> - echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'" >&2
> - error=1
> - echo
> + echo "Error: ABI issue reported for abidiff $ABIDIFF_OPTIONS $dump $dump2" >&2
> if [ $(($abiret & 3)) -ne 0 ]; then
> echo "ABIDIFF_ERROR|ABIDIFF_USAGE_ERROR, this could be a script or environment issue." >&2
> fi
> @@ -57,8 +55,13 @@ for dump in $(find $refdir -name "*.dump"); do
> if [ $(($abiret & 8)) -ne 0 ]; then
> echo "ABIDIFF_ABI_INCOMPATIBLE_CHANGE, this change breaks the ABI." >&2
> fi
> - echo
> + return 1
> }
> -done
> +}'
> +
> +error=
> +find $refdir -name "*.dump" |
> +xargs -n1 -P0 sh -c 'eval "$diff_func"; run_diff $0' ||
> +error=1
>
> [ -z "$error" ] || [ -n "$warnonly" ]
For the record, on my system, calling this script is ~5 times faster:
- before
real 0m5,447s
user 0m4,497s
sys 0m0,937s
- after
real 0m1,202s
user 0m10,784s
sys 0m2,027s
> diff --git a/devtools/gen-abi.sh b/devtools/gen-abi.sh
> index f15a3b9aaf..61f7510ea1 100755
> --- a/devtools/gen-abi.sh
> +++ b/devtools/gen-abi.sh
> @@ -22,5 +22,6 @@ for f in $(find $installdir -name "*.so.*"); do
> fi
>
> libname=$(basename $f)
> - abidw --out-file $dumpdir/${libname%.so*}.dump $f
> -done
> + echo $dumpdir/${libname%.so*}.dump $f
> +done |
> +xargs -n2 -P0 abidw --out-file
> --
> 2.39.0
>
- before
real 0m8,237s
user 0m7,704s
sys 0m0,504s
- after
real 0m2,517s
user 0m14,145s
sys 0m0,766s
Ferruh, I am seeing quite different numbers for running those scripts
(clearly not of the minute order).
I switched to testing/building in tmpfs some time ago.
It requires a good amount of memory (I empirically allocated 40G), but
maybe worth a try for you?
In any case, this patch lgtm.
Acked-by: David Marchand <david.marchand@redhat.com>
--
David Marchand
^ permalink raw reply [relevance 4%]
* [PATCH v2 0/9] Standardize telemetry int types
2022-12-13 18:27 4% [RFC PATCH 0/7] Standardize telemetry int types Bruce Richardson
` (2 preceding siblings ...)
@ 2023-01-12 10:58 4% ` Bruce Richardson
2023-01-12 10:59 3% ` [PATCH v2 8/9] telemetry: make internal int representation 64-bits Bruce Richardson
2023-01-12 10:59 3% ` [PATCH v2 9/9] telemetry: change public API to use 64-bit signed values Bruce Richardson
2023-01-12 17:41 4% ` [PATCH v3 0/9] Standardize telemetry int types Bruce Richardson
4 siblings, 2 replies; 200+ results
From: Bruce Richardson @ 2023-01-12 10:58 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson
Rather than having 64-bit unsigned types and 32-bit signed types
supported by the telemetry lib, we should support 64-bit values
for both types. On the naming side, since both are 64-bit, we
should no longer call the unsigned value u64 - "uint" is better.
This patchset implements these changes as far as is possible while
still keeping API and ABI compatibility.
* Internal structures and functions are updated to use 64-bit ints
* Internal functions are renamed from u64 to uint
* Public enum values are renamed from u64 to uint, and a macro is
added to ensure that older code still compiles
* The public add_*_int functions are changed to take a 64-bit value
rather than a 32-bit one. Since this would be an ABI break, we
use function versioning to ensure older code still calls into
a wrapper function which takes a 32-bit value.
The patchset also contains a couple of other small cleanups to the
telemetry code that were seen in passing when making these changes -
removing RTE_ prefix on internal enums, and simplifying the init of the
the array of data types.
NOTE: the renaming of the u64 functions to uint is split across 3
patches in this set - patches 4,5 and 6. This is to make it easier to
review and to avoid warnings about new functions not being marked
initially as experimental. Some/all of these 3 can be combined on merge
if so desired.
V2:
- added additional patches to replace the old function calls within DPDK
code, something missed in RFC version
- added new patch to make the renamed/new functions immediately public
allowing us to mark the original named versions as deprecated
- re-ordered patches within the sit, so the extra cleanup changes come
first
Bruce Richardson (9):
telemetry: remove RTE prefix from internal enum values
telemetry: make array initialization more robust
telemetry: rename unsigned 64-bit enum value to uint
telemetry: add uint type as alias for u64
global: rename telemetry functions to newer versions
telemetry: mark old names of renamed fns as deprecated
telemetry: update json functions to use int/uint in names
telemetry: make internal int representation 64-bits
telemetry: change public API to use 64-bit signed values
app/test/test_telemetry_data.c | 22 ++---
app/test/test_telemetry_json.c | 9 +-
doc/guides/rel_notes/deprecation.rst | 5 ++
drivers/common/cnxk/roc_platform.h | 2 +-
drivers/net/cnxk/cnxk_ethdev_sec_telemetry.c | 24 ++---
drivers/net/cnxk/cnxk_ethdev_telemetry.c | 6 +-
examples/ipsec-secgw/ipsec-secgw.c | 72 +++++++--------
examples/l3fwd-power/main.c | 4 +-
lib/cryptodev/rte_cryptodev.c | 6 +-
lib/dmadev/rte_dmadev.c | 2 +-
lib/eal/common/eal_common_memory.c | 19 ++--
lib/ethdev/rte_ethdev.c | 12 +--
lib/ethdev/sff_telemetry.c | 2 +-
lib/eventdev/rte_event_eth_rx_adapter.c | 22 ++---
lib/eventdev/rte_event_timer_adapter.c | 38 ++++----
lib/eventdev/rte_eventdev.c | 5 +-
lib/ipsec/ipsec_telemetry.c | 32 +++----
lib/rawdev/rte_rawdev.c | 4 +-
lib/security/rte_security.c | 8 +-
lib/telemetry/meson.build | 1 +
lib/telemetry/rte_telemetry.h | 51 +++++++++--
lib/telemetry/telemetry.c | 56 ++++++------
lib/telemetry/telemetry_data.c | 95 ++++++++++++++------
lib/telemetry/telemetry_data.h | 24 +++--
lib/telemetry/telemetry_json.h | 16 ++--
lib/telemetry/version.map | 9 ++
26 files changed, 323 insertions(+), 223 deletions(-)
--
2.37.2
^ permalink raw reply [relevance 4%]
* [PATCH v2 8/9] telemetry: make internal int representation 64-bits
2023-01-12 10:58 4% ` [PATCH v2 0/9] Standardize telemetry int types Bruce Richardson
@ 2023-01-12 10:59 3% ` Bruce Richardson
2023-01-12 10:59 3% ` [PATCH v2 9/9] telemetry: change public API to use 64-bit signed values Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Bruce Richardson @ 2023-01-12 10:59 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson, Morten Brørup, Tyler Retzlaff, Ciara Power
The internal storage for int values can be expanded from 32-bit to
64-bit without affecting the external ABI.
Suggested-by: Morten Brørup <mb@smartsharesystems.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
lib/telemetry/telemetry_data.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/telemetry/telemetry_data.h b/lib/telemetry/telemetry_data.h
index 8db6875a81..205509c5a2 100644
--- a/lib/telemetry/telemetry_data.h
+++ b/lib/telemetry/telemetry_data.h
@@ -28,7 +28,7 @@ struct container {
*/
union tel_value {
char sval[RTE_TEL_MAX_STRING_LEN];
- int ival;
+ int64_t ival;
uint64_t uval;
struct container container;
};
--
2.37.2
^ permalink raw reply [relevance 3%]
* [PATCH v2 9/9] telemetry: change public API to use 64-bit signed values
2023-01-12 10:58 4% ` [PATCH v2 0/9] Standardize telemetry int types Bruce Richardson
2023-01-12 10:59 3% ` [PATCH v2 8/9] telemetry: make internal int representation 64-bits Bruce Richardson
@ 2023-01-12 10:59 3% ` Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Bruce Richardson @ 2023-01-12 10:59 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson, Morten Brørup, Tyler Retzlaff, Ciara Power
While the unsigned values added to telemetry dicts/arrays were up to
64-bits in size, the sized values were only up to 32-bits. We can
standardize the API by having both int and uint functions take 64-bit
values. For ABI compatibility, we use function versioning to ensure
older binaries can still use the older functions taking a 32-bit
parameter.
Suggested-by: Morten Brørup <mb@smartsharesystems.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
lib/telemetry/meson.build | 1 +
lib/telemetry/rte_telemetry.h | 4 ++--
lib/telemetry/telemetry_data.c | 33 +++++++++++++++++++++++++++++----
lib/telemetry/telemetry_data.h | 6 ++++++
lib/telemetry/version.map | 7 +++++++
5 files changed, 45 insertions(+), 6 deletions(-)
diff --git a/lib/telemetry/meson.build b/lib/telemetry/meson.build
index f84c9aa3be..73750d9ef4 100644
--- a/lib/telemetry/meson.build
+++ b/lib/telemetry/meson.build
@@ -6,3 +6,4 @@ includes = [global_inc]
sources = files('telemetry.c', 'telemetry_data.c', 'telemetry_legacy.c')
headers = files('rte_telemetry.h')
includes += include_directories('../metrics')
+use_function_versioning = true
diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
index 4598303d5d..b481c112dd 100644
--- a/lib/telemetry/rte_telemetry.h
+++ b/lib/telemetry/rte_telemetry.h
@@ -120,7 +120,7 @@ rte_tel_data_add_array_string(struct rte_tel_data *d, const char *str);
* 0 on success, negative errno on error
*/
int
-rte_tel_data_add_array_int(struct rte_tel_data *d, int x);
+rte_tel_data_add_array_int(struct rte_tel_data *d, int64_t x);
/**
* Add an unsigned value to an array.
@@ -208,7 +208,7 @@ rte_tel_data_add_dict_string(struct rte_tel_data *d, const char *name,
* 0 on success, negative errno on error, E2BIG on string truncation of name.
*/
int
-rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val);
+rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int64_t val);
/**
* Add an unsigned value to a dictionary.
diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index 9a180937fd..ac7be795df 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -8,6 +8,7 @@
#undef RTE_USE_LIBBSD
#include <stdbool.h>
+#include <rte_function_versioning.h>
#include <rte_string_fns.h>
#include "telemetry_data.h"
@@ -58,8 +59,8 @@ rte_tel_data_add_array_string(struct rte_tel_data *d, const char *str)
return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
}
-int
-rte_tel_data_add_array_int(struct rte_tel_data *d, int x)
+int __vsym
+rte_tel_data_add_array_int_v24(struct rte_tel_data *d, int64_t x)
{
if (d->type != TEL_ARRAY_INT)
return -EINVAL;
@@ -69,6 +70,18 @@ rte_tel_data_add_array_int(struct rte_tel_data *d, int x)
return 0;
}
+int __vsym
+rte_tel_data_add_array_int_v23(struct rte_tel_data *d, int x)
+{
+ return rte_tel_data_add_array_int_v24(d, x);
+}
+
+/* mark the v23 function as the older version, and v24 as the default version */
+VERSION_SYMBOL(rte_tel_data_add_array_int, _v23, 23);
+BIND_DEFAULT_SYMBOL(rte_tel_data_add_array_int, _v24, 24);
+MAP_STATIC_SYMBOL(int rte_tel_data_add_array_int(struct rte_tel_data *d,
+ int64_t x), rte_tel_data_add_array_int_v24);
+
int
rte_tel_data_add_array_uint(struct rte_tel_data *d, uint64_t x)
{
@@ -146,8 +159,8 @@ rte_tel_data_add_dict_string(struct rte_tel_data *d, const char *name,
return 0;
}
-int
-rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val)
+int __vsym
+rte_tel_data_add_dict_int_v24(struct rte_tel_data *d, const char *name, int64_t val)
{
struct tel_dict_entry *e = &d->data.dict[d->data_len];
if (d->type != TEL_DICT)
@@ -165,6 +178,18 @@ rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val)
return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
}
+int __vsym
+rte_tel_data_add_dict_int_v23(struct rte_tel_data *d, const char *name, int val)
+{
+ return rte_tel_data_add_dict_int_v24(d, name, val);
+}
+
+/* mark the v23 function as the older version, and v24 as the default version */
+VERSION_SYMBOL(rte_tel_data_add_dict_int, _v23, 23);
+BIND_DEFAULT_SYMBOL(rte_tel_data_add_dict_int, _v24, 24);
+MAP_STATIC_SYMBOL(int rte_tel_data_add_dict_int(struct rte_tel_data *d,
+ const char *name, int64_t val), rte_tel_data_add_dict_int_v24);
+
int
rte_tel_data_add_dict_uint(struct rte_tel_data *d,
const char *name, uint64_t val)
diff --git a/lib/telemetry/telemetry_data.h b/lib/telemetry/telemetry_data.h
index 205509c5a2..53e4cabea5 100644
--- a/lib/telemetry/telemetry_data.h
+++ b/lib/telemetry/telemetry_data.h
@@ -49,4 +49,10 @@ struct rte_tel_data {
} data; /* data container */
};
+/* versioned functions */
+int rte_tel_data_add_array_int_v23(struct rte_tel_data *d, int val);
+int rte_tel_data_add_array_int_v24(struct rte_tel_data *d, int64_t val);
+int rte_tel_data_add_dict_int_v23(struct rte_tel_data *d, const char *name, int val);
+int rte_tel_data_add_dict_int_v24(struct rte_tel_data *d, const char *name, int64_t val);
+
#endif
diff --git a/lib/telemetry/version.map b/lib/telemetry/version.map
index d661180317..accfad5011 100644
--- a/lib/telemetry/version.map
+++ b/lib/telemetry/version.map
@@ -21,6 +21,13 @@ DPDK_23 {
local: *;
};
+DPDK_24 {
+ global:
+
+ rte_tel_data_add_array_int;
+ rte_tel_data_add_dict_int;
+} DPDK_23;
+
INTERNAL {
rte_telemetry_legacy_register;
rte_telemetry_init;
--
2.37.2
^ permalink raw reply [relevance 3%]
* Re: [PATCH v4] devtools: parallelize ABI check
2023-01-12 10:53 4% ` David Marchand
@ 2023-01-12 14:14 4% ` Ferruh Yigit
2023-01-18 10:45 4% ` David Marchand
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2023-01-12 14:14 UTC (permalink / raw)
To: David Marchand, Thomas Monjalon; +Cc: dev, bruce.richardson
On 1/12/2023 10:53 AM, David Marchand wrote:
> On Wed, Jan 11, 2023 at 8:53 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>>
>> Generation and comparison of ABI dumps are done on multiple cores
>> thanks to xargs -P0.
>> It can accelerate this long step by 5 in my tests.
>>
>> xargs reports a global error if one of the process has an error.
>>
>> Running a shell function with xargs requires to export it.
>> POSIX shell does not support function export except using an "eval trick".
>> Required variables are also exported.
>>
>> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
>> Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
>> diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
>> index c583eae2fd..31eceb42e6 100755
>> --- a/devtools/check-abi.sh
>> +++ b/devtools/check-abi.sh
>> @@ -34,20 +34,18 @@ else
>> ABIDIFF_OPTIONS="$ABIDIFF_OPTIONS --headers-dir2 $incdir2"
>> fi
>>
>> -error=
>> -for dump in $(find $refdir -name "*.dump"); do
>> +export newdir ABIDIFF_OPTIONS
>> +export diff_func='run_diff() {
>> + dump=$1
>> name=$(basename $dump)
>> dump2=$(find $newdir -name $name)
>> if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
>> echo "Error: cannot find $name in $newdir" >&2
>> - error=1
>> - continue
>> - fi
>> + return 1
>> + fi;
>
> No need for ; here.
> This can be fixed when applying (I tested both your patch and with
> this small fix).
>
>
>> abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
>> abiret=$?
>> - echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'" >&2
>> - error=1
>> - echo
>> + echo "Error: ABI issue reported for abidiff $ABIDIFF_OPTIONS $dump $dump2" >&2
>> if [ $(($abiret & 3)) -ne 0 ]; then
>> echo "ABIDIFF_ERROR|ABIDIFF_USAGE_ERROR, this could be a script or environment issue." >&2
>> fi
>> @@ -57,8 +55,13 @@ for dump in $(find $refdir -name "*.dump"); do
>> if [ $(($abiret & 8)) -ne 0 ]; then
>> echo "ABIDIFF_ABI_INCOMPATIBLE_CHANGE, this change breaks the ABI." >&2
>> fi
>> - echo
>> + return 1
>> }
>> -done
>> +}'
>> +
>> +error=
>> +find $refdir -name "*.dump" |
>> +xargs -n1 -P0 sh -c 'eval "$diff_func"; run_diff $0' ||
>> +error=1
>>
>> [ -z "$error" ] || [ -n "$warnonly" ]
>
> For the record, on my system, calling this script is ~5 times faster:
> - before
> real 0m5,447s
> user 0m4,497s
> sys 0m0,937s
>
> - after
> real 0m1,202s
> user 0m10,784s
> sys 0m2,027s
>
>
>> diff --git a/devtools/gen-abi.sh b/devtools/gen-abi.sh
>> index f15a3b9aaf..61f7510ea1 100755
>> --- a/devtools/gen-abi.sh
>> +++ b/devtools/gen-abi.sh
>> @@ -22,5 +22,6 @@ for f in $(find $installdir -name "*.so.*"); do
>> fi
>>
>> libname=$(basename $f)
>> - abidw --out-file $dumpdir/${libname%.so*}.dump $f
>> -done
>> + echo $dumpdir/${libname%.so*}.dump $f
>> +done |
>> +xargs -n2 -P0 abidw --out-file
>> --
>> 2.39.0
>>
>
> - before
> real 0m8,237s
> user 0m7,704s
> sys 0m0,504s
>
> - after
> real 0m2,517s
> user 0m14,145s
> sys 0m0,766s
>
>
> Ferruh, I am seeing quite different numbers for running those scripts
> (clearly not of the minute order).
> I switched to testing/building in tmpfs some time ago.
> It requires a good amount of memory (I empirically allocated 40G), but
> maybe worth a try for you?
>
I run 'test-meson-builds.sh' script directly and yes I am getting
different numbers although there is still improvement, not in scale with
what you are getting, with v4 I have following:
- before
real 10m3.248s
user 39m8.664s
sys 14m52.870s
- after
real 7m49.086s
user 39m59.507s
sys 15m0.598s
What I am running exactly is:
time DPDK_ABI_REF_VERSION=v22.11.1 DPDK_ABI_REF_DIR=/tmp/dpdk-abiref
DPDK_ABI_REF_SRC=.../dpdk-stable/ ./devtools/test-meson-builds.sh
>
> In any case, this patch lgtm.
> Acked-by: David Marchand <david.marchand@redhat.com>
>
>
^ permalink raw reply [relevance 4%]
* [PATCH v3 0/9] Standardize telemetry int types
2022-12-13 18:27 4% [RFC PATCH 0/7] Standardize telemetry int types Bruce Richardson
` (3 preceding siblings ...)
2023-01-12 10:58 4% ` [PATCH v2 0/9] Standardize telemetry int types Bruce Richardson
@ 2023-01-12 17:41 4% ` Bruce Richardson
2023-01-12 17:41 3% ` [PATCH v3 8/9] telemetry: make internal int representation 64-bits Bruce Richardson
` (2 more replies)
4 siblings, 3 replies; 200+ results
From: Bruce Richardson @ 2023-01-12 17:41 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson
Rather than having 64-bit unsigned types and 32-bit signed types
supported by the telemetry lib, we should support 64-bit values
for both types. On the naming side, since both are 64-bit, we
should no longer call the unsigned value u64 - "uint" is better.
This patchset implements these changes as far as is possible while
still keeping API and ABI compatibility.
* Internal structures and functions are updated to use 64-bit ints
* Internal functions are renamed from u64 to uint
* Public enum values are renamed from u64 to uint, and a macro is
added to ensure that older code still compiles
* The public add_*_int functions are changed to take a 64-bit value
rather than a 32-bit one. Since this would be an ABI break, we
use function versioning to ensure older code still calls into
a wrapper function which takes a 32-bit value.
The patchset also contains a couple of other small cleanups to the
telemetry code that were seen in passing when making these changes -
removing RTE_ prefix on internal enums, and simplifying the init of the
the array of data types.
NOTE: the renaming of the u64 functions to uint is split across 3
patches in this set - patches 4,5 and 6. This is to make it easier to
review and to avoid warnings about new functions not being marked
initially as experimental. Some/all of these 3 can be combined on merge
if so desired.
V3:
- fix build issues due to missing a driver code change
- fix spelling issue flagged by checkpatch
V2:
- added additional patches to replace the old function calls within DPDK
code, something missed in RFC version
- added new patch to make the renamed/new functions immediately public
allowing us to mark the original named versions as deprecated
- re-ordered patches within the sit, so the extra cleanup changes come
first
Bruce Richardson (9):
telemetry: remove RTE prefix from internal enum values
telemetry: make array initialization more robust
telemetry: rename unsigned 64-bit enum value to uint
telemetry: add uint type as alias for u64
global: rename telemetry functions to newer versions
telemetry: mark old names of renamed fns as deprecated
telemetry: update json functions to use int/uint in names
telemetry: make internal int representation 64-bits
telemetry: change public API to use 64-bit signed values
app/test/test_telemetry_data.c | 22 ++---
app/test/test_telemetry_json.c | 9 +-
doc/guides/rel_notes/deprecation.rst | 5 ++
drivers/common/cnxk/roc_platform.h | 4 +-
drivers/net/cnxk/cnxk_ethdev_sec_telemetry.c | 24 ++---
drivers/net/cnxk/cnxk_ethdev_telemetry.c | 6 +-
examples/ipsec-secgw/ipsec-secgw.c | 72 +++++++--------
examples/l3fwd-power/main.c | 4 +-
lib/cryptodev/rte_cryptodev.c | 6 +-
lib/dmadev/rte_dmadev.c | 2 +-
lib/eal/common/eal_common_memory.c | 19 ++--
lib/ethdev/rte_ethdev.c | 12 +--
lib/ethdev/sff_telemetry.c | 2 +-
lib/eventdev/rte_event_eth_rx_adapter.c | 22 ++---
lib/eventdev/rte_event_timer_adapter.c | 38 ++++----
lib/eventdev/rte_eventdev.c | 5 +-
lib/ipsec/ipsec_telemetry.c | 33 +++----
lib/rawdev/rte_rawdev.c | 4 +-
lib/security/rte_security.c | 8 +-
lib/telemetry/meson.build | 1 +
lib/telemetry/rte_telemetry.h | 51 +++++++++--
lib/telemetry/telemetry.c | 56 ++++++------
lib/telemetry/telemetry_data.c | 95 ++++++++++++++------
lib/telemetry/telemetry_data.h | 24 +++--
lib/telemetry/telemetry_json.h | 16 ++--
lib/telemetry/version.map | 9 ++
26 files changed, 325 insertions(+), 224 deletions(-)
--
2.37.2
^ permalink raw reply [relevance 4%]
* [PATCH v3 8/9] telemetry: make internal int representation 64-bits
2023-01-12 17:41 4% ` [PATCH v3 0/9] Standardize telemetry int types Bruce Richardson
@ 2023-01-12 17:41 3% ` Bruce Richardson
2023-01-12 17:41 3% ` [PATCH v3 9/9] telemetry: change public API to use 64-bit signed values Bruce Richardson
2023-01-13 16:39 0% ` [PATCH v3 0/9] Standardize telemetry int types Power, Ciara
2 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2023-01-12 17:41 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson, Morten Brørup, Tyler Retzlaff, Ciara Power
The internal storage for int values can be expanded from 32-bit to
64-bit without affecting the external ABI.
Suggested-by: Morten Brørup <mb@smartsharesystems.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
lib/telemetry/telemetry_data.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/telemetry/telemetry_data.h b/lib/telemetry/telemetry_data.h
index 8db6875a81..205509c5a2 100644
--- a/lib/telemetry/telemetry_data.h
+++ b/lib/telemetry/telemetry_data.h
@@ -28,7 +28,7 @@ struct container {
*/
union tel_value {
char sval[RTE_TEL_MAX_STRING_LEN];
- int ival;
+ int64_t ival;
uint64_t uval;
struct container container;
};
--
2.37.2
^ permalink raw reply [relevance 3%]
* [PATCH v3 9/9] telemetry: change public API to use 64-bit signed values
2023-01-12 17:41 4% ` [PATCH v3 0/9] Standardize telemetry int types Bruce Richardson
2023-01-12 17:41 3% ` [PATCH v3 8/9] telemetry: make internal int representation 64-bits Bruce Richardson
@ 2023-01-12 17:41 3% ` Bruce Richardson
2023-01-13 16:39 0% ` [PATCH v3 0/9] Standardize telemetry int types Power, Ciara
2 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2023-01-12 17:41 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson, Morten Brørup, Tyler Retzlaff, Ciara Power
While the unsigned values added to telemetry dicts/arrays were up to
64-bits in size, the sized values were only up to 32-bits. We can
standardize the API by having both int and uint functions take 64-bit
values. For ABI compatibility, we use function versioning to ensure
older binaries can still use the older functions taking a 32-bit
parameter.
Suggested-by: Morten Brørup <mb@smartsharesystems.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
lib/telemetry/meson.build | 1 +
lib/telemetry/rte_telemetry.h | 4 ++--
lib/telemetry/telemetry_data.c | 33 +++++++++++++++++++++++++++++----
lib/telemetry/telemetry_data.h | 6 ++++++
lib/telemetry/version.map | 7 +++++++
5 files changed, 45 insertions(+), 6 deletions(-)
diff --git a/lib/telemetry/meson.build b/lib/telemetry/meson.build
index f84c9aa3be..73750d9ef4 100644
--- a/lib/telemetry/meson.build
+++ b/lib/telemetry/meson.build
@@ -6,3 +6,4 @@ includes = [global_inc]
sources = files('telemetry.c', 'telemetry_data.c', 'telemetry_legacy.c')
headers = files('rte_telemetry.h')
includes += include_directories('../metrics')
+use_function_versioning = true
diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
index 4598303d5d..b481c112dd 100644
--- a/lib/telemetry/rte_telemetry.h
+++ b/lib/telemetry/rte_telemetry.h
@@ -120,7 +120,7 @@ rte_tel_data_add_array_string(struct rte_tel_data *d, const char *str);
* 0 on success, negative errno on error
*/
int
-rte_tel_data_add_array_int(struct rte_tel_data *d, int x);
+rte_tel_data_add_array_int(struct rte_tel_data *d, int64_t x);
/**
* Add an unsigned value to an array.
@@ -208,7 +208,7 @@ rte_tel_data_add_dict_string(struct rte_tel_data *d, const char *name,
* 0 on success, negative errno on error, E2BIG on string truncation of name.
*/
int
-rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val);
+rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int64_t val);
/**
* Add an unsigned value to a dictionary.
diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index 9a180937fd..ac7be795df 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -8,6 +8,7 @@
#undef RTE_USE_LIBBSD
#include <stdbool.h>
+#include <rte_function_versioning.h>
#include <rte_string_fns.h>
#include "telemetry_data.h"
@@ -58,8 +59,8 @@ rte_tel_data_add_array_string(struct rte_tel_data *d, const char *str)
return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
}
-int
-rte_tel_data_add_array_int(struct rte_tel_data *d, int x)
+int __vsym
+rte_tel_data_add_array_int_v24(struct rte_tel_data *d, int64_t x)
{
if (d->type != TEL_ARRAY_INT)
return -EINVAL;
@@ -69,6 +70,18 @@ rte_tel_data_add_array_int(struct rte_tel_data *d, int x)
return 0;
}
+int __vsym
+rte_tel_data_add_array_int_v23(struct rte_tel_data *d, int x)
+{
+ return rte_tel_data_add_array_int_v24(d, x);
+}
+
+/* mark the v23 function as the older version, and v24 as the default version */
+VERSION_SYMBOL(rte_tel_data_add_array_int, _v23, 23);
+BIND_DEFAULT_SYMBOL(rte_tel_data_add_array_int, _v24, 24);
+MAP_STATIC_SYMBOL(int rte_tel_data_add_array_int(struct rte_tel_data *d,
+ int64_t x), rte_tel_data_add_array_int_v24);
+
int
rte_tel_data_add_array_uint(struct rte_tel_data *d, uint64_t x)
{
@@ -146,8 +159,8 @@ rte_tel_data_add_dict_string(struct rte_tel_data *d, const char *name,
return 0;
}
-int
-rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val)
+int __vsym
+rte_tel_data_add_dict_int_v24(struct rte_tel_data *d, const char *name, int64_t val)
{
struct tel_dict_entry *e = &d->data.dict[d->data_len];
if (d->type != TEL_DICT)
@@ -165,6 +178,18 @@ rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val)
return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
}
+int __vsym
+rte_tel_data_add_dict_int_v23(struct rte_tel_data *d, const char *name, int val)
+{
+ return rte_tel_data_add_dict_int_v24(d, name, val);
+}
+
+/* mark the v23 function as the older version, and v24 as the default version */
+VERSION_SYMBOL(rte_tel_data_add_dict_int, _v23, 23);
+BIND_DEFAULT_SYMBOL(rte_tel_data_add_dict_int, _v24, 24);
+MAP_STATIC_SYMBOL(int rte_tel_data_add_dict_int(struct rte_tel_data *d,
+ const char *name, int64_t val), rte_tel_data_add_dict_int_v24);
+
int
rte_tel_data_add_dict_uint(struct rte_tel_data *d,
const char *name, uint64_t val)
diff --git a/lib/telemetry/telemetry_data.h b/lib/telemetry/telemetry_data.h
index 205509c5a2..53e4cabea5 100644
--- a/lib/telemetry/telemetry_data.h
+++ b/lib/telemetry/telemetry_data.h
@@ -49,4 +49,10 @@ struct rte_tel_data {
} data; /* data container */
};
+/* versioned functions */
+int rte_tel_data_add_array_int_v23(struct rte_tel_data *d, int val);
+int rte_tel_data_add_array_int_v24(struct rte_tel_data *d, int64_t val);
+int rte_tel_data_add_dict_int_v23(struct rte_tel_data *d, const char *name, int val);
+int rte_tel_data_add_dict_int_v24(struct rte_tel_data *d, const char *name, int64_t val);
+
#endif
diff --git a/lib/telemetry/version.map b/lib/telemetry/version.map
index d661180317..accfad5011 100644
--- a/lib/telemetry/version.map
+++ b/lib/telemetry/version.map
@@ -21,6 +21,13 @@ DPDK_23 {
local: *;
};
+DPDK_24 {
+ global:
+
+ rte_tel_data_add_array_int;
+ rte_tel_data_add_dict_int;
+} DPDK_23;
+
INTERNAL {
rte_telemetry_legacy_register;
rte_telemetry_init;
--
2.37.2
^ permalink raw reply [relevance 3%]
* Re: trace point symbols
@ 2023-01-13 11:22 3% ` Jerin Jacob
0 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2023-01-13 11:22 UTC (permalink / raw)
To: Morten Brørup
Cc: Thomas Monjalon, Ferruh Yigit, jerinj, bruce.richardson, dev,
Ankur Dwivedi, orika, ferruh.yigit, chas3, humin29, linville,
ciara.loftus, qi.z.zhang, mw, mk, shaibran, evgenys, igorch,
chandu, irusskikh, shepard.siegel, ed.czeck, john.miller,
ajit.khaparde, somnath.kotur, mczekaj, sthotton, srinivasan,
hkalra, rahul.lakkireddy, johndale, hyonkim, liudongdong3,
yisen.zhuang, xuanziyang2, cloud.wangxiaoyun, zhouguoyang,
simei.su, wenjun1.wu, qiming.yang, Yuying.Zhang, beilei.xing,
xiao.w.wang, jingjing.wu, junfeng.guo, rosen.xu, ndabilpuram,
kirankumark, skori, skoteshwar, lironh, zr, radhac, vburru,
sedara, matan, viacheslavo, sthemmin, longli, spinler,
chaoyong.he, niklas.soderlund, hemant.agrawal, sachin.saxena,
g.singh, apeksha.gupta, sachin.saxena, aboyer, rmody, shshaikh,
dsinghrawat, andrew.rybchenko, jiawenwu, jianwang, jbehrens,
maxime.coquelin, chenbo.xia, steven.webster, matt.peters,
mtetsuyah, grive, jasvinder.singh, cristian.dumitrescu, jgrajcia,
david.marchand
On Thu, Jan 12, 2023 at 3:13 PM Morten Brørup <mb@smartsharesystems.com> wrote:
>
> > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > Sent: Thursday, 12 January 2023 10.11
> >
> >
> > I would like to see a policy regarding trace symbols.
> > If we decide option 1 is not so useful,
> > then we should not export trace symbols at all and document this
> > policy.
> > Also there are some trace symbols which could be cleaned up.
I can send a patch to remove existing exposed symbols for option 1 in
DPDK repo. But, Is n't an ABI break? The only downside, I can think
of, is that a few more entries in version.map file.
I don't have a strong option one way, either. Let me know what you think?
If we decided to remove then, In
https://doc.dpdk.org/guides/prog_guide/trace_lib.html, There is NOTE
section as following, I can remove that as well.
--
The RTE_TRACE_POINT_REGISTER defines the placeholder for the
rte_trace_point_t tracepoint object. The user must export a
__<trace_function_name> symbol in the library .map file for this
tracepoint to be used out of the library, in shared builds. For
example, __app_trace_string will be the exported symbol in the above
example.
---
>
> +1 for not exposing trace point symbols at all.
>
> The trace point symbols are only used internally by DPDK, so they should not be part of DPDK's public API.
>
> It might also make it easier for Bruce to move the trace library out of EAL.
>
> I'm not familiar with the CTF format, but I assume that if we don't expose the trace point symbols, the trace points can still be identified when parsing the trace file.
Yes. It won't impact. The only use case for option 1 is to avoid named lookup.
>
^ permalink raw reply [relevance 3%]
* RE: [PATCH v3 0/9] Standardize telemetry int types
2023-01-12 17:41 4% ` [PATCH v3 0/9] Standardize telemetry int types Bruce Richardson
2023-01-12 17:41 3% ` [PATCH v3 8/9] telemetry: make internal int representation 64-bits Bruce Richardson
2023-01-12 17:41 3% ` [PATCH v3 9/9] telemetry: change public API to use 64-bit signed values Bruce Richardson
@ 2023-01-13 16:39 0% ` Power, Ciara
2 siblings, 0 replies; 200+ results
From: Power, Ciara @ 2023-01-13 16:39 UTC (permalink / raw)
To: Richardson, Bruce, dev; +Cc: Richardson, Bruce
Hi Bruce,
> -----Original Message-----
> From: Bruce Richardson <bruce.richardson@intel.com>
> Sent: Thursday 12 January 2023 17:41
> To: dev@dpdk.org
> Cc: Richardson, Bruce <bruce.richardson@intel.com>
> Subject: [PATCH v3 0/9] Standardize telemetry int types
>
> Rather than having 64-bit unsigned types and 32-bit signed types supported
> by the telemetry lib, we should support 64-bit values for both types. On the
> naming side, since both are 64-bit, we should no longer call the unsigned
> value u64 - "uint" is better.
>
> This patchset implements these changes as far as is possible while still
> keeping API and ABI compatibility.
>
> * Internal structures and functions are updated to use 64-bit ints
> * Internal functions are renamed from u64 to uint
> * Public enum values are renamed from u64 to uint, and a macro is
> added to ensure that older code still compiles
> * The public add_*_int functions are changed to take a 64-bit value
> rather than a 32-bit one. Since this would be an ABI break, we
> use function versioning to ensure older code still calls into
> a wrapper function which takes a 32-bit value.
>
> The patchset also contains a couple of other small cleanups to the telemetry
> code that were seen in passing when making these changes - removing RTE_
> prefix on internal enums, and simplifying the init of the the array of data
> types.
>
> NOTE: the renaming of the u64 functions to uint is split across 3 patches in
> this set - patches 4,5 and 6. This is to make it easier to review and to avoid
> warnings about new functions not being marked initially as experimental.
> Some/all of these 3 can be combined on merge if so desired.
>
> V3:
> - fix build issues due to missing a driver code change
> - fix spelling issue flagged by checkpatch
>
> V2:
> - added additional patches to replace the old function calls within DPDK
> code, something missed in RFC version
> - added new patch to make the renamed/new functions immediately public
> allowing us to mark the original named versions as deprecated
> - re-ordered patches within the sit, so the extra cleanup changes come
> first
>
> Bruce Richardson (9):
> telemetry: remove RTE prefix from internal enum values
> telemetry: make array initialization more robust
> telemetry: rename unsigned 64-bit enum value to uint
> telemetry: add uint type as alias for u64
> global: rename telemetry functions to newer versions
> telemetry: mark old names of renamed fns as deprecated
> telemetry: update json functions to use int/uint in names
> telemetry: make internal int representation 64-bits
> telemetry: change public API to use 64-bit signed values
>
> app/test/test_telemetry_data.c | 22 ++---
> app/test/test_telemetry_json.c | 9 +-
> doc/guides/rel_notes/deprecation.rst | 5 ++
> drivers/common/cnxk/roc_platform.h | 4 +-
> drivers/net/cnxk/cnxk_ethdev_sec_telemetry.c | 24 ++---
> drivers/net/cnxk/cnxk_ethdev_telemetry.c | 6 +-
> examples/ipsec-secgw/ipsec-secgw.c | 72 +++++++--------
> examples/l3fwd-power/main.c | 4 +-
> lib/cryptodev/rte_cryptodev.c | 6 +-
> lib/dmadev/rte_dmadev.c | 2 +-
> lib/eal/common/eal_common_memory.c | 19 ++--
> lib/ethdev/rte_ethdev.c | 12 +--
> lib/ethdev/sff_telemetry.c | 2 +-
> lib/eventdev/rte_event_eth_rx_adapter.c | 22 ++---
> lib/eventdev/rte_event_timer_adapter.c | 38 ++++----
> lib/eventdev/rte_eventdev.c | 5 +-
> lib/ipsec/ipsec_telemetry.c | 33 +++----
> lib/rawdev/rte_rawdev.c | 4 +-
> lib/security/rte_security.c | 8 +-
> lib/telemetry/meson.build | 1 +
> lib/telemetry/rte_telemetry.h | 51 +++++++++--
> lib/telemetry/telemetry.c | 56 ++++++------
> lib/telemetry/telemetry_data.c | 95 ++++++++++++++------
> lib/telemetry/telemetry_data.h | 24 +++--
> lib/telemetry/telemetry_json.h | 16 ++--
> lib/telemetry/version.map | 9 ++
> 26 files changed, 325 insertions(+), 224 deletions(-)
>
> --
> 2.37.2
Series-Acked-by: Ciara Power <ciara.power@intel.com>
^ permalink raw reply [relevance 0%]
* Re: [RFC] Remove Kernel Network Interface (KNI)
@ 2023-01-14 22:21 3% ` Tyler Retzlaff
0 siblings, 0 replies; 200+ results
From: Tyler Retzlaff @ 2023-01-14 22:21 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Thomas Monjalon, dev, Cristian Dumitrescu, Bruce Richardson,
Anatoly Burakov
On Fri, Jan 13, 2023 at 03:25:30PM -0800, Stephen Hemminger wrote:
> On Fri, 13 Jan 2023 19:34:24 +0100
> Thomas Monjalon <thomas@monjalon.net> wrote:
>
> > 13/01/2023 18:13, Stephen Hemminger:
> > > On Fri, 13 Jan 2023 09:12:16 +0100
> > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > >
> > > > 13/01/2023 06:03, Stephen Hemminger:
> > > > > The Linux special network driver for kernel networking has been
> > > > > a long term problem for DPDK. The performance benefits of KNI
> > > > > are available via virtio-user and XDP, and the simpler kernel
> > > > > interface via TAP is also available.
> > > > >
> > > > > This driver has required lots of effort to keep up with the
> > > > > kernel API changes. And the overall architecture of the driver
> > > > > is fundamentally insecure and has unfixable locking and data
> > > > > race problems. No developer has been willing to do extensive
> > > > > tests or be the maintainer.
> > > > >
> > > > > In short, the time has come to do some early spring cleaning
> > > > > and remove KNI from DPDK 23.03.
> > > >
> > > > In doc/guides/rel_notes/deprecation.rst it is announced
> > > > to be removed in 23.11. Let's keep this RFC for later :)
> > > >
> > > >
> > >
> > > For 23.03 could we add a deprecation log message when library is
> > > used and when kernel module is loaded.
> >
> > We already have a message in the lib:
> >
> > int
> > rte_kni_init(unsigned int max_kni_ifaces __rte_unused)
> > {
> > RTE_LOG(WARNING, KNI, "WARNING: KNI is deprecated and will be removed in DPDK 23.11\n");
> >
> > It is a good idea to add a message in the kernel module loading.
> >
> >
> >
> >
>
> No matter how much we tell users, guarantee someone will still miss it and complain :-)
one of the techniques we use is to remove the headers in advance of
removing the ABI. the warning becomes a lot more clear when you can't
compile anymore but your existing binaries continue to run.
^ permalink raw reply [relevance 3%]
* Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
2022-12-26 16:44 4% ` Ori Kam
@ 2023-01-15 22:46 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2023-01-15 22:46 UTC (permalink / raw)
To: Rongwei Liu, Jerin Jacob, Ori Kam
Cc: dev, Matan Azrad, Slava Ovsiienko, Ferruh Yigit,
Andrew Rybchenko, dev, Raslan Darawsheh, maxime.coquelin
26/12/2022 17:44, Ori Kam:
> From: Rongwei Liu <rongweil@nvidia.com>
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > On Wed, Dec 21, 2022 at 6:20 PM Rongwei Liu wrote:
> > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > On Wed, Dec 21, 2022 at 5:35 PM Rongwei Liu wrote:
> > > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > > > On Wed, Dec 21, 2022 at 3:02 PM Rongwei Liu wrote:
> > > > > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > > > > > On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu wrote:
> > > > > > > > > >
> > > > > > > > > > Users may want to change the DPDK process to different
> > > > > > > > > > versions
> > > > > > > > >
> > > > > > > > > Different version of DPDK? If there is any ABI change how to
> > > > > > > > > support
> > > > > this?
> > > > > > > > >
> > > > > > > > There is a new member which was introduced into
> > > > > > > > rte_eth_dev_info but it
> > > > > > > shouldn’t be ABI breaking since using reserved fields.
> > > > > > >
> > > > > > > That is just for rte_eth_dev_info. What about the ABI change in
> > > > > > > different ethdev structure and rte_flow structures across
> > > > > > > different DPDK
> > > > > ABI versions.
> > > > > > >
> > > > > > Besides this, there is no other ABI changes dependency.
> > > > > >
> > > > > > Assume there is a DPDK process A running with version v21.11 and
> > > > > > plan to upgrade to version v22.11. Let' call v22.11 as process B.
> > > > >
> > > > > OK. That's a relief. I understand the use case now.
> > > > >
> > > > > Why not simply use standard DPDK multiprocess model then.
> > > > > Primary process act as server for slow path API. Secondary process
> > > > > can come and go(aka can be updated at runtime) and use as client to
> > > > > update rules via primary-secondray communication mechanism.
> > > > >
> > > > Just image if process A and process B have ABI breakage like different
> > > rte_flow_item_*** and rte_flow_action_*** size and members.
> > > > How can we quickly accommodate primary/secondary to be ABI
> > compatible
> > > across different versions?
> > > > It will be very huge effort and difficult to implement, at least in my
> > opinion.
> > > > What do you think?
> > >
> > > Yes. it difficult what ever approach we take, On other hand, ethdev
> > subsystem
> > > has other components like rte_tm and other offload etc, We can not simply
> > > have rte_eth_process_set_active() and things magical works across
> > different
> > > DPDK versions. Example, if rte_flow rule has meter action will depend on
> > > another HW piece in NIC card for doing the metering but set by flow API.
> > > IMO, Customer can simply use standard multiprocess model if version are
> > > compatible without any special intelligence in application.
> > > Otherwise they can reload and start the application again or have special
> > > intelligence in application to cater the specific area of API they need to
> > > leverage based on server and client DPDK versions.
> >
> > Thanks for the message.
> > IMO, we are trying to eliminate the version/ABI dependency with this new
> > added API.
> > For example, if meter action is in the flow rules:
> > 1. Process A have rules like "eth / ipv4 src 1.1.1.1 / meter / queue / end"
> > 2. Process B starts with "rte_eth_process_set_active(false, flags)"
> >
> > Just give Nvidia' hardware as example (other NIC vendors may not care if
> > group 0 or not)
> > If the process A' rules are in group 0, users should set them one by one to
> > process B.
> > Then either flush process A' rules or quit process A, then process B calls with
> > "rte_eth_process_set_active(true, flags)"
> > All is set.
> > It will avoid complex operations with client/server model and avoid user mis-
> > operation too.
> > We should avoid reload as much as possible since reloading is very time
> > consuming and may take up to few seconds.
> > In this time slot, there is no application to handle the traffic, and everything is
> > lost.
> > For end user especially cloud service providers, they are sensitive to the
> > traffic down time.
>
> From my viewpoint the upgrade has nothing to do with DPDK as a library,
> the upgrade may be because of application upgrade.
> Unless I'm missing something, this API is not meant for API/ABI it is created
> to allow minimum downtime when doing upgrade of the application.
> Unless I'm missing something critical, since the upgrade in any case is not
> only for the DPDK but the entire app, there isn't any ABI/API issue.
Yes we can consider the case of an application upgrade with the same DPDK.
The patch needs to be reworded in this more realistic direction I think.
We can also improve the usage explanations.
That said, another high level question is about the scope of the feature.
In this patch, only ethdev is targetted.
Do you think we need the same migration mechanism in other classes
like vDPA, crypto, etc?
^ permalink raw reply [relevance 0%]
* Re: [PATCH V8 0/8] telemetry: fix data truncation and conversion error and add hex integer API
2022-12-19 7:06 3% ` [PATCH V8 " Huisong Li
@ 2023-01-16 12:06 0% ` lihuisong (C)
2023-01-30 10:39 0% ` lihuisong (C)
0 siblings, 1 reply; 200+ results
From: lihuisong (C) @ 2023-01-16 12:06 UTC (permalink / raw)
To: dev, Ferruh Yigit, Andrew Rybchenko
Cc: bruce.richardson, mb, andrew.rybchenko, huangdaode, liudongdong3,
fengchengwen
Hi Ferruh and Andrew,
This patch series optimizes some codes and bug.
Can you take a look at this patch series?
If there are no other questions, can it be merged?
Best,
Huisong
在 2022/12/19 15:06, Huisong Li 写道:
> Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> rte_tel_data_add_dict/array_int API. This may cause data conversion
> error or data truncation. This patch series uses 'u64' functions to
> do this.
>
> In addition, this patch series introduces two APIs to store unsigned
> integer values as hexadecimal encoded strings in telemetry library.
>
> ---
> -v8: fix the coding style in patch 7/8
> -v7: replace sprintf with snprintf in patch 6/8
> -v6: fix code alignment to keep in line with codes in the file
> -v5:
> - drop a refactor patch.
> - no limit the bit width for xxx_uint_hex API.
> -v4:
> - remove 'u32' value type.merg
> - add padding zero for hexadecimal value
> -v3: fix a misspelling mistake in commit log.
> -v2:
> - fix ABI break warning.
> - introduce two APIs to store u32 and u64 values as hexadecimal
> encoded strings.
>
> Huisong Li (8):
> telemetry: move to header to controllable range
> ethdev: fix possible data truncation and conversion error
> mempool: fix possible data truncation and conversion error
> cryptodev: fix possible data conversion error
> mem: possible data truncation and conversion error
> telemetry: support adding integer value as hexadecimal
> test: add test cases for adding hex integer value API
> ethdev: display capability values in hexadecimal format
>
> app/test/test_telemetry_data.c | 150 +++++++++++++++++++++++++++++
> lib/cryptodev/rte_cryptodev.c | 2 +-
> lib/eal/common/eal_common_memory.c | 10 +-
> lib/ethdev/rte_ethdev.c | 19 ++--
> lib/mempool/rte_mempool.c | 24 ++---
> lib/telemetry/rte_telemetry.h | 52 +++++++++-
> lib/telemetry/telemetry_data.c | 73 ++++++++++++++
> lib/telemetry/version.map | 9 ++
> 8 files changed, 309 insertions(+), 30 deletions(-)
>
^ permalink raw reply [relevance 0%]
* [PATCH 5/5] test/dmadev: add tests for stopping and restarting dev
@ 2023-01-16 15:37 3% ` Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Bruce Richardson @ 2023-01-16 15:37 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson, Chengwen Feng, Kevin Laatz
Validate device operation when a device is stopped or restarted.
The only complication - and gap in the dmadev ABI specification - is
what happens to the job ids on restart. Some drivers reset them to 0,
while others continue where things left off. Take account of both
posibilities in the test case.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
app/test/test_dmadev.c | 46 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
diff --git a/app/test/test_dmadev.c b/app/test/test_dmadev.c
index de787c14e2..8fb73a41e2 100644
--- a/app/test/test_dmadev.c
+++ b/app/test/test_dmadev.c
@@ -304,6 +304,48 @@ test_enqueue_copies(int16_t dev_id, uint16_t vchan)
|| do_multi_copies(dev_id, vchan, 0, 0, 1);
}
+static int
+test_stop_start(int16_t dev_id, uint16_t vchan)
+{
+ /* device is already started on input, should be (re)started on output */
+
+ uint16_t id = 0;
+ enum rte_dma_status_code status = RTE_DMA_STATUS_SUCCESSFUL;
+
+ /* - test stopping a device works ok,
+ * - then do a start-stop without doing a copy
+ * - finally restart the device
+ * checking for errors at each stage, and validating we can still copy at the end.
+ */
+ if (rte_dma_stop(dev_id) < 0)
+ ERR_RETURN("Error stopping device\n");
+
+ if (rte_dma_start(dev_id) < 0)
+ ERR_RETURN("Error restarting device\n");
+ if (rte_dma_stop(dev_id) < 0)
+ ERR_RETURN("Error stopping device after restart (no jobs executed)\n");
+
+ if (rte_dma_start(dev_id) < 0)
+ ERR_RETURN("Error restarting device after multiple stop-starts\n");
+
+ /* before doing a copy, we need to know what the next id will be it should
+ * either be:
+ * - the last completed job before start if driver does not reset id on stop
+ * - or -1 i.e. next job is 0, if driver does reset the job ids on stop
+ */
+ if (rte_dma_completed_status(dev_id, vchan, 1, &id, &status) != 0)
+ ERR_RETURN("Error with rte_dma_completed_status when no job done\n");
+ id += 1; /* id_count is next job id */
+ if (id != id_count && id != 0)
+ ERR_RETURN("Unexpected next id from device after stop-start. Got %u, expected %u or 0\n",
+ id, id_count);
+
+ id_count = id;
+ if (test_single_copy(dev_id, vchan) < 0)
+ ERR_RETURN("Error performing copy after device restart\n");
+ return 0;
+}
+
/* Failure handling test cases - global macros and variables for those tests*/
#define COMP_BURST_SZ 16
#define OPT_FENCE(idx) ((fence && idx == 8) ? RTE_DMA_OP_FLAG_FENCE : 0)
@@ -819,6 +861,10 @@ test_dmadev_instance(int16_t dev_id)
if (runtest("copy", test_enqueue_copies, 640, dev_id, vchan, CHECK_ERRS) < 0)
goto err;
+ /* run tests stopping/starting devices and check jobs still work after restart */
+ if (runtest("stop-start", test_stop_start, 1, dev_id, vchan, CHECK_ERRS) < 0)
+ goto err;
+
/* run some burst capacity tests */
if (rte_dma_burst_capacity(dev_id, vchan) < 64)
printf("DMA Dev %u: insufficient burst capacity (64 required), skipping tests\n",
--
2.37.2
^ permalink raw reply [relevance 3%]
* [PATCH v2 6/6] test/dmadev: add tests for stopping and restarting dev
@ 2023-01-16 17:37 3% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2023-01-16 17:37 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson, Chengwen Feng, Kevin Laatz
Validate device operation when a device is stopped or restarted.
The only complication - and gap in the dmadev ABI specification - is
what happens to the job ids on restart. Some drivers reset them to 0,
while others continue where things left off. Take account of both
possibilities in the test case.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
app/test/test_dmadev.c | 46 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
diff --git a/app/test/test_dmadev.c b/app/test/test_dmadev.c
index de787c14e2..8fb73a41e2 100644
--- a/app/test/test_dmadev.c
+++ b/app/test/test_dmadev.c
@@ -304,6 +304,48 @@ test_enqueue_copies(int16_t dev_id, uint16_t vchan)
|| do_multi_copies(dev_id, vchan, 0, 0, 1);
}
+static int
+test_stop_start(int16_t dev_id, uint16_t vchan)
+{
+ /* device is already started on input, should be (re)started on output */
+
+ uint16_t id = 0;
+ enum rte_dma_status_code status = RTE_DMA_STATUS_SUCCESSFUL;
+
+ /* - test stopping a device works ok,
+ * - then do a start-stop without doing a copy
+ * - finally restart the device
+ * checking for errors at each stage, and validating we can still copy at the end.
+ */
+ if (rte_dma_stop(dev_id) < 0)
+ ERR_RETURN("Error stopping device\n");
+
+ if (rte_dma_start(dev_id) < 0)
+ ERR_RETURN("Error restarting device\n");
+ if (rte_dma_stop(dev_id) < 0)
+ ERR_RETURN("Error stopping device after restart (no jobs executed)\n");
+
+ if (rte_dma_start(dev_id) < 0)
+ ERR_RETURN("Error restarting device after multiple stop-starts\n");
+
+ /* before doing a copy, we need to know what the next id will be it should
+ * either be:
+ * - the last completed job before start if driver does not reset id on stop
+ * - or -1 i.e. next job is 0, if driver does reset the job ids on stop
+ */
+ if (rte_dma_completed_status(dev_id, vchan, 1, &id, &status) != 0)
+ ERR_RETURN("Error with rte_dma_completed_status when no job done\n");
+ id += 1; /* id_count is next job id */
+ if (id != id_count && id != 0)
+ ERR_RETURN("Unexpected next id from device after stop-start. Got %u, expected %u or 0\n",
+ id, id_count);
+
+ id_count = id;
+ if (test_single_copy(dev_id, vchan) < 0)
+ ERR_RETURN("Error performing copy after device restart\n");
+ return 0;
+}
+
/* Failure handling test cases - global macros and variables for those tests*/
#define COMP_BURST_SZ 16
#define OPT_FENCE(idx) ((fence && idx == 8) ? RTE_DMA_OP_FLAG_FENCE : 0)
@@ -819,6 +861,10 @@ test_dmadev_instance(int16_t dev_id)
if (runtest("copy", test_enqueue_copies, 640, dev_id, vchan, CHECK_ERRS) < 0)
goto err;
+ /* run tests stopping/starting devices and check jobs still work after restart */
+ if (runtest("stop-start", test_stop_start, 1, dev_id, vchan, CHECK_ERRS) < 0)
+ goto err;
+
/* run some burst capacity tests */
if (rte_dma_burst_capacity(dev_id, vchan) < 64)
printf("DMA Dev %u: insufficient burst capacity (64 required), skipping tests\n",
--
2.37.2
^ permalink raw reply [relevance 3%]
* [RFC] Fix cryptodev socket id for devices on unknown NUMA node
@ 2023-01-17 10:16 3% Didier Pallard
2023-01-17 11:32 0% ` Morten Brørup
0 siblings, 1 reply; 200+ results
From: Didier Pallard @ 2023-01-17 10:16 UTC (permalink / raw)
To: Akhil Goyal, Fan Zhang, Olivier Matz; +Cc: dev
Since DPDK 22.11 and below commit:
https://git.dpdk.org/dpdk/commit/?id=7dcd73e37965ba0bfa430efeac362fe183ed0ae2
rte_cryptodev_socket_id() could return an incorrect value of 255.
Problem has been seen during configuration of the qat device
on an Atom C3000 architecture. On this arch, PCI is not depending on
any numa socket, causing device numa_node to be equal to SOCKET_ID_ANY.
Due to incorrect cast to uint8_t, this value is stored as 255
in cryptodev structure and returned as such by rte_cryptodev_socket_id()
function.
Below patch proposes one way to fix the issue: casting to a signed int8_t
instead of the uint8_t. (it could also be casted to an int, that is the
usual type for numa_node, but this may break the ABI). This makes the
SOCKET_ID_ANY being propagated up to the user.
Another solution could be to always store a valid numa_node in this field
instead of just copying the numa_node field of the device, but this
requires to fix most crypto PMDs, that are currently just copying the
device value.
What is the preferred solution?
---
cryptodev: fix numa_node type
Since below commit, numa_node can be set to SOCKET_ID_ANY.
Do not cast numa_node to an unsigned uint8, else SOCKET_ID_ANY
is converted to 255, causing rte_cryptodev_socket_id to return
an incorrect value.
Fixes: 7dcd73e37965 ("drivers/bus: set device NUMA node to unknown by default")
Signed-off-by: Didier Pallard <didier.pallard@6wind.com>
---
lib/cryptodev/cryptodev_pmd.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/cryptodev/cryptodev_pmd.h b/lib/cryptodev/cryptodev_pmd.h
index 0020102eb7db..db4745d620f4 100644
--- a/lib/cryptodev/cryptodev_pmd.h
+++ b/lib/cryptodev/cryptodev_pmd.h
@@ -64,8 +64,8 @@ struct rte_cryptodev_pmd_init_params {
struct rte_cryptodev_data {
/** Device ID for this instance */
uint8_t dev_id;
- /** Socket ID where memory is allocated */
- uint8_t socket_id;
+ /** Socket ID of the device */
+ int8_t socket_id;
/** Unique identifier name */
char name[RTE_CRYPTODEV_NAME_MAX_LEN];
--
2.30.2
^ permalink raw reply [relevance 3%]
* RE: [RFC] Fix cryptodev socket id for devices on unknown NUMA node
2023-01-17 10:16 3% [RFC] Fix cryptodev socket id for devices on unknown NUMA node Didier Pallard
@ 2023-01-17 11:32 0% ` Morten Brørup
0 siblings, 0 replies; 200+ results
From: Morten Brørup @ 2023-01-17 11:32 UTC (permalink / raw)
To: Didier Pallard, Akhil Goyal, Fan Zhang, Olivier Matz, thomas; +Cc: dev
> From: Didier Pallard [mailto:didier.pallard@6wind.com]
> Sent: Tuesday, 17 January 2023 11.17
>
> Since DPDK 22.11 and below commit:
> https://git.dpdk.org/dpdk/commit/?id=7dcd73e37965ba0bfa430efeac362fe183
> ed0ae2
> rte_cryptodev_socket_id() could return an incorrect value of 255.
> Problem has been seen during configuration of the qat device
> on an Atom C3000 architecture. On this arch, PCI is not depending on
> any numa socket, causing device numa_node to be equal to SOCKET_ID_ANY.
Disclaimer: I'm not up to speed with this topic or patch, so feel free to ignore my comments here! I'm only speaking up because I fear we are increasing the risk of bugs here. But again, please bear with me, if I have totally misunderstood this!
I was under the impression that single-socket systems used socket_id 0 as default. How can the PCI bus (or QAT device) not depend on any socket? It must be connected somewhere.
Doesn't assigning socket_id = -1 for devices (QAT or anything else) introduce a big risk of bugs, e.g. in comparisons? The special socket_id value -1 should have only two meanings: 1) return value "error", or 2) input value "any". Now it also can mean 3) "unknown"? How do comparison functions work for that... is "any" == "unknown"? And does searching for "0" match "unknown"? It might, or might not, but searching for "any" does match "0". And how about searching for "unknown", if such a value is propagate around in the system.
And if we started considering socket_id == -1 valid with that patch, should the return type of rte_socket_id(void) be signed instead of unsigned?
> Due to incorrect cast to uint8_t, this value is stored as 255
> in cryptodev structure and returned as such by
> rte_cryptodev_socket_id()
> function.
>
> Below patch proposes one way to fix the issue: casting to a signed
> int8_t
> instead of the uint8_t. (it could also be casted to an int, that is the
> usual type for numa_node, but this may break the ABI). This makes the
> SOCKET_ID_ANY being propagated up to the user.
> Another solution could be to always store a valid numa_node in this
> field
> instead of just copying the numa_node field of the device, but this
> requires to fix most crypto PMDs, that are currently just copying the
> device value.
>
> What is the preferred solution?
I prefer that garbage data is not propagated, even if it requires fixing many places.
But as I indicated above, I wonder if part of the root cause stems from considering socket_id == -1 valid data in some structures. (It could be allowed temporarily, e.g. in a template to indicate that the field is uninitialized. But it should not propagate outside the templates when instantiating objects based on the templates.)
>
> ---
> cryptodev: fix numa_node type
>
> Since below commit, numa_node can be set to SOCKET_ID_ANY.
> Do not cast numa_node to an unsigned uint8, else SOCKET_ID_ANY
> is converted to 255, causing rte_cryptodev_socket_id to return
> an incorrect value.
>
> Fixes: 7dcd73e37965 ("drivers/bus: set device NUMA node to unknown by
> default")
> Signed-off-by: Didier Pallard <didier.pallard@6wind.com>
> ---
> lib/cryptodev/cryptodev_pmd.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lib/cryptodev/cryptodev_pmd.h
> b/lib/cryptodev/cryptodev_pmd.h
> index 0020102eb7db..db4745d620f4 100644
> --- a/lib/cryptodev/cryptodev_pmd.h
> +++ b/lib/cryptodev/cryptodev_pmd.h
> @@ -64,8 +64,8 @@ struct rte_cryptodev_pmd_init_params {
> struct rte_cryptodev_data {
> /** Device ID for this instance */
> uint8_t dev_id;
> - /** Socket ID where memory is allocated */
> - uint8_t socket_id;
> + /** Socket ID of the device */
> + int8_t socket_id;
> /** Unique identifier name */
> char name[RTE_CRYPTODEV_NAME_MAX_LEN];
>
> --
> 2.30.2
>
^ permalink raw reply [relevance 0%]
* Re: [PATCH 1/3] eventdev/eth_rx: add params set/get APIs
@ 2023-01-18 10:22 4% ` Jerin Jacob
2023-01-20 8:58 0% ` Naga Harish K, S V
1 sibling, 1 reply; 200+ results
From: Jerin Jacob @ 2023-01-18 10:22 UTC (permalink / raw)
To: Naga Harish K S V; +Cc: jerinj, abhinandan.gujjar, dev, jay.jayatheerthan
On Sat, Jan 7, 2023 at 9:49 PM Naga Harish K S V
<s.v.naga.harish.k@intel.com> wrote:
>
> The adapter configuration parameters defined in the
> ``struct rte_event_eth_rx_adapter_config_params`` can be configured
> and retrieved using ``rte_event_eth_rx_adapter_set_params`` and
> ``rte_event_eth_tx_adapter_get_params`` respectively.
>
> Signed-off-by: Naga Harish K S V <s.v.naga.harish.k@intel.com>
> ---
>
> +/**
> + * Adapter configuration parameters
> + */
> +struct rte_event_eth_rx_adapter_runtime_params {
> + uint32_t max_nb_rx;
> + /**< The adapter can return early if it has processed at least
> + * max_nb_rx mbufs. This isn't treated as a requirement; batching may
> + * cause the adapter to process more than max_nb_rx mbufs.
This parameter as specific to SW only driver. So future something
added from HW only driver item then it won't work
for SW driver. So we need capability per adapter.
So, I would suggest following theme across _all_ adapters.
1) Introduce RTE_EVENT_ETH_RX_ADAPTER_CAP_RUNTIME_XYZ and associate
each parameter(the one we think, it is not common for all adapters)
2) Add some reserved fields in rte_event_eth_rx_adapter_runtime_params
so that we don't break ABI in future
3) Add rte_event_eth_rx_adapter_runtime_params_init() function just
make structure fill with default to avoid ABI break
4) Add rte_event_eth_rx_adapter_runtime_params_info_get(). Lets
capability flags and other items can be return via this
5) Change rte_event_eth_rx_adapter_set_params as
rte_event_eth_rx_adapter_runtime_set() or
rte_event_eth_rx_adapter_runtime_params_set() to make it runtime
explicit
6) Change rte_event_eth_rx_adapter_get_params as
rte_event_eth_rx_adapter_runtime_get() or
rte_event_eth_rx_adapter_runtime_params_get() to make it runtime
explicit
^ permalink raw reply [relevance 4%]
* Re: [PATCH v4] devtools: parallelize ABI check
2023-01-12 14:14 4% ` Ferruh Yigit
@ 2023-01-18 10:45 4% ` David Marchand
2023-01-18 11:43 4% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2023-01-18 10:45 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: Thomas Monjalon, dev, bruce.richardson
On Thu, Jan 12, 2023 at 3:15 PM Ferruh Yigit <ferruh.yigit@amd.com> wrote:
> >> abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
> >> abiret=$?
> >> - echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'" >&2
> >> - error=1
> >> - echo
> >> + echo "Error: ABI issue reported for abidiff $ABIDIFF_OPTIONS $dump $dump2" >&2
> >> if [ $(($abiret & 3)) -ne 0 ]; then
> >> echo "ABIDIFF_ERROR|ABIDIFF_USAGE_ERROR, this could be a script or environment issue." >&2
> >> fi
> >> @@ -57,8 +55,13 @@ for dump in $(find $refdir -name "*.dump"); do
> >> if [ $(($abiret & 8)) -ne 0 ]; then
> >> echo "ABIDIFF_ABI_INCOMPATIBLE_CHANGE, this change breaks the ABI." >&2
> >> fi
> >> - echo
> >> + return 1
> >> }
> >> -done
> >> +}'
> >> +
> >> +error=
> >> +find $refdir -name "*.dump" |
> >> +xargs -n1 -P0 sh -c 'eval "$diff_func"; run_diff $0' ||
> >> +error=1
> >>
> >> [ -z "$error" ] || [ -n "$warnonly" ]
> >
> > For the record, on my system, calling this script is ~5 times faster:
> > - before
> > real 0m5,447s
> > user 0m4,497s
> > sys 0m0,937s
> >
> > - after
> > real 0m1,202s
> > user 0m10,784s
> > sys 0m2,027s
> >
> >
> >> diff --git a/devtools/gen-abi.sh b/devtools/gen-abi.sh
> >> index f15a3b9aaf..61f7510ea1 100755
> >> --- a/devtools/gen-abi.sh
> >> +++ b/devtools/gen-abi.sh
> >> @@ -22,5 +22,6 @@ for f in $(find $installdir -name "*.so.*"); do
> >> fi
> >>
> >> libname=$(basename $f)
> >> - abidw --out-file $dumpdir/${libname%.so*}.dump $f
> >> -done
> >> + echo $dumpdir/${libname%.so*}.dump $f
> >> +done |
> >> +xargs -n2 -P0 abidw --out-file
> >> --
> >> 2.39.0
> >>
> >
> > - before
> > real 0m8,237s
> > user 0m7,704s
> > sys 0m0,504s
> >
> > - after
> > real 0m2,517s
> > user 0m14,145s
> > sys 0m0,766s
> >
> >
> > Ferruh, I am seeing quite different numbers for running those scripts
> > (clearly not of the minute order).
> > I switched to testing/building in tmpfs some time ago.
> > It requires a good amount of memory (I empirically allocated 40G), but
> > maybe worth a try for you?
> >
>
> I run 'test-meson-builds.sh' script directly and yes I am getting
> different numbers although there is still improvement, not in scale with
> what you are getting, with v4 I have following:
>
> - before
> real 10m3.248s
> user 39m8.664s
> sys 14m52.870s
>
> - after
> real 7m49.086s
> user 39m59.507s
> sys 15m0.598s
Well, yes, I did not realise which apples you were looking at :-).
The change looks good in any case.
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [RFC 2/5] ethdev: introduce the affinity field in Tx queue API
2022-12-21 10:29 2% ` [RFC 2/5] ethdev: introduce the affinity field " Jiawei Wang
2023-01-11 16:47 0% ` Ori Kam
@ 2023-01-18 11:37 0% ` Thomas Monjalon
2023-01-18 14:44 0% ` Jiawei(Jonny) Wang
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2023-01-18 11:37 UTC (permalink / raw)
To: Jiawei Wang
Cc: viacheslavo, orika, Aman Singh, Yuying Zhang, Ferruh Yigit,
Andrew Rybchenko, dev, rasland, jerinj
21/12/2022 11:29, Jiawei Wang:
> For the multiple hardware ports connect to a single DPDK port (mhpsdp),
> the previous patch introduces the new rte flow item to match the port
> affinity of the received packets.
>
> This patch adds the tx_affinity setting in Tx queue API, the affinity value
> reflects packets be sent to which hardware port.
I think "affinity" means we would like packet to be sent
on a specific hardware port, but it is not mandatory.
Is it the meaning you want? Or should it be a mandatory port?
> Adds the new tx_affinity field into the padding hole of rte_eth_txconf
> structure, the size of rte_eth_txconf keeps the same. Adds a suppress
> type for structure change in the ABI check file.
>
> This patch adds the testpmd command line:
> testpmd> port config (port_id) txq (queue_id) affinity (value)
>
> For example, there're two hardware ports connects to a single DPDK
connects -> connected
> port (port id 0), and affinity 1 stood for hard port 1 and affinity
> 2 stood for hardware port 2, used the below command to config
> tx affinity for each TxQ:
> port config 0 txq 0 affinity 1
> port config 0 txq 1 affinity 1
> port config 0 txq 2 affinity 2
> port config 0 txq 3 affinity 2
>
> These commands config the TxQ index 0 and TxQ index 1 with affinity 1,
> uses TxQ 0 or TxQ 1 send packets, these packets will be sent from the
> hardware port 1, and similar with hardware port 2 if sending packets
> with TxQ 2 or TxQ 3.
[...]
> @@ -212,6 +212,10 @@ API Changes
> +* ethdev: added a new field:
> +
> + - Tx affinity per-queue ``rte_eth_txconf.tx_affinity``
Adding a new field is not an API change because
existing applications don't need to update their code
if they don't care this new field.
I think you can remove this note.
> --- a/lib/ethdev/rte_ethdev.h
> +++ b/lib/ethdev/rte_ethdev.h
> @@ -1138,6 +1138,7 @@ struct rte_eth_txconf {
> less free descriptors than this value. */
>
> uint8_t tx_deferred_start; /**< Do not start queue with rte_eth_dev_start(). */
> + uint8_t tx_affinity; /**< Drives the setting of affinity per-queue. */
Why "Drives"? It is the setting, right?
rte_eth_txconf is per-queue so no need to repeat.
I think a good comment here would be to mention it is a physical port index for mhpsdp.
Another good comment would be to specify how ports are numbered.
^ permalink raw reply [relevance 0%]
* Re: [PATCH v4] devtools: parallelize ABI check
2023-01-18 10:45 4% ` David Marchand
@ 2023-01-18 11:43 4% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2023-01-18 11:43 UTC (permalink / raw)
To: David Marchand; +Cc: Thomas Monjalon, dev, bruce.richardson
On 1/18/2023 10:45 AM, David Marchand wrote:
> On Thu, Jan 12, 2023 at 3:15 PM Ferruh Yigit <ferruh.yigit@amd.com> wrote:
>>>> abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
>>>> abiret=$?
>>>> - echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'" >&2
>>>> - error=1
>>>> - echo
>>>> + echo "Error: ABI issue reported for abidiff $ABIDIFF_OPTIONS $dump $dump2" >&2
>>>> if [ $(($abiret & 3)) -ne 0 ]; then
>>>> echo "ABIDIFF_ERROR|ABIDIFF_USAGE_ERROR, this could be a script or environment issue." >&2
>>>> fi
>>>> @@ -57,8 +55,13 @@ for dump in $(find $refdir -name "*.dump"); do
>>>> if [ $(($abiret & 8)) -ne 0 ]; then
>>>> echo "ABIDIFF_ABI_INCOMPATIBLE_CHANGE, this change breaks the ABI." >&2
>>>> fi
>>>> - echo
>>>> + return 1
>>>> }
>>>> -done
>>>> +}'
>>>> +
>>>> +error=
>>>> +find $refdir -name "*.dump" |
>>>> +xargs -n1 -P0 sh -c 'eval "$diff_func"; run_diff $0' ||
>>>> +error=1
>>>>
>>>> [ -z "$error" ] || [ -n "$warnonly" ]
>>>
>>> For the record, on my system, calling this script is ~5 times faster:
>>> - before
>>> real 0m5,447s
>>> user 0m4,497s
>>> sys 0m0,937s
>>>
>>> - after
>>> real 0m1,202s
>>> user 0m10,784s
>>> sys 0m2,027s
>>>
>>>
>>>> diff --git a/devtools/gen-abi.sh b/devtools/gen-abi.sh
>>>> index f15a3b9aaf..61f7510ea1 100755
>>>> --- a/devtools/gen-abi.sh
>>>> +++ b/devtools/gen-abi.sh
>>>> @@ -22,5 +22,6 @@ for f in $(find $installdir -name "*.so.*"); do
>>>> fi
>>>>
>>>> libname=$(basename $f)
>>>> - abidw --out-file $dumpdir/${libname%.so*}.dump $f
>>>> -done
>>>> + echo $dumpdir/${libname%.so*}.dump $f
>>>> +done |
>>>> +xargs -n2 -P0 abidw --out-file
>>>> --
>>>> 2.39.0
>>>>
>>>
>>> - before
>>> real 0m8,237s
>>> user 0m7,704s
>>> sys 0m0,504s
>>>
>>> - after
>>> real 0m2,517s
>>> user 0m14,145s
>>> sys 0m0,766s
>>>
>>>
>>> Ferruh, I am seeing quite different numbers for running those scripts
>>> (clearly not of the minute order).
>>> I switched to testing/building in tmpfs some time ago.
>>> It requires a good amount of memory (I empirically allocated 40G), but
>>> maybe worth a try for you?
>>>
>>
>> I run 'test-meson-builds.sh' script directly and yes I am getting
>> different numbers although there is still improvement, not in scale with
>> what you are getting, with v4 I have following:
>>
>> - before
>> real 10m3.248s
>> user 39m8.664s
>> sys 14m52.870s
>>
>> - after
>> real 7m49.086s
>> user 39m59.507s
>> sys 15m0.598s
>
> Well, yes, I did not realise which apples you were looking at :-).
> The change looks good in any case.
>
Ack
^ permalink raw reply [relevance 4%]
* Re: [PATCH V4 0/5] app/testpmd: support mulitple process attach and detach port
2023-01-11 10:46 0% ` Ferruh Yigit
2023-01-12 2:26 0% ` lihuisong (C)
@ 2023-01-18 14:12 0% ` Thomas Monjalon
2023-01-19 10:31 0% ` lihuisong (C)
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2023-01-18 14:12 UTC (permalink / raw)
To: lihuisong (C), Ferruh Yigit
Cc: dev, andrew.rybchenko, liudongdong3, huangdaode, fengchengwen
11/01/2023 11:46, Ferruh Yigit:
> On 1/11/2023 10:27 AM, Ferruh Yigit wrote:
> > On 1/11/2023 12:53 AM, lihuisong (C) wrote:
> >> 在 2023/1/11 0:51, Ferruh Yigit 写道:
> >>> Hi Huisong,
> >>>
> >>> I haven't checked the patch in detail yet, but I can see it gives some
> >>> ABI compatibility warnings, is this expected:
> >> This is to be expected. Because we insert a device state,
> >> RTE_ETH_DEV_ALLOCATED,
> >> before RTE_ETH_DEV_ATTACHED for resolving the issue patch 2/5 mentioned.
> >> We may have to announce it. What do you think?
> >
> > If there is an actual ABI break, it can't go in this release, need to
> > wait LTS release and yes needs deprecation notice in advance.
> >
> > But not all enum value change warnings are real break, need to
> > investigate all warnings one by one.
> > Need to investigate if old application & new dpdk library may cause any
> > unexpected behavior for application.
> >
>
> OR, appending new enum item, `RTE_ETH_DEV_ALLOCATED`, to the end of the
> enum solves the issue, although logically it won't look nice.
> Perhaps order can be fixed in next LTS, to have more logical order, but
> not quite sure if order worth the disturbance may cause in application.
It is a state with a logical order, so it would be nice to be able to do
if (state > RTE_ETH_DEV_ALLOCATED)
but given there is RTE_ETH_DEV_REMOVED later in the enum, not sure it is useful.
^ permalink raw reply [relevance 0%]
* Re: [PATCH v4] devtools: parallelize ABI check
2023-01-11 19:53 33% ` [PATCH v4] " Thomas Monjalon
2023-01-12 10:53 4% ` David Marchand
@ 2023-01-18 14:29 4% ` David Marchand
1 sibling, 0 replies; 200+ results
From: David Marchand @ 2023-01-18 14:29 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, bruce.richardson, Ferruh Yigit
On Wed, Jan 11, 2023 at 8:53 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> Generation and comparison of ABI dumps are done on multiple cores
> thanks to xargs -P0.
> It can accelerate this long step by 5 in my tests.
>
> xargs reports a global error if one of the process has an error.
>
> Running a shell function with xargs requires to export it.
> POSIX shell does not support function export except using an "eval trick".
> Required variables are also exported.
>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
Reviewed-by: David Marchand <david.marchand@redhat.com>
Applied, thanks.
--
David Marchand
^ permalink raw reply [relevance 4%]
* RE: [RFC 2/5] ethdev: introduce the affinity field in Tx queue API
2023-01-18 11:37 0% ` Thomas Monjalon
@ 2023-01-18 14:44 0% ` Jiawei(Jonny) Wang
2023-01-18 16:31 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Jiawei(Jonny) Wang @ 2023-01-18 14:44 UTC (permalink / raw)
To: NBU-Contact-Thomas Monjalon (EXTERNAL)
Cc: Slava Ovsiienko, Ori Kam, Aman Singh, Yuying Zhang, Ferruh Yigit,
Andrew Rybchenko, dev, Raslan Darawsheh, jerinj
Hi,
>
> 21/12/2022 11:29, Jiawei Wang:
> > For the multiple hardware ports connect to a single DPDK port
> > (mhpsdp), the previous patch introduces the new rte flow item to match
> > the port affinity of the received packets.
> >
> > This patch adds the tx_affinity setting in Tx queue API, the affinity
> > value reflects packets be sent to which hardware port.
>
> I think "affinity" means we would like packet to be sent on a specific hardware
> port, but it is not mandatory.
> Is it the meaning you want? Or should it be a mandatory port?
>
Right, it's optional setting not mandatory.
> > Adds the new tx_affinity field into the padding hole of rte_eth_txconf
> > structure, the size of rte_eth_txconf keeps the same. Adds a suppress
> > type for structure change in the ABI check file.
> >
> > This patch adds the testpmd command line:
> > testpmd> port config (port_id) txq (queue_id) affinity (value)
> >
> > For example, there're two hardware ports connects to a single DPDK
>
> connects -> connected
>
OK, will fix in next version.
> > port (port id 0), and affinity 1 stood for hard port 1 and affinity
> > 2 stood for hardware port 2, used the below command to config tx
> > affinity for each TxQ:
> > port config 0 txq 0 affinity 1
> > port config 0 txq 1 affinity 1
> > port config 0 txq 2 affinity 2
> > port config 0 txq 3 affinity 2
> >
> > These commands config the TxQ index 0 and TxQ index 1 with affinity 1,
> > uses TxQ 0 or TxQ 1 send packets, these packets will be sent from the
> > hardware port 1, and similar with hardware port 2 if sending packets
> > with TxQ 2 or TxQ 3.
>
> [...]
> > @@ -212,6 +212,10 @@ API Changes
> > +* ethdev: added a new field:
> > +
> > + - Tx affinity per-queue ``rte_eth_txconf.tx_affinity``
>
> Adding a new field is not an API change because existing applications don't
> need to update their code if they don't care this new field.
> I think you can remove this note.
>
OK, will remove in next version.
> > --- a/lib/ethdev/rte_ethdev.h
> > +++ b/lib/ethdev/rte_ethdev.h
> > @@ -1138,6 +1138,7 @@ struct rte_eth_txconf {
> > less free descriptors than this value. */
> >
> > uint8_t tx_deferred_start; /**< Do not start queue with
> > rte_eth_dev_start(). */
> > + uint8_t tx_affinity; /**< Drives the setting of affinity per-queue.
> > +*/
>
> Why "Drives"? It is the setting, right?
> rte_eth_txconf is per-queue so no need to repeat.
> I think a good comment here would be to mention it is a physical port index for
> mhpsdp.
> Another good comment would be to specify how ports are numbered.
>
OK, will update the comment for this new setting.
Thanks.
^ permalink raw reply [relevance 0%]
* Re: [RFC 2/5] ethdev: introduce the affinity field in Tx queue API
2023-01-18 14:44 0% ` Jiawei(Jonny) Wang
@ 2023-01-18 16:31 0% ` Thomas Monjalon
2023-01-24 13:32 0% ` Jiawei(Jonny) Wang
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2023-01-18 16:31 UTC (permalink / raw)
To: Jiawei(Jonny) Wang
Cc: Slava Ovsiienko, Ori Kam, Aman Singh, Yuying Zhang, Ferruh Yigit,
Andrew Rybchenko, dev, Raslan Darawsheh, jerinj
18/01/2023 15:44, Jiawei(Jonny) Wang:
> > 21/12/2022 11:29, Jiawei Wang:
> > > For the multiple hardware ports connect to a single DPDK port
> > > (mhpsdp), the previous patch introduces the new rte flow item to match
> > > the port affinity of the received packets.
> > >
> > > This patch adds the tx_affinity setting in Tx queue API, the affinity
> > > value reflects packets be sent to which hardware port.
> >
> > I think "affinity" means we would like packet to be sent on a specific hardware
> > port, but it is not mandatory.
> > Is it the meaning you want? Or should it be a mandatory port?
>
> Right, it's optional setting not mandatory.
I think there is a misunderstanding.
I mean that "affinity" with port 0 may suggest that we try
to send to port 0 but sometimes the packet will be sent to port 1.
And I think you want the packet to be always sent to port 0
if affinity is 0, right?
If yes, I think the word "affinity" does not convey the right idea.
And again, the naming should give the idea that we are talking about
multiple ports merged in one DPDK port.
> > > Adds the new tx_affinity field into the padding hole of rte_eth_txconf
> > > structure, the size of rte_eth_txconf keeps the same. Adds a suppress
> > > type for structure change in the ABI check file.
> > >
> > > This patch adds the testpmd command line:
> > > testpmd> port config (port_id) txq (queue_id) affinity (value)
> > >
> > > For example, there're two hardware ports connects to a single DPDK
> >
> > connects -> connected
>
> OK, will fix in next version.
>
> > > port (port id 0), and affinity 1 stood for hard port 1 and affinity
> > > 2 stood for hardware port 2, used the below command to config tx
> > > affinity for each TxQ:
> > > port config 0 txq 0 affinity 1
> > > port config 0 txq 1 affinity 1
> > > port config 0 txq 2 affinity 2
> > > port config 0 txq 3 affinity 2
> > >
> > > These commands config the TxQ index 0 and TxQ index 1 with affinity 1,
> > > uses TxQ 0 or TxQ 1 send packets, these packets will be sent from the
> > > hardware port 1, and similar with hardware port 2 if sending packets
> > > with TxQ 2 or TxQ 3.
> >
> > [...]
> > > @@ -212,6 +212,10 @@ API Changes
> > > +* ethdev: added a new field:
> > > +
> > > + - Tx affinity per-queue ``rte_eth_txconf.tx_affinity``
> >
> > Adding a new field is not an API change because existing applications don't
> > need to update their code if they don't care this new field.
> > I think you can remove this note.
>
> OK, will remove in next version.
>
> > > --- a/lib/ethdev/rte_ethdev.h
> > > +++ b/lib/ethdev/rte_ethdev.h
> > > @@ -1138,6 +1138,7 @@ struct rte_eth_txconf {
> > > less free descriptors than this value. */
> > >
> > > uint8_t tx_deferred_start; /**< Do not start queue with
> > > rte_eth_dev_start(). */
> > > + uint8_t tx_affinity; /**< Drives the setting of affinity per-queue.
> > > +*/
> >
> > Why "Drives"? It is the setting, right?
> > rte_eth_txconf is per-queue so no need to repeat.
> > I think a good comment here would be to mention it is a physical port index for
> > mhpsdp.
> > Another good comment would be to specify how ports are numbered.
>
> OK, will update the comment for this new setting.
>
> Thanks.
^ permalink raw reply [relevance 0%]
* [PATCH v2 1/8] ethdev: add IPv6 routing extension header definition
@ 2023-01-19 3:11 3% ` Rongwei Liu
2023-01-20 9:20 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Rongwei Liu @ 2023-01-19 3:11 UTC (permalink / raw)
To: matan, viacheslavo, orika, thomas, Aman Singh, Yuying Zhang,
Ferruh Yigit, Andrew Rybchenko, Olivier Matz
Cc: dev, rasland
Add IPv6 routing extension header definition and no
TLV support for now.
At rte_flow layer, there are new items defined for matching
type/nexthdr/segments_left field.
Add command line support for IPv6 routing extension header
matching: type/nexthdr/segment_list.
Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
---
app/test-pmd/cmdline_flow.c | 46 ++++++++++++++++++++++++++
doc/guides/prog_guide/rte_flow.rst | 9 +++++
doc/guides/rel_notes/release_23_03.rst | 10 ++++++
lib/ethdev/rte_flow.c | 16 +++++++++
lib/ethdev/rte_flow.h | 19 +++++++++++
lib/net/rte_ip.h | 21 ++++++++++++
6 files changed, 121 insertions(+)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 88108498e0..7a8516829c 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -298,6 +298,10 @@ enum index {
ITEM_IPV6_SRC,
ITEM_IPV6_DST,
ITEM_IPV6_HAS_FRAG_EXT,
+ ITEM_IPV6_ROUTING_EXT,
+ ITEM_IPV6_ROUTING_EXT_TYPE,
+ ITEM_IPV6_ROUTING_EXT_NEXT_HDR,
+ ITEM_IPV6_ROUTING_EXT_SEG_LEFT,
ITEM_ICMP,
ITEM_ICMP_TYPE,
ITEM_ICMP_CODE,
@@ -1326,6 +1330,7 @@ static const enum index next_item[] = {
ITEM_ARP_ETH_IPV4,
ITEM_IPV6_EXT,
ITEM_IPV6_FRAG_EXT,
+ ITEM_IPV6_ROUTING_EXT,
ITEM_ICMP6,
ITEM_ICMP6_ND_NS,
ITEM_ICMP6_ND_NA,
@@ -1435,6 +1440,15 @@ static const enum index item_ipv6[] = {
ITEM_IPV6_SRC,
ITEM_IPV6_DST,
ITEM_IPV6_HAS_FRAG_EXT,
+ ITEM_IPV6_ROUTING_EXT,
+ ITEM_NEXT,
+ ZERO,
+};
+
+static const enum index item_ipv6_routing_ext[] = {
+ ITEM_IPV6_ROUTING_EXT_TYPE,
+ ITEM_IPV6_ROUTING_EXT_NEXT_HDR,
+ ITEM_IPV6_ROUTING_EXT_SEG_LEFT,
ITEM_NEXT,
ZERO,
};
@@ -3844,6 +3858,38 @@ static const struct token token_list[] = {
.args = ARGS(ARGS_ENTRY_BF(struct rte_flow_item_ipv6,
has_frag_ext, 1)),
},
+ [ITEM_IPV6_ROUTING_EXT] = {
+ .name = "ipv6_routing_ext",
+ .help = "match IPv6 routing extension header",
+ .priv = PRIV_ITEM(IPV6_ROUTING_EXT,
+ sizeof(struct rte_flow_item_ipv6_routing_ext)),
+ .next = NEXT(item_ipv6_routing_ext),
+ .call = parse_vc,
+ },
+ [ITEM_IPV6_ROUTING_EXT_TYPE] = {
+ .name = "ext_type",
+ .help = "match IPv6 routing extension header type",
+ .next = NEXT(item_ipv6_routing_ext, NEXT_ENTRY(COMMON_UNSIGNED),
+ item_param),
+ .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_routing_ext,
+ hdr.type)),
+ },
+ [ITEM_IPV6_ROUTING_EXT_NEXT_HDR] = {
+ .name = "ext_next_hdr",
+ .help = "match IPv6 routing extension header next header type",
+ .next = NEXT(item_ipv6_routing_ext, NEXT_ENTRY(COMMON_UNSIGNED),
+ item_param),
+ .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_routing_ext,
+ hdr.next_hdr)),
+ },
+ [ITEM_IPV6_ROUTING_EXT_SEG_LEFT] = {
+ .name = "ext_seg_left",
+ .help = "match IPv6 routing extension header segment left",
+ .next = NEXT(item_ipv6_routing_ext, NEXT_ENTRY(COMMON_UNSIGNED),
+ item_param),
+ .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_routing_ext,
+ hdr.segments_left)),
+ },
[ITEM_ICMP] = {
.name = "icmp",
.help = "match ICMP header",
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 3e6242803d..ae99036be0 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1544,6 +1544,15 @@ Matches Color Marker set by a Meter.
- ``color``: Metering color marker.
+Item: ``IPV6_ROUTING_EXT``
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Matches ipv6 routing extension header.
+
+- ``next_hdr``: Next layer header type.
+- ``type``: IPv6 routing extension header type.
+- ``segments_left``: How many IPv6 destination addresses carries on
+
Actions
~~~~~~~
diff --git a/doc/guides/rel_notes/release_23_03.rst b/doc/guides/rel_notes/release_23_03.rst
index b8c5b68d6c..2a794d598e 100644
--- a/doc/guides/rel_notes/release_23_03.rst
+++ b/doc/guides/rel_notes/release_23_03.rst
@@ -55,6 +55,11 @@ New Features
Also, make sure to start the actual text at the margin.
=======================================================
+* **Added rte_flow support for matching IPv6 routing extension header fields.**
+
+ Added ``ipv6_routing_ext`` items in rte_flow to match IPv6 routing extension
+ header
+
Removed Items
-------------
@@ -84,6 +89,11 @@ API Changes
Also, make sure to start the actual text at the margin.
=======================================================
+* ethdev: added a new structure:
+
+ - IPv6 routing extension header ``rte_flow_item_ipv6_routing_ext`` and
+ ``rte_ipv6_routing_ext``
+
ABI Changes
-----------
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index 7d0c24366c..4074b475c8 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -76,6 +76,20 @@ rte_flow_item_flex_conv(void *buf, const void *data)
return src->length;
}
+static size_t
+rte_flow_item_ipv6_routing_ext_conv(void *buf, const void *data)
+{
+ struct rte_flow_item_ipv6_routing_ext *dst = buf;
+ const struct rte_flow_item_ipv6_routing_ext *src = data;
+ size_t len;
+
+ len = src->hdr.hdr_len ? src->hdr.hdr_len << 3 : src->hdr.segments_left << 4;
+ if (buf)
+ rte_memcpy((void *)((uintptr_t)(dst->hdr.segments)),
+ src->hdr.segments, len);
+ return len;
+}
+
/** Generate flow_item[] entry. */
#define MK_FLOW_ITEM(t, s) \
[RTE_FLOW_ITEM_TYPE_ ## t] = { \
@@ -157,6 +171,8 @@ static const struct rte_flow_desc_data rte_flow_desc_item[] = {
MK_FLOW_ITEM(L2TPV2, sizeof(struct rte_flow_item_l2tpv2)),
MK_FLOW_ITEM(PPP, sizeof(struct rte_flow_item_ppp)),
MK_FLOW_ITEM(METER_COLOR, sizeof(struct rte_flow_item_meter_color)),
+ MK_FLOW_ITEM_FN(IPV6_ROUTING_EXT, sizeof(struct rte_flow_item_ipv6_routing_ext),
+ rte_flow_item_ipv6_routing_ext_conv),
};
/** Generate flow_action[] entry. */
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index b60987db4b..0120d3e7d2 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -624,6 +624,13 @@ enum rte_flow_item_type {
* See struct rte_flow_item_meter_color.
*/
RTE_FLOW_ITEM_TYPE_METER_COLOR,
+
+ /**
+ * Matches the presence of IPv6 routing extension header.
+ *
+ * See struct rte_flow_item_ipv6_routing_ext.
+ */
+ RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT,
};
/**
@@ -873,6 +880,18 @@ struct rte_flow_item_ipv6 {
uint32_t reserved:23;
};
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT.
+ *
+ * Matches an IPv6 routing extension header.
+ */
+struct rte_flow_item_ipv6_routing_ext {
+ struct rte_ipv6_routing_ext hdr;
+};
+
/** Default mask for RTE_FLOW_ITEM_TYPE_IPV6. */
#ifndef __cplusplus
static const struct rte_flow_item_ipv6 rte_flow_item_ipv6_mask = {
diff --git a/lib/net/rte_ip.h b/lib/net/rte_ip.h
index 9c8e8206f0..158a2f83ce 100644
--- a/lib/net/rte_ip.h
+++ b/lib/net/rte_ip.h
@@ -539,6 +539,27 @@ struct rte_ipv6_hdr {
uint8_t dst_addr[16]; /**< IP address of destination host(s). */
} __rte_packed;
+/**
+ * IPv6 Routing Extension Header
+ */
+struct rte_ipv6_routing_ext {
+ uint8_t next_hdr; /**< Protocol, next header. */
+ uint8_t hdr_len; /**< Header length. */
+ uint8_t type; /**< Extension header type. */
+ uint8_t segments_left; /**< Valid segments number. */
+ __extension__
+ union {
+ uint32_t flags;
+ struct {
+ uint8_t last_entry; /**< The last_entry field of SRH */
+ uint8_t flag; /**< Packet flag. */
+ uint16_t tag; /**< Packet tag. */
+ };
+ };
+ __extension__
+ uint32_t segments[0]; /**< Each hop IPv6 address. */
+} __rte_packed;
+
/* IPv6 vtc_flow: IPv / TC / flow_label */
#define RTE_IPV6_HDR_FL_SHIFT 0
#define RTE_IPV6_HDR_TC_SHIFT 20
--
2.27.0
^ permalink raw reply [relevance 3%]
* Re: [PATCH V4 0/5] app/testpmd: support mulitple process attach and detach port
2023-01-18 14:12 0% ` Thomas Monjalon
@ 2023-01-19 10:31 0% ` lihuisong (C)
2023-01-19 14:35 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: lihuisong (C) @ 2023-01-19 10:31 UTC (permalink / raw)
To: Thomas Monjalon, Ferruh Yigit
Cc: dev, andrew.rybchenko, liudongdong3, huangdaode, fengchengwen
在 2023/1/18 22:12, Thomas Monjalon 写道:
> 11/01/2023 11:46, Ferruh Yigit:
>> On 1/11/2023 10:27 AM, Ferruh Yigit wrote:
>>> On 1/11/2023 12:53 AM, lihuisong (C) wrote:
>>>> 在 2023/1/11 0:51, Ferruh Yigit 写道:
>>>>> Hi Huisong,
>>>>>
>>>>> I haven't checked the patch in detail yet, but I can see it gives some
>>>>> ABI compatibility warnings, is this expected:
>>>> This is to be expected. Because we insert a device state,
>>>> RTE_ETH_DEV_ALLOCATED,
>>>> before RTE_ETH_DEV_ATTACHED for resolving the issue patch 2/5 mentioned.
>>>> We may have to announce it. What do you think?
>>> If there is an actual ABI break, it can't go in this release, need to
>>> wait LTS release and yes needs deprecation notice in advance.
>>>
>>> But not all enum value change warnings are real break, need to
>>> investigate all warnings one by one.
>>> Need to investigate if old application & new dpdk library may cause any
>>> unexpected behavior for application.
>>>
>> OR, appending new enum item, `RTE_ETH_DEV_ALLOCATED`, to the end of the
>> enum solves the issue, although logically it won't look nice.
>> Perhaps order can be fixed in next LTS, to have more logical order, but
>> not quite sure if order worth the disturbance may cause in application.
> It is a state with a logical order, so it would be nice to be able to do
> if (state > RTE_ETH_DEV_ALLOCATED)
> but given there is RTE_ETH_DEV_REMOVED later in the enum, not sure it is useful.
The device state is internel. Applications should not access it
directly, right?
Currently, ethdev layer or PMD use it by enum value instead of the way like
'state > RTE_ETH_DEV_ALLOCATED'.
But, I encapsulated an API, rte_eth_dev_is_used(), for ethdev or PMD to
call.
I'm not sure if it can help to eliminate our concerns.
>
>
> .
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC] ethdev: improve link speed to string
@ 2023-01-19 11:41 3% ` Ferruh Yigit
2023-01-19 16:45 0% ` Stephen Hemminger
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2023-01-19 11:41 UTC (permalink / raw)
To: Min Hu (Connor), Andrew Rybchenko; +Cc: thomas, dev
On 9/17/2021 1:43 AM, Min Hu (Connor) wrote:
> 在 2021/9/16 16:21, Andrew Rybchenko 写道:
>> On 9/16/21 11:16 AM, Min Hu (Connor) wrote:
>>> Hi, Andrew,
>>>
>>> 在 2021/9/16 14:22, Andrew Rybchenko 写道:
>>>> On 9/16/21 5:56 AM, Min Hu (Connor) wrote:
>>>>> Currently, link speed to string only supports specific speeds, like
>>>>> 10M,
>>>>> 100M, 1G etc.
>>>>>
>>>>> This patch expands support for any link speed which is over 1M and one
>>>>> decimal place will kept for display at most.
>>>>>
>>>>> Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
>>>>> ---
>>>>> lib/ethdev/rte_ethdev.c | 34 +++++++++++++++++-----------------
>>>>> 1 file changed, 17 insertions(+), 17 deletions(-)
>>>>>
>>>>> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
>>>>> index daf5ca9242..1d3b960305 100644
>>>>> --- a/lib/ethdev/rte_ethdev.c
>>>>> +++ b/lib/ethdev/rte_ethdev.c
>>>>> @@ -2750,24 +2750,24 @@ rte_eth_link_get_nowait(uint16_t port_id,
>>>>> struct rte_eth_link *eth_link)
>>>>> const char *
>>>>> rte_eth_link_speed_to_str(uint32_t link_speed)
>>>>> {
>>>>> - switch (link_speed) {
>>>>> - case ETH_SPEED_NUM_NONE: return "None";
>>>>> - case ETH_SPEED_NUM_10M: return "10 Mbps";
>>>>> - case ETH_SPEED_NUM_100M: return "100 Mbps";
>>>>> - case ETH_SPEED_NUM_1G: return "1 Gbps";
>>>>> - case ETH_SPEED_NUM_2_5G: return "2.5 Gbps";
>>>>> - case ETH_SPEED_NUM_5G: return "5 Gbps";
>>>>> - case ETH_SPEED_NUM_10G: return "10 Gbps";
>>>>> - case ETH_SPEED_NUM_20G: return "20 Gbps";
>>>>> - case ETH_SPEED_NUM_25G: return "25 Gbps";
>>>>> - case ETH_SPEED_NUM_40G: return "40 Gbps";
>>>>> - case ETH_SPEED_NUM_50G: return "50 Gbps";
>>>>> - case ETH_SPEED_NUM_56G: return "56 Gbps";
>>>>> - case ETH_SPEED_NUM_100G: return "100 Gbps";
>>>>> - case ETH_SPEED_NUM_200G: return "200 Gbps";
>>>>> - case ETH_SPEED_NUM_UNKNOWN: return "Unknown";
>>>>> - default: return "Invalid";
>>>>> +#define SPEED_STRING_LEN 16
>>>>> + static char name[SPEED_STRING_LEN];
>>>>
>>>> NACK
>>>>
>>>> Nothing good will happen if you try to use the function to
>>>> print two different link speeds in one log message.
>>> You are right.
>>> And use malloc for "name" will result in memory leakage, which is also
>>> not a good option.
>>>
>>> BTW, do you think if we need to modify the function
>>> "rte_eth_link_speed_to_str"?
>>
>> IMHO it would be more pain than gain in this case.
>>
>> .
>>
> Agree with you. Thanks Andrew
>
It can be option to update the API as following in next ABI break release:
const char *
rte_eth_link_speed_to_str(uint32_t link_speed, char *buf, size_t buf_size);
For this a deprecation notice needs to be sent and approved, not sure
though if it worth.
Meanwhile, what do you think to update string 'Invalid' to something
like 'Irregular' or 'Erratic', does this help to convey the right message?
^ permalink raw reply [relevance 3%]
* Re: [PATCH V4 0/5] app/testpmd: support mulitple process attach and detach port
2023-01-19 10:31 0% ` lihuisong (C)
@ 2023-01-19 14:35 0% ` Thomas Monjalon
2023-01-28 1:39 0% ` lihuisong (C)
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2023-01-19 14:35 UTC (permalink / raw)
To: Ferruh Yigit, lihuisong (C)
Cc: dev, andrew.rybchenko, liudongdong3, huangdaode, fengchengwen
19/01/2023 11:31, lihuisong (C):
> 在 2023/1/18 22:12, Thomas Monjalon 写道:
> > 11/01/2023 11:46, Ferruh Yigit:
> >> On 1/11/2023 10:27 AM, Ferruh Yigit wrote:
> >>> On 1/11/2023 12:53 AM, lihuisong (C) wrote:
> >>>> 在 2023/1/11 0:51, Ferruh Yigit 写道:
> >>>>> Hi Huisong,
> >>>>>
> >>>>> I haven't checked the patch in detail yet, but I can see it gives some
> >>>>> ABI compatibility warnings, is this expected:
> >>>> This is to be expected. Because we insert a device state,
> >>>> RTE_ETH_DEV_ALLOCATED,
> >>>> before RTE_ETH_DEV_ATTACHED for resolving the issue patch 2/5 mentioned.
> >>>> We may have to announce it. What do you think?
> >>> If there is an actual ABI break, it can't go in this release, need to
> >>> wait LTS release and yes needs deprecation notice in advance.
> >>>
> >>> But not all enum value change warnings are real break, need to
> >>> investigate all warnings one by one.
> >>> Need to investigate if old application & new dpdk library may cause any
> >>> unexpected behavior for application.
> >>>
> >> OR, appending new enum item, `RTE_ETH_DEV_ALLOCATED`, to the end of the
> >> enum solves the issue, although logically it won't look nice.
> >> Perhaps order can be fixed in next LTS, to have more logical order, but
> >> not quite sure if order worth the disturbance may cause in application.
> > It is a state with a logical order, so it would be nice to be able to do
> > if (state > RTE_ETH_DEV_ALLOCATED)
> > but given there is RTE_ETH_DEV_REMOVED later in the enum, not sure it is useful.
>
> The device state is internel. Applications should not access it
> directly, right?
Right
> Currently, ethdev layer or PMD use it by enum value instead of the way like
> 'state > RTE_ETH_DEV_ALLOCATED'.
Right
> But, I encapsulated an API, rte_eth_dev_is_used(), for ethdev or PMD to
> call.
> I'm not sure if it can help to eliminate our concerns.
Yes I think it's OK.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC] ethdev: improve link speed to string
2023-01-19 11:41 3% ` Ferruh Yigit
@ 2023-01-19 16:45 0% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2023-01-19 16:45 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: Min Hu (Connor), Andrew Rybchenko, thomas, dev
On Thu, 19 Jan 2023 11:41:12 +0000
Ferruh Yigit <ferruh.yigit@amd.com> wrote:
> >>>> Nothing good will happen if you try to use the function to
> >>>> print two different link speeds in one log message.
> >>> You are right.
> >>> And use malloc for "name" will result in memory leakage, which is also
> >>> not a good option.
> >>>
> >>> BTW, do you think if we need to modify the function
> >>> "rte_eth_link_speed_to_str"?
> >>
> >> IMHO it would be more pain than gain in this case.
> >>
> >> .
> >>
> > Agree with you. Thanks Andrew
> >
>
> It can be option to update the API as following in next ABI break release:
>
> const char *
> rte_eth_link_speed_to_str(uint32_t link_speed, char *buf, size_t buf_size);
>
> For this a deprecation notice needs to be sent and approved, not sure
> though if it worth.
>
>
> Meanwhile, what do you think to update string 'Invalid' to something
> like 'Irregular' or 'Erratic', does this help to convey the right message?
API versioning is possible here.
^ permalink raw reply [relevance 0%]
* RE: [PATCH 1/3] eventdev/eth_rx: add params set/get APIs
2023-01-18 10:22 4% ` Jerin Jacob
@ 2023-01-20 8:58 0% ` Naga Harish K, S V
2023-01-20 9:32 0% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Naga Harish K, S V @ 2023-01-20 8:58 UTC (permalink / raw)
To: Jerin Jacob; +Cc: jerinj, Gujjar, Abhinandan S, dev, Jayatheerthan, Jay
Hi Jerin,
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Wednesday, January 18, 2023 3:52 PM
> To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> Cc: jerinj@marvell.com; Gujjar, Abhinandan S
> <abhinandan.gujjar@intel.com>; dev@dpdk.org; Jayatheerthan, Jay
> <jay.jayatheerthan@intel.com>
> Subject: Re: [PATCH 1/3] eventdev/eth_rx: add params set/get APIs
>
> On Sat, Jan 7, 2023 at 9:49 PM Naga Harish K S V
> <s.v.naga.harish.k@intel.com> wrote:
> >
> > The adapter configuration parameters defined in the ``struct
> > rte_event_eth_rx_adapter_config_params`` can be configured and
> > retrieved using ``rte_event_eth_rx_adapter_set_params`` and
> > ``rte_event_eth_tx_adapter_get_params`` respectively.
> >
> > Signed-off-by: Naga Harish K S V <s.v.naga.harish.k@intel.com>
> > ---
> >
> > +/**
> > + * Adapter configuration parameters
> > + */
> > +struct rte_event_eth_rx_adapter_runtime_params {
> > + uint32_t max_nb_rx;
> > + /**< The adapter can return early if it has processed at least
> > + * max_nb_rx mbufs. This isn't treated as a requirement; batching may
> > + * cause the adapter to process more than max_nb_rx mbufs.
>
> This parameter as specific to SW only driver. So future something added from
> HW only driver item then it won't work for SW driver. So we need capability
> per adapter.
>
> So, I would suggest following theme across _all_ adapters.
>
> 1) Introduce RTE_EVENT_ETH_RX_ADAPTER_CAP_RUNTIME_XYZ and
> associate each parameter(the one we think, it is not common for all
> adapters)
The parameters that are exposed in the patch are all existing parameters and they are made
runtime configurable for SW implementation. I think, there are no such parameters existing today for
HW driver implementation. Hence it may be better to introduce these flags when the HW driver
Implementation requires runtime configurable parameters.
> 2) Add some reserved fields in rte_event_eth_rx_adapter_runtime_params
> so that we don't break ABI in future
Agreed.
> 3) Add rte_event_eth_rx_adapter_runtime_params_init() function just
> make structure fill with default to avoid ABI break
> 4) Add rte_event_eth_rx_adapter_runtime_params_info_get(). Lets
> capability flags and other items can be return via this
These two items(3,4) can be taken as and when item "1" above is implemented.
> 5) Change rte_event_eth_rx_adapter_set_params as
> rte_event_eth_rx_adapter_runtime_set() or
> rte_event_eth_rx_adapter_runtime_params_set() to make it runtime
> explicit
Agreed
> 6) Change rte_event_eth_rx_adapter_get_params as
> rte_event_eth_rx_adapter_runtime_get() or
> rte_event_eth_rx_adapter_runtime_params_get() to make it runtime
> explicit
Agreed
^ permalink raw reply [relevance 0%]
* Re: [PATCH v2 1/8] ethdev: add IPv6 routing extension header definition
2023-01-19 3:11 3% ` [PATCH v2 1/8] ethdev: add IPv6 routing extension header definition Rongwei Liu
@ 2023-01-20 9:20 0% ` Andrew Rybchenko
2023-01-30 3:46 0% ` Rongwei Liu
0 siblings, 2 replies; 200+ results
From: Andrew Rybchenko @ 2023-01-20 9:20 UTC (permalink / raw)
To: Rongwei Liu, matan, viacheslavo, orika, thomas, Aman Singh,
Yuying Zhang, Ferruh Yigit, Olivier Matz
Cc: dev, rasland
On 1/19/23 06:11, Rongwei Liu wrote:
> Add IPv6 routing extension header definition and no
> TLV support for now.
>
> At rte_flow layer, there are new items defined for matching
> type/nexthdr/segments_left field.
>
> Add command line support for IPv6 routing extension header
> matching: type/nexthdr/segment_list.
>
> Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
> Acked-by: Ori Kam <orika@nvidia.com>
[snip]
> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> index 3e6242803d..ae99036be0 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -1544,6 +1544,15 @@ Matches Color Marker set by a Meter.
>
> - ``color``: Metering color marker.
>
> +Item: ``IPV6_ROUTING_EXT``
> +^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +Matches ipv6 routing extension header.
ipv6 -> IPv6
> +
> +- ``next_hdr``: Next layer header type.
> +- ``type``: IPv6 routing extension header type.
> +- ``segments_left``: How many IPv6 destination addresses carries on
Why are only 3 fields mentioned above?
> +
> Actions
> ~~~~~~~
>
> diff --git a/doc/guides/rel_notes/release_23_03.rst b/doc/guides/rel_notes/release_23_03.rst
> index b8c5b68d6c..2a794d598e 100644
> --- a/doc/guides/rel_notes/release_23_03.rst
> +++ b/doc/guides/rel_notes/release_23_03.rst
> @@ -55,6 +55,11 @@ New Features
> Also, make sure to start the actual text at the margin.
> =======================================================
>
> +* **Added rte_flow support for matching IPv6 routing extension header fields.**
> +
> + Added ``ipv6_routing_ext`` items in rte_flow to match IPv6 routing extension
> + header
Missing full stop above.
> +
>
> Removed Items
> -------------
> @@ -84,6 +89,11 @@ API Changes
> Also, make sure to start the actual text at the margin.
> =======================================================
>
> +* ethdev: added a new structure:
> +
> + - IPv6 routing extension header ``rte_flow_item_ipv6_routing_ext`` and
> + ``rte_ipv6_routing_ext``
> +
If I'm not mistaken, additions should not be here. It is not an
API change.
>
> ABI Changes
> -----------
> diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
> index 7d0c24366c..4074b475c8 100644
> --- a/lib/ethdev/rte_flow.c
> +++ b/lib/ethdev/rte_flow.c
> @@ -76,6 +76,20 @@ rte_flow_item_flex_conv(void *buf, const void *data)
> return src->length;
> }
>
> +static size_t
> +rte_flow_item_ipv6_routing_ext_conv(void *buf, const void *data)
> +{
> + struct rte_flow_item_ipv6_routing_ext *dst = buf;
> + const struct rte_flow_item_ipv6_routing_ext *src = data;
> + size_t len;
> +
> + len = src->hdr.hdr_len ? src->hdr.hdr_len << 3 : src->hdr.segments_left << 4;
Compare hdr_len vs 0 explicitly.
Also I'd add parenthesis around ternary operator
values to make it simpler to understand.
> + if (buf)
Please, compare vs NULL explicitly. May be 'dst' would be
better here?
> + rte_memcpy((void *)((uintptr_t)(dst->hdr.segments)),
> + src->hdr.segments, len);
> + return len;
> +}
> +
> /** Generate flow_item[] entry. */
> #define MK_FLOW_ITEM(t, s) \
> [RTE_FLOW_ITEM_TYPE_ ## t] = { \
> @@ -157,6 +171,8 @@ static const struct rte_flow_desc_data rte_flow_desc_item[] = {
> MK_FLOW_ITEM(L2TPV2, sizeof(struct rte_flow_item_l2tpv2)),
> MK_FLOW_ITEM(PPP, sizeof(struct rte_flow_item_ppp)),
> MK_FLOW_ITEM(METER_COLOR, sizeof(struct rte_flow_item_meter_color)),
> + MK_FLOW_ITEM_FN(IPV6_ROUTING_EXT, sizeof(struct rte_flow_item_ipv6_routing_ext),
> + rte_flow_item_ipv6_routing_ext_conv),
> };
>
> /** Generate flow_action[] entry. */
> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
> index b60987db4b..0120d3e7d2 100644
> --- a/lib/ethdev/rte_flow.h
> +++ b/lib/ethdev/rte_flow.h
> @@ -624,6 +624,13 @@ enum rte_flow_item_type {
> * See struct rte_flow_item_meter_color.
> */
> RTE_FLOW_ITEM_TYPE_METER_COLOR,
> +
> + /**
> + * Matches the presence of IPv6 routing extension header.
> + *
> + * See struct rte_flow_item_ipv6_routing_ext.
@see
> + */
> + RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT,
> };
>
> /**
> @@ -873,6 +880,18 @@ struct rte_flow_item_ipv6 {
> uint32_t reserved:23;
> };
>
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this structure may change without prior notice
> + *
> + * RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT.
> + *
> + * Matches an IPv6 routing extension header.
> + */
> +struct rte_flow_item_ipv6_routing_ext {
> + struct rte_ipv6_routing_ext hdr;
> +};
> +
What about default mask?
> /** Default mask for RTE_FLOW_ITEM_TYPE_IPV6. */
> #ifndef __cplusplus
> static const struct rte_flow_item_ipv6 rte_flow_item_ipv6_mask = {
> diff --git a/lib/net/rte_ip.h b/lib/net/rte_ip.h
> index 9c8e8206f0..158a2f83ce 100644
> --- a/lib/net/rte_ip.h
> +++ b/lib/net/rte_ip.h
> @@ -539,6 +539,27 @@ struct rte_ipv6_hdr {
> uint8_t dst_addr[16]; /**< IP address of destination host(s). */
> } __rte_packed;
>
> +/**
> + * IPv6 Routing Extension Header
> + */
> +struct rte_ipv6_routing_ext {
> + uint8_t next_hdr; /**< Protocol, next header. */
> + uint8_t hdr_len; /**< Header length. */
> + uint8_t type; /**< Extension header type. */
> + uint8_t segments_left; /**< Valid segments number. */
> + __extension__
> + union {
> + uint32_t flags;
rte_be32_t ?
> + struct {
> + uint8_t last_entry; /**< The last_entry field of SRH */
> + uint8_t flag; /**< Packet flag. */
> + uint16_t tag; /**< Packet tag. */
rte_be16_t
> + };
> + };
> + __extension__
> + uint32_t segments[0]; /**< Each hop IPv6 address. */
rte_be32_t
> +} __rte_packed;
> +
> /* IPv6 vtc_flow: IPv / TC / flow_label */
> #define RTE_IPV6_HDR_FL_SHIFT 0
> #define RTE_IPV6_HDR_TC_SHIFT 20
^ permalink raw reply [relevance 0%]
* Re: [PATCH 1/3] eventdev/eth_rx: add params set/get APIs
2023-01-20 8:58 0% ` Naga Harish K, S V
@ 2023-01-20 9:32 0% ` Jerin Jacob
2023-01-20 10:33 0% ` Naga Harish K, S V
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2023-01-20 9:32 UTC (permalink / raw)
To: Naga Harish K, S V; +Cc: jerinj, Gujjar, Abhinandan S, dev, Jayatheerthan, Jay
On Fri, Jan 20, 2023 at 2:28 PM Naga Harish K, S V
<s.v.naga.harish.k@intel.com> wrote:
>
> Hi Jerin,
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Wednesday, January 18, 2023 3:52 PM
> > To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> > Cc: jerinj@marvell.com; Gujjar, Abhinandan S
> > <abhinandan.gujjar@intel.com>; dev@dpdk.org; Jayatheerthan, Jay
> > <jay.jayatheerthan@intel.com>
> > Subject: Re: [PATCH 1/3] eventdev/eth_rx: add params set/get APIs
> >
> > On Sat, Jan 7, 2023 at 9:49 PM Naga Harish K S V
> > <s.v.naga.harish.k@intel.com> wrote:
> > >
> > > The adapter configuration parameters defined in the ``struct
> > > rte_event_eth_rx_adapter_config_params`` can be configured and
> > > retrieved using ``rte_event_eth_rx_adapter_set_params`` and
> > > ``rte_event_eth_tx_adapter_get_params`` respectively.
> > >
> > > Signed-off-by: Naga Harish K S V <s.v.naga.harish.k@intel.com>
> > > ---
> > >
> > > +/**
> > > + * Adapter configuration parameters
> > > + */
> > > +struct rte_event_eth_rx_adapter_runtime_params {
> > > + uint32_t max_nb_rx;
> > > + /**< The adapter can return early if it has processed at least
> > > + * max_nb_rx mbufs. This isn't treated as a requirement; batching may
> > > + * cause the adapter to process more than max_nb_rx mbufs.
> >
> > This parameter as specific to SW only driver. So future something added from
> > HW only driver item then it won't work for SW driver. So we need capability
> > per adapter.
> >
> > So, I would suggest following theme across _all_ adapters.
> >
> > 1) Introduce RTE_EVENT_ETH_RX_ADAPTER_CAP_RUNTIME_XYZ and
> > associate each parameter(the one we think, it is not common for all
> > adapters)
>
> The parameters that are exposed in the patch are all existing parameters and they are made
> runtime configurable for SW implementation. I think, there are no such parameters existing today for
> HW driver implementation. Hence it may be better to introduce these flags when the HW driver
> Implementation requires runtime configurable parameters.
Since current values are not applicable to HW. So we any way need the
capability now to tell this is not
applicable for HW.
>
> > 2) Add some reserved fields in rte_event_eth_rx_adapter_runtime_params
> > so that we don't break ABI in future
>
> Agreed.
>
> > 3) Add rte_event_eth_rx_adapter_runtime_params_init() function just
> > make structure fill with default to avoid ABI break
> > 4) Add rte_event_eth_rx_adapter_runtime_params_info_get(). Lets
> > capability flags and other items can be return via this
>
> These two items(3,4) can be taken as and when item "1" above is implemented.
See above.
>
> > 5) Change rte_event_eth_rx_adapter_set_params as
> > rte_event_eth_rx_adapter_runtime_set() or
> > rte_event_eth_rx_adapter_runtime_params_set() to make it runtime
> > explicit
>
> Agreed
>
> > 6) Change rte_event_eth_rx_adapter_get_params as
> > rte_event_eth_rx_adapter_runtime_get() or
> > rte_event_eth_rx_adapter_runtime_params_get() to make it runtime
> > explicit
>
> Agreed
^ permalink raw reply [relevance 0%]
* RE: [PATCH 1/3] eventdev/eth_rx: add params set/get APIs
2023-01-20 9:32 0% ` Jerin Jacob
@ 2023-01-20 10:33 0% ` Naga Harish K, S V
2023-01-23 9:31 0% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Naga Harish K, S V @ 2023-01-20 10:33 UTC (permalink / raw)
To: Jerin Jacob; +Cc: jerinj, Gujjar, Abhinandan S, dev, Jayatheerthan, Jay
Hi Jerin,
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Friday, January 20, 2023 3:02 PM
> To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> Cc: jerinj@marvell.com; Gujjar, Abhinandan S
> <abhinandan.gujjar@intel.com>; dev@dpdk.org; Jayatheerthan, Jay
> <jay.jayatheerthan@intel.com>
> Subject: Re: [PATCH 1/3] eventdev/eth_rx: add params set/get APIs
>
> On Fri, Jan 20, 2023 at 2:28 PM Naga Harish K, S V
> <s.v.naga.harish.k@intel.com> wrote:
> >
> > Hi Jerin,
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > Sent: Wednesday, January 18, 2023 3:52 PM
> > > To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> > > Cc: jerinj@marvell.com; Gujjar, Abhinandan S
> > > <abhinandan.gujjar@intel.com>; dev@dpdk.org; Jayatheerthan, Jay
> > > <jay.jayatheerthan@intel.com>
> > > Subject: Re: [PATCH 1/3] eventdev/eth_rx: add params set/get APIs
> > >
> > > On Sat, Jan 7, 2023 at 9:49 PM Naga Harish K S V
> > > <s.v.naga.harish.k@intel.com> wrote:
> > > >
> > > > The adapter configuration parameters defined in the ``struct
> > > > rte_event_eth_rx_adapter_config_params`` can be configured and
> > > > retrieved using ``rte_event_eth_rx_adapter_set_params`` and
> > > > ``rte_event_eth_tx_adapter_get_params`` respectively.
> > > >
> > > > Signed-off-by: Naga Harish K S V <s.v.naga.harish.k@intel.com>
> > > > ---
> > > >
> > > > +/**
> > > > + * Adapter configuration parameters */ struct
> > > > +rte_event_eth_rx_adapter_runtime_params {
> > > > + uint32_t max_nb_rx;
> > > > + /**< The adapter can return early if it has processed at least
> > > > + * max_nb_rx mbufs. This isn't treated as a requirement; batching
> may
> > > > + * cause the adapter to process more than max_nb_rx mbufs.
> > >
> > > This parameter as specific to SW only driver. So future something
> > > added from HW only driver item then it won't work for SW driver. So
> > > we need capability per adapter.
> > >
> > > So, I would suggest following theme across _all_ adapters.
> > >
> > > 1) Introduce RTE_EVENT_ETH_RX_ADAPTER_CAP_RUNTIME_XYZ and
> associate
> > > each parameter(the one we think, it is not common for all
> > > adapters)
> >
> > The parameters that are exposed in the patch are all existing
> > parameters and they are made runtime configurable for SW
> > implementation. I think, there are no such parameters existing today
> > for HW driver implementation. Hence it may be better to introduce these
> flags when the HW driver Implementation requires runtime configurable
> parameters.
>
> Since current values are not applicable to HW. So we any way need the
> capability now to tell this is not applicable for HW.
>
Depending on the existing adapter capability flag "RTE_EVENT_ETH_RX_ADAPTER_CAP_INTERNAL_PORT",
the current values can be applied to only SW implementation. In this way, there is no need for
creating new capability flags.
> >
> > > 2) Add some reserved fields in
> > > rte_event_eth_rx_adapter_runtime_params
> > > so that we don't break ABI in future
> >
> > Agreed.
> >
> > > 3) Add rte_event_eth_rx_adapter_runtime_params_init() function just
> > > make structure fill with default to avoid ABI break
> > > 4) Add rte_event_eth_rx_adapter_runtime_params_info_get(). Lets
> > > capability flags and other items can be return via this
> >
> > These two items(3,4) can be taken as and when item "1" above is
> implemented.
>
> See above.
>
> >
> > > 5) Change rte_event_eth_rx_adapter_set_params as
> > > rte_event_eth_rx_adapter_runtime_set() or
> > > rte_event_eth_rx_adapter_runtime_params_set() to make it runtime
> > > explicit
> >
> > Agreed
> >
> > > 6) Change rte_event_eth_rx_adapter_get_params as
> > > rte_event_eth_rx_adapter_runtime_get() or
> > > rte_event_eth_rx_adapter_runtime_params_get() to make it runtime
> > > explicit
> >
> > Agreed
^ permalink raw reply [relevance 0%]
* Re: [PATCH v4 0/3] Split logging functionality out of EAL
@ 2023-01-22 14:56 4% ` David Marchand
2023-01-23 14:24 3% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2023-01-22 14:56 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev, Thomas Monjalon, Dodji Seketeli
Hi Bruce,
On Fri, Jan 20, 2023 at 7:22 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> There is a general desire to reduce the size and scope of EAL. To this
> end, this patchset makes a (very) small step in that direction by taking
> the logging functionality out of EAL and putting it into its own library
> that can be built and maintained separately.
>
> As with the first RFC for this, the main obstacle is the "fnmatch"
> function which is needed by both EAL and the new log function when
> building on windows. While the function cannot stay in EAL - or we would
> have a circular dependency, moving it to a new library or just putting
> it in the log library have the disadvantages that it then "leaks" into
> the public namespace without an rte_prefix, which could cause issues.
> Since only a single function is involved, subsequent versions take a
> different approach to v1, and just moves the offending function to be a
> static function in a header file. This allows use by multiple libs
> without conflicting names or making it public.
>
> The other complication, as explained in v1 RFC was that of multiple
> implementations for different OS's. This is solved here in the same
> way as v1, by including the OS in the name and having meson pick the
> correct file for each build. Since only one file is involved, there
> seemed little need for replicating EAL's separate subdirectories
> per-OS.
There is another complication.
The ABI check is not handling properly the case where symbols are
moved to the new log library (even though the dependency to librte_log
is explicit in librte_eal elf).
For now, I don't have a good way to handle this.
A workaround to pass the check is to suppress those symbols wrt the eal dump:
[suppress_function]
symbol_name_regexp = rte_log
[suppress_function]
symbol_name = rte_openlog_stream
[suppress_function]
symbol_name = rte_vlog
But this is not a good solution because we would be losing checks on
them for the rest of the v23 ABI life.
--
David Marchand
^ permalink raw reply [relevance 4%]
* Minutes of Technical Board Meeting, 2022-09-06
@ 2023-01-23 9:02 4% Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2023-01-23 9:02 UTC (permalink / raw)
To: dev; +Cc: Lincoln Lavoie
We had a in-person Technical Board meeting
at the end of the first day of the summit in Arcachon, France.
Some attendees joined virtually, many were in the room.
This is a very late recap of what was said,
mainly based on notes taken by Lincoln, thanks to him.
1/ Testing
Lincoln provided a summary of the Community Lab and the CI process.
Discussed which "rolling" distribution should be used for testing,
group seemed to lean toward support of Arch Linux,
and dropping support for Fedora Rawhide.
When a container upgrade (likely the rolling) starts causing errors,
the previous container must be kept for regular testing,
but we need to be notified of the failure caused by an upgrade.
A badge could be added to the top of the patchwork page,
to represent the status of the rolling distro,
tested periodically on the DPDK main branch.
Honnappa did an intro about the improvements of DTS.
DTS will move in the main DPDK repository.
A future goal is to require DTS update for new DPDK features submissions.
The scope of DTS is testing on real hardware, compared to unit testing.
2/ Security Process
Last week there were two CVEs fixed in all releases in parallel.
There is a specific mailing list, security-prerelease@dpdk.org,
very low volume, with mails coming a few days in advance of the security releases.
3/ Minimum Versions of Software
Meson
It could be interesting to benefit from latest Meson features.
Python
Minimum version is 3.5, which is no longer included in any stable distro.
DTS seems to be aiming for 3.8 as the minimum version,
which might break on older distros.
4/ ABI/API Change Allowances
We had a long discussion about API allowed to break,
and ABI allowed to break every year for LTS versions.
These breaking changes have an impact on users upgrading or not,
and how LTS branches are used.
We need to take into account any change which has an impact for the users.
^ permalink raw reply [relevance 4%]
* Minutes of Technical Board Meeting, 2022-11-30
@ 2023-01-23 9:03 4% Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2023-01-23 9:03 UTC (permalink / raw)
To: dev
1/ Traces in ethdev API
It has been decided to have traces everywhere.
In datapath or in grey area (not sure how fast it should be),
we must use compile-time enabled trace for performance reason.
2/ Tech writer hiring
Hiring failed so far.
Thomas to ask explanations for recent candidates.
3/ MIT license exception
No progress at this date.
4/ UNH SOW
The accomplishments of 2022 must be categorized to fit with 2022 SOW.
The 2023 plan must be voted in a sheet during the next 2 weeks,
and it could be validated during the next meeting.
5/ Release 22.11.1 with hotfix
There is an issue for comparing ABI with 22.11.0.
We need review and testing of the hotfix for making 22.11.1.
The new tag will be the reference for ABI checks.
^ permalink raw reply [relevance 4%]
* Re: [PATCH 1/3] eventdev/eth_rx: add params set/get APIs
2023-01-20 10:33 0% ` Naga Harish K, S V
@ 2023-01-23 9:31 0% ` Jerin Jacob
2023-01-23 18:07 0% ` Naga Harish K, S V
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2023-01-23 9:31 UTC (permalink / raw)
To: Naga Harish K, S V; +Cc: jerinj, Gujjar, Abhinandan S, dev, Jayatheerthan, Jay
On Fri, Jan 20, 2023 at 4:03 PM Naga Harish K, S V
<s.v.naga.harish.k@intel.com> wrote:
>
> Hi Jerin,
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Friday, January 20, 2023 3:02 PM
> > To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> > Cc: jerinj@marvell.com; Gujjar, Abhinandan S
> > <abhinandan.gujjar@intel.com>; dev@dpdk.org; Jayatheerthan, Jay
> > <jay.jayatheerthan@intel.com>
> > Subject: Re: [PATCH 1/3] eventdev/eth_rx: add params set/get APIs
> >
> > On Fri, Jan 20, 2023 at 2:28 PM Naga Harish K, S V
> > <s.v.naga.harish.k@intel.com> wrote:
> > >
> > > Hi Jerin,
> > >
> > > > -----Original Message-----
> > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > Sent: Wednesday, January 18, 2023 3:52 PM
> > > > To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> > > > Cc: jerinj@marvell.com; Gujjar, Abhinandan S
> > > > <abhinandan.gujjar@intel.com>; dev@dpdk.org; Jayatheerthan, Jay
> > > > <jay.jayatheerthan@intel.com>
> > > > Subject: Re: [PATCH 1/3] eventdev/eth_rx: add params set/get APIs
> > > >
> > > > On Sat, Jan 7, 2023 at 9:49 PM Naga Harish K S V
> > > > <s.v.naga.harish.k@intel.com> wrote:
> > > > >
> > > > > The adapter configuration parameters defined in the ``struct
> > > > > rte_event_eth_rx_adapter_config_params`` can be configured and
> > > > > retrieved using ``rte_event_eth_rx_adapter_set_params`` and
> > > > > ``rte_event_eth_tx_adapter_get_params`` respectively.
> > > > >
> > > > > Signed-off-by: Naga Harish K S V <s.v.naga.harish.k@intel.com>
> > > > > ---
> > > > >
> > > > > +/**
> > > > > + * Adapter configuration parameters */ struct
> > > > > +rte_event_eth_rx_adapter_runtime_params {
> > > > > + uint32_t max_nb_rx;
> > > > > + /**< The adapter can return early if it has processed at least
> > > > > + * max_nb_rx mbufs. This isn't treated as a requirement; batching
> > may
> > > > > + * cause the adapter to process more than max_nb_rx mbufs.
> > > >
> > > > This parameter as specific to SW only driver. So future something
> > > > added from HW only driver item then it won't work for SW driver. So
> > > > we need capability per adapter.
> > > >
> > > > So, I would suggest following theme across _all_ adapters.
> > > >
> > > > 1) Introduce RTE_EVENT_ETH_RX_ADAPTER_CAP_RUNTIME_XYZ and
> > associate
> > > > each parameter(the one we think, it is not common for all
> > > > adapters)
> > >
> > > The parameters that are exposed in the patch are all existing
> > > parameters and they are made runtime configurable for SW
> > > implementation. I think, there are no such parameters existing today
> > > for HW driver implementation. Hence it may be better to introduce these
> > flags when the HW driver Implementation requires runtime configurable
> > parameters.
> >
> > Since current values are not applicable to HW. So we any way need the
> > capability now to tell this is not applicable for HW.
> >
>
> Depending on the existing adapter capability flag "RTE_EVENT_ETH_RX_ADAPTER_CAP_INTERNAL_PORT",
> the current values can be applied to only SW implementation. In this way, there is no need for
> creating new capability flags.
OK. Makes sense. Please send next version with remaining suggestions.
>
> > >
> > > > 2) Add some reserved fields in
> > > > rte_event_eth_rx_adapter_runtime_params
> > > > so that we don't break ABI in future
> > >
> > > Agreed.
> > >
> > > > 3) Add rte_event_eth_rx_adapter_runtime_params_init() function just
> > > > make structure fill with default to avoid ABI break
> > > > 4) Add rte_event_eth_rx_adapter_runtime_params_info_get(). Lets
> > > > capability flags and other items can be return via this
> > >
> > > These two items(3,4) can be taken as and when item "1" above is
> > implemented.
> >
> > See above.
> >
> > >
> > > > 5) Change rte_event_eth_rx_adapter_set_params as
> > > > rte_event_eth_rx_adapter_runtime_set() or
> > > > rte_event_eth_rx_adapter_runtime_params_set() to make it runtime
> > > > explicit
> > >
> > > Agreed
> > >
> > > > 6) Change rte_event_eth_rx_adapter_get_params as
> > > > rte_event_eth_rx_adapter_runtime_get() or
> > > > rte_event_eth_rx_adapter_runtime_params_get() to make it runtime
> > > > explicit
> > >
> > > Agreed
^ permalink raw reply [relevance 0%]
* Re: [PATCH v4 0/3] Split logging functionality out of EAL
2023-01-22 14:56 4% ` David Marchand
@ 2023-01-23 14:24 3% ` Bruce Richardson
2023-01-23 14:31 3% ` David Marchand
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2023-01-23 14:24 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Thomas Monjalon, Dodji Seketeli
On Sun, Jan 22, 2023 at 03:56:12PM +0100, David Marchand wrote:
> Hi Bruce,
>
> On Fri, Jan 20, 2023 at 7:22 PM Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> >
> > There is a general desire to reduce the size and scope of EAL. To this
> > end, this patchset makes a (very) small step in that direction by taking
> > the logging functionality out of EAL and putting it into its own library
> > that can be built and maintained separately.
> >
> > As with the first RFC for this, the main obstacle is the "fnmatch"
> > function which is needed by both EAL and the new log function when
> > building on windows. While the function cannot stay in EAL - or we would
> > have a circular dependency, moving it to a new library or just putting
> > it in the log library have the disadvantages that it then "leaks" into
> > the public namespace without an rte_prefix, which could cause issues.
> > Since only a single function is involved, subsequent versions take a
> > different approach to v1, and just moves the offending function to be a
> > static function in a header file. This allows use by multiple libs
> > without conflicting names or making it public.
> >
> > The other complication, as explained in v1 RFC was that of multiple
> > implementations for different OS's. This is solved here in the same
> > way as v1, by including the OS in the name and having meson pick the
> > correct file for each build. Since only one file is involved, there
> > seemed little need for replicating EAL's separate subdirectories
> > per-OS.
>
> There is another complication.
>
> The ABI check is not handling properly the case where symbols are
> moved to the new log library (even though the dependency to librte_log
> is explicit in librte_eal elf).
> For now, I don't have a good way to handle this.
>
> A workaround to pass the check is to suppress those symbols wrt the eal dump:
> [suppress_function]
> symbol_name_regexp = rte_log
> [suppress_function]
> symbol_name = rte_openlog_stream
> [suppress_function]
> symbol_name = rte_vlog
>
> But this is not a good solution because we would be losing checks on
> them for the rest of the v23 ABI life.
>
Right, I got error messages from the CI job for this too, but I also have
no idea how to work around this. Perhaps we only get to move content
between libraries when we do an ABI bump? Seems a bit restrictive, though.
/Bruce
^ permalink raw reply [relevance 3%]
* Re: [PATCH v4 0/3] Split logging functionality out of EAL
2023-01-23 14:24 3% ` Bruce Richardson
@ 2023-01-23 14:31 3% ` David Marchand
2023-01-23 14:36 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2023-01-23 14:31 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev, Thomas Monjalon, Dodji Seketeli
On Mon, Jan 23, 2023 at 3:24 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> On Sun, Jan 22, 2023 at 03:56:12PM +0100, David Marchand wrote:
> > Hi Bruce,
> >
> > On Fri, Jan 20, 2023 at 7:22 PM Bruce Richardson
> > <bruce.richardson@intel.com> wrote:
> > >
> > > There is a general desire to reduce the size and scope of EAL. To this
> > > end, this patchset makes a (very) small step in that direction by taking
> > > the logging functionality out of EAL and putting it into its own library
> > > that can be built and maintained separately.
> > >
> > > As with the first RFC for this, the main obstacle is the "fnmatch"
> > > function which is needed by both EAL and the new log function when
> > > building on windows. While the function cannot stay in EAL - or we would
> > > have a circular dependency, moving it to a new library or just putting
> > > it in the log library have the disadvantages that it then "leaks" into
> > > the public namespace without an rte_prefix, which could cause issues.
> > > Since only a single function is involved, subsequent versions take a
> > > different approach to v1, and just moves the offending function to be a
> > > static function in a header file. This allows use by multiple libs
> > > without conflicting names or making it public.
> > >
> > > The other complication, as explained in v1 RFC was that of multiple
> > > implementations for different OS's. This is solved here in the same
> > > way as v1, by including the OS in the name and having meson pick the
> > > correct file for each build. Since only one file is involved, there
> > > seemed little need for replicating EAL's separate subdirectories
> > > per-OS.
> >
> > There is another complication.
> >
> > The ABI check is not handling properly the case where symbols are
> > moved to the new log library (even though the dependency to librte_log
> > is explicit in librte_eal elf).
> > For now, I don't have a good way to handle this.
> >
> > A workaround to pass the check is to suppress those symbols wrt the eal dump:
> > [suppress_function]
> > symbol_name_regexp = rte_log
> > [suppress_function]
> > symbol_name = rte_openlog_stream
> > [suppress_function]
> > symbol_name = rte_vlog
> >
> > But this is not a good solution because we would be losing checks on
> > them for the rest of the v23 ABI life.
> >
> Right, I got error messages from the CI job for this too, but I also have
> no idea how to work around this. Perhaps we only get to move content
> between libraries when we do an ABI bump? Seems a bit restrictive, though.
Moving symbols as you did does not seem an ABI breakage.
An application that links to eal would see the dt_needed entry for the
new log library, load it accordingly and gets the right symbols.
--
David Marchand
^ permalink raw reply [relevance 3%]
* Re: [PATCH v4 0/3] Split logging functionality out of EAL
2023-01-23 14:31 3% ` David Marchand
@ 2023-01-23 14:36 0% ` Bruce Richardson
2023-01-23 14:42 0% ` David Marchand
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2023-01-23 14:36 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Thomas Monjalon, Dodji Seketeli
On Mon, Jan 23, 2023 at 03:31:58PM +0100, David Marchand wrote:
> On Mon, Jan 23, 2023 at 3:24 PM Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> >
> > On Sun, Jan 22, 2023 at 03:56:12PM +0100, David Marchand wrote:
> > > Hi Bruce,
> > >
> > > On Fri, Jan 20, 2023 at 7:22 PM Bruce Richardson
> > > <bruce.richardson@intel.com> wrote:
> > > >
> > > > There is a general desire to reduce the size and scope of EAL. To this
> > > > end, this patchset makes a (very) small step in that direction by taking
> > > > the logging functionality out of EAL and putting it into its own library
> > > > that can be built and maintained separately.
> > > >
> > > > As with the first RFC for this, the main obstacle is the "fnmatch"
> > > > function which is needed by both EAL and the new log function when
> > > > building on windows. While the function cannot stay in EAL - or we would
> > > > have a circular dependency, moving it to a new library or just putting
> > > > it in the log library have the disadvantages that it then "leaks" into
> > > > the public namespace without an rte_prefix, which could cause issues.
> > > > Since only a single function is involved, subsequent versions take a
> > > > different approach to v1, and just moves the offending function to be a
> > > > static function in a header file. This allows use by multiple libs
> > > > without conflicting names or making it public.
> > > >
> > > > The other complication, as explained in v1 RFC was that of multiple
> > > > implementations for different OS's. This is solved here in the same
> > > > way as v1, by including the OS in the name and having meson pick the
> > > > correct file for each build. Since only one file is involved, there
> > > > seemed little need for replicating EAL's separate subdirectories
> > > > per-OS.
> > >
> > > There is another complication.
> > >
> > > The ABI check is not handling properly the case where symbols are
> > > moved to the new log library (even though the dependency to librte_log
> > > is explicit in librte_eal elf).
> > > For now, I don't have a good way to handle this.
> > >
> > > A workaround to pass the check is to suppress those symbols wrt the eal dump:
> > > [suppress_function]
> > > symbol_name_regexp = rte_log
> > > [suppress_function]
> > > symbol_name = rte_openlog_stream
> > > [suppress_function]
> > > symbol_name = rte_vlog
> > >
> > > But this is not a good solution because we would be losing checks on
> > > them for the rest of the v23 ABI life.
> > >
> > Right, I got error messages from the CI job for this too, but I also have
> > no idea how to work around this. Perhaps we only get to move content
> > between libraries when we do an ABI bump? Seems a bit restrictive, though.
>
> Moving symbols as you did does not seem an ABI breakage.
> An application that links to eal would see the dt_needed entry for the
> new log library, load it accordingly and gets the right symbols.
>
Yes, I agree. However, I also agree with you that it is risky to lose
symbol checking for the moved symbols if we need to remove them from
analysis. That said, maybe others have some ideas as to how to work around
this, or perhaps we just take the risk of disabling checking.
/Bruce
^ permalink raw reply [relevance 0%]
* Re: [PATCH v4 0/3] Split logging functionality out of EAL
2023-01-23 14:36 0% ` Bruce Richardson
@ 2023-01-23 14:42 0% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2023-01-23 14:42 UTC (permalink / raw)
To: Bruce Richardson, Dodji Seketeli; +Cc: dev, Thomas Monjalon
On Mon, Jan 23, 2023 at 3:37 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> On Mon, Jan 23, 2023 at 03:31:58PM +0100, David Marchand wrote:
> > On Mon, Jan 23, 2023 at 3:24 PM Bruce Richardson
> > <bruce.richardson@intel.com> wrote:
> > >
> > > On Sun, Jan 22, 2023 at 03:56:12PM +0100, David Marchand wrote:
> > > > Hi Bruce,
> > > >
> > > > On Fri, Jan 20, 2023 at 7:22 PM Bruce Richardson
> > > > <bruce.richardson@intel.com> wrote:
> > > > >
> > > > > There is a general desire to reduce the size and scope of EAL. To this
> > > > > end, this patchset makes a (very) small step in that direction by taking
> > > > > the logging functionality out of EAL and putting it into its own library
> > > > > that can be built and maintained separately.
> > > > >
> > > > > As with the first RFC for this, the main obstacle is the "fnmatch"
> > > > > function which is needed by both EAL and the new log function when
> > > > > building on windows. While the function cannot stay in EAL - or we would
> > > > > have a circular dependency, moving it to a new library or just putting
> > > > > it in the log library have the disadvantages that it then "leaks" into
> > > > > the public namespace without an rte_prefix, which could cause issues.
> > > > > Since only a single function is involved, subsequent versions take a
> > > > > different approach to v1, and just moves the offending function to be a
> > > > > static function in a header file. This allows use by multiple libs
> > > > > without conflicting names or making it public.
> > > > >
> > > > > The other complication, as explained in v1 RFC was that of multiple
> > > > > implementations for different OS's. This is solved here in the same
> > > > > way as v1, by including the OS in the name and having meson pick the
> > > > > correct file for each build. Since only one file is involved, there
> > > > > seemed little need for replicating EAL's separate subdirectories
> > > > > per-OS.
> > > >
> > > > There is another complication.
> > > >
> > > > The ABI check is not handling properly the case where symbols are
> > > > moved to the new log library (even though the dependency to librte_log
> > > > is explicit in librte_eal elf).
> > > > For now, I don't have a good way to handle this.
> > > >
> > > > A workaround to pass the check is to suppress those symbols wrt the eal dump:
> > > > [suppress_function]
> > > > symbol_name_regexp = rte_log
> > > > [suppress_function]
> > > > symbol_name = rte_openlog_stream
> > > > [suppress_function]
> > > > symbol_name = rte_vlog
> > > >
> > > > But this is not a good solution because we would be losing checks on
> > > > them for the rest of the v23 ABI life.
> > > >
> > > Right, I got error messages from the CI job for this too, but I also have
> > > no idea how to work around this. Perhaps we only get to move content
> > > between libraries when we do an ABI bump? Seems a bit restrictive, though.
> >
> > Moving symbols as you did does not seem an ABI breakage.
> > An application that links to eal would see the dt_needed entry for the
> > new log library, load it accordingly and gets the right symbols.
> >
> Yes, I agree. However, I also agree with you that it is risky to lose
> symbol checking for the moved symbols if we need to remove them from
> analysis. That said, maybe others have some ideas as to how to work around
> this, or perhaps we just take the risk of disabling checking.
I opened a bz for libabigail.
https://sourceware.org/bugzilla/show_bug.cgi?id=30034
If it is handled fast enough, we may have a solution by the time 23.03
is released and we will remove this workaround for 23.07 development
(no pressure Dodji :-p).
--
David Marchand
^ permalink raw reply [relevance 0%]
* RE: [PATCH 1/3] eventdev/eth_rx: add params set/get APIs
2023-01-23 9:31 0% ` Jerin Jacob
@ 2023-01-23 18:07 0% ` Naga Harish K, S V
0 siblings, 0 replies; 200+ results
From: Naga Harish K, S V @ 2023-01-23 18:07 UTC (permalink / raw)
To: Jerin Jacob; +Cc: jerinj, Gujjar, Abhinandan S, dev, Jayatheerthan, Jay
Hi Jerin,
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Monday, January 23, 2023 3:02 PM
> To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> Cc: jerinj@marvell.com; Gujjar, Abhinandan S
> <abhinandan.gujjar@intel.com>; dev@dpdk.org; Jayatheerthan, Jay
> <jay.jayatheerthan@intel.com>
> Subject: Re: [PATCH 1/3] eventdev/eth_rx: add params set/get APIs
>
> On Fri, Jan 20, 2023 at 4:03 PM Naga Harish K, S V
> <s.v.naga.harish.k@intel.com> wrote:
> >
> > Hi Jerin,
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > Sent: Friday, January 20, 2023 3:02 PM
> > > To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> > > Cc: jerinj@marvell.com; Gujjar, Abhinandan S
> > > <abhinandan.gujjar@intel.com>; dev@dpdk.org; Jayatheerthan, Jay
> > > <jay.jayatheerthan@intel.com>
> > > Subject: Re: [PATCH 1/3] eventdev/eth_rx: add params set/get APIs
> > >
> > > On Fri, Jan 20, 2023 at 2:28 PM Naga Harish K, S V
> > > <s.v.naga.harish.k@intel.com> wrote:
> > > >
> > > > Hi Jerin,
> > > >
> > > > > -----Original Message-----
> > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > Sent: Wednesday, January 18, 2023 3:52 PM
> > > > > To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> > > > > Cc: jerinj@marvell.com; Gujjar, Abhinandan S
> > > > > <abhinandan.gujjar@intel.com>; dev@dpdk.org; Jayatheerthan, Jay
> > > > > <jay.jayatheerthan@intel.com>
> > > > > Subject: Re: [PATCH 1/3] eventdev/eth_rx: add params set/get
> > > > > APIs
> > > > >
> > > > > On Sat, Jan 7, 2023 at 9:49 PM Naga Harish K S V
> > > > > <s.v.naga.harish.k@intel.com> wrote:
> > > > > >
> > > > > > The adapter configuration parameters defined in the ``struct
> > > > > > rte_event_eth_rx_adapter_config_params`` can be configured and
> > > > > > retrieved using ``rte_event_eth_rx_adapter_set_params`` and
> > > > > > ``rte_event_eth_tx_adapter_get_params`` respectively.
> > > > > >
> > > > > > Signed-off-by: Naga Harish K S V <s.v.naga.harish.k@intel.com>
> > > > > > ---
> > > > > >
> > > > > > +/**
> > > > > > + * Adapter configuration parameters */ struct
> > > > > > +rte_event_eth_rx_adapter_runtime_params {
> > > > > > + uint32_t max_nb_rx;
> > > > > > + /**< The adapter can return early if it has processed at least
> > > > > > + * max_nb_rx mbufs. This isn't treated as a
> > > > > > +requirement; batching
> > > may
> > > > > > + * cause the adapter to process more than max_nb_rx mbufs.
> > > > >
> > > > > This parameter as specific to SW only driver. So future
> > > > > something added from HW only driver item then it won't work for
> > > > > SW driver. So we need capability per adapter.
> > > > >
> > > > > So, I would suggest following theme across _all_ adapters.
> > > > >
> > > > > 1) Introduce RTE_EVENT_ETH_RX_ADAPTER_CAP_RUNTIME_XYZ and
> > > associate
> > > > > each parameter(the one we think, it is not common for all
> > > > > adapters)
> > > >
> > > > The parameters that are exposed in the patch are all existing
> > > > parameters and they are made runtime configurable for SW
> > > > implementation. I think, there are no such parameters existing
> > > > today for HW driver implementation. Hence it may be better to
> > > > introduce these
> > > flags when the HW driver Implementation requires runtime
> > > configurable parameters.
> > >
> > > Since current values are not applicable to HW. So we any way need
> > > the capability now to tell this is not applicable for HW.
> > >
> >
> > Depending on the existing adapter capability flag
> > "RTE_EVENT_ETH_RX_ADAPTER_CAP_INTERNAL_PORT",
> > the current values can be applied to only SW implementation. In this
> > way, there is no need for creating new capability flags.
>
> OK. Makes sense. Please send next version with remaining suggestions.
>
V2 version of the patch is posted with remaining suggestions.
> >
> > > >
> > > > > 2) Add some reserved fields in
> > > > > rte_event_eth_rx_adapter_runtime_params
> > > > > so that we don't break ABI in future
> > > >
> > > > Agreed.
> > > >
> > > > > 3) Add rte_event_eth_rx_adapter_runtime_params_init() function
> > > > > just make structure fill with default to avoid ABI break
> > > > > 4) Add rte_event_eth_rx_adapter_runtime_params_info_get(). Lets
> > > > > capability flags and other items can be return via this
> > > >
> > > > These two items(3,4) can be taken as and when item "1" above is
> > > implemented.
> > >
> > > See above.
> > >
> > > >
> > > > > 5) Change rte_event_eth_rx_adapter_set_params as
> > > > > rte_event_eth_rx_adapter_runtime_set() or
> > > > > rte_event_eth_rx_adapter_runtime_params_set() to make it
> runtime
> > > > > explicit
> > > >
> > > > Agreed
> > > >
> > > > > 6) Change rte_event_eth_rx_adapter_get_params as
> > > > > rte_event_eth_rx_adapter_runtime_get() or
> > > > > rte_event_eth_rx_adapter_runtime_params_get() to make it
> > > > > runtime explicit
> > > >
> > > > Agreed
^ permalink raw reply [relevance 0%]
* DPDK Release Status Meeting 2023-01-19
@ 2023-01-24 10:33 3% Mcnamara, John
0 siblings, 0 replies; 200+ results
From: Mcnamara, John @ 2023-01-24 10:33 UTC (permalink / raw)
To: dev; +Cc: thomas, david.marchand
[-- Attachment #1: Type: text/plain, Size: 3381 bytes --]
Release status meeting minutes 2023-01-19
=========================================
Agenda:
* Release Dates
* Subtrees
* Roadmaps
* LTS
* Defects
* Opens
Participants:
* AMD
* ARM
* Debian/Microsoft [No]
* Intel
* Marvell
* Nvidia
* Red Hat
Release Dates
-------------
The following are the proposed current dates for 23.03:
* V1: 25 December 2022
* RC1: 8 February 2023
* RC2: 1 March 2023
* RC3: 8 March 2023
* Release: 20 March 2023
Subtrees
--------
* next-net
* Patches being merged but slowly
* rte_flow has a lot of changes in this release and needs support
* Some reviews ongoing but we are missing reviewer support on this tree.
* next-net-intel
* No update.
* next-net-mlx
* No update.
* next-net-mvl
* Nearly all patches merged. Ready for pull.
* next-eventdev
* Nearly all patches merged. Waiting for some review comments
3 sets of patches from Intel.
* Some CNXK updates
* next-baseband
* New tree from this release.
* Some series merged and some under review.
* next-virtio
* Not many series under review.
* Vhost async and VDPA patches need review.
* next-crypto
* Some patches merged this week.
* Build patches for QAT
* PDCP (Packet Data Convergence Protocol) new library targeted for this release
* Patch for CCP driver from last release
* main
* Thread API from Tyler under review
* ABI check merged
* ML Dev patches need review
* CNI (Container Network Interface) for the AF_XDP driver.
* Will update patch to include explanation/docs.
* Request for Roadmaps
Proposed Schedule for 2023
--------------------------
See also http://core.dpdk.org/roadmap/#dates
23.03
* Proposal deadline (RFC/v1 patches): 25 December 2022
* API freeze (-rc1): 8 February 2023
* PMD features freeze (-rc2): 1 March 2023
* Builtin applications features freeze (-rc3): 8 March 2023
* Release: 20 March 2023
23.07
* Proposal deadline (RFC/v1 patches): 15 April 2023
* API freeze (-rc1): 31 May 2023
* PMD features freeze (-rc2): 21 June 2023
* Builtin applications features freeze (-rc3): 28 June 2023
* Release: 12 July 2023
23.11
* Proposal deadline (RFC/v1 patches): 12 August 2023
* API freeze (-rc1): 29 September 2023
* PMD features freeze (-rc2): 20 October 2023
* Builtin applications features freeze (-rc3): 27 October 2023
* Release: 15 November 2023
Other
-----
* TBA
LTS
---
Next releases will be:
* 22.11.1
* 21.11.4
* 20.11.8
* 19.11.15?
* CVE and critical fixes only.
* Distros
* v20.11 in Debian 11
* Ubuntu 22.04 contains 21.11
Defects
-------
* Bugzilla links, 'Bugs', added for hosted projects
* https://www.dpdk.org/hosted-projects/
Opens
-----
* None
DPDK Release Status Meetings
----------------------------
The DPDK Release Status Meeting is intended for DPDK Committers to discuss the
status of the master tree and sub-trees, and for project managers to track
progress or milestone dates.
The meeting occurs on every Thursday at 9:30 UTC over Jitsi on https://meet.jit.si/DPDK
You don't need an invite to join the meeting but if you want a calendar reminder just
send an email to "John McNamara john.mcnamara@intel.com" for the invite.
[-- Attachment #2: Type: text/html, Size: 18068 bytes --]
^ permalink raw reply [relevance 3%]
* [PATCH v4 1/3] pcapng: comment option support for epb
@ 2023-01-24 11:21 4% ` Amit Prakash Shukla
2023-01-24 11:21 2% ` [PATCH v4 2/3] graph: pcap capture for graph nodes Amit Prakash Shukla
0 siblings, 1 reply; 200+ results
From: Amit Prakash Shukla @ 2023-01-24 11:21 UTC (permalink / raw)
To: Reshma Pattan, Stephen Hemminger; +Cc: dev, jerinj, Amit Prakash Shukla
This change enhances rte_pcapng_copy to have comment in enhanced
packet block.
Signed-off-by: Amit Prakash Shukla <amitprakashs@marvell.com>
---
v2:
- Fixed code style issue
- Fixed CI compilation issue on github-robot
v3:
- Code review suggestion from Stephen
- Fixed potential memory leak
v4:
- Code review suggestion from Jerin
app/test/test_pcapng.c | 4 ++--
doc/guides/rel_notes/release_23_03.rst | 2 ++
lib/pcapng/rte_pcapng.c | 10 +++++++++-
lib/pcapng/rte_pcapng.h | 4 +++-
lib/pdump/rte_pdump.c | 2 +-
5 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/app/test/test_pcapng.c b/app/test/test_pcapng.c
index a7acbdc058..303d3d66f9 100644
--- a/app/test/test_pcapng.c
+++ b/app/test/test_pcapng.c
@@ -139,7 +139,7 @@ test_write_packets(void)
struct rte_mbuf *mc;
mc = rte_pcapng_copy(port_id, 0, orig, mp, pkt_len,
- rte_get_tsc_cycles(), 0);
+ rte_get_tsc_cycles(), 0, NULL);
if (mc == NULL) {
fprintf(stderr, "Cannot copy packet\n");
return -1;
@@ -255,7 +255,7 @@ test_write_over_limit_iov_max(void)
struct rte_mbuf *mc;
mc = rte_pcapng_copy(port_id, 0, orig, mp, pkt_len,
- rte_get_tsc_cycles(), 0);
+ rte_get_tsc_cycles(), 0, NULL);
if (mc == NULL) {
fprintf(stderr, "Cannot copy packet\n");
return -1;
diff --git a/doc/guides/rel_notes/release_23_03.rst b/doc/guides/rel_notes/release_23_03.rst
index c15f6fbb9f..8c360b89e4 100644
--- a/doc/guides/rel_notes/release_23_03.rst
+++ b/doc/guides/rel_notes/release_23_03.rst
@@ -98,6 +98,8 @@ API Changes
Also, make sure to start the actual text at the margin.
=======================================================
+* Experimental function ``rte_pcapng_copy`` was updated to support comment
+ section in enhanced packet block in pcapng library.
ABI Changes
-----------
diff --git a/lib/pcapng/rte_pcapng.c b/lib/pcapng/rte_pcapng.c
index 80d08e1a3b..acb31a9d93 100644
--- a/lib/pcapng/rte_pcapng.c
+++ b/lib/pcapng/rte_pcapng.c
@@ -450,7 +450,8 @@ rte_pcapng_copy(uint16_t port_id, uint32_t queue,
const struct rte_mbuf *md,
struct rte_mempool *mp,
uint32_t length, uint64_t cycles,
- enum rte_pcapng_direction direction)
+ enum rte_pcapng_direction direction,
+ const char *comment)
{
struct pcapng_enhance_packet_block *epb;
uint32_t orig_len, data_len, padding, flags;
@@ -511,6 +512,9 @@ rte_pcapng_copy(uint16_t port_id, uint32_t queue,
if (rss_hash)
optlen += pcapng_optlen(sizeof(uint8_t) + sizeof(uint32_t));
+ if (comment)
+ optlen += pcapng_optlen(strlen(comment));
+
/* reserve trailing options and block length */
opt = (struct pcapng_option *)
rte_pktmbuf_append(mc, optlen + sizeof(uint32_t));
@@ -548,6 +552,10 @@ rte_pcapng_copy(uint16_t port_id, uint32_t queue,
&hash_opt, sizeof(hash_opt));
}
+ if (comment)
+ opt = pcapng_add_option(opt, PCAPNG_OPT_COMMENT, comment,
+ strlen(comment));
+
/* Note: END_OPT necessary here. Wireshark doesn't do it. */
/* Add PCAPNG packet header */
diff --git a/lib/pcapng/rte_pcapng.h b/lib/pcapng/rte_pcapng.h
index 7d2697c647..6d286cda41 100644
--- a/lib/pcapng/rte_pcapng.h
+++ b/lib/pcapng/rte_pcapng.h
@@ -100,6 +100,8 @@ enum rte_pcapng_direction {
* The timestamp in TSC cycles.
* @param direction
* The direction of the packer: receive, transmit or unknown.
+ * @param comment
+ * Packet comment.
*
* @return
* - The pointer to the new mbuf formatted for pcapng_write
@@ -111,7 +113,7 @@ struct rte_mbuf *
rte_pcapng_copy(uint16_t port_id, uint32_t queue,
const struct rte_mbuf *m, struct rte_mempool *mp,
uint32_t length, uint64_t timestamp,
- enum rte_pcapng_direction direction);
+ enum rte_pcapng_direction direction, const char *comment);
/**
diff --git a/lib/pdump/rte_pdump.c b/lib/pdump/rte_pdump.c
index a81544cb57..9bc4bab4f2 100644
--- a/lib/pdump/rte_pdump.c
+++ b/lib/pdump/rte_pdump.c
@@ -122,7 +122,7 @@ pdump_copy(uint16_t port_id, uint16_t queue,
if (cbs->ver == V2)
p = rte_pcapng_copy(port_id, queue,
pkts[i], mp, cbs->snaplen,
- ts, direction);
+ ts, direction, NULL);
else
p = rte_pktmbuf_copy(pkts[i], mp, 0, cbs->snaplen);
--
2.25.1
^ permalink raw reply [relevance 4%]
* [PATCH v4 2/3] graph: pcap capture for graph nodes
2023-01-24 11:21 4% ` [PATCH v4 " Amit Prakash Shukla
@ 2023-01-24 11:21 2% ` Amit Prakash Shukla
0 siblings, 0 replies; 200+ results
From: Amit Prakash Shukla @ 2023-01-24 11:21 UTC (permalink / raw)
To: Jerin Jacob, Kiran Kumar K, Nithin Dabilpuram, Anatoly Burakov
Cc: dev, Amit Prakash Shukla
Implementation adds support to capture packets at each node with
packet metadata and node name.
Signed-off-by: Amit Prakash Shukla <amitprakashs@marvell.com>
---
v2:
- Fixed code style issue
- Fixed CI compilation issue on github-robot
v3:
- Code review suggestion from Stephen
- Fixed potential memory leak
v4:
- Code review suggestion from Jerin
app/test/test_graph_perf.c | 2 +-
doc/guides/rel_notes/release_23_03.rst | 7 +
lib/graph/graph.c | 17 +-
lib/graph/graph_pcap.c | 217 +++++++++++++++++++++++++
lib/graph/graph_pcap_private.h | 124 ++++++++++++++
lib/graph/graph_populate.c | 12 +-
lib/graph/graph_private.h | 5 +
lib/graph/meson.build | 3 +-
lib/graph/rte_graph.h | 5 +
lib/graph/rte_graph_worker.h | 9 +
10 files changed, 397 insertions(+), 4 deletions(-)
create mode 100644 lib/graph/graph_pcap.c
create mode 100644 lib/graph/graph_pcap_private.h
diff --git a/app/test/test_graph_perf.c b/app/test/test_graph_perf.c
index 1d065438a6..c5b463f700 100644
--- a/app/test/test_graph_perf.c
+++ b/app/test/test_graph_perf.c
@@ -324,7 +324,7 @@ graph_init(const char *gname, uint8_t nb_srcs, uint8_t nb_sinks,
char nname[RTE_NODE_NAMESIZE / 2];
struct test_node_data *node_data;
char *ename[nodes_per_stage];
- struct rte_graph_param gconf;
+ struct rte_graph_param gconf = {0};
const struct rte_memzone *mz;
uint8_t total_percent = 0;
rte_node_t *src_nodes;
diff --git a/doc/guides/rel_notes/release_23_03.rst b/doc/guides/rel_notes/release_23_03.rst
index 8c360b89e4..9ba392fb58 100644
--- a/doc/guides/rel_notes/release_23_03.rst
+++ b/doc/guides/rel_notes/release_23_03.rst
@@ -69,6 +69,10 @@ New Features
``rte_event_dev_config::nb_single_link_event_port_queues`` parameter
required for eth_rx, eth_tx, crypto and timer eventdev adapters.
+* **Added pcap trace support in graph library.**
+
+ * Added support to capture packets at each graph node with packet metadata and
+ node name.
Removed Items
-------------
@@ -101,6 +105,9 @@ API Changes
* Experimental function ``rte_pcapng_copy`` was updated to support comment
section in enhanced packet block in pcapng library.
+* Experimental structures ``struct rte_graph_param``, ``struct rte_graph`` and
+ ``struct graph`` were updated to support pcap trace in graph library.
+
ABI Changes
-----------
diff --git a/lib/graph/graph.c b/lib/graph/graph.c
index 3a617cc369..a839a2803b 100644
--- a/lib/graph/graph.c
+++ b/lib/graph/graph.c
@@ -15,6 +15,7 @@
#include <rte_string_fns.h>
#include "graph_private.h"
+#include "graph_pcap_private.h"
static struct graph_head graph_list = STAILQ_HEAD_INITIALIZER(graph_list);
static rte_spinlock_t graph_lock = RTE_SPINLOCK_INITIALIZER;
@@ -228,7 +229,12 @@ graph_mem_fixup_node_ctx(struct rte_graph *graph)
node_db = node_from_name(name);
if (node_db == NULL)
SET_ERR_JMP(ENOLINK, fail, "Node %s not found", name);
- node->process = node_db->process;
+
+ if (graph->pcap_enable) {
+ node->process = graph_pcap_dispatch;
+ node->original_process = node_db->process;
+ } else
+ node->process = node_db->process;
}
return graph;
@@ -242,6 +248,9 @@ graph_mem_fixup_secondary(struct rte_graph *graph)
if (graph == NULL || rte_eal_process_type() == RTE_PROC_PRIMARY)
return graph;
+ if (graph_pcap_file_open(graph->pcap_filename) || graph_pcap_mp_init())
+ graph_pcap_exit(graph);
+
return graph_mem_fixup_node_ctx(graph);
}
@@ -323,11 +332,17 @@ rte_graph_create(const char *name, struct rte_graph_param *prm)
if (graph_has_isolated_node(graph))
goto graph_cleanup;
+ /* Initialize pcap config. */
+ graph_pcap_enable(prm->pcap_enable);
+
/* Initialize graph object */
graph->socket = prm->socket_id;
graph->src_node_count = src_node_count;
graph->node_count = graph_nodes_count(graph);
graph->id = graph_id;
+ graph->num_pkt_to_capture = prm->num_pkt_to_capture;
+ if (prm->pcap_filename)
+ rte_strscpy(graph->pcap_filename, prm->pcap_filename, RTE_GRAPH_PCAP_FILE_SZ);
/* Allocate the Graph fast path memory and populate the data */
if (graph_fp_mem_create(graph))
diff --git a/lib/graph/graph_pcap.c b/lib/graph/graph_pcap.c
new file mode 100644
index 0000000000..7bd13ed61e
--- /dev/null
+++ b/lib/graph/graph_pcap.c
@@ -0,0 +1,217 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2023 Marvell International Ltd.
+ */
+
+#include <errno.h>
+#include <unistd.h>
+#include <stdlib.h>
+#include <pwd.h>
+
+#include <rte_mbuf.h>
+#include <rte_pcapng.h>
+
+#include "rte_graph_worker.h"
+
+#include "graph_pcap_private.h"
+
+#define GRAPH_PCAP_BUF_SZ 128
+#define GRAPH_PCAP_NUM_PACKETS 1024
+#define GRAPH_PCAP_PKT_POOL "graph_pcap_pkt_pool"
+#define GRAPH_PCAP_FILE_NAME "dpdk_graph_pcap_capture_XXXXXX.pcapng"
+
+/* For multi-process, packets are captured in separate files. */
+static rte_pcapng_t *pcapng_fd;
+static bool pcap_enable;
+struct rte_mempool *pkt_mp;
+
+void
+graph_pcap_enable(bool val)
+{
+ pcap_enable = val;
+}
+
+int
+graph_pcap_is_enable(void)
+{
+ return pcap_enable;
+}
+
+void
+graph_pcap_exit(struct rte_graph *graph)
+{
+ if (rte_eal_process_type() == RTE_PROC_PRIMARY)
+ if (pkt_mp)
+ rte_mempool_free(pkt_mp);
+
+ if (pcapng_fd) {
+ rte_pcapng_close(pcapng_fd);
+ pcapng_fd = NULL;
+ }
+
+ /* Disable pcap. */
+ graph->pcap_enable = 0;
+ graph_pcap_enable(0);
+}
+
+static int
+graph_pcap_default_path_get(char **dir_path)
+{
+ struct passwd *pwd;
+ char *home_dir;
+
+ /* First check for shell environment variable */
+ home_dir = getenv("HOME");
+ if (home_dir == NULL) {
+ graph_warn("Home env not preset.");
+ /* Fallback to password file entry */
+ pwd = getpwuid(getuid());
+ if (pwd == NULL)
+ return -EINVAL;
+
+ home_dir = pwd->pw_dir;
+ }
+
+ /* Append default pcap file to directory */
+ if (asprintf(dir_path, "%s/%s", home_dir, GRAPH_PCAP_FILE_NAME) == -1)
+ return -ENOMEM;
+
+ return 0;
+}
+
+int
+graph_pcap_file_open(const char *filename)
+{
+ int fd;
+ char file_name[RTE_GRAPH_PCAP_FILE_SZ];
+ char *pcap_dir;
+
+ if (pcapng_fd)
+ goto done;
+
+ if (!filename || filename[0] == '\0') {
+ if (graph_pcap_default_path_get(&pcap_dir) < 0)
+ return -1;
+ snprintf(file_name, RTE_GRAPH_PCAP_FILE_SZ, "%s", pcap_dir);
+ free(pcap_dir);
+ } else {
+ snprintf(file_name, RTE_GRAPH_PCAP_FILE_SZ, "%s_XXXXXX.pcapng",
+ filename);
+ }
+
+ fd = mkstemps(file_name, strlen(".pcapng"));
+ if (fd < 0) {
+ graph_err("mkstemps() failure");
+ return -1;
+ }
+
+ graph_info("pcap filename: %s", file_name);
+
+ /* Open a capture file */
+ pcapng_fd = rte_pcapng_fdopen(fd, NULL, NULL, "Graph pcap tracer",
+ NULL);
+ if (pcapng_fd == NULL) {
+ graph_err("Graph rte_pcapng_fdopen failed.");
+ close(fd);
+ return -1;
+ }
+
+done:
+ return 0;
+}
+
+int
+graph_pcap_mp_init(void)
+{
+ pkt_mp = rte_mempool_lookup(GRAPH_PCAP_PKT_POOL);
+ if (pkt_mp)
+ goto done;
+
+ /* Make a pool for cloned packets */
+ pkt_mp = rte_pktmbuf_pool_create_by_ops(GRAPH_PCAP_PKT_POOL,
+ IOV_MAX + RTE_GRAPH_BURST_SIZE, 0, 0,
+ rte_pcapng_mbuf_size(RTE_MBUF_DEFAULT_BUF_SIZE),
+ SOCKET_ID_ANY, "ring_mp_mc");
+ if (pkt_mp == NULL) {
+ graph_err("Cannot create mempool for graph pcap capture.");
+ return -1;
+ }
+
+done:
+ return 0;
+}
+
+int
+graph_pcap_init(struct graph *graph)
+{
+ struct rte_graph *graph_data = graph->graph;
+
+ if (graph_pcap_file_open(graph->pcap_filename) < 0)
+ goto error;
+
+ if (graph_pcap_mp_init() < 0)
+ goto error;
+
+ /* User configured number of packets to capture. */
+ if (graph->num_pkt_to_capture)
+ graph_data->nb_pkt_to_capture = graph->num_pkt_to_capture;
+ else
+ graph_data->nb_pkt_to_capture = GRAPH_PCAP_NUM_PACKETS;
+
+ /* All good. Now populate data for secondary process. */
+
+ rte_strscpy(graph_data->pcap_filename, graph->pcap_filename, RTE_GRAPH_PCAP_FILE_SZ);
+ graph_data->pcap_enable = 1;
+
+ return 0;
+
+error:
+ graph_pcap_exit(graph_data);
+ graph_pcap_enable(0);
+ graph_err("Graph pcap initialization failed. Disabling pcap trace.");
+ return -1;
+}
+
+uint16_t
+graph_pcap_dispatch(struct rte_graph *graph,
+ struct rte_node *node, void **objs,
+ uint16_t nb_objs)
+{
+ struct rte_mbuf *mbuf_clones[RTE_GRAPH_BURST_SIZE];
+ char buffer[GRAPH_PCAP_BUF_SZ];
+ uint64_t i, num_packets;
+ struct rte_mbuf *mbuf;
+ ssize_t len;
+
+ if (!nb_objs || (graph->nb_pkt_captured >= graph->nb_pkt_to_capture))
+ goto done;
+
+ num_packets = graph->nb_pkt_to_capture - graph->nb_pkt_captured;
+ /* nb_objs will never be greater than RTE_GRAPH_BURST_SIZE */
+ if (num_packets > nb_objs)
+ num_packets = nb_objs;
+
+ snprintf(buffer, GRAPH_PCAP_BUF_SZ, "%s: %s", graph->name, node->name);
+
+ for (i = 0; i < num_packets; i++) {
+ struct rte_mbuf *mc;
+ mbuf = (struct rte_mbuf *)objs[i];
+
+ mc = rte_pcapng_copy(mbuf->port, 0, mbuf, pkt_mp, mbuf->pkt_len,
+ rte_get_tsc_cycles(), 0, buffer);
+ if (mc == NULL)
+ break;
+
+ mbuf_clones[i] = mc;
+ }
+
+ /* write it to capture file */
+ len = rte_pcapng_write_packets(pcapng_fd, mbuf_clones, i);
+ rte_pktmbuf_free_bulk(mbuf_clones, i);
+ if (len <= 0)
+ goto done;
+
+ graph->nb_pkt_captured += i;
+
+done:
+ return node->original_process(graph, node, objs, nb_objs);
+}
diff --git a/lib/graph/graph_pcap_private.h b/lib/graph/graph_pcap_private.h
new file mode 100644
index 0000000000..198add67e2
--- /dev/null
+++ b/lib/graph/graph_pcap_private.h
@@ -0,0 +1,124 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2023 Marvell International Ltd.
+ */
+
+#ifndef _RTE_GRAPH_PCAP_PRIVATE_H_
+#define _RTE_GRAPH_PCAP_PRIVATE_H_
+
+#include <stdint.h>
+#include <sys/types.h>
+
+#include "graph_private.h"
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/**
+ * @internal
+ *
+ * Pcap trace enable/disable function.
+ *
+ * The function is called to enable/disable graph pcap trace functionality.
+ *
+ * @param val
+ * Value to be set to enable/disable graph pcap trace.
+ */
+void graph_pcap_enable(bool val);
+
+/**
+ * @internal
+ *
+ * Check graph pcap trace is enable/disable.
+ *
+ * The function is called to check if the graph pcap trace is enabled/disabled.
+ *
+ * @return
+ * - 1: Enable
+ * - 0: Disable
+ */
+int graph_pcap_is_enable(void);
+
+/**
+ * @internal
+ *
+ * Initialise graph pcap trace functionality.
+ *
+ * The function invoked to allocate mempool.
+ *
+ * @return
+ * 0 on success and -1 on failure.
+ */
+int graph_pcap_mp_init(void);
+
+/**
+ * @internal
+ *
+ * Initialise graph pcap trace functionality.
+ *
+ * The function invoked to open pcap file.
+ *
+ * @param filename
+ * Pcap filename.
+ *
+ * @return
+ * 0 on success and -1 on failure.
+ */
+int graph_pcap_file_open(const char *filename);
+
+/**
+ * @internal
+ *
+ * Initialise graph pcap trace functionality.
+ *
+ * The function invoked when the graph pcap trace is enabled. This function
+ * open's pcap file and allocates mempool. Information needed for secondary
+ * process is populated.
+ *
+ * @param graph
+ * Pointer to graph structure.
+ *
+ * @return
+ * 0 on success and -1 on failure.
+ */
+int graph_pcap_init(struct graph *graph);
+
+/**
+ * @internal
+ *
+ * Exit graph pcap trace functionality.
+ *
+ * The function is called to exit graph pcap trace and close open fd's and
+ * free up memory. Pcap trace is also disabled.
+ *
+ * @param graph
+ * Pointer to graph structure.
+ */
+void graph_pcap_exit(struct rte_graph *graph);
+
+/**
+ * @internal
+ *
+ * Capture mbuf metadata and node metadata to a pcap file.
+ *
+ * When graph pcap trace enabled, this function is invoked prior to each node
+ * and mbuf, node metadata is parsed and captured in a pcap file.
+ *
+ * @param graph
+ * Pointer to the graph object.
+ * @param node
+ * Pointer to the node object.
+ * @param objs
+ * Pointer to an array of objects to be processed.
+ * @param nb_objs
+ * Number of objects in the array.
+ */
+uint16_t graph_pcap_dispatch(struct rte_graph *graph,
+ struct rte_node *node, void **objs,
+ uint16_t nb_objs);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_GRAPH_PCAP_PRIVATE_H_ */
diff --git a/lib/graph/graph_populate.c b/lib/graph/graph_populate.c
index 102fd6c29b..2c0844ce92 100644
--- a/lib/graph/graph_populate.c
+++ b/lib/graph/graph_populate.c
@@ -9,6 +9,7 @@
#include <rte_memzone.h>
#include "graph_private.h"
+#include "graph_pcap_private.h"
static size_t
graph_fp_mem_calc_size(struct graph *graph)
@@ -75,7 +76,11 @@ graph_nodes_populate(struct graph *_graph)
memset(node, 0, sizeof(*node));
node->fence = RTE_GRAPH_FENCE;
node->off = off;
- node->process = graph_node->node->process;
+ if (graph_pcap_is_enable()) {
+ node->process = graph_pcap_dispatch;
+ node->original_process = graph_node->node->process;
+ } else
+ node->process = graph_node->node->process;
memcpy(node->name, graph_node->node->name, RTE_GRAPH_NAMESIZE);
pid = graph_node->node->parent_id;
if (pid != RTE_NODE_ID_INVALID) { /* Cloned node */
@@ -183,6 +188,8 @@ graph_fp_mem_populate(struct graph *graph)
int rc;
graph_header_popluate(graph);
+ if (graph_pcap_is_enable())
+ graph_pcap_init(graph);
graph_nodes_populate(graph);
rc = graph_node_nexts_populate(graph);
rc |= graph_src_nodes_populate(graph);
@@ -227,6 +234,9 @@ graph_nodes_mem_destroy(struct rte_graph *graph)
int
graph_fp_mem_destroy(struct graph *graph)
{
+ if (graph_pcap_is_enable())
+ graph_pcap_exit(graph->graph);
+
graph_nodes_mem_destroy(graph->graph);
return rte_memzone_free(graph->mz);
}
diff --git a/lib/graph/graph_private.h b/lib/graph/graph_private.h
index f9a85c8926..7d1b30b8ac 100644
--- a/lib/graph/graph_private.h
+++ b/lib/graph/graph_private.h
@@ -22,6 +22,7 @@ extern int rte_graph_logtype;
__func__, __LINE__, RTE_FMT_TAIL(__VA_ARGS__, )))
#define graph_err(...) GRAPH_LOG(ERR, __VA_ARGS__)
+#define graph_warn(...) GRAPH_LOG(WARNING, __VA_ARGS__)
#define graph_info(...) GRAPH_LOG(INFO, __VA_ARGS__)
#define graph_dbg(...) GRAPH_LOG(DEBUG, __VA_ARGS__)
@@ -100,6 +101,10 @@ struct graph {
/**< Memory size of the graph. */
int socket;
/**< Socket identifier where memory is allocated. */
+ uint64_t num_pkt_to_capture;
+ /**< Number of packets to be captured per core. */
+ char pcap_filename[RTE_GRAPH_PCAP_FILE_SZ];
+ /**< pcap file name/path. */
STAILQ_HEAD(gnode_list, graph_node) node_list;
/**< Nodes in a graph. */
};
diff --git a/lib/graph/meson.build b/lib/graph/meson.build
index c7327549e8..3526d1b5d4 100644
--- a/lib/graph/meson.build
+++ b/lib/graph/meson.build
@@ -14,7 +14,8 @@ sources = files(
'graph_debug.c',
'graph_stats.c',
'graph_populate.c',
+ 'graph_pcap.c',
)
headers = files('rte_graph.h', 'rte_graph_worker.h')
-deps += ['eal']
+deps += ['eal', 'pcapng']
diff --git a/lib/graph/rte_graph.h b/lib/graph/rte_graph.h
index b32c4bc217..c9a77297fc 100644
--- a/lib/graph/rte_graph.h
+++ b/lib/graph/rte_graph.h
@@ -35,6 +35,7 @@ extern "C" {
#define RTE_GRAPH_NAMESIZE 64 /**< Max length of graph name. */
#define RTE_NODE_NAMESIZE 64 /**< Max length of node name. */
+#define RTE_GRAPH_PCAP_FILE_SZ 64 /**< Max length of pcap file name. */
#define RTE_GRAPH_OFF_INVALID UINT32_MAX /**< Invalid graph offset. */
#define RTE_NODE_ID_INVALID UINT32_MAX /**< Invalid node id. */
#define RTE_EDGE_ID_INVALID UINT16_MAX /**< Invalid edge id. */
@@ -164,6 +165,10 @@ struct rte_graph_param {
uint16_t nb_node_patterns; /**< Number of node patterns. */
const char **node_patterns;
/**< Array of node patterns based on shell pattern. */
+
+ bool pcap_enable; /**< Pcap enable. */
+ uint64_t num_pkt_to_capture; /**< Number of packets to capture. */
+ char *pcap_filename; /**< Filename in which packets to be captured.*/
};
/**
diff --git a/lib/graph/rte_graph_worker.h b/lib/graph/rte_graph_worker.h
index fc6fee48c8..438595b15c 100644
--- a/lib/graph/rte_graph_worker.h
+++ b/lib/graph/rte_graph_worker.h
@@ -44,6 +44,12 @@ struct rte_graph {
rte_graph_t id; /**< Graph identifier. */
int socket; /**< Socket ID where memory is allocated. */
char name[RTE_GRAPH_NAMESIZE]; /**< Name of the graph. */
+ bool pcap_enable; /**< Pcap trace enabled. */
+ /** Number of packets captured per core. */
+ uint64_t nb_pkt_captured;
+ /** Number of packets to capture per core. */
+ uint64_t nb_pkt_to_capture;
+ char pcap_filename[RTE_GRAPH_PCAP_FILE_SZ]; /**< Pcap filename. */
uint64_t fence; /**< Fence. */
} __rte_cache_aligned;
@@ -64,6 +70,9 @@ struct rte_node {
char parent[RTE_NODE_NAMESIZE]; /**< Parent node name. */
char name[RTE_NODE_NAMESIZE]; /**< Name of the node. */
+ /** Original process function when pcap is enabled. */
+ rte_node_process_t original_process;
+
/* Fast path area */
#define RTE_NODE_CTX_SZ 16
uint8_t ctx[RTE_NODE_CTX_SZ] __rte_cache_aligned; /**< Node Context. */
--
2.25.1
^ permalink raw reply [relevance 2%]
* RE: [RFC 2/5] ethdev: introduce the affinity field in Tx queue API
2023-01-18 16:31 0% ` Thomas Monjalon
@ 2023-01-24 13:32 0% ` Jiawei(Jonny) Wang
0 siblings, 0 replies; 200+ results
From: Jiawei(Jonny) Wang @ 2023-01-24 13:32 UTC (permalink / raw)
To: NBU-Contact-Thomas Monjalon (EXTERNAL)
Cc: Slava Ovsiienko, Ori Kam, Aman Singh, Yuying Zhang, Ferruh Yigit,
Andrew Rybchenko, dev, Raslan Darawsheh, jerinj
Hi,
> 18/01/2023 15:44, Jiawei(Jonny) Wang:
> > > 21/12/2022 11:29, Jiawei Wang:
> > > > For the multiple hardware ports connect to a single DPDK port
> > > > (mhpsdp), the previous patch introduces the new rte flow item to
> > > > match the port affinity of the received packets.
> > > >
> > > > This patch adds the tx_affinity setting in Tx queue API, the
> > > > affinity value reflects packets be sent to which hardware port.
> > >
> > > I think "affinity" means we would like packet to be sent on a
> > > specific hardware port, but it is not mandatory.
> > > Is it the meaning you want? Or should it be a mandatory port?
> >
> > Right, it's optional setting not mandatory.
>
> I think there is a misunderstanding.
> I mean that "affinity" with port 0 may suggest that we try to send to port 0 but
> sometimes the packet will be sent to port 1.
>
> And I think you want the packet to be always sent to port 0 if affinity is 0, right?
>
These packets should be always sent to port 0 if 'affinity' be set with hardware port 0.
'affinity is 0' -> 0 means that no affinity be set and traffic should be kept the same behavior
as before, for example, routing between different hardware ports.
> If yes, I think the word "affinity" does not convey the right idea.
> And again, the naming should give the idea that we are talking about multiple
> ports merged in one DPDK port.
>
OK, how about 'tx_mhpsdp_hwport?
'mhpsdp' as mentioned before, 'hwport' means for one 'hardware port'.
> > > > Adds the new tx_affinity field into the padding hole of
> > > > rte_eth_txconf structure, the size of rte_eth_txconf keeps the
> > > > same. Adds a suppress type for structure change in the ABI check file.
> > > >
> > > > This patch adds the testpmd command line:
> > > > testpmd> port config (port_id) txq (queue_id) affinity (value)
> > > >
> > > > For example, there're two hardware ports connects to a single DPDK
> > >
> > > connects -> connected
> >
> > OK, will fix in next version.
> >
> > > > port (port id 0), and affinity 1 stood for hard port 1 and
> > > > affinity
> > > > 2 stood for hardware port 2, used the below command to config tx
> > > > affinity for each TxQ:
> > > > port config 0 txq 0 affinity 1
> > > > port config 0 txq 1 affinity 1
> > > > port config 0 txq 2 affinity 2
> > > > port config 0 txq 3 affinity 2
> > > >
> > > > These commands config the TxQ index 0 and TxQ index 1 with
> > > > affinity 1, uses TxQ 0 or TxQ 1 send packets, these packets will
> > > > be sent from the hardware port 1, and similar with hardware port 2
> > > > if sending packets with TxQ 2 or TxQ 3.
> > >
> > > [...]
> > > > @@ -212,6 +212,10 @@ API Changes
> > > > +* ethdev: added a new field:
> > > > +
> > > > + - Tx affinity per-queue ``rte_eth_txconf.tx_affinity``
> > >
> > > Adding a new field is not an API change because existing
> > > applications don't need to update their code if they don't care this new field.
> > > I think you can remove this note.
> >
> > OK, will remove in next version.
> >
> > > > --- a/lib/ethdev/rte_ethdev.h
> > > > +++ b/lib/ethdev/rte_ethdev.h
> > > > @@ -1138,6 +1138,7 @@ struct rte_eth_txconf {
> > > > less free descriptors than this value. */
> > > >
> > > > uint8_t tx_deferred_start; /**< Do not start queue with
> > > > rte_eth_dev_start(). */
> > > > + uint8_t tx_affinity; /**< Drives the setting of affinity per-queue.
> > > > +*/
> > >
> > > Why "Drives"? It is the setting, right?
> > > rte_eth_txconf is per-queue so no need to repeat.
> > > I think a good comment here would be to mention it is a physical
> > > port index for mhpsdp.
> > > Another good comment would be to specify how ports are numbered.
> >
> > OK, will update the comment for this new setting.
> >
> > Thanks.
>
>
^ permalink raw reply [relevance 0%]
* Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
@ 2023-01-25 10:38 3% ` Jerin Jacob
2023-01-25 16:32 0% ` Naga Harish K, S V
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2023-01-25 10:38 UTC (permalink / raw)
To: Naga Harish K, S V
Cc: jerinj, Carrillo, Erik G, Gujjar, Abhinandan S, dev, Jayatheerthan, Jay
On Wed, Jan 25, 2023 at 3:22 PM Naga Harish K, S V
<s.v.naga.harish.k@intel.com> wrote:
>
> Hi Jerin,
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Wednesday, January 25, 2023 9:42 AM
> > To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> > Cc: jerinj@marvell.com; Carrillo, Erik G <erik.g.carrillo@intel.com>; Gujjar,
> > Abhinandan S <abhinandan.gujjar@intel.com>; dev@dpdk.org;
> > Jayatheerthan, Jay <jay.jayatheerthan@intel.com>
> > Subject: Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
> >
> > On Tue, Jan 24, 2023 at 6:37 PM Naga Harish K, S V
> > <s.v.naga.harish.k@intel.com> wrote:
> > >
> > > Hi Jerin,
> > >
> > > > -----Original Message-----
> > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > Sent: Tuesday, January 24, 2023 10:00 AM
> > > > To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> > > > Cc: jerinj@marvell.com; Carrillo, Erik G
> > > > <erik.g.carrillo@intel.com>; Gujjar, Abhinandan S
> > > > <abhinandan.gujjar@intel.com>; dev@dpdk.org; Jayatheerthan, Jay
> > > > <jay.jayatheerthan@intel.com>
> > > > Subject: Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
> > > >
> > > > On Mon, Jan 23, 2023 at 11:35 PM Naga Harish K S V
> > > > <s.v.naga.harish.k@intel.com> wrote:
> > > > >
> > > > > The adapter configuration parameters defined in the ``struct
> > > > > rte_event_eth_rx_adapter_runtime_params`` can be configured and
> > > > > retrieved using ``rte_event_eth_rx_adapter_runtime_params_set``
> > > > > and ``rte_event_eth_tx_adapter_runtime_params_get`` respectively.
> > > > >
> > > > > Signed-off-by: Naga Harish K S V <s.v.naga.harish.k@intel.com>
> > > >
> > > > > diff --git a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> > > > > b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> > > > > index 461eca566f..2207d6ffc3 100644
> > > > > --- a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> > > > > +++ b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> > > > > @@ -185,6 +185,26 @@ flags for handling received packets, event
> > > > > queue identifier, scheduler type, event priority, polling
> > > > > frequency of the receive queue and flow identifier in struct
> > > > ``rte_event_eth_rx_adapter_queue_conf``.
> > > > >
> > > > > +Set/Get adapter runtime configuration parameters
> > > > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > +
> > > > > +The runtime configuration parameters of adapter can be set/read
> > > > > +using ``rte_event_eth_rx_adapter_runtime_params_set()`` and
> > > > > +``rte_event_eth_rx_adapter_runtime_params_get()`` respectively.
> > > > > +The parameters that can be set/read are defined in ``struct
> > > > rte_event_eth_rx_adapter_runtime_params``.
> > > >
> > > > Good.
> > > >
> > > > > +
> > > > > +``rte_event_eth_rx_adapter_create()`` or
> > > > > +``rte_event_eth_rx_adapter_create_with_params()`` configures the
> > > > > +adapter with default value for maximum packets processed per
> > > > > +request to
> > > > 128.
> > > > > +``rte_event_eth_rx_adapter_runtime_params_set()`` function allows
> > > > > +to reconfigure maximum number of packets processed by adapter per
> > > > > +service request. This is alternative to configuring the maximum
> > > > > +packets processed per request by adapter by using
> > > > > +``rte_event_eth_rx_adapter_create_ext()`` with parameter
> > > > ``rte_event_eth_rx_adapter_conf::max_nb_rx``.
> > > >
> > > > This paragraph is not needed IMO. As it is specific to a driver, and
> > > > we can keep Doxygen comment only.
> > > >
> > > >
> > > > > +
> > > > > +``rte_event_eth_rx_adapter_runtime_parmas_get()`` function
> > > > > +retrieves the configuration parameters that are defined in
> > > > > +``struct
> > > > rte_event_eth_rx_adapter_runtime_params``.
> > > >
> > > > Good.
> > > >
> > > > > +
> > > > > Getting and resetting Adapter queue stats
> > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > >
> > > > > diff --git a/lib/eventdev/rte_event_eth_rx_adapter.c
> > > > > b/lib/eventdev/rte_event_eth_rx_adapter.c
> > > > > index 34aa87379e..d8f3e750b7 100644
> > > > > --- a/lib/eventdev/rte_event_eth_rx_adapter.c
> > > > > +++ b/lib/eventdev/rte_event_eth_rx_adapter.c
> > > > > @@ -35,6 +35,8 @@
> > > > > #define MAX_VECTOR_NS 1E9
> > > > > #define MIN_VECTOR_NS 1E5
> > > > >
> > > > > +#define RXA_NB_RX_WORK_DEFAULT 128
> > > > > +
> > > > > #define ETH_RX_ADAPTER_SERVICE_NAME_LEN 32
> > > > > #define ETH_RX_ADAPTER_MEM_NAME_LEN 32
> > > > >
> > > > > @@ -1554,7 +1556,7 @@ rxa_default_conf_cb(uint8_t id, uint8_t
> > dev_id,
> > > > > }
> > > > >
> > > > > conf->event_port_id = port_id;
> > > > > - conf->max_nb_rx = 128;
> > > > > + conf->max_nb_rx = RXA_NB_RX_WORK_DEFAULT;
> > > > > if (started)
> > > > > ret = rte_event_dev_start(dev_id);
> > > > > rx_adapter->default_cb_arg = 1; @@ -3436,6 +3438,90 @@
> > > > > rte_event_eth_rx_adapter_instance_get(uint16_t eth_dev_id,
> > > > > return -EINVAL;
> > > > > }
> > > >
> > > > > +
> > > > > +int
> > > > > +rte_event_eth_rx_adapter_runtime_params_set(uint8_t id,
> > > > > + struct rte_event_eth_rx_adapter_runtime_params
> > > > > +*params) {
> > > > > + struct event_eth_rx_adapter *rxa;
> > > > > + int ret;
> > > > > +
> > > > > + if (params == NULL)
> > > > > + return -EINVAL;
> > > > > +
> > > > > + if (rxa_memzone_lookup())
> > > > > + return -ENOMEM;
> > > >
> > > > Introduce an adapter callback and move SW adapter related logic
> > > > under callback handler.
> > > >
> > > >
> > > Do you mean introducing eventdev PMD callback for HW implementation?
> >
> > Yes.
> >
>
> Can this be taken care as and when the HW implementation is required?
OK. As long as when case INTERNAL PORT it return -ENOSUP now.
>
> > > There are no adapter callback currently for service based SW
> > Implementation.
> > >
> > > > > +
> > > > > + rxa = rxa_id_to_adapter(id);
> > > > > + if (rxa == NULL)
> > > > > + return -EINVAL;
> > > > > +
> > > > > + ret = rxa_caps_check(rxa);
> > > > > + if (ret)
> > > > > + return ret;
> > > > > +
> > > > > + rte_spinlock_lock(&rxa->rx_lock);
> > > > > + rxa->max_nb_rx = params->max_nb_rx;
> > > > > + rte_spinlock_unlock(&rxa->rx_lock);
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > > +
> > > > > +int
> > > > > +rte_event_eth_rx_adapter_runtime_params_get(uint8_t id,
> > > > > + struct rte_event_eth_rx_adapter_runtime_params
> > > > > +*params) {
> > > > > + struct event_eth_rx_adapter *rxa;
> > > > > + int ret;
> > > > > +
> > > > > + if (params == NULL)
> > > > > + return -EINVAL;
> > > >
> > > >
> > > > Introduce an adapter callback and move SW adapter related logic
> > > > under callback handler.
> > > >
> > > >
> > >
> > > Same as above
> > >
> > > > > +
> > > > > + if (rxa_memzone_lookup())
> > > > > + return -ENOMEM;
> > > > +
> > > > > + rxa = rxa_id_to_adapter(id);
> > > > > + if (rxa == NULL)
> > > > > + return -EINVAL;
> > > > > +
> > > > > + ret = rxa_caps_check(rxa);
> > > > > + if (ret)
> > > > > + return ret;
> > > > > +
> > > > > + params->max_nb_rx = rxa->max_nb_rx;
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > > +
> > > > > +/* RX-adapter telemetry callbacks */
> > > > > #define RXA_ADD_DICT(stats, s) rte_tel_data_add_dict_u64(d, #s,
> > > > > stats.s)
> > > > >
> > > > > static int
> > > > > diff --git a/lib/eventdev/rte_event_eth_rx_adapter.h
> > > > > b/lib/eventdev/rte_event_eth_rx_adapter.h
> > > > > index f4652f40e8..214ffd018c 100644
> > > > > --- a/lib/eventdev/rte_event_eth_rx_adapter.h
> > > > > +++ b/lib/eventdev/rte_event_eth_rx_adapter.h
> > > > > @@ -39,10 +39,21 @@
> > > > > * - rte_event_eth_rx_adapter_queue_stats_reset()
> > > > > * - rte_event_eth_rx_adapter_event_port_get()
> > > > > * - rte_event_eth_rx_adapter_instance_get()
> > > > > + * - rte_event_eth_rx_adapter_runtime_params_get()
> > > > > + * - rte_event_eth_rx_adapter_runtime_params_set()
> > > > > *
> > > > > * The application creates an ethernet to event adapter using
> > > > > * rte_event_eth_rx_adapter_create_ext() or
> > > > rte_event_eth_rx_adapter_create()
> > > > > * or rte_event_eth_rx_adapter_create_with_params() functions.
> > > > > + *
> > > > > + * rte_event_eth_rx_adapter_create() or
> > > > > + rte_event_eth_adapter_create_with_params()
> > > > > + * configures the adapter with default value of maximum packets
> > > > > + processed per
> > > > > + * iteration to RXA_NB_RX_WORK_DEFAULT(128).
> > > > > + * rte_event_eth_rx_adapter_runtime_params_set() allows to
> > > > > + re-configure maximum
> > > > > + * packets processed per iteration. This is alternative to using
> > > > > + * rte_event_eth_rx_adapter_create_ext() with parameter
> > > > > + * rte_event_eth_rx_adapter_conf::max_nb_rx
> > > >
> > > > Move this to Doxygen comment against max_nb_rx
> > > >
> > > > > + *
> > > > > * The adapter needs to know which ethernet rx queues to poll for
> > > > > mbufs as
> > > > well
> > > > > * as event device parameters such as the event queue identifier,
> > event
> > > > > * priority and scheduling type that the adapter should use when
> > > > > constructing @@ -299,6 +310,19 @@ struct
> > > > rte_event_eth_rx_adapter_params {
> > > > > /**< flag to indicate that event buffer is separate for
> > > > > each queue */ };
> > > > >
> > > > > +/**
> > > > > + * Adapter configuration parameters */ struct
> > > > > +rte_event_eth_rx_adapter_runtime_params {
> > > > > + uint32_t max_nb_rx;
> > > > > + /**< The adapter can return early if it has processed at least
> > > > > + * max_nb_rx mbufs. This isn't treated as a requirement; batching
> > may
> > > > > + * cause the adapter to process more than max_nb_rx mbufs.
> > > >
> > > > Also tell it is valid only for INTERNAL PORT capablity is set.
> > > >
> > >
> > > Do you mean, it is valid only for INTERNAL PORT capability is 'not' set?
> >
> > Yes.
> >
> > >
> > > > > + */
> > > > > + uint32_t rsvd[15];
> > > > > + /**< Reserved fields for future use */
> > > >
> > > > Introduce rte_event_eth_rx_adapter_runtime_params_init() to make
> > > > sure rsvd is zero.
> > > >
> > >
> > > The reserved fields are not used by the adapter or application. Not
> > > sure Is it necessary to Introduce a new API to clear reserved fields.
> >
> > When adapter starts using new fileds(when we add new fieds in future), the
> > old applicaiton which is not using
> > rte_event_eth_rx_adapter_runtime_params_init() may have junk value and
> > then adapter implementation will behave bad.
> >
> >
>
> does it mean, the application doesn't re-compile for the new DPDK?
Yes. No need recompile if ABI not breaking.
> When some of the reserved fields are used in the future, the application also may need to be recompiled along with DPDK right?
> As the application also may need to use the newly consumed reserved fields?
The problematic case is:
Adapter implementation of 23.07(Assuming there is change params) field
needs to work with application of 23.03.
rte_event_eth_rx_adapter_runtime_params_init() will sove that.
>
> > >
> > > > > +};
> > > > > +
> > > > > /**
> > > > > *
> > > > > * Callback function invoked by the SW adapter before it
> > > > > continues @@
> > > > > -377,7 +401,7 @@ int rte_event_eth_rx_adapter_create_ext(uint8_t
> > > > > id,
> > > > uint8_t dev_id,
> > > > > * Create a new ethernet Rx event adapter with the specified
> > identifier.
> > > > > * This function uses an internal configuration function that creates an
> > event
> > > > > * port. This default function reconfigures the event device with
> > > > > an
> > > > > - * additional event port and setups up the event port using the
> > > > > port_config
> > > > > + * additional event port and setup the event port using the
> > > > > + port_config
> > > > > * parameter passed into this function. In case the application needs
> > more
> > > > > * control in configuration of the service, it should use the
> > > > > * rte_event_eth_rx_adapter_create_ext() version.
> > > > > @@ -743,6 +767,50 @@
> > > > > rte_event_eth_rx_adapter_instance_get(uint16_t
> > > > eth_dev_id,
> > > > > uint16_t rx_queue_id,
> > > > > uint8_t *rxa_inst_id);
> > > > >
^ permalink raw reply [relevance 3%]
* Re: [EXT] Re: [PATCH v6 1/6] eal: trace: add trace point emit for blob
@ 2023-01-25 16:09 2% ` Ferruh Yigit
2023-01-30 13:35 0% ` Ankur Dwivedi
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2023-01-25 16:09 UTC (permalink / raw)
To: Ankur Dwivedi, dev
Cc: thomas, david.marchand, mdr, orika, chas3, humin29, linville,
ciara.loftus, qi.z.zhang, mw, mk, shaibran, evgenys, igorch,
chandu, Igor Russkikh, shepard.siegel, ed.czeck, john.miller,
ajit.khaparde, somnath.kotur, Jerin Jacob Kollanukkaran,
Maciej Czekaj [C],
Shijith Thotton, Srisivasubramanian Srinivasan, Harman Kalra,
rahul.lakkireddy, johndale, hyonkim, liudongdong3, yisen.zhuang,
xuanziyang2, cloud.wangxiaoyun, zhouguoyang, simei.su,
wenjun1.wu, qiming.yang, Yuying.Zhang, beilei.xing, xiao.w.wang,
jingjing.wu, junfeng.guo, rosen.xu, Nithin Kumar Dabilpuram,
Kiran Kumar Kokkilagadda, Sunil Kumar Kori,
Satha Koteswara Rao Kottidi, Liron Himi, zr, Radha Chintakuntla,
Veerasenareddy Burru, Sathesh B Edara, matan, viacheslavo,
longli, spinler, chaoyong.he, niklas.soderlund, hemant.agrawal,
sachin.saxena, g.singh, apeksha.gupta, sachin.saxena, aboyer,
Rasesh Mody, Shahed Shaikh, Devendra Singh Rawat,
andrew.rybchenko, jiawenwu, jianwang, jbehrens, maxime.coquelin,
chenbo.xia, steven.webster, matt.peters, bruce.richardson,
mtetsuyah, grive, jasvinder.singh, cristian.dumitrescu, jgrajcia,
mb
On 1/25/2023 3:02 PM, Ankur Dwivedi wrote:
>
>>
>> ----------------------------------------------------------------------
>> On 1/20/2023 8:40 AM, Ankur Dwivedi wrote:
>>> Adds a trace point emit function for capturing a blob. The blob
>>> captures the length passed by the application followed by the array.
>>>
>>> The maximum blob bytes which can be captured is bounded by
>>> RTE_TRACE_BLOB_LEN_MAX macro. The value for max blob length macro is
>>> 64 bytes. If the length is less than 64 the remaining trailing bytes
>>> are set to zero.
>>>
>>> This patch also adds test case for emit blob tracepoint function.
>>>
>>> Signed-off-by: Ankur Dwivedi <adwivedi@marvell.com>
>>> ---
>>> app/test/test_trace.c | 11 ++++++++
>>> doc/guides/prog_guide/trace_lib.rst | 12 ++++++++
>>> lib/eal/common/eal_common_trace_points.c | 2 ++
>>> lib/eal/include/rte_eal_trace.h | 6 ++++
>>> lib/eal/include/rte_trace_point.h | 32 ++++++++++++++++++++++
>>> lib/eal/include/rte_trace_point_register.h | 9 ++++++
>>> lib/eal/version.map | 3 ++
>>> 7 files changed, 75 insertions(+)
>>>
>>> diff --git a/app/test/test_trace.c b/app/test/test_trace.c index
>>> 6bedf14024..ad4a394a29 100644
>>> --- a/app/test/test_trace.c
>>> +++ b/app/test/test_trace.c
>>> @@ -4,6 +4,7 @@
>>>
>>> #include <rte_eal_trace.h>
>>> #include <rte_lcore.h>
>>> +#include <rte_random.h>
>>> #include <rte_trace.h>
>>>
>>> #include "test.h"
>>> @@ -177,7 +178,12 @@ test_fp_trace_points(void) static int
>>> test_generic_trace_points(void)
>>> {
>>> + uint8_t arr[RTE_TRACE_BLOB_LEN_MAX];
>>> int tmp;
>>> + int i;
>>> +
>>> + for (i = 0; i < RTE_TRACE_BLOB_LEN_MAX; i++)
>>> + arr[i] = i;
>>>
>>> rte_eal_trace_generic_void();
>>> rte_eal_trace_generic_u64(0x10000000000000);
>>> @@ -195,6 +201,11 @@ test_generic_trace_points(void)
>>> rte_eal_trace_generic_ptr(&tmp);
>>> rte_eal_trace_generic_str("my string");
>>> rte_eal_trace_generic_size_t(sizeof(void *));
>>> + rte_eal_trace_generic_blob(arr, 0);
>>> + rte_eal_trace_generic_blob(arr, 17);
>>> + rte_eal_trace_generic_blob(arr, RTE_TRACE_BLOB_LEN_MAX);
>>> + rte_eal_trace_generic_blob(arr, rte_rand() %
>>> + RTE_TRACE_BLOB_LEN_MAX);
>>> RTE_EAL_TRACE_GENERIC_FUNC;
>>>
>>> return TEST_SUCCESS;
>>> diff --git a/doc/guides/prog_guide/trace_lib.rst
>>> b/doc/guides/prog_guide/trace_lib.rst
>>> index 9a8f38073d..3e0ea5835c 100644
>>> --- a/doc/guides/prog_guide/trace_lib.rst
>>> +++ b/doc/guides/prog_guide/trace_lib.rst
>>> @@ -352,3 +352,15 @@ event ID.
>>> The ``packet.header`` and ``packet.context`` will be written in the
>>> slow path at the time of trace memory creation. The ``trace.header``
>>> and trace payload will be emitted when the tracepoint function is invoked.
>>> +
>>> +Limitations
>>> +-----------
>>> +
>>> +- The ``rte_trace_point_emit_blob()`` function can capture a maximum
>>> +blob of
>>> + length ``RTE_TRACE_BLOB_LEN_MAX`` bytes. The application can call
>>> + ``rte_trace_point_emit_blob()`` multiple times with length less
>>> +than or equal to
>>> + ``RTE_TRACE_BLOB_LEN_MAX``, if it needs to capture more than
>>> +``RTE_TRACE_BLOB_LEN_MAX``
>>> + bytes.
>>> +- If the length passed to the ``rte_trace_point_emit_blob()`` is less
>>> +than
>>> + ``RTE_TRACE_BLOB_LEN_MAX``, then the trailing
>>> +``(RTE_TRACE_BLOB_LEN_MAX - len)``
>>> + bytes in the trace are set to zero.
>>> diff --git a/lib/eal/common/eal_common_trace_points.c
>>> b/lib/eal/common/eal_common_trace_points.c
>>> index 0b0b254615..051f89809c 100644
>>> --- a/lib/eal/common/eal_common_trace_points.c
>>> +++ b/lib/eal/common/eal_common_trace_points.c
>>> @@ -40,6 +40,8 @@
>> RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_size_t,
>>> lib.eal.generic.size_t)
>>> RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_func,
>>> lib.eal.generic.func)
>>> +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_blob,
>>> + lib.eal.generic.blob)
>>>
>>> RTE_TRACE_POINT_REGISTER(rte_eal_trace_alarm_set,
>>> lib.eal.alarm.set)
>>> diff --git a/lib/eal/include/rte_eal_trace.h
>>> b/lib/eal/include/rte_eal_trace.h index 5ef4398230..e0b836eb2f 100644
>>> --- a/lib/eal/include/rte_eal_trace.h
>>> +++ b/lib/eal/include/rte_eal_trace.h
>>> @@ -143,6 +143,12 @@ RTE_TRACE_POINT(
>>> rte_trace_point_emit_string(func);
>>> )
>>>
>>> +RTE_TRACE_POINT(
>>> + rte_eal_trace_generic_blob,
>>> + RTE_TRACE_POINT_ARGS(void *in, uint8_t len),
>>> + rte_trace_point_emit_blob(in, len);
>>> +)
>>> +
>>> #define RTE_EAL_TRACE_GENERIC_FUNC
>>> rte_eal_trace_generic_func(__func__)
>>>
>>> /* Interrupt */
>>> diff --git a/lib/eal/include/rte_trace_point.h
>>> b/lib/eal/include/rte_trace_point.h
>>> index 0f8700974f..aca8344dbf 100644
>>> --- a/lib/eal/include/rte_trace_point.h
>>> +++ b/lib/eal/include/rte_trace_point.h
>>> @@ -144,6 +144,16 @@ _tp _args \
>>> #define rte_trace_point_emit_ptr(val)
>>> /** Tracepoint function payload for string datatype */ #define
>>> rte_trace_point_emit_string(val)
>>> +/**
>>> + * Tracepoint function to capture a blob.
>>> + *
>>> + * @param val
>>> + * Pointer to the array to be captured.
>>> + * @param len
>>> + * Length to be captured. The maximum supported length is
>>> + * RTE_TRACE_BLOB_LEN_MAX bytes.
>>> + */
>>> +#define rte_trace_point_emit_blob(val, len)
>>>
>>
>> This is just for doxygen right, why doxygen comments are not above the actual
>> macros but there is a separate #if block for it?
>
> The actual macro is within a #ifndef __DOXYGEN__ block. I think that is the reason for including
> Doxygen comments here.
Thanks for confirming.
Why comments are not as part of actual macro, but there is a separate
'#ifdef __DOXYGEN__' block?
>>
>>> #endif /* __DOXYGEN__ */
>>>
>>> @@ -152,6 +162,9 @@ _tp _args \
>>> /** @internal Macro to define event header size. */ #define
>>> __RTE_TRACE_EVENT_HEADER_SZ sizeof(uint64_t)
>>>
>>> +/** Macro to define maximum emit length of blob. */ #define
>>> +RTE_TRACE_BLOB_LEN_MAX 64
>>> +
>>> /**
>>> * Enable recording events of the given tracepoint in the trace buffer.
>>> *
>>> @@ -374,12 +387,31 @@ do { \
>>> mem = RTE_PTR_ADD(mem, __RTE_TRACE_EMIT_STRING_LEN_MAX);
>> \ } while
>>> (0)
>>>
>>> +#define rte_trace_point_emit_blob(in, len) \ do { \
>>> + if (unlikely(in == NULL)) \
>>> + return; \
>>> + if (len > RTE_TRACE_BLOB_LEN_MAX) \
>>> + len = RTE_TRACE_BLOB_LEN_MAX; \
>>> + __rte_trace_point_emit(len, uint8_t); \
>>> + memcpy(mem, in, len); \
>>> + mem = RTE_PTR_ADD(mem, len); \
>>> + memset(mem, 0, RTE_TRACE_BLOB_LEN_MAX - len); \
>>> + mem = RTE_PTR_ADD(mem, RTE_TRACE_BLOB_LEN_MAX - len); \
>>
>>
>> Is first memset later memcpy not done because of performance concerns?
>
> The memset sets to 0 the unused bytes (RTE_TRACE_BLOB_LEN_MAX - len). So memset is done after memcpy.
yep, I can see what is done.
Question is, you can do more simply:
memset(mem, 0, RTE_TRACE_BLOB_LEN_MAX);
memcpy(mem, in, len);
mem = RTE_PTR_ADD(mem, RTE_TRACE_BLOB_LEN_MAX - len);
Why did you prefer the implementation you did, intentionally? If so what
is the intention, performance concerns?
btw, I want to remind that size of the 'len' can be max 64 bytes.
>>
>>> +} while (0)
>>> +
>>> #else
>>>
>>> #define __rte_trace_point_emit_header_generic(t) RTE_SET_USED(t)
>>> #define __rte_trace_point_emit_header_fp(t) RTE_SET_USED(t) #define
>>> __rte_trace_point_emit(in, type) RTE_SET_USED(in) #define
>>> rte_trace_point_emit_string(in) RTE_SET_USED(in)
>>> +#define rte_trace_point_emit_blob(in, len) \ do { \
>>> + RTE_SET_USED(in); \
>>> + RTE_SET_USED(len); \
>>> +} while (0)
>>> +
>>>
>>> #endif /* ALLOW_EXPERIMENTAL_API */
>>> #endif /* _RTE_TRACE_POINT_REGISTER_H_ */ diff --git
>>> a/lib/eal/include/rte_trace_point_register.h
>>> b/lib/eal/include/rte_trace_point_register.h
>>> index a32f4d731b..7efbac8a72 100644
>>> --- a/lib/eal/include/rte_trace_point_register.h
>>> +++ b/lib/eal/include/rte_trace_point_register.h
>>> @@ -47,6 +47,15 @@ do { \
>>> RTE_STR(in)"[32]", "string_bounded_t"); \ } while (0)
>>>
>>> +#define rte_trace_point_emit_blob(in, len) \ do { \
>>> + RTE_SET_USED(in); \
>>> + __rte_trace_point_emit(len, uint8_t); \
>>> + __rte_trace_point_emit_field(RTE_TRACE_BLOB_LEN_MAX, \
>>> + RTE_STR(in)"["RTE_STR(RTE_TRACE_BLOB_LEN_MAX)"]", \
>>> + RTE_STR(uint8_t)); \
>>> +} while (0)
>>> +
>>
>> Why this macro defined here again, it is also defined in 'rte_trace_point.h'
>> already?
>> Is it because of 'register_fn()' in '__rte_trace_point_register()'?
>
> Yes the register happens in this function.
You are not really answering questions.
There are three copy of '#define rte_trace_point_emit_blob(in, len)' one
of them is for doxygen comment, please explain why there are two more
copies of it?
>>
>>> #ifdef __cplusplus
>>> }
>>> #endif
>>> diff --git a/lib/eal/version.map b/lib/eal/version.map index
>>> 7ad12a7dc9..67be24686a 100644
>>> --- a/lib/eal/version.map
>>> +++ b/lib/eal/version.map
>>> @@ -440,6 +440,9 @@ EXPERIMENTAL {
>>> rte_thread_detach;
>>> rte_thread_equal;
>>> rte_thread_join;
>>> +
>>> + # added in 23.03
>>> + __rte_eal_trace_generic_blob;
>>
>> This is not a function but a trace object.
>> I guess it was agreed that trace object not need to be exported, and trace can
>> be found by name?
>
> Yes the export in version.map can be removed. Will remove it in next patch series.
ack.
Will there be a separate patch to remove existing symbols? Although I am
not sure if it will be ABI break.
^ permalink raw reply [relevance 2%]
* RE: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
2023-01-25 10:38 3% ` Jerin Jacob
@ 2023-01-25 16:32 0% ` Naga Harish K, S V
2023-01-28 10:53 0% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Naga Harish K, S V @ 2023-01-25 16:32 UTC (permalink / raw)
To: Jerin Jacob
Cc: jerinj, Carrillo, Erik G, Gujjar, Abhinandan S, dev, Jayatheerthan, Jay
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Wednesday, January 25, 2023 4:08 PM
> To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> Cc: jerinj@marvell.com; Carrillo, Erik G <erik.g.carrillo@intel.com>; Gujjar,
> Abhinandan S <abhinandan.gujjar@intel.com>; dev@dpdk.org;
> Jayatheerthan, Jay <jay.jayatheerthan@intel.com>
> Subject: Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
>
> On Wed, Jan 25, 2023 at 3:22 PM Naga Harish K, S V
> <s.v.naga.harish.k@intel.com> wrote:
> >
> > Hi Jerin,
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > Sent: Wednesday, January 25, 2023 9:42 AM
> > > To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> > > Cc: jerinj@marvell.com; Carrillo, Erik G
> > > <erik.g.carrillo@intel.com>; Gujjar, Abhinandan S
> > > <abhinandan.gujjar@intel.com>; dev@dpdk.org; Jayatheerthan, Jay
> > > <jay.jayatheerthan@intel.com>
> > > Subject: Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
> > >
> > > On Tue, Jan 24, 2023 at 6:37 PM Naga Harish K, S V
> > > <s.v.naga.harish.k@intel.com> wrote:
> > > >
> > > > Hi Jerin,
> > > >
> > > > > -----Original Message-----
> > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > Sent: Tuesday, January 24, 2023 10:00 AM
> > > > > To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> > > > > Cc: jerinj@marvell.com; Carrillo, Erik G
> > > > > <erik.g.carrillo@intel.com>; Gujjar, Abhinandan S
> > > > > <abhinandan.gujjar@intel.com>; dev@dpdk.org; Jayatheerthan, Jay
> > > > > <jay.jayatheerthan@intel.com>
> > > > > Subject: Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get
> > > > > APIs
> > > > >
> > > > > On Mon, Jan 23, 2023 at 11:35 PM Naga Harish K S V
> > > > > <s.v.naga.harish.k@intel.com> wrote:
> > > > > >
> > > > > > The adapter configuration parameters defined in the ``struct
> > > > > > rte_event_eth_rx_adapter_runtime_params`` can be configured
> > > > > > and retrieved using
> > > > > > ``rte_event_eth_rx_adapter_runtime_params_set``
> > > > > > and ``rte_event_eth_tx_adapter_runtime_params_get``
> respectively.
> > > > > >
> > > > > > Signed-off-by: Naga Harish K S V <s.v.naga.harish.k@intel.com>
> > > > >
> > > > > > diff --git
> > > > > > a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> > > > > > b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> > > > > > index 461eca566f..2207d6ffc3 100644
> > > > > > --- a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> > > > > > +++ b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> > > > > > @@ -185,6 +185,26 @@ flags for handling received packets,
> > > > > > event queue identifier, scheduler type, event priority,
> > > > > > polling frequency of the receive queue and flow identifier in
> > > > > > struct
> > > > > ``rte_event_eth_rx_adapter_queue_conf``.
> > > > > >
> > > > > > +Set/Get adapter runtime configuration parameters
> > > > > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > > +
> > > > > > +The runtime configuration parameters of adapter can be
> > > > > > +set/read using
> > > > > > +``rte_event_eth_rx_adapter_runtime_params_set()`` and
> ``rte_event_eth_rx_adapter_runtime_params_get()`` respectively.
> > > > > > +The parameters that can be set/read are defined in ``struct
> > > > > rte_event_eth_rx_adapter_runtime_params``.
> > > > >
> > > > > Good.
> > > > >
> > > > > > +
> > > > > > +``rte_event_eth_rx_adapter_create()`` or
> > > > > > +``rte_event_eth_rx_adapter_create_with_params()`` configures
> > > > > > +the adapter with default value for maximum packets processed
> > > > > > +per request to
> > > > > 128.
> > > > > > +``rte_event_eth_rx_adapter_runtime_params_set()`` function
> > > > > > +allows to reconfigure maximum number of packets processed by
> > > > > > +adapter per service request. This is alternative to
> > > > > > +configuring the maximum packets processed per request by
> > > > > > +adapter by using ``rte_event_eth_rx_adapter_create_ext()``
> > > > > > +with parameter
> > > > > ``rte_event_eth_rx_adapter_conf::max_nb_rx``.
> > > > >
> > > > > This paragraph is not needed IMO. As it is specific to a driver,
> > > > > and we can keep Doxygen comment only.
> > > > >
> > > > >
> > > > > > +
> > > > > > +``rte_event_eth_rx_adapter_runtime_parmas_get()`` function
> > > > > > +retrieves the configuration parameters that are defined in
> > > > > > +``struct
> > > > > rte_event_eth_rx_adapter_runtime_params``.
> > > > >
> > > > > Good.
> > > > >
> > > > > > +
> > > > > > Getting and resetting Adapter queue stats
> > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > >
> > > > > > diff --git a/lib/eventdev/rte_event_eth_rx_adapter.c
> > > > > > b/lib/eventdev/rte_event_eth_rx_adapter.c
> > > > > > index 34aa87379e..d8f3e750b7 100644
> > > > > > --- a/lib/eventdev/rte_event_eth_rx_adapter.c
> > > > > > +++ b/lib/eventdev/rte_event_eth_rx_adapter.c
> > > > > > @@ -35,6 +35,8 @@
> > > > > > #define MAX_VECTOR_NS 1E9
> > > > > > #define MIN_VECTOR_NS 1E5
> > > > > >
> > > > > > +#define RXA_NB_RX_WORK_DEFAULT 128
> > > > > > +
> > > > > > #define ETH_RX_ADAPTER_SERVICE_NAME_LEN 32
> > > > > > #define ETH_RX_ADAPTER_MEM_NAME_LEN 32
> > > > > >
> > > > > > @@ -1554,7 +1556,7 @@ rxa_default_conf_cb(uint8_t id, uint8_t
> > > dev_id,
> > > > > > }
> > > > > >
> > > > > > conf->event_port_id = port_id;
> > > > > > - conf->max_nb_rx = 128;
> > > > > > + conf->max_nb_rx = RXA_NB_RX_WORK_DEFAULT;
> > > > > > if (started)
> > > > > > ret = rte_event_dev_start(dev_id);
> > > > > > rx_adapter->default_cb_arg = 1; @@ -3436,6 +3438,90 @@
> > > > > > rte_event_eth_rx_adapter_instance_get(uint16_t eth_dev_id,
> > > > > > return -EINVAL;
> > > > > > }
> > > > >
> > > > > > +
> > > > > > +int
> > > > > > +rte_event_eth_rx_adapter_runtime_params_set(uint8_t id,
> > > > > > + struct rte_event_eth_rx_adapter_runtime_params
> > > > > > +*params) {
> > > > > > + struct event_eth_rx_adapter *rxa;
> > > > > > + int ret;
> > > > > > +
> > > > > > + if (params == NULL)
> > > > > > + return -EINVAL;
> > > > > > +
> > > > > > + if (rxa_memzone_lookup())
> > > > > > + return -ENOMEM;
> > > > >
> > > > > Introduce an adapter callback and move SW adapter related logic
> > > > > under callback handler.
> > > > >
> > > > >
> > > > Do you mean introducing eventdev PMD callback for HW
> implementation?
> > >
> > > Yes.
> > >
> >
> > Can this be taken care as and when the HW implementation is required?
>
> OK. As long as when case INTERNAL PORT it return -ENOSUP now.
>
> >
> > > > There are no adapter callback currently for service based SW
> > > Implementation.
> > > >
> > > > > > +
> > > > > > + rxa = rxa_id_to_adapter(id);
> > > > > > + if (rxa == NULL)
> > > > > > + return -EINVAL;
> > > > > > +
> > > > > > + ret = rxa_caps_check(rxa);
> > > > > > + if (ret)
> > > > > > + return ret;
> > > > > > +
> > > > > > + rte_spinlock_lock(&rxa->rx_lock);
> > > > > > + rxa->max_nb_rx = params->max_nb_rx;
> > > > > > + rte_spinlock_unlock(&rxa->rx_lock);
> > > > > > +
> > > > > > + return 0;
> > > > > > +}
> > > > > > +
> > > > > > +int
> > > > > > +rte_event_eth_rx_adapter_runtime_params_get(uint8_t id,
> > > > > > + struct rte_event_eth_rx_adapter_runtime_params
> > > > > > +*params) {
> > > > > > + struct event_eth_rx_adapter *rxa;
> > > > > > + int ret;
> > > > > > +
> > > > > > + if (params == NULL)
> > > > > > + return -EINVAL;
> > > > >
> > > > >
> > > > > Introduce an adapter callback and move SW adapter related logic
> > > > > under callback handler.
> > > > >
> > > > >
> > > >
> > > > Same as above
> > > >
> > > > > > +
> > > > > > + if (rxa_memzone_lookup())
> > > > > > + return -ENOMEM;
> > > > > +
> > > > > > + rxa = rxa_id_to_adapter(id);
> > > > > > + if (rxa == NULL)
> > > > > > + return -EINVAL;
> > > > > > +
> > > > > > + ret = rxa_caps_check(rxa);
> > > > > > + if (ret)
> > > > > > + return ret;
> > > > > > +
> > > > > > + params->max_nb_rx = rxa->max_nb_rx;
> > > > > > +
> > > > > > + return 0;
> > > > > > +}
> > > > > > +
> > > > > > +/* RX-adapter telemetry callbacks */
> > > > > > #define RXA_ADD_DICT(stats, s) rte_tel_data_add_dict_u64(d,
> > > > > > #s,
> > > > > > stats.s)
> > > > > >
> > > > > > static int
> > > > > > diff --git a/lib/eventdev/rte_event_eth_rx_adapter.h
> > > > > > b/lib/eventdev/rte_event_eth_rx_adapter.h
> > > > > > index f4652f40e8..214ffd018c 100644
> > > > > > --- a/lib/eventdev/rte_event_eth_rx_adapter.h
> > > > > > +++ b/lib/eventdev/rte_event_eth_rx_adapter.h
> > > > > > @@ -39,10 +39,21 @@
> > > > > > * - rte_event_eth_rx_adapter_queue_stats_reset()
> > > > > > * - rte_event_eth_rx_adapter_event_port_get()
> > > > > > * - rte_event_eth_rx_adapter_instance_get()
> > > > > > + * - rte_event_eth_rx_adapter_runtime_params_get()
> > > > > > + * - rte_event_eth_rx_adapter_runtime_params_set()
> > > > > > *
> > > > > > * The application creates an ethernet to event adapter using
> > > > > > * rte_event_eth_rx_adapter_create_ext() or
> > > > > rte_event_eth_rx_adapter_create()
> > > > > > * or rte_event_eth_rx_adapter_create_with_params() functions.
> > > > > > + *
> > > > > > + * rte_event_eth_rx_adapter_create() or
> > > > > > + rte_event_eth_adapter_create_with_params()
> > > > > > + * configures the adapter with default value of maximum
> > > > > > + packets processed per
> > > > > > + * iteration to RXA_NB_RX_WORK_DEFAULT(128).
> > > > > > + * rte_event_eth_rx_adapter_runtime_params_set() allows to
> > > > > > + re-configure maximum
> > > > > > + * packets processed per iteration. This is alternative to
> > > > > > + using
> > > > > > + * rte_event_eth_rx_adapter_create_ext() with parameter
> > > > > > + * rte_event_eth_rx_adapter_conf::max_nb_rx
> > > > >
> > > > > Move this to Doxygen comment against max_nb_rx
> > > > >
> > > > > > + *
> > > > > > * The adapter needs to know which ethernet rx queues to poll
> > > > > > for mbufs as
> > > > > well
> > > > > > * as event device parameters such as the event queue
> > > > > > identifier,
> > > event
> > > > > > * priority and scheduling type that the adapter should use
> > > > > > when constructing @@ -299,6 +310,19 @@ struct
> > > > > rte_event_eth_rx_adapter_params {
> > > > > > /**< flag to indicate that event buffer is separate
> > > > > > for each queue */ };
> > > > > >
> > > > > > +/**
> > > > > > + * Adapter configuration parameters */ struct
> > > > > > +rte_event_eth_rx_adapter_runtime_params {
> > > > > > + uint32_t max_nb_rx;
> > > > > > + /**< The adapter can return early if it has processed at least
> > > > > > + * max_nb_rx mbufs. This isn't treated as a
> > > > > > +requirement; batching
> > > may
> > > > > > + * cause the adapter to process more than max_nb_rx mbufs.
> > > > >
> > > > > Also tell it is valid only for INTERNAL PORT capablity is set.
> > > > >
> > > >
> > > > Do you mean, it is valid only for INTERNAL PORT capability is 'not' set?
> > >
> > > Yes.
> > >
> > > >
> > > > > > + */
> > > > > > + uint32_t rsvd[15];
> > > > > > + /**< Reserved fields for future use */
> > > > >
> > > > > Introduce rte_event_eth_rx_adapter_runtime_params_init() to
> make
> > > > > sure rsvd is zero.
> > > > >
> > > >
> > > > The reserved fields are not used by the adapter or application.
> > > > Not sure Is it necessary to Introduce a new API to clear reserved fields.
> > >
> > > When adapter starts using new fileds(when we add new fieds in
> > > future), the old applicaiton which is not using
> > > rte_event_eth_rx_adapter_runtime_params_init() may have junk value
> > > and then adapter implementation will behave bad.
> > >
> > >
> >
> > does it mean, the application doesn't re-compile for the new DPDK?
>
> Yes. No need recompile if ABI not breaking.
>
> > When some of the reserved fields are used in the future, the application
> also may need to be recompiled along with DPDK right?
> > As the application also may need to use the newly consumed reserved
> fields?
>
> The problematic case is:
>
> Adapter implementation of 23.07(Assuming there is change params) field
> needs to work with application of 23.03.
> rte_event_eth_rx_adapter_runtime_params_init() will sove that.
>
As rte_event_eth_rx_adapter_runtime_params_init() initializes only reserved fields to zero, it may not solve the issue in this case.
The old application only tries to set/get previous valid fields and the newly used fields may still contain junk value.
If the application wants to make use of any the newly used params, the application changes are required anyway.
> >
> > > >
> > > > > > +};
> > > > > > +
> > > > > > /**
> > > > > > *
> > > > > > * Callback function invoked by the SW adapter before it
> > > > > > continues @@
> > > > > > -377,7 +401,7 @@ int
> > > > > > rte_event_eth_rx_adapter_create_ext(uint8_t
> > > > > > id,
> > > > > uint8_t dev_id,
> > > > > > * Create a new ethernet Rx event adapter with the specified
> > > identifier.
> > > > > > * This function uses an internal configuration function that
> > > > > > creates an
> > > event
> > > > > > * port. This default function reconfigures the event device
> > > > > > with an
> > > > > > - * additional event port and setups up the event port using
> > > > > > the port_config
> > > > > > + * additional event port and setup the event port using the
> > > > > > + port_config
> > > > > > * parameter passed into this function. In case the
> > > > > > application needs
> > > more
> > > > > > * control in configuration of the service, it should use the
> > > > > > * rte_event_eth_rx_adapter_create_ext() version.
> > > > > > @@ -743,6 +767,50 @@
> > > > > > rte_event_eth_rx_adapter_instance_get(uint16_t
> > > > > eth_dev_id,
> > > > > > uint16_t rx_queue_id,
> > > > > > uint8_t *rxa_inst_id);
> > > > > >
^ permalink raw reply [relevance 0%]
* deprecation notice process / clarification
@ 2023-01-25 22:36 3% Tyler Retzlaff
2023-01-27 12:47 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Tyler Retzlaff @ 2023-01-25 22:36 UTC (permalink / raw)
To: dev
hi,
i'm looking for some guidance when cleaning up / removing the remaining
shim functions for pthread in windows and i'm not sure how our
deprecation notice / policies apply.
windows has been providing lib/eal/windows/include/pthread.h shim that
allowed applications to use e.g. pthread_xxx functions on windows.
these shim functions were all being provided as inline functions and
were not part of the EAL api but on windows they were implicitly part of
the api surface exposed (to windows only). on posix platforms applications
did not rely on EAL for pthread abi or api (obviously).
recently we introduced a set of platform agnostic thread api in the EAL.
the functions were marked __rte_experimental as a part of new API
addition policy.
what's the most appropriate way to remove the pthread_xxx shim inline
functions from lib/eal/windows/include/pthread.h? do we have to wait the
full deprecation notice period which can't be started until we make the
new functions stable? also keeping in mind we can't actually mark inline
functions __rte_deprecated.
is this a special case where we can just rip them out and break
compilation?
input is appreciated, particularly from any consumers of the windows
port who might be unhappy.
thanks
^ permalink raw reply [relevance 3%]
* Re: deprecation notice process / clarification
2023-01-25 22:36 3% deprecation notice process / clarification Tyler Retzlaff
@ 2023-01-27 12:47 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2023-01-27 12:47 UTC (permalink / raw)
To: Tyler Retzlaff; +Cc: dev
25/01/2023 23:36, Tyler Retzlaff:
> hi,
>
> i'm looking for some guidance when cleaning up / removing the remaining
> shim functions for pthread in windows and i'm not sure how our
> deprecation notice / policies apply.
>
> windows has been providing lib/eal/windows/include/pthread.h shim that
> allowed applications to use e.g. pthread_xxx functions on windows.
>
> these shim functions were all being provided as inline functions and
> were not part of the EAL api but on windows they were implicitly part of
> the api surface exposed (to windows only). on posix platforms applications
> did not rely on EAL for pthread abi or api (obviously).
>
> recently we introduced a set of platform agnostic thread api in the EAL.
> the functions were marked __rte_experimental as a part of new API
> addition policy.
>
> what's the most appropriate way to remove the pthread_xxx shim inline
> functions from lib/eal/windows/include/pthread.h? do we have to wait the
> full deprecation notice period which can't be started until we make the
> new functions stable? also keeping in mind we can't actually mark inline
> functions __rte_deprecated.
>
> is this a special case where we can just rip them out and break
> compilation?
Probably yes.
> input is appreciated, particularly from any consumers of the windows
> port who might be unhappy.
I think there is not too much users of Windows DPDK yet.
I would be in favor of just removing the pthread shim layer
for Windows when rte_thread equivalent is declared stable.
^ permalink raw reply [relevance 0%]
* Re: [PATCH V4 0/5] app/testpmd: support mulitple process attach and detach port
2023-01-19 14:35 0% ` Thomas Monjalon
@ 2023-01-28 1:39 0% ` lihuisong (C)
0 siblings, 0 replies; 200+ results
From: lihuisong (C) @ 2023-01-28 1:39 UTC (permalink / raw)
To: Thomas Monjalon, Ferruh Yigit
Cc: dev, andrew.rybchenko, liudongdong3, huangdaode, fengchengwen
在 2023/1/19 22:35, Thomas Monjalon 写道:
> 19/01/2023 11:31, lihuisong (C):
>> 在 2023/1/18 22:12, Thomas Monjalon 写道:
>>> 11/01/2023 11:46, Ferruh Yigit:
>>>> On 1/11/2023 10:27 AM, Ferruh Yigit wrote:
>>>>> On 1/11/2023 12:53 AM, lihuisong (C) wrote:
>>>>>> 在 2023/1/11 0:51, Ferruh Yigit 写道:
>>>>>>> Hi Huisong,
>>>>>>>
>>>>>>> I haven't checked the patch in detail yet, but I can see it gives some
>>>>>>> ABI compatibility warnings, is this expected:
>>>>>> This is to be expected. Because we insert a device state,
>>>>>> RTE_ETH_DEV_ALLOCATED,
>>>>>> before RTE_ETH_DEV_ATTACHED for resolving the issue patch 2/5 mentioned.
>>>>>> We may have to announce it. What do you think?
>>>>> If there is an actual ABI break, it can't go in this release, need to
>>>>> wait LTS release and yes needs deprecation notice in advance.
>>>>>
>>>>> But not all enum value change warnings are real break, need to
>>>>> investigate all warnings one by one.
>>>>> Need to investigate if old application & new dpdk library may cause any
>>>>> unexpected behavior for application.
>>>>>
>>>> OR, appending new enum item, `RTE_ETH_DEV_ALLOCATED`, to the end of the
>>>> enum solves the issue, although logically it won't look nice.
>>>> Perhaps order can be fixed in next LTS, to have more logical order, but
>>>> not quite sure if order worth the disturbance may cause in application.
>>> It is a state with a logical order, so it would be nice to be able to do
>>> if (state > RTE_ETH_DEV_ALLOCATED)
>>> but given there is RTE_ETH_DEV_REMOVED later in the enum, not sure it is useful.
>> The device state is internel. Applications should not access it
>> directly, right?
> Right
>
>> Currently, ethdev layer or PMD use it by enum value instead of the way like
>> 'state > RTE_ETH_DEV_ALLOCATED'.
> Right
>
>> But, I encapsulated an API, rte_eth_dev_is_used(), for ethdev or PMD to
>> call.
>> I'm not sure if it can help to eliminate our concerns.
> Yes I think it's OK.
ok, I will fix it based on our discussion.
>
>
> .
^ permalink raw reply [relevance 0%]
* Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
2023-01-25 16:32 0% ` Naga Harish K, S V
@ 2023-01-28 10:53 0% ` Jerin Jacob
2023-01-28 17:21 3% ` Stephen Hemminger
2023-01-30 9:56 0% ` Naga Harish K, S V
0 siblings, 2 replies; 200+ results
From: Jerin Jacob @ 2023-01-28 10:53 UTC (permalink / raw)
To: Naga Harish K, S V
Cc: jerinj, Carrillo, Erik G, Gujjar, Abhinandan S, dev, Jayatheerthan, Jay
On Wed, Jan 25, 2023 at 10:02 PM Naga Harish K, S V
<s.v.naga.harish.k@intel.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > >
> > > > > > > + */
> > > > > > > + uint32_t rsvd[15];
> > > > > > > + /**< Reserved fields for future use */
> > > > > >
> > > > > > Introduce rte_event_eth_rx_adapter_runtime_params_init() to
> > make
> > > > > > sure rsvd is zero.
> > > > > >
> > > > >
> > > > > The reserved fields are not used by the adapter or application.
> > > > > Not sure Is it necessary to Introduce a new API to clear reserved fields.
> > > >
> > > > When adapter starts using new fileds(when we add new fieds in
> > > > future), the old applicaiton which is not using
> > > > rte_event_eth_rx_adapter_runtime_params_init() may have junk value
> > > > and then adapter implementation will behave bad.
> > > >
> > > >
> > >
> > > does it mean, the application doesn't re-compile for the new DPDK?
> >
> > Yes. No need recompile if ABI not breaking.
> >
> > > When some of the reserved fields are used in the future, the application
> > also may need to be recompiled along with DPDK right?
> > > As the application also may need to use the newly consumed reserved
> > fields?
> >
> > The problematic case is:
> >
> > Adapter implementation of 23.07(Assuming there is change params) field
> > needs to work with application of 23.03.
> > rte_event_eth_rx_adapter_runtime_params_init() will sove that.
> >
>
> As rte_event_eth_rx_adapter_runtime_params_init() initializes only reserved fields to zero, it may not solve the issue in this case.
rte_event_eth_rx_adapter_runtime_params_init() needs to zero all
fields, not just reserved field.
The application calling sequence is
struct my_config c;
rte_event_eth_rx_adapter_runtime_params_init(&c)
c.interseted_filed_to_be_updated = val;
Let me share an example and you can tell where is the issue
1)Assume parameter structure is 64B and for 22.03 8B are used.
2)rte_event_eth_rx_adapter_runtime_params_init() will clear all 64B.
3)There is an application written based on 22.03 which using only 8B
after calling rte_event_eth_rx_adapter_runtime_params_init()
4)Assume, in 22.07 another 8B added to structure.
5)Now, the application (3) needs to run on 22.07. Since the
application is calling rte_event_eth_rx_adapter_runtime_params_init()
and 9 to 15B are zero, the implementation will not go bad.
> The old application only tries to set/get previous valid fields and the newly used fields may still contain junk value.
> If the application wants to make use of any the newly used params, the application changes are required anyway.
Yes. If application wants to make use of newly added features. No need
to change if new features are not needed for old application.
^ permalink raw reply [relevance 0%]
* [PATCH 2/2] ethdev: introduce the mhpsdp hwport field in Tx queue API
@ 2023-01-28 13:08 2% ` Jiawei Wang
0 siblings, 0 replies; 200+ results
From: Jiawei Wang @ 2023-01-28 13:08 UTC (permalink / raw)
To: viacheslavo, orika, thomas, Aman Singh, Yuying Zhang,
Ferruh Yigit, Andrew Rybchenko
Cc: dev, rasland
For the multiple hardware ports connect to a single DPDK port (mhpsdp),
the previous patch introduces the new rte flow item to match the
hardware port of the received packets.
This patch adds the tx_mhpsdp_hwport setting in Tx queue API, the hwport
value reflects packets be sent to which hardware port.
0 is no port assigned and traffic will be routed between different hardware
ports, if 0 is disabled then try to match on MHPSDP_HW_PORT with 0 will
result in an error.
Adds the new tx_mhpsdp_hwport field into the padding hole of rte_eth_txconf
structure, the size of rte_eth_txconf keeps the same. Adds a suppress
type for structure change in the ABI check file.
This patch adds the testpmd command line:
testpmd> port config (port_id) txq (queue_id) mhpsdp_hwport (value)
For example, there're two hardware ports 0 and 1 connected to
a single DPDK port (port id 0), and mhpsdp_hwport 1 stood for
hardware port 0 and mhpsdp_hwport 2 stood for hardware port 1,
used the below command to config tx mhpsdp_hwport for per Tx Queue:
port config 0 txq 0 mhpsdp_hwport 1
port config 0 txq 1 mhpsdp_hwport 1
port config 0 txq 2 mhpsdp_hwport 2
port config 0 txq 3 mhpsdp_hwport 2
These commands config the TxQ index 0 and TxQ index 1 with mhpsdp_hwport 1,
uses TxQ 0 or TxQ 1 send packets, these packets will be sent from the
hardware port 0, and similar with hardware port 1 if sending packets
with TxQ 2 or TxQ 3.
Signed-off-by: Jiawei Wang <jiaweiw@nvidia.com>
---
app/test-pmd/cmdline.c | 84 +++++++++++++++++++++
devtools/libabigail.abignore | 5 ++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 13 ++++
lib/ethdev/rte_ethdev.h | 8 ++
4 files changed, 110 insertions(+)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index b32dc8bfd4..db9ea8b18a 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -764,6 +764,10 @@ static void cmd_help_long_parsed(void *parsed_result,
"port cleanup (port_id) txq (queue_id) (free_cnt)\n"
" Cleanup txq mbufs for a specific Tx queue\n\n"
+
+ "port config (port_id) txq (queue_id) mhpsdp_hwport (value)\n"
+ " Set the hwport value in mhpsdp "
+ "on a specific Tx queue\n\n"
);
}
@@ -12621,6 +12625,85 @@ static cmdline_parse_inst_t cmd_show_port_flow_transfer_proxy = {
}
};
+/* *** configure port txq mhpsdp_hwport value *** */
+struct cmd_config_tx_mhpsdp_hwport {
+ cmdline_fixed_string_t port;
+ cmdline_fixed_string_t config;
+ portid_t portid;
+ cmdline_fixed_string_t txq;
+ uint16_t qid;
+ cmdline_fixed_string_t mhpsdp_hwport;
+ uint16_t value;
+};
+
+static void
+cmd_config_tx_mhpsdp_hwport_parsed(void *parsed_result,
+ __rte_unused struct cmdline *cl,
+ __rte_unused void *data)
+{
+ struct cmd_config_tx_mhpsdp_hwport *res = parsed_result;
+ struct rte_port *port;
+
+ if (port_id_is_invalid(res->portid, ENABLED_WARN))
+ return;
+
+ if (res->portid == (portid_t)RTE_PORT_ALL) {
+ printf("Invalid port id\n");
+ return;
+ }
+
+ port = &ports[res->portid];
+
+ if (strcmp(res->txq, "txq")) {
+ printf("Unknown parameter\n");
+ return;
+ }
+ if (tx_queue_id_is_invalid(res->qid))
+ return;
+
+ port->txq[res->qid].conf.tx_mhpsdp_hwport = res->value;
+
+ cmd_reconfig_device_queue(res->portid, 0, 1);
+}
+
+cmdline_parse_token_string_t cmd_config_tx_mhpsdp_hwport_port =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_tx_mhpsdp_hwport,
+ port, "port");
+cmdline_parse_token_string_t cmd_config_tx_mhpsdp_hwport_config =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_tx_mhpsdp_hwport,
+ config, "config");
+cmdline_parse_token_num_t cmd_config_tx_mhpsdp_hwport_portid =
+ TOKEN_NUM_INITIALIZER(struct cmd_config_tx_mhpsdp_hwport,
+ portid, RTE_UINT16);
+cmdline_parse_token_string_t cmd_config_tx_mhpsdp_hwport_txq =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_tx_mhpsdp_hwport,
+ txq, "txq");
+cmdline_parse_token_num_t cmd_config_tx_mhpsdp_hwport_qid =
+ TOKEN_NUM_INITIALIZER(struct cmd_config_tx_mhpsdp_hwport,
+ qid, RTE_UINT16);
+cmdline_parse_token_string_t cmd_config_tx_mhpsdp_hwport_hwport =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_tx_mhpsdp_hwport,
+ mhpsdp_hwport, "mhpsdp_hwport");
+cmdline_parse_token_num_t cmd_config_tx_mhpsdp_hwport_value =
+ TOKEN_NUM_INITIALIZER(struct cmd_config_tx_mhpsdp_hwport,
+ value, RTE_UINT16);
+
+static cmdline_parse_inst_t cmd_config_tx_mhpsdp_hwport = {
+ .f = cmd_config_tx_mhpsdp_hwport_parsed,
+ .data = (void *)0,
+ .help_str = "port config <port_id> txq <queue_id> mhpsdp_hwport <value>",
+ .tokens = {
+ (void *)&cmd_config_tx_mhpsdp_hwport_port,
+ (void *)&cmd_config_tx_mhpsdp_hwport_config,
+ (void *)&cmd_config_tx_mhpsdp_hwport_portid,
+ (void *)&cmd_config_tx_mhpsdp_hwport_txq,
+ (void *)&cmd_config_tx_mhpsdp_hwport_qid,
+ (void *)&cmd_config_tx_mhpsdp_hwport_hwport,
+ (void *)&cmd_config_tx_mhpsdp_hwport_value,
+ NULL,
+ },
+};
+
/* ******************************************************************************** */
/* list of instructions */
@@ -12851,6 +12934,7 @@ static cmdline_parse_ctx_t builtin_ctx[] = {
(cmdline_parse_inst_t *)&cmd_show_capability,
(cmdline_parse_inst_t *)&cmd_set_flex_is_pattern,
(cmdline_parse_inst_t *)&cmd_set_flex_spec_pattern,
+ (cmdline_parse_inst_t *)&cmd_config_tx_mhpsdp_hwport,
NULL,
};
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 7a93de3ba1..cbbde4ef05 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -20,6 +20,11 @@
[suppress_file]
soname_regexp = ^librte_.*mlx.*glue\.
+; Ignore fields inserted in middle padding of rte_eth_txconf
+[suppress_type]
+ name = rte_eth_txconf
+ has_data_member_inserted_between = {offset_after(tx_deferred_start), offset_of(offloads)}
+
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Experimental APIs exceptions ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 7be7c55d63..a05fd0e7d0 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -1605,6 +1605,19 @@ Enable or disable a per queue Tx offloading only on a specific Tx queue::
This command should be run when the port is stopped, or else it will fail.
+config per queue Tx mhpsdp_hwport
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Configure a mhpsdp_hwport value per queue Tx offloading only on a specific Tx queue::
+
+ testpmd> port (port_id) txq (queue_id) mhpsdp_hwport (value)
+
+* ``mhpsdp_hwport``: reflects packet can be sent to which hardware port.
+ uses it on multiple hardware ports connect to
+ a single DPDK port (mhpsdp).
+
+This command should be run when the port is stopped, or else it will fail.
+
Config VXLAN Encap outer layers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index c129ca1eaf..c1cef9e21d 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -1138,6 +1138,14 @@ struct rte_eth_txconf {
less free descriptors than this value. */
uint8_t tx_deferred_start; /**< Do not start queue with rte_eth_dev_start(). */
+ /**
+ * Hardware port index for mhpsdp.
+ * Value 0 is no port assigned and traffic could be routed between different
+ * hardware ports, if 0 is disabled then try to match on MHPSDP_HW_PORT with
+ * 0 will result in an error.
+ * Value starts from 1 means that the first hw port in the mhpsdp.
+ */
+ uint8_t tx_mhpsdp_hwport;
/**
* Per-queue Tx offloads to be set using RTE_ETH_TX_OFFLOAD_* flags.
* Only offloads set on tx_queue_offload_capa or tx_offload_capa
--
2.18.1
^ permalink raw reply [relevance 2%]
* Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
2023-01-28 10:53 0% ` Jerin Jacob
@ 2023-01-28 17:21 3% ` Stephen Hemminger
2023-01-30 9:56 0% ` Naga Harish K, S V
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2023-01-28 17:21 UTC (permalink / raw)
To: Jerin Jacob
Cc: Naga Harish K, S V, jerinj, Carrillo, Erik G, Gujjar,
Abhinandan S, dev, Jayatheerthan, Jay
On Sat, 28 Jan 2023 16:23:45 +0530
Jerin Jacob <jerinjacobk@gmail.com> wrote:
> > >
> > > Yes. No need recompile if ABI not breaking.
> > >
> > > > When some of the reserved fields are used in the future, the application
> > > also may need to be recompiled along with DPDK right?
> > > > As the application also may need to use the newly consumed reserved
> > > fields?
> > >
> > > The problematic case is:
> > >
> > > Adapter implementation of 23.07(Assuming there is change params) field
> > > needs to work with application of 23.03.
> > > rte_event_eth_rx_adapter_runtime_params_init() will sove that.
> > >
> >
First off, reserved fields are a problematic design choice IMHO (see YAGNI).
Second. any reserved fields can not be used in future unless the
original code enforced that all reserved fields are zero.
Same is true for holes in structs which some times get reused.
You can't use a reserved field without breaking ABI unless the previous
code enforced that the field must be zero.
^ permalink raw reply [relevance 3%]
* RE: [PATCH v2 1/8] ethdev: add IPv6 routing extension header definition
2023-01-20 9:20 0% ` Andrew Rybchenko
@ 2023-01-30 3:46 0% ` Rongwei Liu
1 sibling, 0 replies; 200+ results
From: Rongwei Liu @ 2023-01-30 3:46 UTC (permalink / raw)
To: Andrew Rybchenko, Matan Azrad, Slava Ovsiienko, Ori Kam,
NBU-Contact-Thomas Monjalon (EXTERNAL),
Aman Singh, Yuying Zhang, Ferruh Yigit, Olivier Matz
Cc: dev, Raslan Darawsheh
HI Andrew
BR
Rongwei
> -----Original Message-----
> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> Sent: Friday, January 20, 2023 17:21
> To: Rongwei Liu <rongweil@nvidia.com>; Matan Azrad <matan@nvidia.com>;
> Slava Ovsiienko <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>;
> NBU-Contact-Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Aman
> Singh <aman.deep.singh@intel.com>; Yuying Zhang
> <yuying.zhang@intel.com>; Ferruh Yigit <ferruh.yigit@amd.com>; Olivier
> Matz <olivier.matz@6wind.com>
> Cc: dev@dpdk.org; Raslan Darawsheh <rasland@nvidia.com>
> Subject: Re: [PATCH v2 1/8] ethdev: add IPv6 routing extension header
> definition
>
> External email: Use caution opening links or attachments
>
>
> On 1/19/23 06:11, Rongwei Liu wrote:
> > Add IPv6 routing extension header definition and no TLV support for
> > now.
> >
> > At rte_flow layer, there are new items defined for matching
> > type/nexthdr/segments_left field.
> >
> > Add command line support for IPv6 routing extension header
> > matching: type/nexthdr/segment_list.
> >
> > Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
> > Acked-by: Ori Kam <orika@nvidia.com>
>
> [snip]
>
> > diff --git a/doc/guides/prog_guide/rte_flow.rst
> > b/doc/guides/prog_guide/rte_flow.rst
> > index 3e6242803d..ae99036be0 100644
> > --- a/doc/guides/prog_guide/rte_flow.rst
> > +++ b/doc/guides/prog_guide/rte_flow.rst
> > @@ -1544,6 +1544,15 @@ Matches Color Marker set by a Meter.
> >
> > - ``color``: Metering color marker.
> >
> > +Item: ``IPV6_ROUTING_EXT``
> > +^^^^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +Matches ipv6 routing extension header.
>
> ipv6 -> IPv6
Sure.
>
> > +
> > +- ``next_hdr``: Next layer header type.
> > +- ``type``: IPv6 routing extension header type.
> > +- ``segments_left``: How many IPv6 destination addresses carries on
>
> Why are only 3 fields mentioned above?
>
This is the 1st phase to matching the 1st uint32 of IPv6 routing extension.
No need to match hdr_len since TLV is ignored.
> > +
> > Actions
> > ~~~~~~~
> >
> > diff --git a/doc/guides/rel_notes/release_23_03.rst
> > b/doc/guides/rel_notes/release_23_03.rst
> > index b8c5b68d6c..2a794d598e 100644
> > --- a/doc/guides/rel_notes/release_23_03.rst
> > +++ b/doc/guides/rel_notes/release_23_03.rst
> > @@ -55,6 +55,11 @@ New Features
> > Also, make sure to start the actual text at the margin.
> > =======================================================
> >
> > +* **Added rte_flow support for matching IPv6 routing extension header
> > +fields.**
> > +
> > + Added ``ipv6_routing_ext`` items in rte_flow to match IPv6 routing
> > + extension header
>
> Missing full stop above.
>
Sure
> > +
> >
> > Removed Items
> > -------------
> > @@ -84,6 +89,11 @@ API Changes
> > Also, make sure to start the actual text at the margin.
> > =======================================================
> >
> > +* ethdev: added a new structure:
> > +
> > + - IPv6 routing extension header ``rte_flow_item_ipv6_routing_ext`` and
> > + ``rte_ipv6_routing_ext``
> > +
>
> If I'm not mistaken, additions should not be here. It is not an API change.
>
Checked existing release doc, "ihl" and "version" of IPv4 header is added here but with "net:" prefix.
Do you think it' good to follow?
> >
> > ABI Changes
> > -----------
> > diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c index
> > 7d0c24366c..4074b475c8 100644
> > --- a/lib/ethdev/rte_flow.c
> > +++ b/lib/ethdev/rte_flow.c
> > @@ -76,6 +76,20 @@ rte_flow_item_flex_conv(void *buf, const void *data)
> > return src->length;
> > }
> >
> > +static size_t
> > +rte_flow_item_ipv6_routing_ext_conv(void *buf, const void *data) {
> > + struct rte_flow_item_ipv6_routing_ext *dst = buf;
> > + const struct rte_flow_item_ipv6_routing_ext *src = data;
> > + size_t len;
> > +
> > + len = src->hdr.hdr_len ? src->hdr.hdr_len << 3 :
> > + src->hdr.segments_left << 4;
>
> Compare hdr_len vs 0 explicitly.
> Also I'd add parenthesis around ternary operator values to make it simpler to
> understand.
Sure.
>
> > + if (buf)
>
> Please, compare vs NULL explicitly. May be 'dst' would be better here?
>
> > + rte_memcpy((void *)((uintptr_t)(dst->hdr.segments)),
> > + src->hdr.segments, len);
> > + return len;
> > +}
> > +
Sure.
> > /** Generate flow_item[] entry. */
> > #define MK_FLOW_ITEM(t, s) \
> > [RTE_FLOW_ITEM_TYPE_ ## t] = { \ @@ -157,6 +171,8 @@ static
> > const struct rte_flow_desc_data rte_flow_desc_item[] = {
> > MK_FLOW_ITEM(L2TPV2, sizeof(struct rte_flow_item_l2tpv2)),
> > MK_FLOW_ITEM(PPP, sizeof(struct rte_flow_item_ppp)),
> > MK_FLOW_ITEM(METER_COLOR, sizeof(struct
> > rte_flow_item_meter_color)),
> > + MK_FLOW_ITEM_FN(IPV6_ROUTING_EXT, sizeof(struct
> rte_flow_item_ipv6_routing_ext),
> > + rte_flow_item_ipv6_routing_ext_conv),
> > };
> >
> > /** Generate flow_action[] entry. */ diff --git
> > a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h index
> > b60987db4b..0120d3e7d2 100644
> > --- a/lib/ethdev/rte_flow.h
> > +++ b/lib/ethdev/rte_flow.h
> > @@ -624,6 +624,13 @@ enum rte_flow_item_type {
> > * See struct rte_flow_item_meter_color.
> > */
> > RTE_FLOW_ITEM_TYPE_METER_COLOR,
> > +
> > + /**
> > + * Matches the presence of IPv6 routing extension header.
> > + *
> > + * See struct rte_flow_item_ipv6_routing_ext.
>
> @see
>
Sure. Looks like there are so many existing wrong usages "See struct" in this file.
> > + */
> > + RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT,
> > };
> >
> > /**
> > @@ -873,6 +880,18 @@ struct rte_flow_item_ipv6 {
> > uint32_t reserved:23;
> > };
> >
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this structure may change without prior notice
> > + *
> > + * RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT.
> > + *
> > + * Matches an IPv6 routing extension header.
> > + */
> > +struct rte_flow_item_ipv6_routing_ext {
> > + struct rte_ipv6_routing_ext hdr; };
> > +
>
> What about default mask?
Tried to add default mask declaration in this file but got "unused variable" warning.
Moved it to "cmdline_flow.c" since it' only used in testpmd encap logic.
>
> > /** Default mask for RTE_FLOW_ITEM_TYPE_IPV6. */
> > #ifndef __cplusplus
> > static const struct rte_flow_item_ipv6 rte_flow_item_ipv6_mask = {
> > diff --git a/lib/net/rte_ip.h b/lib/net/rte_ip.h index
> > 9c8e8206f0..158a2f83ce 100644
> > --- a/lib/net/rte_ip.h
> > +++ b/lib/net/rte_ip.h
> > @@ -539,6 +539,27 @@ struct rte_ipv6_hdr {
> > uint8_t dst_addr[16]; /**< IP address of destination host(s). */
> > } __rte_packed;
> >
> > +/**
> > + * IPv6 Routing Extension Header
> > + */
> > +struct rte_ipv6_routing_ext {
> > + uint8_t next_hdr; /**< Protocol, next header. */
> > + uint8_t hdr_len; /**< Header length. */
> > + uint8_t type; /**< Extension header type. */
> > + uint8_t segments_left; /**< Valid segments number. */
> > + __extension__
> > + union {
> > + uint32_t flags;
>
> rte_be32_t ?
Sure.
>
> > + struct {
> > + uint8_t last_entry; /**< The last_entry field of SRH */
> > + uint8_t flag; /**< Packet flag. */
> > + uint16_t tag; /**< Packet tag. */
>
> rte_be16_t
Sure.
>
> > + };
> > + };
> > + __extension__
> > + uint32_t segments[0]; /**< Each hop IPv6 address. */
>
> rte_be32_t
Sure.
>
> > +} __rte_packed;
> > +
> > /* IPv6 vtc_flow: IPv / TC / flow_label */
> > #define RTE_IPV6_HDR_FL_SHIFT 0
> > #define RTE_IPV6_HDR_TC_SHIFT 20
^ permalink raw reply [relevance 0%]
* [PATCH v3 1/8] ethdev: add IPv6 routing extension header definition
@ 2023-01-30 3:59 3% ` Rongwei Liu
0 siblings, 0 replies; 200+ results
From: Rongwei Liu @ 2023-01-30 3:59 UTC (permalink / raw)
To: matan, viacheslavo, orika, thomas, Aman Singh, Yuying Zhang,
Ferruh Yigit, Andrew Rybchenko, Olivier Matz
Cc: dev, rasland
Add IPv6 routing extension header definition and no
TLV support for now.
At rte_flow layer, there are new items defined for matching
type/nexthdr/segments_left field.
Add command line support for IPv6 routing extension header
matching: type/nexthdr/segment_list.
Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
---
app/test-pmd/cmdline_flow.c | 46 ++++++++++++++++++++++++++
doc/guides/prog_guide/rte_flow.rst | 9 +++++
doc/guides/rel_notes/release_23_03.rst | 9 +++++
lib/ethdev/rte_flow.c | 19 +++++++++++
lib/ethdev/rte_flow.h | 19 +++++++++++
lib/net/rte_ip.h | 21 ++++++++++++
6 files changed, 123 insertions(+)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 88108498e0..7a8516829c 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -298,6 +298,10 @@ enum index {
ITEM_IPV6_SRC,
ITEM_IPV6_DST,
ITEM_IPV6_HAS_FRAG_EXT,
+ ITEM_IPV6_ROUTING_EXT,
+ ITEM_IPV6_ROUTING_EXT_TYPE,
+ ITEM_IPV6_ROUTING_EXT_NEXT_HDR,
+ ITEM_IPV6_ROUTING_EXT_SEG_LEFT,
ITEM_ICMP,
ITEM_ICMP_TYPE,
ITEM_ICMP_CODE,
@@ -1326,6 +1330,7 @@ static const enum index next_item[] = {
ITEM_ARP_ETH_IPV4,
ITEM_IPV6_EXT,
ITEM_IPV6_FRAG_EXT,
+ ITEM_IPV6_ROUTING_EXT,
ITEM_ICMP6,
ITEM_ICMP6_ND_NS,
ITEM_ICMP6_ND_NA,
@@ -1435,6 +1440,15 @@ static const enum index item_ipv6[] = {
ITEM_IPV6_SRC,
ITEM_IPV6_DST,
ITEM_IPV6_HAS_FRAG_EXT,
+ ITEM_IPV6_ROUTING_EXT,
+ ITEM_NEXT,
+ ZERO,
+};
+
+static const enum index item_ipv6_routing_ext[] = {
+ ITEM_IPV6_ROUTING_EXT_TYPE,
+ ITEM_IPV6_ROUTING_EXT_NEXT_HDR,
+ ITEM_IPV6_ROUTING_EXT_SEG_LEFT,
ITEM_NEXT,
ZERO,
};
@@ -3844,6 +3858,38 @@ static const struct token token_list[] = {
.args = ARGS(ARGS_ENTRY_BF(struct rte_flow_item_ipv6,
has_frag_ext, 1)),
},
+ [ITEM_IPV6_ROUTING_EXT] = {
+ .name = "ipv6_routing_ext",
+ .help = "match IPv6 routing extension header",
+ .priv = PRIV_ITEM(IPV6_ROUTING_EXT,
+ sizeof(struct rte_flow_item_ipv6_routing_ext)),
+ .next = NEXT(item_ipv6_routing_ext),
+ .call = parse_vc,
+ },
+ [ITEM_IPV6_ROUTING_EXT_TYPE] = {
+ .name = "ext_type",
+ .help = "match IPv6 routing extension header type",
+ .next = NEXT(item_ipv6_routing_ext, NEXT_ENTRY(COMMON_UNSIGNED),
+ item_param),
+ .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_routing_ext,
+ hdr.type)),
+ },
+ [ITEM_IPV6_ROUTING_EXT_NEXT_HDR] = {
+ .name = "ext_next_hdr",
+ .help = "match IPv6 routing extension header next header type",
+ .next = NEXT(item_ipv6_routing_ext, NEXT_ENTRY(COMMON_UNSIGNED),
+ item_param),
+ .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_routing_ext,
+ hdr.next_hdr)),
+ },
+ [ITEM_IPV6_ROUTING_EXT_SEG_LEFT] = {
+ .name = "ext_seg_left",
+ .help = "match IPv6 routing extension header segment left",
+ .next = NEXT(item_ipv6_routing_ext, NEXT_ENTRY(COMMON_UNSIGNED),
+ item_param),
+ .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_routing_ext,
+ hdr.segments_left)),
+ },
[ITEM_ICMP] = {
.name = "icmp",
.help = "match ICMP header",
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 3e6242803d..602fab29d3 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1544,6 +1544,15 @@ Matches Color Marker set by a Meter.
- ``color``: Metering color marker.
+Item: ``IPV6_ROUTING_EXT``
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Matches IPv6 routing extension header.
+
+- ``next_hdr``: Next layer header type.
+- ``type``: IPv6 routing extension header type.
+- ``segments_left``: How many IPv6 destination addresses carries on.
+
Actions
~~~~~~~
diff --git a/doc/guides/rel_notes/release_23_03.rst b/doc/guides/rel_notes/release_23_03.rst
index b8c5b68d6c..8f482301f7 100644
--- a/doc/guides/rel_notes/release_23_03.rst
+++ b/doc/guides/rel_notes/release_23_03.rst
@@ -55,6 +55,11 @@ New Features
Also, make sure to start the actual text at the margin.
=======================================================
+* **Added rte_flow support for matching IPv6 routing extension header fields.**
+
+ Added ``ipv6_routing_ext`` items in rte_flow to match IPv6 routing extension
+ header.
+
Removed Items
-------------
@@ -84,6 +89,10 @@ API Changes
Also, make sure to start the actual text at the margin.
=======================================================
+* net: added a new structure:
+
+ - IPv6 routing extension header ``rte_ipv6_routing_ext``.
+
ABI Changes
-----------
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index 7d0c24366c..5c423db160 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -76,6 +76,23 @@ rte_flow_item_flex_conv(void *buf, const void *data)
return src->length;
}
+static size_t
+rte_flow_item_ipv6_routing_ext_conv(void *buf, const void *data)
+{
+ struct rte_flow_item_ipv6_routing_ext *dst = buf;
+ const struct rte_flow_item_ipv6_routing_ext *src = data;
+ size_t len;
+
+ if (src->hdr.hdr_len)
+ len = src->hdr.hdr_len << 3;
+ else
+ len = src->hdr.segments_left << 4;
+ if (dst == NULL)
+ return 0;
+ rte_memcpy((void *)((uintptr_t)(dst->hdr.segments)), src->hdr.segments, len);
+ return len;
+}
+
/** Generate flow_item[] entry. */
#define MK_FLOW_ITEM(t, s) \
[RTE_FLOW_ITEM_TYPE_ ## t] = { \
@@ -157,6 +174,8 @@ static const struct rte_flow_desc_data rte_flow_desc_item[] = {
MK_FLOW_ITEM(L2TPV2, sizeof(struct rte_flow_item_l2tpv2)),
MK_FLOW_ITEM(PPP, sizeof(struct rte_flow_item_ppp)),
MK_FLOW_ITEM(METER_COLOR, sizeof(struct rte_flow_item_meter_color)),
+ MK_FLOW_ITEM_FN(IPV6_ROUTING_EXT, sizeof(struct rte_flow_item_ipv6_routing_ext),
+ rte_flow_item_ipv6_routing_ext_conv),
};
/** Generate flow_action[] entry. */
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index b60987db4b..9b9018cba2 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -624,6 +624,13 @@ enum rte_flow_item_type {
* See struct rte_flow_item_meter_color.
*/
RTE_FLOW_ITEM_TYPE_METER_COLOR,
+
+ /**
+ * Matches the presence of IPv6 routing extension header.
+ *
+ * @see struct rte_flow_item_ipv6_routing_ext.
+ */
+ RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT,
};
/**
@@ -873,6 +880,18 @@ struct rte_flow_item_ipv6 {
uint32_t reserved:23;
};
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT.
+ *
+ * Matches an IPv6 routing extension header.
+ */
+struct rte_flow_item_ipv6_routing_ext {
+ struct rte_ipv6_routing_ext hdr;
+};
+
/** Default mask for RTE_FLOW_ITEM_TYPE_IPV6. */
#ifndef __cplusplus
static const struct rte_flow_item_ipv6 rte_flow_item_ipv6_mask = {
diff --git a/lib/net/rte_ip.h b/lib/net/rte_ip.h
index 9c8e8206f0..56c151372a 100644
--- a/lib/net/rte_ip.h
+++ b/lib/net/rte_ip.h
@@ -539,6 +539,27 @@ struct rte_ipv6_hdr {
uint8_t dst_addr[16]; /**< IP address of destination host(s). */
} __rte_packed;
+/**
+ * IPv6 Routing Extension Header
+ */
+struct rte_ipv6_routing_ext {
+ uint8_t next_hdr; /**< Protocol, next header. */
+ uint8_t hdr_len; /**< Header length. */
+ uint8_t type; /**< Extension header type. */
+ uint8_t segments_left; /**< Valid segments number. */
+ __extension__
+ union {
+ rte_be32_t flags;
+ struct {
+ uint8_t last_entry; /**< The last_entry field of SRH */
+ uint8_t flag; /**< Packet flag. */
+ rte_be16_t tag; /**< Packet tag. */
+ };
+ };
+ __extension__
+ rte_be32_t segments[0]; /**< Each hop IPv6 address. */
+} __rte_packed;
+
/* IPv6 vtc_flow: IPv / TC / flow_label */
#define RTE_IPV6_HDR_FL_SHIFT 0
#define RTE_IPV6_HDR_TC_SHIFT 20
--
2.27.0
^ permalink raw reply [relevance 3%]
* RE: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
2023-01-28 10:53 0% ` Jerin Jacob
2023-01-28 17:21 3% ` Stephen Hemminger
@ 2023-01-30 9:56 0% ` Naga Harish K, S V
2023-01-30 14:43 0% ` Jerin Jacob
1 sibling, 1 reply; 200+ results
From: Naga Harish K, S V @ 2023-01-30 9:56 UTC (permalink / raw)
To: Jerin Jacob
Cc: jerinj, Carrillo, Erik G, Gujjar, Abhinandan S, dev, Jayatheerthan, Jay
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Saturday, January 28, 2023 4:24 PM
> To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> Cc: jerinj@marvell.com; Carrillo, Erik G <erik.g.carrillo@intel.com>; Gujjar,
> Abhinandan S <abhinandan.gujjar@intel.com>; dev@dpdk.org;
> Jayatheerthan, Jay <jay.jayatheerthan@intel.com>
> Subject: Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
>
> On Wed, Jan 25, 2023 at 10:02 PM Naga Harish K, S V
> <s.v.naga.harish.k@intel.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
>
> > > > > >
> > > > > > > > + */
> > > > > > > > + uint32_t rsvd[15];
> > > > > > > > + /**< Reserved fields for future use */
> > > > > > >
> > > > > > > Introduce rte_event_eth_rx_adapter_runtime_params_init() to
> > > make
> > > > > > > sure rsvd is zero.
> > > > > > >
> > > > > >
> > > > > > The reserved fields are not used by the adapter or application.
> > > > > > Not sure Is it necessary to Introduce a new API to clear reserved
> fields.
> > > > >
> > > > > When adapter starts using new fileds(when we add new fieds in
> > > > > future), the old applicaiton which is not using
> > > > > rte_event_eth_rx_adapter_runtime_params_init() may have junk
> > > > > value and then adapter implementation will behave bad.
> > > > >
> > > > >
> > > >
> > > > does it mean, the application doesn't re-compile for the new DPDK?
> > >
> > > Yes. No need recompile if ABI not breaking.
> > >
> > > > When some of the reserved fields are used in the future, the
> > > > application
> > > also may need to be recompiled along with DPDK right?
> > > > As the application also may need to use the newly consumed
> > > > reserved
> > > fields?
> > >
> > > The problematic case is:
> > >
> > > Adapter implementation of 23.07(Assuming there is change params)
> > > field needs to work with application of 23.03.
> > > rte_event_eth_rx_adapter_runtime_params_init() will sove that.
> > >
> >
> > As rte_event_eth_rx_adapter_runtime_params_init() initializes only
> reserved fields to zero, it may not solve the issue in this case.
>
> rte_event_eth_rx_adapter_runtime_params_init() needs to zero all fields,
> not just reserved field.
> The application calling sequence is
>
> struct my_config c;
> rte_event_eth_rx_adapter_runtime_params_init(&c)
> c.interseted_filed_to_be_updated = val;
>
Can it be done like
struct my_config c = {0};
c.interseted_filed_to_be_updated = val;
and update Doxygen comments to recommend above usage to reset all fields?
This way, rte_event_eth_rx_adapter_runtime_params_init() can be avoided.
> Let me share an example and you can tell where is the issue
>
> 1)Assume parameter structure is 64B and for 22.03 8B are used.
> 2)rte_event_eth_rx_adapter_runtime_params_init() will clear all 64B.
> 3)There is an application written based on 22.03 which using only 8B after
> calling rte_event_eth_rx_adapter_runtime_params_init()
> 4)Assume, in 22.07 another 8B added to structure.
> 5)Now, the application (3) needs to run on 22.07. Since the application is
> calling rte_event_eth_rx_adapter_runtime_params_init()
> and 9 to 15B are zero, the implementation will not go bad.
>
> > The old application only tries to set/get previous valid fields and the newly
> used fields may still contain junk value.
> > If the application wants to make use of any the newly used params, the
> application changes are required anyway.
>
> Yes. If application wants to make use of newly added features. No need to
> change if new features are not needed for old application.
^ permalink raw reply [relevance 0%]
* Re: [PATCH V8 0/8] telemetry: fix data truncation and conversion error and add hex integer API
2023-01-16 12:06 0% ` lihuisong (C)
@ 2023-01-30 10:39 0% ` lihuisong (C)
0 siblings, 0 replies; 200+ results
From: lihuisong (C) @ 2023-01-30 10:39 UTC (permalink / raw)
To: dev, Ferruh Yigit, Andrew Rybchenko
Cc: bruce.richardson, mb, huangdaode, liudongdong3, fengchengwen
Kindly ping.
在 2023/1/16 20:06, lihuisong (C) 写道:
> Hi Ferruh and Andrew,
>
> This patch series optimizes some codes and bug.
> Can you take a look at this patch series?
> If there are no other questions, can it be merged?
>
> Best,
> Huisong
>
> 在 2022/12/19 15:06, Huisong Li 写道:
>> Some lib telemetry interfaces add the 'u32' and 'u64' data by the
>> rte_tel_data_add_dict/array_int API. This may cause data conversion
>> error or data truncation. This patch series uses 'u64' functions to
>> do this.
>>
>> In addition, this patch series introduces two APIs to store unsigned
>> integer values as hexadecimal encoded strings in telemetry library.
>>
>> ---
>> -v8: fix the coding style in patch 7/8
>> -v7: replace sprintf with snprintf in patch 6/8
>> -v6: fix code alignment to keep in line with codes in the file
>> -v5:
>> - drop a refactor patch.
>> - no limit the bit width for xxx_uint_hex API.
>> -v4:
>> - remove 'u32' value type.merg
>> - add padding zero for hexadecimal value
>> -v3: fix a misspelling mistake in commit log.
>> -v2:
>> - fix ABI break warning.
>> - introduce two APIs to store u32 and u64 values as hexadecimal
>> encoded strings.
>>
>> Huisong Li (8):
>> telemetry: move to header to controllable range
>> ethdev: fix possible data truncation and conversion error
>> mempool: fix possible data truncation and conversion error
>> cryptodev: fix possible data conversion error
>> mem: possible data truncation and conversion error
>> telemetry: support adding integer value as hexadecimal
>> test: add test cases for adding hex integer value API
>> ethdev: display capability values in hexadecimal format
>>
>> app/test/test_telemetry_data.c | 150 +++++++++++++++++++++++++++++
>> lib/cryptodev/rte_cryptodev.c | 2 +-
>> lib/eal/common/eal_common_memory.c | 10 +-
>> lib/ethdev/rte_ethdev.c | 19 ++--
>> lib/mempool/rte_mempool.c | 24 ++---
>> lib/telemetry/rte_telemetry.h | 52 +++++++++-
>> lib/telemetry/telemetry_data.c | 73 ++++++++++++++
>> lib/telemetry/version.map | 9 ++
>> 8 files changed, 309 insertions(+), 30 deletions(-)
>>
>
> .
^ permalink raw reply [relevance 0%]
* RE: [EXT] Re: [PATCH v6 1/6] eal: trace: add trace point emit for blob
2023-01-25 16:09 2% ` Ferruh Yigit
@ 2023-01-30 13:35 0% ` Ankur Dwivedi
0 siblings, 0 replies; 200+ results
From: Ankur Dwivedi @ 2023-01-30 13:35 UTC (permalink / raw)
To: Ferruh Yigit, dev
Cc: thomas, david.marchand, mdr, orika, chas3, humin29, linville,
ciara.loftus, qi.z.zhang, mw, mk, shaibran, evgenys, igorch,
chandu, Igor Russkikh, shepard.siegel, ed.czeck, john.miller,
ajit.khaparde, somnath.kotur, Jerin Jacob Kollanukkaran,
Maciej Czekaj [C],
Shijith Thotton, Srisivasubramanian Srinivasan, Harman Kalra,
rahul.lakkireddy, johndale, hyonkim, liudongdong3, yisen.zhuang,
xuanziyang2, cloud.wangxiaoyun, zhouguoyang, simei.su,
wenjun1.wu, qiming.yang, Yuying.Zhang, beilei.xing, xiao.w.wang,
jingjing.wu, junfeng.guo, rosen.xu, Nithin Kumar Dabilpuram,
Kiran Kumar Kokkilagadda, Sunil Kumar Kori,
Satha Koteswara Rao Kottidi, Liron Himi, zr, Radha Chintakuntla,
Veerasenareddy Burru, Sathesh B Edara, matan, viacheslavo,
longli, spinler, chaoyong.he, niklas.soderlund, hemant.agrawal,
sachin.saxena, g.singh, apeksha.gupta, sachin.saxena, aboyer,
Rasesh Mody, Shahed Shaikh, Devendra Singh Rawat,
andrew.rybchenko, jiawenwu, jianwang, jbehrens, maxime.coquelin,
chenbo.xia, steven.webster, matt.peters, bruce.richardson,
mtetsuyah, grive, jasvinder.singh, cristian.dumitrescu, jgrajcia,
mb
>-----Original Message-----
>From: Ferruh Yigit <ferruh.yigit@amd.com>
>Sent: Wednesday, January 25, 2023 9:40 PM
>To: Ankur Dwivedi <adwivedi@marvell.com>; dev@dpdk.org
>Cc: thomas@monjalon.net; david.marchand@redhat.com; mdr@ashroe.eu;
>orika@nvidia.com; chas3@att.com; humin29@huawei.com;
>linville@tuxdriver.com; ciara.loftus@intel.com; qi.z.zhang@intel.com;
>mw@semihalf.com; mk@semihalf.com; shaibran@amazon.com;
>evgenys@amazon.com; igorch@amazon.com; chandu@amd.com; Igor
>Russkikh <irusskikh@marvell.com>; shepard.siegel@atomicrules.com;
>ed.czeck@atomicrules.com; john.miller@atomicrules.com;
>ajit.khaparde@broadcom.com; somnath.kotur@broadcom.com; Jerin Jacob
>Kollanukkaran <jerinj@marvell.com>; Maciej Czekaj [C]
><mczekaj@marvell.com>; Shijith Thotton <sthotton@marvell.com>;
>Srisivasubramanian Srinivasan <srinivasan@marvell.com>; Harman Kalra
><hkalra@marvell.com>; rahul.lakkireddy@chelsio.com; johndale@cisco.com;
>hyonkim@cisco.com; liudongdong3@huawei.com;
>yisen.zhuang@huawei.com; xuanziyang2@huawei.com;
>cloud.wangxiaoyun@huawei.com; zhouguoyang@huawei.com;
>simei.su@intel.com; wenjun1.wu@intel.com; qiming.yang@intel.com;
>Yuying.Zhang@intel.com; beilei.xing@intel.com; xiao.w.wang@intel.com;
>jingjing.wu@intel.com; junfeng.guo@intel.com; rosen.xu@intel.com; Nithin
>Kumar Dabilpuram <ndabilpuram@marvell.com>; Kiran Kumar Kokkilagadda
><kirankumark@marvell.com>; Sunil Kumar Kori <skori@marvell.com>; Satha
>Koteswara Rao Kottidi <skoteshwar@marvell.com>; Liron Himi
><lironh@marvell.com>; zr@semihalf.com; Radha Chintakuntla
><radhac@marvell.com>; Veerasenareddy Burru <vburru@marvell.com>;
>Sathesh B Edara <sedara@marvell.com>; matan@nvidia.com;
>viacheslavo@nvidia.com; longli@microsoft.com; spinler@cesnet.cz;
>chaoyong.he@corigine.com; niklas.soderlund@corigine.com;
>hemant.agrawal@nxp.com; sachin.saxena@oss.nxp.com; g.singh@nxp.com;
>apeksha.gupta@nxp.com; sachin.saxena@nxp.com; aboyer@pensando.io;
>Rasesh Mody <rmody@marvell.com>; Shahed Shaikh
><shshaikh@marvell.com>; Devendra Singh Rawat
><dsinghrawat@marvell.com>; andrew.rybchenko@oktetlabs.ru;
>jiawenwu@trustnetic.com; jianwang@trustnetic.com;
>jbehrens@vmware.com; maxime.coquelin@redhat.com;
>chenbo.xia@intel.com; steven.webster@windriver.com;
>matt.peters@windriver.com; bruce.richardson@intel.com;
>mtetsuyah@gmail.com; grive@u256.net; jasvinder.singh@intel.com;
>cristian.dumitrescu@intel.com; jgrajcia@cisco.com;
>mb@smartsharesystems.com
>Subject: Re: [EXT] Re: [PATCH v6 1/6] eal: trace: add trace point emit for blob
>
>On 1/25/2023 3:02 PM, Ankur Dwivedi wrote:
>>
>>>
>>> ---------------------------------------------------------------------
>>> - On 1/20/2023 8:40 AM, Ankur Dwivedi wrote:
>>>> Adds a trace point emit function for capturing a blob. The blob
>>>> captures the length passed by the application followed by the array.
>>>>
>>>> The maximum blob bytes which can be captured is bounded by
>>>> RTE_TRACE_BLOB_LEN_MAX macro. The value for max blob length macro
>is
>>>> 64 bytes. If the length is less than 64 the remaining trailing bytes
>>>> are set to zero.
>>>>
>>>> This patch also adds test case for emit blob tracepoint function.
>>>>
>>>> Signed-off-by: Ankur Dwivedi <adwivedi@marvell.com>
>>>> ---
>>>> app/test/test_trace.c | 11 ++++++++
>>>> doc/guides/prog_guide/trace_lib.rst | 12 ++++++++
>>>> lib/eal/common/eal_common_trace_points.c | 2 ++
>>>> lib/eal/include/rte_eal_trace.h | 6 ++++
>>>> lib/eal/include/rte_trace_point.h | 32 ++++++++++++++++++++++
>>>> lib/eal/include/rte_trace_point_register.h | 9 ++++++
>>>> lib/eal/version.map | 3 ++
>>>> 7 files changed, 75 insertions(+)
>>>>
>>>> diff --git a/app/test/test_trace.c b/app/test/test_trace.c index
>>>> 6bedf14024..ad4a394a29 100644
>>>> --- a/app/test/test_trace.c
>>>> +++ b/app/test/test_trace.c
>>>> @@ -4,6 +4,7 @@
>>>>
>>>> #include <rte_eal_trace.h>
>>>> #include <rte_lcore.h>
>>>> +#include <rte_random.h>
>>>> #include <rte_trace.h>
>>>>
>>>> #include "test.h"
>>>> @@ -177,7 +178,12 @@ test_fp_trace_points(void) static int
>>>> test_generic_trace_points(void)
>>>> {
>>>> + uint8_t arr[RTE_TRACE_BLOB_LEN_MAX];
>>>> int tmp;
>>>> + int i;
>>>> +
>>>> + for (i = 0; i < RTE_TRACE_BLOB_LEN_MAX; i++)
>>>> + arr[i] = i;
>>>>
>>>> rte_eal_trace_generic_void();
>>>> rte_eal_trace_generic_u64(0x10000000000000);
>>>> @@ -195,6 +201,11 @@ test_generic_trace_points(void)
>>>> rte_eal_trace_generic_ptr(&tmp);
>>>> rte_eal_trace_generic_str("my string");
>>>> rte_eal_trace_generic_size_t(sizeof(void *));
>>>> + rte_eal_trace_generic_blob(arr, 0);
>>>> + rte_eal_trace_generic_blob(arr, 17);
>>>> + rte_eal_trace_generic_blob(arr, RTE_TRACE_BLOB_LEN_MAX);
>>>> + rte_eal_trace_generic_blob(arr, rte_rand() %
>>>> + RTE_TRACE_BLOB_LEN_MAX);
>>>> RTE_EAL_TRACE_GENERIC_FUNC;
>>>>
>>>> return TEST_SUCCESS;
>>>> diff --git a/doc/guides/prog_guide/trace_lib.rst
>>>> b/doc/guides/prog_guide/trace_lib.rst
>>>> index 9a8f38073d..3e0ea5835c 100644
>>>> --- a/doc/guides/prog_guide/trace_lib.rst
>>>> +++ b/doc/guides/prog_guide/trace_lib.rst
>>>> @@ -352,3 +352,15 @@ event ID.
>>>> The ``packet.header`` and ``packet.context`` will be written in the
>>>> slow path at the time of trace memory creation. The
>>>> ``trace.header`` and trace payload will be emitted when the tracepoint
>function is invoked.
>>>> +
>>>> +Limitations
>>>> +-----------
>>>> +
>>>> +- The ``rte_trace_point_emit_blob()`` function can capture a
>>>> +maximum blob of
>>>> + length ``RTE_TRACE_BLOB_LEN_MAX`` bytes. The application can call
>>>> + ``rte_trace_point_emit_blob()`` multiple times with length less
>>>> +than or equal to
>>>> + ``RTE_TRACE_BLOB_LEN_MAX``, if it needs to capture more than
>>>> +``RTE_TRACE_BLOB_LEN_MAX``
>>>> + bytes.
>>>> +- If the length passed to the ``rte_trace_point_emit_blob()`` is
>>>> +less than
>>>> + ``RTE_TRACE_BLOB_LEN_MAX``, then the trailing
>>>> +``(RTE_TRACE_BLOB_LEN_MAX - len)``
>>>> + bytes in the trace are set to zero.
>>>> diff --git a/lib/eal/common/eal_common_trace_points.c
>>>> b/lib/eal/common/eal_common_trace_points.c
>>>> index 0b0b254615..051f89809c 100644
>>>> --- a/lib/eal/common/eal_common_trace_points.c
>>>> +++ b/lib/eal/common/eal_common_trace_points.c
>>>> @@ -40,6 +40,8 @@
>>> RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_size_t,
>>>> lib.eal.generic.size_t)
>>>> RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_func,
>>>> lib.eal.generic.func)
>>>> +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_blob,
>>>> + lib.eal.generic.blob)
>>>>
>>>> RTE_TRACE_POINT_REGISTER(rte_eal_trace_alarm_set,
>>>> lib.eal.alarm.set)
>>>> diff --git a/lib/eal/include/rte_eal_trace.h
>>>> b/lib/eal/include/rte_eal_trace.h index 5ef4398230..e0b836eb2f
>>>> 100644
>>>> --- a/lib/eal/include/rte_eal_trace.h
>>>> +++ b/lib/eal/include/rte_eal_trace.h
>>>> @@ -143,6 +143,12 @@ RTE_TRACE_POINT(
>>>> rte_trace_point_emit_string(func);
>>>> )
>>>>
>>>> +RTE_TRACE_POINT(
>>>> + rte_eal_trace_generic_blob,
>>>> + RTE_TRACE_POINT_ARGS(void *in, uint8_t len),
>>>> + rte_trace_point_emit_blob(in, len);
>>>> +)
>>>> +
>>>> #define RTE_EAL_TRACE_GENERIC_FUNC
>>>> rte_eal_trace_generic_func(__func__)
>>>>
>>>> /* Interrupt */
>>>> diff --git a/lib/eal/include/rte_trace_point.h
>>>> b/lib/eal/include/rte_trace_point.h
>>>> index 0f8700974f..aca8344dbf 100644
>>>> --- a/lib/eal/include/rte_trace_point.h
>>>> +++ b/lib/eal/include/rte_trace_point.h
>>>> @@ -144,6 +144,16 @@ _tp _args \
>>>> #define rte_trace_point_emit_ptr(val)
>>>> /** Tracepoint function payload for string datatype */ #define
>>>> rte_trace_point_emit_string(val)
>>>> +/**
>>>> + * Tracepoint function to capture a blob.
>>>> + *
>>>> + * @param val
>>>> + * Pointer to the array to be captured.
>>>> + * @param len
>>>> + * Length to be captured. The maximum supported length is
>>>> + * RTE_TRACE_BLOB_LEN_MAX bytes.
>>>> + */
>>>> +#define rte_trace_point_emit_blob(val, len)
>>>>
>>>
>>> This is just for doxygen right, why doxygen comments are not above
>>> the actual macros but there is a separate #if block for it?
>>
>> The actual macro is within a #ifndef __DOXYGEN__ block. I think that
>> is the reason for including Doxygen comments here.
>
>Thanks for confirming.
>
>Why comments are not as part of actual macro, but there is a separate '#ifdef
>__DOXYGEN__' block?
The actual rte_trace_point_emit_blob macro containing the definition, is inside a #ifdef ALLOW_EXPERIMENTAL_API block, so the doxygen will not get generated for rte_trace_point_emit_blob unless ALLOW_EXPERIMENTAL_API is defined in doxygen config.
Putting the macro in #ifdef __DOXYGEN__ generates doxygen for the macro, even if ALLOW_EXPERIMENTAL_API is not defined.
>
>>>
>>>> #endif /* __DOXYGEN__ */
>>>>
>>>> @@ -152,6 +162,9 @@ _tp _args \
>>>> /** @internal Macro to define event header size. */ #define
>>>> __RTE_TRACE_EVENT_HEADER_SZ sizeof(uint64_t)
>>>>
>>>> +/** Macro to define maximum emit length of blob. */ #define
>>>> +RTE_TRACE_BLOB_LEN_MAX 64
>>>> +
>>>> /**
>>>> * Enable recording events of the given tracepoint in the trace buffer.
>>>> *
>>>> @@ -374,12 +387,31 @@ do { \
>>>> mem = RTE_PTR_ADD(mem, __RTE_TRACE_EMIT_STRING_LEN_MAX);
>>> \ } while
>>>> (0)
>>>>
>>>> +#define rte_trace_point_emit_blob(in, len) \ do { \
>>>> + if (unlikely(in == NULL)) \
>>>> + return; \
>>>> + if (len > RTE_TRACE_BLOB_LEN_MAX) \
>>>> + len = RTE_TRACE_BLOB_LEN_MAX; \
>>>> + __rte_trace_point_emit(len, uint8_t); \
>>>> + memcpy(mem, in, len); \
>>>> + mem = RTE_PTR_ADD(mem, len); \
>>>> + memset(mem, 0, RTE_TRACE_BLOB_LEN_MAX - len); \
>>>> + mem = RTE_PTR_ADD(mem, RTE_TRACE_BLOB_LEN_MAX - len); \
>>>
>>>
>>> Is first memset later memcpy not done because of performance concerns?
>>
>> The memset sets to 0 the unused bytes (RTE_TRACE_BLOB_LEN_MAX - len).
>So memset is done after memcpy.
>
>yep, I can see what is done.
>
>Question is, you can do more simply:
>memset(mem, 0, RTE_TRACE_BLOB_LEN_MAX);
>memcpy(mem, in, len);
>mem = RTE_PTR_ADD(mem, RTE_TRACE_BLOB_LEN_MAX - len);
>
>Why did you prefer the implementation you did, intentionally? If so what is
>the intention, performance concerns?
Yes performance is a concern. If memset is done before memcpy, then,
64 <= number of bytes written <= 128, depending on length value from 0 to 64.
But in memset after memcpy, always 64 bytes will be written.
>
>btw, I want to remind that size of the 'len' can be max 64 bytes.
>
>>>
>>>> +} while (0)
>>>> +
>>>> #else
>>>>
>>>> #define __rte_trace_point_emit_header_generic(t) RTE_SET_USED(t)
>>>> #define __rte_trace_point_emit_header_fp(t) RTE_SET_USED(t) #define
>>>> __rte_trace_point_emit(in, type) RTE_SET_USED(in) #define
>>>> rte_trace_point_emit_string(in) RTE_SET_USED(in)
>>>> +#define rte_trace_point_emit_blob(in, len) \ do { \
>>>> + RTE_SET_USED(in); \
>>>> + RTE_SET_USED(len); \
>>>> +} while (0)
>>>> +
>>>>
>>>> #endif /* ALLOW_EXPERIMENTAL_API */ #endif /*
>>>> _RTE_TRACE_POINT_REGISTER_H_ */ diff --git
>>>> a/lib/eal/include/rte_trace_point_register.h
>>>> b/lib/eal/include/rte_trace_point_register.h
>>>> index a32f4d731b..7efbac8a72 100644
>>>> --- a/lib/eal/include/rte_trace_point_register.h
>>>> +++ b/lib/eal/include/rte_trace_point_register.h
>>>> @@ -47,6 +47,15 @@ do { \
>>>> RTE_STR(in)"[32]", "string_bounded_t"); \ } while (0)
>>>>
>>>> +#define rte_trace_point_emit_blob(in, len) \ do { \
>>>> + RTE_SET_USED(in); \
>>>> + __rte_trace_point_emit(len, uint8_t); \
>>>> + __rte_trace_point_emit_field(RTE_TRACE_BLOB_LEN_MAX, \
>>>> + RTE_STR(in)"["RTE_STR(RTE_TRACE_BLOB_LEN_MAX)"]", \
>>>> + RTE_STR(uint8_t)); \
>>>> +} while (0)
>>>> +
>>>
>>> Why this macro defined here again, it is also defined in 'rte_trace_point.h'
>>> already?
>>> Is it because of 'register_fn()' in '__rte_trace_point_register()'?
>>
>> Yes the register happens in this function.
>
>You are not really answering questions.
>
>There are three copy of '#define rte_trace_point_emit_blob(in, len)' one of
>them is for doxygen comment, please explain why there are two more copies
>of it?
>
The rte_trace_point_emit_blob is used when ALLOW_EXPERIMENTAL_API is defined. One definition is for that. The other is basically a null definition when ALLOW_EXPERIMENTAL_API is not defined.
>>>
>>>> #ifdef __cplusplus
>>>> }
>>>> #endif
>>>> diff --git a/lib/eal/version.map b/lib/eal/version.map index
>>>> 7ad12a7dc9..67be24686a 100644
>>>> --- a/lib/eal/version.map
>>>> +++ b/lib/eal/version.map
>>>> @@ -440,6 +440,9 @@ EXPERIMENTAL {
>>>> rte_thread_detach;
>>>> rte_thread_equal;
>>>> rte_thread_join;
>>>> +
>>>> + # added in 23.03
>>>> + __rte_eal_trace_generic_blob;
>>>
>>> This is not a function but a trace object.
>>> I guess it was agreed that trace object not need to be exported, and
>>> trace can be found by name?
>>
>> Yes the export in version.map can be removed. Will remove it in next patch
>series.
>
>ack.
>
>Will there be a separate patch to remove existing symbols? Although I am not
>sure if it will be ABI break.
I will send a separate patch to remove existing tracepoint symbols.
^ permalink raw reply [relevance 0%]
* Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
2023-01-30 9:56 0% ` Naga Harish K, S V
@ 2023-01-30 14:43 0% ` Jerin Jacob
0 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2023-01-30 14:43 UTC (permalink / raw)
To: Naga Harish K, S V
Cc: jerinj, Carrillo, Erik G, Gujjar, Abhinandan S, dev, Jayatheerthan, Jay
On Mon, Jan 30, 2023 at 3:26 PM Naga Harish K, S V
<s.v.naga.harish.k@intel.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Saturday, January 28, 2023 4:24 PM
> > To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> > Cc: jerinj@marvell.com; Carrillo, Erik G <erik.g.carrillo@intel.com>; Gujjar,
> > Abhinandan S <abhinandan.gujjar@intel.com>; dev@dpdk.org;
> > Jayatheerthan, Jay <jay.jayatheerthan@intel.com>
> > Subject: Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
> >
> > On Wed, Jan 25, 2023 at 10:02 PM Naga Harish K, S V
> > <s.v.naga.harish.k@intel.com> wrote:
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> >
> > > > > > >
> > > > > > > > > + */
> > > > > > > > > + uint32_t rsvd[15];
> > > > > > > > > + /**< Reserved fields for future use */
> > > > > > > >
> > > > > > > > Introduce rte_event_eth_rx_adapter_runtime_params_init() to
> > > > make
> > > > > > > > sure rsvd is zero.
> > > > > > > >
> > > > > > >
> > > > > > > The reserved fields are not used by the adapter or application.
> > > > > > > Not sure Is it necessary to Introduce a new API to clear reserved
> > fields.
> > > > > >
> > > > > > When adapter starts using new fileds(when we add new fieds in
> > > > > > future), the old applicaiton which is not using
> > > > > > rte_event_eth_rx_adapter_runtime_params_init() may have junk
> > > > > > value and then adapter implementation will behave bad.
> > > > > >
> > > > > >
> > > > >
> > > > > does it mean, the application doesn't re-compile for the new DPDK?
> > > >
> > > > Yes. No need recompile if ABI not breaking.
> > > >
> > > > > When some of the reserved fields are used in the future, the
> > > > > application
> > > > also may need to be recompiled along with DPDK right?
> > > > > As the application also may need to use the newly consumed
> > > > > reserved
> > > > fields?
> > > >
> > > > The problematic case is:
> > > >
> > > > Adapter implementation of 23.07(Assuming there is change params)
> > > > field needs to work with application of 23.03.
> > > > rte_event_eth_rx_adapter_runtime_params_init() will sove that.
> > > >
> > >
> > > As rte_event_eth_rx_adapter_runtime_params_init() initializes only
> > reserved fields to zero, it may not solve the issue in this case.
> >
> > rte_event_eth_rx_adapter_runtime_params_init() needs to zero all fields,
> > not just reserved field.
> > The application calling sequence is
> >
> > struct my_config c;
> > rte_event_eth_rx_adapter_runtime_params_init(&c)
> > c.interseted_filed_to_be_updated = val;
> >
> Can it be done like
> struct my_config c = {0};
> c.interseted_filed_to_be_updated = val;
> and update Doxygen comments to recommend above usage to reset all fields?
> This way, rte_event_eth_rx_adapter_runtime_params_init() can be avoided.
Better to have a function for documentation clarity. Similar scheme
already there
in DPDK. See rte_eth_cman_config_init()
>
> > Let me share an example and you can tell where is the issue
> >
> > 1)Assume parameter structure is 64B and for 22.03 8B are used.
> > 2)rte_event_eth_rx_adapter_runtime_params_init() will clear all 64B.
> > 3)There is an application written based on 22.03 which using only 8B after
> > calling rte_event_eth_rx_adapter_runtime_params_init()
> > 4)Assume, in 22.07 another 8B added to structure.
> > 5)Now, the application (3) needs to run on 22.07. Since the application is
> > calling rte_event_eth_rx_adapter_runtime_params_init()
> > and 9 to 15B are zero, the implementation will not go bad.
> >
> > > The old application only tries to set/get previous valid fields and the newly
> > used fields may still contain junk value.
> > > If the application wants to make use of any the newly used params, the
> > application changes are required anyway.
> >
> > Yes. If application wants to make use of newly added features. No need to
> > change if new features are not needed for old application.
^ permalink raw reply [relevance 0%]
* [PATCH v2 2/2] ethdev: introduce the PHY affinity field in Tx queue API
@ 2023-01-30 17:00 2% ` Jiawei Wang
0 siblings, 0 replies; 200+ results
From: Jiawei Wang @ 2023-01-30 17:00 UTC (permalink / raw)
To: viacheslavo, orika, thomas, Aman Singh, Yuying Zhang,
Ferruh Yigit, Andrew Rybchenko
Cc: dev, rasland
For the multiple hardware ports connect to a single DPDK port (mhpsdp),
the previous patch introduces the new rte flow item to match the
phy affinity of the received packets.
This patch adds the tx_phy_affinity setting in Tx queue API, the affinity
value reflects packets be sent to which hardware port.
Value 0 is no affinity and traffic will be routed between different
physical ports, if 0 is disabled then try to match on phy_affinity 0
will result in an error.
Adds the new tx_phy_affinity field into the padding hole of rte_eth_txconf
structure, the size of rte_eth_txconf keeps the same. Adds a suppress
type for structure change in the ABI check file.
This patch adds the testpmd command line:
testpmd> port config (port_id) txq (queue_id) phy_affinity (value)
For example, there're two hardware ports 0 and 1 connected to
a single DPDK port (port id 0), and phy_affinity 1 stood for
hardware port 0 and phy_affinity 2 stood for hardware port 1,
used the below command to config tx phy affinity for per Tx Queue:
port config 0 txq 0 phy_affinity 1
port config 0 txq 1 phy_affinity 1
port config 0 txq 2 phy_affinity 2
port config 0 txq 3 phy_affinity 2
These commands config the TxQ index 0 and TxQ index 1 with phy affinity 1,
uses TxQ 0 or TxQ 1 send packets, these packets will be sent from the
hardware port 0, and similar with hardware port 1 if sending packets
with TxQ 2 or TxQ 3.
Signed-off-by: Jiawei Wang <jiaweiw@nvidia.com>
---
app/test-pmd/cmdline.c | 84 +++++++++++++++++++++
devtools/libabigail.abignore | 5 ++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 13 ++++
lib/ethdev/rte_ethdev.h | 7 ++
4 files changed, 109 insertions(+)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index b32dc8bfd4..768f35cb02 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -764,6 +764,10 @@ static void cmd_help_long_parsed(void *parsed_result,
"port cleanup (port_id) txq (queue_id) (free_cnt)\n"
" Cleanup txq mbufs for a specific Tx queue\n\n"
+
+ "port config (port_id) txq (queue_id) phy_affinity (value)\n"
+ " Set the physical affinity value "
+ "on a specific Tx queue\n\n"
);
}
@@ -12621,6 +12625,85 @@ static cmdline_parse_inst_t cmd_show_port_flow_transfer_proxy = {
}
};
+/* *** configure port txq phy_affinity value *** */
+struct cmd_config_tx_phy_affinity {
+ cmdline_fixed_string_t port;
+ cmdline_fixed_string_t config;
+ portid_t portid;
+ cmdline_fixed_string_t txq;
+ uint16_t qid;
+ cmdline_fixed_string_t phy_affinity;
+ uint16_t value;
+};
+
+static void
+cmd_config_tx_phy_affinity_parsed(void *parsed_result,
+ __rte_unused struct cmdline *cl,
+ __rte_unused void *data)
+{
+ struct cmd_config_tx_phy_affinity *res = parsed_result;
+ struct rte_port *port;
+
+ if (port_id_is_invalid(res->portid, ENABLED_WARN))
+ return;
+
+ if (res->portid == (portid_t)RTE_PORT_ALL) {
+ printf("Invalid port id\n");
+ return;
+ }
+
+ port = &ports[res->portid];
+
+ if (strcmp(res->txq, "txq")) {
+ printf("Unknown parameter\n");
+ return;
+ }
+ if (tx_queue_id_is_invalid(res->qid))
+ return;
+
+ port->txq[res->qid].conf.tx_phy_affinity = res->value;
+
+ cmd_reconfig_device_queue(res->portid, 0, 1);
+}
+
+cmdline_parse_token_string_t cmd_config_tx_phy_affinity_port =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_tx_phy_affinity,
+ port, "port");
+cmdline_parse_token_string_t cmd_config_tx_phy_affinity_config =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_tx_phy_affinity,
+ config, "config");
+cmdline_parse_token_num_t cmd_config_tx_phy_affinity_portid =
+ TOKEN_NUM_INITIALIZER(struct cmd_config_tx_phy_affinity,
+ portid, RTE_UINT16);
+cmdline_parse_token_string_t cmd_config_tx_phy_affinity_txq =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_tx_phy_affinity,
+ txq, "txq");
+cmdline_parse_token_num_t cmd_config_tx_phy_affinity_qid =
+ TOKEN_NUM_INITIALIZER(struct cmd_config_tx_phy_affinity,
+ qid, RTE_UINT16);
+cmdline_parse_token_string_t cmd_config_tx_phy_affinity_hwport =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_tx_phy_affinity,
+ phy_affinity, "phy_affinity");
+cmdline_parse_token_num_t cmd_config_tx_phy_affinity_value =
+ TOKEN_NUM_INITIALIZER(struct cmd_config_tx_phy_affinity,
+ value, RTE_UINT16);
+
+static cmdline_parse_inst_t cmd_config_tx_phy_affinity = {
+ .f = cmd_config_tx_phy_affinity_parsed,
+ .data = (void *)0,
+ .help_str = "port config <port_id> txq <queue_id> phy_affinity <value>",
+ .tokens = {
+ (void *)&cmd_config_tx_phy_affinity_port,
+ (void *)&cmd_config_tx_phy_affinity_config,
+ (void *)&cmd_config_tx_phy_affinity_portid,
+ (void *)&cmd_config_tx_phy_affinity_txq,
+ (void *)&cmd_config_tx_phy_affinity_qid,
+ (void *)&cmd_config_tx_phy_affinity_hwport,
+ (void *)&cmd_config_tx_phy_affinity_value,
+ NULL,
+ },
+};
+
/* ******************************************************************************** */
/* list of instructions */
@@ -12851,6 +12934,7 @@ static cmdline_parse_ctx_t builtin_ctx[] = {
(cmdline_parse_inst_t *)&cmd_show_capability,
(cmdline_parse_inst_t *)&cmd_set_flex_is_pattern,
(cmdline_parse_inst_t *)&cmd_set_flex_spec_pattern,
+ (cmdline_parse_inst_t *)&cmd_config_tx_phy_affinity,
NULL,
};
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 7a93de3ba1..cbbde4ef05 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -20,6 +20,11 @@
[suppress_file]
soname_regexp = ^librte_.*mlx.*glue\.
+; Ignore fields inserted in middle padding of rte_eth_txconf
+[suppress_type]
+ name = rte_eth_txconf
+ has_data_member_inserted_between = {offset_after(tx_deferred_start), offset_of(offloads)}
+
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Experimental APIs exceptions ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 1853030e93..e9f20607a2 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -1605,6 +1605,19 @@ Enable or disable a per queue Tx offloading only on a specific Tx queue::
This command should be run when the port is stopped, or else it will fail.
+config per queue Tx physical affinity
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Configure a per queue physical affinity value only on a specific Tx queue::
+
+ testpmd> port (port_id) txq (queue_id) phy_affinity (value)
+
+* ``phy_affinity``: reflects packet can be sent to which hardware port.
+ uses it on multiple hardware ports connect to
+ a single DPDK port (mhpsdp).
+
+This command should be run when the port is stopped, or else it will fail.
+
Config VXLAN Encap outer layers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index c129ca1eaf..b30467c192 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -1138,6 +1138,13 @@ struct rte_eth_txconf {
less free descriptors than this value. */
uint8_t tx_deferred_start; /**< Do not start queue with rte_eth_dev_start(). */
+ /**
+ * Physical affinity to be set.
+ * Value 0 is no affinity and traffic could be routed between different
+ * physical ports, if 0 is disabled then try to match on phy_affinity 0 will
+ * result in an error.
+ */
+ uint8_t tx_phy_affinity;
/**
* Per-queue Tx offloads to be set using RTE_ETH_TX_OFFLOAD_* flags.
* Only offloads set on tx_queue_offload_capa or tx_offload_capa
--
2.18.1
^ permalink raw reply [relevance 2%]
Results 12001-12200 of ~18000 next (newer) | prev (older) | reverse | sort options + mbox downloads above
-- links below jump to the message on this page --
2021-09-13 8:45 [dpdk-dev] Questions about rte_eth_link_speed_to_str API Min Hu (Connor)
2021-09-16 2:56 ` [dpdk-dev] [RFC] ethdev: improve link speed to string Min Hu (Connor)
2021-09-16 6:22 ` Andrew Rybchenko
2021-09-16 8:16 ` Min Hu (Connor)
2021-09-16 8:21 ` Andrew Rybchenko
2021-09-17 0:43 ` Min Hu (Connor)
2023-01-19 11:41 3% ` Ferruh Yigit
2023-01-19 16:45 0% ` Stephen Hemminger
2022-04-19 9:01 [PATCH] doc: fix typos 'depreciated' instead of 'deprecated' Stephen Coleman
2022-04-19 15:44 ` Ray Kinsella
2022-11-15 16:13 0% ` Thomas Monjalon
2022-04-20 8:16 [PATCH v1 0/5] Direct re-arming of buffers on receive side Feifei Wang
2023-01-04 7:30 ` [PATCH v3 0/3] " Feifei Wang
2023-01-04 7:30 ` [PATCH v3 1/3] ethdev: enable direct rearm with separate API Feifei Wang
2023-01-04 8:21 ` Morten Brørup
2023-01-04 8:51 ` 回复: " Feifei Wang
2023-01-04 10:11 4% ` Morten Brørup
2022-08-29 15:18 [RFC PATCH 0/3] Split logging out of EAL Bruce Richardson
2023-01-20 18:21 ` [PATCH v4 0/3] Split logging functionality " Bruce Richardson
2023-01-22 14:56 4% ` David Marchand
2023-01-23 14:24 3% ` Bruce Richardson
2023-01-23 14:31 3% ` David Marchand
2023-01-23 14:36 0% ` Bruce Richardson
2023-01-23 14:42 0% ` David Marchand
2022-09-15 8:26 [PATCH] cryptodev: add missing algorithm strings Volodymyr Fialko
2022-11-02 10:50 ` Kevin Traynor
2022-11-02 10:58 ` [EXT] " Akhil Goyal
2022-11-02 12:13 4% ` David Marchand
2022-11-02 12:31 0% ` Akhil Goyal
2022-09-29 10:29 [PATCH v2 0/4] add trace points in ethdev library Ankur Dwivedi
2022-12-14 12:10 ` [PATCH v3 1/4] ethdev: add trace points Ferruh Yigit
2022-12-15 6:49 ` Jerin Jacob
2023-01-12 9:10 ` Thomas Monjalon
2023-01-12 9:43 ` trace point symbols Morten Brørup
2023-01-13 11:22 3% ` Jerin Jacob
2022-10-30 11:54 [PATCH] mempool: split statistics from debug Morten Brørup
2022-10-31 11:26 ` [PATCH v2 1/3] " Morten Brørup
2022-10-31 11:26 ` [PATCH v2 3/3] mempool: use cache for frequently updated statistics Morten Brørup
2022-11-02 8:01 ` Mattias Rönnblom
2022-11-02 9:29 ` Morten Brørup
2022-11-02 17:55 0% ` Mattias Rönnblom
2022-11-03 15:47 9% [PATCH 0/2] ABI check updates David Marchand
2022-11-03 15:47 21% ` [PATCH 1/2] devtools: unify configuration for ABI check David Marchand
2022-11-03 15:47 41% ` [PATCH 2/2] devtools: stop depending on libabigail xml format David Marchand
2022-11-05 13:40 [RFC] mempool: zero-copy cache put bulk Morten Brørup
2022-11-05 23:11 ` Honnappa Nagarahalli
2022-11-06 6:57 ` Morten Brørup
2022-11-09 17:57 3% ` Honnappa Nagarahalli
2022-11-09 20:36 0% ` Morten Brørup
2022-11-09 22:45 0% ` Honnappa Nagarahalli
2022-11-10 10:15 0% ` Morten Brørup
2022-11-08 11:25 FW: [PATCH v4 3/3] mempool: use cache for frequently updated stats Morten Brørup
2022-11-08 13:32 ` Thomas Monjalon
2022-11-08 14:30 ` Morten Brørup
2022-11-08 15:51 ` Thomas Monjalon
2022-11-08 15:59 ` Bruce Richardson
2022-11-08 17:38 3% ` Konstantin Ananyev
2022-11-09 5:03 4% ` Morten Brørup
2022-11-09 8:21 0% ` Mattias Rönnblom
2022-11-09 10:19 4% ` Konstantin Ananyev
2022-11-09 11:42 0% ` Morten Brørup
2022-11-17 13:58 Regarding User Data in DPDK ACL Library venkatesh bs
2022-11-17 22:52 ` Stephen Hemminger
2022-11-18 10:30 3% ` Konstantin Ananyev
2022-11-19 13:13 0% ` venkatesh bs
2022-11-21 5:40 0% ` Honnappa Nagarahalli
2022-11-21 14:15 0% ` Konstantin Ananyev
2022-11-21 16:56 0% ` Honnappa Nagarahalli
2022-11-22 13:38 0% ` Konstantin Ananyev
2022-11-22 15:53 0% ` Honnappa Nagarahalli
2022-11-22 13:09 3% [PATCH] net/nfp: update descriptors logic Niklas Söderlund
2022-11-23 10:26 [RFC PATCH 0/4] lcore telemetry improvements Robin Jarry
2022-12-07 16:21 ` [PATCH " Robin Jarry
2022-12-07 16:21 ` [PATCH 2/4] eal: allow applications to report their cpu usage Robin Jarry
2022-12-13 15:49 3% ` Robin Jarry
2022-12-13 16:39 0% ` Morten Brørup
2022-12-13 17:45 0% ` Tyler Retzlaff
2022-11-24 16:56 3% [PATCH v1] doc: update release notes for 22.11 John McNamara
2022-11-27 22:22 4% DPDK 22.11 released Thomas Monjalon
2022-11-28 8:33 11% [PATCH] version: 23.03-rc0 David Marchand
2022-12-01 15:37 0% ` Thomas Monjalon
2022-12-01 15:50 0% ` David Marchand
2022-11-29 14:00 [PATCH] drivers: fix symbol exports when map is omitted David Marchand
2022-11-29 18:23 3% ` Ferruh Yigit
2022-11-30 7:13 4% ` David Marchand
2022-11-30 8:27 0% ` David Marchand
2022-11-30 9:19 0% ` Ferruh Yigit
2022-12-02 11:09 3% ` [PATCH v4 1/2] " David Marchand
2022-12-02 13:39 0% ` Aaron Conole
2022-12-05 10:23 3% ` David Marchand
2022-12-05 10:43 0% ` [EXT] " Akhil Goyal
2022-12-05 12:36 0% ` David Marchand
2022-12-05 13:47 0% ` Akhil Goyal
2022-12-05 15:37 0% ` Thomas Monjalon
2022-12-05 16:26 0% ` Akhil Goyal
2022-12-06 10:12 0% ` Ferruh Yigit
2022-12-06 10:18 ` David Marchand
2022-12-06 12:25 ` Ferruh Yigit
2022-12-07 18:00 5% ` Patrick Robb
2022-12-08 13:22 3% ` Thomas Monjalon
2022-12-08 16:06 0% ` Patrick Robb
2022-11-30 22:54 4% help with pthread_t deprecation / api changes Tyler Retzlaff
2022-12-02 1:12 0% ` Tyler Retzlaff
2022-12-02 8:03 0% ` Morten Brørup
2022-12-02 19:57 ` Tyler Retzlaff
2022-12-09 7:53 ` Thomas Monjalon
2022-12-09 16:48 3% ` Stephen Hemminger
2022-12-09 20:06 0% ` Tyler Retzlaff
2022-12-09 21:14 0% ` Thomas Monjalon
2022-12-09 22:38 0% ` Stephen Hemminger
2022-12-09 23:55 0% ` Tyler Retzlaff
2022-12-01 19:01 3% DPDK Release Status Meeting 2022-12-01 Mcnamara, John
2022-12-02 9:46 4% DPDK 22.11.1 released David Marchand
2022-12-03 17:13 3% mbuf performance optimization Morten Brørup
2022-12-05 20:24 [PATCH 0/3] eal: rte_ctrl_thread_create API replacement Tyler Retzlaff
2022-12-05 20:24 ` [PATCH 3/3] eal: deprecate pthread control thread create API Tyler Retzlaff
2022-12-05 21:18 ` Stephen Hemminger
2022-12-06 0:24 3% ` Tyler Retzlaff
2022-12-06 17:28 ` [PATCH v2 0/3] eal: rte_ctrl_thread_create API replacement Tyler Retzlaff
2022-12-06 17:28 ` [PATCH v2 1/3] eal: add rte control thread create API Tyler Retzlaff
2022-12-07 9:13 ` Mattias Rönnblom
2022-12-07 16:38 3% ` Tyler Retzlaff
2022-12-08 21:59 0% ` Mattias Rönnblom
2022-12-06 5:54 [RFC 2/2] ethdev: add API to set process to primary or secondary Stephen Hemminger
2022-12-21 9:00 ` [RFC v3 0/2] add API to set process to active or standby Rongwei Liu
2022-12-21 9:00 ` [RFC v3 2/2] ethdev: " Rongwei Liu
2022-12-21 9:12 4% ` Jerin Jacob
2022-12-21 9:32 3% ` Rongwei Liu
2022-12-21 10:59 5% ` Jerin Jacob
2022-12-21 12:05 5% ` Rongwei Liu
2022-12-21 12:44 0% ` Jerin Jacob
2022-12-21 12:50 4% ` Rongwei Liu
2022-12-21 13:12 0% ` Jerin Jacob
2022-12-21 14:33 3% ` Rongwei Liu
2022-12-26 16:44 4% ` Ori Kam
2023-01-15 22:46 0% ` Thomas Monjalon
2022-12-06 10:16 4% [PATCH] devtools: update Meson setup command Thomas Monjalon
2022-12-06 11:29 1% 21.11.3 patches review and test Kevin Traynor
2022-12-13 11:48 0% ` Christian Ehrhardt
2022-12-16 7:55 0% ` YangHang Liu
2022-12-06 12:23 [PATCH 1/2] devtools: document test meson script config options Ferruh Yigit
2022-12-06 12:23 17% ` [PATCH 2/2] devtools: configure source repo to use as ABI reference Ferruh Yigit
2022-12-08 18:14 7% ` [EXT] " Akhil Goyal
2022-12-08 19:43 4% ` Thomas Monjalon
2022-12-09 4:16 4% ` Akhil Goyal
2022-12-09 8:22 8% ` David Marchand
2022-12-09 8:44 4% ` Ferruh Yigit
2022-12-09 9:02 ` [PATCH v2 1/2] devtools: document test meson script config options David Marchand
2022-12-09 9:02 13% ` [PATCH v2 2/2] devtools: configure source repo to use as ABI reference David Marchand
2022-12-21 15:02 4% ` David Marchand
2022-12-08 8:05 [PATCH 0/8] fix possible data truncation and conversion error Huisong Li
2022-12-09 11:04 3% ` [PATCH V2 00/11] telemetry: add u32 value type and hex integer string API Huisong Li
2022-12-09 18:24 0% ` Morten Brørup
2022-12-12 6:23 0% ` lihuisong (C)
2022-12-11 9:02 0% ` fengchengwen
2022-12-12 6:42 3% ` [PATCH V3 " Huisong Li
2022-12-12 10:31 0% ` Bruce Richardson
2022-12-12 11:02 0% ` Morten Brørup
2022-12-12 11:20 0% ` Bruce Richardson
2022-12-12 12:03 3% ` Morten Brørup
2022-12-12 12:16 3% ` Bruce Richardson
2022-12-13 11:00 0% ` Morten Brørup
2022-12-13 17:12 3% ` Bruce Richardson
2022-12-13 3:02 0% ` lihuisong (C)
2022-12-13 10:15 3% ` [PATCH V4 0/9] telemetry: fix data truncation and conversion error and add hex integer API Huisong Li
2022-12-14 12:32 3% ` [PATCH V5 0/8] " Huisong Li
2022-12-15 10:31 3% ` [PATCH V6 " Huisong Li
2022-12-16 1:54 3% ` [PATCH V7 " Huisong Li
2022-12-19 7:06 3% ` [PATCH V8 " Huisong Li
2023-01-16 12:06 0% ` lihuisong (C)
2023-01-30 10:39 0% ` lihuisong (C)
2022-12-12 15:10 2% [PATCH] cryptodev: add algo enums to string conversion APIs Akhil Goyal
2022-12-13 7:31 0% ` Ruifeng Wang
2022-12-13 7:37 0% ` Anoob Joseph
2022-12-13 8:22 0% ` Power, Ciara
2022-12-14 9:32 0% ` Zhang, Fan
2023-01-04 6:18 2% ` [PATCH v2] " Akhil Goyal
2023-01-05 10:56 0% ` Akhil Goyal
2022-12-13 15:07 3% [PATCH] ci: drop Travis configuration David Marchand
2022-12-13 18:27 4% [RFC PATCH 0/7] Standardize telemetry int types Bruce Richardson
2022-12-13 18:27 3% ` [RFC PATCH 6/7] telemetry: make internal int representation 64-bits Bruce Richardson
2022-12-13 18:27 3% ` [RFC PATCH 7/7] telemetry: change public API to use 64-bit signed values Bruce Richardson
2022-12-13 20:19 3% ` Morten Brørup
2022-12-14 17:53 0% ` Tyler Retzlaff
2022-12-15 2:39 0% ` lihuisong (C)
2022-12-14 17:38 ` [RFC PATCH 2/7] telemetry: add uint type as alias for u64 Tyler Retzlaff
2022-12-15 9:44 ` Bruce Richardson
2022-12-15 13:36 ` Thomas Monjalon
2022-12-15 13:58 4% ` Bruce Richardson
2022-12-19 10:37 0% ` Thomas Monjalon
2022-12-19 13:22 0% ` Bruce Richardson
2023-01-12 10:58 4% ` [PATCH v2 0/9] Standardize telemetry int types Bruce Richardson
2023-01-12 10:59 3% ` [PATCH v2 8/9] telemetry: make internal int representation 64-bits Bruce Richardson
2023-01-12 10:59 3% ` [PATCH v2 9/9] telemetry: change public API to use 64-bit signed values Bruce Richardson
2023-01-12 17:41 4% ` [PATCH v3 0/9] Standardize telemetry int types Bruce Richardson
2023-01-12 17:41 3% ` [PATCH v3 8/9] telemetry: make internal int representation 64-bits Bruce Richardson
2023-01-12 17:41 3% ` [PATCH v3 9/9] telemetry: change public API to use 64-bit signed values Bruce Richardson
2023-01-13 16:39 0% ` [PATCH v3 0/9] Standardize telemetry int types Power, Ciara
2022-12-20 16:22 1% DPDK 21.11.3 released Kevin Traynor
2022-12-21 8:42 [RFC 1/9] ethdev: add IPv6 routing extension header definition Rongwei Liu
2023-01-19 3:11 ` [PATCH v2 0/8] add IPv6 routing extension support Rongwei Liu
2023-01-19 3:11 3% ` [PATCH v2 1/8] ethdev: add IPv6 routing extension header definition Rongwei Liu
2023-01-20 9:20 0% ` Andrew Rybchenko
2023-01-30 3:46 0% ` Rongwei Liu
2023-01-30 3:59 ` [PATCH v3 0/8] add IPv6 routing extension support Rongwei Liu
2023-01-30 3:59 3% ` [PATCH v3 1/8] ethdev: add IPv6 routing extension header definition Rongwei Liu
2022-12-21 10:29 [RFC 0/5] add new port affinity item and affinity in Tx queue API Jiawei Wang
2022-12-21 10:29 2% ` [RFC 2/5] ethdev: introduce the affinity field " Jiawei Wang
2023-01-11 16:47 0% ` Ori Kam
2023-01-18 11:37 0% ` Thomas Monjalon
2023-01-18 14:44 0% ` Jiawei(Jonny) Wang
2023-01-18 16:31 0% ` Thomas Monjalon
2023-01-24 13:32 0% ` Jiawei(Jonny) Wang
2023-01-07 13:39 33% [PATCH] devtools: parallelize ABI check Thomas Monjalon
2023-01-09 9:34 23% ` [PATCH v2] " Thomas Monjalon
2023-01-10 11:08 4% ` Ferruh Yigit
2023-01-11 13:16 33% ` [PATCH v3] " Thomas Monjalon
2023-01-11 14:10 4% ` Bruce Richardson
2023-01-11 14:11 4% ` David Marchand
2023-01-11 17:04 4% ` Thomas Monjalon
2023-01-11 19:53 33% ` [PATCH v4] " Thomas Monjalon
2023-01-12 10:53 4% ` David Marchand
2023-01-12 14:14 4% ` Ferruh Yigit
2023-01-18 10:45 4% ` David Marchand
2023-01-18 11:43 4% ` Ferruh Yigit
2023-01-18 14:29 4% ` David Marchand
2023-01-07 16:18 [PATCH 1/3] eventdev/eth_rx: add params set/get APIs Naga Harish K S V
2023-01-18 10:22 4% ` Jerin Jacob
2023-01-20 8:58 0% ` Naga Harish K, S V
2023-01-20 9:32 0% ` Jerin Jacob
2023-01-20 10:33 0% ` Naga Harish K, S V
2023-01-23 9:31 0% ` Jerin Jacob
2023-01-23 18:07 0% ` Naga Harish K, S V
2023-01-23 18:04 ` [PATCH v2 " Naga Harish K S V
2023-01-24 4:29 ` Jerin Jacob
2023-01-24 13:07 ` Naga Harish K, S V
2023-01-25 4:12 ` Jerin Jacob
2023-01-25 9:52 ` Naga Harish K, S V
2023-01-25 10:38 3% ` Jerin Jacob
2023-01-25 16:32 0% ` Naga Harish K, S V
2023-01-28 10:53 0% ` Jerin Jacob
2023-01-28 17:21 3% ` Stephen Hemminger
2023-01-30 9:56 0% ` Naga Harish K, S V
2023-01-30 14:43 0% ` Jerin Jacob
2023-01-09 22:56 RFC abstracting atomics Tyler Retzlaff
2023-01-10 9:16 ` Bruce Richardson
2023-01-10 20:10 3% ` Tyler Retzlaff
2023-01-11 10:10 0% ` Bruce Richardson
[not found] <20220825024425.10534-1-lihuisong@huawei.com>
2022-12-06 9:26 ` [PATCH V4 0/5] app/testpmd: support mulitple process attach and detach port Huisong Li
2023-01-10 16:51 3% ` Ferruh Yigit
2023-01-11 0:53 0% ` lihuisong (C)
2023-01-11 10:27 3% ` Ferruh Yigit
2023-01-11 10:46 0% ` Ferruh Yigit
2023-01-12 2:26 0% ` lihuisong (C)
2023-01-18 14:12 0% ` Thomas Monjalon
2023-01-19 10:31 0% ` lihuisong (C)
2023-01-19 14:35 0% ` Thomas Monjalon
2023-01-28 1:39 0% ` lihuisong (C)
2023-01-12 10:01 [PATCH v3 1/3] pcapng: comment option support for epb Amit Prakash Shukla
2023-01-24 11:21 4% ` [PATCH v4 " Amit Prakash Shukla
2023-01-24 11:21 2% ` [PATCH v4 2/3] graph: pcap capture for graph nodes Amit Prakash Shukla
2023-01-12 11:21 [PATCH v5 0/6] add trace points in ethdev library Ankur Dwivedi
2023-01-20 8:40 ` [PATCH v6 " Ankur Dwivedi
2023-01-20 8:40 ` [PATCH v6 1/6] eal: trace: add trace point emit for blob Ankur Dwivedi
2023-01-23 17:27 ` Ferruh Yigit
2023-01-25 15:02 ` [EXT] " Ankur Dwivedi
2023-01-25 16:09 2% ` Ferruh Yigit
2023-01-30 13:35 0% ` Ankur Dwivedi
2023-01-13 5:03 [RFC] Remove Kernel Network Interface (KNI) Stephen Hemminger
2023-01-13 8:12 ` Thomas Monjalon
2023-01-13 17:13 ` Stephen Hemminger
2023-01-13 18:34 ` Thomas Monjalon
2023-01-13 23:25 ` Stephen Hemminger
2023-01-14 22:21 3% ` Tyler Retzlaff
2023-01-16 15:37 [PATCH 0/5] dma/ioat: fix issues with stopping and restarting device Bruce Richardson
2023-01-16 15:37 3% ` [PATCH 5/5] test/dmadev: add tests for stopping and restarting dev Bruce Richardson
2023-01-16 17:37 ` [PATCH v2 0/6] dma/ioat: fix issues with stopping and restarting device Bruce Richardson
2023-01-16 17:37 3% ` [PATCH v2 6/6] test/dmadev: add tests for stopping and restarting dev Bruce Richardson
2023-01-17 10:16 3% [RFC] Fix cryptodev socket id for devices on unknown NUMA node Didier Pallard
2023-01-17 11:32 0% ` Morten Brørup
2023-01-23 9:02 4% Minutes of Technical Board Meeting, 2022-09-06 Thomas Monjalon
2023-01-23 9:03 4% Minutes of Technical Board Meeting, 2022-11-30 Thomas Monjalon
2023-01-24 10:33 3% DPDK Release Status Meeting 2023-01-19 Mcnamara, John
2023-01-25 22:36 3% deprecation notice process / clarification Tyler Retzlaff
2023-01-27 12:47 0% ` Thomas Monjalon
2023-01-28 13:08 [PATCH 0/2] add new mhpsdp hw port in the flow item and Tx queue API Jiawei Wang
2023-01-28 13:08 2% ` [PATCH 2/2] ethdev: introduce the mhpsdp hwport field in " Jiawei Wang
[not found] <http://patches.dpdk.org/project/dpdk/cover/20221221102934.13822-1-jiaweiw@nvidia.com/>
2023-01-30 17:00 ` [PATCH v2 0/2] add new PHY affinity in the flow item and " Jiawei Wang
2023-01-30 17:00 2% ` [PATCH v2 2/2] ethdev: introduce the PHY affinity field in " Jiawei Wang
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).