* Re: [dpdk-dev] [PATCH] Introduce travis builds for github repositories
@ 2019-01-24 19:51 0% ` Michael Santana Francisco
0 siblings, 0 replies; 200+ results
From: Michael Santana Francisco @ 2019-01-24 19:51 UTC (permalink / raw)
To: Honnappa Nagarahalli
Cc: dev, Aaron Conole, Bruce Richardson, thomas, Ferruh Yigit, nd
That's a good suggestion. I will look into it.
~Michael Santana
On Thu, Jan 24, 2019 at 2:27 PM Honnappa Nagarahalli <
Honnappa.Nagarahalli@arm.com> wrote:
> >
> > GitHub is a service used by developers to store repositories. GitHub
> > provides service integrations that allow 3rd party services to access
> > developer repositories and perform actions. One of these services is
> Travis-
> > CI, a simple continuous integration platform.
> >
> > This is a simple initial implementation of a travis build for the DPDK
> project.
> > It doesn't require any changes from individual developers to enable, but
> will
> > allow those developers who opt-in to GitHub and the travis service to get
> > automatic builds for every push they make.
> >
> > Additionally, the travis service will send an email to the test-report
> list
> > informing anyone interested in the automated build (including a result).
> >
> > Signed-off-by: Aaron Conole <aconole@redhat.com>
> > Signed-off-by: Michael Santana <msantana@redhat.com>
> > ---
> > .ci/linux-build.sh | 34 +++++++++++++++++++++++++
> > .ci/linux-setup.sh | 3 +++
> > .travis.yml | 39 +++++++++++++++++++++++++++++
> > MAINTAINERS | 6 +++++
> > doc/guides/contributing/patches.rst | 3 +++
> > 5 files changed, 85 insertions(+)
> > create mode 100755 .ci/linux-build.sh
> > create mode 100755 .ci/linux-setup.sh
> > create mode 100644 .travis.yml
> >
> > diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh new file mode
> 100755 index
> > 0000000000..2cfaa05058
> > --- /dev/null
> > +++ b/.ci/linux-build.sh
> > @@ -0,0 +1,34 @@
> > +#!/bin/bash
> > +
> > +# check for whether we're clang or gcc
> > +# setup the right options depending on the environment variables # run
> > +the build
> > +
> > +# Just used for the 'classic' configuration system (ie: make)
> > +set_conf() {
> > + c="$1/.config"
> > + shift
> > +
> > + if grep -q "$1" "$c"; then
> > + sed -i "s:^$1=.*$:$1=$2:g" $c
> > + else
> > + echo $1=$2 >> "$c"
> > + fi
> > +}
> > +
> > +
> > +if [ "${NINJABUILD}" == "1" ]; then
> > + meson build
> > + ninja -C build
> > +else
> > + make config T=x86_64-native-linuxapp-${CC}
> Adding Arm builds would be helpful.
>
> > + if [ "${SHARED}" == "1" ]; then
> > + set_conf build CONFIG_RTE_BUILD_SHARED_LIB y
> > + fi
> > +
> > + if [ "${KERNEL}" == "1" ]; then
> > + echo Unsupported kernel builds at the moment
> > + fi
> > +
> > + make all
> > +fi
> > diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh new file mode
> 100755 index
> > 0000000000..6f9849cb94
> > --- /dev/null
> > +++ b/.ci/linux-setup.sh
> > @@ -0,0 +1,3 @@
> > +#!/bin/sh
> > +
> > +python3.5 -m pip install --upgrade meson --user
> > diff --git a/.travis.yml b/.travis.yml
> > new file mode 100644
> > index 0000000000..432d6c9c6c
> > --- /dev/null
> > +++ b/.travis.yml
> > @@ -0,0 +1,39 @@
> > +language: c
> > +compiler:
> > + - gcc
> > + - clang
> > +
> > +os:
> > + - linux
> > +
> > +addons:
> > + apt:
> > + sources:
> > + - deadsnakes #source for python 3.5
> > + - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
> > + packages:
> > + - libnuma-dev
> > + - linux-headers-$(uname -r)
> > + - python3.5
> > + - python3-pip
> > + - ninja-build
> > +
> > +before_install: ./.ci/${TRAVIS_OS_NAME}-setup.sh
> > +
> > +sudo: false
> > +
> > +env:
> > + - SHARED=1
> > + - KERNEL=1
> > + - NINJABUILD=1
> > +
> > +matrix:
> > + include:
> > + - compiler: clang
> > +
> > +script: ./.ci/${TRAVIS_OS_NAME}-build.sh
> > +
> > +notifications:
> > + email:
> > + recipients:
> > + - test-report@dpdk.org
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 66104405e5..14a7bf1284 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -119,6 +119,12 @@ F: config/rte_config.h
> > F: buildtools/gen-pmdinfo-cfile.sh
> > F: buildtools/symlink-drivers-solibs.sh
> >
> > +Public CI
> > +M: Aaron Conole <aconole@redhat.com>
> > +M: Michael Santana <msantana@redhat.com>
> > +F: .travis.yml
> > +F: .ci/
> > +
> > ABI versioning
> > M: Neil Horman <nhorman@tuxdriver.com>
> > F: lib/librte_compat/
> > diff --git a/doc/guides/contributing/patches.rst
> > b/doc/guides/contributing/patches.rst
> > index a64bb03683..745a11a67a 100644
> > --- a/doc/guides/contributing/patches.rst
> > +++ b/doc/guides/contributing/patches.rst
> > @@ -32,6 +32,9 @@ The mailing list for DPDK development is
> > `dev@dpdk.org <http://mails.dpdk.org/ar Contributors will need to
> > `register for the mailing list <http://mails.dpdk.org/listinfo/dev>`_
> in order
> > to submit patches.
> > It is also worth registering for the DPDK `Patchwork
> > <http://patches.dpdk.org/project/dpdk/list/>`_
> >
> > +If you are using the GitHub service, you can link your repository to
> > +the ``travis-ci.org`` build service. When you push patches to your
> > repository, the travis service will automatically build your changes.
> > +
> > 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.19.1
>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3 0/5] Add non-blocking ring
@ 2019-01-25 5:20 0% ` Honnappa Nagarahalli
2019-01-25 17:42 0% ` Eads, Gage
2019-01-25 17:56 0% ` Eads, Gage
2019-01-28 18:14 3% ` [dpdk-dev] [PATCH v4 " Gage Eads
2 siblings, 2 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-01-25 5:20 UTC (permalink / raw)
To: Gage Eads, dev
Cc: olivier.matz, arybchenko, bruce.richardson, konstantin.ananyev,
stephen, nd, thomas, Ola Liljedahl,
Gavin Hu (Arm Technology China), Song Zhu (Arm Technology China),
nd
Hi Gage,
Thank you for this patch. Arm (Ola Liljedahl) had worked on a non-blocking ring algorithm. We were planning to add it to DPDK at some point this year. I am wondering if you would be open to take a look at the algorithm and collaborate?
I am yet to fully understand both the algorithms. But, Ola has reviewed your patch and can provide a quick overview of the differences here.
If you agree, we can send a RFC patch. You can review that and do performance benchmarking on your platforms. I can also benchmark your patch (may be once you fix the issue identified in __rte_ring_do_nb_enqueue_mp function?) on Arm platforms. May be we can end up with a better combined algorithm.
Hi Thomas/Bruce,
Please let me know if this is ok and if there is a better way to do this.
Thank you,
Honnappa
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Gage Eads
> Sent: Friday, January 18, 2019 9:23 AM
> To: dev@dpdk.org
> Cc: olivier.matz@6wind.com; arybchenko@solarflare.com;
> bruce.richardson@intel.com; konstantin.ananyev@intel.com;
> stephen@networkplumber.org
> Subject: [dpdk-dev] [PATCH v3 0/5] Add non-blocking ring
>
> For some users, the rte ring's "non-preemptive" constraint is not acceptable;
> for example, if the application uses a mixture of pinned high-priority threads
> and multiplexed low-priority threads that share a mempool.
>
> This patchset introduces a non-blocking ring, on top of which a mempool can
> run.
> Crucially, the non-blocking algorithm relies on a 128-bit compare-and-swap,
> so it is currently limited to x86_64 machines. This is also an experimental API,
> so RING_F_NB users must build with the ALLOW_EXPERIMENTAL_API flag.
>
> The ring uses more compare-and-swap atomic operations than the regular rte
> ring:
> With no contention, an enqueue of n pointers uses (1 + 2n) CAS operations
> and a dequeue of n pointers uses 2. This algorithm has worse average-case
> performance than the regular rte ring (particularly a highly-contended ring
> with large bulk accesses), however:
> - For applications with preemptible pthreads, the regular rte ring's worst-case
> performance (i.e. one thread being preempted in the update_tail() critical
> section) is much worse than the non-blocking ring's.
> - Software caching can mitigate the average case performance for ring-based
> algorithms. For example, a non-blocking ring based mempool (a likely use
> case
> for this ring) with per-thread caching.
>
> The non-blocking ring is enabled via a new flag, RING_F_NB. For ease-of-use,
> existing ring enqueue/dequeue functions work with both "regular" and non-
> blocking rings.
>
> This patchset also adds non-blocking versions of ring_autotest and
> ring_perf_autotest, and a non-blocking ring based mempool.
>
> This patchset makes one API change; a deprecation notice will be posted in a
> separate commit.
>
> This patchset depends on the non-blocking stack patchset[1].
>
> [1] http://mails.dpdk.org/archives/dev/2019-January/123653.html
>
> v3:
> - Avoid the ABI break by putting 64-bit head and tail values in the same
> cacheline as struct rte_ring's prod and cons members.
> - Don't attempt to compile rte_atomic128_cmpset without
> ALLOW_EXPERIMENTAL_API, as this would break a large number of libraries.
> - Add a helpful warning to __rte_ring_do_nb_enqueue_mp() in case someone
> tries
> to use RING_F_NB without the ALLOW_EXPERIMENTAL_API flag.
> - Update the ring mempool to use experimental APIs
> - Clarify that RINB_F_NB is only limited to x86_64 currently; ARMv8.1-A
> builds
> can eventually support it with the CASP instruction.
>
> v2:
> - Merge separate docs commit into patch #5
> - Convert uintptr_t to size_t
> - Add a compile-time check for the size of size_t
> - Fix a space-after-typecast issue
> - Fix an unnecessary-parentheses checkpatch warning
> - Bump librte_ring's library version
>
> Gage Eads (5):
> ring: add 64-bit headtail structure
> ring: add a non-blocking implementation
> test_ring: add non-blocking ring autotest
> test_ring_perf: add non-blocking ring perf test
> mempool/ring: add non-blocking ring handlers
>
> doc/guides/prog_guide/env_abstraction_layer.rst | 2 +-
> drivers/mempool/ring/Makefile | 1 +
> drivers/mempool/ring/meson.build | 2 +
> drivers/mempool/ring/rte_mempool_ring.c | 58 ++-
> lib/librte_eventdev/rte_event_ring.h | 2 +-
> lib/librte_ring/Makefile | 3 +-
> lib/librte_ring/rte_ring.c | 72 ++-
> lib/librte_ring/rte_ring.h | 574 ++++++++++++++++++++++--
> lib/librte_ring/rte_ring_generic_64.h | 152 +++++++
> lib/librte_ring/rte_ring_version.map | 7 +
> test/test/test_ring.c | 57 ++-
> test/test/test_ring_perf.c | 19 +-
> 12 files changed, 874 insertions(+), 75 deletions(-) create mode 100644
> lib/librte_ring/rte_ring_generic_64.h
>
> --
> 2.13.6
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3 0/5] Add non-blocking ring
2019-01-25 5:20 0% ` [dpdk-dev] " Honnappa Nagarahalli
@ 2019-01-25 17:42 0% ` Eads, Gage
2019-01-25 17:56 0% ` Eads, Gage
1 sibling, 0 replies; 200+ results
From: Eads, Gage @ 2019-01-25 17:42 UTC (permalink / raw)
To: Honnappa Nagarahalli, dev
Cc: olivier.matz, arybchenko, Richardson, Bruce, Ananyev, Konstantin,
stephen, nd, thomas, Ola Liljedahl,
Gavin Hu (Arm Technology China), Song Zhu (Arm Technology China),
nd
Hi Honnappa,
Works for me -- I'm in favor of the best performing implementation, whoever provides it.
To allow an apples-to-apples comparison, I suggest Ola's/ARM's implementation be made to fit into the rte_ring API with an associated mempool handler. That'll allow us to use the existing ring and mempool performance tests as well. Feel free to use code from this patchset for the rte_ring integration, if that helps, of course.
I expect to have v4 available within the next week.
Thanks,
Gage
> -----Original Message-----
> From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com]
> Sent: Thursday, January 24, 2019 11:21 PM
> To: Eads, Gage <gage.eads@intel.com>; dev@dpdk.org
> Cc: olivier.matz@6wind.com; arybchenko@solarflare.com; Richardson, Bruce
> <bruce.richardson@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; stephen@networkplumber.org; nd
> <nd@arm.com>; thomas@monjalon.net; Ola Liljedahl
> <Ola.Liljedahl@arm.com>; Gavin Hu (Arm Technology China)
> <Gavin.Hu@arm.com>; Song Zhu (Arm Technology China)
> <Song.Zhu@arm.com>; nd <nd@arm.com>
> Subject: RE: [dpdk-dev] [PATCH v3 0/5] Add non-blocking ring
>
> Hi Gage,
> Thank you for this patch. Arm (Ola Liljedahl) had worked on a non-
> blocking ring algorithm. We were planning to add it to DPDK at some point this
> year. I am wondering if you would be open to take a look at the algorithm and
> collaborate?
>
> I am yet to fully understand both the algorithms. But, Ola has reviewed your
> patch and can provide a quick overview of the differences here.
>
> If you agree, we can send a RFC patch. You can review that and do performance
> benchmarking on your platforms. I can also benchmark your patch (may be once
> you fix the issue identified in __rte_ring_do_nb_enqueue_mp function?) on Arm
> platforms. May be we can end up with a better combined algorithm.
>
> Hi Thomas/Bruce,
> Please let me know if this is ok and if there is a better way to do this.
>
> Thank you,
> Honnappa
>
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Gage Eads
> > Sent: Friday, January 18, 2019 9:23 AM
> > To: dev@dpdk.org
> > Cc: olivier.matz@6wind.com; arybchenko@solarflare.com;
> > bruce.richardson@intel.com; konstantin.ananyev@intel.com;
> > stephen@networkplumber.org
> > Subject: [dpdk-dev] [PATCH v3 0/5] Add non-blocking ring
> >
> > For some users, the rte ring's "non-preemptive" constraint is not
> > acceptable; for example, if the application uses a mixture of pinned
> > high-priority threads and multiplexed low-priority threads that share a
> mempool.
> >
> > This patchset introduces a non-blocking ring, on top of which a
> > mempool can run.
> > Crucially, the non-blocking algorithm relies on a 128-bit
> > compare-and-swap, so it is currently limited to x86_64 machines. This
> > is also an experimental API, so RING_F_NB users must build with the
> ALLOW_EXPERIMENTAL_API flag.
> >
> > The ring uses more compare-and-swap atomic operations than the regular
> > rte
> > ring:
> > With no contention, an enqueue of n pointers uses (1 + 2n) CAS
> > operations and a dequeue of n pointers uses 2. This algorithm has
> > worse average-case performance than the regular rte ring (particularly
> > a highly-contended ring with large bulk accesses), however:
> > - For applications with preemptible pthreads, the regular rte ring's worst-case
> > performance (i.e. one thread being preempted in the update_tail() critical
> > section) is much worse than the non-blocking ring's.
> > - Software caching can mitigate the average case performance for ring-based
> > algorithms. For example, a non-blocking ring based mempool (a likely
> > use case
> > for this ring) with per-thread caching.
> >
> > The non-blocking ring is enabled via a new flag, RING_F_NB. For
> > ease-of-use, existing ring enqueue/dequeue functions work with both
> > "regular" and non- blocking rings.
> >
> > This patchset also adds non-blocking versions of ring_autotest and
> > ring_perf_autotest, and a non-blocking ring based mempool.
> >
> > This patchset makes one API change; a deprecation notice will be
> > posted in a separate commit.
> >
> > This patchset depends on the non-blocking stack patchset[1].
> >
> > [1] http://mails.dpdk.org/archives/dev/2019-January/123653.html
> >
> > v3:
> > - Avoid the ABI break by putting 64-bit head and tail values in the same
> > cacheline as struct rte_ring's prod and cons members.
> > - Don't attempt to compile rte_atomic128_cmpset without
> > ALLOW_EXPERIMENTAL_API, as this would break a large number of libraries.
> > - Add a helpful warning to __rte_ring_do_nb_enqueue_mp() in case
> > someone tries
> > to use RING_F_NB without the ALLOW_EXPERIMENTAL_API flag.
> > - Update the ring mempool to use experimental APIs
> > - Clarify that RINB_F_NB is only limited to x86_64 currently;
> > ARMv8.1-A builds
> > can eventually support it with the CASP instruction.
> >
> > v2:
> > - Merge separate docs commit into patch #5
> > - Convert uintptr_t to size_t
> > - Add a compile-time check for the size of size_t
> > - Fix a space-after-typecast issue
> > - Fix an unnecessary-parentheses checkpatch warning
> > - Bump librte_ring's library version
> >
> > Gage Eads (5):
> > ring: add 64-bit headtail structure
> > ring: add a non-blocking implementation
> > test_ring: add non-blocking ring autotest
> > test_ring_perf: add non-blocking ring perf test
> > mempool/ring: add non-blocking ring handlers
> >
> > doc/guides/prog_guide/env_abstraction_layer.rst | 2 +-
> > drivers/mempool/ring/Makefile | 1 +
> > drivers/mempool/ring/meson.build | 2 +
> > drivers/mempool/ring/rte_mempool_ring.c | 58 ++-
> > lib/librte_eventdev/rte_event_ring.h | 2 +-
> > lib/librte_ring/Makefile | 3 +-
> > lib/librte_ring/rte_ring.c | 72 ++-
> > lib/librte_ring/rte_ring.h | 574 ++++++++++++++++++++++--
> > lib/librte_ring/rte_ring_generic_64.h | 152 +++++++
> > lib/librte_ring/rte_ring_version.map | 7 +
> > test/test/test_ring.c | 57 ++-
> > test/test/test_ring_perf.c | 19 +-
> > 12 files changed, 874 insertions(+), 75 deletions(-) create mode
> > 100644 lib/librte_ring/rte_ring_generic_64.h
> >
> > --
> > 2.13.6
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3 0/5] Add non-blocking ring
2019-01-25 5:20 0% ` [dpdk-dev] " Honnappa Nagarahalli
2019-01-25 17:42 0% ` Eads, Gage
@ 2019-01-25 17:56 0% ` Eads, Gage
2019-01-28 10:41 0% ` Ola Liljedahl
1 sibling, 1 reply; 200+ results
From: Eads, Gage @ 2019-01-25 17:56 UTC (permalink / raw)
To: Honnappa Nagarahalli, dev
Cc: olivier.matz, arybchenko, Richardson, Bruce, Ananyev, Konstantin,
stephen, nd, thomas, Ola Liljedahl,
Gavin Hu (Arm Technology China), Song Zhu (Arm Technology China),
nd
> -----Original Message-----
> From: Eads, Gage
> Sent: Friday, January 25, 2019 11:43 AM
> To: 'Honnappa Nagarahalli' <Honnappa.Nagarahalli@arm.com>; dev@dpdk.org
> Cc: olivier.matz@6wind.com; arybchenko@solarflare.com; Richardson, Bruce
> <bruce.richardson@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; stephen@networkplumber.org; nd
> <nd@arm.com>; thomas@monjalon.net; Ola Liljedahl
> <Ola.Liljedahl@arm.com>; Gavin Hu (Arm Technology China)
> <Gavin.Hu@arm.com>; Song Zhu (Arm Technology China)
> <Song.Zhu@arm.com>; nd <nd@arm.com>
> Subject: RE: [dpdk-dev] [PATCH v3 0/5] Add non-blocking ring
>
> Hi Honnappa,
>
> Works for me -- I'm in favor of the best performing implementation, whoever
> provides it.
>
> To allow an apples-to-apples comparison, I suggest Ola's/ARM's implementation
> be made to fit into the rte_ring API with an associated mempool handler. That'll
> allow us to use the existing ring and mempool performance tests as well. Feel
> free to use code from this patchset for the rte_ring integration, if that helps, of
> course.
>
But also, if Ola/ARM's algorithm is sufficiently similar to this one, it's probably better to tweak this patchset's enqueue and dequeue functions with any improvements you can identify rather than creating an entirely separate implementation.
> I expect to have v4 available within the next week.
>
> Thanks,
> Gage
>
> > -----Original Message-----
> > From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com]
> > Sent: Thursday, January 24, 2019 11:21 PM
> > To: Eads, Gage <gage.eads@intel.com>; dev@dpdk.org
> > Cc: olivier.matz@6wind.com; arybchenko@solarflare.com; Richardson,
> > Bruce <bruce.richardson@intel.com>; Ananyev, Konstantin
> > <konstantin.ananyev@intel.com>; stephen@networkplumber.org; nd
> > <nd@arm.com>; thomas@monjalon.net; Ola Liljedahl
> > <Ola.Liljedahl@arm.com>; Gavin Hu (Arm Technology China)
> > <Gavin.Hu@arm.com>; Song Zhu (Arm Technology China)
> > <Song.Zhu@arm.com>; nd <nd@arm.com>
> > Subject: RE: [dpdk-dev] [PATCH v3 0/5] Add non-blocking ring
> >
> > Hi Gage,
> > Thank you for this patch. Arm (Ola Liljedahl) had worked on a non-
> > blocking ring algorithm. We were planning to add it to DPDK at some
> > point this year. I am wondering if you would be open to take a look at
> > the algorithm and collaborate?
> >
> > I am yet to fully understand both the algorithms. But, Ola has
> > reviewed your patch and can provide a quick overview of the differences here.
> >
> > If you agree, we can send a RFC patch. You can review that and do
> > performance benchmarking on your platforms. I can also benchmark your
> > patch (may be once you fix the issue identified in
> > __rte_ring_do_nb_enqueue_mp function?) on Arm platforms. May be we can
> end up with a better combined algorithm.
> >
> > Hi Thomas/Bruce,
> > Please let me know if this is ok and if there is a better way to do this.
> >
> > Thank you,
> > Honnappa
> >
> > > -----Original Message-----
> > > From: dev <dev-bounces@dpdk.org> On Behalf Of Gage Eads
> > > Sent: Friday, January 18, 2019 9:23 AM
> > > To: dev@dpdk.org
> > > Cc: olivier.matz@6wind.com; arybchenko@solarflare.com;
> > > bruce.richardson@intel.com; konstantin.ananyev@intel.com;
> > > stephen@networkplumber.org
> > > Subject: [dpdk-dev] [PATCH v3 0/5] Add non-blocking ring
> > >
> > > For some users, the rte ring's "non-preemptive" constraint is not
> > > acceptable; for example, if the application uses a mixture of pinned
> > > high-priority threads and multiplexed low-priority threads that
> > > share a
> > mempool.
> > >
> > > This patchset introduces a non-blocking ring, on top of which a
> > > mempool can run.
> > > Crucially, the non-blocking algorithm relies on a 128-bit
> > > compare-and-swap, so it is currently limited to x86_64 machines.
> > > This is also an experimental API, so RING_F_NB users must build with
> > > the
> > ALLOW_EXPERIMENTAL_API flag.
> > >
> > > The ring uses more compare-and-swap atomic operations than the
> > > regular rte
> > > ring:
> > > With no contention, an enqueue of n pointers uses (1 + 2n) CAS
> > > operations and a dequeue of n pointers uses 2. This algorithm has
> > > worse average-case performance than the regular rte ring
> > > (particularly a highly-contended ring with large bulk accesses), however:
> > > - For applications with preemptible pthreads, the regular rte ring's worst-
> case
> > > performance (i.e. one thread being preempted in the update_tail() critical
> > > section) is much worse than the non-blocking ring's.
> > > - Software caching can mitigate the average case performance for ring-
> based
> > > algorithms. For example, a non-blocking ring based mempool (a
> > > likely use case
> > > for this ring) with per-thread caching.
> > >
> > > The non-blocking ring is enabled via a new flag, RING_F_NB. For
> > > ease-of-use, existing ring enqueue/dequeue functions work with both
> > > "regular" and non- blocking rings.
> > >
> > > This patchset also adds non-blocking versions of ring_autotest and
> > > ring_perf_autotest, and a non-blocking ring based mempool.
> > >
> > > This patchset makes one API change; a deprecation notice will be
> > > posted in a separate commit.
> > >
> > > This patchset depends on the non-blocking stack patchset[1].
> > >
> > > [1] http://mails.dpdk.org/archives/dev/2019-January/123653.html
> > >
> > > v3:
> > > - Avoid the ABI break by putting 64-bit head and tail values in the same
> > > cacheline as struct rte_ring's prod and cons members.
> > > - Don't attempt to compile rte_atomic128_cmpset without
> > > ALLOW_EXPERIMENTAL_API, as this would break a large number of
> libraries.
> > > - Add a helpful warning to __rte_ring_do_nb_enqueue_mp() in case
> > > someone tries
> > > to use RING_F_NB without the ALLOW_EXPERIMENTAL_API flag.
> > > - Update the ring mempool to use experimental APIs
> > > - Clarify that RINB_F_NB is only limited to x86_64 currently;
> > > ARMv8.1-A builds
> > > can eventually support it with the CASP instruction.
> > >
> > > v2:
> > > - Merge separate docs commit into patch #5
> > > - Convert uintptr_t to size_t
> > > - Add a compile-time check for the size of size_t
> > > - Fix a space-after-typecast issue
> > > - Fix an unnecessary-parentheses checkpatch warning
> > > - Bump librte_ring's library version
> > >
> > > Gage Eads (5):
> > > ring: add 64-bit headtail structure
> > > ring: add a non-blocking implementation
> > > test_ring: add non-blocking ring autotest
> > > test_ring_perf: add non-blocking ring perf test
> > > mempool/ring: add non-blocking ring handlers
> > >
> > > doc/guides/prog_guide/env_abstraction_layer.rst | 2 +-
> > > drivers/mempool/ring/Makefile | 1 +
> > > drivers/mempool/ring/meson.build | 2 +
> > > drivers/mempool/ring/rte_mempool_ring.c | 58 ++-
> > > lib/librte_eventdev/rte_event_ring.h | 2 +-
> > > lib/librte_ring/Makefile | 3 +-
> > > lib/librte_ring/rte_ring.c | 72 ++-
> > > lib/librte_ring/rte_ring.h | 574 ++++++++++++++++++++++--
> > > lib/librte_ring/rte_ring_generic_64.h | 152 +++++++
> > > lib/librte_ring/rte_ring_version.map | 7 +
> > > test/test/test_ring.c | 57 ++-
> > > test/test/test_ring_perf.c | 19 +-
> > > 12 files changed, 874 insertions(+), 75 deletions(-) create mode
> > > 100644 lib/librte_ring/rte_ring_generic_64.h
> > >
> > > --
> > > 2.13.6
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3 0/5] Add non-blocking ring
2019-01-25 17:56 0% ` Eads, Gage
@ 2019-01-28 10:41 0% ` Ola Liljedahl
0 siblings, 0 replies; 200+ results
From: Ola Liljedahl @ 2019-01-28 10:41 UTC (permalink / raw)
To: Honnappa Nagarahalli, gage.eads, dev
Cc: nd, bruce.richardson, thomas, konstantin.ananyev,
Song Zhu (Arm Technology China),
stephen, olivier.matz, arybchenko,
Gavin Hu (Arm Technology China)
On Fri, 2019-01-25 at 17:56 +0000, Eads, Gage wrote:
>
> >
> > -----Original Message-----
> > From: Eads, Gage
> > Sent: Friday, January 25, 2019 11:43 AM
> > To: 'Honnappa Nagarahalli' <Honnappa.Nagarahalli@arm.com>; dev@dpdk.org
> > Cc: olivier.matz@6wind.com; arybchenko@solarflare.com; Richardson, Bruce
> > <bruce.richardson@intel.com>; Ananyev, Konstantin
> > <konstantin.ananyev@intel.com>; stephen@networkplumber.org; nd
> > <nd@arm.com>; thomas@monjalon.net; Ola Liljedahl
> > <Ola.Liljedahl@arm.com>; Gavin Hu (Arm Technology China)
> > <Gavin.Hu@arm.com>; Song Zhu (Arm Technology China)
> > <Song.Zhu@arm.com>; nd <nd@arm.com>
> > Subject: RE: [dpdk-dev] [PATCH v3 0/5] Add non-blocking ring
> >
> > Hi Honnappa,
> >
> > Works for me -- I'm in favor of the best performing implementation, whoever
> > provides it.
> >
> > To allow an apples-to-apples comparison, I suggest Ola's/ARM's
> > implementation
> > be made to fit into the rte_ring API with an associated mempool handler.
> > That'll
> > allow us to use the existing ring and mempool performance tests as well.
> > Feel
> > free to use code from this patchset for the rte_ring integration, if that
> > helps, of
> > course.
> >
> But also, if Ola/ARM's algorithm is sufficiently similar to this one, it's
> probably better to tweak this patchset's enqueue and dequeue functions with
> any improvements you can identify rather than creating an entirely separate
> implementation.
There are strong similarities. But my implementation is separate from rte_ring
(whose code is a mess) which also freed me from any interoperatibility with the
rte_ring code and data structure (with two pairs of head+tail which is
unnecessary for the lock-free ring buffer).
My design and implementation is here:
https://github.com/ARM-software/progress64/blob/master/src/p64_lfring.c
I have a DPDK version in flight. Merging the relevant changes into your patch
makes sense. There are some differences we will have to agree on.
>
> >
> > I expect to have v4 available within the next week.
> >
> > Thanks,
> > Gage
> >
> > >
> > > -----Original Message-----
> > > From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com]
> > > Sent: Thursday, January 24, 2019 11:21 PM
> > > To: Eads, Gage <gage.eads@intel.com>; dev@dpdk.org
> > > Cc: olivier.matz@6wind.com; arybchenko@solarflare.com; Richardson,
> > > Bruce <bruce.richardson@intel.com>; Ananyev, Konstantin
> > > <konstantin.ananyev@intel.com>; stephen@networkplumber.org; nd
> > > <nd@arm.com>; thomas@monjalon.net; Ola Liljedahl
> > > <Ola.Liljedahl@arm.com>; Gavin Hu (Arm Technology China)
> > > <Gavin.Hu@arm.com>; Song Zhu (Arm Technology China)
> > > <Song.Zhu@arm.com>; nd <nd@arm.com>
> > > Subject: RE: [dpdk-dev] [PATCH v3 0/5] Add non-blocking ring
> > >
> > > Hi Gage,
> > > Thank you for this patch. Arm (Ola Liljedahl) had worked on a non-
> > > blocking ring algorithm. We were planning to add it to DPDK at some
> > > point this year. I am wondering if you would be open to take a look at
> > > the algorithm and collaborate?
> > >
> > > I am yet to fully understand both the algorithms. But, Ola has
> > > reviewed your patch and can provide a quick overview of the differences
> > > here.
> > >
> > > If you agree, we can send a RFC patch. You can review that and do
> > > performance benchmarking on your platforms. I can also benchmark your
> > > patch (may be once you fix the issue identified in
> > > __rte_ring_do_nb_enqueue_mp function?) on Arm platforms. May be we can
> > end up with a better combined algorithm.
> > >
> > >
> > > Hi Thomas/Bruce,
> > > Please let me know if this is ok and if there is a better way to do
> > > this.
> > >
> > > Thank you,
> > > Honnappa
> > >
> > > >
> > > > -----Original Message-----
> > > > From: dev <dev-bounces@dpdk.org> On Behalf Of Gage Eads
> > > > Sent: Friday, January 18, 2019 9:23 AM
> > > > To: dev@dpdk.org
> > > > Cc: olivier.matz@6wind.com; arybchenko@solarflare.com;
> > > > bruce.richardson@intel.com; konstantin.ananyev@intel.com;
> > > > stephen@networkplumber.org
> > > > Subject: [dpdk-dev] [PATCH v3 0/5] Add non-blocking ring
> > > >
> > > > For some users, the rte ring's "non-preemptive" constraint is not
> > > > acceptable; for example, if the application uses a mixture of pinned
> > > > high-priority threads and multiplexed low-priority threads that
> > > > share a
> > > mempool.
> > > >
> > > >
> > > > This patchset introduces a non-blocking ring, on top of which a
> > > > mempool can run.
> > > > Crucially, the non-blocking algorithm relies on a 128-bit
> > > > compare-and-swap, so it is currently limited to x86_64 machines.
> > > > This is also an experimental API, so RING_F_NB users must build with
> > > > the
> > > ALLOW_EXPERIMENTAL_API flag.
> > > >
> > > >
> > > > The ring uses more compare-and-swap atomic operations than the
> > > > regular rte
> > > > ring:
> > > > With no contention, an enqueue of n pointers uses (1 + 2n) CAS
> > > > operations and a dequeue of n pointers uses 2. This algorithm has
> > > > worse average-case performance than the regular rte ring
> > > > (particularly a highly-contended ring with large bulk accesses),
> > > > however:
> > > > - For applications with preemptible pthreads, the regular rte ring's
> > > > worst-
> > case
> > >
> > > >
> > > > performance (i.e. one thread being preempted in the update_tail()
> > > > critical
> > > > section) is much worse than the non-blocking ring's.
> > > > - Software caching can mitigate the average case performance for ring-
> > based
> > >
> > > >
> > > > algorithms. For example, a non-blocking ring based mempool (a
> > > > likely use case
> > > > for this ring) with per-thread caching.
> > > >
> > > > The non-blocking ring is enabled via a new flag, RING_F_NB. For
> > > > ease-of-use, existing ring enqueue/dequeue functions work with both
> > > > "regular" and non- blocking rings.
> > > >
> > > > This patchset also adds non-blocking versions of ring_autotest and
> > > > ring_perf_autotest, and a non-blocking ring based mempool.
> > > >
> > > > This patchset makes one API change; a deprecation notice will be
> > > > posted in a separate commit.
> > > >
> > > > This patchset depends on the non-blocking stack patchset[1].
> > > >
> > > > [1] http://mails.dpdk.org/archives/dev/2019-January/123653.html
> > > >
> > > > v3:
> > > > - Avoid the ABI break by putting 64-bit head and tail values in the
> > > > same
> > > > cacheline as struct rte_ring's prod and cons members.
> > > > - Don't attempt to compile rte_atomic128_cmpset without
> > > > ALLOW_EXPERIMENTAL_API, as this would break a large number of
> > libraries.
> > >
> > > >
> > > > - Add a helpful warning to __rte_ring_do_nb_enqueue_mp() in case
> > > > someone tries
> > > > to use RING_F_NB without the ALLOW_EXPERIMENTAL_API flag.
> > > > - Update the ring mempool to use experimental APIs
> > > > - Clarify that RINB_F_NB is only limited to x86_64 currently;
> > > > ARMv8.1-A builds
> > > > can eventually support it with the CASP instruction.
> > > >
> > > > v2:
> > > > - Merge separate docs commit into patch #5
> > > > - Convert uintptr_t to size_t
> > > > - Add a compile-time check for the size of size_t
> > > > - Fix a space-after-typecast issue
> > > > - Fix an unnecessary-parentheses checkpatch warning
> > > > - Bump librte_ring's library version
> > > >
> > > > Gage Eads (5):
> > > > ring: add 64-bit headtail structure
> > > > ring: add a non-blocking implementation
> > > > test_ring: add non-blocking ring autotest
> > > > test_ring_perf: add non-blocking ring perf test
> > > > mempool/ring: add non-blocking ring handlers
> > > >
> > > > doc/guides/prog_guide/env_abstraction_layer.rst | 2 +-
> > > > drivers/mempool/ring/Makefile | 1 +
> > > > drivers/mempool/ring/meson.build | 2 +
> > > > drivers/mempool/ring/rte_mempool_ring.c | 58 ++-
> > > > lib/librte_eventdev/rte_event_ring.h | 2 +-
> > > > lib/librte_ring/Makefile | 3 +-
> > > > lib/librte_ring/rte_ring.c | 72 ++-
> > > > lib/librte_ring/rte_ring.h | 574
> > > > ++++++++++++++++++++++--
> > > > lib/librte_ring/rte_ring_generic_64.h | 152 +++++++
> > > > lib/librte_ring/rte_ring_version.map | 7 +
> > > > test/test/test_ring.c | 57 ++-
> > > > test/test/test_ring_perf.c | 19 +-
> > > > 12 files changed, 874 insertions(+), 75 deletions(-) create mode
> > > > 100644 lib/librte_ring/rte_ring_generic_64.h
> > > >
> > > > --
> > > > 2.13.6
--
Ola Liljedahl, Networking System Architect, Arm
Phone +46706866373, Skype ola.liljedahl
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [EXT] Re: [PATCH v3 0/5] Add non-blocking ring
@ 2019-01-28 13:10 0% ` Jerin Jacob Kollanukkaran
0 siblings, 0 replies; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-01-28 13:10 UTC (permalink / raw)
To: Ola.Liljedahl, gage.eads, dev
Cc: olivier.matz, stephen, nd, bruce.richardson, arybchenko,
konstantin.ananyev
On Wed, 2019-01-23 at 16:29 +0000, Ola Liljedahl wrote:
> External Email
>
> -------------------------------------------------------------------
> ---
> On Wed, 2019-01-23 at 16:02 +0000, Jerin Jacob Kollanukkaran wrote:
> > On Tue, 2019-01-22 at 09:27 +0000, Ola Liljedahl wrote:
> > > On Fri, 2019-01-18 at 09:23 -0600, Gage Eads wrote:
> > > > v3:
> > > > - Avoid the ABI break by putting 64-bit head and tail values
> > > > in
> > > > the
> > > > same
> > > > cacheline as struct rte_ring's prod and cons members.
> > > > - Don't attempt to compile rte_atomic128_cmpset without
> > > > ALLOW_EXPERIMENTAL_API, as this would break a large number
> > > > of
> > > > libraries.
> > > > - Add a helpful warning to __rte_ring_do_nb_enqueue_mp() in
> > > > case
> > > > someone tries
> > > > to use RING_F_NB without the ALLOW_EXPERIMENTAL_API flag.
> > > > - Update the ring mempool to use experimental APIs
> > > > - Clarify that RINB_F_NB is only limited to x86_64 currently;
> > > > ARMv8.1-A builds
> > > > can eventually support it with the CASP instruction.
> > > ARMv8.0 should be able to implement a 128-bit atomic compare
> > > exchange
> > > operation using LDXP/STXP.
> > Just wondering what would the performance difference between CASP
> > vs
> > LDXP/STXP on LSE supported machine?
> I think that is up to the microarchitecture. But one the ideas behind
Yes. This is where things are getting little messy to have generic code
where a lot of stuff is defined based on micro
architecture/IMPLEMENTATION DEFINED as arm spec. Al least, I am dealing
with three different micro archirectures now with a lot of difference.
Including the arm cores and qualcomm cores there could around >6ish
different micro archtectures.
> introducing the LSE atomics was that they should be "better" than the
> equivalent
> code using exclusives. I think non-conditional LDxxx and STxxx
> atomics could be
> better than using exclusives while conditional atomics (CAS, CASP)
> might not be
> so different (the reason has to do with cache coherency, a core can
> speculatively snoop-unique the cache line which is targetted by an
> atomic
> instruction but to what extent that provides a benefit could be
> depend on
> whether the atomic actually performs a store or not).
>
> > I think, We can not detect the presese of LSE support in compile
> > time.
> > Right?
> Unfortunately, AFAIK GCC doesn't notify the source code that it is
> targetting
> v8.1+ with LSE support. If there were intrinsics for (certain) LSE
> instructions
> (e.g. those not generated by the compiler, e.g. STxxx and CASP), we
> could use
> some corresponding preprocessor define to detect the presence of such
> intrinsics
> (they exist for other intrinsics, e.g. __ARM_FEATURE_QRDMX for
> SQRDMLAH/SQRDMLSH
> instructions and corresponding intrinsics).
>
> I have tried to interest the Arm GCC developers in this but have not
> yet
> succeeded. Perhaps if we have more use cases were atomics intrinsics
> would be
> useful, we could convince them to add such intrinsics to the ACLE
> (ARM C
> Language Extensions). But we will never get intrinsics for
> exclusives, they are
> deemed unsafe for explicit use from C. Instead need to provide inline
> assembler
> that contains the complete exclusives sequence. But in practice it
> seems to work
> with using inline assembler for LDXR and STXR as I do in the lockfree
> code
> linked below.
>
> > The dynamic one will be costly like,
> Do you think so? Shouldn't this branch be perfectly predictable? Once
Not just branch predication. Right? Corresponding Load and need for
more I cache etc.
I think, for the generic build we can have either run time detection
or stick with LDXR/STXR.
We can give a compile time option for CASP based code so that for given
micro architecture if it optimized it can make use of it.(Something we
can easily expressed on meson build with MIDR value)
> in a while
> it will fall out of the branch history table but doesn't that mean
> the
> application hasn't been executing this code for some time so not
> really
> performance critical?
>
> > if (hwcaps & HWCAP_ATOMICS) {
> > casp
> > } else {
> > ldxp
> > stxp
> > }
> >
> > > From an ARM perspective, I want all atomic operations to take
> > > memory
> > > ordering arguments (e.g. acquire, release). Not all usages of
> > > e.g.
> > +1
> >
> > > atomic compare exchange require sequential consistency (which I
> > > think
> > > what x86 cmpxchg instruction provides). DPDK functions should not
> > > be
> > > modelled after x86 behaviour.
> > >
> > > Lock-free 128-bit atomics implementations for ARM/AArch64 and
> > > x86-64
> > > are available here:
> > > https://github.com/ARM-software/progress64/blob/master/src/lockfree.h
> > >
> --
> Ola Liljedahl, Networking System Architect, Arm
> Phone +46706866373, Skype ola.liljedahl
>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v4 0/5] Add non-blocking ring
2019-01-25 5:20 0% ` [dpdk-dev] " Honnappa Nagarahalli
@ 2019-01-28 18:14 3% ` Gage Eads
2019-01-28 18:14 2% ` [dpdk-dev] [PATCH v4 1/5] ring: add 64-bit headtail structure Gage Eads
2019-03-05 17:40 2% ` [dpdk-dev] [PATCH v5 0/6] Add lock-free ring and mempool handler Gage Eads
2 siblings, 2 replies; 200+ results
From: Gage Eads @ 2019-01-28 18:14 UTC (permalink / raw)
To: dev
Cc: olivier.matz, arybchenko, bruce.richardson, konstantin.ananyev,
stephen, jerinj, mczekaj, nd, Ola.Liljedahl
For some users, the rte ring's "non-preemptive" constraint is not acceptable;
for example, if the application uses a mixture of pinned high-priority threads
and multiplexed low-priority threads that share a mempool.
This patchset introduces a non-blocking ring, on top of which a mempool can run.
Crucially, the non-blocking algorithm relies on a 128-bit compare-and-swap, so
it is currently limited to x86_64 machines. This is also an experimental API,
so RING_F_NB users must build with the ALLOW_EXPERIMENTAL_API flag.
The ring uses more compare-and-swap atomic operations than the regular rte ring:
With no contention, an enqueue of n pointers uses (1 + 2n) CAS operations and a
dequeue of n pointers uses 2. This algorithm has worse average-case performance
than the regular rte ring (particularly a highly-contended ring with large bulk
accesses), however:
- For applications with preemptible pthreads, the regular rte ring's worst-case
performance (i.e. one thread being preempted in the update_tail() critical
section) is much worse than the non-blocking ring's.
- Software caching can mitigate the average case performance for ring-based
algorithms. For example, a non-blocking ring based mempool (a likely use case
for this ring) with per-thread caching.
The non-blocking ring is enabled via a new flag, RING_F_NB. For ease-of-use,
existing ring enqueue/dequeue functions work with both "regular" and
non-blocking rings.
This patchset also adds non-blocking versions of ring_autotest and
ring_perf_autotest, and a non-blocking ring based mempool.
This patchset makes one API change; a deprecation notice will be posted in a
separate commit.
This patchset depends on the 128-bit compare-and-set patch[1].
[1] http://mails.dpdk.org/archives/dev/2019-January/124159.html
v4:
- Split out nb_enqueue and nb_dequeue functions in generic and C11 versions,
with the necessary memory ordering behavior for weakly consistent machines.
- Convert size_t variables (from v2) to uint64_t and no-longer-applicable
comment about variably-sized ring indexes.
- Fix bug in nb_enqueue_mp that the breaks the non-blocking guarantee.
- Split the ring_ptr cast into two lines.
- Change the dependent patchset from the non-blocking stack patch series
to one only containing the 128b CAS commit
v3:
- Avoid the ABI break by putting 64-bit head and tail values in the same
cacheline as struct rte_ring's prod and cons members.
- Don't attempt to compile rte_atomic128_cmpset without
ALLOW_EXPERIMENTAL_API, as this would break a large number of libraries.
- Add a helpful warning to __rte_ring_do_nb_enqueue_mp() in case someone tries
to use RING_F_NB without the ALLOW_EXPERIMENTAL_API flag.
- Update the ring mempool to use experimental APIs
- Clarify that RINB_F_NB is only limited to x86_64 currently; e.g ARMv8 has the
ISA support for 128-bit CAS to eventually support it.
v2:
- Merge separate docs commit into patch #5
- Convert uintptr_t to size_t
- Add a compile-time check for the size of size_t
- Fix a space-after-typecast issue
- Fix an unnecessary-parentheses checkpatch warning
- Bump librte_ring's library version
Gage Eads (5):
ring: add 64-bit headtail structure
ring: add a non-blocking implementation
test_ring: add non-blocking ring autotest
test_ring_perf: add non-blocking ring perf test
mempool/ring: add non-blocking ring handlers
doc/guides/prog_guide/env_abstraction_layer.rst | 5 +
drivers/mempool/ring/Makefile | 1 +
drivers/mempool/ring/meson.build | 2 +
drivers/mempool/ring/rte_mempool_ring.c | 58 +++-
lib/librte_ring/rte_ring.c | 72 +++-
lib/librte_ring/rte_ring.h | 336 +++++++++++++++++--
lib/librte_ring/rte_ring_c11_mem.h | 427 ++++++++++++++++++++++++
lib/librte_ring/rte_ring_generic.h | 408 ++++++++++++++++++++++
lib/librte_ring/rte_ring_version.map | 7 +
test/test/test_ring.c | 57 ++--
test/test/test_ring_perf.c | 19 +-
11 files changed, 1319 insertions(+), 73 deletions(-)
--
2.13.6
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v4 1/5] ring: add 64-bit headtail structure
2019-01-28 18:14 3% ` [dpdk-dev] [PATCH v4 " Gage Eads
@ 2019-01-28 18:14 2% ` Gage Eads
2019-01-29 12:56 0% ` Ola Liljedahl
2019-03-05 17:40 2% ` [dpdk-dev] [PATCH v5 0/6] Add lock-free ring and mempool handler Gage Eads
1 sibling, 1 reply; 200+ results
From: Gage Eads @ 2019-01-28 18:14 UTC (permalink / raw)
To: dev
Cc: olivier.matz, arybchenko, bruce.richardson, konstantin.ananyev,
stephen, jerinj, mczekaj, nd, Ola.Liljedahl
64-bit head and tail index widths greatly increases the time it takes for
them to wrap-around (with current CPU speeds, it won't happen within the
author's lifetime). This is fundamental to avoiding the ABA problem -- in
which a thread mistakes reading the same tail index in two accesses to mean
that the ring was not modified in the intervening time -- in the upcoming
non-blocking ring implementation. Using a 64-bit index makes the
possibility of this occurring effectively zero.
This commit places the new producer and consumer structures in the same
location in struct rte_ring as their 32-bit counterparts. Since the 32-bit
versions are padded out to a cache line, there is space for the new
structure without affecting the layout of struct rte_ring. Thus, the ABI is
preserved.
Signed-off-by: Gage Eads <gage.eads@intel.com>
---
lib/librte_ring/rte_ring.h | 23 +++++-
lib/librte_ring/rte_ring_c11_mem.h | 153 +++++++++++++++++++++++++++++++++++++
lib/librte_ring/rte_ring_generic.h | 139 +++++++++++++++++++++++++++++++++
3 files changed, 312 insertions(+), 3 deletions(-)
diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
index af5444a9f..00dfb5b85 100644
--- a/lib/librte_ring/rte_ring.h
+++ b/lib/librte_ring/rte_ring.h
@@ -1,6 +1,6 @@
/* SPDX-License-Identifier: BSD-3-Clause
*
- * Copyright (c) 2010-2017 Intel Corporation
+ * Copyright (c) 2010-2019 Intel Corporation
* Copyright (c) 2007-2009 Kip Macy kmacy@freebsd.org
* All rights reserved.
* Derived from FreeBSD's bufring.h
@@ -70,6 +70,15 @@ struct rte_ring_headtail {
uint32_t single; /**< True if single prod/cons */
};
+/* 64-bit version of rte_ring_headtail, for use by rings that need to avoid
+ * head/tail wrap-around.
+ */
+struct rte_ring_headtail_64 {
+ volatile uint64_t head; /**< Prod/consumer head. */
+ volatile uint64_t tail; /**< Prod/consumer tail. */
+ uint32_t single; /**< True if single prod/cons */
+};
+
/**
* An RTE ring structure.
*
@@ -97,11 +106,19 @@ struct rte_ring {
char pad0 __rte_cache_aligned; /**< empty cache line */
/** Ring producer status. */
- struct rte_ring_headtail prod __rte_cache_aligned;
+ RTE_STD_C11
+ union {
+ struct rte_ring_headtail prod __rte_cache_aligned;
+ struct rte_ring_headtail_64 prod_64 __rte_cache_aligned;
+ };
char pad1 __rte_cache_aligned; /**< empty cache line */
/** Ring consumer status. */
- struct rte_ring_headtail cons __rte_cache_aligned;
+ RTE_STD_C11
+ union {
+ struct rte_ring_headtail cons __rte_cache_aligned;
+ struct rte_ring_headtail_64 cons_64 __rte_cache_aligned;
+ };
char pad2 __rte_cache_aligned; /**< empty cache line */
};
diff --git a/lib/librte_ring/rte_ring_c11_mem.h b/lib/librte_ring/rte_ring_c11_mem.h
index 0fb73a337..47acd4c7c 100644
--- a/lib/librte_ring/rte_ring_c11_mem.h
+++ b/lib/librte_ring/rte_ring_c11_mem.h
@@ -178,4 +178,157 @@ __rte_ring_move_cons_head(struct rte_ring *r, int is_sc,
return n;
}
+/**
+ * @internal This function updates the producer head for enqueue using
+ * 64-bit head/tail values.
+ *
+ * @param r
+ * A pointer to the ring structure
+ * @param is_sp
+ * Indicates whether multi-producer path is needed or not
+ * @param n
+ * The number of elements we will want to enqueue, i.e. how far should the
+ * head be moved
+ * @param behavior
+ * RTE_RING_QUEUE_FIXED: Enqueue a fixed number of items from a ring
+ * RTE_RING_QUEUE_VARIABLE: Enqueue as many items as possible from ring
+ * @param old_head
+ * Returns head value as it was before the move, i.e. where enqueue starts
+ * @param new_head
+ * Returns the current/new head value i.e. where enqueue finishes
+ * @param free_entries
+ * Returns the amount of free space in the ring BEFORE head was moved
+ * @return
+ * Actual number of objects enqueued.
+ * If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
+ */
+static __rte_always_inline unsigned int
+__rte_ring_move_prod_head_64(struct rte_ring *r, unsigned int is_sp,
+ unsigned int n, enum rte_ring_queue_behavior behavior,
+ uint64_t *old_head, uint64_t *new_head,
+ uint32_t *free_entries)
+{
+ const uint32_t capacity = r->capacity;
+ uint64_t cons_tail;
+ unsigned int max = n;
+ int success;
+
+ *old_head = __atomic_load_n(&r->prod_64.head, __ATOMIC_RELAXED);
+ do {
+ /* Reset n to the initial burst count */
+ n = max;
+
+ /* Ensure the head is read before tail */
+ __atomic_thread_fence(__ATOMIC_ACQUIRE);
+
+ /* load-acquire synchronize with store-release of ht->tail
+ * in update_tail.
+ */
+ cons_tail = __atomic_load_n(&r->cons_64.tail,
+ __ATOMIC_ACQUIRE);
+
+ /* The subtraction is done between two unsigned 32bits value
+ * (the result is always modulo 32 bits even if we have
+ * *old_head > cons_tail). So 'free_entries' is always between 0
+ * and capacity (which is < size).
+ */
+ *free_entries = (capacity + cons_tail - *old_head);
+
+ /* check that we have enough room in ring */
+ if (unlikely(n > *free_entries))
+ n = (behavior == RTE_RING_QUEUE_FIXED) ?
+ 0 : *free_entries;
+
+ if (n == 0)
+ return 0;
+
+ *new_head = *old_head + n;
+ if (is_sp)
+ r->prod_64.head = *new_head, success = 1;
+ else
+ /* on failure, *old_head is updated */
+ success = __atomic_compare_exchange_n(&r->prod_64.head,
+ old_head, *new_head,
+ 0, __ATOMIC_RELAXED,
+ __ATOMIC_RELAXED);
+ } while (unlikely(success == 0));
+ return n;
+}
+
+/**
+ * @internal This function updates the consumer head for dequeue using
+ * 64-bit head/tail values.
+ *
+ * @param r
+ * A pointer to the ring structure
+ * @param is_sc
+ * Indicates whether multi-consumer path is needed or not
+ * @param n
+ * The number of elements we will want to enqueue, i.e. how far should the
+ * head be moved
+ * @param behavior
+ * RTE_RING_QUEUE_FIXED: Dequeue a fixed number of items from a ring
+ * RTE_RING_QUEUE_VARIABLE: Dequeue as many items as possible from ring
+ * @param old_head
+ * Returns head value as it was before the move, i.e. where dequeue starts
+ * @param new_head
+ * Returns the current/new head value i.e. where dequeue finishes
+ * @param entries
+ * Returns the number of entries in the ring BEFORE head was moved
+ * @return
+ * - Actual number of objects dequeued.
+ * If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
+ */
+static __rte_always_inline unsigned int
+__rte_ring_move_cons_head_64(struct rte_ring *r, unsigned int is_sc,
+ unsigned int n, enum rte_ring_queue_behavior behavior,
+ uint64_t *old_head, uint64_t *new_head,
+ uint32_t *entries)
+{
+ unsigned int max = n;
+ uint64_t prod_tail;
+ int success;
+
+ /* move cons.head atomically */
+ *old_head = __atomic_load_n(&r->cons_64.head, __ATOMIC_RELAXED);
+ do {
+ /* Restore n as it may change every loop */
+ n = max;
+
+ /* Ensure the head is read before tail */
+ __atomic_thread_fence(__ATOMIC_ACQUIRE);
+
+ /* this load-acquire synchronize with store-release of ht->tail
+ * in update_tail.
+ */
+ prod_tail = __atomic_load_n(&r->prod_64.tail,
+ __ATOMIC_ACQUIRE);
+
+ /* The subtraction is done between two unsigned 32bits value
+ * (the result is always modulo 32 bits even if we have
+ * cons_head > prod_tail). So 'entries' is always between 0
+ * and size(ring)-1.
+ */
+ *entries = (prod_tail - *old_head);
+
+ /* Set the actual entries for dequeue */
+ if (n > *entries)
+ n = (behavior == RTE_RING_QUEUE_FIXED) ? 0 : *entries;
+
+ if (unlikely(n == 0))
+ return 0;
+
+ *new_head = *old_head + n;
+ if (is_sc)
+ r->cons_64.head = *new_head, success = 1;
+ else
+ /* on failure, *old_head will be updated */
+ success = __atomic_compare_exchange_n(&r->cons_64.head,
+ old_head, *new_head,
+ 0, __ATOMIC_RELAXED,
+ __ATOMIC_RELAXED);
+ } while (unlikely(success == 0));
+ return n;
+}
+
#endif /* _RTE_RING_C11_MEM_H_ */
diff --git a/lib/librte_ring/rte_ring_generic.h b/lib/librte_ring/rte_ring_generic.h
index ea7dbe5b9..2158e092a 100644
--- a/lib/librte_ring/rte_ring_generic.h
+++ b/lib/librte_ring/rte_ring_generic.h
@@ -167,4 +167,143 @@ __rte_ring_move_cons_head(struct rte_ring *r, unsigned int is_sc,
return n;
}
+/**
+ * @internal This function updates the producer head for enqueue using
+ * 64-bit head/tail values.
+ *
+ * @param r
+ * A pointer to the ring structure
+ * @param is_sp
+ * Indicates whether multi-producer path is needed or not
+ * @param n
+ * The number of elements we will want to enqueue, i.e. how far should the
+ * head be moved
+ * @param behavior
+ * RTE_RING_QUEUE_FIXED: Enqueue a fixed number of items from a ring
+ * RTE_RING_QUEUE_VARIABLE: Enqueue as many items as possible from ring
+ * @param old_head
+ * Returns head value as it was before the move, i.e. where enqueue starts
+ * @param new_head
+ * Returns the current/new head value i.e. where enqueue finishes
+ * @param free_entries
+ * Returns the amount of free space in the ring BEFORE head was moved
+ * @return
+ * Actual number of objects enqueued.
+ * If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
+ */
+static __rte_always_inline unsigned int
+__rte_ring_move_prod_head_64(struct rte_ring *r, unsigned int is_sp,
+ unsigned int n, enum rte_ring_queue_behavior behavior,
+ uint64_t *old_head, uint64_t *new_head,
+ uint32_t *free_entries)
+{
+ const uint32_t capacity = r->capacity;
+ unsigned int max = n;
+ int success;
+
+ do {
+ /* Reset n to the initial burst count */
+ n = max;
+
+ *old_head = r->prod_64.head;
+
+ /* add rmb barrier to avoid load/load reorder in weak
+ * memory model. It is noop on x86
+ */
+ rte_smp_rmb();
+
+ /*
+ * The subtraction is done between two unsigned 64bits value
+ * (the result is always modulo 64 bits even if we have
+ * *old_head > cons_tail). So 'free_entries' is always between 0
+ * and capacity (which is < size).
+ */
+ *free_entries = (capacity + r->cons_64.tail - *old_head);
+
+ /* check that we have enough room in ring */
+ if (unlikely(n > *free_entries))
+ n = (behavior == RTE_RING_QUEUE_FIXED) ?
+ 0 : *free_entries;
+
+ if (n == 0)
+ return 0;
+
+ *new_head = *old_head + n;
+ if (is_sp)
+ r->prod_64.head = *new_head, success = 1;
+ else
+ success = rte_atomic64_cmpset(&r->prod_64.head,
+ *old_head, *new_head);
+ } while (unlikely(success == 0));
+ return n;
+}
+
+/**
+ * @internal This function updates the consumer head for dequeue using
+ * 64-bit head/tail values.
+ *
+ * @param r
+ * A pointer to the ring structure
+ * @param is_sc
+ * Indicates whether multi-consumer path is needed or not
+ * @param n
+ * The number of elements we will want to enqueue, i.e. how far should the
+ * head be moved
+ * @param behavior
+ * RTE_RING_QUEUE_FIXED: Dequeue a fixed number of items from a ring
+ * RTE_RING_QUEUE_VARIABLE: Dequeue as many items as possible from ring
+ * @param old_head
+ * Returns head value as it was before the move, i.e. where dequeue starts
+ * @param new_head
+ * Returns the current/new head value i.e. where dequeue finishes
+ * @param entries
+ * Returns the number of entries in the ring BEFORE head was moved
+ * @return
+ * - Actual number of objects dequeued.
+ * If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
+ */
+static __rte_always_inline unsigned int
+__rte_ring_move_cons_head_64(struct rte_ring *r, unsigned int is_sc,
+ unsigned int n, enum rte_ring_queue_behavior behavior,
+ uint64_t *old_head, uint64_t *new_head,
+ uint32_t *entries)
+{
+ unsigned int max = n;
+ int success;
+
+ do {
+ /* Restore n as it may change every loop */
+ n = max;
+
+ *old_head = r->cons_64.head;
+
+ /* add rmb barrier to avoid load/load reorder in weak
+ * memory model. It is noop on x86
+ */
+ rte_smp_rmb();
+
+ /* The subtraction is done between two unsigned 64bits value
+ * (the result is always modulo 64 bits even if we have
+ * cons_head > prod_tail). So 'entries' is always between 0
+ * and size(ring)-1.
+ */
+ *entries = (r->prod_64.tail - *old_head);
+
+ /* Set the actual entries for dequeue */
+ if (n > *entries)
+ n = (behavior == RTE_RING_QUEUE_FIXED) ? 0 : *entries;
+
+ if (unlikely(n == 0))
+ return 0;
+
+ *new_head = *old_head + n;
+ if (is_sc)
+ r->cons_64.head = *new_head, success = 1;
+ else
+ success = rte_atomic64_cmpset(&r->cons_64.head,
+ *old_head, *new_head);
+ } while (unlikely(success == 0));
+ return n;
+}
+
#endif /* _RTE_RING_GENERIC_H_ */
--
2.13.6
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [PATCH v4 1/5] ring: add 64-bit headtail structure
2019-01-28 18:14 2% ` [dpdk-dev] [PATCH v4 1/5] ring: add 64-bit headtail structure Gage Eads
@ 2019-01-29 12:56 0% ` Ola Liljedahl
0 siblings, 0 replies; 200+ results
From: Ola Liljedahl @ 2019-01-29 12:56 UTC (permalink / raw)
To: gage.eads, dev
Cc: jerinj, mczekaj, nd, bruce.richardson, konstantin.ananyev,
stephen, olivier.matz, arybchenko
On Mon, 2019-01-28 at 12:14 -0600, Gage Eads wrote:
> 64-bit head and tail index widths greatly increases the time it takes for
> them to wrap-around (with current CPU speeds, it won't happen within the
> author's lifetime). This is fundamental to avoiding the ABA problem -- in
> which a thread mistakes reading the same tail index in two accesses to mean
> that the ring was not modified in the intervening time -- in the upcoming
> non-blocking ring implementation. Using a 64-bit index makes the
> possibility of this occurring effectively zero.
Just an observation.
The following invariant holds (using ring_size instead of mask):
∀ index: ring[index % ring_size].index % ring_size == index % ring_size
i.e. the N (N=log2 ring size) lsb of ring[].index will always be the same (for a
specific slot) so serve no purpose.
This means we don't have to store the whole index in each slot, it is enough to
store "index / ring_size" (which I call the lap counter). This could be useful
for an implementation for 32-bit platforms which support 64-bit CAS (to write
the slot ptr & index (lap counter) atomically) and uses 64-bit head & tail
indexes (to avoid the quick wrap around you would have with 32-bit ring
indexes).
So
ring[index % ring_size].lap = index / ring_size;
An implementation could of course use bitwise-and instead of modulo and bitwise-
right shift instead of division. The 2-logaritm of ring_size should also be pre-
calcucated and stored in the ring buffer metadata.
-- Ola
>
> This commit places the new producer and consumer structures in the same
> location in struct rte_ring as their 32-bit counterparts. Since the 32-bit
> versions are padded out to a cache line, there is space for the new
> structure without affecting the layout of struct rte_ring. Thus, the ABI is
> preserved.
>
> Signed-off-by: Gage Eads <gage.eads@intel.com>
> ---
> lib/librte_ring/rte_ring.h | 23 +++++-
> lib/librte_ring/rte_ring_c11_mem.h | 153
> +++++++++++++++++++++++++++++++++++++
> lib/librte_ring/rte_ring_generic.h | 139 +++++++++++++++++++++++++++++++++
> 3 files changed, 312 insertions(+), 3 deletions(-)
>
> diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
> index af5444a9f..00dfb5b85 100644
> --- a/lib/librte_ring/rte_ring.h
> +++ b/lib/librte_ring/rte_ring.h
> @@ -1,6 +1,6 @@
> /* SPDX-License-Identifier: BSD-3-Clause
> *
> - * Copyright (c) 2010-2017 Intel Corporation
> + * Copyright (c) 2010-2019 Intel Corporation
> * Copyright (c) 2007-2009 Kip Macy kmacy@freebsd.org
> * All rights reserved.
> * Derived from FreeBSD's bufring.h
> @@ -70,6 +70,15 @@ struct rte_ring_headtail {
> uint32_t single; /**< True if single prod/cons */
> };
>
> +/* 64-bit version of rte_ring_headtail, for use by rings that need to avoid
> + * head/tail wrap-around.
> + */
> +struct rte_ring_headtail_64 {
> + volatile uint64_t head; /**< Prod/consumer head. */
> + volatile uint64_t tail; /**< Prod/consumer tail. */
> + uint32_t single; /**< True if single prod/cons */
> +};
> +
> /**
> * An RTE ring structure.
> *
> @@ -97,11 +106,19 @@ struct rte_ring {
> char pad0 __rte_cache_aligned; /**< empty cache line */
>
> /** Ring producer status. */
> - struct rte_ring_headtail prod __rte_cache_aligned;
> + RTE_STD_C11
> + union {
> + struct rte_ring_headtail prod __rte_cache_aligned;
> + struct rte_ring_headtail_64 prod_64 __rte_cache_aligned;
> + };
> char pad1 __rte_cache_aligned; /**< empty cache line */
>
> /** Ring consumer status. */
> - struct rte_ring_headtail cons __rte_cache_aligned;
> + RTE_STD_C11
> + union {
> + struct rte_ring_headtail cons __rte_cache_aligned;
> + struct rte_ring_headtail_64 cons_64 __rte_cache_aligned;
> + };
> char pad2 __rte_cache_aligned; /**< empty cache line */
> };
>
> diff --git a/lib/librte_ring/rte_ring_c11_mem.h
> b/lib/librte_ring/rte_ring_c11_mem.h
> index 0fb73a337..47acd4c7c 100644
> --- a/lib/librte_ring/rte_ring_c11_mem.h
> +++ b/lib/librte_ring/rte_ring_c11_mem.h
> @@ -178,4 +178,157 @@ __rte_ring_move_cons_head(struct rte_ring *r, int is_sc,
> return n;
> }
>
> +/**
> + * @internal This function updates the producer head for enqueue using
> + * 64-bit head/tail values.
> + *
> + * @param r
> + * A pointer to the ring structure
> + * @param is_sp
> + * Indicates whether multi-producer path is needed or not
> + * @param n
> + * The number of elements we will want to enqueue, i.e. how far should the
> + * head be moved
> + * @param behavior
> + * RTE_RING_QUEUE_FIXED: Enqueue a fixed number of items from a ring
> + * RTE_RING_QUEUE_VARIABLE: Enqueue as many items as possible from ring
> + * @param old_head
> + * Returns head value as it was before the move, i.e. where enqueue starts
> + * @param new_head
> + * Returns the current/new head value i.e. where enqueue finishes
> + * @param free_entries
> + * Returns the amount of free space in the ring BEFORE head was moved
> + * @return
> + * Actual number of objects enqueued.
> + * If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
> + */
> +static __rte_always_inline unsigned int
> +__rte_ring_move_prod_head_64(struct rte_ring *r, unsigned int is_sp,
> + unsigned int n, enum rte_ring_queue_behavior behavior,
> + uint64_t *old_head, uint64_t *new_head,
> + uint32_t *free_entries)
> +{
> + const uint32_t capacity = r->capacity;
> + uint64_t cons_tail;
> + unsigned int max = n;
> + int success;
> +
> + *old_head = __atomic_load_n(&r->prod_64.head, __ATOMIC_RELAXED);
> + do {
> + /* Reset n to the initial burst count */
> + n = max;
> +
> + /* Ensure the head is read before tail */
> + __atomic_thread_fence(__ATOMIC_ACQUIRE);
> +
> + /* load-acquire synchronize with store-release of ht->tail
> + * in update_tail.
> + */
> + cons_tail = __atomic_load_n(&r->cons_64.tail,
> + __ATOMIC_ACQUIRE);
> +
> + /* The subtraction is done between two unsigned 32bits value
> + * (the result is always modulo 32 bits even if we have
> + * *old_head > cons_tail). So 'free_entries' is always
> between 0
> + * and capacity (which is < size).
> + */
> + *free_entries = (capacity + cons_tail - *old_head);
> +
> + /* check that we have enough room in ring */
> + if (unlikely(n > *free_entries))
> + n = (behavior == RTE_RING_QUEUE_FIXED) ?
> + 0 : *free_entries;
> +
> + if (n == 0)
> + return 0;
> +
> + *new_head = *old_head + n;
> + if (is_sp)
> + r->prod_64.head = *new_head, success = 1;
> + else
> + /* on failure, *old_head is updated */
> + success = __atomic_compare_exchange_n(&r-
> >prod_64.head,
> + old_head, *new_head,
> + 0, __ATOMIC_RELAXED,
> + __ATOMIC_RELAXED);
> + } while (unlikely(success == 0));
> + return n;
> +}
> +
> +/**
> + * @internal This function updates the consumer head for dequeue using
> + * 64-bit head/tail values.
> + *
> + * @param r
> + * A pointer to the ring structure
> + * @param is_sc
> + * Indicates whether multi-consumer path is needed or not
> + * @param n
> + * The number of elements we will want to enqueue, i.e. how far should the
> + * head be moved
> + * @param behavior
> + * RTE_RING_QUEUE_FIXED: Dequeue a fixed number of items from a ring
> + * RTE_RING_QUEUE_VARIABLE: Dequeue as many items as possible from ring
> + * @param old_head
> + * Returns head value as it was before the move, i.e. where dequeue starts
> + * @param new_head
> + * Returns the current/new head value i.e. where dequeue finishes
> + * @param entries
> + * Returns the number of entries in the ring BEFORE head was moved
> + * @return
> + * - Actual number of objects dequeued.
> + * If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
> + */
> +static __rte_always_inline unsigned int
> +__rte_ring_move_cons_head_64(struct rte_ring *r, unsigned int is_sc,
> + unsigned int n, enum rte_ring_queue_behavior behavior,
> + uint64_t *old_head, uint64_t *new_head,
> + uint32_t *entries)
> +{
> + unsigned int max = n;
> + uint64_t prod_tail;
> + int success;
> +
> + /* move cons.head atomically */
> + *old_head = __atomic_load_n(&r->cons_64.head, __ATOMIC_RELAXED);
> + do {
> + /* Restore n as it may change every loop */
> + n = max;
> +
> + /* Ensure the head is read before tail */
> + __atomic_thread_fence(__ATOMIC_ACQUIRE);
> +
> + /* this load-acquire synchronize with store-release of ht-
> >tail
> + * in update_tail.
> + */
> + prod_tail = __atomic_load_n(&r->prod_64.tail,
> + __ATOMIC_ACQUIRE);
> +
> + /* The subtraction is done between two unsigned 32bits value
> + * (the result is always modulo 32 bits even if we have
> + * cons_head > prod_tail). So 'entries' is always between 0
> + * and size(ring)-1.
> + */
> + *entries = (prod_tail - *old_head);
> +
> + /* Set the actual entries for dequeue */
> + if (n > *entries)
> + n = (behavior == RTE_RING_QUEUE_FIXED) ? 0 :
> *entries;
> +
> + if (unlikely(n == 0))
> + return 0;
> +
> + *new_head = *old_head + n;
> + if (is_sc)
> + r->cons_64.head = *new_head, success = 1;
> + else
> + /* on failure, *old_head will be updated */
> + success = __atomic_compare_exchange_n(&r-
> >cons_64.head,
> + old_head, *new_head,
> + 0, __ATOMIC_RELAXED,
> + __ATOMIC_RELAXED);
> + } while (unlikely(success == 0));
> + return n;
> +}
> +
> #endif /* _RTE_RING_C11_MEM_H_ */
> diff --git a/lib/librte_ring/rte_ring_generic.h
> b/lib/librte_ring/rte_ring_generic.h
> index ea7dbe5b9..2158e092a 100644
> --- a/lib/librte_ring/rte_ring_generic.h
> +++ b/lib/librte_ring/rte_ring_generic.h
> @@ -167,4 +167,143 @@ __rte_ring_move_cons_head(struct rte_ring *r, unsigned
> int is_sc,
> return n;
> }
>
> +/**
> + * @internal This function updates the producer head for enqueue using
> + * 64-bit head/tail values.
> + *
> + * @param r
> + * A pointer to the ring structure
> + * @param is_sp
> + * Indicates whether multi-producer path is needed or not
> + * @param n
> + * The number of elements we will want to enqueue, i.e. how far should the
> + * head be moved
> + * @param behavior
> + * RTE_RING_QUEUE_FIXED: Enqueue a fixed number of items from a ring
> + * RTE_RING_QUEUE_VARIABLE: Enqueue as many items as possible from ring
> + * @param old_head
> + * Returns head value as it was before the move, i.e. where enqueue starts
> + * @param new_head
> + * Returns the current/new head value i.e. where enqueue finishes
> + * @param free_entries
> + * Returns the amount of free space in the ring BEFORE head was moved
> + * @return
> + * Actual number of objects enqueued.
> + * If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
> + */
> +static __rte_always_inline unsigned int
> +__rte_ring_move_prod_head_64(struct rte_ring *r, unsigned int is_sp,
> + unsigned int n, enum rte_ring_queue_behavior behavior,
> + uint64_t *old_head, uint64_t *new_head,
> + uint32_t *free_entries)
> +{
> + const uint32_t capacity = r->capacity;
> + unsigned int max = n;
> + int success;
> +
> + do {
> + /* Reset n to the initial burst count */
> + n = max;
> +
> + *old_head = r->prod_64.head;
> +
> + /* add rmb barrier to avoid load/load reorder in weak
> + * memory model. It is noop on x86
> + */
> + rte_smp_rmb();
> +
> + /*
> + * The subtraction is done between two unsigned 64bits value
> + * (the result is always modulo 64 bits even if we have
> + * *old_head > cons_tail). So 'free_entries' is always
> between 0
> + * and capacity (which is < size).
> + */
> + *free_entries = (capacity + r->cons_64.tail - *old_head);
> +
> + /* check that we have enough room in ring */
> + if (unlikely(n > *free_entries))
> + n = (behavior == RTE_RING_QUEUE_FIXED) ?
> + 0 : *free_entries;
> +
> + if (n == 0)
> + return 0;
> +
> + *new_head = *old_head + n;
> + if (is_sp)
> + r->prod_64.head = *new_head, success = 1;
> + else
> + success = rte_atomic64_cmpset(&r->prod_64.head,
> + *old_head, *new_head);
> + } while (unlikely(success == 0));
> + return n;
> +}
> +
> +/**
> + * @internal This function updates the consumer head for dequeue using
> + * 64-bit head/tail values.
> + *
> + * @param r
> + * A pointer to the ring structure
> + * @param is_sc
> + * Indicates whether multi-consumer path is needed or not
> + * @param n
> + * The number of elements we will want to enqueue, i.e. how far should the
> + * head be moved
> + * @param behavior
> + * RTE_RING_QUEUE_FIXED: Dequeue a fixed number of items from a ring
> + * RTE_RING_QUEUE_VARIABLE: Dequeue as many items as possible from ring
> + * @param old_head
> + * Returns head value as it was before the move, i.e. where dequeue starts
> + * @param new_head
> + * Returns the current/new head value i.e. where dequeue finishes
> + * @param entries
> + * Returns the number of entries in the ring BEFORE head was moved
> + * @return
> + * - Actual number of objects dequeued.
> + * If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
> + */
> +static __rte_always_inline unsigned int
> +__rte_ring_move_cons_head_64(struct rte_ring *r, unsigned int is_sc,
> + unsigned int n, enum rte_ring_queue_behavior behavior,
> + uint64_t *old_head, uint64_t *new_head,
> + uint32_t *entries)
> +{
> + unsigned int max = n;
> + int success;
> +
> + do {
> + /* Restore n as it may change every loop */
> + n = max;
> +
> + *old_head = r->cons_64.head;
> +
> + /* add rmb barrier to avoid load/load reorder in weak
> + * memory model. It is noop on x86
> + */
> + rte_smp_rmb();
> +
> + /* The subtraction is done between two unsigned 64bits value
> + * (the result is always modulo 64 bits even if we have
> + * cons_head > prod_tail). So 'entries' is always between 0
> + * and size(ring)-1.
> + */
> + *entries = (r->prod_64.tail - *old_head);
> +
> + /* Set the actual entries for dequeue */
> + if (n > *entries)
> + n = (behavior == RTE_RING_QUEUE_FIXED) ? 0 :
> *entries;
> +
> + if (unlikely(n == 0))
> + return 0;
> +
> + *new_head = *old_head + n;
> + if (is_sc)
> + r->cons_64.head = *new_head, success = 1;
> + else
> + success = rte_atomic64_cmpset(&r->cons_64.head,
> + *old_head, *new_head);
> + } while (unlikely(success == 0));
> + return n;
> +}
> +
> #endif /* _RTE_RING_GENERIC_H_ */
--
Ola Liljedahl, Networking System Architect, Arm
Phone +46706866373, Skype ola.liljedahl
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v2 2/2] ci: Introduce travis builds for github repositories
@ 2019-01-30 22:16 3% ` Michael Santana
1 sibling, 0 replies; 200+ results
From: Michael Santana @ 2019-01-30 22:16 UTC (permalink / raw)
To: dev; +Cc: Aaron Conole, Bruce Richardson, Honnappa Nagarahalli, Thomas Monjalon
GitHub is a service used by developers to store repositories. GitHub
provides service integrations that allow 3rd party services to access
developer repositories and perform actions. One of these services is
Travis-CI, a simple continuous integration platform.
This is a simple initial implementation of a travis build for the DPDK
project. It doesn't require any changes from individual developers to
enable, but will allow those developers who opt-in to GitHub and the
travis service to get automatic builds for every push they make.
Additionally, the travis service will send an email to the test-report
list informing anyone interested in the automated build (including a
result).
Signed-off-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Michael Santana <msantana@redhat.com>
---
v2:
- Added aarch64 build
- Added multiple meson options for builds
- Added multiple make/config options for builds
.ci/linux-build.sh | 88 +++++++++++++++
.ci/linux-setup.sh | 31 ++++++
.travis.yml | 159 ++++++++++++++++++++++++++++
MAINTAINERS | 7 ++
doc/guides/contributing/patches.rst | 4 +
meson_cross_aarch64_gcc.txt | 12 +++
6 files changed, 301 insertions(+)
create mode 100755 .ci/linux-build.sh
create mode 100755 .ci/linux-setup.sh
create mode 100644 .travis.yml
create mode 100644 meson_cross_aarch64_gcc.txt
diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
new file mode 100755
index 000000000..66d031a21
--- /dev/null
+++ b/.ci/linux-build.sh
@@ -0,0 +1,88 @@
+#!/bin/bash
+
+# check for whether we're clang or gcc
+# setup the right options depending on the environment variables
+# run the build
+
+# Just used for the 'classic' configuration system (ie: make)
+set_conf() {
+ echo "[BUILT WITH $2 SET TO $3]"
+ c="$1/.config"
+ shift
+
+ if grep -q "$1" "$c"; then
+ sed -i "s:^$1=.*$:$1=$2:g" $c
+ else
+ echo $1=$2 >> "$c"
+ fi
+}
+
+BUILD_ARCH="x86_64-native-linuxapp-"
+
+if [ "${ARM64}" == "1" ]; then
+ # convert the arch specifier
+ BUILD_ARCH="arm64-armv8a-linuxapp-"
+ ARM64_TOOL="linaro-arm-tool"
+ export PATH=$PATH:$(pwd)/${ARM64_TOOL}/bin
+fi
+
+
+if [ "${NINJABUILD}" == "1" ]; then
+ OPTS=""
+
+ DEF_LIB="static"
+ if [ "${SHARED}" == "1" ]; then
+ DEF_LIB="shared"
+ fi
+
+ if [ "${KERNEL}" == "1" ]; then
+ OPTS="-Denable_kmods=false"
+ fi
+
+ if [ "${ARM64}" == "1" ]; then
+ OPTS="${OPTS} --cross-file meson_cross_aarch64_${CC}.txt"
+ fi
+
+ OPTS="$OPTS --default-library=$DEF_LIB"
+ meson build --werror -Dexamples=all ${OPTS}
+ ninja -C build
+else
+ EXTRA_OPTS=""
+
+ make config T="${BUILD_ARCH}${CC}"
+
+ set_conf build CONFIG_RTE_KNI_KMOD n
+ set_conf build CONFIG_RTE_EAL_IGB_UIO n
+
+ if dpkg --list | grep -q zlib1g ; then
+ set_conf build CONFIG_RTE_LIBRTE_PMD_ZLIB y
+ fi
+
+ if dpkg --list | grep -q libpcap-dev ; then
+ set_conf build CONFIG_RTE_PORT_PCAP y
+ fi
+
+ if [ "${SHARED}" == "1" ]; then
+ set_conf build CONFIG_RTE_BUILD_SHARED_LIB y
+ fi
+
+ if [ "${KERNEL}" == "1" ]; then
+ echo Unsupported kernel builds at the moment
+ fi
+
+ if [ "${ARM64}" == "1" ]; then
+ EXTRA_OPTS="CROSS=aarch64-linux-gnu-"
+
+ # need to turn off these extras
+ set_conf build CONFIG_RTE_PORT_PCAP n
+ set_conf build CONFIG_RTE_LIBRTE_PMD_ZLIB n
+
+ # convert the CC/CXX variables
+ export CC=aarch64-linux-gnu-${CC}
+ export CXX=aarch64-linux-gnu-${CXX}
+ export AR=aarch64-linux-gnu-ar
+ export STRIP=aarch64-linux-gnu-strip
+ fi
+
+ make all ${EXTRA_OPTS}
+fi
diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh
new file mode 100755
index 000000000..7d6478ef9
--- /dev/null
+++ b/.ci/linux-setup.sh
@@ -0,0 +1,31 @@
+#!/bin/bash
+
+python3.5 -m pip install --upgrade meson --user
+
+echo "ARM64 is [ ${ARM64} ]"
+
+if [ "${ARM64}" == "1" ]; then
+ # need to build & install libnuma
+ # This will only be minimal support for now.
+ ARM64_TOOL_URL='https://releases.linaro.org/components/toolchain/binaries/latest-7/aarch64-linux-gnu/gcc-linaro-7.4.1-2019.02-x86_64_aarch64-linux-gnu.tar.xz'
+ ARM64_TOOL="linaro-arm-tool"
+ NUMA_GIT_URL="https://github.com/numactl/numactl.git"
+
+ wget -O "${ARM64_TOOL}.tar.xz" "${ARM64_TOOL_URL}"
+ tar -xf "${ARM64_TOOL}.tar.xz"
+ mv gcc-linaro* "${ARM64_TOOL}"
+ export PATH=$PATH:$(pwd)/${ARM64_TOOL}/bin
+ git clone "${NUMA_GIT_URL}"
+ cd numactl
+ git checkout v2.0.11
+ ./autogen.sh
+ autoconf -i
+ mkdir numa_bin
+ ./configure --host=aarch64-linux-gnu CC=aarch64-linux-gnu-gcc \
+ --prefix=$(pwd)/numa_bin
+ make install # install numa
+ cd ..
+ cp numactl/numa_bin/include/numa*.h "${ARM64_TOOL}/aarch64-linux-gnu/libc/usr/include/"
+ cp numactl/numa_bin/lib/libnuma.* "${ARM64_TOOL}/aarch64-linux-gnu/lib64/"
+ cp numactl/numa_bin/lib/libnuma.* "${ARM64_TOOL}/lib/"
+fi
diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 000000000..f296d6914
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,159 @@
+language: c
+compiler:
+ - gcc
+ - clang
+
+os:
+ - linux
+
+addons:
+ apt:
+ sources:
+ - deadsnakes #source for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+
+before_install: ./.ci/${TRAVIS_OS_NAME}-setup.sh
+
+sudo: false
+
+env:
+ - SHARED=1
+ - KERNEL=1
+ - SHARED=1 KERNEL=1
+ - NINJABUILD=1
+ - NINJABUILD=1 SHARED=1
+ - NINJABUILD=1 KERNEL=1
+ - NINJABUILD=1 SHARED=1 KERNEL=1
+
+matrix:
+ include:
+ - env: SHARED=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #source for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: KERNEL=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #source for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: SHARED=1 KERNEL=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #source for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: SHARED=1
+ compiler: clang
+ addons:
+ apt:
+ sources:
+ - deadsnakes #source for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: KERNEL=1
+ compiler: clang
+ addons:
+ apt:
+ sources:
+ - deadsnakes #source for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: SHARED=1 KERNEL=1
+ compiler: clang
+ addons:
+ apt:
+ sources:
+ - deadsnakes #source for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: ARM64=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #source for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), libtool, python3.5, python3-pip]
+ - env: ARM64=1 NINJABUILD=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #source for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [linux-headers-$(uname -r), libtool, python3.5, python3-pip, ninja-build]
+ - env: NINJABUILD=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #source for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: NINJABUILD=1 SHARED=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #source for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: NINJABUILD=1 KERNEL=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #source for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: NINJABUILD=1 SHARED=1 KERNEL=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #source for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+
+
+script: ./.ci/${TRAVIS_OS_NAME}-build.sh
+
+notifications:
+ email:
+ recipients:
+ - test-report@dpdk.org
diff --git a/MAINTAINERS b/MAINTAINERS
index 66104405e..634afc41d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -119,6 +119,13 @@ F: config/rte_config.h
F: buildtools/gen-pmdinfo-cfile.sh
F: buildtools/symlink-drivers-solibs.sh
+Public CI
+M: Aaron Conole <aconole@redhat.com>
+M: Michael Santana <msantana@redhat.com>
+F: .travis.yml
+F: .ci/
+F: meson_cross_aarch64_gcc.txt
+
ABI versioning
M: Neil Horman <nhorman@tuxdriver.com>
F: lib/librte_compat/
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index a64bb0368..49e930cbb 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -32,6 +32,10 @@ The mailing list for DPDK development is `dev@dpdk.org <http://mails.dpdk.org/ar
Contributors will need to `register for the mailing list <http://mails.dpdk.org/listinfo/dev>`_ in order to submit patches.
It is also worth registering for the DPDK `Patchwork <http://patches.dpdk.org/project/dpdk/list/>`_
+If you are using the GitHub service, you can link your repository to
+the ``travis-ci.org`` build service. When you push patches to your GitHub
+repository, the travis service will automatically build your changes.
+
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.
diff --git a/meson_cross_aarch64_gcc.txt b/meson_cross_aarch64_gcc.txt
new file mode 100644
index 000000000..aee167d13
--- /dev/null
+++ b/meson_cross_aarch64_gcc.txt
@@ -0,0 +1,12 @@
+[binaries]
+c = 'aarch64-linux-gnu-gcc'
+cpp = 'aarch64-linux-gnu-g++'
+ar = 'aarch64-linux-gnu-gcc-ar'
+strip = 'aarch64-linux-gnu-strip'
+pkgconfig = 'aarch64-linux-gnu-pkg-config'
+
+[host_machine]
+system = 'linux'
+cpu_family = 'aarch64'
+cpu = 'aarch64'
+endian = 'little'
--
2.19.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for cryptodev config
@ 2019-01-31 9:53 4% ` Akhil Goyal
2019-02-01 11:14 4% ` Thomas Monjalon
2019-03-07 10:39 4% ` [dpdk-dev] [PATCH v2] " Anoob Joseph
1 sibling, 1 reply; 200+ results
From: Akhil Goyal @ 2019-01-31 9:53 UTC (permalink / raw)
To: Anoob Joseph, Pablo de Lara, Fiona Trahe
Cc: Jerin Jacob Kollanukkaran, Narayana Prasad Raju Athreya,
Shally Verma, dev
On 1/17/2019 3:09 PM, Anoob Joseph wrote:
> Add new field ff_enable in rte_cryptodev_config. This enables
> applications to control the features enabled on the crypto device.
>
> Proposed new layout:
>
> /** Crypto device configuration structure */
> struct rte_cryptodev_config {
> int socket_id; /**< Socket to allocate resources on */
> uint16_t nb_queue_pairs;
> /**< Number of queue pairs to configure on device */
> + uint64_t ff_enable;
> + /**< Feature flags to be enabled on the device. Only the features set
> + * on rte_cryptodev_info.feature_flags are allowed to be set.
> + */
> };
>
> For eth devices, rte_eth_conf.rx_mode.offloads and
> rte_eth_conf.tx_mode.offloads fields are used by applications to
> control the offloads enabled on the eth device. This proposal adds a
> similar ability for the crypto device.
>
> Signed-off-by: Anoob Joseph <anoobj@marvell.com>
>
Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] eal: fix strdup usages in internal config
@ 2019-01-31 11:21 0% ` Kevin Traynor
2019-01-31 14:10 0% ` Burakov, Anatoly
0 siblings, 1 reply; 200+ results
From: Kevin Traynor @ 2019-01-31 11:21 UTC (permalink / raw)
To: Anatoly Burakov, dev; +Cc: Bruce Richardson, thomas, ferruh.yigit, andy01011501
On 01/10/2019 01:38 PM, Anatoly Burakov wrote:
> Currently, we use strdup in a few places to store command-line
> parameter values for certain internal config values. There are
> several issues with that.
>
> First of all, they're never freed, so memory ends up leaking
> either after EAL exit, or when these command-line options are
> supplied multiple times.
>
> Second of all, they're defined as `const char *`, so they
> *cannot* be freed even if we wanted to.
>
> Finally, strdup may return NULL, which will be stored in the
> config. For most fields, NULL is a valid value, but for the
> default prefix, the value is always expected to be valid.
>
> To fix all of this, three things are done. First, we change
> the definitions of these values to `char *` as opposed to
> `const char *`. This does not break the ABI, and previous
> code assumes constness (which is more restrictive), so it's
> safe to do so.
>
> Then, fix all usages of strdup to check return value, and add
> a cleanup function that will free the memory occupied by
> these strings, as well as freeing them before assigning a new
> value to prevent leaks when parameter is specified multiple
> times.
>
> And finally, add an internal API to query hugefile prefix, so
> that, absent of a valid value, a default value will be
> returned, and also fix up all usages of hugefile prefix to
> use this API instead of accessing hugefile prefix directly.
>
> Bugzilla ID: 108
>
Hi Anatoly - this doesn't have stable or Fixes tags, but the bugzilla
was reported on 17.11. Is it for backport to stable branches?
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> ---
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] eal: fix strdup usages in internal config
2019-01-31 11:21 0% ` Kevin Traynor
@ 2019-01-31 14:10 0% ` Burakov, Anatoly
2019-01-31 14:15 0% ` Kevin Traynor
0 siblings, 1 reply; 200+ results
From: Burakov, Anatoly @ 2019-01-31 14:10 UTC (permalink / raw)
To: Kevin Traynor, dev; +Cc: Bruce Richardson, thomas, ferruh.yigit, andy01011501
On 31-Jan-19 11:21 AM, Kevin Traynor wrote:
> On 01/10/2019 01:38 PM, Anatoly Burakov wrote:
>> Currently, we use strdup in a few places to store command-line
>> parameter values for certain internal config values. There are
>> several issues with that.
>>
>> First of all, they're never freed, so memory ends up leaking
>> either after EAL exit, or when these command-line options are
>> supplied multiple times.
>>
>> Second of all, they're defined as `const char *`, so they
>> *cannot* be freed even if we wanted to.
>>
>> Finally, strdup may return NULL, which will be stored in the
>> config. For most fields, NULL is a valid value, but for the
>> default prefix, the value is always expected to be valid.
>>
>> To fix all of this, three things are done. First, we change
>> the definitions of these values to `char *` as opposed to
>> `const char *`. This does not break the ABI, and previous
>> code assumes constness (which is more restrictive), so it's
>> safe to do so.
>>
>> Then, fix all usages of strdup to check return value, and add
>> a cleanup function that will free the memory occupied by
>> these strings, as well as freeing them before assigning a new
>> value to prevent leaks when parameter is specified multiple
>> times.
>>
>> And finally, add an internal API to query hugefile prefix, so
>> that, absent of a valid value, a default value will be
>> returned, and also fix up all usages of hugefile prefix to
>> use this API instead of accessing hugefile prefix directly.
>>
>> Bugzilla ID: 108
>>
>
> Hi Anatoly - this doesn't have stable or Fixes tags, but the bugzilla
> was reported on 17.11. Is it for backport to stable branches?
>
It can be. Whether it's worth the effort of backporting is not my call :)
--
Thanks,
Anatoly
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] eal: fix strdup usages in internal config
2019-01-31 14:10 0% ` Burakov, Anatoly
@ 2019-01-31 14:15 0% ` Kevin Traynor
2019-01-31 15:04 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Kevin Traynor @ 2019-01-31 14:15 UTC (permalink / raw)
To: Burakov, Anatoly, dev
Cc: Bruce Richardson, thomas, ferruh.yigit, andy01011501,
Yongseok Koh, stable
On 01/31/2019 02:10 PM, Burakov, Anatoly wrote:
> On 31-Jan-19 11:21 AM, Kevin Traynor wrote:
>> On 01/10/2019 01:38 PM, Anatoly Burakov wrote:
>>> Currently, we use strdup in a few places to store command-line
>>> parameter values for certain internal config values. There are
>>> several issues with that.
>>>
>>> First of all, they're never freed, so memory ends up leaking
>>> either after EAL exit, or when these command-line options are
>>> supplied multiple times.
>>>
>>> Second of all, they're defined as `const char *`, so they
>>> *cannot* be freed even if we wanted to.
>>>
>>> Finally, strdup may return NULL, which will be stored in the
>>> config. For most fields, NULL is a valid value, but for the
>>> default prefix, the value is always expected to be valid.
>>>
>>> To fix all of this, three things are done. First, we change
>>> the definitions of these values to `char *` as opposed to
>>> `const char *`. This does not break the ABI, and previous
>>> code assumes constness (which is more restrictive), so it's
>>> safe to do so.
>>>
>>> Then, fix all usages of strdup to check return value, and add
>>> a cleanup function that will free the memory occupied by
>>> these strings, as well as freeing them before assigning a new
>>> value to prevent leaks when parameter is specified multiple
>>> times.
>>>
>>> And finally, add an internal API to query hugefile prefix, so
>>> that, absent of a valid value, a default value will be
>>> returned, and also fix up all usages of hugefile prefix to
>>> use this API instead of accessing hugefile prefix directly.
>>>
>>> Bugzilla ID: 108
>>>
>>
>> Hi Anatoly - this doesn't have stable or Fixes tags, but the bugzilla
>> was reported on 17.11. Is it for backport to stable branches?
>>
>
> It can be. Whether it's worth the effort of backporting is not my call :)
>
It's fine for 18.11 branch anyway, just needed a little help due to some
changed context. I will send diff to stable list as normal.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] eal: fix strdup usages in internal config
2019-01-31 14:15 0% ` Kevin Traynor
@ 2019-01-31 15:04 0% ` Thomas Monjalon
2019-01-31 15:55 0% ` Burakov, Anatoly
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-01-31 15:04 UTC (permalink / raw)
To: Kevin Traynor
Cc: Burakov, Anatoly, dev, Bruce Richardson, ferruh.yigit,
andy01011501, Yongseok Koh, stable
31/01/2019 15:15, Kevin Traynor:
> On 01/31/2019 02:10 PM, Burakov, Anatoly wrote:
> > On 31-Jan-19 11:21 AM, Kevin Traynor wrote:
> >> On 01/10/2019 01:38 PM, Anatoly Burakov wrote:
> >>> Currently, we use strdup in a few places to store command-line
> >>> parameter values for certain internal config values. There are
> >>> several issues with that.
> >>>
> >>> First of all, they're never freed, so memory ends up leaking
> >>> either after EAL exit, or when these command-line options are
> >>> supplied multiple times.
> >>>
> >>> Second of all, they're defined as `const char *`, so they
> >>> *cannot* be freed even if we wanted to.
> >>>
> >>> Finally, strdup may return NULL, which will be stored in the
> >>> config. For most fields, NULL is a valid value, but for the
> >>> default prefix, the value is always expected to be valid.
> >>>
> >>> To fix all of this, three things are done. First, we change
> >>> the definitions of these values to `char *` as opposed to
> >>> `const char *`. This does not break the ABI, and previous
> >>> code assumes constness (which is more restrictive), so it's
> >>> safe to do so.
> >>>
> >>> Then, fix all usages of strdup to check return value, and add
> >>> a cleanup function that will free the memory occupied by
> >>> these strings, as well as freeing them before assigning a new
> >>> value to prevent leaks when parameter is specified multiple
> >>> times.
> >>>
> >>> And finally, add an internal API to query hugefile prefix, so
> >>> that, absent of a valid value, a default value will be
> >>> returned, and also fix up all usages of hugefile prefix to
> >>> use this API instead of accessing hugefile prefix directly.
> >>>
> >>> Bugzilla ID: 108
> >>>
> >>
> >> Hi Anatoly - this doesn't have stable or Fixes tags, but the bugzilla
> >> was reported on 17.11. Is it for backport to stable branches?
> >>
> >
> > It can be. Whether it's worth the effort of backporting is not my call :)
> >
>
> It's fine for 18.11 branch anyway, just needed a little help due to some
> changed context. I will send diff to stable list as normal.
Nothing was broken. I see it like an improvement.
Not sure it is worth the effort.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] eal: fix strdup usages in internal config
2019-01-31 15:04 0% ` Thomas Monjalon
@ 2019-01-31 15:55 0% ` Burakov, Anatoly
2019-01-31 15:57 0% ` Kevin Traynor
0 siblings, 1 reply; 200+ results
From: Burakov, Anatoly @ 2019-01-31 15:55 UTC (permalink / raw)
To: Thomas Monjalon, Kevin Traynor
Cc: dev, Bruce Richardson, ferruh.yigit, andy01011501, Yongseok Koh, stable
On 31-Jan-19 3:04 PM, Thomas Monjalon wrote:
> 31/01/2019 15:15, Kevin Traynor:
>> On 01/31/2019 02:10 PM, Burakov, Anatoly wrote:
>>> On 31-Jan-19 11:21 AM, Kevin Traynor wrote:
>>>> On 01/10/2019 01:38 PM, Anatoly Burakov wrote:
>>>>> Currently, we use strdup in a few places to store command-line
>>>>> parameter values for certain internal config values. There are
>>>>> several issues with that.
>>>>>
>>>>> First of all, they're never freed, so memory ends up leaking
>>>>> either after EAL exit, or when these command-line options are
>>>>> supplied multiple times.
>>>>>
>>>>> Second of all, they're defined as `const char *`, so they
>>>>> *cannot* be freed even if we wanted to.
>>>>>
>>>>> Finally, strdup may return NULL, which will be stored in the
>>>>> config. For most fields, NULL is a valid value, but for the
>>>>> default prefix, the value is always expected to be valid.
>>>>>
>>>>> To fix all of this, three things are done. First, we change
>>>>> the definitions of these values to `char *` as opposed to
>>>>> `const char *`. This does not break the ABI, and previous
>>>>> code assumes constness (which is more restrictive), so it's
>>>>> safe to do so.
>>>>>
>>>>> Then, fix all usages of strdup to check return value, and add
>>>>> a cleanup function that will free the memory occupied by
>>>>> these strings, as well as freeing them before assigning a new
>>>>> value to prevent leaks when parameter is specified multiple
>>>>> times.
>>>>>
>>>>> And finally, add an internal API to query hugefile prefix, so
>>>>> that, absent of a valid value, a default value will be
>>>>> returned, and also fix up all usages of hugefile prefix to
>>>>> use this API instead of accessing hugefile prefix directly.
>>>>>
>>>>> Bugzilla ID: 108
>>>>>
>>>>
>>>> Hi Anatoly - this doesn't have stable or Fixes tags, but the bugzilla
>>>> was reported on 17.11. Is it for backport to stable branches?
>>>>
>>>
>>> It can be. Whether it's worth the effort of backporting is not my call :)
>>>
>>
>> It's fine for 18.11 branch anyway, just needed a little help due to some
>> changed context. I will send diff to stable list as normal.
>
> Nothing was broken. I see it like an improvement.
> Not sure it is worth the effort.
>
Well, *technically*, there was a memory leak. For example, if you
specify mbuf pool ops flag multiple times, previously allocated strdup()
call results would be discarded and leaked.
However, it's such a minor issue that it's indeed likely not worth the
effort.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] eal: fix strdup usages in internal config
2019-01-31 15:55 0% ` Burakov, Anatoly
@ 2019-01-31 15:57 0% ` Kevin Traynor
0 siblings, 0 replies; 200+ results
From: Kevin Traynor @ 2019-01-31 15:57 UTC (permalink / raw)
To: Burakov, Anatoly, Thomas Monjalon
Cc: dev, Bruce Richardson, ferruh.yigit, andy01011501, Yongseok Koh, stable
On 01/31/2019 03:55 PM, Burakov, Anatoly wrote:
> On 31-Jan-19 3:04 PM, Thomas Monjalon wrote:
>> 31/01/2019 15:15, Kevin Traynor:
>>> On 01/31/2019 02:10 PM, Burakov, Anatoly wrote:
>>>> On 31-Jan-19 11:21 AM, Kevin Traynor wrote:
>>>>> On 01/10/2019 01:38 PM, Anatoly Burakov wrote:
>>>>>> Currently, we use strdup in a few places to store command-line
>>>>>> parameter values for certain internal config values. There are
>>>>>> several issues with that.
>>>>>>
>>>>>> First of all, they're never freed, so memory ends up leaking
>>>>>> either after EAL exit, or when these command-line options are
>>>>>> supplied multiple times.
>>>>>>
>>>>>> Second of all, they're defined as `const char *`, so they
>>>>>> *cannot* be freed even if we wanted to.
>>>>>>
>>>>>> Finally, strdup may return NULL, which will be stored in the
>>>>>> config. For most fields, NULL is a valid value, but for the
>>>>>> default prefix, the value is always expected to be valid.
>>>>>>
>>>>>> To fix all of this, three things are done. First, we change
>>>>>> the definitions of these values to `char *` as opposed to
>>>>>> `const char *`. This does not break the ABI, and previous
>>>>>> code assumes constness (which is more restrictive), so it's
>>>>>> safe to do so.
>>>>>>
>>>>>> Then, fix all usages of strdup to check return value, and add
>>>>>> a cleanup function that will free the memory occupied by
>>>>>> these strings, as well as freeing them before assigning a new
>>>>>> value to prevent leaks when parameter is specified multiple
>>>>>> times.
>>>>>>
>>>>>> And finally, add an internal API to query hugefile prefix, so
>>>>>> that, absent of a valid value, a default value will be
>>>>>> returned, and also fix up all usages of hugefile prefix to
>>>>>> use this API instead of accessing hugefile prefix directly.
>>>>>>
>>>>>> Bugzilla ID: 108
>>>>>>
>>>>>
>>>>> Hi Anatoly - this doesn't have stable or Fixes tags, but the bugzilla
>>>>> was reported on 17.11. Is it for backport to stable branches?
>>>>>
>>>>
>>>> It can be. Whether it's worth the effort of backporting is not my
>>>> call :)
>>>>
>>>
>>> It's fine for 18.11 branch anyway, just needed a little help due to some
>>> changed context. I will send diff to stable list as normal.
>>
>> Nothing was broken. I see it like an improvement.
>> Not sure it is worth the effort.
>>
>
> Well, *technically*, there was a memory leak. For example, if you
> specify mbuf pool ops flag multiple times, previously allocated strdup()
> call results would be discarded and leaked.
>
> However, it's such a minor issue that it's indeed likely not worth the
> effort.
>
>
It's already done - just sent it in the batch a few mins ago
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v1] doc: update release notes for 19.02
@ 2019-01-31 16:24 3% John McNamara
2019-02-01 9:23 3% ` [dpdk-dev] [PATCH v3] " John McNamara
0 siblings, 1 reply; 200+ results
From: John McNamara @ 2019-01-31 16:24 UTC (permalink / raw)
To: dev; +Cc: marko.kovacevic, John McNamara
Fix grammar, spelling and formatting of DPDK 19.02 release notes.
Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
doc/guides/rel_notes/release_19_02.rst | 80 +++++++++++++++-------------------
1 file changed, 35 insertions(+), 45 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_02.rst b/doc/guides/rel_notes/release_19_02.rst
index 3372c4d..d7a85b2 100644
--- a/doc/guides/rel_notes/release_19_02.rst
+++ b/doc/guides/rel_notes/release_19_02.rst
@@ -54,7 +54,7 @@ New Features
Also, make sure to start the actual text at the margin.
=========================================================
-* **Added support to free hugepages exactly as originally allocated.**
+* **Added support for freing hugepages exactly as originally allocated.**
Some applications using memory event callbacks (especially for managing
RDMA memory regions) require that memory be freed back to the system
@@ -69,16 +69,19 @@ New Features
chunks of external memory to be registered with DPDK without adding them to
the malloc heap.
-* **Support for using virtio-user without hugepages**
+* **Added support for using virtio-user without hugepages.**
- The --no-huge mode was augmented to use memfd-backed memory (on systems that
- support memfd), to allow using virtio-user-based NICs without hugepages.
+ The ``--no-huge`` mode was augmented to use memfd-backed memory (on systems
+ that support memfd), to allow using virtio-user-based NICs without
+ hugepages.
-* **Release of the ENA PMD v2.0.0**
+* **Release of the ENA PMD v2.0.0.**
+
+ Version 2.0.0 of the ENA PMD was added with the following additions:
* Added Low Latency Queue v2 (LLQv2). This feature reduces the latency
of the packets by pushing the header directly through the PCI to the
- device. This allows the NIC to start handle packet right after the doorbell
+ device. This allows the NIC to start handle packets right after the doorbell
without waiting for DMA.
* Added independent configuration of HW Tx and Rx ring depths.
* Added support for up to 8k Rx descriptors per ring.
@@ -95,31 +98,31 @@ New Features
* **Updated the enic driver.**
- * Added support for ``RTE_ETH_DEV_CLOSE_REMOVE`` flag.
- * Added the handler to get firmware version string.
+ * Added support for the ``RTE_ETH_DEV_CLOSE_REMOVE`` flag.
+ * Added a handler to get the firmware version string.
* Added support for multicast filtering.
* **Added dynamic queues allocation support for i40e VF.**
- Previously, available queues of VF is reserved by PF at initialize stage.
- Now both DPDK PF and Kernel PF (>=2.1.14) will support dynamic queue
- allocation. At runtime, when VF request more queue number exceed the initial
- reserved amount, PF can allocate up to 16 queues as the request after a VF
- reset.
+ Previously, the available VF queues were reserved by PF at initialization
+ stage. Now both DPDK PF and Kernel PF (>=2.1.14) will support dynamic queue
+ allocation. At runtime, when VF requests for more queue exceed the initial
+ reserved amount, the PF can allocate up to 16 queues as the request after a
+ VF reset.
-* **Added ICE net PMD**
+* **Added ICE net PMD.**
- Added the new ``ice`` net driver for Intel® Ethernet Network Adapters E810.
+ Added the new ``ice`` net driver for Intel(R) Ethernet Network Adapters E810.
See the :doc:`../nics/ice` NIC guide for more details on this new driver.
* **Added support for SW-assisted VDPA live migration.**
This SW-assisted VDPA live migration facility helps VDPA devices without
logging capability to perform live migration, a mediated SW relay can help
- devices to track dirty pages caused by DMA. IFC driver has enabled this
+ devices to track dirty pages caused by DMA. the IFC driver has enabled this
SW-assisted live migration mode.
-* **Added security checks to cryptodev symmetric session operations.**
+* **Added security checks to the cryptodev symmetric session operations.**
Added a set of security checks to the access cryptodev symmetric session.
The checks include the session's user data read/write check and the
@@ -127,9 +130,9 @@ New Features
* **Updated the AESNI-MB PMD.**
- * Add support for intel-ipsec-mb version 0.52.
- * Add AES-GMAC algorithm support.
- * Add Plain SHA1, SHA224, SHA256, SHA384, and SHA512 algorithms support.
+ * Added support for intel-ipsec-mb version 0.52.
+ * Added AES-GMAC algorithm support.
+ * Added Plain SHA1, SHA224, SHA256, SHA384, and SHA512 algorithms support.
* **Added IPsec Library.**
@@ -145,13 +148,13 @@ New Features
* **Updated the ipsec-secgw sample application.**
The ``ipsec-secgw`` sample application has been updated to use the new
- ``librte_ipsec`` library also added in this release.
+ ``librte_ipsec`` library, which has also been added in this release.
The original functionality of ipsec-secgw is retained, a new command line
parameter ``-l`` has been added to ipsec-secgw to use the IPsec library,
instead of the existing IPsec code in the application.
The IPsec library does not support all the functionality of the existing
- ipsec-secgw application, its is planned to add the outstanding functionality
+ ipsec-secgw application. It is planned to add the outstanding functionality
in future releases.
See :doc:`../sample_app_ug/ipsec_secgw` for more information.
@@ -175,19 +178,6 @@ New Features
detected by the library.
-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
-----------
@@ -204,16 +194,16 @@ API Changes
=========================================================
* eal: Function ``rte_bsf64`` in ``rte_bitmap.h`` has been renamed to
- ``rte_bsf64_safe`` and moved to ``rte_common.h``. A new ``rte_bsf64`` function
- has been added in ``rte_common.h`` that follows convention set by existing
- ``rte_bsf32`` function.
+ ``rte_bsf64_safe`` and moved to ``rte_common.h``. A new ``rte_bsf64``
+ function has been added in ``rte_common.h`` that follows the convention set
+ by the existing ``rte_bsf32`` function.
* eal: Segment fd API on Linux now sets error code to ``ENOTSUP`` in more cases
- where segment fd API is not expected to be supported:
+ where segment the fd API is not expected to be supported:
- - On attempt to get segment fd for an externally allocated memory segment
+ - On attempt to get a segment fd for an externally allocated memory segment
- In cases where memfd support would have been required to provide segment
- fd's (such as in-memory or no-huge mode)
+ fds (such as in-memory or no-huge mode)
* eal: Functions ``rte_malloc_dump_stats()``, ``rte_malloc_dump_heaps()`` and
``rte_malloc_get_socket_stats()`` are no longer safe to call concurrently with
@@ -234,10 +224,10 @@ API Changes
* cryptodev: The parameter ``session_pool`` in the function
``rte_cryptodev_queue_pair_setup()`` is removed.
-* cryptodev: a new function ``rte_cryptodev_sym_session_pool_create()`` is
+* cryptodev: a new function ``rte_cryptodev_sym_session_pool_create()`` has been
introduced. This function is now mandatory when creating symmetric session
header mempool. Please note all crypto applications are required to use this
- function from now on. Failed to do so will cause
+ function from now on. Failed to do so will cause a
``rte_cryptodev_sym_session_create()`` function call return error.
@@ -260,14 +250,14 @@ ABI Changes
to include the following fields: ``queue ID``, ``traffic class``, ``color``.
* cryptodev: as shown in the the 18.11 deprecation notice, the structure
- ``rte_cryptodev_qp_conf`` has been added two parameters of symmetric session
+ ``rte_cryptodev_qp_conf`` has added two parameters for symmetric session
mempool and symmetric session private data mempool.
* cryptodev: as shown in the the 18.11 deprecation notice, the structure
``rte_cryptodev_sym_session`` has been updated to contain more information
to ensure safely accessing the session and session private data.
-* security: New field ``uint64_t opaque_data`` is added into
+* security: A new field ``uint64_t opaque_data`` has been added to
``rte_security_session`` structure. That would allow upper layer to easily
associate/de-associate some user defined data with the security session.
--
2.7.5
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v2] doc: update release notes for 19.02
@ 2019-01-31 17:39 3% John McNamara
0 siblings, 0 replies; 200+ results
From: John McNamara @ 2019-01-31 17:39 UTC (permalink / raw)
To: dev; +Cc: marko.kovacevic, John McNamara
Fix grammar, spelling and formatting of DPDK 19.02 release notes.
Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
doc/guides/rel_notes/release_19_02.rst | 80 +++++++++++++++-------------------
1 file changed, 35 insertions(+), 45 deletions(-)
v2: Minor typo.
diff --git a/doc/guides/rel_notes/release_19_02.rst b/doc/guides/rel_notes/release_19_02.rst
index 3372c4d..4362723 100644
--- a/doc/guides/rel_notes/release_19_02.rst
+++ b/doc/guides/rel_notes/release_19_02.rst
@@ -54,7 +54,7 @@ New Features
Also, make sure to start the actual text at the margin.
=========================================================
-* **Added support to free hugepages exactly as originally allocated.**
+* **Added support for freeing hugepages exactly as originally allocated.**
Some applications using memory event callbacks (especially for managing
RDMA memory regions) require that memory be freed back to the system
@@ -69,16 +69,19 @@ New Features
chunks of external memory to be registered with DPDK without adding them to
the malloc heap.
-* **Support for using virtio-user without hugepages**
+* **Added support for using virtio-user without hugepages.**
- The --no-huge mode was augmented to use memfd-backed memory (on systems that
- support memfd), to allow using virtio-user-based NICs without hugepages.
+ The ``--no-huge`` mode was augmented to use memfd-backed memory (on systems
+ that support memfd), to allow using virtio-user-based NICs without
+ hugepages.
-* **Release of the ENA PMD v2.0.0**
+* **Release of the ENA PMD v2.0.0.**
+
+ Version 2.0.0 of the ENA PMD was added with the following additions:
* Added Low Latency Queue v2 (LLQv2). This feature reduces the latency
of the packets by pushing the header directly through the PCI to the
- device. This allows the NIC to start handle packet right after the doorbell
+ device. This allows the NIC to start handle packets right after the doorbell
without waiting for DMA.
* Added independent configuration of HW Tx and Rx ring depths.
* Added support for up to 8k Rx descriptors per ring.
@@ -95,31 +98,31 @@ New Features
* **Updated the enic driver.**
- * Added support for ``RTE_ETH_DEV_CLOSE_REMOVE`` flag.
- * Added the handler to get firmware version string.
+ * Added support for the ``RTE_ETH_DEV_CLOSE_REMOVE`` flag.
+ * Added a handler to get the firmware version string.
* Added support for multicast filtering.
* **Added dynamic queues allocation support for i40e VF.**
- Previously, available queues of VF is reserved by PF at initialize stage.
- Now both DPDK PF and Kernel PF (>=2.1.14) will support dynamic queue
- allocation. At runtime, when VF request more queue number exceed the initial
- reserved amount, PF can allocate up to 16 queues as the request after a VF
- reset.
+ Previously, the available VF queues were reserved by PF at initialization
+ stage. Now both DPDK PF and Kernel PF (>=2.1.14) will support dynamic queue
+ allocation. At runtime, when VF requests for more queue exceed the initial
+ reserved amount, the PF can allocate up to 16 queues as the request after a
+ VF reset.
-* **Added ICE net PMD**
+* **Added ICE net PMD.**
- Added the new ``ice`` net driver for Intel® Ethernet Network Adapters E810.
+ Added the new ``ice`` net driver for Intel(R) Ethernet Network Adapters E810.
See the :doc:`../nics/ice` NIC guide for more details on this new driver.
* **Added support for SW-assisted VDPA live migration.**
This SW-assisted VDPA live migration facility helps VDPA devices without
logging capability to perform live migration, a mediated SW relay can help
- devices to track dirty pages caused by DMA. IFC driver has enabled this
+ devices to track dirty pages caused by DMA. the IFC driver has enabled this
SW-assisted live migration mode.
-* **Added security checks to cryptodev symmetric session operations.**
+* **Added security checks to the cryptodev symmetric session operations.**
Added a set of security checks to the access cryptodev symmetric session.
The checks include the session's user data read/write check and the
@@ -127,9 +130,9 @@ New Features
* **Updated the AESNI-MB PMD.**
- * Add support for intel-ipsec-mb version 0.52.
- * Add AES-GMAC algorithm support.
- * Add Plain SHA1, SHA224, SHA256, SHA384, and SHA512 algorithms support.
+ * Added support for intel-ipsec-mb version 0.52.
+ * Added AES-GMAC algorithm support.
+ * Added Plain SHA1, SHA224, SHA256, SHA384, and SHA512 algorithms support.
* **Added IPsec Library.**
@@ -145,13 +148,13 @@ New Features
* **Updated the ipsec-secgw sample application.**
The ``ipsec-secgw`` sample application has been updated to use the new
- ``librte_ipsec`` library also added in this release.
+ ``librte_ipsec`` library, which has also been added in this release.
The original functionality of ipsec-secgw is retained, a new command line
parameter ``-l`` has been added to ipsec-secgw to use the IPsec library,
instead of the existing IPsec code in the application.
The IPsec library does not support all the functionality of the existing
- ipsec-secgw application, its is planned to add the outstanding functionality
+ ipsec-secgw application. It is planned to add the outstanding functionality
in future releases.
See :doc:`../sample_app_ug/ipsec_secgw` for more information.
@@ -175,19 +178,6 @@ New Features
detected by the library.
-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
-----------
@@ -204,16 +194,16 @@ API Changes
=========================================================
* eal: Function ``rte_bsf64`` in ``rte_bitmap.h`` has been renamed to
- ``rte_bsf64_safe`` and moved to ``rte_common.h``. A new ``rte_bsf64`` function
- has been added in ``rte_common.h`` that follows convention set by existing
- ``rte_bsf32`` function.
+ ``rte_bsf64_safe`` and moved to ``rte_common.h``. A new ``rte_bsf64``
+ function has been added in ``rte_common.h`` that follows the convention set
+ by the existing ``rte_bsf32`` function.
* eal: Segment fd API on Linux now sets error code to ``ENOTSUP`` in more cases
- where segment fd API is not expected to be supported:
+ where segment the fd API is not expected to be supported:
- - On attempt to get segment fd for an externally allocated memory segment
+ - On attempt to get a segment fd for an externally allocated memory segment
- In cases where memfd support would have been required to provide segment
- fd's (such as in-memory or no-huge mode)
+ fds (such as in-memory or no-huge mode)
* eal: Functions ``rte_malloc_dump_stats()``, ``rte_malloc_dump_heaps()`` and
``rte_malloc_get_socket_stats()`` are no longer safe to call concurrently with
@@ -234,10 +224,10 @@ API Changes
* cryptodev: The parameter ``session_pool`` in the function
``rte_cryptodev_queue_pair_setup()`` is removed.
-* cryptodev: a new function ``rte_cryptodev_sym_session_pool_create()`` is
+* cryptodev: a new function ``rte_cryptodev_sym_session_pool_create()`` has been
introduced. This function is now mandatory when creating symmetric session
header mempool. Please note all crypto applications are required to use this
- function from now on. Failed to do so will cause
+ function from now on. Failed to do so will cause a
``rte_cryptodev_sym_session_create()`` function call return error.
@@ -260,14 +250,14 @@ ABI Changes
to include the following fields: ``queue ID``, ``traffic class``, ``color``.
* cryptodev: as shown in the the 18.11 deprecation notice, the structure
- ``rte_cryptodev_qp_conf`` has been added two parameters of symmetric session
+ ``rte_cryptodev_qp_conf`` has added two parameters for symmetric session
mempool and symmetric session private data mempool.
* cryptodev: as shown in the the 18.11 deprecation notice, the structure
``rte_cryptodev_sym_session`` has been updated to contain more information
to ensure safely accessing the session and session private data.
-* security: New field ``uint64_t opaque_data`` is added into
+* security: A new field ``uint64_t opaque_data`` has been added to
``rte_security_session`` structure. That would allow upper layer to easily
associate/de-associate some user defined data with the security session.
--
2.7.5
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v4 1/3] doc: clean ABI/API policy guide
@ 2019-01-31 17:46 4% ` Kevin Traynor
2019-03-01 17:32 35% ` [dpdk-dev] [PATCH v5 " Ferruh Yigit
1 sibling, 0 replies; 200+ results
From: Kevin Traynor @ 2019-01-31 17:46 UTC (permalink / raw)
To: Ferruh Yigit, dev, John McNamara, Marko Kovacevic
Cc: Luca Boccassi, Yongseok Koh, Neil Horman
On 01/24/2019 06:10 PM, Ferruh Yigit wrote:
> The original document written from the point of ABI versioning but later
> additions make document confusing, convert document into a ABI/API
> policy documentation and organize the document in subsections:
> - ABI/API Deprecation
> - Experimental APIs
> - Library versioning
> - ABI versioning
>
> Aim to clarify confusion between deprecation versioned ABI and overall
> ABI/API deprecation, also ABI versioning and Library versioning by
> organizing the sections.
>
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
For series
Acked-by: Kevin Traynor <ktraynor@redhat.com>
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v3] doc: update release notes for 19.02
2019-01-31 16:24 3% [dpdk-dev] [PATCH v1] doc: update release notes for 19.02 John McNamara
@ 2019-02-01 9:23 3% ` John McNamara
0 siblings, 0 replies; 200+ results
From: John McNamara @ 2019-02-01 9:23 UTC (permalink / raw)
To: dev; +Cc: marko.kovacevic, John McNamara
Fix grammar, spelling and formatting of DPDK 19.02 release notes.
Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
doc/guides/rel_notes/release_19_02.rst | 80 +++++++++++++++-------------------
1 file changed, 35 insertions(+), 45 deletions(-)
v3: rebased to master.
diff --git a/doc/guides/rel_notes/release_19_02.rst b/doc/guides/rel_notes/release_19_02.rst
index 027d772..6bacbdb 100644
--- a/doc/guides/rel_notes/release_19_02.rst
+++ b/doc/guides/rel_notes/release_19_02.rst
@@ -54,7 +54,7 @@ New Features
Also, make sure to start the actual text at the margin.
=========================================================
-* **Added support to free hugepages exactly as originally allocated.**
+* **Added support for freeing hugepages exactly as originally allocated.**
Some applications using memory event callbacks (especially for managing
RDMA memory regions) require that memory be freed back to the system
@@ -69,16 +69,19 @@ New Features
chunks of external memory to be registered with DPDK without adding them to
the malloc heap.
-* **Support for using virtio-user without hugepages**
+* **Added support for using virtio-user without hugepages.**
- The --no-huge mode was augmented to use memfd-backed memory (on systems that
- support memfd), to allow using virtio-user-based NICs without hugepages.
+ The ``--no-huge`` mode was augmented to use memfd-backed memory (on systems
+ that support memfd), to allow using virtio-user-based NICs without
+ hugepages.
-* **Release of the ENA PMD v2.0.0**
+* **Release of the ENA PMD v2.0.0.**
+
+ Version 2.0.0 of the ENA PMD was added with the following additions:
* Added Low Latency Queue v2 (LLQv2). This feature reduces the latency
of the packets by pushing the header directly through the PCI to the
- device. This allows the NIC to start handle packet right after the doorbell
+ device. This allows the NIC to start handle packets right after the doorbell
without waiting for DMA.
* Added independent configuration of HW Tx and Rx ring depths.
* Added support for up to 8k Rx descriptors per ring.
@@ -111,31 +114,31 @@ New Features
* **Updated the enic driver.**
- * Added support for ``RTE_ETH_DEV_CLOSE_REMOVE`` flag.
- * Added the handler to get firmware version string.
+ * Added support for the ``RTE_ETH_DEV_CLOSE_REMOVE`` flag.
+ * Added a handler to get the firmware version string.
* Added support for multicast filtering.
* **Added dynamic queues allocation support for i40e VF.**
- Previously, available queues of VF is reserved by PF at initialize stage.
- Now both DPDK PF and Kernel PF (>=2.1.14) will support dynamic queue
- allocation. At runtime, when VF request more queue number exceed the initial
- reserved amount, PF can allocate up to 16 queues as the request after a VF
- reset.
+ Previously, the available VF queues were reserved by PF at initialization
+ stage. Now both DPDK PF and Kernel PF (>=2.1.14) will support dynamic queue
+ allocation. At runtime, when VF requests for more queue exceed the initial
+ reserved amount, the PF can allocate up to 16 queues as the request after a
+ VF reset.
-* **Added ICE net PMD**
+* **Added ICE net PMD.**
- Added the new ``ice`` net driver for Intel® Ethernet Network Adapters E810.
+ Added the new ``ice`` net driver for Intel(R) Ethernet Network Adapters E810.
See the :doc:`../nics/ice` NIC guide for more details on this new driver.
* **Added support for SW-assisted VDPA live migration.**
This SW-assisted VDPA live migration facility helps VDPA devices without
logging capability to perform live migration, a mediated SW relay can help
- devices to track dirty pages caused by DMA. IFC driver has enabled this
+ devices to track dirty pages caused by DMA. the IFC driver has enabled this
SW-assisted live migration mode.
-* **Added security checks to cryptodev symmetric session operations.**
+* **Added security checks to the cryptodev symmetric session operations.**
Added a set of security checks to the access cryptodev symmetric session.
The checks include the session's user data read/write check and the
@@ -143,9 +146,9 @@ New Features
* **Updated the AESNI-MB PMD.**
- * Add support for intel-ipsec-mb version 0.52.
- * Add AES-GMAC algorithm support.
- * Add Plain SHA1, SHA224, SHA256, SHA384, and SHA512 algorithms support.
+ * Added support for intel-ipsec-mb version 0.52.
+ * Added AES-GMAC algorithm support.
+ * Added Plain SHA1, SHA224, SHA256, SHA384, and SHA512 algorithms support.
* **Added IPsec Library.**
@@ -161,13 +164,13 @@ New Features
* **Updated the ipsec-secgw sample application.**
The ``ipsec-secgw`` sample application has been updated to use the new
- ``librte_ipsec`` library also added in this release.
+ ``librte_ipsec`` library, which has also been added in this release.
The original functionality of ipsec-secgw is retained, a new command line
parameter ``-l`` has been added to ipsec-secgw to use the IPsec library,
instead of the existing IPsec code in the application.
The IPsec library does not support all the functionality of the existing
- ipsec-secgw application, its is planned to add the outstanding functionality
+ ipsec-secgw application. It is planned to add the outstanding functionality
in future releases.
See :doc:`../sample_app_ug/ipsec_secgw` for more information.
@@ -191,19 +194,6 @@ New Features
detected by the library.
-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
-----------
@@ -220,16 +210,16 @@ API Changes
=========================================================
* eal: Function ``rte_bsf64`` in ``rte_bitmap.h`` has been renamed to
- ``rte_bsf64_safe`` and moved to ``rte_common.h``. A new ``rte_bsf64`` function
- has been added in ``rte_common.h`` that follows convention set by existing
- ``rte_bsf32`` function.
+ ``rte_bsf64_safe`` and moved to ``rte_common.h``. A new ``rte_bsf64``
+ function has been added in ``rte_common.h`` that follows the convention set
+ by the existing ``rte_bsf32`` function.
* eal: Segment fd API on Linux now sets error code to ``ENOTSUP`` in more cases
- where segment fd API is not expected to be supported:
+ where segment the fd API is not expected to be supported:
- - On attempt to get segment fd for an externally allocated memory segment
+ - On attempt to get a segment fd for an externally allocated memory segment
- In cases where memfd support would have been required to provide segment
- fd's (such as in-memory or no-huge mode)
+ fds (such as in-memory or no-huge mode)
* eal: Functions ``rte_malloc_dump_stats()``, ``rte_malloc_dump_heaps()`` and
``rte_malloc_get_socket_stats()`` are no longer safe to call concurrently with
@@ -250,10 +240,10 @@ API Changes
* cryptodev: The parameter ``session_pool`` in the function
``rte_cryptodev_queue_pair_setup()`` is removed.
-* cryptodev: a new function ``rte_cryptodev_sym_session_pool_create()`` is
+* cryptodev: a new function ``rte_cryptodev_sym_session_pool_create()`` has been
introduced. This function is now mandatory when creating symmetric session
header mempool. Please note all crypto applications are required to use this
- function from now on. Failed to do so will cause
+ function from now on. Failed to do so will cause a
``rte_cryptodev_sym_session_create()`` function call return error.
@@ -276,14 +266,14 @@ ABI Changes
to include the following fields: ``queue ID``, ``traffic class``, ``color``.
* cryptodev: as shown in the the 18.11 deprecation notice, the structure
- ``rte_cryptodev_qp_conf`` has been added two parameters of symmetric session
+ ``rte_cryptodev_qp_conf`` has added two parameters for symmetric session
mempool and symmetric session private data mempool.
* cryptodev: as shown in the the 18.11 deprecation notice, the structure
``rte_cryptodev_sym_session`` has been updated to contain more information
to ensure safely accessing the session and session private data.
-* security: New field ``uint64_t opaque_data`` is added into
+* security: A new field ``uint64_t opaque_data`` has been added to
``rte_security_session`` structure. That would allow upper layer to easily
associate/de-associate some user defined data with the security session.
--
2.7.5
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for cryptodev config
2019-01-31 9:53 4% ` Akhil Goyal
@ 2019-02-01 11:14 4% ` Thomas Monjalon
2019-02-01 11:49 4% ` Trahe, Fiona
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-02-01 11:14 UTC (permalink / raw)
To: dev
Cc: Akhil Goyal, Anoob Joseph, Pablo de Lara, Fiona Trahe,
Jerin Jacob Kollanukkaran, Narayana Prasad Raju Athreya,
Shally Verma, declan.doherty
There is only one ack for this change.
A deprecation requires more agreement (3 valuable acks).
Other opinions?
31/01/2019 10:53, Akhil Goyal:
> On 1/17/2019 3:09 PM, Anoob Joseph wrote:
> > Add new field ff_enable in rte_cryptodev_config. This enables
> > applications to control the features enabled on the crypto device.
> >
> > Proposed new layout:
> >
> > /** Crypto device configuration structure */
> > struct rte_cryptodev_config {
> > int socket_id; /**< Socket to allocate resources on */
> > uint16_t nb_queue_pairs;
> > /**< Number of queue pairs to configure on device */
> > + uint64_t ff_enable;
> > + /**< Feature flags to be enabled on the device. Only the features set
> > + * on rte_cryptodev_info.feature_flags are allowed to be set.
> > + */
> > };
> >
> > For eth devices, rte_eth_conf.rx_mode.offloads and
> > rte_eth_conf.tx_mode.offloads fields are used by applications to
> > control the offloads enabled on the eth device. This proposal adds a
> > similar ability for the crypto device.
> >
> > Signed-off-by: Anoob Joseph <anoobj@marvell.com>
> >
> Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for cryptodev config
2019-02-01 11:14 4% ` Thomas Monjalon
@ 2019-02-01 11:49 4% ` Trahe, Fiona
2019-02-28 10:02 4% ` Akhil Goyal
0 siblings, 1 reply; 200+ results
From: Trahe, Fiona @ 2019-02-01 11:49 UTC (permalink / raw)
To: Thomas Monjalon, dev
Cc: Akhil Goyal, Anoob Joseph, De Lara Guarch, Pablo,
Jerin Jacob Kollanukkaran, Narayana Prasad Raju Athreya,
Shally Verma, Doherty, Declan, Trahe, Fiona
Hi Thomas, Akhil, Anoob,
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Friday, February 1, 2019 11:14 AM
> To: dev@dpdk.org
> Cc: Akhil Goyal <akhil.goyal@nxp.com>; Anoob Joseph <anoobj@marvell.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; Trahe, Fiona <fiona.trahe@intel.com>; Jerin Jacob Kollanukkaran
> <jerinj@marvell.com>; Narayana Prasad Raju Athreya <pathreya@marvell.com>; Shally Verma
> <shallyv@marvell.com>; Doherty, Declan <declan.doherty@intel.com>
> Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI change for cryptodev config
>
> There is only one ack for this change.
> A deprecation requires more agreement (3 valuable acks).
> Other opinions?
>
>
> 31/01/2019 10:53, Akhil Goyal:
> > On 1/17/2019 3:09 PM, Anoob Joseph wrote:
> > > Add new field ff_enable in rte_cryptodev_config. This enables
> > > applications to control the features enabled on the crypto device.
> > >
> > > Proposed new layout:
> > >
> > > /** Crypto device configuration structure */
> > > struct rte_cryptodev_config {
> > > int socket_id; /**< Socket to allocate resources on */
> > > uint16_t nb_queue_pairs;
> > > /**< Number of queue pairs to configure on device */
> > > + uint64_t ff_enable;
> > > + /**< Feature flags to be enabled on the device. Only the features set
> > > + * on rte_cryptodev_info.feature_flags are allowed to be set.
> > > + */
> > > };
> > >
> > > For eth devices, rte_eth_conf.rx_mode.offloads and
> > > rte_eth_conf.tx_mode.offloads fields are used by applications to
> > > control the offloads enabled on the eth device. This proposal adds a
> > > similar ability for the crypto device.
> > >
> > > Signed-off-by: Anoob Joseph <anoobj@marvell.com>
> > >
> > Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
[Fiona] Keeping consistent with ethdev is a lower priority that adding a
param that works well for crypto. As proposed this ff_enable is problematic for crypto
as it makes no sense to enable/disable most of the flags.
For some there's no sensible action a PMD can take, e.g. RTE_CRYPTODEV_FF_HW_ACCELERATED.
For some, PMDs would need to add performance impacting forks on the data path to check for disabled features. E.g. if an applic disables the RTE_CRYPTODEV_FF_CPU_AESNI flag, what does it expect the PMD to do? Not use the aesni capability of the CPU? Fork and do a less performant implementation?
Or if this flag is set, RTE_CRYPTODEV_FF_OOP_LB_IN_LB_OUT or RTE_CRYPTODEV_FF_SYM_OPERATION_CHAINING, does the PMD need to check for operations like these and reject them?
It seems there are only 3 of the 16 flags that it's desirable to disable, based on the earlier thread
RTE_CRYPTODEV_FF_ASYMMETRIC_CRYPTO
RTE_CRYPTODEV_FF_SYMMETRIC_CRYPTO
RTE_CRYPTODEV_FF_SECURITY
So I propose this param should be called ff_disable.
It should documented - and maybe provide a mask for - the flags the application is allowed to disable - only the above 3. Then PMDs only need to implement enable/disable functionality for that subset of flags.
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v4] doc: announce ring API change
@ 2019-02-01 14:36 3% ` Gage Eads
0 siblings, 0 replies; 200+ results
From: Gage Eads @ 2019-02-01 14:36 UTC (permalink / raw)
To: dev
Cc: olivier.matz, arybchenko, bruce.richardson, konstantin.ananyev,
stephen, Honnappa.Nagarahalli, gavin.hu, Ola.Liljedahl, nd
In order to support the non-blocking ring[1], an API change (additional
argument to rte_ring_get_memsize()) is required in librte_ring. This commit
updates the deprecation notice to pave the way for its inclusion in
19.08.
[1] http://mails.dpdk.org/archives/dev/2019-January/124162.html
Signed-off-by: Gage Eads <gage.eads@intel.com>
---
v4:
- 19.05 -> 19.08
v3:
- "two changes are planned" -> "one change is planned"
v2:
- Drop the ABI change notice
doc/guides/rel_notes/deprecation.rst | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index d4aea4b46..93509e23a 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -83,3 +83,9 @@ Deprecation Notices
- The size and layout of ``rte_cryptodev_qp_conf`` and syntax of
``rte_cryptodev_queue_pair_setup`` will change to to allow to use
two different mempools for crypto and device private sessions.
+
+* ring: one change is planned for rte_ring in v19.08:
+
+ - rte_ring_get_memsize() will get a new ``flags`` parameter, so it can
+ calculate the memory required for rings that require more than 8B per entry
+ (such as the upcoming non-blocking ring).
--
2.13.6
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v3 2/2] ci: Introduce travis builds for github repositories
@ 2019-02-01 16:48 3% ` Michael Santana
2019-02-06 19:17 0% ` Honnappa Nagarahalli
1 sibling, 1 reply; 200+ results
From: Michael Santana @ 2019-02-01 16:48 UTC (permalink / raw)
To: dev; +Cc: Aaron Conole, Bruce Richardson, Honnappa Nagarahalli, Thomas Monjalon
GitHub is a service used by developers to store repositories. GitHub
provides service integrations that allow 3rd party services to access
developer repositories and perform actions. One of these services is
Travis-CI, a simple continuous integration platform.
This is a simple initial implementation of a travis build for the DPDK
project. It doesn't require any changes from individual developers to
enable, but will allow those developers who opt-in to GitHub and the
travis service to get automatic builds for every push they make.
Additionally, the travis service will send an email to the test-report
list informing anyone interested in the automated build (including a
result).
Signed-off-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Michael Santana <msantana@redhat.com>
---
v3:
- Renamed ambiguous variable names and comments, including the variable
KERNEL to DISABLE_KERNEL_MODULES and comment 'source for python' to
'Repo for python'
- Removed duplicate file meson_cross_aarch64_gcc.txt. Used
arm64_armv8_linuxapp_gcc file instead
.ci/linux-build.sh | 88 +++++++++++++++
.ci/linux-setup.sh | 31 ++++++
.travis.yml | 159 ++++++++++++++++++++++++++++
MAINTAINERS | 7 ++
doc/guides/contributing/patches.rst | 4 +
5 files changed, 289 insertions(+)
create mode 100755 .ci/linux-build.sh
create mode 100755 .ci/linux-setup.sh
create mode 100644 .travis.yml
diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
new file mode 100755
index 000000000..7aa90822c
--- /dev/null
+++ b/.ci/linux-build.sh
@@ -0,0 +1,88 @@
+#!/bin/bash
+
+# check for whether we're clang or gcc
+# setup the right options depending on the environment variables
+# run the build
+
+# Just used for the 'classic' configuration system (ie: make)
+set_conf() {
+ echo "[BUILT WITH $2 SET TO $3]"
+ c="$1/.config"
+ shift
+
+ if grep -q "$1" "$c"; then
+ sed -i "s:^$1=.*$:$1=$2:g" $c
+ else
+ echo $1=$2 >> "$c"
+ fi
+}
+
+BUILD_ARCH="x86_64-native-linuxapp-"
+
+if [ "${ARM64}" == "1" ]; then
+ # convert the arch specifier
+ BUILD_ARCH="arm64-armv8a-linuxapp-"
+ ARM64_TOOL="linaro-arm-tool"
+ export PATH=$PATH:$(pwd)/${ARM64_TOOL}/bin
+fi
+
+
+if [ "${NINJABUILD}" == "1" ]; then
+ OPTS=""
+
+ DEF_LIB="static"
+ if [ "${SHARED}" == "1" ]; then
+ DEF_LIB="shared"
+ fi
+
+ if [ "${DISABLE_KERNEL_MODULES}" == "1" ]; then
+ OPTS="-Denable_kmods=false"
+ fi
+
+ if [ "${ARM64}" == "1" ]; then
+ OPTS="${OPTS} --cross-file config/arm/arm64_armv8_linuxapp_gcc"
+ fi
+
+ OPTS="$OPTS --default-library=$DEF_LIB"
+ meson build --werror -Dexamples=all ${OPTS}
+ ninja -C build
+else
+ EXTRA_OPTS=""
+
+ make config T="${BUILD_ARCH}${CC}"
+
+ set_conf build CONFIG_RTE_KNI_KMOD n
+ set_conf build CONFIG_RTE_EAL_IGB_UIO n
+
+ if dpkg --list | grep -q zlib1g ; then
+ set_conf build CONFIG_RTE_LIBRTE_PMD_ZLIB y
+ fi
+
+ if dpkg --list | grep -q libpcap-dev ; then
+ set_conf build CONFIG_RTE_PORT_PCAP y
+ fi
+
+ if [ "${SHARED}" == "1" ]; then
+ set_conf build CONFIG_RTE_BUILD_SHARED_LIB y
+ fi
+
+ if [ "${DISABLE_KERNEL_MODULES}" == "1" ]; then
+ echo Unsupported kernel builds at the moment
+ fi
+
+ if [ "${ARM64}" == "1" ]; then
+ EXTRA_OPTS="CROSS=aarch64-linux-gnu-"
+
+ # need to turn off these extras
+ set_conf build CONFIG_RTE_PORT_PCAP n
+ set_conf build CONFIG_RTE_LIBRTE_PMD_ZLIB n
+
+ # convert the CC/CXX variables
+ export CC=aarch64-linux-gnu-${CC}
+ export CXX=aarch64-linux-gnu-${CXX}
+ export AR=aarch64-linux-gnu-ar
+ export STRIP=aarch64-linux-gnu-strip
+ fi
+
+ make all ${EXTRA_OPTS}
+fi
diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh
new file mode 100755
index 000000000..7d6478ef9
--- /dev/null
+++ b/.ci/linux-setup.sh
@@ -0,0 +1,31 @@
+#!/bin/bash
+
+python3.5 -m pip install --upgrade meson --user
+
+echo "ARM64 is [ ${ARM64} ]"
+
+if [ "${ARM64}" == "1" ]; then
+ # need to build & install libnuma
+ # This will only be minimal support for now.
+ ARM64_TOOL_URL='https://releases.linaro.org/components/toolchain/binaries/latest-7/aarch64-linux-gnu/gcc-linaro-7.4.1-2019.02-x86_64_aarch64-linux-gnu.tar.xz'
+ ARM64_TOOL="linaro-arm-tool"
+ NUMA_GIT_URL="https://github.com/numactl/numactl.git"
+
+ wget -O "${ARM64_TOOL}.tar.xz" "${ARM64_TOOL_URL}"
+ tar -xf "${ARM64_TOOL}.tar.xz"
+ mv gcc-linaro* "${ARM64_TOOL}"
+ export PATH=$PATH:$(pwd)/${ARM64_TOOL}/bin
+ git clone "${NUMA_GIT_URL}"
+ cd numactl
+ git checkout v2.0.11
+ ./autogen.sh
+ autoconf -i
+ mkdir numa_bin
+ ./configure --host=aarch64-linux-gnu CC=aarch64-linux-gnu-gcc \
+ --prefix=$(pwd)/numa_bin
+ make install # install numa
+ cd ..
+ cp numactl/numa_bin/include/numa*.h "${ARM64_TOOL}/aarch64-linux-gnu/libc/usr/include/"
+ cp numactl/numa_bin/lib/libnuma.* "${ARM64_TOOL}/aarch64-linux-gnu/lib64/"
+ cp numactl/numa_bin/lib/libnuma.* "${ARM64_TOOL}/lib/"
+fi
diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 000000000..afd63aa33
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,159 @@
+language: c
+compiler:
+ - gcc
+ - clang
+
+os:
+ - linux
+
+addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+
+before_install: ./.ci/${TRAVIS_OS_NAME}-setup.sh
+
+sudo: false
+
+env:
+ - SHARED=1
+ - DISABLE_KERNEL_MODULES=1
+ - SHARED=1 DISABLE_KERNEL_MODULES=1
+ - NINJABUILD=1
+ - NINJABUILD=1 SHARED=1
+ - NINJABUILD=1 DISABLE_KERNEL_MODULES=1
+ - NINJABUILD=1 SHARED=1 DISABLE_KERNEL_MODULES=1
+
+matrix:
+ include:
+ - env: SHARED=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: DISABLE_KERNEL_MODULES=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: SHARED=1 DISABLE_KERNEL_MODULES=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: SHARED=1
+ compiler: clang
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: DISABLE_KERNEL_MODULES=1
+ compiler: clang
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: SHARED=1 DISABLE_KERNEL_MODULES=1
+ compiler: clang
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: ARM64=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), libtool, python3.5, python3-pip]
+ - env: ARM64=1 NINJABUILD=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [linux-headers-$(uname -r), libtool, python3.5, python3-pip, ninja-build]
+ - env: NINJABUILD=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: NINJABUILD=1 SHARED=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: NINJABUILD=1 DISABLE_KERNEL_MODULES=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: NINJABUILD=1 SHARED=1 DISABLE_KERNEL_MODULES=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+
+
+script: ./.ci/${TRAVIS_OS_NAME}-build.sh
+
+notifications:
+ email:
+ recipients:
+ - test-report@dpdk.org
diff --git a/MAINTAINERS b/MAINTAINERS
index 835d8a201..eed6f69d3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -119,6 +119,13 @@ F: config/rte_config.h
F: buildtools/gen-pmdinfo-cfile.sh
F: buildtools/symlink-drivers-solibs.sh
+Public CI
+M: Aaron Conole <aconole@redhat.com>
+M: Michael Santana <msantana@redhat.com>
+F: .travis.yml
+F: .ci/
+F: meson_cross_aarch64_gcc.txt
+
ABI versioning
M: Neil Horman <nhorman@tuxdriver.com>
F: lib/librte_compat/
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index a64bb0368..49e930cbb 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -32,6 +32,10 @@ The mailing list for DPDK development is `dev@dpdk.org <http://mails.dpdk.org/ar
Contributors will need to `register for the mailing list <http://mails.dpdk.org/listinfo/dev>`_ in order to submit patches.
It is also worth registering for the DPDK `Patchwork <http://patches.dpdk.org/project/dpdk/list/>`_
+If you are using the GitHub service, you can link your repository to
+the ``travis-ci.org`` build service. When you push patches to your GitHub
+repository, the travis service will automatically build your changes.
+
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.20.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH] version: 19.05-rc0
@ 2019-02-02 15:34 6% Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-02-02 15:34 UTC (permalink / raw)
To: john.mcnamara, marko.kovacevic; +Cc: dev
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
doc/guides/rel_notes/index.rst | 1 +
doc/guides/rel_notes/release_19_05.rst | 210 ++++++++++++++++++++
lib/librte_eal/common/include/rte_version.h | 6 +-
meson.build | 2 +-
4 files changed, 215 insertions(+), 4 deletions(-)
create mode 100644 doc/guides/rel_notes/release_19_05.rst
diff --git a/doc/guides/rel_notes/index.rst b/doc/guides/rel_notes/index.rst
index ccfd38bcf..e12947193 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_19_05
release_19_02
release_18_11
release_18_08
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
new file mode 100644
index 000000000..e3a7ed22f
--- /dev/null
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -0,0 +1,210 @@
+.. SPDX-License-Identifier: BSD-3-Clause
+ Copyright 2019 The DPDK contributors
+
+DPDK Release 19.05
+==================
+
+.. **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::
+
+ make doc-guides-html
+
+ xdg-open build/doc/html/guides/rel_notes/release_19_05.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
+ - 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.
+ =========================================================
+
+
+Shared Library Versions
+-----------------------
+
+.. Update any library version updated in this release
+ and prepend with a ``+`` sign, like this:
+
+ libfoo.so.1
+ + libupdated.so.2
+ libbar.so.1
+
+ This section is a comment. Do not overwrite or remove it.
+ =========================================================
+
+The libraries prepended with a plus sign were incremented in this version.
+
+.. code-block:: diff
+
+ librte_acl.so.2
+ librte_bbdev.so.1
+ librte_bitratestats.so.2
+ librte_bpf.so.1
+ librte_bus_dpaa.so.2
+ librte_bus_fslmc.so.2
+ librte_bus_ifpga.so.2
+ librte_bus_pci.so.2
+ librte_bus_vdev.so.2
+ librte_bus_vmbus.so.2
+ librte_cfgfile.so.2
+ librte_cmdline.so.2
+ librte_compressdev.so.1
+ librte_cryptodev.so.6
+ librte_distributor.so.1
+ librte_eal.so.9
+ librte_efd.so.1
+ librte_ethdev.so.11
+ librte_eventdev.so.6
+ librte_flow_classify.so.1
+ librte_gro.so.1
+ librte_gso.so.1
+ librte_hash.so.2
+ librte_ip_frag.so.1
+ librte_jobstats.so.1
+ librte_kni.so.2
+ librte_kvargs.so.1
+ librte_latencystats.so.1
+ librte_lpm.so.2
+ librte_mbuf.so.5
+ librte_member.so.1
+ librte_mempool.so.5
+ librte_meter.so.2
+ librte_metrics.so.1
+ librte_net.so.1
+ librte_pci.so.1
+ librte_pdump.so.3
+ librte_pipeline.so.3
+ librte_pmd_bnxt.so.2
+ librte_pmd_bond.so.2
+ librte_pmd_i40e.so.2
+ librte_pmd_ixgbe.so.2
+ librte_pmd_dpaa2_qdma.so.1
+ librte_pmd_ring.so.2
+ librte_pmd_softnic.so.1
+ librte_pmd_vhost.so.2
+ librte_port.so.3
+ librte_power.so.1
+ librte_rawdev.so.1
+ librte_reorder.so.1
+ librte_ring.so.2
+ librte_sched.so.2
+ librte_security.so.2
+ librte_table.so.3
+ librte_timer.so.1
+ librte_vhost.so.4
+
+
+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.
+ =========================================================
diff --git a/lib/librte_eal/common/include/rte_version.h b/lib/librte_eal/common/include/rte_version.h
index 229838f1c..a7eed7ab7 100644
--- a/lib/librte_eal/common/include/rte_version.h
+++ b/lib/librte_eal/common/include/rte_version.h
@@ -32,7 +32,7 @@ extern "C" {
/**
* Minor version/month number i.e. the mm in yy.mm.z
*/
-#define RTE_VER_MONTH 2
+#define RTE_VER_MONTH 5
/**
* Patch level number i.e. the z in yy.mm.z
@@ -42,14 +42,14 @@ extern "C" {
/**
* Extra string to be appended to version number
*/
-#define RTE_VER_SUFFIX ""
+#define RTE_VER_SUFFIX "-rc"
/**
* Patch release number
* 0-15 = release candidates
* 16 = release
*/
-#define RTE_VER_RELEASE 16
+#define RTE_VER_RELEASE 0
/**
* Macro to compute a version number usable for comparisons
diff --git a/meson.build b/meson.build
index 21d428fa1..7f5e8674b 100644
--- a/meson.build
+++ b/meson.build
@@ -2,7 +2,7 @@
# Copyright(c) 2017 Intel Corporation
project('DPDK', 'C',
- version: '19.02.0',
+ version: '19.05.0-rc0',
license: 'BSD',
default_options: ['buildtype=release', 'default_library=static'],
meson_version: '>= 0.41'
--
2.20.1
^ permalink raw reply [relevance 6%]
* [dpdk-dev] [PATCH v3] compat: merge compat library into EAL
@ 2019-02-06 11:01 4% ` Bruce Richardson
2019-02-06 12:22 0% ` Neil Horman
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2019-02-06 11:01 UTC (permalink / raw)
To: dev
Cc: Bruce Richardson, stable, Neil Horman, David Marchand, Anatoly Burakov
Since compat library is only a single header, we can easily move it into
the EAL common headers instead of tracking it separately. The downside of
this is that it becomes a little more difficult to have any libs that are
built before EAL depend on it. Thankfully, this is not a major problem as
the only library which uses rte_compat.h and is built before EAL (kvargs)
already has the path to the compat.h header file explicitly called out as
an include path.
However, to ensure that we don't hit problems later with this, we can add
EAL common headers folder to the global include list in the meson build
which means that all common headers can be safely used by all libraries, no
matter what their build order.
As a side-effect, this patch also fixes an issue with building on BSD using
meson, due to compat lib no longer needing to be listed as a dependency.
Fixes: a8499f65a1d1 ("log: add missing experimental tag")
CC: stable@dpdk.org
CC: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Reviewed-by: David Marchand <david.marchand@redhat.com>
Tested-by: David Marchand <david.marchand@redhat.com>
Tested-by: Anatoly Burakov <anatoly.burakov@intel.com>
---
V3: Add stable on CC, and remove extra word in commit log.
V2: Clean up a few missed references to the compat library in our
documentation and MAINTAINERS file.
Added in fixes tag, as this patch should also fix build issues
with BSD.
---
MAINTAINERS | 1 -
doc/api/doxy-api.conf.in | 1 -
doc/guides/contributing/documentation.rst | 1 -
doc/guides/contributing/versioning.rst | 2 +-
lib/Makefile | 2 --
lib/librte_cmdline/meson.build | 1 -
lib/librte_compat/Makefile | 13 -------------
lib/librte_compat/meson.build | 8 --------
lib/librte_eal/common/Makefile | 2 +-
.../common/include}/rte_compat.h | 0
lib/librte_eal/common/meson.build | 1 +
lib/librte_eal/linuxapp/eal/meson.build | 2 +-
lib/librte_eal/meson.build | 1 -
lib/librte_kvargs/meson.build | 3 ---
lib/meson.build | 2 +-
meson.build | 2 +-
16 files changed, 6 insertions(+), 36 deletions(-)
delete mode 100644 lib/librte_compat/Makefile
delete mode 100644 lib/librte_compat/meson.build
rename lib/{librte_compat => librte_eal/common/include}/rte_compat.h (100%)
diff --git a/MAINTAINERS b/MAINTAINERS
index 835d8a201..0707caea5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -121,7 +121,6 @@ F: buildtools/symlink-drivers-solibs.sh
ABI versioning
M: Neil Horman <nhorman@tuxdriver.com>
-F: lib/librte_compat/
F: doc/guides/rel_notes/deprecation.rst
F: devtools/validate-abi.sh
F: devtools/check-symbol-change.sh
diff --git a/doc/api/doxy-api.conf.in b/doc/api/doxy-api.conf.in
index bef9320c0..a365e669b 100644
--- a/doc/api/doxy-api.conf.in
+++ b/doc/api/doxy-api.conf.in
@@ -23,7 +23,6 @@ INPUT = @TOPDIR@/doc/api/doxy-api-index.md \
@TOPDIR@/lib/librte_bpf \
@TOPDIR@/lib/librte_cfgfile \
@TOPDIR@/lib/librte_cmdline \
- @TOPDIR@/lib/librte_compat \
@TOPDIR@/lib/librte_compressdev \
@TOPDIR@/lib/librte_cryptodev \
@TOPDIR@/lib/librte_distributor \
diff --git a/doc/guides/contributing/documentation.rst b/doc/guides/contributing/documentation.rst
index c72280a29..baf0921fb 100644
--- a/doc/guides/contributing/documentation.rst
+++ b/doc/guides/contributing/documentation.rst
@@ -22,7 +22,6 @@ The main directories that contain files related to documentation are shown below
|-- librte_acl
|-- librte_cfgfile
|-- librte_cmdline
- |-- librte_compat
|-- librte_eal
| |-- ...
...
diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index 01b36247e..18b031998 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -167,7 +167,7 @@ functionality or behavior. When that occurs, it is desirable to allow for
backward compatibility for a time with older binaries that are dynamically
linked to the DPDK.
-To support backward compatibility the ``lib/librte_compat/rte_compat.h``
+To support backward compatibility the ``rte_compat.h``
header file provides macros to use when updating exported functions. These
macros are used in conjunction with the ``rte_<library>_version.map`` file for
a given library to allow multiple versions of a symbol to exist in a shared
diff --git a/lib/Makefile b/lib/Makefile
index d6239d27c..ffbfd0d94 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -3,9 +3,7 @@
include $(RTE_SDK)/mk/rte.vars.mk
-DIRS-y += librte_compat
DIRS-$(CONFIG_RTE_LIBRTE_KVARGS) += librte_kvargs
-DEPDIRS-librte_kvargs := librte_compat
DIRS-$(CONFIG_RTE_LIBRTE_EAL) += librte_eal
DEPDIRS-librte_eal := librte_kvargs
DIRS-$(CONFIG_RTE_LIBRTE_PCI) += librte_pci
diff --git a/lib/librte_cmdline/meson.build b/lib/librte_cmdline/meson.build
index 30498906c..0fa61385f 100644
--- a/lib/librte_cmdline/meson.build
+++ b/lib/librte_cmdline/meson.build
@@ -3,7 +3,6 @@
# This library is processed before EAL
includes = [global_inc]
-includes += include_directories('../librte_eal/common/include')
version = 2
sources = files('cmdline.c',
diff --git a/lib/librte_compat/Makefile b/lib/librte_compat/Makefile
deleted file mode 100644
index 61089fe77..000000000
--- a/lib/librte_compat/Makefile
+++ /dev/null
@@ -1,13 +0,0 @@
-# SPDX-License-Identifier: BSD-3-Clause
-# Copyright(c) 2013 Neil Horman <nhorman@tuxdriver.com>
-# All rights reserved.
-
-include $(RTE_SDK)/mk/rte.vars.mk
-
-
-LIBABIVER := 1
-
-# install includes
-SYMLINK-y-include := rte_compat.h
-
-include $(RTE_SDK)/mk/rte.install.mk
diff --git a/lib/librte_compat/meson.build b/lib/librte_compat/meson.build
deleted file mode 100644
index 82c7eea55..000000000
--- a/lib/librte_compat/meson.build
+++ /dev/null
@@ -1,8 +0,0 @@
-# SPDX-License-Identifier: BSD-3-Clause
-# Copyright(c) 2017 Intel Corporation
-
-
-install_headers('rte_compat.h')
-
-set_variable('dep_rte_compat',
- declare_dependency(include_directories: include_directories('.')))
diff --git a/lib/librte_eal/common/Makefile b/lib/librte_eal/common/Makefile
index 87d8c455d..c487201b3 100644
--- a/lib/librte_eal/common/Makefile
+++ b/lib/librte_eal/common/Makefile
@@ -3,7 +3,7 @@
include $(RTE_SDK)/mk/rte.vars.mk
-INC := rte_branch_prediction.h rte_common.h
+INC := rte_branch_prediction.h rte_common.h rte_compat.h
INC += rte_debug.h rte_eal.h rte_eal_interrupts.h
INC += rte_errno.h rte_launch.h rte_lcore.h
INC += rte_log.h rte_memory.h rte_memzone.h
diff --git a/lib/librte_compat/rte_compat.h b/lib/librte_eal/common/include/rte_compat.h
similarity index 100%
rename from lib/librte_compat/rte_compat.h
rename to lib/librte_eal/common/include/rte_compat.h
diff --git a/lib/librte_eal/common/meson.build b/lib/librte_eal/common/meson.build
index 2a10d57d8..5ecae0b1f 100644
--- a/lib/librte_eal/common/meson.build
+++ b/lib/librte_eal/common/meson.build
@@ -53,6 +53,7 @@ common_headers = files(
'include/rte_bitmap.h',
'include/rte_class.h',
'include/rte_common.h',
+ 'include/rte_compat.h',
'include/rte_debug.h',
'include/rte_devargs.h',
'include/rte_dev.h',
diff --git a/lib/librte_eal/linuxapp/eal/meson.build b/lib/librte_eal/linuxapp/eal/meson.build
index 6e31c2aaa..7e68b2c0d 100644
--- a/lib/librte_eal/linuxapp/eal/meson.build
+++ b/lib/librte_eal/linuxapp/eal/meson.build
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Intel Corporation
-eal_inc += include_directories('include', '../../../librte_compat')
+eal_inc += include_directories('include')
install_subdir('include/exec-env', install_dir: get_option('includedir'))
env_objs = []
diff --git a/lib/librte_eal/meson.build b/lib/librte_eal/meson.build
index a18f3a826..64d857a4a 100644
--- a/lib/librte_eal/meson.build
+++ b/lib/librte_eal/meson.build
@@ -23,7 +23,6 @@ endif
version = 9 # the version of the EAL API
allow_experimental_apis = true
-deps += 'compat'
deps += 'kvargs'
sources = common_sources + env_sources
objs = common_objs + env_objs
diff --git a/lib/librte_kvargs/meson.build b/lib/librte_kvargs/meson.build
index acd3e5432..ecaedf5a5 100644
--- a/lib/librte_kvargs/meson.build
+++ b/lib/librte_kvargs/meson.build
@@ -2,10 +2,7 @@
# Copyright(c) 2017 Intel Corporation
includes = [global_inc]
-includes += include_directories('../librte_eal/common/include')
version = 1
sources = files('rte_kvargs.c')
headers = files('rte_kvargs.h')
-
-deps += 'compat'
diff --git a/lib/meson.build b/lib/meson.build
index e8b40f546..edcccdcb6 100644
--- a/lib/meson.build
+++ b/lib/meson.build
@@ -8,7 +8,7 @@
# sometimes skip deps that would be implied by others, e.g. if mempool is
# given as a dep, no need to mention ring. This is especially true for the
# core libs which are widely reused, so their deps are kept to a minimum.
-libraries = [ 'compat', # just a header, used for versioning
+libraries = [
'cmdline', # ethdev depends on cmdline for parsing functions
'kvargs', # eal depends on kvargs
'eal', 'ring', 'mempool', 'mbuf', 'net', 'meter', 'ethdev', 'pci', # core
diff --git a/meson.build b/meson.build
index 21d428fa1..2c83a5452 100644
--- a/meson.build
+++ b/meson.build
@@ -32,7 +32,7 @@ eal_pmd_path = join_paths(get_option('prefix'), driver_install_path)
# configure the build, and make sure configs here and in config folder are
# able to be included in any file. We also store a global array of include dirs
# for passing to pmdinfogen scripts
-global_inc = include_directories('.', 'config')
+global_inc = include_directories('.', 'config', 'lib/librte_eal/common/include')
subdir('config')
# build libs and drivers
--
2.20.1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v3] compat: merge compat library into EAL
2019-02-06 11:01 4% ` [dpdk-dev] [PATCH v3] " Bruce Richardson
@ 2019-02-06 12:22 0% ` Neil Horman
0 siblings, 0 replies; 200+ results
From: Neil Horman @ 2019-02-06 12:22 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev, stable, David Marchand, Anatoly Burakov
On Wed, Feb 06, 2019 at 11:01:30AM +0000, Bruce Richardson wrote:
> Since compat library is only a single header, we can easily move it into
> the EAL common headers instead of tracking it separately. The downside of
> this is that it becomes a little more difficult to have any libs that are
> built before EAL depend on it. Thankfully, this is not a major problem as
> the only library which uses rte_compat.h and is built before EAL (kvargs)
> already has the path to the compat.h header file explicitly called out as
> an include path.
>
> However, to ensure that we don't hit problems later with this, we can add
> EAL common headers folder to the global include list in the meson build
> which means that all common headers can be safely used by all libraries, no
> matter what their build order.
>
This assumes that the compat lib will always just be a header though, no? Will
this work in the event that someone wants to add some compatibility code that
requires its own C compilation unit?
> As a side-effect, this patch also fixes an issue with building on BSD using
> meson, due to compat lib no longer needing to be listed as a dependency.
>
Can you elaborate here a bit please? listing a lib as a dependency seems like a
fundamental function of a build system, was there a bug with meson in this
capacity?
Thanks
Neil
> Fixes: a8499f65a1d1 ("log: add missing experimental tag")
>
> CC: stable@dpdk.org
> CC: Neil Horman <nhorman@tuxdriver.com>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> Reviewed-by: David Marchand <david.marchand@redhat.com>
> Tested-by: David Marchand <david.marchand@redhat.com>
> Tested-by: Anatoly Burakov <anatoly.burakov@intel.com>
> ---
> V3: Add stable on CC, and remove extra word in commit log.
> V2: Clean up a few missed references to the compat library in our
> documentation and MAINTAINERS file.
> Added in fixes tag, as this patch should also fix build issues
> with BSD.
> ---
> MAINTAINERS | 1 -
> doc/api/doxy-api.conf.in | 1 -
> doc/guides/contributing/documentation.rst | 1 -
> doc/guides/contributing/versioning.rst | 2 +-
> lib/Makefile | 2 --
> lib/librte_cmdline/meson.build | 1 -
> lib/librte_compat/Makefile | 13 -------------
> lib/librte_compat/meson.build | 8 --------
> lib/librte_eal/common/Makefile | 2 +-
> .../common/include}/rte_compat.h | 0
> lib/librte_eal/common/meson.build | 1 +
> lib/librte_eal/linuxapp/eal/meson.build | 2 +-
> lib/librte_eal/meson.build | 1 -
> lib/librte_kvargs/meson.build | 3 ---
> lib/meson.build | 2 +-
> meson.build | 2 +-
> 16 files changed, 6 insertions(+), 36 deletions(-)
> delete mode 100644 lib/librte_compat/Makefile
> delete mode 100644 lib/librte_compat/meson.build
> rename lib/{librte_compat => librte_eal/common/include}/rte_compat.h (100%)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 835d8a201..0707caea5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -121,7 +121,6 @@ F: buildtools/symlink-drivers-solibs.sh
>
> ABI versioning
> M: Neil Horman <nhorman@tuxdriver.com>
> -F: lib/librte_compat/
> F: doc/guides/rel_notes/deprecation.rst
> F: devtools/validate-abi.sh
> F: devtools/check-symbol-change.sh
> diff --git a/doc/api/doxy-api.conf.in b/doc/api/doxy-api.conf.in
> index bef9320c0..a365e669b 100644
> --- a/doc/api/doxy-api.conf.in
> +++ b/doc/api/doxy-api.conf.in
> @@ -23,7 +23,6 @@ INPUT = @TOPDIR@/doc/api/doxy-api-index.md \
> @TOPDIR@/lib/librte_bpf \
> @TOPDIR@/lib/librte_cfgfile \
> @TOPDIR@/lib/librte_cmdline \
> - @TOPDIR@/lib/librte_compat \
> @TOPDIR@/lib/librte_compressdev \
> @TOPDIR@/lib/librte_cryptodev \
> @TOPDIR@/lib/librte_distributor \
> diff --git a/doc/guides/contributing/documentation.rst b/doc/guides/contributing/documentation.rst
> index c72280a29..baf0921fb 100644
> --- a/doc/guides/contributing/documentation.rst
> +++ b/doc/guides/contributing/documentation.rst
> @@ -22,7 +22,6 @@ The main directories that contain files related to documentation are shown below
> |-- librte_acl
> |-- librte_cfgfile
> |-- librte_cmdline
> - |-- librte_compat
> |-- librte_eal
> | |-- ...
> ...
> diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
> index 01b36247e..18b031998 100644
> --- a/doc/guides/contributing/versioning.rst
> +++ b/doc/guides/contributing/versioning.rst
> @@ -167,7 +167,7 @@ functionality or behavior. When that occurs, it is desirable to allow for
> backward compatibility for a time with older binaries that are dynamically
> linked to the DPDK.
>
> -To support backward compatibility the ``lib/librte_compat/rte_compat.h``
> +To support backward compatibility the ``rte_compat.h``
> header file provides macros to use when updating exported functions. These
> macros are used in conjunction with the ``rte_<library>_version.map`` file for
> a given library to allow multiple versions of a symbol to exist in a shared
> diff --git a/lib/Makefile b/lib/Makefile
> index d6239d27c..ffbfd0d94 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -3,9 +3,7 @@
>
> include $(RTE_SDK)/mk/rte.vars.mk
>
> -DIRS-y += librte_compat
> DIRS-$(CONFIG_RTE_LIBRTE_KVARGS) += librte_kvargs
> -DEPDIRS-librte_kvargs := librte_compat
> DIRS-$(CONFIG_RTE_LIBRTE_EAL) += librte_eal
> DEPDIRS-librte_eal := librte_kvargs
> DIRS-$(CONFIG_RTE_LIBRTE_PCI) += librte_pci
> diff --git a/lib/librte_cmdline/meson.build b/lib/librte_cmdline/meson.build
> index 30498906c..0fa61385f 100644
> --- a/lib/librte_cmdline/meson.build
> +++ b/lib/librte_cmdline/meson.build
> @@ -3,7 +3,6 @@
>
> # This library is processed before EAL
> includes = [global_inc]
> -includes += include_directories('../librte_eal/common/include')
>
> version = 2
> sources = files('cmdline.c',
> diff --git a/lib/librte_compat/Makefile b/lib/librte_compat/Makefile
> deleted file mode 100644
> index 61089fe77..000000000
> --- a/lib/librte_compat/Makefile
> +++ /dev/null
> @@ -1,13 +0,0 @@
> -# SPDX-License-Identifier: BSD-3-Clause
> -# Copyright(c) 2013 Neil Horman <nhorman@tuxdriver.com>
> -# All rights reserved.
> -
> -include $(RTE_SDK)/mk/rte.vars.mk
> -
> -
> -LIBABIVER := 1
> -
> -# install includes
> -SYMLINK-y-include := rte_compat.h
> -
> -include $(RTE_SDK)/mk/rte.install.mk
> diff --git a/lib/librte_compat/meson.build b/lib/librte_compat/meson.build
> deleted file mode 100644
> index 82c7eea55..000000000
> --- a/lib/librte_compat/meson.build
> +++ /dev/null
> @@ -1,8 +0,0 @@
> -# SPDX-License-Identifier: BSD-3-Clause
> -# Copyright(c) 2017 Intel Corporation
> -
> -
> -install_headers('rte_compat.h')
> -
> -set_variable('dep_rte_compat',
> - declare_dependency(include_directories: include_directories('.')))
> diff --git a/lib/librte_eal/common/Makefile b/lib/librte_eal/common/Makefile
> index 87d8c455d..c487201b3 100644
> --- a/lib/librte_eal/common/Makefile
> +++ b/lib/librte_eal/common/Makefile
> @@ -3,7 +3,7 @@
>
> include $(RTE_SDK)/mk/rte.vars.mk
>
> -INC := rte_branch_prediction.h rte_common.h
> +INC := rte_branch_prediction.h rte_common.h rte_compat.h
> INC += rte_debug.h rte_eal.h rte_eal_interrupts.h
> INC += rte_errno.h rte_launch.h rte_lcore.h
> INC += rte_log.h rte_memory.h rte_memzone.h
> diff --git a/lib/librte_compat/rte_compat.h b/lib/librte_eal/common/include/rte_compat.h
> similarity index 100%
> rename from lib/librte_compat/rte_compat.h
> rename to lib/librte_eal/common/include/rte_compat.h
> diff --git a/lib/librte_eal/common/meson.build b/lib/librte_eal/common/meson.build
> index 2a10d57d8..5ecae0b1f 100644
> --- a/lib/librte_eal/common/meson.build
> +++ b/lib/librte_eal/common/meson.build
> @@ -53,6 +53,7 @@ common_headers = files(
> 'include/rte_bitmap.h',
> 'include/rte_class.h',
> 'include/rte_common.h',
> + 'include/rte_compat.h',
> 'include/rte_debug.h',
> 'include/rte_devargs.h',
> 'include/rte_dev.h',
> diff --git a/lib/librte_eal/linuxapp/eal/meson.build b/lib/librte_eal/linuxapp/eal/meson.build
> index 6e31c2aaa..7e68b2c0d 100644
> --- a/lib/librte_eal/linuxapp/eal/meson.build
> +++ b/lib/librte_eal/linuxapp/eal/meson.build
> @@ -1,7 +1,7 @@
> # SPDX-License-Identifier: BSD-3-Clause
> # Copyright(c) 2017 Intel Corporation
>
> -eal_inc += include_directories('include', '../../../librte_compat')
> +eal_inc += include_directories('include')
> install_subdir('include/exec-env', install_dir: get_option('includedir'))
>
> env_objs = []
> diff --git a/lib/librte_eal/meson.build b/lib/librte_eal/meson.build
> index a18f3a826..64d857a4a 100644
> --- a/lib/librte_eal/meson.build
> +++ b/lib/librte_eal/meson.build
> @@ -23,7 +23,6 @@ endif
>
> version = 9 # the version of the EAL API
> allow_experimental_apis = true
> -deps += 'compat'
> deps += 'kvargs'
> sources = common_sources + env_sources
> objs = common_objs + env_objs
> diff --git a/lib/librte_kvargs/meson.build b/lib/librte_kvargs/meson.build
> index acd3e5432..ecaedf5a5 100644
> --- a/lib/librte_kvargs/meson.build
> +++ b/lib/librte_kvargs/meson.build
> @@ -2,10 +2,7 @@
> # Copyright(c) 2017 Intel Corporation
>
> includes = [global_inc]
> -includes += include_directories('../librte_eal/common/include')
>
> version = 1
> sources = files('rte_kvargs.c')
> headers = files('rte_kvargs.h')
> -
> -deps += 'compat'
> diff --git a/lib/meson.build b/lib/meson.build
> index e8b40f546..edcccdcb6 100644
> --- a/lib/meson.build
> +++ b/lib/meson.build
> @@ -8,7 +8,7 @@
> # sometimes skip deps that would be implied by others, e.g. if mempool is
> # given as a dep, no need to mention ring. This is especially true for the
> # core libs which are widely reused, so their deps are kept to a minimum.
> -libraries = [ 'compat', # just a header, used for versioning
> +libraries = [
> 'cmdline', # ethdev depends on cmdline for parsing functions
> 'kvargs', # eal depends on kvargs
> 'eal', 'ring', 'mempool', 'mbuf', 'net', 'meter', 'ethdev', 'pci', # core
> diff --git a/meson.build b/meson.build
> index 21d428fa1..2c83a5452 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -32,7 +32,7 @@ eal_pmd_path = join_paths(get_option('prefix'), driver_install_path)
> # configure the build, and make sure configs here and in config folder are
> # able to be included in any file. We also store a global array of include dirs
> # for passing to pmdinfogen scripts
> -global_inc = include_directories('.', 'config')
> +global_inc = include_directories('.', 'config', 'lib/librte_eal/common/include')
> subdir('config')
>
> # build libs and drivers
> --
> 2.20.1
>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3 2/2] ci: Introduce travis builds for github repositories
2019-02-01 16:48 3% ` [dpdk-dev] [PATCH v3 2/2] ci: Introduce travis builds for github repositories Michael Santana
@ 2019-02-06 19:17 0% ` Honnappa Nagarahalli
2019-02-06 20:18 0% ` Aaron Conole
0 siblings, 1 reply; 200+ results
From: Honnappa Nagarahalli @ 2019-02-06 19:17 UTC (permalink / raw)
To: Michael Santana, dev
Cc: Aaron Conole, Bruce Richardson, thomas, nd, Honnappa Nagarahalli, nd
Hi Michael/Aaron,
Thanks for adding the Arm build. I have few comments inline.
> -----Original Message-----
> From: Michael Santana <msantana@redhat.com>
> Sent: Friday, February 1, 2019 10:48 AM
> To: dev@dpdk.org
> Cc: Aaron Conole <aconole@redhat.com>; Bruce Richardson
> <bruce.richardson@intel.com>; Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com>; thomas@monjalon.net
> Subject: [PATCH v3 2/2] ci: Introduce travis builds for github repositories
>
> GitHub is a service used by developers to store repositories. GitHub provides
> service integrations that allow 3rd party services to access developer
> repositories and perform actions. One of these services is Travis-CI, a simple
> continuous integration platform.
>
> This is a simple initial implementation of a travis build for the DPDK project. It
> doesn't require any changes from individual developers to enable, but will
> allow those developers who opt-in to GitHub and the travis service to get
> automatic builds for every push they make.
>
> Additionally, the travis service will send an email to the test-report list
> informing anyone interested in the automated build (including a result).
>
> Signed-off-by: Aaron Conole <aconole@redhat.com>
> Signed-off-by: Michael Santana <msantana@redhat.com>
> ---
> v3:
> - Renamed ambiguous variable names and comments, including the variable
> KERNEL to DISABLE_KERNEL_MODULES and comment 'source for python' to
> 'Repo for python'
> - Removed duplicate file meson_cross_aarch64_gcc.txt. Used
> arm64_armv8_linuxapp_gcc file instead
>
> .ci/linux-build.sh | 88 +++++++++++++++
> .ci/linux-setup.sh | 31 ++++++
> .travis.yml | 159 ++++++++++++++++++++++++++++
> MAINTAINERS | 7 ++
> doc/guides/contributing/patches.rst | 4 +
> 5 files changed, 289 insertions(+)
> create mode 100755 .ci/linux-build.sh
> create mode 100755 .ci/linux-setup.sh
> create mode 100644 .travis.yml
>
> diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh new file mode 100755 index
> 000000000..7aa90822c
> --- /dev/null
> +++ b/.ci/linux-build.sh
> @@ -0,0 +1,88 @@
> +#!/bin/bash
> +
> +# check for whether we're clang or gcc
> +# setup the right options depending on the environment variables # run
> +the build
> +
> +# Just used for the 'classic' configuration system (ie: make)
> +set_conf() {
> + echo "[BUILT WITH $2 SET TO $3]"
> + c="$1/.config"
> + shift
> +
> + if grep -q "$1" "$c"; then
> + sed -i "s:^$1=.*$:$1=$2:g" $c
> + else
> + echo $1=$2 >> "$c"
> + fi
> +}
> +
> +BUILD_ARCH="x86_64-native-linuxapp-"
> +
> +if [ "${ARM64}" == "1" ]; then
Would be good to change the variable names from ARM64 to 'AARCH64...'
> + # convert the arch specifier
> + BUILD_ARCH="arm64-armv8a-linuxapp-"
> + ARM64_TOOL="linaro-arm-tool"
> + export PATH=$PATH:$(pwd)/${ARM64_TOOL}/bin
> +fi
> +
> +
> +if [ "${NINJABUILD}" == "1" ]; then
> + OPTS=""
> +
> + DEF_LIB="static"
> + if [ "${SHARED}" == "1" ]; then
> + DEF_LIB="shared"
> + fi
> +
> + if [ "${DISABLE_KERNEL_MODULES}" == "1" ]; then
> + OPTS="-Denable_kmods=false"
> + fi
> +
> + if [ "${ARM64}" == "1" ]; then
> + OPTS="${OPTS} --cross-file config/arm/arm64_armv8_linuxapp_gcc"
> + fi
> +
> + OPTS="$OPTS --default-library=$DEF_LIB"
> + meson build --werror -Dexamples=all ${OPTS}
> + ninja -C build
> +else
> + EXTRA_OPTS=""
> +
> + make config T="${BUILD_ARCH}${CC}"
> +
> + set_conf build CONFIG_RTE_KNI_KMOD n
> + set_conf build CONFIG_RTE_EAL_IGB_UIO n
> +
> + if dpkg --list | grep -q zlib1g ; then
> + set_conf build CONFIG_RTE_LIBRTE_PMD_ZLIB y
> + fi
> +
> + if dpkg --list | grep -q libpcap-dev ; then
> + set_conf build CONFIG_RTE_PORT_PCAP y
> + fi
> +
> + if [ "${SHARED}" == "1" ]; then
> + set_conf build CONFIG_RTE_BUILD_SHARED_LIB y
> + fi
> +
> + if [ "${DISABLE_KERNEL_MODULES}" == "1" ]; then
> + echo Unsupported kernel builds at the moment
> + fi
> +
> + if [ "${ARM64}" == "1" ]; then
> + EXTRA_OPTS="CROSS=aarch64-linux-gnu-"
> +
> + # need to turn off these extras
> + set_conf build CONFIG_RTE_PORT_PCAP n
> + set_conf build CONFIG_RTE_LIBRTE_PMD_ZLIB n
> +
> + # convert the CC/CXX variables
> + export CC=aarch64-linux-gnu-${CC}
> + export CXX=aarch64-linux-gnu-${CXX}
> + export AR=aarch64-linux-gnu-ar
> + export STRIP=aarch64-linux-gnu-strip
> + fi
> +
> + make all ${EXTRA_OPTS}
> +fi
> diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh new file mode 100755 index
> 000000000..7d6478ef9
> --- /dev/null
> +++ b/.ci/linux-setup.sh
> @@ -0,0 +1,31 @@
> +#!/bin/bash
> +
> +python3.5 -m pip install --upgrade meson --user
> +
> +echo "ARM64 is [ ${ARM64} ]"
> +
> +if [ "${ARM64}" == "1" ]; then
> + # need to build & install libnuma
> + # This will only be minimal support for now.
> +
> ARM64_TOOL_URL='https://releases.linaro.org/components/toolchain/binari
> es/latest-7/aarch64-linux-gnu/gcc-linaro-7.4.1-2019.02-x86_64_aarch64-
> linux-gnu.tar.xz'
> + ARM64_TOOL="linaro-arm-tool"
> + NUMA_GIT_URL="https://github.com/numactl/numactl.git"
> +
> + wget -O "${ARM64_TOOL}.tar.xz" "${ARM64_TOOL_URL}"
> + tar -xf "${ARM64_TOOL}.tar.xz"
> + mv gcc-linaro* "${ARM64_TOOL}"
> + export PATH=$PATH:$(pwd)/${ARM64_TOOL}/bin
> + git clone "${NUMA_GIT_URL}"
> + cd numactl
> + git checkout v2.0.11
> + ./autogen.sh
> + autoconf -i
> + mkdir numa_bin
> + ./configure --host=aarch64-linux-gnu CC=aarch64-linux-gnu-gcc \
> + --prefix=$(pwd)/numa_bin
> + make install # install numa
> + cd ..
> + cp numactl/numa_bin/include/numa*.h "${ARM64_TOOL}/aarch64-linux-
> gnu/libc/usr/include/"
> + cp numactl/numa_bin/lib/libnuma.* "${ARM64_TOOL}/aarch64-linux-
> gnu/lib64/"
> + cp numactl/numa_bin/lib/libnuma.* "${ARM64_TOOL}/lib/"
> +fi
> diff --git a/.travis.yml b/.travis.yml
> new file mode 100644
> index 000000000..afd63aa33
> --- /dev/null
> +++ b/.travis.yml
> @@ -0,0 +1,159 @@
> +language: c
> +compiler:
> + - gcc
> + - clang
> +
> +os:
> + - linux
> +
> +addons:
> + apt:
> + sources:
> + - deadsnakes #Repo for python 3.5
> + - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
> + packages:
> + - [libnuma-dev, linux-headers-$(uname -r), python3.5,
> +python3-pip, ninja-build]
> +
> +before_install: ./.ci/${TRAVIS_OS_NAME}-setup.sh
> +
> +sudo: false
> +
> +env:
> + - SHARED=1
> + - DISABLE_KERNEL_MODULES=1
> + - SHARED=1 DISABLE_KERNEL_MODULES=1
> + - NINJABUILD=1
> + - NINJABUILD=1 SHARED=1
> + - NINJABUILD=1 DISABLE_KERNEL_MODULES=1
> + - NINJABUILD=1 SHARED=1 DISABLE_KERNEL_MODULES=1
My understanding is we need to list 'ARM64=1' and 'ARM64=1 NINJABUILD=1' here.
> +
> +matrix:
> + include:
> + - env: SHARED=1
> + compiler: gcc
> + addons:
> + apt:
> + sources:
> + - deadsnakes #Repo for python 3.5
> + - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
> + packages:
> + - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
> + - [libnuma-dev, linux-headers-$(uname -r), python3.5,
> +python3-pip, ninja-build]
> + - env: DISABLE_KERNEL_MODULES=1
> + compiler: gcc
> + addons:
> + apt:
> + sources:
> + - deadsnakes #Repo for python 3.5
> + - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
> + packages:
> + - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
> + - [libnuma-dev, linux-headers-$(uname -r), python3.5,
> +python3-pip, ninja-build]
> + - env: SHARED=1 DISABLE_KERNEL_MODULES=1
> + compiler: gcc
> + addons:
> + apt:
> + sources:
> + - deadsnakes #Repo for python 3.5
> + - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
> + packages:
> + - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
> + - [libnuma-dev, linux-headers-$(uname -r), python3.5,
> +python3-pip, ninja-build]
> + - env: SHARED=1
> + compiler: clang
> + addons:
> + apt:
> + sources:
> + - deadsnakes #Repo for python 3.5
> + - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
> + packages:
> + - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
> + - [libnuma-dev, linux-headers-$(uname -r), python3.5,
> +python3-pip, ninja-build]
> + - env: DISABLE_KERNEL_MODULES=1
> + compiler: clang
> + addons:
> + apt:
> + sources:
> + - deadsnakes #Repo for python 3.5
> + - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
> + packages:
> + - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
> + - [libnuma-dev, linux-headers-$(uname -r), python3.5,
> +python3-pip, ninja-build]
> + - env: SHARED=1 DISABLE_KERNEL_MODULES=1
> + compiler: clang
> + addons:
> + apt:
> + sources:
> + - deadsnakes #Repo for python 3.5
> + - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
> + packages:
> + - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
> + - [libnuma-dev, linux-headers-$(uname -r), python3.5,
> +python3-pip, ninja-build]
> + - env: ARM64=1
> + compiler: gcc
> + addons:
> + apt:
> + sources:
> + - deadsnakes #Repo for python 3.5
> + - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
> + packages:
> + - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
> + - [libnuma-dev, linux-headers-$(uname -r), libtool,
> +python3.5, python3-pip]
> + - env: ARM64=1 NINJABUILD=1
> + compiler: gcc
> + addons:
> + apt:
> + sources:
> + - deadsnakes #Repo for python 3.5
> + - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
> + packages:
> + - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
> + - [linux-headers-$(uname -r), libtool, python3.5,
> +python3-pip, ninja-build]
> + - env: NINJABUILD=1
> + compiler: gcc
> + addons:
> + apt:
> + sources:
> + - deadsnakes #Repo for python 3.5
> + - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
> + packages:
> + - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
> + - [libnuma-dev, linux-headers-$(uname -r), python3.5,
> +python3-pip, ninja-build]
> + - env: NINJABUILD=1 SHARED=1
> + compiler: gcc
> + addons:
> + apt:
> + sources:
> + - deadsnakes #Repo for python 3.5
> + - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
> + packages:
> + - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
> + - [libnuma-dev, linux-headers-$(uname -r), python3.5,
> +python3-pip, ninja-build]
> + - env: NINJABUILD=1 DISABLE_KERNEL_MODULES=1
> + compiler: gcc
> + addons:
> + apt:
> + sources:
> + - deadsnakes #Repo for python 3.5
> + - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
> + packages:
> + - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
> + - [libnuma-dev, linux-headers-$(uname -r), python3.5,
> +python3-pip, ninja-build]
> + - env: NINJABUILD=1 SHARED=1 DISABLE_KERNEL_MODULES=1
> + compiler: gcc
> + addons:
> + apt:
> + sources:
> + - deadsnakes #Repo for python 3.5
> + - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
> + packages:
> + - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
> + - [libnuma-dev, linux-headers-$(uname -r), python3.5,
> +python3-pip, ninja-build]
> +
> +
> +script: ./.ci/${TRAVIS_OS_NAME}-build.sh
> +
> +notifications:
> + email:
> + recipients:
> + - test-report@dpdk.org
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 835d8a201..eed6f69d3 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -119,6 +119,13 @@ F: config/rte_config.h
> F: buildtools/gen-pmdinfo-cfile.sh
> F: buildtools/symlink-drivers-solibs.sh
>
> +Public CI
> +M: Aaron Conole <aconole@redhat.com>
> +M: Michael Santana <msantana@redhat.com>
> +F: .travis.yml
> +F: .ci/
> +F: meson_cross_aarch64_gcc.txt
Not required
> +
> ABI versioning
> M: Neil Horman <nhorman@tuxdriver.com>
> F: lib/librte_compat/
> diff --git a/doc/guides/contributing/patches.rst
> b/doc/guides/contributing/patches.rst
> index a64bb0368..49e930cbb 100644
> --- a/doc/guides/contributing/patches.rst
> +++ b/doc/guides/contributing/patches.rst
> @@ -32,6 +32,10 @@ The mailing list for DPDK development is
> `dev@dpdk.org <http://mails.dpdk.org/ar Contributors will need to `register
> for the mailing list <http://mails.dpdk.org/listinfo/dev>`_ in order to submit
> patches.
> It is also worth registering for the DPDK `Patchwork
> <http://patches.dpdk.org/project/dpdk/list/>`_
>
> +If you are using the GitHub service, you can link your repository to
> +the ``travis-ci.org`` build service. When you push patches to your
> +GitHub repository, the travis service will automatically build your changes.
> +
> 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.20.1
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3 2/2] ci: Introduce travis builds for github repositories
2019-02-06 19:17 0% ` Honnappa Nagarahalli
@ 2019-02-06 20:18 0% ` Aaron Conole
0 siblings, 0 replies; 200+ results
From: Aaron Conole @ 2019-02-06 20:18 UTC (permalink / raw)
To: Honnappa Nagarahalli; +Cc: Michael Santana, dev, Bruce Richardson, thomas, nd
Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> writes:
> Hi Michael/Aaron,
> Thanks for adding the Arm build. I have few comments inline.
>
>> -----Original Message-----
>> From: Michael Santana <msantana@redhat.com>
>> Sent: Friday, February 1, 2019 10:48 AM
>> To: dev@dpdk.org
>> Cc: Aaron Conole <aconole@redhat.com>; Bruce Richardson
>> <bruce.richardson@intel.com>; Honnappa Nagarahalli
>> <Honnappa.Nagarahalli@arm.com>; thomas@monjalon.net
>> Subject: [PATCH v3 2/2] ci: Introduce travis builds for github repositories
>>
>> GitHub is a service used by developers to store repositories. GitHub provides
>> service integrations that allow 3rd party services to access developer
>> repositories and perform actions. One of these services is Travis-CI, a simple
>> continuous integration platform.
>>
>> This is a simple initial implementation of a travis build for the DPDK project. It
>> doesn't require any changes from individual developers to enable, but will
>> allow those developers who opt-in to GitHub and the travis service to get
>> automatic builds for every push they make.
>>
>> Additionally, the travis service will send an email to the test-report list
>> informing anyone interested in the automated build (including a result).
>>
>> Signed-off-by: Aaron Conole <aconole@redhat.com>
>> Signed-off-by: Michael Santana <msantana@redhat.com>
>> ---
>> v3:
>> - Renamed ambiguous variable names and comments, including the variable
>> KERNEL to DISABLE_KERNEL_MODULES and comment 'source for python' to
>> 'Repo for python'
>> - Removed duplicate file meson_cross_aarch64_gcc.txt. Used
>> arm64_armv8_linuxapp_gcc file instead
>>
>> .ci/linux-build.sh | 88 +++++++++++++++
>> .ci/linux-setup.sh | 31 ++++++
>> .travis.yml | 159 ++++++++++++++++++++++++++++
>> MAINTAINERS | 7 ++
>> doc/guides/contributing/patches.rst | 4 +
>> 5 files changed, 289 insertions(+)
>> create mode 100755 .ci/linux-build.sh
>> create mode 100755 .ci/linux-setup.sh
>> create mode 100644 .travis.yml
>>
>> diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh new file mode 100755 index
>> 000000000..7aa90822c
>> --- /dev/null
>> +++ b/.ci/linux-build.sh
>> @@ -0,0 +1,88 @@
>> +#!/bin/bash
>> +
>> +# check for whether we're clang or gcc
>> +# setup the right options depending on the environment variables # run
>> +the build
>> +
>> +# Just used for the 'classic' configuration system (ie: make)
>> +set_conf() {
>> + echo "[BUILT WITH $2 SET TO $3]"
>> + c="$1/.config"
>> + shift
>> +
>> + if grep -q "$1" "$c"; then
>> + sed -i "s:^$1=.*$:$1=$2:g" $c
>> + else
>> + echo $1=$2 >> "$c"
>> + fi
>> +}
>> +
>> +BUILD_ARCH="x86_64-native-linuxapp-"
>> +
>> +if [ "${ARM64}" == "1" ]; then
> Would be good to change the variable names from ARM64 to 'AARCH64...'
Since we need to spin a change anyway, we'll change it.
>> + # convert the arch specifier
>> + BUILD_ARCH="arm64-armv8a-linuxapp-"
>> + ARM64_TOOL="linaro-arm-tool"
>> + export PATH=$PATH:$(pwd)/${ARM64_TOOL}/bin
>> +fi
>> +
>> +
>> +if [ "${NINJABUILD}" == "1" ]; then
>> + OPTS=""
>> +
>> + DEF_LIB="static"
>> + if [ "${SHARED}" == "1" ]; then
>> + DEF_LIB="shared"
>> + fi
>> +
>> + if [ "${DISABLE_KERNEL_MODULES}" == "1" ]; then
>> + OPTS="-Denable_kmods=false"
>> + fi
>> +
>> + if [ "${ARM64}" == "1" ]; then
>> + OPTS="${OPTS} --cross-file config/arm/arm64_armv8_linuxapp_gcc"
>> + fi
>> +
>> + OPTS="$OPTS --default-library=$DEF_LIB"
>> + meson build --werror -Dexamples=all ${OPTS}
>> + ninja -C build
>> +else
>> + EXTRA_OPTS=""
>> +
>> + make config T="${BUILD_ARCH}${CC}"
>> +
>> + set_conf build CONFIG_RTE_KNI_KMOD n
>> + set_conf build CONFIG_RTE_EAL_IGB_UIO n
>> +
>> + if dpkg --list | grep -q zlib1g ; then
>> + set_conf build CONFIG_RTE_LIBRTE_PMD_ZLIB y
>> + fi
>> +
>> + if dpkg --list | grep -q libpcap-dev ; then
>> + set_conf build CONFIG_RTE_PORT_PCAP y
>> + fi
>> +
>> + if [ "${SHARED}" == "1" ]; then
>> + set_conf build CONFIG_RTE_BUILD_SHARED_LIB y
>> + fi
>> +
>> + if [ "${DISABLE_KERNEL_MODULES}" == "1" ]; then
>> + echo Unsupported kernel builds at the moment
>> + fi
>> +
>> + if [ "${ARM64}" == "1" ]; then
>> + EXTRA_OPTS="CROSS=aarch64-linux-gnu-"
>> +
>> + # need to turn off these extras
>> + set_conf build CONFIG_RTE_PORT_PCAP n
>> + set_conf build CONFIG_RTE_LIBRTE_PMD_ZLIB n
>> +
>> + # convert the CC/CXX variables
>> + export CC=aarch64-linux-gnu-${CC}
>> + export CXX=aarch64-linux-gnu-${CXX}
>> + export AR=aarch64-linux-gnu-ar
>> + export STRIP=aarch64-linux-gnu-strip
>> + fi
>> +
>> + make all ${EXTRA_OPTS}
>> +fi
>> diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh new file mode 100755 index
>> 000000000..7d6478ef9
>> --- /dev/null
>> +++ b/.ci/linux-setup.sh
>> @@ -0,0 +1,31 @@
>> +#!/bin/bash
>> +
>> +python3.5 -m pip install --upgrade meson --user
>> +
>> +echo "ARM64 is [ ${ARM64} ]"
>> +
>> +if [ "${ARM64}" == "1" ]; then
>> + # need to build & install libnuma
>> + # This will only be minimal support for now.
>> +
>> ARM64_TOOL_URL='https://releases.linaro.org/components/toolchain/binari
>> es/latest-7/aarch64-linux-gnu/gcc-linaro-7.4.1-2019.02-x86_64_aarch64-
>> linux-gnu.tar.xz'
>> + ARM64_TOOL="linaro-arm-tool"
>> + NUMA_GIT_URL="https://github.com/numactl/numactl.git"
>> +
>> + wget -O "${ARM64_TOOL}.tar.xz" "${ARM64_TOOL_URL}"
>> + tar -xf "${ARM64_TOOL}.tar.xz"
>> + mv gcc-linaro* "${ARM64_TOOL}"
>> + export PATH=$PATH:$(pwd)/${ARM64_TOOL}/bin
>> + git clone "${NUMA_GIT_URL}"
>> + cd numactl
>> + git checkout v2.0.11
>> + ./autogen.sh
>> + autoconf -i
>> + mkdir numa_bin
>> + ./configure --host=aarch64-linux-gnu CC=aarch64-linux-gnu-gcc \
>> + --prefix=$(pwd)/numa_bin
>> + make install # install numa
>> + cd ..
>> + cp numactl/numa_bin/include/numa*.h "${ARM64_TOOL}/aarch64-linux-
>> gnu/libc/usr/include/"
>> + cp numactl/numa_bin/lib/libnuma.* "${ARM64_TOOL}/aarch64-linux-
>> gnu/lib64/"
>> + cp numactl/numa_bin/lib/libnuma.* "${ARM64_TOOL}/lib/"
>> +fi
>> diff --git a/.travis.yml b/.travis.yml
>> new file mode 100644
>> index 000000000..afd63aa33
>> --- /dev/null
>> +++ b/.travis.yml
>> @@ -0,0 +1,159 @@
>> +language: c
>> +compiler:
>> + - gcc
>> + - clang
>> +
>> +os:
>> + - linux
>> +
>> +addons:
>> + apt:
>> + sources:
>> + - deadsnakes #Repo for python 3.5
>> + - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
>> + packages:
>> + - [libnuma-dev, linux-headers-$(uname -r), python3.5,
>> +python3-pip, ninja-build]
>> +
>> +before_install: ./.ci/${TRAVIS_OS_NAME}-setup.sh
>> +
>> +sudo: false
>> +
>> +env:
>> + - SHARED=1
>> + - DISABLE_KERNEL_MODULES=1
>> + - SHARED=1 DISABLE_KERNEL_MODULES=1
>> + - NINJABUILD=1
>> + - NINJABUILD=1 SHARED=1
>> + - NINJABUILD=1 DISABLE_KERNEL_MODULES=1
>> + - NINJABUILD=1 SHARED=1 DISABLE_KERNEL_MODULES=1
> My understanding is we need to list 'ARM64=1' and 'ARM64=1 NINJABUILD=1' here.
We don't. We have a build explicitly in the matrix section below to
cover it.
>> +
>> +matrix:
>> + include:
>> + - env: SHARED=1
>> + compiler: gcc
>> + addons:
>> + apt:
>> + sources:
>> + - deadsnakes #Repo for python 3.5
>> + - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
>> + packages:
>> + - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
>> + - [libnuma-dev, linux-headers-$(uname -r), python3.5,
>> +python3-pip, ninja-build]
>> + - env: DISABLE_KERNEL_MODULES=1
>> + compiler: gcc
>> + addons:
>> + apt:
>> + sources:
>> + - deadsnakes #Repo for python 3.5
>> + - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
>> + packages:
>> + - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
>> + - [libnuma-dev, linux-headers-$(uname -r), python3.5,
>> +python3-pip, ninja-build]
>> + - env: SHARED=1 DISABLE_KERNEL_MODULES=1
>> + compiler: gcc
>> + addons:
>> + apt:
>> + sources:
>> + - deadsnakes #Repo for python 3.5
>> + - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
>> + packages:
>> + - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
>> + - [libnuma-dev, linux-headers-$(uname -r), python3.5,
>> +python3-pip, ninja-build]
>> + - env: SHARED=1
>> + compiler: clang
>> + addons:
>> + apt:
>> + sources:
>> + - deadsnakes #Repo for python 3.5
>> + - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
>> + packages:
>> + - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
>> + - [libnuma-dev, linux-headers-$(uname -r), python3.5,
>> +python3-pip, ninja-build]
>> + - env: DISABLE_KERNEL_MODULES=1
>> + compiler: clang
>> + addons:
>> + apt:
>> + sources:
>> + - deadsnakes #Repo for python 3.5
>> + - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
>> + packages:
>> + - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
>> + - [libnuma-dev, linux-headers-$(uname -r), python3.5,
>> +python3-pip, ninja-build]
>> + - env: SHARED=1 DISABLE_KERNEL_MODULES=1
>> + compiler: clang
>> + addons:
>> + apt:
>> + sources:
>> + - deadsnakes #Repo for python 3.5
>> + - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
>> + packages:
>> + - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
>> + - [libnuma-dev, linux-headers-$(uname -r), python3.5,
>> +python3-pip, ninja-build]
>> + - env: ARM64=1
>> + compiler: gcc
>> + addons:
>> + apt:
>> + sources:
>> + - deadsnakes #Repo for python 3.5
>> + - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
>> + packages:
>> + - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
>> + - [libnuma-dev, linux-headers-$(uname -r), libtool,
>> +python3.5, python3-pip]
>> + - env: ARM64=1 NINJABUILD=1
>> + compiler: gcc
>> + addons:
>> + apt:
>> + sources:
>> + - deadsnakes #Repo for python 3.5
>> + - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
>> + packages:
>> + - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
>> + - [linux-headers-$(uname -r), libtool, python3.5,
>> +python3-pip, ninja-build]
>> + - env: NINJABUILD=1
>> + compiler: gcc
>> + addons:
>> + apt:
>> + sources:
>> + - deadsnakes #Repo for python 3.5
>> + - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
>> + packages:
>> + - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
>> + - [libnuma-dev, linux-headers-$(uname -r), python3.5,
>> +python3-pip, ninja-build]
>> + - env: NINJABUILD=1 SHARED=1
>> + compiler: gcc
>> + addons:
>> + apt:
>> + sources:
>> + - deadsnakes #Repo for python 3.5
>> + - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
>> + packages:
>> + - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
>> + - [libnuma-dev, linux-headers-$(uname -r), python3.5,
>> +python3-pip, ninja-build]
>> + - env: NINJABUILD=1 DISABLE_KERNEL_MODULES=1
>> + compiler: gcc
>> + addons:
>> + apt:
>> + sources:
>> + - deadsnakes #Repo for python 3.5
>> + - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
>> + packages:
>> + - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
>> + - [libnuma-dev, linux-headers-$(uname -r), python3.5,
>> +python3-pip, ninja-build]
>> + - env: NINJABUILD=1 SHARED=1 DISABLE_KERNEL_MODULES=1
>> + compiler: gcc
>> + addons:
>> + apt:
>> + sources:
>> + - deadsnakes #Repo for python 3.5
>> + - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
>> + packages:
>> + - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
>> + - [libnuma-dev, linux-headers-$(uname -r), python3.5,
>> +python3-pip, ninja-build]
>> +
>> +
>> +script: ./.ci/${TRAVIS_OS_NAME}-build.sh
>> +
>> +notifications:
>> + email:
>> + recipients:
>> + - test-report@dpdk.org
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 835d8a201..eed6f69d3 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -119,6 +119,13 @@ F: config/rte_config.h
>> F: buildtools/gen-pmdinfo-cfile.sh
>> F: buildtools/symlink-drivers-solibs.sh
>>
>> +Public CI
>> +M: Aaron Conole <aconole@redhat.com>
>> +M: Michael Santana <msantana@redhat.com>
>> +F: .travis.yml
>> +F: .ci/
>> +F: meson_cross_aarch64_gcc.txt
> Not required
Oops. Okay we will fix it.
>> +
>> ABI versioning
>> M: Neil Horman <nhorman@tuxdriver.com>
>> F: lib/librte_compat/
>> diff --git a/doc/guides/contributing/patches.rst
>> b/doc/guides/contributing/patches.rst
>> index a64bb0368..49e930cbb 100644
>> --- a/doc/guides/contributing/patches.rst
>> +++ b/doc/guides/contributing/patches.rst
>> @@ -32,6 +32,10 @@ The mailing list for DPDK development is
>> `dev@dpdk.org <http://mails.dpdk.org/ar Contributors will need to `register
>> for the mailing list <http://mails.dpdk.org/listinfo/dev>`_ in order to submit
>> patches.
>> It is also worth registering for the DPDK `Patchwork
>> <http://patches.dpdk.org/project/dpdk/list/>`_
>>
>> +If you are using the GitHub service, you can link your repository to
>> +the ``travis-ci.org`` build service. When you push patches to your
>> +GitHub repository, the travis service will automatically build your changes.
>> +
>> 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.20.1
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v4 2/2] ci: Introduce travis builds for github repositories
@ 2019-02-06 22:13 3% ` Michael Santana
1 sibling, 0 replies; 200+ results
From: Michael Santana @ 2019-02-06 22:13 UTC (permalink / raw)
To: dev; +Cc: Aaron Conole, Bruce Richardson, Honnappa Nagarahalli, Thomas Monjalon
GitHub is a service used by developers to store repositories. GitHub
provides service integrations that allow 3rd party services to access
developer repositories and perform actions. One of these services is
Travis-CI, a simple continuous integration platform.
This is a simple initial implementation of a travis build for the DPDK
project. It doesn't require any changes from individual developers to
enable, but will allow those developers who opt-in to GitHub and the
travis service to get automatic builds for every push they make.
Additionally, the travis service will send an email to the test-report
list informing anyone interested in the automated build (including a
result).
Signed-off-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Michael Santana <msantana@redhat.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
---
v4:
- Remove non-existing file form maintainers list:
meson_cross_aarch64_gcc.txt
- Renamed ARCH64 to AARM64 for travis environment variable
.ci/linux-build.sh | 88 +++++++++++++++
.ci/linux-setup.sh | 31 ++++++
.travis.yml | 159 ++++++++++++++++++++++++++++
MAINTAINERS | 6 ++
doc/guides/contributing/patches.rst | 4 +
5 files changed, 288 insertions(+)
create mode 100755 .ci/linux-build.sh
create mode 100755 .ci/linux-setup.sh
create mode 100644 .travis.yml
diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
new file mode 100755
index 000000000..9c6af2ead
--- /dev/null
+++ b/.ci/linux-build.sh
@@ -0,0 +1,88 @@
+#!/bin/bash
+
+# check for whether we're clang or gcc
+# setup the right options depending on the environment variables
+# run the build
+
+# Just used for the 'classic' configuration system (ie: make)
+set_conf() {
+ echo "[BUILT WITH $2 SET TO $3]"
+ c="$1/.config"
+ shift
+
+ if grep -q "$1" "$c"; then
+ sed -i "s:^$1=.*$:$1=$2:g" $c
+ else
+ echo $1=$2 >> "$c"
+ fi
+}
+
+BUILD_ARCH="x86_64-native-linuxapp-"
+
+if [ "${AARCH64}" == "1" ]; then
+ # convert the arch specifier
+ BUILD_ARCH="arm64-armv8a-linuxapp-"
+ ARM64_TOOL="linaro-arm-tool"
+ export PATH=$PATH:$(pwd)/${ARM64_TOOL}/bin
+fi
+
+
+if [ "${NINJABUILD}" == "1" ]; then
+ OPTS=""
+
+ DEF_LIB="static"
+ if [ "${SHARED}" == "1" ]; then
+ DEF_LIB="shared"
+ fi
+
+ if [ "${DISABLE_KERNEL_MODULES}" == "1" ]; then
+ OPTS="-Denable_kmods=false"
+ fi
+
+ if [ "${AARCH64}" == "1" ]; then
+ OPTS="${OPTS} --cross-file config/arm/arm64_armv8_linuxapp_gcc"
+ fi
+
+ OPTS="$OPTS --default-library=$DEF_LIB"
+ meson build --werror -Dexamples=all ${OPTS}
+ ninja -C build
+else
+ EXTRA_OPTS=""
+
+ make config T="${BUILD_ARCH}${CC}"
+
+ set_conf build CONFIG_RTE_KNI_KMOD n
+ set_conf build CONFIG_RTE_EAL_IGB_UIO n
+
+ if dpkg --list | grep -q zlib1g ; then
+ set_conf build CONFIG_RTE_LIBRTE_PMD_ZLIB y
+ fi
+
+ if dpkg --list | grep -q libpcap-dev ; then
+ set_conf build CONFIG_RTE_PORT_PCAP y
+ fi
+
+ if [ "${SHARED}" == "1" ]; then
+ set_conf build CONFIG_RTE_BUILD_SHARED_LIB y
+ fi
+
+ if [ "${DISABLE_KERNEL_MODULES}" == "1" ]; then
+ echo Unsupported kernel builds at the moment
+ fi
+
+ if [ "${AARCH64}" == "1" ]; then
+ EXTRA_OPTS="CROSS=aarch64-linux-gnu-"
+
+ # need to turn off these extras
+ set_conf build CONFIG_RTE_PORT_PCAP n
+ set_conf build CONFIG_RTE_LIBRTE_PMD_ZLIB n
+
+ # convert the CC/CXX variables
+ export CC=aarch64-linux-gnu-${CC}
+ export CXX=aarch64-linux-gnu-${CXX}
+ export AR=aarch64-linux-gnu-ar
+ export STRIP=aarch64-linux-gnu-strip
+ fi
+
+ make all ${EXTRA_OPTS}
+fi
diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh
new file mode 100755
index 000000000..15183165b
--- /dev/null
+++ b/.ci/linux-setup.sh
@@ -0,0 +1,31 @@
+#!/bin/bash
+
+python3.5 -m pip install --upgrade meson --user
+
+echo "AARCH64 is [ ${AARCH64} ]"
+
+if [ "${AARCH64}" == "1" ]; then
+ # need to build & install libnuma
+ # This will only be minimal support for now.
+ ARM64_TOOL_URL='https://releases.linaro.org/components/toolchain/binaries/latest-7/aarch64-linux-gnu/gcc-linaro-7.4.1-2019.02-x86_64_aarch64-linux-gnu.tar.xz'
+ ARM64_TOOL="linaro-arm-tool"
+ NUMA_GIT_URL="https://github.com/numactl/numactl.git"
+
+ wget -O "${ARM64_TOOL}.tar.xz" "${ARM64_TOOL_URL}"
+ tar -xf "${ARM64_TOOL}.tar.xz"
+ mv gcc-linaro* "${ARM64_TOOL}"
+ export PATH=$PATH:$(pwd)/${ARM64_TOOL}/bin
+ git clone "${NUMA_GIT_URL}"
+ cd numactl
+ git checkout v2.0.11
+ ./autogen.sh
+ autoconf -i
+ mkdir numa_bin
+ ./configure --host=aarch64-linux-gnu CC=aarch64-linux-gnu-gcc \
+ --prefix=$(pwd)/numa_bin
+ make install # install numa
+ cd ..
+ cp numactl/numa_bin/include/numa*.h "${ARM64_TOOL}/aarch64-linux-gnu/libc/usr/include/"
+ cp numactl/numa_bin/lib/libnuma.* "${ARM64_TOOL}/aarch64-linux-gnu/lib64/"
+ cp numactl/numa_bin/lib/libnuma.* "${ARM64_TOOL}/lib/"
+fi
diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 000000000..0faa35770
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,159 @@
+language: c
+compiler:
+ - gcc
+ - clang
+
+os:
+ - linux
+
+addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+
+before_install: ./.ci/${TRAVIS_OS_NAME}-setup.sh
+
+sudo: false
+
+env:
+ - SHARED=1
+ - DISABLE_KERNEL_MODULES=1
+ - SHARED=1 DISABLE_KERNEL_MODULES=1
+ - NINJABUILD=1
+ - NINJABUILD=1 SHARED=1
+ - NINJABUILD=1 DISABLE_KERNEL_MODULES=1
+ - NINJABUILD=1 SHARED=1 DISABLE_KERNEL_MODULES=1
+
+matrix:
+ include:
+ - env: SHARED=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: DISABLE_KERNEL_MODULES=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: SHARED=1 DISABLE_KERNEL_MODULES=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: SHARED=1
+ compiler: clang
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: DISABLE_KERNEL_MODULES=1
+ compiler: clang
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: SHARED=1 DISABLE_KERNEL_MODULES=1
+ compiler: clang
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: AARCH64=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), libtool, python3.5, python3-pip]
+ - env: AARCH64=1 NINJABUILD=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [linux-headers-$(uname -r), libtool, python3.5, python3-pip, ninja-build]
+ - env: NINJABUILD=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: NINJABUILD=1 SHARED=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: NINJABUILD=1 DISABLE_KERNEL_MODULES=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: NINJABUILD=1 SHARED=1 DISABLE_KERNEL_MODULES=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+
+
+script: ./.ci/${TRAVIS_OS_NAME}-build.sh
+
+notifications:
+ email:
+ recipients:
+ - test-report@dpdk.org
diff --git a/MAINTAINERS b/MAINTAINERS
index 835d8a201..3f9de1151 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -119,6 +119,12 @@ F: config/rte_config.h
F: buildtools/gen-pmdinfo-cfile.sh
F: buildtools/symlink-drivers-solibs.sh
+Public CI
+M: Aaron Conole <aconole@redhat.com>
+M: Michael Santana <msantana@redhat.com>
+F: .travis.yml
+F: .ci/
+
ABI versioning
M: Neil Horman <nhorman@tuxdriver.com>
F: lib/librte_compat/
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index a64bb0368..49e930cbb 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -32,6 +32,10 @@ The mailing list for DPDK development is `dev@dpdk.org <http://mails.dpdk.org/ar
Contributors will need to `register for the mailing list <http://mails.dpdk.org/listinfo/dev>`_ in order to submit patches.
It is also worth registering for the DPDK `Patchwork <http://patches.dpdk.org/project/dpdk/list/>`_
+If you are using the GitHub service, you can link your repository to
+the ``travis-ci.org`` build service. When you push patches to your GitHub
+repository, the travis service will automatically build your changes.
+
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.20.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v5 2/2] ci: Introduce travis builds for github repositories
@ 2019-02-07 22:01 3% ` Michael Santana
1 sibling, 0 replies; 200+ results
From: Michael Santana @ 2019-02-07 22:01 UTC (permalink / raw)
To: dev; +Cc: Aaron Conole, Bruce Richardson, Honnappa Nagarahalli, Thomas Monjalon
GitHub is a service used by developers to store repositories. GitHub
provides service integrations that allow 3rd party services to access
developer repositories and perform actions. One of these services is
Travis-CI, a simple continuous integration platform.
This is a simple initial implementation of a travis build for the DPDK
project. It doesn't require any changes from individual developers to
enable, but will allow those developers who opt-in to GitHub and the
travis service to get automatic builds for every push they make.
Additionally, the travis service will send an email to the test-report
list informing anyone interested in the automated build (including a
result).
Signed-off-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Michael Santana <msantana@redhat.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
---
v5:
Renamed ARM64 to AARCH64
.ci/linux-build.sh | 88 +++++++++++++++
.ci/linux-setup.sh | 31 ++++++
.travis.yml | 159 ++++++++++++++++++++++++++++
MAINTAINERS | 6 ++
doc/guides/contributing/patches.rst | 4 +
5 files changed, 288 insertions(+)
create mode 100755 .ci/linux-build.sh
create mode 100755 .ci/linux-setup.sh
create mode 100644 .travis.yml
diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
new file mode 100755
index 000000000..3535a905f
--- /dev/null
+++ b/.ci/linux-build.sh
@@ -0,0 +1,88 @@
+#!/bin/bash
+
+# check for whether we're clang or gcc
+# setup the right options depending on the environment variables
+# run the build
+
+# Just used for the 'classic' configuration system (ie: make)
+set_conf() {
+ echo "[BUILT WITH $2 SET TO $3]"
+ c="$1/.config"
+ shift
+
+ if grep -q "$1" "$c"; then
+ sed -i "s:^$1=.*$:$1=$2:g" $c
+ else
+ echo $1=$2 >> "$c"
+ fi
+}
+
+BUILD_ARCH="x86_64-native-linuxapp-"
+
+if [ "${AARCH64}" == "1" ]; then
+ # convert the arch specifier
+ BUILD_ARCH="arm64-armv8a-linuxapp-"
+ AARCH64_TOOL="linaro-arm-tool"
+ export PATH=$PATH:$(pwd)/${AARCH64_TOOL}/bin
+fi
+
+
+if [ "${NINJABUILD}" == "1" ]; then
+ OPTS=""
+
+ DEF_LIB="static"
+ if [ "${SHARED}" == "1" ]; then
+ DEF_LIB="shared"
+ fi
+
+ if [ "${DISABLE_KERNEL_MODULES}" == "1" ]; then
+ OPTS="-Denable_kmods=false"
+ fi
+
+ if [ "${AARCH64}" == "1" ]; then
+ OPTS="${OPTS} --cross-file config/arm/arm64_armv8_linuxapp_gcc"
+ fi
+
+ OPTS="$OPTS --default-library=$DEF_LIB"
+ meson build --werror -Dexamples=all ${OPTS}
+ ninja -C build
+else
+ EXTRA_OPTS=""
+
+ make config T="${BUILD_ARCH}${CC}"
+
+ set_conf build CONFIG_RTE_KNI_KMOD n
+ set_conf build CONFIG_RTE_EAL_IGB_UIO n
+
+ if dpkg --list | grep -q zlib1g ; then
+ set_conf build CONFIG_RTE_LIBRTE_PMD_ZLIB y
+ fi
+
+ if dpkg --list | grep -q libpcap-dev ; then
+ set_conf build CONFIG_RTE_PORT_PCAP y
+ fi
+
+ if [ "${SHARED}" == "1" ]; then
+ set_conf build CONFIG_RTE_BUILD_SHARED_LIB y
+ fi
+
+ if [ "${DISABLE_KERNEL_MODULES}" == "1" ]; then
+ echo Unsupported kernel builds at the moment
+ fi
+
+ if [ "${AARCH64}" == "1" ]; then
+ EXTRA_OPTS="CROSS=aarch64-linux-gnu-"
+
+ # need to turn off these extras
+ set_conf build CONFIG_RTE_PORT_PCAP n
+ set_conf build CONFIG_RTE_LIBRTE_PMD_ZLIB n
+
+ # convert the CC/CXX variables
+ export CC=aarch64-linux-gnu-${CC}
+ export CXX=aarch64-linux-gnu-${CXX}
+ export AR=aarch64-linux-gnu-ar
+ export STRIP=aarch64-linux-gnu-strip
+ fi
+
+ make all ${EXTRA_OPTS}
+fi
diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh
new file mode 100755
index 000000000..8dfd5aa49
--- /dev/null
+++ b/.ci/linux-setup.sh
@@ -0,0 +1,31 @@
+#!/bin/bash
+
+python3.5 -m pip install --upgrade meson --user
+
+echo "AARCH64 is [ ${AARCH64} ]"
+
+if [ "${AARCH64}" == "1" ]; then
+ # need to build & install libnuma
+ # This will only be minimal support for now.
+ AARCH64_TOOL_URL='https://releases.linaro.org/components/toolchain/binaries/latest-7/aarch64-linux-gnu/gcc-linaro-7.4.1-2019.02-x86_64_aarch64-linux-gnu.tar.xz'
+ AARCH64_TOOL="linaro-arm-tool"
+ NUMA_GIT_URL="https://github.com/numactl/numactl.git"
+
+ wget -O "${AARCH64_TOOL}.tar.xz" "${AARCH64_TOOL_URL}"
+ tar -xf "${AARCH64_TOOL}.tar.xz"
+ mv gcc-linaro* "${AARCH64_TOOL}"
+ export PATH=$PATH:$(pwd)/${AARCH64_TOOL}/bin
+ git clone "${NUMA_GIT_URL}"
+ cd numactl
+ git checkout v2.0.11
+ ./autogen.sh
+ autoconf -i
+ mkdir numa_bin
+ ./configure --host=aarch64-linux-gnu CC=aarch64-linux-gnu-gcc \
+ --prefix=$(pwd)/numa_bin
+ make install # install numa
+ cd ..
+ cp numactl/numa_bin/include/numa*.h "${AARCH64_TOOL}/aarch64-linux-gnu/libc/usr/include/"
+ cp numactl/numa_bin/lib/libnuma.* "${AARCH64_TOOL}/aarch64-linux-gnu/lib64/"
+ cp numactl/numa_bin/lib/libnuma.* "${AARCH64_TOOL}/lib/"
+fi
diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 000000000..0faa35770
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,159 @@
+language: c
+compiler:
+ - gcc
+ - clang
+
+os:
+ - linux
+
+addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+
+before_install: ./.ci/${TRAVIS_OS_NAME}-setup.sh
+
+sudo: false
+
+env:
+ - SHARED=1
+ - DISABLE_KERNEL_MODULES=1
+ - SHARED=1 DISABLE_KERNEL_MODULES=1
+ - NINJABUILD=1
+ - NINJABUILD=1 SHARED=1
+ - NINJABUILD=1 DISABLE_KERNEL_MODULES=1
+ - NINJABUILD=1 SHARED=1 DISABLE_KERNEL_MODULES=1
+
+matrix:
+ include:
+ - env: SHARED=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: DISABLE_KERNEL_MODULES=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: SHARED=1 DISABLE_KERNEL_MODULES=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: SHARED=1
+ compiler: clang
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: DISABLE_KERNEL_MODULES=1
+ compiler: clang
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: SHARED=1 DISABLE_KERNEL_MODULES=1
+ compiler: clang
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: AARCH64=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), libtool, python3.5, python3-pip]
+ - env: AARCH64=1 NINJABUILD=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [linux-headers-$(uname -r), libtool, python3.5, python3-pip, ninja-build]
+ - env: NINJABUILD=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: NINJABUILD=1 SHARED=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: NINJABUILD=1 DISABLE_KERNEL_MODULES=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+ - env: NINJABUILD=1 SHARED=1 DISABLE_KERNEL_MODULES=1
+ compiler: gcc
+ addons:
+ apt:
+ sources:
+ - deadsnakes #Repo for python 3.5
+ - sourceline: 'ppa:mstipicevic/ninja-build-1-7-2'
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3.5, python3-pip, ninja-build]
+
+
+script: ./.ci/${TRAVIS_OS_NAME}-build.sh
+
+notifications:
+ email:
+ recipients:
+ - test-report@dpdk.org
diff --git a/MAINTAINERS b/MAINTAINERS
index 835d8a201..3f9de1151 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -119,6 +119,12 @@ F: config/rte_config.h
F: buildtools/gen-pmdinfo-cfile.sh
F: buildtools/symlink-drivers-solibs.sh
+Public CI
+M: Aaron Conole <aconole@redhat.com>
+M: Michael Santana <msantana@redhat.com>
+F: .travis.yml
+F: .ci/
+
ABI versioning
M: Neil Horman <nhorman@tuxdriver.com>
F: lib/librte_compat/
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index a64bb0368..49e930cbb 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -32,6 +32,10 @@ The mailing list for DPDK development is `dev@dpdk.org <http://mails.dpdk.org/ar
Contributors will need to `register for the mailing list <http://mails.dpdk.org/listinfo/dev>`_ in order to submit patches.
It is also worth registering for the DPDK `Patchwork <http://patches.dpdk.org/project/dpdk/list/>`_
+If you are using the GitHub service, you can link your repository to
+the ``travis-ci.org`` build service. When you push patches to your GitHub
+repository, the travis service will automatically build your changes.
+
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.20.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] service: fix parameter type
@ 2019-02-08 15:01 0% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-02-08 15:01 UTC (permalink / raw)
To: Van Haaren, Harry, Rao, Nikhil; +Cc: dev
On 1/21/2019 11:43 AM, Van Haaren, Harry wrote:
>> -----Original Message-----
>> From: Rao, Nikhil
>> Sent: Saturday, January 19, 2019 2:01 PM
>> To: Van Haaren, Harry <harry.van.haaren@intel.com>
>> Cc: dev@dpdk.org; Rao, Nikhil <nikhil.rao@intel.com>
>> Subject: [PATCH] service: fix parameter type
>>
>> The type of value parameter to rte_service_attr_get
>> should be uint64_t *, since the attributes
>> are of type uint64_t.
>>
>> Fixes: 4d55194d76a4 ("service: add attribute get function")
>>
>> Reviewed-by: Gage Eads <gage.eads@intel.com>
>> Signed-off-by: Nikhil Rao <nikhil.rao@intel.com>
>
> Acked-by: Harry van Haaren <harry.van.haaren@intel.com>
>
>> ---
>> lib/librte_eal/common/include/rte_service.h | 2 +-
>> lib/librte_eal/common/rte_service.c | 2 +-
>> test/test/test_service_cores.c | 2 +-
>> 3 files changed, 3 insertions(+), 3 deletions(-)
>>
>> For 19.02, I assume this will require the ABI change announcement. I will
>> post it once this patch is acked.
>
> Correct - this breaks API and ABI, so certainly will need an announce.
Hi Nikhil P,
Can you please send a new version of this patch, that includes removing the
deprecation notice too? (Keeping the ack)
Thanks,
ferruh
>
> Thanks for the fixup, -Harry
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC 00/14] prefix network structures
@ 2019-02-13 11:48 0% ` Yigit, Ferruh
2019-02-18 12:37 0% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Yigit, Ferruh @ 2019-02-13 11:48 UTC (permalink / raw)
To: Olivier Matz, Ferruh Yigit
Cc: Wiles, Keith, Stephen Hemminger, dpdk-dev, Richardson, Bruce
On 12/27/2018 9:35 AM, Olivier Matz wrote:
> Hi,
>
> On Fri, Dec 21, 2018 at 03:14:29PM +0000, Ferruh Yigit wrote:
>> On 12/21/2018 2:38 PM, Wiles, Keith wrote:
>>>
>>>
>>>> On Dec 20, 2018, at 5:48 PM, Stephen Hemminger <stephen@networkplumber.org> wrote:
>>>>
>>>> On Thu, 20 Dec 2018 21:59:37 +0000
>>>> Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>>>>
>>>>> On 10/24/2018 9:18 AM, olivier.matz at 6wind.com (Olivier Matz) wrote:
>>>>>> This RFC targets 19.02.
>>>>>>
>>>>>> The rte_net headers conflict with the libc headers, because
>>>>>> some definitions are duplicated, sometimes with few differences.
>>>>>> This was discussed in [1], and more recently at the techboard.
>>>>>>
>>>>>> Before sending the deprecation notice (target for this is 18.11),
>>>>>> here is a draft that can be discussed.
>>>>>>
>>>>>> This RFC adds the rte_ (or RTE_) prefix to all structures, functions
>>>>>> and defines in rte_net library. This is a big changeset, that will
>>>>>> break the API of many functions, but not the ABI.
>>>>>>
>>>>>> One question I'm asking is how can we manage the transition.
>>>>>> Initially, I hoped it was possible to have a compat layer during
>>>>>> one release (supporting both prefixed and unprefixed names), but
>>>>>> now that the patch is done, it seems the impact is too big, and
>>>>>> impacts too many libraries.
>>>>>>
>>>>>> Few examples:
>>>>>> - rte_eth_macaddr_get/add/remove() use a (struct rte_ether_addr *)
>>>>>> - many rte_flow structures use the rte_ prefixed net structures
>>>>>> - the mac field of virtio_net structure is rte_ether_addr
>>>>>> - the first arg of rte_thash_load_v6_addrs is (struct rte_ipv6_hdr *)
>>>>>> ...
>>>>>>
>>>>>> Therefore, it is clear that doing this would break the compilation
>>>>>> of many external applications.
>>>>>>
>>>>>> Another drawback we need to take in account: it will make the
>>>>>> backport of patches more difficult, although this is something
>>>>>> that could be tempered by a script.
>>>>>>
>>>>>> While it is obviously better to have a good namespace convention,
>>>>>> we need to identify the issues we have today before deciding it's
>>>>>> worth doing the change.
>>>>>>
>>>>>> Comments?
>>>>>
>>>>> Is there an consensus about the patchset? There was a decision on techboard to
>>>>> go with this change (adding rte_ prefix) [1].
>>>>>
>>>>>
>>>>> This is something that will affect DPDK consumers. Since many APIs are changing
>>>>> most probably will break API compatibility for many libraries.
>>>>>
>>>>> Meanwhile the conflict with the libc headers mentioned a few times in the past,
>>>>> this is something we need to fix.
>>>>>
>>>>> There are a few comments reluctant to this big modification, but what I
>>>>> understand from Olivier's response both using BSD defines or having
>>>>> compatibility headers in DPDK won't solve the problem completely.
>>>>>
>>>>> And assuming we will continue with this solution, another question is do we
>>>>> still want to push in 19.02 scope? (And from process point of view I think a
>>>>> deprecation notice is not merged for this change in 18.11 scope.)
>>>>>
>>>>> With the prediction of 19.05 will be big and already break API/ABI for some
>>>>> libraries, can we push this into 19.05 as an early merge into repo?
>>>>>
>>>>> And I think this patch will affect LTS releases and will break auto backporting
>>>>> for many fixes because it touches many places, so pushing this change even to
>>>>> next LTS (19.11) can be an option.
>>>>>
>>>>>
>>>>> Olivier, Thomas,
>>>>>
>>>>> What do you think about postponing this to 19.05 or even 19.11 ?
>>>>>
>>>>>
>>>>>
>>>>> [1]
>>>>> https://mails.dpdk.org/archives/dev/2018-October/116695.html
>>>>>
>>>>>>
>>>>>>
>>>>>> Things that are missing in RFC:
>>>>>> - test with FreeBSD
>>>>>> - manually fix some indentation issues
>>>>>>
>>>>>>
>>>>>> Olivier Matz (14):
>>>>>> net: add rte prefix to arp structures
>>>>>> net: add rte prefix to arp defines
>>>>>> net: add rte prefix to ether structures
>>>>>> net: add rte prefix to ether functions
>>>>>> net: add rte prefix to ether defines
>>>>>> net: add rte prefix to esp structure
>>>>>> net: add rte prefix to gre structure
>>>>>> net: add rte prefix to icmp structure
>>>>>> net: add rte prefix to icmp defines
>>>>>> net: add rte prefix to ip structure
>>>>>> net: add rte prefix to ip defines
>>>>>> net: add rte prefix to sctp structure
>>>>>> net: add rte prefix to tcp structure
>>>>>> net: add rte prefix to udp structure
>>>>>
>>>>>
>>>>
>>>> Sigh. Another case where DPDK has to reinvent something because
>>>> we can't figure out how to do dependent libraries correctly.
>>>> I would have rather just using the existing Linux, BSD definitions
>>>> and fixing the DPDK code.
>
>
> It is not that simple. As I said in [1], there are still some
> differences between gnu libc and freebsd libc. Unfortunatly, the struct
> ether_addr is one of the most important in dpdk, because it is widely
> used in APIs (drivers).
>
> We can find others differences, for instance in constant definitions in
> if_arp.h. I also see that some structures are packed in freebsd but not
> in glibc (ex: icmp6), this could have performance impact.
>
> Many protocols that are currently defined in dpdk are missing in glibc:
> esp, sctp, gre, mpls, ... so we will at least need rte_ structures for
> these protocols.
>
> Supporting other OSes or libc in the future could also increase the gaps.
>
> For these reasons think it is reasonable to have a consistent set of
> network structures in dpdk.
>
>
> [1] https://mails.dpdk.org/archives/dev/2018-October/117258.html
>
>
>>>> It is probably the only viable compromise, but it adds to long
>>>> term maintenance, and breaks DPDK applications. Neither of which
>>>> is a good thing.
>>>>
>>>> Should this be done by marking the old structure deprecated
>>>> first? Ideally, spread over three releases: first, tell the users
>>>> in the documentation it is coming; second, mark the old structures
>>>> as deprecated causing compiler warnings; third, remove the old
>>>> definitions. Doing at once is introducing user pain for no gain.
>>>
>>> +1
>
> Annoucing the change before doing it is obvious. Marking the old
> structures as deprecated before removing them is maybe doable (to be
> checked that it does not cause conflicts with new structures), but it
> means the conflict with libc headers that we are trying to solve will
> remain for one more version, for a limited gain.
>
>> With the current timeline, readiness of the patch and comments, at least it
>> won't able to make this release, I will update the patchset status as 'Deferred'
>>
>> Should we discuss this again in techboard?
>
> We should surely weigh the pros and cons. Especially the additional
> backport troubles it can bring.
>
> Are many people bothered by the current conflict with the libc headers?
This is still open.
If we will get these patchset, I suggest it getting early in the 19.05, patch is
mechanical but it is huge and will affect almost all other patches under
development. So I am not really for pushing this close to RC.
Is there any way to decide on this week, at worst next week?
Thanks,
ferruh
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v2] service: fix parameter type
@ 2019-02-14 9:56 4% ` Nikhil Rao
2019-02-15 10:29 4% ` [dpdk-dev] [PATCH v3] " Nikhil Rao
2019-03-28 6:29 4% ` [dpdk-dev] [PATCH v4] " Nikhil Rao
3 siblings, 0 replies; 200+ results
From: Nikhil Rao @ 2019-02-14 9:56 UTC (permalink / raw)
To: harry.van.haaren; +Cc: ferruh.yigit, dev, Nikhil Rao
The type of value parameter to rte_service_attr_get
should be uint64_t *, since the attributes
are of type uint64_t.
Fixes: 4d55194d76a4 ("service: add attribute get function")
Reviewed-by: Gage Eads <gage.eads@intel.com>
Signed-off-by: Nikhil Rao <nikhil.rao@intel.com>
Acked-by: Harry van Haaren <harry.van.haaren@intel.com>
---
lib/librte_eal/common/include/rte_service.h | 2 +-
lib/librte_eal/common/rte_service.c | 2 +-
test/test/test_service_cores.c | 2 +-
doc/guides/rel_notes/release_19_05.rst | 5 ++++-
lib/librte_eal/bsdapp/eal/Makefile | 2 +-
lib/librte_eal/linuxapp/eal/Makefile | 2 +-
lib/librte_eal/meson.build | 2 +-
7 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/lib/librte_eal/common/include/rte_service.h b/lib/librte_eal/common/include/rte_service.h
index 34b41af..670c89a 100644
--- a/lib/librte_eal/common/include/rte_service.h
+++ b/lib/librte_eal/common/include/rte_service.h
@@ -372,7 +372,7 @@ int32_t rte_service_run_iter_on_app_lcore(uint32_t id,
* -EINVAL Invalid id, attr_id or attr_value was NULL.
*/
int32_t rte_service_attr_get(uint32_t id, uint32_t attr_id,
- uint32_t *attr_value);
+ uint64_t *attr_value);
/**
* Reset all attribute values of a service.
diff --git a/lib/librte_eal/common/rte_service.c b/lib/librte_eal/common/rte_service.c
index 03fde97..5f75e5a 100644
--- a/lib/librte_eal/common/rte_service.c
+++ b/lib/librte_eal/common/rte_service.c
@@ -734,7 +734,7 @@ int32_t rte_service_run_iter_on_app_lcore(uint32_t id,
}
int32_t
-rte_service_attr_get(uint32_t id, uint32_t attr_id, uint32_t *attr_value)
+rte_service_attr_get(uint32_t id, uint32_t attr_id, uint64_t *attr_value)
{
struct rte_service_spec_impl *s;
SERVICE_VALID_GET_OR_ERR_RET(id, s, -EINVAL);
diff --git a/test/test/test_service_cores.c b/test/test/test_service_cores.c
index ec31882..82bb2ce 100644
--- a/test/test/test_service_cores.c
+++ b/test/test/test_service_cores.c
@@ -259,7 +259,7 @@ static int32_t dummy_mt_safe_cb(void *args)
rte_service_set_stats_enable(id, 1);
uint32_t attr_id = UINT32_MAX;
- uint32_t attr_value = 0xdead;
+ uint64_t attr_value = 0xdead;
/* check error return values */
TEST_ASSERT_EQUAL(-EINVAL, rte_service_attr_get(id, attr_id,
&attr_value),
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 2b0f60d..b8ed3d3 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -94,6 +94,9 @@ API Changes
Also, make sure to start the actual text at the margin.
=========================================================
+eal: as shown in the 19.02 deprecation notice, the type of the ``attr_value``
+ parameter of the function ``rte_service_attr_get()`` has been changed
+ from ``uint32_t *`` to ``uint64_t *``.
ABI Changes
-----------
@@ -143,7 +146,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_compressdev.so.1
librte_cryptodev.so.6
librte_distributor.so.1
- librte_eal.so.9
+ +librte_eal.so.10
librte_efd.so.1
librte_ethdev.so.11
librte_eventdev.so.6
diff --git a/lib/librte_eal/bsdapp/eal/Makefile b/lib/librte_eal/bsdapp/eal/Makefile
index bfeddaa..4bc8555 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -22,7 +22,7 @@ LDLIBS += -lrte_kvargs
EXPORT_MAP := ../../rte_eal_version.map
-LIBABIVER := 9
+LIBABIVER := 10
# specific to bsdapp exec-env
SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) := eal.c
diff --git a/lib/librte_eal/linuxapp/eal/Makefile b/lib/librte_eal/linuxapp/eal/Makefile
index 51deb57..db6aca3 100644
--- a/lib/librte_eal/linuxapp/eal/Makefile
+++ b/lib/librte_eal/linuxapp/eal/Makefile
@@ -10,7 +10,7 @@ ARCH_DIR ?= $(RTE_ARCH)
EXPORT_MAP := ../../rte_eal_version.map
VPATH += $(RTE_SDK)/lib/librte_eal/common/arch/$(ARCH_DIR)
-LIBABIVER := 9
+LIBABIVER := 10
VPATH += $(RTE_SDK)/lib/librte_eal/common
diff --git a/lib/librte_eal/meson.build b/lib/librte_eal/meson.build
index a18f3a8..030171e 100644
--- a/lib/librte_eal/meson.build
+++ b/lib/librte_eal/meson.build
@@ -21,7 +21,7 @@ else
error('unsupported system type "@0@"'.format(host_machine.system()))
endif
-version = 9 # the version of the EAL API
+version = 10 # the version of the EAL API
allow_experimental_apis = true
deps += 'compat'
deps += 'kvargs'
--
1.8.3.1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 3/5] app/testpmd: add missing transmit errors stats
@ 2019-02-15 9:33 3% ` David Marchand
2019-02-15 14:05 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2019-02-15 9:33 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev, Bruce Richardson, Wenzhuo Lu, Jingjing Wu,
bernard.iremonger, Maxime Coquelin, Yigit, Ferruh,
Andrew Rybchenko
On Fri, Feb 15, 2019 at 9:58 AM Thomas Monjalon <thomas@monjalon.net> wrote:
> 14/02/2019 19:51, David Marchand:
> > What is the purpose of oerrors ?
> >
> > Since the drivers (via rte_eth_tx_burst return value) report the numbers
> of
> > packets successfully transmitted, the application can try to retransmit
> the
> > packets that did not make it and counts this.
> > If the driver counts such "missed" packets, then it does the job the
> > application will do anyway (wasting some cycles).
> > But what is more a problem is that the application does not know if the
> > packets in oerrors are its own retries or problems that the driver can
> not
> > detect (hw problems) but the hw can.
> >
> > So the best option is that oerrors does not report the packets the driver
> > refuses (and I can see some drivers that do not comply to this) but only
> > "external" errors from the driver pov.
>
> I can see the benefit of having driver errors in the stats,
> so it is generically stored for later analysis or print.
> It could be managed at ethdev level instead of the application
> doing the computation.
>
> What about splitting the Tx errors in 2 fields? oerrors / ofull ?
> Who said it's awful? sorry Bruce for anticipating ;)
>
Summary, correct me if we are not aligned :-)
- ofull (maybe ofifoerrors?) is actually a count of SW failed transmits
- it would be handled in rte_eth_tx_burst() itself in a generic way
- the drivers do not need to track such SW failed transmits
- oerrors only counts packets HW failed transmits, dropped out of the
driver tx_pkt_burst() knowledge
- the application does not have to track SW failed transmits since the
stats is in ethdev
It sounds good to me, this means an ethdev abi breakage.
I will drop my current patch anyway.
Touching oerrors would be a separate effort.
--
David Marchand
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v3] service: fix parameter type
2019-02-14 9:56 4% ` [dpdk-dev] [PATCH v2] " Nikhil Rao
@ 2019-02-15 10:29 4% ` Nikhil Rao
2019-02-18 20:27 0% ` Rami Rosen
2019-03-28 6:29 4% ` [dpdk-dev] [PATCH v4] " Nikhil Rao
3 siblings, 1 reply; 200+ results
From: Nikhil Rao @ 2019-02-15 10:29 UTC (permalink / raw)
To: harry.van.haaren; +Cc: ferruh.yigit, dev, Nikhil Rao
The type of value parameter to rte_service_attr_get
should be uint64_t *, since the attributes
are of type uint64_t.
Fixes: 4d55194d76a4 ("service: add attribute get function")
Reviewed-by: Gage Eads <gage.eads@intel.com>
Signed-off-by: Nikhil Rao <nikhil.rao@intel.com>
Acked-by: Harry van Haaren <harry.van.haaren@intel.com>
---
lib/librte_eal/common/include/rte_service.h | 2 +-
lib/librte_eal/common/rte_service.c | 2 +-
test/test/test_service_cores.c | 2 +-
doc/guides/rel_notes/deprecation.rst | 4 ----
doc/guides/rel_notes/release_19_05.rst | 5 ++++-
lib/librte_eal/bsdapp/eal/Makefile | 2 +-
lib/librte_eal/linuxapp/eal/Makefile | 2 +-
lib/librte_eal/meson.build | 2 +-
8 files changed, 10 insertions(+), 11 deletions(-)
v2:
* Update release notes.
* Update library version in makefiles.
v3:
* Remove deprecation notice.
diff --git a/lib/librte_eal/common/include/rte_service.h b/lib/librte_eal/common/include/rte_service.h
index 34b41af..670c89a 100644
--- a/lib/librte_eal/common/include/rte_service.h
+++ b/lib/librte_eal/common/include/rte_service.h
@@ -372,7 +372,7 @@ int32_t rte_service_run_iter_on_app_lcore(uint32_t id,
* -EINVAL Invalid id, attr_id or attr_value was NULL.
*/
int32_t rte_service_attr_get(uint32_t id, uint32_t attr_id,
- uint32_t *attr_value);
+ uint64_t *attr_value);
/**
* Reset all attribute values of a service.
diff --git a/lib/librte_eal/common/rte_service.c b/lib/librte_eal/common/rte_service.c
index 03fde97..5f75e5a 100644
--- a/lib/librte_eal/common/rte_service.c
+++ b/lib/librte_eal/common/rte_service.c
@@ -734,7 +734,7 @@ int32_t rte_service_run_iter_on_app_lcore(uint32_t id,
}
int32_t
-rte_service_attr_get(uint32_t id, uint32_t attr_id, uint32_t *attr_value)
+rte_service_attr_get(uint32_t id, uint32_t attr_id, uint64_t *attr_value)
{
struct rte_service_spec_impl *s;
SERVICE_VALID_GET_OR_ERR_RET(id, s, -EINVAL);
diff --git a/test/test/test_service_cores.c b/test/test/test_service_cores.c
index ec31882..82bb2ce 100644
--- a/test/test/test_service_cores.c
+++ b/test/test/test_service_cores.c
@@ -259,7 +259,7 @@ static int32_t dummy_mt_safe_cb(void *args)
rte_service_set_stats_enable(id, 1);
uint32_t attr_id = UINT32_MAX;
- uint32_t attr_value = 0xdead;
+ uint64_t attr_value = 0xdead;
/* check error return values */
TEST_ASSERT_EQUAL(-EINVAL, rte_service_attr_get(id, attr_id,
&attr_value),
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 1b4fcb7..93ed31f 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -20,10 +20,6 @@ Deprecation Notices
* kvargs: The function ``rte_kvargs_process`` will get a new parameter
for returning key match count. It will ease handling of no-match case.
-* eal: The ``attr_value`` parameter of ``rte_service_attr_get()``
- will be changed from ``uint32_t *`` to ``uint64_t *``
- as the attributes are of type ``uint64_t``.
-
* eal: both declaring and identifying devices will be streamlined in v18.11.
New functions will appear to query a specific port from buses, classes of
device and device drivers. Device declaration will be made coherent with the
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 2b0f60d..b8ed3d3 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -94,6 +94,9 @@ API Changes
Also, make sure to start the actual text at the margin.
=========================================================
+eal: as shown in the 19.02 deprecation notice, the type of the ``attr_value``
+ parameter of the function ``rte_service_attr_get()`` has been changed
+ from ``uint32_t *`` to ``uint64_t *``.
ABI Changes
-----------
@@ -143,7 +146,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_compressdev.so.1
librte_cryptodev.so.6
librte_distributor.so.1
- librte_eal.so.9
+ +librte_eal.so.10
librte_efd.so.1
librte_ethdev.so.11
librte_eventdev.so.6
diff --git a/lib/librte_eal/bsdapp/eal/Makefile b/lib/librte_eal/bsdapp/eal/Makefile
index bfeddaa..4bc8555 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -22,7 +22,7 @@ LDLIBS += -lrte_kvargs
EXPORT_MAP := ../../rte_eal_version.map
-LIBABIVER := 9
+LIBABIVER := 10
# specific to bsdapp exec-env
SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) := eal.c
diff --git a/lib/librte_eal/linuxapp/eal/Makefile b/lib/librte_eal/linuxapp/eal/Makefile
index 51deb57..db6aca3 100644
--- a/lib/librte_eal/linuxapp/eal/Makefile
+++ b/lib/librte_eal/linuxapp/eal/Makefile
@@ -10,7 +10,7 @@ ARCH_DIR ?= $(RTE_ARCH)
EXPORT_MAP := ../../rte_eal_version.map
VPATH += $(RTE_SDK)/lib/librte_eal/common/arch/$(ARCH_DIR)
-LIBABIVER := 9
+LIBABIVER := 10
VPATH += $(RTE_SDK)/lib/librte_eal/common
diff --git a/lib/librte_eal/meson.build b/lib/librte_eal/meson.build
index a18f3a8..030171e 100644
--- a/lib/librte_eal/meson.build
+++ b/lib/librte_eal/meson.build
@@ -21,7 +21,7 @@ else
error('unsupported system type "@0@"'.format(host_machine.system()))
endif
-version = 9 # the version of the EAL API
+version = 10 # the version of the EAL API
allow_experimental_apis = true
deps += 'compat'
deps += 'kvargs'
--
1.8.3.1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 3/5] app/testpmd: add missing transmit errors stats
2019-02-15 9:33 3% ` David Marchand
@ 2019-02-15 14:05 0% ` Bruce Richardson
2019-02-15 14:13 0% ` Wiles, Keith
2019-02-15 15:04 0% ` David Marchand
0 siblings, 2 replies; 200+ results
From: Bruce Richardson @ 2019-02-15 14:05 UTC (permalink / raw)
To: David Marchand
Cc: Thomas Monjalon, dev, Wenzhuo Lu, Jingjing Wu, bernard.iremonger,
Maxime Coquelin, Yigit, Ferruh, Andrew Rybchenko
On Fri, Feb 15, 2019 at 10:33:47AM +0100, David Marchand wrote:
> On Fri, Feb 15, 2019 at 9:58 AM Thomas Monjalon
> <[1]thomas@monjalon.net> wrote:
>
> 14/02/2019 19:51, David Marchand:
> > What is the purpose of oerrors ?
> >
> > Since the drivers (via rte_eth_tx_burst return value) report the
> numbers of
> > packets successfully transmitted, the application can try to
> retransmit the
> > packets that did not make it and counts this.
> > If the driver counts such "missed" packets, then it does the job
> the
> > application will do anyway (wasting some cycles).
> > But what is more a problem is that the application does not know
> if the
> > packets in oerrors are its own retries or problems that the driver
> can not
> > detect (hw problems) but the hw can.
> >
> > So the best option is that oerrors does not report the packets the
> driver
> > refuses (and I can see some drivers that do not comply to this)
> but only
> > "external" errors from the driver pov.
> I can see the benefit of having driver errors in the stats,
> so it is generically stored for later analysis or print.
> It could be managed at ethdev level instead of the application
> doing the computation.
> What about splitting the Tx errors in 2 fields? oerrors / ofull ?
> Who said it's awful? sorry Bruce for anticipating ;)
>
> Summary, correct me if we are not aligned :-)
> - ofull (maybe ofifoerrors?) is actually a count of SW failed transmits
> - it would be handled in rte_eth_tx_burst() itself in a generic way
> - the drivers do not need to track such SW failed transmits
> - oerrors only counts packets HW failed transmits, dropped out of the
> driver tx_pkt_burst() knowledge
> - the application does not have to track SW failed transmits since the
> stats is in ethdev
> It sounds good to me, this means an ethdev abi breakage.
Hang on, why do we need ethdev to track this at all, given that it's
trivial for apps to track this themselves. Would we not be better just to
add this tracking into testpmd and leave ethdev and drivers alone? Perhaps
I'm missing something?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 3/5] app/testpmd: add missing transmit errors stats
2019-02-15 14:05 0% ` Bruce Richardson
@ 2019-02-15 14:13 0% ` Wiles, Keith
2019-02-15 15:04 0% ` David Marchand
1 sibling, 0 replies; 200+ results
From: Wiles, Keith @ 2019-02-15 14:13 UTC (permalink / raw)
To: Richardson, Bruce
Cc: David Marchand, Thomas Monjalon, dpdk-dev, Lu, Wenzhuo, Wu,
Jingjing, Iremonger, Bernard, Maxime Coquelin, Yigit, Ferruh,
Andrew Rybchenko
> On Feb 15, 2019, at 8:05 AM, Bruce Richardson <bruce.richardson@intel.com> wrote:
>
> On Fri, Feb 15, 2019 at 10:33:47AM +0100, David Marchand wrote:
>> On Fri, Feb 15, 2019 at 9:58 AM Thomas Monjalon
>> <[1]thomas@monjalon.net> wrote:
>>
>> 14/02/2019 19:51, David Marchand:
>>> What is the purpose of oerrors ?
>>>
>>> Since the drivers (via rte_eth_tx_burst return value) report the
>> numbers of
>>> packets successfully transmitted, the application can try to
>> retransmit the
>>> packets that did not make it and counts this.
>>> If the driver counts such "missed" packets, then it does the job
>> the
>>> application will do anyway (wasting some cycles).
>>> But what is more a problem is that the application does not know
>> if the
>>> packets in oerrors are its own retries or problems that the driver
>> can not
>>> detect (hw problems) but the hw can.
>>>
>>> So the best option is that oerrors does not report the packets the
>> driver
>>> refuses (and I can see some drivers that do not comply to this)
>> but only
>>> "external" errors from the driver pov.
>> I can see the benefit of having driver errors in the stats,
>> so it is generically stored for later analysis or print.
>> It could be managed at ethdev level instead of the application
>> doing the computation.
>> What about splitting the Tx errors in 2 fields? oerrors / ofull ?
>> Who said it's awful? sorry Bruce for anticipating ;)
>>
>> Summary, correct me if we are not aligned :-)
>> - ofull (maybe ofifoerrors?) is actually a count of SW failed transmits
>> - it would be handled in rte_eth_tx_burst() itself in a generic way
>> - the drivers do not need to track such SW failed transmits
>> - oerrors only counts packets HW failed transmits, dropped out of the
>> driver tx_pkt_burst() knowledge
>> - the application does not have to track SW failed transmits since the
>> stats is in ethdev
>> It sounds good to me, this means an ethdev abi breakage.
>
> Hang on, why do we need ethdev to track this at all, given that it's
> trivial for apps to track this themselves. Would we not be better just to
> add this tracking into testpmd and leave ethdev and drivers alone? Perhaps
> I'm missing something?
Adding the counters to ethdev stats is a good idea to me, the number of tx full failures is a great counter as it can tell you a lot about performance of the application. if the ofull counter is high then we have a lot of re-xmit attempts which can point to the problem quicker IMO. Adding it to the PMDs is the right place for this type of information as it is a very common needed counter.
>
Regards,
Keith
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 3/5] app/testpmd: add missing transmit errors stats
2019-02-15 14:05 0% ` Bruce Richardson
2019-02-15 14:13 0% ` Wiles, Keith
@ 2019-02-15 15:04 0% ` David Marchand
2019-02-15 16:19 4% ` Thomas Monjalon
1 sibling, 1 reply; 200+ results
From: David Marchand @ 2019-02-15 15:04 UTC (permalink / raw)
To: Bruce Richardson
Cc: Thomas Monjalon, dev, Wenzhuo Lu, Jingjing Wu, bernard.iremonger,
Maxime Coquelin, Yigit, Ferruh, Andrew Rybchenko
On Fri, Feb 15, 2019 at 3:05 PM Bruce Richardson <bruce.richardson@intel.com>
wrote:
> On Fri, Feb 15, 2019 at 10:33:47AM +0100, David Marchand wrote:
> > On Fri, Feb 15, 2019 at 9:58 AM Thomas Monjalon
> > <[1]thomas@monjalon.net> wrote:
> >
> > 14/02/2019 19:51, David Marchand:
> > > What is the purpose of oerrors ?
> > >
> > > Since the drivers (via rte_eth_tx_burst return value) report the
> > numbers of
> > > packets successfully transmitted, the application can try to
> > retransmit the
> > > packets that did not make it and counts this.
> > > If the driver counts such "missed" packets, then it does the job
> > the
> > > application will do anyway (wasting some cycles).
> > > But what is more a problem is that the application does not know
> > if the
> > > packets in oerrors are its own retries or problems that the driver
> > can not
> > > detect (hw problems) but the hw can.
> > >
> > > So the best option is that oerrors does not report the packets the
> > driver
> > > refuses (and I can see some drivers that do not comply to this)
> > but only
> > > "external" errors from the driver pov.
> > I can see the benefit of having driver errors in the stats,
> > so it is generically stored for later analysis or print.
> > It could be managed at ethdev level instead of the application
> > doing the computation.
> > What about splitting the Tx errors in 2 fields? oerrors / ofull ?
> > Who said it's awful? sorry Bruce for anticipating ;)
> >
> > Summary, correct me if we are not aligned :-)
> > - ofull (maybe ofifoerrors?) is actually a count of SW failed
> transmits
> > - it would be handled in rte_eth_tx_burst() itself in a generic way
> > - the drivers do not need to track such SW failed transmits
> > - oerrors only counts packets HW failed transmits, dropped out of the
> > driver tx_pkt_burst() knowledge
> > - the application does not have to track SW failed transmits since the
> > stats is in ethdev
> > It sounds good to me, this means an ethdev abi breakage.
>
> Hang on, why do we need ethdev to track this at all, given that it's
> trivial for apps to track this themselves. Would we not be better just to
> add this tracking into testpmd and leave ethdev and drivers alone? Perhaps
> I'm missing something?
>
This was my first intention but Thomas hopped in ;-)
testpmd does it already via the fs->fwd_dropped stats and ovs has its
tx_dropped stat.
The problem is that all drivers have different approach about this.
Some drivers only count real hw errors in oerrors.
But others count the packets it can't send in oerrors (+ there are some
cases that seem buggy to me where the driver will always refuse the mbufs
for reason X and the application can retry indefinitely to send...).
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 3/5] app/testpmd: add missing transmit errors stats
2019-02-15 15:04 0% ` David Marchand
@ 2019-02-15 16:19 4% ` Thomas Monjalon
2019-02-15 17:32 0% ` David Marchand
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-02-15 16:19 UTC (permalink / raw)
To: David Marchand
Cc: Bruce Richardson, dev, Wenzhuo Lu, Jingjing Wu,
bernard.iremonger, Maxime Coquelin, Yigit, Ferruh,
Andrew Rybchenko, keith.wiles
15/02/2019 16:04, David Marchand:
> On Fri, Feb 15, 2019 at 3:05 PM Bruce Richardson <bruce.richardson@intel.com>
> wrote:
>
> > On Fri, Feb 15, 2019 at 10:33:47AM +0100, David Marchand wrote:
> > > On Fri, Feb 15, 2019 at 9:58 AM Thomas Monjalon
> > > <[1]thomas@monjalon.net> wrote:
> > >
> > > 14/02/2019 19:51, David Marchand:
> > > > What is the purpose of oerrors ?
> > > >
> > > > Since the drivers (via rte_eth_tx_burst return value) report the
> > > numbers of
> > > > packets successfully transmitted, the application can try to
> > > retransmit the
> > > > packets that did not make it and counts this.
> > > > If the driver counts such "missed" packets, then it does the job
> > > the
> > > > application will do anyway (wasting some cycles).
> > > > But what is more a problem is that the application does not know
> > > if the
> > > > packets in oerrors are its own retries or problems that the driver
> > > can not
> > > > detect (hw problems) but the hw can.
> > > >
> > > > So the best option is that oerrors does not report the packets the
> > > driver
> > > > refuses (and I can see some drivers that do not comply to this)
> > > but only
> > > > "external" errors from the driver pov.
> > > I can see the benefit of having driver errors in the stats,
> > > so it is generically stored for later analysis or print.
> > > It could be managed at ethdev level instead of the application
> > > doing the computation.
> > > What about splitting the Tx errors in 2 fields? oerrors / ofull ?
> > > Who said it's awful? sorry Bruce for anticipating ;)
> > >
> > > Summary, correct me if we are not aligned :-)
> > > - ofull (maybe ofifoerrors?) is actually a count of SW failed
> > transmits
> > > - it would be handled in rte_eth_tx_burst() itself in a generic way
> > > - the drivers do not need to track such SW failed transmits
> > > - oerrors only counts packets HW failed transmits, dropped out of the
> > > driver tx_pkt_burst() knowledge
> > > - the application does not have to track SW failed transmits since the
> > > stats is in ethdev
> > > It sounds good to me, this means an ethdev abi breakage.
> >
> > Hang on, why do we need ethdev to track this at all, given that it's
> > trivial for apps to track this themselves. Would we not be better just to
> > add this tracking into testpmd and leave ethdev and drivers alone? Perhaps
> > I'm missing something?
> >
>
> This was my first intention but Thomas hopped in ;-)
I was just opening the discussion :)
> testpmd does it already via the fs->fwd_dropped stats and ovs has its
> tx_dropped stat.
>
> The problem is that all drivers have different approach about this.
> Some drivers only count real hw errors in oerrors.
> But others count the packets it can't send in oerrors (+ there are some
> cases that seem buggy to me where the driver will always refuse the mbufs
> for reason X and the application can retry indefinitely to send...).
We have 3 options:
1/ status quo = oerrors is inconsistent across drivers
2/ API break = oerrors stop being incremented for temporary
unavailability (i.e. queue full, kind of ERETRY),
report only packets which will be never sent,
may be a small performance gain for some drivers
3/ API + ABI break = same as 2/ +
report ERETRY errors in ofull (same as tx_burst() delta)
Note that the option 2 is a light API break which does not require
any deprecation notice because the original definition of oerrors
is really vague: "failed transmitted packets"
By changing the definition of errors to "packets lost", we can count
HW errors + packets not matching requirements.
As David suggests, the packets not matching requirements can be freed
as it is done for packets successfully transmitted to the HW.
We need also to update the definition of the return value of
rte_eth_tx_burst(): "packets actually stored in transmit descriptors".
We should also count the bad packets rejected by the driver.
Then the number of bad packets would be the difference between
the return value of rte_eth_tx_burst() and opackets counter.
This solution is fixing some bugs and enforce a consistent behaviour.
The option 3 is breaking the ABI and may degrade the performances.
The only benefit is convenience or semantic: ofull would be the
equivalent of imissed.
The application can count the same by making the difference between
the burst size and the return of rte_eth_tx_burst.
My vote is for the option 2.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 3/5] app/testpmd: add missing transmit errors stats
2019-02-15 16:19 4% ` Thomas Monjalon
@ 2019-02-15 17:32 0% ` David Marchand
2019-02-15 18:15 0% ` Ananyev, Konstantin
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2019-02-15 17:32 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Bruce Richardson, dev, Wenzhuo Lu, Jingjing Wu,
bernard.iremonger, Maxime Coquelin, Yigit, Ferruh,
Andrew Rybchenko, keith.wiles
On Fri, Feb 15, 2019 at 5:19 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> 15/02/2019 16:04, David Marchand:
> > On Fri, Feb 15, 2019 at 3:05 PM Bruce Richardson <
> bruce.richardson@intel.com>
> > wrote:
> >
> > > On Fri, Feb 15, 2019 at 10:33:47AM +0100, David Marchand wrote:
> > > > On Fri, Feb 15, 2019 at 9:58 AM Thomas Monjalon
> > > > <[1]thomas@monjalon.net> wrote:
> > > >
> > > > 14/02/2019 19:51, David Marchand:
> > > > > What is the purpose of oerrors ?
> > > > >
> > > > > Since the drivers (via rte_eth_tx_burst return value) report
> the
> > > > numbers of
> > > > > packets successfully transmitted, the application can try to
> > > > retransmit the
> > > > > packets that did not make it and counts this.
> > > > > If the driver counts such "missed" packets, then it does the
> job
> > > > the
> > > > > application will do anyway (wasting some cycles).
> > > > > But what is more a problem is that the application does not
> know
> > > > if the
> > > > > packets in oerrors are its own retries or problems that the
> driver
> > > > can not
> > > > > detect (hw problems) but the hw can.
> > > > >
> > > > > So the best option is that oerrors does not report the
> packets the
> > > > driver
> > > > > refuses (and I can see some drivers that do not comply to
> this)
> > > > but only
> > > > > "external" errors from the driver pov.
> > > > I can see the benefit of having driver errors in the stats,
> > > > so it is generically stored for later analysis or print.
> > > > It could be managed at ethdev level instead of the application
> > > > doing the computation.
> > > > What about splitting the Tx errors in 2 fields? oerrors / ofull
> ?
> > > > Who said it's awful? sorry Bruce for anticipating ;)
> > > >
> > > > Summary, correct me if we are not aligned :-)
> > > > - ofull (maybe ofifoerrors?) is actually a count of SW failed
> > > transmits
> > > > - it would be handled in rte_eth_tx_burst() itself in a generic
> way
> > > > - the drivers do not need to track such SW failed transmits
> > > > - oerrors only counts packets HW failed transmits, dropped out of
> the
> > > > driver tx_pkt_burst() knowledge
> > > > - the application does not have to track SW failed transmits
> since the
> > > > stats is in ethdev
> > > > It sounds good to me, this means an ethdev abi breakage.
> > >
> > > Hang on, why do we need ethdev to track this at all, given that it's
> > > trivial for apps to track this themselves. Would we not be better just
> to
> > > add this tracking into testpmd and leave ethdev and drivers alone?
> Perhaps
> > > I'm missing something?
> > >
> >
> > This was my first intention but Thomas hopped in ;-)
>
> I was just opening the discussion :)
>
> > testpmd does it already via the fs->fwd_dropped stats and ovs has its
> > tx_dropped stat.
> >
> > The problem is that all drivers have different approach about this.
> > Some drivers only count real hw errors in oerrors.
> > But others count the packets it can't send in oerrors (+ there are some
> > cases that seem buggy to me where the driver will always refuse the mbufs
> > for reason X and the application can retry indefinitely to send...).
>
> We have 3 options:
> 1/ status quo = oerrors is inconsistent across drivers
> 2/ API break = oerrors stop being incremented for temporary
> unavailability (i.e. queue full, kind of ERETRY),
> report only packets which will be never sent,
> may be a small performance gain for some drivers
> 3/ API + ABI break = same as 2/ +
> report ERETRY errors in ofull (same as tx_burst() delta)
>
> Note that the option 2 is a light API break which does not require
> any deprecation notice because the original definition of oerrors
> is really vague: "failed transmitted packets"
> By changing the definition of errors to "packets lost", we can count
> HW errors + packets not matching requirements.
> As David suggests, the packets not matching requirements can be freed
> as it is done for packets successfully transmitted to the HW.
> We need also to update the definition of the return value of
> rte_eth_tx_burst(): "packets actually stored in transmit descriptors".
> We should also count the bad packets rejected by the driver.
> Then the number of bad packets would be the difference between
> the return value of rte_eth_tx_burst() and opackets counter.
> This solution is fixing some bugs and enforce a consistent behaviour.
>
I am also for option 2 especially because of this.
A driver that refuses a packet for reason X (which is a limitation, or an
incorrect config or whatever that is not a transient condition) but gives
it back to the application is a bad driver.
> The option 3 is breaking the ABI and may degrade the performances.
> The only benefit is convenience or semantic: ofull would be the
> equivalent of imissed.
> The application can count the same by making the difference between
> the burst size and the return of rte_eth_tx_burst.
>
> My vote is for the option 2.
>
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 3/5] app/testpmd: add missing transmit errors stats
2019-02-15 17:32 0% ` David Marchand
@ 2019-02-15 18:15 0% ` Ananyev, Konstantin
0 siblings, 0 replies; 200+ results
From: Ananyev, Konstantin @ 2019-02-15 18:15 UTC (permalink / raw)
To: David Marchand, Thomas Monjalon
Cc: Richardson, Bruce, dev, Lu, Wenzhuo, Wu, Jingjing, Iremonger,
Bernard, Maxime Coquelin, Yigit, Ferruh, Andrew Rybchenko, Wiles,
Keith
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of David Marchand
> Sent: Friday, February 15, 2019 5:32 PM
> To: Thomas Monjalon <thomas@monjalon.net>
> Cc: Richardson, Bruce <bruce.richardson@intel.com>; dev@dpdk.org; Lu, Wenzhuo <wenzhuo.lu@intel.com>; Wu, Jingjing
> <jingjing.wu@intel.com>; Iremonger, Bernard <bernard.iremonger@intel.com>; Maxime Coquelin <mcoqueli@redhat.com>; Yigit, Ferruh
> <ferruh.yigit@intel.com>; Andrew Rybchenko <arybchenko@solarflare.com>; Wiles, Keith <keith.wiles@intel.com>
> Subject: Re: [dpdk-dev] [PATCH 3/5] app/testpmd: add missing transmit errors stats
>
> On Fri, Feb 15, 2019 at 5:19 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> > 15/02/2019 16:04, David Marchand:
> > > On Fri, Feb 15, 2019 at 3:05 PM Bruce Richardson <
> > bruce.richardson@intel.com>
> > > wrote:
> > >
> > > > On Fri, Feb 15, 2019 at 10:33:47AM +0100, David Marchand wrote:
> > > > > On Fri, Feb 15, 2019 at 9:58 AM Thomas Monjalon
> > > > > <[1]thomas@monjalon.net> wrote:
> > > > >
> > > > > 14/02/2019 19:51, David Marchand:
> > > > > > What is the purpose of oerrors ?
> > > > > >
> > > > > > Since the drivers (via rte_eth_tx_burst return value) report
> > the
> > > > > numbers of
> > > > > > packets successfully transmitted, the application can try to
> > > > > retransmit the
> > > > > > packets that did not make it and counts this.
> > > > > > If the driver counts such "missed" packets, then it does the
> > job
> > > > > the
> > > > > > application will do anyway (wasting some cycles).
> > > > > > But what is more a problem is that the application does not
> > know
> > > > > if the
> > > > > > packets in oerrors are its own retries or problems that the
> > driver
> > > > > can not
> > > > > > detect (hw problems) but the hw can.
> > > > > >
> > > > > > So the best option is that oerrors does not report the
> > packets the
> > > > > driver
> > > > > > refuses (and I can see some drivers that do not comply to
> > this)
> > > > > but only
> > > > > > "external" errors from the driver pov.
> > > > > I can see the benefit of having driver errors in the stats,
> > > > > so it is generically stored for later analysis or print.
> > > > > It could be managed at ethdev level instead of the application
> > > > > doing the computation.
> > > > > What about splitting the Tx errors in 2 fields? oerrors / ofull
> > ?
> > > > > Who said it's awful? sorry Bruce for anticipating ;)
> > > > >
> > > > > Summary, correct me if we are not aligned :-)
> > > > > - ofull (maybe ofifoerrors?) is actually a count of SW failed
> > > > transmits
> > > > > - it would be handled in rte_eth_tx_burst() itself in a generic
> > way
> > > > > - the drivers do not need to track such SW failed transmits
> > > > > - oerrors only counts packets HW failed transmits, dropped out of
> > the
> > > > > driver tx_pkt_burst() knowledge
> > > > > - the application does not have to track SW failed transmits
> > since the
> > > > > stats is in ethdev
> > > > > It sounds good to me, this means an ethdev abi breakage.
> > > >
> > > > Hang on, why do we need ethdev to track this at all, given that it's
> > > > trivial for apps to track this themselves. Would we not be better just
> > to
> > > > add this tracking into testpmd and leave ethdev and drivers alone?
> > Perhaps
> > > > I'm missing something?
> > > >
> > >
> > > This was my first intention but Thomas hopped in ;-)
> >
> > I was just opening the discussion :)
> >
> > > testpmd does it already via the fs->fwd_dropped stats and ovs has its
> > > tx_dropped stat.
> > >
> > > The problem is that all drivers have different approach about this.
> > > Some drivers only count real hw errors in oerrors.
> > > But others count the packets it can't send in oerrors (+ there are some
> > > cases that seem buggy to me where the driver will always refuse the mbufs
> > > for reason X and the application can retry indefinitely to send...).
> >
> > We have 3 options:
> > 1/ status quo = oerrors is inconsistent across drivers
> > 2/ API break = oerrors stop being incremented for temporary
> > unavailability (i.e. queue full, kind of ERETRY),
> > report only packets which will be never sent,
> > may be a small performance gain for some drivers
> > 3/ API + ABI break = same as 2/ +
> > report ERETRY errors in ofull (same as tx_burst() delta)
> >
> > Note that the option 2 is a light API break which does not require
> > any deprecation notice because the original definition of oerrors
> > is really vague: "failed transmitted packets"
> > By changing the definition of errors to "packets lost", we can count
> > HW errors + packets not matching requirements.
> > As David suggests, the packets not matching requirements can be freed
> > as it is done for packets successfully transmitted to the HW.
> > We need also to update the definition of the return value of
> > rte_eth_tx_burst(): "packets actually stored in transmit descriptors".
> > We should also count the bad packets rejected by the driver.
> > Then the number of bad packets would be the difference between
> > the return value of rte_eth_tx_burst() and opackets counter.
> > This solution is fixing some bugs and enforce a consistent behaviour.
> >
>
> I am also for option 2 especially because of this.
> A driver that refuses a packet for reason X (which is a limitation, or an
> incorrect config or whatever that is not a transient condition) but gives
> it back to the application is a bad driver.
Why? What.s wrong to leave it to the upper layer to decide what to
do with the packets that can't be sent (by one reason or another)?
>
>
> > The option 3 is breaking the ABI and may degrade the performances.
> > The only benefit is convenience or semantic: ofull would be the
> > equivalent of imissed.
> > The application can count the same by making the difference between
> > the burst size and the return of rte_eth_tx_burst.
> >
> > My vote is for the option 2.
> >
>
>
>
> --
> David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC 00/14] prefix network structures
2019-02-13 11:48 0% ` Yigit, Ferruh
@ 2019-02-18 12:37 0% ` Ferruh Yigit
2019-02-18 16:58 0% ` Olivier Matz
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2019-02-18 12:37 UTC (permalink / raw)
To: Yigit, Ferruh, Olivier Matz
Cc: Wiles, Keith, Stephen Hemminger, dpdk-dev, Richardson, Bruce
On 2/13/2019 11:48 AM, Yigit, Ferruh wrote:
> On 12/27/2018 9:35 AM, Olivier Matz wrote:
>> Hi,
>>
>> On Fri, Dec 21, 2018 at 03:14:29PM +0000, Ferruh Yigit wrote:
>>> On 12/21/2018 2:38 PM, Wiles, Keith wrote:
>>>>
>>>>
>>>>> On Dec 20, 2018, at 5:48 PM, Stephen Hemminger <stephen@networkplumber.org> wrote:
>>>>>
>>>>> On Thu, 20 Dec 2018 21:59:37 +0000
>>>>> Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>>>>>
>>>>>> On 10/24/2018 9:18 AM, olivier.matz at 6wind.com (Olivier Matz) wrote:
>>>>>>> This RFC targets 19.02.
>>>>>>>
>>>>>>> The rte_net headers conflict with the libc headers, because
>>>>>>> some definitions are duplicated, sometimes with few differences.
>>>>>>> This was discussed in [1], and more recently at the techboard.
>>>>>>>
>>>>>>> Before sending the deprecation notice (target for this is 18.11),
>>>>>>> here is a draft that can be discussed.
>>>>>>>
>>>>>>> This RFC adds the rte_ (or RTE_) prefix to all structures, functions
>>>>>>> and defines in rte_net library. This is a big changeset, that will
>>>>>>> break the API of many functions, but not the ABI.
>>>>>>>
>>>>>>> One question I'm asking is how can we manage the transition.
>>>>>>> Initially, I hoped it was possible to have a compat layer during
>>>>>>> one release (supporting both prefixed and unprefixed names), but
>>>>>>> now that the patch is done, it seems the impact is too big, and
>>>>>>> impacts too many libraries.
>>>>>>>
>>>>>>> Few examples:
>>>>>>> - rte_eth_macaddr_get/add/remove() use a (struct rte_ether_addr *)
>>>>>>> - many rte_flow structures use the rte_ prefixed net structures
>>>>>>> - the mac field of virtio_net structure is rte_ether_addr
>>>>>>> - the first arg of rte_thash_load_v6_addrs is (struct rte_ipv6_hdr *)
>>>>>>> ...
>>>>>>>
>>>>>>> Therefore, it is clear that doing this would break the compilation
>>>>>>> of many external applications.
>>>>>>>
>>>>>>> Another drawback we need to take in account: it will make the
>>>>>>> backport of patches more difficult, although this is something
>>>>>>> that could be tempered by a script.
>>>>>>>
>>>>>>> While it is obviously better to have a good namespace convention,
>>>>>>> we need to identify the issues we have today before deciding it's
>>>>>>> worth doing the change.
>>>>>>>
>>>>>>> Comments?
>>>>>>
>>>>>> Is there an consensus about the patchset? There was a decision on techboard to
>>>>>> go with this change (adding rte_ prefix) [1].
>>>>>>
>>>>>>
>>>>>> This is something that will affect DPDK consumers. Since many APIs are changing
>>>>>> most probably will break API compatibility for many libraries.
>>>>>>
>>>>>> Meanwhile the conflict with the libc headers mentioned a few times in the past,
>>>>>> this is something we need to fix.
>>>>>>
>>>>>> There are a few comments reluctant to this big modification, but what I
>>>>>> understand from Olivier's response both using BSD defines or having
>>>>>> compatibility headers in DPDK won't solve the problem completely.
>>>>>>
>>>>>> And assuming we will continue with this solution, another question is do we
>>>>>> still want to push in 19.02 scope? (And from process point of view I think a
>>>>>> deprecation notice is not merged for this change in 18.11 scope.)
>>>>>>
>>>>>> With the prediction of 19.05 will be big and already break API/ABI for some
>>>>>> libraries, can we push this into 19.05 as an early merge into repo?
>>>>>>
>>>>>> And I think this patch will affect LTS releases and will break auto backporting
>>>>>> for many fixes because it touches many places, so pushing this change even to
>>>>>> next LTS (19.11) can be an option.
>>>>>>
>>>>>>
>>>>>> Olivier, Thomas,
>>>>>>
>>>>>> What do you think about postponing this to 19.05 or even 19.11 ?
>>>>>>
>>>>>>
>>>>>>
>>>>>> [1]
>>>>>> https://mails.dpdk.org/archives/dev/2018-October/116695.html
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Things that are missing in RFC:
>>>>>>> - test with FreeBSD
>>>>>>> - manually fix some indentation issues
>>>>>>>
>>>>>>>
>>>>>>> Olivier Matz (14):
>>>>>>> net: add rte prefix to arp structures
>>>>>>> net: add rte prefix to arp defines
>>>>>>> net: add rte prefix to ether structures
>>>>>>> net: add rte prefix to ether functions
>>>>>>> net: add rte prefix to ether defines
>>>>>>> net: add rte prefix to esp structure
>>>>>>> net: add rte prefix to gre structure
>>>>>>> net: add rte prefix to icmp structure
>>>>>>> net: add rte prefix to icmp defines
>>>>>>> net: add rte prefix to ip structure
>>>>>>> net: add rte prefix to ip defines
>>>>>>> net: add rte prefix to sctp structure
>>>>>>> net: add rte prefix to tcp structure
>>>>>>> net: add rte prefix to udp structure
>>>>>>
>>>>>>
>>>>>
>>>>> Sigh. Another case where DPDK has to reinvent something because
>>>>> we can't figure out how to do dependent libraries correctly.
>>>>> I would have rather just using the existing Linux, BSD definitions
>>>>> and fixing the DPDK code.
>>
>>
>> It is not that simple. As I said in [1], there are still some
>> differences between gnu libc and freebsd libc. Unfortunatly, the struct
>> ether_addr is one of the most important in dpdk, because it is widely
>> used in APIs (drivers).
>>
>> We can find others differences, for instance in constant definitions in
>> if_arp.h. I also see that some structures are packed in freebsd but not
>> in glibc (ex: icmp6), this could have performance impact.
>>
>> Many protocols that are currently defined in dpdk are missing in glibc:
>> esp, sctp, gre, mpls, ... so we will at least need rte_ structures for
>> these protocols.
>>
>> Supporting other OSes or libc in the future could also increase the gaps.
>>
>> For these reasons think it is reasonable to have a consistent set of
>> network structures in dpdk.
>>
>>
>> [1] https://mails.dpdk.org/archives/dev/2018-October/117258.html
>>
>>
>>>>> It is probably the only viable compromise, but it adds to long
>>>>> term maintenance, and breaks DPDK applications. Neither of which
>>>>> is a good thing.
>>>>>
>>>>> Should this be done by marking the old structure deprecated
>>>>> first? Ideally, spread over three releases: first, tell the users
>>>>> in the documentation it is coming; second, mark the old structures
>>>>> as deprecated causing compiler warnings; third, remove the old
>>>>> definitions. Doing at once is introducing user pain for no gain.
>>>>
>>>> +1
>>
>> Annoucing the change before doing it is obvious. Marking the old
>> structures as deprecated before removing them is maybe doable (to be
>> checked that it does not cause conflicts with new structures), but it
>> means the conflict with libc headers that we are trying to solve will
>> remain for one more version, for a limited gain.
>>
>>> With the current timeline, readiness of the patch and comments, at least it
>>> won't able to make this release, I will update the patchset status as 'Deferred'
>>>
>>> Should we discuss this again in techboard?
>>
>> We should surely weigh the pros and cons. Especially the additional
>> backport troubles it can bring.
>>
>> Are many people bothered by the current conflict with the libc headers?
>
> This is still open.
>
> If we will get these patchset, I suggest it getting early in the 19.05, patch is
> mechanical but it is huge and will affect almost all other patches under
> development. So I am not really for pushing this close to RC.
>
> Is there any way to decide on this week, at worst next week?
This has been discussed in techboard meeting and decided to go with this patch.
But we are missing the deprecation notice for this.
Olivier,
Can you send a deprecation notice for this in the scope of the 19.05?
And can we target the actual patch for very early days of the 19.08?
Thanks,
ferruh
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC 00/14] prefix network structures
2019-02-18 12:37 0% ` Ferruh Yigit
@ 2019-02-18 16:58 0% ` Olivier Matz
0 siblings, 0 replies; 200+ results
From: Olivier Matz @ 2019-02-18 16:58 UTC (permalink / raw)
To: Ferruh Yigit
Cc: Yigit, Ferruh, Wiles, Keith, Stephen Hemminger, dpdk-dev,
Richardson, Bruce
On Mon, Feb 18, 2019 at 12:37:41PM +0000, Ferruh Yigit wrote:
> On 2/13/2019 11:48 AM, Yigit, Ferruh wrote:
> > On 12/27/2018 9:35 AM, Olivier Matz wrote:
> >> Hi,
> >>
> >> On Fri, Dec 21, 2018 at 03:14:29PM +0000, Ferruh Yigit wrote:
> >>> On 12/21/2018 2:38 PM, Wiles, Keith wrote:
> >>>>
> >>>>
> >>>>> On Dec 20, 2018, at 5:48 PM, Stephen Hemminger <stephen@networkplumber.org> wrote:
> >>>>>
> >>>>> On Thu, 20 Dec 2018 21:59:37 +0000
> >>>>> Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> >>>>>
> >>>>>> On 10/24/2018 9:18 AM, olivier.matz at 6wind.com (Olivier Matz) wrote:
> >>>>>>> This RFC targets 19.02.
> >>>>>>>
> >>>>>>> The rte_net headers conflict with the libc headers, because
> >>>>>>> some definitions are duplicated, sometimes with few differences.
> >>>>>>> This was discussed in [1], and more recently at the techboard.
> >>>>>>>
> >>>>>>> Before sending the deprecation notice (target for this is 18.11),
> >>>>>>> here is a draft that can be discussed.
> >>>>>>>
> >>>>>>> This RFC adds the rte_ (or RTE_) prefix to all structures, functions
> >>>>>>> and defines in rte_net library. This is a big changeset, that will
> >>>>>>> break the API of many functions, but not the ABI.
> >>>>>>>
> >>>>>>> One question I'm asking is how can we manage the transition.
> >>>>>>> Initially, I hoped it was possible to have a compat layer during
> >>>>>>> one release (supporting both prefixed and unprefixed names), but
> >>>>>>> now that the patch is done, it seems the impact is too big, and
> >>>>>>> impacts too many libraries.
> >>>>>>>
> >>>>>>> Few examples:
> >>>>>>> - rte_eth_macaddr_get/add/remove() use a (struct rte_ether_addr *)
> >>>>>>> - many rte_flow structures use the rte_ prefixed net structures
> >>>>>>> - the mac field of virtio_net structure is rte_ether_addr
> >>>>>>> - the first arg of rte_thash_load_v6_addrs is (struct rte_ipv6_hdr *)
> >>>>>>> ...
> >>>>>>>
> >>>>>>> Therefore, it is clear that doing this would break the compilation
> >>>>>>> of many external applications.
> >>>>>>>
> >>>>>>> Another drawback we need to take in account: it will make the
> >>>>>>> backport of patches more difficult, although this is something
> >>>>>>> that could be tempered by a script.
> >>>>>>>
> >>>>>>> While it is obviously better to have a good namespace convention,
> >>>>>>> we need to identify the issues we have today before deciding it's
> >>>>>>> worth doing the change.
> >>>>>>>
> >>>>>>> Comments?
> >>>>>>
> >>>>>> Is there an consensus about the patchset? There was a decision on techboard to
> >>>>>> go with this change (adding rte_ prefix) [1].
> >>>>>>
> >>>>>>
> >>>>>> This is something that will affect DPDK consumers. Since many APIs are changing
> >>>>>> most probably will break API compatibility for many libraries.
> >>>>>>
> >>>>>> Meanwhile the conflict with the libc headers mentioned a few times in the past,
> >>>>>> this is something we need to fix.
> >>>>>>
> >>>>>> There are a few comments reluctant to this big modification, but what I
> >>>>>> understand from Olivier's response both using BSD defines or having
> >>>>>> compatibility headers in DPDK won't solve the problem completely.
> >>>>>>
> >>>>>> And assuming we will continue with this solution, another question is do we
> >>>>>> still want to push in 19.02 scope? (And from process point of view I think a
> >>>>>> deprecation notice is not merged for this change in 18.11 scope.)
> >>>>>>
> >>>>>> With the prediction of 19.05 will be big and already break API/ABI for some
> >>>>>> libraries, can we push this into 19.05 as an early merge into repo?
> >>>>>>
> >>>>>> And I think this patch will affect LTS releases and will break auto backporting
> >>>>>> for many fixes because it touches many places, so pushing this change even to
> >>>>>> next LTS (19.11) can be an option.
> >>>>>>
> >>>>>>
> >>>>>> Olivier, Thomas,
> >>>>>>
> >>>>>> What do you think about postponing this to 19.05 or even 19.11 ?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> [1]
> >>>>>> https://mails.dpdk.org/archives/dev/2018-October/116695.html
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Things that are missing in RFC:
> >>>>>>> - test with FreeBSD
> >>>>>>> - manually fix some indentation issues
> >>>>>>>
> >>>>>>>
> >>>>>>> Olivier Matz (14):
> >>>>>>> net: add rte prefix to arp structures
> >>>>>>> net: add rte prefix to arp defines
> >>>>>>> net: add rte prefix to ether structures
> >>>>>>> net: add rte prefix to ether functions
> >>>>>>> net: add rte prefix to ether defines
> >>>>>>> net: add rte prefix to esp structure
> >>>>>>> net: add rte prefix to gre structure
> >>>>>>> net: add rte prefix to icmp structure
> >>>>>>> net: add rte prefix to icmp defines
> >>>>>>> net: add rte prefix to ip structure
> >>>>>>> net: add rte prefix to ip defines
> >>>>>>> net: add rte prefix to sctp structure
> >>>>>>> net: add rte prefix to tcp structure
> >>>>>>> net: add rte prefix to udp structure
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> Sigh. Another case where DPDK has to reinvent something because
> >>>>> we can't figure out how to do dependent libraries correctly.
> >>>>> I would have rather just using the existing Linux, BSD definitions
> >>>>> and fixing the DPDK code.
> >>
> >>
> >> It is not that simple. As I said in [1], there are still some
> >> differences between gnu libc and freebsd libc. Unfortunatly, the struct
> >> ether_addr is one of the most important in dpdk, because it is widely
> >> used in APIs (drivers).
> >>
> >> We can find others differences, for instance in constant definitions in
> >> if_arp.h. I also see that some structures are packed in freebsd but not
> >> in glibc (ex: icmp6), this could have performance impact.
> >>
> >> Many protocols that are currently defined in dpdk are missing in glibc:
> >> esp, sctp, gre, mpls, ... so we will at least need rte_ structures for
> >> these protocols.
> >>
> >> Supporting other OSes or libc in the future could also increase the gaps.
> >>
> >> For these reasons think it is reasonable to have a consistent set of
> >> network structures in dpdk.
> >>
> >>
> >> [1] https://mails.dpdk.org/archives/dev/2018-October/117258.html
> >>
> >>
> >>>>> It is probably the only viable compromise, but it adds to long
> >>>>> term maintenance, and breaks DPDK applications. Neither of which
> >>>>> is a good thing.
> >>>>>
> >>>>> Should this be done by marking the old structure deprecated
> >>>>> first? Ideally, spread over three releases: first, tell the users
> >>>>> in the documentation it is coming; second, mark the old structures
> >>>>> as deprecated causing compiler warnings; third, remove the old
> >>>>> definitions. Doing at once is introducing user pain for no gain.
> >>>>
> >>>> +1
> >>
> >> Annoucing the change before doing it is obvious. Marking the old
> >> structures as deprecated before removing them is maybe doable (to be
> >> checked that it does not cause conflicts with new structures), but it
> >> means the conflict with libc headers that we are trying to solve will
> >> remain for one more version, for a limited gain.
> >>
> >>> With the current timeline, readiness of the patch and comments, at least it
> >>> won't able to make this release, I will update the patchset status as 'Deferred'
> >>>
> >>> Should we discuss this again in techboard?
> >>
> >> We should surely weigh the pros and cons. Especially the additional
> >> backport troubles it can bring.
> >>
> >> Are many people bothered by the current conflict with the libc headers?
> >
> > This is still open.
> >
> > If we will get these patchset, I suggest it getting early in the 19.05, patch is
> > mechanical but it is huge and will affect almost all other patches under
> > development. So I am not really for pushing this close to RC.
> >
> > Is there any way to decide on this week, at worst next week?
>
> This has been discussed in techboard meeting and decided to go with this patch.
> But we are missing the deprecation notice for this.
>
>
> Olivier,
>
> Can you send a deprecation notice for this in the scope of the 19.05?
> And can we target the actual patch for very early days of the 19.08?
>
Hi Ferruh,
OK, will do. Thank you.
Olivier
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3] service: fix parameter type
2019-02-15 10:29 4% ` [dpdk-dev] [PATCH v3] " Nikhil Rao
@ 2019-02-18 20:27 0% ` Rami Rosen
0 siblings, 0 replies; 200+ results
From: Rami Rosen @ 2019-02-18 20:27 UTC (permalink / raw)
To: Nikhil Rao; +Cc: harry.van.haaren, Ferruh Yigit, dev
Reviewed-by: Rami Rosen <ramirose@gmail.com>
On Fri, Feb 15, 2019 at 12:29 PM Nikhil Rao <nikhil.rao@intel.com> wrote:
> The type of value parameter to rte_service_attr_get
> should be uint64_t *, since the attributes
> are of type uint64_t.
>
> Fixes: 4d55194d76a4 ("service: add attribute get function")
>
> Reviewed-by: Gage Eads <gage.eads@intel.com>
> Signed-off-by: Nikhil Rao <nikhil.rao@intel.com>
> Acked-by: Harry van Haaren <harry.van.haaren@intel.com>
> ---
> lib/librte_eal/common/include/rte_service.h | 2 +-
> lib/librte_eal/common/rte_service.c | 2 +-
> test/test/test_service_cores.c | 2 +-
> doc/guides/rel_notes/deprecation.rst | 4 ----
> doc/guides/rel_notes/release_19_05.rst | 5 ++++-
> lib/librte_eal/bsdapp/eal/Makefile | 2 +-
> lib/librte_eal/linuxapp/eal/Makefile | 2 +-
> lib/librte_eal/meson.build | 2 +-
> 8 files changed, 10 insertions(+), 11 deletions(-)
>
> v2:
> * Update release notes.
> * Update library version in makefiles.
>
> v3:
> * Remove deprecation notice.
>
> diff --git a/lib/librte_eal/common/include/rte_service.h
> b/lib/librte_eal/common/include/rte_service.h
> index 34b41af..670c89a 100644
> --- a/lib/librte_eal/common/include/rte_service.h
> +++ b/lib/librte_eal/common/include/rte_service.h
> @@ -372,7 +372,7 @@ int32_t rte_service_run_iter_on_app_lcore(uint32_t id,
> * -EINVAL Invalid id, attr_id or attr_value was NULL.
> */
> int32_t rte_service_attr_get(uint32_t id, uint32_t attr_id,
> - uint32_t *attr_value);
> + uint64_t *attr_value);
>
> /**
> * Reset all attribute values of a service.
> diff --git a/lib/librte_eal/common/rte_service.c
> b/lib/librte_eal/common/rte_service.c
> index 03fde97..5f75e5a 100644
> --- a/lib/librte_eal/common/rte_service.c
> +++ b/lib/librte_eal/common/rte_service.c
> @@ -734,7 +734,7 @@ int32_t rte_service_run_iter_on_app_lcore(uint32_t id,
> }
>
> int32_t
> -rte_service_attr_get(uint32_t id, uint32_t attr_id, uint32_t *attr_value)
> +rte_service_attr_get(uint32_t id, uint32_t attr_id, uint64_t *attr_value)
> {
> struct rte_service_spec_impl *s;
> SERVICE_VALID_GET_OR_ERR_RET(id, s, -EINVAL);
> diff --git a/test/test/test_service_cores.c
> b/test/test/test_service_cores.c
> index ec31882..82bb2ce 100644
> --- a/test/test/test_service_cores.c
> +++ b/test/test/test_service_cores.c
> @@ -259,7 +259,7 @@ static int32_t dummy_mt_safe_cb(void *args)
> rte_service_set_stats_enable(id, 1);
>
> uint32_t attr_id = UINT32_MAX;
> - uint32_t attr_value = 0xdead;
> + uint64_t attr_value = 0xdead;
> /* check error return values */
> TEST_ASSERT_EQUAL(-EINVAL, rte_service_attr_get(id, attr_id,
> &attr_value),
> diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> index 1b4fcb7..93ed31f 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -20,10 +20,6 @@ Deprecation Notices
> * kvargs: The function ``rte_kvargs_process`` will get a new parameter
> for returning key match count. It will ease handling of no-match case.
>
> -* eal: The ``attr_value`` parameter of ``rte_service_attr_get()``
> - will be changed from ``uint32_t *`` to ``uint64_t *``
> - as the attributes are of type ``uint64_t``.
> -
> * eal: both declaring and identifying devices will be streamlined in
> v18.11.
> New functions will appear to query a specific port from buses, classes
> of
> device and device drivers. Device declaration will be made coherent
> with the
> diff --git a/doc/guides/rel_notes/release_19_05.rst
> b/doc/guides/rel_notes/release_19_05.rst
> index 2b0f60d..b8ed3d3 100644
> --- a/doc/guides/rel_notes/release_19_05.rst
> +++ b/doc/guides/rel_notes/release_19_05.rst
> @@ -94,6 +94,9 @@ API Changes
> Also, make sure to start the actual text at the margin.
> =========================================================
>
> +eal: as shown in the 19.02 deprecation notice, the type of the
> ``attr_value``
> + parameter of the function ``rte_service_attr_get()`` has been changed
> + from ``uint32_t *`` to ``uint64_t *``.
>
> ABI Changes
> -----------
> @@ -143,7 +146,7 @@ The libraries prepended with a plus sign were
> incremented in this version.
> librte_compressdev.so.1
> librte_cryptodev.so.6
> librte_distributor.so.1
> - librte_eal.so.9
> + +librte_eal.so.10
> librte_efd.so.1
> librte_ethdev.so.11
> librte_eventdev.so.6
> diff --git a/lib/librte_eal/bsdapp/eal/Makefile
> b/lib/librte_eal/bsdapp/eal/Makefile
> index bfeddaa..4bc8555 100644
> --- a/lib/librte_eal/bsdapp/eal/Makefile
> +++ b/lib/librte_eal/bsdapp/eal/Makefile
> @@ -22,7 +22,7 @@ LDLIBS += -lrte_kvargs
>
> EXPORT_MAP := ../../rte_eal_version.map
>
> -LIBABIVER := 9
> +LIBABIVER := 10
>
> # specific to bsdapp exec-env
> SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) := eal.c
> diff --git a/lib/librte_eal/linuxapp/eal/Makefile
> b/lib/librte_eal/linuxapp/eal/Makefile
> index 51deb57..db6aca3 100644
> --- a/lib/librte_eal/linuxapp/eal/Makefile
> +++ b/lib/librte_eal/linuxapp/eal/Makefile
> @@ -10,7 +10,7 @@ ARCH_DIR ?= $(RTE_ARCH)
> EXPORT_MAP := ../../rte_eal_version.map
> VPATH += $(RTE_SDK)/lib/librte_eal/common/arch/$(ARCH_DIR)
>
> -LIBABIVER := 9
> +LIBABIVER := 10
>
> VPATH += $(RTE_SDK)/lib/librte_eal/common
>
> diff --git a/lib/librte_eal/meson.build b/lib/librte_eal/meson.build
> index a18f3a8..030171e 100644
> --- a/lib/librte_eal/meson.build
> +++ b/lib/librte_eal/meson.build
> @@ -21,7 +21,7 @@ else
> error('unsupported system type "@0@
> "'.format(host_machine.system()))
> endif
>
> -version = 9 # the version of the EAL API
> +version = 10 # the version of the EAL API
> allow_experimental_apis = true
> deps += 'compat'
> deps += 'kvargs'
> --
> 1.8.3.1
>
>
--
regards,
Rami Rosen
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [RFC 1/6] ethdev: add min/max MTU to device info
@ 2019-02-20 15:57 5% ` Ian Stokes
0 siblings, 0 replies; 200+ results
From: Ian Stokes @ 2019-02-20 15:57 UTC (permalink / raw)
To: dev; +Cc: stephen, Ian Stokes
From: Stephen Hemminger <stephen@networkplumber.org>
This addresses the usability issue raised by OVS at DPDK Userspace
summit. It adds general min/max mtu into device info. For compatiablity,
and to save space, it fits in a hole in existing structure.
The initial version sets max mtu to normal Ethernet, it is up to
PMD to set larger value if it supports Jumbo frames.
Also remove the deprecation notice introduced in 18.11 regarding this
change.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Ian Stokes <ian.stokes@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 12 ------------
lib/librte_ethdev/rte_ethdev.c | 7 +++++++
lib/librte_ethdev/rte_ethdev.h | 2 ++
3 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 1b4fcb7e6..0e85c47f3 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -56,18 +56,6 @@ Deprecation Notices
Target release for removal of the legacy API will be defined once most
PMDs have switched to rte_flow.
-* ethdev: Maximum and minimum MTU values vary between hardware devices. In
- hardware agnostic DPDK applications access to such information would allow
- a more accurate way of validating and setting supported MTU values on a per
- device basis rather than using a defined default for all devices. To
- resolve this, the following members will be added to ``rte_eth_dev_info``.
- Note: these can be added to fit a hole in the existing structure for amd64
- but not for 32-bit, as such ABI change will occur as size of the structure
- will increase.
-
- - Member ``uint16_t min_mtu`` the minimum MTU allowed.
- - Member ``uint16_t max_mtu`` the maximum MTU allowed.
-
* meter: New ``rte_color`` definition will be added in 19.02 and that will
replace ``enum rte_meter_color`` in meter library in 19.05. This will help
to consolidate color definition, which is currently replicated in many places,
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 0d192a24b..f089af94d 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -2527,6 +2527,8 @@ rte_eth_dev_info_get(uint16_t port_id, struct rte_eth_dev_info *dev_info)
dev_info->rx_desc_lim = lim;
dev_info->tx_desc_lim = lim;
dev_info->device = dev->device;
+ dev_info->min_mtu = ETHER_MIN_MTU;
+ dev_info->max_mtu = ETHER_MTU;
RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get);
(*dev->dev_ops->dev_infos_get)(dev, dev_info);
@@ -2590,12 +2592,17 @@ int
rte_eth_dev_set_mtu(uint16_t port_id, uint16_t mtu)
{
int ret;
+ struct rte_eth_dev_info dev_info;
struct rte_eth_dev *dev;
RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
dev = &rte_eth_devices[port_id];
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->mtu_set, -ENOTSUP);
+ rte_eth_dev_info_get(port_id, &dev_info);
+ if (mtu < dev_info.min_mtu || mtu > dev_info.max_mtu)
+ return -EINVAL;
+
ret = (*dev->dev_ops->mtu_set)(dev, mtu);
if (!ret)
dev->data->mtu = mtu;
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index a3c864a13..9fe51b2bd 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1086,6 +1086,8 @@ struct rte_eth_dev_info {
const char *driver_name; /**< Device Driver name. */
unsigned int if_index; /**< Index to bound host interface, or 0 if none.
Use if_indextoname() to translate into an interface name. */
+ uint16_t min_mtu; /**< Minimum MTU allowed */
+ uint16_t max_mtu; /**< Maximum MTU allowed */
const uint32_t *dev_flags; /**< Device flags */
uint32_t min_rx_bufsize; /**< Minimum size of RX buffer. */
uint32_t max_rx_pktlen; /**< Maximum configurable length of RX pkt. */
--
2.13.6
^ permalink raw reply [relevance 5%]
* [dpdk-dev] [PATCH v2 1/6] vfio: allow DMA map of memory for the default vfio fd
@ 2019-02-21 14:50 5% ` Shahaf Shuler
0 siblings, 0 replies; 200+ results
From: Shahaf Shuler @ 2019-02-21 14:50 UTC (permalink / raw)
To: anatoly.burakov, yskoh, thomas, ferruh.yigit, nhorman, gaetan.rivet; +Cc: dev
Enable users the option to call rte_vfio_dma_map with request to map
to the default vfio fd.
Signed-off-by: Shahaf Shuler <shahafs@mellanox.com>
---
doc/guides/rel_notes/release_19_05.rst | 3 +++
lib/librte_eal/common/include/rte_vfio.h | 8 ++++++--
lib/librte_eal/linuxapp/eal/eal_vfio.c | 10 ++++++++--
3 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 2b0f60d3d8..2c682e36cf 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -110,6 +110,9 @@ ABI Changes
Also, make sure to start the actual text at the margin.
=========================================================
+* vfio: Functions ``rte_vfio_container_dma_map`` and
+ ``rte_vfio_container_dma_unmap`` have been extended with an option to
+ request mapping or un-mapping to the default vfio container fd.
Shared Library Versions
-----------------------
diff --git a/lib/librte_eal/common/include/rte_vfio.h b/lib/librte_eal/common/include/rte_vfio.h
index cae96fab90..54a0df5726 100644
--- a/lib/librte_eal/common/include/rte_vfio.h
+++ b/lib/librte_eal/common/include/rte_vfio.h
@@ -73,6 +73,8 @@ struct vfio_info_cap_header {
#define RTE_VFIO_CAP_MSIX_MAPPABLE 3
#endif
+#define RTE_VFIO_DEFAULT_CONTAINER_FD (-1)
+
#else /* not VFIO_PRESENT */
/* we don't need an actual definition, only pointer is used */
@@ -347,7 +349,8 @@ rte_vfio_container_group_unbind(int container_fd, int iommu_group_num);
* Perform DMA mapping for devices in a container.
*
* @param container_fd
- * the specified container fd
+ * the specified container fd. Use RTE_VFIO_DEFAULT_CONTAINER_FD to
+ * use the default container.
*
* @param vaddr
* Starting virtual address of memory to be mapped.
@@ -370,7 +373,8 @@ rte_vfio_container_dma_map(int container_fd, uint64_t vaddr,
* Perform DMA unmapping for devices in a container.
*
* @param container_fd
- * the specified container fd
+ * the specified container fd. Use RTE_VFIO_DEFAULT_CONTAINER_FD to
+ * use the default container.
*
* @param vaddr
* Starting virtual address of memory to be unmapped.
diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.c b/lib/librte_eal/linuxapp/eal/eal_vfio.c
index c821e83826..9adbda8bb7 100644
--- a/lib/librte_eal/linuxapp/eal/eal_vfio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_vfio.c
@@ -1897,7 +1897,10 @@ rte_vfio_container_dma_map(int container_fd, uint64_t vaddr, uint64_t iova,
return -1;
}
- vfio_cfg = get_vfio_cfg_by_container_fd(container_fd);
+ if (container_fd == RTE_VFIO_DEFAULT_CONTAINER_FD)
+ vfio_cfg = default_vfio_cfg;
+ else
+ vfio_cfg = get_vfio_cfg_by_container_fd(container_fd);
if (vfio_cfg == NULL) {
RTE_LOG(ERR, EAL, "Invalid container fd\n");
return -1;
@@ -1917,7 +1920,10 @@ rte_vfio_container_dma_unmap(int container_fd, uint64_t vaddr, uint64_t iova,
return -1;
}
- vfio_cfg = get_vfio_cfg_by_container_fd(container_fd);
+ if (container_fd == RTE_VFIO_DEFAULT_CONTAINER_FD)
+ vfio_cfg = default_vfio_cfg;
+ else
+ vfio_cfg = get_vfio_cfg_by_container_fd(container_fd);
if (vfio_cfg == NULL) {
RTE_LOG(ERR, EAL, "Invalid container fd\n");
return -1;
--
2.12.0
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH] lib/cryptodev: fix driver name comparison
@ 2019-02-21 17:03 3% ` Trahe, Fiona
2019-02-22 4:47 0% ` Anoob Joseph
0 siblings, 1 reply; 200+ results
From: Trahe, Fiona @ 2019-02-21 17:03 UTC (permalink / raw)
To: Anoob Joseph, Akhil Goyal, Doherty, Declan, De Lara Guarch, Pablo
Cc: Jerin Jacob Kollanukkaran, Narayana Prasad Raju Athreya, dev,
Ankur Dwivedi, Trahe, Fiona
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Anoob Joseph
> Sent: Wednesday, February 20, 2019 3:42 PM
> To: Akhil Goyal <akhil.goyal@nxp.com>; Doherty, Declan <declan.doherty@intel.com>; De Lara Guarch,
> Pablo <pablo.de.lara.guarch@intel.com>
> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad Raju Athreya
> <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi <adwivedi@marvell.com>
> Subject: Re: [dpdk-dev] [PATCH] lib/cryptodev: fix driver name comparison
>
> Hi Akhil, Declan, Pablo,
>
> Can you review this patch and share your thoughts?
>
> Thanks,
> Anoob
>
> > -----Original Message-----
> > From: Anoob Joseph
> > Sent: Monday, February 4, 2019 4:56 PM
> > To: Akhil Goyal <akhil.goyal@nxp.com>; Declan Doherty
> > <declan.doherty@intel.com>; Pablo de Lara <pablo.de.lara.guarch@intel.com>
> > Cc: Anoob Joseph <anoobj@marvell.com>; Jerin Jacob Kollanukkaran
> > <jerinj@marvell.com>; Narayana Prasad Raju Athreya
> > <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi
> > <adwivedi@marvell.com>
> > Subject: [PATCH] lib/cryptodev: fix driver name comparison
> >
> > The string compare to the length of driver name might give false positives when
> > there are drivers with similar names (one being the subset of another).
> >
> > Following is such a naming which could result in false positive.
> > 1. crypto_driver
> > 2. crypto_driver1
[Fiona] This patch changes compare for both driver and device names.
Update description to mention device names too.
> > When strncmp with len = strlen("crypto_driver") is done, it could give a false
> > positive when compared against "crypto_driver1".
> >
> > Fixes: d11b0f30df88 ("cryptodev: introduce API and framework for crypto
> > devices")
> >
> > Signed-off-by: Ankur Dwivedi <adwivedi@marvell.com>
> > Signed-off-by: Anoob Joseph <anoobj@marvell.com>
> > ---
> > lib/librte_cryptodev/rte_cryptodev.c | 11 ++++++-----
> > 1 file changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/lib/librte_cryptodev/rte_cryptodev.c
> > b/lib/librte_cryptodev/rte_cryptodev.c
> > index 7009735..b743c60 100644
> > --- a/lib/librte_cryptodev/rte_cryptodev.c
> > +++ b/lib/librte_cryptodev/rte_cryptodev.c
> > @@ -510,7 +510,8 @@ rte_cryptodev_pmd_get_named_dev(const char *name)
> > dev = &cryptodev_globals.devs[i];
> >
> > if ((dev->attached == RTE_CRYPTODEV_ATTACHED) &&
> > - (strcmp(dev->data->name, name) == 0))
> > + (strncmp(dev->data->name, name,
> > + RTE_CRYPTODEV_NAME_MAX_LEN)
> > == 0))
> > return dev;
> > }
> >
> > @@ -542,8 +543,8 @@ rte_cryptodev_get_dev_id(const char *name)
> > return -1;
> >
> > for (i = 0; i < cryptodev_globals.nb_devs; i++)
> > - if ((strcmp(cryptodev_globals.devs[i].data->name, name)
> > - == 0) &&
> > + if ((strncmp(cryptodev_globals.devs[i].data->name, name,
> > + RTE_CRYPTODEV_NAME_MAX_LEN) == 0) &&
[Fiona] Is this safe? The const passed to this may not be the full length of RTE_CRYPTODEV_NAME_MAX_LEN. Does this prototype need to specify that a full length const filled with trailing zeros must be passed in? And if so is this an ABI breakage?
> > (cryptodev_globals.devs[i].attached ==
> > RTE_CRYPTODEV_ATTACHED))
> > return i;
> > @@ -586,7 +587,7 @@ rte_cryptodev_devices_get(const char *driver_name,
> > uint8_t *devices,
> >
> > cmp = strncmp(devs[i].device->driver->name,
> > driver_name,
> > - strlen(driver_name));
> > + RTE_CRYPTODEV_NAME_MAX_LEN);
[Fiona] Is this safe? Same comment as for device name.
Also assumes RTE_CRYPTODEV_NAME_MAX_LEN is same as RTE_DEV_NAME_MAX_LEN. They're both 64 at the moment so not currently an issue.
> >
> > if (cmp == 0)
> > devices[count++] = devs[i].data->dev_id; @@ -
> > 1691,7 +1692,7 @@ rte_cryptodev_driver_id_get(const char *name)
> >
> > TAILQ_FOREACH(driver, &cryptodev_driver_list, next) {
> > driver_name = driver->driver->name;
> > - if (strncmp(driver_name, name, strlen(driver_name)) == 0)
> > + if (strncmp(driver_name, name,
> > RTE_CRYPTODEV_NAME_MAX_LEN) == 0)
> > return driver->id;
> > }
> > return -1;
> > --
> > 2.7.4
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] lib/cryptodev: fix driver name comparison
2019-02-21 17:03 3% ` Trahe, Fiona
@ 2019-02-22 4:47 0% ` Anoob Joseph
2019-02-22 15:39 0% ` Trahe, Fiona
0 siblings, 1 reply; 200+ results
From: Anoob Joseph @ 2019-02-22 4:47 UTC (permalink / raw)
To: Trahe, Fiona, Akhil Goyal, Doherty, Declan, De Lara Guarch, Pablo
Cc: Jerin Jacob Kollanukkaran, Narayana Prasad Raju Athreya, dev,
Ankur Dwivedi
Hi Fiona,
Please see inline.
Thanks,
Anoob
> -----Original Message-----
> From: Trahe, Fiona <fiona.trahe@intel.com>
> Sent: Thursday, February 21, 2019 10:33 PM
> To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal
> <akhil.goyal@nxp.com>; Doherty, Declan <declan.doherty@intel.com>; De
> Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad Raju
> Athreya <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi
> <adwivedi@marvell.com>; Trahe, Fiona <fiona.trahe@intel.com>
> Subject: RE: [PATCH] lib/cryptodev: fix driver name comparison
>
>
>
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Anoob Joseph
> > Sent: Wednesday, February 20, 2019 3:42 PM
> > To: Akhil Goyal <akhil.goyal@nxp.com>; Doherty, Declan
> > <declan.doherty@intel.com>; De Lara Guarch, Pablo
> > <pablo.de.lara.guarch@intel.com>
> > Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad
> > Raju Athreya <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi
> > <adwivedi@marvell.com>
> > Subject: Re: [dpdk-dev] [PATCH] lib/cryptodev: fix driver name
> > comparison
> >
> > Hi Akhil, Declan, Pablo,
> >
> > Can you review this patch and share your thoughts?
> >
> > Thanks,
> > Anoob
> >
> > > -----Original Message-----
> > > From: Anoob Joseph
> > > Sent: Monday, February 4, 2019 4:56 PM
> > > To: Akhil Goyal <akhil.goyal@nxp.com>; Declan Doherty
> > > <declan.doherty@intel.com>; Pablo de Lara
> > > <pablo.de.lara.guarch@intel.com>
> > > Cc: Anoob Joseph <anoobj@marvell.com>; Jerin Jacob Kollanukkaran
> > > <jerinj@marvell.com>; Narayana Prasad Raju Athreya
> > > <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi
> > > <adwivedi@marvell.com>
> > > Subject: [PATCH] lib/cryptodev: fix driver name comparison
> > >
> > > The string compare to the length of driver name might give false
> > > positives when there are drivers with similar names (one being the
> subset of another).
> > >
> > > Following is such a naming which could result in false positive.
> > > 1. crypto_driver
> > > 2. crypto_driver1
> [Fiona] This patch changes compare for both driver and device names.
> Update description to mention device names too.
[Anoob] Will update that.
>
> > > When strncmp with len = strlen("crypto_driver") is done, it could
> > > give a false positive when compared against "crypto_driver1".
> > >
> > > Fixes: d11b0f30df88 ("cryptodev: introduce API and framework for
> > > crypto
> > > devices")
> > >
> > > Signed-off-by: Ankur Dwivedi <adwivedi@marvell.com>
> > > Signed-off-by: Anoob Joseph <anoobj@marvell.com>
> > > ---
> > > lib/librte_cryptodev/rte_cryptodev.c | 11 ++++++-----
> > > 1 file changed, 6 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/lib/librte_cryptodev/rte_cryptodev.c
> > > b/lib/librte_cryptodev/rte_cryptodev.c
> > > index 7009735..b743c60 100644
> > > --- a/lib/librte_cryptodev/rte_cryptodev.c
> > > +++ b/lib/librte_cryptodev/rte_cryptodev.c
> > > @@ -510,7 +510,8 @@ rte_cryptodev_pmd_get_named_dev(const char
> *name)
> > > dev = &cryptodev_globals.devs[i];
> > >
> > > if ((dev->attached == RTE_CRYPTODEV_ATTACHED) &&
> > > - (strcmp(dev->data->name, name) == 0))
> > > + (strncmp(dev->data->name, name,
> > > + RTE_CRYPTODEV_NAME_MAX_LEN)
> > > == 0))
> > > return dev;
> > > }
> > >
> > > @@ -542,8 +543,8 @@ rte_cryptodev_get_dev_id(const char *name)
> > > return -1;
> > >
> > > for (i = 0; i < cryptodev_globals.nb_devs; i++)
> > > - if ((strcmp(cryptodev_globals.devs[i].data->name, name)
> > > - == 0) &&
> > > + if ((strncmp(cryptodev_globals.devs[i].data->name, name,
> > > + RTE_CRYPTODEV_NAME_MAX_LEN) == 0)
> &&
> [Fiona] Is this safe? The const passed to this may not be the full length of
> RTE_CRYPTODEV_NAME_MAX_LEN. Does this prototype need to specify
> that a full length const filled with trailing zeros must be passed in? And if so is
> this an ABI breakage?
>
[Anoob] strcmp itself is not safe when we have buffers which are not NULL terminated. Strncmp will make sure the check won't exceed RTE_CRYPTODEV_NAME_MAX_LEN.
>From man page, "The strncmp() function is similar, except it only compares the first (at most) n bytes of s1 and s2."
The main issue here is the usage of strncmp with strlen(driver_name), as in the below cases. Strlen will return string length, which doesn't include \0. strcmp is good enough to fix the issue. But usage of strcmp would assume that the const is filled with trailing zero. IMO, none of these options are really safe. So please advise on what would be the best solution here. I'll revise the patch accordingly.
>
> > > (cryptodev_globals.devs[i].attached ==
> > >
> RTE_CRYPTODEV_ATTACHED))
> > > return i;
> > > @@ -586,7 +587,7 @@ rte_cryptodev_devices_get(const char
> > > *driver_name, uint8_t *devices,
> > >
> > > cmp = strncmp(devs[i].device->driver->name,
> > > driver_name,
> > > - strlen(driver_name));
> > > + RTE_CRYPTODEV_NAME_MAX_LEN);
> [Fiona] Is this safe? Same comment as for device name.
> Also assumes RTE_CRYPTODEV_NAME_MAX_LEN is same as
> RTE_DEV_NAME_MAX_LEN. They're both 64 at the moment so not currently
> an issue.
>
[Anoob] Will fix this with v2.
> > >
> > > if (cmp == 0)
> > > devices[count++] = devs[i].data->dev_id;
> @@ -
> > > 1691,7 +1692,7 @@ rte_cryptodev_driver_id_get(const char *name)
> > >
> > > TAILQ_FOREACH(driver, &cryptodev_driver_list, next) {
> > > driver_name = driver->driver->name;
> > > - if (strncmp(driver_name, name, strlen(driver_name)) == 0)
> > > + if (strncmp(driver_name, name,
> > > RTE_CRYPTODEV_NAME_MAX_LEN) == 0)
> > > return driver->id;
> > > }
> > > return -1;
> > > --
> > > 2.7.4
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] lib/cryptodev: fix driver name comparison
2019-02-22 4:47 0% ` Anoob Joseph
@ 2019-02-22 15:39 0% ` Trahe, Fiona
2019-02-23 6:11 3% ` Anoob Joseph
0 siblings, 1 reply; 200+ results
From: Trahe, Fiona @ 2019-02-22 15:39 UTC (permalink / raw)
To: Anoob Joseph, Akhil Goyal, Doherty, Declan, De Lara Guarch, Pablo
Cc: Jerin Jacob Kollanukkaran, Narayana Prasad Raju Athreya, dev,
Ankur Dwivedi, Trahe, Fiona
Hi Anoob,
> > > > @@ -542,8 +543,8 @@ rte_cryptodev_get_dev_id(const char *name)
> > > > return -1;
> > > >
> > > > for (i = 0; i < cryptodev_globals.nb_devs; i++)
> > > > - if ((strcmp(cryptodev_globals.devs[i].data->name, name)
> > > > - == 0) &&
> > > > + if ((strncmp(cryptodev_globals.devs[i].data->name, name,
> > > > + RTE_CRYPTODEV_NAME_MAX_LEN) == 0)
> > &&
> > [Fiona] Is this safe? The const passed to this may not be the full length of
> > RTE_CRYPTODEV_NAME_MAX_LEN. Does this prototype need to specify
> > that a full length const filled with trailing zeros must be passed in? And if so is
> > this an ABI breakage?
> >
>
> [Anoob] strcmp itself is not safe when we have buffers which are not NULL terminated. Strncmp will make
> sure the check won't exceed RTE_CRYPTODEV_NAME_MAX_LEN.
>
> From man page, "The strncmp() function is similar, except it only compares the first (at most) n bytes of
> s1 and s2."
>
> The main issue here is the usage of strncmp with strlen(driver_name), as in the below cases. Strlen will
> return string length, which doesn't include \0. strcmp is good enough to fix the issue. But usage of strcmp
> would assume that the const is filled with trailing zero. IMO, none of these options are really safe. So
> please advise on what would be the best solution here. I'll revise the patch accordingly.
[Fiona] I agree and think it is safest as you've coded it. However I'd suggest adding a comment on the relevant APIs saying that the string must be passed in in a buffer of size <use relevant #define> with trailing zeros.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] lib/cryptodev: fix driver name comparison
2019-02-22 15:39 0% ` Trahe, Fiona
@ 2019-02-23 6:11 3% ` Anoob Joseph
2019-02-25 11:52 3% ` Trahe, Fiona
0 siblings, 1 reply; 200+ results
From: Anoob Joseph @ 2019-02-23 6:11 UTC (permalink / raw)
To: Trahe, Fiona, Akhil Goyal, Doherty, Declan, De Lara Guarch,
Pablo, Yigit, Ferruh, Thomas Monjalon
Cc: Jerin Jacob Kollanukkaran, Narayana Prasad Raju Athreya, dev,
Ankur Dwivedi
Hi Fiona,
> -----Original Message-----
> From: Trahe, Fiona <fiona.trahe@intel.com>
> Sent: Friday, February 22, 2019 9:09 PM
> To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal <akhil.goyal@nxp.com>;
> Doherty, Declan <declan.doherty@intel.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>
> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad Raju
> Athreya <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi
> <adwivedi@marvell.com>; Trahe, Fiona <fiona.trahe@intel.com>
> Subject: RE: [PATCH] lib/cryptodev: fix driver name comparison
>
> Hi Anoob,
>
> > > > > @@ -542,8 +543,8 @@ rte_cryptodev_get_dev_id(const char *name)
> > > > > return -1;
> > > > >
> > > > > for (i = 0; i < cryptodev_globals.nb_devs; i++)
> > > > > - if ((strcmp(cryptodev_globals.devs[i].data->name, name)
> > > > > - == 0) &&
> > > > > + if ((strncmp(cryptodev_globals.devs[i].data->name,
> name,
> > > > > + RTE_CRYPTODEV_NAME_MAX_LEN)
> == 0)
> > > &&
> > > [Fiona] Is this safe? The const passed to this may not be the full
> > > length of RTE_CRYPTODEV_NAME_MAX_LEN. Does this prototype need to
> > > specify that a full length const filled with trailing zeros must be
> > > passed in? And if so is this an ABI breakage?
> > >
> >
> > [Anoob] strcmp itself is not safe when we have buffers which are not
> > NULL terminated. Strncmp will make sure the check won't exceed
> RTE_CRYPTODEV_NAME_MAX_LEN.
> >
> > From man page, "The strncmp() function is similar, except it only
> > compares the first (at most) n bytes of
> > s1 and s2."
> >
> > The main issue here is the usage of strncmp with strlen(driver_name),
> > as in the below cases. Strlen will return string length, which doesn't
> > include \0. strcmp is good enough to fix the issue. But usage of
> > strcmp would assume that the const is filled with trailing zero. IMO, none of
> these options are really safe. So please advise on what would be the best
> solution here. I'll revise the patch accordingly.
> [Fiona] I agree and think it is safest as you've coded it. However I'd suggest
> adding a comment on the relevant APIs saying that the string must be passed in
> in a buffer of size <use relevant #define> with trailing zeros.
[Anoob] Do you want this patch to address that? And wouldn't specifying something like that explicitly, be an ABI breakage?
Also, I think the same is applicable for other similar functions (rte_eth_dev_get_port_by_name() etc), wherever we expect a string. Please do share your thoughts on what all I should include in this patch.
Thanks,
Anoob
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] lib/cryptodev: fix driver name comparison
2019-02-23 6:11 3% ` Anoob Joseph
@ 2019-02-25 11:52 3% ` Trahe, Fiona
2019-02-28 6:48 0% ` Anoob Joseph
0 siblings, 1 reply; 200+ results
From: Trahe, Fiona @ 2019-02-25 11:52 UTC (permalink / raw)
To: Anoob Joseph, Akhil Goyal, Doherty, Declan, De Lara Guarch,
Pablo, Yigit, Ferruh, Thomas Monjalon
Cc: Jerin Jacob Kollanukkaran, Narayana Prasad Raju Athreya, dev,
Ankur Dwivedi
Hi Anoob
> -----Original Message-----
> From: Anoob Joseph [mailto:anoobj@marvell.com]
> Sent: Saturday, February 23, 2019 6:12 AM
> To: Trahe, Fiona <fiona.trahe@intel.com>; Akhil Goyal <akhil.goyal@nxp.com>; Doherty, Declan
> <declan.doherty@intel.com>; De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Yigit, Ferruh
> <ferruh.yigit@intel.com>; Thomas Monjalon <thomas@monjalon.net>
> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad Raju Athreya
> <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi <adwivedi@marvell.com>
> Subject: RE: [PATCH] lib/cryptodev: fix driver name comparison
>
> Hi Fiona,
>
> > -----Original Message-----
> > From: Trahe, Fiona <fiona.trahe@intel.com>
> > Sent: Friday, February 22, 2019 9:09 PM
> > To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal <akhil.goyal@nxp.com>;
> > Doherty, Declan <declan.doherty@intel.com>; De Lara Guarch, Pablo
> > <pablo.de.lara.guarch@intel.com>
> > Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad Raju
> > Athreya <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi
> > <adwivedi@marvell.com>; Trahe, Fiona <fiona.trahe@intel.com>
> > Subject: RE: [PATCH] lib/cryptodev: fix driver name comparison
> >
> > Hi Anoob,
> >
> > > > > > @@ -542,8 +543,8 @@ rte_cryptodev_get_dev_id(const char *name)
> > > > > > return -1;
> > > > > >
> > > > > > for (i = 0; i < cryptodev_globals.nb_devs; i++)
> > > > > > - if ((strcmp(cryptodev_globals.devs[i].data->name, name)
> > > > > > - == 0) &&
> > > > > > + if ((strncmp(cryptodev_globals.devs[i].data->name,
> > name,
> > > > > > + RTE_CRYPTODEV_NAME_MAX_LEN)
> > == 0)
> > > > &&
> > > > [Fiona] Is this safe? The const passed to this may not be the full
> > > > length of RTE_CRYPTODEV_NAME_MAX_LEN. Does this prototype need to
> > > > specify that a full length const filled with trailing zeros must be
> > > > passed in? And if so is this an ABI breakage?
> > > >
> > >
> > > [Anoob] strcmp itself is not safe when we have buffers which are not
> > > NULL terminated. Strncmp will make sure the check won't exceed
> > RTE_CRYPTODEV_NAME_MAX_LEN.
> > >
> > > From man page, "The strncmp() function is similar, except it only
> > > compares the first (at most) n bytes of
> > > s1 and s2."
> > >
> > > The main issue here is the usage of strncmp with strlen(driver_name),
> > > as in the below cases. Strlen will return string length, which doesn't
> > > include \0. strcmp is good enough to fix the issue. But usage of
> > > strcmp would assume that the const is filled with trailing zero. IMO, none of
> > these options are really safe. So please advise on what would be the best
> > solution here. I'll revise the patch accordingly.
> > [Fiona] I agree and think it is safest as you've coded it. However I'd suggest
> > adding a comment on the relevant APIs saying that the string must be passed in
> > in a buffer of size <use relevant #define> with trailing zeros.
>
> [Anoob] Do you want this patch to address that? And wouldn't specifying something like that explicitly, be
> an ABI breakage?
[Fiona] Yes, I think it should be in this patch as this patch is causing it.
But it's up to the maintainers what's acceptable - it seems to me that it's an ABI breakage, avoiding
saying it explicitly doesn't make it less so.
>
> Also, I think the same is applicable for other similar functions (rte_eth_dev_get_port_by_name() etc),
> wherever we expect a string. Please do share your thoughts on what all I should include in this patch.
>
> Thanks,
> Anoob
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] vhost: add virtio configuration space access socket messages
[not found] ` <CGME20190225135328eucas1p1560252488ef0f0db87f0509d2bb7813c@eucas1p1.samsung.com>
@ 2019-02-25 13:53 3% ` Ilya Maximets
2019-02-26 7:02 0% ` Liu, Changpeng
0 siblings, 1 reply; 200+ results
From: Ilya Maximets @ 2019-02-25 13:53 UTC (permalink / raw)
To: Changpeng Liu, dev
Cc: dariusz.stojaczyk, maxime.coquelin, tiwei.bie, zhihong.wang, Jason Wang
On 25.02.2019 10:51, Changpeng Liu wrote:
> This patch adds new vhost user messages GET_CONFIG and SET_CONFIG
> used to get/set virtio device's PCI configuration space.
>
> Signed-off-by: Changpeng Liu <changpeng.liu@intel.com>
> Reviewed-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com>
> ---
> lib/librte_vhost/rte_vhost.h | 8 ++++++++
> lib/librte_vhost/vhost_user.c | 44 +++++++++++++++++++++++++++++++++++++++++++
> lib/librte_vhost/vhost_user.h | 16 ++++++++++++++++
> 3 files changed, 68 insertions(+)
>
> diff --git a/lib/librte_vhost/rte_vhost.h b/lib/librte_vhost/rte_vhost.h
> index 2753670..ab710ce 100644
> --- a/lib/librte_vhost/rte_vhost.h
> +++ b/lib/librte_vhost/rte_vhost.h
> @@ -63,6 +63,10 @@
> #define VHOST_USER_PROTOCOL_F_PAGEFAULT 8
> #endif
>
> +#ifndef VHOST_USER_PROTOCOL_F_CONFIG
> +#define VHOST_USER_PROTOCOL_F_CONFIG 9
> +#endif
> +
> #ifndef VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD
> #define VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD 10
> #endif
> @@ -173,6 +177,10 @@ struct vhost_device_ops {
>
> int (*vring_state_changed)(int vid, uint16_t queue_id, int enable); /**< triggered when a vring is enabled or disabled */
>
> + int (*get_config)(int vid, uint8_t *config, uint32_t config_len);
> + int (*set_config)(int vid, uint8_t *config, uint32_t offset,
> + uint32_t len, uint32_t flags);
'struct vhost_device_ops' is user visible. This changes API and ABI.
You need to update docs/rel_notes and bump the library version accordingly.
Best regards, Ilya Maximets.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] vhost: add virtio configuration space access socket messages
2019-02-25 13:53 3% ` [dpdk-dev] " Ilya Maximets
@ 2019-02-26 7:02 0% ` Liu, Changpeng
0 siblings, 0 replies; 200+ results
From: Liu, Changpeng @ 2019-02-26 7:02 UTC (permalink / raw)
To: Ilya Maximets, dev
Cc: Stojaczyk, Dariusz, maxime.coquelin, Bie, Tiwei, Wang, Zhihong,
Jason Wang
> -----Original Message-----
> From: Ilya Maximets [mailto:i.maximets@samsung.com]
> Sent: Monday, February 25, 2019 9:53 PM
> To: Liu, Changpeng <changpeng.liu@intel.com>; dev@dpdk.org
> Cc: Stojaczyk, Dariusz <dariusz.stojaczyk@intel.com>;
> maxime.coquelin@redhat.com; Bie, Tiwei <tiwei.bie@intel.com>; Wang,
> Zhihong <zhihong.wang@intel.com>; Jason Wang <jasowang@redhat.com>
> Subject: Re: vhost: add virtio configuration space access socket messages
>
> On 25.02.2019 10:51, Changpeng Liu wrote:
> > This patch adds new vhost user messages GET_CONFIG and SET_CONFIG
> > used to get/set virtio device's PCI configuration space.
> >
> > Signed-off-by: Changpeng Liu <changpeng.liu@intel.com>
> > Reviewed-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com>
> > ---
> > lib/librte_vhost/rte_vhost.h | 8 ++++++++
> > lib/librte_vhost/vhost_user.c | 44
> +++++++++++++++++++++++++++++++++++++++++++
> > lib/librte_vhost/vhost_user.h | 16 ++++++++++++++++
> > 3 files changed, 68 insertions(+)
> >
> > diff --git a/lib/librte_vhost/rte_vhost.h b/lib/librte_vhost/rte_vhost.h
> > index 2753670..ab710ce 100644
> > --- a/lib/librte_vhost/rte_vhost.h
> > +++ b/lib/librte_vhost/rte_vhost.h
> > @@ -63,6 +63,10 @@
> > #define VHOST_USER_PROTOCOL_F_PAGEFAULT 8
> > #endif
> >
> > +#ifndef VHOST_USER_PROTOCOL_F_CONFIG
> > +#define VHOST_USER_PROTOCOL_F_CONFIG 9
> > +#endif
> > +
> > #ifndef VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD
> > #define VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD 10
> > #endif
> > @@ -173,6 +177,10 @@ struct vhost_device_ops {
> >
> > int (*vring_state_changed)(int vid, uint16_t queue_id, int enable);
> /**< triggered when a vring is enabled or disabled */
> >
> > + int (*get_config)(int vid, uint8_t *config, uint32_t config_len);
> > + int (*set_config)(int vid, uint8_t *config, uint32_t offset,
> > + uint32_t len, uint32_t flags);
>
> 'struct vhost_device_ops' is user visible. This changes API and ABI.
> You need to update docs/rel_notes and bump the library version accordingly.
Sounds good.
>
> Best regards, Ilya Maximets.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v1 1/6] ethdev: add min/max MTU to device info
@ 2019-02-27 21:45 13% ` Ian Stokes
2019-03-19 16:15 0% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Ian Stokes @ 2019-02-27 21:45 UTC (permalink / raw)
To: dev; +Cc: stephen, Ian Stokes
From: Stephen Hemminger <stephen@networkplumber.org>
This addresses the usability issue raised by OVS at DPDK Userspace
summit. It adds general min/max mtu into device info. For compatiablity,
and to save space, it fits in a hole in existing structure.
The initial version sets max mtu to normal Ethernet, it is up to
PMD to set larger value if it supports Jumbo frames.
Also remove the deprecation notice introduced in 18.11 regarding this
change and bump ethdev ABI version.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Ian Stokes <ian.stokes@intel.com>
Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
---
RFC -> v1
* Removed RFC status.
* dev_info->max_mtu set to UINT16_MAX initially instead of ETHER_MTU to
avoid breaking jumbo frame support. ETHER_MTU to be re-introduced
when all PMD drivers modified to support min/max mtu support.
* Bump ethdev ABI version.
* Added ACK from Andrew Rybchenko.
---
doc/guides/rel_notes/deprecation.rst | 12 ------------
doc/guides/rel_notes/release_19_05.rst | 8 +++++++-
lib/librte_ethdev/Makefile | 2 +-
lib/librte_ethdev/meson.build | 2 +-
lib/librte_ethdev/rte_ethdev.c | 7 +++++++
lib/librte_ethdev/rte_ethdev.h | 2 ++
6 files changed, 18 insertions(+), 15 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 1b4fcb7e6..0e85c47f3 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -56,18 +56,6 @@ Deprecation Notices
Target release for removal of the legacy API will be defined once most
PMDs have switched to rte_flow.
-* ethdev: Maximum and minimum MTU values vary between hardware devices. In
- hardware agnostic DPDK applications access to such information would allow
- a more accurate way of validating and setting supported MTU values on a per
- device basis rather than using a defined default for all devices. To
- resolve this, the following members will be added to ``rte_eth_dev_info``.
- Note: these can be added to fit a hole in the existing structure for amd64
- but not for 32-bit, as such ABI change will occur as size of the structure
- will increase.
-
- - Member ``uint16_t min_mtu`` the minimum MTU allowed.
- - Member ``uint16_t max_mtu`` the maximum MTU allowed.
-
* meter: New ``rte_color`` definition will be added in 19.02 and that will
replace ``enum rte_meter_color`` in meter library in 19.05. This will help
to consolidate color definition, which is currently replicated in many places,
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index c0390ca16..a5790352c 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -116,6 +116,12 @@ ABI Changes
Also, make sure to start the actual text at the margin.
=========================================================
+* ethdev: Additional fields in rte_eth_dev_info.
+
+ The ``rte_eth_dev_info`` structure has had two extra fields
+ added: ``min_mtu`` and ``max_mtu``. Each of these are of type ``uint16_t``.
+ The values of these fields can be set specifically by the PMD drivers as
+ supported values can vary from device to device.
Shared Library Versions
-----------------------
@@ -151,7 +157,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_distributor.so.1
librte_eal.so.9
librte_efd.so.1
- librte_ethdev.so.11
+ + librte_ethdev.so.12
librte_eventdev.so.6
librte_flow_classify.so.1
librte_gro.so.1
diff --git a/lib/librte_ethdev/Makefile b/lib/librte_ethdev/Makefile
index e09c4263a..8d4a02630 100644
--- a/lib/librte_ethdev/Makefile
+++ b/lib/librte_ethdev/Makefile
@@ -16,7 +16,7 @@ LDLIBS += -lrte_mbuf -lrte_kvargs -lrte_cmdline -lrte_meter
EXPORT_MAP := rte_ethdev_version.map
-LIBABIVER := 11
+LIBABIVER := 12
SRCS-y += ethdev_private.c
SRCS-y += rte_ethdev.c
diff --git a/lib/librte_ethdev/meson.build b/lib/librte_ethdev/meson.build
index e98942ff8..8d6165b2a 100644
--- a/lib/librte_ethdev/meson.build
+++ b/lib/librte_ethdev/meson.build
@@ -2,7 +2,7 @@
# Copyright(c) 2017 Intel Corporation
name = 'ethdev'
-version = 11
+version = 12
allow_experimental_apis = true
sources = files('ethdev_private.c',
'ethdev_profile.c',
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 85c179496..bdb5f2b0d 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -2524,6 +2524,8 @@ rte_eth_dev_info_get(uint16_t port_id, struct rte_eth_dev_info *dev_info)
dev_info->rx_desc_lim = lim;
dev_info->tx_desc_lim = lim;
dev_info->device = dev->device;
+ dev_info->min_mtu = ETHER_MIN_MTU;
+ dev_info->max_mtu = UINT16_MAX;
RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get);
(*dev->dev_ops->dev_infos_get)(dev, dev_info);
@@ -2587,12 +2589,17 @@ int
rte_eth_dev_set_mtu(uint16_t port_id, uint16_t mtu)
{
int ret;
+ struct rte_eth_dev_info dev_info;
struct rte_eth_dev *dev;
RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
dev = &rte_eth_devices[port_id];
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->mtu_set, -ENOTSUP);
+ rte_eth_dev_info_get(port_id, &dev_info);
+ if (mtu < dev_info.min_mtu || mtu > dev_info.max_mtu)
+ return -EINVAL;
+
ret = (*dev->dev_ops->mtu_set)(dev, mtu);
if (!ret)
dev->data->mtu = mtu;
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index a3c864a13..9fe51b2bd 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1086,6 +1086,8 @@ struct rte_eth_dev_info {
const char *driver_name; /**< Device Driver name. */
unsigned int if_index; /**< Index to bound host interface, or 0 if none.
Use if_indextoname() to translate into an interface name. */
+ uint16_t min_mtu; /**< Minimum MTU allowed */
+ uint16_t max_mtu; /**< Maximum MTU allowed */
const uint32_t *dev_flags; /**< Device flags */
uint32_t min_rx_bufsize; /**< Minimum size of RX buffer. */
uint32_t max_rx_pktlen; /**< Maximum configurable length of RX pkt. */
--
2.13.6
^ permalink raw reply [relevance 13%]
* Re: [dpdk-dev] [PATCH] lib/cryptodev: fix driver name comparison
2019-02-25 11:52 3% ` Trahe, Fiona
@ 2019-02-28 6:48 0% ` Anoob Joseph
2019-02-28 8:51 3% ` Akhil Goyal
0 siblings, 1 reply; 200+ results
From: Anoob Joseph @ 2019-02-28 6:48 UTC (permalink / raw)
To: Trahe, Fiona, Akhil Goyal, Doherty, Declan, De Lara Guarch,
Pablo, Yigit, Ferruh, Thomas Monjalon
Cc: Jerin Jacob Kollanukkaran, Narayana Prasad Raju Athreya, dev,
Ankur Dwivedi
Hi Akhil, Declan, Pablo,
Can you review this patch and share your thoughts?
Thanks,
Anoob
> -----Original Message-----
> From: Trahe, Fiona <fiona.trahe@intel.com>
> Sent: Monday, February 25, 2019 5:22 PM
> To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal
> <akhil.goyal@nxp.com>; Doherty, Declan <declan.doherty@intel.com>; De
> Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Yigit, Ferruh
> <ferruh.yigit@intel.com>; Thomas Monjalon <thomas@monjalon.net>
> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad Raju
> Athreya <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi
> <adwivedi@marvell.com>
> Subject: RE: [PATCH] lib/cryptodev: fix driver name comparison
>
> Hi Anoob
>
> > -----Original Message-----
> > From: Anoob Joseph [mailto:anoobj@marvell.com]
> > Sent: Saturday, February 23, 2019 6:12 AM
> > To: Trahe, Fiona <fiona.trahe@intel.com>; Akhil Goyal
> > <akhil.goyal@nxp.com>; Doherty, Declan <declan.doherty@intel.com>; De
> > Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Yigit, Ferruh
> > <ferruh.yigit@intel.com>; Thomas Monjalon <thomas@monjalon.net>
> > Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad
> > Raju Athreya <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi
> > <adwivedi@marvell.com>
> > Subject: RE: [PATCH] lib/cryptodev: fix driver name comparison
> >
> > Hi Fiona,
> >
> > > -----Original Message-----
> > > From: Trahe, Fiona <fiona.trahe@intel.com>
> > > Sent: Friday, February 22, 2019 9:09 PM
> > > To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal
> > > <akhil.goyal@nxp.com>; Doherty, Declan <declan.doherty@intel.com>;
> > > De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> > > Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad
> > > Raju Athreya <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi
> > > <adwivedi@marvell.com>; Trahe, Fiona <fiona.trahe@intel.com>
> > > Subject: RE: [PATCH] lib/cryptodev: fix driver name comparison
> > >
> > > Hi Anoob,
> > >
> > > > > > > @@ -542,8 +543,8 @@ rte_cryptodev_get_dev_id(const char
> *name)
> > > > > > > return -1;
> > > > > > >
> > > > > > > for (i = 0; i < cryptodev_globals.nb_devs; i++)
> > > > > > > - if ((strcmp(cryptodev_globals.devs[i].data->name,
> name)
> > > > > > > - == 0) &&
> > > > > > > + if ((strncmp(cryptodev_globals.devs[i].data->name,
> > > name,
> > > > > > > + RTE_CRYPTODEV_NAME_MAX_LEN)
> > > == 0)
> > > > > &&
> > > > > [Fiona] Is this safe? The const passed to this may not be the
> > > > > full length of RTE_CRYPTODEV_NAME_MAX_LEN. Does this
> prototype
> > > > > need to specify that a full length const filled with trailing
> > > > > zeros must be passed in? And if so is this an ABI breakage?
> > > > >
> > > >
> > > > [Anoob] strcmp itself is not safe when we have buffers which are
> > > > not NULL terminated. Strncmp will make sure the check won't exceed
> > > RTE_CRYPTODEV_NAME_MAX_LEN.
> > > >
> > > > From man page, "The strncmp() function is similar, except it only
> > > > compares the first (at most) n bytes of
> > > > s1 and s2."
> > > >
> > > > The main issue here is the usage of strncmp with
> > > > strlen(driver_name), as in the below cases. Strlen will return
> > > > string length, which doesn't include \0. strcmp is good enough to
> > > > fix the issue. But usage of strcmp would assume that the const is
> > > > filled with trailing zero. IMO, none of
> > > these options are really safe. So please advise on what would be the
> > > best solution here. I'll revise the patch accordingly.
> > > [Fiona] I agree and think it is safest as you've coded it. However
> > > I'd suggest adding a comment on the relevant APIs saying that the
> > > string must be passed in in a buffer of size <use relevant #define> with
> trailing zeros.
> >
> > [Anoob] Do you want this patch to address that? And wouldn't
> > specifying something like that explicitly, be an ABI breakage?
> [Fiona] Yes, I think it should be in this patch as this patch is causing it.
> But it's up to the maintainers what's acceptable - it seems to me that it's an
> ABI breakage, avoiding saying it explicitly doesn't make it less so.
>
> >
> > Also, I think the same is applicable for other similar functions
> > (rte_eth_dev_get_port_by_name() etc), wherever we expect a string.
> Please do share your thoughts on what all I should include in this patch.
> >
> > Thanks,
> > Anoob
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] lib/cryptodev: fix driver name comparison
2019-02-28 6:48 0% ` Anoob Joseph
@ 2019-02-28 8:51 3% ` Akhil Goyal
2019-02-28 9:27 0% ` Anoob Joseph
0 siblings, 1 reply; 200+ results
From: Akhil Goyal @ 2019-02-28 8:51 UTC (permalink / raw)
To: Anoob Joseph, Trahe, Fiona, Doherty, Declan, De Lara Guarch,
Pablo, Yigit, Ferruh, Thomas Monjalon
Cc: Jerin Jacob Kollanukkaran, Narayana Prasad Raju Athreya, dev,
Ankur Dwivedi
Hi Anoob,
On 2/28/2019 12:18 PM, Anoob Joseph wrote:
> Hi Akhil, Declan, Pablo,
>
> Can you review this patch and share your thoughts?
>
> Thanks,
> Anoob
>
>> -----Original Message-----
>> From: Trahe, Fiona <fiona.trahe@intel.com>
>> Sent: Monday, February 25, 2019 5:22 PM
>> To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal
>> <akhil.goyal@nxp.com>; Doherty, Declan <declan.doherty@intel.com>; De
>> Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Yigit, Ferruh
>> <ferruh.yigit@intel.com>; Thomas Monjalon <thomas@monjalon.net>
>> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad Raju
>> Athreya <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi
>> <adwivedi@marvell.com>
>> Subject: RE: [PATCH] lib/cryptodev: fix driver name comparison
>>
>> Hi Anoob
>>
>>> -----Original Message-----
>>> From: Anoob Joseph [mailto:anoobj@marvell.com]
>>> Sent: Saturday, February 23, 2019 6:12 AM
>>> To: Trahe, Fiona <fiona.trahe@intel.com>; Akhil Goyal
>>> <akhil.goyal@nxp.com>; Doherty, Declan <declan.doherty@intel.com>; De
>>> Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Yigit, Ferruh
>>> <ferruh.yigit@intel.com>; Thomas Monjalon <thomas@monjalon.net>
>>> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad
>>> Raju Athreya <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi
>>> <adwivedi@marvell.com>
>>> Subject: RE: [PATCH] lib/cryptodev: fix driver name comparison
>>>
>>> Hi Fiona,
>>>
>>>> -----Original Message-----
>>>> From: Trahe, Fiona <fiona.trahe@intel.com>
>>>> Sent: Friday, February 22, 2019 9:09 PM
>>>> To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal
>>>> <akhil.goyal@nxp.com>; Doherty, Declan <declan.doherty@intel.com>;
>>>> De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
>>>> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad
>>>> Raju Athreya <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi
>>>> <adwivedi@marvell.com>; Trahe, Fiona <fiona.trahe@intel.com>
>>>> Subject: RE: [PATCH] lib/cryptodev: fix driver name comparison
>>>>
>>>> Hi Anoob,
>>>>
>>>>>>>> @@ -542,8 +543,8 @@ rte_cryptodev_get_dev_id(const char
>> *name)
>>>>>>>> return -1;
>>>>>>>>
>>>>>>>> for (i = 0; i < cryptodev_globals.nb_devs; i++)
>>>>>>>> - if ((strcmp(cryptodev_globals.devs[i].data->name,
>> name)
>>>>>>>> - == 0) &&
>>>>>>>> + if ((strncmp(cryptodev_globals.devs[i].data->name,
>>>> name,
>>>>>>>> + RTE_CRYPTODEV_NAME_MAX_LEN)
consider using "strlen(name) + 1" instead of RTE_CRYPTODEV_NAME_MAX_LEN.
This will not cause any ABI breakage in my opinion and and will check
till we get a null terminated string in both the strings.
What say?
-Akhil
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] lib/cryptodev: fix driver name comparison
2019-02-28 8:51 3% ` Akhil Goyal
@ 2019-02-28 9:27 0% ` Anoob Joseph
2019-02-28 10:20 0% ` Akhil Goyal
0 siblings, 1 reply; 200+ results
From: Anoob Joseph @ 2019-02-28 9:27 UTC (permalink / raw)
To: Akhil Goyal, Trahe, Fiona, Doherty, Declan, De Lara Guarch,
Pablo, Yigit, Ferruh, Thomas Monjalon
Cc: Jerin Jacob Kollanukkaran, Narayana Prasad Raju Athreya, dev,
Ankur Dwivedi
Hi Akhil,
Please see inline.
Thanks,
Anoob
> -----Original Message-----
> From: Akhil Goyal <akhil.goyal@nxp.com>
> Sent: Thursday, February 28, 2019 2:22 PM
> To: Anoob Joseph <anoobj@marvell.com>; Trahe, Fiona
> <fiona.trahe@intel.com>; Doherty, Declan <declan.doherty@intel.com>; De
> Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Yigit, Ferruh
> <ferruh.yigit@intel.com>; Thomas Monjalon <thomas@monjalon.net>
> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad Raju
> Athreya <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi
> <adwivedi@marvell.com>
> Subject: Re: [dpdk-dev] [PATCH] lib/cryptodev: fix driver name comparison
>
> Hi Anoob,
>
> On 2/28/2019 12:18 PM, Anoob Joseph wrote:
> > Hi Akhil, Declan, Pablo,
> >
> > Can you review this patch and share your thoughts?
> >
> > Thanks,
> > Anoob
> >
> >> -----Original Message-----
> >> From: Trahe, Fiona <fiona.trahe@intel.com>
> >> Sent: Monday, February 25, 2019 5:22 PM
> >> To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal
> >> <akhil.goyal@nxp.com>; Doherty, Declan <declan.doherty@intel.com>;
> De
> >> Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Yigit, Ferruh
> >> <ferruh.yigit@intel.com>; Thomas Monjalon <thomas@monjalon.net>
> >> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad
> >> Raju Athreya <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi
> >> <adwivedi@marvell.com>
> >> Subject: RE: [PATCH] lib/cryptodev: fix driver name comparison
> >>
> >> Hi Anoob
> >>
> >>> -----Original Message-----
> >>> From: Anoob Joseph [mailto:anoobj@marvell.com]
> >>> Sent: Saturday, February 23, 2019 6:12 AM
> >>> To: Trahe, Fiona <fiona.trahe@intel.com>; Akhil Goyal
> >>> <akhil.goyal@nxp.com>; Doherty, Declan <declan.doherty@intel.com>;
> >>> De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Yigit,
> >>> Ferruh <ferruh.yigit@intel.com>; Thomas Monjalon
> >>> <thomas@monjalon.net>
> >>> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad
> >>> Raju Athreya <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi
> >>> <adwivedi@marvell.com>
> >>> Subject: RE: [PATCH] lib/cryptodev: fix driver name comparison
> >>>
> >>> Hi Fiona,
> >>>
> >>>> -----Original Message-----
> >>>> From: Trahe, Fiona <fiona.trahe@intel.com>
> >>>> Sent: Friday, February 22, 2019 9:09 PM
> >>>> To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal
> >>>> <akhil.goyal@nxp.com>; Doherty, Declan
> <declan.doherty@intel.com>;
> >>>> De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> >>>> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad
> >>>> Raju Athreya <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi
> >>>> <adwivedi@marvell.com>; Trahe, Fiona <fiona.trahe@intel.com>
> >>>> Subject: RE: [PATCH] lib/cryptodev: fix driver name comparison
> >>>>
> >>>> Hi Anoob,
> >>>>
> >>>>>>>> @@ -542,8 +543,8 @@ rte_cryptodev_get_dev_id(const char
> >> *name)
> >>>>>>>> return -1;
> >>>>>>>>
> >>>>>>>> for (i = 0; i < cryptodev_globals.nb_devs; i++)
> >>>>>>>> - if ((strcmp(cryptodev_globals.devs[i].data->name,
> >> name)
> >>>>>>>> - == 0) &&
> >>>>>>>> + if ((strncmp(cryptodev_globals.devs[i].data->name,
> >>>> name,
> >>>>>>>> + RTE_CRYPTODEV_NAME_MAX_LEN)
>
> consider using "strlen(name) + 1" instead of
> RTE_CRYPTODEV_NAME_MAX_LEN.
> This will not cause any ABI breakage in my opinion and and will check till we
> get a null terminated string in both the strings.
> What say?
[Anoob] In that case, I'll restrict the patch to two places. Wherever strlen(name) is used, I'll make it strlen(name)+1. I won't touch strcmp ones as that would work as is. Shall I prepare a v2?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 1/3] cryptodev: add result field to mod exp and inverse operations
@ 2019-02-28 9:59 3% ` Akhil Goyal
2019-02-28 10:44 0% ` Kusztal, ArkadiuszX
0 siblings, 1 reply; 200+ results
From: Akhil Goyal @ 2019-02-28 9:59 UTC (permalink / raw)
To: Shally Verma, Arek Kusztal, dev; +Cc: fiona.trahe, shally.verma
On 2/12/2019 4:25 PM, Shally Verma wrote:
>
>> -----Original Message-----
>> From: Arek Kusztal <arkadiuszx.kusztal@intel.com>
>> Sent: 08 February 2019 16:44
>> To: dev@dpdk.org
>> Cc: akhil.goyal@nxp.com; fiona.trahe@intel.com; shally.verma@caviumnetworks.com; Arek Kusztal <arkadiuszx.kusztal@intel.com>
>> Subject: [PATCH v2 1/3] cryptodev: add result field to mod exp and inverse operations
>>
>> External Email
>>
>> This commit adds result field to be used when modular exponentiation or
>> modular multiplicative inverse operation is used
>>
>> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
>> ---
> Acked-by: Shally Verma <shallyv@marvell.com>
>
>> lib/librte_cryptodev/rte_crypto_asym.h | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/lib/librte_cryptodev/rte_crypto_asym.h b/lib/librte_cryptodev/rte_crypto_asym.h
>> index 0a50cd5..991263f 100644
>> --- a/lib/librte_cryptodev/rte_crypto_asym.h
>> +++ b/lib/librte_cryptodev/rte_crypto_asym.h
>> @@ -339,6 +339,16 @@ struct rte_crypto_mod_op_param {
>> * be relatively prime to modulus in corresponding Modular
>> * Multiplicative Inverse rte_crypto_modinv_xform
>> */
>> +
>> + rte_crypto_param result;
ABI breakage??
Do we have a deprecation notice?
>> + /**<
>> + * Pointer to the result of modular exponentiation/multiplicative inverse
>> + * data in octet-string network byte order format.
>> + *
>> + * This field shall be big enough to hold the result of Modular
>> + * Exponentiation or Modular Multplicative Inverse
>> + * (bigger or equal to length of modulus)
>> + */
>> };
>>
>> /**
>> --
>> 2.1.0
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for cryptodev config
2019-02-01 11:49 4% ` Trahe, Fiona
@ 2019-02-28 10:02 4% ` Akhil Goyal
2019-02-28 10:54 4% ` Anoob Joseph
0 siblings, 1 reply; 200+ results
From: Akhil Goyal @ 2019-02-28 10:02 UTC (permalink / raw)
To: Trahe, Fiona, Thomas Monjalon, dev
Cc: Anoob Joseph, De Lara Guarch, Pablo, Jerin Jacob Kollanukkaran,
Narayana Prasad Raju Athreya, Shally Verma, Doherty, Declan
Hi Anoob,
On 2/1/2019 5:19 PM, Trahe, Fiona wrote:
> Hi Thomas, Akhil, Anoob,
>
>> -----Original Message-----
>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
>> Sent: Friday, February 1, 2019 11:14 AM
>> To: dev@dpdk.org
>> Cc: Akhil Goyal <akhil.goyal@nxp.com>; Anoob Joseph <anoobj@marvell.com>; De Lara Guarch, Pablo
>> <pablo.de.lara.guarch@intel.com>; Trahe, Fiona <fiona.trahe@intel.com>; Jerin Jacob Kollanukkaran
>> <jerinj@marvell.com>; Narayana Prasad Raju Athreya <pathreya@marvell.com>; Shally Verma
>> <shallyv@marvell.com>; Doherty, Declan <declan.doherty@intel.com>
>> Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI change for cryptodev config
>>
>> There is only one ack for this change.
>> A deprecation requires more agreement (3 valuable acks).
>> Other opinions?
>>
>>
>> 31/01/2019 10:53, Akhil Goyal:
>>> On 1/17/2019 3:09 PM, Anoob Joseph wrote:
>>>> Add new field ff_enable in rte_cryptodev_config. This enables
>>>> applications to control the features enabled on the crypto device.
>>>>
>>>> Proposed new layout:
>>>>
>>>> /** Crypto device configuration structure */
>>>> struct rte_cryptodev_config {
>>>> int socket_id; /**< Socket to allocate resources on */
>>>> uint16_t nb_queue_pairs;
>>>> /**< Number of queue pairs to configure on device */
>>>> + uint64_t ff_enable;
>>>> + /**< Feature flags to be enabled on the device. Only the features set
>>>> + * on rte_cryptodev_info.feature_flags are allowed to be set.
>>>> + */
>>>> };
>>>>
>>>> For eth devices, rte_eth_conf.rx_mode.offloads and
>>>> rte_eth_conf.tx_mode.offloads fields are used by applications to
>>>> control the offloads enabled on the eth device. This proposal adds a
>>>> similar ability for the crypto device.
>>>>
>>>> Signed-off-by: Anoob Joseph <anoobj@marvell.com>
>>>>
>>> Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
> [Fiona] Keeping consistent with ethdev is a lower priority that adding a
> param that works well for crypto. As proposed this ff_enable is problematic for crypto
> as it makes no sense to enable/disable most of the flags.
> For some there's no sensible action a PMD can take, e.g. RTE_CRYPTODEV_FF_HW_ACCELERATED.
> For some, PMDs would need to add performance impacting forks on the data path to check for disabled features. E.g. if an applic disables the RTE_CRYPTODEV_FF_CPU_AESNI flag, what does it expect the PMD to do? Not use the aesni capability of the CPU? Fork and do a less performant implementation?
> Or if this flag is set, RTE_CRYPTODEV_FF_OOP_LB_IN_LB_OUT or RTE_CRYPTODEV_FF_SYM_OPERATION_CHAINING, does the PMD need to check for operations like these and reject them?
> It seems there are only 3 of the 16 flags that it's desirable to disable, based on the earlier thread
> RTE_CRYPTODEV_FF_ASYMMETRIC_CRYPTO
> RTE_CRYPTODEV_FF_SYMMETRIC_CRYPTO
> RTE_CRYPTODEV_FF_SECURITY
> So I propose this param should be called ff_disable.
> It should documented - and maybe provide a mask for - the flags the application is allowed to disable - only the above 3. Then PMDs only need to implement enable/disable functionality for that subset of flags.
could you send a new version of this patch as per the comments from Fiona.
Thanks,
Akhil
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] lib/cryptodev: fix driver name comparison
2019-02-28 9:27 0% ` Anoob Joseph
@ 2019-02-28 10:20 0% ` Akhil Goyal
2019-02-28 14:30 0% ` Trahe, Fiona
0 siblings, 1 reply; 200+ results
From: Akhil Goyal @ 2019-02-28 10:20 UTC (permalink / raw)
To: Anoob Joseph, Trahe, Fiona, Doherty, Declan, De Lara Guarch,
Pablo, Yigit, Ferruh, Thomas Monjalon
Cc: Jerin Jacob Kollanukkaran, Narayana Prasad Raju Athreya, dev,
Ankur Dwivedi
On 2/28/2019 2:57 PM, Anoob Joseph wrote:
> Hi Akhil,
>
> Please see inline.
>
> Thanks,
> Anoob
>
>> -----Original Message-----
>> From: Akhil Goyal <akhil.goyal@nxp.com>
>> Sent: Thursday, February 28, 2019 2:22 PM
>> To: Anoob Joseph <anoobj@marvell.com>; Trahe, Fiona
>> <fiona.trahe@intel.com>; Doherty, Declan <declan.doherty@intel.com>; De
>> Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Yigit, Ferruh
>> <ferruh.yigit@intel.com>; Thomas Monjalon <thomas@monjalon.net>
>> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad Raju
>> Athreya <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi
>> <adwivedi@marvell.com>
>> Subject: Re: [dpdk-dev] [PATCH] lib/cryptodev: fix driver name comparison
>>
>> Hi Anoob,
>>
>> On 2/28/2019 12:18 PM, Anoob Joseph wrote:
>>> Hi Akhil, Declan, Pablo,
>>>
>>> Can you review this patch and share your thoughts?
>>>
>>> Thanks,
>>> Anoob
>>>
>>>> -----Original Message-----
>>>> From: Trahe, Fiona <fiona.trahe@intel.com>
>>>> Sent: Monday, February 25, 2019 5:22 PM
>>>> To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal
>>>> <akhil.goyal@nxp.com>; Doherty, Declan <declan.doherty@intel.com>;
>> De
>>>> Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Yigit, Ferruh
>>>> <ferruh.yigit@intel.com>; Thomas Monjalon <thomas@monjalon.net>
>>>> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad
>>>> Raju Athreya <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi
>>>> <adwivedi@marvell.com>
>>>> Subject: RE: [PATCH] lib/cryptodev: fix driver name comparison
>>>>
>>>> Hi Anoob
>>>>
>>>>> -----Original Message-----
>>>>> From: Anoob Joseph [mailto:anoobj@marvell.com]
>>>>> Sent: Saturday, February 23, 2019 6:12 AM
>>>>> To: Trahe, Fiona <fiona.trahe@intel.com>; Akhil Goyal
>>>>> <akhil.goyal@nxp.com>; Doherty, Declan <declan.doherty@intel.com>;
>>>>> De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Yigit,
>>>>> Ferruh <ferruh.yigit@intel.com>; Thomas Monjalon
>>>>> <thomas@monjalon.net>
>>>>> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad
>>>>> Raju Athreya <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi
>>>>> <adwivedi@marvell.com>
>>>>> Subject: RE: [PATCH] lib/cryptodev: fix driver name comparison
>>>>>
>>>>> Hi Fiona,
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Trahe, Fiona <fiona.trahe@intel.com>
>>>>>> Sent: Friday, February 22, 2019 9:09 PM
>>>>>> To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal
>>>>>> <akhil.goyal@nxp.com>; Doherty, Declan
>> <declan.doherty@intel.com>;
>>>>>> De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
>>>>>> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad
>>>>>> Raju Athreya <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi
>>>>>> <adwivedi@marvell.com>; Trahe, Fiona <fiona.trahe@intel.com>
>>>>>> Subject: RE: [PATCH] lib/cryptodev: fix driver name comparison
>>>>>>
>>>>>> Hi Anoob,
>>>>>>
>>>>>>>>>> @@ -542,8 +543,8 @@ rte_cryptodev_get_dev_id(const char
>>>> *name)
>>>>>>>>>> return -1;
>>>>>>>>>>
>>>>>>>>>> for (i = 0; i < cryptodev_globals.nb_devs; i++)
>>>>>>>>>> - if ((strcmp(cryptodev_globals.devs[i].data->name,
>>>> name)
>>>>>>>>>> - == 0) &&
>>>>>>>>>> + if ((strncmp(cryptodev_globals.devs[i].data->name,
>>>>>> name,
>>>>>>>>>> + RTE_CRYPTODEV_NAME_MAX_LEN)
>> consider using "strlen(name) + 1" instead of
>> RTE_CRYPTODEV_NAME_MAX_LEN.
>> This will not cause any ABI breakage in my opinion and and will check till we
>> get a null terminated string in both the strings.
>> What say?
> [Anoob] In that case, I'll restrict the patch to two places. Wherever strlen(name) is used, I'll make it strlen(name)+1. I won't touch strcmp ones as that would work as is. Shall I prepare a v2?
I think it should be fine.
Fiona,
Any comments?
-Akhil
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 1/3] cryptodev: add result field to mod exp and inverse operations
2019-02-28 9:59 3% ` Akhil Goyal
@ 2019-02-28 10:44 0% ` Kusztal, ArkadiuszX
2019-02-28 10:52 0% ` Akhil Goyal
0 siblings, 1 reply; 200+ results
From: Kusztal, ArkadiuszX @ 2019-02-28 10:44 UTC (permalink / raw)
To: Akhil Goyal, Shally Verma, dev; +Cc: Trahe, Fiona, shally.verma
Hi Akhil,
> -----Original Message-----
> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> Sent: Thursday, February 28, 2019 10:59 AM
> To: Shally Verma <shallyv@marvell.com>; Kusztal, ArkadiuszX
> <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
> Cc: Trahe, Fiona <fiona.trahe@intel.com>;
> shally.verma@caviumnetworks.com
> Subject: Re: [dpdk-dev] [PATCH v2 1/3] cryptodev: add result field to mod
> exp and inverse operations
>
>
>
> On 2/12/2019 4:25 PM, Shally Verma wrote:
> >
> >> -----Original Message-----
> >> From: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> >> Sent: 08 February 2019 16:44
> >> To: dev@dpdk.org
> >> Cc: akhil.goyal@nxp.com; fiona.trahe@intel.com;
> >> shally.verma@caviumnetworks.com; Arek Kusztal
> >> <arkadiuszx.kusztal@intel.com>
> >> Subject: [PATCH v2 1/3] cryptodev: add result field to mod exp and
> >> inverse operations
> >>
> >> External Email
> >>
> >> This commit adds result field to be used when modular exponentiation
> >> or modular multiplicative inverse operation is used
> >>
> >> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> >> ---
> > Acked-by: Shally Verma <shallyv@marvell.com>
> >
> >> lib/librte_cryptodev/rte_crypto_asym.h | 10 ++++++++++
> >> 1 file changed, 10 insertions(+)
> >>
> >> diff --git a/lib/librte_cryptodev/rte_crypto_asym.h
> >> b/lib/librte_cryptodev/rte_crypto_asym.h
> >> index 0a50cd5..991263f 100644
> >> --- a/lib/librte_cryptodev/rte_crypto_asym.h
> >> +++ b/lib/librte_cryptodev/rte_crypto_asym.h
> >> @@ -339,6 +339,16 @@ struct rte_crypto_mod_op_param {
> >> * be relatively prime to modulus in corresponding Modular
> >> * Multiplicative Inverse rte_crypto_modinv_xform
> >> */
> >> +
> >> + rte_crypto_param result;
> ABI breakage??
> Do we have a deprecation notice?
Is not asymmetric crypto API still experimental? Do we have then add deprecation notice?
> >> + /**<
> >> + * Pointer to the result of modular exponentiation/multiplicative
> inverse
> >> + * data in octet-string network byte order format.
> >> + *
> >> + * This field shall be big enough to hold the result of Modular
> >> + * Exponentiation or Modular Multplicative Inverse
> >> + * (bigger or equal to length of modulus)
> >> + */
> >> };
> >>
> >> /**
> >> --
> >> 2.1.0
Thanks,
Arek
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 1/3] cryptodev: add result field to mod exp and inverse operations
2019-02-28 10:44 0% ` Kusztal, ArkadiuszX
@ 2019-02-28 10:52 0% ` Akhil Goyal
0 siblings, 0 replies; 200+ results
From: Akhil Goyal @ 2019-02-28 10:52 UTC (permalink / raw)
To: Kusztal, ArkadiuszX, Shally Verma, dev; +Cc: Trahe, Fiona, shally.verma
Hi Arek,
On 2/28/2019 4:14 PM, Kusztal, ArkadiuszX wrote:
> Hi Akhil,
>
>> -----Original Message-----
>> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
>> Sent: Thursday, February 28, 2019 10:59 AM
>> To: Shally Verma <shallyv@marvell.com>; Kusztal, ArkadiuszX
>> <arkadiuszx.kusztal@intel.com>; dev@dpdk.org
>> Cc: Trahe, Fiona <fiona.trahe@intel.com>;
>> shally.verma@caviumnetworks.com
>> Subject: Re: [dpdk-dev] [PATCH v2 1/3] cryptodev: add result field to mod
>> exp and inverse operations
>>
>>
>>
>> On 2/12/2019 4:25 PM, Shally Verma wrote:
>>>> -----Original Message-----
>>>> From: Arek Kusztal <arkadiuszx.kusztal@intel.com>
>>>> Sent: 08 February 2019 16:44
>>>> To: dev@dpdk.org
>>>> Cc: akhil.goyal@nxp.com; fiona.trahe@intel.com;
>>>> shally.verma@caviumnetworks.com; Arek Kusztal
>>>> <arkadiuszx.kusztal@intel.com>
>>>> Subject: [PATCH v2 1/3] cryptodev: add result field to mod exp and
>>>> inverse operations
>>>>
>>>> External Email
>>>>
>>>> This commit adds result field to be used when modular exponentiation
>>>> or modular multiplicative inverse operation is used
>>>>
>>>> Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
>>>> ---
>>> Acked-by: Shally Verma <shallyv@marvell.com>
>>>
>>>> lib/librte_cryptodev/rte_crypto_asym.h | 10 ++++++++++
>>>> 1 file changed, 10 insertions(+)
>>>>
>>>> diff --git a/lib/librte_cryptodev/rte_crypto_asym.h
>>>> b/lib/librte_cryptodev/rte_crypto_asym.h
>>>> index 0a50cd5..991263f 100644
>>>> --- a/lib/librte_cryptodev/rte_crypto_asym.h
>>>> +++ b/lib/librte_cryptodev/rte_crypto_asym.h
>>>> @@ -339,6 +339,16 @@ struct rte_crypto_mod_op_param {
>>>> * be relatively prime to modulus in corresponding Modular
>>>> * Multiplicative Inverse rte_crypto_modinv_xform
>>>> */
>>>> +
>>>> + rte_crypto_param result;
>> ABI breakage??
>> Do we have a deprecation notice?
> Is not asymmetric crypto API still experimental? Do we have then add deprecation notice?
sorry I missed that. Actually I did not see anything tagged as
EXPERIMENTAL in rte_crypto_asym.h. Probably it should be mentioned at
the top of the file as it is mentioned in other files which are
experimental.
>
>>>> + /**<
>>>> + * Pointer to the result of modular exponentiation/multiplicative
>> inverse
>>>> + * data in octet-string network byte order format.
>>>> + *
>>>> + * This field shall be big enough to hold the result of Modular
>>>> + * Exponentiation or Modular Multplicative Inverse
>>>> + * (bigger or equal to length of modulus)
>>>> + */
>>>> };
>>>>
>>>> /**
>>>> --
>>>> 2.1.0
> Thanks,
> Arek
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for cryptodev config
2019-02-28 10:02 4% ` Akhil Goyal
@ 2019-02-28 10:54 4% ` Anoob Joseph
0 siblings, 0 replies; 200+ results
From: Anoob Joseph @ 2019-02-28 10:54 UTC (permalink / raw)
To: Akhil Goyal, Trahe, Fiona, Thomas Monjalon, dev
Cc: De Lara Guarch, Pablo, Jerin Jacob Kollanukkaran,
Narayana Prasad Raju Athreya, Shally Verma, Doherty, Declan
Hi Akhil,
I'll send a v2 incorporating Fiona's comments.
Thanks,
Anoob
> -----Original Message-----
> From: Akhil Goyal <akhil.goyal@nxp.com>
> Sent: Thursday, February 28, 2019 3:32 PM
> To: Trahe, Fiona <fiona.trahe@intel.com>; Thomas Monjalon
> <thomas@monjalon.net>; dev@dpdk.org
> Cc: Anoob Joseph <anoobj@marvell.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; Jerin Jacob Kollanukkaran
> <jerinj@marvell.com>; Narayana Prasad Raju Athreya
> <pathreya@marvell.com>; Shally Verma <shallyv@marvell.com>; Doherty,
> Declan <declan.doherty@intel.com>
> Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI change for cryptodev
> config
>
> Hi Anoob,
>
> On 2/1/2019 5:19 PM, Trahe, Fiona wrote:
> > Hi Thomas, Akhil, Anoob,
> >
> >> -----Original Message-----
> >> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> >> Sent: Friday, February 1, 2019 11:14 AM
> >> To: dev@dpdk.org
> >> Cc: Akhil Goyal <akhil.goyal@nxp.com>; Anoob Joseph
> >> <anoobj@marvell.com>; De Lara Guarch, Pablo
> >> <pablo.de.lara.guarch@intel.com>; Trahe, Fiona
> >> <fiona.trahe@intel.com>; Jerin Jacob Kollanukkaran
> >> <jerinj@marvell.com>; Narayana Prasad Raju Athreya
> >> <pathreya@marvell.com>; Shally Verma <shallyv@marvell.com>;
> Doherty,
> >> Declan <declan.doherty@intel.com>
> >> Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI change for
> >> cryptodev config
> >>
> >> There is only one ack for this change.
> >> A deprecation requires more agreement (3 valuable acks).
> >> Other opinions?
> >>
> >>
> >> 31/01/2019 10:53, Akhil Goyal:
> >>> On 1/17/2019 3:09 PM, Anoob Joseph wrote:
> >>>> Add new field ff_enable in rte_cryptodev_config. This enables
> >>>> applications to control the features enabled on the crypto device.
> >>>>
> >>>> Proposed new layout:
> >>>>
> >>>> /** Crypto device configuration structure */ struct
> >>>> rte_cryptodev_config {
> >>>> int socket_id; /**< Socket to allocate resources on */
> >>>> uint16_t nb_queue_pairs;
> >>>> /**< Number of queue pairs to configure on device */
> >>>> + uint64_t ff_enable;
> >>>> + /**< Feature flags to be enabled on the device. Only the features
> set
> >>>> + * on rte_cryptodev_info.feature_flags are allowed to be set.
> >>>> + */
> >>>> };
> >>>>
> >>>> For eth devices, rte_eth_conf.rx_mode.offloads and
> >>>> rte_eth_conf.tx_mode.offloads fields are used by applications to
> >>>> control the offloads enabled on the eth device. This proposal adds
> >>>> a similar ability for the crypto device.
> >>>>
> >>>> Signed-off-by: Anoob Joseph <anoobj@marvell.com>
> >>>>
> >>> Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
> > [Fiona] Keeping consistent with ethdev is a lower priority that adding
> > a param that works well for crypto. As proposed this ff_enable is
> > problematic for crypto as it makes no sense to enable/disable most of the
> flags.
> > For some there's no sensible action a PMD can take, e.g.
> RTE_CRYPTODEV_FF_HW_ACCELERATED.
> > For some, PMDs would need to add performance impacting forks on the
> data path to check for disabled features. E.g. if an applic disables the
> RTE_CRYPTODEV_FF_CPU_AESNI flag, what does it expect the PMD to do?
> Not use the aesni capability of the CPU? Fork and do a less performant
> implementation?
> > Or if this flag is set, RTE_CRYPTODEV_FF_OOP_LB_IN_LB_OUT or
> RTE_CRYPTODEV_FF_SYM_OPERATION_CHAINING, does the PMD need to
> check for operations like these and reject them?
> > It seems there are only 3 of the 16 flags that it's desirable to
> > disable, based on the earlier thread
> > RTE_CRYPTODEV_FF_ASYMMETRIC_CRYPTO
> > RTE_CRYPTODEV_FF_SYMMETRIC_CRYPTO
> > RTE_CRYPTODEV_FF_SECURITY
> > So I propose this param should be called ff_disable.
> > It should documented - and maybe provide a mask for - the flags the
> application is allowed to disable - only the above 3. Then PMDs only need to
> implement enable/disable functionality for that subset of flags.
>
> could you send a new version of this patch as per the comments from Fiona.
>
> Thanks,
> Akhil
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] lib/cryptodev: fix driver name comparison
2019-02-28 10:20 0% ` Akhil Goyal
@ 2019-02-28 14:30 0% ` Trahe, Fiona
2019-03-01 6:24 0% ` Anoob Joseph
0 siblings, 1 reply; 200+ results
From: Trahe, Fiona @ 2019-02-28 14:30 UTC (permalink / raw)
To: Akhil Goyal, Anoob Joseph, Doherty, Declan, De Lara Guarch,
Pablo, Yigit, Ferruh, Thomas Monjalon
Cc: Jerin Jacob Kollanukkaran, Narayana Prasad Raju Athreya, dev,
Ankur Dwivedi, Trahe, Fiona
Hi Akhil, Anoob,
> -----Original Message-----
> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> Sent: Thursday, February 28, 2019 10:20 AM
> To: Anoob Joseph <anoobj@marvell.com>; Trahe, Fiona <fiona.trahe@intel.com>; Doherty, Declan
> <declan.doherty@intel.com>; De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Yigit, Ferruh
> <ferruh.yigit@intel.com>; Thomas Monjalon <thomas@monjalon.net>
> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad Raju Athreya
> <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi <adwivedi@marvell.com>
> Subject: Re: [dpdk-dev] [PATCH] lib/cryptodev: fix driver name comparison
>
>
>
> On 2/28/2019 2:57 PM, Anoob Joseph wrote:
> > Hi Akhil,
> >
> > Please see inline.
> >
> > Thanks,
> > Anoob
> >
> >> -----Original Message-----
> >> From: Akhil Goyal <akhil.goyal@nxp.com>
> >> Sent: Thursday, February 28, 2019 2:22 PM
> >> To: Anoob Joseph <anoobj@marvell.com>; Trahe, Fiona
> >> <fiona.trahe@intel.com>; Doherty, Declan <declan.doherty@intel.com>; De
> >> Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Yigit, Ferruh
> >> <ferruh.yigit@intel.com>; Thomas Monjalon <thomas@monjalon.net>
> >> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad Raju
> >> Athreya <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi
> >> <adwivedi@marvell.com>
> >> Subject: Re: [dpdk-dev] [PATCH] lib/cryptodev: fix driver name comparison
> >>
> >> Hi Anoob,
> >>
> >> On 2/28/2019 12:18 PM, Anoob Joseph wrote:
> >>> Hi Akhil, Declan, Pablo,
> >>>
> >>> Can you review this patch and share your thoughts?
> >>>
> >>> Thanks,
> >>> Anoob
> >>>
> >>>> -----Original Message-----
> >>>> From: Trahe, Fiona <fiona.trahe@intel.com>
> >>>> Sent: Monday, February 25, 2019 5:22 PM
> >>>> To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal
> >>>> <akhil.goyal@nxp.com>; Doherty, Declan <declan.doherty@intel.com>;
> >> De
> >>>> Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Yigit, Ferruh
> >>>> <ferruh.yigit@intel.com>; Thomas Monjalon <thomas@monjalon.net>
> >>>> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad
> >>>> Raju Athreya <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi
> >>>> <adwivedi@marvell.com>
> >>>> Subject: RE: [PATCH] lib/cryptodev: fix driver name comparison
> >>>>
> >>>> Hi Anoob
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Anoob Joseph [mailto:anoobj@marvell.com]
> >>>>> Sent: Saturday, February 23, 2019 6:12 AM
> >>>>> To: Trahe, Fiona <fiona.trahe@intel.com>; Akhil Goyal
> >>>>> <akhil.goyal@nxp.com>; Doherty, Declan <declan.doherty@intel.com>;
> >>>>> De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Yigit,
> >>>>> Ferruh <ferruh.yigit@intel.com>; Thomas Monjalon
> >>>>> <thomas@monjalon.net>
> >>>>> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad
> >>>>> Raju Athreya <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi
> >>>>> <adwivedi@marvell.com>
> >>>>> Subject: RE: [PATCH] lib/cryptodev: fix driver name comparison
> >>>>>
> >>>>> Hi Fiona,
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Trahe, Fiona <fiona.trahe@intel.com>
> >>>>>> Sent: Friday, February 22, 2019 9:09 PM
> >>>>>> To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal
> >>>>>> <akhil.goyal@nxp.com>; Doherty, Declan
> >> <declan.doherty@intel.com>;
> >>>>>> De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> >>>>>> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad
> >>>>>> Raju Athreya <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi
> >>>>>> <adwivedi@marvell.com>; Trahe, Fiona <fiona.trahe@intel.com>
> >>>>>> Subject: RE: [PATCH] lib/cryptodev: fix driver name comparison
> >>>>>>
> >>>>>> Hi Anoob,
> >>>>>>
> >>>>>>>>>> @@ -542,8 +543,8 @@ rte_cryptodev_get_dev_id(const char
> >>>> *name)
> >>>>>>>>>> return -1;
> >>>>>>>>>>
> >>>>>>>>>> for (i = 0; i < cryptodev_globals.nb_devs; i++)
> >>>>>>>>>> - if ((strcmp(cryptodev_globals.devs[i].data->name,
> >>>> name)
> >>>>>>>>>> - == 0) &&
> >>>>>>>>>> + if ((strncmp(cryptodev_globals.devs[i].data->name,
> >>>>>> name,
> >>>>>>>>>> + RTE_CRYPTODEV_NAME_MAX_LEN)
> >> consider using "strlen(name) + 1" instead of
> >> RTE_CRYPTODEV_NAME_MAX_LEN.
> >> This will not cause any ABI breakage in my opinion and and will check till we
> >> get a null terminated string in both the strings.
> >> What say?
> > [Anoob] In that case, I'll restrict the patch to two places. Wherever strlen(name) is used, I'll make it
> strlen(name)+1. I won't touch strcmp ones as that would work as is. Shall I prepare a v2?
> I think it should be fine.
>
> Fiona,
> Any comments?
[Fiona] Good idea. That should be ok.
>
> -Akhil
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] lib/cryptodev: fix driver name comparison
2019-02-28 14:30 0% ` Trahe, Fiona
@ 2019-03-01 6:24 0% ` Anoob Joseph
2019-03-07 5:51 0% ` Anoob Joseph
0 siblings, 1 reply; 200+ results
From: Anoob Joseph @ 2019-03-01 6:24 UTC (permalink / raw)
To: Trahe, Fiona, Akhil Goyal, Doherty, Declan, De Lara Guarch,
Pablo, Yigit, Ferruh, Thomas Monjalon
Cc: Jerin Jacob Kollanukkaran, Narayana Prasad Raju Athreya, dev,
Ankur Dwivedi
Hi Fiona, Akhil,
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Trahe, Fiona
> Sent: Thursday, February 28, 2019 8:00 PM
> To: Akhil Goyal <akhil.goyal@nxp.com>; Anoob Joseph
> <anoobj@marvell.com>; Doherty, Declan <declan.doherty@intel.com>; De
> Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Yigit, Ferruh
> <ferruh.yigit@intel.com>; Thomas Monjalon <thomas@monjalon.net>
> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad Raju
> Athreya <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi
> <adwivedi@marvell.com>; Trahe, Fiona <fiona.trahe@intel.com>
> Subject: Re: [dpdk-dev] [PATCH] lib/cryptodev: fix driver name comparison
>
> Hi Akhil, Anoob,
>
> > -----Original Message-----
> > From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> > Sent: Thursday, February 28, 2019 10:20 AM
> > To: Anoob Joseph <anoobj@marvell.com>; Trahe, Fiona
> > <fiona.trahe@intel.com>; Doherty, Declan <declan.doherty@intel.com>;
> > De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Yigit, Ferruh
> > <ferruh.yigit@intel.com>; Thomas Monjalon <thomas@monjalon.net>
> > Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad
> > Raju Athreya <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi
> > <adwivedi@marvell.com>
> > Subject: Re: [dpdk-dev] [PATCH] lib/cryptodev: fix driver name
> > comparison
> >
> >
> >
> > On 2/28/2019 2:57 PM, Anoob Joseph wrote:
> > > Hi Akhil,
> > >
> > > Please see inline.
> > >
> > > Thanks,
> > > Anoob
> > >
> > >> -----Original Message-----
> > >> From: Akhil Goyal <akhil.goyal@nxp.com>
> > >> Sent: Thursday, February 28, 2019 2:22 PM
> > >> To: Anoob Joseph <anoobj@marvell.com>; Trahe, Fiona
> > >> <fiona.trahe@intel.com>; Doherty, Declan
> > >> <declan.doherty@intel.com>; De Lara Guarch, Pablo
> > >> <pablo.de.lara.guarch@intel.com>; Yigit, Ferruh
> > >> <ferruh.yigit@intel.com>; Thomas Monjalon <thomas@monjalon.net>
> > >> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad
> > >> Raju Athreya <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi
> > >> <adwivedi@marvell.com>
> > >> Subject: Re: [dpdk-dev] [PATCH] lib/cryptodev: fix driver name
> > >> comparison
> > >>
> > >> Hi Anoob,
> > >>
> > >> On 2/28/2019 12:18 PM, Anoob Joseph wrote:
> > >>> Hi Akhil, Declan, Pablo,
> > >>>
> > >>> Can you review this patch and share your thoughts?
> > >>>
> > >>> Thanks,
> > >>> Anoob
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Trahe, Fiona <fiona.trahe@intel.com>
> > >>>> Sent: Monday, February 25, 2019 5:22 PM
> > >>>> To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal
> > >>>> <akhil.goyal@nxp.com>; Doherty, Declan
> > >>>> <declan.doherty@intel.com>;
> > >> De
> > >>>> Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Yigit,
> > >>>> Ferruh <ferruh.yigit@intel.com>; Thomas Monjalon
> > >>>> <thomas@monjalon.net>
> > >>>> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana
> > >>>> Prasad Raju Athreya <pathreya@marvell.com>; dev@dpdk.org;
> Ankur
> > >>>> Dwivedi <adwivedi@marvell.com>
> > >>>> Subject: RE: [PATCH] lib/cryptodev: fix driver name comparison
> > >>>>
> > >>>> Hi Anoob
> > >>>>
> > >>>>> -----Original Message-----
> > >>>>> From: Anoob Joseph [mailto:anoobj@marvell.com]
> > >>>>> Sent: Saturday, February 23, 2019 6:12 AM
> > >>>>> To: Trahe, Fiona <fiona.trahe@intel.com>; Akhil Goyal
> > >>>>> <akhil.goyal@nxp.com>; Doherty, Declan
> > >>>>> <declan.doherty@intel.com>; De Lara Guarch, Pablo
> > >>>>> <pablo.de.lara.guarch@intel.com>; Yigit, Ferruh
> > >>>>> <ferruh.yigit@intel.com>; Thomas Monjalon
> <thomas@monjalon.net>
> > >>>>> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana
> > >>>>> Prasad Raju Athreya <pathreya@marvell.com>; dev@dpdk.org;
> Ankur
> > >>>>> Dwivedi <adwivedi@marvell.com>
> > >>>>> Subject: RE: [PATCH] lib/cryptodev: fix driver name comparison
> > >>>>>
> > >>>>> Hi Fiona,
> > >>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: Trahe, Fiona <fiona.trahe@intel.com>
> > >>>>>> Sent: Friday, February 22, 2019 9:09 PM
> > >>>>>> To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal
> > >>>>>> <akhil.goyal@nxp.com>; Doherty, Declan
> > >> <declan.doherty@intel.com>;
> > >>>>>> De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> > >>>>>> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana
> > >>>>>> Prasad Raju Athreya <pathreya@marvell.com>; dev@dpdk.org;
> Ankur
> > >>>>>> Dwivedi <adwivedi@marvell.com>; Trahe, Fiona
> > >>>>>> <fiona.trahe@intel.com>
> > >>>>>> Subject: RE: [PATCH] lib/cryptodev: fix driver name comparison
> > >>>>>>
> > >>>>>> Hi Anoob,
> > >>>>>>
> > >>>>>>>>>> @@ -542,8 +543,8 @@ rte_cryptodev_get_dev_id(const char
> > >>>> *name)
> > >>>>>>>>>> return -1;
> > >>>>>>>>>>
> > >>>>>>>>>> for (i = 0; i < cryptodev_globals.nb_devs; i++)
> > >>>>>>>>>> - if ((strcmp(cryptodev_globals.devs[i].data-
> >name,
> > >>>> name)
> > >>>>>>>>>> - == 0) &&
> > >>>>>>>>>> + if ((strncmp(cryptodev_globals.devs[i].data-
> >name,
> > >>>>>> name,
> > >>>>>>>>>> +
> RTE_CRYPTODEV_NAME_MAX_LEN)
> > >> consider using "strlen(name) + 1" instead of
> > >> RTE_CRYPTODEV_NAME_MAX_LEN.
> > >> This will not cause any ABI breakage in my opinion and and will
> > >> check till we get a null terminated string in both the strings.
> > >> What say?
> > > [Anoob] In that case, I'll restrict the patch to two places.
> > > Wherever strlen(name) is used, I'll make it
> > strlen(name)+1. I won't touch strcmp ones as that would work as is. Shall I
> prepare a v2?
> > I think it should be fine.
> >
> > Fiona,
> > Any comments?
> [Fiona] Good idea. That should be ok.
[Anoob] Another thought. If we are fine with doing strlen of input buffer, then using strcmp would also do. That way the usage also would be uniform in the file.
Thanks,
Anoob
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v5 1/3] doc: clean ABI/API policy guide
2019-01-31 17:46 4% ` Kevin Traynor
@ 2019-03-01 17:32 35% ` Ferruh Yigit
2019-03-01 17:32 17% ` [dpdk-dev] [PATCH v5 2/3] doc: make RTE_NEXT_ABI optional Ferruh Yigit
1 sibling, 1 reply; 200+ results
From: Ferruh Yigit @ 2019-03-01 17:32 UTC (permalink / raw)
To: dev, John McNamara, Marko Kovacevic
Cc: Neil Horman, Luca Boccassi, Kevin Traynor, Yongseok Koh
The original document written from the point of ABI versioning but later
additions make document confusing, convert document into a ABI/API
policy documentation and organize the document in subsections:
- ABI/API Deprecation
- Experimental APIs
- Library versioning
- ABI versioning
Aim to clarify confusion between deprecation versioned ABI and overall
ABI/API deprecation, also ABI versioning and Library versioning by
organizing the sections.
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
---
Cc: Luca Boccassi <bluca@debian.org>
Cc: Kevin Traynor <ktraynor@redhat.com>
Cc: Yongseok Koh <yskoh@mellanox.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
---
doc/guides/contributing/versioning.rst | 132 +++++++++++++------------
1 file changed, 71 insertions(+), 61 deletions(-)
diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index 18b031998..0bd7e6c44 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -1,33 +1,31 @@
.. SPDX-License-Identifier: BSD-3-Clause
Copyright 2018 The DPDK contributors
-Managing ABI updates
-====================
+DPDK ABI/API policy
+===================
Description
-----------
This document details some methods for handling ABI management in the DPDK.
-Note this document is not exhaustive, in that C library versioning is flexible
-allowing multiple methods to achieve various goals, but it will provide the user
-with some introductory methods
General Guidelines
------------------
#. Whenever possible, ABI should be preserved
-#. Libraries or APIs marked in ``experimental`` state may change without constraint.
+#. ABI/API may be changed with a deprecation process
+#. The modification of symbols can generally be managed with versioning
+#. Libraries or APIs marked in ``experimental`` state may change without constraint
#. New APIs will be marked as ``experimental`` for at least one release to allow
any issues found by users of the new API to be fixed quickly
#. The addition of symbols is generally not problematic
-#. The modification of symbols can generally be managed with versioning
#. The removal of symbols generally is an ABI break and requires bumping of the
LIBABIVER macro
#. Updates to the minimum hardware requirements, which drop support for hardware which
was previously supported, should be treated as an ABI change.
What is an ABI
---------------
+~~~~~~~~~~~~~~
An ABI (Application Binary Interface) is the set of runtime interfaces exposed
by a library. It is similar to an API (Application Programming Interface) but
@@ -39,9 +37,13 @@ Therefore, in the case of dynamic linking, it is critical that an ABI is
preserved, or (when modified), done in such a way that the application is unable
to behave improperly or in an unexpected fashion.
-The DPDK ABI policy
+
+ABI/API Deprecation
-------------------
+The DPDK ABI policy
+~~~~~~~~~~~~~~~~~~~
+
ABI versions are set at the time of major release labeling, and the ABI may
change multiple times, without warning, between the last release label and the
HEAD label of the git tree.
@@ -99,8 +101,36 @@ readability purposes should be avoided.
follow the relevant deprecation policy procedures as above: 3 acks and
announcement at least one release in advance.
+Examples of Deprecation Notices
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following are some examples of ABI deprecation notices which would be
+added to the Release Notes:
+
+* The Macro ``#RTE_FOO`` is deprecated and will be removed with version 2.0,
+ to be replaced with the inline function ``rte_foo()``.
+
+* The function ``rte_mbuf_grok()`` has been updated to include a new parameter
+ in version 2.0. Backwards compatibility will be maintained for this function
+ until the release of version 2.1
+
+* The members of ``struct rte_foo`` have been reorganized in release 2.0 for
+ performance reasons. Existing binary applications will have backwards
+ compatibility in release 2.0, while newly built binaries will need to
+ reference the new structure variant ``struct rte_foo2``. Compatibility will
+ be removed in release 2.2, and all applications will require updating and
+ rebuilding to the new structure at that time, which will be renamed to the
+ original ``struct rte_foo``.
+
+* Significant ABI changes are planned for the ``librte_dostuff`` library. The
+ upcoming release 2.0 will not contain these changes, but release 2.1 will,
+ and no backwards compatibility is planned due to the extensive nature of
+ these changes. Binaries using this library built prior to version 2.1 will
+ require updating and recompilation.
+
+
Experimental APIs
-~~~~~~~~~~~~~~~~~
+-----------------
APIs marked as ``experimental`` are not considered part of the ABI and may
change without warning at any time. Since changes to APIs are most likely
@@ -130,35 +160,38 @@ is not required. Though, an API should remain in experimental state for at least
one release. Thereafter, normal process of posting patch for review to mailing
list can be followed.
-Examples of Deprecation Notices
--------------------------------
-The following are some examples of ABI deprecation notices which would be
-added to the Release Notes:
+Library versioning
+------------------
-* The Macro ``#RTE_FOO`` is deprecated and will be removed with version 2.0,
- to be replaced with the inline function ``rte_foo()``.
+Downstreams might want to provide different DPDK releases at the same time to
+support multiple consumers of DPDK linked against older and newer sonames.
-* The function ``rte_mbuf_grok()`` has been updated to include a new parameter
- in version 2.0. Backwards compatibility will be maintained for this function
- until the release of version 2.1
+Also due to the interdependencies that DPDK libraries can have applications
+might end up with an executable space in which multiple versions of a library
+are mapped by ld.so.
-* The members of ``struct rte_foo`` have been reorganized in release 2.0 for
- performance reasons. Existing binary applications will have backwards
- compatibility in release 2.0, while newly built binaries will need to
- reference the new structure variant ``struct rte_foo2``. Compatibility will
- be removed in release 2.2, and all applications will require updating and
- rebuilding to the new structure at that time, which will be renamed to the
- original ``struct rte_foo``.
+Think of LibA that got an ABI bump and LibB that did not get an ABI bump but is
+depending on LibA.
-* Significant ABI changes are planned for the ``librte_dostuff`` library. The
- upcoming release 2.0 will not contain these changes, but release 2.1 will,
- and no backwards compatibility is planned due to the extensive nature of
- these changes. Binaries using this library built prior to version 2.1 will
- require updating and recompilation.
+.. note::
+
+ Application
+ \-> LibA.old
+ \-> LibB.new -> LibA.new
+
+That is a conflict which can be avoided by setting ``CONFIG_RTE_MAJOR_ABI``.
+If set, the value of ``CONFIG_RTE_MAJOR_ABI`` overwrites all - otherwise per
+library - versions defined in the libraries ``LIBABIVER``.
+An example might be ``CONFIG_RTE_MAJOR_ABI=16.11`` which will make all libraries
+``librte<?>.so.16.11`` instead of ``librte<?>.so.<LIBABIVER>``.
+
+
+ABI versioning
+--------------
Versioning Macros
------------------
+~~~~~~~~~~~~~~~~~
When a symbol is exported from a library to provide an API, it also provides a
calling convention (ABI) that is embodied in its name, return type and
@@ -186,36 +219,11 @@ The macros exported are:
fully qualified function ``p``, so that if a symbol becomes versioned, it
can still be mapped back to the public symbol name.
-Setting a Major ABI version
----------------------------
-
-Downstreams might want to provide different DPDK releases at the same time to
-support multiple consumers of DPDK linked against older and newer sonames.
-
-Also due to the interdependencies that DPDK libraries can have applications
-might end up with an executable space in which multiple versions of a library
-are mapped by ld.so.
-
-Think of LibA that got an ABI bump and LibB that did not get an ABI bump but is
-depending on LibA.
-
-.. note::
-
- Application
- \-> LibA.old
- \-> LibB.new -> LibA.new
-
-That is a conflict which can be avoided by setting ``CONFIG_RTE_MAJOR_ABI``.
-If set, the value of ``CONFIG_RTE_MAJOR_ABI`` overwrites all - otherwise per
-library - versions defined in the libraries ``LIBABIVER``.
-An example might be ``CONFIG_RTE_MAJOR_ABI=16.11`` which will make all libraries
-``librte<?>.so.16.11`` instead of ``librte<?>.so.<LIBABIVER>``.
-
Examples of ABI Macro use
--------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^
Updating a public API
-~~~~~~~~~~~~~~~~~~~~~
+_____________________
Assume we have a function as follows
@@ -425,7 +433,7 @@ and a new DPDK_2.1 version, used by future built applications.
Deprecating part of a public API
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+________________________________
Lets assume that you've done the above update, and after a few releases have
passed you decide you would like to retire the old version of the function.
@@ -483,7 +491,7 @@ possibly incompatible library version:
+LIBABIVER := 2
Deprecating an entire ABI version
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+_________________________________
While removing a symbol from and ABI may be useful, it is often more practical
to remove an entire version node at once. If a version node completely
@@ -532,6 +540,7 @@ Lastly, any VERSION_SYMBOL macros that point to the old version node should be
removed, taking care to keep, where need old code in place to support newer
versions of the symbol.
+
Running the ABI Validator
-------------------------
@@ -571,3 +580,4 @@ compile both tags) it will create compatibility reports in the
follows::
grep -lr Incompatible compat_reports/
+
--
2.20.1
^ permalink raw reply [relevance 35%]
* [dpdk-dev] [PATCH v5 2/3] doc: make RTE_NEXT_ABI optional
2019-03-01 17:32 35% ` [dpdk-dev] [PATCH v5 " Ferruh Yigit
@ 2019-03-01 17:32 17% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-03-01 17:32 UTC (permalink / raw)
To: dev, John McNamara, Marko Kovacevic
Cc: Neil Horman, Luca Boccassi, Kevin Traynor, Yongseok Koh
Initial process requires oncoming changes described in deprecation
notice should be implemented in a RTE_NEXT_ABI gated way.
This has been discussed in technical board, and since this can cause a
multiple #ifdef blocks in multiple locations of the code, can be
confusing specially for the modifications that requires data structure
changes. Anyway this was not happening in practice.
Making RTE_NEXT_ABI usage more optional based on techboard decision:
http://mails.dpdk.org/archives/dev/2019-January/123519.html
The intention with using RTE_NEXT_ABI was to provide more information
to the user about planned changes, and force developer to think more in
coding level. Since RTE_NEXT_ABI become optional, now the preferred way
to do this is, if possible, sending changes, described in deprecation
notice, as a separate patch and reference it in deprecation notice.
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
---
Cc: Luca Boccassi <bluca@debian.org>
Cc: Kevin Traynor <ktraynor@redhat.com>
Cc: Yongseok Koh <yskoh@mellanox.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
---
doc/guides/contributing/versioning.rst | 15 ++++++---------
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index 0bd7e6c44..2fcb8bafd 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -73,19 +73,16 @@ being provided. The requirements for doing so are:
interest" be sought for each deprecation, for example: from NIC vendors,
CPU vendors, end-users, etc.
-#. The changes (including an alternative map file) must be gated with
- the ``RTE_NEXT_ABI`` option, and provided with a deprecation notice at the
- same time.
- It will become the default ABI in the next release.
+#. The changes (including an alternative map file) can be included with
+ deprecation notice, in wrapped way by the ``RTE_NEXT_ABI`` option,
+ to provide more details about oncoming changes.
+ ``RTE_NEXT_ABI`` wrapper will be removed when it become the default ABI.
+ More preferred way to provide this information is sending the feature
+ as a separate patch and reference it in deprecation notice.
#. A full deprecation cycle, as explained above, must be made to offer
downstream consumers sufficient warning of the change.
-#. At the beginning of the next release cycle, every ``RTE_NEXT_ABI``
- conditions will be removed, the ``LIBABIVER`` variable in the makefile(s)
- where the ABI is changed will be incremented, and the map files will
- be updated.
-
Note that the above process for ABI deprecation should not be undertaken
lightly. ABI stability is extremely important for downstream consumers of the
DPDK, especially when distributed in shared object form. Every effort should
--
2.20.1
^ permalink raw reply [relevance 17%]
* [dpdk-dev] [PATCH] crypto/aesni_mb: support newer version library only
@ 2019-03-04 11:47 1% Fan Zhang
2019-03-04 14:47 0% ` Trahe, Fiona
0 siblings, 1 reply; 200+ results
From: Fan Zhang @ 2019-03-04 11:47 UTC (permalink / raw)
To: dev; +Cc: akhil.goyal, roy.fan.zhang, arkadiuszx.kusztal, fiona.trahe
As stated in 19.02 deprecation notice, this patch updates the
aesni_mb PMD to remove the support of older Intel-ipsec-mb
library version eariler than 0.52.
Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
---
Although the PMD dependency to the library is changed, the ABI/API
are not updated as the APIs to access the PMD remains intact. When
the user compile the PMD a error message "IPSec MB version >=
0.52" will be displayed to inform the user to update the library.
doc/guides/cryptodevs/aesni_mb.rst | 8 +-
doc/guides/rel_notes/deprecation.rst | 3 -
drivers/crypto/aesni_mb/Makefile | 21 +-
drivers/crypto/aesni_mb/aesni_mb_ops.h | 302 -----
drivers/crypto/aesni_mb/meson.build | 13 +-
drivers/crypto/aesni_mb/rte_aesni_mb_pmd_compat.c | 1313 --------------------
.../crypto/aesni_mb/rte_aesni_mb_pmd_ops_compat.c | 745 -----------
drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h | 37 -
8 files changed, 16 insertions(+), 2426 deletions(-)
delete mode 100644 drivers/crypto/aesni_mb/aesni_mb_ops.h
delete mode 100644 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_compat.c
delete mode 100644 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops_compat.c
diff --git a/doc/guides/cryptodevs/aesni_mb.rst b/doc/guides/cryptodevs/aesni_mb.rst
index 47f2ecc2f..d3567d279 100644
--- a/doc/guides/cryptodevs/aesni_mb.rst
+++ b/doc/guides/cryptodevs/aesni_mb.rst
@@ -57,10 +57,7 @@ Limitations
* Chained mbufs are not supported.
* Only in-place is currently supported (destination address is the same as source address).
-* RTE_CRYPTO_AEAD_AES_GCM only works properly when the multi-buffer library is
- 0.51.0 or newer.
-* RTE_CRYPTO_HASH_AES_GMAC is supported by library version v0.51 or later.
-* RTE_CRYPTO_HASH_SHA* is supported by library version v0.52 or later.
+* Only support Intel multi buffer library version 0.52 or later.
Installation
@@ -92,7 +89,8 @@ and the Multi-Buffer library version supported by them:
17.05 - 17.08 0.45 - 0.48
17.11 0.47 - 0.48
18.02 0.48
- 18.05+ 0.49+
+ 18.05 0.49
+ 19.02+ 0.52+
============== ============================
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 1b4fcb7e6..8adeaa552 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -72,6 +72,3 @@ Deprecation Notices
replace ``enum rte_meter_color`` in meter library in 19.05. This will help
to consolidate color definition, which is currently replicated in many places,
such as: rte_meter.h, rte_mtr.h, rte_tm.h.
-
-* crypto/aesni_mb: the minimum supported intel-ipsec-mb library version will be
- changed from 0.49.0 to 0.52.0.
diff --git a/drivers/crypto/aesni_mb/Makefile b/drivers/crypto/aesni_mb/Makefile
index 8d2024c9e..f3035340a 100644
--- a/drivers/crypto/aesni_mb/Makefile
+++ b/drivers/crypto/aesni_mb/Makefile
@@ -32,19 +32,14 @@ IMB_VERSION = $(shell grep -e "IMB_VERSION_STR" $(IMB_HDR) | cut -d'"' -f2)
IMB_VERSION_NUM = $(shell grep -e "IMB_VERSION_NUM" $(IMB_HDR) | cut -d' ' -f3)
ifeq ($(IMB_VERSION),)
- # files for older version of IMB
- SRCS-$(CONFIG_RTE_LIBRTE_PMD_AESNI_MB) += rte_aesni_mb_pmd_compat.c
- SRCS-$(CONFIG_RTE_LIBRTE_PMD_AESNI_MB) += rte_aesni_mb_pmd_ops_compat.c
-else
- ifeq ($(shell expr $(IMB_VERSION_NUM) \>= 0x3400), 1)
- # files for a new version of IMB
- SRCS-$(CONFIG_RTE_LIBRTE_PMD_AESNI_MB) += rte_aesni_mb_pmd.c
- SRCS-$(CONFIG_RTE_LIBRTE_PMD_AESNI_MB) += rte_aesni_mb_pmd_ops.c
- else
- # files for older version of IMB
- SRCS-$(CONFIG_RTE_LIBRTE_PMD_AESNI_MB) += rte_aesni_mb_pmd_compat.c
- SRCS-$(CONFIG_RTE_LIBRTE_PMD_AESNI_MB) += rte_aesni_mb_pmd_ops_compat.c
- endif
+$(error "IPSec_MB version >= 0.52 is required")
endif
+ifeq ($(shell expr $(IMB_VERSION_NUM) \< 0x3400), 1)
+$(error "IPSec_MB version >= 0.52 is required")
+endif
+
+SRCS-$(CONFIG_RTE_LIBRTE_PMD_AESNI_MB) += rte_aesni_mb_pmd.c
+SRCS-$(CONFIG_RTE_LIBRTE_PMD_AESNI_MB) += rte_aesni_mb_pmd_ops.c
+
include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/drivers/crypto/aesni_mb/aesni_mb_ops.h b/drivers/crypto/aesni_mb/aesni_mb_ops.h
deleted file mode 100644
index 575d6a5b8..000000000
--- a/drivers/crypto/aesni_mb/aesni_mb_ops.h
+++ /dev/null
@@ -1,302 +0,0 @@
-/* SPDX-License-Identifier: BSD-3-Clause
- * Copyright(c) 2015 Intel Corporation
- */
-
-#ifndef _AESNI_MB_OPS_H_
-#define _AESNI_MB_OPS_H_
-
-#ifndef LINUX
-#define LINUX
-#endif
-
-#include <intel-ipsec-mb.h>
-
-/*
- * IMB_VERSION_NUM macro was introduced in version Multi-buffer 0.50,
- * so if macro is not defined, it means that the version is 0.49.
- */
-#if !defined(IMB_VERSION_NUM)
-#define IMB_VERSION(a, b, c) (((a) << 16) + ((b) << 8) + (c))
-#define IMB_VERSION_NUM IMB_VERSION(0, 49, 0)
-#endif
-
-enum aesni_mb_vector_mode {
- RTE_AESNI_MB_NOT_SUPPORTED = 0,
- RTE_AESNI_MB_SSE,
- RTE_AESNI_MB_AVX,
- RTE_AESNI_MB_AVX2,
- RTE_AESNI_MB_AVX512
-};
-
-typedef void (*md5_one_block_t)(const void *data, void *digest);
-
-typedef void (*sha1_one_block_t)(const void *data, void *digest);
-typedef void (*sha224_one_block_t)(const void *data, void *digest);
-typedef void (*sha256_one_block_t)(const void *data, void *digest);
-typedef void (*sha384_one_block_t)(const void *data, void *digest);
-typedef void (*sha512_one_block_t)(const void *data, void *digest);
-
-typedef void (*aes_keyexp_128_t)
- (const void *key, void *enc_exp_keys, void *dec_exp_keys);
-typedef void (*aes_keyexp_192_t)
- (const void *key, void *enc_exp_keys, void *dec_exp_keys);
-typedef void (*aes_keyexp_256_t)
- (const void *key, void *enc_exp_keys, void *dec_exp_keys);
-typedef void (*aes_xcbc_expand_key_t)
- (const void *key, void *exp_k1, void *k2, void *k3);
-typedef void (*aes_cmac_sub_key_gen_t)
- (const void *exp_key, void *k2, void *k3);
-typedef void (*aes_cmac_keyexp_t)
- (const void *key, void *keyexp);
-typedef void (*aes_gcm_keyexp_t)
- (const void *key, struct gcm_key_data *keyexp);
-
-/** Multi-buffer library function pointer table */
-struct aesni_mb_op_fns {
- struct {
- init_mb_mgr_t init_mgr;
- /**< Initialise scheduler */
- get_next_job_t get_next;
- /**< Get next free job structure */
- submit_job_t submit;
- /**< Submit job to scheduler */
- get_completed_job_t get_completed_job;
- /**< Get completed job */
- flush_job_t flush_job;
- /**< flush jobs from manager */
- } job;
- /**< multi buffer manager functions */
-
- struct {
- struct {
- md5_one_block_t md5;
- /**< MD5 one block hash */
- sha1_one_block_t sha1;
- /**< SHA1 one block hash */
- sha224_one_block_t sha224;
- /**< SHA224 one block hash */
- sha256_one_block_t sha256;
- /**< SHA256 one block hash */
- sha384_one_block_t sha384;
- /**< SHA384 one block hash */
- sha512_one_block_t sha512;
- /**< SHA512 one block hash */
- } one_block;
- /**< one block hash functions */
-
- struct {
- aes_keyexp_128_t aes128;
- /**< AES128 key expansions */
- aes_keyexp_192_t aes192;
- /**< AES192 key expansions */
- aes_keyexp_256_t aes256;
- /**< AES256 key expansions */
- aes_xcbc_expand_key_t aes_xcbc;
- /**< AES XCBC key epansions */
- aes_cmac_sub_key_gen_t aes_cmac_subkey;
- /**< AES CMAC subkey expansions */
- aes_cmac_keyexp_t aes_cmac_expkey;
- /**< AES CMAC key expansions */
- aes_gcm_keyexp_t aes_gcm_128;
- /**< AES GCM 128 key expansions */
- aes_gcm_keyexp_t aes_gcm_192;
- /**< AES GCM 192 key expansions */
- aes_gcm_keyexp_t aes_gcm_256;
- /**< AES GCM 256 key expansions */
- } keyexp;
- /**< Key expansion functions */
-#if IMB_VERSION_NUM >= IMB_VERSION(0, 50, 0)
- struct {
- hash_fn_t sha1;
- hash_fn_t sha224;
- hash_fn_t sha256;
- hash_fn_t sha384;
- hash_fn_t sha512;
- } multi_block;
- /** multi block hash functions */
-#endif
- } aux;
- /**< Auxiliary functions */
-};
-
-
-static const struct aesni_mb_op_fns job_ops[] = {
- [RTE_AESNI_MB_NOT_SUPPORTED] = {
- .job = {
- NULL
- },
- .aux = {
- .one_block = {
- NULL
- },
- .keyexp = {
- NULL
- },
-#if IMB_VERSION_NUM >= IMB_VERSION(0, 50, 0)
- .multi_block = {
- NULL
- }
-#endif
-
- }
- },
- [RTE_AESNI_MB_SSE] = {
- .job = {
- init_mb_mgr_sse,
- get_next_job_sse,
- submit_job_sse,
- get_completed_job_sse,
- flush_job_sse
- },
- .aux = {
- .one_block = {
- md5_one_block_sse,
- sha1_one_block_sse,
- sha224_one_block_sse,
- sha256_one_block_sse,
- sha384_one_block_sse,
- sha512_one_block_sse
- },
- .keyexp = {
- aes_keyexp_128_sse,
- aes_keyexp_192_sse,
- aes_keyexp_256_sse,
- aes_xcbc_expand_key_sse,
- aes_cmac_subkey_gen_sse,
- aes_keyexp_128_enc_sse,
- aes_gcm_pre_128_sse,
- aes_gcm_pre_192_sse,
- aes_gcm_pre_256_sse
- },
-#if IMB_VERSION_NUM >= IMB_VERSION(0, 50, 0)
- .multi_block = {
- sha1_sse,
- sha224_sse,
- sha256_sse,
- sha384_sse,
- sha512_sse
- }
-#endif
- }
- },
- [RTE_AESNI_MB_AVX] = {
- .job = {
- init_mb_mgr_avx,
- get_next_job_avx,
- submit_job_avx,
- get_completed_job_avx,
- flush_job_avx
- },
- .aux = {
- .one_block = {
- md5_one_block_avx,
- sha1_one_block_avx,
- sha224_one_block_avx,
- sha256_one_block_avx,
- sha384_one_block_avx,
- sha512_one_block_avx
- },
- .keyexp = {
- aes_keyexp_128_avx,
- aes_keyexp_192_avx,
- aes_keyexp_256_avx,
- aes_xcbc_expand_key_avx,
- aes_cmac_subkey_gen_avx,
- aes_keyexp_128_enc_avx,
- aes_gcm_pre_128_avx_gen2,
- aes_gcm_pre_192_avx_gen2,
- aes_gcm_pre_256_avx_gen2
- },
-#if IMB_VERSION_NUM >= IMB_VERSION(0, 50, 0)
- .multi_block = {
- sha1_avx,
- sha224_avx,
- sha256_avx,
- sha384_avx,
- sha512_avx
- }
-#endif
- }
- },
- [RTE_AESNI_MB_AVX2] = {
- .job = {
- init_mb_mgr_avx2,
- get_next_job_avx2,
- submit_job_avx2,
- get_completed_job_avx2,
- flush_job_avx2
- },
- .aux = {
- .one_block = {
- md5_one_block_avx2,
- sha1_one_block_avx2,
- sha224_one_block_avx2,
- sha256_one_block_avx2,
- sha384_one_block_avx2,
- sha512_one_block_avx2
- },
- .keyexp = {
- aes_keyexp_128_avx2,
- aes_keyexp_192_avx2,
- aes_keyexp_256_avx2,
- aes_xcbc_expand_key_avx2,
- aes_cmac_subkey_gen_avx2,
- aes_keyexp_128_enc_avx2,
- aes_gcm_pre_128_avx_gen4,
- aes_gcm_pre_192_avx_gen4,
- aes_gcm_pre_256_avx_gen4
- },
-#if IMB_VERSION_NUM >= IMB_VERSION(0, 50, 0)
- .multi_block = {
- sha1_avx2,
- sha224_avx2,
- sha256_avx2,
- sha384_avx2,
- sha512_avx2
- }
-#endif
- }
- },
- [RTE_AESNI_MB_AVX512] = {
- .job = {
- init_mb_mgr_avx512,
- get_next_job_avx512,
- submit_job_avx512,
- get_completed_job_avx512,
- flush_job_avx512
- },
- .aux = {
- .one_block = {
- md5_one_block_avx512,
- sha1_one_block_avx512,
- sha224_one_block_avx512,
- sha256_one_block_avx512,
- sha384_one_block_avx512,
- sha512_one_block_avx512
- },
- .keyexp = {
- aes_keyexp_128_avx512,
- aes_keyexp_192_avx512,
- aes_keyexp_256_avx512,
- aes_xcbc_expand_key_avx512,
- aes_cmac_subkey_gen_avx512,
- aes_keyexp_128_enc_avx512,
- aes_gcm_pre_128_avx_gen4,
- aes_gcm_pre_192_avx_gen4,
- aes_gcm_pre_256_avx_gen4
- },
-#if IMB_VERSION_NUM >= IMB_VERSION(0, 50, 0)
- .multi_block = {
- sha1_avx512,
- sha224_avx512,
- sha256_avx512,
- sha384_avx512,
- sha512_avx512
- }
-#endif
- }
- }
-};
-
-
-#endif /* _AESNI_MB_OPS_H_ */
diff --git a/drivers/crypto/aesni_mb/meson.build b/drivers/crypto/aesni_mb/meson.build
index 6313c4bd0..fbc4878af 100644
--- a/drivers/crypto/aesni_mb/meson.build
+++ b/drivers/crypto/aesni_mb/meson.build
@@ -10,16 +10,13 @@ else
imb_arr = cc.get_define('IMB_VERSION_STR',
prefix : '#include<intel-ipsec-mb.h>').split('"')
- imb_ver =''.join(imb_arr)
+ imb_ver = ''.join(imb_arr)
- if imb_ver.version_compare('>=' + IPSec_MB_ver_0_52)
- message('Build for a new version of library IPSec_MB[' + imb_ver + ']')
- sources = files('rte_aesni_mb_pmd.c',
- 'rte_aesni_mb_pmd_ops.c')
+ if (imb_ver == '') or (imb_ver.version_compare('<' + IPSec_MB_ver_0_52))
+ message('IPSec_MB version >= 0.52 is required')
+ build = false
else
- sources = files('rte_aesni_mb_pmd_compat.c',
- 'rte_aesni_mb_pmd_ops_compat.c')
- message('Build for older version of library IPSec_MB[' + imb_ver + ']')
+ sources = files('rte_aesni_mb_pmd.c', 'rte_aesni_mb_pmd_ops.c')
endif
endif
diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_compat.c b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_compat.c
deleted file mode 100644
index 8020f68e3..000000000
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_compat.c
+++ /dev/null
@@ -1,1313 +0,0 @@
-/* SPDX-License-Identifier: BSD-3-Clause
- * Copyright(c) 2015-2017 Intel Corporation
- */
-
-#include <intel-ipsec-mb.h>
-
-#include <rte_common.h>
-#include <rte_hexdump.h>
-#include <rte_cryptodev.h>
-#include <rte_cryptodev_pmd.h>
-#include <rte_bus_vdev.h>
-#include <rte_malloc.h>
-#include <rte_cpuflags.h>
-
-#include "rte_aesni_mb_pmd_private.h"
-
-#define AES_CCM_DIGEST_MIN_LEN 4
-#define AES_CCM_DIGEST_MAX_LEN 16
-#define HMAC_MAX_BLOCK_SIZE 128
-static uint8_t cryptodev_driver_id;
-
-typedef void (*hash_one_block_t)(const void *data, void *digest);
-typedef void (*aes_keyexp_t)(const void *key, void *enc_exp_keys, void *dec_exp_keys);
-
-/**
- * Calculate the authentication pre-computes
- *
- * @param one_block_hash Function pointer to calculate digest on ipad/opad
- * @param ipad Inner pad output byte array
- * @param opad Outer pad output byte array
- * @param hkey Authentication key
- * @param hkey_len Authentication key length
- * @param blocksize Block size of selected hash algo
- */
-static void
-calculate_auth_precomputes(hash_one_block_t one_block_hash,
- uint8_t *ipad, uint8_t *opad,
- uint8_t *hkey, uint16_t hkey_len,
- uint16_t blocksize)
-{
- unsigned i, length;
-
- uint8_t ipad_buf[blocksize] __rte_aligned(16);
- uint8_t opad_buf[blocksize] __rte_aligned(16);
-
- /* Setup inner and outer pads */
- memset(ipad_buf, HMAC_IPAD_VALUE, blocksize);
- memset(opad_buf, HMAC_OPAD_VALUE, blocksize);
-
- /* XOR hash key with inner and outer pads */
- length = hkey_len > blocksize ? blocksize : hkey_len;
-
- for (i = 0; i < length; i++) {
- ipad_buf[i] ^= hkey[i];
- opad_buf[i] ^= hkey[i];
- }
-
- /* Compute partial hashes */
- (*one_block_hash)(ipad_buf, ipad);
- (*one_block_hash)(opad_buf, opad);
-
- /* Clean up stack */
- memset(ipad_buf, 0, blocksize);
- memset(opad_buf, 0, blocksize);
-}
-
-/** Get xform chain order */
-static enum aesni_mb_operation
-aesni_mb_get_chain_order(const struct rte_crypto_sym_xform *xform)
-{
- if (xform == NULL)
- return AESNI_MB_OP_NOT_SUPPORTED;
-
- if (xform->type == RTE_CRYPTO_SYM_XFORM_CIPHER) {
- if (xform->next == NULL)
- return AESNI_MB_OP_CIPHER_ONLY;
- if (xform->next->type == RTE_CRYPTO_SYM_XFORM_AUTH)
- return AESNI_MB_OP_CIPHER_HASH;
- }
-
- if (xform->type == RTE_CRYPTO_SYM_XFORM_AUTH) {
- if (xform->next == NULL)
- return AESNI_MB_OP_HASH_ONLY;
- if (xform->next->type == RTE_CRYPTO_SYM_XFORM_CIPHER)
- return AESNI_MB_OP_HASH_CIPHER;
- }
-
- if (xform->type == RTE_CRYPTO_SYM_XFORM_AEAD) {
- if (xform->aead.algo == RTE_CRYPTO_AEAD_AES_CCM ||
- xform->aead.algo == RTE_CRYPTO_AEAD_AES_GCM) {
- if (xform->aead.op == RTE_CRYPTO_AEAD_OP_ENCRYPT)
- return AESNI_MB_OP_AEAD_CIPHER_HASH;
- else
- return AESNI_MB_OP_AEAD_HASH_CIPHER;
- }
- }
-
- return AESNI_MB_OP_NOT_SUPPORTED;
-}
-
-/** Set session authentication parameters */
-static int
-aesni_mb_set_session_auth_parameters(const struct aesni_mb_op_fns *mb_ops,
- struct aesni_mb_session *sess,
- const struct rte_crypto_sym_xform *xform)
-{
- hash_one_block_t hash_oneblock_fn;
- unsigned int key_larger_block_size = 0;
- uint8_t hashed_key[HMAC_MAX_BLOCK_SIZE] = { 0 };
-
- if (xform == NULL) {
- sess->auth.algo = NULL_HASH;
- return 0;
- }
-
- if (xform->type != RTE_CRYPTO_SYM_XFORM_AUTH) {
- AESNI_MB_LOG(ERR, "Crypto xform struct not of type auth");
- return -1;
- }
-
- /* Set the request digest size */
- sess->auth.req_digest_len = xform->auth.digest_length;
-
- /* Select auth generate/verify */
- sess->auth.operation = xform->auth.op;
-
- /* Set Authentication Parameters */
- if (xform->auth.algo == RTE_CRYPTO_AUTH_AES_XCBC_MAC) {
- sess->auth.algo = AES_XCBC;
-
- uint16_t xcbc_mac_digest_len =
- get_truncated_digest_byte_length(AES_XCBC);
- if (sess->auth.req_digest_len != xcbc_mac_digest_len) {
- AESNI_MB_LOG(ERR, "Invalid digest size\n");
- return -EINVAL;
- }
- sess->auth.gen_digest_len = sess->auth.req_digest_len;
- (*mb_ops->aux.keyexp.aes_xcbc)(xform->auth.key.data,
- sess->auth.xcbc.k1_expanded,
- sess->auth.xcbc.k2, sess->auth.xcbc.k3);
- return 0;
- }
-
- if (xform->auth.algo == RTE_CRYPTO_AUTH_AES_CMAC) {
- sess->auth.algo = AES_CMAC;
-
- uint16_t cmac_digest_len = get_digest_byte_length(AES_CMAC);
-
- if (sess->auth.req_digest_len > cmac_digest_len) {
- AESNI_MB_LOG(ERR, "Invalid digest size\n");
- return -EINVAL;
- }
- /*
- * Multi-buffer lib supports digest sizes from 4 to 16 bytes
- * in version 0.50 and sizes of 12 and 16 bytes,
- * in version 0.49.
- * If size requested is different, generate the full digest
- * (16 bytes) in a temporary location and then memcpy
- * the requested number of bytes.
- */
-#if IMB_VERSION_NUM >= IMB_VERSION(0, 50, 0)
- if (sess->auth.req_digest_len < 4)
-#else
- uint16_t cmac_trunc_digest_len =
- get_truncated_digest_byte_length(AES_CMAC);
- if (sess->auth.req_digest_len != cmac_digest_len &&
- sess->auth.req_digest_len != cmac_trunc_digest_len)
-#endif
- sess->auth.gen_digest_len = cmac_digest_len;
- else
- sess->auth.gen_digest_len = sess->auth.req_digest_len;
- (*mb_ops->aux.keyexp.aes_cmac_expkey)(xform->auth.key.data,
- sess->auth.cmac.expkey);
-
- (*mb_ops->aux.keyexp.aes_cmac_subkey)(sess->auth.cmac.expkey,
- sess->auth.cmac.skey1, sess->auth.cmac.skey2);
- return 0;
- }
-
- if (xform->auth.algo == RTE_CRYPTO_AUTH_AES_GMAC) {
- if (xform->auth.op == RTE_CRYPTO_AUTH_OP_GENERATE) {
- sess->cipher.direction = ENCRYPT;
- sess->chain_order = CIPHER_HASH;
- } else
- sess->cipher.direction = DECRYPT;
-
- sess->auth.algo = AES_GMAC;
- /*
- * Multi-buffer lib supports 8, 12 and 16 bytes of digest.
- * If size requested is different, generate the full digest
- * (16 bytes) in a temporary location and then memcpy
- * the requested number of bytes.
- */
- if (sess->auth.req_digest_len != 16 &&
- sess->auth.req_digest_len != 12 &&
- sess->auth.req_digest_len != 8) {
- sess->auth.gen_digest_len = 16;
- } else {
- sess->auth.gen_digest_len = sess->auth.req_digest_len;
- }
- sess->iv.length = xform->auth.iv.length;
- sess->iv.offset = xform->auth.iv.offset;
-
- switch (xform->auth.key.length) {
- case AES_128_BYTES:
- sess->cipher.key_length_in_bytes = AES_128_BYTES;
- (mb_ops->aux.keyexp.aes_gcm_128)(xform->auth.key.data,
- &sess->cipher.gcm_key);
- break;
- case AES_192_BYTES:
- sess->cipher.key_length_in_bytes = AES_192_BYTES;
- (mb_ops->aux.keyexp.aes_gcm_192)(xform->auth.key.data,
- &sess->cipher.gcm_key);
- break;
- case AES_256_BYTES:
- sess->cipher.key_length_in_bytes = AES_256_BYTES;
- (mb_ops->aux.keyexp.aes_gcm_256)(xform->auth.key.data,
- &sess->cipher.gcm_key);
- break;
- default:
- RTE_LOG(ERR, PMD, "failed to parse test type\n");
- return -EINVAL;
- }
-
- return 0;
- }
-
- switch (xform->auth.algo) {
- case RTE_CRYPTO_AUTH_MD5_HMAC:
- sess->auth.algo = MD5;
- hash_oneblock_fn = mb_ops->aux.one_block.md5;
- break;
- case RTE_CRYPTO_AUTH_SHA1_HMAC:
- sess->auth.algo = SHA1;
- hash_oneblock_fn = mb_ops->aux.one_block.sha1;
-#if IMB_VERSION_NUM >= IMB_VERSION(0, 50, 0)
- if (xform->auth.key.length > get_auth_algo_blocksize(SHA1)) {
- mb_ops->aux.multi_block.sha1(
- xform->auth.key.data,
- xform->auth.key.length,
- hashed_key);
- key_larger_block_size = 1;
- }
-#endif
- break;
- case RTE_CRYPTO_AUTH_SHA224_HMAC:
- sess->auth.algo = SHA_224;
- hash_oneblock_fn = mb_ops->aux.one_block.sha224;
-#if IMB_VERSION_NUM >= IMB_VERSION(0, 50, 0)
- if (xform->auth.key.length > get_auth_algo_blocksize(SHA_224)) {
- mb_ops->aux.multi_block.sha224(
- xform->auth.key.data,
- xform->auth.key.length,
- hashed_key);
- key_larger_block_size = 1;
- }
-#endif
- break;
- case RTE_CRYPTO_AUTH_SHA256_HMAC:
- sess->auth.algo = SHA_256;
- hash_oneblock_fn = mb_ops->aux.one_block.sha256;
-#if IMB_VERSION_NUM >= IMB_VERSION(0, 50, 0)
- if (xform->auth.key.length > get_auth_algo_blocksize(SHA_256)) {
- mb_ops->aux.multi_block.sha256(
- xform->auth.key.data,
- xform->auth.key.length,
- hashed_key);
- key_larger_block_size = 1;
- }
-#endif
- break;
- case RTE_CRYPTO_AUTH_SHA384_HMAC:
- sess->auth.algo = SHA_384;
- hash_oneblock_fn = mb_ops->aux.one_block.sha384;
-#if IMB_VERSION_NUM >= IMB_VERSION(0, 50, 0)
- if (xform->auth.key.length > get_auth_algo_blocksize(SHA_384)) {
- mb_ops->aux.multi_block.sha384(
- xform->auth.key.data,
- xform->auth.key.length,
- hashed_key);
- key_larger_block_size = 1;
- }
-#endif
- break;
- case RTE_CRYPTO_AUTH_SHA512_HMAC:
- sess->auth.algo = SHA_512;
- hash_oneblock_fn = mb_ops->aux.one_block.sha512;
-#if IMB_VERSION_NUM >= IMB_VERSION(0, 50, 0)
- if (xform->auth.key.length > get_auth_algo_blocksize(SHA_512)) {
- mb_ops->aux.multi_block.sha512(
- xform->auth.key.data,
- xform->auth.key.length,
- hashed_key);
- key_larger_block_size = 1;
- }
-#endif
- break;
- default:
- AESNI_MB_LOG(ERR, "Unsupported authentication algorithm selection");
- return -ENOTSUP;
- }
- uint16_t trunc_digest_size =
- get_truncated_digest_byte_length(sess->auth.algo);
- uint16_t full_digest_size =
- get_digest_byte_length(sess->auth.algo);
-
-#if IMB_VERSION_NUM >= IMB_VERSION(0, 50, 0)
- if (sess->auth.req_digest_len > full_digest_size ||
- sess->auth.req_digest_len == 0) {
-#else
- if (sess->auth.req_digest_len != trunc_digest_size) {
-#endif
- AESNI_MB_LOG(ERR, "Invalid digest size\n");
- return -EINVAL;
- }
-
- if (sess->auth.req_digest_len != trunc_digest_size &&
- sess->auth.req_digest_len != full_digest_size)
- sess->auth.gen_digest_len = full_digest_size;
- else
- sess->auth.gen_digest_len = sess->auth.req_digest_len;
-
- /* Calculate Authentication precomputes */
- if (key_larger_block_size) {
- calculate_auth_precomputes(hash_oneblock_fn,
- sess->auth.pads.inner, sess->auth.pads.outer,
- hashed_key,
- xform->auth.key.length,
- get_auth_algo_blocksize(sess->auth.algo));
- } else {
- calculate_auth_precomputes(hash_oneblock_fn,
- sess->auth.pads.inner, sess->auth.pads.outer,
- xform->auth.key.data,
- xform->auth.key.length,
- get_auth_algo_blocksize(sess->auth.algo));
- }
-
- return 0;
-}
-
-/** Set session cipher parameters */
-static int
-aesni_mb_set_session_cipher_parameters(const struct aesni_mb_op_fns *mb_ops,
- struct aesni_mb_session *sess,
- const struct rte_crypto_sym_xform *xform)
-{
- uint8_t is_aes = 0;
- uint8_t is_3DES = 0;
- aes_keyexp_t aes_keyexp_fn;
-
- if (xform == NULL) {
- sess->cipher.mode = NULL_CIPHER;
- return 0;
- }
-
- if (xform->type != RTE_CRYPTO_SYM_XFORM_CIPHER) {
- AESNI_MB_LOG(ERR, "Crypto xform struct not of type cipher");
- return -EINVAL;
- }
-
- /* Select cipher direction */
- switch (xform->cipher.op) {
- case RTE_CRYPTO_CIPHER_OP_ENCRYPT:
- sess->cipher.direction = ENCRYPT;
- break;
- case RTE_CRYPTO_CIPHER_OP_DECRYPT:
- sess->cipher.direction = DECRYPT;
- break;
- default:
- AESNI_MB_LOG(ERR, "Invalid cipher operation parameter");
- return -EINVAL;
- }
-
- /* Select cipher mode */
- switch (xform->cipher.algo) {
- case RTE_CRYPTO_CIPHER_AES_CBC:
- sess->cipher.mode = CBC;
- is_aes = 1;
- break;
- case RTE_CRYPTO_CIPHER_AES_CTR:
- sess->cipher.mode = CNTR;
- is_aes = 1;
- break;
- case RTE_CRYPTO_CIPHER_AES_DOCSISBPI:
- sess->cipher.mode = DOCSIS_SEC_BPI;
- is_aes = 1;
- break;
- case RTE_CRYPTO_CIPHER_DES_CBC:
- sess->cipher.mode = DES;
- break;
- case RTE_CRYPTO_CIPHER_DES_DOCSISBPI:
- sess->cipher.mode = DOCSIS_DES;
- break;
- case RTE_CRYPTO_CIPHER_3DES_CBC:
- sess->cipher.mode = DES3;
- is_3DES = 1;
- break;
- default:
- AESNI_MB_LOG(ERR, "Unsupported cipher mode parameter");
- return -ENOTSUP;
- }
-
- /* Set IV parameters */
- sess->iv.offset = xform->cipher.iv.offset;
- sess->iv.length = xform->cipher.iv.length;
-
- /* Check key length and choose key expansion function for AES */
- if (is_aes) {
- switch (xform->cipher.key.length) {
- case AES_128_BYTES:
- sess->cipher.key_length_in_bytes = AES_128_BYTES;
- aes_keyexp_fn = mb_ops->aux.keyexp.aes128;
- break;
- case AES_192_BYTES:
- sess->cipher.key_length_in_bytes = AES_192_BYTES;
- aes_keyexp_fn = mb_ops->aux.keyexp.aes192;
- break;
- case AES_256_BYTES:
- sess->cipher.key_length_in_bytes = AES_256_BYTES;
- aes_keyexp_fn = mb_ops->aux.keyexp.aes256;
- break;
- default:
- AESNI_MB_LOG(ERR, "Invalid cipher key length");
- return -EINVAL;
- }
-
- /* Expanded cipher keys */
- (*aes_keyexp_fn)(xform->cipher.key.data,
- sess->cipher.expanded_aes_keys.encode,
- sess->cipher.expanded_aes_keys.decode);
-
- } else if (is_3DES) {
- uint64_t *keys[3] = {sess->cipher.exp_3des_keys.key[0],
- sess->cipher.exp_3des_keys.key[1],
- sess->cipher.exp_3des_keys.key[2]};
-
- switch (xform->cipher.key.length) {
- case 24:
- des_key_schedule(keys[0], xform->cipher.key.data);
- des_key_schedule(keys[1], xform->cipher.key.data+8);
- des_key_schedule(keys[2], xform->cipher.key.data+16);
-
- /* Initialize keys - 24 bytes: [K1-K2-K3] */
- sess->cipher.exp_3des_keys.ks_ptr[0] = keys[0];
- sess->cipher.exp_3des_keys.ks_ptr[1] = keys[1];
- sess->cipher.exp_3des_keys.ks_ptr[2] = keys[2];
- break;
- case 16:
- des_key_schedule(keys[0], xform->cipher.key.data);
- des_key_schedule(keys[1], xform->cipher.key.data+8);
-
- /* Initialize keys - 16 bytes: [K1=K1,K2=K2,K3=K1] */
- sess->cipher.exp_3des_keys.ks_ptr[0] = keys[0];
- sess->cipher.exp_3des_keys.ks_ptr[1] = keys[1];
- sess->cipher.exp_3des_keys.ks_ptr[2] = keys[0];
- break;
- case 8:
- des_key_schedule(keys[0], xform->cipher.key.data);
-
- /* Initialize keys - 8 bytes: [K1 = K2 = K3] */
- sess->cipher.exp_3des_keys.ks_ptr[0] = keys[0];
- sess->cipher.exp_3des_keys.ks_ptr[1] = keys[0];
- sess->cipher.exp_3des_keys.ks_ptr[2] = keys[0];
- break;
- default:
- AESNI_MB_LOG(ERR, "Invalid cipher key length");
- return -EINVAL;
- }
-
-#if IMB_VERSION_NUM >= IMB_VERSION(0, 50, 0)
- sess->cipher.key_length_in_bytes = 24;
-#else
- sess->cipher.key_length_in_bytes = 8;
-#endif
- } else {
- if (xform->cipher.key.length != 8) {
- AESNI_MB_LOG(ERR, "Invalid cipher key length");
- return -EINVAL;
- }
- sess->cipher.key_length_in_bytes = 8;
-
- des_key_schedule((uint64_t *)sess->cipher.expanded_aes_keys.encode,
- xform->cipher.key.data);
- des_key_schedule((uint64_t *)sess->cipher.expanded_aes_keys.decode,
- xform->cipher.key.data);
- }
-
- return 0;
-}
-
-static int
-aesni_mb_set_session_aead_parameters(const struct aesni_mb_op_fns *mb_ops,
- struct aesni_mb_session *sess,
- const struct rte_crypto_sym_xform *xform)
-{
- union {
- aes_keyexp_t aes_keyexp_fn;
- aes_gcm_keyexp_t aes_gcm_keyexp_fn;
- } keyexp;
-
- switch (xform->aead.op) {
- case RTE_CRYPTO_AEAD_OP_ENCRYPT:
- sess->cipher.direction = ENCRYPT;
- sess->auth.operation = RTE_CRYPTO_AUTH_OP_GENERATE;
- break;
- case RTE_CRYPTO_AEAD_OP_DECRYPT:
- sess->cipher.direction = DECRYPT;
- sess->auth.operation = RTE_CRYPTO_AUTH_OP_VERIFY;
- break;
- default:
- AESNI_MB_LOG(ERR, "Invalid aead operation parameter");
- return -EINVAL;
- }
-
- switch (xform->aead.algo) {
- case RTE_CRYPTO_AEAD_AES_CCM:
- sess->cipher.mode = CCM;
- sess->auth.algo = AES_CCM;
-
- /* Check key length and choose key expansion function for AES */
- switch (xform->aead.key.length) {
- case AES_128_BYTES:
- sess->cipher.key_length_in_bytes = AES_128_BYTES;
- keyexp.aes_keyexp_fn = mb_ops->aux.keyexp.aes128;
- break;
- default:
- AESNI_MB_LOG(ERR, "Invalid cipher key length");
- return -EINVAL;
- }
-
- /* Expanded cipher keys */
- (*keyexp.aes_keyexp_fn)(xform->aead.key.data,
- sess->cipher.expanded_aes_keys.encode,
- sess->cipher.expanded_aes_keys.decode);
- break;
-
- case RTE_CRYPTO_AEAD_AES_GCM:
- sess->cipher.mode = GCM;
- sess->auth.algo = AES_GMAC;
-
- switch (xform->aead.key.length) {
- case AES_128_BYTES:
- sess->cipher.key_length_in_bytes = AES_128_BYTES;
- keyexp.aes_gcm_keyexp_fn =
- mb_ops->aux.keyexp.aes_gcm_128;
- break;
- case AES_192_BYTES:
- sess->cipher.key_length_in_bytes = AES_192_BYTES;
- keyexp.aes_gcm_keyexp_fn =
- mb_ops->aux.keyexp.aes_gcm_192;
- break;
- case AES_256_BYTES:
- sess->cipher.key_length_in_bytes = AES_256_BYTES;
- keyexp.aes_gcm_keyexp_fn =
- mb_ops->aux.keyexp.aes_gcm_256;
- break;
- default:
- AESNI_MB_LOG(ERR, "Invalid cipher key length");
- return -EINVAL;
- }
-
- (keyexp.aes_gcm_keyexp_fn)(xform->aead.key.data,
- &sess->cipher.gcm_key);
- break;
-
- default:
- AESNI_MB_LOG(ERR, "Unsupported aead mode parameter");
- return -ENOTSUP;
- }
-
- /* Set IV parameters */
- sess->iv.offset = xform->aead.iv.offset;
- sess->iv.length = xform->aead.iv.length;
-
- sess->auth.req_digest_len = xform->aead.digest_length;
- /* CCM digests must be between 4 and 16 and an even number */
- if (sess->auth.req_digest_len < AES_CCM_DIGEST_MIN_LEN ||
- sess->auth.req_digest_len > AES_CCM_DIGEST_MAX_LEN ||
- (sess->auth.req_digest_len & 1) == 1) {
- AESNI_MB_LOG(ERR, "Invalid digest size\n");
- return -EINVAL;
- }
- sess->auth.gen_digest_len = sess->auth.req_digest_len;
-
- return 0;
-}
-
-/** Parse crypto xform chain and set private session parameters */
-int
-aesni_mb_set_session_parameters(const struct aesni_mb_op_fns *mb_ops,
- struct aesni_mb_session *sess,
- const struct rte_crypto_sym_xform *xform)
-{
- const struct rte_crypto_sym_xform *auth_xform = NULL;
- const struct rte_crypto_sym_xform *cipher_xform = NULL;
- const struct rte_crypto_sym_xform *aead_xform = NULL;
- int ret;
-
- /* Select Crypto operation - hash then cipher / cipher then hash */
- switch (aesni_mb_get_chain_order(xform)) {
- case AESNI_MB_OP_HASH_CIPHER:
- sess->chain_order = HASH_CIPHER;
- auth_xform = xform;
- cipher_xform = xform->next;
- break;
- case AESNI_MB_OP_CIPHER_HASH:
- sess->chain_order = CIPHER_HASH;
- auth_xform = xform->next;
- cipher_xform = xform;
- break;
- case AESNI_MB_OP_HASH_ONLY:
- sess->chain_order = HASH_CIPHER;
- auth_xform = xform;
- cipher_xform = NULL;
- break;
- case AESNI_MB_OP_CIPHER_ONLY:
- /*
- * Multi buffer library operates only at two modes,
- * CIPHER_HASH and HASH_CIPHER. When doing ciphering only,
- * chain order depends on cipher operation: encryption is always
- * the first operation and decryption the last one.
- */
- if (xform->cipher.op == RTE_CRYPTO_CIPHER_OP_ENCRYPT)
- sess->chain_order = CIPHER_HASH;
- else
- sess->chain_order = HASH_CIPHER;
- auth_xform = NULL;
- cipher_xform = xform;
- break;
- case AESNI_MB_OP_AEAD_CIPHER_HASH:
- sess->chain_order = CIPHER_HASH;
- sess->aead.aad_len = xform->aead.aad_length;
- aead_xform = xform;
- break;
- case AESNI_MB_OP_AEAD_HASH_CIPHER:
- sess->chain_order = HASH_CIPHER;
- sess->aead.aad_len = xform->aead.aad_length;
- aead_xform = xform;
- break;
- case AESNI_MB_OP_NOT_SUPPORTED:
- default:
- AESNI_MB_LOG(ERR, "Unsupported operation chain order parameter");
- return -ENOTSUP;
- }
-
- /* Default IV length = 0 */
- sess->iv.length = 0;
-
- ret = aesni_mb_set_session_auth_parameters(mb_ops, sess, auth_xform);
- if (ret != 0) {
- AESNI_MB_LOG(ERR, "Invalid/unsupported authentication parameters");
- return ret;
- }
-
- ret = aesni_mb_set_session_cipher_parameters(mb_ops, sess,
- cipher_xform);
- if (ret != 0) {
- AESNI_MB_LOG(ERR, "Invalid/unsupported cipher parameters");
- return ret;
- }
-
- if (aead_xform) {
- ret = aesni_mb_set_session_aead_parameters(mb_ops, sess,
- aead_xform);
- if (ret != 0) {
- AESNI_MB_LOG(ERR, "Invalid/unsupported aead parameters");
- return ret;
- }
- }
-
- return 0;
-}
-
-/**
- * burst enqueue, place crypto operations on ingress queue for processing.
- *
- * @param __qp Queue Pair to process
- * @param ops Crypto operations for processing
- * @param nb_ops Number of crypto operations for processing
- *
- * @return
- * - Number of crypto operations enqueued
- */
-static uint16_t
-aesni_mb_pmd_enqueue_burst(void *__qp, struct rte_crypto_op **ops,
- uint16_t nb_ops)
-{
- struct aesni_mb_qp *qp = __qp;
-
- unsigned int nb_enqueued;
-
- nb_enqueued = rte_ring_enqueue_burst(qp->ingress_queue,
- (void **)ops, nb_ops, NULL);
-
- qp->stats.enqueued_count += nb_enqueued;
-
- return nb_enqueued;
-}
-
-/** Get multi buffer session */
-static inline struct aesni_mb_session *
-get_session(struct aesni_mb_qp *qp, struct rte_crypto_op *op)
-{
- struct aesni_mb_session *sess = NULL;
-
- if (op->sess_type == RTE_CRYPTO_OP_WITH_SESSION) {
- if (likely(op->sym->session != NULL))
- sess = (struct aesni_mb_session *)
- get_sym_session_private_data(
- op->sym->session,
- cryptodev_driver_id);
- } else {
- void *_sess = NULL;
- void *_sess_private_data = NULL;
-
- if (rte_mempool_get(qp->sess_mp, (void **)&_sess))
- return NULL;
-
- if (rte_mempool_get(qp->sess_mp_priv, (void **)&_sess_private_data))
- return NULL;
-
- sess = (struct aesni_mb_session *)_sess_private_data;
-
- if (unlikely(aesni_mb_set_session_parameters(qp->op_fns,
- sess, op->sym->xform) != 0)) {
- rte_mempool_put(qp->sess_mp, _sess);
- rte_mempool_put(qp->sess_mp_priv, _sess_private_data);
- sess = NULL;
- }
- op->sym->session = (struct rte_cryptodev_sym_session *)_sess;
- set_sym_session_private_data(op->sym->session,
- cryptodev_driver_id, _sess_private_data);
- }
-
- if (unlikely(sess == NULL))
- op->status = RTE_CRYPTO_OP_STATUS_INVALID_SESSION;
-
- return sess;
-}
-
-/**
- * Process a crypto operation and complete a JOB_AES_HMAC job structure for
- * submission to the multi buffer library for processing.
- *
- * @param qp queue pair
- * @param job JOB_AES_HMAC structure to fill
- * @param m mbuf to process
- *
- * @return
- * - Completed JOB_AES_HMAC structure pointer on success
- * - NULL pointer if completion of JOB_AES_HMAC structure isn't possible
- */
-static inline int
-set_mb_job_params(JOB_AES_HMAC *job, struct aesni_mb_qp *qp,
- struct rte_crypto_op *op, uint8_t *digest_idx)
-{
- struct rte_mbuf *m_src = op->sym->m_src, *m_dst;
- struct aesni_mb_session *session;
- uint16_t m_offset = 0;
-
- session = get_session(qp, op);
- if (session == NULL) {
- op->status = RTE_CRYPTO_OP_STATUS_INVALID_SESSION;
- return -1;
- }
-
- /* Set crypto operation */
- job->chain_order = session->chain_order;
-
- /* Set cipher parameters */
- job->cipher_direction = session->cipher.direction;
- job->cipher_mode = session->cipher.mode;
-
- job->aes_key_len_in_bytes = session->cipher.key_length_in_bytes;
-
- /* Set authentication parameters */
- job->hash_alg = session->auth.algo;
-
- switch (job->hash_alg) {
- case AES_XCBC:
- job->u.XCBC._k1_expanded = session->auth.xcbc.k1_expanded;
- job->u.XCBC._k2 = session->auth.xcbc.k2;
- job->u.XCBC._k3 = session->auth.xcbc.k3;
-
- job->aes_enc_key_expanded =
- session->cipher.expanded_aes_keys.encode;
- job->aes_dec_key_expanded =
- session->cipher.expanded_aes_keys.decode;
- break;
-
- case AES_CCM:
- job->u.CCM.aad = op->sym->aead.aad.data + 18;
- job->u.CCM.aad_len_in_bytes = session->aead.aad_len;
- job->aes_enc_key_expanded =
- session->cipher.expanded_aes_keys.encode;
- job->aes_dec_key_expanded =
- session->cipher.expanded_aes_keys.decode;
- break;
-
- case AES_CMAC:
- job->u.CMAC._key_expanded = session->auth.cmac.expkey;
- job->u.CMAC._skey1 = session->auth.cmac.skey1;
- job->u.CMAC._skey2 = session->auth.cmac.skey2;
- job->aes_enc_key_expanded =
- session->cipher.expanded_aes_keys.encode;
- job->aes_dec_key_expanded =
- session->cipher.expanded_aes_keys.decode;
- break;
-
- case AES_GMAC:
- if (session->cipher.mode == GCM) {
- job->u.GCM.aad = op->sym->aead.aad.data;
- job->u.GCM.aad_len_in_bytes = session->aead.aad_len;
- } else {
- /* For GMAC */
- job->u.GCM.aad = rte_pktmbuf_mtod_offset(m_src,
- uint8_t *, op->sym->auth.data.offset);
- job->u.GCM.aad_len_in_bytes = op->sym->auth.data.length;
- job->cipher_mode = GCM;
- }
- job->aes_enc_key_expanded = &session->cipher.gcm_key;
- job->aes_dec_key_expanded = &session->cipher.gcm_key;
- break;
-
- default:
- job->u.HMAC._hashed_auth_key_xor_ipad = session->auth.pads.inner;
- job->u.HMAC._hashed_auth_key_xor_opad = session->auth.pads.outer;
-
- if (job->cipher_mode == DES3) {
- job->aes_enc_key_expanded =
- session->cipher.exp_3des_keys.ks_ptr;
- job->aes_dec_key_expanded =
- session->cipher.exp_3des_keys.ks_ptr;
- } else {
- job->aes_enc_key_expanded =
- session->cipher.expanded_aes_keys.encode;
- job->aes_dec_key_expanded =
- session->cipher.expanded_aes_keys.decode;
- }
- }
-
- /* Mutable crypto operation parameters */
- if (op->sym->m_dst) {
- m_src = m_dst = op->sym->m_dst;
-
- /* append space for output data to mbuf */
- char *odata = rte_pktmbuf_append(m_dst,
- rte_pktmbuf_data_len(op->sym->m_src));
- if (odata == NULL) {
- AESNI_MB_LOG(ERR, "failed to allocate space in destination "
- "mbuf for source data");
- op->status = RTE_CRYPTO_OP_STATUS_ERROR;
- return -1;
- }
-
- memcpy(odata, rte_pktmbuf_mtod(op->sym->m_src, void*),
- rte_pktmbuf_data_len(op->sym->m_src));
- } else {
- m_dst = m_src;
- if (job->hash_alg == AES_CCM || (job->hash_alg == AES_GMAC &&
- session->cipher.mode == GCM))
- m_offset = op->sym->aead.data.offset;
- else
- m_offset = op->sym->cipher.data.offset;
- }
-
- /* Set digest output location */
- if (job->hash_alg != NULL_HASH &&
- session->auth.operation == RTE_CRYPTO_AUTH_OP_VERIFY) {
- job->auth_tag_output = qp->temp_digests[*digest_idx];
- *digest_idx = (*digest_idx + 1) % MAX_JOBS;
- } else {
- if (job->hash_alg == AES_CCM || (job->hash_alg == AES_GMAC &&
- session->cipher.mode == GCM))
- job->auth_tag_output = op->sym->aead.digest.data;
- else
- job->auth_tag_output = op->sym->auth.digest.data;
-
- if (session->auth.req_digest_len != session->auth.gen_digest_len) {
- job->auth_tag_output = qp->temp_digests[*digest_idx];
- *digest_idx = (*digest_idx + 1) % MAX_JOBS;
- }
- }
- /*
- * Multi-buffer library current only support returning a truncated
- * digest length as specified in the relevant IPsec RFCs
- */
-
- /* Set digest length */
- job->auth_tag_output_len_in_bytes = session->auth.gen_digest_len;
-
- /* Set IV parameters */
- job->iv_len_in_bytes = session->iv.length;
-
- /* Data Parameter */
- job->src = rte_pktmbuf_mtod(m_src, uint8_t *);
- job->dst = rte_pktmbuf_mtod_offset(m_dst, uint8_t *, m_offset);
-
- switch (job->hash_alg) {
- case AES_CCM:
- job->cipher_start_src_offset_in_bytes =
- op->sym->aead.data.offset;
- job->msg_len_to_cipher_in_bytes = op->sym->aead.data.length;
- job->hash_start_src_offset_in_bytes = op->sym->aead.data.offset;
- job->msg_len_to_hash_in_bytes = op->sym->aead.data.length;
-
- job->iv = rte_crypto_op_ctod_offset(op, uint8_t *,
- session->iv.offset + 1);
- break;
-
- case AES_GMAC:
- if (session->cipher.mode == GCM) {
- job->cipher_start_src_offset_in_bytes =
- op->sym->aead.data.offset;
- job->hash_start_src_offset_in_bytes =
- op->sym->aead.data.offset;
- job->msg_len_to_cipher_in_bytes =
- op->sym->aead.data.length;
- job->msg_len_to_hash_in_bytes =
- op->sym->aead.data.length;
- } else {
- job->cipher_start_src_offset_in_bytes =
- op->sym->auth.data.offset;
- job->hash_start_src_offset_in_bytes =
- op->sym->auth.data.offset;
- job->msg_len_to_cipher_in_bytes = 0;
- job->msg_len_to_hash_in_bytes = 0;
- }
- job->iv = rte_crypto_op_ctod_offset(op, uint8_t *,
- session->iv.offset);
-
- break;
-
- default:
- job->cipher_start_src_offset_in_bytes =
- op->sym->cipher.data.offset;
- job->msg_len_to_cipher_in_bytes = op->sym->cipher.data.length;
-
- job->hash_start_src_offset_in_bytes = op->sym->auth.data.offset;
- job->msg_len_to_hash_in_bytes = op->sym->auth.data.length;
-
- job->iv = rte_crypto_op_ctod_offset(op, uint8_t *,
- session->iv.offset);
- }
-
- /* Set user data to be crypto operation data struct */
- job->user_data = op;
-
- return 0;
-}
-
-static inline void
-verify_digest(JOB_AES_HMAC *job, void *digest, uint16_t len, uint8_t *status)
-{
- if (memcmp(job->auth_tag_output, digest, len) != 0)
- *status = RTE_CRYPTO_OP_STATUS_AUTH_FAILED;
-}
-
-static inline void
-generate_digest(JOB_AES_HMAC *job, struct rte_crypto_op *op,
- struct aesni_mb_session *sess)
-{
- /* No extra copy neeed */
- if (likely(sess->auth.req_digest_len == sess->auth.gen_digest_len))
- return;
-
- /*
- * This can only happen for HMAC, so only digest
- * for authentication algos is required
- */
- memcpy(op->sym->auth.digest.data, job->auth_tag_output,
- sess->auth.req_digest_len);
-}
-
-/**
- * Process a completed job and return rte_mbuf which job processed
- *
- * @param qp Queue Pair to process
- * @param job JOB_AES_HMAC job to process
- *
- * @return
- * - Returns processed crypto operation.
- * - Returns NULL on invalid job
- */
-static inline struct rte_crypto_op *
-post_process_mb_job(struct aesni_mb_qp *qp, JOB_AES_HMAC *job)
-{
- struct rte_crypto_op *op = (struct rte_crypto_op *)job->user_data;
- struct aesni_mb_session *sess = get_sym_session_private_data(
- op->sym->session,
- cryptodev_driver_id);
-
- if (likely(op->status == RTE_CRYPTO_OP_STATUS_NOT_PROCESSED)) {
- switch (job->status) {
- case STS_COMPLETED:
- op->status = RTE_CRYPTO_OP_STATUS_SUCCESS;
-
- if (job->hash_alg == NULL_HASH)
- break;
-
- if (sess->auth.operation == RTE_CRYPTO_AUTH_OP_VERIFY) {
- if (job->hash_alg == AES_CCM ||
- (job->hash_alg == AES_GMAC &&
- sess->cipher.mode == GCM))
- verify_digest(job,
- op->sym->aead.digest.data,
- sess->auth.req_digest_len,
- &op->status);
- else
- verify_digest(job,
- op->sym->auth.digest.data,
- sess->auth.req_digest_len,
- &op->status);
- } else
- generate_digest(job, op, sess);
- break;
- default:
- op->status = RTE_CRYPTO_OP_STATUS_ERROR;
- }
- }
-
- /* Free session if a session-less crypto op */
- if (op->sess_type == RTE_CRYPTO_OP_SESSIONLESS) {
- memset(sess, 0, sizeof(struct aesni_mb_session));
- memset(op->sym->session, 0,
- rte_cryptodev_sym_get_existing_header_session_size(
- op->sym->session));
- rte_mempool_put(qp->sess_mp_priv, sess);
- rte_mempool_put(qp->sess_mp, op->sym->session);
- op->sym->session = NULL;
- }
-
- return op;
-}
-
-/**
- * Process a completed JOB_AES_HMAC job and keep processing jobs until
- * get_completed_job return NULL
- *
- * @param qp Queue Pair to process
- * @param job JOB_AES_HMAC job
- *
- * @return
- * - Number of processed jobs
- */
-static unsigned
-handle_completed_jobs(struct aesni_mb_qp *qp, JOB_AES_HMAC *job,
- struct rte_crypto_op **ops, uint16_t nb_ops)
-{
- struct rte_crypto_op *op = NULL;
- unsigned processed_jobs = 0;
-
- while (job != NULL) {
- op = post_process_mb_job(qp, job);
-
- if (op) {
- ops[processed_jobs++] = op;
- qp->stats.dequeued_count++;
- } else {
- qp->stats.dequeue_err_count++;
- break;
- }
- if (processed_jobs == nb_ops)
- break;
-
- job = (*qp->op_fns->job.get_completed_job)(qp->mb_mgr);
- }
-
- return processed_jobs;
-}
-
-static inline uint16_t
-flush_mb_mgr(struct aesni_mb_qp *qp, struct rte_crypto_op **ops,
- uint16_t nb_ops)
-{
- int processed_ops = 0;
-
- /* Flush the remaining jobs */
- JOB_AES_HMAC *job = (*qp->op_fns->job.flush_job)(qp->mb_mgr);
-
- if (job)
- processed_ops += handle_completed_jobs(qp, job,
- &ops[processed_ops], nb_ops - processed_ops);
-
- return processed_ops;
-}
-
-static inline JOB_AES_HMAC *
-set_job_null_op(JOB_AES_HMAC *job, struct rte_crypto_op *op)
-{
- job->chain_order = HASH_CIPHER;
- job->cipher_mode = NULL_CIPHER;
- job->hash_alg = NULL_HASH;
- job->cipher_direction = DECRYPT;
-
- /* Set user data to be crypto operation data struct */
- job->user_data = op;
-
- return job;
-}
-
-static uint16_t
-aesni_mb_pmd_dequeue_burst(void *queue_pair, struct rte_crypto_op **ops,
- uint16_t nb_ops)
-{
- struct aesni_mb_qp *qp = queue_pair;
-
- struct rte_crypto_op *op;
- JOB_AES_HMAC *job;
-
- int retval, processed_jobs = 0;
-
- if (unlikely(nb_ops == 0))
- return 0;
-
- uint8_t digest_idx = qp->digest_idx;
- do {
- /* Get next free mb job struct from mb manager */
- job = (*qp->op_fns->job.get_next)(qp->mb_mgr);
- if (unlikely(job == NULL)) {
- /* if no free mb job structs we need to flush mb_mgr */
- processed_jobs += flush_mb_mgr(qp,
- &ops[processed_jobs],
- nb_ops - processed_jobs);
-
- if (nb_ops == processed_jobs)
- break;
-
- job = (*qp->op_fns->job.get_next)(qp->mb_mgr);
- }
-
- /*
- * Get next operation to process from ingress queue.
- * There is no need to return the job to the MB_MGR
- * if there are no more operations to process, since the MB_MGR
- * can use that pointer again in next get_next calls.
- */
- retval = rte_ring_dequeue(qp->ingress_queue, (void **)&op);
- if (retval < 0)
- break;
-
- retval = set_mb_job_params(job, qp, op, &digest_idx);
- if (unlikely(retval != 0)) {
- qp->stats.dequeue_err_count++;
- set_job_null_op(job, op);
- }
-
- /* Submit job to multi-buffer for processing */
- job = (*qp->op_fns->job.submit)(qp->mb_mgr);
-
- /*
- * If submit returns a processed job then handle it,
- * before submitting subsequent jobs
- */
- if (job)
- processed_jobs += handle_completed_jobs(qp, job,
- &ops[processed_jobs],
- nb_ops - processed_jobs);
-
- } while (processed_jobs < nb_ops);
-
- qp->digest_idx = digest_idx;
-
- if (processed_jobs < 1)
- processed_jobs += flush_mb_mgr(qp,
- &ops[processed_jobs],
- nb_ops - processed_jobs);
-
- return processed_jobs;
-}
-
-static int cryptodev_aesni_mb_remove(struct rte_vdev_device *vdev);
-
-static int
-cryptodev_aesni_mb_create(const char *name,
- struct rte_vdev_device *vdev,
- struct rte_cryptodev_pmd_init_params *init_params)
-{
- struct rte_cryptodev *dev;
- struct aesni_mb_private *internals;
- enum aesni_mb_vector_mode vector_mode;
-
- /* Check CPU for support for AES instruction set */
- if (!rte_cpu_get_flag_enabled(RTE_CPUFLAG_AES)) {
- AESNI_MB_LOG(ERR, "AES instructions not supported by CPU");
- return -EFAULT;
- }
-
- dev = rte_cryptodev_pmd_create(name, &vdev->device, init_params);
- if (dev == NULL) {
- AESNI_MB_LOG(ERR, "failed to create cryptodev vdev");
- return -ENODEV;
- }
-
- /* Check CPU for supported vector instruction set */
- if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX512F))
- vector_mode = RTE_AESNI_MB_AVX512;
- else if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX2))
- vector_mode = RTE_AESNI_MB_AVX2;
- else if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_AVX))
- vector_mode = RTE_AESNI_MB_AVX;
- else
- vector_mode = RTE_AESNI_MB_SSE;
-
- dev->driver_id = cryptodev_driver_id;
- dev->dev_ops = rte_aesni_mb_pmd_ops;
-
- /* register rx/tx burst functions for data path */
- dev->dequeue_burst = aesni_mb_pmd_dequeue_burst;
- dev->enqueue_burst = aesni_mb_pmd_enqueue_burst;
-
- dev->feature_flags = RTE_CRYPTODEV_FF_SYMMETRIC_CRYPTO |
- RTE_CRYPTODEV_FF_SYM_OPERATION_CHAINING |
- RTE_CRYPTODEV_FF_CPU_AESNI;
-
- switch (vector_mode) {
- case RTE_AESNI_MB_SSE:
- dev->feature_flags |= RTE_CRYPTODEV_FF_CPU_SSE;
- break;
- case RTE_AESNI_MB_AVX:
- dev->feature_flags |= RTE_CRYPTODEV_FF_CPU_AVX;
- break;
- case RTE_AESNI_MB_AVX2:
- dev->feature_flags |= RTE_CRYPTODEV_FF_CPU_AVX2;
- break;
- case RTE_AESNI_MB_AVX512:
- dev->feature_flags |= RTE_CRYPTODEV_FF_CPU_AVX512;
- break;
- default:
- break;
- }
-
- /* Set vector instructions mode supported */
- internals = dev->data->dev_private;
-
- internals->vector_mode = vector_mode;
- internals->max_nb_queue_pairs = init_params->max_nb_queue_pairs;
-
-#if IMB_VERSION_NUM >= IMB_VERSION(0, 50, 0)
- AESNI_MB_LOG(INFO, "IPSec Multi-buffer library version used: %s\n",
- imb_get_version_str());
-#else
- AESNI_MB_LOG(INFO, "IPSec Multi-buffer library version used: 0.49.0\n");
-#endif
-
- return 0;
-}
-
-static int
-cryptodev_aesni_mb_probe(struct rte_vdev_device *vdev)
-{
- struct rte_cryptodev_pmd_init_params init_params = {
- "",
- sizeof(struct aesni_mb_private),
- rte_socket_id(),
- RTE_CRYPTODEV_PMD_DEFAULT_MAX_NB_QUEUE_PAIRS
- };
- const char *name, *args;
- int retval;
-
- name = rte_vdev_device_name(vdev);
- if (name == NULL)
- return -EINVAL;
-
- args = rte_vdev_device_args(vdev);
-
- retval = rte_cryptodev_pmd_parse_input_args(&init_params, args);
- if (retval) {
- AESNI_MB_LOG(ERR, "Failed to parse initialisation arguments[%s]",
- args);
- return -EINVAL;
- }
-
- return cryptodev_aesni_mb_create(name, vdev, &init_params);
-}
-
-static int
-cryptodev_aesni_mb_remove(struct rte_vdev_device *vdev)
-{
- struct rte_cryptodev *cryptodev;
- const char *name;
-
- name = rte_vdev_device_name(vdev);
- if (name == NULL)
- return -EINVAL;
-
- cryptodev = rte_cryptodev_pmd_get_named_dev(name);
- if (cryptodev == NULL)
- return -ENODEV;
-
- return rte_cryptodev_pmd_destroy(cryptodev);
-}
-
-static struct rte_vdev_driver cryptodev_aesni_mb_pmd_drv = {
- .probe = cryptodev_aesni_mb_probe,
- .remove = cryptodev_aesni_mb_remove
-};
-
-static struct cryptodev_driver aesni_mb_crypto_drv;
-
-RTE_PMD_REGISTER_VDEV(CRYPTODEV_NAME_AESNI_MB_PMD, cryptodev_aesni_mb_pmd_drv);
-RTE_PMD_REGISTER_ALIAS(CRYPTODEV_NAME_AESNI_MB_PMD, cryptodev_aesni_mb_pmd);
-RTE_PMD_REGISTER_PARAM_STRING(CRYPTODEV_NAME_AESNI_MB_PMD,
- "max_nb_queue_pairs=<int> "
- "socket_id=<int>");
-RTE_PMD_REGISTER_CRYPTO_DRIVER(aesni_mb_crypto_drv,
- cryptodev_aesni_mb_pmd_drv.driver,
- cryptodev_driver_id);
-
-RTE_INIT(aesni_mb_init_log)
-{
- aesni_mb_logtype_driver = rte_log_register("pmd.crypto.aesni_mb");
-}
diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops_compat.c b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops_compat.c
deleted file mode 100644
index 79a38b25e..000000000
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops_compat.c
+++ /dev/null
@@ -1,745 +0,0 @@
-/* SPDX-License-Identifier: BSD-3-Clause
- * Copyright(c) 2015-2017 Intel Corporation
- */
-
-#include <string.h>
-
-#include <rte_common.h>
-#include <rte_malloc.h>
-#include <rte_cryptodev_pmd.h>
-
-#include "rte_aesni_mb_pmd_private.h"
-
-
-static const struct rte_cryptodev_capabilities aesni_mb_pmd_capabilities[] = {
- { /* MD5 HMAC */
- .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
- {.sym = {
- .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH,
- {.auth = {
- .algo = RTE_CRYPTO_AUTH_MD5_HMAC,
- .block_size = 64,
- .key_size = {
- .min = 1,
- .max = 64,
- .increment = 1
- },
- .digest_size = {
-#if IMB_VERSION_NUM >= IMB_VERSION(0, 50, 0)
- .min = 1,
- .max = 16,
- .increment = 1
-#else
- .min = 12,
- .max = 12,
- .increment = 0
-#endif
- },
- .iv_size = { 0 }
- }, }
- }, }
- },
- { /* SHA1 HMAC */
- .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
- {.sym = {
- .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH,
- {.auth = {
- .algo = RTE_CRYPTO_AUTH_SHA1_HMAC,
- .block_size = 64,
- .key_size = {
- .min = 1,
-#if IMB_VERSION_NUM >= IMB_VERSION(0, 50, 0)
- .max = 65535,
-#else
- .max = 64,
-#endif
- .increment = 1
- },
- .digest_size = {
-#if IMB_VERSION_NUM >= IMB_VERSION(0, 50, 0)
- .min = 1,
- .max = 20,
- .increment = 1
-#else
- .min = 12,
- .max = 12,
- .increment = 0
-#endif
- },
- .iv_size = { 0 }
- }, }
- }, }
- },
- { /* SHA224 HMAC */
- .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
- {.sym = {
- .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH,
- {.auth = {
- .algo = RTE_CRYPTO_AUTH_SHA224_HMAC,
- .block_size = 64,
- .key_size = {
- .min = 1,
-#if IMB_VERSION_NUM >= IMB_VERSION(0, 50, 0)
- .max = 65535,
-#else
- .max = 64,
-#endif
- .increment = 1
- },
- .digest_size = {
-#if IMB_VERSION_NUM >= IMB_VERSION(0, 50, 0)
- .min = 1,
- .max = 28,
- .increment = 1
-#else
- .min = 14,
- .max = 14,
- .increment = 0
-#endif
- },
- .iv_size = { 0 }
- }, }
- }, }
- },
- { /* SHA256 HMAC */
- .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
- {.sym = {
- .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH,
- {.auth = {
- .algo = RTE_CRYPTO_AUTH_SHA256_HMAC,
- .block_size = 64,
- .key_size = {
- .min = 1,
-#if IMB_VERSION_NUM >= IMB_VERSION(0, 50, 0)
- .max = 65535,
-#else
- .max = 64,
-#endif
- .increment = 1
- },
- .digest_size = {
-#if IMB_VERSION_NUM >= IMB_VERSION(0, 50, 0)
- .min = 1,
- .max = 32,
- .increment = 1
-#else
- .min = 16,
- .max = 16,
- .increment = 0
-#endif
- },
- .iv_size = { 0 }
- }, }
- }, }
- },
- { /* SHA384 HMAC */
- .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
- {.sym = {
- .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH,
- {.auth = {
- .algo = RTE_CRYPTO_AUTH_SHA384_HMAC,
- .block_size = 128,
- .key_size = {
- .min = 1,
-#if IMB_VERSION_NUM >= IMB_VERSION(0, 50, 0)
- .max = 65535,
-#else
- .max = 128,
-#endif
- .increment = 1
- },
- .digest_size = {
-#if IMB_VERSION_NUM >= IMB_VERSION(0, 50, 0)
- .min = 1,
- .max = 48,
- .increment = 1
-#else
- .min = 24,
- .max = 24,
- .increment = 0
-#endif
- },
- .iv_size = { 0 }
- }, }
- }, }
- },
- { /* SHA512 HMAC */
- .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
- {.sym = {
- .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH,
- {.auth = {
- .algo = RTE_CRYPTO_AUTH_SHA512_HMAC,
- .block_size = 128,
- .key_size = {
- .min = 1,
-#if IMB_VERSION_NUM >= IMB_VERSION(0, 50, 0)
- .max = 65535,
-#else
- .max = 128,
-#endif
- .increment = 1
- },
- .digest_size = {
-#if IMB_VERSION_NUM >= IMB_VERSION(0, 50, 0)
- .min = 1,
- .max = 64,
- .increment = 1
-#else
- .min = 32,
- .max = 32,
- .increment = 0
-#endif
- },
- .iv_size = { 0 }
- }, }
- }, }
- },
- { /* AES XCBC HMAC */
- .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
- {.sym = {
- .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH,
- {.auth = {
- .algo = RTE_CRYPTO_AUTH_AES_XCBC_MAC,
- .block_size = 16,
- .key_size = {
- .min = 16,
- .max = 16,
- .increment = 0
- },
- .digest_size = {
- .min = 12,
- .max = 12,
- .increment = 0
- },
- .iv_size = { 0 }
- }, }
- }, }
- },
- { /* AES CBC */
- .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
- {.sym = {
- .xform_type = RTE_CRYPTO_SYM_XFORM_CIPHER,
- {.cipher = {
- .algo = RTE_CRYPTO_CIPHER_AES_CBC,
- .block_size = 16,
- .key_size = {
- .min = 16,
- .max = 32,
- .increment = 8
- },
- .iv_size = {
- .min = 16,
- .max = 16,
- .increment = 0
- }
- }, }
- }, }
- },
- { /* AES CTR */
- .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
- {.sym = {
- .xform_type = RTE_CRYPTO_SYM_XFORM_CIPHER,
- {.cipher = {
- .algo = RTE_CRYPTO_CIPHER_AES_CTR,
- .block_size = 16,
- .key_size = {
- .min = 16,
- .max = 32,
- .increment = 8
- },
- .iv_size = {
- .min = 12,
- .max = 16,
- .increment = 4
- }
- }, }
- }, }
- },
- { /* AES DOCSIS BPI */
- .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
- {.sym = {
- .xform_type = RTE_CRYPTO_SYM_XFORM_CIPHER,
- {.cipher = {
- .algo = RTE_CRYPTO_CIPHER_AES_DOCSISBPI,
- .block_size = 16,
- .key_size = {
- .min = 16,
- .max = 16,
- .increment = 0
- },
- .iv_size = {
- .min = 16,
- .max = 16,
- .increment = 0
- }
- }, }
- }, }
- },
- { /* DES CBC */
- .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
- {.sym = {
- .xform_type = RTE_CRYPTO_SYM_XFORM_CIPHER,
- {.cipher = {
- .algo = RTE_CRYPTO_CIPHER_DES_CBC,
- .block_size = 8,
- .key_size = {
- .min = 8,
- .max = 8,
- .increment = 0
- },
- .iv_size = {
- .min = 8,
- .max = 8,
- .increment = 0
- }
- }, }
- }, }
- },
- { /* 3DES CBC */
- .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
- {.sym = {
- .xform_type = RTE_CRYPTO_SYM_XFORM_CIPHER,
- {.cipher = {
- .algo = RTE_CRYPTO_CIPHER_3DES_CBC,
- .block_size = 8,
- .key_size = {
- .min = 8,
- .max = 24,
- .increment = 8
- },
- .iv_size = {
- .min = 8,
- .max = 8,
- .increment = 0
- }
- }, }
- }, }
- },
- { /* DES DOCSIS BPI */
- .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
- {.sym = {
- .xform_type = RTE_CRYPTO_SYM_XFORM_CIPHER,
- {.cipher = {
- .algo = RTE_CRYPTO_CIPHER_DES_DOCSISBPI,
- .block_size = 8,
- .key_size = {
- .min = 8,
- .max = 8,
- .increment = 0
- },
- .iv_size = {
- .min = 8,
- .max = 8,
- .increment = 0
- }
- }, }
- }, }
- },
- { /* AES CCM */
- .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
- {.sym = {
- .xform_type = RTE_CRYPTO_SYM_XFORM_AEAD,
- {.aead = {
- .algo = RTE_CRYPTO_AEAD_AES_CCM,
- .block_size = 16,
- .key_size = {
- .min = 16,
- .max = 16,
- .increment = 0
- },
- .digest_size = {
- .min = 4,
- .max = 16,
- .increment = 2
- },
- .aad_size = {
- .min = 0,
- .max = 46,
- .increment = 1
- },
- .iv_size = {
- .min = 7,
- .max = 13,
- .increment = 1
- },
- }, }
- }, }
- },
- { /* AES CMAC */
- .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
- {.sym = {
- .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH,
- {.auth = {
- .algo = RTE_CRYPTO_AUTH_AES_CMAC,
- .block_size = 16,
- .key_size = {
- .min = 16,
- .max = 16,
- .increment = 0
- },
- .digest_size = {
- .min = 1,
- .max = 16,
- .increment = 1
- },
- .iv_size = { 0 }
- }, }
- }, }
- },
- { /* AES GCM */
- .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
- {.sym = {
- .xform_type = RTE_CRYPTO_SYM_XFORM_AEAD,
- {.aead = {
- .algo = RTE_CRYPTO_AEAD_AES_GCM,
- .block_size = 16,
- .key_size = {
- .min = 16,
- .max = 32,
- .increment = 8
- },
- .digest_size = {
- .min = 8,
- .max = 16,
- .increment = 4
- },
- .aad_size = {
- .min = 0,
- .max = 65535,
- .increment = 1
- },
- .iv_size = {
- .min = 12,
- .max = 12,
- .increment = 0
- }
- }, }
- }, }
- },
- { /* AES GMAC (AUTH) */
- .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
- {.sym = {
- .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH,
- {.auth = {
- .algo = RTE_CRYPTO_AUTH_AES_GMAC,
- .block_size = 16,
- .key_size = {
- .min = 16,
- .max = 32,
- .increment = 8
- },
- .digest_size = {
- .min = 8,
- .max = 16,
- .increment = 4
- },
- .iv_size = {
- .min = 12,
- .max = 12,
- .increment = 0
- }
- }, }
- }, }
- },
- RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST()
-};
-
-
-/** Configure device */
-static int
-aesni_mb_pmd_config(__rte_unused struct rte_cryptodev *dev,
- __rte_unused struct rte_cryptodev_config *config)
-{
- return 0;
-}
-
-/** Start device */
-static int
-aesni_mb_pmd_start(__rte_unused struct rte_cryptodev *dev)
-{
- return 0;
-}
-
-/** Stop device */
-static void
-aesni_mb_pmd_stop(__rte_unused struct rte_cryptodev *dev)
-{
-}
-
-/** Close device */
-static int
-aesni_mb_pmd_close(__rte_unused struct rte_cryptodev *dev)
-{
- return 0;
-}
-
-
-/** Get device statistics */
-static void
-aesni_mb_pmd_stats_get(struct rte_cryptodev *dev,
- struct rte_cryptodev_stats *stats)
-{
- int qp_id;
-
- for (qp_id = 0; qp_id < dev->data->nb_queue_pairs; qp_id++) {
- struct aesni_mb_qp *qp = dev->data->queue_pairs[qp_id];
-
- stats->enqueued_count += qp->stats.enqueued_count;
- stats->dequeued_count += qp->stats.dequeued_count;
-
- stats->enqueue_err_count += qp->stats.enqueue_err_count;
- stats->dequeue_err_count += qp->stats.dequeue_err_count;
- }
-}
-
-/** Reset device statistics */
-static void
-aesni_mb_pmd_stats_reset(struct rte_cryptodev *dev)
-{
- int qp_id;
-
- for (qp_id = 0; qp_id < dev->data->nb_queue_pairs; qp_id++) {
- struct aesni_mb_qp *qp = dev->data->queue_pairs[qp_id];
-
- memset(&qp->stats, 0, sizeof(qp->stats));
- }
-}
-
-
-/** Get device info */
-static void
-aesni_mb_pmd_info_get(struct rte_cryptodev *dev,
- struct rte_cryptodev_info *dev_info)
-{
- struct aesni_mb_private *internals = dev->data->dev_private;
-
- if (dev_info != NULL) {
- dev_info->driver_id = dev->driver_id;
- dev_info->feature_flags = dev->feature_flags;
- dev_info->capabilities = aesni_mb_pmd_capabilities;
- dev_info->max_nb_queue_pairs = internals->max_nb_queue_pairs;
- /* No limit of number of sessions */
- dev_info->sym.max_nb_sessions = 0;
- }
-}
-
-/** Release queue pair */
-static int
-aesni_mb_pmd_qp_release(struct rte_cryptodev *dev, uint16_t qp_id)
-{
- struct aesni_mb_qp *qp = dev->data->queue_pairs[qp_id];
- struct rte_ring *r = NULL;
-
- if (qp != NULL) {
- r = rte_ring_lookup(qp->name);
- if (r)
- rte_ring_free(r);
- if (qp->mb_mgr)
- free_mb_mgr(qp->mb_mgr);
- rte_free(qp);
- dev->data->queue_pairs[qp_id] = NULL;
- }
- return 0;
-}
-
-/** set a unique name for the queue pair based on it's name, dev_id and qp_id */
-static int
-aesni_mb_pmd_qp_set_unique_name(struct rte_cryptodev *dev,
- struct aesni_mb_qp *qp)
-{
- unsigned n = snprintf(qp->name, sizeof(qp->name),
- "aesni_mb_pmd_%u_qp_%u",
- dev->data->dev_id, qp->id);
-
- if (n >= sizeof(qp->name))
- return -1;
-
- return 0;
-}
-
-/** Create a ring to place processed operations on */
-static struct rte_ring *
-aesni_mb_pmd_qp_create_processed_ops_ring(struct aesni_mb_qp *qp,
- unsigned int ring_size, int socket_id)
-{
- struct rte_ring *r;
- char ring_name[RTE_CRYPTODEV_NAME_MAX_LEN];
-
- unsigned int n = snprintf(ring_name, sizeof(ring_name), "%s", qp->name);
-
- if (n >= sizeof(ring_name))
- return NULL;
-
- r = rte_ring_lookup(ring_name);
- if (r) {
- if (rte_ring_get_size(r) >= ring_size) {
- AESNI_MB_LOG(INFO, "Reusing existing ring %s for processed ops",
- ring_name);
- return r;
- }
-
- AESNI_MB_LOG(ERR, "Unable to reuse existing ring %s for processed ops",
- ring_name);
- return NULL;
- }
-
- return rte_ring_create(ring_name, ring_size, socket_id,
- RING_F_SP_ENQ | RING_F_SC_DEQ);
-}
-
-/** Setup a queue pair */
-static int
-aesni_mb_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
- const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id)
-{
- struct aesni_mb_qp *qp = NULL;
- struct aesni_mb_private *internals = dev->data->dev_private;
- int ret = -1;
-
- /* Free memory prior to re-allocation if needed. */
- if (dev->data->queue_pairs[qp_id] != NULL)
- aesni_mb_pmd_qp_release(dev, qp_id);
-
- /* Allocate the queue pair data structure. */
- qp = rte_zmalloc_socket("AES-NI PMD Queue Pair", sizeof(*qp),
- RTE_CACHE_LINE_SIZE, socket_id);
- if (qp == NULL)
- return -ENOMEM;
-
- qp->id = qp_id;
- dev->data->queue_pairs[qp_id] = qp;
-
- if (aesni_mb_pmd_qp_set_unique_name(dev, qp))
- goto qp_setup_cleanup;
-
-
- qp->mb_mgr = alloc_mb_mgr(0);
- if (qp->mb_mgr == NULL) {
- ret = -ENOMEM;
- goto qp_setup_cleanup;
- }
-
- qp->op_fns = &job_ops[internals->vector_mode];
-
- qp->ingress_queue = aesni_mb_pmd_qp_create_processed_ops_ring(qp,
- qp_conf->nb_descriptors, socket_id);
- if (qp->ingress_queue == NULL) {
- ret = -1;
- goto qp_setup_cleanup;
- }
-
- qp->sess_mp = qp_conf->mp_session;
- qp->sess_mp_priv = qp_conf->mp_session_private;
-
- memset(&qp->stats, 0, sizeof(qp->stats));
-
- char mp_name[RTE_MEMPOOL_NAMESIZE];
-
- snprintf(mp_name, RTE_MEMPOOL_NAMESIZE,
- "digest_mp_%u_%u", dev->data->dev_id, qp_id);
-
- /* Initialise multi-buffer manager */
- (*qp->op_fns->job.init_mgr)(qp->mb_mgr);
- return 0;
-
-qp_setup_cleanup:
- if (qp) {
- if (qp->mb_mgr == NULL)
- free_mb_mgr(qp->mb_mgr);
- rte_free(qp);
- }
-
- return ret;
-}
-
-/** Return the number of allocated queue pairs */
-static uint32_t
-aesni_mb_pmd_qp_count(struct rte_cryptodev *dev)
-{
- return dev->data->nb_queue_pairs;
-}
-
-/** Returns the size of the aesni multi-buffer session structure */
-static unsigned
-aesni_mb_pmd_sym_session_get_size(struct rte_cryptodev *dev __rte_unused)
-{
- return sizeof(struct aesni_mb_session);
-}
-
-/** Configure a aesni multi-buffer session from a crypto xform chain */
-static int
-aesni_mb_pmd_sym_session_configure(struct rte_cryptodev *dev,
- struct rte_crypto_sym_xform *xform,
- struct rte_cryptodev_sym_session *sess,
- struct rte_mempool *mempool)
-{
- void *sess_private_data;
- struct aesni_mb_private *internals = dev->data->dev_private;
- int ret;
-
- if (unlikely(sess == NULL)) {
- AESNI_MB_LOG(ERR, "invalid session struct");
- return -EINVAL;
- }
-
- if (rte_mempool_get(mempool, &sess_private_data)) {
- AESNI_MB_LOG(ERR,
- "Couldn't get object from session mempool");
- return -ENOMEM;
- }
-
- ret = aesni_mb_set_session_parameters(&job_ops[internals->vector_mode],
- sess_private_data, xform);
- if (ret != 0) {
- AESNI_MB_LOG(ERR, "failed configure session parameters");
-
- /* Return session to mempool */
- rte_mempool_put(mempool, sess_private_data);
- return ret;
- }
-
- set_sym_session_private_data(sess, dev->driver_id,
- sess_private_data);
-
- return 0;
-}
-
-/** Clear the memory of session so it doesn't leave key material behind */
-static void
-aesni_mb_pmd_sym_session_clear(struct rte_cryptodev *dev,
- struct rte_cryptodev_sym_session *sess)
-{
- uint8_t index = dev->driver_id;
- void *sess_priv = get_sym_session_private_data(sess, index);
-
- /* Zero out the whole structure */
- if (sess_priv) {
- memset(sess_priv, 0, sizeof(struct aesni_mb_session));
- struct rte_mempool *sess_mp = rte_mempool_from_obj(sess_priv);
- set_sym_session_private_data(sess, index, NULL);
- rte_mempool_put(sess_mp, sess_priv);
- }
-}
-
-struct rte_cryptodev_ops aesni_mb_pmd_ops = {
- .dev_configure = aesni_mb_pmd_config,
- .dev_start = aesni_mb_pmd_start,
- .dev_stop = aesni_mb_pmd_stop,
- .dev_close = aesni_mb_pmd_close,
-
- .stats_get = aesni_mb_pmd_stats_get,
- .stats_reset = aesni_mb_pmd_stats_reset,
-
- .dev_infos_get = aesni_mb_pmd_info_get,
-
- .queue_pair_setup = aesni_mb_pmd_qp_setup,
- .queue_pair_release = aesni_mb_pmd_qp_release,
- .queue_pair_count = aesni_mb_pmd_qp_count,
-
- .sym_session_get_size = aesni_mb_pmd_sym_session_get_size,
- .sym_session_configure = aesni_mb_pmd_sym_session_configure,
- .sym_session_clear = aesni_mb_pmd_sym_session_clear
-};
-
-struct rte_cryptodev_ops *rte_aesni_mb_pmd_ops = &aesni_mb_pmd_ops;
diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h
index 61f419dda..4d439360f 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h
@@ -7,21 +7,6 @@
#include <intel-ipsec-mb.h>
-
-/*
- * IMB_VERSION_NUM macro was introduced in version Multi-buffer 0.50,
- * so if macro is not defined, it means that the version is 0.49.
- */
-#if !defined(IMB_VERSION_NUM)
-#define IMB_VERSION(a, b, c) (((a) << 16) + ((b) << 8) + (c))
-#define IMB_VERSION_NUM IMB_VERSION(0, 49, 0)
-#endif
-
-#if IMB_VERSION_NUM < IMB_VERSION(0, 52, 0)
-#include "aesni_mb_ops.h"
-#endif
-
-#if IMB_VERSION_NUM >= IMB_VERSION(0, 52, 0)
enum aesni_mb_vector_mode {
RTE_AESNI_MB_NOT_SUPPORTED = 0,
RTE_AESNI_MB_SSE,
@@ -29,8 +14,6 @@ enum aesni_mb_vector_mode {
RTE_AESNI_MB_AVX2,
RTE_AESNI_MB_AVX512
};
-#endif
-
#define CRYPTODEV_NAME_AESNI_MB_PMD crypto_aesni_mb
/**< AES-NI Multi buffer PMD device name */
@@ -109,13 +92,11 @@ static const unsigned auth_digest_byte_lengths[] = {
[AES_CMAC] = 16,
[AES_GMAC] = 12,
[NULL_HASH] = 0,
-#if IMB_VERSION_NUM >= IMB_VERSION(0, 52, 0)
[PLAIN_SHA1] = 20,
[PLAIN_SHA_224] = 28,
[PLAIN_SHA_256] = 32,
[PLAIN_SHA_384] = 48,
[PLAIN_SHA_512] = 64
-#endif
/**< Vector mode dependent pointer table of the multi-buffer APIs */
};
@@ -149,10 +130,8 @@ struct aesni_mb_private {
/**< CPU vector instruction set mode */
unsigned max_nb_queue_pairs;
/**< Max number of queue pairs supported by device */
-#if IMB_VERSION_NUM >= IMB_VERSION(0, 52, 0)
MB_MGR *mb_mgr;
/**< Multi-buffer instance */
-#endif
};
/** AESNI Multi buffer queue pair */
@@ -160,10 +139,6 @@ struct aesni_mb_qp {
uint16_t id;
/**< Queue Pair Identifier */
char name[RTE_CRYPTODEV_NAME_MAX_LEN];
-#if IMB_VERSION_NUM < IMB_VERSION(0, 52, 0)
- /**< Unique Queue Pair Name */
- const struct aesni_mb_op_fns *op_fns;
-#endif
/**< Unique Queue Pair Name */
MB_MGR *mb_mgr;
/**< Multi-buffer instance */
@@ -277,22 +252,10 @@ struct aesni_mb_session {
} aead;
} __rte_cache_aligned;
-
-
-#if IMB_VERSION_NUM >= IMB_VERSION(0, 52, 0)
-/**
- *
- */
extern int
aesni_mb_set_session_parameters(const MB_MGR *mb_mgr,
struct aesni_mb_session *sess,
const struct rte_crypto_sym_xform *xform);
-#else
-extern int
-aesni_mb_set_session_parameters(const struct aesni_mb_op_fns *mb_ops,
- struct aesni_mb_session *sess,
- const struct rte_crypto_sym_xform *xform);
-#endif
/** device specific operations function pointer structure */
extern struct rte_cryptodev_ops *rte_aesni_mb_pmd_ops;
--
2.14.5
^ permalink raw reply [relevance 1%]
* Re: [dpdk-dev] [PATCH v3] net/nfb: new netcope driver
@ 2019-03-04 12:35 3% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2019-03-04 12:35 UTC (permalink / raw)
To: Rastislav Černay; +Cc: dev, Yigit, Ferruh
On Mon, Mar 4, 2019 at 1:30 PM Rastislav Černay <cernay@netcope.com> wrote:
> >>> What is the point of adding when i >= RTE_ETHDEV_QUEUE_STAT_CNTRS ?
>
> struct rte_eth_stats {
> ...
> uint64_t q_opackets[RTE_ETHDEV_QUEUE_STAT_CNTRS]
> ...
> }
>
> As there can be more queues (nb_tx) then RTE_ETHDEV_QUEUE_STAT_CNTRS (16)
> and struct rte_eth_stats eth_stats is allocated statically,
> there is need to check so it does not write garbage somewhere.
>
How about looping on min(nb_tx, RTE_ETHDEV_QUEUE_STAT_CNTRS) ?
> >>> Besides, q_errors[] is for reception errors.
> I will fix that, meanwhile could q_errors[] be renamed to q_ierrors[]?
> Also could there be a way to publish output errors per queue, for example
> q_oerrors[]?
>
At the moment, no, this would be a api breakage, and adding oerrors would
be a abi breakage.
This can be discussed yes, I just sent a series about q_errors[].
You can still export this via xstats.
--
David Marchand
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] crypto/aesni_mb: support newer version library only
2019-03-04 11:47 1% [dpdk-dev] [PATCH] crypto/aesni_mb: support newer version library only Fan Zhang
@ 2019-03-04 14:47 0% ` Trahe, Fiona
0 siblings, 0 replies; 200+ results
From: Trahe, Fiona @ 2019-03-04 14:47 UTC (permalink / raw)
To: Zhang, Roy Fan, dev; +Cc: akhil.goyal, Kusztal, ArkadiuszX, Trahe, Fiona
Hi Fan,
> -----Original Message-----
> From: Zhang, Roy Fan
> Sent: Monday, March 4, 2019 11:47 AM
> To: dev@dpdk.org
> Cc: akhil.goyal@nxp.com; Zhang, Roy Fan <roy.fan.zhang@intel.com>; Kusztal, ArkadiuszX
> <arkadiuszx.kusztal@intel.com>; Trahe, Fiona <fiona.trahe@intel.com>
> Subject: [PATCH] crypto/aesni_mb: support newer version library only
>
> As stated in 19.02 deprecation notice, this patch updates the
> aesni_mb PMD to remove the support of older Intel-ipsec-mb
> library version eariler than 0.52.
>
> Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
> ---
> Although the PMD dependency to the library is changed, the ABI/API
> are not updated as the APIs to access the PMD remains intact. When
> the user compile the PMD a error message "IPSec MB version >=
> 0.52" will be displayed to inform the user to update the library.
>
> doc/guides/cryptodevs/aesni_mb.rst | 8 +-
> doc/guides/rel_notes/deprecation.rst | 3 -
> drivers/crypto/aesni_mb/Makefile | 21 +-
> drivers/crypto/aesni_mb/aesni_mb_ops.h | 302 -----
> drivers/crypto/aesni_mb/meson.build | 13 +-
> drivers/crypto/aesni_mb/rte_aesni_mb_pmd_compat.c | 1313 --------------------
> .../crypto/aesni_mb/rte_aesni_mb_pmd_ops_compat.c | 745 -----------
> drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h | 37 -
> 8 files changed, 16 insertions(+), 2426 deletions(-)
> delete mode 100644 drivers/crypto/aesni_mb/aesni_mb_ops.h
> delete mode 100644 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_compat.c
> delete mode 100644 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops_compat.c
>
> diff --git a/doc/guides/cryptodevs/aesni_mb.rst b/doc/guides/cryptodevs/aesni_mb.rst
> index 47f2ecc2f..d3567d279 100644
> --- a/doc/guides/cryptodevs/aesni_mb.rst
> +++ b/doc/guides/cryptodevs/aesni_mb.rst
> @@ -57,10 +57,7 @@ Limitations
>
> * Chained mbufs are not supported.
> * Only in-place is currently supported (destination address is the same as source address).
> -* RTE_CRYPTO_AEAD_AES_GCM only works properly when the multi-buffer library is
> - 0.51.0 or newer.
> -* RTE_CRYPTO_HASH_AES_GMAC is supported by library version v0.51 or later.
> -* RTE_CRYPTO_HASH_SHA* is supported by library version v0.52 or later.
> +* Only support Intel multi buffer library version 0.52 or later.
>
>
> Installation
> @@ -92,7 +89,8 @@ and the Multi-Buffer library version supported by them:
> 17.05 - 17.08 0.45 - 0.48
> 17.11 0.47 - 0.48
> 18.02 0.48
> - 18.05+ 0.49+
> + 18.05 0.49
> + 19.02+ 0.52+
[Fiona] shouldn't this be
19.05+ 0.52+
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v6 1/1] ci: Introduce travis builds for github repositories
@ 2019-03-04 16:12 3% ` Michael Santana
2019-03-22 16:56 3% ` [dpdk-dev] [PATCH v7] " Michael Santana
0 siblings, 1 reply; 200+ results
From: Michael Santana @ 2019-03-04 16:12 UTC (permalink / raw)
To: dev; +Cc: Aaron Conole, Bruce Richardson, Honnappa Nagarahalli, Thomas Monjalon
GitHub is a service used by developers to store repositories. GitHub
provides service integrations that allow 3rd party services to access
developer repositories and perform actions. One of these services is
Travis-CI, a simple continuous integration platform.
This is a simple initial implementation of a travis build for the DPDK
project. It doesn't require any changes from individual developers to
enable, but will allow those developers who opt-in to GitHub and the
travis service to get automatic builds for every push they make.
Additionally, the travis service will send an email to the test-report
list informing anyone interested in the automated build (including a
result).
Signed-off-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Michael Santana <msantana@redhat.com>
---
v6:
Removed all classic make builds
.ci/linux-build.sh | 21 +++++++++
.ci/linux-setup.sh | 3 ++
.travis.yml | 73 +++++++++++++++++++++++++++++
MAINTAINERS | 6 +++
doc/guides/contributing/patches.rst | 4 ++
5 files changed, 107 insertions(+)
create mode 100755 .ci/linux-build.sh
create mode 100755 .ci/linux-setup.sh
create mode 100644 .travis.yml
diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
new file mode 100755
index 000000000..6b65ad31b
--- /dev/null
+++ b/.ci/linux-build.sh
@@ -0,0 +1,21 @@
+#!/bin/bash -xe
+
+function on_error() {
+ FILES_TO_PRINT=( "build/meson-logs/testlog.txt" "build/.ninja_log" "build/meson-logs/meson-log.txt")
+
+ for pr_file in "${FILES_TO_PRINT[@]}"; do
+ if [ -e "$pr_file" ]; then
+ cat "$pr_file"
+ fi
+ done
+}
+trap on_error ERR
+
+if [ "${AARCH64}" == "1" ]; then
+ # convert the arch specifier
+ OPTS="${OPTS} -DRTE_ARCH_64=1 --cross-file config/arm/arm64_armv8_linuxapp_gcc"
+fi
+
+OPTS="$OPTS --default-library=$DEF_LIB"
+meson build --werror -Dexamples=all ${OPTS}
+ninja -C build
diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh
new file mode 100755
index 000000000..63502c90a
--- /dev/null
+++ b/.ci/linux-setup.sh
@@ -0,0 +1,3 @@
+ #!/bin/bash
+
+python3 -m pip install --upgrade meson --user
diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 000000000..b0ab00a9d
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,73 @@
+language: c
+compiler:
+ - gcc
+ - clang
+
+dist: xenial
+
+os:
+ - linux
+
+addons:
+ apt:
+ update: true
+ packages:
+ - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
+
+before_install: ./.ci/${TRAVIS_OS_NAME}-setup.sh
+
+sudo: false
+
+env:
+ - DEF_LIB="static"
+ - DEF_LIB="shared"
+ - DEF_LIB="static" OPTS="-Denable_kmods=false"
+ - DEF_LIB="shared" OPTS="-Denable_kmods=false"
+
+matrix:
+ include:
+ - env: DEF_LIB="static" OPTS="-Denable_kmods=false" AARCH64=1
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
+ - [gcc-aarch64-linux-gnu, libc6-dev-arm64-cross]
+ - env: DEF_LIB="shared" OPTS="-Denable_kmods=false" AARCH64=1
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
+ - [gcc-aarch64-linux-gnu, libc6-dev-arm64-cross]
+ - env: DEF_LIB="static"
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
+ - env: DEF_LIB="shared"
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
+ - env: DEF_LIB="static" OPTS="-Denable_kmods=false"
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
+ - env: DEF_LIB="shared" OPTS="-Denable_kmods=false"
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+ - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
+
+
+script: ./.ci/${TRAVIS_OS_NAME}-build.sh
diff --git a/MAINTAINERS b/MAINTAINERS
index 15c53888c..e4b9a8e00 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -119,6 +119,12 @@ F: config/rte_config.h
F: buildtools/gen-pmdinfo-cfile.sh
F: buildtools/symlink-drivers-solibs.sh
+Public CI
+M: Aaron Conole <aconole@redhat.com>
+M: Michael Santana <msantana@redhat.com>
+F: .travis.yml
+F: .ci/
+
ABI versioning
M: Neil Horman <nhorman@tuxdriver.com>
F: doc/guides/rel_notes/deprecation.rst
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index 211a5cdc7..22a9039e8 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -32,6 +32,10 @@ The mailing list for DPDK development is `dev@dpdk.org <http://mails.dpdk.org/ar
Contributors will need to `register for the mailing list <http://mails.dpdk.org/listinfo/dev>`_ in order to submit patches.
It is also worth registering for the DPDK `Patchwork <http://patches.dpdk.org/project/dpdk/list/>`_
+If you are using the GitHub service, you can link your repository to
+the ``travis-ci.org`` build service. When you push patches to your GitHub
+repository, the travis service will automatically build your changes.
+
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.20.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v1 2/6] lib/mbuf: enable parse flags when create mempool
@ 2019-03-05 8:30 3% ` David Marchand
2019-03-07 3:07 0% ` Ye Xiaolong
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2019-03-05 8:30 UTC (permalink / raw)
To: Xiaolong Ye; +Cc: dev, Qi Zhang, Olivier Matz
On Fri, Mar 1, 2019 at 9:13 AM Xiaolong Ye <xiaolong.ye@intel.com> wrote:
> This give the option that applicaiton can configure each
> memory chunk's size precisely. (by MEMPOOL_F_NO_SPREAD).
>
> Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
> Signed-off-by: Xiaolong Ye <xiaolong.ye@intel.com>
>
Cc: maintainer
---
> lib/librte_mbuf/rte_mbuf.c | 15 ++++++++++++---
> lib/librte_mbuf/rte_mbuf.h | 8 +++++++-
> 2 files changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
> index 21f6f7404..0f6fcff28 100644
> --- a/lib/librte_mbuf/rte_mbuf.c
> +++ b/lib/librte_mbuf/rte_mbuf.c
> @@ -110,7 +110,7 @@ rte_pktmbuf_init(struct rte_mempool *mp,
> struct rte_mempool *
> rte_pktmbuf_pool_create_by_ops(const char *name, unsigned int n,
> unsigned int cache_size, uint16_t priv_size, uint16_t
> data_room_size,
> - int socket_id, const char *ops_name)
> + unsigned int flags, int socket_id, const char *ops_name)
> {
> struct rte_mempool *mp;
> struct rte_pktmbuf_pool_private mbp_priv;
>
You can't do that, rte_pktmbuf_pool_create_by_ops is exposed to the user
apps and part of the ABI.
You must define a new internal fonction that takes this flag, keeps the
existing interface and add your new experimental api.
--
David Marchand
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v3 1/6] vfio: allow DMA map of memory for the default vfio fd
@ 2019-03-05 13:59 5% ` Shahaf Shuler
1 sibling, 0 replies; 200+ results
From: Shahaf Shuler @ 2019-03-05 13:59 UTC (permalink / raw)
To: anatoly.burakov, yskoh, thomas, ferruh.yigit, nhorman, gaetan.rivet; +Cc: dev
Enable users the option to call rte_vfio_dma_map with request to map
to the default vfio fd.
Signed-off-by: Shahaf Shuler <shahafs@mellanox.com>
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
---
doc/guides/rel_notes/release_19_05.rst | 3 +++
lib/librte_eal/common/include/rte_vfio.h | 8 ++++++--
lib/librte_eal/linuxapp/eal/eal_vfio.c | 10 ++++++++--
3 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 4a3e2a7f31..b02753bbc4 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -122,6 +122,9 @@ ABI Changes
Also, make sure to start the actual text at the margin.
=========================================================
+* vfio: Functions ``rte_vfio_container_dma_map`` and
+ ``rte_vfio_container_dma_unmap`` have been extended with an option to
+ request mapping or un-mapping to the default vfio container fd.
Shared Library Versions
-----------------------
diff --git a/lib/librte_eal/common/include/rte_vfio.h b/lib/librte_eal/common/include/rte_vfio.h
index cae96fab90..cdfbedc1f9 100644
--- a/lib/librte_eal/common/include/rte_vfio.h
+++ b/lib/librte_eal/common/include/rte_vfio.h
@@ -80,6 +80,8 @@ struct vfio_device_info;
#endif /* VFIO_PRESENT */
+#define RTE_VFIO_DEFAULT_CONTAINER_FD (-1)
+
/**
* Setup vfio_cfg for the device identified by its address.
* It discovers the configured I/O MMU groups or sets a new one for the device.
@@ -347,7 +349,8 @@ rte_vfio_container_group_unbind(int container_fd, int iommu_group_num);
* Perform DMA mapping for devices in a container.
*
* @param container_fd
- * the specified container fd
+ * the specified container fd. Use RTE_VFIO_DEFAULT_CONTAINER_FD to
+ * use the default container.
*
* @param vaddr
* Starting virtual address of memory to be mapped.
@@ -370,7 +373,8 @@ rte_vfio_container_dma_map(int container_fd, uint64_t vaddr,
* Perform DMA unmapping for devices in a container.
*
* @param container_fd
- * the specified container fd
+ * the specified container fd. Use RTE_VFIO_DEFAULT_CONTAINER_FD to
+ * use the default container.
*
* @param vaddr
* Starting virtual address of memory to be unmapped.
diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.c b/lib/librte_eal/linuxapp/eal/eal_vfio.c
index c821e83826..9adbda8bb7 100644
--- a/lib/librte_eal/linuxapp/eal/eal_vfio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_vfio.c
@@ -1897,7 +1897,10 @@ rte_vfio_container_dma_map(int container_fd, uint64_t vaddr, uint64_t iova,
return -1;
}
- vfio_cfg = get_vfio_cfg_by_container_fd(container_fd);
+ if (container_fd == RTE_VFIO_DEFAULT_CONTAINER_FD)
+ vfio_cfg = default_vfio_cfg;
+ else
+ vfio_cfg = get_vfio_cfg_by_container_fd(container_fd);
if (vfio_cfg == NULL) {
RTE_LOG(ERR, EAL, "Invalid container fd\n");
return -1;
@@ -1917,7 +1920,10 @@ rte_vfio_container_dma_unmap(int container_fd, uint64_t vaddr, uint64_t iova,
return -1;
}
- vfio_cfg = get_vfio_cfg_by_container_fd(container_fd);
+ if (container_fd == RTE_VFIO_DEFAULT_CONTAINER_FD)
+ vfio_cfg = default_vfio_cfg;
+ else
+ vfio_cfg = get_vfio_cfg_by_container_fd(container_fd);
if (vfio_cfg == NULL) {
RTE_LOG(ERR, EAL, "Invalid container fd\n");
return -1;
--
2.12.0
^ permalink raw reply [relevance 5%]
* [dpdk-dev] [PATCH v5 0/6] Add lock-free ring and mempool handler
2019-01-28 18:14 3% ` [dpdk-dev] [PATCH v4 " Gage Eads
2019-01-28 18:14 2% ` [dpdk-dev] [PATCH v4 1/5] ring: add 64-bit headtail structure Gage Eads
@ 2019-03-05 17:40 2% ` Gage Eads
2019-03-05 17:40 2% ` [dpdk-dev] [PATCH v5 1/6] ring: add a pointer-width headtail structure Gage Eads
2019-03-06 15:03 2% ` [dpdk-dev] [PATCH v6 0/6] Add lock-free ring and mempool handler Gage Eads
1 sibling, 2 replies; 200+ results
From: Gage Eads @ 2019-03-05 17:40 UTC (permalink / raw)
To: dev
Cc: olivier.matz, arybchenko, bruce.richardson, konstantin.ananyev,
stephen, jerinj, mczekaj, nd, Ola.Liljedahl
For some users, the rte ring's "non-preemptive" constraint is not acceptable;
for example, if the application uses a mixture of pinned high-priority threads
and multiplexed low-priority threads that share a mempool.
This patchset introduces a lock-free ring and a mempool based on it. The
lock-free algorithm relies on a double-pointer compare-and-swap, so for 64-bit
architectures it is currently limited to x86_64.
The ring uses more compare-and-swap atomic operations than the regular rte ring:
With no contention, an enqueue of n pointers uses (1 + n) CAS operations and a
dequeue of n pointers uses 1. This algorithm has worse average-case performance
than the regular rte ring (particularly a highly-contended ring with large bulk
accesses), however:
- For applications with preemptible pthreads, the regular rte ring's worst-case
performance (i.e. one thread being preempted in the update_tail() critical
section) is much worse than the lock-free ring's.
- Software caching can mitigate the average case performance for ring-based
algorithms. For example, a lock-free ring based mempool (a likely use case
for this ring) with per-thread caching.
The lock-free ring is enabled via a new flag, RING_F_LF. For ease-of-use,
existing ring enqueue/dequeue functions work with both standard and lock-free
rings. This is also an experimental API, so RING_F_LF users must build with the
ALLOW_EXPERIMENTAL_API flag.
This patchset also adds lock-free versions of ring_autotest and
ring_perf_autotest, and a lock-free ring based mempool.
This patchset makes one API change; a deprecation notice was posted in a
separate commit[1].
This patchset depends on the 128-bit compare-and-set patch[2].
[1] http://mails.dpdk.org/archives/dev/2019-February/124321.html
[2] http://mails.dpdk.org/archives/dev/2019-March/125751.html
v5:
- Incorporated lfring's enqueue and dequeue logic from
http://mails.dpdk.org/archives/dev/2019-January/124242.html
- Renamed non-blocking -> lock-free and NB -> LF to align with a similar
change in the lock-free stack patchset:
http://mails.dpdk.org/archives/dev/2019-March/125797.html
- Added support for 32-bit architectures by using the full 32b of the
modification counter and requiring LF rings on these architectures to be at
least 1024 entries.
- Updated to the latest rte_atomic128_cmp_exchange() interface.
- Added ring start marker to struct rte_ring
v4:
- Split out nb_enqueue and nb_dequeue functions in generic and C11 versions,
with the necessary memory ordering behavior for weakly consistent machines.
- Convert size_t variables (from v2) to uint64_t and no-longer-applicable
comment about variably-sized ring indexes.
- Fix bug in nb_enqueue_mp that the breaks the non-blocking guarantee.
- Split the ring_ptr cast into two lines.
- Change the dependent patchset from the non-blocking stack patch series
to one only containing the 128b CAS commit
v3:
- Avoid the ABI break by putting 64-bit head and tail values in the same
cacheline as struct rte_ring's prod and cons members.
- Don't attempt to compile rte_atomic128_cmpset without
ALLOW_EXPERIMENTAL_API, as this would break a large number of libraries.
- Add a helpful warning to __rte_ring_do_nb_enqueue_mp() in case someone tries
to use RING_F_NB without the ALLOW_EXPERIMENTAL_API flag.
- Update the ring mempool to use experimental APIs
- Clarify that RINB_F_NB is only limited to x86_64 currently; e.g. ARMv8 has the
ISA support for 128-bit CAS to eventually support it.
v2:
- Merge separate docs commit into patch #5
- Convert uintptr_t to size_t
- Add a compile-time check for the size of size_t
- Fix a space-after-typecast issue
- Fix an unnecessary-parentheses checkpatch warning
- Bump librte_ring's library version
Gage Eads (6):
ring: add a pointer-width headtail structure
ring: add a ring start marker
ring: add a lock-free implementation
test_ring: add lock-free ring autotest
test_ring_perf: add lock-free ring perf test
mempool/ring: add lock-free ring handlers
doc/guides/prog_guide/env_abstraction_layer.rst | 10 +
drivers/mempool/ring/Makefile | 1 +
drivers/mempool/ring/meson.build | 2 +
drivers/mempool/ring/rte_mempool_ring.c | 58 ++-
lib/librte_ring/rte_ring.c | 92 ++++-
lib/librte_ring/rte_ring.h | 334 ++++++++++++++--
lib/librte_ring/rte_ring_c11_mem.h | 501 ++++++++++++++++++++++++
lib/librte_ring/rte_ring_generic.h | 484 +++++++++++++++++++++++
lib/librte_ring/rte_ring_version.map | 7 +
test/test/test_ring.c | 61 +--
test/test/test_ring_perf.c | 19 +-
11 files changed, 1492 insertions(+), 77 deletions(-)
--
2.13.6
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v5 1/6] ring: add a pointer-width headtail structure
2019-03-05 17:40 2% ` [dpdk-dev] [PATCH v5 0/6] Add lock-free ring and mempool handler Gage Eads
@ 2019-03-05 17:40 2% ` Gage Eads
2019-03-06 15:03 2% ` [dpdk-dev] [PATCH v6 0/6] Add lock-free ring and mempool handler Gage Eads
1 sibling, 0 replies; 200+ results
From: Gage Eads @ 2019-03-05 17:40 UTC (permalink / raw)
To: dev
Cc: olivier.matz, arybchenko, bruce.richardson, konstantin.ananyev,
stephen, jerinj, mczekaj, nd, Ola.Liljedahl
For 64-bit systems, at current CPU speeds, 64-bit head and tail indexes
will not wrap-around within the author's lifetime. This is important to
avoiding the ABA problem -- in which a thread mistakes reading the same
tail index in two accesses to mean that the ring was not modified in the
intervening time -- in the upcoming lock-free ring implementation. Using a
64-bit index makes the possibility of this occurring effectively zero. This
commit uses pointer-width indexes so the lock-free ring can support 32-bit
systems as well.
This commit places the new producer and consumer structures in the same
location in struct rte_ring as their 32-bit counterparts. Since the 32-bit
versions are padded out to a cache line, there is space for the new
structure without affecting the layout of struct rte_ring. Thus, the ABI is
preserved.
Signed-off-by: Gage Eads <gage.eads@intel.com>
---
lib/librte_ring/rte_ring.h | 21 +++++-
lib/librte_ring/rte_ring_c11_mem.h | 143 +++++++++++++++++++++++++++++++++++++
lib/librte_ring/rte_ring_generic.h | 130 +++++++++++++++++++++++++++++++++
3 files changed, 291 insertions(+), 3 deletions(-)
diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
index af5444a9f..c78db6916 100644
--- a/lib/librte_ring/rte_ring.h
+++ b/lib/librte_ring/rte_ring.h
@@ -1,6 +1,6 @@
/* SPDX-License-Identifier: BSD-3-Clause
*
- * Copyright (c) 2010-2017 Intel Corporation
+ * Copyright (c) 2010-2019 Intel Corporation
* Copyright (c) 2007-2009 Kip Macy kmacy@freebsd.org
* All rights reserved.
* Derived from FreeBSD's bufring.h
@@ -70,6 +70,13 @@ struct rte_ring_headtail {
uint32_t single; /**< True if single prod/cons */
};
+/* Structure to hold a pair of pointer-sized head/tail values and metadata */
+struct rte_ring_headtail_ptr {
+ volatile uintptr_t head; /**< Prod/consumer head. */
+ volatile uintptr_t tail; /**< Prod/consumer tail. */
+ uint32_t single; /**< True if single prod/cons */
+};
+
/**
* An RTE ring structure.
*
@@ -97,11 +104,19 @@ struct rte_ring {
char pad0 __rte_cache_aligned; /**< empty cache line */
/** Ring producer status. */
- struct rte_ring_headtail prod __rte_cache_aligned;
+ RTE_STD_C11
+ union {
+ struct rte_ring_headtail prod __rte_cache_aligned;
+ struct rte_ring_headtail_ptr prod_ptr __rte_cache_aligned;
+ };
char pad1 __rte_cache_aligned; /**< empty cache line */
/** Ring consumer status. */
- struct rte_ring_headtail cons __rte_cache_aligned;
+ RTE_STD_C11
+ union {
+ struct rte_ring_headtail cons __rte_cache_aligned;
+ struct rte_ring_headtail_ptr cons_ptr __rte_cache_aligned;
+ };
char pad2 __rte_cache_aligned; /**< empty cache line */
};
diff --git a/lib/librte_ring/rte_ring_c11_mem.h b/lib/librte_ring/rte_ring_c11_mem.h
index 0fb73a337..545caf257 100644
--- a/lib/librte_ring/rte_ring_c11_mem.h
+++ b/lib/librte_ring/rte_ring_c11_mem.h
@@ -178,4 +178,147 @@ __rte_ring_move_cons_head(struct rte_ring *r, int is_sc,
return n;
}
+/**
+ * @internal This function updates the producer head for enqueue using
+ * pointer-sized head/tail values.
+ *
+ * @param r
+ * A pointer to the ring structure
+ * @param is_sp
+ * Indicates whether multi-producer path is needed or not
+ * @param n
+ * The number of elements we will want to enqueue, i.e. how far should the
+ * head be moved
+ * @param behavior
+ * RTE_RING_QUEUE_FIXED: Enqueue a fixed number of items from a ring
+ * RTE_RING_QUEUE_VARIABLE: Enqueue as many items as possible from ring
+ * @param old_head
+ * Returns head value as it was before the move, i.e. where enqueue starts
+ * @param new_head
+ * Returns the current/new head value i.e. where enqueue finishes
+ * @param free_entries
+ * Returns the amount of free space in the ring BEFORE head was moved
+ * @return
+ * Actual number of objects enqueued.
+ * If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
+ */
+static __rte_always_inline unsigned int
+__rte_ring_move_prod_head_ptr(struct rte_ring *r, unsigned int is_sp,
+ unsigned int n, enum rte_ring_queue_behavior behavior,
+ uintptr_t *old_head, uintptr_t *new_head,
+ uint32_t *free_entries)
+{
+ const uint32_t capacity = r->capacity;
+ uintptr_t cons_tail;
+ unsigned int max = n;
+ int success;
+
+ *old_head = __atomic_load_n(&r->prod_ptr.head, __ATOMIC_RELAXED);
+ do {
+ /* Reset n to the initial burst count */
+ n = max;
+
+ /* Ensure the head is read before tail */
+ __atomic_thread_fence(__ATOMIC_ACQUIRE);
+
+ /* load-acquire synchronize with store-release of ht->tail
+ * in update_tail.
+ */
+ cons_tail = __atomic_load_n(&r->cons_ptr.tail,
+ __ATOMIC_ACQUIRE);
+
+ *free_entries = (capacity + cons_tail - *old_head);
+
+ /* check that we have enough room in ring */
+ if (unlikely(n > *free_entries))
+ n = (behavior == RTE_RING_QUEUE_FIXED) ?
+ 0 : *free_entries;
+
+ if (n == 0)
+ return 0;
+
+ *new_head = *old_head + n;
+ if (is_sp)
+ r->prod_ptr.head = *new_head, success = 1;
+ else
+ /* on failure, *old_head is updated */
+ success = __atomic_compare_exchange_n(&r->prod_ptr.head,
+ old_head, *new_head,
+ 0, __ATOMIC_RELAXED,
+ __ATOMIC_RELAXED);
+ } while (unlikely(success == 0));
+ return n;
+}
+
+/**
+ * @internal This function updates the consumer head for dequeue using
+ * pointer-sized head/tail values.
+ *
+ * @param r
+ * A pointer to the ring structure
+ * @param is_sc
+ * Indicates whether multi-consumer path is needed or not
+ * @param n
+ * The number of elements we will want to enqueue, i.e. how far should the
+ * head be moved
+ * @param behavior
+ * RTE_RING_QUEUE_FIXED: Dequeue a fixed number of items from a ring
+ * RTE_RING_QUEUE_VARIABLE: Dequeue as many items as possible from ring
+ * @param old_head
+ * Returns head value as it was before the move, i.e. where dequeue starts
+ * @param new_head
+ * Returns the current/new head value i.e. where dequeue finishes
+ * @param entries
+ * Returns the number of entries in the ring BEFORE head was moved
+ * @return
+ * - Actual number of objects dequeued.
+ * If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
+ */
+static __rte_always_inline unsigned int
+__rte_ring_move_cons_head_ptr(struct rte_ring *r, unsigned int is_sc,
+ unsigned int n, enum rte_ring_queue_behavior behavior,
+ uintptr_t *old_head, uintptr_t *new_head,
+ uint32_t *entries)
+{
+ unsigned int max = n;
+ uintptr_t prod_tail;
+ int success;
+
+ /* move cons.head atomically */
+ *old_head = __atomic_load_n(&r->cons_ptr.head, __ATOMIC_RELAXED);
+ do {
+ /* Restore n as it may change every loop */
+ n = max;
+
+ /* Ensure the head is read before tail */
+ __atomic_thread_fence(__ATOMIC_ACQUIRE);
+
+ /* this load-acquire synchronize with store-release of ht->tail
+ * in update_tail.
+ */
+ prod_tail = __atomic_load_n(&r->prod_ptr.tail,
+ __ATOMIC_ACQUIRE);
+
+ *entries = (prod_tail - *old_head);
+
+ /* Set the actual entries for dequeue */
+ if (n > *entries)
+ n = (behavior == RTE_RING_QUEUE_FIXED) ? 0 : *entries;
+
+ if (unlikely(n == 0))
+ return 0;
+
+ *new_head = *old_head + n;
+ if (is_sc)
+ r->cons_ptr.head = *new_head, success = 1;
+ else
+ /* on failure, *old_head will be updated */
+ success = __atomic_compare_exchange_n(&r->cons_ptr.head,
+ old_head, *new_head,
+ 0, __ATOMIC_RELAXED,
+ __ATOMIC_RELAXED);
+ } while (unlikely(success == 0));
+ return n;
+}
+
#endif /* _RTE_RING_C11_MEM_H_ */
diff --git a/lib/librte_ring/rte_ring_generic.h b/lib/librte_ring/rte_ring_generic.h
index ea7dbe5b9..6a0e1bbfb 100644
--- a/lib/librte_ring/rte_ring_generic.h
+++ b/lib/librte_ring/rte_ring_generic.h
@@ -167,4 +167,134 @@ __rte_ring_move_cons_head(struct rte_ring *r, unsigned int is_sc,
return n;
}
+/**
+ * @internal This function updates the producer head for enqueue using
+ * pointer-sized head/tail values.
+ *
+ * @param r
+ * A pointer to the ring structure
+ * @param is_sp
+ * Indicates whether multi-producer path is needed or not
+ * @param n
+ * The number of elements we will want to enqueue, i.e. how far should the
+ * head be moved
+ * @param behavior
+ * RTE_RING_QUEUE_FIXED: Enqueue a fixed number of items from a ring
+ * RTE_RING_QUEUE_VARIABLE: Enqueue as many items as possible from ring
+ * @param old_head
+ * Returns head value as it was before the move, i.e. where enqueue starts
+ * @param new_head
+ * Returns the current/new head value i.e. where enqueue finishes
+ * @param free_entries
+ * Returns the amount of free space in the ring BEFORE head was moved
+ * @return
+ * Actual number of objects enqueued.
+ * If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
+ */
+static __rte_always_inline unsigned int
+__rte_ring_move_prod_head_ptr(struct rte_ring *r, unsigned int is_sp,
+ unsigned int n, enum rte_ring_queue_behavior behavior,
+ uintptr_t *old_head, uintptr_t *new_head,
+ uint32_t *free_entries)
+{
+ const uint32_t capacity = r->capacity;
+ unsigned int max = n;
+ int success;
+
+ do {
+ /* Reset n to the initial burst count */
+ n = max;
+
+ *old_head = r->prod_ptr.head;
+
+ /* add rmb barrier to avoid load/load reorder in weak
+ * memory model. It is noop on x86
+ */
+ rte_smp_rmb();
+
+ *free_entries = (capacity + r->cons_ptr.tail - *old_head);
+
+ /* check that we have enough room in ring */
+ if (unlikely(n > *free_entries))
+ n = (behavior == RTE_RING_QUEUE_FIXED) ?
+ 0 : *free_entries;
+
+ if (n == 0)
+ return 0;
+
+ *new_head = *old_head + n;
+ if (is_sp)
+ r->prod_ptr.head = *new_head, success = 1;
+ else
+ success = __sync_bool_compare_and_swap(
+ &r->prod_ptr.head,
+ *old_head, *new_head);
+ } while (unlikely(success == 0));
+ return n;
+}
+
+/**
+ * @internal This function updates the consumer head for dequeue using
+ * pointer-sized head/tail values.
+ *
+ * @param r
+ * A pointer to the ring structure
+ * @param is_sc
+ * Indicates whether multi-consumer path is needed or not
+ * @param n
+ * The number of elements we will want to enqueue, i.e. how far should the
+ * head be moved
+ * @param behavior
+ * RTE_RING_QUEUE_FIXED: Dequeue a fixed number of items from a ring
+ * RTE_RING_QUEUE_VARIABLE: Dequeue as many items as possible from ring
+ * @param old_head
+ * Returns head value as it was before the move, i.e. where dequeue starts
+ * @param new_head
+ * Returns the current/new head value i.e. where dequeue finishes
+ * @param entries
+ * Returns the number of entries in the ring BEFORE head was moved
+ * @return
+ * - Actual number of objects dequeued.
+ * If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
+ */
+static __rte_always_inline unsigned int
+__rte_ring_move_cons_head_ptr(struct rte_ring *r, unsigned int is_sc,
+ unsigned int n, enum rte_ring_queue_behavior behavior,
+ uintptr_t *old_head, uintptr_t *new_head,
+ uint32_t *entries)
+{
+ unsigned int max = n;
+ int success;
+
+ do {
+ /* Restore n as it may change every loop */
+ n = max;
+
+ *old_head = r->cons_ptr.head;
+
+ /* add rmb barrier to avoid load/load reorder in weak
+ * memory model. It is noop on x86
+ */
+ rte_smp_rmb();
+
+ *entries = (r->prod_ptr.tail - *old_head);
+
+ /* Set the actual entries for dequeue */
+ if (n > *entries)
+ n = (behavior == RTE_RING_QUEUE_FIXED) ? 0 : *entries;
+
+ if (unlikely(n == 0))
+ return 0;
+
+ *new_head = *old_head + n;
+ if (is_sc)
+ r->cons_ptr.head = *new_head, success = 1;
+ else
+ success = __sync_bool_compare_and_swap(
+ &r->cons_ptr.head,
+ *old_head, *new_head);
+ } while (unlikely(success == 0));
+ return n;
+}
+
#endif /* _RTE_RING_GENERIC_H_ */
--
2.13.6
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [PATCH v3 0/2] Timer library changes
@ 2019-03-05 22:41 0% ` Carrillo, Erik G
2019-03-06 17:20 5% ` [dpdk-dev] [PATCH v4 " Erik Gabriel Carrillo
1 sibling, 0 replies; 200+ results
From: Carrillo, Erik G @ 2019-03-05 22:41 UTC (permalink / raw)
To: rsanford; +Cc: dev, techboard
Hi all,
I'd like to bring this patch proposal up again and see if I can get any more feedback from the maintainer or others.
I need to update the map file to reflect the next release, so I'll add those changes in if any other modifications are suggested.
Thanks,
Erik
ML: https://mails.dpdk.org/archives/dev/2018-December/120864.html
Patchwork: https://patches.dpdk.org/project/dpdk/list/?series=2767
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Erik Gabriel Carrillo
> Sent: Thursday, December 13, 2018 4:27 PM
> To: rsanford@akamai.com
> Cc: stephen@networkplumber.org; jerin.jacob@caviumnetworks.com;
> pbhagavatula@caviumnetworks.com; dev@dpdk.org
> Subject: [dpdk-dev] [PATCH v3 0/2] Timer library changes
>
> This patch series modifies the timer library in such a way that structures that
> used to be statically allocated in a process's data segment are now allocated
> in shared memory. As these structures contain lists of timers, new APIs are
> introduced that allow a caller to specify the particular structure instance into
> which a timer should be inserted or from which a timer should be removed.
> This enables primary and secondary processes to modify the same timer list,
> which enables some multi-process use cases that were not previously
> possible; e.g. a secondary process can start a timer whose expiration is
> detected in a primary process running a new flavor of timer_manage().
>
> The original library API is mostly unchanged, though implementations are
> updated to call into newly added functions with a default structure instance
> ID that provides the original behavior. New functions are introduced to
> enable applications to allocate structure instances to house timer lists, and to
> reference them with an identifier when starting and stopping timers, and
> finally, to manage the timer lists referenced with an identifier.
>
> My initial performance testing with the "timer_perf_autotest" test shows no
> performance regression or improvement, and inspection of the generated
> optimized code shows that the extra function call gets inlined in the functions
> that now have an extra function call.
>
> Depends on: https://patches.dpdk.org/patch/48417/
>
> Changes in v3:
> - remove C++ style comment in first patch in series (Stephen)
>
> Changes in v2:
> - split these changes out into their own series
> - version the symbols where the existing ABI was updated, and
> provide alternate implementation with behavior equivalent to original
> behavior. Validated ABI compatibility with validate-abi.sh
> - refactor changes to simplify patches
>
> Erik Gabriel Carrillo (2):
> timer: allow timer management in shared memory
> timer: add function to stop all timers in a list
>
> lib/librte_timer/Makefile | 1 +
> lib/librte_timer/rte_timer.c | 558
> ++++++++++++++++++++++++++++++---
> lib/librte_timer/rte_timer.h | 258 ++++++++++++++-
> lib/librte_timer/rte_timer_version.map | 23 ++
> 4 files changed, 795 insertions(+), 45 deletions(-)
>
> --
> 2.6.4
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v6 1/6] ring: add a pointer-width headtail structure
2019-03-06 15:03 2% ` [dpdk-dev] [PATCH v6 0/6] Add lock-free ring and mempool handler Gage Eads
@ 2019-03-06 15:03 2% ` Gage Eads
2019-03-18 21:35 2% ` [dpdk-dev] [PATCH v7 0/6] Add lock-free ring and mempool handler Gage Eads
1 sibling, 0 replies; 200+ results
From: Gage Eads @ 2019-03-06 15:03 UTC (permalink / raw)
To: dev
Cc: olivier.matz, arybchenko, bruce.richardson, konstantin.ananyev,
stephen, jerinj, mczekaj, nd, Ola.Liljedahl
For 64-bit systems, at current CPU speeds, 64-bit head and tail indexes
will not wrap-around within the author's lifetime. This is important to
avoiding the ABA problem -- in which a thread mistakes reading the same
tail index in two accesses to mean that the ring was not modified in the
intervening time -- in the upcoming lock-free ring implementation. Using a
64-bit index makes the possibility of this occurring effectively zero. This
commit uses pointer-width indexes so the lock-free ring can support 32-bit
systems as well.
This commit places the new producer and consumer structures in the same
location in struct rte_ring as their 32-bit counterparts. Since the 32-bit
versions are padded out to a cache line, there is space for the new
structure without affecting the layout of struct rte_ring. Thus, the ABI is
preserved.
Signed-off-by: Gage Eads <gage.eads@intel.com>
---
lib/librte_ring/rte_ring.h | 21 +++++-
lib/librte_ring/rte_ring_c11_mem.h | 143 +++++++++++++++++++++++++++++++++++++
lib/librte_ring/rte_ring_generic.h | 130 +++++++++++++++++++++++++++++++++
3 files changed, 291 insertions(+), 3 deletions(-)
diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
index af5444a9f..c78db6916 100644
--- a/lib/librte_ring/rte_ring.h
+++ b/lib/librte_ring/rte_ring.h
@@ -1,6 +1,6 @@
/* SPDX-License-Identifier: BSD-3-Clause
*
- * Copyright (c) 2010-2017 Intel Corporation
+ * Copyright (c) 2010-2019 Intel Corporation
* Copyright (c) 2007-2009 Kip Macy kmacy@freebsd.org
* All rights reserved.
* Derived from FreeBSD's bufring.h
@@ -70,6 +70,13 @@ struct rte_ring_headtail {
uint32_t single; /**< True if single prod/cons */
};
+/* Structure to hold a pair of pointer-sized head/tail values and metadata */
+struct rte_ring_headtail_ptr {
+ volatile uintptr_t head; /**< Prod/consumer head. */
+ volatile uintptr_t tail; /**< Prod/consumer tail. */
+ uint32_t single; /**< True if single prod/cons */
+};
+
/**
* An RTE ring structure.
*
@@ -97,11 +104,19 @@ struct rte_ring {
char pad0 __rte_cache_aligned; /**< empty cache line */
/** Ring producer status. */
- struct rte_ring_headtail prod __rte_cache_aligned;
+ RTE_STD_C11
+ union {
+ struct rte_ring_headtail prod __rte_cache_aligned;
+ struct rte_ring_headtail_ptr prod_ptr __rte_cache_aligned;
+ };
char pad1 __rte_cache_aligned; /**< empty cache line */
/** Ring consumer status. */
- struct rte_ring_headtail cons __rte_cache_aligned;
+ RTE_STD_C11
+ union {
+ struct rte_ring_headtail cons __rte_cache_aligned;
+ struct rte_ring_headtail_ptr cons_ptr __rte_cache_aligned;
+ };
char pad2 __rte_cache_aligned; /**< empty cache line */
};
diff --git a/lib/librte_ring/rte_ring_c11_mem.h b/lib/librte_ring/rte_ring_c11_mem.h
index 0fb73a337..545caf257 100644
--- a/lib/librte_ring/rte_ring_c11_mem.h
+++ b/lib/librte_ring/rte_ring_c11_mem.h
@@ -178,4 +178,147 @@ __rte_ring_move_cons_head(struct rte_ring *r, int is_sc,
return n;
}
+/**
+ * @internal This function updates the producer head for enqueue using
+ * pointer-sized head/tail values.
+ *
+ * @param r
+ * A pointer to the ring structure
+ * @param is_sp
+ * Indicates whether multi-producer path is needed or not
+ * @param n
+ * The number of elements we will want to enqueue, i.e. how far should the
+ * head be moved
+ * @param behavior
+ * RTE_RING_QUEUE_FIXED: Enqueue a fixed number of items from a ring
+ * RTE_RING_QUEUE_VARIABLE: Enqueue as many items as possible from ring
+ * @param old_head
+ * Returns head value as it was before the move, i.e. where enqueue starts
+ * @param new_head
+ * Returns the current/new head value i.e. where enqueue finishes
+ * @param free_entries
+ * Returns the amount of free space in the ring BEFORE head was moved
+ * @return
+ * Actual number of objects enqueued.
+ * If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
+ */
+static __rte_always_inline unsigned int
+__rte_ring_move_prod_head_ptr(struct rte_ring *r, unsigned int is_sp,
+ unsigned int n, enum rte_ring_queue_behavior behavior,
+ uintptr_t *old_head, uintptr_t *new_head,
+ uint32_t *free_entries)
+{
+ const uint32_t capacity = r->capacity;
+ uintptr_t cons_tail;
+ unsigned int max = n;
+ int success;
+
+ *old_head = __atomic_load_n(&r->prod_ptr.head, __ATOMIC_RELAXED);
+ do {
+ /* Reset n to the initial burst count */
+ n = max;
+
+ /* Ensure the head is read before tail */
+ __atomic_thread_fence(__ATOMIC_ACQUIRE);
+
+ /* load-acquire synchronize with store-release of ht->tail
+ * in update_tail.
+ */
+ cons_tail = __atomic_load_n(&r->cons_ptr.tail,
+ __ATOMIC_ACQUIRE);
+
+ *free_entries = (capacity + cons_tail - *old_head);
+
+ /* check that we have enough room in ring */
+ if (unlikely(n > *free_entries))
+ n = (behavior == RTE_RING_QUEUE_FIXED) ?
+ 0 : *free_entries;
+
+ if (n == 0)
+ return 0;
+
+ *new_head = *old_head + n;
+ if (is_sp)
+ r->prod_ptr.head = *new_head, success = 1;
+ else
+ /* on failure, *old_head is updated */
+ success = __atomic_compare_exchange_n(&r->prod_ptr.head,
+ old_head, *new_head,
+ 0, __ATOMIC_RELAXED,
+ __ATOMIC_RELAXED);
+ } while (unlikely(success == 0));
+ return n;
+}
+
+/**
+ * @internal This function updates the consumer head for dequeue using
+ * pointer-sized head/tail values.
+ *
+ * @param r
+ * A pointer to the ring structure
+ * @param is_sc
+ * Indicates whether multi-consumer path is needed or not
+ * @param n
+ * The number of elements we will want to enqueue, i.e. how far should the
+ * head be moved
+ * @param behavior
+ * RTE_RING_QUEUE_FIXED: Dequeue a fixed number of items from a ring
+ * RTE_RING_QUEUE_VARIABLE: Dequeue as many items as possible from ring
+ * @param old_head
+ * Returns head value as it was before the move, i.e. where dequeue starts
+ * @param new_head
+ * Returns the current/new head value i.e. where dequeue finishes
+ * @param entries
+ * Returns the number of entries in the ring BEFORE head was moved
+ * @return
+ * - Actual number of objects dequeued.
+ * If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
+ */
+static __rte_always_inline unsigned int
+__rte_ring_move_cons_head_ptr(struct rte_ring *r, unsigned int is_sc,
+ unsigned int n, enum rte_ring_queue_behavior behavior,
+ uintptr_t *old_head, uintptr_t *new_head,
+ uint32_t *entries)
+{
+ unsigned int max = n;
+ uintptr_t prod_tail;
+ int success;
+
+ /* move cons.head atomically */
+ *old_head = __atomic_load_n(&r->cons_ptr.head, __ATOMIC_RELAXED);
+ do {
+ /* Restore n as it may change every loop */
+ n = max;
+
+ /* Ensure the head is read before tail */
+ __atomic_thread_fence(__ATOMIC_ACQUIRE);
+
+ /* this load-acquire synchronize with store-release of ht->tail
+ * in update_tail.
+ */
+ prod_tail = __atomic_load_n(&r->prod_ptr.tail,
+ __ATOMIC_ACQUIRE);
+
+ *entries = (prod_tail - *old_head);
+
+ /* Set the actual entries for dequeue */
+ if (n > *entries)
+ n = (behavior == RTE_RING_QUEUE_FIXED) ? 0 : *entries;
+
+ if (unlikely(n == 0))
+ return 0;
+
+ *new_head = *old_head + n;
+ if (is_sc)
+ r->cons_ptr.head = *new_head, success = 1;
+ else
+ /* on failure, *old_head will be updated */
+ success = __atomic_compare_exchange_n(&r->cons_ptr.head,
+ old_head, *new_head,
+ 0, __ATOMIC_RELAXED,
+ __ATOMIC_RELAXED);
+ } while (unlikely(success == 0));
+ return n;
+}
+
#endif /* _RTE_RING_C11_MEM_H_ */
diff --git a/lib/librte_ring/rte_ring_generic.h b/lib/librte_ring/rte_ring_generic.h
index ea7dbe5b9..6a0e1bbfb 100644
--- a/lib/librte_ring/rte_ring_generic.h
+++ b/lib/librte_ring/rte_ring_generic.h
@@ -167,4 +167,134 @@ __rte_ring_move_cons_head(struct rte_ring *r, unsigned int is_sc,
return n;
}
+/**
+ * @internal This function updates the producer head for enqueue using
+ * pointer-sized head/tail values.
+ *
+ * @param r
+ * A pointer to the ring structure
+ * @param is_sp
+ * Indicates whether multi-producer path is needed or not
+ * @param n
+ * The number of elements we will want to enqueue, i.e. how far should the
+ * head be moved
+ * @param behavior
+ * RTE_RING_QUEUE_FIXED: Enqueue a fixed number of items from a ring
+ * RTE_RING_QUEUE_VARIABLE: Enqueue as many items as possible from ring
+ * @param old_head
+ * Returns head value as it was before the move, i.e. where enqueue starts
+ * @param new_head
+ * Returns the current/new head value i.e. where enqueue finishes
+ * @param free_entries
+ * Returns the amount of free space in the ring BEFORE head was moved
+ * @return
+ * Actual number of objects enqueued.
+ * If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
+ */
+static __rte_always_inline unsigned int
+__rte_ring_move_prod_head_ptr(struct rte_ring *r, unsigned int is_sp,
+ unsigned int n, enum rte_ring_queue_behavior behavior,
+ uintptr_t *old_head, uintptr_t *new_head,
+ uint32_t *free_entries)
+{
+ const uint32_t capacity = r->capacity;
+ unsigned int max = n;
+ int success;
+
+ do {
+ /* Reset n to the initial burst count */
+ n = max;
+
+ *old_head = r->prod_ptr.head;
+
+ /* add rmb barrier to avoid load/load reorder in weak
+ * memory model. It is noop on x86
+ */
+ rte_smp_rmb();
+
+ *free_entries = (capacity + r->cons_ptr.tail - *old_head);
+
+ /* check that we have enough room in ring */
+ if (unlikely(n > *free_entries))
+ n = (behavior == RTE_RING_QUEUE_FIXED) ?
+ 0 : *free_entries;
+
+ if (n == 0)
+ return 0;
+
+ *new_head = *old_head + n;
+ if (is_sp)
+ r->prod_ptr.head = *new_head, success = 1;
+ else
+ success = __sync_bool_compare_and_swap(
+ &r->prod_ptr.head,
+ *old_head, *new_head);
+ } while (unlikely(success == 0));
+ return n;
+}
+
+/**
+ * @internal This function updates the consumer head for dequeue using
+ * pointer-sized head/tail values.
+ *
+ * @param r
+ * A pointer to the ring structure
+ * @param is_sc
+ * Indicates whether multi-consumer path is needed or not
+ * @param n
+ * The number of elements we will want to enqueue, i.e. how far should the
+ * head be moved
+ * @param behavior
+ * RTE_RING_QUEUE_FIXED: Dequeue a fixed number of items from a ring
+ * RTE_RING_QUEUE_VARIABLE: Dequeue as many items as possible from ring
+ * @param old_head
+ * Returns head value as it was before the move, i.e. where dequeue starts
+ * @param new_head
+ * Returns the current/new head value i.e. where dequeue finishes
+ * @param entries
+ * Returns the number of entries in the ring BEFORE head was moved
+ * @return
+ * - Actual number of objects dequeued.
+ * If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
+ */
+static __rte_always_inline unsigned int
+__rte_ring_move_cons_head_ptr(struct rte_ring *r, unsigned int is_sc,
+ unsigned int n, enum rte_ring_queue_behavior behavior,
+ uintptr_t *old_head, uintptr_t *new_head,
+ uint32_t *entries)
+{
+ unsigned int max = n;
+ int success;
+
+ do {
+ /* Restore n as it may change every loop */
+ n = max;
+
+ *old_head = r->cons_ptr.head;
+
+ /* add rmb barrier to avoid load/load reorder in weak
+ * memory model. It is noop on x86
+ */
+ rte_smp_rmb();
+
+ *entries = (r->prod_ptr.tail - *old_head);
+
+ /* Set the actual entries for dequeue */
+ if (n > *entries)
+ n = (behavior == RTE_RING_QUEUE_FIXED) ? 0 : *entries;
+
+ if (unlikely(n == 0))
+ return 0;
+
+ *new_head = *old_head + n;
+ if (is_sc)
+ r->cons_ptr.head = *new_head, success = 1;
+ else
+ success = __sync_bool_compare_and_swap(
+ &r->cons_ptr.head,
+ *old_head, *new_head);
+ } while (unlikely(success == 0));
+ return n;
+}
+
#endif /* _RTE_RING_GENERIC_H_ */
--
2.13.6
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v6 0/6] Add lock-free ring and mempool handler
2019-03-05 17:40 2% ` [dpdk-dev] [PATCH v5 0/6] Add lock-free ring and mempool handler Gage Eads
2019-03-05 17:40 2% ` [dpdk-dev] [PATCH v5 1/6] ring: add a pointer-width headtail structure Gage Eads
@ 2019-03-06 15:03 2% ` Gage Eads
2019-03-06 15:03 2% ` [dpdk-dev] [PATCH v6 1/6] ring: add a pointer-width headtail structure Gage Eads
2019-03-18 21:35 2% ` [dpdk-dev] [PATCH v7 0/6] Add lock-free ring and mempool handler Gage Eads
1 sibling, 2 replies; 200+ results
From: Gage Eads @ 2019-03-06 15:03 UTC (permalink / raw)
To: dev
Cc: olivier.matz, arybchenko, bruce.richardson, konstantin.ananyev,
stephen, jerinj, mczekaj, nd, Ola.Liljedahl
For some users, the rte ring's "non-preemptive" constraint is not acceptable;
for example, if the application uses a mixture of pinned high-priority threads
and multiplexed low-priority threads that share a mempool.
This patchset introduces a lock-free ring and a mempool based on it. The
lock-free algorithm relies on a double-pointer compare-and-swap, so for 64-bit
architectures it is currently limited to x86_64.
The ring uses more compare-and-swap atomic operations than the regular rte ring:
With no contention, an enqueue of n pointers uses (1 + n) CAS operations and a
dequeue of n pointers uses 1. This algorithm has worse average-case performance
than the regular rte ring (particularly a highly-contended ring with large bulk
accesses), however:
- For applications with preemptible pthreads, the regular rte ring's worst-case
performance (i.e. one thread being preempted in the update_tail() critical
section) is much worse than the lock-free ring's.
- Software caching can mitigate the average case performance for ring-based
algorithms. For example, a lock-free ring based mempool (a likely use case
for this ring) with per-thread caching.
The lock-free ring is enabled via a new flag, RING_F_LF. For ease-of-use,
existing ring enqueue/dequeue functions work with both standard and lock-free
rings. This is also an experimental API, so RING_F_LF users must build with the
ALLOW_EXPERIMENTAL_API flag.
This patchset also adds lock-free versions of ring_autotest and
ring_perf_autotest, and a lock-free ring based mempool.
This patchset makes one API change; a deprecation notice was posted in a
separate commit[1].
This patchset depends on the 128-bit compare-and-set patch[2].
[1] http://mails.dpdk.org/archives/dev/2019-February/124321.html
[2] http://mails.dpdk.org/archives/dev/2019-March/125751.html
v6:
- Rebase patchset onto master (test/test/ -> app/test/)
v5:
- Incorporated lfring's enqueue and dequeue logic from
http://mails.dpdk.org/archives/dev/2019-January/124242.html
- Renamed non-blocking -> lock-free and NB -> LF to align with a similar
change in the lock-free stack patchset:
http://mails.dpdk.org/archives/dev/2019-March/125797.html
- Added support for 32-bit architectures by using the full 32b of the
modification counter and requiring LF rings on these architectures to be at
least 1024 entries.
- Updated to the latest rte_atomic128_cmp_exchange() interface.
- Added ring start marker to struct rte_ring
v4:
- Split out nb_enqueue and nb_dequeue functions in generic and C11 versions,
with the necessary memory ordering behavior for weakly consistent machines.
- Convert size_t variables (from v2) to uint64_t and no-longer-applicable
comment about variably-sized ring indexes.
- Fix bug in nb_enqueue_mp that the breaks the non-blocking guarantee.
- Split the ring_ptr cast into two lines.
- Change the dependent patchset from the non-blocking stack patch series
to one only containing the 128b CAS commit
v3:
- Avoid the ABI break by putting 64-bit head and tail values in the same
cacheline as struct rte_ring's prod and cons members.
- Don't attempt to compile rte_atomic128_cmpset without
ALLOW_EXPERIMENTAL_API, as this would break a large number of libraries.
- Add a helpful warning to __rte_ring_do_nb_enqueue_mp() in case someone tries
to use RING_F_NB without the ALLOW_EXPERIMENTAL_API flag.
- Update the ring mempool to use experimental APIs
- Clarify that RINB_F_NB is only limited to x86_64 currently; e.g. ARMv8 has the
ISA support for 128-bit CAS to eventually support it.
v2:
- Merge separate docs commit into patch #5
- Convert uintptr_t to size_t
- Add a compile-time check for the size of size_t
- Fix a space-after-typecast issue
- Fix an unnecessary-parentheses checkpatch warning
- Bump librte_ring's library version
Gage Eads (6):
ring: add a pointer-width headtail structure
ring: add a ring start marker
ring: add a lock-free implementation
test_ring: add lock-free ring autotest
test_ring_perf: add lock-free ring perf test
mempool/ring: add lock-free ring handlers
app/test/test_ring.c | 61 +--
app/test/test_ring_perf.c | 19 +-
doc/guides/prog_guide/env_abstraction_layer.rst | 10 +
drivers/mempool/ring/Makefile | 1 +
drivers/mempool/ring/meson.build | 2 +
drivers/mempool/ring/rte_mempool_ring.c | 58 ++-
lib/librte_ring/rte_ring.c | 92 ++++-
lib/librte_ring/rte_ring.h | 334 ++++++++++++++--
lib/librte_ring/rte_ring_c11_mem.h | 501 ++++++++++++++++++++++++
lib/librte_ring/rte_ring_generic.h | 484 +++++++++++++++++++++++
lib/librte_ring/rte_ring_version.map | 7 +
11 files changed, 1492 insertions(+), 77 deletions(-)
--
2.13.6
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [RFC PATCH 0/6] change legacy linuxapp/bsdapp names
@ 2019-03-06 16:22 1% Bruce Richardson
2019-03-06 16:22 7% ` [dpdk-dev] [PATCH 6/6] build: allow linux and freebsd in build configs Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2019-03-06 16:22 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson
The terms linuxapp and bsdapp are legacy names in DPDK that are equivalent
to the more usual names of "linux" and "freebsd". Therefore, we can
replace the instances of the "app" names with the more usual variants. The
only issue in maintaining backward compatibility which can be done by
preserving a) the build config filenames and b) the macros defined for
the build. In both cases, new configs/macros are added while keeping the
old for compatiblity.
The first 5 patches are relatively minor, internal changes, or changes for
the newer meson system. Patch 6 is larger in size as it changes the
make build system which has far greater use of the names linuxapp and
bsdapp.
Bruce Richardson (6):
eal/bsdapp: rename to freebsd
eal/linuxapp: rename to linux
build/linux: rename macro from LINUXAPP to LINUX
build/freebsd: rename macro from BSDPAPP to FREEBSD
build/meson: change linuxapp to linux in meson cross files
build: allow linux and freebsd in build configs
MAINTAINERS | 16 +--
app/test-bbdev/test-bbdev.py | 2 +-
app/test-bbdev/test_bbdev_vector.c | 2 +-
.../cperf_test_vector_parsing.c | 2 +-
app/test-pmd/testpmd.c | 2 +-
app/test/autotest.py | 2 +-
app/test/process.h | 4 +-
app/test/test.c | 2 +-
app/test/test_alarm.c | 2 +-
app/test/test_eal_flags.c | 34 +++---
app/test/test_eal_fs.c | 2 +-
app/test/test_errno.c | 2 +-
app/test/test_interrupts.c | 4 +-
app/test/test_kni.c | 2 +-
app/test/test_mempool.c | 2 +-
app/test/test_mp_secondary.c | 6 +-
app/test/test_pdump.c | 2 +-
app/test/test_timer_perf.c | 2 +-
app/test/test_timer_racecond.c | 2 +-
...mv8_linuxapp_gcc => arm64_armv8_linux_gcc} | 0
...aa2_linuxapp_gcc => arm64_dpaa2_linux_gcc} | 0
...dpaa_linuxapp_gcc => arm64_dpaa_linux_gcc} | 0
..._linuxapp_gcc => arm64_thunderx_linux_gcc} | 0
...on_armv8a_linuxapp => common_armv8a_linux} | 2 +-
config/{common_bsdapp => common_freebsd} | 2 +-
config/{common_linuxapp => common_linux} | 1 +
config/defconfig_arm-armv7a-linux-gcc | 1 +
config/defconfig_arm-armv7a-linuxapp-gcc | 2 +-
config/defconfig_arm64-armv8a-linux-clang | 1 +
config/defconfig_arm64-armv8a-linux-gcc | 1 +
config/defconfig_arm64-armv8a-linuxapp-clang | 2 +-
config/defconfig_arm64-armv8a-linuxapp-gcc | 2 +-
config/defconfig_arm64-bluefield-linux-gcc | 1 +
config/defconfig_arm64-bluefield-linuxapp-gcc | 2 +-
config/defconfig_arm64-dpaa-linux-gcc | 1 +
config/defconfig_arm64-dpaa-linuxapp-gcc | 2 +-
config/defconfig_arm64-dpaa2-linux-gcc | 1 +
config/defconfig_arm64-dpaa2-linuxapp-gcc | 2 +-
config/defconfig_arm64-stingray-linux-gcc | 1 +
config/defconfig_arm64-stingray-linuxapp-gcc | 2 +-
config/defconfig_arm64-thunderx-linux-gcc | 1 +
config/defconfig_arm64-thunderx-linuxapp-gcc | 2 +-
config/defconfig_arm64-xgene1-linux-gcc | 1 +
config/defconfig_arm64-xgene1-linuxapp-gcc | 2 +-
config/defconfig_i686-native-linux-gcc | 1 +
config/defconfig_i686-native-linux-icc | 1 +
config/defconfig_i686-native-linuxapp-gcc | 2 +-
config/defconfig_i686-native-linuxapp-icc | 2 +-
config/defconfig_ppc_64-power8-linux-gcc | 1 +
config/defconfig_ppc_64-power8-linuxapp-gcc | 2 +-
config/defconfig_x86_64-native-bsdapp-clang | 2 +-
config/defconfig_x86_64-native-bsdapp-gcc | 2 +-
config/defconfig_x86_64-native-freebsd-clang | 1 +
config/defconfig_x86_64-native-freebsd-gcc | 1 +
config/defconfig_x86_64-native-linux-clang | 1 +
config/defconfig_x86_64-native-linux-gcc | 1 +
config/defconfig_x86_64-native-linux-icc | 1 +
config/defconfig_x86_64-native-linuxapp-clang | 2 +-
config/defconfig_x86_64-native-linuxapp-gcc | 2 +-
config/defconfig_x86_64-native-linuxapp-icc | 2 +-
config/defconfig_x86_x32-native-linux-gcc | 1 +
config/defconfig_x86_x32-native-linuxapp-gcc | 2 +-
config/rte_config.h | 8 ++
devtools/build-tags.sh | 12 +--
devtools/test-build.sh | 2 +-
devtools/test-meson-builds.sh | 2 +-
devtools/validate-abi.sh | 2 +-
doc/build-sdk-meson.txt | 4 +-
doc/build-sdk-quick.txt | 2 +-
doc/guides/compressdevs/octeontx.rst | 4 +-
doc/guides/contributing/design.rst | 8 +-
doc/guides/contributing/patches.rst | 14 +--
doc/guides/contributing/versioning.rst | 6 +-
doc/guides/cryptodevs/armv8.rst | 2 +-
doc/guides/cryptodevs/caam_jr.rst | 6 +-
doc/guides/cryptodevs/dpaa2_sec.rst | 2 +-
doc/guides/cryptodevs/dpaa_sec.rst | 2 +-
doc/guides/cryptodevs/openssl.rst | 2 +-
doc/guides/cryptodevs/virtio.rst | 8 +-
doc/guides/cryptodevs/zuc.rst | 2 +-
doc/guides/eventdevs/dpaa.rst | 2 +-
doc/guides/eventdevs/dpaa2.rst | 2 +-
doc/guides/eventdevs/octeontx.rst | 2 +-
doc/guides/freebsd_gsg/build_dpdk.rst | 6 +-
doc/guides/freebsd_gsg/build_sample_apps.rst | 10 +-
doc/guides/freebsd_gsg/install_from_ports.rst | 4 +-
doc/guides/freebsd_gsg/intro.rst | 4 +-
doc/guides/howto/lm_bond_virtio_sriov.rst | 4 +-
doc/guides/howto/lm_virtio_vhost_user.rst | 4 +-
doc/guides/howto/pvp_reference_benchmark.rst | 4 +-
.../virtio_user_for_container_networking.rst | 4 +-
doc/guides/linux_gsg/build_dpdk.rst | 10 +-
doc/guides/linux_gsg/build_sample_apps.rst | 6 +-
.../linux_gsg/cross_build_dpdk_for_arm64.rst | 6 +-
doc/guides/linux_gsg/intro.rst | 4 +-
.../linux_gsg/nic_perf_intel_platform.rst | 2 +-
doc/guides/linux_gsg/quick_start.rst | 26 ++---
doc/guides/mempool/octeontx.rst | 2 +-
doc/guides/nics/build_and_test.rst | 34 +++---
doc/guides/nics/cxgbe.rst | 6 +-
doc/guides/nics/dpaa.rst | 2 +-
doc/guides/nics/enic.rst | 2 +-
doc/guides/nics/intel_vf.rst | 10 +-
doc/guides/nics/mlx5.rst | 2 +-
doc/guides/nics/mvneta.rst | 2 +-
doc/guides/nics/mvpp2.rst | 4 +-
doc/guides/nics/nfp.rst | 2 +-
doc/guides/nics/octeontx.rst | 4 +-
doc/guides/nics/softnic.rst | 4 +-
doc/guides/nics/tap.rst | 2 +-
doc/guides/nics/thunderx.rst | 4 +-
doc/guides/platform/octeontx.rst | 6 +-
doc/guides/prog_guide/build_app.rst | 4 +-
.../prog_guide/dev_kit_build_system.rst | 8 +-
.../prog_guide/dev_kit_root_make_help.rst | 6 +-
.../prog_guide/env_abstraction_layer.rst | 10 +-
.../prog_guide/ext_app_lib_make_help.rst | 4 +-
doc/guides/prog_guide/extend_dpdk.rst | 4 +-
doc/guides/prog_guide/glossary.rst | 2 +-
doc/guides/prog_guide/img/linuxapp_launch.svg | 4 +-
doc/guides/prog_guide/intro.rst | 2 +-
doc/guides/prog_guide/overview.rst | 2 +-
doc/guides/prog_guide/profile_app.rst | 2 +-
doc/guides/prog_guide/qos_framework.rst | 2 +-
doc/guides/rawdevs/dpaa2_cmdif.rst | 2 +-
doc/guides/rawdevs/dpaa2_qdma.rst | 2 +-
doc/guides/rel_notes/release_19_02.rst | 2 +-
doc/guides/rel_notes/release_2_1.rst | 2 +-
doc/guides/sample_app_ug/bbdev_app.rst | 6 +-
doc/guides/sample_app_ug/cmd_line.rst | 2 +-
doc/guides/sample_app_ug/dist_app.rst | 2 +-
doc/guides/sample_app_ug/fips_validation.rst | 4 +-
doc/guides/sample_app_ug/flow_classify.rst | 2 +-
doc/guides/sample_app_ug/flow_filtering.rst | 4 +-
doc/guides/sample_app_ug/hello_world.rst | 4 +-
doc/guides/sample_app_ug/ip_frag.rst | 4 +-
doc/guides/sample_app_ug/ip_reassembly.rst | 4 +-
doc/guides/sample_app_ug/keep_alive.rst | 2 +-
.../sample_app_ug/kernel_nic_interface.rst | 2 +-
doc/guides/sample_app_ug/l2_forward_cat.rst | 2 +-
.../sample_app_ug/l2_forward_crypto.rst | 2 +-
.../sample_app_ug/l2_forward_job_stats.rst | 2 +-
.../sample_app_ug/l2_forward_real_virtual.rst | 2 +-
doc/guides/sample_app_ug/link_status_intr.rst | 2 +-
.../sample_app_ug/netmap_compatibility.rst | 2 +-
.../sample_app_ug/performance_thread.rst | 2 +-
doc/guides/sample_app_ug/ptpclient.rst | 4 +-
doc/guides/sample_app_ug/qos_scheduler.rst | 2 +-
doc/guides/sample_app_ug/quota_watermark.rst | 4 +-
doc/guides/sample_app_ug/rxtx_callbacks.rst | 2 +-
doc/guides/sample_app_ug/service_cores.rst | 2 +-
doc/guides/sample_app_ug/skeleton.rst | 2 +-
doc/guides/sample_app_ug/tep_termination.rst | 2 +-
doc/guides/sample_app_ug/timer.rst | 2 +-
.../sample_app_ug/vmdq_dcb_forwarding.rst | 4 +-
doc/guides/testpmd_app_ug/build_app.rst | 2 +-
doc/guides/tools/testbbdev.rst | 8 +-
drivers/bus/dpaa/Makefile | 2 +-
drivers/bus/pci/Makefile | 4 +-
drivers/bus/vmbus/Makefile | 4 +-
drivers/crypto/caam_jr/Makefile | 2 +-
drivers/crypto/dpaa2_sec/Makefile | 2 +-
drivers/crypto/dpaa_sec/Makefile | 2 +-
drivers/crypto/virtio/virtio_pci.c | 2 +-
drivers/event/dpaa/Makefile | 2 +-
drivers/event/dpaa2/Makefile | 2 +-
drivers/mempool/dpaa2/Makefile | 2 +-
drivers/net/ark/Makefile | 2 +-
drivers/net/dpaa/Makefile | 2 +-
drivers/net/dpaa2/Makefile | 2 +-
drivers/net/failsafe/Makefile | 2 +-
drivers/net/failsafe/failsafe_private.h | 2 +-
drivers/net/pcap/rte_eth_pcap.c | 6 +-
drivers/net/sfc/sfc_intr.c | 2 +-
drivers/net/softnic/Makefile | 2 +-
drivers/net/softnic/rte_eth_softnic_tap.c | 4 +-
drivers/net/virtio/virtio_pci.c | 2 +-
drivers/raw/dpaa2_qdma/Makefile | 2 +-
examples/Makefile | 2 +-
examples/bbdev_app/Makefile | 2 +-
examples/bond/Makefile | 2 +-
examples/cmdline/Makefile | 2 +-
examples/distributor/Makefile | 2 +-
examples/ethtool/Makefile | 6 +-
examples/ethtool/ethtool-app/Makefile | 2 +-
examples/ethtool/lib/Makefile | 6 +-
examples/eventdev_pipeline/Makefile | 2 +-
examples/exception_path/Makefile | 2 +-
examples/exception_path/main.c | 4 +-
examples/fips_validation/Makefile | 2 +-
examples/flow_classify/Makefile | 2 +-
examples/flow_filtering/Makefile | 2 +-
examples/helloworld/Makefile | 2 +-
examples/ip_fragmentation/Makefile | 2 +-
examples/ip_pipeline/Makefile | 6 +-
examples/ip_pipeline/tap.c | 4 +-
examples/ip_reassembly/Makefile | 2 +-
examples/ipsec-secgw/Makefile | 2 +-
examples/ipsec-secgw/test/common_defs.sh | 2 +-
examples/ipv4_multicast/Makefile | 2 +-
examples/kni/Makefile | 6 +-
examples/l2fwd-cat/Makefile | 2 +-
examples/l2fwd-crypto/Makefile | 2 +-
examples/l2fwd-jobstats/Makefile | 2 +-
examples/l2fwd-keepalive/Makefile | 2 +-
examples/l2fwd-keepalive/ka-agent/Makefile | 2 +-
examples/l2fwd/Makefile | 2 +-
examples/l3fwd-acl/Makefile | 2 +-
examples/l3fwd-power/Makefile | 6 +-
examples/l3fwd-vf/Makefile | 2 +-
examples/l3fwd/Makefile | 2 +-
examples/link_status_interrupt/Makefile | 2 +-
examples/load_balancer/Makefile | 2 +-
examples/multi_process/Makefile | 10 +-
.../multi_process/client_server_mp/Makefile | 6 +-
.../client_server_mp/mp_server/Makefile | 6 +-
examples/multi_process/hotplug_mp/Makefile | 2 +-
examples/multi_process/simple_mp/Makefile | 2 +-
examples/multi_process/symmetric_mp/Makefile | 2 +-
examples/netmap_compat/Makefile | 2 +-
examples/netmap_compat/bridge/Makefile | 6 +-
examples/packet_ordering/Makefile | 2 +-
examples/performance-thread/Makefile | 2 +-
.../performance-thread/l3fwd-thread/Makefile | 2 +-
.../performance-thread/pthread_shim/Makefile | 2 +-
.../pthread_shim/pthread_shim.c | 2 +-
examples/ptpclient/Makefile | 2 +-
examples/qos_meter/Makefile | 2 +-
examples/qos_sched/Makefile | 6 +-
examples/quota_watermark/Makefile | 6 +-
examples/quota_watermark/qw/Makefile | 2 +-
examples/quota_watermark/qwctl/Makefile | 2 +-
examples/rxtx_callbacks/Makefile | 2 +-
examples/server_node_efd/Makefile | 6 +-
examples/server_node_efd/server/Makefile | 6 +-
examples/service_cores/Makefile | 2 +-
examples/skeleton/Makefile | 2 +-
examples/tep_termination/Makefile | 6 +-
examples/timer/Makefile | 2 +-
examples/vdpa/Makefile | 4 +-
examples/vhost/Makefile | 6 +-
examples/vhost_crypto/Makefile | 6 +-
examples/vhost_scsi/Makefile | 6 +-
examples/vm_power_manager/Makefile | 2 +-
examples/vm_power_manager/guest_cli/Makefile | 2 +-
examples/vmdq/Makefile | 2 +-
examples/vmdq_dcb/Makefile | 2 +-
kernel/Makefile | 4 +-
kernel/freebsd/Makefile | 4 +-
kernel/linux/kni/meson.build | 2 +-
lib/Makefile | 2 +-
lib/librte_eal/Makefile | 8 +-
lib/librte_eal/bsdapp/eal/Makefile | 94 ----------------
lib/librte_eal/common/arch/x86/rte_cycles.c | 2 +-
lib/librte_eal/common/eal_common_errno.c | 2 +-
.../common/include/generic/rte_byteorder.h | 2 +-
lib/librte_eal/common/include/rte_debug.h | 2 +-
lib/librte_eal/common/include/rte_eal.h | 2 +-
.../common/include/rte_string_fns.h | 4 +-
.../{bsdapp => freebsd}/BSDmakefile.meson | 0
lib/librte_eal/{bsdapp => freebsd}/Makefile | 2 +-
lib/librte_eal/freebsd/eal/Makefile | 94 ++++++++++++++++
lib/librte_eal/{bsdapp => freebsd}/eal/eal.c | 0
.../{bsdapp => freebsd}/eal/eal_alarm.c | 0
.../eal/eal_alarm_private.h | 0
.../{bsdapp => freebsd}/eal/eal_cpuflags.c | 0
.../{bsdapp => freebsd}/eal/eal_debug.c | 0
.../{bsdapp => freebsd}/eal/eal_dev.c | 0
.../eal/eal_hugepage_info.c | 0
.../{bsdapp => freebsd}/eal/eal_interrupts.c | 0
.../{bsdapp => freebsd}/eal/eal_lcore.c | 0
.../{bsdapp => freebsd}/eal/eal_memalloc.c | 0
.../{bsdapp => freebsd}/eal/eal_memory.c | 0
.../{bsdapp => freebsd}/eal/eal_thread.c | 0
.../{bsdapp => freebsd}/eal/eal_timer.c | 0
.../{bsdapp => freebsd}/eal/meson.build | 0
lib/librte_eal/{linuxapp => linux}/Makefile | 2 +-
lib/librte_eal/linux/eal/Makefile | 101 ++++++++++++++++++
lib/librte_eal/{linuxapp => linux}/eal/eal.c | 0
.../{linuxapp => linux}/eal/eal_alarm.c | 0
.../{linuxapp => linux}/eal/eal_cpuflags.c | 0
.../{linuxapp => linux}/eal/eal_debug.c | 0
.../{linuxapp => linux}/eal/eal_dev.c | 0
.../eal/eal_hugepage_info.c | 0
.../{linuxapp => linux}/eal/eal_interrupts.c | 0
.../{linuxapp => linux}/eal/eal_lcore.c | 0
.../{linuxapp => linux}/eal/eal_log.c | 0
.../{linuxapp => linux}/eal/eal_memalloc.c | 0
.../{linuxapp => linux}/eal/eal_memory.c | 0
.../{linuxapp => linux}/eal/eal_thread.c | 0
.../{linuxapp => linux}/eal/eal_timer.c | 0
.../{linuxapp => linux}/eal/eal_vfio.c | 0
.../{linuxapp => linux}/eal/eal_vfio.h | 0
.../eal/eal_vfio_mp_sync.c | 0
.../eal/include/exec-env/rte_kni_common.h | 0
.../{linuxapp => linux}/eal/meson.build | 0
lib/librte_eal/linuxapp/eal/Makefile | 101 ------------------
lib/librte_eal/meson.build | 8 +-
lib/librte_eventdev/Makefile | 2 +-
lib/librte_kni/rte_kni.c | 2 +-
mk/exec-env/bsdapp | 1 +
mk/exec-env/{bsdapp => freebsd}/rte.app.mk | 0
mk/exec-env/{bsdapp => freebsd}/rte.vars.mk | 2 +-
mk/exec-env/{linuxapp => linux}/rte.app.mk | 0
mk/exec-env/{linuxapp => linux}/rte.vars.mk | 2 +-
mk/exec-env/linuxapp | 1 +
mk/rte.app.mk | 4 +-
mk/rte.sdkconfig.mk | 9 +-
mk/rte.sdkinstall.mk | 3 +
mk/rte.sdkroot.mk | 2 +-
usertools/dpdk-setup.sh | 4 +-
311 files changed, 668 insertions(+), 635 deletions(-)
rename config/arm/{arm64_armv8_linuxapp_gcc => arm64_armv8_linux_gcc} (100%)
rename config/arm/{arm64_dpaa2_linuxapp_gcc => arm64_dpaa2_linux_gcc} (100%)
rename config/arm/{arm64_dpaa_linuxapp_gcc => arm64_dpaa_linux_gcc} (100%)
rename config/arm/{arm64_thunderx_linuxapp_gcc => arm64_thunderx_linux_gcc} (100%)
rename config/{common_armv8a_linuxapp => common_armv8a_linux} (97%)
rename config/{common_bsdapp => common_freebsd} (91%)
rename config/{common_linuxapp => common_linux} (98%)
create mode 120000 config/defconfig_arm-armv7a-linux-gcc
create mode 120000 config/defconfig_arm64-armv8a-linux-clang
create mode 120000 config/defconfig_arm64-armv8a-linux-gcc
create mode 120000 config/defconfig_arm64-bluefield-linux-gcc
create mode 120000 config/defconfig_arm64-dpaa-linux-gcc
create mode 120000 config/defconfig_arm64-dpaa2-linux-gcc
create mode 120000 config/defconfig_arm64-stingray-linux-gcc
create mode 120000 config/defconfig_arm64-thunderx-linux-gcc
create mode 120000 config/defconfig_arm64-xgene1-linux-gcc
create mode 120000 config/defconfig_i686-native-linux-gcc
create mode 120000 config/defconfig_i686-native-linux-icc
create mode 120000 config/defconfig_ppc_64-power8-linux-gcc
create mode 120000 config/defconfig_x86_64-native-freebsd-clang
create mode 120000 config/defconfig_x86_64-native-freebsd-gcc
create mode 120000 config/defconfig_x86_64-native-linux-clang
create mode 120000 config/defconfig_x86_64-native-linux-gcc
create mode 120000 config/defconfig_x86_64-native-linux-icc
create mode 120000 config/defconfig_x86_x32-native-linux-gcc
delete mode 100644 lib/librte_eal/bsdapp/eal/Makefile
rename lib/librte_eal/{bsdapp => freebsd}/BSDmakefile.meson (100%)
rename lib/librte_eal/{bsdapp => freebsd}/Makefile (78%)
create mode 100644 lib/librte_eal/freebsd/eal/Makefile
rename lib/librte_eal/{bsdapp => freebsd}/eal/eal.c (100%)
rename lib/librte_eal/{bsdapp => freebsd}/eal/eal_alarm.c (100%)
rename lib/librte_eal/{bsdapp => freebsd}/eal/eal_alarm_private.h (100%)
rename lib/librte_eal/{bsdapp => freebsd}/eal/eal_cpuflags.c (100%)
rename lib/librte_eal/{bsdapp => freebsd}/eal/eal_debug.c (100%)
rename lib/librte_eal/{bsdapp => freebsd}/eal/eal_dev.c (100%)
rename lib/librte_eal/{bsdapp => freebsd}/eal/eal_hugepage_info.c (100%)
rename lib/librte_eal/{bsdapp => freebsd}/eal/eal_interrupts.c (100%)
rename lib/librte_eal/{bsdapp => freebsd}/eal/eal_lcore.c (100%)
rename lib/librte_eal/{bsdapp => freebsd}/eal/eal_memalloc.c (100%)
rename lib/librte_eal/{bsdapp => freebsd}/eal/eal_memory.c (100%)
rename lib/librte_eal/{bsdapp => freebsd}/eal/eal_thread.c (100%)
rename lib/librte_eal/{bsdapp => freebsd}/eal/eal_timer.c (100%)
rename lib/librte_eal/{bsdapp => freebsd}/eal/meson.build (100%)
rename lib/librte_eal/{linuxapp => linux}/Makefile (82%)
create mode 100644 lib/librte_eal/linux/eal/Makefile
rename lib/librte_eal/{linuxapp => linux}/eal/eal.c (100%)
rename lib/librte_eal/{linuxapp => linux}/eal/eal_alarm.c (100%)
rename lib/librte_eal/{linuxapp => linux}/eal/eal_cpuflags.c (100%)
rename lib/librte_eal/{linuxapp => linux}/eal/eal_debug.c (100%)
rename lib/librte_eal/{linuxapp => linux}/eal/eal_dev.c (100%)
rename lib/librte_eal/{linuxapp => linux}/eal/eal_hugepage_info.c (100%)
rename lib/librte_eal/{linuxapp => linux}/eal/eal_interrupts.c (100%)
rename lib/librte_eal/{linuxapp => linux}/eal/eal_lcore.c (100%)
rename lib/librte_eal/{linuxapp => linux}/eal/eal_log.c (100%)
rename lib/librte_eal/{linuxapp => linux}/eal/eal_memalloc.c (100%)
rename lib/librte_eal/{linuxapp => linux}/eal/eal_memory.c (100%)
rename lib/librte_eal/{linuxapp => linux}/eal/eal_thread.c (100%)
rename lib/librte_eal/{linuxapp => linux}/eal/eal_timer.c (100%)
rename lib/librte_eal/{linuxapp => linux}/eal/eal_vfio.c (100%)
rename lib/librte_eal/{linuxapp => linux}/eal/eal_vfio.h (100%)
rename lib/librte_eal/{linuxapp => linux}/eal/eal_vfio_mp_sync.c (100%)
rename lib/librte_eal/{linuxapp => linux}/eal/include/exec-env/rte_kni_common.h (100%)
rename lib/librte_eal/{linuxapp => linux}/eal/meson.build (100%)
delete mode 100644 lib/librte_eal/linuxapp/eal/Makefile
create mode 120000 mk/exec-env/bsdapp
rename mk/exec-env/{bsdapp => freebsd}/rte.app.mk (100%)
rename mk/exec-env/{bsdapp => freebsd}/rte.vars.mk (94%)
rename mk/exec-env/{linuxapp => linux}/rte.app.mk (100%)
rename mk/exec-env/{linuxapp => linux}/rte.vars.mk (95%)
create mode 120000 mk/exec-env/linuxapp
--
2.20.1
^ permalink raw reply [relevance 1%]
* [dpdk-dev] [PATCH 6/6] build: allow linux and freebsd in build configs
2019-03-06 16:22 1% [dpdk-dev] [RFC PATCH 0/6] change legacy linuxapp/bsdapp names Bruce Richardson
@ 2019-03-06 16:22 7% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2019-03-06 16:22 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson
Rather than using linuxapp and bsdapp everywhere, we can change things to
use the, more readable, terms "linux" and "freebsd" in our build configs.
Rather than renaming the configs we can just duplicate the existing ones
with the new names using symlinks, and use the new names exclusively
internally. ["make showconfigs" also only shows the new names to keep the
list short] The result is that backward compatibility is kept fully but any
new builds or development can be done using the newer names, i.e. both
"make config T=x86_64-native-linuxapp-gcc" and "T=x86_64-native-linux-gcc"
work.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
app/test-bbdev/test-bbdev.py | 2 +-
app/test/autotest.py | 2 +-
app/test/test.c | 2 +-
...on_armv8a_linuxapp => common_armv8a_linux} | 2 +-
config/{common_bsdapp => common_freebsd} | 0
config/{common_linuxapp => common_linux} | 0
config/defconfig_arm-armv7a-linux-gcc | 1 +
config/defconfig_arm-armv7a-linuxapp-gcc | 2 +-
config/defconfig_arm64-armv8a-linux-clang | 1 +
config/defconfig_arm64-armv8a-linux-gcc | 1 +
config/defconfig_arm64-armv8a-linuxapp-clang | 2 +-
config/defconfig_arm64-armv8a-linuxapp-gcc | 2 +-
config/defconfig_arm64-bluefield-linux-gcc | 1 +
config/defconfig_arm64-bluefield-linuxapp-gcc | 2 +-
config/defconfig_arm64-dpaa-linux-gcc | 1 +
config/defconfig_arm64-dpaa-linuxapp-gcc | 2 +-
config/defconfig_arm64-dpaa2-linux-gcc | 1 +
config/defconfig_arm64-dpaa2-linuxapp-gcc | 2 +-
config/defconfig_arm64-stingray-linux-gcc | 1 +
config/defconfig_arm64-stingray-linuxapp-gcc | 2 +-
config/defconfig_arm64-thunderx-linux-gcc | 1 +
config/defconfig_arm64-thunderx-linuxapp-gcc | 2 +-
config/defconfig_arm64-xgene1-linux-gcc | 1 +
config/defconfig_arm64-xgene1-linuxapp-gcc | 2 +-
config/defconfig_i686-native-linux-gcc | 1 +
config/defconfig_i686-native-linux-icc | 1 +
config/defconfig_i686-native-linuxapp-gcc | 2 +-
config/defconfig_i686-native-linuxapp-icc | 2 +-
config/defconfig_ppc_64-power8-linux-gcc | 1 +
config/defconfig_ppc_64-power8-linuxapp-gcc | 2 +-
config/defconfig_x86_64-native-bsdapp-clang | 2 +-
config/defconfig_x86_64-native-bsdapp-gcc | 2 +-
config/defconfig_x86_64-native-freebsd-clang | 1 +
config/defconfig_x86_64-native-freebsd-gcc | 1 +
config/defconfig_x86_64-native-linux-clang | 1 +
config/defconfig_x86_64-native-linux-gcc | 1 +
config/defconfig_x86_64-native-linux-icc | 1 +
config/defconfig_x86_64-native-linuxapp-clang | 2 +-
config/defconfig_x86_64-native-linuxapp-gcc | 2 +-
config/defconfig_x86_64-native-linuxapp-icc | 2 +-
config/defconfig_x86_x32-native-linux-gcc | 1 +
config/defconfig_x86_x32-native-linuxapp-gcc | 2 +-
devtools/build-tags.sh | 8 ++---
devtools/test-build.sh | 2 +-
devtools/validate-abi.sh | 2 +-
doc/build-sdk-quick.txt | 2 +-
doc/guides/compressdevs/octeontx.rst | 4 +--
doc/guides/contributing/design.rst | 6 ++--
doc/guides/contributing/patches.rst | 14 ++++----
doc/guides/contributing/versioning.rst | 6 ++--
doc/guides/cryptodevs/armv8.rst | 2 +-
doc/guides/cryptodevs/caam_jr.rst | 6 ++--
doc/guides/cryptodevs/dpaa2_sec.rst | 2 +-
doc/guides/cryptodevs/dpaa_sec.rst | 2 +-
doc/guides/cryptodevs/openssl.rst | 2 +-
doc/guides/cryptodevs/virtio.rst | 8 ++---
doc/guides/cryptodevs/zuc.rst | 2 +-
doc/guides/eventdevs/dpaa.rst | 2 +-
doc/guides/eventdevs/dpaa2.rst | 2 +-
doc/guides/eventdevs/octeontx.rst | 2 +-
doc/guides/freebsd_gsg/build_dpdk.rst | 6 ++--
doc/guides/freebsd_gsg/build_sample_apps.rst | 10 +++---
doc/guides/freebsd_gsg/install_from_ports.rst | 4 +--
doc/guides/freebsd_gsg/intro.rst | 4 +--
doc/guides/howto/lm_bond_virtio_sriov.rst | 4 +--
doc/guides/howto/lm_virtio_vhost_user.rst | 4 +--
doc/guides/howto/pvp_reference_benchmark.rst | 4 +--
.../virtio_user_for_container_networking.rst | 4 +--
doc/guides/linux_gsg/build_dpdk.rst | 10 +++---
doc/guides/linux_gsg/build_sample_apps.rst | 6 ++--
.../linux_gsg/cross_build_dpdk_for_arm64.rst | 6 ++--
doc/guides/linux_gsg/intro.rst | 4 +--
.../linux_gsg/nic_perf_intel_platform.rst | 2 +-
doc/guides/linux_gsg/quick_start.rst | 26 +++++++-------
doc/guides/mempool/octeontx.rst | 2 +-
doc/guides/nics/build_and_test.rst | 34 +++++++++----------
doc/guides/nics/cxgbe.rst | 6 ++--
doc/guides/nics/dpaa.rst | 2 +-
doc/guides/nics/enic.rst | 2 +-
doc/guides/nics/intel_vf.rst | 10 +++---
doc/guides/nics/mlx5.rst | 2 +-
doc/guides/nics/mvneta.rst | 2 +-
doc/guides/nics/mvpp2.rst | 4 +--
doc/guides/nics/nfp.rst | 2 +-
doc/guides/nics/octeontx.rst | 4 +--
doc/guides/nics/softnic.rst | 4 +--
doc/guides/nics/tap.rst | 2 +-
doc/guides/nics/thunderx.rst | 4 +--
doc/guides/platform/octeontx.rst | 6 ++--
doc/guides/prog_guide/build_app.rst | 4 +--
.../prog_guide/dev_kit_build_system.rst | 8 ++---
.../prog_guide/dev_kit_root_make_help.rst | 6 ++--
.../prog_guide/env_abstraction_layer.rst | 6 ++--
.../prog_guide/ext_app_lib_make_help.rst | 4 +--
doc/guides/prog_guide/extend_dpdk.rst | 4 +--
doc/guides/prog_guide/glossary.rst | 2 +-
doc/guides/prog_guide/img/linuxapp_launch.svg | 4 +--
doc/guides/prog_guide/intro.rst | 2 +-
doc/guides/prog_guide/overview.rst | 2 +-
doc/guides/prog_guide/profile_app.rst | 2 +-
doc/guides/prog_guide/qos_framework.rst | 2 +-
doc/guides/rawdevs/dpaa2_cmdif.rst | 2 +-
doc/guides/rawdevs/dpaa2_qdma.rst | 2 +-
doc/guides/rel_notes/release_19_02.rst | 2 +-
doc/guides/rel_notes/release_2_1.rst | 2 +-
doc/guides/sample_app_ug/bbdev_app.rst | 6 ++--
doc/guides/sample_app_ug/cmd_line.rst | 2 +-
doc/guides/sample_app_ug/dist_app.rst | 2 +-
doc/guides/sample_app_ug/fips_validation.rst | 4 +--
doc/guides/sample_app_ug/flow_classify.rst | 2 +-
doc/guides/sample_app_ug/flow_filtering.rst | 4 +--
doc/guides/sample_app_ug/hello_world.rst | 4 +--
doc/guides/sample_app_ug/ip_frag.rst | 4 +--
doc/guides/sample_app_ug/ip_reassembly.rst | 4 +--
doc/guides/sample_app_ug/keep_alive.rst | 2 +-
.../sample_app_ug/kernel_nic_interface.rst | 2 +-
doc/guides/sample_app_ug/l2_forward_cat.rst | 2 +-
.../sample_app_ug/l2_forward_crypto.rst | 2 +-
.../sample_app_ug/l2_forward_job_stats.rst | 2 +-
.../sample_app_ug/l2_forward_real_virtual.rst | 2 +-
doc/guides/sample_app_ug/link_status_intr.rst | 2 +-
.../sample_app_ug/netmap_compatibility.rst | 2 +-
.../sample_app_ug/performance_thread.rst | 2 +-
doc/guides/sample_app_ug/ptpclient.rst | 4 +--
doc/guides/sample_app_ug/qos_scheduler.rst | 2 +-
doc/guides/sample_app_ug/quota_watermark.rst | 4 +--
doc/guides/sample_app_ug/rxtx_callbacks.rst | 2 +-
doc/guides/sample_app_ug/service_cores.rst | 2 +-
doc/guides/sample_app_ug/skeleton.rst | 2 +-
doc/guides/sample_app_ug/tep_termination.rst | 2 +-
doc/guides/sample_app_ug/timer.rst | 2 +-
.../sample_app_ug/vmdq_dcb_forwarding.rst | 4 +--
doc/guides/testpmd_app_ug/build_app.rst | 2 +-
doc/guides/tools/testbbdev.rst | 8 ++---
drivers/net/softnic/Makefile | 2 +-
examples/Makefile | 2 +-
examples/bbdev_app/Makefile | 2 +-
examples/bond/Makefile | 2 +-
examples/cmdline/Makefile | 2 +-
examples/distributor/Makefile | 2 +-
examples/ethtool/Makefile | 4 +--
examples/ethtool/ethtool-app/Makefile | 2 +-
examples/ethtool/lib/Makefile | 4 +--
examples/eventdev_pipeline/Makefile | 2 +-
examples/exception_path/Makefile | 2 +-
examples/fips_validation/Makefile | 2 +-
examples/flow_classify/Makefile | 2 +-
examples/flow_filtering/Makefile | 2 +-
examples/helloworld/Makefile | 2 +-
examples/ip_fragmentation/Makefile | 2 +-
examples/ip_pipeline/Makefile | 4 +--
examples/ip_reassembly/Makefile | 2 +-
examples/ipsec-secgw/Makefile | 2 +-
examples/ipsec-secgw/test/common_defs.sh | 2 +-
examples/ipv4_multicast/Makefile | 2 +-
examples/kni/Makefile | 4 +--
examples/l2fwd-cat/Makefile | 2 +-
examples/l2fwd-crypto/Makefile | 2 +-
examples/l2fwd-jobstats/Makefile | 2 +-
examples/l2fwd-keepalive/Makefile | 2 +-
examples/l2fwd-keepalive/ka-agent/Makefile | 2 +-
examples/l2fwd/Makefile | 2 +-
examples/l3fwd-acl/Makefile | 2 +-
examples/l3fwd-power/Makefile | 4 +--
examples/l3fwd-vf/Makefile | 2 +-
examples/l3fwd/Makefile | 2 +-
examples/link_status_interrupt/Makefile | 2 +-
examples/load_balancer/Makefile | 2 +-
examples/multi_process/Makefile | 2 +-
.../multi_process/client_server_mp/Makefile | 2 +-
.../client_server_mp/mp_server/Makefile | 4 +--
examples/multi_process/hotplug_mp/Makefile | 2 +-
examples/multi_process/simple_mp/Makefile | 2 +-
examples/multi_process/symmetric_mp/Makefile | 2 +-
examples/netmap_compat/Makefile | 2 +-
examples/netmap_compat/bridge/Makefile | 4 +--
examples/packet_ordering/Makefile | 2 +-
examples/performance-thread/Makefile | 2 +-
.../performance-thread/l3fwd-thread/Makefile | 2 +-
.../performance-thread/pthread_shim/Makefile | 2 +-
examples/ptpclient/Makefile | 2 +-
examples/qos_meter/Makefile | 2 +-
examples/qos_sched/Makefile | 4 +--
examples/quota_watermark/Makefile | 2 +-
examples/quota_watermark/qw/Makefile | 2 +-
examples/quota_watermark/qwctl/Makefile | 2 +-
examples/rxtx_callbacks/Makefile | 2 +-
examples/server_node_efd/Makefile | 2 +-
examples/server_node_efd/server/Makefile | 4 +--
examples/service_cores/Makefile | 2 +-
examples/skeleton/Makefile | 2 +-
examples/tep_termination/Makefile | 4 +--
examples/timer/Makefile | 2 +-
examples/vdpa/Makefile | 4 +--
examples/vhost/Makefile | 4 +--
examples/vhost_crypto/Makefile | 4 +--
examples/vhost_scsi/Makefile | 4 +--
examples/vm_power_manager/Makefile | 2 +-
examples/vm_power_manager/guest_cli/Makefile | 2 +-
examples/vmdq/Makefile | 2 +-
examples/vmdq_dcb/Makefile | 2 +-
lib/librte_eal/common/include/rte_debug.h | 2 +-
lib/librte_eal/common/include/rte_eal.h | 2 +-
lib/librte_eal/freebsd/eal/Makefile | 4 +--
lib/librte_eal/linux/eal/Makefile | 2 +-
mk/exec-env/bsdapp | 1 +
mk/exec-env/{bsdapp => freebsd}/rte.app.mk | 0
mk/exec-env/{bsdapp => freebsd}/rte.vars.mk | 2 +-
mk/exec-env/{linuxapp => linux}/rte.app.mk | 0
mk/exec-env/{linuxapp => linux}/rte.vars.mk | 2 +-
mk/exec-env/linuxapp | 1 +
mk/rte.sdkconfig.mk | 9 ++---
mk/rte.sdkinstall.mk | 3 ++
mk/rte.sdkroot.mk | 2 +-
usertools/dpdk-setup.sh | 4 +--
215 files changed, 337 insertions(+), 313 deletions(-)
rename config/{common_armv8a_linuxapp => common_armv8a_linux} (97%)
rename config/{common_bsdapp => common_freebsd} (100%)
rename config/{common_linuxapp => common_linux} (100%)
create mode 120000 config/defconfig_arm-armv7a-linux-gcc
create mode 120000 config/defconfig_arm64-armv8a-linux-clang
create mode 120000 config/defconfig_arm64-armv8a-linux-gcc
create mode 120000 config/defconfig_arm64-bluefield-linux-gcc
create mode 120000 config/defconfig_arm64-dpaa-linux-gcc
create mode 120000 config/defconfig_arm64-dpaa2-linux-gcc
create mode 120000 config/defconfig_arm64-stingray-linux-gcc
create mode 120000 config/defconfig_arm64-thunderx-linux-gcc
create mode 120000 config/defconfig_arm64-xgene1-linux-gcc
create mode 120000 config/defconfig_i686-native-linux-gcc
create mode 120000 config/defconfig_i686-native-linux-icc
create mode 120000 config/defconfig_ppc_64-power8-linux-gcc
create mode 120000 config/defconfig_x86_64-native-freebsd-clang
create mode 120000 config/defconfig_x86_64-native-freebsd-gcc
create mode 120000 config/defconfig_x86_64-native-linux-clang
create mode 120000 config/defconfig_x86_64-native-linux-gcc
create mode 120000 config/defconfig_x86_64-native-linux-icc
create mode 120000 config/defconfig_x86_x32-native-linux-gcc
create mode 120000 mk/exec-env/bsdapp
rename mk/exec-env/{bsdapp => freebsd}/rte.app.mk (100%)
rename mk/exec-env/{bsdapp => freebsd}/rte.vars.mk (94%)
rename mk/exec-env/{linuxapp => linux}/rte.app.mk (100%)
rename mk/exec-env/{linuxapp => linux}/rte.vars.mk (95%)
create mode 120000 mk/exec-env/linuxapp
diff --git a/app/test-bbdev/test-bbdev.py b/app/test-bbdev/test-bbdev.py
index acab9eb16..25340ec8e 100755
--- a/app/test-bbdev/test-bbdev.py
+++ b/app/test-bbdev/test-bbdev.py
@@ -23,7 +23,7 @@ def kill(process):
if "RTE_TARGET" in os.environ:
dpdk_target = os.environ["RTE_TARGET"]
else:
- dpdk_target = "x86_64-native-linuxapp-gcc"
+ dpdk_target = "x86_64-native-linux-gcc"
parser = argparse.ArgumentParser(
description='BBdev Unit Test Application',
diff --git a/app/test/autotest.py b/app/test/autotest.py
index 12997fdf0..46c469eee 100644
--- a/app/test/autotest.py
+++ b/app/test/autotest.py
@@ -38,7 +38,7 @@ def usage():
# how many workers to run tests with. FreeBSD doesn't support multiple primary
# processes, so make it 1, otherwise make it 4. ignored for non-parallel tests
-n_processes = 1 if "bsdapp" in target else 4
+n_processes = 1 if "bsd" in target else 4
runner = autotest_runner.AutotestRunner(cmdline, target, test_blacklist,
test_whitelist, n_processes)
diff --git a/app/test/test.c b/app/test/test.c
index 351c7f275..d646f5160 100644
--- a/app/test/test.c
+++ b/app/test/test.c
@@ -36,7 +36,7 @@ extern cmdline_parse_ctx_t main_ctx[];
const char *prgname; /* to be set to argv[0] */
-static const char *recursive_call; /* used in linuxapp for MP and other tests */
+static const char *recursive_call; /* used in linux for MP and other tests */
static int
no_action(void){ return 0; }
diff --git a/config/common_armv8a_linuxapp b/config/common_armv8a_linux
similarity index 97%
rename from config/common_armv8a_linuxapp
rename to config/common_armv8a_linux
index ad88a37b1..72091de1c 100644
--- a/config/common_armv8a_linuxapp
+++ b/config/common_armv8a_linux
@@ -2,7 +2,7 @@
# Copyright(c) 2017 Cavium, Inc
#
-#include "common_linuxapp"
+#include "common_linux"
CONFIG_RTE_MACHINE="armv8a"
diff --git a/config/common_bsdapp b/config/common_freebsd
similarity index 100%
rename from config/common_bsdapp
rename to config/common_freebsd
diff --git a/config/common_linuxapp b/config/common_linux
similarity index 100%
rename from config/common_linuxapp
rename to config/common_linux
diff --git a/config/defconfig_arm-armv7a-linux-gcc b/config/defconfig_arm-armv7a-linux-gcc
new file mode 120000
index 000000000..84619de43
--- /dev/null
+++ b/config/defconfig_arm-armv7a-linux-gcc
@@ -0,0 +1 @@
+defconfig_arm-armv7a-linuxapp-gcc
\ No newline at end of file
diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc b/config/defconfig_arm-armv7a-linuxapp-gcc
index 63f3a507b..c9509b274 100644
--- a/config/defconfig_arm-armv7a-linuxapp-gcc
+++ b/config/defconfig_arm-armv7a-linuxapp-gcc
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright (C) 2015 RehiveTech. All right reserved.
-#include "common_linuxapp"
+#include "common_linux"
CONFIG_RTE_MACHINE="armv7a"
diff --git a/config/defconfig_arm64-armv8a-linux-clang b/config/defconfig_arm64-armv8a-linux-clang
new file mode 120000
index 000000000..196808b98
--- /dev/null
+++ b/config/defconfig_arm64-armv8a-linux-clang
@@ -0,0 +1 @@
+defconfig_arm64-armv8a-linuxapp-clang
\ No newline at end of file
diff --git a/config/defconfig_arm64-armv8a-linux-gcc b/config/defconfig_arm64-armv8a-linux-gcc
new file mode 120000
index 000000000..094951956
--- /dev/null
+++ b/config/defconfig_arm64-armv8a-linux-gcc
@@ -0,0 +1 @@
+defconfig_arm64-armv8a-linuxapp-gcc
\ No newline at end of file
diff --git a/config/defconfig_arm64-armv8a-linuxapp-clang b/config/defconfig_arm64-armv8a-linuxapp-clang
index 487714ea0..d3b4dad53 100644
--- a/config/defconfig_arm64-armv8a-linuxapp-clang
+++ b/config/defconfig_arm64-armv8a-linuxapp-clang
@@ -2,7 +2,7 @@
# Copyright(c) 2017 Cavium, Inc
#
-#include "common_armv8a_linuxapp"
+#include "common_armv8a_linux"
CONFIG_RTE_TOOLCHAIN="clang"
CONFIG_RTE_TOOLCHAIN_CLANG=y
diff --git a/config/defconfig_arm64-armv8a-linuxapp-gcc b/config/defconfig_arm64-armv8a-linuxapp-gcc
index a6ed90c51..58c4a4029 100644
--- a/config/defconfig_arm64-armv8a-linuxapp-gcc
+++ b/config/defconfig_arm64-armv8a-linuxapp-gcc
@@ -2,7 +2,7 @@
# Copyright(c) 2015 Cavium, Inc
#
-#include "common_armv8a_linuxapp"
+#include "common_armv8a_linux"
CONFIG_RTE_TOOLCHAIN="gcc"
CONFIG_RTE_TOOLCHAIN_GCC=y
diff --git a/config/defconfig_arm64-bluefield-linux-gcc b/config/defconfig_arm64-bluefield-linux-gcc
new file mode 120000
index 000000000..dad37d5e7
--- /dev/null
+++ b/config/defconfig_arm64-bluefield-linux-gcc
@@ -0,0 +1 @@
+defconfig_arm64-bluefield-linuxapp-gcc
\ No newline at end of file
diff --git a/config/defconfig_arm64-bluefield-linuxapp-gcc b/config/defconfig_arm64-bluefield-linuxapp-gcc
index dd252c0e4..b49653881 100644
--- a/config/defconfig_arm64-bluefield-linuxapp-gcc
+++ b/config/defconfig_arm64-bluefield-linuxapp-gcc
@@ -2,7 +2,7 @@
# Copyright 2019 Mellanox Technologies, Ltd
#
-#include "defconfig_arm64-armv8a-linuxapp-gcc"
+#include "defconfig_arm64-armv8a-linux-gcc"
# Mellanox BlueField
CONFIG_RTE_ARCH_ARM_TUNE="cortex-a72"
diff --git a/config/defconfig_arm64-dpaa-linux-gcc b/config/defconfig_arm64-dpaa-linux-gcc
new file mode 120000
index 000000000..dc05caacf
--- /dev/null
+++ b/config/defconfig_arm64-dpaa-linux-gcc
@@ -0,0 +1 @@
+defconfig_arm64-dpaa-linuxapp-gcc
\ No newline at end of file
diff --git a/config/defconfig_arm64-dpaa-linuxapp-gcc b/config/defconfig_arm64-dpaa-linuxapp-gcc
index 544b6770d..b408d4f48 100644
--- a/config/defconfig_arm64-dpaa-linuxapp-gcc
+++ b/config/defconfig_arm64-dpaa-linuxapp-gcc
@@ -2,7 +2,7 @@
# Copyright 2016 Freescale Semiconductor, Inc.
# Copyright 2017 NXP
-#include "defconfig_arm64-armv8a-linuxapp-gcc"
+#include "defconfig_arm64-armv8a-linux-gcc"
# NXP (Freescale) - Soc Architecture with FMAN, QMAN & BMAN support
CONFIG_RTE_MACHINE="dpaa"
diff --git a/config/defconfig_arm64-dpaa2-linux-gcc b/config/defconfig_arm64-dpaa2-linux-gcc
new file mode 120000
index 000000000..9a6c6c4cb
--- /dev/null
+++ b/config/defconfig_arm64-dpaa2-linux-gcc
@@ -0,0 +1 @@
+defconfig_arm64-dpaa2-linuxapp-gcc
\ No newline at end of file
diff --git a/config/defconfig_arm64-dpaa2-linuxapp-gcc b/config/defconfig_arm64-dpaa2-linuxapp-gcc
index 96f478a06..8b545f5f7 100644
--- a/config/defconfig_arm64-dpaa2-linuxapp-gcc
+++ b/config/defconfig_arm64-dpaa2-linuxapp-gcc
@@ -3,7 +3,7 @@
# Copyright 2016 NXP
#
-#include "defconfig_arm64-armv8a-linuxapp-gcc"
+#include "defconfig_arm64-armv8a-linux-gcc"
# NXP (Freescale) - Soc Architecture with WRIOP and QBMAN support
CONFIG_RTE_MACHINE="dpaa2"
diff --git a/config/defconfig_arm64-stingray-linux-gcc b/config/defconfig_arm64-stingray-linux-gcc
new file mode 120000
index 000000000..829dd65f0
--- /dev/null
+++ b/config/defconfig_arm64-stingray-linux-gcc
@@ -0,0 +1 @@
+defconfig_arm64-stingray-linuxapp-gcc
\ No newline at end of file
diff --git a/config/defconfig_arm64-stingray-linuxapp-gcc b/config/defconfig_arm64-stingray-linuxapp-gcc
index 999250723..7b33aa7af 100644
--- a/config/defconfig_arm64-stingray-linuxapp-gcc
+++ b/config/defconfig_arm64-stingray-linuxapp-gcc
@@ -2,7 +2,7 @@
# Copyright (C) Broadcom 2017-2018. All rights reserved.
#
-#include "defconfig_arm64-armv8a-linuxapp-gcc"
+#include "defconfig_arm64-armv8a-linux-gcc"
# Broadcom - Stingray
CONFIG_RTE_MACHINE="armv8a"
diff --git a/config/defconfig_arm64-thunderx-linux-gcc b/config/defconfig_arm64-thunderx-linux-gcc
new file mode 120000
index 000000000..1b9c4ad21
--- /dev/null
+++ b/config/defconfig_arm64-thunderx-linux-gcc
@@ -0,0 +1 @@
+defconfig_arm64-thunderx-linuxapp-gcc
\ No newline at end of file
diff --git a/config/defconfig_arm64-thunderx-linuxapp-gcc b/config/defconfig_arm64-thunderx-linuxapp-gcc
index fd160aa04..a52f06651 100644
--- a/config/defconfig_arm64-thunderx-linuxapp-gcc
+++ b/config/defconfig_arm64-thunderx-linuxapp-gcc
@@ -2,7 +2,7 @@
# Copyright(c) 2015 Cavium, Inc
#
-#include "defconfig_arm64-armv8a-linuxapp-gcc"
+#include "defconfig_arm64-armv8a-linux-gcc"
CONFIG_RTE_MACHINE="thunderx"
diff --git a/config/defconfig_arm64-xgene1-linux-gcc b/config/defconfig_arm64-xgene1-linux-gcc
new file mode 120000
index 000000000..d5e8b5e55
--- /dev/null
+++ b/config/defconfig_arm64-xgene1-linux-gcc
@@ -0,0 +1 @@
+defconfig_arm64-xgene1-linuxapp-gcc
\ No newline at end of file
diff --git a/config/defconfig_arm64-xgene1-linuxapp-gcc b/config/defconfig_arm64-xgene1-linuxapp-gcc
index a2dd465b7..fbf576c4a 100644
--- a/config/defconfig_arm64-xgene1-linuxapp-gcc
+++ b/config/defconfig_arm64-xgene1-linuxapp-gcc
@@ -2,7 +2,7 @@
# Copyright(c) 2015 Cavium, Inc
#
-#include "defconfig_arm64-armv8a-linuxapp-gcc"
+#include "defconfig_arm64-armv8a-linux-gcc"
CONFIG_RTE_MACHINE="xgene1"
CONFIG_RTE_CACHE_LINE_SIZE=64
diff --git a/config/defconfig_i686-native-linux-gcc b/config/defconfig_i686-native-linux-gcc
new file mode 120000
index 000000000..927141d5d
--- /dev/null
+++ b/config/defconfig_i686-native-linux-gcc
@@ -0,0 +1 @@
+defconfig_i686-native-linuxapp-gcc
\ No newline at end of file
diff --git a/config/defconfig_i686-native-linux-icc b/config/defconfig_i686-native-linux-icc
new file mode 120000
index 000000000..e6a466b3e
--- /dev/null
+++ b/config/defconfig_i686-native-linux-icc
@@ -0,0 +1 @@
+defconfig_i686-native-linuxapp-icc
\ No newline at end of file
diff --git a/config/defconfig_i686-native-linuxapp-gcc b/config/defconfig_i686-native-linuxapp-gcc
index 9b7086859..0340c84cf 100644
--- a/config/defconfig_i686-native-linuxapp-gcc
+++ b/config/defconfig_i686-native-linuxapp-gcc
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2010-2014 Intel Corporation
-#include "common_linuxapp"
+#include "common_linux"
CONFIG_RTE_MACHINE="native"
diff --git a/config/defconfig_i686-native-linuxapp-icc b/config/defconfig_i686-native-linuxapp-icc
index 17defd803..34a55fd18 100644
--- a/config/defconfig_i686-native-linuxapp-icc
+++ b/config/defconfig_i686-native-linuxapp-icc
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2010-2014 Intel Corporation
-#include "common_linuxapp"
+#include "common_linux"
CONFIG_RTE_MACHINE="native"
diff --git a/config/defconfig_ppc_64-power8-linux-gcc b/config/defconfig_ppc_64-power8-linux-gcc
new file mode 120000
index 000000000..580c92e12
--- /dev/null
+++ b/config/defconfig_ppc_64-power8-linux-gcc
@@ -0,0 +1 @@
+defconfig_ppc_64-power8-linuxapp-gcc
\ No newline at end of file
diff --git a/config/defconfig_ppc_64-power8-linuxapp-gcc b/config/defconfig_ppc_64-power8-linuxapp-gcc
index 8cbf7ed50..7e248b755 100644
--- a/config/defconfig_ppc_64-power8-linuxapp-gcc
+++ b/config/defconfig_ppc_64-power8-linuxapp-gcc
@@ -28,7 +28,7 @@
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-#include "common_linuxapp"
+#include "common_linux"
CONFIG_RTE_MACHINE="power8"
diff --git a/config/defconfig_x86_64-native-bsdapp-clang b/config/defconfig_x86_64-native-bsdapp-clang
index 8d2d10b48..7204738e1 100644
--- a/config/defconfig_x86_64-native-bsdapp-clang
+++ b/config/defconfig_x86_64-native-bsdapp-clang
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2010-2014 Intel Corporation
-#include "common_bsdapp"
+#include "common_freebsd"
CONFIG_RTE_MACHINE="native"
diff --git a/config/defconfig_x86_64-native-bsdapp-gcc b/config/defconfig_x86_64-native-bsdapp-gcc
index 174a74b0e..b24e2e6d5 100644
--- a/config/defconfig_x86_64-native-bsdapp-gcc
+++ b/config/defconfig_x86_64-native-bsdapp-gcc
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2010-2014 Intel Corporation
-#include "common_bsdapp"
+#include "common_freebsd"
CONFIG_RTE_MACHINE="native"
diff --git a/config/defconfig_x86_64-native-freebsd-clang b/config/defconfig_x86_64-native-freebsd-clang
new file mode 120000
index 000000000..76115fd5a
--- /dev/null
+++ b/config/defconfig_x86_64-native-freebsd-clang
@@ -0,0 +1 @@
+defconfig_x86_64-native-bsdapp-clang
\ No newline at end of file
diff --git a/config/defconfig_x86_64-native-freebsd-gcc b/config/defconfig_x86_64-native-freebsd-gcc
new file mode 120000
index 000000000..72dd4b44b
--- /dev/null
+++ b/config/defconfig_x86_64-native-freebsd-gcc
@@ -0,0 +1 @@
+defconfig_x86_64-native-bsdapp-gcc
\ No newline at end of file
diff --git a/config/defconfig_x86_64-native-linux-clang b/config/defconfig_x86_64-native-linux-clang
new file mode 120000
index 000000000..3bcf89d6a
--- /dev/null
+++ b/config/defconfig_x86_64-native-linux-clang
@@ -0,0 +1 @@
+defconfig_x86_64-native-linuxapp-clang
\ No newline at end of file
diff --git a/config/defconfig_x86_64-native-linux-gcc b/config/defconfig_x86_64-native-linux-gcc
new file mode 120000
index 000000000..d70796594
--- /dev/null
+++ b/config/defconfig_x86_64-native-linux-gcc
@@ -0,0 +1 @@
+defconfig_x86_64-native-linuxapp-gcc
\ No newline at end of file
diff --git a/config/defconfig_x86_64-native-linux-icc b/config/defconfig_x86_64-native-linux-icc
new file mode 120000
index 000000000..a36b47131
--- /dev/null
+++ b/config/defconfig_x86_64-native-linux-icc
@@ -0,0 +1 @@
+defconfig_x86_64-native-linuxapp-icc
\ No newline at end of file
diff --git a/config/defconfig_x86_64-native-linuxapp-clang b/config/defconfig_x86_64-native-linuxapp-clang
index 52d0d22fc..7508c0f2d 100644
--- a/config/defconfig_x86_64-native-linuxapp-clang
+++ b/config/defconfig_x86_64-native-linuxapp-clang
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2010-2014 Intel Corporation
-#include "common_linuxapp"
+#include "common_linux"
CONFIG_RTE_MACHINE="native"
diff --git a/config/defconfig_x86_64-native-linuxapp-gcc b/config/defconfig_x86_64-native-linuxapp-gcc
index afa5d478e..db67066a5 100644
--- a/config/defconfig_x86_64-native-linuxapp-gcc
+++ b/config/defconfig_x86_64-native-linuxapp-gcc
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2010-2014 Intel Corporation
-#include "common_linuxapp"
+#include "common_linux"
CONFIG_RTE_MACHINE="native"
diff --git a/config/defconfig_x86_64-native-linuxapp-icc b/config/defconfig_x86_64-native-linuxapp-icc
index 59783111c..d3ecae475 100644
--- a/config/defconfig_x86_64-native-linuxapp-icc
+++ b/config/defconfig_x86_64-native-linuxapp-icc
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2010-2014 Intel Corporation
-#include "common_linuxapp"
+#include "common_linux"
CONFIG_RTE_MACHINE="native"
diff --git a/config/defconfig_x86_x32-native-linux-gcc b/config/defconfig_x86_x32-native-linux-gcc
new file mode 120000
index 000000000..7ea00cecb
--- /dev/null
+++ b/config/defconfig_x86_x32-native-linux-gcc
@@ -0,0 +1 @@
+defconfig_x86_x32-native-linuxapp-gcc
\ No newline at end of file
diff --git a/config/defconfig_x86_x32-native-linuxapp-gcc b/config/defconfig_x86_x32-native-linuxapp-gcc
index 2c8419f14..14445abaa 100644
--- a/config/defconfig_x86_x32-native-linuxapp-gcc
+++ b/config/defconfig_x86_x32-native-linuxapp-gcc
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2010-2014 Intel Corporation
-#include "common_linuxapp"
+#include "common_linux"
CONFIG_RTE_MACHINE="native"
diff --git a/devtools/build-tags.sh b/devtools/build-tags.sh
index 67b12f65a..dfd66c2d4 100755
--- a/devtools/build-tags.sh
+++ b/devtools/build-tags.sh
@@ -40,8 +40,8 @@ ignore="( -name .svn -o -name CVS -o -name .hg -o -name .git ) -prune -o"
source_dirs="app buildtools drivers examples lib"
-skip_bsd="( -name bsdapp ) -prune -o"
-skip_linux="( -name linuxapp ) -prune -o"
+skip_bsd="( -name freebsd ) -prune -o"
+skip_linux="( -name linux ) -prune -o"
skip_arch="( -name arch ) -prune -o"
skip_sse="( -name *_sse*.[chS] ) -prune -o"
skip_avx="( -name *_avx*.[chS] ) -prune -o"
@@ -146,8 +146,8 @@ check_valid_target()
if [ -n "$2" ]; then
check_valid_target $2
- echo $2 | grep -q "linuxapp-" || linux=false
- echo $2 | grep -q "bsdapp-" || bsd=false
+ echo $2 | grep -q "linux" || linux=false
+ echo $2 | grep -q "bsd" || bsd=false
echo $2 | grep -q "x86_64-" || x86_64=false
echo $2 | grep -q "arm-" || arm_32=false
echo $2 | grep -q "arm64-" || arm_64=false
diff --git a/devtools/test-build.sh b/devtools/test-build.sh
index 19ff759ed..70e91da52 100755
--- a/devtools/test-build.sh
+++ b/devtools/test-build.sh
@@ -46,7 +46,7 @@ print_help () {
-v verbose build
config: defconfig[[~][+]option1[[~][+]option2...]]
- Example: x86_64-native-linuxapp-gcc+debug~RXTX_CALLBACKS
+ Example: x86_64-native-linux-gcc+debug~RXTX_CALLBACKS
The lowercase options are defined inside $(basename $0).
The uppercase options can be the end of a defconfig option
to enable if prefixed with '+' or to disable if prefixed with '~'.
diff --git a/devtools/validate-abi.sh b/devtools/validate-abi.sh
index 138436d93..54df2e476 100755
--- a/devtools/validate-abi.sh
+++ b/devtools/validate-abi.sh
@@ -9,7 +9,7 @@ set -e
abicheck=abi-compliance-checker
abidump=abi-dumper
default_dst=abi-check
-default_target=x86_64-native-linuxapp-gcc
+default_target=x86_64-native-linux-gcc
# trap on error
err_report() {
diff --git a/doc/build-sdk-quick.txt b/doc/build-sdk-quick.txt
index ff297806a..bcfa7d6fe 100644
--- a/doc/build-sdk-quick.txt
+++ b/doc/build-sdk-quick.txt
@@ -1,7 +1,7 @@
Basic build
make defconfig && make
or
- make config T=x86_64-native-linuxapp-gcc && make
+ make config T=x86_64-native-linux-gcc && make
Build commands
config get configuration from target template (T=)
defconfig auto-select target template based on arch, OS, etc.
diff --git a/doc/guides/compressdevs/octeontx.rst b/doc/guides/compressdevs/octeontx.rst
index c57d03a8e..5924ad1fa 100644
--- a/doc/guides/compressdevs/octeontx.rst
+++ b/doc/guides/compressdevs/octeontx.rst
@@ -68,7 +68,7 @@ following ``make`` command:
.. code-block:: console
cd <DPDK-source-directory>
- make config T=arm64-thunderx-linuxapp-gcc install
+ make config T=arm64-thunderx-linux-gcc install
Initialization
@@ -97,7 +97,7 @@ probed. To use the PMD in an application, user must:
reserve enough huge pages
cd to the top-level DPDK directory
- export RTE_TARGET=arm64-thunderx-linuxapp-gcc
+ export RTE_TARGET=arm64-thunderx-linux-gcc
export RTE_SDK=`pwd`
cd to app/test
type the command "make" to compile
diff --git a/doc/guides/contributing/design.rst b/doc/guides/contributing/design.rst
index 7b18de409..d3dd694b6 100644
--- a/doc/guides/contributing/design.rst
+++ b/doc/guides/contributing/design.rst
@@ -7,12 +7,12 @@ Design
Environment or Architecture-specific Sources
--------------------------------------------
-In DPDK and DPDK applications, some code is specific to an architecture (i686, x86_64) or to an executive environment (bsdapp or linuxapp) and so on.
+In DPDK and DPDK applications, some code is specific to an architecture (i686, x86_64) or to an executive environment (freebsd or linux) and so on.
As far as is possible, all such instances of architecture or env-specific code should be provided via standard APIs in the EAL.
By convention, a file is common if it is not located in a directory indicating that it is specific.
For instance, a file located in a subdir of "x86_64" directory is specific to this architecture.
-A file located in a subdir of "linuxapp" is specific to this execution environment.
+A file located in a subdir of "linux" is specific to this execution environment.
.. note::
@@ -81,7 +81,7 @@ are collected for any instance of any object type provided by the library:
.. code-block:: console
- # DPDK file config/common_linuxapp, config/common_bsdapp, etc.
+ # DPDK file config/common_linux, config/common_freebsd, etc.
CONFIG_RTE_<LIBRARY_NAME>_STATS_COLLECT=y/n
The default value for this DPDK configuration file variable (either "yes" or
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index 211a5cdc7..90927a52d 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -437,7 +437,7 @@ Makefile System
Compilation of patches and changes should be tested using the ``test-build.sh`` script in the ``devtools``
directory of the DPDK repo::
- devtools/test-build.sh x86_64-native-linuxapp-gcc+next+shared
+ devtools/test-build.sh x86_64-native-linux-gcc+next+shared
The script usage is::
@@ -452,9 +452,9 @@ Where:
Examples of configs are::
- x86_64-native-linuxapp-gcc
- x86_64-native-linuxapp-gcc+next+shared
- x86_64-native-linuxapp-clang+shared
+ x86_64-native-linux-gcc
+ x86_64-native-linux-gcc+next+shared
+ x86_64-native-linux-clang+shared
The builds can be modified via the following environmental variables:
@@ -468,9 +468,9 @@ These can be set from the command line or in the config files shown above in the
The recommended configurations and options to test compilation prior to submitting patches are::
- x86_64-native-linuxapp-gcc+shared+next
- x86_64-native-linuxapp-clang+shared
- i686-native-linuxapp-gcc
+ x86_64-native-linux-gcc+shared+next
+ x86_64-native-linux-clang+shared
+ i686-native-linux-gcc
export DPDK_DEP_ZLIB=y
export DPDK_DEP_PCAP=y
diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index 18b031998..e7b326b5d 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -557,13 +557,13 @@ on the local repo and target is the usual DPDK compilation target.
For example::
# Check between the previous and latest commit:
- ./devtools/validate-abi.sh HEAD~1 HEAD x86_64-native-linuxapp-gcc
+ ./devtools/validate-abi.sh HEAD~1 HEAD x86_64-native-linux-gcc
# Check between two tags:
- ./devtools/validate-abi.sh v2.0.0 v2.1.0 x86_64-native-linuxapp-gcc
+ ./devtools/validate-abi.sh v2.0.0 v2.1.0 x86_64-native-linux-gcc
# Check between git master and local topic-branch "vhost-hacking":
- ./devtools/validate-abi.sh master vhost-hacking x86_64-native-linuxapp-gcc
+ ./devtools/validate-abi.sh master vhost-hacking x86_64-native-linux-gcc
After the validation script completes (it can take a while since it need to
compile both tags) it will create compatibility reports in the
diff --git a/doc/guides/cryptodevs/armv8.rst b/doc/guides/cryptodevs/armv8.rst
index 725398daf..e60af8400 100644
--- a/doc/guides/cryptodevs/armv8.rst
+++ b/doc/guides/cryptodevs/armv8.rst
@@ -42,7 +42,7 @@ In order to enable this virtual crypto PMD, user must:
make -C $ARMV8_CRYPTO_LIB_PATH/
* Set CONFIG_RTE_LIBRTE_PMD_ARMV8_CRYPTO=y in
- config/defconfig_arm64-armv8a-linuxapp-gcc
+ config/defconfig_arm64-armv8a-linux-gcc
The corresponding device can be created only if the following features
are supported by the CPU:
diff --git a/doc/guides/cryptodevs/caam_jr.rst b/doc/guides/cryptodevs/caam_jr.rst
index e87ff0915..6622b79c7 100644
--- a/doc/guides/cryptodevs/caam_jr.rst
+++ b/doc/guides/cryptodevs/caam_jr.rst
@@ -121,14 +121,14 @@ to enable caam_jr PMD.
Please note that enabling debugging options may affect system performance.
* ``CONFIG_RTE_LIBRTE_PMD_CAAM_JR`` (default ``n``)
- By default it is only enabled in common_linuxapp config.
+ By default it is only enabled in common_linux config.
Toggle compilation of the ``librte_pmd_caam_jr`` driver.
* ``CONFIG_RTE_LIBRTE_PMD_CAAM_JR_BE`` (default ``n``)
By default it is disabled.
It can be used when the underlying hardware supports the CAAM in BE mode.
e.g. LS1043A, LS1046A supports CAAM in BE mode.
- BE mode is enabled by default in defconfig-arm64-dpaa-linuxapp-gcc.
+ BE mode is enabled by default in defconfig-arm64-dpaa-linux-gcc.
Installations
-------------
@@ -138,7 +138,7 @@ following ``make`` command:
.. code-block:: console
cd <DPDK-source-directory>
- make config T=arm64-armv8a-linuxapp-gcc install
+ make config T=arm64-armv8a-linux-gcc install
Enabling logs
-------------
diff --git a/doc/guides/cryptodevs/dpaa2_sec.rst b/doc/guides/cryptodevs/dpaa2_sec.rst
index aee79ab44..21cb00360 100644
--- a/doc/guides/cryptodevs/dpaa2_sec.rst
+++ b/doc/guides/cryptodevs/dpaa2_sec.rst
@@ -191,7 +191,7 @@ following ``make`` command:
.. code-block:: console
cd <DPDK-source-directory>
- make config T=arm64-dpaa2-linuxapp-gcc install
+ make config T=arm64-dpaa2-linux-gcc install
Enabling logs
-------------
diff --git a/doc/guides/cryptodevs/dpaa_sec.rst b/doc/guides/cryptodevs/dpaa_sec.rst
index 897a4fe80..0a2600634 100644
--- a/doc/guides/cryptodevs/dpaa_sec.rst
+++ b/doc/guides/cryptodevs/dpaa_sec.rst
@@ -131,7 +131,7 @@ following ``make`` command:
.. code-block:: console
cd <DPDK-source-directory>
- make config T=arm64-dpaa-linuxapp-gcc install
+ make config T=arm64-dpaa-linux-gcc install
Enabling logs
-------------
diff --git a/doc/guides/cryptodevs/openssl.rst b/doc/guides/cryptodevs/openssl.rst
index bdc30f66f..89aa5bac4 100644
--- a/doc/guides/cryptodevs/openssl.rst
+++ b/doc/guides/cryptodevs/openssl.rst
@@ -67,7 +67,7 @@ For Ubuntu 14.04 LTS these packages have to be installed in the build system:
.. code-block:: console
sudo apt-get install openssl
- sudo apt-get install libc6-dev-i386 # for i686-native-linuxapp-gcc target
+ sudo apt-get install libc6-dev-i386 # for i686-native-linux-gcc target
This code was also verified on Fedora 24.
This code has NOT been verified on FreeBSD yet.
diff --git a/doc/guides/cryptodevs/virtio.rst b/doc/guides/cryptodevs/virtio.rst
index cfc6d57d7..1496ec920 100644
--- a/doc/guides/cryptodevs/virtio.rst
+++ b/doc/guides/cryptodevs/virtio.rst
@@ -79,8 +79,8 @@ Finally the front-end virtio crypto PMD driver can be installed:
cd to the top-level DPDK directory
sed -i 's,\(CONFIG_RTE_LIBRTE_PMD_VIRTIO_CRYPTO\)=n,\1=y,' config/common_base
- make config T=x86_64-native-linuxapp-gcc
- make install T=x86_64-native-linuxapp-gcc
+ make config T=x86_64-native-linux-gcc
+ make install T=x86_64-native-linux-gcc
Tests
-----
@@ -91,7 +91,7 @@ The unit test cases can be tested as below:
reserve enough huge pages
cd to the top-level DPDK directory
- export RTE_TARGET=x86_64-native-linuxapp-gcc
+ export RTE_TARGET=x86_64-native-linux-gcc
export RTE_SDK=`pwd`
cd to app/test
type the command "make" to compile
@@ -104,7 +104,7 @@ The performance can be tested as below:
reserve enough huge pages
cd to the top-level DPDK directory
- export RTE_TARGET=x86_64-native-linuxapp-gcc
+ export RTE_TARGET=x86_64-native-linux-gcc
export RTE_SDK=`pwd`
cd to app/test-crypto-perf
type the command "make" to compile
diff --git a/doc/guides/cryptodevs/zuc.rst b/doc/guides/cryptodevs/zuc.rst
index e38989968..69a5218b1 100644
--- a/doc/guides/cryptodevs/zuc.rst
+++ b/doc/guides/cryptodevs/zuc.rst
@@ -62,7 +62,7 @@ In order to enable this virtual crypto PMD, user must:
.. code-block:: console
- make config T=x86_64-native-linuxapp-gcc
+ make config T=x86_64-native-linux-gcc
sed -i 's,\(CONFIG_RTE_LIBRTE_PMD_ZUC\)=n,\1=y,' build/.config
make
diff --git a/doc/guides/eventdevs/dpaa.rst b/doc/guides/eventdevs/dpaa.rst
index cfc40347a..be68c6da6 100644
--- a/doc/guides/eventdevs/dpaa.rst
+++ b/doc/guides/eventdevs/dpaa.rst
@@ -62,7 +62,7 @@ following ``make`` command:
.. code-block:: console
cd <DPDK-source-directory>
- make config T=arm64-dpaa-linuxapp-gcc install
+ make config T=arm64-dpaa-linux-gcc install
Initialization
--------------
diff --git a/doc/guides/eventdevs/dpaa2.rst b/doc/guides/eventdevs/dpaa2.rst
index 2b1700a5d..332b1a31c 100644
--- a/doc/guides/eventdevs/dpaa2.rst
+++ b/doc/guides/eventdevs/dpaa2.rst
@@ -71,7 +71,7 @@ following ``make`` command:
.. code-block:: console
cd <DPDK-source-directory>
- make config T=arm64-dpaa2-linuxapp-gcc install
+ make config T=arm64-dpaa2-linux-gcc install
Initialization
--------------
diff --git a/doc/guides/eventdevs/octeontx.rst b/doc/guides/eventdevs/octeontx.rst
index e276fd440..ab36a36e0 100644
--- a/doc/guides/eventdevs/octeontx.rst
+++ b/doc/guides/eventdevs/octeontx.rst
@@ -63,7 +63,7 @@ following ``make`` command:
.. code-block:: console
cd <DPDK-source-directory>
- make config T=arm64-thunderx-linuxapp-gcc install
+ make config T=arm64-thunderx-linux-gcc install
Initialization
diff --git a/doc/guides/freebsd_gsg/build_dpdk.rst b/doc/guides/freebsd_gsg/build_dpdk.rst
index 102ce1413..7abd85aa5 100644
--- a/doc/guides/freebsd_gsg/build_dpdk.rst
+++ b/doc/guides/freebsd_gsg/build_dpdk.rst
@@ -107,7 +107,7 @@ Where:
* ``MACHINE`` is: ``native``
-* ``EXECENV`` is: ``bsdapp``
+* ``EXECENV`` is: ``freebsd``
* ``TOOLCHAIN`` is: ``gcc`` | ``clang``
@@ -130,7 +130,7 @@ For example to compile for FreeBSD use:
.. code-block:: console
- gmake install T=x86_64-native-bsdapp-clang
+ gmake install T=x86_64-native-freebsd-clang
.. note::
@@ -208,7 +208,7 @@ An error such as:
.. code-block:: console
- kldload: can't load ./x86_64-native-bsdapp-gcc/kmod/contigmem.ko:
+ kldload: can't load ./x86_64-native-freebsd-gcc/kmod/contigmem.ko:
Exec format error
is generally attributed to not having enough contiguous memory
diff --git a/doc/guides/freebsd_gsg/build_sample_apps.rst b/doc/guides/freebsd_gsg/build_sample_apps.rst
index a085b6187..0c1b9cb79 100644
--- a/doc/guides/freebsd_gsg/build_sample_apps.rst
+++ b/doc/guides/freebsd_gsg/build_sample_apps.rst
@@ -13,7 +13,7 @@ Compiling a Sample Application
------------------------------
Once a DPDK target environment directory has been created (such as
-``x86_64-native-bsdapp-clang``), it contains all libraries and header files required
+``x86_64-native-freebsd-clang``), it contains all libraries and header files required
to build an application.
When compiling an application in the FreeBSD environment on the DPDK,
@@ -22,8 +22,8 @@ the following variables must be exported:
* ``RTE_SDK`` - Points to the DPDK installation directory.
* ``RTE_TARGET`` - Points to the DPDK target environment directory.
- For FreeBSD, this is the ``x86_64-native-bsdapp-clang`` or
- ``x86_64-native-bsdapp-gcc`` directory.
+ For FreeBSD, this is the ``x86_64-native-freebsd-clang`` or
+ ``x86_64-native-freebsd-gcc`` directory.
The following is an example of creating the ``helloworld`` application, which runs
in the DPDK FreeBSD environment. While the example demonstrates compiling
@@ -43,7 +43,7 @@ in the build directory.
cd $(RTE_SDK)
cd examples/helloworld/
setenv RTE_SDK $HOME/DPDK
- setenv RTE_TARGET x86_64-native-bsdapp-gcc
+ setenv RTE_TARGET x86_64-native-freebsd-gcc
gmake CC=gcc49
CC main.o
@@ -67,7 +67,7 @@ in the build directory.
setenv RTE_SDK /home/user/DPDK
cp -r $(RTE_SDK)/examples/helloworld my_rte_app
cd my_rte_app/
- setenv RTE_TARGET x86_64-native-bsdapp-gcc
+ setenv RTE_TARGET x86_64-native-freebsd-gcc
gmake CC=gcc49
CC main.o
diff --git a/doc/guides/freebsd_gsg/install_from_ports.rst b/doc/guides/freebsd_gsg/install_from_ports.rst
index 253328eb1..633699e9d 100644
--- a/doc/guides/freebsd_gsg/install_from_ports.rst
+++ b/doc/guides/freebsd_gsg/install_from_ports.rst
@@ -57,7 +57,7 @@ environmental variables should be set as below:
* ``RTE_SDK=/usr/local/share/dpdk``
-* ``RTE_TARGET=x86_64-native-bsdapp-clang``
+* ``RTE_TARGET=x86_64-native-freebsd-clang``
.. note::
@@ -72,7 +72,7 @@ compiled and run as below:
export RTE_SDK=/usr/local/share/dpdk
- export RTE_TARGET=x86_64-native-bsdapp-clang
+ export RTE_TARGET=x86_64-native-freebsd-clang
cp -r /usr/local/share/dpdk/examples/helloworld .
diff --git a/doc/guides/freebsd_gsg/intro.rst b/doc/guides/freebsd_gsg/intro.rst
index 115f428f9..e5611bca6 100644
--- a/doc/guides/freebsd_gsg/intro.rst
+++ b/doc/guides/freebsd_gsg/intro.rst
@@ -7,7 +7,7 @@ Introduction
This document contains instructions for installing and configuring the
Data Plane Development Kit (DPDK) software. It is designed to get customers
up and running quickly and describes how to compile and run a
-DPDK application in a FreeBSD application (bsdapp) environment, without going
+DPDK application in a FreeBSD application (freebsd) environment, without going
deeply into detail.
For a comprehensive guide to installing and using FreeBSD, the following
@@ -37,7 +37,7 @@ The following is a list of DPDK documents in the suggested reading order:
* **Programmer's Guide**: Describes:
* The software architecture and how to use it (through examples),
- specifically in a Linux* application (linuxapp) environment
+ specifically in a Linux* application (linux) environment
* The content of the DPDK, the build system (including the commands
that can be used in the root DPDK Makefile to build the development
diff --git a/doc/guides/howto/lm_bond_virtio_sriov.rst b/doc/guides/howto/lm_bond_virtio_sriov.rst
index a47d6dbf8..ee8ccdaf5 100644
--- a/doc/guides/howto/lm_bond_virtio_sriov.rst
+++ b/doc/guides/howto/lm_bond_virtio_sriov.rst
@@ -591,7 +591,7 @@ Set up DPDK in the Virtual Machine
rmmod virtio-pci ixgbevf
modprobe uio
- insmod /root/dpdk/x86_64-default-linuxapp-gcc/kmod/igb_uio.ko
+ insmod /root/dpdk/x86_64-default-linux-gcc/kmod/igb_uio.ko
/root/dpdk/usertools/dpdk-devbind.py -b igb_uio 0000:00:03.0
/root/dpdk/usertools/dpdk-devbind.py -b igb_uio 0000:00:04.0
@@ -613,7 +613,7 @@ Run testpmd in the Virtual Machine.
# use for bonding of virtio and vf tests in VM
- /root/dpdk/x86_64-default-linuxapp-gcc/app/testpmd \
+ /root/dpdk/x86_64-default-linux-gcc/app/testpmd \
-l 0-3 -n 4 --socket-mem 350 -- --i --port-topology=chained
.. _lm_bond_virtio_sriov_switch_conf:
diff --git a/doc/guides/howto/lm_virtio_vhost_user.rst b/doc/guides/howto/lm_virtio_vhost_user.rst
index 3f5ebd58a..6ebc10f71 100644
--- a/doc/guides/howto/lm_virtio_vhost_user.rst
+++ b/doc/guides/howto/lm_virtio_vhost_user.rst
@@ -421,7 +421,7 @@ setup_dpdk_virtio_in_vm.sh
rmmod virtio-pci
modprobe uio
- insmod /root/dpdk/x86_64-default-linuxapp-gcc/kmod/igb_uio.ko
+ insmod /root/dpdk/x86_64-default-linux-gcc/kmod/igb_uio.ko
/root/dpdk/usertools/dpdk-devbind.py -b igb_uio 0000:00:03.0
/root/dpdk/usertools/dpdk-devbind.py -b igb_uio 0000:00:04.0
@@ -437,5 +437,5 @@ run_testpmd_in_vm.sh
# Run testpmd for use with vhost_user sample app.
# test system has 8 cpus (0-7), use cpus 2-7 for VM
- /root/dpdk/x86_64-default-linuxapp-gcc/app/testpmd \
+ /root/dpdk/x86_64-default-linux-gcc/app/testpmd \
-l 0-5 -n 4 --socket-mem 350 -- --burst=64 --i
diff --git a/doc/guides/howto/pvp_reference_benchmark.rst b/doc/guides/howto/pvp_reference_benchmark.rst
index 67fa232ec..b90c63457 100644
--- a/doc/guides/howto/pvp_reference_benchmark.rst
+++ b/doc/guides/howto/pvp_reference_benchmark.rst
@@ -132,7 +132,7 @@ Build DPDK:
git clone git://dpdk.org/dpdk
cd dpdk
export RTE_SDK=$PWD
- make install T=x86_64-native-linuxapp-gcc DESTDIR=install
+ make install T=x86_64-native-linux-gcc DESTDIR=install
Testpmd launch
@@ -346,7 +346,7 @@ Build DPDK:
git clone git://dpdk.org/dpdk
cd dpdk
export RTE_SDK=$PWD
- make install T=x86_64-native-linuxapp-gcc DESTDIR=install
+ make install T=x86_64-native-linux-gcc DESTDIR=install
Testpmd launch
diff --git a/doc/guides/howto/virtio_user_for_container_networking.rst b/doc/guides/howto/virtio_user_for_container_networking.rst
index 2313dc794..f31d918bc 100644
--- a/doc/guides/howto/virtio_user_for_container_networking.rst
+++ b/doc/guides/howto/virtio_user_for_container_networking.rst
@@ -60,7 +60,7 @@ some minor changes.
.. code-block:: console
- make install RTE_SDK=`pwd` T=x86_64-native-linuxapp-gcc
+ make install RTE_SDK=`pwd` T=x86_64-native-linux-gcc
#. Write a Dockerfile like below.
@@ -70,7 +70,7 @@ some minor changes.
FROM ubuntu:latest
WORKDIR /usr/src/dpdk
COPY . /usr/src/dpdk
- ENV PATH "$PATH:/usr/src/dpdk/x86_64-native-linuxapp-gcc/app/"
+ ENV PATH "$PATH:/usr/src/dpdk/x86_64-native-linux-gcc/app/"
EOT
#. Build a Docker image.
diff --git a/doc/guides/linux_gsg/build_dpdk.rst b/doc/guides/linux_gsg/build_dpdk.rst
index d02fd7848..7c0329fcc 100644
--- a/doc/guides/linux_gsg/build_dpdk.rst
+++ b/doc/guides/linux_gsg/build_dpdk.rst
@@ -46,7 +46,7 @@ where:
* ``MACHINE`` can be: ``native``, ``power8``, ``armv8a``
-* ``EXECENV`` can be: ``linuxapp``, ``bsdapp``
+* ``EXECENV`` can be: ``linux``, ``freebsd``
* ``TOOLCHAIN`` can be: ``gcc``, ``icc``
@@ -76,20 +76,20 @@ For example, to compile a 64-bit target using icc, run:
.. code-block:: console
- make install T=x86_64-native-linuxapp-icc
+ make install T=x86_64-native-linux-icc
To compile a 32-bit build using gcc, the make command should be:
.. code-block:: console
- make install T=i686-native-linuxapp-gcc
+ make install T=i686-native-linux-gcc
To prepare a target without building it, for example, if the configuration changes need to be made before compilation,
use the ``make config T=<target>`` command:
.. code-block:: console
- make config T=x86_64-native-linuxapp-gcc
+ make config T=x86_64-native-linux-gcc
.. warning::
@@ -104,7 +104,7 @@ The user may also make modifications to the compile-time DPDK configuration by e
.. code-block:: console
- cd x86_64-native-linuxapp-gcc
+ cd x86_64-native-linux-gcc
vi .config
make
diff --git a/doc/guides/linux_gsg/build_sample_apps.rst b/doc/guides/linux_gsg/build_sample_apps.rst
index 332424e05..2f606535c 100644
--- a/doc/guides/linux_gsg/build_sample_apps.rst
+++ b/doc/guides/linux_gsg/build_sample_apps.rst
@@ -15,7 +15,7 @@ It also provides a pointer to where sample applications are stored.
Compiling a Sample Application
------------------------------
-Once an DPDK target environment directory has been created (such as ``x86_64-native-linuxapp-gcc``),
+Once an DPDK target environment directory has been created (such as ``x86_64-native-linux-gcc``),
it contains all libraries and header files required to build an application.
When compiling an application in the Linux* environment on the DPDK, the following variables must be exported:
@@ -36,7 +36,7 @@ By default, the binary is generated in the build directory.
cd examples/helloworld/
export RTE_SDK=$HOME/DPDK
- export RTE_TARGET=x86_64-native-linuxapp-gcc
+ export RTE_TARGET=x86_64-native-linux-gcc
make
CC main.o
@@ -58,7 +58,7 @@ By default, the binary is generated in the build directory.
export RTE_SDK=/home/user/DPDK
cp -r $(RTE_SDK)/examples/helloworld my_rte_app
cd my_rte_app/
- export RTE_TARGET=x86_64-native-linuxapp-gcc
+ export RTE_TARGET=x86_64-native-linux-gcc
make
CC main.o
diff --git a/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst b/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst
index 9d1f0fa00..270a60674 100644
--- a/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst
+++ b/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst
@@ -76,11 +76,11 @@ Copy the NUMA header files and lib to the cross compiler's directories:
Configure and cross compile DPDK Build
--------------------------------------
-To configure a build, choose one of the target configurations, like arm64-dpaa2-linuxapp-gcc and arm64-thunderx-linuxapp-gcc.
+To configure a build, choose one of the target configurations, like arm64-dpaa2-linux-gcc and arm64-thunderx-linux-gcc.
.. code-block:: console
- make config T=arm64-armv8a-linuxapp-gcc
+ make config T=arm64-armv8a-linux-gcc
To cross-compile, without compiling the kernel modules, use the following command:
@@ -128,5 +128,5 @@ command::
For example if the target machine is arm64 we can use the following
command::
- meson arm64-build --cross-file config/arm/arm64_armv8_linuxapp_gcc
+ meson arm64-build --cross-file config/arm/arm64_armv8_linux_gcc
ninja -C arm64-build
diff --git a/doc/guides/linux_gsg/intro.rst b/doc/guides/linux_gsg/intro.rst
index 74a8bc9fd..94877f4ae 100644
--- a/doc/guides/linux_gsg/intro.rst
+++ b/doc/guides/linux_gsg/intro.rst
@@ -6,7 +6,7 @@ Introduction
This document contains instructions for installing and configuring the Data Plane Development Kit (DPDK) software.
It is designed to get customers up and running quickly.
-The document describes how to compile and run a DPDK application in a Linux application (linuxapp) environment,
+The document describes how to compile and run a DPDK application in a Linux application (linux) environment,
without going deeply into detail.
Documentation Roadmap
@@ -21,7 +21,7 @@ The following is a list of DPDK documents in the suggested reading order:
* Programmer's Guide: Describes:
- * The software architecture and how to use it (through examples), specifically in a Linux application (linuxapp) environment
+ * The software architecture and how to use it (through examples), specifically in a Linux application (linux) environment
* The content of the DPDK, the build system (including the commands that can be used in the root DPDK Makefile to build the development kit and
an application) and guidelines for porting an application
diff --git a/doc/guides/linux_gsg/nic_perf_intel_platform.rst b/doc/guides/linux_gsg/nic_perf_intel_platform.rst
index a556a4008..0c25ec03d 100644
--- a/doc/guides/linux_gsg/nic_perf_intel_platform.rst
+++ b/doc/guides/linux_gsg/nic_perf_intel_platform.rst
@@ -133,7 +133,7 @@ Configurations before running DPDK
# Build DPDK target.
cd dpdk_folder
- make install T=x86_64-native-linuxapp-gcc -j
+ make install T=x86_64-native-linux-gcc -j
# Get the hugepage size.
awk '/Hugepagesize/ {print $2}' /proc/meminfo
diff --git a/doc/guides/linux_gsg/quick_start.rst b/doc/guides/linux_gsg/quick_start.rst
index 43974df88..d7b04ae01 100644
--- a/doc/guides/linux_gsg/quick_start.rst
+++ b/doc/guides/linux_gsg/quick_start.rst
@@ -93,25 +93,25 @@ Some options in the script prompt the user for further data before proceeding.
------------------------------------------------------------------------
- [1] i686-native-linuxapp-gcc
+ [1] i686-native-linux-gcc
- [2] i686-native-linuxapp-icc
+ [2] i686-native-linux-icc
- [3] ppc_64-power8-linuxapp-gcc
+ [3] ppc_64-power8-linux-gcc
- [4] x86_64-native-bsdapp-clang
+ [4] x86_64-native-freebsd-clang
- [5] x86_64-native-bsdapp-gcc
+ [5] x86_64-native-freebsd-gcc
- [6] x86_64-native-linuxapp-clang
+ [6] x86_64-native-linux-clang
- [7] x86_64-native-linuxapp-gcc
+ [7] x86_64-native-linux-gcc
- [8] x86_64-native-linuxapp-icc
+ [8] x86_64-native-linux-icc
------------------------------------------------------------------------
- Step 2: Setup linuxapp environment
+ Step 2: Setup linux environment
------------------------------------------------------------------------
@@ -135,7 +135,7 @@ Some options in the script prompt the user for further data before proceeding.
------------------------------------------------------------------------
- Step 3: Run test application for linuxapp environment
+ Step 3: Run test application for linux environment
------------------------------------------------------------------------
@@ -173,19 +173,19 @@ Some options in the script prompt the user for further data before proceeding.
Option:
-The following selection demonstrates the creation of the ``x86_64-native-linuxapp-gcc`` DPDK library.
+The following selection demonstrates the creation of the ``x86_64-native-linux-gcc`` DPDK library.
.. code-block:: console
Option: 9
- ================== Installing x86_64-native-linuxapp-gcc
+ ================== Installing x86_64-native-linux-gcc
Configuration done
== Build lib
...
Build complete
- RTE_TARGET exported as x86_64-native-linuxapp-gcc
+ RTE_TARGET exported as x86_64-native-linux-gcc
The following selection demonstrates the starting of the DPDK UIO driver.
diff --git a/doc/guides/mempool/octeontx.rst b/doc/guides/mempool/octeontx.rst
index 3ade61fc2..dfa1993e1 100644
--- a/doc/guides/mempool/octeontx.rst
+++ b/doc/guides/mempool/octeontx.rst
@@ -56,7 +56,7 @@ following ``make`` command:
.. code-block:: console
cd <DPDK-source-directory>
- make config T=arm64-thunderx-linuxapp-gcc
+ make config T=arm64-thunderx-linux-gcc
Initialization
diff --git a/doc/guides/nics/build_and_test.rst b/doc/guides/nics/build_and_test.rst
index d9a78eef0..aae5c111d 100644
--- a/doc/guides/nics/build_and_test.rst
+++ b/doc/guides/nics/build_and_test.rst
@@ -33,26 +33,26 @@ Example output:
.. code-block:: console
- arm-armv7a-linuxapp-gcc
- arm64-armv8a-linuxapp-gcc
- arm64-dpaa2-linuxapp-gcc
- arm64-thunderx-linuxapp-gcc
- arm64-xgene1-linuxapp-gcc
- i686-native-linuxapp-gcc
- i686-native-linuxapp-icc
- ppc_64-power8-linuxapp-gcc
- x86_64-native-bsdapp-clang
- x86_64-native-bsdapp-gcc
- x86_64-native-linuxapp-clang
- x86_64-native-linuxapp-gcc
- x86_64-native-linuxapp-icc
- x86_x32-native-linuxapp-gcc
+ arm-armv7a-linux-gcc
+ arm64-armv8a-linux-gcc
+ arm64-dpaa2-linux-gcc
+ arm64-thunderx-linux-gcc
+ arm64-xgene1-linux-gcc
+ i686-native-linux-gcc
+ i686-native-linux-icc
+ ppc_64-power8-linux-gcc
+ x86_64-native-freebsd-clang
+ x86_64-native-freebsd-gcc
+ x86_64-native-linux-clang
+ x86_64-native-linux-gcc
+ x86_64-native-linux-icc
+ x86_x32-native-linux-gcc
To compile a PMD for Linux x86_64 gcc target, run the following "make" command:
.. code-block:: console
- make install T=x86_64-native-linuxapp-gcc
+ make install T=x86_64-native-linux-gcc
Use ARM (ThunderX, DPAA, X-Gene) or PowerPC target for respective platform.
@@ -102,7 +102,7 @@ This section demonstrates how to setup and run ``testpmd`` in Linux.
.. code-block:: console
modprobe uio
- insmod ./x86_64-native-linuxapp-gcc/kmod/igb_uio.ko
+ insmod ./x86_64-native-linux-gcc/kmod/igb_uio.ko
or
@@ -139,7 +139,7 @@ This section demonstrates how to setup and run ``testpmd`` in Linux.
.. code-block:: console
- ./x86_64-native-linuxapp-gcc/app/testpmd -l 0-3 -n 4 -- -i
+ ./x86_64-native-linux-gcc/app/testpmd -l 0-3 -n 4 -- -i
Successful execution will show initialization messages from EAL, PMD and
testpmd application. A prompt will be displayed at the end for user commands
diff --git a/doc/guides/nics/cxgbe.rst b/doc/guides/nics/cxgbe.rst
index 58d88eef5..f3e611506 100644
--- a/doc/guides/nics/cxgbe.rst
+++ b/doc/guides/nics/cxgbe.rst
@@ -493,7 +493,7 @@ devices managed by librte_pmd_cxgbe in FreeBSD operating system.
.. code-block:: console
- cp x86_64-native-bsdapp-clang/kmod/contigmem.ko /boot/kernel/
+ cp x86_64-native-freebsd-clang/kmod/contigmem.ko /boot/kernel/
#. Add the following lines to /boot/loader.conf:
@@ -574,13 +574,13 @@ devices managed by librte_pmd_cxgbe in FreeBSD operating system.
.. code-block:: console
- kldload ./x86_64-native-bsdapp-clang/kmod/nic_uio.ko
+ kldload ./x86_64-native-freebsd-clang/kmod/nic_uio.ko
#. Start testpmd with basic parameters:
.. code-block:: console
- ./x86_64-native-bsdapp-clang/app/testpmd -l 0-3 -n 4 -w 0000:02:00.4 -- -i
+ ./x86_64-native-freebsd-clang/app/testpmd -l 0-3 -n 4 -w 0000:02:00.4 -- -i
Example output:
diff --git a/doc/guides/nics/dpaa.rst b/doc/guides/nics/dpaa.rst
index 2173673b9..fb7bc7d0c 100644
--- a/doc/guides/nics/dpaa.rst
+++ b/doc/guides/nics/dpaa.rst
@@ -271,7 +271,7 @@ for details.
.. code-block:: console
- ./arm64-dpaa-linuxapp-gcc/testpmd -c 0xff -n 1 \
+ ./arm64-dpaa-linux-gcc/testpmd -c 0xff -n 1 \
-- -i --portmask=0x3 --nb-cores=1 --no-flush-rx
.....
diff --git a/doc/guides/nics/enic.rst b/doc/guides/nics/enic.rst
index bc38f51aa..6dfe5d7ac 100644
--- a/doc/guides/nics/enic.rst
+++ b/doc/guides/nics/enic.rst
@@ -572,7 +572,7 @@ PMD. Typically, the limit has to be raised to higher than 2GB.
e.g., 2621440
The compilation of any unused drivers can be disabled using the
-configuration file in config/ directory (e.g., config/common_linuxapp).
+configuration file in config/ directory (e.g., config/common_linux).
This would help in bringing down the time taken for building the
libraries and the initialization time of the application.
diff --git a/doc/guides/nics/intel_vf.rst b/doc/guides/nics/intel_vf.rst
index 49a7085a9..3400fe189 100644
--- a/doc/guides/nics/intel_vf.rst
+++ b/doc/guides/nics/intel_vf.rst
@@ -521,19 +521,19 @@ The setup procedure is as follows:
.. code-block:: console
- make install T=x86_64-native-linuxapp-gcc
- ./x86_64-native-linuxapp-gcc/app/testpmd -l 0-3 -n 4 -- -i
+ make install T=x86_64-native-linux-gcc
+ ./x86_64-native-linux-gcc/app/testpmd -l 0-3 -n 4 -- -i
#. Finally, access the Guest OS using vncviewer with the localhost:5900 port and check the lspci command output in the Guest OS.
The virtual functions will be listed as available for use.
-#. Configure and install the DPDK with an x86_64-native-linuxapp-gcc configuration on the Guest OS as normal,
+#. Configure and install the DPDK with an x86_64-native-linux-gcc configuration on the Guest OS as normal,
that is, there is no change to the normal installation procedure.
.. code-block:: console
- make config T=x86_64-native-linuxapp-gcc O=x86_64-native-linuxapp-gcc
- cd x86_64-native-linuxapp-gcc
+ make config T=x86_64-native-linux-gcc O=x86_64-native-linux-gcc
+ cd x86_64-native-linux-gcc
make
.. note::
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 0b6749654..020037300 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -223,7 +223,7 @@ These options can be modified in the ``.config`` file.
.. note::
- For Bluefield, target should be set to ``arm64-bluefield-linuxapp-gcc``. This
+ For Bluefield, target should be set to ``arm64-bluefield-linux-gcc``. This
will enable ``CONFIG_RTE_LIBRTE_MLX5_PMD`` and set ``RTE_CACHE_LINE_SIZE`` to
64. Default armv8a configuration of make build and meson build set it to 128
then brings performance degradation.
diff --git a/doc/guides/nics/mvneta.rst b/doc/guides/nics/mvneta.rst
index 2132a8197..c8b00ddf2 100644
--- a/doc/guides/nics/mvneta.rst
+++ b/doc/guides/nics/mvneta.rst
@@ -133,7 +133,7 @@ the path to the MUSDK installation directory needs to be exported.
export LIBMUSDK_PATH=<musdk>/usr/local
export CROSS=aarch64-linux-gnu-
- make config T=arm64-armv8a-linuxapp-gcc
+ make config T=arm64-armv8a-linux-gcc
sed -ri 's,(MVNETA_PMD=)n,\1y,' build/.config
make
diff --git a/doc/guides/nics/mvpp2.rst b/doc/guides/nics/mvpp2.rst
index 4101d2d89..09e2f2a56 100644
--- a/doc/guides/nics/mvpp2.rst
+++ b/doc/guides/nics/mvpp2.rst
@@ -180,9 +180,9 @@ For additional instructions regarding DPDK cross compilation please refer to :do
export LIBMUSDK_PATH=<musdk>/usr/local
export CROSS=<toolchain>/bin/aarch64-linux-gnu-
export RTE_KERNELDIR=<kernel-dir>
- export RTE_TARGET=arm64-armv8a-linuxapp-gcc
+ export RTE_TARGET=arm64-armv8a-linux-gcc
- make config T=arm64-armv8a-linuxapp-gcc
+ make config T=arm64-armv8a-linux-gcc
sed -i "s/MVNETA_PMD=y/MVNETA_PMD=n/" build/.config
sed -i "s/MVPP2_PMD=n/MVPP2_PMD=y/" build/.config
make
diff --git a/doc/guides/nics/nfp.rst b/doc/guides/nics/nfp.rst
index 3bfb0ef61..09a8529b9 100644
--- a/doc/guides/nics/nfp.rst
+++ b/doc/guides/nics/nfp.rst
@@ -75,7 +75,7 @@ compile it along with other DPDK PMDs even if no BSP was installed previously.
Of course, a DPDK app will require such a BSP installed for using the
NFP PMD, along with a specific NFP firmware application.
-Default PMD configuration is at the **common_linuxapp configuration** file:
+Default PMD configuration is at the **common_linux configuration** file:
- **CONFIG_RTE_LIBRTE_NFP_PMD=y**
diff --git a/doc/guides/nics/octeontx.rst b/doc/guides/nics/octeontx.rst
index f8111d3cc..012a3ec21 100644
--- a/doc/guides/nics/octeontx.rst
+++ b/doc/guides/nics/octeontx.rst
@@ -71,7 +71,7 @@ following ``make`` command:
.. code-block:: console
cd <DPDK-source-directory>
- make config T=arm64-thunderx-linuxapp-gcc install
+ make config T=arm64-thunderx-linux-gcc install
#. Running testpmd:
@@ -83,7 +83,7 @@ following ``make`` command:
.. code-block:: console
- ./arm64-thunderx-linuxapp-gcc/app/testpmd -c 700 \
+ ./arm64-thunderx-linux-gcc/app/testpmd -c 700 \
--base-virtaddr=0x100000000000 \
--mbuf-pool-ops-name="octeontx_fpavf" \
--vdev='event_octeontx' \
diff --git a/doc/guides/nics/softnic.rst b/doc/guides/nics/softnic.rst
index 32a9cf22f..c8962d90b 100644
--- a/doc/guides/nics/softnic.rst
+++ b/doc/guides/nics/softnic.rst
@@ -54,7 +54,7 @@ Release Notes*.
Build options
-------------
-The default PMD configuration available in the common_linuxapp configuration file:
+The default PMD configuration available in the common_linux configuration file:
CONFIG_RTE_LIBRTE_PMD_SOFTNIC=y
@@ -347,7 +347,7 @@ commands.
.. code-block:: console
- ./x86_64-native-linuxapp-gcc/app/testpmd -l 23-25 -n 4 \
+ ./x86_64-native-linux-gcc/app/testpmd -l 23-25 -n 4 \
--vdev 'net_softnic0, \
firmware=./drivers/net/softnic/ \
firmware.cli, \
diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst
index 9a3d7b348..063bd0be4 100644
--- a/doc/guides/nics/tap.rst
+++ b/doc/guides/nics/tap.rst
@@ -181,7 +181,7 @@ used to build the dpdk you pulled down.
Run pktgen from the pktgen directory in a terminal with a commandline like the
following::
- sudo ./app/app/x86_64-native-linuxapp-gcc/app/pktgen -l 1-5 -n 4 \
+ sudo ./app/app/x86_64-native-linux-gcc/app/pktgen -l 1-5 -n 4 \
--proc-type auto --log-level debug --socket-mem 512,512 --file-prefix pg \
--vdev=net_tap0 --vdev=net_tap1 -b 05:00.0 -b 05:00.1 \
-b 04:00.0 -b 04:00.1 -b 04:00.2 -b 04:00.3 \
diff --git a/doc/guides/nics/thunderx.rst b/doc/guides/nics/thunderx.rst
index e84eaafe5..53eaec72a 100644
--- a/doc/guides/nics/thunderx.rst
+++ b/doc/guides/nics/thunderx.rst
@@ -70,7 +70,7 @@ Refer to the document :ref:`compiling and testing a PMD for a NIC <pmd_build_and
for details.
To compile the ThunderX NICVF PMD for Linux arm64 gcc,
-use arm64-thunderx-linuxapp-gcc as target.
+use arm64-thunderx-linux-gcc as target.
Linux
-----
@@ -177,7 +177,7 @@ This section provides instructions to configure SR-IOV with Linux OS.
.. code-block:: console
- ./arm64-thunderx-linuxapp-gcc/app/testpmd -l 0-3 -n 4 -w 0002:01:00.2 \
+ ./arm64-thunderx-linux-gcc/app/testpmd -l 0-3 -n 4 -w 0002:01:00.2 \
-- -i --no-flush-rx \
--port-topology=loop
diff --git a/doc/guides/platform/octeontx.rst b/doc/guides/platform/octeontx.rst
index 3bde91f9d..7d1cb647d 100644
--- a/doc/guides/platform/octeontx.rst
+++ b/doc/guides/platform/octeontx.rst
@@ -95,7 +95,7 @@ drivers can be compiled with the following steps,
.. code-block:: console
cd <dpdk directory>
- make config T=arm64-thunderx-linuxapp-gcc
+ make config T=arm64-thunderx-linux-gcc
make
The example applications can be compiled using the following:
@@ -144,7 +144,7 @@ to build applications for **OCTEON TX** :sup:`®` platforms.
cd <dpdk directory>
export RTE_SDK=$PWD
export RTE_KERNELDIR=$THUNDER_ROOT/linux/kernel/linux
- make config T=arm64-thunderx-linuxapp-gcc
+ make config T=arm64-thunderx-linux-gcc
make -j CROSS=aarch64-thunderx-linux-gnu- CONFIG_RTE_KNI_KMOD=n CONFIG_RTE_EAL_IGB_UIO=n EXTRA_CFLAGS="-isystem <numa_install_dir>/include" EXTRA_LDFLAGS="-L<numa_install_dir>/lib -lnuma"
If NUMA support is not required, it can be disabled as explained in
@@ -154,7 +154,7 @@ Following steps could be used in that case.
.. code-block:: console
- make config T=arm64-thunderx-linuxapp-gcc
+ make config T=arm64-thunderx-linux-gcc
make CROSS=aarch64-thunderx-linux-gnu-
diff --git a/doc/guides/prog_guide/build_app.rst b/doc/guides/prog_guide/build_app.rst
index fa6aa8a2f..bffa55bbe 100644
--- a/doc/guides/prog_guide/build_app.rst
+++ b/doc/guides/prog_guide/build_app.rst
@@ -16,7 +16,7 @@ RTE_SDK and RTE_TARGET.
~/DPDK$ cd examples/helloworld/
~/DPDK/examples/helloworld$ export RTE_SDK=/home/user/DPDK
- ~/DPDK/examples/helloworld$ export RTE_TARGET=x86_64-native-linuxapp-gcc
+ ~/DPDK/examples/helloworld$ export RTE_TARGET=x86_64-native-linux-gcc
~/DPDK/examples/helloworld$ make
CC main.o
LD helloworld
@@ -40,7 +40,7 @@ The sample application (Hello World) can be duplicated in a new directory as a s
~$ cp -r DPDK/examples/helloworld my_rte_app
~$ cd my_rte_app/
~/my_rte_app$ export RTE_SDK=/home/user/DPDK
- ~/my_rte_app$ export RTE_TARGET=x86_64-native-linuxapp-gcc
+ ~/my_rte_app$ export RTE_TARGET=x86_64-native-linux-gcc
~/my_rte_app$ make
CC main.o
LD helloworld
diff --git a/doc/guides/prog_guide/dev_kit_build_system.rst b/doc/guides/prog_guide/dev_kit_build_system.rst
index 855b5da53..a0c923096 100644
--- a/doc/guides/prog_guide/dev_kit_build_system.rst
+++ b/doc/guides/prog_guide/dev_kit_build_system.rst
@@ -31,13 +31,13 @@ Each build directory contains include files, libraries, and applications.
A build directory is specific to a configuration that includes architecture + execution environment + toolchain.
It is possible to have several build directories sharing the same sources with different configurations.
-For instance, to create a new build directory called my_sdk_build_dir using the default configuration template config/defconfig_x86_64-linuxapp,
+For instance, to create a new build directory called my_sdk_build_dir using the default configuration template config/defconfig_x86_64-linux,
we use:
.. code-block:: console
cd ${RTE_SDK}
- make config T=x86_64-native-linuxapp-gcc O=my_sdk_build_dir
+ make config T=x86_64-native-linux-gcc O=my_sdk_build_dir
This creates a new my_sdk_build_dir directory. After that, we can compile by doing:
@@ -65,7 +65,7 @@ To compile an application, the user must set the RTE_SDK and RTE_TARGET environm
.. code-block:: console
export RTE_SDK=/opt/DPDK
- export RTE_TARGET=x86_64-native-linuxapp-gcc
+ export RTE_TARGET=x86_64-native-linux-gcc
cd /path/to/my_app
For a new application, the user must create their own Makefile that includes some .mk files, such as
@@ -248,7 +248,7 @@ Useful Variables Provided by the Build System
* RTE_TOOLCHAIN: Defines the toolchain (gcc , icc).
It is the same value as CONFIG_RTE_TOOLCHAIN but without the double-quotes around the string.
-* RTE_EXEC_ENV: Defines the executive environment (linuxapp).
+* RTE_EXEC_ENV: Defines the executive environment (linux).
It is the same value as CONFIG_RTE_EXEC_ENV but without the double-quotes around the string.
* RTE_KERNELDIR: This variable contains the absolute path to the kernel sources that will be used to compile the kernel modules.
diff --git a/doc/guides/prog_guide/dev_kit_root_make_help.rst b/doc/guides/prog_guide/dev_kit_root_make_help.rst
index 633161f09..a30db7d5b 100644
--- a/doc/guides/prog_guide/dev_kit_root_make_help.rst
+++ b/doc/guides/prog_guide/dev_kit_root_make_help.rst
@@ -27,7 +27,7 @@ This is an optional parameter, the default output directory is build.
.. code-block:: console
- make config O=mybuild T=x86_64-native-linuxapp-gcc
+ make config O=mybuild T=x86_64-native-linux-gcc
Build Targets
-------------
@@ -163,7 +163,7 @@ For instance, the following command:
.. code-block:: console
cd $(RTE_SDK)
- make config O=mybuild T=x86_64-native-linuxapp-gcc
+ make config O=mybuild T=x86_64-native-linux-gcc
make O=mybuild
is equivalent to:
@@ -171,7 +171,7 @@ is equivalent to:
.. code-block:: console
cd $(RTE_SDK)
- make config O=mybuild T=x86_64-native-linuxapp-gcc
+ make config O=mybuild T=x86_64-native-linux-gcc
cd mybuild
# no need to specify O= now
diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst
index 8780928a6..3d78b4ebe 100644
--- a/doc/guides/prog_guide/env_abstraction_layer.rst
+++ b/doc/guides/prog_guide/env_abstraction_layer.rst
@@ -54,9 +54,9 @@ A check is also performed at initialization time to ensure that the micro archit
Then, the main() function is called. The core initialization and launch is done in rte_eal_init() (see the API documentation).
It consist of calls to the pthread library (more specifically, pthread_self(), pthread_create(), and pthread_setaffinity_np()).
-.. _figure_linuxapp_launch:
+.. _figure_linux_launch:
.. figure:: img/linuxapp_launch.*
EAL Initialization in a Linux Application Environment
@@ -79,7 +79,7 @@ API documentation for details.
Multi-process Support
~~~~~~~~~~~~~~~~~~~~~
-The Linuxapp EAL allows a multi-process as well as a multi-threaded (pthread) deployment model.
+The Linux EAL allows a multi-process as well as a multi-threaded (pthread) deployment model.
See chapter
:ref:`Multi-process Support <Multi-process_Support>` for more details.
diff --git a/doc/guides/prog_guide/ext_app_lib_make_help.rst b/doc/guides/prog_guide/ext_app_lib_make_help.rst
index 7e8e9fd3a..4312778dc 100644
--- a/doc/guides/prog_guide/ext_app_lib_make_help.rst
+++ b/doc/guides/prog_guide/ext_app_lib_make_help.rst
@@ -22,7 +22,7 @@ The following variables must be defined:
* ${RTE_SDK}: Points to the root directory of the DPDK.
-* ${RTE_TARGET}: Reference the target to be used for compilation (for example, x86_64-native-linuxapp-gcc).
+* ${RTE_TARGET}: Reference the target to be used for compilation (for example, x86_64-native-linux-gcc).
Build Targets
-------------
@@ -94,5 +94,5 @@ It is possible to run the Makefile from another directory, by specifying the out
.. code-block:: console
export RTE_SDK=/path/to/DPDK
- export RTE_TARGET=x86_64-native-linuxapp-icc
+ export RTE_TARGET=x86_64-native-linux-icc
make -f /path/to/my_app/Makefile S=/path/to/my_app O=/path/to/build_dir
diff --git a/doc/guides/prog_guide/extend_dpdk.rst b/doc/guides/prog_guide/extend_dpdk.rst
index 725994ee0..a3b3d300b 100644
--- a/doc/guides/prog_guide/extend_dpdk.rst
+++ b/doc/guides/prog_guide/extend_dpdk.rst
@@ -73,7 +73,7 @@ To add a new library to the DPDK, proceed as follows:
.. code-block:: console
cd ${RTE_SDK}
- make config T=x86_64-native-linuxapp-gcc
+ make config T=x86_64-native-linux-gcc
make
@@ -105,5 +105,5 @@ Once you have added a library, a new test case should be added in the test appli
.. code-block:: console
cd ${RTE_SDK}
- make config T=x86_64-native-linuxapp-gcc
+ make config T=x86_64-native-linux-gcc
make
diff --git a/doc/guides/prog_guide/glossary.rst b/doc/guides/prog_guide/glossary.rst
index dda45bd18..21063a414 100644
--- a/doc/guides/prog_guide/glossary.rst
+++ b/doc/guides/prog_guide/glossary.rst
@@ -205,7 +205,7 @@ SW
Target
In the DPDK, the target is a combination of architecture, machine,
executive environment and toolchain. For example:
- i686-native-linuxapp-gcc.
+ i686-native-linux-gcc.
TCP
Transmission Control Protocol
diff --git a/doc/guides/prog_guide/img/linuxapp_launch.svg b/doc/guides/prog_guide/img/linuxapp_launch.svg
index af685897d..3af560554 100644
--- a/doc/guides/prog_guide/img/linuxapp_launch.svg
+++ b/doc/guides/prog_guide/img/linuxapp_launch.svg
@@ -17,9 +17,9 @@
id="svg2"
sodipodi:version="0.32"
inkscape:version="0.48.4 r9939"
- sodipodi:docname="linuxapp_launch.svg"
+ sodipodi:docname="linux_launch.svg"
inkscape:output_extension="org.inkscape.output.svg.inkscape"
- inkscape:export-filename="/home/matz/rapports/doc/intel/architecture_docs/linuxapp_launch.png"
+ inkscape:export-filename="/home/matz/rapports/doc/intel/architecture_docs/linux_launch.png"
inkscape:export-xdpi="90"
inkscape:export-ydpi="90"
version="1.1">
diff --git a/doc/guides/prog_guide/intro.rst b/doc/guides/prog_guide/intro.rst
index be556a742..5b319d36d 100644
--- a/doc/guides/prog_guide/intro.rst
+++ b/doc/guides/prog_guide/intro.rst
@@ -31,7 +31,7 @@ The following is a list of DPDK documents in the suggested reading order:
* **Programmer's Guide** (this document): Describes:
* The software architecture and how to use it (through examples),
- specifically in a Linux* application (linuxapp) environment
+ specifically in a Linux* application (linux) environment
* The content of the DPDK, the build system
(including the commands that can be used in the root DPDK Makefile to build the development kit and an application)
diff --git a/doc/guides/prog_guide/overview.rst b/doc/guides/prog_guide/overview.rst
index c01f37e3c..986c89690 100644
--- a/doc/guides/prog_guide/overview.rst
+++ b/doc/guides/prog_guide/overview.rst
@@ -52,7 +52,7 @@ The following are examples of how the variables can be set:
.. code-block:: console
export RTE_SDK=/home/user/DPDK
- export RTE_TARGET=x86_64-native-linuxapp-gcc
+ export RTE_TARGET=x86_64-native-linux-gcc
See the *DPDK Getting Started Guide* for information on setting up the development environment.
diff --git a/doc/guides/prog_guide/profile_app.rst b/doc/guides/prog_guide/profile_app.rst
index 02f05614a..5af795c0d 100644
--- a/doc/guides/prog_guide/profile_app.rst
+++ b/doc/guides/prog_guide/profile_app.rst
@@ -84,7 +84,7 @@ an armv8 machine.
make
sudo insmod pmu_el0_cycle_counter.ko
cd $DPDK_DIR
- make config T=arm64-armv8a-linuxapp-gcc
+ make config T=arm64-armv8a-linux-gcc
echo "CONFIG_RTE_ARM_EAL_RDTSC_USE_PMU=y" >> build/.config
make
diff --git a/doc/guides/prog_guide/qos_framework.rst b/doc/guides/prog_guide/qos_framework.rst
index 0ce3cd58d..a7527b21c 100644
--- a/doc/guides/prog_guide/qos_framework.rst
+++ b/doc/guides/prog_guide/qos_framework.rst
@@ -1511,7 +1511,7 @@ To enable it, use the DPDK configuration parameter:
This parameter must be set to y.
The parameter is found in the build configuration files in the DPDK/config directory,
-for example, DPDK/config/common_linuxapp.
+for example, DPDK/config/common_linux.
RED configuration parameters are specified in the rte_red_params structure within the rte_sched_port_params structure
that is passed to the scheduler on initialization.
RED parameters are specified separately for four traffic classes and three packet colors (green, yellow and red)
diff --git a/doc/guides/rawdevs/dpaa2_cmdif.rst b/doc/guides/rawdevs/dpaa2_cmdif.rst
index bebda8333..6db06777c 100644
--- a/doc/guides/rawdevs/dpaa2_cmdif.rst
+++ b/doc/guides/rawdevs/dpaa2_cmdif.rst
@@ -77,7 +77,7 @@ following ``make`` command:
.. code-block:: console
cd <DPDK-source-directory>
- make config T=arm64-dpaa2-linuxapp-gcc install
+ make config T=arm64-dpaa2-linux-gcc install
Initialization
--------------
diff --git a/doc/guides/rawdevs/dpaa2_qdma.rst b/doc/guides/rawdevs/dpaa2_qdma.rst
index 793a8513f..359e4c69f 100644
--- a/doc/guides/rawdevs/dpaa2_qdma.rst
+++ b/doc/guides/rawdevs/dpaa2_qdma.rst
@@ -81,7 +81,7 @@ following ``make`` command:
.. code-block:: console
cd <DPDK-source-directory>
- make config T=arm64-dpaa2-linuxapp-gcc install
+ make config T=arm64-dpaa2-linux-gcc install
Initialization
--------------
diff --git a/doc/guides/rel_notes/release_19_02.rst b/doc/guides/rel_notes/release_19_02.rst
index 6bacbdb8f..b353620b7 100644
--- a/doc/guides/rel_notes/release_19_02.rst
+++ b/doc/guides/rel_notes/release_19_02.rst
@@ -110,7 +110,7 @@ New Features
* Added static linkage of ``mlx`` dependency.
* Improved stability of E-Switch flow driver.
* Added new make build configuration to set the cacheline size for Bluefield
- correctly - ``arm64-bluefield-linuxapp-gcc``.
+ correctly - ``arm64-bluefield-linux-gcc``.
* **Updated the enic driver.**
diff --git a/doc/guides/rel_notes/release_2_1.rst b/doc/guides/rel_notes/release_2_1.rst
index 0c27826f9..beadc51ba 100644
--- a/doc/guides/rel_notes/release_2_1.rst
+++ b/doc/guides/rel_notes/release_2_1.rst
@@ -70,7 +70,7 @@ New Features
* In UIO, the RX interrupt shares the same vector with other
interrupts. When the RX interrupt and LSC interrupt are both enabled, only
the former is available.
- * RX interrupt is only implemented for the linuxapp target.
+ * RX interrupt is only implemented for the linux target.
* The feature is only currently enabled for tow PMDs: ixgbe and igb.
diff --git a/doc/guides/sample_app_ug/bbdev_app.rst b/doc/guides/sample_app_ug/bbdev_app.rst
index 653f972f3..40a3264ab 100644
--- a/doc/guides/sample_app_ug/bbdev_app.rst
+++ b/doc/guides/sample_app_ug/bbdev_app.rst
@@ -46,7 +46,7 @@ Compiling the Application
.. code-block:: console
- export RTE_TARGET=x86_64-native-linuxapp-gcc
+ export RTE_TARGET=x86_64-native-linux-gcc
See the *DPDK Getting Started Guide* for possible RTE_TARGET values.
@@ -78,7 +78,7 @@ the specified baseband operation are available on application initialization.
This means that HW baseband device/s must be bound to a DPDK driver or
a SW baseband device/s (virtual BBdev) must be created (using --vdev).
-To run the application in linuxapp environment with the turbo_sw baseband device
+To run the application in linux environment with the turbo_sw baseband device
using the whitelisted port running on 1 encoding lcore and 1 decoding lcore
issue the command:
@@ -116,7 +116,7 @@ ports.
.. code-block:: console
- $ ./pktgen-3.4.0/app/x86_64-native-linuxapp-gcc/pktgen -c 0x3 \
+ $ ./pktgen-3.4.0/app/x86_64-native-linux-gcc/pktgen -c 0x3 \
--socket-mem=1,1 --file-prefix=pg -w <NIC1PCIADDR> -- -m 1.0 -P
where:
diff --git a/doc/guides/sample_app_ug/cmd_line.rst b/doc/guides/sample_app_ug/cmd_line.rst
index b38a5b335..828a607be 100644
--- a/doc/guides/sample_app_ug/cmd_line.rst
+++ b/doc/guides/sample_app_ug/cmd_line.rst
@@ -48,7 +48,7 @@ The application is located in the ``cmd_line`` sub-directory.
Running the Application
-----------------------
-To run the application in linuxapp environment, issue the following command:
+To run the application in linux environment, issue the following command:
.. code-block:: console
diff --git a/doc/guides/sample_app_ug/dist_app.rst b/doc/guides/sample_app_ug/dist_app.rst
index 1f68d081c..abfdd2c5e 100644
--- a/doc/guides/sample_app_ug/dist_app.rst
+++ b/doc/guides/sample_app_ug/dist_app.rst
@@ -46,7 +46,7 @@ Running the Application
* -p PORTMASK: Hexadecimal bitmask of ports to configure
-#. To run the application in linuxapp environment with 10 lcores, 4 ports,
+#. To run the application in linux environment with 10 lcores, 4 ports,
issue the command:
.. code-block:: console
diff --git a/doc/guides/sample_app_ug/fips_validation.rst b/doc/guides/sample_app_ug/fips_validation.rst
index aeacfacb7..2953fddeb 100644
--- a/doc/guides/sample_app_ug/fips_validation.rst
+++ b/doc/guides/sample_app_ug/fips_validation.rst
@@ -112,7 +112,7 @@ where,
are folder paths.
-To run the application in linuxapp environment to test one AES FIPS test data
+To run the application in linux environment to test one AES FIPS test data
file for crypto_aesni_mb PMD, issue the command:
.. code-block:: console
@@ -121,7 +121,7 @@ file for crypto_aesni_mb PMD, issue the command:
--req-file /PATH/TO/REQUEST/FILE.req --rsp-file ./PATH/TO/RESPONSE/FILE.rsp
--cryptodev crypto_aesni_mb
-To run the application in linuxapp environment to test all AES-GCM FIPS test
+To run the application in linux environment to test all AES-GCM FIPS test
data files in one folder for crypto_aesni_gcm PMD, issue the command:
.. code-block:: console
diff --git a/doc/guides/sample_app_ug/flow_classify.rst b/doc/guides/sample_app_ug/flow_classify.rst
index 003ed0356..a6383b3c7 100644
--- a/doc/guides/sample_app_ug/flow_classify.rst
+++ b/doc/guides/sample_app_ug/flow_classify.rst
@@ -24,7 +24,7 @@ The application is located in the ``flow_classify`` sub-directory.
Running the Application
-----------------------
-To run the example in a ``linuxapp`` environment:
+To run the example in a ``linux`` environment:
.. code-block:: console
diff --git a/doc/guides/sample_app_ug/flow_filtering.rst b/doc/guides/sample_app_ug/flow_filtering.rst
index 9dba85acf..be3d63f90 100644
--- a/doc/guides/sample_app_ug/flow_filtering.rst
+++ b/doc/guides/sample_app_ug/flow_filtering.rst
@@ -26,7 +26,7 @@ Set the target, for example:
.. code-block:: console
- export RTE_TARGET=x86_64-native-linuxapp-gcc
+ export RTE_TARGET=x86_64-native-linux-gcc
See the *DPDK Getting Started* Guide for possible ``RTE_TARGET`` values.
@@ -40,7 +40,7 @@ Build the application as follows:
Running the Application
-----------------------
-To run the example in a ``linuxapp`` environment:
+To run the example in a ``linux`` environment:
.. code-block:: console
diff --git a/doc/guides/sample_app_ug/hello_world.rst b/doc/guides/sample_app_ug/hello_world.rst
index a2051f799..c0e0a1549 100644
--- a/doc/guides/sample_app_ug/hello_world.rst
+++ b/doc/guides/sample_app_ug/hello_world.rst
@@ -17,7 +17,7 @@ The application is located in the ``helloworld`` sub-directory.
Running the Application
-----------------------
-To run the example in a linuxapp environment:
+To run the example in a linux environment:
.. code-block:: console
@@ -48,7 +48,7 @@ This is done in the main() function using the following code:
if (ret < 0)
rte_panic("Cannot init EAL\n");
-This call finishes the initialization process that was started before main() is called (in case of a Linuxapp environment).
+This call finishes the initialization process that was started before main() is called (in case of a Linux environment).
The argc and argv arguments are provided to the rte_eal_init() function.
The value returned is the number of parsed arguments.
diff --git a/doc/guides/sample_app_ug/ip_frag.rst b/doc/guides/sample_app_ug/ip_frag.rst
index 7914a977a..2583f0c3d 100644
--- a/doc/guides/sample_app_ug/ip_frag.rst
+++ b/doc/guides/sample_app_ug/ip_frag.rst
@@ -61,7 +61,7 @@ where:
* -q NQ is the number of queue (=ports) per lcore (the default is 1)
-To run the example in linuxapp environment with 2 lcores (2,4) over 2 ports(0,2) with 1 RX queue per lcore:
+To run the example in linux environment with 2 lcores (2,4) over 2 ports(0,2) with 1 RX queue per lcore:
.. code-block:: console
@@ -90,7 +90,7 @@ To run the example in linuxapp environment with 2 lcores (2,4) over 2 ports(0,2)
IP_FRAG: entering main loop on lcore 2
IP_FRAG: -- lcoreid=2 portid=0
-To run the example in linuxapp environment with 1 lcore (4) over 2 ports(0,2) with 2 RX queues per lcore:
+To run the example in linux environment with 1 lcore (4) over 2 ports(0,2) with 2 RX queues per lcore:
.. code-block:: console
diff --git a/doc/guides/sample_app_ug/ip_reassembly.rst b/doc/guides/sample_app_ug/ip_reassembly.rst
index e1b56d7be..a628b63cb 100644
--- a/doc/guides/sample_app_ug/ip_reassembly.rst
+++ b/doc/guides/sample_app_ug/ip_reassembly.rst
@@ -57,7 +57,7 @@ where:
then they are considered as invalid and will be dropped.
Valid range is 1ms - 3600s. Default value: 1s.
-To run the example in linuxapp environment with 2 lcores (2,4) over 2 ports(0,2) with 1 RX queue per lcore:
+To run the example in linux environment with 2 lcores (2,4) over 2 ports(0,2) with 1 RX queue per lcore:
.. code-block:: console
@@ -88,7 +88,7 @@ To run the example in linuxapp environment with 2 lcores (2,4) over 2 ports(0,2)
IP_RSMBL: entering main loop on lcore 2
IP_RSMBL: -- lcoreid=2 portid=0
-To run the example in linuxapp environment with 1 lcore (4) over 2 ports(0,2) with 2 RX queues per lcore:
+To run the example in linux environment with 1 lcore (4) over 2 ports(0,2) with 2 RX queues per lcore:
.. code-block:: console
diff --git a/doc/guides/sample_app_ug/keep_alive.rst b/doc/guides/sample_app_ug/keep_alive.rst
index 5ceaa442d..865ba69e5 100644
--- a/doc/guides/sample_app_ug/keep_alive.rst
+++ b/doc/guides/sample_app_ug/keep_alive.rst
@@ -63,7 +63,7 @@ where,
* ``T PERIOD``: statistics will be refreshed each PERIOD seconds (0 to
disable, 10 default, 86400 maximum).
-To run the application in linuxapp environment with 4 lcores, 16 ports
+To run the application in linux environment with 4 lcores, 16 ports
8 RX queues per lcore and a ping interval of 10ms, issue the command:
.. code-block:: console
diff --git a/doc/guides/sample_app_ug/kernel_nic_interface.rst b/doc/guides/sample_app_ug/kernel_nic_interface.rst
index 6acdf0fff..f8fe17bd0 100644
--- a/doc/guides/sample_app_ug/kernel_nic_interface.rst
+++ b/doc/guides/sample_app_ug/kernel_nic_interface.rst
@@ -87,7 +87,7 @@ The application is located in the ``examples/kni`` sub-directory.
.. note::
- This application is intended as a linuxapp only.
+ This application is intended as a linux only.
Running the kni Example Application
-----------------------------------
diff --git a/doc/guides/sample_app_ug/l2_forward_cat.rst b/doc/guides/sample_app_ug/l2_forward_cat.rst
index 4ee877b4d..0a813200b 100644
--- a/doc/guides/sample_app_ug/l2_forward_cat.rst
+++ b/doc/guides/sample_app_ug/l2_forward_cat.rst
@@ -66,7 +66,7 @@ The application is located in the ``l2fwd-cat`` sub-directory.
Running the Application
-----------------------
-To run the example in a ``linuxapp`` environment and enable CAT on cpus 0-2:
+To run the example in a ``linux`` environment and enable CAT on cpus 0-2:
.. code-block:: console
diff --git a/doc/guides/sample_app_ug/l2_forward_crypto.rst b/doc/guides/sample_app_ug/l2_forward_crypto.rst
index 855afd8fc..e8d52dad2 100644
--- a/doc/guides/sample_app_ug/l2_forward_crypto.rst
+++ b/doc/guides/sample_app_ug/l2_forward_crypto.rst
@@ -158,7 +158,7 @@ the specified crypto operation are available on application initialization.
This means that HW crypto device/s must be bound to a DPDK driver or
a SW crypto device/s (virtual crypto PMD) must be created (using --vdev).
-To run the application in linuxapp environment with 2 lcores, 2 ports and 2 crypto devices, issue the command:
+To run the application in linux environment with 2 lcores, 2 ports and 2 crypto devices, issue the command:
.. code-block:: console
diff --git a/doc/guides/sample_app_ug/l2_forward_job_stats.rst b/doc/guides/sample_app_ug/l2_forward_job_stats.rst
index ba73d8557..dfc1ed9ca 100644
--- a/doc/guides/sample_app_ug/l2_forward_job_stats.rst
+++ b/doc/guides/sample_app_ug/l2_forward_job_stats.rst
@@ -91,7 +91,7 @@ where,
* l: Use locale thousands separator when formatting big numbers.
-To run the application in linuxapp environment with 4 lcores, 16 ports, 8 RX queues per lcore and
+To run the application in linux environment with 4 lcores, 16 ports, 8 RX queues per lcore and
thousands separator printing, issue the command:
.. code-block:: console
diff --git a/doc/guides/sample_app_ug/l2_forward_real_virtual.rst b/doc/guides/sample_app_ug/l2_forward_real_virtual.rst
index 2b2d5afa0..e5b28e425 100644
--- a/doc/guides/sample_app_ug/l2_forward_real_virtual.rst
+++ b/doc/guides/sample_app_ug/l2_forward_real_virtual.rst
@@ -101,7 +101,7 @@ where,
* --[no-]mac-updating: Enable or disable MAC addresses updating (enabled by default).
-To run the application in linuxapp environment with 4 lcores, 16 ports and 8 RX queues per lcore and MAC address
+To run the application in linux environment with 4 lcores, 16 ports and 8 RX queues per lcore and MAC address
updating enabled, issue the command:
.. code-block:: console
diff --git a/doc/guides/sample_app_ug/link_status_intr.rst b/doc/guides/sample_app_ug/link_status_intr.rst
index 695c088e8..571cd2d60 100644
--- a/doc/guides/sample_app_ug/link_status_intr.rst
+++ b/doc/guides/sample_app_ug/link_status_intr.rst
@@ -49,7 +49,7 @@ where,
* -T PERIOD: statistics will be refreshed each PERIOD seconds (0 to disable, 10 default)
-To run the application in a linuxapp environment with 4 lcores, 4 memory channels, 16 ports and 8 RX queues per lcore,
+To run the application in a linux environment with 4 lcores, 4 memory channels, 16 ports and 8 RX queues per lcore,
issue the command:
.. code-block:: console
diff --git a/doc/guides/sample_app_ug/netmap_compatibility.rst b/doc/guides/sample_app_ug/netmap_compatibility.rst
index 33b1cc214..219613e2a 100644
--- a/doc/guides/sample_app_ug/netmap_compatibility.rst
+++ b/doc/guides/sample_app_ug/netmap_compatibility.rst
@@ -117,7 +117,7 @@ where,
If two ``-i`` parameters are given, the two interfaces form a bridge,
where traffic received on one interface is replicated and sent to the other interface.
-For example, to run the application in a linuxapp environment using port 0 and 2:
+For example, to run the application in a linux environment using port 0 and 2:
.. code-block:: console
diff --git a/doc/guides/sample_app_ug/performance_thread.rst b/doc/guides/sample_app_ug/performance_thread.rst
index fbd30a5ea..e2c04efcc 100644
--- a/doc/guides/sample_app_ug/performance_thread.rst
+++ b/doc/guides/sample_app_ug/performance_thread.rst
@@ -1158,7 +1158,7 @@ To build and run the pthread shim example
.. code-block:: console
- export RTE_TARGET=x86_64-native-linuxapp-gcc
+ export RTE_TARGET=x86_64-native-linux-gcc
See the DPDK Getting Started Guide for possible RTE_TARGET values.
diff --git a/doc/guides/sample_app_ug/ptpclient.rst b/doc/guides/sample_app_ug/ptpclient.rst
index 53de50374..9d7446d5f 100644
--- a/doc/guides/sample_app_ug/ptpclient.rst
+++ b/doc/guides/sample_app_ug/ptpclient.rst
@@ -58,7 +58,7 @@ To compile the sample application see :doc:`compiling`.
The application is located in the ``ptpclient`` sub-directory.
.. note::
- To compile the application edit the ``config/common_linuxapp`` configuration file to enable IEEE1588
+ To compile the application edit the ``config/common_linux`` configuration file to enable IEEE1588
and then recompile DPDK:
.. code-block:: console
@@ -68,7 +68,7 @@ The application is located in the ``ptpclient`` sub-directory.
Running the Application
-----------------------
-To run the example in a ``linuxapp`` environment:
+To run the example in a ``linux`` environment:
.. code-block:: console
diff --git a/doc/guides/sample_app_ug/qos_scheduler.rst b/doc/guides/sample_app_ug/qos_scheduler.rst
index d6c3bc6c7..cdd29d90c 100644
--- a/doc/guides/sample_app_ug/qos_scheduler.rst
+++ b/doc/guides/sample_app_ug/qos_scheduler.rst
@@ -37,7 +37,7 @@ The application is located in the ``qos_sched`` sub-directory.
.. note::
- This application is intended as a linuxapp only.
+ This application is intended as a linux only.
.. note::
diff --git a/doc/guides/sample_app_ug/quota_watermark.rst b/doc/guides/sample_app_ug/quota_watermark.rst
index 67200e15d..125e6fb73 100644
--- a/doc/guides/sample_app_ug/quota_watermark.rst
+++ b/doc/guides/sample_app_ug/quota_watermark.rst
@@ -88,7 +88,7 @@ where,
-p PORTMASK: A hexadecimal bitmask of the ports to configure
-To run the application in a linuxapp environment with four logical cores and ports 0 and 2,
+To run the application in a linux environment with four logical cores and ports 0 and 2,
issue the following command:
.. code-block:: console
@@ -110,7 +110,7 @@ The control application requires a number of command line options:
The --proc-type=secondary option is necessary for the EAL to properly initialize the control application to
use the same huge pages as the core application and thus be able to access its rings.
-To run the application in a linuxapp environment on logical core 0, issue the following command:
+To run the application in a linux environment on logical core 0, issue the following command:
.. code-block:: console
diff --git a/doc/guides/sample_app_ug/rxtx_callbacks.rst b/doc/guides/sample_app_ug/rxtx_callbacks.rst
index 85d96d8a2..81463d28d 100644
--- a/doc/guides/sample_app_ug/rxtx_callbacks.rst
+++ b/doc/guides/sample_app_ug/rxtx_callbacks.rst
@@ -32,7 +32,7 @@ target. This is generally on by default:
Running the Application
-----------------------
-To run the example in a ``linuxapp`` environment:
+To run the example in a ``linux`` environment:
.. code-block:: console
diff --git a/doc/guides/sample_app_ug/service_cores.rst b/doc/guides/sample_app_ug/service_cores.rst
index b8339e70b..cd0f4717a 100644
--- a/doc/guides/sample_app_ug/service_cores.rst
+++ b/doc/guides/sample_app_ug/service_cores.rst
@@ -31,7 +31,7 @@ Compiling the Application
.. code-block:: console
- export RTE_TARGET=x86_64-native-linuxapp-gcc
+ export RTE_TARGET=x86_64-native-linux-gcc
See the *DPDK Getting Started* Guide for possible RTE_TARGET values.
diff --git a/doc/guides/sample_app_ug/skeleton.rst b/doc/guides/sample_app_ug/skeleton.rst
index 959561716..11ee521b3 100644
--- a/doc/guides/sample_app_ug/skeleton.rst
+++ b/doc/guides/sample_app_ug/skeleton.rst
@@ -21,7 +21,7 @@ The application is located in the ``skeleton`` sub-directory.
Running the Application
-----------------------
-To run the example in a ``linuxapp`` environment:
+To run the example in a ``linux`` environment:
.. code-block:: console
diff --git a/doc/guides/sample_app_ug/tep_termination.rst b/doc/guides/sample_app_ug/tep_termination.rst
index b3332977b..df159355d 100644
--- a/doc/guides/sample_app_ug/tep_termination.rst
+++ b/doc/guides/sample_app_ug/tep_termination.rst
@@ -94,7 +94,7 @@ Compiling the Sample Code
-------------------------
To enable vhost, turn on vhost library in the configure file
-``config/common_linuxapp``.
+``config/common_linux``.
.. code-block:: console
diff --git a/doc/guides/sample_app_ug/timer.rst b/doc/guides/sample_app_ug/timer.rst
index d87a7abc1..87dfb4c1f 100644
--- a/doc/guides/sample_app_ug/timer.rst
+++ b/doc/guides/sample_app_ug/timer.rst
@@ -17,7 +17,7 @@ The application is located in the ``timer`` sub-directory.
Running the Application
-----------------------
-To run the example in linuxapp environment:
+To run the example in linux environment:
.. code-block:: console
diff --git a/doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst b/doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst
index 0e9da9707..707afe91a 100644
--- a/doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst
+++ b/doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst
@@ -68,7 +68,7 @@ The application is located in the ``vmdq_dcb`` sub-directory.
Running the Application
-----------------------
-To run the example in a linuxapp environment:
+To run the example in a linux environment:
.. code-block:: console
@@ -250,7 +250,7 @@ See :doc:`l2_forward_real_virtual` for more information.
Statistics Display
~~~~~~~~~~~~~~~~~~
-When run in a linuxapp environment,
+When run in a linux environment,
the VMDQ and DCB Forwarding sample application can display statistics showing the number of packets read from each RX queue.
This is provided by way of a signal handler for the SIGHUP signal,
which simply prints to standard output the packet counts in grid form.
diff --git a/doc/guides/testpmd_app_ug/build_app.rst b/doc/guides/testpmd_app_ug/build_app.rst
index 45a8395e0..d1ca9f3d1 100644
--- a/doc/guides/testpmd_app_ug/build_app.rst
+++ b/doc/guides/testpmd_app_ug/build_app.rst
@@ -19,7 +19,7 @@ The basic compilation steps are:
.. code-block:: console
- export RTE_TARGET=x86_64-native-linuxapp-gcc
+ export RTE_TARGET=x86_64-native-linux-gcc
#. Build the application:
diff --git a/doc/guides/tools/testbbdev.rst b/doc/guides/tools/testbbdev.rst
index 5caa90239..f3386472d 100644
--- a/doc/guides/tools/testbbdev.rst
+++ b/doc/guides/tools/testbbdev.rst
@@ -227,7 +227,7 @@ Running Tests
-------------
Shortened tree of isg_cid-wireless_dpdk_ae with dpdk compiled for
-x86_64-native-linuxapp-icc target:
+x86_64-native-linux-icc target:
::
@@ -256,7 +256,7 @@ x86_64-native-linuxapp-icc target:
|-- turbo_enc_c1_k40_r0_e1194_rm.data
|-- turbo_enc_c1_k6144_r0_e32256_crc24b_rm.data
- |-- x86_64-native-linuxapp-icc
+ |-- x86_64-native-linux-icc
|-- app
|-- testbbdev
@@ -265,7 +265,7 @@ All bbdev devices
.. code-block:: console
- ./test-bbdev.py -p ../../x86_64-native-linuxapp-icc/app/testbbdev
+ ./test-bbdev.py -p ../../x86_64-native-linux-icc/app/testbbdev
-v turbo_dec_default.data
It runs all available tests using the test vector filled based on
@@ -279,7 +279,7 @@ baseband turbo_sw device
.. code-block:: console
- ./test-bbdev.py -p ../../x86_64-native-linuxapp-icc/app/testbbdev
+ ./test-bbdev.py -p ../../x86_64-native-linux-icc/app/testbbdev
-e="--vdev=baseband_turbo_sw" -t 120 -c validation
-v ./test_vectors/turbo_* -n 64 -b 8 32
diff --git a/drivers/net/softnic/Makefile b/drivers/net/softnic/Makefile
index 484e76cd6..64885dd86 100644
--- a/drivers/net/softnic/Makefile
+++ b/drivers/net/softnic/Makefile
@@ -46,7 +46,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_PMD_SOFTNIC) += conn.c
SYMLINK-y-include += rte_eth_softnic.h
ifneq ($(CONFIG_RTE_EXEC_ENV),"linuxapp")
-$(info Softnic PMD can only operate in a linuxapp environment, \
+$(info Softnic PMD can only operate in a linux environment, \
please change the definition of the RTE_TARGET environment variable)
all:
clean:
diff --git a/examples/Makefile b/examples/Makefile
index 33fe0e586..c7a81f08d 100644
--- a/examples/Makefile
+++ b/examples/Makefile
@@ -6,7 +6,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/bbdev_app/Makefile b/examples/bbdev_app/Makefile
index 18dd99db2..51abf82cf 100644
--- a/examples/bbdev_app/Makefile
+++ b/examples/bbdev_app/Makefile
@@ -46,7 +46,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/bond/Makefile b/examples/bond/Makefile
index d6e500aab..98a31d6b5 100644
--- a/examples/bond/Makefile
+++ b/examples/bond/Makefile
@@ -48,7 +48,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/cmdline/Makefile b/examples/cmdline/Makefile
index a617cce11..30a87626e 100644
--- a/examples/cmdline/Makefile
+++ b/examples/cmdline/Makefile
@@ -44,7 +44,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/distributor/Makefile b/examples/distributor/Makefile
index 05ea0bfec..0cda58a5b 100644
--- a/examples/distributor/Makefile
+++ b/examples/distributor/Makefile
@@ -44,7 +44,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/ethtool/Makefile b/examples/ethtool/Makefile
index 70a4f5dc9..27908bb63 100644
--- a/examples/ethtool/Makefile
+++ b/examples/ethtool/Makefile
@@ -6,12 +6,12 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overwritten by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
ifneq ($(CONFIG_RTE_EXEC_ENV_LINUX),y)
-$(info This application can only operate in a linuxapp environment, \
+$(info This application can only operate in a linux environment, \
please change the definition of the RTE_TARGET environment variable)
else
diff --git a/examples/ethtool/ethtool-app/Makefile b/examples/ethtool/ethtool-app/Makefile
index 9ecfc0b89..0dae20383 100644
--- a/examples/ethtool/ethtool-app/Makefile
+++ b/examples/ethtool/ethtool-app/Makefile
@@ -6,7 +6,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/ethtool/lib/Makefile b/examples/ethtool/lib/Makefile
index ee83b8769..70e00eee8 100644
--- a/examples/ethtool/lib/Makefile
+++ b/examples/ethtool/lib/Makefile
@@ -6,12 +6,12 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overwritten by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
ifneq ($(CONFIG_RTE_EXEC_ENV_LINUX),y)
-$(error This application can only operate in a linuxapp environment, \
+$(error This application can only operate in a linux environment, \
please change the definition of the RTE_TARGET environment variable)
endif
diff --git a/examples/eventdev_pipeline/Makefile b/examples/eventdev_pipeline/Makefile
index 1a789ccc3..238c41ea2 100644
--- a/examples/eventdev_pipeline/Makefile
+++ b/examples/eventdev_pipeline/Makefile
@@ -48,7 +48,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/exception_path/Makefile b/examples/exception_path/Makefile
index ae74781ec..1f08792ee 100644
--- a/examples/exception_path/Makefile
+++ b/examples/exception_path/Makefile
@@ -44,7 +44,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/fips_validation/Makefile b/examples/fips_validation/Makefile
index a7170d809..923d0be6e 100644
--- a/examples/fips_validation/Makefile
+++ b/examples/fips_validation/Makefile
@@ -52,7 +52,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
INC += $(sort $(wildcard *.h))
diff --git a/examples/flow_classify/Makefile b/examples/flow_classify/Makefile
index f1fa4df62..3a49f971c 100644
--- a/examples/flow_classify/Makefile
+++ b/examples/flow_classify/Makefile
@@ -46,7 +46,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/flow_filtering/Makefile b/examples/flow_filtering/Makefile
index 8f86b7b24..cc51ffdb8 100644
--- a/examples/flow_filtering/Makefile
+++ b/examples/flow_filtering/Makefile
@@ -42,7 +42,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/helloworld/Makefile b/examples/helloworld/Makefile
index d66b526b6..0b5374d03 100644
--- a/examples/helloworld/Makefile
+++ b/examples/helloworld/Makefile
@@ -44,7 +44,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/ip_fragmentation/Makefile b/examples/ip_fragmentation/Makefile
index 9e89e744c..fd186406c 100644
--- a/examples/ip_fragmentation/Makefile
+++ b/examples/ip_fragmentation/Makefile
@@ -45,7 +45,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/ip_pipeline/Makefile b/examples/ip_pipeline/Makefile
index 8b1744d0d..26d2c71b0 100644
--- a/examples/ip_pipeline/Makefile
+++ b/examples/ip_pipeline/Makefile
@@ -64,12 +64,12 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
ifneq ($(CONFIG_RTE_EXEC_ENV_LINUX),y)
-$(info This application can only operate in a linuxapp environment, \
+$(info This application can only operate in a linux environment, \
please change the definition of the RTE_TARGET environment variable)
all:
clean:
diff --git a/examples/ip_reassembly/Makefile b/examples/ip_reassembly/Makefile
index 1e81315f2..672ffe384 100644
--- a/examples/ip_reassembly/Makefile
+++ b/examples/ip_reassembly/Makefile
@@ -45,7 +45,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/ipsec-secgw/Makefile b/examples/ipsec-secgw/Makefile
index 08f474da6..0236a74bf 100644
--- a/examples/ipsec-secgw/Makefile
+++ b/examples/ipsec-secgw/Makefile
@@ -57,7 +57,7 @@ ifeq ($(RTE_SDK),)
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/ipsec-secgw/test/common_defs.sh b/examples/ipsec-secgw/test/common_defs.sh
index 1ed31f89f..693c70cd1 100644
--- a/examples/ipsec-secgw/test/common_defs.sh
+++ b/examples/ipsec-secgw/test/common_defs.sh
@@ -45,7 +45,7 @@ REMOTE_IPV6=fd12:3456:789a:0031:0000:0000:0000:0014
LOCAL_IPV6=fd12:3456:789a:0031:0000:0000:0000:0092
DPDK_PATH=${RTE_SDK:-${PWD}}
-DPDK_BUILD=${RTE_TARGET:-x86_64-native-linuxapp-gcc}
+DPDK_BUILD=${RTE_TARGET:-x86_64-native-linux-gcc}
SGW_OUT_FILE=./ipsec-secgw.out1
diff --git a/examples/ipv4_multicast/Makefile b/examples/ipv4_multicast/Makefile
index a16c62333..ea7339aa9 100644
--- a/examples/ipv4_multicast/Makefile
+++ b/examples/ipv4_multicast/Makefile
@@ -45,7 +45,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/kni/Makefile b/examples/kni/Makefile
index 096ec4d97..e6d897f94 100644
--- a/examples/kni/Makefile
+++ b/examples/kni/Makefile
@@ -45,12 +45,12 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
ifneq ($(CONFIG_RTE_EXEC_ENV_LINUX),y)
-$(error This application can only operate in a linuxapp environment, \
+$(error This application can only operate in a linux environment, \
please change the definition of the RTE_TARGET environment variable)
endif
diff --git a/examples/l2fwd-cat/Makefile b/examples/l2fwd-cat/Makefile
index b6eeabde1..111247edb 100644
--- a/examples/l2fwd-cat/Makefile
+++ b/examples/l2fwd-cat/Makefile
@@ -50,7 +50,7 @@ $(error "Please define PQOS_INSTALL_PATH environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/l2fwd-crypto/Makefile b/examples/l2fwd-crypto/Makefile
index 229fc2a89..84249a5cb 100644
--- a/examples/l2fwd-crypto/Makefile
+++ b/examples/l2fwd-crypto/Makefile
@@ -44,7 +44,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/l2fwd-jobstats/Makefile b/examples/l2fwd-jobstats/Makefile
index 696a8b21a..cacec916e 100644
--- a/examples/l2fwd-jobstats/Makefile
+++ b/examples/l2fwd-jobstats/Makefile
@@ -44,7 +44,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/l2fwd-keepalive/Makefile b/examples/l2fwd-keepalive/Makefile
index 4ab67db44..3d3f28e68 100644
--- a/examples/l2fwd-keepalive/Makefile
+++ b/examples/l2fwd-keepalive/Makefile
@@ -46,7 +46,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/l2fwd-keepalive/ka-agent/Makefile b/examples/l2fwd-keepalive/ka-agent/Makefile
index ddb6e83f6..005b72c63 100644
--- a/examples/l2fwd-keepalive/ka-agent/Makefile
+++ b/examples/l2fwd-keepalive/ka-agent/Makefile
@@ -6,7 +6,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/l2fwd/Makefile b/examples/l2fwd/Makefile
index a8a47ad4e..30866015b 100644
--- a/examples/l2fwd/Makefile
+++ b/examples/l2fwd/Makefile
@@ -44,7 +44,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/l3fwd-acl/Makefile b/examples/l3fwd-acl/Makefile
index 285683f83..294c1f101 100644
--- a/examples/l3fwd-acl/Makefile
+++ b/examples/l3fwd-acl/Makefile
@@ -44,7 +44,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/l3fwd-power/Makefile b/examples/l3fwd-power/Makefile
index 61f151c12..4c768380c 100644
--- a/examples/l3fwd-power/Makefile
+++ b/examples/l3fwd-power/Makefile
@@ -46,12 +46,12 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
ifneq ($(CONFIG_RTE_EXEC_ENV_LINUX),y)
-$(info This application can only operate in a linuxapp environment, \
+$(info This application can only operate in a linux environment, \
please change the definition of the RTE_TARGET environment variable)
all:
else
diff --git a/examples/l3fwd-vf/Makefile b/examples/l3fwd-vf/Makefile
index dfb1d52d3..90f4f7fb3 100644
--- a/examples/l3fwd-vf/Makefile
+++ b/examples/l3fwd-vf/Makefile
@@ -44,7 +44,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/l3fwd/Makefile b/examples/l3fwd/Makefile
index cccdd9dfa..9fa7a448e 100644
--- a/examples/l3fwd/Makefile
+++ b/examples/l3fwd/Makefile
@@ -44,7 +44,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/link_status_interrupt/Makefile b/examples/link_status_interrupt/Makefile
index 160682123..65773f8c4 100644
--- a/examples/link_status_interrupt/Makefile
+++ b/examples/link_status_interrupt/Makefile
@@ -44,7 +44,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/load_balancer/Makefile b/examples/load_balancer/Makefile
index 197b019d5..280dfa97e 100644
--- a/examples/load_balancer/Makefile
+++ b/examples/load_balancer/Makefile
@@ -44,7 +44,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/multi_process/Makefile b/examples/multi_process/Makefile
index 4514014a0..b0633df38 100644
--- a/examples/multi_process/Makefile
+++ b/examples/multi_process/Makefile
@@ -6,7 +6,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/multi_process/client_server_mp/Makefile b/examples/multi_process/client_server_mp/Makefile
index 76f895175..f199faf1f 100644
--- a/examples/multi_process/client_server_mp/Makefile
+++ b/examples/multi_process/client_server_mp/Makefile
@@ -6,7 +6,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/multi_process/client_server_mp/mp_server/Makefile b/examples/multi_process/client_server_mp/mp_server/Makefile
index 09ee270c0..ac18822b0 100644
--- a/examples/multi_process/client_server_mp/mp_server/Makefile
+++ b/examples/multi_process/client_server_mp/mp_server/Makefile
@@ -6,12 +6,12 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
ifneq ($(CONFIG_RTE_EXEC_ENV_LINUX),y)
-$(error This application can only operate in a linuxapp environment, \
+$(error This application can only operate in a linux environment, \
please change the definition of the RTE_TARGET environment variable)
endif
diff --git a/examples/multi_process/hotplug_mp/Makefile b/examples/multi_process/hotplug_mp/Makefile
index bc36aeaed..b5babf685 100644
--- a/examples/multi_process/hotplug_mp/Makefile
+++ b/examples/multi_process/hotplug_mp/Makefile
@@ -6,7 +6,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/multi_process/simple_mp/Makefile b/examples/multi_process/simple_mp/Makefile
index fba9c8682..6657538a4 100644
--- a/examples/multi_process/simple_mp/Makefile
+++ b/examples/multi_process/simple_mp/Makefile
@@ -6,7 +6,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/multi_process/symmetric_mp/Makefile b/examples/multi_process/symmetric_mp/Makefile
index 6fb9cc366..9226690b1 100644
--- a/examples/multi_process/symmetric_mp/Makefile
+++ b/examples/multi_process/symmetric_mp/Makefile
@@ -6,7 +6,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/netmap_compat/Makefile b/examples/netmap_compat/Makefile
index dd87ac9bd..f2bf39e69 100644
--- a/examples/netmap_compat/Makefile
+++ b/examples/netmap_compat/Makefile
@@ -6,7 +6,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
unexport RTE_SRCDIR RTE_OUTPUT RTE_EXTMK
diff --git a/examples/netmap_compat/bridge/Makefile b/examples/netmap_compat/bridge/Makefile
index 4c8981acb..3e3ff0795 100644
--- a/examples/netmap_compat/bridge/Makefile
+++ b/examples/netmap_compat/bridge/Makefile
@@ -6,12 +6,12 @@ $(error "Please define the RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
ifneq ($(CONFIG_RTE_EXEC_ENV_LINUX),y)
-$(info This application can only operate in a linuxapp environment, \
+$(info This application can only operate in a linux environment, \
please change the definition of the RTE_TARGET environment variable)
all:
clean:
diff --git a/examples/packet_ordering/Makefile b/examples/packet_ordering/Makefile
index 3cf1ee1dc..16781e762 100644
--- a/examples/packet_ordering/Makefile
+++ b/examples/packet_ordering/Makefile
@@ -44,7 +44,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/performance-thread/Makefile b/examples/performance-thread/Makefile
index 792ac661e..d63fcbbb9 100644
--- a/examples/performance-thread/Makefile
+++ b/examples/performance-thread/Makefile
@@ -6,7 +6,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/performance-thread/l3fwd-thread/Makefile b/examples/performance-thread/l3fwd-thread/Makefile
index 5558043f2..7bc0fef82 100644
--- a/examples/performance-thread/l3fwd-thread/Makefile
+++ b/examples/performance-thread/l3fwd-thread/Makefile
@@ -6,7 +6,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/performance-thread/pthread_shim/Makefile b/examples/performance-thread/pthread_shim/Makefile
index a6d276a49..731aef637 100644
--- a/examples/performance-thread/pthread_shim/Makefile
+++ b/examples/performance-thread/pthread_shim/Makefile
@@ -6,7 +6,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/ptpclient/Makefile b/examples/ptpclient/Makefile
index 989e2dd40..99c817ffd 100644
--- a/examples/ptpclient/Makefile
+++ b/examples/ptpclient/Makefile
@@ -44,7 +44,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overriddegitn by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/qos_meter/Makefile b/examples/qos_meter/Makefile
index 46341b1a7..fe44e6418 100644
--- a/examples/qos_meter/Makefile
+++ b/examples/qos_meter/Makefile
@@ -46,7 +46,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/qos_sched/Makefile b/examples/qos_sched/Makefile
index e0d298345..44df68ab8 100644
--- a/examples/qos_sched/Makefile
+++ b/examples/qos_sched/Makefile
@@ -44,12 +44,12 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
ifneq ($(CONFIG_RTE_EXEC_ENV_LINUX),y)
-$(info This application can only operate in a linuxapp environment, \
+$(info This application can only operate in a linux environment, \
please change the definition of the RTE_TARGET environment variable)
all:
clean:
diff --git a/examples/quota_watermark/Makefile b/examples/quota_watermark/Makefile
index ec7d989ae..6a20cba0c 100644
--- a/examples/quota_watermark/Makefile
+++ b/examples/quota_watermark/Makefile
@@ -6,7 +6,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/quota_watermark/qw/Makefile b/examples/quota_watermark/qw/Makefile
index 84299e594..9971acc41 100644
--- a/examples/quota_watermark/qw/Makefile
+++ b/examples/quota_watermark/qw/Makefile
@@ -6,7 +6,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/quota_watermark/qwctl/Makefile b/examples/quota_watermark/qwctl/Makefile
index b390128e7..b3640f7d4 100644
--- a/examples/quota_watermark/qwctl/Makefile
+++ b/examples/quota_watermark/qwctl/Makefile
@@ -6,7 +6,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/rxtx_callbacks/Makefile b/examples/rxtx_callbacks/Makefile
index e9d30d56f..5154089de 100644
--- a/examples/rxtx_callbacks/Makefile
+++ b/examples/rxtx_callbacks/Makefile
@@ -44,7 +44,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/server_node_efd/Makefile b/examples/server_node_efd/Makefile
index de90253fe..0e0896609 100644
--- a/examples/server_node_efd/Makefile
+++ b/examples/server_node_efd/Makefile
@@ -6,7 +6,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/server_node_efd/server/Makefile b/examples/server_node_efd/server/Makefile
index 1ca958abb..2906261dd 100644
--- a/examples/server_node_efd/server/Makefile
+++ b/examples/server_node_efd/server/Makefile
@@ -6,12 +6,12 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
ifneq ($(CONFIG_RTE_EXEC_ENV_LINUX),y)
-$(error This application can only operate in a linuxapp environment, \
+$(error This application can only operate in a linux environment, \
please change the definition of the RTE_TARGET environment variable)
endif
diff --git a/examples/service_cores/Makefile b/examples/service_cores/Makefile
index a4d6b7b44..d38acd53a 100644
--- a/examples/service_cores/Makefile
+++ b/examples/service_cores/Makefile
@@ -44,7 +44,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/skeleton/Makefile b/examples/skeleton/Makefile
index bd980ec9b..5e2742ec6 100644
--- a/examples/skeleton/Makefile
+++ b/examples/skeleton/Makefile
@@ -44,7 +44,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/tep_termination/Makefile b/examples/tep_termination/Makefile
index 44af6ca52..f5303bacb 100644
--- a/examples/tep_termination/Makefile
+++ b/examples/tep_termination/Makefile
@@ -48,12 +48,12 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
ifneq ($(CONFIG_RTE_EXEC_ENV_LINUX),y)
-$(error This application can only operate in a linuxapp environment, \
+$(error This application can only operate in a linux environment, \
please change the definition of the RTE_TARGET environment variable)
endif
diff --git a/examples/timer/Makefile b/examples/timer/Makefile
index 42b23f28e..daed94d29 100644
--- a/examples/timer/Makefile
+++ b/examples/timer/Makefile
@@ -44,7 +44,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/vdpa/Makefile b/examples/vdpa/Makefile
index 42672a2bc..b28378f0c 100644
--- a/examples/vdpa/Makefile
+++ b/examples/vdpa/Makefile
@@ -6,12 +6,12 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
ifneq ($(CONFIG_RTE_EXEC_ENV),"linuxapp")
-$(info This application can only operate in a linuxapp environment, \
+$(info This application can only operate in a linux environment, \
please change the definition of the RTE_TARGET environment variable)
all:
else
diff --git a/examples/vhost/Makefile b/examples/vhost/Makefile
index 540ccaaee..d58d002ba 100644
--- a/examples/vhost/Makefile
+++ b/examples/vhost/Makefile
@@ -48,12 +48,12 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
ifneq ($(CONFIG_RTE_EXEC_ENV_LINUX),y)
-$(info This application can only operate in a linuxapp environment, \
+$(info This application can only operate in a linux environment, \
please change the definition of the RTE_TARGET environment variable)
all:
else
diff --git a/examples/vhost_crypto/Makefile b/examples/vhost_crypto/Makefile
index 719cc5595..80403a5e9 100644
--- a/examples/vhost_crypto/Makefile
+++ b/examples/vhost_crypto/Makefile
@@ -6,12 +6,12 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
ifneq ($(CONFIG_RTE_EXEC_ENV_LINUX),y)
-$(info This application can only operate in a linuxapp environment, \
+$(info This application can only operate in a linux environment, \
please change the definition of the RTE_TARGET environment variable)
all:
else
diff --git a/examples/vhost_scsi/Makefile b/examples/vhost_scsi/Makefile
index 3392d24b2..58ff7a25c 100644
--- a/examples/vhost_scsi/Makefile
+++ b/examples/vhost_scsi/Makefile
@@ -47,12 +47,12 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
ifneq ($(CONFIG_RTE_EXEC_ENV_LINUX),y)
-$(info This application can only operate in a linuxapp environment, \
+$(info This application can only operate in a linux environment, \
please change the definition of the RTE_TARGET environment variable)
all:
else
diff --git a/examples/vm_power_manager/Makefile b/examples/vm_power_manager/Makefile
index 50147c05d..e608bb61a 100644
--- a/examples/vm_power_manager/Makefile
+++ b/examples/vm_power_manager/Makefile
@@ -10,7 +10,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/vm_power_manager/guest_cli/Makefile b/examples/vm_power_manager/guest_cli/Makefile
index 8b1db861e..a5634eacf 100644
--- a/examples/vm_power_manager/guest_cli/Makefile
+++ b/examples/vm_power_manager/guest_cli/Makefile
@@ -6,7 +6,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/vmdq/Makefile b/examples/vmdq/Makefile
index 87abeab93..09ff070a8 100644
--- a/examples/vmdq/Makefile
+++ b/examples/vmdq/Makefile
@@ -44,7 +44,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/examples/vmdq_dcb/Makefile b/examples/vmdq_dcb/Makefile
index bf161cb2b..436ccb9c1 100644
--- a/examples/vmdq_dcb/Makefile
+++ b/examples/vmdq_dcb/Makefile
@@ -44,7 +44,7 @@ $(error "Please define RTE_SDK environment variable")
endif
# Default target, can be overridden by command line or environment
-RTE_TARGET ?= x86_64-native-linuxapp-gcc
+RTE_TARGET ?= x86_64-native-linux-gcc
include $(RTE_SDK)/mk/rte.vars.mk
diff --git a/lib/librte_eal/common/include/rte_debug.h b/lib/librte_eal/common/include/rte_debug.h
index 272df494c..748d32c80 100644
--- a/lib/librte_eal/common/include/rte_debug.h
+++ b/lib/librte_eal/common/include/rte_debug.h
@@ -39,7 +39,7 @@ void rte_dump_registers(void);
*
* Display the format string and its expanded arguments (printf-like).
*
- * In a linuxapp environment, this function dumps the stack and calls
+ * In a linux environment, this function dumps the stack and calls
* abort() resulting in a core dump if enabled.
*
* The function never returns.
diff --git a/lib/librte_eal/common/include/rte_eal.h b/lib/librte_eal/common/include/rte_eal.h
index a0cedd573..833433229 100644
--- a/lib/librte_eal/common/include/rte_eal.h
+++ b/lib/librte_eal/common/include/rte_eal.h
@@ -41,7 +41,7 @@ enum rte_lcore_role_t {
};
/**
- * The type of process in a linuxapp, multi-process setup
+ * The type of process in a linux, multi-process setup
*/
enum rte_proc_type_t {
RTE_PROC_AUTO = -1, /* allow auto-detection of primary/secondary */
diff --git a/lib/librte_eal/freebsd/eal/Makefile b/lib/librte_eal/freebsd/eal/Makefile
index aa4b9ef8e..8e9450c26 100644
--- a/lib/librte_eal/freebsd/eal/Makefile
+++ b/lib/librte_eal/freebsd/eal/Makefile
@@ -24,7 +24,7 @@ EXPORT_MAP := ../../rte_eal_version.map
LIBABIVER := 9
-# specific to bsdapp exec-env
+# specific to freebsd exec-env
SRCS-$(CONFIG_RTE_EXEC_ENV_FREEBSD) := eal.c
SRCS-$(CONFIG_RTE_EXEC_ENV_FREEBSD) += eal_cpuflags.c
SRCS-$(CONFIG_RTE_EXEC_ENV_FREEBSD) += eal_memory.c
@@ -86,7 +86,7 @@ CFLAGS_eal_thread.o += -Wno-return-type
CFLAGS_eal_hpet.o += -Wno-return-type
endif
-INC := # no bsdapp specific headers
+INC := # no bsd specific headers
SYMLINK-$(CONFIG_RTE_EXEC_ENV_FREEBSD)-include/exec-env := \
$(addprefix include/exec-env/,$(INC))
diff --git a/lib/librte_eal/linux/eal/Makefile b/lib/librte_eal/linux/eal/Makefile
index 9e32f1174..e5e668cd0 100644
--- a/lib/librte_eal/linux/eal/Makefile
+++ b/lib/librte_eal/linux/eal/Makefile
@@ -29,7 +29,7 @@ ifeq ($(CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES),y)
LDLIBS += -lnuma
endif
-# specific to linuxapp exec-env
+# specific to linux exec-env
SRCS-$(CONFIG_RTE_EXEC_ENV_LINUX) := eal.c
SRCS-$(CONFIG_RTE_EXEC_ENV_LINUX) += eal_cpuflags.c
SRCS-$(CONFIG_RTE_EXEC_ENV_LINUX) += eal_hugepage_info.c
diff --git a/mk/exec-env/bsdapp b/mk/exec-env/bsdapp
new file mode 120000
index 000000000..69f5cba2c
--- /dev/null
+++ b/mk/exec-env/bsdapp
@@ -0,0 +1 @@
+freebsd/
\ No newline at end of file
diff --git a/mk/exec-env/bsdapp/rte.app.mk b/mk/exec-env/freebsd/rte.app.mk
similarity index 100%
rename from mk/exec-env/bsdapp/rte.app.mk
rename to mk/exec-env/freebsd/rte.app.mk
diff --git a/mk/exec-env/bsdapp/rte.vars.mk b/mk/exec-env/freebsd/rte.vars.mk
similarity index 94%
rename from mk/exec-env/bsdapp/rte.vars.mk
rename to mk/exec-env/freebsd/rte.vars.mk
index cec08840b..c6be560b3 100644
--- a/mk/exec-env/bsdapp/rte.vars.mk
+++ b/mk/exec-env/freebsd/rte.vars.mk
@@ -9,7 +9,7 @@
# - define EXECENV_ASFLAGS variable (overridden by cmdline)
# - may override any previously defined variable
#
-# examples for RTE_EXEC_ENV: linuxapp, bsdapp
+# examples for RTE_EXEC_ENV: linux, freebsd
#
ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
EXECENV_CFLAGS = -pthread -fPIC
diff --git a/mk/exec-env/linuxapp/rte.app.mk b/mk/exec-env/linux/rte.app.mk
similarity index 100%
rename from mk/exec-env/linuxapp/rte.app.mk
rename to mk/exec-env/linux/rte.app.mk
diff --git a/mk/exec-env/linuxapp/rte.vars.mk b/mk/exec-env/linux/rte.vars.mk
similarity index 95%
rename from mk/exec-env/linuxapp/rte.vars.mk
rename to mk/exec-env/linux/rte.vars.mk
index 57ee82150..d04d0e29c 100644
--- a/mk/exec-env/linuxapp/rte.vars.mk
+++ b/mk/exec-env/linux/rte.vars.mk
@@ -9,7 +9,7 @@
# - define EXECENV_ASFLAGS variable (overridden by cmdline)
# - may override any previously defined variable
#
-# examples for RTE_EXEC_ENV: linuxapp, bsdapp
+# examples for RTE_EXEC_ENV: linux, freebsd
#
ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y)
EXECENV_CFLAGS = -pthread -fPIC
diff --git a/mk/exec-env/linuxapp b/mk/exec-env/linuxapp
new file mode 120000
index 000000000..ce5e2c77b
--- /dev/null
+++ b/mk/exec-env/linuxapp
@@ -0,0 +1 @@
+linux/
\ No newline at end of file
diff --git a/mk/rte.sdkconfig.mk b/mk/rte.sdkconfig.mk
index fa77331cb..c79bec179 100644
--- a/mk/rte.sdkconfig.mk
+++ b/mk/rte.sdkconfig.mk
@@ -21,9 +21,10 @@ showversionum:
$(RTE_SRCDIR)/lib/librte_eal/common/include/rte_version.h); \
printf '%02d%02d\n' "$$1" "$$2"
-INSTALL_CONFIGS := $(sort $(filter-out %~,\
+INSTALL_CONFIGS := $(sort $(filter-out %app-icc,$(filter-out %app-clang,\
+ $(filter-out %app-gcc,$(filter-out %~,\
$(patsubst $(RTE_SRCDIR)/config/defconfig_%,%,\
- $(wildcard $(RTE_SRCDIR)/config/defconfig_*))))
+ $(wildcard $(RTE_SRCDIR)/config/defconfig_*)))))))
INSTALL_TARGETS := $(addsuffix _install,$(INSTALL_CONFIGS))
.PHONY: showconfigs
@@ -53,9 +54,9 @@ defconfig:
)-$(shell \
uname | awk '{ \
if ($$0 == "Linux") { \
- print "linuxapp"} \
+ print "linux"} \
else { \
- print "bsdapp"} }' \
+ print "freebsd"} }' \
)-$(shell \
${CC} --version | grep -o 'cc\|gcc\|icc\|clang' | awk \
'{ \
diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk
index 2d34b4e5a..5c4215cd7 100644
--- a/mk/rte.sdkinstall.mk
+++ b/mk/rte.sdkinstall.mk
@@ -24,6 +24,9 @@ export prefix ?=
kerneldir ?= $(prefix)/kmod
else
ifeq ($(RTE_EXEC_ENV),linuxapp)
+RTE_EXEC_ENV=linux
+endif
+ifeq ($(RTE_EXEC_ENV),linux)
kerneldir ?= /lib/modules/$(shell uname -r)/extra/dpdk
else
kerneldir ?= /boot/modules
diff --git a/mk/rte.sdkroot.mk b/mk/rte.sdkroot.mk
index d91583a63..4043a9d4e 100644
--- a/mk/rte.sdkroot.mk
+++ b/mk/rte.sdkroot.mk
@@ -28,7 +28,7 @@ export BUILDING_RTE_SDK
#
# We can specify the configuration template when doing the "make
-# config". For instance: make config T=x86_64-native-linuxapp-gcc
+# config". For instance: make config T=x86_64-native-linux-gcc
#
RTE_CONFIG_TEMPLATE :=
ifdef T
diff --git a/usertools/dpdk-setup.sh b/usertools/dpdk-setup.sh
index 5eebbce87..d00807420 100755
--- a/usertools/dpdk-setup.sh
+++ b/usertools/dpdk-setup.sh
@@ -479,7 +479,7 @@ step1_func()
#
step2_func()
{
- TITLE="Setup linuxapp environment"
+ TITLE="Setup linux environment"
TEXT[1]="Insert IGB UIO module"
FUNC[1]="load_igb_uio_module"
@@ -514,7 +514,7 @@ step2_func()
#
step3_func()
{
- TITLE="Run test application for linuxapp environment"
+ TITLE="Run test application for linux environment"
TEXT[1]="Run test application (\$RTE_TARGET/app/test)"
FUNC[1]="run_test_app"
--
2.20.1
^ permalink raw reply [relevance 7%]
* [dpdk-dev] [PATCH v4 0/2] Timer library changes
2019-03-05 22:41 0% ` Carrillo, Erik G
@ 2019-03-06 17:20 5% ` Erik Gabriel Carrillo
1 sibling, 0 replies; 200+ results
From: Erik Gabriel Carrillo @ 2019-03-06 17:20 UTC (permalink / raw)
To: rsanford, thomas; +Cc: dev, nhorman
This patch series modifies the timer library in such a way that
structures that used to be statically allocated in a process's data
segment are now allocated in shared memory. As these structures contain
lists of timers, new APIs are introduced that allow a caller to specify
the particular structure instance into which a timer should be inserted
or from which a timer should be removed. This enables primary and
secondary processes to modify the same timer list, which enables some
multi-process use cases that were not previously possible; e.g. a
secondary process can start a timer whose expiration is detected in a
primary process running a new flavor of timer_manage().
The original library API is mostly unchanged, though implementations are
updated to call into newly added functions with a default structure
instance ID that provides the original behavior. New functions are
introduced to enable applications to allocate structure instances to
house timer lists, and to reference them with an identifier when
starting and stopping timers, and finally, to manage the timer lists
referenced with an identifier.
My initial performance testing with the "timer_perf_autotest" test shows
no performance regression or improvement, and inspection of the
generated optimized code shows that the extra function call gets inlined
in the functions that now have an extra function call.
Changes in v4:
- Updated versioned symbols so that they correspond to the next
release. Checked ABI compatibility again with validate-abi.sh.
Changes in v3:
- remove C++ style comment in first patch in series (Stephen)
Changes in v2:
- split these changes out into their own series
- version the symbols where the existing ABI was updated, and
provide alternate implementation with behavior equivalent to original
behavior. Validated ABI compatibility with validate-abi.sh
- refactor changes to simplify patches
Erik Gabriel Carrillo (2):
timer: allow timer management in shared memory
timer: add function to stop all timers in a list
lib/librte_timer/Makefile | 1 +
lib/librte_timer/rte_timer.c | 558 ++++++++++++++++++++++++++++++---
lib/librte_timer/rte_timer.h | 258 ++++++++++++++-
lib/librte_timer/rte_timer_version.map | 23 ++
4 files changed, 795 insertions(+), 45 deletions(-)
--
2.6.4
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH v1 2/6] lib/mbuf: enable parse flags when create mempool
2019-03-05 8:30 3% ` David Marchand
@ 2019-03-07 3:07 0% ` Ye Xiaolong
0 siblings, 0 replies; 200+ results
From: Ye Xiaolong @ 2019-03-07 3:07 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Qi Zhang, Olivier Matz
Hi David,
Thanks for you comments.
On 03/05, David Marchand wrote:
>On Fri, Mar 1, 2019 at 9:13 AM Xiaolong Ye <xiaolong.ye@intel.com> wrote:
>
>> This give the option that applicaiton can configure each
>> memory chunk's size precisely. (by MEMPOOL_F_NO_SPREAD).
>>
>> Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
>> Signed-off-by: Xiaolong Ye <xiaolong.ye@intel.com>
>>
>
>Cc: maintainer
>
>---
>> lib/librte_mbuf/rte_mbuf.c | 15 ++++++++++++---
>> lib/librte_mbuf/rte_mbuf.h | 8 +++++++-
>> 2 files changed, 19 insertions(+), 4 deletions(-)
>>
>> diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
>> index 21f6f7404..0f6fcff28 100644
>> --- a/lib/librte_mbuf/rte_mbuf.c
>> +++ b/lib/librte_mbuf/rte_mbuf.c
>> @@ -110,7 +110,7 @@ rte_pktmbuf_init(struct rte_mempool *mp,
>> struct rte_mempool *
>> rte_pktmbuf_pool_create_by_ops(const char *name, unsigned int n,
>> unsigned int cache_size, uint16_t priv_size, uint16_t
>> data_room_size,
>> - int socket_id, const char *ops_name)
>> + unsigned int flags, int socket_id, const char *ops_name)
>> {
>> struct rte_mempool *mp;
>> struct rte_pktmbuf_pool_private mbp_priv;
>>
>
>You can't do that, rte_pktmbuf_pool_create_by_ops is exposed to the user
>apps and part of the ABI.
>You must define a new internal fonction that takes this flag, keeps the
>existing interface and add your new experimental api.
>
In this case, if I define a new function that takes the flag, it seems would
have a lot of duplicated code with rte_pktmbuf_pool_create_by_ops, do you have
any suggestions for better handling?
Thanks,
Xiaolong
>
>--
>David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] lib/cryptodev: fix driver name comparison
2019-03-01 6:24 0% ` Anoob Joseph
@ 2019-03-07 5:51 0% ` Anoob Joseph
0 siblings, 0 replies; 200+ results
From: Anoob Joseph @ 2019-03-07 5:51 UTC (permalink / raw)
To: Anoob Joseph, Trahe, Fiona, Akhil Goyal, Doherty, Declan,
De Lara Guarch, Pablo, Yigit, Ferruh, Thomas Monjalon
Cc: Jerin Jacob Kollanukkaran, Narayana Prasad Raju Athreya, dev,
Ankur Dwivedi
Hi Akhil, Fiona,
Would the usage of strcmp be alright? Please check my comment inline.
Thanks,
Anoob
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Anoob Joseph
> Sent: Friday, March 1, 2019 11:55 AM
> To: Trahe, Fiona <fiona.trahe@intel.com>; Akhil Goyal
> <akhil.goyal@nxp.com>; Doherty, Declan <declan.doherty@intel.com>; De
> Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Yigit, Ferruh
> <ferruh.yigit@intel.com>; Thomas Monjalon <thomas@monjalon.net>
> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad Raju
> Athreya <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi
> <adwivedi@marvell.com>
> Subject: Re: [dpdk-dev] [PATCH] lib/cryptodev: fix driver name comparison
>
> Hi Fiona, Akhil,
>
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Trahe, Fiona
> > Sent: Thursday, February 28, 2019 8:00 PM
> > To: Akhil Goyal <akhil.goyal@nxp.com>; Anoob Joseph
> > <anoobj@marvell.com>; Doherty, Declan <declan.doherty@intel.com>; De
> > Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Yigit, Ferruh
> > <ferruh.yigit@intel.com>; Thomas Monjalon <thomas@monjalon.net>
> > Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad
> > Raju Athreya <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi
> > <adwivedi@marvell.com>; Trahe, Fiona <fiona.trahe@intel.com>
> > Subject: Re: [dpdk-dev] [PATCH] lib/cryptodev: fix driver name
> > comparison
> >
> > Hi Akhil, Anoob,
> >
> > > -----Original Message-----
> > > From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> > > Sent: Thursday, February 28, 2019 10:20 AM
> > > To: Anoob Joseph <anoobj@marvell.com>; Trahe, Fiona
> > > <fiona.trahe@intel.com>; Doherty, Declan <declan.doherty@intel.com>;
> > > De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Yigit,
> > > Ferruh <ferruh.yigit@intel.com>; Thomas Monjalon
> > > <thomas@monjalon.net>
> > > Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana Prasad
> > > Raju Athreya <pathreya@marvell.com>; dev@dpdk.org; Ankur Dwivedi
> > > <adwivedi@marvell.com>
> > > Subject: Re: [dpdk-dev] [PATCH] lib/cryptodev: fix driver name
> > > comparison
> > >
> > >
> > >
> > > On 2/28/2019 2:57 PM, Anoob Joseph wrote:
> > > > Hi Akhil,
> > > >
> > > > Please see inline.
> > > >
> > > > Thanks,
> > > > Anoob
> > > >
> > > >> -----Original Message-----
> > > >> From: Akhil Goyal <akhil.goyal@nxp.com>
> > > >> Sent: Thursday, February 28, 2019 2:22 PM
> > > >> To: Anoob Joseph <anoobj@marvell.com>; Trahe, Fiona
> > > >> <fiona.trahe@intel.com>; Doherty, Declan
> > > >> <declan.doherty@intel.com>; De Lara Guarch, Pablo
> > > >> <pablo.de.lara.guarch@intel.com>; Yigit, Ferruh
> > > >> <ferruh.yigit@intel.com>; Thomas Monjalon
> <thomas@monjalon.net>
> > > >> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana
> > > >> Prasad Raju Athreya <pathreya@marvell.com>; dev@dpdk.org; Ankur
> > > >> Dwivedi <adwivedi@marvell.com>
> > > >> Subject: Re: [dpdk-dev] [PATCH] lib/cryptodev: fix driver name
> > > >> comparison
> > > >>
> > > >> Hi Anoob,
> > > >>
> > > >> On 2/28/2019 12:18 PM, Anoob Joseph wrote:
> > > >>> Hi Akhil, Declan, Pablo,
> > > >>>
> > > >>> Can you review this patch and share your thoughts?
> > > >>>
> > > >>> Thanks,
> > > >>> Anoob
> > > >>>
> > > >>>> -----Original Message-----
> > > >>>> From: Trahe, Fiona <fiona.trahe@intel.com>
> > > >>>> Sent: Monday, February 25, 2019 5:22 PM
> > > >>>> To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal
> > > >>>> <akhil.goyal@nxp.com>; Doherty, Declan
> > > >>>> <declan.doherty@intel.com>;
> > > >> De
> > > >>>> Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Yigit,
> > > >>>> Ferruh <ferruh.yigit@intel.com>; Thomas Monjalon
> > > >>>> <thomas@monjalon.net>
> > > >>>> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana
> > > >>>> Prasad Raju Athreya <pathreya@marvell.com>; dev@dpdk.org;
> > Ankur
> > > >>>> Dwivedi <adwivedi@marvell.com>
> > > >>>> Subject: RE: [PATCH] lib/cryptodev: fix driver name comparison
> > > >>>>
> > > >>>> Hi Anoob
> > > >>>>
> > > >>>>> -----Original Message-----
> > > >>>>> From: Anoob Joseph [mailto:anoobj@marvell.com]
> > > >>>>> Sent: Saturday, February 23, 2019 6:12 AM
> > > >>>>> To: Trahe, Fiona <fiona.trahe@intel.com>; Akhil Goyal
> > > >>>>> <akhil.goyal@nxp.com>; Doherty, Declan
> > > >>>>> <declan.doherty@intel.com>; De Lara Guarch, Pablo
> > > >>>>> <pablo.de.lara.guarch@intel.com>; Yigit, Ferruh
> > > >>>>> <ferruh.yigit@intel.com>; Thomas Monjalon
> > <thomas@monjalon.net>
> > > >>>>> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana
> > > >>>>> Prasad Raju Athreya <pathreya@marvell.com>; dev@dpdk.org;
> > Ankur
> > > >>>>> Dwivedi <adwivedi@marvell.com>
> > > >>>>> Subject: RE: [PATCH] lib/cryptodev: fix driver name comparison
> > > >>>>>
> > > >>>>> Hi Fiona,
> > > >>>>>
> > > >>>>>> -----Original Message-----
> > > >>>>>> From: Trahe, Fiona <fiona.trahe@intel.com>
> > > >>>>>> Sent: Friday, February 22, 2019 9:09 PM
> > > >>>>>> To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal
> > > >>>>>> <akhil.goyal@nxp.com>; Doherty, Declan
> > > >> <declan.doherty@intel.com>;
> > > >>>>>> De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> > > >>>>>> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana
> > > >>>>>> Prasad Raju Athreya <pathreya@marvell.com>; dev@dpdk.org;
> > Ankur
> > > >>>>>> Dwivedi <adwivedi@marvell.com>; Trahe, Fiona
> > > >>>>>> <fiona.trahe@intel.com>
> > > >>>>>> Subject: RE: [PATCH] lib/cryptodev: fix driver name
> > > >>>>>> comparison
> > > >>>>>>
> > > >>>>>> Hi Anoob,
> > > >>>>>>
> > > >>>>>>>>>> @@ -542,8 +543,8 @@ rte_cryptodev_get_dev_id(const
> char
> > > >>>> *name)
> > > >>>>>>>>>> return -1;
> > > >>>>>>>>>>
> > > >>>>>>>>>> for (i = 0; i < cryptodev_globals.nb_devs; i++)
> > > >>>>>>>>>> - if ((strcmp(cryptodev_globals.devs[i].data-
> > >name,
> > > >>>> name)
> > > >>>>>>>>>> - == 0) &&
> > > >>>>>>>>>> + if ((strncmp(cryptodev_globals.devs[i].data-
> > >name,
> > > >>>>>> name,
> > > >>>>>>>>>> +
> > RTE_CRYPTODEV_NAME_MAX_LEN)
> > > >> consider using "strlen(name) + 1" instead of
> > > >> RTE_CRYPTODEV_NAME_MAX_LEN.
> > > >> This will not cause any ABI breakage in my opinion and and will
> > > >> check till we get a null terminated string in both the strings.
> > > >> What say?
> > > > [Anoob] In that case, I'll restrict the patch to two places.
> > > > Wherever strlen(name) is used, I'll make it
> > > strlen(name)+1. I won't touch strcmp ones as that would work as is.
> > > Shall I
> > prepare a v2?
> > > I think it should be fine.
> > >
> > > Fiona,
> > > Any comments?
> > [Fiona] Good idea. That should be ok.
>
> [Anoob] Another thought. If we are fine with doing strlen of input buffer,
> then using strcmp would also do. That way the usage also would be uniform
> in the file.
>
> Thanks,
> Anoob
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v2] doc: announce ABI change for cryptodev config
2019-01-31 9:53 4% ` Akhil Goyal
@ 2019-03-07 10:39 4% ` Anoob Joseph
2019-03-07 15:25 4% ` Trahe, Fiona
1 sibling, 1 reply; 200+ results
From: Anoob Joseph @ 2019-03-07 10:39 UTC (permalink / raw)
To: Akhil Goyal, Fiona Trahe, Pablo de Lara
Cc: Anoob Joseph, Jerin Jacob Kollanukkaran,
Narayana Prasad Raju Athreya, Shally Verma, Suheil Chandran, dev
Add new field ff_disable in rte_cryptodev_config. This enables
applications to control the features enabled on the crypto device.
Proposed new layout:
/** Crypto device configuration structure */
struct rte_cryptodev_config {
int socket_id; /**< Socket to allocate resources on */
uint16_t nb_queue_pairs;
/**< Number of queue pairs to configure on device */
+ uint64_t ff_disable;
+ /**< Feature flags to be disabled. Only the following features are
+ * allowed to be disabled,
+ * - RTE_CRYPTODEV_FF_SYMMETRIC_CRYPTO
+ * - RTE_CRYPTODEV_FF_ASYMMETRIC_CRYPTO
+ * - RTE_CRYTPODEV_FF_SECURITY
+ */
};
For eth devices, rte_eth_conf.rx_mode.offloads and
rte_eth_conf.tx_mode.offloads fields are used by applications to
control the offloads enabled on the eth device. This proposal adds a
similar ability for the crypto device.
Signed-off-by: Anoob Joseph <anoobj@marvell.com>
---
v2:
* Renamed 'ff_enable' to 'ff_disable'
doc/guides/rel_notes/deprecation.rst | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 1b4fcb7..d0a60f9 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -75,3 +75,17 @@ Deprecation Notices
* crypto/aesni_mb: the minimum supported intel-ipsec-mb library version will be
changed from 0.49.0 to 0.52.0.
+
+* cryptodev: New member in ``rte_cryptodev_config`` to allow applications to
+ disable features supported by the crypto device. Only the following features
+ would be allowed to be disabled this way,
+
+ - ``RTE_CRYPTODEV_FF_SYMMETRIC_CRYPTO``
+ - ``RTE_CRYPTODEV_FF_ASYMMETRIC_CRYPTO``
+ - ``RTE_CRYPTODEV_FF_SECURITY``
+
+ Disabling unused features would facilitate efficient usage of HW/SW offload.
+
+ - Member ``uint64_t ff_disable`` in ``rte_cryptodev_config``
+
+ The field would be added in v19.08.
--
2.7.4
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] cryptodev: fix restore crypto op alignment and layout
@ 2019-03-07 14:13 8% Konstantin Ananyev
2019-03-08 12:59 0% ` Trahe, Fiona
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Konstantin Ananyev @ 2019-03-07 14:13 UTC (permalink / raw)
To: dev
Cc: akhil.goyal, umesh.kartha, pablo.de.lara.guarch, shally.verma,
Konstantin Ananyev
in 18.08 new cache-aligned structure rte_crypto_asym_op was introduced.
As it also was included into rte_crypto_op, it caused implicit change
in rte_crypto_op layout and alignment: now rte_crypto_op is cahce-line
aligned has a hole of 40/104 bytes between phys_addr and sym/asym op.
It looks like unintended ABI breakage, plus such change can cause
negative performance effects:
- now status and sym[0].m_src lies on different cache-lines, so
post-process code would need extra cache-line read.
- new alignment causes grow of the space requirements and cache-line
reads/updates for structures that contain rte_crypto_op inside.
As there seems no actual need to have rte_crypto_asym_op cache-line
aligned, and rte_crypto_asym_op is not intended to be used on it's own -
the simplest fix is just to remove cache-line alignment for it.
As the immediate positive effect: on IA ipsec-secgw performance increased
by 5-10% (depending on the crypto-dev and algo used).
My guess that on machines with 128B cache-line and lookaside-protocol
capable crypto devices the impact will be even more noticeable.
Fixes: 26008aaed14c ("cryptodev: add asymmetric xform and op definitions")
Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
---
doc/guides/rel_notes/release_19_05.rst | 7 +++++++
lib/librte_cryptodev/Makefile | 2 +-
lib/librte_cryptodev/meson.build | 2 +-
lib/librte_cryptodev/rte_crypto_asym.h | 2 +-
4 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index c0390ca16..ec2651b65 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -116,6 +116,13 @@ ABI Changes
Also, make sure to start the actual text at the margin.
=========================================================
+* cryptodev: in 18.08 new structure ``rte_crypto_asym_op`` was introduced and
+ included into ``rte_crypto_op``. As ``rte_crypto_asym_op`` structure was
+ defined as cache-line aligned that caused unintended changes in
+ ``rte_crypto_op`` structure layout and alignment. Remove cache-line
+ alignment for ``rte_crypto_asym_op`` to restore expected ``rte_crypto_op``
+ layout and alignment.
+
Shared Library Versions
-----------------------
diff --git a/lib/librte_cryptodev/Makefile b/lib/librte_cryptodev/Makefile
index 859c4f0f1..c20e090a8 100644
--- a/lib/librte_cryptodev/Makefile
+++ b/lib/librte_cryptodev/Makefile
@@ -7,7 +7,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
LIB = librte_cryptodev.a
# library version
-LIBABIVER := 6
+LIBABIVER := 7
# build flags
CFLAGS += -O3
diff --git a/lib/librte_cryptodev/meson.build b/lib/librte_cryptodev/meson.build
index bcd969437..9e009d466 100644
--- a/lib/librte_cryptodev/meson.build
+++ b/lib/librte_cryptodev/meson.build
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017-2019 Intel Corporation
-version = 6
+version = 7
allow_experimental_apis = true
sources = files('rte_cryptodev.c', 'rte_cryptodev_pmd.c')
headers = files('rte_cryptodev.h',
diff --git a/lib/librte_cryptodev/rte_crypto_asym.h b/lib/librte_cryptodev/rte_crypto_asym.h
index 5e185b2dd..70465c90d 100644
--- a/lib/librte_cryptodev/rte_crypto_asym.h
+++ b/lib/librte_cryptodev/rte_crypto_asym.h
@@ -487,7 +487,7 @@ struct rte_crypto_asym_op {
struct rte_crypto_dh_op_param dh;
struct rte_crypto_dsa_op_param dsa;
};
-} __rte_cache_aligned;
+};
#ifdef __cplusplus
}
--
2.17.1
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [PATCH v2] doc: announce ABI change for cryptodev config
2019-03-07 10:39 4% ` [dpdk-dev] [PATCH v2] " Anoob Joseph
@ 2019-03-07 15:25 4% ` Trahe, Fiona
2019-03-29 14:23 4% ` Akhil Goyal
0 siblings, 1 reply; 200+ results
From: Trahe, Fiona @ 2019-03-07 15:25 UTC (permalink / raw)
To: Anoob Joseph, Akhil Goyal, De Lara Guarch, Pablo
Cc: Jerin Jacob Kollanukkaran, Narayana Prasad Raju Athreya,
Shally Verma, Suheil Chandran, dev, Trahe, Fiona
> -----Original Message-----
> From: Anoob Joseph [mailto:anoobj@marvell.com]
> Sent: Thursday, March 7, 2019 10:40 AM
> To: Akhil Goyal <akhil.goyal@nxp.com>; Trahe, Fiona <fiona.trahe@intel.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>
> Cc: Anoob Joseph <anoobj@marvell.com>; Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana
> Prasad Raju Athreya <pathreya@marvell.com>; Shally Verma <shallyv@marvell.com>; Suheil Chandran
> <schandran@marvell.com>; dev@dpdk.org
> Subject: [PATCH v2] doc: announce ABI change for cryptodev config
>
> Add new field ff_disable in rte_cryptodev_config. This enables
> applications to control the features enabled on the crypto device.
>
> Proposed new layout:
>
> /** Crypto device configuration structure */
> struct rte_cryptodev_config {
> int socket_id; /**< Socket to allocate resources on */
> uint16_t nb_queue_pairs;
> /**< Number of queue pairs to configure on device */
> + uint64_t ff_disable;
> + /**< Feature flags to be disabled. Only the following features are
> + * allowed to be disabled,
> + * - RTE_CRYPTODEV_FF_SYMMETRIC_CRYPTO
> + * - RTE_CRYPTODEV_FF_ASYMMETRIC_CRYPTO
> + * - RTE_CRYTPODEV_FF_SECURITY
> + */
> };
>
> For eth devices, rte_eth_conf.rx_mode.offloads and
> rte_eth_conf.tx_mode.offloads fields are used by applications to
> control the offloads enabled on the eth device. This proposal adds a
> similar ability for the crypto device.
>
> Signed-off-by: Anoob Joseph <anoobj@marvell.com>
Acked-by: Fiona Trahe <fiona.trahe@intel.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] cryptodev: fix restore crypto op alignment and layout
2019-03-07 14:13 8% [dpdk-dev] [PATCH] cryptodev: fix restore crypto op alignment and layout Konstantin Ananyev
@ 2019-03-08 12:59 0% ` Trahe, Fiona
2019-03-12 12:04 0% ` Shally Verma
2019-03-19 13:33 3% ` Akhil Goyal
2 siblings, 0 replies; 200+ results
From: Trahe, Fiona @ 2019-03-08 12:59 UTC (permalink / raw)
To: Ananyev, Konstantin, dev
Cc: akhil.goyal, umesh.kartha, De Lara Guarch, Pablo, shally.verma,
Ananyev, Konstantin, Trahe, Fiona
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Konstantin Ananyev
> Sent: Thursday, March 7, 2019 2:13 PM
> To: dev@dpdk.org
> Cc: akhil.goyal@nxp.com; umesh.kartha@caviumnetworks.com; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; shally.verma@caviumnetworks.com; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>
> Subject: [dpdk-dev] [PATCH] cryptodev: fix restore crypto op alignment and layout
>
> in 18.08 new cache-aligned structure rte_crypto_asym_op was introduced.
> As it also was included into rte_crypto_op, it caused implicit change
> in rte_crypto_op layout and alignment: now rte_crypto_op is cahce-line
> aligned has a hole of 40/104 bytes between phys_addr and sym/asym op.
> It looks like unintended ABI breakage, plus such change can cause
> negative performance effects:
> - now status and sym[0].m_src lies on different cache-lines, so
> post-process code would need extra cache-line read.
> - new alignment causes grow of the space requirements and cache-line
> reads/updates for structures that contain rte_crypto_op inside.
> As there seems no actual need to have rte_crypto_asym_op cache-line
> aligned, and rte_crypto_asym_op is not intended to be used on it's own -
> the simplest fix is just to remove cache-line alignment for it.
> As the immediate positive effect: on IA ipsec-secgw performance increased
> by 5-10% (depending on the crypto-dev and algo used).
> My guess that on machines with 128B cache-line and lookaside-protocol
> capable crypto devices the impact will be even more noticeable.
>
> Fixes: 26008aaed14c ("cryptodev: add asymmetric xform and op definitions")
>
> Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
Acked-by: Fiona Trahe <fiona.trahe@intel.com>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v4 1/6] vfio: allow DMA map of memory for the default vfio fd
@ 2019-03-10 8:27 5% ` Shahaf Shuler
2019-03-30 0:23 3% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Shahaf Shuler @ 2019-03-10 8:27 UTC (permalink / raw)
To: anatoly.burakov, yskoh, thomas, ferruh.yigit, nhorman, gaetan.rivet; +Cc: dev
Enable users the option to call rte_vfio_dma_map with request to map
to the default vfio fd.
Signed-off-by: Shahaf Shuler <shahafs@mellanox.com>
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
---
doc/guides/rel_notes/release_19_05.rst | 3 +++
lib/librte_eal/common/include/rte_vfio.h | 8 ++++++--
lib/librte_eal/linuxapp/eal/eal_vfio.c | 10 ++++++++--
3 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 61a2c73837..aa77b24bf5 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -136,6 +136,9 @@ ABI Changes
Also, make sure to start the actual text at the margin.
=========================================================
+* vfio: Functions ``rte_vfio_container_dma_map`` and
+ ``rte_vfio_container_dma_unmap`` have been extended with an option to
+ request mapping or un-mapping to the default vfio container fd.
Shared Library Versions
-----------------------
diff --git a/lib/librte_eal/common/include/rte_vfio.h b/lib/librte_eal/common/include/rte_vfio.h
index cae96fab90..cdfbedc1f9 100644
--- a/lib/librte_eal/common/include/rte_vfio.h
+++ b/lib/librte_eal/common/include/rte_vfio.h
@@ -80,6 +80,8 @@ struct vfio_device_info;
#endif /* VFIO_PRESENT */
+#define RTE_VFIO_DEFAULT_CONTAINER_FD (-1)
+
/**
* Setup vfio_cfg for the device identified by its address.
* It discovers the configured I/O MMU groups or sets a new one for the device.
@@ -347,7 +349,8 @@ rte_vfio_container_group_unbind(int container_fd, int iommu_group_num);
* Perform DMA mapping for devices in a container.
*
* @param container_fd
- * the specified container fd
+ * the specified container fd. Use RTE_VFIO_DEFAULT_CONTAINER_FD to
+ * use the default container.
*
* @param vaddr
* Starting virtual address of memory to be mapped.
@@ -370,7 +373,8 @@ rte_vfio_container_dma_map(int container_fd, uint64_t vaddr,
* Perform DMA unmapping for devices in a container.
*
* @param container_fd
- * the specified container fd
+ * the specified container fd. Use RTE_VFIO_DEFAULT_CONTAINER_FD to
+ * use the default container.
*
* @param vaddr
* Starting virtual address of memory to be unmapped.
diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.c b/lib/librte_eal/linuxapp/eal/eal_vfio.c
index c821e83826..9adbda8bb7 100644
--- a/lib/librte_eal/linuxapp/eal/eal_vfio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_vfio.c
@@ -1897,7 +1897,10 @@ rte_vfio_container_dma_map(int container_fd, uint64_t vaddr, uint64_t iova,
return -1;
}
- vfio_cfg = get_vfio_cfg_by_container_fd(container_fd);
+ if (container_fd == RTE_VFIO_DEFAULT_CONTAINER_FD)
+ vfio_cfg = default_vfio_cfg;
+ else
+ vfio_cfg = get_vfio_cfg_by_container_fd(container_fd);
if (vfio_cfg == NULL) {
RTE_LOG(ERR, EAL, "Invalid container fd\n");
return -1;
@@ -1917,7 +1920,10 @@ rte_vfio_container_dma_unmap(int container_fd, uint64_t vaddr, uint64_t iova,
return -1;
}
- vfio_cfg = get_vfio_cfg_by_container_fd(container_fd);
+ if (container_fd == RTE_VFIO_DEFAULT_CONTAINER_FD)
+ vfio_cfg = default_vfio_cfg;
+ else
+ vfio_cfg = get_vfio_cfg_by_container_fd(container_fd);
if (vfio_cfg == NULL) {
RTE_LOG(ERR, EAL, "Invalid container fd\n");
return -1;
--
2.12.0
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH] cryptodev: fix restore crypto op alignment and layout
2019-03-07 14:13 8% [dpdk-dev] [PATCH] cryptodev: fix restore crypto op alignment and layout Konstantin Ananyev
2019-03-08 12:59 0% ` Trahe, Fiona
@ 2019-03-12 12:04 0% ` Shally Verma
2019-03-19 13:33 3% ` Akhil Goyal
2 siblings, 0 replies; 200+ results
From: Shally Verma @ 2019-03-12 12:04 UTC (permalink / raw)
To: Konstantin Ananyev, dev
Cc: akhil.goyal, umesh.kartha, pablo.de.lara.guarch, shally.verma
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Konstantin Ananyev
> Sent: Thursday, March 7, 2019 7:43 PM
> To: dev@dpdk.org
> Cc: akhil.goyal@nxp.com; umesh.kartha@caviumnetworks.com;
> pablo.de.lara.guarch@intel.com; shally.verma@caviumnetworks.com;
> Konstantin Ananyev <konstantin.ananyev@intel.com>
> Subject: [dpdk-dev] [PATCH] cryptodev: fix restore crypto op alignment and
> layout
>
> in 18.08 new cache-aligned structure rte_crypto_asym_op was introduced.
> As it also was included into rte_crypto_op, it caused implicit change in
> rte_crypto_op layout and alignment: now rte_crypto_op is cahce-line aligned
> has a hole of 40/104 bytes between phys_addr and sym/asym op.
> It looks like unintended ABI breakage, plus such change can cause negative
> performance effects:
> - now status and sym[0].m_src lies on different cache-lines, so
> post-process code would need extra cache-line read.
> - new alignment causes grow of the space requirements and cache-line
> reads/updates for structures that contain rte_crypto_op inside.
> As there seems no actual need to have rte_crypto_asym_op cache-line
> aligned, and rte_crypto_asym_op is not intended to be used on it's own - the
> simplest fix is just to remove cache-line alignment for it.
> As the immediate positive effect: on IA ipsec-secgw performance increased
> by 5-10% (depending on the crypto-dev and algo used).
> My guess that on machines with 128B cache-line and lookaside-protocol
> capable crypto devices the impact will be even more noticeable.
>
> Fixes: 26008aaed14c ("cryptodev: add asymmetric xform and op definitions")
>
> Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> ---
It's a valid point that asym_op is not going to be used standalone. Thanks for pointing it out.
Acked-by: Shally Verma <shally.verma@marvell.com>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH 1/4] power: fix non thread-safe power env modification
@ 2019-03-13 19:48 4% ` Hajkowski
2019-03-13 19:48 4% ` Hajkowski
2019-03-13 19:48 4% ` [dpdk-dev] [PATCH 2/4] power: return error in set env when power env already set Hajkowski
1 sibling, 1 reply; 200+ results
From: Hajkowski @ 2019-03-13 19:48 UTC (permalink / raw)
To: david.hunt; +Cc: dev, Marcin Hajkowski, stable
From: Marcin Hajkowski <marcinx.hajkowski@intel.com>
Due to lack of thread safety in exisiting solution
use spinlock mechanism for atomic
modification of power environment related data.
Fixes: 445c6528b5 ("power: common interface for guest and host")
Cc: stable@dpdk.org
Signed-off-by: Marcin Hajkowski <marcinx.hajkowski@intel.com>
---
doc/guides/rel_notes/release_19_05.rst | 2 ++
lib/librte_power/rte_power.c | 30 ++++++++++++++++++--------
lib/librte_power/rte_power.h | 2 +-
3 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 61a2c7383..65371e4c8 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -120,6 +120,8 @@ API Changes
Also, make sure to start the actual text at the margin.
=========================================================
+ * power: ``rte_power_set_env`` and ``rte_power_unset_env`` functions
+ have been modified to be thread safe.
ABI Changes
-----------
diff --git a/lib/librte_power/rte_power.c b/lib/librte_power/rte_power.c
index a05fbef94..540d69be7 100644
--- a/lib/librte_power/rte_power.c
+++ b/lib/librte_power/rte_power.c
@@ -2,7 +2,7 @@
* Copyright(c) 2010-2014 Intel Corporation
*/
-#include <rte_atomic.h>
+#include <rte_spinlock.h>
#include "rte_power.h"
#include "power_acpi_cpufreq.h"
@@ -12,7 +12,7 @@
enum power_management_env global_default_env = PM_ENV_NOT_SET;
-volatile uint32_t global_env_cfg_status = 0;
+static rte_spinlock_t global_env_cfg_lock = RTE_SPINLOCK_INITIALIZER;
/* function pointers */
rte_power_freqs_t rte_power_freqs = NULL;
@@ -30,9 +30,15 @@ rte_power_get_capabilities_t rte_power_get_capabilities;
int
rte_power_set_env(enum power_management_env env)
{
- if (rte_atomic32_cmpset(&global_env_cfg_status, 0, 1) == 0) {
+ rte_spinlock_lock(&global_env_cfg_lock);
+
+ if (global_default_env != PM_ENV_NOT_SET) {
+ rte_spinlock_unlock(&global_env_cfg_lock);
return 0;
}
+
+ int ret = 0;
+
if (env == PM_ENV_ACPI_CPUFREQ) {
rte_power_freqs = power_acpi_cpufreq_freqs;
rte_power_get_freq = power_acpi_cpufreq_get_freq;
@@ -73,18 +79,24 @@ rte_power_set_env(enum power_management_env env)
} else {
RTE_LOG(ERR, POWER, "Invalid Power Management Environment(%d) set\n",
env);
- rte_power_unset_env();
- return -1;
+ ret = -1;
}
- global_default_env = env;
- return 0;
+
+ if (ret == 0)
+ global_default_env = env;
+ else
+ global_default_env = PM_ENV_NOT_SET;
+
+ rte_spinlock_unlock(&global_env_cfg_lock);
+ return ret;
}
void
rte_power_unset_env(void)
{
- if (rte_atomic32_cmpset(&global_env_cfg_status, 1, 0) != 0)
- global_default_env = PM_ENV_NOT_SET;
+ rte_spinlock_lock(&global_env_cfg_lock);
+ global_default_env = PM_ENV_NOT_SET;
+ rte_spinlock_unlock(&global_env_cfg_lock);
}
enum power_management_env
diff --git a/lib/librte_power/rte_power.h b/lib/librte_power/rte_power.h
index c5e8f6b5b..54b76b4ee 100644
--- a/lib/librte_power/rte_power.h
+++ b/lib/librte_power/rte_power.h
@@ -26,7 +26,7 @@ enum power_management_env {PM_ENV_NOT_SET, PM_ENV_ACPI_CPUFREQ, PM_ENV_KVM_VM,
/**
* Set the default power management implementation. If this is not called prior
* to rte_power_init(), then auto-detect of the environment will take place.
- * It is not thread safe.
+ * It is thread safe.
*
* @param env
* env. The environment in which to initialise Power Management for.
--
2.17.2
--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH 2/4] power: return error in set env when power env already set
2019-03-13 19:48 4% ` [dpdk-dev] [PATCH 1/4] power: fix non thread-safe power env modification Hajkowski
@ 2019-03-13 19:48 4% ` Hajkowski
2019-03-13 19:48 4% ` Hajkowski
1 sibling, 1 reply; 200+ results
From: Hajkowski @ 2019-03-13 19:48 UTC (permalink / raw)
To: david.hunt; +Cc: dev, Marcin Hajkowski
From: Marcin Hajkowski <marcinx.hajkowski@intel.com>
On attempt to set_env in already initialized state notify
user by returning error that operation cannot be performed.
Signed-off-by: Marcin Hajkowski <marcinx.hajkowski@intel.com>
---
doc/guides/rel_notes/release_19_05.rst | 4 ++++
lib/librte_power/rte_power.c | 3 ++-
lib/librte_power/rte_power.h | 3 ++-
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 65371e4c8..0da26b937 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -120,9 +120,13 @@ API Changes
Also, make sure to start the actual text at the margin.
=========================================================
+
* power: ``rte_power_set_env`` and ``rte_power_unset_env`` functions
have been modified to be thread safe.
+ * power: Function ``rte_power_set_env`` modified to return -1 if environment
+ has been already set.
+
ABI Changes
-----------
diff --git a/lib/librte_power/rte_power.c b/lib/librte_power/rte_power.c
index 540d69be7..ed701087d 100644
--- a/lib/librte_power/rte_power.c
+++ b/lib/librte_power/rte_power.c
@@ -33,8 +33,9 @@ rte_power_set_env(enum power_management_env env)
rte_spinlock_lock(&global_env_cfg_lock);
if (global_default_env != PM_ENV_NOT_SET) {
+ RTE_LOG(ERR, POWER, "Power Management Environment already set.\n");
rte_spinlock_unlock(&global_env_cfg_lock);
- return 0;
+ return -1;
}
int ret = 0;
diff --git a/lib/librte_power/rte_power.h b/lib/librte_power/rte_power.h
index 54b76b4ee..a3130e709 100644
--- a/lib/librte_power/rte_power.h
+++ b/lib/librte_power/rte_power.h
@@ -26,7 +26,8 @@ enum power_management_env {PM_ENV_NOT_SET, PM_ENV_ACPI_CPUFREQ, PM_ENV_KVM_VM,
/**
* Set the default power management implementation. If this is not called prior
* to rte_power_init(), then auto-detect of the environment will take place.
- * It is thread safe.
+ * It is thread safe. New env can be set only in unitialized state
+ * (thus rte_power_unset_env must be called if different env was already set).
*
* @param env
* env. The environment in which to initialise Power Management for.
--
2.17.2
--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH 1/4] power: fix non thread-safe power env modification
2019-03-13 19:48 4% ` [dpdk-dev] [PATCH 1/4] power: fix non thread-safe power env modification Hajkowski
@ 2019-03-13 19:48 4% ` Hajkowski
0 siblings, 0 replies; 200+ results
From: Hajkowski @ 2019-03-13 19:48 UTC (permalink / raw)
To: david.hunt; +Cc: dev, Marcin Hajkowski, stable
From: Marcin Hajkowski <marcinx.hajkowski@intel.com>
Due to lack of thread safety in exisiting solution
use spinlock mechanism for atomic
modification of power environment related data.
Fixes: 445c6528b5 ("power: common interface for guest and host")
Cc: stable@dpdk.org
Signed-off-by: Marcin Hajkowski <marcinx.hajkowski@intel.com>
---
doc/guides/rel_notes/release_19_05.rst | 2 ++
lib/librte_power/rte_power.c | 30 ++++++++++++++++++--------
lib/librte_power/rte_power.h | 2 +-
3 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 61a2c7383..65371e4c8 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -120,6 +120,8 @@ API Changes
Also, make sure to start the actual text at the margin.
=========================================================
+ * power: ``rte_power_set_env`` and ``rte_power_unset_env`` functions
+ have been modified to be thread safe.
ABI Changes
-----------
diff --git a/lib/librte_power/rte_power.c b/lib/librte_power/rte_power.c
index a05fbef94..540d69be7 100644
--- a/lib/librte_power/rte_power.c
+++ b/lib/librte_power/rte_power.c
@@ -2,7 +2,7 @@
* Copyright(c) 2010-2014 Intel Corporation
*/
-#include <rte_atomic.h>
+#include <rte_spinlock.h>
#include "rte_power.h"
#include "power_acpi_cpufreq.h"
@@ -12,7 +12,7 @@
enum power_management_env global_default_env = PM_ENV_NOT_SET;
-volatile uint32_t global_env_cfg_status = 0;
+static rte_spinlock_t global_env_cfg_lock = RTE_SPINLOCK_INITIALIZER;
/* function pointers */
rte_power_freqs_t rte_power_freqs = NULL;
@@ -30,9 +30,15 @@ rte_power_get_capabilities_t rte_power_get_capabilities;
int
rte_power_set_env(enum power_management_env env)
{
- if (rte_atomic32_cmpset(&global_env_cfg_status, 0, 1) == 0) {
+ rte_spinlock_lock(&global_env_cfg_lock);
+
+ if (global_default_env != PM_ENV_NOT_SET) {
+ rte_spinlock_unlock(&global_env_cfg_lock);
return 0;
}
+
+ int ret = 0;
+
if (env == PM_ENV_ACPI_CPUFREQ) {
rte_power_freqs = power_acpi_cpufreq_freqs;
rte_power_get_freq = power_acpi_cpufreq_get_freq;
@@ -73,18 +79,24 @@ rte_power_set_env(enum power_management_env env)
} else {
RTE_LOG(ERR, POWER, "Invalid Power Management Environment(%d) set\n",
env);
- rte_power_unset_env();
- return -1;
+ ret = -1;
}
- global_default_env = env;
- return 0;
+
+ if (ret == 0)
+ global_default_env = env;
+ else
+ global_default_env = PM_ENV_NOT_SET;
+
+ rte_spinlock_unlock(&global_env_cfg_lock);
+ return ret;
}
void
rte_power_unset_env(void)
{
- if (rte_atomic32_cmpset(&global_env_cfg_status, 1, 0) != 0)
- global_default_env = PM_ENV_NOT_SET;
+ rte_spinlock_lock(&global_env_cfg_lock);
+ global_default_env = PM_ENV_NOT_SET;
+ rte_spinlock_unlock(&global_env_cfg_lock);
}
enum power_management_env
diff --git a/lib/librte_power/rte_power.h b/lib/librte_power/rte_power.h
index c5e8f6b5b..54b76b4ee 100644
--- a/lib/librte_power/rte_power.h
+++ b/lib/librte_power/rte_power.h
@@ -26,7 +26,7 @@ enum power_management_env {PM_ENV_NOT_SET, PM_ENV_ACPI_CPUFREQ, PM_ENV_KVM_VM,
/**
* Set the default power management implementation. If this is not called prior
* to rte_power_init(), then auto-detect of the environment will take place.
- * It is not thread safe.
+ * It is thread safe.
*
* @param env
* env. The environment in which to initialise Power Management for.
--
2.17.2
--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH 2/4] power: return error in set env when power env already set
2019-03-13 19:48 4% ` [dpdk-dev] [PATCH 2/4] power: return error in set env when power env already set Hajkowski
@ 2019-03-13 19:48 4% ` Hajkowski
0 siblings, 0 replies; 200+ results
From: Hajkowski @ 2019-03-13 19:48 UTC (permalink / raw)
To: david.hunt; +Cc: dev, Marcin Hajkowski
From: Marcin Hajkowski <marcinx.hajkowski@intel.com>
On attempt to set_env in already initialized state notify
user by returning error that operation cannot be performed.
Signed-off-by: Marcin Hajkowski <marcinx.hajkowski@intel.com>
---
doc/guides/rel_notes/release_19_05.rst | 4 ++++
lib/librte_power/rte_power.c | 3 ++-
lib/librte_power/rte_power.h | 3 ++-
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 65371e4c8..0da26b937 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -120,9 +120,13 @@ API Changes
Also, make sure to start the actual text at the margin.
=========================================================
+
* power: ``rte_power_set_env`` and ``rte_power_unset_env`` functions
have been modified to be thread safe.
+ * power: Function ``rte_power_set_env`` modified to return -1 if environment
+ has been already set.
+
ABI Changes
-----------
diff --git a/lib/librte_power/rte_power.c b/lib/librte_power/rte_power.c
index 540d69be7..ed701087d 100644
--- a/lib/librte_power/rte_power.c
+++ b/lib/librte_power/rte_power.c
@@ -33,8 +33,9 @@ rte_power_set_env(enum power_management_env env)
rte_spinlock_lock(&global_env_cfg_lock);
if (global_default_env != PM_ENV_NOT_SET) {
+ RTE_LOG(ERR, POWER, "Power Management Environment already set.\n");
rte_spinlock_unlock(&global_env_cfg_lock);
- return 0;
+ return -1;
}
int ret = 0;
diff --git a/lib/librte_power/rte_power.h b/lib/librte_power/rte_power.h
index 54b76b4ee..a3130e709 100644
--- a/lib/librte_power/rte_power.h
+++ b/lib/librte_power/rte_power.h
@@ -26,7 +26,8 @@ enum power_management_env {PM_ENV_NOT_SET, PM_ENV_ACPI_CPUFREQ, PM_ENV_KVM_VM,
/**
* Set the default power management implementation. If this is not called prior
* to rte_power_init(), then auto-detect of the environment will take place.
- * It is thread safe.
+ * It is thread safe. New env can be set only in unitialized state
+ * (thus rte_power_unset_env must be called if different env was already set).
*
* @param env
* env. The environment in which to initialise Power Management for.
--
2.17.2
--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH 1/4] power: fix non thread-safe power env modification
@ 2019-03-15 9:34 4% ` Hajkowski
2019-03-15 9:34 4% ` Hajkowski
2019-03-15 9:34 4% ` [dpdk-dev] [PATCH 2/4] power: return error in set env when power env already set Hajkowski
1 sibling, 1 reply; 200+ results
From: Hajkowski @ 2019-03-15 9:34 UTC (permalink / raw)
To: david.hunt; +Cc: dev, Marcin Hajkowski, stable
From: Marcin Hajkowski <marcinx.hajkowski@intel.com>
Due to lack of thread safety in exisiting solution
use spinlock mechanism for atomic
modification of power environment related data.
Fixes: 445c6528b5 ("power: common interface for guest and host")
Cc: stable@dpdk.org
Signed-off-by: Marcin Hajkowski <marcinx.hajkowski@intel.com>
---
doc/guides/rel_notes/release_19_05.rst | 2 ++
lib/librte_power/rte_power.c | 30 ++++++++++++++++++--------
lib/librte_power/rte_power.h | 2 +-
3 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 61a2c7383..65371e4c8 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -120,6 +120,8 @@ API Changes
Also, make sure to start the actual text at the margin.
=========================================================
+ * power: ``rte_power_set_env`` and ``rte_power_unset_env`` functions
+ have been modified to be thread safe.
ABI Changes
-----------
diff --git a/lib/librte_power/rte_power.c b/lib/librte_power/rte_power.c
index a05fbef94..540d69be7 100644
--- a/lib/librte_power/rte_power.c
+++ b/lib/librte_power/rte_power.c
@@ -2,7 +2,7 @@
* Copyright(c) 2010-2014 Intel Corporation
*/
-#include <rte_atomic.h>
+#include <rte_spinlock.h>
#include "rte_power.h"
#include "power_acpi_cpufreq.h"
@@ -12,7 +12,7 @@
enum power_management_env global_default_env = PM_ENV_NOT_SET;
-volatile uint32_t global_env_cfg_status = 0;
+static rte_spinlock_t global_env_cfg_lock = RTE_SPINLOCK_INITIALIZER;
/* function pointers */
rte_power_freqs_t rte_power_freqs = NULL;
@@ -30,9 +30,15 @@ rte_power_get_capabilities_t rte_power_get_capabilities;
int
rte_power_set_env(enum power_management_env env)
{
- if (rte_atomic32_cmpset(&global_env_cfg_status, 0, 1) == 0) {
+ rte_spinlock_lock(&global_env_cfg_lock);
+
+ if (global_default_env != PM_ENV_NOT_SET) {
+ rte_spinlock_unlock(&global_env_cfg_lock);
return 0;
}
+
+ int ret = 0;
+
if (env == PM_ENV_ACPI_CPUFREQ) {
rte_power_freqs = power_acpi_cpufreq_freqs;
rte_power_get_freq = power_acpi_cpufreq_get_freq;
@@ -73,18 +79,24 @@ rte_power_set_env(enum power_management_env env)
} else {
RTE_LOG(ERR, POWER, "Invalid Power Management Environment(%d) set\n",
env);
- rte_power_unset_env();
- return -1;
+ ret = -1;
}
- global_default_env = env;
- return 0;
+
+ if (ret == 0)
+ global_default_env = env;
+ else
+ global_default_env = PM_ENV_NOT_SET;
+
+ rte_spinlock_unlock(&global_env_cfg_lock);
+ return ret;
}
void
rte_power_unset_env(void)
{
- if (rte_atomic32_cmpset(&global_env_cfg_status, 1, 0) != 0)
- global_default_env = PM_ENV_NOT_SET;
+ rte_spinlock_lock(&global_env_cfg_lock);
+ global_default_env = PM_ENV_NOT_SET;
+ rte_spinlock_unlock(&global_env_cfg_lock);
}
enum power_management_env
diff --git a/lib/librte_power/rte_power.h b/lib/librte_power/rte_power.h
index c5e8f6b5b..54b76b4ee 100644
--- a/lib/librte_power/rte_power.h
+++ b/lib/librte_power/rte_power.h
@@ -26,7 +26,7 @@ enum power_management_env {PM_ENV_NOT_SET, PM_ENV_ACPI_CPUFREQ, PM_ENV_KVM_VM,
/**
* Set the default power management implementation. If this is not called prior
* to rte_power_init(), then auto-detect of the environment will take place.
- * It is not thread safe.
+ * It is thread safe.
*
* @param env
* env. The environment in which to initialise Power Management for.
--
2.17.2
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH 2/4] power: return error in set env when power env already set
2019-03-15 9:34 4% ` [dpdk-dev] [PATCH 1/4] power: fix non thread-safe power env modification Hajkowski
@ 2019-03-15 9:34 4% ` Hajkowski
2019-03-15 9:34 4% ` Hajkowski
1 sibling, 1 reply; 200+ results
From: Hajkowski @ 2019-03-15 9:34 UTC (permalink / raw)
To: david.hunt; +Cc: dev, Marcin Hajkowski
From: Marcin Hajkowski <marcinx.hajkowski@intel.com>
On attempt to set_env in already initialized state notify
user by returning error that operation cannot be performed.
Signed-off-by: Marcin Hajkowski <marcinx.hajkowski@intel.com>
---
doc/guides/rel_notes/release_19_05.rst | 4 ++++
lib/librte_power/rte_power.c | 3 ++-
lib/librte_power/rte_power.h | 3 ++-
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 65371e4c8..0da26b937 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -120,9 +120,13 @@ API Changes
Also, make sure to start the actual text at the margin.
=========================================================
+
* power: ``rte_power_set_env`` and ``rte_power_unset_env`` functions
have been modified to be thread safe.
+ * power: Function ``rte_power_set_env`` modified to return -1 if environment
+ has been already set.
+
ABI Changes
-----------
diff --git a/lib/librte_power/rte_power.c b/lib/librte_power/rte_power.c
index 540d69be7..ed701087d 100644
--- a/lib/librte_power/rte_power.c
+++ b/lib/librte_power/rte_power.c
@@ -33,8 +33,9 @@ rte_power_set_env(enum power_management_env env)
rte_spinlock_lock(&global_env_cfg_lock);
if (global_default_env != PM_ENV_NOT_SET) {
+ RTE_LOG(ERR, POWER, "Power Management Environment already set.\n");
rte_spinlock_unlock(&global_env_cfg_lock);
- return 0;
+ return -1;
}
int ret = 0;
diff --git a/lib/librte_power/rte_power.h b/lib/librte_power/rte_power.h
index 54b76b4ee..a3130e709 100644
--- a/lib/librte_power/rte_power.h
+++ b/lib/librte_power/rte_power.h
@@ -26,7 +26,8 @@ enum power_management_env {PM_ENV_NOT_SET, PM_ENV_ACPI_CPUFREQ, PM_ENV_KVM_VM,
/**
* Set the default power management implementation. If this is not called prior
* to rte_power_init(), then auto-detect of the environment will take place.
- * It is thread safe.
+ * It is thread safe. New env can be set only in unitialized state
+ * (thus rte_power_unset_env must be called if different env was already set).
*
* @param env
* env. The environment in which to initialise Power Management for.
--
2.17.2
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH 1/4] power: fix non thread-safe power env modification
2019-03-15 9:34 4% ` [dpdk-dev] [PATCH 1/4] power: fix non thread-safe power env modification Hajkowski
@ 2019-03-15 9:34 4% ` Hajkowski
0 siblings, 0 replies; 200+ results
From: Hajkowski @ 2019-03-15 9:34 UTC (permalink / raw)
To: david.hunt; +Cc: dev, Marcin Hajkowski, stable
From: Marcin Hajkowski <marcinx.hajkowski@intel.com>
Due to lack of thread safety in exisiting solution
use spinlock mechanism for atomic
modification of power environment related data.
Fixes: 445c6528b5 ("power: common interface for guest and host")
Cc: stable@dpdk.org
Signed-off-by: Marcin Hajkowski <marcinx.hajkowski@intel.com>
---
doc/guides/rel_notes/release_19_05.rst | 2 ++
lib/librte_power/rte_power.c | 30 ++++++++++++++++++--------
lib/librte_power/rte_power.h | 2 +-
3 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 61a2c7383..65371e4c8 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -120,6 +120,8 @@ API Changes
Also, make sure to start the actual text at the margin.
=========================================================
+ * power: ``rte_power_set_env`` and ``rte_power_unset_env`` functions
+ have been modified to be thread safe.
ABI Changes
-----------
diff --git a/lib/librte_power/rte_power.c b/lib/librte_power/rte_power.c
index a05fbef94..540d69be7 100644
--- a/lib/librte_power/rte_power.c
+++ b/lib/librte_power/rte_power.c
@@ -2,7 +2,7 @@
* Copyright(c) 2010-2014 Intel Corporation
*/
-#include <rte_atomic.h>
+#include <rte_spinlock.h>
#include "rte_power.h"
#include "power_acpi_cpufreq.h"
@@ -12,7 +12,7 @@
enum power_management_env global_default_env = PM_ENV_NOT_SET;
-volatile uint32_t global_env_cfg_status = 0;
+static rte_spinlock_t global_env_cfg_lock = RTE_SPINLOCK_INITIALIZER;
/* function pointers */
rte_power_freqs_t rte_power_freqs = NULL;
@@ -30,9 +30,15 @@ rte_power_get_capabilities_t rte_power_get_capabilities;
int
rte_power_set_env(enum power_management_env env)
{
- if (rte_atomic32_cmpset(&global_env_cfg_status, 0, 1) == 0) {
+ rte_spinlock_lock(&global_env_cfg_lock);
+
+ if (global_default_env != PM_ENV_NOT_SET) {
+ rte_spinlock_unlock(&global_env_cfg_lock);
return 0;
}
+
+ int ret = 0;
+
if (env == PM_ENV_ACPI_CPUFREQ) {
rte_power_freqs = power_acpi_cpufreq_freqs;
rte_power_get_freq = power_acpi_cpufreq_get_freq;
@@ -73,18 +79,24 @@ rte_power_set_env(enum power_management_env env)
} else {
RTE_LOG(ERR, POWER, "Invalid Power Management Environment(%d) set\n",
env);
- rte_power_unset_env();
- return -1;
+ ret = -1;
}
- global_default_env = env;
- return 0;
+
+ if (ret == 0)
+ global_default_env = env;
+ else
+ global_default_env = PM_ENV_NOT_SET;
+
+ rte_spinlock_unlock(&global_env_cfg_lock);
+ return ret;
}
void
rte_power_unset_env(void)
{
- if (rte_atomic32_cmpset(&global_env_cfg_status, 1, 0) != 0)
- global_default_env = PM_ENV_NOT_SET;
+ rte_spinlock_lock(&global_env_cfg_lock);
+ global_default_env = PM_ENV_NOT_SET;
+ rte_spinlock_unlock(&global_env_cfg_lock);
}
enum power_management_env
diff --git a/lib/librte_power/rte_power.h b/lib/librte_power/rte_power.h
index c5e8f6b5b..54b76b4ee 100644
--- a/lib/librte_power/rte_power.h
+++ b/lib/librte_power/rte_power.h
@@ -26,7 +26,7 @@ enum power_management_env {PM_ENV_NOT_SET, PM_ENV_ACPI_CPUFREQ, PM_ENV_KVM_VM,
/**
* Set the default power management implementation. If this is not called prior
* to rte_power_init(), then auto-detect of the environment will take place.
- * It is not thread safe.
+ * It is thread safe.
*
* @param env
* env. The environment in which to initialise Power Management for.
--
2.17.2
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH 2/4] power: return error in set env when power env already set
2019-03-15 9:34 4% ` [dpdk-dev] [PATCH 2/4] power: return error in set env when power env already set Hajkowski
@ 2019-03-15 9:34 4% ` Hajkowski
0 siblings, 0 replies; 200+ results
From: Hajkowski @ 2019-03-15 9:34 UTC (permalink / raw)
To: david.hunt; +Cc: dev, Marcin Hajkowski
From: Marcin Hajkowski <marcinx.hajkowski@intel.com>
On attempt to set_env in already initialized state notify
user by returning error that operation cannot be performed.
Signed-off-by: Marcin Hajkowski <marcinx.hajkowski@intel.com>
---
doc/guides/rel_notes/release_19_05.rst | 4 ++++
lib/librte_power/rte_power.c | 3 ++-
lib/librte_power/rte_power.h | 3 ++-
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 65371e4c8..0da26b937 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -120,9 +120,13 @@ API Changes
Also, make sure to start the actual text at the margin.
=========================================================
+
* power: ``rte_power_set_env`` and ``rte_power_unset_env`` functions
have been modified to be thread safe.
+ * power: Function ``rte_power_set_env`` modified to return -1 if environment
+ has been already set.
+
ABI Changes
-----------
diff --git a/lib/librte_power/rte_power.c b/lib/librte_power/rte_power.c
index 540d69be7..ed701087d 100644
--- a/lib/librte_power/rte_power.c
+++ b/lib/librte_power/rte_power.c
@@ -33,8 +33,9 @@ rte_power_set_env(enum power_management_env env)
rte_spinlock_lock(&global_env_cfg_lock);
if (global_default_env != PM_ENV_NOT_SET) {
+ RTE_LOG(ERR, POWER, "Power Management Environment already set.\n");
rte_spinlock_unlock(&global_env_cfg_lock);
- return 0;
+ return -1;
}
int ret = 0;
diff --git a/lib/librte_power/rte_power.h b/lib/librte_power/rte_power.h
index 54b76b4ee..a3130e709 100644
--- a/lib/librte_power/rte_power.h
+++ b/lib/librte_power/rte_power.h
@@ -26,7 +26,8 @@ enum power_management_env {PM_ENV_NOT_SET, PM_ENV_ACPI_CPUFREQ, PM_ENV_KVM_VM,
/**
* Set the default power management implementation. If this is not called prior
* to rte_power_init(), then auto-detect of the environment will take place.
- * It is thread safe.
+ * It is thread safe. New env can be set only in unitialized state
+ * (thus rte_power_unset_env must be called if different env was already set).
*
* @param env
* env. The environment in which to initialise Power Management for.
--
2.17.2
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v2 1/4] power: fix non thread-safe power env modification
@ 2019-03-18 11:56 4% Hajkowski
2019-03-18 11:56 4% ` Hajkowski
2019-03-18 11:56 4% ` [dpdk-dev] [PATCH v2 2/4] power: return error in set env when power env already set Hajkowski
0 siblings, 2 replies; 200+ results
From: Hajkowski @ 2019-03-18 11:56 UTC (permalink / raw)
To: david.hunt; +Cc: dev, Marcin Hajkowski, stable
From: Marcin Hajkowski <marcinx.hajkowski@intel.com>
Due to lack of thread safety in exisiting solution
use spinlock mechanism for atomic
modification of power environment related data.
Fixes: 445c6528b5 ("power: common interface for guest and host")
Cc: stable@dpdk.org
Signed-off-by: Marcin Hajkowski <marcinx.hajkowski@intel.com>
---
doc/guides/rel_notes/release_19_05.rst | 2 ++
lib/librte_power/rte_power.c | 30 ++++++++++++++++++--------
lib/librte_power/rte_power.h | 2 +-
3 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 61a2c7383..65371e4c8 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -120,6 +120,8 @@ API Changes
Also, make sure to start the actual text at the margin.
=========================================================
+ * power: ``rte_power_set_env`` and ``rte_power_unset_env`` functions
+ have been modified to be thread safe.
ABI Changes
-----------
diff --git a/lib/librte_power/rte_power.c b/lib/librte_power/rte_power.c
index a05fbef94..540d69be7 100644
--- a/lib/librte_power/rte_power.c
+++ b/lib/librte_power/rte_power.c
@@ -2,7 +2,7 @@
* Copyright(c) 2010-2014 Intel Corporation
*/
-#include <rte_atomic.h>
+#include <rte_spinlock.h>
#include "rte_power.h"
#include "power_acpi_cpufreq.h"
@@ -12,7 +12,7 @@
enum power_management_env global_default_env = PM_ENV_NOT_SET;
-volatile uint32_t global_env_cfg_status = 0;
+static rte_spinlock_t global_env_cfg_lock = RTE_SPINLOCK_INITIALIZER;
/* function pointers */
rte_power_freqs_t rte_power_freqs = NULL;
@@ -30,9 +30,15 @@ rte_power_get_capabilities_t rte_power_get_capabilities;
int
rte_power_set_env(enum power_management_env env)
{
- if (rte_atomic32_cmpset(&global_env_cfg_status, 0, 1) == 0) {
+ rte_spinlock_lock(&global_env_cfg_lock);
+
+ if (global_default_env != PM_ENV_NOT_SET) {
+ rte_spinlock_unlock(&global_env_cfg_lock);
return 0;
}
+
+ int ret = 0;
+
if (env == PM_ENV_ACPI_CPUFREQ) {
rte_power_freqs = power_acpi_cpufreq_freqs;
rte_power_get_freq = power_acpi_cpufreq_get_freq;
@@ -73,18 +79,24 @@ rte_power_set_env(enum power_management_env env)
} else {
RTE_LOG(ERR, POWER, "Invalid Power Management Environment(%d) set\n",
env);
- rte_power_unset_env();
- return -1;
+ ret = -1;
}
- global_default_env = env;
- return 0;
+
+ if (ret == 0)
+ global_default_env = env;
+ else
+ global_default_env = PM_ENV_NOT_SET;
+
+ rte_spinlock_unlock(&global_env_cfg_lock);
+ return ret;
}
void
rte_power_unset_env(void)
{
- if (rte_atomic32_cmpset(&global_env_cfg_status, 1, 0) != 0)
- global_default_env = PM_ENV_NOT_SET;
+ rte_spinlock_lock(&global_env_cfg_lock);
+ global_default_env = PM_ENV_NOT_SET;
+ rte_spinlock_unlock(&global_env_cfg_lock);
}
enum power_management_env
diff --git a/lib/librte_power/rte_power.h b/lib/librte_power/rte_power.h
index c5e8f6b5b..54b76b4ee 100644
--- a/lib/librte_power/rte_power.h
+++ b/lib/librte_power/rte_power.h
@@ -26,7 +26,7 @@ enum power_management_env {PM_ENV_NOT_SET, PM_ENV_ACPI_CPUFREQ, PM_ENV_KVM_VM,
/**
* Set the default power management implementation. If this is not called prior
* to rte_power_init(), then auto-detect of the environment will take place.
- * It is not thread safe.
+ * It is thread safe.
*
* @param env
* env. The environment in which to initialise Power Management for.
--
2.17.2
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v2 2/4] power: return error in set env when power env already set
2019-03-18 11:56 4% [dpdk-dev] [PATCH v2 1/4] power: fix non thread-safe power env modification Hajkowski
2019-03-18 11:56 4% ` Hajkowski
@ 2019-03-18 11:56 4% ` Hajkowski
2019-03-18 11:56 4% ` Hajkowski
1 sibling, 1 reply; 200+ results
From: Hajkowski @ 2019-03-18 11:56 UTC (permalink / raw)
To: david.hunt; +Cc: dev, Marcin Hajkowski
From: Marcin Hajkowski <marcinx.hajkowski@intel.com>
On attempt to set_env in already initialized state notify
user by returning error that operation cannot be performed.
Signed-off-by: Marcin Hajkowski <marcinx.hajkowski@intel.com>
---
doc/guides/rel_notes/release_19_05.rst | 4 ++++
lib/librte_power/rte_power.c | 3 ++-
lib/librte_power/rte_power.h | 3 ++-
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 65371e4c8..0da26b937 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -120,9 +120,13 @@ API Changes
Also, make sure to start the actual text at the margin.
=========================================================
+
* power: ``rte_power_set_env`` and ``rte_power_unset_env`` functions
have been modified to be thread safe.
+ * power: Function ``rte_power_set_env`` modified to return -1 if environment
+ has been already set.
+
ABI Changes
-----------
diff --git a/lib/librte_power/rte_power.c b/lib/librte_power/rte_power.c
index 540d69be7..ed701087d 100644
--- a/lib/librte_power/rte_power.c
+++ b/lib/librte_power/rte_power.c
@@ -33,8 +33,9 @@ rte_power_set_env(enum power_management_env env)
rte_spinlock_lock(&global_env_cfg_lock);
if (global_default_env != PM_ENV_NOT_SET) {
+ RTE_LOG(ERR, POWER, "Power Management Environment already set.\n");
rte_spinlock_unlock(&global_env_cfg_lock);
- return 0;
+ return -1;
}
int ret = 0;
diff --git a/lib/librte_power/rte_power.h b/lib/librte_power/rte_power.h
index 54b76b4ee..a3130e709 100644
--- a/lib/librte_power/rte_power.h
+++ b/lib/librte_power/rte_power.h
@@ -26,7 +26,8 @@ enum power_management_env {PM_ENV_NOT_SET, PM_ENV_ACPI_CPUFREQ, PM_ENV_KVM_VM,
/**
* Set the default power management implementation. If this is not called prior
* to rte_power_init(), then auto-detect of the environment will take place.
- * It is thread safe.
+ * It is thread safe. New env can be set only in unitialized state
+ * (thus rte_power_unset_env must be called if different env was already set).
*
* @param env
* env. The environment in which to initialise Power Management for.
--
2.17.2
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v2 1/4] power: fix non thread-safe power env modification
2019-03-18 11:56 4% [dpdk-dev] [PATCH v2 1/4] power: fix non thread-safe power env modification Hajkowski
@ 2019-03-18 11:56 4% ` Hajkowski
2019-03-18 11:56 4% ` [dpdk-dev] [PATCH v2 2/4] power: return error in set env when power env already set Hajkowski
1 sibling, 0 replies; 200+ results
From: Hajkowski @ 2019-03-18 11:56 UTC (permalink / raw)
To: david.hunt; +Cc: dev, Marcin Hajkowski, stable
From: Marcin Hajkowski <marcinx.hajkowski@intel.com>
Due to lack of thread safety in exisiting solution
use spinlock mechanism for atomic
modification of power environment related data.
Fixes: 445c6528b5 ("power: common interface for guest and host")
Cc: stable@dpdk.org
Signed-off-by: Marcin Hajkowski <marcinx.hajkowski@intel.com>
---
doc/guides/rel_notes/release_19_05.rst | 2 ++
lib/librte_power/rte_power.c | 30 ++++++++++++++++++--------
lib/librte_power/rte_power.h | 2 +-
3 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 61a2c7383..65371e4c8 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -120,6 +120,8 @@ API Changes
Also, make sure to start the actual text at the margin.
=========================================================
+ * power: ``rte_power_set_env`` and ``rte_power_unset_env`` functions
+ have been modified to be thread safe.
ABI Changes
-----------
diff --git a/lib/librte_power/rte_power.c b/lib/librte_power/rte_power.c
index a05fbef94..540d69be7 100644
--- a/lib/librte_power/rte_power.c
+++ b/lib/librte_power/rte_power.c
@@ -2,7 +2,7 @@
* Copyright(c) 2010-2014 Intel Corporation
*/
-#include <rte_atomic.h>
+#include <rte_spinlock.h>
#include "rte_power.h"
#include "power_acpi_cpufreq.h"
@@ -12,7 +12,7 @@
enum power_management_env global_default_env = PM_ENV_NOT_SET;
-volatile uint32_t global_env_cfg_status = 0;
+static rte_spinlock_t global_env_cfg_lock = RTE_SPINLOCK_INITIALIZER;
/* function pointers */
rte_power_freqs_t rte_power_freqs = NULL;
@@ -30,9 +30,15 @@ rte_power_get_capabilities_t rte_power_get_capabilities;
int
rte_power_set_env(enum power_management_env env)
{
- if (rte_atomic32_cmpset(&global_env_cfg_status, 0, 1) == 0) {
+ rte_spinlock_lock(&global_env_cfg_lock);
+
+ if (global_default_env != PM_ENV_NOT_SET) {
+ rte_spinlock_unlock(&global_env_cfg_lock);
return 0;
}
+
+ int ret = 0;
+
if (env == PM_ENV_ACPI_CPUFREQ) {
rte_power_freqs = power_acpi_cpufreq_freqs;
rte_power_get_freq = power_acpi_cpufreq_get_freq;
@@ -73,18 +79,24 @@ rte_power_set_env(enum power_management_env env)
} else {
RTE_LOG(ERR, POWER, "Invalid Power Management Environment(%d) set\n",
env);
- rte_power_unset_env();
- return -1;
+ ret = -1;
}
- global_default_env = env;
- return 0;
+
+ if (ret == 0)
+ global_default_env = env;
+ else
+ global_default_env = PM_ENV_NOT_SET;
+
+ rte_spinlock_unlock(&global_env_cfg_lock);
+ return ret;
}
void
rte_power_unset_env(void)
{
- if (rte_atomic32_cmpset(&global_env_cfg_status, 1, 0) != 0)
- global_default_env = PM_ENV_NOT_SET;
+ rte_spinlock_lock(&global_env_cfg_lock);
+ global_default_env = PM_ENV_NOT_SET;
+ rte_spinlock_unlock(&global_env_cfg_lock);
}
enum power_management_env
diff --git a/lib/librte_power/rte_power.h b/lib/librte_power/rte_power.h
index c5e8f6b5b..54b76b4ee 100644
--- a/lib/librte_power/rte_power.h
+++ b/lib/librte_power/rte_power.h
@@ -26,7 +26,7 @@ enum power_management_env {PM_ENV_NOT_SET, PM_ENV_ACPI_CPUFREQ, PM_ENV_KVM_VM,
/**
* Set the default power management implementation. If this is not called prior
* to rte_power_init(), then auto-detect of the environment will take place.
- * It is not thread safe.
+ * It is thread safe.
*
* @param env
* env. The environment in which to initialise Power Management for.
--
2.17.2
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v2 2/4] power: return error in set env when power env already set
2019-03-18 11:56 4% ` [dpdk-dev] [PATCH v2 2/4] power: return error in set env when power env already set Hajkowski
@ 2019-03-18 11:56 4% ` Hajkowski
0 siblings, 0 replies; 200+ results
From: Hajkowski @ 2019-03-18 11:56 UTC (permalink / raw)
To: david.hunt; +Cc: dev, Marcin Hajkowski
From: Marcin Hajkowski <marcinx.hajkowski@intel.com>
On attempt to set_env in already initialized state notify
user by returning error that operation cannot be performed.
Signed-off-by: Marcin Hajkowski <marcinx.hajkowski@intel.com>
---
doc/guides/rel_notes/release_19_05.rst | 4 ++++
lib/librte_power/rte_power.c | 3 ++-
lib/librte_power/rte_power.h | 3 ++-
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 65371e4c8..0da26b937 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -120,9 +120,13 @@ API Changes
Also, make sure to start the actual text at the margin.
=========================================================
+
* power: ``rte_power_set_env`` and ``rte_power_unset_env`` functions
have been modified to be thread safe.
+ * power: Function ``rte_power_set_env`` modified to return -1 if environment
+ has been already set.
+
ABI Changes
-----------
diff --git a/lib/librte_power/rte_power.c b/lib/librte_power/rte_power.c
index 540d69be7..ed701087d 100644
--- a/lib/librte_power/rte_power.c
+++ b/lib/librte_power/rte_power.c
@@ -33,8 +33,9 @@ rte_power_set_env(enum power_management_env env)
rte_spinlock_lock(&global_env_cfg_lock);
if (global_default_env != PM_ENV_NOT_SET) {
+ RTE_LOG(ERR, POWER, "Power Management Environment already set.\n");
rte_spinlock_unlock(&global_env_cfg_lock);
- return 0;
+ return -1;
}
int ret = 0;
diff --git a/lib/librte_power/rte_power.h b/lib/librte_power/rte_power.h
index 54b76b4ee..a3130e709 100644
--- a/lib/librte_power/rte_power.h
+++ b/lib/librte_power/rte_power.h
@@ -26,7 +26,8 @@ enum power_management_env {PM_ENV_NOT_SET, PM_ENV_ACPI_CPUFREQ, PM_ENV_KVM_VM,
/**
* Set the default power management implementation. If this is not called prior
* to rte_power_init(), then auto-detect of the environment will take place.
- * It is thread safe.
+ * It is thread safe. New env can be set only in unitialized state
+ * (thus rte_power_unset_env must be called if different env was already set).
*
* @param env
* env. The environment in which to initialise Power Management for.
--
2.17.2
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v7 0/6] Add lock-free ring and mempool handler
2019-03-06 15:03 2% ` [dpdk-dev] [PATCH v6 0/6] Add lock-free ring and mempool handler Gage Eads
2019-03-06 15:03 2% ` [dpdk-dev] [PATCH v6 1/6] ring: add a pointer-width headtail structure Gage Eads
@ 2019-03-18 21:35 2% ` Gage Eads
2019-03-18 21:35 2% ` Gage Eads
` (3 more replies)
1 sibling, 4 replies; 200+ results
From: Gage Eads @ 2019-03-18 21:35 UTC (permalink / raw)
To: dev
Cc: olivier.matz, arybchenko, bruce.richardson, konstantin.ananyev,
stephen, jerinj, mczekaj, nd, Ola.Liljedahl, gage.eads
For some users, the rte ring's "non-preemptive" constraint is not acceptable;
for example, if the application uses a mixture of pinned high-priority threads
and multiplexed low-priority threads that share a mempool.
This patchset introduces a lock-free ring and a mempool based on it. The
lock-free algorithm relies on a double-pointer compare-and-swap, so for 64-bit
architectures it is currently limited to x86_64.
The ring uses more compare-and-swap atomic operations than the regular rte ring:
With no contention, an enqueue of n pointers uses (1 + n) CAS operations and a
dequeue of n pointers uses 1. This algorithm has worse average-case performance
than the regular rte ring (particularly a highly-contended ring with large bulk
accesses), however:
- For applications with preemptible pthreads, the regular rte ring's worst-case
performance (i.e. one thread being preempted in the update_tail() critical
section) is much worse than the lock-free ring's.
- Software caching can mitigate the average case performance for ring-based
algorithms. For example, a lock-free ring based mempool (a likely use case
for this ring) with per-thread caching.
The lock-free ring is enabled via a new flag, RING_F_LF. For ease-of-use,
existing ring enqueue/dequeue functions work with both standard and lock-free
rings. This is also an experimental API, so RING_F_LF users must build with the
ALLOW_EXPERIMENTAL_API flag.
This patchset also adds lock-free versions of ring_autotest and
ring_perf_autotest, and a lock-free ring based mempool.
This patchset makes one API change; a deprecation notice was posted in a
separate commit[1].
This patchset depends on the 128-bit compare-and-set patch[2].
[1] http://mails.dpdk.org/archives/dev/2019-February/124321.html
[2] http://mails.dpdk.org/archives/dev/2019-March/125751.html
v7:
- Added ARM copyright to rte_ring_generic.h and rte_ring_c11_mem.h, since the
lock-free algorithm is based on ARM's lfring (see v5 notes)
- Rename __rte_ring_reload_tail() -> __rte_ring_lf_load_tail()
- Remove the unused return value from __rte_ring_lf_load_tail()
- Rename 'prev_tail' to 'next_tail' in the multi-producer lock-free enqueue
v6:
- Rebase patchset onto master (test/test/ -> app/test/)
v5:
- Incorporated lfring's enqueue and dequeue logic from
http://mails.dpdk.org/archives/dev/2019-January/124242.html
- Renamed non-blocking -> lock-free and NB -> LF to align with a similar
change in the lock-free stack patchset:
http://mails.dpdk.org/archives/dev/2019-March/125797.html
- Added support for 32-bit architectures by using the full 32b of the
modification counter and requiring LF rings on these architectures to be at
least 1024 entries.
- Updated to the latest rte_atomic128_cmp_exchange() interface.
- Added ring start marker to struct rte_ring
v4:
- Split out nb_enqueue and nb_dequeue functions in generic and C11 versions,
with the necessary memory ordering behavior for weakly consistent machines.
- Convert size_t variables (from v2) to uint64_t and no-longer-applicable
comment about variably-sized ring indexes.
- Fix bug in nb_enqueue_mp that the breaks the non-blocking guarantee.
- Split the ring_ptr cast into two lines.
- Change the dependent patchset from the non-blocking stack patch series
to one only containing the 128b CAS commit
v3:
- Avoid the ABI break by putting 64-bit head and tail values in the same
cacheline as struct rte_ring's prod and cons members.
- Don't attempt to compile rte_atomic128_cmpset without
ALLOW_EXPERIMENTAL_API, as this would break a large number of libraries.
- Add a helpful warning to __rte_ring_do_nb_enqueue_mp() in case someone tries
to use RING_F_NB without the ALLOW_EXPERIMENTAL_API flag.
- Update the ring mempool to use experimental APIs
- Clarify that RINB_F_NB is only limited to x86_64 currently; e.g. ARMv8 has the
ISA support for 128-bit CAS to eventually support it.
v2:
- Merge separate docs commit into patch #5
- Convert uintptr_t to size_t
- Add a compile-time check for the size of size_t
- Fix a space-after-typecast issue
- Fix an unnecessary-parentheses checkpatch warning
- Bump librte_ring's library version
Gage Eads (6):
ring: add a pointer-width headtail structure
ring: add a ring start marker
ring: add a lock-free implementation
test_ring: add lock-free ring autotest
test_ring_perf: add lock-free ring perf test
mempool/ring: add lock-free ring handlers
app/test/test_ring.c | 61 +--
app/test/test_ring_perf.c | 19 +-
doc/guides/prog_guide/env_abstraction_layer.rst | 10 +
drivers/mempool/ring/Makefile | 1 +
drivers/mempool/ring/meson.build | 2 +
drivers/mempool/ring/rte_mempool_ring.c | 58 ++-
lib/librte_ring/rte_ring.c | 92 ++++-
lib/librte_ring/rte_ring.h | 334 ++++++++++++++--
lib/librte_ring/rte_ring_c11_mem.h | 501 ++++++++++++++++++++++++
lib/librte_ring/rte_ring_generic.h | 485 ++++++++++++++++++++++-
lib/librte_ring/rte_ring_version.map | 7 +
11 files changed, 1492 insertions(+), 78 deletions(-)
--
2.13.6
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v7 1/6] ring: add a pointer-width headtail structure
2019-03-18 21:35 2% ` [dpdk-dev] [PATCH v7 0/6] Add lock-free ring and mempool handler Gage Eads
2019-03-18 21:35 2% ` Gage Eads
@ 2019-03-18 21:35 2% ` Gage Eads
2019-03-18 21:35 2% ` Gage Eads
2019-03-19 1:20 2% ` [dpdk-dev] [PATCH v8 " Gage Eads
3 siblings, 1 reply; 200+ results
From: Gage Eads @ 2019-03-18 21:35 UTC (permalink / raw)
To: dev
Cc: olivier.matz, arybchenko, bruce.richardson, konstantin.ananyev,
stephen, jerinj, mczekaj, nd, Ola.Liljedahl, gage.eads
For 64-bit systems, at current CPU speeds, 64-bit head and tail indexes
will not wrap-around within the author's lifetime. This is important to
avoiding the ABA problem -- in which a thread mistakes reading the same
tail index in two accesses to mean that the ring was not modified in the
intervening time -- in the upcoming lock-free ring implementation. Using a
64-bit index makes the possibility of this occurring effectively zero. This
commit uses pointer-width indexes so the lock-free ring can support 32-bit
systems as well.
This commit places the new producer and consumer structures in the same
location in struct rte_ring as their 32-bit counterparts. Since the 32-bit
versions are padded out to a cache line, there is space for the new
structure without affecting the layout of struct rte_ring. Thus, the ABI is
preserved.
Signed-off-by: Gage Eads <gage.eads@intel.com>
---
lib/librte_ring/rte_ring.h | 21 +++++-
lib/librte_ring/rte_ring_c11_mem.h | 143 +++++++++++++++++++++++++++++++++++++
lib/librte_ring/rte_ring_generic.h | 130 +++++++++++++++++++++++++++++++++
3 files changed, 291 insertions(+), 3 deletions(-)
diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
index af5444a9f..c78db6916 100644
--- a/lib/librte_ring/rte_ring.h
+++ b/lib/librte_ring/rte_ring.h
@@ -1,6 +1,6 @@
/* SPDX-License-Identifier: BSD-3-Clause
*
- * Copyright (c) 2010-2017 Intel Corporation
+ * Copyright (c) 2010-2019 Intel Corporation
* Copyright (c) 2007-2009 Kip Macy kmacy@freebsd.org
* All rights reserved.
* Derived from FreeBSD's bufring.h
@@ -70,6 +70,13 @@ struct rte_ring_headtail {
uint32_t single; /**< True if single prod/cons */
};
+/* Structure to hold a pair of pointer-sized head/tail values and metadata */
+struct rte_ring_headtail_ptr {
+ volatile uintptr_t head; /**< Prod/consumer head. */
+ volatile uintptr_t tail; /**< Prod/consumer tail. */
+ uint32_t single; /**< True if single prod/cons */
+};
+
/**
* An RTE ring structure.
*
@@ -97,11 +104,19 @@ struct rte_ring {
char pad0 __rte_cache_aligned; /**< empty cache line */
/** Ring producer status. */
- struct rte_ring_headtail prod __rte_cache_aligned;
+ RTE_STD_C11
+ union {
+ struct rte_ring_headtail prod __rte_cache_aligned;
+ struct rte_ring_headtail_ptr prod_ptr __rte_cache_aligned;
+ };
char pad1 __rte_cache_aligned; /**< empty cache line */
/** Ring consumer status. */
- struct rte_ring_headtail cons __rte_cache_aligned;
+ RTE_STD_C11
+ union {
+ struct rte_ring_headtail cons __rte_cache_aligned;
+ struct rte_ring_headtail_ptr cons_ptr __rte_cache_aligned;
+ };
char pad2 __rte_cache_aligned; /**< empty cache line */
};
diff --git a/lib/librte_ring/rte_ring_c11_mem.h b/lib/librte_ring/rte_ring_c11_mem.h
index 0fb73a337..545caf257 100644
--- a/lib/librte_ring/rte_ring_c11_mem.h
+++ b/lib/librte_ring/rte_ring_c11_mem.h
@@ -178,4 +178,147 @@ __rte_ring_move_cons_head(struct rte_ring *r, int is_sc,
return n;
}
+/**
+ * @internal This function updates the producer head for enqueue using
+ * pointer-sized head/tail values.
+ *
+ * @param r
+ * A pointer to the ring structure
+ * @param is_sp
+ * Indicates whether multi-producer path is needed or not
+ * @param n
+ * The number of elements we will want to enqueue, i.e. how far should the
+ * head be moved
+ * @param behavior
+ * RTE_RING_QUEUE_FIXED: Enqueue a fixed number of items from a ring
+ * RTE_RING_QUEUE_VARIABLE: Enqueue as many items as possible from ring
+ * @param old_head
+ * Returns head value as it was before the move, i.e. where enqueue starts
+ * @param new_head
+ * Returns the current/new head value i.e. where enqueue finishes
+ * @param free_entries
+ * Returns the amount of free space in the ring BEFORE head was moved
+ * @return
+ * Actual number of objects enqueued.
+ * If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
+ */
+static __rte_always_inline unsigned int
+__rte_ring_move_prod_head_ptr(struct rte_ring *r, unsigned int is_sp,
+ unsigned int n, enum rte_ring_queue_behavior behavior,
+ uintptr_t *old_head, uintptr_t *new_head,
+ uint32_t *free_entries)
+{
+ const uint32_t capacity = r->capacity;
+ uintptr_t cons_tail;
+ unsigned int max = n;
+ int success;
+
+ *old_head = __atomic_load_n(&r->prod_ptr.head, __ATOMIC_RELAXED);
+ do {
+ /* Reset n to the initial burst count */
+ n = max;
+
+ /* Ensure the head is read before tail */
+ __atomic_thread_fence(__ATOMIC_ACQUIRE);
+
+ /* load-acquire synchronize with store-release of ht->tail
+ * in update_tail.
+ */
+ cons_tail = __atomic_load_n(&r->cons_ptr.tail,
+ __ATOMIC_ACQUIRE);
+
+ *free_entries = (capacity + cons_tail - *old_head);
+
+ /* check that we have enough room in ring */
+ if (unlikely(n > *free_entries))
+ n = (behavior == RTE_RING_QUEUE_FIXED) ?
+ 0 : *free_entries;
+
+ if (n == 0)
+ return 0;
+
+ *new_head = *old_head + n;
+ if (is_sp)
+ r->prod_ptr.head = *new_head, success = 1;
+ else
+ /* on failure, *old_head is updated */
+ success = __atomic_compare_exchange_n(&r->prod_ptr.head,
+ old_head, *new_head,
+ 0, __ATOMIC_RELAXED,
+ __ATOMIC_RELAXED);
+ } while (unlikely(success == 0));
+ return n;
+}
+
+/**
+ * @internal This function updates the consumer head for dequeue using
+ * pointer-sized head/tail values.
+ *
+ * @param r
+ * A pointer to the ring structure
+ * @param is_sc
+ * Indicates whether multi-consumer path is needed or not
+ * @param n
+ * The number of elements we will want to enqueue, i.e. how far should the
+ * head be moved
+ * @param behavior
+ * RTE_RING_QUEUE_FIXED: Dequeue a fixed number of items from a ring
+ * RTE_RING_QUEUE_VARIABLE: Dequeue as many items as possible from ring
+ * @param old_head
+ * Returns head value as it was before the move, i.e. where dequeue starts
+ * @param new_head
+ * Returns the current/new head value i.e. where dequeue finishes
+ * @param entries
+ * Returns the number of entries in the ring BEFORE head was moved
+ * @return
+ * - Actual number of objects dequeued.
+ * If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
+ */
+static __rte_always_inline unsigned int
+__rte_ring_move_cons_head_ptr(struct rte_ring *r, unsigned int is_sc,
+ unsigned int n, enum rte_ring_queue_behavior behavior,
+ uintptr_t *old_head, uintptr_t *new_head,
+ uint32_t *entries)
+{
+ unsigned int max = n;
+ uintptr_t prod_tail;
+ int success;
+
+ /* move cons.head atomically */
+ *old_head = __atomic_load_n(&r->cons_ptr.head, __ATOMIC_RELAXED);
+ do {
+ /* Restore n as it may change every loop */
+ n = max;
+
+ /* Ensure the head is read before tail */
+ __atomic_thread_fence(__ATOMIC_ACQUIRE);
+
+ /* this load-acquire synchronize with store-release of ht->tail
+ * in update_tail.
+ */
+ prod_tail = __atomic_load_n(&r->prod_ptr.tail,
+ __ATOMIC_ACQUIRE);
+
+ *entries = (prod_tail - *old_head);
+
+ /* Set the actual entries for dequeue */
+ if (n > *entries)
+ n = (behavior == RTE_RING_QUEUE_FIXED) ? 0 : *entries;
+
+ if (unlikely(n == 0))
+ return 0;
+
+ *new_head = *old_head + n;
+ if (is_sc)
+ r->cons_ptr.head = *new_head, success = 1;
+ else
+ /* on failure, *old_head will be updated */
+ success = __atomic_compare_exchange_n(&r->cons_ptr.head,
+ old_head, *new_head,
+ 0, __ATOMIC_RELAXED,
+ __ATOMIC_RELAXED);
+ } while (unlikely(success == 0));
+ return n;
+}
+
#endif /* _RTE_RING_C11_MEM_H_ */
diff --git a/lib/librte_ring/rte_ring_generic.h b/lib/librte_ring/rte_ring_generic.h
index ea7dbe5b9..6a0e1bbfb 100644
--- a/lib/librte_ring/rte_ring_generic.h
+++ b/lib/librte_ring/rte_ring_generic.h
@@ -167,4 +167,134 @@ __rte_ring_move_cons_head(struct rte_ring *r, unsigned int is_sc,
return n;
}
+/**
+ * @internal This function updates the producer head for enqueue using
+ * pointer-sized head/tail values.
+ *
+ * @param r
+ * A pointer to the ring structure
+ * @param is_sp
+ * Indicates whether multi-producer path is needed or not
+ * @param n
+ * The number of elements we will want to enqueue, i.e. how far should the
+ * head be moved
+ * @param behavior
+ * RTE_RING_QUEUE_FIXED: Enqueue a fixed number of items from a ring
+ * RTE_RING_QUEUE_VARIABLE: Enqueue as many items as possible from ring
+ * @param old_head
+ * Returns head value as it was before the move, i.e. where enqueue starts
+ * @param new_head
+ * Returns the current/new head value i.e. where enqueue finishes
+ * @param free_entries
+ * Returns the amount of free space in the ring BEFORE head was moved
+ * @return
+ * Actual number of objects enqueued.
+ * If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
+ */
+static __rte_always_inline unsigned int
+__rte_ring_move_prod_head_ptr(struct rte_ring *r, unsigned int is_sp,
+ unsigned int n, enum rte_ring_queue_behavior behavior,
+ uintptr_t *old_head, uintptr_t *new_head,
+ uint32_t *free_entries)
+{
+ const uint32_t capacity = r->capacity;
+ unsigned int max = n;
+ int success;
+
+ do {
+ /* Reset n to the initial burst count */
+ n = max;
+
+ *old_head = r->prod_ptr.head;
+
+ /* add rmb barrier to avoid load/load reorder in weak
+ * memory model. It is noop on x86
+ */
+ rte_smp_rmb();
+
+ *free_entries = (capacity + r->cons_ptr.tail - *old_head);
+
+ /* check that we have enough room in ring */
+ if (unlikely(n > *free_entries))
+ n = (behavior == RTE_RING_QUEUE_FIXED) ?
+ 0 : *free_entries;
+
+ if (n == 0)
+ return 0;
+
+ *new_head = *old_head + n;
+ if (is_sp)
+ r->prod_ptr.head = *new_head, success = 1;
+ else
+ success = __sync_bool_compare_and_swap(
+ &r->prod_ptr.head,
+ *old_head, *new_head);
+ } while (unlikely(success == 0));
+ return n;
+}
+
+/**
+ * @internal This function updates the consumer head for dequeue using
+ * pointer-sized head/tail values.
+ *
+ * @param r
+ * A pointer to the ring structure
+ * @param is_sc
+ * Indicates whether multi-consumer path is needed or not
+ * @param n
+ * The number of elements we will want to enqueue, i.e. how far should the
+ * head be moved
+ * @param behavior
+ * RTE_RING_QUEUE_FIXED: Dequeue a fixed number of items from a ring
+ * RTE_RING_QUEUE_VARIABLE: Dequeue as many items as possible from ring
+ * @param old_head
+ * Returns head value as it was before the move, i.e. where dequeue starts
+ * @param new_head
+ * Returns the current/new head value i.e. where dequeue finishes
+ * @param entries
+ * Returns the number of entries in the ring BEFORE head was moved
+ * @return
+ * - Actual number of objects dequeued.
+ * If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
+ */
+static __rte_always_inline unsigned int
+__rte_ring_move_cons_head_ptr(struct rte_ring *r, unsigned int is_sc,
+ unsigned int n, enum rte_ring_queue_behavior behavior,
+ uintptr_t *old_head, uintptr_t *new_head,
+ uint32_t *entries)
+{
+ unsigned int max = n;
+ int success;
+
+ do {
+ /* Restore n as it may change every loop */
+ n = max;
+
+ *old_head = r->cons_ptr.head;
+
+ /* add rmb barrier to avoid load/load reorder in weak
+ * memory model. It is noop on x86
+ */
+ rte_smp_rmb();
+
+ *entries = (r->prod_ptr.tail - *old_head);
+
+ /* Set the actual entries for dequeue */
+ if (n > *entries)
+ n = (behavior == RTE_RING_QUEUE_FIXED) ? 0 : *entries;
+
+ if (unlikely(n == 0))
+ return 0;
+
+ *new_head = *old_head + n;
+ if (is_sc)
+ r->cons_ptr.head = *new_head, success = 1;
+ else
+ success = __sync_bool_compare_and_swap(
+ &r->cons_ptr.head,
+ *old_head, *new_head);
+ } while (unlikely(success == 0));
+ return n;
+}
+
#endif /* _RTE_RING_GENERIC_H_ */
--
2.13.6
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v7 0/6] Add lock-free ring and mempool handler
2019-03-18 21:35 2% ` [dpdk-dev] [PATCH v7 0/6] Add lock-free ring and mempool handler Gage Eads
@ 2019-03-18 21:35 2% ` Gage Eads
2019-03-18 21:35 2% ` [dpdk-dev] [PATCH v7 1/6] ring: add a pointer-width headtail structure Gage Eads
` (2 subsequent siblings)
3 siblings, 0 replies; 200+ results
From: Gage Eads @ 2019-03-18 21:35 UTC (permalink / raw)
To: dev
Cc: olivier.matz, arybchenko, bruce.richardson, konstantin.ananyev,
stephen, jerinj, mczekaj, nd, Ola.Liljedahl, gage.eads
For some users, the rte ring's "non-preemptive" constraint is not acceptable;
for example, if the application uses a mixture of pinned high-priority threads
and multiplexed low-priority threads that share a mempool.
This patchset introduces a lock-free ring and a mempool based on it. The
lock-free algorithm relies on a double-pointer compare-and-swap, so for 64-bit
architectures it is currently limited to x86_64.
The ring uses more compare-and-swap atomic operations than the regular rte ring:
With no contention, an enqueue of n pointers uses (1 + n) CAS operations and a
dequeue of n pointers uses 1. This algorithm has worse average-case performance
than the regular rte ring (particularly a highly-contended ring with large bulk
accesses), however:
- For applications with preemptible pthreads, the regular rte ring's worst-case
performance (i.e. one thread being preempted in the update_tail() critical
section) is much worse than the lock-free ring's.
- Software caching can mitigate the average case performance for ring-based
algorithms. For example, a lock-free ring based mempool (a likely use case
for this ring) with per-thread caching.
The lock-free ring is enabled via a new flag, RING_F_LF. For ease-of-use,
existing ring enqueue/dequeue functions work with both standard and lock-free
rings. This is also an experimental API, so RING_F_LF users must build with the
ALLOW_EXPERIMENTAL_API flag.
This patchset also adds lock-free versions of ring_autotest and
ring_perf_autotest, and a lock-free ring based mempool.
This patchset makes one API change; a deprecation notice was posted in a
separate commit[1].
This patchset depends on the 128-bit compare-and-set patch[2].
[1] http://mails.dpdk.org/archives/dev/2019-February/124321.html
[2] http://mails.dpdk.org/archives/dev/2019-March/125751.html
v7:
- Added ARM copyright to rte_ring_generic.h and rte_ring_c11_mem.h, since the
lock-free algorithm is based on ARM's lfring (see v5 notes)
- Rename __rte_ring_reload_tail() -> __rte_ring_lf_load_tail()
- Remove the unused return value from __rte_ring_lf_load_tail()
- Rename 'prev_tail' to 'next_tail' in the multi-producer lock-free enqueue
v6:
- Rebase patchset onto master (test/test/ -> app/test/)
v5:
- Incorporated lfring's enqueue and dequeue logic from
http://mails.dpdk.org/archives/dev/2019-January/124242.html
- Renamed non-blocking -> lock-free and NB -> LF to align with a similar
change in the lock-free stack patchset:
http://mails.dpdk.org/archives/dev/2019-March/125797.html
- Added support for 32-bit architectures by using the full 32b of the
modification counter and requiring LF rings on these architectures to be at
least 1024 entries.
- Updated to the latest rte_atomic128_cmp_exchange() interface.
- Added ring start marker to struct rte_ring
v4:
- Split out nb_enqueue and nb_dequeue functions in generic and C11 versions,
with the necessary memory ordering behavior for weakly consistent machines.
- Convert size_t variables (from v2) to uint64_t and no-longer-applicable
comment about variably-sized ring indexes.
- Fix bug in nb_enqueue_mp that the breaks the non-blocking guarantee.
- Split the ring_ptr cast into two lines.
- Change the dependent patchset from the non-blocking stack patch series
to one only containing the 128b CAS commit
v3:
- Avoid the ABI break by putting 64-bit head and tail values in the same
cacheline as struct rte_ring's prod and cons members.
- Don't attempt to compile rte_atomic128_cmpset without
ALLOW_EXPERIMENTAL_API, as this would break a large number of libraries.
- Add a helpful warning to __rte_ring_do_nb_enqueue_mp() in case someone tries
to use RING_F_NB without the ALLOW_EXPERIMENTAL_API flag.
- Update the ring mempool to use experimental APIs
- Clarify that RINB_F_NB is only limited to x86_64 currently; e.g. ARMv8 has the
ISA support for 128-bit CAS to eventually support it.
v2:
- Merge separate docs commit into patch #5
- Convert uintptr_t to size_t
- Add a compile-time check for the size of size_t
- Fix a space-after-typecast issue
- Fix an unnecessary-parentheses checkpatch warning
- Bump librte_ring's library version
Gage Eads (6):
ring: add a pointer-width headtail structure
ring: add a ring start marker
ring: add a lock-free implementation
test_ring: add lock-free ring autotest
test_ring_perf: add lock-free ring perf test
mempool/ring: add lock-free ring handlers
app/test/test_ring.c | 61 +--
app/test/test_ring_perf.c | 19 +-
doc/guides/prog_guide/env_abstraction_layer.rst | 10 +
drivers/mempool/ring/Makefile | 1 +
drivers/mempool/ring/meson.build | 2 +
drivers/mempool/ring/rte_mempool_ring.c | 58 ++-
lib/librte_ring/rte_ring.c | 92 ++++-
lib/librte_ring/rte_ring.h | 334 ++++++++++++++--
lib/librte_ring/rte_ring_c11_mem.h | 501 ++++++++++++++++++++++++
lib/librte_ring/rte_ring_generic.h | 485 ++++++++++++++++++++++-
lib/librte_ring/rte_ring_version.map | 7 +
11 files changed, 1492 insertions(+), 78 deletions(-)
--
2.13.6
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v7 1/6] ring: add a pointer-width headtail structure
2019-03-18 21:35 2% ` [dpdk-dev] [PATCH v7 1/6] ring: add a pointer-width headtail structure Gage Eads
@ 2019-03-18 21:35 2% ` Gage Eads
0 siblings, 0 replies; 200+ results
From: Gage Eads @ 2019-03-18 21:35 UTC (permalink / raw)
To: dev
Cc: olivier.matz, arybchenko, bruce.richardson, konstantin.ananyev,
stephen, jerinj, mczekaj, nd, Ola.Liljedahl, gage.eads
For 64-bit systems, at current CPU speeds, 64-bit head and tail indexes
will not wrap-around within the author's lifetime. This is important to
avoiding the ABA problem -- in which a thread mistakes reading the same
tail index in two accesses to mean that the ring was not modified in the
intervening time -- in the upcoming lock-free ring implementation. Using a
64-bit index makes the possibility of this occurring effectively zero. This
commit uses pointer-width indexes so the lock-free ring can support 32-bit
systems as well.
This commit places the new producer and consumer structures in the same
location in struct rte_ring as their 32-bit counterparts. Since the 32-bit
versions are padded out to a cache line, there is space for the new
structure without affecting the layout of struct rte_ring. Thus, the ABI is
preserved.
Signed-off-by: Gage Eads <gage.eads@intel.com>
---
lib/librte_ring/rte_ring.h | 21 +++++-
lib/librte_ring/rte_ring_c11_mem.h | 143 +++++++++++++++++++++++++++++++++++++
lib/librte_ring/rte_ring_generic.h | 130 +++++++++++++++++++++++++++++++++
3 files changed, 291 insertions(+), 3 deletions(-)
diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
index af5444a9f..c78db6916 100644
--- a/lib/librte_ring/rte_ring.h
+++ b/lib/librte_ring/rte_ring.h
@@ -1,6 +1,6 @@
/* SPDX-License-Identifier: BSD-3-Clause
*
- * Copyright (c) 2010-2017 Intel Corporation
+ * Copyright (c) 2010-2019 Intel Corporation
* Copyright (c) 2007-2009 Kip Macy kmacy@freebsd.org
* All rights reserved.
* Derived from FreeBSD's bufring.h
@@ -70,6 +70,13 @@ struct rte_ring_headtail {
uint32_t single; /**< True if single prod/cons */
};
+/* Structure to hold a pair of pointer-sized head/tail values and metadata */
+struct rte_ring_headtail_ptr {
+ volatile uintptr_t head; /**< Prod/consumer head. */
+ volatile uintptr_t tail; /**< Prod/consumer tail. */
+ uint32_t single; /**< True if single prod/cons */
+};
+
/**
* An RTE ring structure.
*
@@ -97,11 +104,19 @@ struct rte_ring {
char pad0 __rte_cache_aligned; /**< empty cache line */
/** Ring producer status. */
- struct rte_ring_headtail prod __rte_cache_aligned;
+ RTE_STD_C11
+ union {
+ struct rte_ring_headtail prod __rte_cache_aligned;
+ struct rte_ring_headtail_ptr prod_ptr __rte_cache_aligned;
+ };
char pad1 __rte_cache_aligned; /**< empty cache line */
/** Ring consumer status. */
- struct rte_ring_headtail cons __rte_cache_aligned;
+ RTE_STD_C11
+ union {
+ struct rte_ring_headtail cons __rte_cache_aligned;
+ struct rte_ring_headtail_ptr cons_ptr __rte_cache_aligned;
+ };
char pad2 __rte_cache_aligned; /**< empty cache line */
};
diff --git a/lib/librte_ring/rte_ring_c11_mem.h b/lib/librte_ring/rte_ring_c11_mem.h
index 0fb73a337..545caf257 100644
--- a/lib/librte_ring/rte_ring_c11_mem.h
+++ b/lib/librte_ring/rte_ring_c11_mem.h
@@ -178,4 +178,147 @@ __rte_ring_move_cons_head(struct rte_ring *r, int is_sc,
return n;
}
+/**
+ * @internal This function updates the producer head for enqueue using
+ * pointer-sized head/tail values.
+ *
+ * @param r
+ * A pointer to the ring structure
+ * @param is_sp
+ * Indicates whether multi-producer path is needed or not
+ * @param n
+ * The number of elements we will want to enqueue, i.e. how far should the
+ * head be moved
+ * @param behavior
+ * RTE_RING_QUEUE_FIXED: Enqueue a fixed number of items from a ring
+ * RTE_RING_QUEUE_VARIABLE: Enqueue as many items as possible from ring
+ * @param old_head
+ * Returns head value as it was before the move, i.e. where enqueue starts
+ * @param new_head
+ * Returns the current/new head value i.e. where enqueue finishes
+ * @param free_entries
+ * Returns the amount of free space in the ring BEFORE head was moved
+ * @return
+ * Actual number of objects enqueued.
+ * If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
+ */
+static __rte_always_inline unsigned int
+__rte_ring_move_prod_head_ptr(struct rte_ring *r, unsigned int is_sp,
+ unsigned int n, enum rte_ring_queue_behavior behavior,
+ uintptr_t *old_head, uintptr_t *new_head,
+ uint32_t *free_entries)
+{
+ const uint32_t capacity = r->capacity;
+ uintptr_t cons_tail;
+ unsigned int max = n;
+ int success;
+
+ *old_head = __atomic_load_n(&r->prod_ptr.head, __ATOMIC_RELAXED);
+ do {
+ /* Reset n to the initial burst count */
+ n = max;
+
+ /* Ensure the head is read before tail */
+ __atomic_thread_fence(__ATOMIC_ACQUIRE);
+
+ /* load-acquire synchronize with store-release of ht->tail
+ * in update_tail.
+ */
+ cons_tail = __atomic_load_n(&r->cons_ptr.tail,
+ __ATOMIC_ACQUIRE);
+
+ *free_entries = (capacity + cons_tail - *old_head);
+
+ /* check that we have enough room in ring */
+ if (unlikely(n > *free_entries))
+ n = (behavior == RTE_RING_QUEUE_FIXED) ?
+ 0 : *free_entries;
+
+ if (n == 0)
+ return 0;
+
+ *new_head = *old_head + n;
+ if (is_sp)
+ r->prod_ptr.head = *new_head, success = 1;
+ else
+ /* on failure, *old_head is updated */
+ success = __atomic_compare_exchange_n(&r->prod_ptr.head,
+ old_head, *new_head,
+ 0, __ATOMIC_RELAXED,
+ __ATOMIC_RELAXED);
+ } while (unlikely(success == 0));
+ return n;
+}
+
+/**
+ * @internal This function updates the consumer head for dequeue using
+ * pointer-sized head/tail values.
+ *
+ * @param r
+ * A pointer to the ring structure
+ * @param is_sc
+ * Indicates whether multi-consumer path is needed or not
+ * @param n
+ * The number of elements we will want to enqueue, i.e. how far should the
+ * head be moved
+ * @param behavior
+ * RTE_RING_QUEUE_FIXED: Dequeue a fixed number of items from a ring
+ * RTE_RING_QUEUE_VARIABLE: Dequeue as many items as possible from ring
+ * @param old_head
+ * Returns head value as it was before the move, i.e. where dequeue starts
+ * @param new_head
+ * Returns the current/new head value i.e. where dequeue finishes
+ * @param entries
+ * Returns the number of entries in the ring BEFORE head was moved
+ * @return
+ * - Actual number of objects dequeued.
+ * If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
+ */
+static __rte_always_inline unsigned int
+__rte_ring_move_cons_head_ptr(struct rte_ring *r, unsigned int is_sc,
+ unsigned int n, enum rte_ring_queue_behavior behavior,
+ uintptr_t *old_head, uintptr_t *new_head,
+ uint32_t *entries)
+{
+ unsigned int max = n;
+ uintptr_t prod_tail;
+ int success;
+
+ /* move cons.head atomically */
+ *old_head = __atomic_load_n(&r->cons_ptr.head, __ATOMIC_RELAXED);
+ do {
+ /* Restore n as it may change every loop */
+ n = max;
+
+ /* Ensure the head is read before tail */
+ __atomic_thread_fence(__ATOMIC_ACQUIRE);
+
+ /* this load-acquire synchronize with store-release of ht->tail
+ * in update_tail.
+ */
+ prod_tail = __atomic_load_n(&r->prod_ptr.tail,
+ __ATOMIC_ACQUIRE);
+
+ *entries = (prod_tail - *old_head);
+
+ /* Set the actual entries for dequeue */
+ if (n > *entries)
+ n = (behavior == RTE_RING_QUEUE_FIXED) ? 0 : *entries;
+
+ if (unlikely(n == 0))
+ return 0;
+
+ *new_head = *old_head + n;
+ if (is_sc)
+ r->cons_ptr.head = *new_head, success = 1;
+ else
+ /* on failure, *old_head will be updated */
+ success = __atomic_compare_exchange_n(&r->cons_ptr.head,
+ old_head, *new_head,
+ 0, __ATOMIC_RELAXED,
+ __ATOMIC_RELAXED);
+ } while (unlikely(success == 0));
+ return n;
+}
+
#endif /* _RTE_RING_C11_MEM_H_ */
diff --git a/lib/librte_ring/rte_ring_generic.h b/lib/librte_ring/rte_ring_generic.h
index ea7dbe5b9..6a0e1bbfb 100644
--- a/lib/librte_ring/rte_ring_generic.h
+++ b/lib/librte_ring/rte_ring_generic.h
@@ -167,4 +167,134 @@ __rte_ring_move_cons_head(struct rte_ring *r, unsigned int is_sc,
return n;
}
+/**
+ * @internal This function updates the producer head for enqueue using
+ * pointer-sized head/tail values.
+ *
+ * @param r
+ * A pointer to the ring structure
+ * @param is_sp
+ * Indicates whether multi-producer path is needed or not
+ * @param n
+ * The number of elements we will want to enqueue, i.e. how far should the
+ * head be moved
+ * @param behavior
+ * RTE_RING_QUEUE_FIXED: Enqueue a fixed number of items from a ring
+ * RTE_RING_QUEUE_VARIABLE: Enqueue as many items as possible from ring
+ * @param old_head
+ * Returns head value as it was before the move, i.e. where enqueue starts
+ * @param new_head
+ * Returns the current/new head value i.e. where enqueue finishes
+ * @param free_entries
+ * Returns the amount of free space in the ring BEFORE head was moved
+ * @return
+ * Actual number of objects enqueued.
+ * If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
+ */
+static __rte_always_inline unsigned int
+__rte_ring_move_prod_head_ptr(struct rte_ring *r, unsigned int is_sp,
+ unsigned int n, enum rte_ring_queue_behavior behavior,
+ uintptr_t *old_head, uintptr_t *new_head,
+ uint32_t *free_entries)
+{
+ const uint32_t capacity = r->capacity;
+ unsigned int max = n;
+ int success;
+
+ do {
+ /* Reset n to the initial burst count */
+ n = max;
+
+ *old_head = r->prod_ptr.head;
+
+ /* add rmb barrier to avoid load/load reorder in weak
+ * memory model. It is noop on x86
+ */
+ rte_smp_rmb();
+
+ *free_entries = (capacity + r->cons_ptr.tail - *old_head);
+
+ /* check that we have enough room in ring */
+ if (unlikely(n > *free_entries))
+ n = (behavior == RTE_RING_QUEUE_FIXED) ?
+ 0 : *free_entries;
+
+ if (n == 0)
+ return 0;
+
+ *new_head = *old_head + n;
+ if (is_sp)
+ r->prod_ptr.head = *new_head, success = 1;
+ else
+ success = __sync_bool_compare_and_swap(
+ &r->prod_ptr.head,
+ *old_head, *new_head);
+ } while (unlikely(success == 0));
+ return n;
+}
+
+/**
+ * @internal This function updates the consumer head for dequeue using
+ * pointer-sized head/tail values.
+ *
+ * @param r
+ * A pointer to the ring structure
+ * @param is_sc
+ * Indicates whether multi-consumer path is needed or not
+ * @param n
+ * The number of elements we will want to enqueue, i.e. how far should the
+ * head be moved
+ * @param behavior
+ * RTE_RING_QUEUE_FIXED: Dequeue a fixed number of items from a ring
+ * RTE_RING_QUEUE_VARIABLE: Dequeue as many items as possible from ring
+ * @param old_head
+ * Returns head value as it was before the move, i.e. where dequeue starts
+ * @param new_head
+ * Returns the current/new head value i.e. where dequeue finishes
+ * @param entries
+ * Returns the number of entries in the ring BEFORE head was moved
+ * @return
+ * - Actual number of objects dequeued.
+ * If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
+ */
+static __rte_always_inline unsigned int
+__rte_ring_move_cons_head_ptr(struct rte_ring *r, unsigned int is_sc,
+ unsigned int n, enum rte_ring_queue_behavior behavior,
+ uintptr_t *old_head, uintptr_t *new_head,
+ uint32_t *entries)
+{
+ unsigned int max = n;
+ int success;
+
+ do {
+ /* Restore n as it may change every loop */
+ n = max;
+
+ *old_head = r->cons_ptr.head;
+
+ /* add rmb barrier to avoid load/load reorder in weak
+ * memory model. It is noop on x86
+ */
+ rte_smp_rmb();
+
+ *entries = (r->prod_ptr.tail - *old_head);
+
+ /* Set the actual entries for dequeue */
+ if (n > *entries)
+ n = (behavior == RTE_RING_QUEUE_FIXED) ? 0 : *entries;
+
+ if (unlikely(n == 0))
+ return 0;
+
+ *new_head = *old_head + n;
+ if (is_sc)
+ r->cons_ptr.head = *new_head, success = 1;
+ else
+ success = __sync_bool_compare_and_swap(
+ &r->cons_ptr.head,
+ *old_head, *new_head);
+ } while (unlikely(success == 0));
+ return n;
+}
+
#endif /* _RTE_RING_GENERIC_H_ */
--
2.13.6
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v8 0/6] Add lock-free ring and mempool handler
2019-03-18 21:35 2% ` [dpdk-dev] [PATCH v7 0/6] Add lock-free ring and mempool handler Gage Eads
` (2 preceding siblings ...)
@ 2019-03-19 1:20 2% ` Gage Eads
2019-03-19 1:20 2% ` Gage Eads
2019-03-19 1:20 2% ` [dpdk-dev] [PATCH v8 1/6] ring: add a pointer-width headtail structure Gage Eads
3 siblings, 2 replies; 200+ results
From: Gage Eads @ 2019-03-19 1:20 UTC (permalink / raw)
To: dev
Cc: olivier.matz, arybchenko, bruce.richardson, konstantin.ananyev,
stephen, jerinj, mczekaj, nd, Ola.Liljedahl, gage.eads
For some users, the rte ring's "non-preemptive" constraint is not acceptable;
for example, if the application uses a mixture of pinned high-priority threads
and multiplexed low-priority threads that share a mempool.
This patchset introduces a lock-free ring and a mempool based on it. The
lock-free algorithm relies on a double-pointer compare-and-swap, so for 64-bit
architectures it is currently limited to x86_64.
The ring uses more compare-and-swap atomic operations than the regular rte ring:
With no contention, an enqueue of n pointers uses (1 + n) CAS operations and a
dequeue of n pointers uses 1. This algorithm has worse average-case performance
than the regular rte ring (particularly a highly-contended ring with large bulk
accesses), however:
- For applications with preemptible pthreads, the regular rte ring's worst-case
performance (i.e. one thread being preempted in the update_tail() critical
section) is much worse than the lock-free ring's.
- Software caching can mitigate the average case performance for ring-based
algorithms. For example, a lock-free ring based mempool (a likely use case
for this ring) with per-thread caching.
The lock-free ring is enabled via a new flag, RING_F_LF. For ease-of-use,
existing ring enqueue/dequeue functions work with both standard and lock-free
rings. This is also an experimental API, so RING_F_LF users must build with the
ALLOW_EXPERIMENTAL_API flag.
This patchset also adds lock-free versions of ring_autotest and
ring_perf_autotest, and a lock-free ring based mempool.
This patchset makes one API change; a deprecation notice was posted in a
separate commit[1].
This patchset depends on the 128-bit compare-and-set patch[2].
[1] http://mails.dpdk.org/archives/dev/2019-February/124321.html
[2] http://mails.dpdk.org/archives/dev/2019-March/125751.html
v8:
- Fixed two bugs in the generic implementation written as though the
compare-and-swap would update the expected value on failure.
v7:
- Added ARM copyright to rte_ring_generic.h and rte_ring_c11_mem.h, since the
lock-free algorithm is based on ARM's lfring (see v5 notes)
- Rename __rte_ring_reload_tail() -> __rte_ring_lf_load_tail()
- Remove the unused return value from __rte_ring_lf_load_tail()
- Rename 'prev_tail' to 'next_tail' in the multi-producer lock-free enqueue
v6:
- Rebase patchset onto master (test/test/ -> app/test/)
v5:
- Incorporated lfring's enqueue and dequeue logic from
http://mails.dpdk.org/archives/dev/2019-January/124242.html
- Renamed non-blocking -> lock-free and NB -> LF to align with a similar
change in the lock-free stack patchset:
http://mails.dpdk.org/archives/dev/2019-March/125797.html
- Added support for 32-bit architectures by using the full 32b of the
modification counter and requiring LF rings on these architectures to be at
least 1024 entries.
- Updated to the latest rte_atomic128_cmp_exchange() interface.
- Added ring start marker to struct rte_ring
v4:
- Split out nb_enqueue and nb_dequeue functions in generic and C11 versions,
with the necessary memory ordering behavior for weakly consistent machines.
- Convert size_t variables (from v2) to uint64_t and no-longer-applicable
comment about variably-sized ring indexes.
- Fix bug in nb_enqueue_mp that the breaks the non-blocking guarantee.
- Split the ring_ptr cast into two lines.
- Change the dependent patchset from the non-blocking stack patch series
to one only containing the 128b CAS commit
v3:
- Avoid the ABI break by putting 64-bit head and tail values in the same
cacheline as struct rte_ring's prod and cons members.
- Don't attempt to compile rte_atomic128_cmpset without
ALLOW_EXPERIMENTAL_API, as this would break a large number of libraries.
- Add a helpful warning to __rte_ring_do_nb_enqueue_mp() in case someone tries
to use RING_F_NB without the ALLOW_EXPERIMENTAL_API flag.
- Update the ring mempool to use experimental APIs
- Clarify that RINB_F_NB is only limited to x86_64 currently; e.g. ARMv8 has the
ISA support for 128-bit CAS to eventually support it.
v2:
- Merge separate docs commit into patch #5
- Convert uintptr_t to size_t
- Add a compile-time check for the size of size_t
- Fix a space-after-typecast issue
- Fix an unnecessary-parentheses checkpatch warning
- Bump librte_ring's library version
Gage Eads (6):
ring: add a pointer-width headtail structure
ring: add a ring start marker
ring: add a lock-free implementation
test_ring: add lock-free ring autotest
test_ring_perf: add lock-free ring perf test
mempool/ring: add lock-free ring handlers
app/test/test_ring.c | 61 +--
app/test/test_ring_perf.c | 19 +-
doc/guides/prog_guide/env_abstraction_layer.rst | 10 +
drivers/mempool/ring/Makefile | 1 +
drivers/mempool/ring/meson.build | 2 +
drivers/mempool/ring/rte_mempool_ring.c | 58 ++-
lib/librte_ring/rte_ring.c | 92 ++++-
lib/librte_ring/rte_ring.h | 334 ++++++++++++++--
lib/librte_ring/rte_ring_c11_mem.h | 501 ++++++++++++++++++++++++
lib/librte_ring/rte_ring_generic.h | 487 ++++++++++++++++++++++-
lib/librte_ring/rte_ring_version.map | 7 +
11 files changed, 1494 insertions(+), 78 deletions(-)
--
2.13.6
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v8 1/6] ring: add a pointer-width headtail structure
2019-03-19 1:20 2% ` [dpdk-dev] [PATCH v8 " Gage Eads
2019-03-19 1:20 2% ` Gage Eads
@ 2019-03-19 1:20 2% ` Gage Eads
2019-03-19 1:20 2% ` Gage Eads
1 sibling, 1 reply; 200+ results
From: Gage Eads @ 2019-03-19 1:20 UTC (permalink / raw)
To: dev
Cc: olivier.matz, arybchenko, bruce.richardson, konstantin.ananyev,
stephen, jerinj, mczekaj, nd, Ola.Liljedahl, gage.eads
For 64-bit systems, at current CPU speeds, 64-bit head and tail indexes
will not wrap-around within the author's lifetime. This is important to
avoiding the ABA problem -- in which a thread mistakes reading the same
tail index in two accesses to mean that the ring was not modified in the
intervening time -- in the upcoming lock-free ring implementation. Using a
64-bit index makes the possibility of this occurring effectively zero. This
commit uses pointer-width indexes so the lock-free ring can support 32-bit
systems as well.
This commit places the new producer and consumer structures in the same
location in struct rte_ring as their 32-bit counterparts. Since the 32-bit
versions are padded out to a cache line, there is space for the new
structure without affecting the layout of struct rte_ring. Thus, the ABI is
preserved.
Signed-off-by: Gage Eads <gage.eads@intel.com>
---
lib/librte_ring/rte_ring.h | 21 +++++-
lib/librte_ring/rte_ring_c11_mem.h | 143 +++++++++++++++++++++++++++++++++++++
lib/librte_ring/rte_ring_generic.h | 130 +++++++++++++++++++++++++++++++++
3 files changed, 291 insertions(+), 3 deletions(-)
diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
index af5444a9f..c78db6916 100644
--- a/lib/librte_ring/rte_ring.h
+++ b/lib/librte_ring/rte_ring.h
@@ -1,6 +1,6 @@
/* SPDX-License-Identifier: BSD-3-Clause
*
- * Copyright (c) 2010-2017 Intel Corporation
+ * Copyright (c) 2010-2019 Intel Corporation
* Copyright (c) 2007-2009 Kip Macy kmacy@freebsd.org
* All rights reserved.
* Derived from FreeBSD's bufring.h
@@ -70,6 +70,13 @@ struct rte_ring_headtail {
uint32_t single; /**< True if single prod/cons */
};
+/* Structure to hold a pair of pointer-sized head/tail values and metadata */
+struct rte_ring_headtail_ptr {
+ volatile uintptr_t head; /**< Prod/consumer head. */
+ volatile uintptr_t tail; /**< Prod/consumer tail. */
+ uint32_t single; /**< True if single prod/cons */
+};
+
/**
* An RTE ring structure.
*
@@ -97,11 +104,19 @@ struct rte_ring {
char pad0 __rte_cache_aligned; /**< empty cache line */
/** Ring producer status. */
- struct rte_ring_headtail prod __rte_cache_aligned;
+ RTE_STD_C11
+ union {
+ struct rte_ring_headtail prod __rte_cache_aligned;
+ struct rte_ring_headtail_ptr prod_ptr __rte_cache_aligned;
+ };
char pad1 __rte_cache_aligned; /**< empty cache line */
/** Ring consumer status. */
- struct rte_ring_headtail cons __rte_cache_aligned;
+ RTE_STD_C11
+ union {
+ struct rte_ring_headtail cons __rte_cache_aligned;
+ struct rte_ring_headtail_ptr cons_ptr __rte_cache_aligned;
+ };
char pad2 __rte_cache_aligned; /**< empty cache line */
};
diff --git a/lib/librte_ring/rte_ring_c11_mem.h b/lib/librte_ring/rte_ring_c11_mem.h
index 0fb73a337..545caf257 100644
--- a/lib/librte_ring/rte_ring_c11_mem.h
+++ b/lib/librte_ring/rte_ring_c11_mem.h
@@ -178,4 +178,147 @@ __rte_ring_move_cons_head(struct rte_ring *r, int is_sc,
return n;
}
+/**
+ * @internal This function updates the producer head for enqueue using
+ * pointer-sized head/tail values.
+ *
+ * @param r
+ * A pointer to the ring structure
+ * @param is_sp
+ * Indicates whether multi-producer path is needed or not
+ * @param n
+ * The number of elements we will want to enqueue, i.e. how far should the
+ * head be moved
+ * @param behavior
+ * RTE_RING_QUEUE_FIXED: Enqueue a fixed number of items from a ring
+ * RTE_RING_QUEUE_VARIABLE: Enqueue as many items as possible from ring
+ * @param old_head
+ * Returns head value as it was before the move, i.e. where enqueue starts
+ * @param new_head
+ * Returns the current/new head value i.e. where enqueue finishes
+ * @param free_entries
+ * Returns the amount of free space in the ring BEFORE head was moved
+ * @return
+ * Actual number of objects enqueued.
+ * If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
+ */
+static __rte_always_inline unsigned int
+__rte_ring_move_prod_head_ptr(struct rte_ring *r, unsigned int is_sp,
+ unsigned int n, enum rte_ring_queue_behavior behavior,
+ uintptr_t *old_head, uintptr_t *new_head,
+ uint32_t *free_entries)
+{
+ const uint32_t capacity = r->capacity;
+ uintptr_t cons_tail;
+ unsigned int max = n;
+ int success;
+
+ *old_head = __atomic_load_n(&r->prod_ptr.head, __ATOMIC_RELAXED);
+ do {
+ /* Reset n to the initial burst count */
+ n = max;
+
+ /* Ensure the head is read before tail */
+ __atomic_thread_fence(__ATOMIC_ACQUIRE);
+
+ /* load-acquire synchronize with store-release of ht->tail
+ * in update_tail.
+ */
+ cons_tail = __atomic_load_n(&r->cons_ptr.tail,
+ __ATOMIC_ACQUIRE);
+
+ *free_entries = (capacity + cons_tail - *old_head);
+
+ /* check that we have enough room in ring */
+ if (unlikely(n > *free_entries))
+ n = (behavior == RTE_RING_QUEUE_FIXED) ?
+ 0 : *free_entries;
+
+ if (n == 0)
+ return 0;
+
+ *new_head = *old_head + n;
+ if (is_sp)
+ r->prod_ptr.head = *new_head, success = 1;
+ else
+ /* on failure, *old_head is updated */
+ success = __atomic_compare_exchange_n(&r->prod_ptr.head,
+ old_head, *new_head,
+ 0, __ATOMIC_RELAXED,
+ __ATOMIC_RELAXED);
+ } while (unlikely(success == 0));
+ return n;
+}
+
+/**
+ * @internal This function updates the consumer head for dequeue using
+ * pointer-sized head/tail values.
+ *
+ * @param r
+ * A pointer to the ring structure
+ * @param is_sc
+ * Indicates whether multi-consumer path is needed or not
+ * @param n
+ * The number of elements we will want to enqueue, i.e. how far should the
+ * head be moved
+ * @param behavior
+ * RTE_RING_QUEUE_FIXED: Dequeue a fixed number of items from a ring
+ * RTE_RING_QUEUE_VARIABLE: Dequeue as many items as possible from ring
+ * @param old_head
+ * Returns head value as it was before the move, i.e. where dequeue starts
+ * @param new_head
+ * Returns the current/new head value i.e. where dequeue finishes
+ * @param entries
+ * Returns the number of entries in the ring BEFORE head was moved
+ * @return
+ * - Actual number of objects dequeued.
+ * If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
+ */
+static __rte_always_inline unsigned int
+__rte_ring_move_cons_head_ptr(struct rte_ring *r, unsigned int is_sc,
+ unsigned int n, enum rte_ring_queue_behavior behavior,
+ uintptr_t *old_head, uintptr_t *new_head,
+ uint32_t *entries)
+{
+ unsigned int max = n;
+ uintptr_t prod_tail;
+ int success;
+
+ /* move cons.head atomically */
+ *old_head = __atomic_load_n(&r->cons_ptr.head, __ATOMIC_RELAXED);
+ do {
+ /* Restore n as it may change every loop */
+ n = max;
+
+ /* Ensure the head is read before tail */
+ __atomic_thread_fence(__ATOMIC_ACQUIRE);
+
+ /* this load-acquire synchronize with store-release of ht->tail
+ * in update_tail.
+ */
+ prod_tail = __atomic_load_n(&r->prod_ptr.tail,
+ __ATOMIC_ACQUIRE);
+
+ *entries = (prod_tail - *old_head);
+
+ /* Set the actual entries for dequeue */
+ if (n > *entries)
+ n = (behavior == RTE_RING_QUEUE_FIXED) ? 0 : *entries;
+
+ if (unlikely(n == 0))
+ return 0;
+
+ *new_head = *old_head + n;
+ if (is_sc)
+ r->cons_ptr.head = *new_head, success = 1;
+ else
+ /* on failure, *old_head will be updated */
+ success = __atomic_compare_exchange_n(&r->cons_ptr.head,
+ old_head, *new_head,
+ 0, __ATOMIC_RELAXED,
+ __ATOMIC_RELAXED);
+ } while (unlikely(success == 0));
+ return n;
+}
+
#endif /* _RTE_RING_C11_MEM_H_ */
diff --git a/lib/librte_ring/rte_ring_generic.h b/lib/librte_ring/rte_ring_generic.h
index ea7dbe5b9..6a0e1bbfb 100644
--- a/lib/librte_ring/rte_ring_generic.h
+++ b/lib/librte_ring/rte_ring_generic.h
@@ -167,4 +167,134 @@ __rte_ring_move_cons_head(struct rte_ring *r, unsigned int is_sc,
return n;
}
+/**
+ * @internal This function updates the producer head for enqueue using
+ * pointer-sized head/tail values.
+ *
+ * @param r
+ * A pointer to the ring structure
+ * @param is_sp
+ * Indicates whether multi-producer path is needed or not
+ * @param n
+ * The number of elements we will want to enqueue, i.e. how far should the
+ * head be moved
+ * @param behavior
+ * RTE_RING_QUEUE_FIXED: Enqueue a fixed number of items from a ring
+ * RTE_RING_QUEUE_VARIABLE: Enqueue as many items as possible from ring
+ * @param old_head
+ * Returns head value as it was before the move, i.e. where enqueue starts
+ * @param new_head
+ * Returns the current/new head value i.e. where enqueue finishes
+ * @param free_entries
+ * Returns the amount of free space in the ring BEFORE head was moved
+ * @return
+ * Actual number of objects enqueued.
+ * If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
+ */
+static __rte_always_inline unsigned int
+__rte_ring_move_prod_head_ptr(struct rte_ring *r, unsigned int is_sp,
+ unsigned int n, enum rte_ring_queue_behavior behavior,
+ uintptr_t *old_head, uintptr_t *new_head,
+ uint32_t *free_entries)
+{
+ const uint32_t capacity = r->capacity;
+ unsigned int max = n;
+ int success;
+
+ do {
+ /* Reset n to the initial burst count */
+ n = max;
+
+ *old_head = r->prod_ptr.head;
+
+ /* add rmb barrier to avoid load/load reorder in weak
+ * memory model. It is noop on x86
+ */
+ rte_smp_rmb();
+
+ *free_entries = (capacity + r->cons_ptr.tail - *old_head);
+
+ /* check that we have enough room in ring */
+ if (unlikely(n > *free_entries))
+ n = (behavior == RTE_RING_QUEUE_FIXED) ?
+ 0 : *free_entries;
+
+ if (n == 0)
+ return 0;
+
+ *new_head = *old_head + n;
+ if (is_sp)
+ r->prod_ptr.head = *new_head, success = 1;
+ else
+ success = __sync_bool_compare_and_swap(
+ &r->prod_ptr.head,
+ *old_head, *new_head);
+ } while (unlikely(success == 0));
+ return n;
+}
+
+/**
+ * @internal This function updates the consumer head for dequeue using
+ * pointer-sized head/tail values.
+ *
+ * @param r
+ * A pointer to the ring structure
+ * @param is_sc
+ * Indicates whether multi-consumer path is needed or not
+ * @param n
+ * The number of elements we will want to enqueue, i.e. how far should the
+ * head be moved
+ * @param behavior
+ * RTE_RING_QUEUE_FIXED: Dequeue a fixed number of items from a ring
+ * RTE_RING_QUEUE_VARIABLE: Dequeue as many items as possible from ring
+ * @param old_head
+ * Returns head value as it was before the move, i.e. where dequeue starts
+ * @param new_head
+ * Returns the current/new head value i.e. where dequeue finishes
+ * @param entries
+ * Returns the number of entries in the ring BEFORE head was moved
+ * @return
+ * - Actual number of objects dequeued.
+ * If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
+ */
+static __rte_always_inline unsigned int
+__rte_ring_move_cons_head_ptr(struct rte_ring *r, unsigned int is_sc,
+ unsigned int n, enum rte_ring_queue_behavior behavior,
+ uintptr_t *old_head, uintptr_t *new_head,
+ uint32_t *entries)
+{
+ unsigned int max = n;
+ int success;
+
+ do {
+ /* Restore n as it may change every loop */
+ n = max;
+
+ *old_head = r->cons_ptr.head;
+
+ /* add rmb barrier to avoid load/load reorder in weak
+ * memory model. It is noop on x86
+ */
+ rte_smp_rmb();
+
+ *entries = (r->prod_ptr.tail - *old_head);
+
+ /* Set the actual entries for dequeue */
+ if (n > *entries)
+ n = (behavior == RTE_RING_QUEUE_FIXED) ? 0 : *entries;
+
+ if (unlikely(n == 0))
+ return 0;
+
+ *new_head = *old_head + n;
+ if (is_sc)
+ r->cons_ptr.head = *new_head, success = 1;
+ else
+ success = __sync_bool_compare_and_swap(
+ &r->cons_ptr.head,
+ *old_head, *new_head);
+ } while (unlikely(success == 0));
+ return n;
+}
+
#endif /* _RTE_RING_GENERIC_H_ */
--
2.13.6
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v8 0/6] Add lock-free ring and mempool handler
2019-03-19 1:20 2% ` [dpdk-dev] [PATCH v8 " Gage Eads
@ 2019-03-19 1:20 2% ` Gage Eads
2019-03-19 1:20 2% ` [dpdk-dev] [PATCH v8 1/6] ring: add a pointer-width headtail structure Gage Eads
1 sibling, 0 replies; 200+ results
From: Gage Eads @ 2019-03-19 1:20 UTC (permalink / raw)
To: dev
Cc: olivier.matz, arybchenko, bruce.richardson, konstantin.ananyev,
stephen, jerinj, mczekaj, nd, Ola.Liljedahl, gage.eads
For some users, the rte ring's "non-preemptive" constraint is not acceptable;
for example, if the application uses a mixture of pinned high-priority threads
and multiplexed low-priority threads that share a mempool.
This patchset introduces a lock-free ring and a mempool based on it. The
lock-free algorithm relies on a double-pointer compare-and-swap, so for 64-bit
architectures it is currently limited to x86_64.
The ring uses more compare-and-swap atomic operations than the regular rte ring:
With no contention, an enqueue of n pointers uses (1 + n) CAS operations and a
dequeue of n pointers uses 1. This algorithm has worse average-case performance
than the regular rte ring (particularly a highly-contended ring with large bulk
accesses), however:
- For applications with preemptible pthreads, the regular rte ring's worst-case
performance (i.e. one thread being preempted in the update_tail() critical
section) is much worse than the lock-free ring's.
- Software caching can mitigate the average case performance for ring-based
algorithms. For example, a lock-free ring based mempool (a likely use case
for this ring) with per-thread caching.
The lock-free ring is enabled via a new flag, RING_F_LF. For ease-of-use,
existing ring enqueue/dequeue functions work with both standard and lock-free
rings. This is also an experimental API, so RING_F_LF users must build with the
ALLOW_EXPERIMENTAL_API flag.
This patchset also adds lock-free versions of ring_autotest and
ring_perf_autotest, and a lock-free ring based mempool.
This patchset makes one API change; a deprecation notice was posted in a
separate commit[1].
This patchset depends on the 128-bit compare-and-set patch[2].
[1] http://mails.dpdk.org/archives/dev/2019-February/124321.html
[2] http://mails.dpdk.org/archives/dev/2019-March/125751.html
v8:
- Fixed two bugs in the generic implementation written as though the
compare-and-swap would update the expected value on failure.
v7:
- Added ARM copyright to rte_ring_generic.h and rte_ring_c11_mem.h, since the
lock-free algorithm is based on ARM's lfring (see v5 notes)
- Rename __rte_ring_reload_tail() -> __rte_ring_lf_load_tail()
- Remove the unused return value from __rte_ring_lf_load_tail()
- Rename 'prev_tail' to 'next_tail' in the multi-producer lock-free enqueue
v6:
- Rebase patchset onto master (test/test/ -> app/test/)
v5:
- Incorporated lfring's enqueue and dequeue logic from
http://mails.dpdk.org/archives/dev/2019-January/124242.html
- Renamed non-blocking -> lock-free and NB -> LF to align with a similar
change in the lock-free stack patchset:
http://mails.dpdk.org/archives/dev/2019-March/125797.html
- Added support for 32-bit architectures by using the full 32b of the
modification counter and requiring LF rings on these architectures to be at
least 1024 entries.
- Updated to the latest rte_atomic128_cmp_exchange() interface.
- Added ring start marker to struct rte_ring
v4:
- Split out nb_enqueue and nb_dequeue functions in generic and C11 versions,
with the necessary memory ordering behavior for weakly consistent machines.
- Convert size_t variables (from v2) to uint64_t and no-longer-applicable
comment about variably-sized ring indexes.
- Fix bug in nb_enqueue_mp that the breaks the non-blocking guarantee.
- Split the ring_ptr cast into two lines.
- Change the dependent patchset from the non-blocking stack patch series
to one only containing the 128b CAS commit
v3:
- Avoid the ABI break by putting 64-bit head and tail values in the same
cacheline as struct rte_ring's prod and cons members.
- Don't attempt to compile rte_atomic128_cmpset without
ALLOW_EXPERIMENTAL_API, as this would break a large number of libraries.
- Add a helpful warning to __rte_ring_do_nb_enqueue_mp() in case someone tries
to use RING_F_NB without the ALLOW_EXPERIMENTAL_API flag.
- Update the ring mempool to use experimental APIs
- Clarify that RINB_F_NB is only limited to x86_64 currently; e.g. ARMv8 has the
ISA support for 128-bit CAS to eventually support it.
v2:
- Merge separate docs commit into patch #5
- Convert uintptr_t to size_t
- Add a compile-time check for the size of size_t
- Fix a space-after-typecast issue
- Fix an unnecessary-parentheses checkpatch warning
- Bump librte_ring's library version
Gage Eads (6):
ring: add a pointer-width headtail structure
ring: add a ring start marker
ring: add a lock-free implementation
test_ring: add lock-free ring autotest
test_ring_perf: add lock-free ring perf test
mempool/ring: add lock-free ring handlers
app/test/test_ring.c | 61 +--
app/test/test_ring_perf.c | 19 +-
doc/guides/prog_guide/env_abstraction_layer.rst | 10 +
drivers/mempool/ring/Makefile | 1 +
drivers/mempool/ring/meson.build | 2 +
drivers/mempool/ring/rte_mempool_ring.c | 58 ++-
lib/librte_ring/rte_ring.c | 92 ++++-
lib/librte_ring/rte_ring.h | 334 ++++++++++++++--
lib/librte_ring/rte_ring_c11_mem.h | 501 ++++++++++++++++++++++++
lib/librte_ring/rte_ring_generic.h | 487 ++++++++++++++++++++++-
lib/librte_ring/rte_ring_version.map | 7 +
11 files changed, 1494 insertions(+), 78 deletions(-)
--
2.13.6
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v8 1/6] ring: add a pointer-width headtail structure
2019-03-19 1:20 2% ` [dpdk-dev] [PATCH v8 1/6] ring: add a pointer-width headtail structure Gage Eads
@ 2019-03-19 1:20 2% ` Gage Eads
0 siblings, 0 replies; 200+ results
From: Gage Eads @ 2019-03-19 1:20 UTC (permalink / raw)
To: dev
Cc: olivier.matz, arybchenko, bruce.richardson, konstantin.ananyev,
stephen, jerinj, mczekaj, nd, Ola.Liljedahl, gage.eads
For 64-bit systems, at current CPU speeds, 64-bit head and tail indexes
will not wrap-around within the author's lifetime. This is important to
avoiding the ABA problem -- in which a thread mistakes reading the same
tail index in two accesses to mean that the ring was not modified in the
intervening time -- in the upcoming lock-free ring implementation. Using a
64-bit index makes the possibility of this occurring effectively zero. This
commit uses pointer-width indexes so the lock-free ring can support 32-bit
systems as well.
This commit places the new producer and consumer structures in the same
location in struct rte_ring as their 32-bit counterparts. Since the 32-bit
versions are padded out to a cache line, there is space for the new
structure without affecting the layout of struct rte_ring. Thus, the ABI is
preserved.
Signed-off-by: Gage Eads <gage.eads@intel.com>
---
lib/librte_ring/rte_ring.h | 21 +++++-
lib/librte_ring/rte_ring_c11_mem.h | 143 +++++++++++++++++++++++++++++++++++++
lib/librte_ring/rte_ring_generic.h | 130 +++++++++++++++++++++++++++++++++
3 files changed, 291 insertions(+), 3 deletions(-)
diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
index af5444a9f..c78db6916 100644
--- a/lib/librte_ring/rte_ring.h
+++ b/lib/librte_ring/rte_ring.h
@@ -1,6 +1,6 @@
/* SPDX-License-Identifier: BSD-3-Clause
*
- * Copyright (c) 2010-2017 Intel Corporation
+ * Copyright (c) 2010-2019 Intel Corporation
* Copyright (c) 2007-2009 Kip Macy kmacy@freebsd.org
* All rights reserved.
* Derived from FreeBSD's bufring.h
@@ -70,6 +70,13 @@ struct rte_ring_headtail {
uint32_t single; /**< True if single prod/cons */
};
+/* Structure to hold a pair of pointer-sized head/tail values and metadata */
+struct rte_ring_headtail_ptr {
+ volatile uintptr_t head; /**< Prod/consumer head. */
+ volatile uintptr_t tail; /**< Prod/consumer tail. */
+ uint32_t single; /**< True if single prod/cons */
+};
+
/**
* An RTE ring structure.
*
@@ -97,11 +104,19 @@ struct rte_ring {
char pad0 __rte_cache_aligned; /**< empty cache line */
/** Ring producer status. */
- struct rte_ring_headtail prod __rte_cache_aligned;
+ RTE_STD_C11
+ union {
+ struct rte_ring_headtail prod __rte_cache_aligned;
+ struct rte_ring_headtail_ptr prod_ptr __rte_cache_aligned;
+ };
char pad1 __rte_cache_aligned; /**< empty cache line */
/** Ring consumer status. */
- struct rte_ring_headtail cons __rte_cache_aligned;
+ RTE_STD_C11
+ union {
+ struct rte_ring_headtail cons __rte_cache_aligned;
+ struct rte_ring_headtail_ptr cons_ptr __rte_cache_aligned;
+ };
char pad2 __rte_cache_aligned; /**< empty cache line */
};
diff --git a/lib/librte_ring/rte_ring_c11_mem.h b/lib/librte_ring/rte_ring_c11_mem.h
index 0fb73a337..545caf257 100644
--- a/lib/librte_ring/rte_ring_c11_mem.h
+++ b/lib/librte_ring/rte_ring_c11_mem.h
@@ -178,4 +178,147 @@ __rte_ring_move_cons_head(struct rte_ring *r, int is_sc,
return n;
}
+/**
+ * @internal This function updates the producer head for enqueue using
+ * pointer-sized head/tail values.
+ *
+ * @param r
+ * A pointer to the ring structure
+ * @param is_sp
+ * Indicates whether multi-producer path is needed or not
+ * @param n
+ * The number of elements we will want to enqueue, i.e. how far should the
+ * head be moved
+ * @param behavior
+ * RTE_RING_QUEUE_FIXED: Enqueue a fixed number of items from a ring
+ * RTE_RING_QUEUE_VARIABLE: Enqueue as many items as possible from ring
+ * @param old_head
+ * Returns head value as it was before the move, i.e. where enqueue starts
+ * @param new_head
+ * Returns the current/new head value i.e. where enqueue finishes
+ * @param free_entries
+ * Returns the amount of free space in the ring BEFORE head was moved
+ * @return
+ * Actual number of objects enqueued.
+ * If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
+ */
+static __rte_always_inline unsigned int
+__rte_ring_move_prod_head_ptr(struct rte_ring *r, unsigned int is_sp,
+ unsigned int n, enum rte_ring_queue_behavior behavior,
+ uintptr_t *old_head, uintptr_t *new_head,
+ uint32_t *free_entries)
+{
+ const uint32_t capacity = r->capacity;
+ uintptr_t cons_tail;
+ unsigned int max = n;
+ int success;
+
+ *old_head = __atomic_load_n(&r->prod_ptr.head, __ATOMIC_RELAXED);
+ do {
+ /* Reset n to the initial burst count */
+ n = max;
+
+ /* Ensure the head is read before tail */
+ __atomic_thread_fence(__ATOMIC_ACQUIRE);
+
+ /* load-acquire synchronize with store-release of ht->tail
+ * in update_tail.
+ */
+ cons_tail = __atomic_load_n(&r->cons_ptr.tail,
+ __ATOMIC_ACQUIRE);
+
+ *free_entries = (capacity + cons_tail - *old_head);
+
+ /* check that we have enough room in ring */
+ if (unlikely(n > *free_entries))
+ n = (behavior == RTE_RING_QUEUE_FIXED) ?
+ 0 : *free_entries;
+
+ if (n == 0)
+ return 0;
+
+ *new_head = *old_head + n;
+ if (is_sp)
+ r->prod_ptr.head = *new_head, success = 1;
+ else
+ /* on failure, *old_head is updated */
+ success = __atomic_compare_exchange_n(&r->prod_ptr.head,
+ old_head, *new_head,
+ 0, __ATOMIC_RELAXED,
+ __ATOMIC_RELAXED);
+ } while (unlikely(success == 0));
+ return n;
+}
+
+/**
+ * @internal This function updates the consumer head for dequeue using
+ * pointer-sized head/tail values.
+ *
+ * @param r
+ * A pointer to the ring structure
+ * @param is_sc
+ * Indicates whether multi-consumer path is needed or not
+ * @param n
+ * The number of elements we will want to enqueue, i.e. how far should the
+ * head be moved
+ * @param behavior
+ * RTE_RING_QUEUE_FIXED: Dequeue a fixed number of items from a ring
+ * RTE_RING_QUEUE_VARIABLE: Dequeue as many items as possible from ring
+ * @param old_head
+ * Returns head value as it was before the move, i.e. where dequeue starts
+ * @param new_head
+ * Returns the current/new head value i.e. where dequeue finishes
+ * @param entries
+ * Returns the number of entries in the ring BEFORE head was moved
+ * @return
+ * - Actual number of objects dequeued.
+ * If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
+ */
+static __rte_always_inline unsigned int
+__rte_ring_move_cons_head_ptr(struct rte_ring *r, unsigned int is_sc,
+ unsigned int n, enum rte_ring_queue_behavior behavior,
+ uintptr_t *old_head, uintptr_t *new_head,
+ uint32_t *entries)
+{
+ unsigned int max = n;
+ uintptr_t prod_tail;
+ int success;
+
+ /* move cons.head atomically */
+ *old_head = __atomic_load_n(&r->cons_ptr.head, __ATOMIC_RELAXED);
+ do {
+ /* Restore n as it may change every loop */
+ n = max;
+
+ /* Ensure the head is read before tail */
+ __atomic_thread_fence(__ATOMIC_ACQUIRE);
+
+ /* this load-acquire synchronize with store-release of ht->tail
+ * in update_tail.
+ */
+ prod_tail = __atomic_load_n(&r->prod_ptr.tail,
+ __ATOMIC_ACQUIRE);
+
+ *entries = (prod_tail - *old_head);
+
+ /* Set the actual entries for dequeue */
+ if (n > *entries)
+ n = (behavior == RTE_RING_QUEUE_FIXED) ? 0 : *entries;
+
+ if (unlikely(n == 0))
+ return 0;
+
+ *new_head = *old_head + n;
+ if (is_sc)
+ r->cons_ptr.head = *new_head, success = 1;
+ else
+ /* on failure, *old_head will be updated */
+ success = __atomic_compare_exchange_n(&r->cons_ptr.head,
+ old_head, *new_head,
+ 0, __ATOMIC_RELAXED,
+ __ATOMIC_RELAXED);
+ } while (unlikely(success == 0));
+ return n;
+}
+
#endif /* _RTE_RING_C11_MEM_H_ */
diff --git a/lib/librte_ring/rte_ring_generic.h b/lib/librte_ring/rte_ring_generic.h
index ea7dbe5b9..6a0e1bbfb 100644
--- a/lib/librte_ring/rte_ring_generic.h
+++ b/lib/librte_ring/rte_ring_generic.h
@@ -167,4 +167,134 @@ __rte_ring_move_cons_head(struct rte_ring *r, unsigned int is_sc,
return n;
}
+/**
+ * @internal This function updates the producer head for enqueue using
+ * pointer-sized head/tail values.
+ *
+ * @param r
+ * A pointer to the ring structure
+ * @param is_sp
+ * Indicates whether multi-producer path is needed or not
+ * @param n
+ * The number of elements we will want to enqueue, i.e. how far should the
+ * head be moved
+ * @param behavior
+ * RTE_RING_QUEUE_FIXED: Enqueue a fixed number of items from a ring
+ * RTE_RING_QUEUE_VARIABLE: Enqueue as many items as possible from ring
+ * @param old_head
+ * Returns head value as it was before the move, i.e. where enqueue starts
+ * @param new_head
+ * Returns the current/new head value i.e. where enqueue finishes
+ * @param free_entries
+ * Returns the amount of free space in the ring BEFORE head was moved
+ * @return
+ * Actual number of objects enqueued.
+ * If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
+ */
+static __rte_always_inline unsigned int
+__rte_ring_move_prod_head_ptr(struct rte_ring *r, unsigned int is_sp,
+ unsigned int n, enum rte_ring_queue_behavior behavior,
+ uintptr_t *old_head, uintptr_t *new_head,
+ uint32_t *free_entries)
+{
+ const uint32_t capacity = r->capacity;
+ unsigned int max = n;
+ int success;
+
+ do {
+ /* Reset n to the initial burst count */
+ n = max;
+
+ *old_head = r->prod_ptr.head;
+
+ /* add rmb barrier to avoid load/load reorder in weak
+ * memory model. It is noop on x86
+ */
+ rte_smp_rmb();
+
+ *free_entries = (capacity + r->cons_ptr.tail - *old_head);
+
+ /* check that we have enough room in ring */
+ if (unlikely(n > *free_entries))
+ n = (behavior == RTE_RING_QUEUE_FIXED) ?
+ 0 : *free_entries;
+
+ if (n == 0)
+ return 0;
+
+ *new_head = *old_head + n;
+ if (is_sp)
+ r->prod_ptr.head = *new_head, success = 1;
+ else
+ success = __sync_bool_compare_and_swap(
+ &r->prod_ptr.head,
+ *old_head, *new_head);
+ } while (unlikely(success == 0));
+ return n;
+}
+
+/**
+ * @internal This function updates the consumer head for dequeue using
+ * pointer-sized head/tail values.
+ *
+ * @param r
+ * A pointer to the ring structure
+ * @param is_sc
+ * Indicates whether multi-consumer path is needed or not
+ * @param n
+ * The number of elements we will want to enqueue, i.e. how far should the
+ * head be moved
+ * @param behavior
+ * RTE_RING_QUEUE_FIXED: Dequeue a fixed number of items from a ring
+ * RTE_RING_QUEUE_VARIABLE: Dequeue as many items as possible from ring
+ * @param old_head
+ * Returns head value as it was before the move, i.e. where dequeue starts
+ * @param new_head
+ * Returns the current/new head value i.e. where dequeue finishes
+ * @param entries
+ * Returns the number of entries in the ring BEFORE head was moved
+ * @return
+ * - Actual number of objects dequeued.
+ * If behavior == RTE_RING_QUEUE_FIXED, this will be 0 or n only.
+ */
+static __rte_always_inline unsigned int
+__rte_ring_move_cons_head_ptr(struct rte_ring *r, unsigned int is_sc,
+ unsigned int n, enum rte_ring_queue_behavior behavior,
+ uintptr_t *old_head, uintptr_t *new_head,
+ uint32_t *entries)
+{
+ unsigned int max = n;
+ int success;
+
+ do {
+ /* Restore n as it may change every loop */
+ n = max;
+
+ *old_head = r->cons_ptr.head;
+
+ /* add rmb barrier to avoid load/load reorder in weak
+ * memory model. It is noop on x86
+ */
+ rte_smp_rmb();
+
+ *entries = (r->prod_ptr.tail - *old_head);
+
+ /* Set the actual entries for dequeue */
+ if (n > *entries)
+ n = (behavior == RTE_RING_QUEUE_FIXED) ? 0 : *entries;
+
+ if (unlikely(n == 0))
+ return 0;
+
+ *new_head = *old_head + n;
+ if (is_sc)
+ r->cons_ptr.head = *new_head, success = 1;
+ else
+ success = __sync_bool_compare_and_swap(
+ &r->cons_ptr.head,
+ *old_head, *new_head);
+ } while (unlikely(success == 0));
+ return n;
+}
+
#endif /* _RTE_RING_GENERIC_H_ */
--
2.13.6
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v2 0/6] Introduce AF_XDP PMD
@ 2019-03-19 7:12 3% ` Xiaolong Ye
2019-03-19 7:12 3% ` Xiaolong Ye
2019-03-21 9:18 3% ` [dpdk-dev] [PATCH v3 0/5] " Xiaolong Ye
` (6 subsequent siblings)
8 siblings, 1 reply; 200+ results
From: Xiaolong Ye @ 2019-03-19 7:12 UTC (permalink / raw)
To: dev; +Cc: Qi Zhang, Karlsson Magnus, Topel Bjorn, Xiaolong Ye
Overview
========
This patchset adds a new PMD driver for AF_XDP which is a proposed
faster version of AF_PACKET interface in Linux, see below links [1] [2] for
details of AF_XDP introduction:
AF_XDP roadmap
==============
- AF_XDP is included in upstream kernel since 4.18, and AF_XDP support
in libbpf has been merged in v5.1-rc1.
- Now i40e and ixgbe drivers have supported zero copy mode.
Change logs
===========
V2:
- Fix a NULL pointer reference crash issue
- Fix txonly stop sending traffic in zc mode
- Refactor rte_mbuf.c to avoid ABI breakage.
- Fix multiple style issues pointed by Ferruh, David, Stephen, Luca.
changes vs RFC sent by Qi last Aug:
- Re-work base on AF_XDP's interface changes since the new libbpf has
provided higher-level APIs that hide many of the details of the AP_XDP
uapi. After the rework, it helps to reduce 300+ lines of code.
- multi-queues is not supported due to current libbpf doesn't support
multi-sockets on a single umem.
- No extra steps to load xdp program manually, since the current behavior of
libbpf would load a default xdp program when user calls xsk_socket__create.
userspace application only needs to handle the cleanup.
How to try
==========
1. take the kernel >= v5.1-rc1, build kernel and replace your host
kernel with it.
make sure you turn on XDP sockets when compiling
Networking support -->
Networking options -->
[ * ] XDP sockets
2. build libbpf in tools/lib/bpf, and copy the libbpf.a and libbpf.so to /usr/lib64
cd tools/lib/bpf
make
3. ethtool -L enp59s0f0 combined 1
4. start testpmd
./build/app/testpmd -c 0xc -n 4 --vdev eth_af_xdp,iface=enp59s0f0,queue=0 -- -i --rxq=1 --txq=1
in this case, default xdp program will be loaded and linked to queue 0 of enp59s0f0,
network traffics travel to queue 0 will be redirected to af_xdp socket.
[1] https://lwn.net/Articles/750845/
[2] https://fosdem.org/2018/schedule/event/af_xdp/
Xiaolong Ye (6):
net/af_xdp: introduce AF XDP PMD driver
lib/mbuf: introduce helper to create mempool with flags
lib/mempool: allow page size aligned mempool
net/af_xdp: use mbuf mempool for buffer management
net/af_xdp: enable zero copy
app/testpmd: add mempool flags parameter
MAINTAINERS | 6 +
app/test-pmd/parameters.c | 12 +
app/test-pmd/testpmd.c | 17 +-
app/test-pmd/testpmd.h | 1 +
config/common_base | 5 +
config/common_linux | 1 +
doc/guides/nics/af_xdp.rst | 45 +
doc/guides/nics/features/af_xdp.ini | 11 +
doc/guides/nics/index.rst | 1 +
doc/guides/rel_notes/release_19_05.rst | 7 +
doc/guides/testpmd_app_ug/run_app.rst | 4 +
drivers/net/Makefile | 1 +
drivers/net/af_xdp/Makefile | 33 +
drivers/net/af_xdp/meson.build | 21 +
drivers/net/af_xdp/rte_eth_af_xdp.c | 1013 +++++++++++++++++
drivers/net/af_xdp/rte_pmd_af_xdp_version.map | 3 +
drivers/net/meson.build | 1 +
lib/librte_mbuf/rte_mbuf.c | 29 +-
lib/librte_mbuf/rte_mbuf.h | 45 +
lib/librte_mempool/rte_mempool.c | 3 +
lib/librte_mempool/rte_mempool.h | 1 +
mk/rte.app.mk | 1 +
22 files changed, 1249 insertions(+), 12 deletions(-)
create mode 100644 doc/guides/nics/af_xdp.rst
create mode 100644 doc/guides/nics/features/af_xdp.ini
create mode 100644 drivers/net/af_xdp/Makefile
create mode 100644 drivers/net/af_xdp/meson.build
create mode 100644 drivers/net/af_xdp/rte_eth_af_xdp.c
create mode 100644 drivers/net/af_xdp/rte_pmd_af_xdp_version.map
--
2.17.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v2 0/6] Introduce AF_XDP PMD
2019-03-19 7:12 3% ` [dpdk-dev] [PATCH v2 0/6] Introduce AF_XDP PMD Xiaolong Ye
@ 2019-03-19 7:12 3% ` Xiaolong Ye
0 siblings, 0 replies; 200+ results
From: Xiaolong Ye @ 2019-03-19 7:12 UTC (permalink / raw)
To: dev; +Cc: Qi Zhang, Karlsson Magnus, Topel Bjorn, Xiaolong Ye
Overview
========
This patchset adds a new PMD driver for AF_XDP which is a proposed
faster version of AF_PACKET interface in Linux, see below links [1] [2] for
details of AF_XDP introduction:
AF_XDP roadmap
==============
- AF_XDP is included in upstream kernel since 4.18, and AF_XDP support
in libbpf has been merged in v5.1-rc1.
- Now i40e and ixgbe drivers have supported zero copy mode.
Change logs
===========
V2:
- Fix a NULL pointer reference crash issue
- Fix txonly stop sending traffic in zc mode
- Refactor rte_mbuf.c to avoid ABI breakage.
- Fix multiple style issues pointed by Ferruh, David, Stephen, Luca.
changes vs RFC sent by Qi last Aug:
- Re-work base on AF_XDP's interface changes since the new libbpf has
provided higher-level APIs that hide many of the details of the AP_XDP
uapi. After the rework, it helps to reduce 300+ lines of code.
- multi-queues is not supported due to current libbpf doesn't support
multi-sockets on a single umem.
- No extra steps to load xdp program manually, since the current behavior of
libbpf would load a default xdp program when user calls xsk_socket__create.
userspace application only needs to handle the cleanup.
How to try
==========
1. take the kernel >= v5.1-rc1, build kernel and replace your host
kernel with it.
make sure you turn on XDP sockets when compiling
Networking support -->
Networking options -->
[ * ] XDP sockets
2. build libbpf in tools/lib/bpf, and copy the libbpf.a and libbpf.so to /usr/lib64
cd tools/lib/bpf
make
3. ethtool -L enp59s0f0 combined 1
4. start testpmd
./build/app/testpmd -c 0xc -n 4 --vdev eth_af_xdp,iface=enp59s0f0,queue=0 -- -i --rxq=1 --txq=1
in this case, default xdp program will be loaded and linked to queue 0 of enp59s0f0,
network traffics travel to queue 0 will be redirected to af_xdp socket.
[1] https://lwn.net/Articles/750845/
[2] https://fosdem.org/2018/schedule/event/af_xdp/
Xiaolong Ye (6):
net/af_xdp: introduce AF XDP PMD driver
lib/mbuf: introduce helper to create mempool with flags
lib/mempool: allow page size aligned mempool
net/af_xdp: use mbuf mempool for buffer management
net/af_xdp: enable zero copy
app/testpmd: add mempool flags parameter
MAINTAINERS | 6 +
app/test-pmd/parameters.c | 12 +
app/test-pmd/testpmd.c | 17 +-
app/test-pmd/testpmd.h | 1 +
config/common_base | 5 +
config/common_linux | 1 +
doc/guides/nics/af_xdp.rst | 45 +
doc/guides/nics/features/af_xdp.ini | 11 +
doc/guides/nics/index.rst | 1 +
doc/guides/rel_notes/release_19_05.rst | 7 +
doc/guides/testpmd_app_ug/run_app.rst | 4 +
drivers/net/Makefile | 1 +
drivers/net/af_xdp/Makefile | 33 +
drivers/net/af_xdp/meson.build | 21 +
drivers/net/af_xdp/rte_eth_af_xdp.c | 1013 +++++++++++++++++
drivers/net/af_xdp/rte_pmd_af_xdp_version.map | 3 +
drivers/net/meson.build | 1 +
lib/librte_mbuf/rte_mbuf.c | 29 +-
lib/librte_mbuf/rte_mbuf.h | 45 +
lib/librte_mempool/rte_mempool.c | 3 +
lib/librte_mempool/rte_mempool.h | 1 +
mk/rte.app.mk | 1 +
22 files changed, 1249 insertions(+), 12 deletions(-)
create mode 100644 doc/guides/nics/af_xdp.rst
create mode 100644 doc/guides/nics/features/af_xdp.ini
create mode 100644 drivers/net/af_xdp/Makefile
create mode 100644 drivers/net/af_xdp/meson.build
create mode 100644 drivers/net/af_xdp/rte_eth_af_xdp.c
create mode 100644 drivers/net/af_xdp/rte_pmd_af_xdp_version.map
--
2.17.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] cryptodev: fix restore crypto op alignment and layout
2019-03-07 14:13 8% [dpdk-dev] [PATCH] cryptodev: fix restore crypto op alignment and layout Konstantin Ananyev
2019-03-08 12:59 0% ` Trahe, Fiona
2019-03-12 12:04 0% ` Shally Verma
@ 2019-03-19 13:33 3% ` Akhil Goyal
2019-03-19 13:33 3% ` Akhil Goyal
2019-03-19 14:00 0% ` Akhil Goyal
2 siblings, 2 replies; 200+ results
From: Akhil Goyal @ 2019-03-19 13:33 UTC (permalink / raw)
To: Konstantin Ananyev, dev; +Cc: umesh.kartha, pablo.de.lara.guarch, shally.verma
Hi Konstantin,
On 3/7/2019 7:43 PM, Konstantin Ananyev wrote:
> in 18.08 new cache-aligned structure rte_crypto_asym_op was introduced.
> As it also was included into rte_crypto_op, it caused implicit change
> in rte_crypto_op layout and alignment: now rte_crypto_op is cahce-line
> aligned has a hole of 40/104 bytes between phys_addr and sym/asym op.
> It looks like unintended ABI breakage, plus such change can cause
> negative performance effects:
> - now status and sym[0].m_src lies on different cache-lines, so
> post-process code would need extra cache-line read.
> - new alignment causes grow of the space requirements and cache-line
> reads/updates for structures that contain rte_crypto_op inside.
> As there seems no actual need to have rte_crypto_asym_op cache-line
> aligned, and rte_crypto_asym_op is not intended to be used on it's own -
> the simplest fix is just to remove cache-line alignment for it.
> As the immediate positive effect: on IA ipsec-secgw performance increased
> by 5-10% (depending on the crypto-dev and algo used).
> My guess that on machines with 128B cache-line and lookaside-protocol
> capable crypto devices the impact will be even more noticeable.
>
> Fixes: 26008aaed14c ("cryptodev: add asymmetric xform and op definitions")
>
> Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> ---
> doc/guides/rel_notes/release_19_05.rst | 7 +++++++
> lib/librte_cryptodev/Makefile | 2 +-
> lib/librte_cryptodev/meson.build | 2 +-
> lib/librte_cryptodev/rte_crypto_asym.h | 2 +-
> 4 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
> index c0390ca16..ec2651b65 100644
> --- a/doc/guides/rel_notes/release_19_05.rst
> +++ b/doc/guides/rel_notes/release_19_05.rst
> @@ -116,6 +116,13 @@ ABI Changes
> Also, make sure to start the actual text at the margin.
> =========================================================
>
> +* cryptodev: in 18.08 new structure ``rte_crypto_asym_op`` was introduced and
> + included into ``rte_crypto_op``. As ``rte_crypto_asym_op`` structure was
> + defined as cache-line aligned that caused unintended changes in
> + ``rte_crypto_op`` structure layout and alignment. Remove cache-line
> + alignment for ``rte_crypto_asym_op`` to restore expected ``rte_crypto_op``
> + layout and alignment.
> +
>
ABI version should be bumped in the release notes as well. I will update
that while merging.
Apart from that
Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
> Shared Library Versions
> -----------------------
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] cryptodev: fix restore crypto op alignment and layout
2019-03-19 13:33 3% ` Akhil Goyal
@ 2019-03-19 13:33 3% ` Akhil Goyal
2019-03-19 14:00 0% ` Akhil Goyal
1 sibling, 0 replies; 200+ results
From: Akhil Goyal @ 2019-03-19 13:33 UTC (permalink / raw)
To: Konstantin Ananyev, dev; +Cc: umesh.kartha, pablo.de.lara.guarch, shally.verma
Hi Konstantin,
On 3/7/2019 7:43 PM, Konstantin Ananyev wrote:
> in 18.08 new cache-aligned structure rte_crypto_asym_op was introduced.
> As it also was included into rte_crypto_op, it caused implicit change
> in rte_crypto_op layout and alignment: now rte_crypto_op is cahce-line
> aligned has a hole of 40/104 bytes between phys_addr and sym/asym op.
> It looks like unintended ABI breakage, plus such change can cause
> negative performance effects:
> - now status and sym[0].m_src lies on different cache-lines, so
> post-process code would need extra cache-line read.
> - new alignment causes grow of the space requirements and cache-line
> reads/updates for structures that contain rte_crypto_op inside.
> As there seems no actual need to have rte_crypto_asym_op cache-line
> aligned, and rte_crypto_asym_op is not intended to be used on it's own -
> the simplest fix is just to remove cache-line alignment for it.
> As the immediate positive effect: on IA ipsec-secgw performance increased
> by 5-10% (depending on the crypto-dev and algo used).
> My guess that on machines with 128B cache-line and lookaside-protocol
> capable crypto devices the impact will be even more noticeable.
>
> Fixes: 26008aaed14c ("cryptodev: add asymmetric xform and op definitions")
>
> Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> ---
> doc/guides/rel_notes/release_19_05.rst | 7 +++++++
> lib/librte_cryptodev/Makefile | 2 +-
> lib/librte_cryptodev/meson.build | 2 +-
> lib/librte_cryptodev/rte_crypto_asym.h | 2 +-
> 4 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
> index c0390ca16..ec2651b65 100644
> --- a/doc/guides/rel_notes/release_19_05.rst
> +++ b/doc/guides/rel_notes/release_19_05.rst
> @@ -116,6 +116,13 @@ ABI Changes
> Also, make sure to start the actual text at the margin.
> =========================================================
>
> +* cryptodev: in 18.08 new structure ``rte_crypto_asym_op`` was introduced and
> + included into ``rte_crypto_op``. As ``rte_crypto_asym_op`` structure was
> + defined as cache-line aligned that caused unintended changes in
> + ``rte_crypto_op`` structure layout and alignment. Remove cache-line
> + alignment for ``rte_crypto_asym_op`` to restore expected ``rte_crypto_op``
> + layout and alignment.
> +
>
ABI version should be bumped in the release notes as well. I will update
that while merging.
Apart from that
Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
> Shared Library Versions
> -----------------------
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v4 1/5] eal: add VXLAN-GPE macro
@ 2019-03-19 13:50 4% ` David Marchand
2019-03-19 13:50 4% ` David Marchand
2019-03-19 16:34 0% ` Ferruh Yigit
0 siblings, 2 replies; 200+ results
From: David Marchand @ 2019-03-19 13:50 UTC (permalink / raw)
To: Qiming Yang, Thomas Monjalon, Yigit, Ferruh, Andrew Rybchenko
Cc: dev, Qi Zhang
eal: in the title ? we are in ethdev.
On Tue, Mar 19, 2019 at 10:14 AM Qiming Yang <qiming.yang@intel.com> wrote:
> This patch added VXLAN-GPE macro in rte_eth_tunnel_type.
>
> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
> ---
> lib/librte_ethdev/rte_eth_ctrl.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/lib/librte_ethdev/rte_eth_ctrl.h
> b/lib/librte_ethdev/rte_eth_ctrl.h
> index 5ea8ae2..b341634 100644
> --- a/lib/librte_ethdev/rte_eth_ctrl.h
> +++ b/lib/librte_ethdev/rte_eth_ctrl.h
> @@ -229,6 +229,7 @@ enum rte_eth_tunnel_type {
> RTE_TUNNEL_TYPE_NVGRE,
> RTE_TUNNEL_TYPE_IP_IN_GRE,
> RTE_L2_TUNNEL_TYPE_E_TAG,
> + RTE_TUNNEL_TYPE_VXLAN_GPE,
> RTE_TUNNEL_TYPE_MAX,
> };
>
Comments on this patch:
- is this the normal process to get an ethdev api update go through
dpdk-next-net-intel without an ethdev maintainer acking?
- does this patch introduce an api/abi breakage? (validate-abi.sh did not
complain, to my surprise)
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v4 1/5] eal: add VXLAN-GPE macro
2019-03-19 13:50 4% ` David Marchand
@ 2019-03-19 13:50 4% ` David Marchand
2019-03-19 16:34 0% ` Ferruh Yigit
1 sibling, 0 replies; 200+ results
From: David Marchand @ 2019-03-19 13:50 UTC (permalink / raw)
To: Qiming Yang, Thomas Monjalon, Yigit, Ferruh, Andrew Rybchenko
Cc: dev, Qi Zhang
eal: in the title ? we are in ethdev.
On Tue, Mar 19, 2019 at 10:14 AM Qiming Yang <qiming.yang@intel.com> wrote:
> This patch added VXLAN-GPE macro in rte_eth_tunnel_type.
>
> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
> ---
> lib/librte_ethdev/rte_eth_ctrl.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/lib/librte_ethdev/rte_eth_ctrl.h
> b/lib/librte_ethdev/rte_eth_ctrl.h
> index 5ea8ae2..b341634 100644
> --- a/lib/librte_ethdev/rte_eth_ctrl.h
> +++ b/lib/librte_ethdev/rte_eth_ctrl.h
> @@ -229,6 +229,7 @@ enum rte_eth_tunnel_type {
> RTE_TUNNEL_TYPE_NVGRE,
> RTE_TUNNEL_TYPE_IP_IN_GRE,
> RTE_L2_TUNNEL_TYPE_E_TAG,
> + RTE_TUNNEL_TYPE_VXLAN_GPE,
> RTE_TUNNEL_TYPE_MAX,
> };
>
Comments on this patch:
- is this the normal process to get an ethdev api update go through
dpdk-next-net-intel without an ethdev maintainer acking?
- does this patch introduce an api/abi breakage? (validate-abi.sh did not
complain, to my surprise)
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] cryptodev: fix restore crypto op alignment and layout
2019-03-19 13:33 3% ` Akhil Goyal
2019-03-19 13:33 3% ` Akhil Goyal
@ 2019-03-19 14:00 0% ` Akhil Goyal
2019-03-19 14:00 0% ` Akhil Goyal
1 sibling, 1 reply; 200+ results
From: Akhil Goyal @ 2019-03-19 14:00 UTC (permalink / raw)
To: Konstantin Ananyev, dev; +Cc: umesh.kartha, pablo.de.lara.guarch, shally.verma
On 3/19/2019 7:03 PM, Akhil Goyal wrote:
> Hi Konstantin,
>
> On 3/7/2019 7:43 PM, Konstantin Ananyev wrote:
>> in 18.08 new cache-aligned structure rte_crypto_asym_op was introduced.
>> As it also was included into rte_crypto_op, it caused implicit change
>> in rte_crypto_op layout and alignment: now rte_crypto_op is cahce-line
>> aligned has a hole of 40/104 bytes between phys_addr and sym/asym op.
>> It looks like unintended ABI breakage, plus such change can cause
>> negative performance effects:
>> - now status and sym[0].m_src lies on different cache-lines, so
>> post-process code would need extra cache-line read.
>> - new alignment causes grow of the space requirements and cache-line
>> reads/updates for structures that contain rte_crypto_op inside.
>> As there seems no actual need to have rte_crypto_asym_op cache-line
>> aligned, and rte_crypto_asym_op is not intended to be used on it's own -
>> the simplest fix is just to remove cache-line alignment for it.
>> As the immediate positive effect: on IA ipsec-secgw performance increased
>> by 5-10% (depending on the crypto-dev and algo used).
>> My guess that on machines with 128B cache-line and lookaside-protocol
>> capable crypto devices the impact will be even more noticeable.
>>
>> Fixes: 26008aaed14c ("cryptodev: add asymmetric xform and op definitions")
>>
>> Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
>> ---
>> doc/guides/rel_notes/release_19_05.rst | 7 +++++++
>> lib/librte_cryptodev/Makefile | 2 +-
>> lib/librte_cryptodev/meson.build | 2 +-
>> lib/librte_cryptodev/rte_crypto_asym.h | 2 +-
>> 4 files changed, 10 insertions(+), 3 deletions(-)
>>
>> diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
>> index c0390ca16..ec2651b65 100644
>> --- a/doc/guides/rel_notes/release_19_05.rst
>> +++ b/doc/guides/rel_notes/release_19_05.rst
>> @@ -116,6 +116,13 @@ ABI Changes
>> Also, make sure to start the actual text at the margin.
>> =========================================================
>>
>> +* cryptodev: in 18.08 new structure ``rte_crypto_asym_op`` was introduced and
>> + included into ``rte_crypto_op``. As ``rte_crypto_asym_op`` structure was
>> + defined as cache-line aligned that caused unintended changes in
>> + ``rte_crypto_op`` structure layout and alignment. Remove cache-line
>> + alignment for ``rte_crypto_asym_op`` to restore expected ``rte_crypto_op``
>> + layout and alignment.
>> +
>>
> ABI version should be bumped in the release notes as well. I will update
> that while merging.
> Apart from that
> Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
>> Shared Library Versions
>> -----------------------
>>
Applied to dpdk-next-crypto
Thanks.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] cryptodev: fix restore crypto op alignment and layout
2019-03-19 14:00 0% ` Akhil Goyal
@ 2019-03-19 14:00 0% ` Akhil Goyal
0 siblings, 0 replies; 200+ results
From: Akhil Goyal @ 2019-03-19 14:00 UTC (permalink / raw)
To: Konstantin Ananyev, dev; +Cc: umesh.kartha, pablo.de.lara.guarch, shally.verma
On 3/19/2019 7:03 PM, Akhil Goyal wrote:
> Hi Konstantin,
>
> On 3/7/2019 7:43 PM, Konstantin Ananyev wrote:
>> in 18.08 new cache-aligned structure rte_crypto_asym_op was introduced.
>> As it also was included into rte_crypto_op, it caused implicit change
>> in rte_crypto_op layout and alignment: now rte_crypto_op is cahce-line
>> aligned has a hole of 40/104 bytes between phys_addr and sym/asym op.
>> It looks like unintended ABI breakage, plus such change can cause
>> negative performance effects:
>> - now status and sym[0].m_src lies on different cache-lines, so
>> post-process code would need extra cache-line read.
>> - new alignment causes grow of the space requirements and cache-line
>> reads/updates for structures that contain rte_crypto_op inside.
>> As there seems no actual need to have rte_crypto_asym_op cache-line
>> aligned, and rte_crypto_asym_op is not intended to be used on it's own -
>> the simplest fix is just to remove cache-line alignment for it.
>> As the immediate positive effect: on IA ipsec-secgw performance increased
>> by 5-10% (depending on the crypto-dev and algo used).
>> My guess that on machines with 128B cache-line and lookaside-protocol
>> capable crypto devices the impact will be even more noticeable.
>>
>> Fixes: 26008aaed14c ("cryptodev: add asymmetric xform and op definitions")
>>
>> Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
>> ---
>> doc/guides/rel_notes/release_19_05.rst | 7 +++++++
>> lib/librte_cryptodev/Makefile | 2 +-
>> lib/librte_cryptodev/meson.build | 2 +-
>> lib/librte_cryptodev/rte_crypto_asym.h | 2 +-
>> 4 files changed, 10 insertions(+), 3 deletions(-)
>>
>> diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
>> index c0390ca16..ec2651b65 100644
>> --- a/doc/guides/rel_notes/release_19_05.rst
>> +++ b/doc/guides/rel_notes/release_19_05.rst
>> @@ -116,6 +116,13 @@ ABI Changes
>> Also, make sure to start the actual text at the margin.
>> =========================================================
>>
>> +* cryptodev: in 18.08 new structure ``rte_crypto_asym_op`` was introduced and
>> + included into ``rte_crypto_op``. As ``rte_crypto_asym_op`` structure was
>> + defined as cache-line aligned that caused unintended changes in
>> + ``rte_crypto_op`` structure layout and alignment. Remove cache-line
>> + alignment for ``rte_crypto_asym_op`` to restore expected ``rte_crypto_op``
>> + layout and alignment.
>> +
>>
> ABI version should be bumped in the release notes as well. I will update
> that while merging.
> Apart from that
> Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
>> Shared Library Versions
>> -----------------------
>>
Applied to dpdk-next-crypto
Thanks.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH] doc: fix abi check script examples
@ 2019-03-19 14:05 29% David Marchand
2019-03-19 14:05 29% ` David Marchand
2019-03-19 17:19 4% ` Neil Horman
0 siblings, 2 replies; 200+ results
From: David Marchand @ 2019-03-19 14:05 UTC (permalink / raw)
To: dev; +Cc: stable, Olivier Matz, Neil Horman
The doc examples are not aligned on the script following the
incriminated commit.
Fixes: c4a5fe3bf832 ("devtools: rework ABI checker script")
Cc: stable@dpdk.org
Cc: Olivier Matz <olivier.matz@6wind.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
doc/guides/contributing/versioning.rst | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index e7b326b..98b8de3 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -548,26 +548,29 @@ utilities which can be installed via a package manager. For example::
The syntax of the ``validate-abi.sh`` utility is::
- ./devtools/validate-abi.sh <REV1> <REV2> <TARGET>
+ ./devtools/validate-abi.sh <REV1> <REV2>
Where ``REV1`` and ``REV2`` are valid gitrevisions(7)
https://www.kernel.org/pub/software/scm/git/docs/gitrevisions.html
-on the local repo and target is the usual DPDK compilation target.
+on the local repo.
For example::
# Check between the previous and latest commit:
- ./devtools/validate-abi.sh HEAD~1 HEAD x86_64-native-linux-gcc
+ ./devtools/validate-abi.sh HEAD~1 HEAD
+
+ # Check on a specific compilation target:
+ ./devtools/validate-abi.sh -t x86_64-native-linux-gcc HEAD~1 HEAD
# Check between two tags:
- ./devtools/validate-abi.sh v2.0.0 v2.1.0 x86_64-native-linux-gcc
+ ./devtools/validate-abi.sh v2.0.0 v2.1.0
# Check between git master and local topic-branch "vhost-hacking":
- ./devtools/validate-abi.sh master vhost-hacking x86_64-native-linux-gcc
+ ./devtools/validate-abi.sh master vhost-hacking
After the validation script completes (it can take a while since it need to
compile both tags) it will create compatibility reports in the
-``./compat_report`` directory. Listed incompatibilities can be found as
-follows::
+``./abi-check/compat_report`` directory. Listed incompatibilities can be found
+as follows::
- grep -lr Incompatible compat_reports/
+ grep -lr Incompatible abi-check/compat_reports/
--
1.8.3.1
^ permalink raw reply [relevance 29%]
* [dpdk-dev] [PATCH] doc: fix abi check script examples
2019-03-19 14:05 29% [dpdk-dev] [PATCH] doc: fix abi check script examples David Marchand
@ 2019-03-19 14:05 29% ` David Marchand
2019-03-19 17:19 4% ` Neil Horman
1 sibling, 0 replies; 200+ results
From: David Marchand @ 2019-03-19 14:05 UTC (permalink / raw)
To: dev; +Cc: stable, Olivier Matz, Neil Horman
The doc examples are not aligned on the script following the
incriminated commit.
Fixes: c4a5fe3bf832 ("devtools: rework ABI checker script")
Cc: stable@dpdk.org
Cc: Olivier Matz <olivier.matz@6wind.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
doc/guides/contributing/versioning.rst | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index e7b326b..98b8de3 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -548,26 +548,29 @@ utilities which can be installed via a package manager. For example::
The syntax of the ``validate-abi.sh`` utility is::
- ./devtools/validate-abi.sh <REV1> <REV2> <TARGET>
+ ./devtools/validate-abi.sh <REV1> <REV2>
Where ``REV1`` and ``REV2`` are valid gitrevisions(7)
https://www.kernel.org/pub/software/scm/git/docs/gitrevisions.html
-on the local repo and target is the usual DPDK compilation target.
+on the local repo.
For example::
# Check between the previous and latest commit:
- ./devtools/validate-abi.sh HEAD~1 HEAD x86_64-native-linux-gcc
+ ./devtools/validate-abi.sh HEAD~1 HEAD
+
+ # Check on a specific compilation target:
+ ./devtools/validate-abi.sh -t x86_64-native-linux-gcc HEAD~1 HEAD
# Check between two tags:
- ./devtools/validate-abi.sh v2.0.0 v2.1.0 x86_64-native-linux-gcc
+ ./devtools/validate-abi.sh v2.0.0 v2.1.0
# Check between git master and local topic-branch "vhost-hacking":
- ./devtools/validate-abi.sh master vhost-hacking x86_64-native-linux-gcc
+ ./devtools/validate-abi.sh master vhost-hacking
After the validation script completes (it can take a while since it need to
compile both tags) it will create compatibility reports in the
-``./compat_report`` directory. Listed incompatibilities can be found as
-follows::
+``./abi-check/compat_report`` directory. Listed incompatibilities can be found
+as follows::
- grep -lr Incompatible compat_reports/
+ grep -lr Incompatible abi-check/compat_reports/
--
1.8.3.1
^ permalink raw reply [relevance 29%]
* Re: [dpdk-dev] [PATCH v7 0/6] Add lock-free ring and mempool handler
@ 2019-03-19 15:51 3% ` Stephen Hemminger
2019-03-19 15:51 3% ` Stephen Hemminger
2019-04-01 19:23 0% ` Eads, Gage
0 siblings, 2 replies; 200+ results
From: Stephen Hemminger @ 2019-03-19 15:51 UTC (permalink / raw)
To: Eads, Gage
Cc: dev, olivier.matz, arybchenko, Richardson, Bruce, Ananyev,
Konstantin, jerinj, mczekaj, nd, Ola.Liljedahl
On Mon, 18 Mar 2019 21:49:44 +0000
"Eads, Gage" <gage.eads@intel.com> wrote:
> Hi all,
>
> Friendly reminder that in order to get this feature into 19.08 (assuming folks also want that :)), the API deprecation notice needs to be merged into 19.05.
>
> Thanks,
> Gage
Given the recent API/ABI stability discussion, this is the kind of patch that really
needs to be examined and justified.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v7 0/6] Add lock-free ring and mempool handler
2019-03-19 15:51 3% ` Stephen Hemminger
@ 2019-03-19 15:51 3% ` Stephen Hemminger
2019-04-01 19:23 0% ` Eads, Gage
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-03-19 15:51 UTC (permalink / raw)
To: Eads, Gage
Cc: dev, olivier.matz, arybchenko, Richardson, Bruce, Ananyev,
Konstantin, jerinj, mczekaj, nd, Ola.Liljedahl
On Mon, 18 Mar 2019 21:49:44 +0000
"Eads, Gage" <gage.eads@intel.com> wrote:
> Hi all,
>
> Friendly reminder that in order to get this feature into 19.08 (assuming folks also want that :)), the API deprecation notice needs to be merged into 19.05.
>
> Thanks,
> Gage
Given the recent API/ABI stability discussion, this is the kind of patch that really
needs to be examined and justified.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v1 1/6] ethdev: add min/max MTU to device info
2019-02-27 21:45 13% ` [dpdk-dev] [PATCH v1 1/6] " Ian Stokes
@ 2019-03-19 16:15 0% ` Ferruh Yigit
2019-03-19 16:15 0% ` Ferruh Yigit
2019-03-21 12:50 0% ` Ian Stokes
0 siblings, 2 replies; 200+ results
From: Ferruh Yigit @ 2019-03-19 16:15 UTC (permalink / raw)
To: Ian Stokes, dev; +Cc: stephen
On 2/27/2019 9:45 PM, Ian Stokes wrote:
> From: Stephen Hemminger <stephen@networkplumber.org>
>
> This addresses the usability issue raised by OVS at DPDK Userspace
> summit. It adds general min/max mtu into device info. For compatiablity,
> and to save space, it fits in a hole in existing structure.
>
> The initial version sets max mtu to normal Ethernet, it is up to
> PMD to set larger value if it supports Jumbo frames.
>
> Also remove the deprecation notice introduced in 18.11 regarding this
> change and bump ethdev ABI version.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> Signed-off-by: Ian Stokes <ian.stokes@intel.com>
> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
> @@ -2524,6 +2524,8 @@ rte_eth_dev_info_get(uint16_t port_id, struct rte_eth_dev_info *dev_info)
> dev_info->rx_desc_lim = lim;
> dev_info->tx_desc_lim = lim;
> dev_info->device = dev->device;
> + dev_info->min_mtu = ETHER_MIN_MTU;
> + dev_info->max_mtu = UINT16_MAX;
Not only mtu but do you think should we document in 'rte_eth_dev_info_get()'
doxygen documentation, the default values that API sets?
>
> RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get);
> (*dev->dev_ops->dev_infos_get)(dev, dev_info);
> @@ -2587,12 +2589,17 @@ int
> rte_eth_dev_set_mtu(uint16_t port_id, uint16_t mtu)
> {
> int ret;
> + struct rte_eth_dev_info dev_info;
> struct rte_eth_dev *dev;
>
> RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> dev = &rte_eth_devices[port_id];
> RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->mtu_set, -ENOTSUP);
>
> + rte_eth_dev_info_get(port_id, &dev_info);
If we rely on 'rte_eth_dev_info_get()', we should add a check if "dev_infos_get"
is supported before calling it, like [1]. Unfortunately 'rte_eth_dev_info_get()'
return type is 'void', so we can't know if the struct has valid values or not
otherwise.
Or perhaps if port doesn't support "dev_infos_get", we can skip the mtu check
instead of returning error.
[1]
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_infos_get, -ENOTSUP);
> + if (mtu < dev_info.min_mtu || mtu > dev_info.max_mtu)
> + return -EINVAL;
> +
Should we document this behavior change in the function comment in header file?
Update when -EINVAL returned, etc..
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v1 1/6] ethdev: add min/max MTU to device info
2019-03-19 16:15 0% ` Ferruh Yigit
@ 2019-03-19 16:15 0% ` Ferruh Yigit
2019-03-21 12:50 0% ` Ian Stokes
1 sibling, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-03-19 16:15 UTC (permalink / raw)
To: Ian Stokes, dev; +Cc: stephen
On 2/27/2019 9:45 PM, Ian Stokes wrote:
> From: Stephen Hemminger <stephen@networkplumber.org>
>
> This addresses the usability issue raised by OVS at DPDK Userspace
> summit. It adds general min/max mtu into device info. For compatiablity,
> and to save space, it fits in a hole in existing structure.
>
> The initial version sets max mtu to normal Ethernet, it is up to
> PMD to set larger value if it supports Jumbo frames.
>
> Also remove the deprecation notice introduced in 18.11 regarding this
> change and bump ethdev ABI version.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> Signed-off-by: Ian Stokes <ian.stokes@intel.com>
> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
> @@ -2524,6 +2524,8 @@ rte_eth_dev_info_get(uint16_t port_id, struct rte_eth_dev_info *dev_info)
> dev_info->rx_desc_lim = lim;
> dev_info->tx_desc_lim = lim;
> dev_info->device = dev->device;
> + dev_info->min_mtu = ETHER_MIN_MTU;
> + dev_info->max_mtu = UINT16_MAX;
Not only mtu but do you think should we document in 'rte_eth_dev_info_get()'
doxygen documentation, the default values that API sets?
>
> RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get);
> (*dev->dev_ops->dev_infos_get)(dev, dev_info);
> @@ -2587,12 +2589,17 @@ int
> rte_eth_dev_set_mtu(uint16_t port_id, uint16_t mtu)
> {
> int ret;
> + struct rte_eth_dev_info dev_info;
> struct rte_eth_dev *dev;
>
> RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> dev = &rte_eth_devices[port_id];
> RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->mtu_set, -ENOTSUP);
>
> + rte_eth_dev_info_get(port_id, &dev_info);
If we rely on 'rte_eth_dev_info_get()', we should add a check if "dev_infos_get"
is supported before calling it, like [1]. Unfortunately 'rte_eth_dev_info_get()'
return type is 'void', so we can't know if the struct has valid values or not
otherwise.
Or perhaps if port doesn't support "dev_infos_get", we can skip the mtu check
instead of returning error.
[1]
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_infos_get, -ENOTSUP);
> + if (mtu < dev_info.min_mtu || mtu > dev_info.max_mtu)
> + return -EINVAL;
> +
Should we document this behavior change in the function comment in header file?
Update when -EINVAL returned, etc..
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 1/5] eal: add VXLAN-GPE macro
2019-03-19 13:50 4% ` David Marchand
2019-03-19 13:50 4% ` David Marchand
@ 2019-03-19 16:34 0% ` Ferruh Yigit
2019-03-19 16:34 0% ` Ferruh Yigit
1 sibling, 1 reply; 200+ results
From: Ferruh Yigit @ 2019-03-19 16:34 UTC (permalink / raw)
To: David Marchand, Qiming Yang, Thomas Monjalon, Andrew Rybchenko
Cc: dev, Qi Zhang
On 3/19/2019 1:50 PM, David Marchand wrote:
> eal: in the title ? we are in ethdev.
>
> On Tue, Mar 19, 2019 at 10:14 AM Qiming Yang <qiming.yang@intel.com> wrote:
>
>> This patch added VXLAN-GPE macro in rte_eth_tunnel_type.
>>
>> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
>> ---
>> lib/librte_ethdev/rte_eth_ctrl.h | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/lib/librte_ethdev/rte_eth_ctrl.h
>> b/lib/librte_ethdev/rte_eth_ctrl.h
>> index 5ea8ae2..b341634 100644
>> --- a/lib/librte_ethdev/rte_eth_ctrl.h
>> +++ b/lib/librte_ethdev/rte_eth_ctrl.h
>> @@ -229,6 +229,7 @@ enum rte_eth_tunnel_type {
>> RTE_TUNNEL_TYPE_NVGRE,
>> RTE_TUNNEL_TYPE_IP_IN_GRE,
>> RTE_L2_TUNNEL_TYPE_E_TAG,
>> + RTE_TUNNEL_TYPE_VXLAN_GPE,
>> RTE_TUNNEL_TYPE_MAX,
>> };
>>
>
>
> Comments on this patch:
> - is this the normal process to get an ethdev api update go through
> dpdk-next-net-intel without an ethdev maintainer acking?
No.
Vendor sub-trees are for the driver only changes.
> - does this patch introduce an api/abi breakage? (validate-abi.sh did not
> complain, to my surprise)
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 1/5] eal: add VXLAN-GPE macro
2019-03-19 16:34 0% ` Ferruh Yigit
@ 2019-03-19 16:34 0% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-03-19 16:34 UTC (permalink / raw)
To: David Marchand, Qiming Yang, Thomas Monjalon, Andrew Rybchenko
Cc: dev, Qi Zhang
On 3/19/2019 1:50 PM, David Marchand wrote:
> eal: in the title ? we are in ethdev.
>
> On Tue, Mar 19, 2019 at 10:14 AM Qiming Yang <qiming.yang@intel.com> wrote:
>
>> This patch added VXLAN-GPE macro in rte_eth_tunnel_type.
>>
>> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
>> ---
>> lib/librte_ethdev/rte_eth_ctrl.h | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/lib/librte_ethdev/rte_eth_ctrl.h
>> b/lib/librte_ethdev/rte_eth_ctrl.h
>> index 5ea8ae2..b341634 100644
>> --- a/lib/librte_ethdev/rte_eth_ctrl.h
>> +++ b/lib/librte_ethdev/rte_eth_ctrl.h
>> @@ -229,6 +229,7 @@ enum rte_eth_tunnel_type {
>> RTE_TUNNEL_TYPE_NVGRE,
>> RTE_TUNNEL_TYPE_IP_IN_GRE,
>> RTE_L2_TUNNEL_TYPE_E_TAG,
>> + RTE_TUNNEL_TYPE_VXLAN_GPE,
>> RTE_TUNNEL_TYPE_MAX,
>> };
>>
>
>
> Comments on this patch:
> - is this the normal process to get an ethdev api update go through
> dpdk-next-net-intel without an ethdev maintainer acking?
No.
Vendor sub-trees are for the driver only changes.
> - does this patch introduce an api/abi breakage? (validate-abi.sh did not
> complain, to my surprise)
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC PATCH 1/2] ethdev: introduce internal rxq/txq stats API
@ 2019-03-19 17:18 4% ` Ferruh Yigit
2019-03-19 17:18 4% ` Ferruh Yigit
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Ferruh Yigit @ 2019-03-19 17:18 UTC (permalink / raw)
To: David Marchand, dev; +Cc: thomas, arybchenko, Stokes, Ian, Stephen Hemminger
On 3/14/2019 3:13 PM, David Marchand wrote:
> Introduce a new api to retrieve per queue statistics from the drivers.
> The api objectives:
> - easily add some common per queue statistics and have it exposed
> through the user xstats api while the user stats api is left untouched
> - remove the limitations on the per queue statistics count (inherited
> from ixgbe) and avoid recurrent bugs on stats array overflow
The patch is adding two new dev_ops 'rxq_stats_get' & 'txq_stats_get', my
concern is if it is overkill to have three dev_ops to get stats
and I am feeling that is making xstat code more complex.
Would it be simpler to add 'q_ierrors' & 'q_oerrors' to 'struct rte_eth_stats'?
And perhaps we can do the 'fix rxq q_errors' patchset [1] after this change, so
fix can be done with less changes, although it will push the fix into next
release because of the ABI break.
OR ethdev will be broken this release, because of max_mtu, since ABI is already
broken perhaps we can squeeze this in.
Overall I would like to get more comment on this, Andrew, Thomas?
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
<...>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [RFC PATCH 1/2] ethdev: introduce internal rxq/txq stats API
2019-03-19 17:18 4% ` Ferruh Yigit
@ 2019-03-19 17:18 4% ` Ferruh Yigit
2019-03-19 17:54 3% ` Stephen Hemminger
2019-03-26 9:29 0% ` David Marchand
2 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-03-19 17:18 UTC (permalink / raw)
To: David Marchand, dev; +Cc: thomas, arybchenko, Stokes, Ian, Stephen Hemminger
On 3/14/2019 3:13 PM, David Marchand wrote:
> Introduce a new api to retrieve per queue statistics from the drivers.
> The api objectives:
> - easily add some common per queue statistics and have it exposed
> through the user xstats api while the user stats api is left untouched
> - remove the limitations on the per queue statistics count (inherited
> from ixgbe) and avoid recurrent bugs on stats array overflow
The patch is adding two new dev_ops 'rxq_stats_get' & 'txq_stats_get', my
concern is if it is overkill to have three dev_ops to get stats
and I am feeling that is making xstat code more complex.
Would it be simpler to add 'q_ierrors' & 'q_oerrors' to 'struct rte_eth_stats'?
And perhaps we can do the 'fix rxq q_errors' patchset [1] after this change, so
fix can be done with less changes, although it will push the fix into next
release because of the ABI break.
OR ethdev will be broken this release, because of max_mtu, since ABI is already
broken perhaps we can squeeze this in.
Overall I would like to get more comment on this, Andrew, Thomas?
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
<...>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: fix abi check script examples
2019-03-19 14:05 29% [dpdk-dev] [PATCH] doc: fix abi check script examples David Marchand
2019-03-19 14:05 29% ` David Marchand
@ 2019-03-19 17:19 4% ` Neil Horman
2019-03-19 17:19 4% ` Neil Horman
1 sibling, 1 reply; 200+ results
From: Neil Horman @ 2019-03-19 17:19 UTC (permalink / raw)
To: David Marchand; +Cc: dev, stable, Olivier Matz
On Tue, Mar 19, 2019 at 03:05:18PM +0100, David Marchand wrote:
> The doc examples are not aligned on the script following the
> incriminated commit.
>
> Fixes: c4a5fe3bf832 ("devtools: rework ABI checker script")
> Cc: stable@dpdk.org
>
> Cc: Olivier Matz <olivier.matz@6wind.com>
> Cc: Neil Horman <nhorman@tuxdriver.com>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
> doc/guides/contributing/versioning.rst | 19 +++++++++++--------
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
> index e7b326b..98b8de3 100644
> --- a/doc/guides/contributing/versioning.rst
> +++ b/doc/guides/contributing/versioning.rst
> @@ -548,26 +548,29 @@ utilities which can be installed via a package manager. For example::
>
> The syntax of the ``validate-abi.sh`` utility is::
>
> - ./devtools/validate-abi.sh <REV1> <REV2> <TARGET>
> + ./devtools/validate-abi.sh <REV1> <REV2>
>
> Where ``REV1`` and ``REV2`` are valid gitrevisions(7)
> https://www.kernel.org/pub/software/scm/git/docs/gitrevisions.html
> -on the local repo and target is the usual DPDK compilation target.
> +on the local repo.
>
> For example::
>
> # Check between the previous and latest commit:
> - ./devtools/validate-abi.sh HEAD~1 HEAD x86_64-native-linux-gcc
> + ./devtools/validate-abi.sh HEAD~1 HEAD
> +
> + # Check on a specific compilation target:
> + ./devtools/validate-abi.sh -t x86_64-native-linux-gcc HEAD~1 HEAD
>
> # Check between two tags:
> - ./devtools/validate-abi.sh v2.0.0 v2.1.0 x86_64-native-linux-gcc
> + ./devtools/validate-abi.sh v2.0.0 v2.1.0
>
> # Check between git master and local topic-branch "vhost-hacking":
> - ./devtools/validate-abi.sh master vhost-hacking x86_64-native-linux-gcc
> + ./devtools/validate-abi.sh master vhost-hacking
>
> After the validation script completes (it can take a while since it need to
> compile both tags) it will create compatibility reports in the
> -``./compat_report`` directory. Listed incompatibilities can be found as
> -follows::
> +``./abi-check/compat_report`` directory. Listed incompatibilities can be found
> +as follows::
>
> - grep -lr Incompatible compat_reports/
> + grep -lr Incompatible abi-check/compat_reports/
> --
> 1.8.3.1
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: fix abi check script examples
2019-03-19 17:19 4% ` Neil Horman
@ 2019-03-19 17:19 4% ` Neil Horman
0 siblings, 0 replies; 200+ results
From: Neil Horman @ 2019-03-19 17:19 UTC (permalink / raw)
To: David Marchand; +Cc: dev, stable, Olivier Matz
On Tue, Mar 19, 2019 at 03:05:18PM +0100, David Marchand wrote:
> The doc examples are not aligned on the script following the
> incriminated commit.
>
> Fixes: c4a5fe3bf832 ("devtools: rework ABI checker script")
> Cc: stable@dpdk.org
>
> Cc: Olivier Matz <olivier.matz@6wind.com>
> Cc: Neil Horman <nhorman@tuxdriver.com>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
> doc/guides/contributing/versioning.rst | 19 +++++++++++--------
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
> index e7b326b..98b8de3 100644
> --- a/doc/guides/contributing/versioning.rst
> +++ b/doc/guides/contributing/versioning.rst
> @@ -548,26 +548,29 @@ utilities which can be installed via a package manager. For example::
>
> The syntax of the ``validate-abi.sh`` utility is::
>
> - ./devtools/validate-abi.sh <REV1> <REV2> <TARGET>
> + ./devtools/validate-abi.sh <REV1> <REV2>
>
> Where ``REV1`` and ``REV2`` are valid gitrevisions(7)
> https://www.kernel.org/pub/software/scm/git/docs/gitrevisions.html
> -on the local repo and target is the usual DPDK compilation target.
> +on the local repo.
>
> For example::
>
> # Check between the previous and latest commit:
> - ./devtools/validate-abi.sh HEAD~1 HEAD x86_64-native-linux-gcc
> + ./devtools/validate-abi.sh HEAD~1 HEAD
> +
> + # Check on a specific compilation target:
> + ./devtools/validate-abi.sh -t x86_64-native-linux-gcc HEAD~1 HEAD
>
> # Check between two tags:
> - ./devtools/validate-abi.sh v2.0.0 v2.1.0 x86_64-native-linux-gcc
> + ./devtools/validate-abi.sh v2.0.0 v2.1.0
>
> # Check between git master and local topic-branch "vhost-hacking":
> - ./devtools/validate-abi.sh master vhost-hacking x86_64-native-linux-gcc
> + ./devtools/validate-abi.sh master vhost-hacking
>
> After the validation script completes (it can take a while since it need to
> compile both tags) it will create compatibility reports in the
> -``./compat_report`` directory. Listed incompatibilities can be found as
> -follows::
> +``./abi-check/compat_report`` directory. Listed incompatibilities can be found
> +as follows::
>
> - grep -lr Incompatible compat_reports/
> + grep -lr Incompatible abi-check/compat_reports/
> --
> 1.8.3.1
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [RFC PATCH 1/2] ethdev: introduce internal rxq/txq stats API
2019-03-19 17:18 4% ` Ferruh Yigit
2019-03-19 17:18 4% ` Ferruh Yigit
@ 2019-03-19 17:54 3% ` Stephen Hemminger
2019-03-19 17:54 3% ` Stephen Hemminger
2019-03-26 9:29 0% ` David Marchand
2 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-03-19 17:54 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: David Marchand, dev, thomas, arybchenko, Stokes, Ian
On Tue, 19 Mar 2019 17:18:08 +0000
Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> On 3/14/2019 3:13 PM, David Marchand wrote:
> > Introduce a new api to retrieve per queue statistics from the drivers.
> > The api objectives:
> > - easily add some common per queue statistics and have it exposed
> > through the user xstats api while the user stats api is left untouched
> > - remove the limitations on the per queue statistics count (inherited
> > from ixgbe) and avoid recurrent bugs on stats array overflow
>
> The patch is adding two new dev_ops 'rxq_stats_get' & 'txq_stats_get', my
> concern is if it is overkill to have three dev_ops to get stats
> and I am feeling that is making xstat code more complex.
>
> Would it be simpler to add 'q_ierrors' & 'q_oerrors' to 'struct rte_eth_stats'?
>
> And perhaps we can do the 'fix rxq q_errors' patchset [1] after this change, so
> fix can be done with less changes, although it will push the fix into next
> release because of the ABI break.
> OR ethdev will be broken this release, because of max_mtu, since ABI is already
> broken perhaps we can squeeze this in.
>
> Overall I would like to get more comment on this, Andrew, Thomas?
>
> >
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
>
> <...>
>
My preference would be:
1. Make all DPDK drivers consistent in usage of current statistic values.
2. Propose an enhancement to have new ethdev statistics match some pre-existing
standard like SNMP or other RFC.
3. Reduce custom (xstats) values by using #2. Leave it for driver specific stuff.
I.e: don't modify existing API at all, make a new one.
PS: ethdev is one of those structures that needs to get removed/hidden from
application headers. It should be possible to add/remove stuff from ethdev internals, device and bus
without breaking API/ABI.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC PATCH 1/2] ethdev: introduce internal rxq/txq stats API
2019-03-19 17:54 3% ` Stephen Hemminger
@ 2019-03-19 17:54 3% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-03-19 17:54 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: David Marchand, dev, thomas, arybchenko, Stokes, Ian
On Tue, 19 Mar 2019 17:18:08 +0000
Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> On 3/14/2019 3:13 PM, David Marchand wrote:
> > Introduce a new api to retrieve per queue statistics from the drivers.
> > The api objectives:
> > - easily add some common per queue statistics and have it exposed
> > through the user xstats api while the user stats api is left untouched
> > - remove the limitations on the per queue statistics count (inherited
> > from ixgbe) and avoid recurrent bugs on stats array overflow
>
> The patch is adding two new dev_ops 'rxq_stats_get' & 'txq_stats_get', my
> concern is if it is overkill to have three dev_ops to get stats
> and I am feeling that is making xstat code more complex.
>
> Would it be simpler to add 'q_ierrors' & 'q_oerrors' to 'struct rte_eth_stats'?
>
> And perhaps we can do the 'fix rxq q_errors' patchset [1] after this change, so
> fix can be done with less changes, although it will push the fix into next
> release because of the ABI break.
> OR ethdev will be broken this release, because of max_mtu, since ABI is already
> broken perhaps we can squeeze this in.
>
> Overall I would like to get more comment on this, Andrew, Thomas?
>
> >
> > Signed-off-by: David Marchand <david.marchand@redhat.com>
>
> <...>
>
My preference would be:
1. Make all DPDK drivers consistent in usage of current statistic values.
2. Propose an enhancement to have new ethdev statistics match some pre-existing
standard like SNMP or other RFC.
3. Reduce custom (xstats) values by using #2. Leave it for driver specific stuff.
I.e: don't modify existing API at all, make a new one.
PS: ethdev is one of those structures that needs to get removed/hidden from
application headers. It should be possible to add/remove stuff from ethdev internals, device and bus
without breaking API/ABI.
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v3 0/5] Introduce AF_XDP PMD
2019-03-19 7:12 3% ` [dpdk-dev] [PATCH v2 0/6] Introduce AF_XDP PMD Xiaolong Ye
@ 2019-03-21 9:18 3% ` Xiaolong Ye
2019-03-21 9:18 3% ` Xiaolong Ye
2019-03-22 13:01 3% ` [dpdk-dev] [PATCH v4 " Xiaolong Ye
` (5 subsequent siblings)
8 siblings, 1 reply; 200+ results
From: Xiaolong Ye @ 2019-03-21 9:18 UTC (permalink / raw)
To: dev; +Cc: Qi Zhang, Karlsson Magnus, Topel Bjorn, Xiaolong Ye
Overview
========
This patchset adds a new PMD driver for AF_XDP which is a proposed
faster version of AF_PACKET interface in Linux, see below links [1] [2] for
details of AF_XDP introduction:
AF_XDP roadmap
==============
- AF_XDP is included in upstream kernel since 4.18, and AF_XDP support
in libbpf has been merged in v5.1-rc1.
- Now i40e and ixgbe drivers have supported zero copy mode.
Change logs
===========
V3:
- Fix all style issues pointed by Stephen, Mattias, David.
- Drop the testpmd change as we'll adopt Jerin's suggestion to add a new
mempool driver to handle the application use of AF_XDP's zero copy feature.
V2:
- Fix a NULL pointer reference crash issue
- Fix txonly stop sending traffic in zc mode
- Refactor rte_mbuf.c to avoid ABI breakage.
- Fix multiple style issues pointed by Ferruh, David, Stephen, Luca.
changes vs RFC sent by Qi last Aug:
- Re-work base on AF_XDP's interface changes since the new libbpf has
provided higher-level APIs that hide many of the details of the AP_XDP
uapi. After the rework, it helps to reduce 300+ lines of code.
- multi-queues is not supported due to current libbpf doesn't support
multi-sockets on a single umem.
- No extra steps to load xdp program manually, since the current behavior of
libbpf would load a default xdp program when user calls xsk_socket__create.
userspace application only needs to handle the cleanup.
How to try
==========
1. take the kernel >= v5.1-rc1, build kernel and replace your host
kernel with it.
make sure you turn on XDP sockets when compiling
Networking support -->
Networking options -->
[ * ] XDP sockets
2. build libbpf in tools/lib/bpf, and copy the libbpf.a and libbpf.so to /usr/lib64
cd tools/lib/bpf
make
3. ethtool -L enp59s0f0 combined 1
4. start testpmd
./build/app/testpmd -c 0xc -n 4 --vdev eth_af_xdp,iface=enp59s0f0,queue=0 -- -i --rxq=1 --txq=1
in this case, default xdp program will be loaded and linked to queue 0 of enp59s0f0,
network traffics travel to queue 0 will be redirected to af_xdp socket.
Xiaolong Ye (5):
net/af_xdp: introduce AF XDP PMD driver
lib/mbuf: introduce helper to create mempool with flags
lib/mempool: allow page size aligned mempool
net/af_xdp: use mbuf mempool for buffer management
net/af_xdp: enable zero copy
MAINTAINERS | 6 +
config/common_base | 5 +
config/common_linux | 1 +
doc/guides/nics/af_xdp.rst | 45 +
doc/guides/nics/features/af_xdp.ini | 11 +
doc/guides/nics/index.rst | 1 +
doc/guides/rel_notes/release_19_05.rst | 7 +
drivers/net/Makefile | 1 +
drivers/net/af_xdp/Makefile | 32 +
drivers/net/af_xdp/meson.build | 21 +
drivers/net/af_xdp/rte_eth_af_xdp.c | 1018 +++++++++++++++++
drivers/net/af_xdp/rte_pmd_af_xdp_version.map | 3 +
drivers/net/meson.build | 1 +
lib/librte_mbuf/rte_mbuf.c | 29 +-
lib/librte_mbuf/rte_mbuf.h | 45 +
lib/librte_mempool/rte_mempool.c | 3 +
lib/librte_mempool/rte_mempool.h | 1 +
mk/rte.app.mk | 1 +
18 files changed, 1226 insertions(+), 5 deletions(-)
create mode 100644 doc/guides/nics/af_xdp.rst
create mode 100644 doc/guides/nics/features/af_xdp.ini
create mode 100644 drivers/net/af_xdp/Makefile
create mode 100644 drivers/net/af_xdp/meson.build
create mode 100644 drivers/net/af_xdp/rte_eth_af_xdp.c
create mode 100644 drivers/net/af_xdp/rte_pmd_af_xdp_version.map
--
2.17.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v3 0/5] Introduce AF_XDP PMD
2019-03-21 9:18 3% ` [dpdk-dev] [PATCH v3 0/5] " Xiaolong Ye
@ 2019-03-21 9:18 3% ` Xiaolong Ye
0 siblings, 0 replies; 200+ results
From: Xiaolong Ye @ 2019-03-21 9:18 UTC (permalink / raw)
To: dev; +Cc: Qi Zhang, Karlsson Magnus, Topel Bjorn, Xiaolong Ye
Overview
========
This patchset adds a new PMD driver for AF_XDP which is a proposed
faster version of AF_PACKET interface in Linux, see below links [1] [2] for
details of AF_XDP introduction:
AF_XDP roadmap
==============
- AF_XDP is included in upstream kernel since 4.18, and AF_XDP support
in libbpf has been merged in v5.1-rc1.
- Now i40e and ixgbe drivers have supported zero copy mode.
Change logs
===========
V3:
- Fix all style issues pointed by Stephen, Mattias, David.
- Drop the testpmd change as we'll adopt Jerin's suggestion to add a new
mempool driver to handle the application use of AF_XDP's zero copy feature.
V2:
- Fix a NULL pointer reference crash issue
- Fix txonly stop sending traffic in zc mode
- Refactor rte_mbuf.c to avoid ABI breakage.
- Fix multiple style issues pointed by Ferruh, David, Stephen, Luca.
changes vs RFC sent by Qi last Aug:
- Re-work base on AF_XDP's interface changes since the new libbpf has
provided higher-level APIs that hide many of the details of the AP_XDP
uapi. After the rework, it helps to reduce 300+ lines of code.
- multi-queues is not supported due to current libbpf doesn't support
multi-sockets on a single umem.
- No extra steps to load xdp program manually, since the current behavior of
libbpf would load a default xdp program when user calls xsk_socket__create.
userspace application only needs to handle the cleanup.
How to try
==========
1. take the kernel >= v5.1-rc1, build kernel and replace your host
kernel with it.
make sure you turn on XDP sockets when compiling
Networking support -->
Networking options -->
[ * ] XDP sockets
2. build libbpf in tools/lib/bpf, and copy the libbpf.a and libbpf.so to /usr/lib64
cd tools/lib/bpf
make
3. ethtool -L enp59s0f0 combined 1
4. start testpmd
./build/app/testpmd -c 0xc -n 4 --vdev eth_af_xdp,iface=enp59s0f0,queue=0 -- -i --rxq=1 --txq=1
in this case, default xdp program will be loaded and linked to queue 0 of enp59s0f0,
network traffics travel to queue 0 will be redirected to af_xdp socket.
Xiaolong Ye (5):
net/af_xdp: introduce AF XDP PMD driver
lib/mbuf: introduce helper to create mempool with flags
lib/mempool: allow page size aligned mempool
net/af_xdp: use mbuf mempool for buffer management
net/af_xdp: enable zero copy
MAINTAINERS | 6 +
config/common_base | 5 +
config/common_linux | 1 +
doc/guides/nics/af_xdp.rst | 45 +
doc/guides/nics/features/af_xdp.ini | 11 +
doc/guides/nics/index.rst | 1 +
doc/guides/rel_notes/release_19_05.rst | 7 +
drivers/net/Makefile | 1 +
drivers/net/af_xdp/Makefile | 32 +
drivers/net/af_xdp/meson.build | 21 +
drivers/net/af_xdp/rte_eth_af_xdp.c | 1018 +++++++++++++++++
drivers/net/af_xdp/rte_pmd_af_xdp_version.map | 3 +
drivers/net/meson.build | 1 +
lib/librte_mbuf/rte_mbuf.c | 29 +-
lib/librte_mbuf/rte_mbuf.h | 45 +
lib/librte_mempool/rte_mempool.c | 3 +
lib/librte_mempool/rte_mempool.h | 1 +
mk/rte.app.mk | 1 +
18 files changed, 1226 insertions(+), 5 deletions(-)
create mode 100644 doc/guides/nics/af_xdp.rst
create mode 100644 doc/guides/nics/features/af_xdp.ini
create mode 100644 drivers/net/af_xdp/Makefile
create mode 100644 drivers/net/af_xdp/meson.build
create mode 100644 drivers/net/af_xdp/rte_eth_af_xdp.c
create mode 100644 drivers/net/af_xdp/rte_pmd_af_xdp_version.map
--
2.17.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v1 1/6] ethdev: add min/max MTU to device info
2019-03-19 16:15 0% ` Ferruh Yigit
2019-03-19 16:15 0% ` Ferruh Yigit
@ 2019-03-21 12:50 0% ` Ian Stokes
2019-03-21 12:50 0% ` Ian Stokes
2019-03-21 14:06 0% ` Ferruh Yigit
1 sibling, 2 replies; 200+ results
From: Ian Stokes @ 2019-03-21 12:50 UTC (permalink / raw)
To: Ferruh Yigit, dev; +Cc: stephen
On 3/19/2019 4:15 PM, Ferruh Yigit wrote:
> On 2/27/2019 9:45 PM, Ian Stokes wrote:
>> From: Stephen Hemminger <stephen@networkplumber.org>
>>
>> This addresses the usability issue raised by OVS at DPDK Userspace
>> summit. It adds general min/max mtu into device info. For compatiablity,
>> and to save space, it fits in a hole in existing structure.
>>
>> The initial version sets max mtu to normal Ethernet, it is up to
>> PMD to set larger value if it supports Jumbo frames.
>>
>> Also remove the deprecation notice introduced in 18.11 regarding this
>> change and bump ethdev ABI version.
>>
>> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>> Signed-off-by: Ian Stokes <ian.stokes@intel.com>
>> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
>
>> @@ -2524,6 +2524,8 @@ rte_eth_dev_info_get(uint16_t port_id, struct rte_eth_dev_info *dev_info)
>> dev_info->rx_desc_lim = lim;
>> dev_info->tx_desc_lim = lim;
>> dev_info->device = dev->device;
>> + dev_info->min_mtu = ETHER_MIN_MTU;
>> + dev_info->max_mtu = UINT16_MAX;
>
> Not only mtu but do you think should we document in 'rte_eth_dev_info_get()'
> doxygen documentation, the default values that API sets?
>
Sure, that would be useful, I can include it in the v2 of this patch.
What would you document the values under? They are not @params and not
@return, is there a particular label/format that should be used for
values set within a function?
>>
>> RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get);
>> (*dev->dev_ops->dev_infos_get)(dev, dev_info);
>> @@ -2587,12 +2589,17 @@ int
>> rte_eth_dev_set_mtu(uint16_t port_id, uint16_t mtu)
>> {
>> int ret;
>> + struct rte_eth_dev_info dev_info;
>> struct rte_eth_dev *dev;
>>
>> RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
>> dev = &rte_eth_devices[port_id];
>> RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->mtu_set, -ENOTSUP);
>>
>> + rte_eth_dev_info_get(port_id, &dev_info);
>
> If we rely on 'rte_eth_dev_info_get()', we should add a check if "dev_infos_get"
> is supported before calling it, like [1]. Unfortunately 'rte_eth_dev_info_get()'
> return type is 'void', so we can't know if the struct has valid values or not
> otherwise.
> Or perhaps if port doesn't support "dev_infos_get", we can skip the mtu check
> instead of returning error.
>
Hmmm,good point, I assumed rte_eth_dev_info_get() would be implemented
for nearly all devices but again, only assumption, could be wrong.
I'd prefer to err on the side of caution, so for the moment we can skip
the check if dev infos is not available as you suggest. That way it
should still work non supported devices.
> [1]
> RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_infos_get, -ENOTSUP);
>
>> + if (mtu < dev_info.min_mtu || mtu > dev_info.max_mtu)
>> + return -EINVAL;
>> +
>
> Should we document this behavior change in the function comment in header file?
> Update when -EINVAL returned, etc..
Sure I can take care of that in the v2.
Ian
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v1 1/6] ethdev: add min/max MTU to device info
2019-03-21 12:50 0% ` Ian Stokes
@ 2019-03-21 12:50 0% ` Ian Stokes
2019-03-21 14:06 0% ` Ferruh Yigit
1 sibling, 0 replies; 200+ results
From: Ian Stokes @ 2019-03-21 12:50 UTC (permalink / raw)
To: Ferruh Yigit, dev; +Cc: stephen
On 3/19/2019 4:15 PM, Ferruh Yigit wrote:
> On 2/27/2019 9:45 PM, Ian Stokes wrote:
>> From: Stephen Hemminger <stephen@networkplumber.org>
>>
>> This addresses the usability issue raised by OVS at DPDK Userspace
>> summit. It adds general min/max mtu into device info. For compatiablity,
>> and to save space, it fits in a hole in existing structure.
>>
>> The initial version sets max mtu to normal Ethernet, it is up to
>> PMD to set larger value if it supports Jumbo frames.
>>
>> Also remove the deprecation notice introduced in 18.11 regarding this
>> change and bump ethdev ABI version.
>>
>> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>> Signed-off-by: Ian Stokes <ian.stokes@intel.com>
>> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
>
>> @@ -2524,6 +2524,8 @@ rte_eth_dev_info_get(uint16_t port_id, struct rte_eth_dev_info *dev_info)
>> dev_info->rx_desc_lim = lim;
>> dev_info->tx_desc_lim = lim;
>> dev_info->device = dev->device;
>> + dev_info->min_mtu = ETHER_MIN_MTU;
>> + dev_info->max_mtu = UINT16_MAX;
>
> Not only mtu but do you think should we document in 'rte_eth_dev_info_get()'
> doxygen documentation, the default values that API sets?
>
Sure, that would be useful, I can include it in the v2 of this patch.
What would you document the values under? They are not @params and not
@return, is there a particular label/format that should be used for
values set within a function?
>>
>> RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get);
>> (*dev->dev_ops->dev_infos_get)(dev, dev_info);
>> @@ -2587,12 +2589,17 @@ int
>> rte_eth_dev_set_mtu(uint16_t port_id, uint16_t mtu)
>> {
>> int ret;
>> + struct rte_eth_dev_info dev_info;
>> struct rte_eth_dev *dev;
>>
>> RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
>> dev = &rte_eth_devices[port_id];
>> RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->mtu_set, -ENOTSUP);
>>
>> + rte_eth_dev_info_get(port_id, &dev_info);
>
> If we rely on 'rte_eth_dev_info_get()', we should add a check if "dev_infos_get"
> is supported before calling it, like [1]. Unfortunately 'rte_eth_dev_info_get()'
> return type is 'void', so we can't know if the struct has valid values or not
> otherwise.
> Or perhaps if port doesn't support "dev_infos_get", we can skip the mtu check
> instead of returning error.
>
Hmmm,good point, I assumed rte_eth_dev_info_get() would be implemented
for nearly all devices but again, only assumption, could be wrong.
I'd prefer to err on the side of caution, so for the moment we can skip
the check if dev infos is not available as you suggest. That way it
should still work non supported devices.
> [1]
> RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_infos_get, -ENOTSUP);
>
>> + if (mtu < dev_info.min_mtu || mtu > dev_info.max_mtu)
>> + return -EINVAL;
>> +
>
> Should we document this behavior change in the function comment in header file?
> Update when -EINVAL returned, etc..
Sure I can take care of that in the v2.
Ian
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v1 1/6] ethdev: add min/max MTU to device info
2019-03-21 12:50 0% ` Ian Stokes
2019-03-21 12:50 0% ` Ian Stokes
@ 2019-03-21 14:06 0% ` Ferruh Yigit
2019-03-21 14:06 0% ` Ferruh Yigit
2019-03-21 14:59 0% ` Ian Stokes
1 sibling, 2 replies; 200+ results
From: Ferruh Yigit @ 2019-03-21 14:06 UTC (permalink / raw)
To: Ian Stokes, dev; +Cc: stephen
On 3/21/2019 12:50 PM, Ian Stokes wrote:
> On 3/19/2019 4:15 PM, Ferruh Yigit wrote:
>> On 2/27/2019 9:45 PM, Ian Stokes wrote:
>>> From: Stephen Hemminger <stephen@networkplumber.org>
>>>
>>> This addresses the usability issue raised by OVS at DPDK Userspace
>>> summit. It adds general min/max mtu into device info. For compatiablity,
>>> and to save space, it fits in a hole in existing structure.
>>>
>>> The initial version sets max mtu to normal Ethernet, it is up to
>>> PMD to set larger value if it supports Jumbo frames.
>>>
>>> Also remove the deprecation notice introduced in 18.11 regarding this
>>> change and bump ethdev ABI version.
>>>
>>> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>>> Signed-off-by: Ian Stokes <ian.stokes@intel.com>
>>> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
>>
>>> @@ -2524,6 +2524,8 @@ rte_eth_dev_info_get(uint16_t port_id, struct rte_eth_dev_info *dev_info)
>>> dev_info->rx_desc_lim = lim;
>>> dev_info->tx_desc_lim = lim;
>>> dev_info->device = dev->device;
>>> + dev_info->min_mtu = ETHER_MIN_MTU;
>>> + dev_info->max_mtu = UINT16_MAX;
>>
>> Not only mtu but do you think should we document in 'rte_eth_dev_info_get()'
>> doxygen documentation, the default values that API sets?
>>
>
> Sure, that would be useful, I can include it in the v2 of this patch.
> What would you document the values under? They are not @params and not
> @return, is there a particular label/format that should be used for
> values set within a function?
In the description paragraph of the function perhaps? I am not aware of a label
for this.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v1 1/6] ethdev: add min/max MTU to device info
2019-03-21 14:06 0% ` Ferruh Yigit
@ 2019-03-21 14:06 0% ` Ferruh Yigit
2019-03-21 14:59 0% ` Ian Stokes
1 sibling, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-03-21 14:06 UTC (permalink / raw)
To: Ian Stokes, dev; +Cc: stephen
On 3/21/2019 12:50 PM, Ian Stokes wrote:
> On 3/19/2019 4:15 PM, Ferruh Yigit wrote:
>> On 2/27/2019 9:45 PM, Ian Stokes wrote:
>>> From: Stephen Hemminger <stephen@networkplumber.org>
>>>
>>> This addresses the usability issue raised by OVS at DPDK Userspace
>>> summit. It adds general min/max mtu into device info. For compatiablity,
>>> and to save space, it fits in a hole in existing structure.
>>>
>>> The initial version sets max mtu to normal Ethernet, it is up to
>>> PMD to set larger value if it supports Jumbo frames.
>>>
>>> Also remove the deprecation notice introduced in 18.11 regarding this
>>> change and bump ethdev ABI version.
>>>
>>> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>>> Signed-off-by: Ian Stokes <ian.stokes@intel.com>
>>> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
>>
>>> @@ -2524,6 +2524,8 @@ rte_eth_dev_info_get(uint16_t port_id, struct rte_eth_dev_info *dev_info)
>>> dev_info->rx_desc_lim = lim;
>>> dev_info->tx_desc_lim = lim;
>>> dev_info->device = dev->device;
>>> + dev_info->min_mtu = ETHER_MIN_MTU;
>>> + dev_info->max_mtu = UINT16_MAX;
>>
>> Not only mtu but do you think should we document in 'rte_eth_dev_info_get()'
>> doxygen documentation, the default values that API sets?
>>
>
> Sure, that would be useful, I can include it in the v2 of this patch.
> What would you document the values under? They are not @params and not
> @return, is there a particular label/format that should be used for
> values set within a function?
In the description paragraph of the function perhaps? I am not aware of a label
for this.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v1 1/6] ethdev: add min/max MTU to device info
2019-03-21 14:06 0% ` Ferruh Yigit
2019-03-21 14:06 0% ` Ferruh Yigit
@ 2019-03-21 14:59 0% ` Ian Stokes
2019-03-21 14:59 0% ` Ian Stokes
1 sibling, 1 reply; 200+ results
From: Ian Stokes @ 2019-03-21 14:59 UTC (permalink / raw)
To: Ferruh Yigit, dev; +Cc: stephen
On 3/21/2019 2:06 PM, Ferruh Yigit wrote:
> On 3/21/2019 12:50 PM, Ian Stokes wrote:
>> On 3/19/2019 4:15 PM, Ferruh Yigit wrote:
>>> On 2/27/2019 9:45 PM, Ian Stokes wrote:
>>>> From: Stephen Hemminger <stephen@networkplumber.org>
>>>>
>>>> This addresses the usability issue raised by OVS at DPDK Userspace
>>>> summit. It adds general min/max mtu into device info. For compatiablity,
>>>> and to save space, it fits in a hole in existing structure.
>>>>
>>>> The initial version sets max mtu to normal Ethernet, it is up to
>>>> PMD to set larger value if it supports Jumbo frames.
>>>>
>>>> Also remove the deprecation notice introduced in 18.11 regarding this
>>>> change and bump ethdev ABI version.
>>>>
>>>> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>>>> Signed-off-by: Ian Stokes <ian.stokes@intel.com>
>>>> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
>>>
>>>> @@ -2524,6 +2524,8 @@ rte_eth_dev_info_get(uint16_t port_id, struct rte_eth_dev_info *dev_info)
>>>> dev_info->rx_desc_lim = lim;
>>>> dev_info->tx_desc_lim = lim;
>>>> dev_info->device = dev->device;
>>>> + dev_info->min_mtu = ETHER_MIN_MTU;
>>>> + dev_info->max_mtu = UINT16_MAX;
>>>
>>> Not only mtu but do you think should we document in 'rte_eth_dev_info_get()'
>>> doxygen documentation, the default values that API sets?
>>>
>>
>> Sure, that would be useful, I can include it in the v2 of this patch.
>> What would you document the values under? They are not @params and not
>> @return, is there a particular label/format that should be used for
>> values set within a function?
>
> In the description paragraph of the function perhaps? I am not aware of a label
> for this.
>
Perfect, thanks for the clarification.
Ian
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v1 1/6] ethdev: add min/max MTU to device info
2019-03-21 14:59 0% ` Ian Stokes
@ 2019-03-21 14:59 0% ` Ian Stokes
0 siblings, 0 replies; 200+ results
From: Ian Stokes @ 2019-03-21 14:59 UTC (permalink / raw)
To: Ferruh Yigit, dev; +Cc: stephen
On 3/21/2019 2:06 PM, Ferruh Yigit wrote:
> On 3/21/2019 12:50 PM, Ian Stokes wrote:
>> On 3/19/2019 4:15 PM, Ferruh Yigit wrote:
>>> On 2/27/2019 9:45 PM, Ian Stokes wrote:
>>>> From: Stephen Hemminger <stephen@networkplumber.org>
>>>>
>>>> This addresses the usability issue raised by OVS at DPDK Userspace
>>>> summit. It adds general min/max mtu into device info. For compatiablity,
>>>> and to save space, it fits in a hole in existing structure.
>>>>
>>>> The initial version sets max mtu to normal Ethernet, it is up to
>>>> PMD to set larger value if it supports Jumbo frames.
>>>>
>>>> Also remove the deprecation notice introduced in 18.11 regarding this
>>>> change and bump ethdev ABI version.
>>>>
>>>> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>>>> Signed-off-by: Ian Stokes <ian.stokes@intel.com>
>>>> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
>>>
>>>> @@ -2524,6 +2524,8 @@ rte_eth_dev_info_get(uint16_t port_id, struct rte_eth_dev_info *dev_info)
>>>> dev_info->rx_desc_lim = lim;
>>>> dev_info->tx_desc_lim = lim;
>>>> dev_info->device = dev->device;
>>>> + dev_info->min_mtu = ETHER_MIN_MTU;
>>>> + dev_info->max_mtu = UINT16_MAX;
>>>
>>> Not only mtu but do you think should we document in 'rte_eth_dev_info_get()'
>>> doxygen documentation, the default values that API sets?
>>>
>>
>> Sure, that would be useful, I can include it in the v2 of this patch.
>> What would you document the values under? They are not @params and not
>> @return, is there a particular label/format that should be used for
>> values set within a function?
>
> In the description paragraph of the function perhaps? I am not aware of a label
> for this.
>
Perfect, thanks for the clarification.
Ian
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v2 1/7] ethdev: add min/max MTU to device info
@ 2019-03-22 13:01 12% ` Ian Stokes
2019-03-22 13:01 12% ` Ian Stokes
2019-03-25 14:26 0% ` Ferruh Yigit
2019-03-29 17:52 11% ` [dpdk-dev] [PATCH v3 " Ferruh Yigit
1 sibling, 2 replies; 200+ results
From: Ian Stokes @ 2019-03-22 13:01 UTC (permalink / raw)
To: dev; +Cc: stephen, Ian Stokes
From: Stephen Hemminger <stephen@networkplumber.org>
This addresses the usability issue raised by OVS at DPDK Userspace
summit. It adds general min/max mtu into device info. For compatiablity,
and to save space, it fits in a hole in existing structure.
The initial version sets max mtu to normal Ethernet, it is up to
PMD to set larger value if it supports Jumbo frames.
Also remove the deprecation notice introduced in 18.11 regarding this
change and bump ethdev ABI version.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Ian Stokes <ian.stokes@intel.com>
Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
---
v1 -> v2
* Document default values set in rte_eth_dev_info_get() in doxygen
documentation.
* Document causes of EINVAL returns for rte_eth_dev_set_mtu() in doxygen
documentation.
* Check if dev_infos_get is supported before validating mtu values in
rte_eth_dev_mtu_set. If unsupported skip validation step.
RFC -> v1
* Removed RFC status.
* dev_info->max_mtu set to UINT16_MAX initially instead of ETHER_MTU to
avoid breaking jumbo frame support. ETHER_MTU to be re-introduced
when all PMD drivers modified to support min/max mtu support.
* Bump ethdev ABI version.
* Added ACK from Andrew Rybchenko.
---
doc/guides/rel_notes/deprecation.rst | 12 ------------
doc/guides/rel_notes/release_19_05.rst | 8 +++++++-
lib/librte_ethdev/Makefile | 2 +-
lib/librte_ethdev/meson.build | 2 +-
lib/librte_ethdev/rte_ethdev.c | 15 +++++++++++++++
lib/librte_ethdev/rte_ethdev.h | 33 ++++++++++++++++++++++++++++++++-
6 files changed, 56 insertions(+), 16 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 1b4fcb7e6..0e85c47f3 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -56,18 +56,6 @@ Deprecation Notices
Target release for removal of the legacy API will be defined once most
PMDs have switched to rte_flow.
-* ethdev: Maximum and minimum MTU values vary between hardware devices. In
- hardware agnostic DPDK applications access to such information would allow
- a more accurate way of validating and setting supported MTU values on a per
- device basis rather than using a defined default for all devices. To
- resolve this, the following members will be added to ``rte_eth_dev_info``.
- Note: these can be added to fit a hole in the existing structure for amd64
- but not for 32-bit, as such ABI change will occur as size of the structure
- will increase.
-
- - Member ``uint16_t min_mtu`` the minimum MTU allowed.
- - Member ``uint16_t max_mtu`` the maximum MTU allowed.
-
* meter: New ``rte_color`` definition will be added in 19.02 and that will
replace ``enum rte_meter_color`` in meter library in 19.05. This will help
to consolidate color definition, which is currently replicated in many places,
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 61a2c7383..6ba3fab9a 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -136,6 +136,12 @@ ABI Changes
Also, make sure to start the actual text at the margin.
=========================================================
+* ethdev: Additional fields in rte_eth_dev_info.
+
+ The ``rte_eth_dev_info`` structure has had two extra fields
+ added: ``min_mtu`` and ``max_mtu``. Each of these are of type ``uint16_t``.
+ The values of these fields can be set specifically by the PMD drivers as
+ supported values can vary from device to device.
Shared Library Versions
-----------------------
@@ -171,7 +177,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_distributor.so.1
librte_eal.so.9
librte_efd.so.1
- librte_ethdev.so.11
+ + librte_ethdev.so.12
librte_eventdev.so.6
librte_flow_classify.so.1
librte_gro.so.1
diff --git a/lib/librte_ethdev/Makefile b/lib/librte_ethdev/Makefile
index e09c4263a..8d4a02630 100644
--- a/lib/librte_ethdev/Makefile
+++ b/lib/librte_ethdev/Makefile
@@ -16,7 +16,7 @@ LDLIBS += -lrte_mbuf -lrte_kvargs -lrte_cmdline -lrte_meter
EXPORT_MAP := rte_ethdev_version.map
-LIBABIVER := 11
+LIBABIVER := 12
SRCS-y += ethdev_private.c
SRCS-y += rte_ethdev.c
diff --git a/lib/librte_ethdev/meson.build b/lib/librte_ethdev/meson.build
index e98942ff8..8d6165b2a 100644
--- a/lib/librte_ethdev/meson.build
+++ b/lib/librte_ethdev/meson.build
@@ -2,7 +2,7 @@
# Copyright(c) 2017 Intel Corporation
name = 'ethdev'
-version = 11
+version = 12
allow_experimental_apis = true
sources = files('ethdev_private.c',
'ethdev_profile.c',
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 85c179496..fe72e88c2 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -2524,6 +2524,8 @@ rte_eth_dev_info_get(uint16_t port_id, struct rte_eth_dev_info *dev_info)
dev_info->rx_desc_lim = lim;
dev_info->tx_desc_lim = lim;
dev_info->device = dev->device;
+ dev_info->min_mtu = ETHER_MIN_MTU;
+ dev_info->max_mtu = UINT16_MAX;
RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get);
(*dev->dev_ops->dev_infos_get)(dev, dev_info);
@@ -2587,12 +2589,25 @@ int
rte_eth_dev_set_mtu(uint16_t port_id, uint16_t mtu)
{
int ret;
+ struct rte_eth_dev_info dev_info;
struct rte_eth_dev *dev;
RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
dev = &rte_eth_devices[port_id];
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->mtu_set, -ENOTSUP);
+ /*
+ * Check if the device supports dev_infos_get, if it does not
+ * skip min_mtu/max_mtu validation here as this requires values
+ * that are populated within the call to rte_eth_dev_info_get()
+ * which relies on dev->dev_ops->dev_infos_get.
+ */
+ if (*dev->dev_ops->dev_infos_get != NULL) {
+ rte_eth_dev_info_get(port_id, &dev_info);
+ if (mtu < dev_info.min_mtu || mtu > dev_info.max_mtu)
+ return -EINVAL;
+ }
+
ret = (*dev->dev_ops->mtu_set)(dev, mtu);
if (!ret)
dev->data->mtu = mtu;
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index a3c864a13..bea1bd2d4 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1086,6 +1086,8 @@ struct rte_eth_dev_info {
const char *driver_name; /**< Device Driver name. */
unsigned int if_index; /**< Index to bound host interface, or 0 if none.
Use if_indextoname() to translate into an interface name. */
+ uint16_t min_mtu; /**< Minimum MTU allowed */
+ uint16_t max_mtu; /**< Maximum MTU allowed */
const uint32_t *dev_flags; /**< Device flags */
uint32_t min_rx_bufsize; /**< Minimum size of RX buffer. */
uint32_t max_rx_pktlen; /**< Maximum configurable length of RX pkt. */
@@ -2202,6 +2204,33 @@ void rte_eth_macaddr_get(uint16_t port_id, struct ether_addr *mac_addr);
/**
* Retrieve the contextual information of an Ethernet device.
*
+ * As part of this function, a number of of fields in dev_info will be
+ * initialized as follows:
+ *
+ * rx_desc_lim = lim
+ * tx_desc_lim = lim
+ *
+ * Where lim is defined within the rte_eth_dev_info_get as
+ *
+ * const struct rte_eth_desc_lim lim = {
+ * .nb_max = UINT16_MAX,
+ * .nb_min = 0,
+ * .nb_align = 1,
+ * };
+ *
+ * device = dev->device
+ * min_mtu = ETHER_MIN_MTU
+ * max_mtu = UINT16_MAX
+ *
+ * The following fields will be populated if support for dev_infos_get()
+ * exists for the device and the rte_eth_dev 'dev' has been populated
+ * successfully with a call to it:
+ *
+ * driver_name = dev->device->driver->name
+ * nb_rx_queues = dev->data->nb_rx_queues
+ * nb_tx_queues = dev->data->nb_tx_queues
+ * dev_flags = &dev->data->dev_flags
+ *
* @param port_id
* The port identifier of the Ethernet device.
* @param dev_info
@@ -2298,7 +2327,9 @@ int rte_eth_dev_get_mtu(uint16_t port_id, uint16_t *mtu);
* - (-ENOTSUP) if operation is not supported.
* - (-ENODEV) if *port_id* invalid.
* - (-EIO) if device is removed.
- * - (-EINVAL) if *mtu* invalid.
+ * - (-EINVAL) if *mtu* invalid, validation of mtu can occur within
+ * rte_eth_dev_set_mtu if dev_infos_get is supported by the device or
+ * when the mtu is set using dev->dev_ops->mtu_set.
* - (-EBUSY) if operation is not allowed when the port is running
*/
int rte_eth_dev_set_mtu(uint16_t port_id, uint16_t mtu);
--
2.13.6
^ permalink raw reply [relevance 12%]
* [dpdk-dev] [PATCH v2 1/7] ethdev: add min/max MTU to device info
2019-03-22 13:01 12% ` [dpdk-dev] [PATCH v2 1/7] " Ian Stokes
@ 2019-03-22 13:01 12% ` Ian Stokes
2019-03-25 14:26 0% ` Ferruh Yigit
1 sibling, 0 replies; 200+ results
From: Ian Stokes @ 2019-03-22 13:01 UTC (permalink / raw)
To: dev; +Cc: stephen, Ian Stokes
From: Stephen Hemminger <stephen@networkplumber.org>
This addresses the usability issue raised by OVS at DPDK Userspace
summit. It adds general min/max mtu into device info. For compatiablity,
and to save space, it fits in a hole in existing structure.
The initial version sets max mtu to normal Ethernet, it is up to
PMD to set larger value if it supports Jumbo frames.
Also remove the deprecation notice introduced in 18.11 regarding this
change and bump ethdev ABI version.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Ian Stokes <ian.stokes@intel.com>
Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
---
v1 -> v2
* Document default values set in rte_eth_dev_info_get() in doxygen
documentation.
* Document causes of EINVAL returns for rte_eth_dev_set_mtu() in doxygen
documentation.
* Check if dev_infos_get is supported before validating mtu values in
rte_eth_dev_mtu_set. If unsupported skip validation step.
RFC -> v1
* Removed RFC status.
* dev_info->max_mtu set to UINT16_MAX initially instead of ETHER_MTU to
avoid breaking jumbo frame support. ETHER_MTU to be re-introduced
when all PMD drivers modified to support min/max mtu support.
* Bump ethdev ABI version.
* Added ACK from Andrew Rybchenko.
---
doc/guides/rel_notes/deprecation.rst | 12 ------------
doc/guides/rel_notes/release_19_05.rst | 8 +++++++-
lib/librte_ethdev/Makefile | 2 +-
lib/librte_ethdev/meson.build | 2 +-
lib/librte_ethdev/rte_ethdev.c | 15 +++++++++++++++
lib/librte_ethdev/rte_ethdev.h | 33 ++++++++++++++++++++++++++++++++-
6 files changed, 56 insertions(+), 16 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 1b4fcb7e6..0e85c47f3 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -56,18 +56,6 @@ Deprecation Notices
Target release for removal of the legacy API will be defined once most
PMDs have switched to rte_flow.
-* ethdev: Maximum and minimum MTU values vary between hardware devices. In
- hardware agnostic DPDK applications access to such information would allow
- a more accurate way of validating and setting supported MTU values on a per
- device basis rather than using a defined default for all devices. To
- resolve this, the following members will be added to ``rte_eth_dev_info``.
- Note: these can be added to fit a hole in the existing structure for amd64
- but not for 32-bit, as such ABI change will occur as size of the structure
- will increase.
-
- - Member ``uint16_t min_mtu`` the minimum MTU allowed.
- - Member ``uint16_t max_mtu`` the maximum MTU allowed.
-
* meter: New ``rte_color`` definition will be added in 19.02 and that will
replace ``enum rte_meter_color`` in meter library in 19.05. This will help
to consolidate color definition, which is currently replicated in many places,
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 61a2c7383..6ba3fab9a 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -136,6 +136,12 @@ ABI Changes
Also, make sure to start the actual text at the margin.
=========================================================
+* ethdev: Additional fields in rte_eth_dev_info.
+
+ The ``rte_eth_dev_info`` structure has had two extra fields
+ added: ``min_mtu`` and ``max_mtu``. Each of these are of type ``uint16_t``.
+ The values of these fields can be set specifically by the PMD drivers as
+ supported values can vary from device to device.
Shared Library Versions
-----------------------
@@ -171,7 +177,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_distributor.so.1
librte_eal.so.9
librte_efd.so.1
- librte_ethdev.so.11
+ + librte_ethdev.so.12
librte_eventdev.so.6
librte_flow_classify.so.1
librte_gro.so.1
diff --git a/lib/librte_ethdev/Makefile b/lib/librte_ethdev/Makefile
index e09c4263a..8d4a02630 100644
--- a/lib/librte_ethdev/Makefile
+++ b/lib/librte_ethdev/Makefile
@@ -16,7 +16,7 @@ LDLIBS += -lrte_mbuf -lrte_kvargs -lrte_cmdline -lrte_meter
EXPORT_MAP := rte_ethdev_version.map
-LIBABIVER := 11
+LIBABIVER := 12
SRCS-y += ethdev_private.c
SRCS-y += rte_ethdev.c
diff --git a/lib/librte_ethdev/meson.build b/lib/librte_ethdev/meson.build
index e98942ff8..8d6165b2a 100644
--- a/lib/librte_ethdev/meson.build
+++ b/lib/librte_ethdev/meson.build
@@ -2,7 +2,7 @@
# Copyright(c) 2017 Intel Corporation
name = 'ethdev'
-version = 11
+version = 12
allow_experimental_apis = true
sources = files('ethdev_private.c',
'ethdev_profile.c',
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 85c179496..fe72e88c2 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -2524,6 +2524,8 @@ rte_eth_dev_info_get(uint16_t port_id, struct rte_eth_dev_info *dev_info)
dev_info->rx_desc_lim = lim;
dev_info->tx_desc_lim = lim;
dev_info->device = dev->device;
+ dev_info->min_mtu = ETHER_MIN_MTU;
+ dev_info->max_mtu = UINT16_MAX;
RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get);
(*dev->dev_ops->dev_infos_get)(dev, dev_info);
@@ -2587,12 +2589,25 @@ int
rte_eth_dev_set_mtu(uint16_t port_id, uint16_t mtu)
{
int ret;
+ struct rte_eth_dev_info dev_info;
struct rte_eth_dev *dev;
RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
dev = &rte_eth_devices[port_id];
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->mtu_set, -ENOTSUP);
+ /*
+ * Check if the device supports dev_infos_get, if it does not
+ * skip min_mtu/max_mtu validation here as this requires values
+ * that are populated within the call to rte_eth_dev_info_get()
+ * which relies on dev->dev_ops->dev_infos_get.
+ */
+ if (*dev->dev_ops->dev_infos_get != NULL) {
+ rte_eth_dev_info_get(port_id, &dev_info);
+ if (mtu < dev_info.min_mtu || mtu > dev_info.max_mtu)
+ return -EINVAL;
+ }
+
ret = (*dev->dev_ops->mtu_set)(dev, mtu);
if (!ret)
dev->data->mtu = mtu;
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index a3c864a13..bea1bd2d4 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1086,6 +1086,8 @@ struct rte_eth_dev_info {
const char *driver_name; /**< Device Driver name. */
unsigned int if_index; /**< Index to bound host interface, or 0 if none.
Use if_indextoname() to translate into an interface name. */
+ uint16_t min_mtu; /**< Minimum MTU allowed */
+ uint16_t max_mtu; /**< Maximum MTU allowed */
const uint32_t *dev_flags; /**< Device flags */
uint32_t min_rx_bufsize; /**< Minimum size of RX buffer. */
uint32_t max_rx_pktlen; /**< Maximum configurable length of RX pkt. */
@@ -2202,6 +2204,33 @@ void rte_eth_macaddr_get(uint16_t port_id, struct ether_addr *mac_addr);
/**
* Retrieve the contextual information of an Ethernet device.
*
+ * As part of this function, a number of of fields in dev_info will be
+ * initialized as follows:
+ *
+ * rx_desc_lim = lim
+ * tx_desc_lim = lim
+ *
+ * Where lim is defined within the rte_eth_dev_info_get as
+ *
+ * const struct rte_eth_desc_lim lim = {
+ * .nb_max = UINT16_MAX,
+ * .nb_min = 0,
+ * .nb_align = 1,
+ * };
+ *
+ * device = dev->device
+ * min_mtu = ETHER_MIN_MTU
+ * max_mtu = UINT16_MAX
+ *
+ * The following fields will be populated if support for dev_infos_get()
+ * exists for the device and the rte_eth_dev 'dev' has been populated
+ * successfully with a call to it:
+ *
+ * driver_name = dev->device->driver->name
+ * nb_rx_queues = dev->data->nb_rx_queues
+ * nb_tx_queues = dev->data->nb_tx_queues
+ * dev_flags = &dev->data->dev_flags
+ *
* @param port_id
* The port identifier of the Ethernet device.
* @param dev_info
@@ -2298,7 +2327,9 @@ int rte_eth_dev_get_mtu(uint16_t port_id, uint16_t *mtu);
* - (-ENOTSUP) if operation is not supported.
* - (-ENODEV) if *port_id* invalid.
* - (-EIO) if device is removed.
- * - (-EINVAL) if *mtu* invalid.
+ * - (-EINVAL) if *mtu* invalid, validation of mtu can occur within
+ * rte_eth_dev_set_mtu if dev_infos_get is supported by the device or
+ * when the mtu is set using dev->dev_ops->mtu_set.
* - (-EBUSY) if operation is not allowed when the port is running
*/
int rte_eth_dev_set_mtu(uint16_t port_id, uint16_t mtu);
--
2.13.6
^ permalink raw reply [relevance 12%]
* [dpdk-dev] [PATCH v4 0/5] Introduce AF_XDP PMD
` (2 preceding siblings ...)
2019-03-21 9:18 3% ` [dpdk-dev] [PATCH v3 0/5] " Xiaolong Ye
@ 2019-03-22 13:01 3% ` Xiaolong Ye
2019-03-22 13:01 3% ` Xiaolong Ye
2019-03-25 6:03 2% ` [dpdk-dev] [PATCH v5 " Xiaolong Ye
` (4 subsequent siblings)
8 siblings, 1 reply; 200+ results
From: Xiaolong Ye @ 2019-03-22 13:01 UTC (permalink / raw)
To: dev; +Cc: Qi Zhang, Karlsson Magnus, Topel Bjorn, Xiaolong Ye
Overview
========
This patchset adds a new PMD driver for AF_XDP which is a proposed
faster version of AF_PACKET interface in Linux, see below links [1] [2] for
details of AF_XDP introduction:
AF_XDP roadmap
==============
- AF_XDP is included in upstream kernel since 4.18, and AF_XDP support
in libbpf has been merged in v5.1-rc1.
- Now i40e and ixgbe drivers have supported zero copy mode.
Change logs
===========
V4:
- change vdev name to net_af_xdp
- adopt dynamic log type for all logging
- Fix other style issues raised by Stephen
V3:
- Fix all style issues pointed by Stephen, Mattias, David.
- Drop the testpmd change as we'll adopt Jerin's suggestion to add a new
mempool driver to handle the application use of AF_XDP's zero copy feature.
V2:
- Fix a NULL pointer reference crash issue
- Fix txonly stop sending traffic in zc mode
- Refactor rte_mbuf.c to avoid ABI breakage.
- Fix multiple style issues pointed by Ferruh, David, Stephen, Luca.
changes vs RFC sent by Qi last Aug:
- Re-work base on AF_XDP's interface changes since the new libbpf has
provided higher-level APIs that hide many of the details of the AP_XDP
uapi. After the rework, it helps to reduce 300+ lines of code.
- multi-queues is not supported due to current libbpf doesn't support
multi-sockets on a single umem.
- No extra steps to load xdp program manually, since the current behavior of
libbpf would load a default xdp program when user calls xsk_socket__create.
userspace application only needs to handle the cleanup.
How to try
==========
1. take the kernel >= v5.1-rc1, build kernel and replace your host
kernel with it.
make sure you turn on XDP sockets when compiling
Networking support -->
Networking options -->
[ * ] XDP sockets
2. build libbpf in tools/lib/bpf, and copy the libbpf.a and libbpf.so to /usr/lib64
cd tools/lib/bpf
make
3. ethtool -L enp59s0f0 combined 1
4. start testpmd
./build/app/testpmd -c 0xc -n 4 --vdev net_af_xdp,iface=enp59s0f0,queue=0 -- -i --rxq=1 --txq=1
in this case, default xdp program will be loaded and linked to queue 0 of enp59s0f0,
network traffics travel to queue 0 will be redirected to af_xdp socket.
Xiaolong Ye (5):
net/af_xdp: introduce AF XDP PMD driver
lib/mbuf: introduce helper to create mempool with flags
lib/mempool: allow page size aligned mempool
net/af_xdp: use mbuf mempool for buffer management
net/af_xdp: enable zero copy
MAINTAINERS | 6 +
config/common_base | 5 +
config/common_linux | 1 +
doc/guides/nics/af_xdp.rst | 45 +
doc/guides/nics/features/af_xdp.ini | 11 +
doc/guides/nics/index.rst | 1 +
doc/guides/rel_notes/release_19_05.rst | 7 +
drivers/net/Makefile | 1 +
drivers/net/af_xdp/Makefile | 32 +
drivers/net/af_xdp/meson.build | 21 +
drivers/net/af_xdp/rte_eth_af_xdp.c | 1028 +++++++++++++++++
drivers/net/af_xdp/rte_pmd_af_xdp_version.map | 3 +
drivers/net/meson.build | 1 +
lib/librte_mbuf/rte_mbuf.c | 29 +-
lib/librte_mbuf/rte_mbuf.h | 45 +
lib/librte_mempool/rte_mempool.c | 3 +
lib/librte_mempool/rte_mempool.h | 1 +
mk/rte.app.mk | 1 +
18 files changed, 1236 insertions(+), 5 deletions(-)
create mode 100644 doc/guides/nics/af_xdp.rst
create mode 100644 doc/guides/nics/features/af_xdp.ini
create mode 100644 drivers/net/af_xdp/Makefile
create mode 100644 drivers/net/af_xdp/meson.build
create mode 100644 drivers/net/af_xdp/rte_eth_af_xdp.c
create mode 100644 drivers/net/af_xdp/rte_pmd_af_xdp_version.map
--
2.17.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v4 0/5] Introduce AF_XDP PMD
2019-03-22 13:01 3% ` [dpdk-dev] [PATCH v4 " Xiaolong Ye
@ 2019-03-22 13:01 3% ` Xiaolong Ye
0 siblings, 0 replies; 200+ results
From: Xiaolong Ye @ 2019-03-22 13:01 UTC (permalink / raw)
To: dev; +Cc: Qi Zhang, Karlsson Magnus, Topel Bjorn, Xiaolong Ye
Overview
========
This patchset adds a new PMD driver for AF_XDP which is a proposed
faster version of AF_PACKET interface in Linux, see below links [1] [2] for
details of AF_XDP introduction:
AF_XDP roadmap
==============
- AF_XDP is included in upstream kernel since 4.18, and AF_XDP support
in libbpf has been merged in v5.1-rc1.
- Now i40e and ixgbe drivers have supported zero copy mode.
Change logs
===========
V4:
- change vdev name to net_af_xdp
- adopt dynamic log type for all logging
- Fix other style issues raised by Stephen
V3:
- Fix all style issues pointed by Stephen, Mattias, David.
- Drop the testpmd change as we'll adopt Jerin's suggestion to add a new
mempool driver to handle the application use of AF_XDP's zero copy feature.
V2:
- Fix a NULL pointer reference crash issue
- Fix txonly stop sending traffic in zc mode
- Refactor rte_mbuf.c to avoid ABI breakage.
- Fix multiple style issues pointed by Ferruh, David, Stephen, Luca.
changes vs RFC sent by Qi last Aug:
- Re-work base on AF_XDP's interface changes since the new libbpf has
provided higher-level APIs that hide many of the details of the AP_XDP
uapi. After the rework, it helps to reduce 300+ lines of code.
- multi-queues is not supported due to current libbpf doesn't support
multi-sockets on a single umem.
- No extra steps to load xdp program manually, since the current behavior of
libbpf would load a default xdp program when user calls xsk_socket__create.
userspace application only needs to handle the cleanup.
How to try
==========
1. take the kernel >= v5.1-rc1, build kernel and replace your host
kernel with it.
make sure you turn on XDP sockets when compiling
Networking support -->
Networking options -->
[ * ] XDP sockets
2. build libbpf in tools/lib/bpf, and copy the libbpf.a and libbpf.so to /usr/lib64
cd tools/lib/bpf
make
3. ethtool -L enp59s0f0 combined 1
4. start testpmd
./build/app/testpmd -c 0xc -n 4 --vdev net_af_xdp,iface=enp59s0f0,queue=0 -- -i --rxq=1 --txq=1
in this case, default xdp program will be loaded and linked to queue 0 of enp59s0f0,
network traffics travel to queue 0 will be redirected to af_xdp socket.
Xiaolong Ye (5):
net/af_xdp: introduce AF XDP PMD driver
lib/mbuf: introduce helper to create mempool with flags
lib/mempool: allow page size aligned mempool
net/af_xdp: use mbuf mempool for buffer management
net/af_xdp: enable zero copy
MAINTAINERS | 6 +
config/common_base | 5 +
config/common_linux | 1 +
doc/guides/nics/af_xdp.rst | 45 +
doc/guides/nics/features/af_xdp.ini | 11 +
doc/guides/nics/index.rst | 1 +
doc/guides/rel_notes/release_19_05.rst | 7 +
drivers/net/Makefile | 1 +
drivers/net/af_xdp/Makefile | 32 +
drivers/net/af_xdp/meson.build | 21 +
drivers/net/af_xdp/rte_eth_af_xdp.c | 1028 +++++++++++++++++
drivers/net/af_xdp/rte_pmd_af_xdp_version.map | 3 +
drivers/net/meson.build | 1 +
lib/librte_mbuf/rte_mbuf.c | 29 +-
lib/librte_mbuf/rte_mbuf.h | 45 +
lib/librte_mempool/rte_mempool.c | 3 +
lib/librte_mempool/rte_mempool.h | 1 +
mk/rte.app.mk | 1 +
18 files changed, 1236 insertions(+), 5 deletions(-)
create mode 100644 doc/guides/nics/af_xdp.rst
create mode 100644 doc/guides/nics/features/af_xdp.ini
create mode 100644 drivers/net/af_xdp/Makefile
create mode 100644 drivers/net/af_xdp/meson.build
create mode 100644 drivers/net/af_xdp/rte_eth_af_xdp.c
create mode 100644 drivers/net/af_xdp/rte_pmd_af_xdp_version.map
--
2.17.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v7] ci: Introduce travis builds for github repositories
2019-03-04 16:12 3% ` [dpdk-dev] [PATCH v6 1/1] ci: Introduce travis builds for github repositories Michael Santana
@ 2019-03-22 16:56 3% ` Michael Santana
2019-03-22 16:56 3% ` Michael Santana
2019-03-25 15:32 3% ` [dpdk-dev] [PATCH v8] " Michael Santana
0 siblings, 2 replies; 200+ results
From: Michael Santana @ 2019-03-22 16:56 UTC (permalink / raw)
To: dev
Cc: Aaron Conole, Bruce Richardson, Honnappa Nagarahalli,
Thomas Monjalon, Luca Boccassi
GitHub is a service used by developers to store repositories. GitHub
provides service integrations that allow 3rd party services to access
developer repositories and perform actions. One of these services is
Travis-CI, a simple continuous integration platform.
This series introduces the ability for any github mirrors of the DPDK
project, including developer mirrors, to kick off builds under the
travis CI infrastructure. For now, this just means compilation - no
other kinds of automated run exists yet. In the future, this can be
expanded to execute and report results for any test-suites that might
exist.
This is a simple initial implementation of a travis build for the DPDK
project. It doesn't require any changes from individual developers to
enable, but will allow those developers who opt-in to GitHub and the
travis service to get automatic builds for every push they make.
The files added under .ci/ exist so that in the future, other CI
support platforms (such as cirrus, appveyor, etc.) could have a common
place to put their requisite scripts without polluting the main tree.
Signed-off-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Michael Santana <msantana@redhat.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
---
.ci/linux-build.sh | 24 +++++++
.ci/linux-setup.sh | 3 +
.travis.yml | 99 +++++++++++++++++++++++++++++
MAINTAINERS | 6 ++
doc/guides/contributing/patches.rst | 4 ++
5 files changed, 136 insertions(+)
create mode 100755 .ci/linux-build.sh
create mode 100755 .ci/linux-setup.sh
create mode 100644 .travis.yml
diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
new file mode 100755
index 000000000..767840e40
--- /dev/null
+++ b/.ci/linux-build.sh
@@ -0,0 +1,24 @@
+#!/bin/sh -xe
+
+on_error() {
+ if [ $? = 0 ]; then
+ exit
+ fi
+ FILES_TO_PRINT="build/meson-logs/testlog.txt build/.ninja_log build/meson-logs/meson-log.txt"
+
+ for pr_file in ${FILES_TO_PRINT}; do
+ if [ -e "$pr_file" ]; then
+ cat "$pr_file"
+ fi
+ done
+}
+trap on_error EXIT
+
+if [ "${AARCH64}" = "1" ]; then
+ # convert the arch specifier
+ OPTS="${OPTS} -DRTE_ARCH_64=1 --cross-file config/arm/arm64_armv8_linuxapp_gcc"
+fi
+
+OPTS="$OPTS --default-library=$DEF_LIB"
+meson build --werror -Dexamples=all ${OPTS}
+ninja -C build
diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh
new file mode 100755
index 000000000..acdf9f370
--- /dev/null
+++ b/.ci/linux-setup.sh
@@ -0,0 +1,3 @@
+#!/bin/sh
+
+python3 -m pip install --upgrade meson --user
diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 000000000..3045eada5
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,99 @@
+language: c
+compiler:
+ - gcc
+ - clang
+
+dist: xenial
+
+os:
+ - linux
+
+addons:
+ apt:
+ update: true
+ packages: &required_packages
+ - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
+
+aarch64_packages: &aarch64_packages
+ - *required_packages
+ - [gcc-aarch64-linux-gnu, libc6-dev-arm64-cross]
+
+extra_packages: &extra_packages
+ - *required_packages
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+
+before_install: ./.ci/${TRAVIS_OS_NAME}-setup.sh
+
+sudo: false
+
+env:
+ - DEF_LIB="static"
+ - DEF_LIB="shared"
+ - DEF_LIB="static" OPTS="-Denable_kmods=false"
+ - DEF_LIB="shared" OPTS="-Denable_kmods=false"
+
+matrix:
+ include:
+ - env: DEF_LIB="static" OPTS="-Denable_kmods=false" AARCH64=1
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - *aarch64_packages
+ - env: DEF_LIB="shared" OPTS="-Denable_kmods=false" AARCH64=1
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - *aarch64_packages
+ - env: DEF_LIB="static"
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - *extra_packages
+ - env: DEF_LIB="shared"
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - *extra_packages
+ - env: DEF_LIB="static" OPTS="-Denable_kmods=false"
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - *extra_packages
+ - env: DEF_LIB="shared" OPTS="-Denable_kmods=false"
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - *extra_packages
+ - env: DEF_LIB="static"
+ compiler: clang
+ addons:
+ apt:
+ packages:
+ - *extra_packages
+ - env: DEF_LIB="shared"
+ compiler: clang
+ addons:
+ apt:
+ packages:
+ - *extra_packages
+ - env: DEF_LIB="static" OPTS="-Denable_kmods=false"
+ compiler: clang
+ addons:
+ apt:
+ packages:
+ - *extra_packages
+ - env: DEF_LIB="shared" OPTS="-Denable_kmods=false"
+ compiler: clang
+ addons:
+ apt:
+ packages:
+ - *extra_packages
+
+
+script: ./.ci/${TRAVIS_OS_NAME}-build.sh
diff --git a/MAINTAINERS b/MAINTAINERS
index 15c53888c..e4b9a8e00 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -119,6 +119,12 @@ F: config/rte_config.h
F: buildtools/gen-pmdinfo-cfile.sh
F: buildtools/symlink-drivers-solibs.sh
+Public CI
+M: Aaron Conole <aconole@redhat.com>
+M: Michael Santana <msantana@redhat.com>
+F: .travis.yml
+F: .ci/
+
ABI versioning
M: Neil Horman <nhorman@tuxdriver.com>
F: doc/guides/rel_notes/deprecation.rst
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index 211a5cdc7..22a9039e8 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -32,6 +32,10 @@ The mailing list for DPDK development is `dev@dpdk.org <http://mails.dpdk.org/ar
Contributors will need to `register for the mailing list <http://mails.dpdk.org/listinfo/dev>`_ in order to submit patches.
It is also worth registering for the DPDK `Patchwork <http://patches.dpdk.org/project/dpdk/list/>`_
+If you are using the GitHub service, you can link your repository to
+the ``travis-ci.org`` build service. When you push patches to your GitHub
+repository, the travis service will automatically build your changes.
+
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.20.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v7] ci: Introduce travis builds for github repositories
2019-03-22 16:56 3% ` [dpdk-dev] [PATCH v7] " Michael Santana
@ 2019-03-22 16:56 3% ` Michael Santana
2019-03-25 15:32 3% ` [dpdk-dev] [PATCH v8] " Michael Santana
1 sibling, 0 replies; 200+ results
From: Michael Santana @ 2019-03-22 16:56 UTC (permalink / raw)
To: dev
Cc: Aaron Conole, Bruce Richardson, Honnappa Nagarahalli,
Thomas Monjalon, Luca Boccassi
GitHub is a service used by developers to store repositories. GitHub
provides service integrations that allow 3rd party services to access
developer repositories and perform actions. One of these services is
Travis-CI, a simple continuous integration platform.
This series introduces the ability for any github mirrors of the DPDK
project, including developer mirrors, to kick off builds under the
travis CI infrastructure. For now, this just means compilation - no
other kinds of automated run exists yet. In the future, this can be
expanded to execute and report results for any test-suites that might
exist.
This is a simple initial implementation of a travis build for the DPDK
project. It doesn't require any changes from individual developers to
enable, but will allow those developers who opt-in to GitHub and the
travis service to get automatic builds for every push they make.
The files added under .ci/ exist so that in the future, other CI
support platforms (such as cirrus, appveyor, etc.) could have a common
place to put their requisite scripts without polluting the main tree.
Signed-off-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Michael Santana <msantana@redhat.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
---
.ci/linux-build.sh | 24 +++++++
.ci/linux-setup.sh | 3 +
.travis.yml | 99 +++++++++++++++++++++++++++++
MAINTAINERS | 6 ++
doc/guides/contributing/patches.rst | 4 ++
5 files changed, 136 insertions(+)
create mode 100755 .ci/linux-build.sh
create mode 100755 .ci/linux-setup.sh
create mode 100644 .travis.yml
diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
new file mode 100755
index 000000000..767840e40
--- /dev/null
+++ b/.ci/linux-build.sh
@@ -0,0 +1,24 @@
+#!/bin/sh -xe
+
+on_error() {
+ if [ $? = 0 ]; then
+ exit
+ fi
+ FILES_TO_PRINT="build/meson-logs/testlog.txt build/.ninja_log build/meson-logs/meson-log.txt"
+
+ for pr_file in ${FILES_TO_PRINT}; do
+ if [ -e "$pr_file" ]; then
+ cat "$pr_file"
+ fi
+ done
+}
+trap on_error EXIT
+
+if [ "${AARCH64}" = "1" ]; then
+ # convert the arch specifier
+ OPTS="${OPTS} -DRTE_ARCH_64=1 --cross-file config/arm/arm64_armv8_linuxapp_gcc"
+fi
+
+OPTS="$OPTS --default-library=$DEF_LIB"
+meson build --werror -Dexamples=all ${OPTS}
+ninja -C build
diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh
new file mode 100755
index 000000000..acdf9f370
--- /dev/null
+++ b/.ci/linux-setup.sh
@@ -0,0 +1,3 @@
+#!/bin/sh
+
+python3 -m pip install --upgrade meson --user
diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 000000000..3045eada5
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,99 @@
+language: c
+compiler:
+ - gcc
+ - clang
+
+dist: xenial
+
+os:
+ - linux
+
+addons:
+ apt:
+ update: true
+ packages: &required_packages
+ - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
+
+aarch64_packages: &aarch64_packages
+ - *required_packages
+ - [gcc-aarch64-linux-gnu, libc6-dev-arm64-cross]
+
+extra_packages: &extra_packages
+ - *required_packages
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+
+before_install: ./.ci/${TRAVIS_OS_NAME}-setup.sh
+
+sudo: false
+
+env:
+ - DEF_LIB="static"
+ - DEF_LIB="shared"
+ - DEF_LIB="static" OPTS="-Denable_kmods=false"
+ - DEF_LIB="shared" OPTS="-Denable_kmods=false"
+
+matrix:
+ include:
+ - env: DEF_LIB="static" OPTS="-Denable_kmods=false" AARCH64=1
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - *aarch64_packages
+ - env: DEF_LIB="shared" OPTS="-Denable_kmods=false" AARCH64=1
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - *aarch64_packages
+ - env: DEF_LIB="static"
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - *extra_packages
+ - env: DEF_LIB="shared"
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - *extra_packages
+ - env: DEF_LIB="static" OPTS="-Denable_kmods=false"
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - *extra_packages
+ - env: DEF_LIB="shared" OPTS="-Denable_kmods=false"
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - *extra_packages
+ - env: DEF_LIB="static"
+ compiler: clang
+ addons:
+ apt:
+ packages:
+ - *extra_packages
+ - env: DEF_LIB="shared"
+ compiler: clang
+ addons:
+ apt:
+ packages:
+ - *extra_packages
+ - env: DEF_LIB="static" OPTS="-Denable_kmods=false"
+ compiler: clang
+ addons:
+ apt:
+ packages:
+ - *extra_packages
+ - env: DEF_LIB="shared" OPTS="-Denable_kmods=false"
+ compiler: clang
+ addons:
+ apt:
+ packages:
+ - *extra_packages
+
+
+script: ./.ci/${TRAVIS_OS_NAME}-build.sh
diff --git a/MAINTAINERS b/MAINTAINERS
index 15c53888c..e4b9a8e00 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -119,6 +119,12 @@ F: config/rte_config.h
F: buildtools/gen-pmdinfo-cfile.sh
F: buildtools/symlink-drivers-solibs.sh
+Public CI
+M: Aaron Conole <aconole@redhat.com>
+M: Michael Santana <msantana@redhat.com>
+F: .travis.yml
+F: .ci/
+
ABI versioning
M: Neil Horman <nhorman@tuxdriver.com>
F: doc/guides/rel_notes/deprecation.rst
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index 211a5cdc7..22a9039e8 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -32,6 +32,10 @@ The mailing list for DPDK development is `dev@dpdk.org <http://mails.dpdk.org/ar
Contributors will need to `register for the mailing list <http://mails.dpdk.org/listinfo/dev>`_ in order to submit patches.
It is also worth registering for the DPDK `Patchwork <http://patches.dpdk.org/project/dpdk/list/>`_
+If you are using the GitHub service, you can link your repository to
+the ``travis-ci.org`` build service. When you push patches to your GitHub
+repository, the travis service will automatically build your changes.
+
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.20.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v5 0/5] Introduce AF_XDP PMD
` (3 preceding siblings ...)
2019-03-22 13:01 3% ` [dpdk-dev] [PATCH v4 " Xiaolong Ye
@ 2019-03-25 6:03 2% ` Xiaolong Ye
2019-03-25 6:03 2% ` Xiaolong Ye
2019-03-26 12:20 2% ` [dpdk-dev] [PATCH v6 " Xiaolong Ye
` (3 subsequent siblings)
8 siblings, 1 reply; 200+ results
From: Xiaolong Ye @ 2019-03-25 6:03 UTC (permalink / raw)
To: dev, David Marchand
Cc: Qi Zhang, Karlsson Magnus, Topel Bjorn, Maxime Coquelin,
Stephen Hemminger, Ferruh Yigit, Luca Boccassi, Bruce Richardson,
Ananyev Konstantin, Xiaolong Ye
Overview
========
This patchset adds a new PMD driver for AF_XDP which is a proposed
faster version of AF_PACKET interface in Linux, see below links [1] [2] for
details of AF_XDP introduction:
AF_XDP roadmap
==============
- AF_XDP is included in upstream kernel since 4.18, and AF_XDP support
in libbpf has been merged in v5.1-rc1.
- Now i40e and ixgbe drivers have supported zero copy mode.
Change logs
===========
V5:
- disable AF_XDP pmd by default due to it requires kernel more recent
than minimum kernel version supported by DPDK
- address other review comments of Maxime
V4:
- change vdev name to net_af_xdp
- adopt dynamic log type for all logging
- Fix other style issues raised by Stephen
V3:
- Fix all style issues pointed by Stephen, Mattias, David.
- Drop the testpmd change as we'll adopt Jerin's suggestion to add a new
mempool driver to handle the application use of AF_XDP's zero copy feature.
V2:
- Fix a NULL pointer reference crash issue
- Fix txonly stop sending traffic in zc mode
- Refactor rte_mbuf.c to avoid ABI breakage.
- Fix multiple style issues pointed by Ferruh, David, Stephen, Luca.
changes vs RFC sent by Qi last Aug:
- Re-work base on AF_XDP's interface changes since the new libbpf has
provided higher-level APIs that hide many of the details of the AP_XDP
uapi. After the rework, it helps to reduce 300+ lines of code.
- multi-queues is not supported due to current libbpf doesn't support
multi-sockets on a single umem.
- No extra steps to load xdp program manually, since the current behavior of
libbpf would load a default xdp program when user calls xsk_socket__create.
userspace application only needs to handle the cleanup.
How to try
==========
1. take the kernel >= v5.1-rc1, build kernel and replace your host
kernel with it.
make sure you turn on XDP sockets when compiling
Networking support -->
Networking options -->
[ * ] XDP sockets
2. build libbpf in tools/lib/bpf, and copy the libbpf.a and libbpf.so to /usr/lib64
cd tools/lib/bpf
make
3. ethtool -L enp59s0f0 combined 1
4. extra step to build dpdk
explicitly enable AF_XDP pmd by adding below line to
config/common_linux
CONFIG_RTE_LIBRTE_PMD_AF_XDP=y
5. start testpmd
./build/app/testpmd -c 0xc -n 4 --vdev net_af_xdp,iface=enp59s0f0,queue=0 -- -i --rxq=1 --txq=1
in this case, default xdp program will be loaded and linked to queue 0 of enp59s0f0,
network traffics travel to queue 0 will be redirected to af_xdp socket.
Xiaolong Ye (5):
net/af_xdp: introduce AF XDP PMD driver
lib/mbuf: introduce helper to create mempool with flags
lib/mempool: allow page size aligned mempool
net/af_xdp: use mbuf mempool for buffer management
net/af_xdp: enable zero copy
MAINTAINERS | 6 +
config/common_base | 5 +
doc/guides/nics/af_xdp.rst | 45 +
doc/guides/nics/features/af_xdp.ini | 11 +
doc/guides/nics/index.rst | 1 +
doc/guides/rel_notes/release_19_05.rst | 7 +
drivers/net/Makefile | 1 +
drivers/net/af_xdp/Makefile | 32 +
drivers/net/af_xdp/meson.build | 21 +
drivers/net/af_xdp/rte_eth_af_xdp.c | 1020 +++++++++++++++++
drivers/net/af_xdp/rte_pmd_af_xdp_version.map | 3 +
drivers/net/meson.build | 1 +
lib/librte_mbuf/rte_mbuf.c | 29 +-
lib/librte_mbuf/rte_mbuf.h | 45 +
lib/librte_mbuf/rte_mbuf_version.map | 1 +
lib/librte_mempool/rte_mempool.c | 3 +
lib/librte_mempool/rte_mempool.h | 1 +
mk/rte.app.mk | 1 +
18 files changed, 1228 insertions(+), 5 deletions(-)
create mode 100644 doc/guides/nics/af_xdp.rst
create mode 100644 doc/guides/nics/features/af_xdp.ini
create mode 100644 drivers/net/af_xdp/Makefile
create mode 100644 drivers/net/af_xdp/meson.build
create mode 100644 drivers/net/af_xdp/rte_eth_af_xdp.c
create mode 100644 drivers/net/af_xdp/rte_pmd_af_xdp_version.map
--
2.17.1
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v5 0/5] Introduce AF_XDP PMD
2019-03-25 6:03 2% ` [dpdk-dev] [PATCH v5 " Xiaolong Ye
@ 2019-03-25 6:03 2% ` Xiaolong Ye
0 siblings, 0 replies; 200+ results
From: Xiaolong Ye @ 2019-03-25 6:03 UTC (permalink / raw)
To: dev, David Marchand
Cc: Qi Zhang, Karlsson Magnus, Topel Bjorn, Maxime Coquelin,
Stephen Hemminger, Ferruh Yigit, Luca Boccassi, Bruce Richardson,
Ananyev Konstantin, Xiaolong Ye
Overview
========
This patchset adds a new PMD driver for AF_XDP which is a proposed
faster version of AF_PACKET interface in Linux, see below links [1] [2] for
details of AF_XDP introduction:
AF_XDP roadmap
==============
- AF_XDP is included in upstream kernel since 4.18, and AF_XDP support
in libbpf has been merged in v5.1-rc1.
- Now i40e and ixgbe drivers have supported zero copy mode.
Change logs
===========
V5:
- disable AF_XDP pmd by default due to it requires kernel more recent
than minimum kernel version supported by DPDK
- address other review comments of Maxime
V4:
- change vdev name to net_af_xdp
- adopt dynamic log type for all logging
- Fix other style issues raised by Stephen
V3:
- Fix all style issues pointed by Stephen, Mattias, David.
- Drop the testpmd change as we'll adopt Jerin's suggestion to add a new
mempool driver to handle the application use of AF_XDP's zero copy feature.
V2:
- Fix a NULL pointer reference crash issue
- Fix txonly stop sending traffic in zc mode
- Refactor rte_mbuf.c to avoid ABI breakage.
- Fix multiple style issues pointed by Ferruh, David, Stephen, Luca.
changes vs RFC sent by Qi last Aug:
- Re-work base on AF_XDP's interface changes since the new libbpf has
provided higher-level APIs that hide many of the details of the AP_XDP
uapi. After the rework, it helps to reduce 300+ lines of code.
- multi-queues is not supported due to current libbpf doesn't support
multi-sockets on a single umem.
- No extra steps to load xdp program manually, since the current behavior of
libbpf would load a default xdp program when user calls xsk_socket__create.
userspace application only needs to handle the cleanup.
How to try
==========
1. take the kernel >= v5.1-rc1, build kernel and replace your host
kernel with it.
make sure you turn on XDP sockets when compiling
Networking support -->
Networking options -->
[ * ] XDP sockets
2. build libbpf in tools/lib/bpf, and copy the libbpf.a and libbpf.so to /usr/lib64
cd tools/lib/bpf
make
3. ethtool -L enp59s0f0 combined 1
4. extra step to build dpdk
explicitly enable AF_XDP pmd by adding below line to
config/common_linux
CONFIG_RTE_LIBRTE_PMD_AF_XDP=y
5. start testpmd
./build/app/testpmd -c 0xc -n 4 --vdev net_af_xdp,iface=enp59s0f0,queue=0 -- -i --rxq=1 --txq=1
in this case, default xdp program will be loaded and linked to queue 0 of enp59s0f0,
network traffics travel to queue 0 will be redirected to af_xdp socket.
Xiaolong Ye (5):
net/af_xdp: introduce AF XDP PMD driver
lib/mbuf: introduce helper to create mempool with flags
lib/mempool: allow page size aligned mempool
net/af_xdp: use mbuf mempool for buffer management
net/af_xdp: enable zero copy
MAINTAINERS | 6 +
config/common_base | 5 +
doc/guides/nics/af_xdp.rst | 45 +
doc/guides/nics/features/af_xdp.ini | 11 +
doc/guides/nics/index.rst | 1 +
doc/guides/rel_notes/release_19_05.rst | 7 +
drivers/net/Makefile | 1 +
drivers/net/af_xdp/Makefile | 32 +
drivers/net/af_xdp/meson.build | 21 +
drivers/net/af_xdp/rte_eth_af_xdp.c | 1020 +++++++++++++++++
drivers/net/af_xdp/rte_pmd_af_xdp_version.map | 3 +
drivers/net/meson.build | 1 +
lib/librte_mbuf/rte_mbuf.c | 29 +-
lib/librte_mbuf/rte_mbuf.h | 45 +
lib/librte_mbuf/rte_mbuf_version.map | 1 +
lib/librte_mempool/rte_mempool.c | 3 +
lib/librte_mempool/rte_mempool.h | 1 +
mk/rte.app.mk | 1 +
18 files changed, 1228 insertions(+), 5 deletions(-)
create mode 100644 doc/guides/nics/af_xdp.rst
create mode 100644 doc/guides/nics/features/af_xdp.ini
create mode 100644 drivers/net/af_xdp/Makefile
create mode 100644 drivers/net/af_xdp/meson.build
create mode 100644 drivers/net/af_xdp/rte_eth_af_xdp.c
create mode 100644 drivers/net/af_xdp/rte_pmd_af_xdp_version.map
--
2.17.1
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [PATCH v2 1/7] ethdev: add min/max MTU to device info
2019-03-22 13:01 12% ` [dpdk-dev] [PATCH v2 1/7] " Ian Stokes
2019-03-22 13:01 12% ` Ian Stokes
@ 2019-03-25 14:26 0% ` Ferruh Yigit
2019-03-25 14:26 0% ` Ferruh Yigit
1 sibling, 1 reply; 200+ results
From: Ferruh Yigit @ 2019-03-25 14:26 UTC (permalink / raw)
To: Ian Stokes, dev; +Cc: stephen
On 3/22/2019 1:01 PM, Ian Stokes wrote:
> From: Stephen Hemminger <stephen@networkplumber.org>
>
> This addresses the usability issue raised by OVS at DPDK Userspace
> summit. It adds general min/max mtu into device info. For compatiablity,
> and to save space, it fits in a hole in existing structure.
>
> The initial version sets max mtu to normal Ethernet, it is up to
> PMD to set larger value if it supports Jumbo frames.
>
> Also remove the deprecation notice introduced in 18.11 regarding this
> change and bump ethdev ABI version.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> Signed-off-by: Ian Stokes <ian.stokes@intel.com>
> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 1/7] ethdev: add min/max MTU to device info
2019-03-25 14:26 0% ` Ferruh Yigit
@ 2019-03-25 14:26 0% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-03-25 14:26 UTC (permalink / raw)
To: Ian Stokes, dev; +Cc: stephen
On 3/22/2019 1:01 PM, Ian Stokes wrote:
> From: Stephen Hemminger <stephen@networkplumber.org>
>
> This addresses the usability issue raised by OVS at DPDK Userspace
> summit. It adds general min/max mtu into device info. For compatiablity,
> and to save space, it fits in a hole in existing structure.
>
> The initial version sets max mtu to normal Ethernet, it is up to
> PMD to set larger value if it supports Jumbo frames.
>
> Also remove the deprecation notice introduced in 18.11 regarding this
> change and bump ethdev ABI version.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> Signed-off-by: Ian Stokes <ian.stokes@intel.com>
> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v8] ci: Introduce travis builds for github repositories
2019-03-22 16:56 3% ` [dpdk-dev] [PATCH v7] " Michael Santana
2019-03-22 16:56 3% ` Michael Santana
@ 2019-03-25 15:32 3% ` Michael Santana
2019-03-25 15:32 3% ` Michael Santana
1 sibling, 1 reply; 200+ results
From: Michael Santana @ 2019-03-25 15:32 UTC (permalink / raw)
To: dev
Cc: Aaron Conole, Bruce Richardson, Honnappa Nagarahalli,
Thomas Monjalon, Luca Boccassi
GitHub is a service used by developers to store repositories. GitHub
provides service integrations that allow 3rd party services to access
developer repositories and perform actions. One of these services is
Travis-CI, a simple continuous integration platform.
This series introduces the ability for any github mirrors of the DPDK
project, including developer mirrors, to kick off builds under the
travis CI infrastructure. For now, this just means compilation - no
other kinds of automated run exists yet. In the future, this can be
expanded to execute and report results for any test-suites that might
exist.
This is a simple initial implementation of a travis build for the DPDK
project. It doesn't require any changes from individual developers to
enable, but will allow those developers who opt-in to GitHub and the
travis service to get automatic builds for every push they make.
The files added under .ci/ exist so that in the future, other CI
support platforms (such as cirrus, appveyor, etc.) could have a common
place to put their requisite scripts without polluting the main tree.
Signed-off-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Michael Santana <msantana@redhat.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
---
.ci/linux-build.sh | 24 +++++++
.ci/linux-setup.sh | 3 +
.travis.yml | 99 +++++++++++++++++++++++++++++
MAINTAINERS | 6 ++
doc/guides/contributing/patches.rst | 4 ++
5 files changed, 136 insertions(+)
create mode 100755 .ci/linux-build.sh
create mode 100755 .ci/linux-setup.sh
create mode 100644 .travis.yml
diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
new file mode 100755
index 000000000..767840e40
--- /dev/null
+++ b/.ci/linux-build.sh
@@ -0,0 +1,24 @@
+#!/bin/sh -xe
+
+on_error() {
+ if [ $? = 0 ]; then
+ exit
+ fi
+ FILES_TO_PRINT="build/meson-logs/testlog.txt build/.ninja_log build/meson-logs/meson-log.txt"
+
+ for pr_file in $FILES_TO_PRINT; do
+ if [ -e "$pr_file" ]; then
+ cat "$pr_file"
+ fi
+ done
+}
+trap on_error EXIT
+
+if [ "$AARCH64" = "1" ]; then
+ # convert the arch specifier
+ OPTS="$OPTS --cross-file config/arm/arm64_armv8_linuxapp_gcc"
+fi
+
+OPTS="$OPTS --default-library=$DEF_LIB"
+meson build --werror -Dexamples=all $OPTS
+ninja -C build
diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh
new file mode 100755
index 000000000..acdf9f370
--- /dev/null
+++ b/.ci/linux-setup.sh
@@ -0,0 +1,3 @@
+#!/bin/sh
+
+python3 -m pip install --upgrade meson --user
diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 000000000..3045eada5
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,99 @@
+language: c
+compiler:
+ - gcc
+ - clang
+
+dist: xenial
+
+os:
+ - linux
+
+addons:
+ apt:
+ update: true
+ packages: &required_packages
+ - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
+
+aarch64_packages: &aarch64_packages
+ - *required_packages
+ - [gcc-aarch64-linux-gnu, libc6-dev-arm64-cross]
+
+extra_packages: &extra_packages
+ - *required_packages
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+
+before_install: ./.ci/${TRAVIS_OS_NAME}-setup.sh
+
+sudo: false
+
+env:
+ - DEF_LIB="static"
+ - DEF_LIB="shared"
+ - DEF_LIB="static" OPTS="-Denable_kmods=false"
+ - DEF_LIB="shared" OPTS="-Denable_kmods=false"
+
+matrix:
+ include:
+ - env: DEF_LIB="static" OPTS="-Denable_kmods=false" AARCH64=1
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - *aarch64_packages
+ - env: DEF_LIB="shared" OPTS="-Denable_kmods=false" AARCH64=1
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - *aarch64_packages
+ - env: DEF_LIB="static"
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - *extra_packages
+ - env: DEF_LIB="shared"
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - *extra_packages
+ - env: DEF_LIB="static" OPTS="-Denable_kmods=false"
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - *extra_packages
+ - env: DEF_LIB="shared" OPTS="-Denable_kmods=false"
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - *extra_packages
+ - env: DEF_LIB="static"
+ compiler: clang
+ addons:
+ apt:
+ packages:
+ - *extra_packages
+ - env: DEF_LIB="shared"
+ compiler: clang
+ addons:
+ apt:
+ packages:
+ - *extra_packages
+ - env: DEF_LIB="static" OPTS="-Denable_kmods=false"
+ compiler: clang
+ addons:
+ apt:
+ packages:
+ - *extra_packages
+ - env: DEF_LIB="shared" OPTS="-Denable_kmods=false"
+ compiler: clang
+ addons:
+ apt:
+ packages:
+ - *extra_packages
+
+
+script: ./.ci/${TRAVIS_OS_NAME}-build.sh
diff --git a/MAINTAINERS b/MAINTAINERS
index 15c53888c..e4b9a8e00 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -119,6 +119,12 @@ F: config/rte_config.h
F: buildtools/gen-pmdinfo-cfile.sh
F: buildtools/symlink-drivers-solibs.sh
+Public CI
+M: Aaron Conole <aconole@redhat.com>
+M: Michael Santana <msantana@redhat.com>
+F: .travis.yml
+F: .ci/
+
ABI versioning
M: Neil Horman <nhorman@tuxdriver.com>
F: doc/guides/rel_notes/deprecation.rst
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index 211a5cdc7..22a9039e8 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -32,6 +32,10 @@ The mailing list for DPDK development is `dev@dpdk.org <http://mails.dpdk.org/ar
Contributors will need to `register for the mailing list <http://mails.dpdk.org/listinfo/dev>`_ in order to submit patches.
It is also worth registering for the DPDK `Patchwork <http://patches.dpdk.org/project/dpdk/list/>`_
+If you are using the GitHub service, you can link your repository to
+the ``travis-ci.org`` build service. When you push patches to your GitHub
+repository, the travis service will automatically build your changes.
+
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.20.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v8] ci: Introduce travis builds for github repositories
2019-03-25 15:32 3% ` [dpdk-dev] [PATCH v8] " Michael Santana
@ 2019-03-25 15:32 3% ` Michael Santana
0 siblings, 0 replies; 200+ results
From: Michael Santana @ 2019-03-25 15:32 UTC (permalink / raw)
To: dev
Cc: Aaron Conole, Bruce Richardson, Honnappa Nagarahalli,
Thomas Monjalon, Luca Boccassi
GitHub is a service used by developers to store repositories. GitHub
provides service integrations that allow 3rd party services to access
developer repositories and perform actions. One of these services is
Travis-CI, a simple continuous integration platform.
This series introduces the ability for any github mirrors of the DPDK
project, including developer mirrors, to kick off builds under the
travis CI infrastructure. For now, this just means compilation - no
other kinds of automated run exists yet. In the future, this can be
expanded to execute and report results for any test-suites that might
exist.
This is a simple initial implementation of a travis build for the DPDK
project. It doesn't require any changes from individual developers to
enable, but will allow those developers who opt-in to GitHub and the
travis service to get automatic builds for every push they make.
The files added under .ci/ exist so that in the future, other CI
support platforms (such as cirrus, appveyor, etc.) could have a common
place to put their requisite scripts without polluting the main tree.
Signed-off-by: Aaron Conole <aconole@redhat.com>
Signed-off-by: Michael Santana <msantana@redhat.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
---
.ci/linux-build.sh | 24 +++++++
.ci/linux-setup.sh | 3 +
.travis.yml | 99 +++++++++++++++++++++++++++++
MAINTAINERS | 6 ++
doc/guides/contributing/patches.rst | 4 ++
5 files changed, 136 insertions(+)
create mode 100755 .ci/linux-build.sh
create mode 100755 .ci/linux-setup.sh
create mode 100644 .travis.yml
diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
new file mode 100755
index 000000000..767840e40
--- /dev/null
+++ b/.ci/linux-build.sh
@@ -0,0 +1,24 @@
+#!/bin/sh -xe
+
+on_error() {
+ if [ $? = 0 ]; then
+ exit
+ fi
+ FILES_TO_PRINT="build/meson-logs/testlog.txt build/.ninja_log build/meson-logs/meson-log.txt"
+
+ for pr_file in $FILES_TO_PRINT; do
+ if [ -e "$pr_file" ]; then
+ cat "$pr_file"
+ fi
+ done
+}
+trap on_error EXIT
+
+if [ "$AARCH64" = "1" ]; then
+ # convert the arch specifier
+ OPTS="$OPTS --cross-file config/arm/arm64_armv8_linuxapp_gcc"
+fi
+
+OPTS="$OPTS --default-library=$DEF_LIB"
+meson build --werror -Dexamples=all $OPTS
+ninja -C build
diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh
new file mode 100755
index 000000000..acdf9f370
--- /dev/null
+++ b/.ci/linux-setup.sh
@@ -0,0 +1,3 @@
+#!/bin/sh
+
+python3 -m pip install --upgrade meson --user
diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 000000000..3045eada5
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,99 @@
+language: c
+compiler:
+ - gcc
+ - clang
+
+dist: xenial
+
+os:
+ - linux
+
+addons:
+ apt:
+ update: true
+ packages: &required_packages
+ - [libnuma-dev, linux-headers-$(uname -r), python3-setuptools, python3-wheel, python3-pip, ninja-build]
+
+aarch64_packages: &aarch64_packages
+ - *required_packages
+ - [gcc-aarch64-linux-gnu, libc6-dev-arm64-cross]
+
+extra_packages: &extra_packages
+ - *required_packages
+ - [libbsd-dev, libpcap-dev, libcrypto++-dev, libjansson4]
+
+before_install: ./.ci/${TRAVIS_OS_NAME}-setup.sh
+
+sudo: false
+
+env:
+ - DEF_LIB="static"
+ - DEF_LIB="shared"
+ - DEF_LIB="static" OPTS="-Denable_kmods=false"
+ - DEF_LIB="shared" OPTS="-Denable_kmods=false"
+
+matrix:
+ include:
+ - env: DEF_LIB="static" OPTS="-Denable_kmods=false" AARCH64=1
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - *aarch64_packages
+ - env: DEF_LIB="shared" OPTS="-Denable_kmods=false" AARCH64=1
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - *aarch64_packages
+ - env: DEF_LIB="static"
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - *extra_packages
+ - env: DEF_LIB="shared"
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - *extra_packages
+ - env: DEF_LIB="static" OPTS="-Denable_kmods=false"
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - *extra_packages
+ - env: DEF_LIB="shared" OPTS="-Denable_kmods=false"
+ compiler: gcc
+ addons:
+ apt:
+ packages:
+ - *extra_packages
+ - env: DEF_LIB="static"
+ compiler: clang
+ addons:
+ apt:
+ packages:
+ - *extra_packages
+ - env: DEF_LIB="shared"
+ compiler: clang
+ addons:
+ apt:
+ packages:
+ - *extra_packages
+ - env: DEF_LIB="static" OPTS="-Denable_kmods=false"
+ compiler: clang
+ addons:
+ apt:
+ packages:
+ - *extra_packages
+ - env: DEF_LIB="shared" OPTS="-Denable_kmods=false"
+ compiler: clang
+ addons:
+ apt:
+ packages:
+ - *extra_packages
+
+
+script: ./.ci/${TRAVIS_OS_NAME}-build.sh
diff --git a/MAINTAINERS b/MAINTAINERS
index 15c53888c..e4b9a8e00 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -119,6 +119,12 @@ F: config/rte_config.h
F: buildtools/gen-pmdinfo-cfile.sh
F: buildtools/symlink-drivers-solibs.sh
+Public CI
+M: Aaron Conole <aconole@redhat.com>
+M: Michael Santana <msantana@redhat.com>
+F: .travis.yml
+F: .ci/
+
ABI versioning
M: Neil Horman <nhorman@tuxdriver.com>
F: doc/guides/rel_notes/deprecation.rst
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index 211a5cdc7..22a9039e8 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -32,6 +32,10 @@ The mailing list for DPDK development is `dev@dpdk.org <http://mails.dpdk.org/ar
Contributors will need to `register for the mailing list <http://mails.dpdk.org/listinfo/dev>`_ in order to submit patches.
It is also worth registering for the DPDK `Patchwork <http://patches.dpdk.org/project/dpdk/list/>`_
+If you are using the GitHub service, you can link your repository to
+the ``travis-ci.org`` build service. When you push patches to your GitHub
+repository, the travis service will automatically build your changes.
+
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.20.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC PATCH 1/2] ethdev: introduce internal rxq/txq stats API
2019-03-19 17:18 4% ` Ferruh Yigit
2019-03-19 17:18 4% ` Ferruh Yigit
2019-03-19 17:54 3% ` Stephen Hemminger
@ 2019-03-26 9:29 0% ` David Marchand
2019-03-26 9:29 0% ` David Marchand
2 siblings, 1 reply; 200+ results
From: David Marchand @ 2019-03-26 9:29 UTC (permalink / raw)
To: Ferruh Yigit, Thomas Monjalon, Andrew Rybchenko
Cc: dev, Stokes, Ian, Stephen Hemminger
On Tue, Mar 19, 2019 at 6:18 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> On 3/14/2019 3:13 PM, David Marchand wrote:
> > Introduce a new api to retrieve per queue statistics from the drivers.
> > The api objectives:
> > - easily add some common per queue statistics and have it exposed
> > through the user xstats api while the user stats api is left untouched
> > - remove the limitations on the per queue statistics count (inherited
> > from ixgbe) and avoid recurrent bugs on stats array overflow
>
> The patch is adding two new dev_ops 'rxq_stats_get' & 'txq_stats_get', my
> concern is if it is overkill to have three dev_ops to get stats
> and I am feeling that is making xstat code more complex.
>
Having these new (meant to be) internal dev_ops has the avantage of
separating the statistics reported from the drivers from the exported api.
This is also why I did not prefix the structure names with rte_.
The "complex" part is in a single place, ethdev and this is when
translating from an internal representation to the exposed bits in the
public apis.
Would it be simpler to add 'q_ierrors' & 'q_oerrors' to 'struct
> rte_eth_stats'?
>
It does not solve the problem of drivers that are buggy because of the
limit on RTE_ETHDEV_QUEUE_STAT_CNTRS.
All drivers need to be aware of this limitation of the rte_eth_stats
structure.
The drivers manipulate queues in rx/tx_queue_setup dev_ops for example,
having rxq/txq_stats_get dev_ops is more consistent to me.
> And perhaps we can do the 'fix rxq q_errors' patchset [1] after this
> change, so
> fix can be done with less changes, although it will push the fix into next
> release because of the ABI break.
>
I am fine with merging this together, we don't want to backport this
anyway, right?
But so far, I don't feel the need to break the rte_eth_stats_get API, if we
want to go to this, we can define an entirely new api to expose
standardized bits and still use the rxq/txq_stats_get internal dev_ops I
propose.
Thomas, Andrew, can you provide feedback please ?
rc1 is coming.
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC PATCH 1/2] ethdev: introduce internal rxq/txq stats API
2019-03-26 9:29 0% ` David Marchand
@ 2019-03-26 9:29 0% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2019-03-26 9:29 UTC (permalink / raw)
To: Ferruh Yigit, Thomas Monjalon, Andrew Rybchenko
Cc: dev, Stokes, Ian, Stephen Hemminger
On Tue, Mar 19, 2019 at 6:18 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> On 3/14/2019 3:13 PM, David Marchand wrote:
> > Introduce a new api to retrieve per queue statistics from the drivers.
> > The api objectives:
> > - easily add some common per queue statistics and have it exposed
> > through the user xstats api while the user stats api is left untouched
> > - remove the limitations on the per queue statistics count (inherited
> > from ixgbe) and avoid recurrent bugs on stats array overflow
>
> The patch is adding two new dev_ops 'rxq_stats_get' & 'txq_stats_get', my
> concern is if it is overkill to have three dev_ops to get stats
> and I am feeling that is making xstat code more complex.
>
Having these new (meant to be) internal dev_ops has the avantage of
separating the statistics reported from the drivers from the exported api.
This is also why I did not prefix the structure names with rte_.
The "complex" part is in a single place, ethdev and this is when
translating from an internal representation to the exposed bits in the
public apis.
Would it be simpler to add 'q_ierrors' & 'q_oerrors' to 'struct
> rte_eth_stats'?
>
It does not solve the problem of drivers that are buggy because of the
limit on RTE_ETHDEV_QUEUE_STAT_CNTRS.
All drivers need to be aware of this limitation of the rte_eth_stats
structure.
The drivers manipulate queues in rx/tx_queue_setup dev_ops for example,
having rxq/txq_stats_get dev_ops is more consistent to me.
> And perhaps we can do the 'fix rxq q_errors' patchset [1] after this
> change, so
> fix can be done with less changes, although it will push the fix into next
> release because of the ABI break.
>
I am fine with merging this together, we don't want to backport this
anyway, right?
But so far, I don't feel the need to break the rte_eth_stats_get API, if we
want to go to this, we can define an entirely new api to expose
standardized bits and still use the rxq/txq_stats_get internal dev_ops I
propose.
Thomas, Andrew, can you provide feedback please ?
rc1 is coming.
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v5 3/8] kvargs: adding a module definition file
@ 2019-03-26 10:58 3% ` Bruce Richardson
2019-03-26 10:58 3% ` Bruce Richardson
2019-03-26 13:37 0% ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
0 siblings, 2 replies; 200+ results
From: Bruce Richardson @ 2019-03-26 10:58 UTC (permalink / raw)
To: Jerin Jacob Kollanukkaran
Cc: anand.rawat, dev, pallavi.kadam, thomas, ranjit.menon, jeffrey.b.shaw
On Tue, Mar 26, 2019 at 10:32:34AM +0000, Jerin Jacob Kollanukkaran wrote:
> On Mon, 2019-03-25 at 23:02 -0700, Anand Rawat wrote:
> > adding a DEF file for kvargs to specify the exports
> > for the creation of the shared library.
> >
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > Signed-off-by: Anand Rawat <anand.rawat@intel.com>
> > Reviewed-by: Pallavi Kadam <pallavi.kadam@intel.com>
> > Reviewed-by: Ranjit Menon <ranjit.menon@intel.com>
> > ---
> > lib/librte_kvargs/rte_kvargs_exports.def | 7 +++++++
> > 1 file changed, 7 insertions(+)
> > create mode 100644 lib/librte_kvargs/rte_kvargs_exports.def
> >
> > diff --git a/lib/librte_kvargs/rte_kvargs_exports.def
> > b/lib/librte_kvargs/rte_kvargs_exports.def
> > new file mode 100644
> > index 000000000..265d3cc9a
> > --- /dev/null
> > +++ b/lib/librte_kvargs/rte_kvargs_exports.def
>
> Maintaining two separate files (.map and .def) for shared
> library definition will be pain full.
>
Yes, though I'd question how much more painful it is than having to update
a separate map file anyway - just consider the number of patches that have
been submitted over the years which failed shared library build because map
file updates were forgotten.
However, my hope is that down the road we can have the def file generated
from the map file (or potentially vice versa). Perhaps the meson python
module could be used to allow us to script it a bit.
> # Is it possible to add neutral file format if windows is not happy
> with .map file?
> # I am not sure, How we can express "EXPERIMENTAL" tag with .def file.
> # It is good to check, How OTHER cross platform libraries addressing
> this problem
>
A wider question is whether it is possible at all to have ABI versions
associated with functions? I didn't find any mention of it in the
documentations, and if it's not possible, then the question of how to put
an experimental version is moot, I think.
/Bruce
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v5 3/8] kvargs: adding a module definition file
2019-03-26 10:58 3% ` Bruce Richardson
@ 2019-03-26 10:58 3% ` Bruce Richardson
2019-03-26 13:37 0% ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
1 sibling, 0 replies; 200+ results
From: Bruce Richardson @ 2019-03-26 10:58 UTC (permalink / raw)
To: Jerin Jacob Kollanukkaran
Cc: anand.rawat, dev, pallavi.kadam, thomas, ranjit.menon, jeffrey.b.shaw
On Tue, Mar 26, 2019 at 10:32:34AM +0000, Jerin Jacob Kollanukkaran wrote:
> On Mon, 2019-03-25 at 23:02 -0700, Anand Rawat wrote:
> > adding a DEF file for kvargs to specify the exports
> > for the creation of the shared library.
> >
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > Signed-off-by: Anand Rawat <anand.rawat@intel.com>
> > Reviewed-by: Pallavi Kadam <pallavi.kadam@intel.com>
> > Reviewed-by: Ranjit Menon <ranjit.menon@intel.com>
> > ---
> > lib/librte_kvargs/rte_kvargs_exports.def | 7 +++++++
> > 1 file changed, 7 insertions(+)
> > create mode 100644 lib/librte_kvargs/rte_kvargs_exports.def
> >
> > diff --git a/lib/librte_kvargs/rte_kvargs_exports.def
> > b/lib/librte_kvargs/rte_kvargs_exports.def
> > new file mode 100644
> > index 000000000..265d3cc9a
> > --- /dev/null
> > +++ b/lib/librte_kvargs/rte_kvargs_exports.def
>
> Maintaining two separate files (.map and .def) for shared
> library definition will be pain full.
>
Yes, though I'd question how much more painful it is than having to update
a separate map file anyway - just consider the number of patches that have
been submitted over the years which failed shared library build because map
file updates were forgotten.
However, my hope is that down the road we can have the def file generated
from the map file (or potentially vice versa). Perhaps the meson python
module could be used to allow us to script it a bit.
> # Is it possible to add neutral file format if windows is not happy
> with .map file?
> # I am not sure, How we can express "EXPERIMENTAL" tag with .def file.
> # It is good to check, How OTHER cross platform libraries addressing
> this problem
>
A wider question is whether it is possible at all to have ABI versions
associated with functions? I didn't find any mention of it in the
documentations, and if it's not possible, then the question of how to put
an experimental version is moot, I think.
/Bruce
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v6 0/5] Introduce AF_XDP PMD
` (4 preceding siblings ...)
2019-03-25 6:03 2% ` [dpdk-dev] [PATCH v5 " Xiaolong Ye
@ 2019-03-26 12:20 2% ` Xiaolong Ye
2019-03-26 12:20 2% ` Xiaolong Ye
2019-03-27 9:00 2% ` [dpdk-dev] [PATCH v7 " Xiaolong Ye
` (2 subsequent siblings)
8 siblings, 1 reply; 200+ results
From: Xiaolong Ye @ 2019-03-26 12:20 UTC (permalink / raw)
To: dev, David Marchand, Andrew Rybchenko
Cc: Qi Zhang, Karlsson Magnus, Topel Bjorn, Maxime Coquelin,
Stephen Hemminger, Ferruh Yigit, Luca Boccassi, Bruce Richardson,
Ananyev Konstantin, Xiaolong Ye
Overview
========
This patchset adds a new PMD driver for AF_XDP which is a proposed
faster version of AF_PACKET interface in Linux, see below links [1] [2] for
details of AF_XDP introduction:
AF_XDP roadmap
==============
- AF_XDP is included in upstream kernel since 4.18, and AF_XDP support
in libbpf has been merged in v5.1-rc1.
- Now i40e and ixgbe drivers have supported zero copy mode.
Change logs
===========
V6:
- remove the newline in AF_XDP_LOG definition to avoid double new lines
issue.
- rename MEMPOOL_F_PAGE_ALIGN to MEMPOOL_CHUNK_F_PAGE_ALIGN.
V5:
- disable AF_XDP pmd by default due to it requires kernel more recent
than minimum kernel version supported by DPDK
- address other review comments of Maxime
V4:
- change vdev name to net_af_xdp
- adopt dynamic log type for all logging
- Fix other style issues raised by Stephen
V3:
- Fix all style issues pointed by Stephen, Mattias, David.
- Drop the testpmd change as we'll adopt Jerin's suggestion to add a new
mempool driver to handle the application use of AF_XDP's zero copy feature.
V2:
- Fix a NULL pointer reference crash issue
- Fix txonly stop sending traffic in zc mode
- Refactor rte_mbuf.c to avoid ABI breakage.
- Fix multiple style issues pointed by Ferruh, David, Stephen, Luca.
changes vs RFC sent by Qi last Aug:
- Re-work base on AF_XDP's interface changes since the new libbpf has
provided higher-level APIs that hide many of the details of the AP_XDP
uapi. After the rework, it helps to reduce 300+ lines of code.
- multi-queues is not supported due to current libbpf doesn't support
multi-sockets on a single umem.
- No extra steps to load xdp program manually, since the current behavior of
libbpf would load a default xdp program when user calls xsk_socket__create.
userspace application only needs to handle the cleanup.
How to try
==========
1. take the kernel >= v5.1-rc1, build kernel and replace your host
kernel with it.
make sure you turn on XDP sockets when compiling
Networking support -->
Networking options -->
[ * ] XDP sockets
2. build libbpf in tools/lib/bpf, and copy the libbpf.a and libbpf.so to /usr/lib64
cd tools/lib/bpf
make
3. ethtool -L enp59s0f0 combined 1
4. extra step to build dpdk
explicitly enable AF_XDP pmd by adding below line to
config/common_linux
CONFIG_RTE_LIBRTE_PMD_AF_XDP=y
5. start testpmd
./build/app/testpmd -c 0xc -n 4 --vdev net_af_xdp,iface=enp59s0f0,queue=0 -- -i --rxq=1 --txq=1
in this case, default xdp program will be loaded and linked to queue 0 of enp59s0f0,
network traffics travel to queue 0 will be redirected to af_xdp socket.
Xiaolong Ye (5):
net/af_xdp: introduce AF XDP PMD driver
lib/mbuf: introduce helper to create mempool with flags
lib/mempool: allow page size aligned mempool
net/af_xdp: use mbuf mempool for buffer management
net/af_xdp: enable zero copy
MAINTAINERS | 6 +
config/common_base | 5 +
doc/guides/nics/af_xdp.rst | 45 +
doc/guides/nics/features/af_xdp.ini | 11 +
doc/guides/nics/index.rst | 1 +
doc/guides/rel_notes/release_19_05.rst | 7 +
drivers/net/Makefile | 1 +
drivers/net/af_xdp/Makefile | 32 +
drivers/net/af_xdp/meson.build | 21 +
drivers/net/af_xdp/rte_eth_af_xdp.c | 1020 +++++++++++++++++
drivers/net/af_xdp/rte_pmd_af_xdp_version.map | 3 +
drivers/net/meson.build | 1 +
lib/librte_mbuf/rte_mbuf.c | 29 +-
lib/librte_mbuf/rte_mbuf.h | 45 +
lib/librte_mbuf/rte_mbuf_version.map | 1 +
lib/librte_mempool/rte_mempool.c | 3 +
lib/librte_mempool/rte_mempool.h | 1 +
mk/rte.app.mk | 1 +
18 files changed, 1228 insertions(+), 5 deletions(-)
create mode 100644 doc/guides/nics/af_xdp.rst
create mode 100644 doc/guides/nics/features/af_xdp.ini
create mode 100644 drivers/net/af_xdp/Makefile
create mode 100644 drivers/net/af_xdp/meson.build
create mode 100644 drivers/net/af_xdp/rte_eth_af_xdp.c
create mode 100644 drivers/net/af_xdp/rte_pmd_af_xdp_version.map
--
2.17.1
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v6 0/5] Introduce AF_XDP PMD
2019-03-26 12:20 2% ` [dpdk-dev] [PATCH v6 " Xiaolong Ye
@ 2019-03-26 12:20 2% ` Xiaolong Ye
0 siblings, 0 replies; 200+ results
From: Xiaolong Ye @ 2019-03-26 12:20 UTC (permalink / raw)
To: dev, David Marchand, Andrew Rybchenko
Cc: Qi Zhang, Karlsson Magnus, Topel Bjorn, Maxime Coquelin,
Stephen Hemminger, Ferruh Yigit, Luca Boccassi, Bruce Richardson,
Ananyev Konstantin, Xiaolong Ye
Overview
========
This patchset adds a new PMD driver for AF_XDP which is a proposed
faster version of AF_PACKET interface in Linux, see below links [1] [2] for
details of AF_XDP introduction:
AF_XDP roadmap
==============
- AF_XDP is included in upstream kernel since 4.18, and AF_XDP support
in libbpf has been merged in v5.1-rc1.
- Now i40e and ixgbe drivers have supported zero copy mode.
Change logs
===========
V6:
- remove the newline in AF_XDP_LOG definition to avoid double new lines
issue.
- rename MEMPOOL_F_PAGE_ALIGN to MEMPOOL_CHUNK_F_PAGE_ALIGN.
V5:
- disable AF_XDP pmd by default due to it requires kernel more recent
than minimum kernel version supported by DPDK
- address other review comments of Maxime
V4:
- change vdev name to net_af_xdp
- adopt dynamic log type for all logging
- Fix other style issues raised by Stephen
V3:
- Fix all style issues pointed by Stephen, Mattias, David.
- Drop the testpmd change as we'll adopt Jerin's suggestion to add a new
mempool driver to handle the application use of AF_XDP's zero copy feature.
V2:
- Fix a NULL pointer reference crash issue
- Fix txonly stop sending traffic in zc mode
- Refactor rte_mbuf.c to avoid ABI breakage.
- Fix multiple style issues pointed by Ferruh, David, Stephen, Luca.
changes vs RFC sent by Qi last Aug:
- Re-work base on AF_XDP's interface changes since the new libbpf has
provided higher-level APIs that hide many of the details of the AP_XDP
uapi. After the rework, it helps to reduce 300+ lines of code.
- multi-queues is not supported due to current libbpf doesn't support
multi-sockets on a single umem.
- No extra steps to load xdp program manually, since the current behavior of
libbpf would load a default xdp program when user calls xsk_socket__create.
userspace application only needs to handle the cleanup.
How to try
==========
1. take the kernel >= v5.1-rc1, build kernel and replace your host
kernel with it.
make sure you turn on XDP sockets when compiling
Networking support -->
Networking options -->
[ * ] XDP sockets
2. build libbpf in tools/lib/bpf, and copy the libbpf.a and libbpf.so to /usr/lib64
cd tools/lib/bpf
make
3. ethtool -L enp59s0f0 combined 1
4. extra step to build dpdk
explicitly enable AF_XDP pmd by adding below line to
config/common_linux
CONFIG_RTE_LIBRTE_PMD_AF_XDP=y
5. start testpmd
./build/app/testpmd -c 0xc -n 4 --vdev net_af_xdp,iface=enp59s0f0,queue=0 -- -i --rxq=1 --txq=1
in this case, default xdp program will be loaded and linked to queue 0 of enp59s0f0,
network traffics travel to queue 0 will be redirected to af_xdp socket.
Xiaolong Ye (5):
net/af_xdp: introduce AF XDP PMD driver
lib/mbuf: introduce helper to create mempool with flags
lib/mempool: allow page size aligned mempool
net/af_xdp: use mbuf mempool for buffer management
net/af_xdp: enable zero copy
MAINTAINERS | 6 +
config/common_base | 5 +
doc/guides/nics/af_xdp.rst | 45 +
doc/guides/nics/features/af_xdp.ini | 11 +
doc/guides/nics/index.rst | 1 +
doc/guides/rel_notes/release_19_05.rst | 7 +
drivers/net/Makefile | 1 +
drivers/net/af_xdp/Makefile | 32 +
drivers/net/af_xdp/meson.build | 21 +
drivers/net/af_xdp/rte_eth_af_xdp.c | 1020 +++++++++++++++++
drivers/net/af_xdp/rte_pmd_af_xdp_version.map | 3 +
drivers/net/meson.build | 1 +
lib/librte_mbuf/rte_mbuf.c | 29 +-
lib/librte_mbuf/rte_mbuf.h | 45 +
lib/librte_mbuf/rte_mbuf_version.map | 1 +
lib/librte_mempool/rte_mempool.c | 3 +
lib/librte_mempool/rte_mempool.h | 1 +
mk/rte.app.mk | 1 +
18 files changed, 1228 insertions(+), 5 deletions(-)
create mode 100644 doc/guides/nics/af_xdp.rst
create mode 100644 doc/guides/nics/features/af_xdp.ini
create mode 100644 drivers/net/af_xdp/Makefile
create mode 100644 drivers/net/af_xdp/meson.build
create mode 100644 drivers/net/af_xdp/rte_eth_af_xdp.c
create mode 100644 drivers/net/af_xdp/rte_pmd_af_xdp_version.map
--
2.17.1
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [EXT] Re: [PATCH v5 3/8] kvargs: adding a module definition file
2019-03-26 10:58 3% ` Bruce Richardson
2019-03-26 10:58 3% ` Bruce Richardson
@ 2019-03-26 13:37 0% ` Jerin Jacob Kollanukkaran
2019-03-26 13:37 0% ` Jerin Jacob Kollanukkaran
1 sibling, 1 reply; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-03-26 13:37 UTC (permalink / raw)
To: bruce.richardson
Cc: pallavi.kadam, thomas, anand.rawat, dev, ranjit.menon, jeffrey.b.shaw
On Tue, 2019-03-26 at 10:58 +0000, Bruce Richardson wrote:
> -------------------------------------------------------------------
> ---
> On Tue, Mar 26, 2019 at 10:32:34AM +0000, Jerin Jacob Kollanukkaran
> wrote:
> > On Mon, 2019-03-25 at 23:02 -0700, Anand Rawat wrote:
> > > adding a DEF file for kvargs to specify the exports
> > > for the creation of the shared library.
> > >
> > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > Signed-off-by: Anand Rawat <anand.rawat@intel.com>
> > > Reviewed-by: Pallavi Kadam <pallavi.kadam@intel.com>
> > > Reviewed-by: Ranjit Menon <ranjit.menon@intel.com>
> > > ---
> > > lib/librte_kvargs/rte_kvargs_exports.def | 7 +++++++
> > > 1 file changed, 7 insertions(+)
> > > create mode 100644 lib/librte_kvargs/rte_kvargs_exports.def
> > >
> > > diff --git a/lib/librte_kvargs/rte_kvargs_exports.def
> > > b/lib/librte_kvargs/rte_kvargs_exports.def
> > > new file mode 100644
> > > index 000000000..265d3cc9a
> > > --- /dev/null
> > > +++ b/lib/librte_kvargs/rte_kvargs_exports.def
> >
> > Maintaining two separate files (.map and .def) for shared
> > library definition will be pain full.
> >
>
> Yes, though I'd question how much more painful it is than having to
> update
> a separate map file anyway - just consider the number of patches that
It is painful due to the fact that, If it is windows ONLY file then
developer need to test on Windows as well as it may break Windows.
If it is a common file, at least, it will be tested on one platform.
So responsibly wise it is a clean partition between windows eal
maintainers vs generic library maintainers.
> have
> been submitted over the years which failed shared library build
> because map
> file updates were forgotten.
>
> However, my hope is that down the road we can have the def file
> generated
> from the map file (or potentially vice versa). Perhaps the meson
> python
> module could be used to allow us to script it a bit.
Make sense. Do we want to support shared lib for Windows for the first
version? or Can we live with static lib till we find a proper solution.
I do believe the base Windows Helloworld support needs to added this
release in main repo and add the subsequent features step by step.
I would treat, shared lib as subsequent feature if it is not clean.
>
> > # Is it possible to add neutral file format if windows is not happy
> > with .map file?
> > # I am not sure, How we can express "EXPERIMENTAL" tag with .def
> > file.
> > # It is good to check, How OTHER cross platform libraries
> > addressing
> > this problem
> >
> A wider question is whether it is possible at all to have ABI
> versions
> associated with functions? I didn't find any mention of it in the
> documentations, and if it's not possible, then the question of how to
> put
> an experimental version is moot, I think.
Yes, Waiting for the comments from Wider audience.
>
> /Bruce
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [EXT] Re: [PATCH v5 3/8] kvargs: adding a module definition file
2019-03-26 13:37 0% ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
@ 2019-03-26 13:37 0% ` Jerin Jacob Kollanukkaran
0 siblings, 0 replies; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-03-26 13:37 UTC (permalink / raw)
To: bruce.richardson
Cc: pallavi.kadam, thomas, anand.rawat, dev, ranjit.menon, jeffrey.b.shaw
On Tue, 2019-03-26 at 10:58 +0000, Bruce Richardson wrote:
> -------------------------------------------------------------------
> ---
> On Tue, Mar 26, 2019 at 10:32:34AM +0000, Jerin Jacob Kollanukkaran
> wrote:
> > On Mon, 2019-03-25 at 23:02 -0700, Anand Rawat wrote:
> > > adding a DEF file for kvargs to specify the exports
> > > for the creation of the shared library.
> > >
> > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > Signed-off-by: Anand Rawat <anand.rawat@intel.com>
> > > Reviewed-by: Pallavi Kadam <pallavi.kadam@intel.com>
> > > Reviewed-by: Ranjit Menon <ranjit.menon@intel.com>
> > > ---
> > > lib/librte_kvargs/rte_kvargs_exports.def | 7 +++++++
> > > 1 file changed, 7 insertions(+)
> > > create mode 100644 lib/librte_kvargs/rte_kvargs_exports.def
> > >
> > > diff --git a/lib/librte_kvargs/rte_kvargs_exports.def
> > > b/lib/librte_kvargs/rte_kvargs_exports.def
> > > new file mode 100644
> > > index 000000000..265d3cc9a
> > > --- /dev/null
> > > +++ b/lib/librte_kvargs/rte_kvargs_exports.def
> >
> > Maintaining two separate files (.map and .def) for shared
> > library definition will be pain full.
> >
>
> Yes, though I'd question how much more painful it is than having to
> update
> a separate map file anyway - just consider the number of patches that
It is painful due to the fact that, If it is windows ONLY file then
developer need to test on Windows as well as it may break Windows.
If it is a common file, at least, it will be tested on one platform.
So responsibly wise it is a clean partition between windows eal
maintainers vs generic library maintainers.
> have
> been submitted over the years which failed shared library build
> because map
> file updates were forgotten.
>
> However, my hope is that down the road we can have the def file
> generated
> from the map file (or potentially vice versa). Perhaps the meson
> python
> module could be used to allow us to script it a bit.
Make sense. Do we want to support shared lib for Windows for the first
version? or Can we live with static lib till we find a proper solution.
I do believe the base Windows Helloworld support needs to added this
release in main repo and add the subsequent features step by step.
I would treat, shared lib as subsequent feature if it is not clean.
>
> > # Is it possible to add neutral file format if windows is not happy
> > with .map file?
> > # I am not sure, How we can express "EXPERIMENTAL" tag with .def
> > file.
> > # It is good to check, How OTHER cross platform libraries
> > addressing
> > this problem
> >
> A wider question is whether it is possible at all to have ABI
> versions
> associated with functions? I didn't find any mention of it in the
> documentations, and if it's not possible, then the question of how to
> put
> an experimental version is moot, I think.
Yes, Waiting for the comments from Wider audience.
>
> /Bruce
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3] crypto/aesni_mb: support newer version library only
@ 2019-03-26 15:35 3% ` Zhang, Roy Fan
2019-03-26 15:35 3% ` Zhang, Roy Fan
2019-03-26 15:43 0% ` Akhil Goyal
0 siblings, 2 replies; 200+ results
From: Zhang, Roy Fan @ 2019-03-26 15:35 UTC (permalink / raw)
To: Akhil Goyal, dev; +Cc: De Lara Guarch, Pablo, Yigit, Ferruh
Hi Akhil,
I have discussed with Ferruh in relation to the updating release note
for this change.
However the change seems not apply to any section under the release note.
The change does not introduce new feature, nor breaks ABI/API -
it only changes the requirement of the dependent external library version,
and makefile/meson will pop up error when the library version is too old and
prevents compiling.
Regards,
Fan
> -----Original Message-----
> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> Sent: Tuesday, March 26, 2019 9:11 AM
> To: Zhang, Roy Fan <roy.fan.zhang@intel.com>; dev@dpdk.org
> Cc: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v3] crypto/aesni_mb: support newer version
> library only
> >
> I think this deserve to be updated in the release note as well.
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v3] crypto/aesni_mb: support newer version library only
2019-03-26 15:35 3% ` Zhang, Roy Fan
@ 2019-03-26 15:35 3% ` Zhang, Roy Fan
2019-03-26 15:43 0% ` Akhil Goyal
1 sibling, 0 replies; 200+ results
From: Zhang, Roy Fan @ 2019-03-26 15:35 UTC (permalink / raw)
To: Akhil Goyal, dev; +Cc: De Lara Guarch, Pablo, Yigit, Ferruh
Hi Akhil,
I have discussed with Ferruh in relation to the updating release note
for this change.
However the change seems not apply to any section under the release note.
The change does not introduce new feature, nor breaks ABI/API -
it only changes the requirement of the dependent external library version,
and makefile/meson will pop up error when the library version is too old and
prevents compiling.
Regards,
Fan
> -----Original Message-----
> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> Sent: Tuesday, March 26, 2019 9:11 AM
> To: Zhang, Roy Fan <roy.fan.zhang@intel.com>; dev@dpdk.org
> Cc: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v3] crypto/aesni_mb: support newer version
> library only
> >
> I think this deserve to be updated in the release note as well.
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v3] crypto/aesni_mb: support newer version library only
2019-03-26 15:35 3% ` Zhang, Roy Fan
2019-03-26 15:35 3% ` Zhang, Roy Fan
@ 2019-03-26 15:43 0% ` Akhil Goyal
2019-03-26 15:43 0% ` Akhil Goyal
2019-03-29 14:38 0% ` Akhil Goyal
1 sibling, 2 replies; 200+ results
From: Akhil Goyal @ 2019-03-26 15:43 UTC (permalink / raw)
To: Zhang, Roy Fan, dev; +Cc: De Lara Guarch, Pablo, Yigit, Ferruh
On 3/26/2019 9:05 PM, Zhang, Roy Fan wrote:
> Hi Akhil,
>
> I have discussed with Ferruh in relation to the updating release note
> for this change.
> However the change seems not apply to any section under the release note.
>
> The change does not introduce new feature, nor breaks ABI/API -
> it only changes the requirement of the dependent external library version,
> and makefile/meson will pop up error when the library version is too old and
> prevents compiling.
>
> Regards,
> Fan
ok. I will pick the patch.
>
>> -----Original Message-----
>> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
>> Sent: Tuesday, March 26, 2019 9:11 AM
>> To: Zhang, Roy Fan <roy.fan.zhang@intel.com>; dev@dpdk.org
>> Cc: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
>> Subject: Re: [dpdk-dev] [PATCH v3] crypto/aesni_mb: support newer version
>> library only
>> I think this deserve to be updated in the release note as well.
>>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3] crypto/aesni_mb: support newer version library only
2019-03-26 15:43 0% ` Akhil Goyal
@ 2019-03-26 15:43 0% ` Akhil Goyal
2019-03-29 14:38 0% ` Akhil Goyal
1 sibling, 0 replies; 200+ results
From: Akhil Goyal @ 2019-03-26 15:43 UTC (permalink / raw)
To: Zhang, Roy Fan, dev; +Cc: De Lara Guarch, Pablo, Yigit, Ferruh
On 3/26/2019 9:05 PM, Zhang, Roy Fan wrote:
> Hi Akhil,
>
> I have discussed with Ferruh in relation to the updating release note
> for this change.
> However the change seems not apply to any section under the release note.
>
> The change does not introduce new feature, nor breaks ABI/API -
> it only changes the requirement of the dependent external library version,
> and makefile/meson will pop up error when the library version is too old and
> prevents compiling.
>
> Regards,
> Fan
ok. I will pick the patch.
>
>> -----Original Message-----
>> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
>> Sent: Tuesday, March 26, 2019 9:11 AM
>> To: Zhang, Roy Fan <roy.fan.zhang@intel.com>; dev@dpdk.org
>> Cc: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
>> Subject: Re: [dpdk-dev] [PATCH v3] crypto/aesni_mb: support newer version
>> library only
>> I think this deserve to be updated in the release note as well.
>>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v7 0/5] Introduce AF_XDP PMD
` (5 preceding siblings ...)
2019-03-26 12:20 2% ` [dpdk-dev] [PATCH v6 " Xiaolong Ye
@ 2019-03-27 9:00 2% ` Xiaolong Ye
2019-03-27 9:00 2% ` Xiaolong Ye
2019-04-02 10:45 2% ` [dpdk-dev] [PATCH v8 0/1] " Xiaolong Ye
2019-04-02 15:46 2% ` [dpdk-dev] [PATCH v9 0/1] Introduce " Xiaolong Ye
8 siblings, 1 reply; 200+ results
From: Xiaolong Ye @ 2019-03-27 9:00 UTC (permalink / raw)
To: dev, David Marchand, Andrew Rybchenko
Cc: Qi Zhang, Karlsson Magnus, Topel Bjorn, Maxime Coquelin,
Stephen Hemminger, Ferruh Yigit, Luca Boccassi, Bruce Richardson,
Ananyev Konstantin, Xiaolong Ye
Overview
========
This patchset adds a new PMD driver for AF_XDP which is a proposed
faster version of AF_PACKET interface in Linux, see below links [1] [2] for
details of AF_XDP introduction:
AF_XDP roadmap
==============
- AF_XDP is included in upstream kernel since 4.18, and AF_XDP support
in libbpf has been merged in v5.1-rc1.
- Now i40e and ixgbe drivers have supported zero copy mode.
Change logs
===========
v7:
- mention mtu limitation in af_xdp.rst
- fix the vdev name in af_xdp.rst
V6:
- remove the newline in AF_XDP_LOG definition to avoid double new lines
issue.
- rename MEMPOOL_F_PAGE_ALIGN to MEMPOOL_CHUNK_F_PAGE_ALIGN.
V5:
- disable AF_XDP pmd by default due to it requires kernel more recent
than minimum kernel version supported by DPDK
- address other review comments of Maxime
V4:
- change vdev name to net_af_xdp
- adopt dynamic log type for all logging
- Fix other style issues raised by Stephen
V3:
- Fix all style issues pointed by Stephen, Mattias, David.
- Drop the testpmd change as we'll adopt Jerin's suggestion to add a new
mempool driver to handle the application use of AF_XDP's zero copy feature.
V2:
- Fix a NULL pointer reference crash issue
- Fix txonly stop sending traffic in zc mode
- Refactor rte_mbuf.c to avoid ABI breakage.
- Fix multiple style issues pointed by Ferruh, David, Stephen, Luca.
changes vs RFC sent by Qi last Aug:
- Re-work base on AF_XDP's interface changes since the new libbpf has
provided higher-level APIs that hide many of the details of the AP_XDP
uapi. After the rework, it helps to reduce 300+ lines of code.
- multi-queues is not supported due to current libbpf doesn't support
multi-sockets on a single umem.
- No extra steps to load xdp program manually, since the current behavior of
libbpf would load a default xdp program when user calls xsk_socket__create.
userspace application only needs to handle the cleanup.
How to try
==========
1. take the kernel >= v5.1-rc1, build kernel and replace your host
kernel with it.
make sure you turn on XDP sockets when compiling
Networking support -->
Networking options -->
[ * ] XDP sockets
2. build libbpf in tools/lib/bpf, and copy the libbpf.a and libbpf.so to /usr/lib64
cd tools/lib/bpf
make
3. ethtool -L enp59s0f0 combined 1
4. extra step to build dpdk
explicitly enable AF_XDP pmd by adding below line to
config/common_linux
CONFIG_RTE_LIBRTE_PMD_AF_XDP=y
5. start testpmd
./build/app/testpmd -c 0xc -n 4 --vdev net_af_xdp,iface=enp59s0f0,queue=0 -- -i --rxq=1 --txq=1
in this case, default xdp program will be loaded and linked to queue 0 of enp59s0f0,
network traffics travel to queue 0 will be redirected to af_xdp socket.
Xiaolong Ye (5):
net/af_xdp: introduce AF XDP PMD driver
lib/mbuf: introduce helper to create mempool with flags
lib/mempool: allow page size aligned mempool
net/af_xdp: use mbuf mempool for buffer management
net/af_xdp: enable zero copy
MAINTAINERS | 6 +
config/common_base | 5 +
doc/guides/nics/af_xdp.rst | 45 +
doc/guides/nics/features/af_xdp.ini | 11 +
doc/guides/nics/index.rst | 1 +
doc/guides/rel_notes/release_19_05.rst | 7 +
drivers/net/Makefile | 1 +
drivers/net/af_xdp/Makefile | 32 +
drivers/net/af_xdp/meson.build | 21 +
drivers/net/af_xdp/rte_eth_af_xdp.c | 1020 +++++++++++++++++
drivers/net/af_xdp/rte_pmd_af_xdp_version.map | 3 +
drivers/net/meson.build | 1 +
lib/librte_mbuf/rte_mbuf.c | 29 +-
lib/librte_mbuf/rte_mbuf.h | 45 +
lib/librte_mbuf/rte_mbuf_version.map | 1 +
lib/librte_mempool/rte_mempool.c | 3 +
lib/librte_mempool/rte_mempool.h | 1 +
mk/rte.app.mk | 1 +
18 files changed, 1228 insertions(+), 5 deletions(-)
create mode 100644 doc/guides/nics/af_xdp.rst
create mode 100644 doc/guides/nics/features/af_xdp.ini
create mode 100644 drivers/net/af_xdp/Makefile
create mode 100644 drivers/net/af_xdp/meson.build
create mode 100644 drivers/net/af_xdp/rte_eth_af_xdp.c
create mode 100644 drivers/net/af_xdp/rte_pmd_af_xdp_version.map
--
2.17.1
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v7 0/5] Introduce AF_XDP PMD
2019-03-27 9:00 2% ` [dpdk-dev] [PATCH v7 " Xiaolong Ye
@ 2019-03-27 9:00 2% ` Xiaolong Ye
0 siblings, 0 replies; 200+ results
From: Xiaolong Ye @ 2019-03-27 9:00 UTC (permalink / raw)
To: dev, David Marchand, Andrew Rybchenko
Cc: Qi Zhang, Karlsson Magnus, Topel Bjorn, Maxime Coquelin,
Stephen Hemminger, Ferruh Yigit, Luca Boccassi, Bruce Richardson,
Ananyev Konstantin, Xiaolong Ye
Overview
========
This patchset adds a new PMD driver for AF_XDP which is a proposed
faster version of AF_PACKET interface in Linux, see below links [1] [2] for
details of AF_XDP introduction:
AF_XDP roadmap
==============
- AF_XDP is included in upstream kernel since 4.18, and AF_XDP support
in libbpf has been merged in v5.1-rc1.
- Now i40e and ixgbe drivers have supported zero copy mode.
Change logs
===========
v7:
- mention mtu limitation in af_xdp.rst
- fix the vdev name in af_xdp.rst
V6:
- remove the newline in AF_XDP_LOG definition to avoid double new lines
issue.
- rename MEMPOOL_F_PAGE_ALIGN to MEMPOOL_CHUNK_F_PAGE_ALIGN.
V5:
- disable AF_XDP pmd by default due to it requires kernel more recent
than minimum kernel version supported by DPDK
- address other review comments of Maxime
V4:
- change vdev name to net_af_xdp
- adopt dynamic log type for all logging
- Fix other style issues raised by Stephen
V3:
- Fix all style issues pointed by Stephen, Mattias, David.
- Drop the testpmd change as we'll adopt Jerin's suggestion to add a new
mempool driver to handle the application use of AF_XDP's zero copy feature.
V2:
- Fix a NULL pointer reference crash issue
- Fix txonly stop sending traffic in zc mode
- Refactor rte_mbuf.c to avoid ABI breakage.
- Fix multiple style issues pointed by Ferruh, David, Stephen, Luca.
changes vs RFC sent by Qi last Aug:
- Re-work base on AF_XDP's interface changes since the new libbpf has
provided higher-level APIs that hide many of the details of the AP_XDP
uapi. After the rework, it helps to reduce 300+ lines of code.
- multi-queues is not supported due to current libbpf doesn't support
multi-sockets on a single umem.
- No extra steps to load xdp program manually, since the current behavior of
libbpf would load a default xdp program when user calls xsk_socket__create.
userspace application only needs to handle the cleanup.
How to try
==========
1. take the kernel >= v5.1-rc1, build kernel and replace your host
kernel with it.
make sure you turn on XDP sockets when compiling
Networking support -->
Networking options -->
[ * ] XDP sockets
2. build libbpf in tools/lib/bpf, and copy the libbpf.a and libbpf.so to /usr/lib64
cd tools/lib/bpf
make
3. ethtool -L enp59s0f0 combined 1
4. extra step to build dpdk
explicitly enable AF_XDP pmd by adding below line to
config/common_linux
CONFIG_RTE_LIBRTE_PMD_AF_XDP=y
5. start testpmd
./build/app/testpmd -c 0xc -n 4 --vdev net_af_xdp,iface=enp59s0f0,queue=0 -- -i --rxq=1 --txq=1
in this case, default xdp program will be loaded and linked to queue 0 of enp59s0f0,
network traffics travel to queue 0 will be redirected to af_xdp socket.
Xiaolong Ye (5):
net/af_xdp: introduce AF XDP PMD driver
lib/mbuf: introduce helper to create mempool with flags
lib/mempool: allow page size aligned mempool
net/af_xdp: use mbuf mempool for buffer management
net/af_xdp: enable zero copy
MAINTAINERS | 6 +
config/common_base | 5 +
doc/guides/nics/af_xdp.rst | 45 +
doc/guides/nics/features/af_xdp.ini | 11 +
doc/guides/nics/index.rst | 1 +
doc/guides/rel_notes/release_19_05.rst | 7 +
drivers/net/Makefile | 1 +
drivers/net/af_xdp/Makefile | 32 +
drivers/net/af_xdp/meson.build | 21 +
drivers/net/af_xdp/rte_eth_af_xdp.c | 1020 +++++++++++++++++
drivers/net/af_xdp/rte_pmd_af_xdp_version.map | 3 +
drivers/net/meson.build | 1 +
lib/librte_mbuf/rte_mbuf.c | 29 +-
lib/librte_mbuf/rte_mbuf.h | 45 +
lib/librte_mbuf/rte_mbuf_version.map | 1 +
lib/librte_mempool/rte_mempool.c | 3 +
lib/librte_mempool/rte_mempool.h | 1 +
mk/rte.app.mk | 1 +
18 files changed, 1228 insertions(+), 5 deletions(-)
create mode 100644 doc/guides/nics/af_xdp.rst
create mode 100644 doc/guides/nics/features/af_xdp.ini
create mode 100644 drivers/net/af_xdp/Makefile
create mode 100644 drivers/net/af_xdp/meson.build
create mode 100644 drivers/net/af_xdp/rte_eth_af_xdp.c
create mode 100644 drivers/net/af_xdp/rte_pmd_af_xdp_version.map
--
2.17.1
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH] meter: replace color definitions with rte_color values
@ 2019-03-27 15:44 1% Jasvinder Singh
2019-03-27 15:44 1% ` Jasvinder Singh
0 siblings, 1 reply; 200+ results
From: Jasvinder Singh @ 2019-03-27 15:44 UTC (permalink / raw)
To: dev; +Cc: cristian.dumitrescu
This patch implements the changes proposed in the deprecation
note[1].
Replace mulitple color definitions in various places such as
rte_meter.h, rte_tm.h and rte_mtr.h with single rte_color defined
in rte_meter.h.
[1] https://mails.dpdk.org/archives/dev/2019-January/123861.html
Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
---
app/proc-info/main.c | 36 +++---
app/test-pmd/cmdline_mtr.c | 46 +++----
app/test-pmd/cmdline_tm.c | 22 ++--
app/test/test_meter.c | 126 ++++++++++----------
app/test/test_sched.c | 6 +-
doc/guides/rel_notes/deprecation.rst | 5 -
doc/guides/rel_notes/release_19_05.rst | 6 +-
drivers/net/softnic/rte_eth_softnic_cli.c | 14 +--
drivers/net/softnic/rte_eth_softnic_flow.c | 12 +-
drivers/net/softnic/rte_eth_softnic_meter.c | 26 ++--
drivers/net/softnic/rte_eth_softnic_tm.c | 28 ++---
examples/ip_pipeline/cli.c | 20 ++--
examples/qos_meter/main.h | 10 +-
examples/qos_meter/rte_policer.c | 4 +-
examples/qos_meter/rte_policer.h | 12 +-
examples/qos_sched/app_thread.c | 2 +-
lib/librte_ethdev/rte_mtr.c | 2 +-
lib/librte_ethdev/rte_mtr.h | 10 +-
lib/librte_ethdev/rte_mtr_driver.h | 2 +-
lib/librte_ethdev/rte_tm.h | 14 +--
lib/librte_meter/Makefile | 2 +-
lib/librte_meter/meson.build | 2 +-
lib/librte_meter/rte_meter.h | 91 +++++++-------
lib/librte_pipeline/rte_table_action.c | 50 ++++----
lib/librte_pipeline/rte_table_action.h | 8 +-
lib/librte_sched/rte_sched.c | 12 +-
lib/librte_sched/rte_sched.h | 6 +-
27 files changed, 283 insertions(+), 291 deletions(-)
diff --git a/app/proc-info/main.c b/app/proc-info/main.c
index b9acfa9ec..30189d417 100644
--- a/app/proc-info/main.c
+++ b/app/proc-info/main.c
@@ -873,21 +873,21 @@ show_tm(void)
printf(" - mark support:\n");
printf("\t -- vlan dei: GREEN (%d) YELLOW (%d) RED (%d)\n",
- cap.mark_vlan_dei_supported[RTE_TM_GREEN],
- cap.mark_vlan_dei_supported[RTE_TM_YELLOW],
- cap.mark_vlan_dei_supported[RTE_TM_RED]);
+ cap.mark_vlan_dei_supported[RTE_COLOR_GREEN],
+ cap.mark_vlan_dei_supported[RTE_COLOR_YELLOW],
+ cap.mark_vlan_dei_supported[RTE_COLOR_RED]);
printf("\t -- ip ecn tcp: GREEN (%d) YELLOW (%d) RED (%d)\n",
- cap.mark_ip_ecn_tcp_supported[RTE_TM_GREEN],
- cap.mark_ip_ecn_tcp_supported[RTE_TM_YELLOW],
- cap.mark_ip_ecn_tcp_supported[RTE_TM_RED]);
+ cap.mark_ip_ecn_tcp_supported[RTE_COLOR_GREEN],
+ cap.mark_ip_ecn_tcp_supported[RTE_COLOR_YELLOW],
+ cap.mark_ip_ecn_tcp_supported[RTE_COLOR_RED]);
printf("\t -- ip ecn sctp: GREEN (%d) YELLOW (%d) RED (%d)\n",
- cap.mark_ip_ecn_sctp_supported[RTE_TM_GREEN],
- cap.mark_ip_ecn_sctp_supported[RTE_TM_YELLOW],
- cap.mark_ip_ecn_sctp_supported[RTE_TM_RED]);
+ cap.mark_ip_ecn_sctp_supported[RTE_COLOR_GREEN],
+ cap.mark_ip_ecn_sctp_supported[RTE_COLOR_YELLOW],
+ cap.mark_ip_ecn_sctp_supported[RTE_COLOR_RED]);
printf("\t -- ip dscp: GREEN (%d) YELLOW (%d) RED (%d)\n",
- cap.mark_ip_dscp_supported[RTE_TM_GREEN],
- cap.mark_ip_dscp_supported[RTE_TM_YELLOW],
- cap.mark_ip_dscp_supported[RTE_TM_RED]);
+ cap.mark_ip_dscp_supported[RTE_COLOR_GREEN],
+ cap.mark_ip_dscp_supported[RTE_COLOR_YELLOW],
+ cap.mark_ip_dscp_supported[RTE_COLOR_RED]);
printf(" - mask stats (0x%"PRIx64")"
" dynamic update (0x%"PRIx64")\n",
@@ -1004,12 +1004,12 @@ show_tm(void)
" pkts (%"PRIu64") bytes (%"PRIu64")\n"
"\t -- RED:"
" pkts (%"PRIu64") bytes (%"PRIu64")\n",
- stats.leaf.n_pkts_dropped[RTE_TM_GREEN],
- stats.leaf.n_bytes_dropped[RTE_TM_GREEN],
- stats.leaf.n_pkts_dropped[RTE_TM_YELLOW],
- stats.leaf.n_bytes_dropped[RTE_TM_YELLOW],
- stats.leaf.n_pkts_dropped[RTE_TM_RED],
- stats.leaf.n_bytes_dropped[RTE_TM_RED]);
+ stats.leaf.n_pkts_dropped[RTE_COLOR_GREEN],
+ stats.leaf.n_bytes_dropped[RTE_COLOR_GREEN],
+ stats.leaf.n_pkts_dropped[RTE_COLOR_YELLOW],
+ stats.leaf.n_bytes_dropped[RTE_COLOR_YELLOW],
+ stats.leaf.n_pkts_dropped[RTE_COLOR_RED],
+ stats.leaf.n_bytes_dropped[RTE_COLOR_RED]);
}
}
diff --git a/app/test-pmd/cmdline_mtr.c b/app/test-pmd/cmdline_mtr.c
index c506d87ee..ab5c8642d 100644
--- a/app/test-pmd/cmdline_mtr.c
+++ b/app/test-pmd/cmdline_mtr.c
@@ -74,7 +74,7 @@ parse_uint(uint64_t *value, const char *str)
}
static int
-parse_dscp_table_entries(char *str, enum rte_mtr_color **dscp_table)
+parse_dscp_table_entries(char *str, enum rte_color **dscp_table)
{
char *token;
int i = 0;
@@ -84,21 +84,21 @@ parse_dscp_table_entries(char *str, enum rte_mtr_color **dscp_table)
return 0;
/* Allocate memory for dscp table */
- *dscp_table = (enum rte_mtr_color *)malloc(MAX_DSCP_TABLE_ENTRIES *
- sizeof(enum rte_mtr_color));
+ *dscp_table = (enum rte_color *)malloc(MAX_DSCP_TABLE_ENTRIES *
+ sizeof(enum rte_color));
if (*dscp_table == NULL)
return -1;
while (1) {
if (strcmp(token, "G") == 0 ||
strcmp(token, "g") == 0)
- *dscp_table[i++] = RTE_MTR_GREEN;
+ *dscp_table[i++] = RTE_COLOR_GREEN;
else if (strcmp(token, "Y") == 0 ||
strcmp(token, "y") == 0)
- *dscp_table[i++] = RTE_MTR_YELLOW;
+ *dscp_table[i++] = RTE_COLOR_YELLOW;
else if (strcmp(token, "R") == 0 ||
strcmp(token, "r") == 0)
- *dscp_table[i++] = RTE_MTR_RED;
+ *dscp_table[i++] = RTE_COLOR_RED;
else {
free(*dscp_table);
return -1;
@@ -117,7 +117,7 @@ parse_dscp_table_entries(char *str, enum rte_mtr_color **dscp_table)
static int
parse_meter_color_str(char *c_str, uint32_t *use_prev_meter_color,
- enum rte_mtr_color **dscp_table)
+ enum rte_color **dscp_table)
{
char *token;
uint64_t previous_mtr_color = 0;
@@ -182,20 +182,20 @@ parse_policer_action_string(char *p_str, uint32_t action_mask,
return -1;
if (g_color == 0 && (action_mask & 0x1)) {
- actions[RTE_MTR_GREEN] = action;
+ actions[RTE_COLOR_GREEN] = action;
g_color = 1;
} else if (y_color == 0 && (action_mask & 0x2)) {
- actions[RTE_MTR_YELLOW] = action;
+ actions[RTE_COLOR_YELLOW] = action;
y_color = 1;
} else
- actions[RTE_MTR_RED] = action;
+ actions[RTE_COLOR_RED] = action;
}
return 0;
}
static int
parse_multi_token_string(char *t_str, uint16_t *port_id,
- uint32_t *mtr_id, enum rte_mtr_color **dscp_table)
+ uint32_t *mtr_id, enum rte_color **dscp_table)
{
char *token;
uint64_t val;
@@ -782,7 +782,7 @@ static void cmd_create_port_meter_parsed(void *parsed_result,
uint32_t shared = res->shared;
uint32_t use_prev_meter_color = 0;
uint16_t port_id = res->port_id;
- enum rte_mtr_color *dscp_table = NULL;
+ enum rte_color *dscp_table = NULL;
char *c_str = res->meter_input_color;
int ret;
@@ -808,11 +808,11 @@ static void cmd_create_port_meter_parsed(void *parsed_result,
else
params.meter_enable = 0;
- params.action[RTE_MTR_GREEN] =
+ params.action[RTE_COLOR_GREEN] =
string_to_policer_action(res->g_action);
- params.action[RTE_MTR_YELLOW] =
+ params.action[RTE_COLOR_YELLOW] =
string_to_policer_action(res->y_action);
- params.action[RTE_MTR_RED] =
+ params.action[RTE_COLOR_RED] =
string_to_policer_action(res->r_action);
params.stats_mask = res->statistics_mask;
@@ -1134,7 +1134,7 @@ static void cmd_set_port_meter_dscp_table_parsed(void *parsed_result,
{
struct cmd_set_port_meter_dscp_table_result *res = parsed_result;
struct rte_mtr_error error;
- enum rte_mtr_color *dscp_table = NULL;
+ enum rte_color *dscp_table = NULL;
char *t_str = res->token_string;
uint32_t mtr_id = 0;
uint16_t port_id;
@@ -1245,7 +1245,7 @@ static void cmd_set_port_meter_policer_action_parsed(void *parsed_result,
}
/* Allocate memory for policer actions */
- actions = (enum rte_mtr_policer_action *)malloc(RTE_MTR_COLORS *
+ actions = (enum rte_mtr_policer_action *)malloc(RTE_COLORS *
sizeof(enum rte_mtr_policer_action));
if (actions == NULL) {
printf("Memory for policer actions not allocated (error)\n");
@@ -1426,22 +1426,22 @@ static void cmd_show_port_meter_stats_parsed(void *parsed_result,
/* Display stats */
if (stats_mask & RTE_MTR_STATS_N_PKTS_GREEN)
printf("\tPkts G: %" PRIu64 "\n",
- stats.n_pkts[RTE_MTR_GREEN]);
+ stats.n_pkts[RTE_COLOR_GREEN]);
if (stats_mask & RTE_MTR_STATS_N_BYTES_GREEN)
printf("\tBytes G: %" PRIu64 "\n",
- stats.n_bytes[RTE_MTR_GREEN]);
+ stats.n_bytes[RTE_COLOR_GREEN]);
if (stats_mask & RTE_MTR_STATS_N_PKTS_YELLOW)
printf("\tPkts Y: %" PRIu64 "\n",
- stats.n_pkts[RTE_MTR_YELLOW]);
+ stats.n_pkts[RTE_COLOR_YELLOW]);
if (stats_mask & RTE_MTR_STATS_N_BYTES_YELLOW)
printf("\tBytes Y: %" PRIu64 "\n",
- stats.n_bytes[RTE_MTR_YELLOW]);
+ stats.n_bytes[RTE_COLOR_YELLOW]);
if (stats_mask & RTE_MTR_STATS_N_PKTS_RED)
printf("\tPkts R: %" PRIu64 "\n",
- stats.n_pkts[RTE_MTR_RED]);
+ stats.n_pkts[RTE_COLOR_RED]);
if (stats_mask & RTE_MTR_STATS_N_BYTES_RED)
printf("\tBytes R: %" PRIu64 "\n",
- stats.n_bytes[RTE_MTR_RED]);
+ stats.n_bytes[RTE_COLOR_RED]);
if (stats_mask & RTE_MTR_STATS_N_PKTS_DROPPED)
printf("\tPkts DROPPED: %" PRIu64 "\n",
stats.n_pkts_dropped);
diff --git a/app/test-pmd/cmdline_tm.c b/app/test-pmd/cmdline_tm.c
index 101208474..d62a4f544 100644
--- a/app/test-pmd/cmdline_tm.c
+++ b/app/test-pmd/cmdline_tm.c
@@ -296,7 +296,7 @@ static void cmd_show_port_tm_cap_parsed(void *parsed_result,
printf("cap.cman_wred_context_shared_n_contexts_per_node_max %" PRIu32
"\n", cap.cman_wred_context_shared_n_contexts_per_node_max);
- for (i = 0; i < RTE_TM_COLORS; i++) {
+ for (i = 0; i < RTE_COLORS; i++) {
printf("cap.mark_vlan_dei_supported %" PRId32 "\n",
cap.mark_vlan_dei_supported[i]);
printf("cap.mark_ip_ecn_tcp_supported %" PRId32 "\n",
@@ -642,22 +642,22 @@ static void cmd_show_port_tm_node_stats_parsed(void *parsed_result,
stats.n_bytes);
if (stats_mask & RTE_TM_STATS_N_PKTS_GREEN_DROPPED)
printf("\tPkts dropped (green): %" PRIu64 "\n",
- stats.leaf.n_pkts_dropped[RTE_TM_GREEN]);
+ stats.leaf.n_pkts_dropped[RTE_COLOR_GREEN]);
if (stats_mask & RTE_TM_STATS_N_PKTS_YELLOW_DROPPED)
printf("\tPkts dropped (yellow): %" PRIu64 "\n",
- stats.leaf.n_pkts_dropped[RTE_TM_YELLOW]);
+ stats.leaf.n_pkts_dropped[RTE_COLOR_YELLOW]);
if (stats_mask & RTE_TM_STATS_N_PKTS_RED_DROPPED)
printf("\tPkts dropped (red): %" PRIu64 "\n",
- stats.leaf.n_pkts_dropped[RTE_TM_RED]);
+ stats.leaf.n_pkts_dropped[RTE_COLOR_RED]);
if (stats_mask & RTE_TM_STATS_N_BYTES_GREEN_DROPPED)
printf("\tBytes dropped (green): %" PRIu64 "\n",
- stats.leaf.n_bytes_dropped[RTE_TM_GREEN]);
+ stats.leaf.n_bytes_dropped[RTE_COLOR_GREEN]);
if (stats_mask & RTE_TM_STATS_N_BYTES_YELLOW_DROPPED)
printf("\tBytes dropped (yellow): %" PRIu64 "\n",
- stats.leaf.n_bytes_dropped[RTE_TM_YELLOW]);
+ stats.leaf.n_bytes_dropped[RTE_COLOR_YELLOW]);
if (stats_mask & RTE_TM_STATS_N_BYTES_RED_DROPPED)
printf("\tBytes dropped (red): %" PRIu64 "\n",
- stats.leaf.n_bytes_dropped[RTE_TM_RED]);
+ stats.leaf.n_bytes_dropped[RTE_COLOR_RED]);
if (stats_mask & RTE_TM_STATS_N_PKTS_QUEUED)
printf("\tPkts queued: %" PRIu64 "\n",
stats.leaf.n_pkts_queued);
@@ -1267,7 +1267,7 @@ static void cmd_add_port_tm_node_wred_profile_parsed(void *parsed_result,
{
struct cmd_add_port_tm_node_wred_profile_result *res = parsed_result;
struct rte_tm_wred_params wp;
- enum rte_tm_color color;
+ enum rte_color color;
struct rte_tm_error error;
uint32_t wred_profile_id = res->wred_profile_id;
portid_t port_id = res->port_id;
@@ -1280,7 +1280,7 @@ static void cmd_add_port_tm_node_wred_profile_parsed(void *parsed_result,
memset(&error, 0, sizeof(struct rte_tm_error));
/* WRED Params (Green Color)*/
- color = RTE_TM_GREEN;
+ color = RTE_COLOR_GREEN;
wp.red_params[color].min_th = res->min_th_g;
wp.red_params[color].max_th = res->max_th_g;
wp.red_params[color].maxp_inv = res->maxp_inv_g;
@@ -1288,14 +1288,14 @@ static void cmd_add_port_tm_node_wred_profile_parsed(void *parsed_result,
/* WRED Params (Yellow Color)*/
- color = RTE_TM_YELLOW;
+ color = RTE_COLOR_YELLOW;
wp.red_params[color].min_th = res->min_th_y;
wp.red_params[color].max_th = res->max_th_y;
wp.red_params[color].maxp_inv = res->maxp_inv_y;
wp.red_params[color].wq_log2 = res->wq_log2_y;
/* WRED Params (Red Color)*/
- color = RTE_TM_RED;
+ color = RTE_COLOR_RED;
wp.red_params[color].min_th = res->min_th_r;
wp.red_params[color].max_th = res->max_th_r;
wp.red_params[color].maxp_inv = res->maxp_inv_r;
diff --git a/app/test/test_meter.c b/app/test/test_meter.c
index f935faa53..f6fe6494a 100644
--- a/app/test/test_meter.c
+++ b/app/test/test_meter.c
@@ -215,7 +215,7 @@ tm_test_srtcm_color_blind_check(void)
time = rte_get_tsc_cycles() + hz;
if (rte_meter_srtcm_color_blind_check(
&sm, &sp, time, TM_TEST_SRTCM_CBS_DF - 1)
- != e_RTE_METER_GREEN)
+ != RTE_COLOR_GREEN)
melog(SRTCM_BLIND_CHECK_MSG" GREEN");
/* Test yellow */
@@ -226,7 +226,7 @@ tm_test_srtcm_color_blind_check(void)
time = rte_get_tsc_cycles() + hz;
if (rte_meter_srtcm_color_blind_check(
&sm, &sp, time, TM_TEST_SRTCM_CBS_DF + 1)
- != e_RTE_METER_YELLOW)
+ != RTE_COLOR_YELLOW)
melog(SRTCM_BLIND_CHECK_MSG" YELLOW");
if (rte_meter_srtcm_profile_config(&sp, &sparams) != 0)
@@ -235,7 +235,7 @@ tm_test_srtcm_color_blind_check(void)
melog(SRTCM_BLIND_CHECK_MSG);
time = rte_get_tsc_cycles() + hz;
if (rte_meter_srtcm_color_blind_check(
- &sm, &sp, time, (uint32_t)sp.ebs - 1) != e_RTE_METER_YELLOW)
+ &sm, &sp, time, (uint32_t)sp.ebs - 1) != RTE_COLOR_YELLOW)
melog(SRTCM_BLIND_CHECK_MSG" YELLOW");
/* Test red */
@@ -246,7 +246,7 @@ tm_test_srtcm_color_blind_check(void)
time = rte_get_tsc_cycles() + hz;
if (rte_meter_srtcm_color_blind_check(
&sm, &sp, time, TM_TEST_SRTCM_EBS_DF + 1)
- != e_RTE_METER_RED)
+ != RTE_COLOR_RED)
melog(SRTCM_BLIND_CHECK_MSG" RED");
return 0;
@@ -274,7 +274,7 @@ tm_test_trtcm_color_blind_check(void)
time = rte_get_tsc_cycles() + hz;
if (rte_meter_trtcm_color_blind_check(
&tm, &tp, time, TM_TEST_TRTCM_CBS_DF - 1)
- != e_RTE_METER_GREEN)
+ != RTE_COLOR_GREEN)
melog(TRTCM_BLIND_CHECK_MSG" GREEN");
/* Test yellow */
@@ -285,7 +285,7 @@ tm_test_trtcm_color_blind_check(void)
time = rte_get_tsc_cycles() + hz;
if (rte_meter_trtcm_color_blind_check(
&tm, &tp, time, TM_TEST_TRTCM_CBS_DF + 1)
- != e_RTE_METER_YELLOW)
+ != RTE_COLOR_YELLOW)
melog(TRTCM_BLIND_CHECK_MSG" YELLOW");
if (rte_meter_trtcm_profile_config(&tp, &tparams) != 0)
@@ -295,7 +295,7 @@ tm_test_trtcm_color_blind_check(void)
time = rte_get_tsc_cycles() + hz;
if (rte_meter_trtcm_color_blind_check(
&tm, &tp, time, TM_TEST_TRTCM_PBS_DF - 1)
- != e_RTE_METER_YELLOW)
+ != RTE_COLOR_YELLOW)
melog(TRTCM_BLIND_CHECK_MSG" YELLOW");
/* Test red */
@@ -306,7 +306,7 @@ tm_test_trtcm_color_blind_check(void)
time = rte_get_tsc_cycles() + hz;
if (rte_meter_trtcm_color_blind_check(
&tm, &tp, time, TM_TEST_TRTCM_PBS_DF + 1)
- != e_RTE_METER_RED)
+ != RTE_COLOR_RED)
melog(TRTCM_BLIND_CHECK_MSG" RED");
return 0;
@@ -333,7 +333,7 @@ tm_test_trtcm_rfc4115_color_blind_check(void)
time = rte_get_tsc_cycles() + hz;
if (rte_meter_trtcm_rfc4115_color_blind_check(
&tm, &tp, time, TM_TEST_TRTCM_CBS_DF - 1)
- != e_RTE_METER_GREEN)
+ != RTE_COLOR_GREEN)
melog(TRTCM_RFC4115_BLIND_CHECK_MSG" GREEN");
/* Test yellow */
@@ -344,7 +344,7 @@ tm_test_trtcm_rfc4115_color_blind_check(void)
time = rte_get_tsc_cycles() + hz;
if (rte_meter_trtcm_rfc4115_color_blind_check(
&tm, &tp, time, TM_TEST_TRTCM_CBS_DF + 1)
- != e_RTE_METER_YELLOW)
+ != RTE_COLOR_YELLOW)
melog(TRTCM_RFC4115_BLIND_CHECK_MSG" YELLOW");
if (rte_meter_trtcm_rfc4115_profile_config(&tp, &rfc4115params) != 0)
@@ -354,7 +354,7 @@ tm_test_trtcm_rfc4115_color_blind_check(void)
time = rte_get_tsc_cycles() + hz;
if (rte_meter_trtcm_rfc4115_color_blind_check(
&tm, &tp, time, TM_TEST_TRTCM_EBS_DF - 1)
- != e_RTE_METER_YELLOW)
+ != RTE_COLOR_YELLOW)
melog(TRTCM_RFC4115_BLIND_CHECK_MSG" YELLOW");
/* Test red */
@@ -365,7 +365,7 @@ tm_test_trtcm_rfc4115_color_blind_check(void)
time = rte_get_tsc_cycles() + hz;
if (rte_meter_trtcm_rfc4115_color_blind_check(
&tm, &tp, time, TM_TEST_TRTCM_EBS_DF + 1)
- != e_RTE_METER_RED)
+ != RTE_COLOR_RED)
melog(TRTCM_RFC4115_BLIND_CHECK_MSG" RED");
return 0;
@@ -383,7 +383,7 @@ tm_test_trtcm_rfc4115_color_blind_check(void)
static inline int
tm_test_srtcm_aware_check
-(enum rte_meter_color in[4], enum rte_meter_color out[4])
+(enum rte_color in[4], enum rte_color out[4])
{
#define SRTCM_AWARE_CHECK_MSG "srtcm_aware_check"
struct rte_meter_srtcm_profile sp;
@@ -437,7 +437,7 @@ tm_test_srtcm_aware_check
static inline int
tm_test_srtcm_color_aware_check(void)
{
- enum rte_meter_color in[4], out[4];
+ enum rte_color in[4], out[4];
/**
* test 4 points that will produce green, yellow, yellow, red flag
@@ -445,11 +445,11 @@ tm_test_srtcm_color_aware_check(void)
*/
/* previouly have a green, test points should keep unchanged */
- in[0] = in[1] = in[2] = in[3] = e_RTE_METER_GREEN;
- out[0] = e_RTE_METER_GREEN;
- out[1] = e_RTE_METER_YELLOW;
- out[2] = e_RTE_METER_YELLOW;
- out[3] = e_RTE_METER_RED;
+ in[0] = in[1] = in[2] = in[3] = RTE_COLOR_GREEN;
+ out[0] = RTE_COLOR_GREEN;
+ out[1] = RTE_COLOR_YELLOW;
+ out[2] = RTE_COLOR_YELLOW;
+ out[3] = RTE_COLOR_RED;
if (tm_test_srtcm_aware_check(in, out) != 0)
return -1;
@@ -457,11 +457,11 @@ tm_test_srtcm_color_aware_check(void)
* previously have a yellow, green & yellow = yellow
* yellow & red = red
*/
- in[0] = in[1] = in[2] = in[3] = e_RTE_METER_YELLOW;
- out[0] = e_RTE_METER_YELLOW;
- out[1] = e_RTE_METER_YELLOW;
- out[2] = e_RTE_METER_YELLOW;
- out[3] = e_RTE_METER_RED;
+ in[0] = in[1] = in[2] = in[3] = RTE_COLOR_YELLOW;
+ out[0] = RTE_COLOR_YELLOW;
+ out[1] = RTE_COLOR_YELLOW;
+ out[2] = RTE_COLOR_YELLOW;
+ out[3] = RTE_COLOR_RED;
if (tm_test_srtcm_aware_check(in, out) != 0)
return -1;
@@ -469,11 +469,11 @@ tm_test_srtcm_color_aware_check(void)
* previously have a red, red & green = red
* red & yellow = red
*/
- in[0] = in[1] = in[2] = in[3] = e_RTE_METER_RED;
- out[0] = e_RTE_METER_RED;
- out[1] = e_RTE_METER_RED;
- out[2] = e_RTE_METER_RED;
- out[3] = e_RTE_METER_RED;
+ in[0] = in[1] = in[2] = in[3] = RTE_COLOR_RED;
+ out[0] = RTE_COLOR_RED;
+ out[1] = RTE_COLOR_RED;
+ out[2] = RTE_COLOR_RED;
+ out[3] = RTE_COLOR_RED;
if (tm_test_srtcm_aware_check(in, out) != 0)
return -1;
@@ -490,7 +490,7 @@ tm_test_srtcm_color_aware_check(void)
*/
static inline int
tm_test_trtcm_aware_check
-(enum rte_meter_color in[4], enum rte_meter_color out[4])
+(enum rte_color in[4], enum rte_color out[4])
{
#define TRTCM_AWARE_CHECK_MSG "trtcm_aware_check"
struct rte_meter_trtcm_profile tp;
@@ -545,34 +545,34 @@ tm_test_trtcm_aware_check
static inline int
tm_test_trtcm_color_aware_check(void)
{
- enum rte_meter_color in[4], out[4];
+ enum rte_color in[4], out[4];
/**
* test 4 points that will produce green, yellow, yellow, red flag
* if using blind check
*/
/* previouly have a green, test points should keep unchanged */
- in[0] = in[1] = in[2] = in[3] = e_RTE_METER_GREEN;
- out[0] = e_RTE_METER_GREEN;
- out[1] = e_RTE_METER_YELLOW;
- out[2] = e_RTE_METER_YELLOW;
- out[3] = e_RTE_METER_RED;
+ in[0] = in[1] = in[2] = in[3] = RTE_COLOR_GREEN;
+ out[0] = RTE_COLOR_GREEN;
+ out[1] = RTE_COLOR_YELLOW;
+ out[2] = RTE_COLOR_YELLOW;
+ out[3] = RTE_COLOR_RED;
if (tm_test_trtcm_aware_check(in, out) != 0)
return -1;
- in[0] = in[1] = in[2] = in[3] = e_RTE_METER_YELLOW;
- out[0] = e_RTE_METER_YELLOW;
- out[1] = e_RTE_METER_YELLOW;
- out[2] = e_RTE_METER_YELLOW;
- out[3] = e_RTE_METER_RED;
+ in[0] = in[1] = in[2] = in[3] = RTE_COLOR_YELLOW;
+ out[0] = RTE_COLOR_YELLOW;
+ out[1] = RTE_COLOR_YELLOW;
+ out[2] = RTE_COLOR_YELLOW;
+ out[3] = RTE_COLOR_RED;
if (tm_test_trtcm_aware_check(in, out) != 0)
return -1;
- in[0] = in[1] = in[2] = in[3] = e_RTE_METER_RED;
- out[0] = e_RTE_METER_RED;
- out[1] = e_RTE_METER_RED;
- out[2] = e_RTE_METER_RED;
- out[3] = e_RTE_METER_RED;
+ in[0] = in[1] = in[2] = in[3] = RTE_COLOR_RED;
+ out[0] = RTE_COLOR_RED;
+ out[1] = RTE_COLOR_RED;
+ out[2] = RTE_COLOR_RED;
+ out[3] = RTE_COLOR_RED;
if (tm_test_trtcm_aware_check(in, out) != 0)
return -1;
@@ -589,7 +589,7 @@ tm_test_trtcm_color_aware_check(void)
*/
static inline int
tm_test_trtcm_rfc4115_aware_check
-(enum rte_meter_color in[4], enum rte_meter_color out[4])
+(enum rte_color in[4], enum rte_color out[4])
{
#define TRTCM_RFC4115_AWARE_CHECK_MSG "trtcm_rfc4115_aware_check"
struct rte_meter_trtcm_rfc4115_profile tp;
@@ -642,34 +642,34 @@ tm_test_trtcm_rfc4115_aware_check
static inline int
tm_test_trtcm_rfc4115_color_aware_check(void)
{
- enum rte_meter_color in[4], out[4];
+ enum rte_color in[4], out[4];
/**
* test 4 points that will produce green, yellow, yellow, red flag
* if using blind check
*/
/* previouly have a green, test points should keep unchanged */
- in[0] = in[1] = in[2] = in[3] = e_RTE_METER_GREEN;
- out[0] = e_RTE_METER_GREEN;
- out[1] = e_RTE_METER_YELLOW;
- out[2] = e_RTE_METER_YELLOW;
- out[3] = e_RTE_METER_RED;
+ in[0] = in[1] = in[2] = in[3] = RTE_COLOR_GREEN;
+ out[0] = RTE_COLOR_GREEN;
+ out[1] = RTE_COLOR_YELLOW;
+ out[2] = RTE_COLOR_YELLOW;
+ out[3] = RTE_COLOR_RED;
if (tm_test_trtcm_rfc4115_aware_check(in, out) != 0)
return -1;
- in[0] = in[1] = in[2] = in[3] = e_RTE_METER_YELLOW;
- out[0] = e_RTE_METER_YELLOW;
- out[1] = e_RTE_METER_YELLOW;
- out[2] = e_RTE_METER_YELLOW;
- out[3] = e_RTE_METER_RED;
+ in[0] = in[1] = in[2] = in[3] = RTE_COLOR_YELLOW;
+ out[0] = RTE_COLOR_YELLOW;
+ out[1] = RTE_COLOR_YELLOW;
+ out[2] = RTE_COLOR_YELLOW;
+ out[3] = RTE_COLOR_RED;
if (tm_test_trtcm_rfc4115_aware_check(in, out) != 0)
return -1;
- in[0] = in[1] = in[2] = in[3] = e_RTE_METER_RED;
- out[0] = e_RTE_METER_RED;
- out[1] = e_RTE_METER_RED;
- out[2] = e_RTE_METER_RED;
- out[3] = e_RTE_METER_RED;
+ in[0] = in[1] = in[2] = in[3] = RTE_COLOR_RED;
+ out[0] = RTE_COLOR_RED;
+ out[1] = RTE_COLOR_RED;
+ out[2] = RTE_COLOR_RED;
+ out[3] = RTE_COLOR_RED;
if (tm_test_trtcm_rfc4115_aware_check(in, out) != 0)
return -1;
diff --git a/app/test/test_sched.c b/app/test/test_sched.c
index 40e411cab..4eed8dbde 100644
--- a/app/test/test_sched.c
+++ b/app/test/test_sched.c
@@ -96,7 +96,7 @@ prepare_pkt(struct rte_sched_port *port, struct rte_mbuf *mbuf)
rte_sched_port_pkt_write(port, mbuf, SUBPORT, PIPE, TC, QUEUE,
- e_RTE_METER_YELLOW);
+ RTE_COLOR_YELLOW);
/* 64 byte packet */
mbuf->pkt_len = 60;
@@ -150,11 +150,11 @@ test_sched(void)
TEST_ASSERT_EQUAL(err, 10, "Wrong dequeue, err=%d\n", err);
for (i = 0; i < 10; i++) {
- enum rte_meter_color color;
+ enum rte_color color;
uint32_t subport, traffic_class, queue;
color = rte_sched_port_pkt_read_color(out_mbufs[i]);
- TEST_ASSERT_EQUAL(color, e_RTE_METER_YELLOW, "Wrong color\n");
+ TEST_ASSERT_EQUAL(color, RTE_COLOR_YELLOW, "Wrong color\n");
rte_sched_port_pkt_read_tree_path(port, out_mbufs[i],
&subport, &pipe, &traffic_class, &queue);
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 1b4fcb7e6..e91a1bb45 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -68,10 +68,5 @@ Deprecation Notices
- Member ``uint16_t min_mtu`` the minimum MTU allowed.
- Member ``uint16_t max_mtu`` the maximum MTU allowed.
-* meter: New ``rte_color`` definition will be added in 19.02 and that will
- replace ``enum rte_meter_color`` in meter library in 19.05. This will help
- to consolidate color definition, which is currently replicated in many places,
- such as: rte_meter.h, rte_mtr.h, rte_tm.h.
-
* crypto/aesni_mb: the minimum supported intel-ipsec-mb library version will be
changed from 0.49.0 to 0.52.0.
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index d11bb5a2b..c97e5a48c 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -134,6 +134,10 @@ API Changes
Also, make sure to start the actual text at the margin.
=========================================================
+* meter: replace ``enum rte_meter_color`` in meter library with new
+ ``rte_color`` definition added in 19.02. To consolidate mulitple color
+ definitions replicated at many places such as: rte_mtr.h, rte_tm.h,
+ replacements with rte_color values are done.
ABI Changes
-----------
@@ -207,7 +211,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_mbuf.so.5
librte_member.so.1
librte_mempool.so.5
- librte_meter.so.2
+ librte_meter.so.3
librte_metrics.so.1
librte_net.so.1
librte_pci.so.1
diff --git a/drivers/net/softnic/rte_eth_softnic_cli.c b/drivers/net/softnic/rte_eth_softnic_cli.c
index 76136c2e2..b83fd038f 100644
--- a/drivers/net/softnic/rte_eth_softnic_cli.c
+++ b/drivers/net/softnic/rte_eth_softnic_cli.c
@@ -3550,11 +3550,11 @@ parse_table_action_meter_tc(char **tokens,
softnic_parser_read_uint32(&mtr->meter_profile_id, tokens[1]) ||
strcmp(tokens[2], "policer") ||
strcmp(tokens[3], "g") ||
- parse_policer_action(tokens[4], &mtr->policer[e_RTE_METER_GREEN]) ||
+ parse_policer_action(tokens[4], &mtr->policer[RTE_COLOR_GREEN]) ||
strcmp(tokens[5], "y") ||
- parse_policer_action(tokens[6], &mtr->policer[e_RTE_METER_YELLOW]) ||
+ parse_policer_action(tokens[6], &mtr->policer[RTE_COLOR_YELLOW]) ||
strcmp(tokens[7], "r") ||
- parse_policer_action(tokens[8], &mtr->policer[e_RTE_METER_RED]))
+ parse_policer_action(tokens[8], &mtr->policer[RTE_COLOR_RED]))
return 0;
return 9;
@@ -5384,7 +5384,7 @@ load_dscp_table(struct rte_table_action_dscp_table *dscp_table,
for (dscp = 0, l = 1; ; l++) {
char line[64];
char *tokens[3];
- enum rte_meter_color color;
+ enum rte_color color;
uint32_t tc_id, tc_queue_id, n_tokens = RTE_DIM(tokens);
if (fgets(line, sizeof(line), f) == NULL)
@@ -5417,17 +5417,17 @@ load_dscp_table(struct rte_table_action_dscp_table *dscp_table,
switch (tokens[2][0]) {
case 'g':
case 'G':
- color = e_RTE_METER_GREEN;
+ color = RTE_COLOR_GREEN;
break;
case 'y':
case 'Y':
- color = e_RTE_METER_YELLOW;
+ color = RTE_COLOR_YELLOW;
break;
case 'r':
case 'R':
- color = e_RTE_METER_RED;
+ color = RTE_COLOR_RED;
break;
default:
diff --git a/drivers/net/softnic/rte_eth_softnic_flow.c b/drivers/net/softnic/rte_eth_softnic_flow.c
index aefc384dc..ccd58c01c 100644
--- a/drivers/net/softnic/rte_eth_softnic_flow.c
+++ b/drivers/net/softnic/rte_eth_softnic_flow.c
@@ -1624,12 +1624,12 @@ flow_rule_action_get(struct pmd_internals *softnic,
/* RTE_TABLE_ACTION_METER */
rule_action->mtr.mtr[0].meter_profile_id = meter_profile_id;
- rule_action->mtr.mtr[0].policer[e_RTE_METER_GREEN] =
- softnic_table_action_policer(m->params.action[RTE_MTR_GREEN]);
- rule_action->mtr.mtr[0].policer[e_RTE_METER_YELLOW] =
- softnic_table_action_policer(m->params.action[RTE_MTR_YELLOW]);
- rule_action->mtr.mtr[0].policer[e_RTE_METER_RED] =
- softnic_table_action_policer(m->params.action[RTE_MTR_RED]);
+ rule_action->mtr.mtr[0].policer[RTE_COLOR_GREEN] =
+ softnic_table_action_policer(m->params.action[RTE_COLOR_GREEN]);
+ rule_action->mtr.mtr[0].policer[RTE_COLOR_YELLOW] =
+ softnic_table_action_policer(m->params.action[RTE_COLOR_YELLOW]);
+ rule_action->mtr.mtr[0].policer[RTE_COLOR_RED] =
+ softnic_table_action_policer(m->params.action[RTE_COLOR_RED]);
rule_action->mtr.tc_mask = 1;
rule_action->action_mask |= 1 << RTE_TABLE_ACTION_MTR;
break;
diff --git a/drivers/net/softnic/rte_eth_softnic_meter.c b/drivers/net/softnic/rte_eth_softnic_meter.c
index 7b747ba5d..31a2a0e6d 100644
--- a/drivers/net/softnic/rte_eth_softnic_meter.c
+++ b/drivers/net/softnic/rte_eth_softnic_meter.c
@@ -458,7 +458,7 @@ pmd_mtr_meter_profile_update(struct rte_eth_dev *dev,
static int
pmd_mtr_meter_dscp_table_update(struct rte_eth_dev *dev,
uint32_t mtr_id,
- enum rte_mtr_color *dscp_table,
+ enum rte_color *dscp_table,
struct rte_mtr_error *error)
{
struct pmd_internals *p = dev->data->dev_private;
@@ -488,7 +488,7 @@ pmd_mtr_meter_dscp_table_update(struct rte_eth_dev *dev,
memcpy(&dt, &table->dscp_table, sizeof(dt));
for (i = 0; i < RTE_DIM(dt.entry); i++)
- dt.entry[i].color = (enum rte_meter_color)dscp_table[i];
+ dt.entry[i].color = (enum rte_color)dscp_table[i];
/* Update table */
status = softnic_pipeline_table_dscp_table_update(p,
@@ -536,7 +536,7 @@ pmd_mtr_policer_actions_update(struct rte_eth_dev *dev,
NULL,
"Invalid actions");
- for (i = 0; i < RTE_MTR_COLORS; i++) {
+ for (i = 0; i < RTE_COLORS; i++) {
if (action_mask & (1 << i)) {
if (actions[i] != MTR_POLICER_ACTION_COLOR_GREEN &&
actions[i] != MTR_POLICER_ACTION_COLOR_YELLOW &&
@@ -560,7 +560,7 @@ pmd_mtr_policer_actions_update(struct rte_eth_dev *dev,
memcpy(&action, &m->flow->action, sizeof(action));
/* Set action */
- for (i = 0; i < RTE_MTR_COLORS; i++)
+ for (i = 0; i < RTE_COLORS; i++)
if (action_mask & (1 << i))
action.mtr.mtr[0].policer[i] =
softnic_table_action_policer(actions[i]);
@@ -588,7 +588,7 @@ pmd_mtr_policer_actions_update(struct rte_eth_dev *dev,
}
/* Meter: Update policer actions */
- for (i = 0; i < RTE_MTR_COLORS; i++)
+ for (i = 0; i < RTE_COLORS; i++)
if (action_mask & (1 << i))
m->params.action[i] = actions[i];
@@ -618,15 +618,15 @@ mtr_stats_convert(struct softnic_mtr *m,
if (in->n_packets_valid) {
uint32_t i;
- for (i = 0; i < RTE_MTR_COLORS; i++) {
+ for (i = 0; i < RTE_COLORS; i++) {
if (m->params.action[i] == MTR_POLICER_ACTION_COLOR_GREEN)
- out->n_pkts[RTE_MTR_GREEN] += in->n_packets[i];
+ out->n_pkts[RTE_COLOR_GREEN] += in->n_packets[i];
if (m->params.action[i] == MTR_POLICER_ACTION_COLOR_YELLOW)
- out->n_pkts[RTE_MTR_YELLOW] += in->n_packets[i];
+ out->n_pkts[RTE_COLOR_YELLOW] += in->n_packets[i];
if (m->params.action[i] == MTR_POLICER_ACTION_COLOR_RED)
- out->n_pkts[RTE_MTR_RED] += in->n_packets[i];
+ out->n_pkts[RTE_COLOR_RED] += in->n_packets[i];
if (m->params.action[i] == MTR_POLICER_ACTION_DROP)
out->n_pkts_dropped += in->n_packets[i];
@@ -638,15 +638,15 @@ mtr_stats_convert(struct softnic_mtr *m,
if (in->n_bytes_valid) {
uint32_t i;
- for (i = 0; i < RTE_MTR_COLORS; i++) {
+ for (i = 0; i < RTE_COLORS; i++) {
if (m->params.action[i] == MTR_POLICER_ACTION_COLOR_GREEN)
- out->n_bytes[RTE_MTR_GREEN] += in->n_bytes[i];
+ out->n_bytes[RTE_COLOR_GREEN] += in->n_bytes[i];
if (m->params.action[i] == MTR_POLICER_ACTION_COLOR_YELLOW)
- out->n_bytes[RTE_MTR_YELLOW] += in->n_bytes[i];
+ out->n_bytes[RTE_COLOR_YELLOW] += in->n_bytes[i];
if (m->params.action[i] == MTR_POLICER_ACTION_COLOR_RED)
- out->n_bytes[RTE_MTR_RED] += in->n_bytes[i];
+ out->n_bytes[RTE_COLOR_RED] += in->n_bytes[i];
if (m->params.action[i] == MTR_POLICER_ACTION_DROP)
out->n_bytes_dropped += in->n_bytes[i];
diff --git a/drivers/net/softnic/rte_eth_softnic_tm.c b/drivers/net/softnic/rte_eth_softnic_tm.c
index baaafbe29..58744a9eb 100644
--- a/drivers/net/softnic/rte_eth_softnic_tm.c
+++ b/drivers/net/softnic/rte_eth_softnic_tm.c
@@ -1204,7 +1204,7 @@ wred_profile_check(struct rte_eth_dev *dev,
struct rte_tm_error *error)
{
struct tm_wred_profile *wp;
- enum rte_tm_color color;
+ enum rte_color color;
/* WRED profile ID must not be NONE. */
if (wred_profile_id == RTE_TM_WRED_PROFILE_ID_NONE)
@@ -1240,7 +1240,7 @@ wred_profile_check(struct rte_eth_dev *dev,
rte_strerror(ENOTSUP));
/* min_th <= max_th, max_th > 0 */
- for (color = RTE_TM_GREEN; color < RTE_TM_COLORS; color++) {
+ for (color = RTE_COLOR_GREEN; color < RTE_COLORS; color++) {
uint32_t min_th = profile->red_params[color].min_th;
uint32_t max_th = profile->red_params[color].max_th;
@@ -2218,10 +2218,10 @@ wred_profiles_set(struct rte_eth_dev *dev)
struct pmd_internals *p = dev->data->dev_private;
struct rte_sched_port_params *pp = &p->soft.tm.params.port_params;
uint32_t tc_id;
- enum rte_tm_color color;
+ enum rte_color color;
for (tc_id = 0; tc_id < RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE; tc_id++)
- for (color = RTE_TM_GREEN; color < RTE_TM_COLORS; color++) {
+ for (color = RTE_COLOR_GREEN; color < RTE_COLORS; color++) {
struct rte_red_params *dst =
&pp->red_params[tc_id][color];
struct tm_wred_profile *src_wp =
@@ -3058,9 +3058,9 @@ read_port_stats(struct rte_eth_dev *dev,
s.n_pkts_tc[id] - s.n_pkts_tc_dropped[id];
nr->stats.n_bytes +=
s.n_bytes_tc[id] - s.n_bytes_tc_dropped[id];
- nr->stats.leaf.n_pkts_dropped[RTE_TM_GREEN] +=
+ nr->stats.leaf.n_pkts_dropped[RTE_COLOR_GREEN] +=
s.n_pkts_tc_dropped[id];
- nr->stats.leaf.n_bytes_dropped[RTE_TM_GREEN] +=
+ nr->stats.leaf.n_bytes_dropped[RTE_COLOR_GREEN] +=
s.n_bytes_tc_dropped[id];
}
}
@@ -3105,9 +3105,9 @@ read_subport_stats(struct rte_eth_dev *dev,
s.n_pkts_tc[tc_id] - s.n_pkts_tc_dropped[tc_id];
ns->stats.n_bytes +=
s.n_bytes_tc[tc_id] - s.n_bytes_tc_dropped[tc_id];
- ns->stats.leaf.n_pkts_dropped[RTE_TM_GREEN] +=
+ ns->stats.leaf.n_pkts_dropped[RTE_COLOR_GREEN] +=
s.n_pkts_tc_dropped[tc_id];
- ns->stats.leaf.n_bytes_dropped[RTE_TM_GREEN] +=
+ ns->stats.leaf.n_bytes_dropped[RTE_COLOR_GREEN] +=
s.n_bytes_tc_dropped[tc_id];
}
@@ -3162,8 +3162,8 @@ read_pipe_stats(struct rte_eth_dev *dev,
/* Stats accumulate */
np->stats.n_pkts += s.n_pkts - s.n_pkts_dropped;
np->stats.n_bytes += s.n_bytes - s.n_bytes_dropped;
- np->stats.leaf.n_pkts_dropped[RTE_TM_GREEN] += s.n_pkts_dropped;
- np->stats.leaf.n_bytes_dropped[RTE_TM_GREEN] +=
+ np->stats.leaf.n_pkts_dropped[RTE_COLOR_GREEN] += s.n_pkts_dropped;
+ np->stats.leaf.n_bytes_dropped[RTE_COLOR_GREEN] +=
s.n_bytes_dropped;
np->stats.leaf.n_pkts_queued = qlen;
}
@@ -3222,8 +3222,8 @@ read_tc_stats(struct rte_eth_dev *dev,
/* Stats accumulate */
nt->stats.n_pkts += s.n_pkts - s.n_pkts_dropped;
nt->stats.n_bytes += s.n_bytes - s.n_bytes_dropped;
- nt->stats.leaf.n_pkts_dropped[RTE_TM_GREEN] += s.n_pkts_dropped;
- nt->stats.leaf.n_bytes_dropped[RTE_TM_GREEN] +=
+ nt->stats.leaf.n_pkts_dropped[RTE_COLOR_GREEN] += s.n_pkts_dropped;
+ nt->stats.leaf.n_bytes_dropped[RTE_COLOR_GREEN] +=
s.n_bytes_dropped;
nt->stats.leaf.n_pkts_queued = qlen;
}
@@ -3281,8 +3281,8 @@ read_queue_stats(struct rte_eth_dev *dev,
/* Stats accumulate */
nq->stats.n_pkts += s.n_pkts - s.n_pkts_dropped;
nq->stats.n_bytes += s.n_bytes - s.n_bytes_dropped;
- nq->stats.leaf.n_pkts_dropped[RTE_TM_GREEN] += s.n_pkts_dropped;
- nq->stats.leaf.n_bytes_dropped[RTE_TM_GREEN] +=
+ nq->stats.leaf.n_pkts_dropped[RTE_COLOR_GREEN] += s.n_pkts_dropped;
+ nq->stats.leaf.n_bytes_dropped[RTE_COLOR_GREEN] +=
s.n_bytes_dropped;
nq->stats.leaf.n_pkts_queued = qlen;
diff --git a/examples/ip_pipeline/cli.c b/examples/ip_pipeline/cli.c
index a92467e63..49028efb0 100644
--- a/examples/ip_pipeline/cli.c
+++ b/examples/ip_pipeline/cli.c
@@ -3233,11 +3233,11 @@ parse_table_action_meter_tc(char **tokens,
parser_read_uint32(&mtr->meter_profile_id, tokens[1]) ||
strcmp(tokens[2], "policer") ||
strcmp(tokens[3], "g") ||
- parse_policer_action(tokens[4], &mtr->policer[e_RTE_METER_GREEN]) ||
+ parse_policer_action(tokens[4], &mtr->policer[RTE_COLOR_GREEN]) ||
strcmp(tokens[5], "y") ||
- parse_policer_action(tokens[6], &mtr->policer[e_RTE_METER_YELLOW]) ||
+ parse_policer_action(tokens[6], &mtr->policer[RTE_COLOR_YELLOW]) ||
strcmp(tokens[7], "r") ||
- parse_policer_action(tokens[8], &mtr->policer[e_RTE_METER_RED]))
+ parse_policer_action(tokens[8], &mtr->policer[RTE_COLOR_RED]))
return 0;
return 9;
@@ -4907,11 +4907,11 @@ table_rule_show(const char *pipeline_name,
struct rte_table_action_mtr_tc_params *p =
&a->mtr.mtr[i];
enum rte_table_action_policer ga =
- p->policer[e_RTE_METER_GREEN];
+ p->policer[RTE_COLOR_GREEN];
enum rte_table_action_policer ya =
- p->policer[e_RTE_METER_YELLOW];
+ p->policer[RTE_COLOR_YELLOW];
enum rte_table_action_policer ra =
- p->policer[e_RTE_METER_RED];
+ p->policer[RTE_COLOR_RED];
fprintf(f, "tc%u meter %u policer g %s y %s r %s ",
i,
@@ -5604,7 +5604,7 @@ load_dscp_table(struct rte_table_action_dscp_table *dscp_table,
for (dscp = 0, l = 1; ; l++) {
char line[64];
char *tokens[3];
- enum rte_meter_color color;
+ enum rte_color color;
uint32_t tc_id, tc_queue_id, n_tokens = RTE_DIM(tokens);
if (fgets(line, sizeof(line), f) == NULL)
@@ -5637,17 +5637,17 @@ load_dscp_table(struct rte_table_action_dscp_table *dscp_table,
switch (tokens[2][0]) {
case 'g':
case 'G':
- color = e_RTE_METER_GREEN;
+ color = RTE_COLOR_GREEN;
break;
case 'y':
case 'Y':
- color = e_RTE_METER_YELLOW;
+ color = RTE_COLOR_YELLOW;
break;
case 'r':
case 'R':
- color = e_RTE_METER_RED;
+ color = RTE_COLOR_RED;
break;
default:
diff --git a/examples/qos_meter/main.h b/examples/qos_meter/main.h
index f51eb664e..ab20151eb 100644
--- a/examples/qos_meter/main.h
+++ b/examples/qos_meter/main.h
@@ -6,13 +6,13 @@
#define _MAIN_H_
enum policer_action {
- GREEN = e_RTE_METER_GREEN,
- YELLOW = e_RTE_METER_YELLOW,
- RED = e_RTE_METER_RED,
- DROP = 3,
+ GREEN = RTE_COLOR_GREEN,
+ YELLOW = RTE_COLOR_YELLOW,
+ RED = RTE_COLOR_RED,
+ DROP = 3,
};
-enum policer_action policer_table[e_RTE_METER_COLORS][e_RTE_METER_COLORS] =
+enum policer_action policer_table[RTE_COLORS][RTE_COLORS] =
{
{ GREEN, RED, RED},
{ DROP, YELLOW, RED},
diff --git a/examples/qos_meter/rte_policer.c b/examples/qos_meter/rte_policer.c
index 58c13ec67..10d5fe8a4 100644
--- a/examples/qos_meter/rte_policer.c
+++ b/examples/qos_meter/rte_policer.c
@@ -7,7 +7,7 @@
int
rte_phb_config(struct rte_phb *phb_table, uint32_t phb_table_index,
- enum rte_meter_color pre_meter, enum rte_meter_color post_meter, enum rte_phb_action action)
+ enum rte_color pre_meter, enum rte_color post_meter, enum rte_phb_action action)
{
struct rte_phb *phb = NULL;
@@ -16,7 +16,7 @@ rte_phb_config(struct rte_phb *phb_table, uint32_t phb_table_index,
return -1;
}
- if ((pre_meter > e_RTE_METER_RED) || (post_meter > e_RTE_METER_RED) || (pre_meter > post_meter)) {
+ if ((pre_meter > RTE_COLOR_RED) || (post_meter > RTE_COLOR_RED) || (pre_meter > post_meter)) {
return -2;
}
diff --git a/examples/qos_meter/rte_policer.h b/examples/qos_meter/rte_policer.h
index 532a853dd..95efe5b85 100644
--- a/examples/qos_meter/rte_policer.h
+++ b/examples/qos_meter/rte_policer.h
@@ -9,22 +9,22 @@
#include <rte_meter.h>
enum rte_phb_action {
- e_RTE_PHB_ACTION_GREEN = e_RTE_METER_GREEN,
- e_RTE_PHB_ACTION_YELLOW = e_RTE_METER_YELLOW,
- e_RTE_PHB_ACTION_RED = e_RTE_METER_RED,
+ e_RTE_PHB_ACTION_GREEN = RTE_COLOR_GREEN,
+ e_RTE_PHB_ACTION_YELLOW = RTE_COLOR_YELLOW,
+ e_RTE_PHB_ACTION_RED = RTE_COLOR_RED,
e_RTE_PHB_ACTION_DROP = 3,
};
struct rte_phb {
- enum rte_phb_action actions[e_RTE_METER_COLORS][e_RTE_METER_COLORS];
+ enum rte_phb_action actions[RTE_COLORS][RTE_COLORS];
};
int
rte_phb_config(struct rte_phb *phb_table, uint32_t phb_table_index,
- enum rte_meter_color pre_meter, enum rte_meter_color post_meter, enum rte_phb_action action);
+ enum rte_color pre_meter, enum rte_color post_meter, enum rte_phb_action action);
static inline enum rte_phb_action
-policer_run(struct rte_phb *phb_table, uint32_t phb_table_index, enum rte_meter_color pre_meter, enum rte_meter_color post_meter)
+policer_run(struct rte_phb *phb_table, uint32_t phb_table_index, enum rte_color pre_meter, enum rte_color post_meter)
{
struct rte_phb *phb = &phb_table[phb_table_index];
enum rte_phb_action action = phb->actions[pre_meter][post_meter];
diff --git a/examples/qos_sched/app_thread.c b/examples/qos_sched/app_thread.c
index bec4deee3..e14b275e3 100644
--- a/examples/qos_sched/app_thread.c
+++ b/examples/qos_sched/app_thread.c
@@ -77,7 +77,7 @@ app_rx_thread(struct thread_conf **confs)
rx_mbufs[i],
subport, pipe,
traffic_class, queue,
- (enum rte_meter_color) color);
+ (enum rte_color) color);
}
if (unlikely(rte_ring_sp_enqueue_bulk(conf->rx_ring,
diff --git a/lib/librte_ethdev/rte_mtr.c b/lib/librte_ethdev/rte_mtr.c
index 1046cb5fd..12b815406 100644
--- a/lib/librte_ethdev/rte_mtr.c
+++ b/lib/librte_ethdev/rte_mtr.c
@@ -153,7 +153,7 @@ rte_mtr_meter_profile_update(uint16_t port_id,
int __rte_experimental
rte_mtr_meter_dscp_table_update(uint16_t port_id,
uint32_t mtr_id,
- enum rte_mtr_color *dscp_table,
+ enum rte_color *dscp_table,
struct rte_mtr_error *error)
{
struct rte_eth_dev *dev = &rte_eth_devices[port_id];
diff --git a/lib/librte_ethdev/rte_mtr.h b/lib/librte_ethdev/rte_mtr.h
index c667f87e1..e6831bc70 100644
--- a/lib/librte_ethdev/rte_mtr.h
+++ b/lib/librte_ethdev/rte_mtr.h
@@ -123,10 +123,10 @@ enum rte_mtr_stats_type {
*/
struct rte_mtr_stats {
/** Number of packets passed by the policer (per color). */
- uint64_t n_pkts[RTE_MTR_COLORS];
+ uint64_t n_pkts[RTE_COLORS];
/** Number of bytes passed by the policer (per color). */
- uint64_t n_bytes[RTE_MTR_COLORS];
+ uint64_t n_bytes[RTE_COLORS];
/** Number of packets dropped by the policer. */
uint64_t n_pkts_dropped;
@@ -258,7 +258,7 @@ struct rte_mtr_params {
* at least one yellow or red color element, then the color aware mode
* is configured.
*/
- enum rte_mtr_color *dscp_table;
+ enum rte_color *dscp_table;
/** Non-zero to enable the meter, zero to disable the meter at the time
* of MTR object creation. Ignored when the meter profile indicated by
@@ -268,7 +268,7 @@ struct rte_mtr_params {
int meter_enable;
/** Policer actions (per meter output color). */
- enum rte_mtr_policer_action action[RTE_MTR_COLORS];
+ enum rte_mtr_policer_action action[RTE_COLORS];
/** Set of stats counters to be enabled.
* @see enum rte_mtr_stats_type
@@ -634,7 +634,7 @@ rte_mtr_meter_profile_update(uint16_t port_id,
int __rte_experimental
rte_mtr_meter_dscp_table_update(uint16_t port_id,
uint32_t mtr_id,
- enum rte_mtr_color *dscp_table,
+ enum rte_color *dscp_table,
struct rte_mtr_error *error);
/**
diff --git a/lib/librte_ethdev/rte_mtr_driver.h b/lib/librte_ethdev/rte_mtr_driver.h
index c9a6d7c38..3ec7ffa2a 100644
--- a/lib/librte_ethdev/rte_mtr_driver.h
+++ b/lib/librte_ethdev/rte_mtr_driver.h
@@ -70,7 +70,7 @@ typedef int (*rte_mtr_meter_profile_update_t)(struct rte_eth_dev *dev,
typedef int (*rte_mtr_meter_dscp_table_update_t)(struct rte_eth_dev *dev,
uint32_t mtr_id,
- enum rte_mtr_color *dscp_table,
+ enum rte_color *dscp_table,
struct rte_mtr_error *error);
/**< @internal MTR object meter DSCP table update */
diff --git a/lib/librte_ethdev/rte_tm.h b/lib/librte_ethdev/rte_tm.h
index c4a788b85..980bf4419 100644
--- a/lib/librte_ethdev/rte_tm.h
+++ b/lib/librte_ethdev/rte_tm.h
@@ -177,12 +177,12 @@ struct rte_tm_node_stats {
/** Number of packets dropped by current leaf node per each
* color.
*/
- uint64_t n_pkts_dropped[RTE_TM_COLORS];
+ uint64_t n_pkts_dropped[RTE_COLORS];
/** Number of bytes dropped by current leaf node per each
* color.
*/
- uint64_t n_bytes_dropped[RTE_TM_COLORS];
+ uint64_t n_bytes_dropped[RTE_COLORS];
/** Number of packets currently waiting in the packet queue of
* current leaf node.
@@ -433,16 +433,16 @@ struct rte_tm_capabilities {
uint32_t cman_wred_context_shared_n_contexts_per_node_max;
/** Support for VLAN DEI packet marking (per color). */
- int mark_vlan_dei_supported[RTE_TM_COLORS];
+ int mark_vlan_dei_supported[RTE_COLORS];
/** Support for IPv4/IPv6 ECN marking of TCP packets (per color). */
- int mark_ip_ecn_tcp_supported[RTE_TM_COLORS];
+ int mark_ip_ecn_tcp_supported[RTE_COLORS];
/** Support for IPv4/IPv6 ECN marking of SCTP packets (per color). */
- int mark_ip_ecn_sctp_supported[RTE_TM_COLORS];
+ int mark_ip_ecn_sctp_supported[RTE_COLORS];
/** Support for IPv4/IPv6 DSCP packet marking (per color). */
- int mark_ip_dscp_supported[RTE_TM_COLORS];
+ int mark_ip_dscp_supported[RTE_COLORS];
/** Set of supported dynamic update operations.
* @see enum rte_tm_dynamic_update_type
@@ -859,7 +859,7 @@ struct rte_tm_red_params {
*/
struct rte_tm_wred_params {
/** One set of RED parameters per packet color */
- struct rte_tm_red_params red_params[RTE_TM_COLORS];
+ struct rte_tm_red_params red_params[RTE_COLORS];
/** When non-zero, the *min_th* and *max_th* thresholds are specified
* in packets (WRED packet mode). When zero, the *min_th* and *max_th*
diff --git a/lib/librte_meter/Makefile b/lib/librte_meter/Makefile
index 2dc071e8e..79ad79744 100644
--- a/lib/librte_meter/Makefile
+++ b/lib/librte_meter/Makefile
@@ -16,7 +16,7 @@ LDLIBS += -lrte_eal
EXPORT_MAP := rte_meter_version.map
-LIBABIVER := 2
+LIBABIVER := 3
#
# all source are stored in SRCS-y
diff --git a/lib/librte_meter/meson.build b/lib/librte_meter/meson.build
index 947bc19e2..422123e20 100644
--- a/lib/librte_meter/meson.build
+++ b/lib/librte_meter/meson.build
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Intel Corporation
-version = 2
+version = 3
sources = files('rte_meter.c')
headers = files('rte_meter.h')
diff --git a/lib/librte_meter/rte_meter.h b/lib/librte_meter/rte_meter.h
index 005e4eeee..3e383d2e8 100644
--- a/lib/librte_meter/rte_meter.h
+++ b/lib/librte_meter/rte_meter.h
@@ -40,13 +40,6 @@ enum rte_color {
RTE_COLORS /**< Number of colors */
};
-/* New rte_color is defined and used to deprecate rte_meter_color soon. */
-#define rte_meter_color rte_color
-#define e_RTE_METER_GREEN RTE_COLOR_GREEN
-#define e_RTE_METER_YELLOW RTE_COLOR_YELLOW
-#define e_RTE_METER_RED RTE_COLOR_RED
-#define e_RTE_METER_COLORS RTE_COLORS
-
/** srTCM parameters per metered traffic flow. The CIR, CBS and EBS parameters only
count bytes of IP packets and do not include link specific headers. At least one of
the CBS or EBS parameters has to be greater than zero. */
@@ -211,7 +204,7 @@ rte_meter_trtcm_rfc4115_config(struct rte_meter_trtcm_rfc4115 *m,
* @return
* Color assigned to the current IP packet
*/
-static inline enum rte_meter_color
+static inline enum rte_color
rte_meter_srtcm_color_blind_check(struct rte_meter_srtcm *m,
struct rte_meter_srtcm_profile *p,
uint64_t time,
@@ -233,12 +226,12 @@ rte_meter_srtcm_color_blind_check(struct rte_meter_srtcm *m,
* @return
* Color assigned to the current IP packet
*/
-static inline enum rte_meter_color
+static inline enum rte_color
rte_meter_srtcm_color_aware_check(struct rte_meter_srtcm *m,
struct rte_meter_srtcm_profile *p,
uint64_t time,
uint32_t pkt_len,
- enum rte_meter_color pkt_color);
+ enum rte_color pkt_color);
/**
* trTCM color blind traffic metering
@@ -254,7 +247,7 @@ rte_meter_srtcm_color_aware_check(struct rte_meter_srtcm *m,
* @return
* Color assigned to the current IP packet
*/
-static inline enum rte_meter_color
+static inline enum rte_color
rte_meter_trtcm_color_blind_check(struct rte_meter_trtcm *m,
struct rte_meter_trtcm_profile *p,
uint64_t time,
@@ -276,12 +269,12 @@ rte_meter_trtcm_color_blind_check(struct rte_meter_trtcm *m,
* @return
* Color assigned to the current IP packet
*/
-static inline enum rte_meter_color
+static inline enum rte_color
rte_meter_trtcm_color_aware_check(struct rte_meter_trtcm *m,
struct rte_meter_trtcm_profile *p,
uint64_t time,
uint32_t pkt_len,
- enum rte_meter_color pkt_color);
+ enum rte_color pkt_color);
/**
* @warning
@@ -300,7 +293,7 @@ rte_meter_trtcm_color_aware_check(struct rte_meter_trtcm *m,
* @return
* Color assigned to the current IP packet
*/
-static inline enum rte_meter_color __rte_experimental
+static inline enum rte_color __rte_experimental
rte_meter_trtcm_rfc4115_color_blind_check(
struct rte_meter_trtcm_rfc4115 *m,
struct rte_meter_trtcm_rfc4115_profile *p,
@@ -326,13 +319,13 @@ rte_meter_trtcm_rfc4115_color_blind_check(
* @return
* Color assigned to the current IP packet
*/
-static inline enum rte_meter_color __rte_experimental
+static inline enum rte_color __rte_experimental
rte_meter_trtcm_rfc4115_color_aware_check(
struct rte_meter_trtcm_rfc4115 *m,
struct rte_meter_trtcm_rfc4115_profile *p,
uint64_t time,
uint32_t pkt_len,
- enum rte_meter_color pkt_color);
+ enum rte_color pkt_color);
/*
* Inline implementation of run-time methods
@@ -417,7 +410,7 @@ struct rte_meter_trtcm_rfc4115 {
/**< Number of bytes currently available in the excess(E) token bucket */
};
-static inline enum rte_meter_color
+static inline enum rte_color
rte_meter_srtcm_color_blind_check(struct rte_meter_srtcm *m,
struct rte_meter_srtcm_profile *p,
uint64_t time,
@@ -444,26 +437,26 @@ rte_meter_srtcm_color_blind_check(struct rte_meter_srtcm *m,
if (tc >= pkt_len) {
m->tc = tc - pkt_len;
m->te = te;
- return e_RTE_METER_GREEN;
+ return RTE_COLOR_GREEN;
}
if (te >= pkt_len) {
m->tc = tc;
m->te = te - pkt_len;
- return e_RTE_METER_YELLOW;
+ return RTE_COLOR_YELLOW;
}
m->tc = tc;
m->te = te;
- return e_RTE_METER_RED;
+ return RTE_COLOR_RED;
}
-static inline enum rte_meter_color
+static inline enum rte_color
rte_meter_srtcm_color_aware_check(struct rte_meter_srtcm *m,
struct rte_meter_srtcm_profile *p,
uint64_t time,
uint32_t pkt_len,
- enum rte_meter_color pkt_color)
+ enum rte_color pkt_color)
{
uint64_t time_diff, n_periods, tc, te;
@@ -483,24 +476,24 @@ rte_meter_srtcm_color_aware_check(struct rte_meter_srtcm *m,
}
/* Color logic */
- if ((pkt_color == e_RTE_METER_GREEN) && (tc >= pkt_len)) {
+ if ((pkt_color == RTE_COLOR_GREEN) && (tc >= pkt_len)) {
m->tc = tc - pkt_len;
m->te = te;
- return e_RTE_METER_GREEN;
+ return RTE_COLOR_GREEN;
}
- if ((pkt_color != e_RTE_METER_RED) && (te >= pkt_len)) {
+ if ((pkt_color != RTE_COLOR_RED) && (te >= pkt_len)) {
m->tc = tc;
m->te = te - pkt_len;
- return e_RTE_METER_YELLOW;
+ return RTE_COLOR_YELLOW;
}
m->tc = tc;
m->te = te;
- return e_RTE_METER_RED;
+ return RTE_COLOR_RED;
}
-static inline enum rte_meter_color
+static inline enum rte_color
rte_meter_trtcm_color_blind_check(struct rte_meter_trtcm *m,
struct rte_meter_trtcm_profile *p,
uint64_t time,
@@ -528,26 +521,26 @@ rte_meter_trtcm_color_blind_check(struct rte_meter_trtcm *m,
if (tp < pkt_len) {
m->tc = tc;
m->tp = tp;
- return e_RTE_METER_RED;
+ return RTE_COLOR_RED;
}
if (tc < pkt_len) {
m->tc = tc;
m->tp = tp - pkt_len;
- return e_RTE_METER_YELLOW;
+ return RTE_COLOR_YELLOW;
}
m->tc = tc - pkt_len;
m->tp = tp - pkt_len;
- return e_RTE_METER_GREEN;
+ return RTE_COLOR_GREEN;
}
-static inline enum rte_meter_color
+static inline enum rte_color
rte_meter_trtcm_color_aware_check(struct rte_meter_trtcm *m,
struct rte_meter_trtcm_profile *p,
uint64_t time,
uint32_t pkt_len,
- enum rte_meter_color pkt_color)
+ enum rte_color pkt_color)
{
uint64_t time_diff_tc, time_diff_tp, n_periods_tc, n_periods_tp, tc, tp;
@@ -568,24 +561,24 @@ rte_meter_trtcm_color_aware_check(struct rte_meter_trtcm *m,
tp = p->pbs;
/* Color logic */
- if ((pkt_color == e_RTE_METER_RED) || (tp < pkt_len)) {
+ if ((pkt_color == RTE_COLOR_RED) || (tp < pkt_len)) {
m->tc = tc;
m->tp = tp;
- return e_RTE_METER_RED;
+ return RTE_COLOR_RED;
}
- if ((pkt_color == e_RTE_METER_YELLOW) || (tc < pkt_len)) {
+ if ((pkt_color == RTE_COLOR_YELLOW) || (tc < pkt_len)) {
m->tc = tc;
m->tp = tp - pkt_len;
- return e_RTE_METER_YELLOW;
+ return RTE_COLOR_YELLOW;
}
m->tc = tc - pkt_len;
m->tp = tp - pkt_len;
- return e_RTE_METER_GREEN;
+ return RTE_COLOR_GREEN;
}
-static inline enum rte_meter_color __rte_experimental
+static inline enum rte_color __rte_experimental
rte_meter_trtcm_rfc4115_color_blind_check(
struct rte_meter_trtcm_rfc4115 *m,
struct rte_meter_trtcm_rfc4115_profile *p,
@@ -614,27 +607,27 @@ rte_meter_trtcm_rfc4115_color_blind_check(
if (tc >= pkt_len) {
m->tc = tc - pkt_len;
m->te = te;
- return e_RTE_METER_GREEN;
+ return RTE_COLOR_GREEN;
}
if (te >= pkt_len) {
m->tc = tc;
m->te = te - pkt_len;
- return e_RTE_METER_YELLOW;
+ return RTE_COLOR_YELLOW;
}
/* If we end up here the color is RED */
m->tc = tc;
m->te = te;
- return e_RTE_METER_RED;
+ return RTE_COLOR_RED;
}
-static inline enum rte_meter_color __rte_experimental
+static inline enum rte_color __rte_experimental
rte_meter_trtcm_rfc4115_color_aware_check(
struct rte_meter_trtcm_rfc4115 *m,
struct rte_meter_trtcm_rfc4115_profile *p,
uint64_t time,
uint32_t pkt_len,
- enum rte_meter_color pkt_color)
+ enum rte_color pkt_color)
{
uint64_t time_diff_tc, time_diff_te, n_periods_tc, n_periods_te, tc, te;
@@ -655,22 +648,22 @@ rte_meter_trtcm_rfc4115_color_aware_check(
te = p->ebs;
/* Color logic */
- if ((pkt_color == e_RTE_METER_GREEN) && (tc >= pkt_len)) {
+ if ((pkt_color == RTE_COLOR_GREEN) && (tc >= pkt_len)) {
m->tc = tc - pkt_len;
m->te = te;
- return e_RTE_METER_GREEN;
+ return RTE_COLOR_GREEN;
}
- if ((pkt_color != e_RTE_METER_RED) && (te >= pkt_len)) {
+ if ((pkt_color != RTE_COLOR_RED) && (te >= pkt_len)) {
m->tc = tc;
m->te = te - pkt_len;
- return e_RTE_METER_YELLOW;
+ return RTE_COLOR_YELLOW;
}
/* If we end up here the color is RED */
m->tc = tc;
m->te = te;
- return e_RTE_METER_RED;
+ return RTE_COLOR_RED;
}
diff --git a/lib/librte_pipeline/rte_table_action.c b/lib/librte_pipeline/rte_table_action.c
index 8a2bb13dc..54d622f3f 100644
--- a/lib/librte_pipeline/rte_table_action.c
+++ b/lib/librte_pipeline/rte_table_action.c
@@ -109,29 +109,29 @@ mtr_cfg_check(struct rte_table_action_mtr_config *mtr)
struct mtr_trtcm_data {
struct rte_meter_trtcm trtcm;
- uint64_t stats[e_RTE_METER_COLORS];
+ uint64_t stats[RTE_COLORS];
} __attribute__((__packed__));
#define MTR_TRTCM_DATA_METER_PROFILE_ID_GET(data) \
- (((data)->stats[e_RTE_METER_GREEN] & 0xF8LLU) >> 3)
+ (((data)->stats[RTE_COLOR_GREEN] & 0xF8LLU) >> 3)
static void
mtr_trtcm_data_meter_profile_id_set(struct mtr_trtcm_data *data,
uint32_t profile_id)
{
- data->stats[e_RTE_METER_GREEN] &= ~0xF8LLU;
- data->stats[e_RTE_METER_GREEN] |= (profile_id % 32) << 3;
+ data->stats[RTE_COLOR_GREEN] &= ~0xF8LLU;
+ data->stats[RTE_COLOR_GREEN] |= (profile_id % 32) << 3;
}
#define MTR_TRTCM_DATA_POLICER_ACTION_DROP_GET(data, color)\
(((data)->stats[(color)] & 4LLU) >> 2)
#define MTR_TRTCM_DATA_POLICER_ACTION_COLOR_GET(data, color)\
- ((enum rte_meter_color)((data)->stats[(color)] & 3LLU))
+ ((enum rte_color)((data)->stats[(color)] & 3LLU))
static void
mtr_trtcm_data_policer_action_set(struct mtr_trtcm_data *data,
- enum rte_meter_color color,
+ enum rte_color color,
enum rte_table_action_policer action)
{
if (action == RTE_TABLE_ACTION_POLICER_DROP) {
@@ -144,14 +144,14 @@ mtr_trtcm_data_policer_action_set(struct mtr_trtcm_data *data,
static uint64_t
mtr_trtcm_data_stats_get(struct mtr_trtcm_data *data,
- enum rte_meter_color color)
+ enum rte_color color)
{
return data->stats[color] >> 8;
}
static void
mtr_trtcm_data_stats_reset(struct mtr_trtcm_data *data,
- enum rte_meter_color color)
+ enum rte_color color)
{
data->stats[color] &= 0xFFLU;
}
@@ -166,7 +166,7 @@ mtr_data_size(struct rte_table_action_mtr_config *mtr)
}
struct dscp_table_entry_data {
- enum rte_meter_color color;
+ enum rte_color color;
uint16_t tc;
uint16_t tc_queue;
};
@@ -287,16 +287,16 @@ mtr_apply(struct mtr_trtcm_data *data,
/* Policer actions */
mtr_trtcm_data_policer_action_set(data_tc,
- e_RTE_METER_GREEN,
- p_tc->policer[e_RTE_METER_GREEN]);
+ RTE_COLOR_GREEN,
+ p_tc->policer[RTE_COLOR_GREEN]);
mtr_trtcm_data_policer_action_set(data_tc,
- e_RTE_METER_YELLOW,
- p_tc->policer[e_RTE_METER_YELLOW]);
+ RTE_COLOR_YELLOW,
+ p_tc->policer[RTE_COLOR_YELLOW]);
mtr_trtcm_data_policer_action_set(data_tc,
- e_RTE_METER_RED,
- p_tc->policer[e_RTE_METER_RED]);
+ RTE_COLOR_RED,
+ p_tc->policer[RTE_COLOR_RED]);
}
return 0;
@@ -313,7 +313,7 @@ pkt_work_mtr(struct rte_mbuf *mbuf,
{
uint64_t drop_mask;
struct dscp_table_entry_data *dscp_entry = &dscp_table->entry[dscp];
- enum rte_meter_color color_in, color_meter, color_policer;
+ enum rte_color color_in, color_meter, color_policer;
uint32_t tc, mp_id;
tc = dscp_entry->tc;
@@ -2672,14 +2672,14 @@ rte_table_action_meter_read(struct rte_table_action *action,
if ((tc_mask & (1 << i)) == 0)
continue;
- dst->n_packets[e_RTE_METER_GREEN] =
- mtr_trtcm_data_stats_get(src, e_RTE_METER_GREEN);
+ dst->n_packets[RTE_COLOR_GREEN] =
+ mtr_trtcm_data_stats_get(src, RTE_COLOR_GREEN);
- dst->n_packets[e_RTE_METER_YELLOW] =
- mtr_trtcm_data_stats_get(src, e_RTE_METER_YELLOW);
+ dst->n_packets[RTE_COLOR_YELLOW] =
+ mtr_trtcm_data_stats_get(src, RTE_COLOR_YELLOW);
- dst->n_packets[e_RTE_METER_RED] =
- mtr_trtcm_data_stats_get(src, e_RTE_METER_RED);
+ dst->n_packets[RTE_COLOR_RED] =
+ mtr_trtcm_data_stats_get(src, RTE_COLOR_RED);
dst->n_packets_valid = 1;
dst->n_bytes_valid = 0;
@@ -2696,9 +2696,9 @@ rte_table_action_meter_read(struct rte_table_action *action,
if ((tc_mask & (1 << i)) == 0)
continue;
- mtr_trtcm_data_stats_reset(src, e_RTE_METER_GREEN);
- mtr_trtcm_data_stats_reset(src, e_RTE_METER_YELLOW);
- mtr_trtcm_data_stats_reset(src, e_RTE_METER_RED);
+ mtr_trtcm_data_stats_reset(src, RTE_COLOR_GREEN);
+ mtr_trtcm_data_stats_reset(src, RTE_COLOR_YELLOW);
+ mtr_trtcm_data_stats_reset(src, RTE_COLOR_RED);
}
diff --git a/lib/librte_pipeline/rte_table_action.h b/lib/librte_pipeline/rte_table_action.h
index c96061291..bb28dfc54 100644
--- a/lib/librte_pipeline/rte_table_action.h
+++ b/lib/librte_pipeline/rte_table_action.h
@@ -202,7 +202,7 @@ struct rte_table_action_dscp_table_entry {
/** Packet color. Used by the meter action as the packet input color
* for the color aware mode of the traffic metering algorithm.
*/
- enum rte_meter_color color;
+ enum rte_color color;
};
/** DSCP translation table. */
@@ -259,7 +259,7 @@ struct rte_table_action_mtr_tc_params {
uint32_t meter_profile_id;
/** Policer actions. */
- enum rte_table_action_policer policer[e_RTE_METER_COLORS];
+ enum rte_table_action_policer policer[RTE_COLORS];
};
/** Meter action statistics counters per traffic class. */
@@ -268,13 +268,13 @@ struct rte_table_action_mtr_counters_tc {
* and before the policer actions are executed. Only valid when
* *n_packets_valid* is non-zero.
*/
- uint64_t n_packets[e_RTE_METER_COLORS];
+ uint64_t n_packets[RTE_COLORS];
/** Number of packet bytes per color at the output of the traffic
* metering and before the policer actions are executed. Only valid when
* *n_bytes_valid* is non-zero.
*/
- uint64_t n_bytes[e_RTE_METER_COLORS];
+ uint64_t n_bytes[RTE_COLORS];
/** When non-zero, the *n_packets* field is valid. */
int n_packets_valid;
diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
index 77aed9fb2..a60ddf97e 100644
--- a/lib/librte_sched/rte_sched.c
+++ b/lib/librte_sched/rte_sched.c
@@ -177,7 +177,7 @@ struct rte_sched_port {
uint32_t n_pipe_profiles;
uint32_t pipe_tc3_rate_max;
#ifdef RTE_SCHED_RED
- struct rte_red_config red_config[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE][e_RTE_METER_COLORS];
+ struct rte_red_config red_config[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE][RTE_COLORS];
#endif
/* Timing */
@@ -642,7 +642,7 @@ rte_sched_port_config(struct rte_sched_port_params *params)
for (i = 0; i < RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE; i++) {
uint32_t j;
- for (j = 0; j < e_RTE_METER_COLORS; j++) {
+ for (j = 0; j < RTE_COLORS; j++) {
/* if min/max are both zero, then RED is disabled */
if ((params->red_params[i][j].min_th |
params->red_params[i][j].max_th) == 0) {
@@ -1015,7 +1015,7 @@ rte_sched_port_pkt_write(struct rte_sched_port *port,
struct rte_mbuf *pkt,
uint32_t subport, uint32_t pipe,
uint32_t traffic_class,
- uint32_t queue, enum rte_meter_color color)
+ uint32_t queue, enum rte_color color)
{
uint32_t queue_id = rte_sched_port_qindex(port, subport, pipe,
traffic_class, queue);
@@ -1037,10 +1037,10 @@ rte_sched_port_pkt_read_tree_path(struct rte_sched_port *port,
*queue = queue_id & (RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS - 1);
}
-enum rte_meter_color
+enum rte_color
rte_sched_port_pkt_read_color(const struct rte_mbuf *pkt)
{
- return (enum rte_meter_color)rte_mbuf_sched_color_get(pkt);
+ return (enum rte_color)rte_mbuf_sched_color_get(pkt);
}
int
@@ -1188,7 +1188,7 @@ rte_sched_port_red_drop(struct rte_sched_port *port, struct rte_mbuf *pkt, uint3
struct rte_red_config *red_cfg;
struct rte_red *red;
uint32_t tc_index;
- enum rte_meter_color color;
+ enum rte_color color;
tc_index = (qindex >> 2) & 0x3;
color = rte_sched_port_pkt_read_color(pkt);
diff --git a/lib/librte_sched/rte_sched.h b/lib/librte_sched/rte_sched.h
index 243efa1d4..904d09d88 100644
--- a/lib/librte_sched/rte_sched.h
+++ b/lib/librte_sched/rte_sched.h
@@ -205,7 +205,7 @@ struct rte_sched_port_params {
* Every pipe is configured using one of the profiles from this table. */
uint32_t n_pipe_profiles; /**< Profiles in the pipe profile table */
#ifdef RTE_SCHED_RED
- struct rte_red_params red_params[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE][e_RTE_METER_COLORS]; /**< RED parameters */
+ struct rte_red_params red_params[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE][RTE_COLORS]; /**< RED parameters */
#endif
};
@@ -374,7 +374,7 @@ void
rte_sched_port_pkt_write(struct rte_sched_port *port,
struct rte_mbuf *pkt,
uint32_t subport, uint32_t pipe, uint32_t traffic_class,
- uint32_t queue, enum rte_meter_color color);
+ uint32_t queue, enum rte_color color);
/**
* Scheduler hierarchy path read from packet descriptor (struct
@@ -402,7 +402,7 @@ rte_sched_port_pkt_read_tree_path(struct rte_sched_port *port,
uint32_t *subport, uint32_t *pipe,
uint32_t *traffic_class, uint32_t *queue);
-enum rte_meter_color
+enum rte_color
rte_sched_port_pkt_read_color(const struct rte_mbuf *pkt);
/**
--
2.17.1
^ permalink raw reply [relevance 1%]
* [dpdk-dev] [PATCH] meter: replace color definitions with rte_color values
2019-03-27 15:44 1% [dpdk-dev] [PATCH] meter: replace color definitions with rte_color values Jasvinder Singh
@ 2019-03-27 15:44 1% ` Jasvinder Singh
0 siblings, 0 replies; 200+ results
From: Jasvinder Singh @ 2019-03-27 15:44 UTC (permalink / raw)
To: dev; +Cc: cristian.dumitrescu
This patch implements the changes proposed in the deprecation
note[1].
Replace mulitple color definitions in various places such as
rte_meter.h, rte_tm.h and rte_mtr.h with single rte_color defined
in rte_meter.h.
[1] https://mails.dpdk.org/archives/dev/2019-January/123861.html
Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
---
app/proc-info/main.c | 36 +++---
app/test-pmd/cmdline_mtr.c | 46 +++----
app/test-pmd/cmdline_tm.c | 22 ++--
app/test/test_meter.c | 126 ++++++++++----------
app/test/test_sched.c | 6 +-
doc/guides/rel_notes/deprecation.rst | 5 -
doc/guides/rel_notes/release_19_05.rst | 6 +-
drivers/net/softnic/rte_eth_softnic_cli.c | 14 +--
drivers/net/softnic/rte_eth_softnic_flow.c | 12 +-
drivers/net/softnic/rte_eth_softnic_meter.c | 26 ++--
drivers/net/softnic/rte_eth_softnic_tm.c | 28 ++---
examples/ip_pipeline/cli.c | 20 ++--
examples/qos_meter/main.h | 10 +-
examples/qos_meter/rte_policer.c | 4 +-
examples/qos_meter/rte_policer.h | 12 +-
examples/qos_sched/app_thread.c | 2 +-
lib/librte_ethdev/rte_mtr.c | 2 +-
lib/librte_ethdev/rte_mtr.h | 10 +-
lib/librte_ethdev/rte_mtr_driver.h | 2 +-
lib/librte_ethdev/rte_tm.h | 14 +--
lib/librte_meter/Makefile | 2 +-
lib/librte_meter/meson.build | 2 +-
lib/librte_meter/rte_meter.h | 91 +++++++-------
lib/librte_pipeline/rte_table_action.c | 50 ++++----
lib/librte_pipeline/rte_table_action.h | 8 +-
lib/librte_sched/rte_sched.c | 12 +-
lib/librte_sched/rte_sched.h | 6 +-
27 files changed, 283 insertions(+), 291 deletions(-)
diff --git a/app/proc-info/main.c b/app/proc-info/main.c
index b9acfa9ec..30189d417 100644
--- a/app/proc-info/main.c
+++ b/app/proc-info/main.c
@@ -873,21 +873,21 @@ show_tm(void)
printf(" - mark support:\n");
printf("\t -- vlan dei: GREEN (%d) YELLOW (%d) RED (%d)\n",
- cap.mark_vlan_dei_supported[RTE_TM_GREEN],
- cap.mark_vlan_dei_supported[RTE_TM_YELLOW],
- cap.mark_vlan_dei_supported[RTE_TM_RED]);
+ cap.mark_vlan_dei_supported[RTE_COLOR_GREEN],
+ cap.mark_vlan_dei_supported[RTE_COLOR_YELLOW],
+ cap.mark_vlan_dei_supported[RTE_COLOR_RED]);
printf("\t -- ip ecn tcp: GREEN (%d) YELLOW (%d) RED (%d)\n",
- cap.mark_ip_ecn_tcp_supported[RTE_TM_GREEN],
- cap.mark_ip_ecn_tcp_supported[RTE_TM_YELLOW],
- cap.mark_ip_ecn_tcp_supported[RTE_TM_RED]);
+ cap.mark_ip_ecn_tcp_supported[RTE_COLOR_GREEN],
+ cap.mark_ip_ecn_tcp_supported[RTE_COLOR_YELLOW],
+ cap.mark_ip_ecn_tcp_supported[RTE_COLOR_RED]);
printf("\t -- ip ecn sctp: GREEN (%d) YELLOW (%d) RED (%d)\n",
- cap.mark_ip_ecn_sctp_supported[RTE_TM_GREEN],
- cap.mark_ip_ecn_sctp_supported[RTE_TM_YELLOW],
- cap.mark_ip_ecn_sctp_supported[RTE_TM_RED]);
+ cap.mark_ip_ecn_sctp_supported[RTE_COLOR_GREEN],
+ cap.mark_ip_ecn_sctp_supported[RTE_COLOR_YELLOW],
+ cap.mark_ip_ecn_sctp_supported[RTE_COLOR_RED]);
printf("\t -- ip dscp: GREEN (%d) YELLOW (%d) RED (%d)\n",
- cap.mark_ip_dscp_supported[RTE_TM_GREEN],
- cap.mark_ip_dscp_supported[RTE_TM_YELLOW],
- cap.mark_ip_dscp_supported[RTE_TM_RED]);
+ cap.mark_ip_dscp_supported[RTE_COLOR_GREEN],
+ cap.mark_ip_dscp_supported[RTE_COLOR_YELLOW],
+ cap.mark_ip_dscp_supported[RTE_COLOR_RED]);
printf(" - mask stats (0x%"PRIx64")"
" dynamic update (0x%"PRIx64")\n",
@@ -1004,12 +1004,12 @@ show_tm(void)
" pkts (%"PRIu64") bytes (%"PRIu64")\n"
"\t -- RED:"
" pkts (%"PRIu64") bytes (%"PRIu64")\n",
- stats.leaf.n_pkts_dropped[RTE_TM_GREEN],
- stats.leaf.n_bytes_dropped[RTE_TM_GREEN],
- stats.leaf.n_pkts_dropped[RTE_TM_YELLOW],
- stats.leaf.n_bytes_dropped[RTE_TM_YELLOW],
- stats.leaf.n_pkts_dropped[RTE_TM_RED],
- stats.leaf.n_bytes_dropped[RTE_TM_RED]);
+ stats.leaf.n_pkts_dropped[RTE_COLOR_GREEN],
+ stats.leaf.n_bytes_dropped[RTE_COLOR_GREEN],
+ stats.leaf.n_pkts_dropped[RTE_COLOR_YELLOW],
+ stats.leaf.n_bytes_dropped[RTE_COLOR_YELLOW],
+ stats.leaf.n_pkts_dropped[RTE_COLOR_RED],
+ stats.leaf.n_bytes_dropped[RTE_COLOR_RED]);
}
}
diff --git a/app/test-pmd/cmdline_mtr.c b/app/test-pmd/cmdline_mtr.c
index c506d87ee..ab5c8642d 100644
--- a/app/test-pmd/cmdline_mtr.c
+++ b/app/test-pmd/cmdline_mtr.c
@@ -74,7 +74,7 @@ parse_uint(uint64_t *value, const char *str)
}
static int
-parse_dscp_table_entries(char *str, enum rte_mtr_color **dscp_table)
+parse_dscp_table_entries(char *str, enum rte_color **dscp_table)
{
char *token;
int i = 0;
@@ -84,21 +84,21 @@ parse_dscp_table_entries(char *str, enum rte_mtr_color **dscp_table)
return 0;
/* Allocate memory for dscp table */
- *dscp_table = (enum rte_mtr_color *)malloc(MAX_DSCP_TABLE_ENTRIES *
- sizeof(enum rte_mtr_color));
+ *dscp_table = (enum rte_color *)malloc(MAX_DSCP_TABLE_ENTRIES *
+ sizeof(enum rte_color));
if (*dscp_table == NULL)
return -1;
while (1) {
if (strcmp(token, "G") == 0 ||
strcmp(token, "g") == 0)
- *dscp_table[i++] = RTE_MTR_GREEN;
+ *dscp_table[i++] = RTE_COLOR_GREEN;
else if (strcmp(token, "Y") == 0 ||
strcmp(token, "y") == 0)
- *dscp_table[i++] = RTE_MTR_YELLOW;
+ *dscp_table[i++] = RTE_COLOR_YELLOW;
else if (strcmp(token, "R") == 0 ||
strcmp(token, "r") == 0)
- *dscp_table[i++] = RTE_MTR_RED;
+ *dscp_table[i++] = RTE_COLOR_RED;
else {
free(*dscp_table);
return -1;
@@ -117,7 +117,7 @@ parse_dscp_table_entries(char *str, enum rte_mtr_color **dscp_table)
static int
parse_meter_color_str(char *c_str, uint32_t *use_prev_meter_color,
- enum rte_mtr_color **dscp_table)
+ enum rte_color **dscp_table)
{
char *token;
uint64_t previous_mtr_color = 0;
@@ -182,20 +182,20 @@ parse_policer_action_string(char *p_str, uint32_t action_mask,
return -1;
if (g_color == 0 && (action_mask & 0x1)) {
- actions[RTE_MTR_GREEN] = action;
+ actions[RTE_COLOR_GREEN] = action;
g_color = 1;
} else if (y_color == 0 && (action_mask & 0x2)) {
- actions[RTE_MTR_YELLOW] = action;
+ actions[RTE_COLOR_YELLOW] = action;
y_color = 1;
} else
- actions[RTE_MTR_RED] = action;
+ actions[RTE_COLOR_RED] = action;
}
return 0;
}
static int
parse_multi_token_string(char *t_str, uint16_t *port_id,
- uint32_t *mtr_id, enum rte_mtr_color **dscp_table)
+ uint32_t *mtr_id, enum rte_color **dscp_table)
{
char *token;
uint64_t val;
@@ -782,7 +782,7 @@ static void cmd_create_port_meter_parsed(void *parsed_result,
uint32_t shared = res->shared;
uint32_t use_prev_meter_color = 0;
uint16_t port_id = res->port_id;
- enum rte_mtr_color *dscp_table = NULL;
+ enum rte_color *dscp_table = NULL;
char *c_str = res->meter_input_color;
int ret;
@@ -808,11 +808,11 @@ static void cmd_create_port_meter_parsed(void *parsed_result,
else
params.meter_enable = 0;
- params.action[RTE_MTR_GREEN] =
+ params.action[RTE_COLOR_GREEN] =
string_to_policer_action(res->g_action);
- params.action[RTE_MTR_YELLOW] =
+ params.action[RTE_COLOR_YELLOW] =
string_to_policer_action(res->y_action);
- params.action[RTE_MTR_RED] =
+ params.action[RTE_COLOR_RED] =
string_to_policer_action(res->r_action);
params.stats_mask = res->statistics_mask;
@@ -1134,7 +1134,7 @@ static void cmd_set_port_meter_dscp_table_parsed(void *parsed_result,
{
struct cmd_set_port_meter_dscp_table_result *res = parsed_result;
struct rte_mtr_error error;
- enum rte_mtr_color *dscp_table = NULL;
+ enum rte_color *dscp_table = NULL;
char *t_str = res->token_string;
uint32_t mtr_id = 0;
uint16_t port_id;
@@ -1245,7 +1245,7 @@ static void cmd_set_port_meter_policer_action_parsed(void *parsed_result,
}
/* Allocate memory for policer actions */
- actions = (enum rte_mtr_policer_action *)malloc(RTE_MTR_COLORS *
+ actions = (enum rte_mtr_policer_action *)malloc(RTE_COLORS *
sizeof(enum rte_mtr_policer_action));
if (actions == NULL) {
printf("Memory for policer actions not allocated (error)\n");
@@ -1426,22 +1426,22 @@ static void cmd_show_port_meter_stats_parsed(void *parsed_result,
/* Display stats */
if (stats_mask & RTE_MTR_STATS_N_PKTS_GREEN)
printf("\tPkts G: %" PRIu64 "\n",
- stats.n_pkts[RTE_MTR_GREEN]);
+ stats.n_pkts[RTE_COLOR_GREEN]);
if (stats_mask & RTE_MTR_STATS_N_BYTES_GREEN)
printf("\tBytes G: %" PRIu64 "\n",
- stats.n_bytes[RTE_MTR_GREEN]);
+ stats.n_bytes[RTE_COLOR_GREEN]);
if (stats_mask & RTE_MTR_STATS_N_PKTS_YELLOW)
printf("\tPkts Y: %" PRIu64 "\n",
- stats.n_pkts[RTE_MTR_YELLOW]);
+ stats.n_pkts[RTE_COLOR_YELLOW]);
if (stats_mask & RTE_MTR_STATS_N_BYTES_YELLOW)
printf("\tBytes Y: %" PRIu64 "\n",
- stats.n_bytes[RTE_MTR_YELLOW]);
+ stats.n_bytes[RTE_COLOR_YELLOW]);
if (stats_mask & RTE_MTR_STATS_N_PKTS_RED)
printf("\tPkts R: %" PRIu64 "\n",
- stats.n_pkts[RTE_MTR_RED]);
+ stats.n_pkts[RTE_COLOR_RED]);
if (stats_mask & RTE_MTR_STATS_N_BYTES_RED)
printf("\tBytes R: %" PRIu64 "\n",
- stats.n_bytes[RTE_MTR_RED]);
+ stats.n_bytes[RTE_COLOR_RED]);
if (stats_mask & RTE_MTR_STATS_N_PKTS_DROPPED)
printf("\tPkts DROPPED: %" PRIu64 "\n",
stats.n_pkts_dropped);
diff --git a/app/test-pmd/cmdline_tm.c b/app/test-pmd/cmdline_tm.c
index 101208474..d62a4f544 100644
--- a/app/test-pmd/cmdline_tm.c
+++ b/app/test-pmd/cmdline_tm.c
@@ -296,7 +296,7 @@ static void cmd_show_port_tm_cap_parsed(void *parsed_result,
printf("cap.cman_wred_context_shared_n_contexts_per_node_max %" PRIu32
"\n", cap.cman_wred_context_shared_n_contexts_per_node_max);
- for (i = 0; i < RTE_TM_COLORS; i++) {
+ for (i = 0; i < RTE_COLORS; i++) {
printf("cap.mark_vlan_dei_supported %" PRId32 "\n",
cap.mark_vlan_dei_supported[i]);
printf("cap.mark_ip_ecn_tcp_supported %" PRId32 "\n",
@@ -642,22 +642,22 @@ static void cmd_show_port_tm_node_stats_parsed(void *parsed_result,
stats.n_bytes);
if (stats_mask & RTE_TM_STATS_N_PKTS_GREEN_DROPPED)
printf("\tPkts dropped (green): %" PRIu64 "\n",
- stats.leaf.n_pkts_dropped[RTE_TM_GREEN]);
+ stats.leaf.n_pkts_dropped[RTE_COLOR_GREEN]);
if (stats_mask & RTE_TM_STATS_N_PKTS_YELLOW_DROPPED)
printf("\tPkts dropped (yellow): %" PRIu64 "\n",
- stats.leaf.n_pkts_dropped[RTE_TM_YELLOW]);
+ stats.leaf.n_pkts_dropped[RTE_COLOR_YELLOW]);
if (stats_mask & RTE_TM_STATS_N_PKTS_RED_DROPPED)
printf("\tPkts dropped (red): %" PRIu64 "\n",
- stats.leaf.n_pkts_dropped[RTE_TM_RED]);
+ stats.leaf.n_pkts_dropped[RTE_COLOR_RED]);
if (stats_mask & RTE_TM_STATS_N_BYTES_GREEN_DROPPED)
printf("\tBytes dropped (green): %" PRIu64 "\n",
- stats.leaf.n_bytes_dropped[RTE_TM_GREEN]);
+ stats.leaf.n_bytes_dropped[RTE_COLOR_GREEN]);
if (stats_mask & RTE_TM_STATS_N_BYTES_YELLOW_DROPPED)
printf("\tBytes dropped (yellow): %" PRIu64 "\n",
- stats.leaf.n_bytes_dropped[RTE_TM_YELLOW]);
+ stats.leaf.n_bytes_dropped[RTE_COLOR_YELLOW]);
if (stats_mask & RTE_TM_STATS_N_BYTES_RED_DROPPED)
printf("\tBytes dropped (red): %" PRIu64 "\n",
- stats.leaf.n_bytes_dropped[RTE_TM_RED]);
+ stats.leaf.n_bytes_dropped[RTE_COLOR_RED]);
if (stats_mask & RTE_TM_STATS_N_PKTS_QUEUED)
printf("\tPkts queued: %" PRIu64 "\n",
stats.leaf.n_pkts_queued);
@@ -1267,7 +1267,7 @@ static void cmd_add_port_tm_node_wred_profile_parsed(void *parsed_result,
{
struct cmd_add_port_tm_node_wred_profile_result *res = parsed_result;
struct rte_tm_wred_params wp;
- enum rte_tm_color color;
+ enum rte_color color;
struct rte_tm_error error;
uint32_t wred_profile_id = res->wred_profile_id;
portid_t port_id = res->port_id;
@@ -1280,7 +1280,7 @@ static void cmd_add_port_tm_node_wred_profile_parsed(void *parsed_result,
memset(&error, 0, sizeof(struct rte_tm_error));
/* WRED Params (Green Color)*/
- color = RTE_TM_GREEN;
+ color = RTE_COLOR_GREEN;
wp.red_params[color].min_th = res->min_th_g;
wp.red_params[color].max_th = res->max_th_g;
wp.red_params[color].maxp_inv = res->maxp_inv_g;
@@ -1288,14 +1288,14 @@ static void cmd_add_port_tm_node_wred_profile_parsed(void *parsed_result,
/* WRED Params (Yellow Color)*/
- color = RTE_TM_YELLOW;
+ color = RTE_COLOR_YELLOW;
wp.red_params[color].min_th = res->min_th_y;
wp.red_params[color].max_th = res->max_th_y;
wp.red_params[color].maxp_inv = res->maxp_inv_y;
wp.red_params[color].wq_log2 = res->wq_log2_y;
/* WRED Params (Red Color)*/
- color = RTE_TM_RED;
+ color = RTE_COLOR_RED;
wp.red_params[color].min_th = res->min_th_r;
wp.red_params[color].max_th = res->max_th_r;
wp.red_params[color].maxp_inv = res->maxp_inv_r;
diff --git a/app/test/test_meter.c b/app/test/test_meter.c
index f935faa53..f6fe6494a 100644
--- a/app/test/test_meter.c
+++ b/app/test/test_meter.c
@@ -215,7 +215,7 @@ tm_test_srtcm_color_blind_check(void)
time = rte_get_tsc_cycles() + hz;
if (rte_meter_srtcm_color_blind_check(
&sm, &sp, time, TM_TEST_SRTCM_CBS_DF - 1)
- != e_RTE_METER_GREEN)
+ != RTE_COLOR_GREEN)
melog(SRTCM_BLIND_CHECK_MSG" GREEN");
/* Test yellow */
@@ -226,7 +226,7 @@ tm_test_srtcm_color_blind_check(void)
time = rte_get_tsc_cycles() + hz;
if (rte_meter_srtcm_color_blind_check(
&sm, &sp, time, TM_TEST_SRTCM_CBS_DF + 1)
- != e_RTE_METER_YELLOW)
+ != RTE_COLOR_YELLOW)
melog(SRTCM_BLIND_CHECK_MSG" YELLOW");
if (rte_meter_srtcm_profile_config(&sp, &sparams) != 0)
@@ -235,7 +235,7 @@ tm_test_srtcm_color_blind_check(void)
melog(SRTCM_BLIND_CHECK_MSG);
time = rte_get_tsc_cycles() + hz;
if (rte_meter_srtcm_color_blind_check(
- &sm, &sp, time, (uint32_t)sp.ebs - 1) != e_RTE_METER_YELLOW)
+ &sm, &sp, time, (uint32_t)sp.ebs - 1) != RTE_COLOR_YELLOW)
melog(SRTCM_BLIND_CHECK_MSG" YELLOW");
/* Test red */
@@ -246,7 +246,7 @@ tm_test_srtcm_color_blind_check(void)
time = rte_get_tsc_cycles() + hz;
if (rte_meter_srtcm_color_blind_check(
&sm, &sp, time, TM_TEST_SRTCM_EBS_DF + 1)
- != e_RTE_METER_RED)
+ != RTE_COLOR_RED)
melog(SRTCM_BLIND_CHECK_MSG" RED");
return 0;
@@ -274,7 +274,7 @@ tm_test_trtcm_color_blind_check(void)
time = rte_get_tsc_cycles() + hz;
if (rte_meter_trtcm_color_blind_check(
&tm, &tp, time, TM_TEST_TRTCM_CBS_DF - 1)
- != e_RTE_METER_GREEN)
+ != RTE_COLOR_GREEN)
melog(TRTCM_BLIND_CHECK_MSG" GREEN");
/* Test yellow */
@@ -285,7 +285,7 @@ tm_test_trtcm_color_blind_check(void)
time = rte_get_tsc_cycles() + hz;
if (rte_meter_trtcm_color_blind_check(
&tm, &tp, time, TM_TEST_TRTCM_CBS_DF + 1)
- != e_RTE_METER_YELLOW)
+ != RTE_COLOR_YELLOW)
melog(TRTCM_BLIND_CHECK_MSG" YELLOW");
if (rte_meter_trtcm_profile_config(&tp, &tparams) != 0)
@@ -295,7 +295,7 @@ tm_test_trtcm_color_blind_check(void)
time = rte_get_tsc_cycles() + hz;
if (rte_meter_trtcm_color_blind_check(
&tm, &tp, time, TM_TEST_TRTCM_PBS_DF - 1)
- != e_RTE_METER_YELLOW)
+ != RTE_COLOR_YELLOW)
melog(TRTCM_BLIND_CHECK_MSG" YELLOW");
/* Test red */
@@ -306,7 +306,7 @@ tm_test_trtcm_color_blind_check(void)
time = rte_get_tsc_cycles() + hz;
if (rte_meter_trtcm_color_blind_check(
&tm, &tp, time, TM_TEST_TRTCM_PBS_DF + 1)
- != e_RTE_METER_RED)
+ != RTE_COLOR_RED)
melog(TRTCM_BLIND_CHECK_MSG" RED");
return 0;
@@ -333,7 +333,7 @@ tm_test_trtcm_rfc4115_color_blind_check(void)
time = rte_get_tsc_cycles() + hz;
if (rte_meter_trtcm_rfc4115_color_blind_check(
&tm, &tp, time, TM_TEST_TRTCM_CBS_DF - 1)
- != e_RTE_METER_GREEN)
+ != RTE_COLOR_GREEN)
melog(TRTCM_RFC4115_BLIND_CHECK_MSG" GREEN");
/* Test yellow */
@@ -344,7 +344,7 @@ tm_test_trtcm_rfc4115_color_blind_check(void)
time = rte_get_tsc_cycles() + hz;
if (rte_meter_trtcm_rfc4115_color_blind_check(
&tm, &tp, time, TM_TEST_TRTCM_CBS_DF + 1)
- != e_RTE_METER_YELLOW)
+ != RTE_COLOR_YELLOW)
melog(TRTCM_RFC4115_BLIND_CHECK_MSG" YELLOW");
if (rte_meter_trtcm_rfc4115_profile_config(&tp, &rfc4115params) != 0)
@@ -354,7 +354,7 @@ tm_test_trtcm_rfc4115_color_blind_check(void)
time = rte_get_tsc_cycles() + hz;
if (rte_meter_trtcm_rfc4115_color_blind_check(
&tm, &tp, time, TM_TEST_TRTCM_EBS_DF - 1)
- != e_RTE_METER_YELLOW)
+ != RTE_COLOR_YELLOW)
melog(TRTCM_RFC4115_BLIND_CHECK_MSG" YELLOW");
/* Test red */
@@ -365,7 +365,7 @@ tm_test_trtcm_rfc4115_color_blind_check(void)
time = rte_get_tsc_cycles() + hz;
if (rte_meter_trtcm_rfc4115_color_blind_check(
&tm, &tp, time, TM_TEST_TRTCM_EBS_DF + 1)
- != e_RTE_METER_RED)
+ != RTE_COLOR_RED)
melog(TRTCM_RFC4115_BLIND_CHECK_MSG" RED");
return 0;
@@ -383,7 +383,7 @@ tm_test_trtcm_rfc4115_color_blind_check(void)
static inline int
tm_test_srtcm_aware_check
-(enum rte_meter_color in[4], enum rte_meter_color out[4])
+(enum rte_color in[4], enum rte_color out[4])
{
#define SRTCM_AWARE_CHECK_MSG "srtcm_aware_check"
struct rte_meter_srtcm_profile sp;
@@ -437,7 +437,7 @@ tm_test_srtcm_aware_check
static inline int
tm_test_srtcm_color_aware_check(void)
{
- enum rte_meter_color in[4], out[4];
+ enum rte_color in[4], out[4];
/**
* test 4 points that will produce green, yellow, yellow, red flag
@@ -445,11 +445,11 @@ tm_test_srtcm_color_aware_check(void)
*/
/* previouly have a green, test points should keep unchanged */
- in[0] = in[1] = in[2] = in[3] = e_RTE_METER_GREEN;
- out[0] = e_RTE_METER_GREEN;
- out[1] = e_RTE_METER_YELLOW;
- out[2] = e_RTE_METER_YELLOW;
- out[3] = e_RTE_METER_RED;
+ in[0] = in[1] = in[2] = in[3] = RTE_COLOR_GREEN;
+ out[0] = RTE_COLOR_GREEN;
+ out[1] = RTE_COLOR_YELLOW;
+ out[2] = RTE_COLOR_YELLOW;
+ out[3] = RTE_COLOR_RED;
if (tm_test_srtcm_aware_check(in, out) != 0)
return -1;
@@ -457,11 +457,11 @@ tm_test_srtcm_color_aware_check(void)
* previously have a yellow, green & yellow = yellow
* yellow & red = red
*/
- in[0] = in[1] = in[2] = in[3] = e_RTE_METER_YELLOW;
- out[0] = e_RTE_METER_YELLOW;
- out[1] = e_RTE_METER_YELLOW;
- out[2] = e_RTE_METER_YELLOW;
- out[3] = e_RTE_METER_RED;
+ in[0] = in[1] = in[2] = in[3] = RTE_COLOR_YELLOW;
+ out[0] = RTE_COLOR_YELLOW;
+ out[1] = RTE_COLOR_YELLOW;
+ out[2] = RTE_COLOR_YELLOW;
+ out[3] = RTE_COLOR_RED;
if (tm_test_srtcm_aware_check(in, out) != 0)
return -1;
@@ -469,11 +469,11 @@ tm_test_srtcm_color_aware_check(void)
* previously have a red, red & green = red
* red & yellow = red
*/
- in[0] = in[1] = in[2] = in[3] = e_RTE_METER_RED;
- out[0] = e_RTE_METER_RED;
- out[1] = e_RTE_METER_RED;
- out[2] = e_RTE_METER_RED;
- out[3] = e_RTE_METER_RED;
+ in[0] = in[1] = in[2] = in[3] = RTE_COLOR_RED;
+ out[0] = RTE_COLOR_RED;
+ out[1] = RTE_COLOR_RED;
+ out[2] = RTE_COLOR_RED;
+ out[3] = RTE_COLOR_RED;
if (tm_test_srtcm_aware_check(in, out) != 0)
return -1;
@@ -490,7 +490,7 @@ tm_test_srtcm_color_aware_check(void)
*/
static inline int
tm_test_trtcm_aware_check
-(enum rte_meter_color in[4], enum rte_meter_color out[4])
+(enum rte_color in[4], enum rte_color out[4])
{
#define TRTCM_AWARE_CHECK_MSG "trtcm_aware_check"
struct rte_meter_trtcm_profile tp;
@@ -545,34 +545,34 @@ tm_test_trtcm_aware_check
static inline int
tm_test_trtcm_color_aware_check(void)
{
- enum rte_meter_color in[4], out[4];
+ enum rte_color in[4], out[4];
/**
* test 4 points that will produce green, yellow, yellow, red flag
* if using blind check
*/
/* previouly have a green, test points should keep unchanged */
- in[0] = in[1] = in[2] = in[3] = e_RTE_METER_GREEN;
- out[0] = e_RTE_METER_GREEN;
- out[1] = e_RTE_METER_YELLOW;
- out[2] = e_RTE_METER_YELLOW;
- out[3] = e_RTE_METER_RED;
+ in[0] = in[1] = in[2] = in[3] = RTE_COLOR_GREEN;
+ out[0] = RTE_COLOR_GREEN;
+ out[1] = RTE_COLOR_YELLOW;
+ out[2] = RTE_COLOR_YELLOW;
+ out[3] = RTE_COLOR_RED;
if (tm_test_trtcm_aware_check(in, out) != 0)
return -1;
- in[0] = in[1] = in[2] = in[3] = e_RTE_METER_YELLOW;
- out[0] = e_RTE_METER_YELLOW;
- out[1] = e_RTE_METER_YELLOW;
- out[2] = e_RTE_METER_YELLOW;
- out[3] = e_RTE_METER_RED;
+ in[0] = in[1] = in[2] = in[3] = RTE_COLOR_YELLOW;
+ out[0] = RTE_COLOR_YELLOW;
+ out[1] = RTE_COLOR_YELLOW;
+ out[2] = RTE_COLOR_YELLOW;
+ out[3] = RTE_COLOR_RED;
if (tm_test_trtcm_aware_check(in, out) != 0)
return -1;
- in[0] = in[1] = in[2] = in[3] = e_RTE_METER_RED;
- out[0] = e_RTE_METER_RED;
- out[1] = e_RTE_METER_RED;
- out[2] = e_RTE_METER_RED;
- out[3] = e_RTE_METER_RED;
+ in[0] = in[1] = in[2] = in[3] = RTE_COLOR_RED;
+ out[0] = RTE_COLOR_RED;
+ out[1] = RTE_COLOR_RED;
+ out[2] = RTE_COLOR_RED;
+ out[3] = RTE_COLOR_RED;
if (tm_test_trtcm_aware_check(in, out) != 0)
return -1;
@@ -589,7 +589,7 @@ tm_test_trtcm_color_aware_check(void)
*/
static inline int
tm_test_trtcm_rfc4115_aware_check
-(enum rte_meter_color in[4], enum rte_meter_color out[4])
+(enum rte_color in[4], enum rte_color out[4])
{
#define TRTCM_RFC4115_AWARE_CHECK_MSG "trtcm_rfc4115_aware_check"
struct rte_meter_trtcm_rfc4115_profile tp;
@@ -642,34 +642,34 @@ tm_test_trtcm_rfc4115_aware_check
static inline int
tm_test_trtcm_rfc4115_color_aware_check(void)
{
- enum rte_meter_color in[4], out[4];
+ enum rte_color in[4], out[4];
/**
* test 4 points that will produce green, yellow, yellow, red flag
* if using blind check
*/
/* previouly have a green, test points should keep unchanged */
- in[0] = in[1] = in[2] = in[3] = e_RTE_METER_GREEN;
- out[0] = e_RTE_METER_GREEN;
- out[1] = e_RTE_METER_YELLOW;
- out[2] = e_RTE_METER_YELLOW;
- out[3] = e_RTE_METER_RED;
+ in[0] = in[1] = in[2] = in[3] = RTE_COLOR_GREEN;
+ out[0] = RTE_COLOR_GREEN;
+ out[1] = RTE_COLOR_YELLOW;
+ out[2] = RTE_COLOR_YELLOW;
+ out[3] = RTE_COLOR_RED;
if (tm_test_trtcm_rfc4115_aware_check(in, out) != 0)
return -1;
- in[0] = in[1] = in[2] = in[3] = e_RTE_METER_YELLOW;
- out[0] = e_RTE_METER_YELLOW;
- out[1] = e_RTE_METER_YELLOW;
- out[2] = e_RTE_METER_YELLOW;
- out[3] = e_RTE_METER_RED;
+ in[0] = in[1] = in[2] = in[3] = RTE_COLOR_YELLOW;
+ out[0] = RTE_COLOR_YELLOW;
+ out[1] = RTE_COLOR_YELLOW;
+ out[2] = RTE_COLOR_YELLOW;
+ out[3] = RTE_COLOR_RED;
if (tm_test_trtcm_rfc4115_aware_check(in, out) != 0)
return -1;
- in[0] = in[1] = in[2] = in[3] = e_RTE_METER_RED;
- out[0] = e_RTE_METER_RED;
- out[1] = e_RTE_METER_RED;
- out[2] = e_RTE_METER_RED;
- out[3] = e_RTE_METER_RED;
+ in[0] = in[1] = in[2] = in[3] = RTE_COLOR_RED;
+ out[0] = RTE_COLOR_RED;
+ out[1] = RTE_COLOR_RED;
+ out[2] = RTE_COLOR_RED;
+ out[3] = RTE_COLOR_RED;
if (tm_test_trtcm_rfc4115_aware_check(in, out) != 0)
return -1;
diff --git a/app/test/test_sched.c b/app/test/test_sched.c
index 40e411cab..4eed8dbde 100644
--- a/app/test/test_sched.c
+++ b/app/test/test_sched.c
@@ -96,7 +96,7 @@ prepare_pkt(struct rte_sched_port *port, struct rte_mbuf *mbuf)
rte_sched_port_pkt_write(port, mbuf, SUBPORT, PIPE, TC, QUEUE,
- e_RTE_METER_YELLOW);
+ RTE_COLOR_YELLOW);
/* 64 byte packet */
mbuf->pkt_len = 60;
@@ -150,11 +150,11 @@ test_sched(void)
TEST_ASSERT_EQUAL(err, 10, "Wrong dequeue, err=%d\n", err);
for (i = 0; i < 10; i++) {
- enum rte_meter_color color;
+ enum rte_color color;
uint32_t subport, traffic_class, queue;
color = rte_sched_port_pkt_read_color(out_mbufs[i]);
- TEST_ASSERT_EQUAL(color, e_RTE_METER_YELLOW, "Wrong color\n");
+ TEST_ASSERT_EQUAL(color, RTE_COLOR_YELLOW, "Wrong color\n");
rte_sched_port_pkt_read_tree_path(port, out_mbufs[i],
&subport, &pipe, &traffic_class, &queue);
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 1b4fcb7e6..e91a1bb45 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -68,10 +68,5 @@ Deprecation Notices
- Member ``uint16_t min_mtu`` the minimum MTU allowed.
- Member ``uint16_t max_mtu`` the maximum MTU allowed.
-* meter: New ``rte_color`` definition will be added in 19.02 and that will
- replace ``enum rte_meter_color`` in meter library in 19.05. This will help
- to consolidate color definition, which is currently replicated in many places,
- such as: rte_meter.h, rte_mtr.h, rte_tm.h.
-
* crypto/aesni_mb: the minimum supported intel-ipsec-mb library version will be
changed from 0.49.0 to 0.52.0.
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index d11bb5a2b..c97e5a48c 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -134,6 +134,10 @@ API Changes
Also, make sure to start the actual text at the margin.
=========================================================
+* meter: replace ``enum rte_meter_color`` in meter library with new
+ ``rte_color`` definition added in 19.02. To consolidate mulitple color
+ definitions replicated at many places such as: rte_mtr.h, rte_tm.h,
+ replacements with rte_color values are done.
ABI Changes
-----------
@@ -207,7 +211,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_mbuf.so.5
librte_member.so.1
librte_mempool.so.5
- librte_meter.so.2
+ librte_meter.so.3
librte_metrics.so.1
librte_net.so.1
librte_pci.so.1
diff --git a/drivers/net/softnic/rte_eth_softnic_cli.c b/drivers/net/softnic/rte_eth_softnic_cli.c
index 76136c2e2..b83fd038f 100644
--- a/drivers/net/softnic/rte_eth_softnic_cli.c
+++ b/drivers/net/softnic/rte_eth_softnic_cli.c
@@ -3550,11 +3550,11 @@ parse_table_action_meter_tc(char **tokens,
softnic_parser_read_uint32(&mtr->meter_profile_id, tokens[1]) ||
strcmp(tokens[2], "policer") ||
strcmp(tokens[3], "g") ||
- parse_policer_action(tokens[4], &mtr->policer[e_RTE_METER_GREEN]) ||
+ parse_policer_action(tokens[4], &mtr->policer[RTE_COLOR_GREEN]) ||
strcmp(tokens[5], "y") ||
- parse_policer_action(tokens[6], &mtr->policer[e_RTE_METER_YELLOW]) ||
+ parse_policer_action(tokens[6], &mtr->policer[RTE_COLOR_YELLOW]) ||
strcmp(tokens[7], "r") ||
- parse_policer_action(tokens[8], &mtr->policer[e_RTE_METER_RED]))
+ parse_policer_action(tokens[8], &mtr->policer[RTE_COLOR_RED]))
return 0;
return 9;
@@ -5384,7 +5384,7 @@ load_dscp_table(struct rte_table_action_dscp_table *dscp_table,
for (dscp = 0, l = 1; ; l++) {
char line[64];
char *tokens[3];
- enum rte_meter_color color;
+ enum rte_color color;
uint32_t tc_id, tc_queue_id, n_tokens = RTE_DIM(tokens);
if (fgets(line, sizeof(line), f) == NULL)
@@ -5417,17 +5417,17 @@ load_dscp_table(struct rte_table_action_dscp_table *dscp_table,
switch (tokens[2][0]) {
case 'g':
case 'G':
- color = e_RTE_METER_GREEN;
+ color = RTE_COLOR_GREEN;
break;
case 'y':
case 'Y':
- color = e_RTE_METER_YELLOW;
+ color = RTE_COLOR_YELLOW;
break;
case 'r':
case 'R':
- color = e_RTE_METER_RED;
+ color = RTE_COLOR_RED;
break;
default:
diff --git a/drivers/net/softnic/rte_eth_softnic_flow.c b/drivers/net/softnic/rte_eth_softnic_flow.c
index aefc384dc..ccd58c01c 100644
--- a/drivers/net/softnic/rte_eth_softnic_flow.c
+++ b/drivers/net/softnic/rte_eth_softnic_flow.c
@@ -1624,12 +1624,12 @@ flow_rule_action_get(struct pmd_internals *softnic,
/* RTE_TABLE_ACTION_METER */
rule_action->mtr.mtr[0].meter_profile_id = meter_profile_id;
- rule_action->mtr.mtr[0].policer[e_RTE_METER_GREEN] =
- softnic_table_action_policer(m->params.action[RTE_MTR_GREEN]);
- rule_action->mtr.mtr[0].policer[e_RTE_METER_YELLOW] =
- softnic_table_action_policer(m->params.action[RTE_MTR_YELLOW]);
- rule_action->mtr.mtr[0].policer[e_RTE_METER_RED] =
- softnic_table_action_policer(m->params.action[RTE_MTR_RED]);
+ rule_action->mtr.mtr[0].policer[RTE_COLOR_GREEN] =
+ softnic_table_action_policer(m->params.action[RTE_COLOR_GREEN]);
+ rule_action->mtr.mtr[0].policer[RTE_COLOR_YELLOW] =
+ softnic_table_action_policer(m->params.action[RTE_COLOR_YELLOW]);
+ rule_action->mtr.mtr[0].policer[RTE_COLOR_RED] =
+ softnic_table_action_policer(m->params.action[RTE_COLOR_RED]);
rule_action->mtr.tc_mask = 1;
rule_action->action_mask |= 1 << RTE_TABLE_ACTION_MTR;
break;
diff --git a/drivers/net/softnic/rte_eth_softnic_meter.c b/drivers/net/softnic/rte_eth_softnic_meter.c
index 7b747ba5d..31a2a0e6d 100644
--- a/drivers/net/softnic/rte_eth_softnic_meter.c
+++ b/drivers/net/softnic/rte_eth_softnic_meter.c
@@ -458,7 +458,7 @@ pmd_mtr_meter_profile_update(struct rte_eth_dev *dev,
static int
pmd_mtr_meter_dscp_table_update(struct rte_eth_dev *dev,
uint32_t mtr_id,
- enum rte_mtr_color *dscp_table,
+ enum rte_color *dscp_table,
struct rte_mtr_error *error)
{
struct pmd_internals *p = dev->data->dev_private;
@@ -488,7 +488,7 @@ pmd_mtr_meter_dscp_table_update(struct rte_eth_dev *dev,
memcpy(&dt, &table->dscp_table, sizeof(dt));
for (i = 0; i < RTE_DIM(dt.entry); i++)
- dt.entry[i].color = (enum rte_meter_color)dscp_table[i];
+ dt.entry[i].color = (enum rte_color)dscp_table[i];
/* Update table */
status = softnic_pipeline_table_dscp_table_update(p,
@@ -536,7 +536,7 @@ pmd_mtr_policer_actions_update(struct rte_eth_dev *dev,
NULL,
"Invalid actions");
- for (i = 0; i < RTE_MTR_COLORS; i++) {
+ for (i = 0; i < RTE_COLORS; i++) {
if (action_mask & (1 << i)) {
if (actions[i] != MTR_POLICER_ACTION_COLOR_GREEN &&
actions[i] != MTR_POLICER_ACTION_COLOR_YELLOW &&
@@ -560,7 +560,7 @@ pmd_mtr_policer_actions_update(struct rte_eth_dev *dev,
memcpy(&action, &m->flow->action, sizeof(action));
/* Set action */
- for (i = 0; i < RTE_MTR_COLORS; i++)
+ for (i = 0; i < RTE_COLORS; i++)
if (action_mask & (1 << i))
action.mtr.mtr[0].policer[i] =
softnic_table_action_policer(actions[i]);
@@ -588,7 +588,7 @@ pmd_mtr_policer_actions_update(struct rte_eth_dev *dev,
}
/* Meter: Update policer actions */
- for (i = 0; i < RTE_MTR_COLORS; i++)
+ for (i = 0; i < RTE_COLORS; i++)
if (action_mask & (1 << i))
m->params.action[i] = actions[i];
@@ -618,15 +618,15 @@ mtr_stats_convert(struct softnic_mtr *m,
if (in->n_packets_valid) {
uint32_t i;
- for (i = 0; i < RTE_MTR_COLORS; i++) {
+ for (i = 0; i < RTE_COLORS; i++) {
if (m->params.action[i] == MTR_POLICER_ACTION_COLOR_GREEN)
- out->n_pkts[RTE_MTR_GREEN] += in->n_packets[i];
+ out->n_pkts[RTE_COLOR_GREEN] += in->n_packets[i];
if (m->params.action[i] == MTR_POLICER_ACTION_COLOR_YELLOW)
- out->n_pkts[RTE_MTR_YELLOW] += in->n_packets[i];
+ out->n_pkts[RTE_COLOR_YELLOW] += in->n_packets[i];
if (m->params.action[i] == MTR_POLICER_ACTION_COLOR_RED)
- out->n_pkts[RTE_MTR_RED] += in->n_packets[i];
+ out->n_pkts[RTE_COLOR_RED] += in->n_packets[i];
if (m->params.action[i] == MTR_POLICER_ACTION_DROP)
out->n_pkts_dropped += in->n_packets[i];
@@ -638,15 +638,15 @@ mtr_stats_convert(struct softnic_mtr *m,
if (in->n_bytes_valid) {
uint32_t i;
- for (i = 0; i < RTE_MTR_COLORS; i++) {
+ for (i = 0; i < RTE_COLORS; i++) {
if (m->params.action[i] == MTR_POLICER_ACTION_COLOR_GREEN)
- out->n_bytes[RTE_MTR_GREEN] += in->n_bytes[i];
+ out->n_bytes[RTE_COLOR_GREEN] += in->n_bytes[i];
if (m->params.action[i] == MTR_POLICER_ACTION_COLOR_YELLOW)
- out->n_bytes[RTE_MTR_YELLOW] += in->n_bytes[i];
+ out->n_bytes[RTE_COLOR_YELLOW] += in->n_bytes[i];
if (m->params.action[i] == MTR_POLICER_ACTION_COLOR_RED)
- out->n_bytes[RTE_MTR_RED] += in->n_bytes[i];
+ out->n_bytes[RTE_COLOR_RED] += in->n_bytes[i];
if (m->params.action[i] == MTR_POLICER_ACTION_DROP)
out->n_bytes_dropped += in->n_bytes[i];
diff --git a/drivers/net/softnic/rte_eth_softnic_tm.c b/drivers/net/softnic/rte_eth_softnic_tm.c
index baaafbe29..58744a9eb 100644
--- a/drivers/net/softnic/rte_eth_softnic_tm.c
+++ b/drivers/net/softnic/rte_eth_softnic_tm.c
@@ -1204,7 +1204,7 @@ wred_profile_check(struct rte_eth_dev *dev,
struct rte_tm_error *error)
{
struct tm_wred_profile *wp;
- enum rte_tm_color color;
+ enum rte_color color;
/* WRED profile ID must not be NONE. */
if (wred_profile_id == RTE_TM_WRED_PROFILE_ID_NONE)
@@ -1240,7 +1240,7 @@ wred_profile_check(struct rte_eth_dev *dev,
rte_strerror(ENOTSUP));
/* min_th <= max_th, max_th > 0 */
- for (color = RTE_TM_GREEN; color < RTE_TM_COLORS; color++) {
+ for (color = RTE_COLOR_GREEN; color < RTE_COLORS; color++) {
uint32_t min_th = profile->red_params[color].min_th;
uint32_t max_th = profile->red_params[color].max_th;
@@ -2218,10 +2218,10 @@ wred_profiles_set(struct rte_eth_dev *dev)
struct pmd_internals *p = dev->data->dev_private;
struct rte_sched_port_params *pp = &p->soft.tm.params.port_params;
uint32_t tc_id;
- enum rte_tm_color color;
+ enum rte_color color;
for (tc_id = 0; tc_id < RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE; tc_id++)
- for (color = RTE_TM_GREEN; color < RTE_TM_COLORS; color++) {
+ for (color = RTE_COLOR_GREEN; color < RTE_COLORS; color++) {
struct rte_red_params *dst =
&pp->red_params[tc_id][color];
struct tm_wred_profile *src_wp =
@@ -3058,9 +3058,9 @@ read_port_stats(struct rte_eth_dev *dev,
s.n_pkts_tc[id] - s.n_pkts_tc_dropped[id];
nr->stats.n_bytes +=
s.n_bytes_tc[id] - s.n_bytes_tc_dropped[id];
- nr->stats.leaf.n_pkts_dropped[RTE_TM_GREEN] +=
+ nr->stats.leaf.n_pkts_dropped[RTE_COLOR_GREEN] +=
s.n_pkts_tc_dropped[id];
- nr->stats.leaf.n_bytes_dropped[RTE_TM_GREEN] +=
+ nr->stats.leaf.n_bytes_dropped[RTE_COLOR_GREEN] +=
s.n_bytes_tc_dropped[id];
}
}
@@ -3105,9 +3105,9 @@ read_subport_stats(struct rte_eth_dev *dev,
s.n_pkts_tc[tc_id] - s.n_pkts_tc_dropped[tc_id];
ns->stats.n_bytes +=
s.n_bytes_tc[tc_id] - s.n_bytes_tc_dropped[tc_id];
- ns->stats.leaf.n_pkts_dropped[RTE_TM_GREEN] +=
+ ns->stats.leaf.n_pkts_dropped[RTE_COLOR_GREEN] +=
s.n_pkts_tc_dropped[tc_id];
- ns->stats.leaf.n_bytes_dropped[RTE_TM_GREEN] +=
+ ns->stats.leaf.n_bytes_dropped[RTE_COLOR_GREEN] +=
s.n_bytes_tc_dropped[tc_id];
}
@@ -3162,8 +3162,8 @@ read_pipe_stats(struct rte_eth_dev *dev,
/* Stats accumulate */
np->stats.n_pkts += s.n_pkts - s.n_pkts_dropped;
np->stats.n_bytes += s.n_bytes - s.n_bytes_dropped;
- np->stats.leaf.n_pkts_dropped[RTE_TM_GREEN] += s.n_pkts_dropped;
- np->stats.leaf.n_bytes_dropped[RTE_TM_GREEN] +=
+ np->stats.leaf.n_pkts_dropped[RTE_COLOR_GREEN] += s.n_pkts_dropped;
+ np->stats.leaf.n_bytes_dropped[RTE_COLOR_GREEN] +=
s.n_bytes_dropped;
np->stats.leaf.n_pkts_queued = qlen;
}
@@ -3222,8 +3222,8 @@ read_tc_stats(struct rte_eth_dev *dev,
/* Stats accumulate */
nt->stats.n_pkts += s.n_pkts - s.n_pkts_dropped;
nt->stats.n_bytes += s.n_bytes - s.n_bytes_dropped;
- nt->stats.leaf.n_pkts_dropped[RTE_TM_GREEN] += s.n_pkts_dropped;
- nt->stats.leaf.n_bytes_dropped[RTE_TM_GREEN] +=
+ nt->stats.leaf.n_pkts_dropped[RTE_COLOR_GREEN] += s.n_pkts_dropped;
+ nt->stats.leaf.n_bytes_dropped[RTE_COLOR_GREEN] +=
s.n_bytes_dropped;
nt->stats.leaf.n_pkts_queued = qlen;
}
@@ -3281,8 +3281,8 @@ read_queue_stats(struct rte_eth_dev *dev,
/* Stats accumulate */
nq->stats.n_pkts += s.n_pkts - s.n_pkts_dropped;
nq->stats.n_bytes += s.n_bytes - s.n_bytes_dropped;
- nq->stats.leaf.n_pkts_dropped[RTE_TM_GREEN] += s.n_pkts_dropped;
- nq->stats.leaf.n_bytes_dropped[RTE_TM_GREEN] +=
+ nq->stats.leaf.n_pkts_dropped[RTE_COLOR_GREEN] += s.n_pkts_dropped;
+ nq->stats.leaf.n_bytes_dropped[RTE_COLOR_GREEN] +=
s.n_bytes_dropped;
nq->stats.leaf.n_pkts_queued = qlen;
diff --git a/examples/ip_pipeline/cli.c b/examples/ip_pipeline/cli.c
index a92467e63..49028efb0 100644
--- a/examples/ip_pipeline/cli.c
+++ b/examples/ip_pipeline/cli.c
@@ -3233,11 +3233,11 @@ parse_table_action_meter_tc(char **tokens,
parser_read_uint32(&mtr->meter_profile_id, tokens[1]) ||
strcmp(tokens[2], "policer") ||
strcmp(tokens[3], "g") ||
- parse_policer_action(tokens[4], &mtr->policer[e_RTE_METER_GREEN]) ||
+ parse_policer_action(tokens[4], &mtr->policer[RTE_COLOR_GREEN]) ||
strcmp(tokens[5], "y") ||
- parse_policer_action(tokens[6], &mtr->policer[e_RTE_METER_YELLOW]) ||
+ parse_policer_action(tokens[6], &mtr->policer[RTE_COLOR_YELLOW]) ||
strcmp(tokens[7], "r") ||
- parse_policer_action(tokens[8], &mtr->policer[e_RTE_METER_RED]))
+ parse_policer_action(tokens[8], &mtr->policer[RTE_COLOR_RED]))
return 0;
return 9;
@@ -4907,11 +4907,11 @@ table_rule_show(const char *pipeline_name,
struct rte_table_action_mtr_tc_params *p =
&a->mtr.mtr[i];
enum rte_table_action_policer ga =
- p->policer[e_RTE_METER_GREEN];
+ p->policer[RTE_COLOR_GREEN];
enum rte_table_action_policer ya =
- p->policer[e_RTE_METER_YELLOW];
+ p->policer[RTE_COLOR_YELLOW];
enum rte_table_action_policer ra =
- p->policer[e_RTE_METER_RED];
+ p->policer[RTE_COLOR_RED];
fprintf(f, "tc%u meter %u policer g %s y %s r %s ",
i,
@@ -5604,7 +5604,7 @@ load_dscp_table(struct rte_table_action_dscp_table *dscp_table,
for (dscp = 0, l = 1; ; l++) {
char line[64];
char *tokens[3];
- enum rte_meter_color color;
+ enum rte_color color;
uint32_t tc_id, tc_queue_id, n_tokens = RTE_DIM(tokens);
if (fgets(line, sizeof(line), f) == NULL)
@@ -5637,17 +5637,17 @@ load_dscp_table(struct rte_table_action_dscp_table *dscp_table,
switch (tokens[2][0]) {
case 'g':
case 'G':
- color = e_RTE_METER_GREEN;
+ color = RTE_COLOR_GREEN;
break;
case 'y':
case 'Y':
- color = e_RTE_METER_YELLOW;
+ color = RTE_COLOR_YELLOW;
break;
case 'r':
case 'R':
- color = e_RTE_METER_RED;
+ color = RTE_COLOR_RED;
break;
default:
diff --git a/examples/qos_meter/main.h b/examples/qos_meter/main.h
index f51eb664e..ab20151eb 100644
--- a/examples/qos_meter/main.h
+++ b/examples/qos_meter/main.h
@@ -6,13 +6,13 @@
#define _MAIN_H_
enum policer_action {
- GREEN = e_RTE_METER_GREEN,
- YELLOW = e_RTE_METER_YELLOW,
- RED = e_RTE_METER_RED,
- DROP = 3,
+ GREEN = RTE_COLOR_GREEN,
+ YELLOW = RTE_COLOR_YELLOW,
+ RED = RTE_COLOR_RED,
+ DROP = 3,
};
-enum policer_action policer_table[e_RTE_METER_COLORS][e_RTE_METER_COLORS] =
+enum policer_action policer_table[RTE_COLORS][RTE_COLORS] =
{
{ GREEN, RED, RED},
{ DROP, YELLOW, RED},
diff --git a/examples/qos_meter/rte_policer.c b/examples/qos_meter/rte_policer.c
index 58c13ec67..10d5fe8a4 100644
--- a/examples/qos_meter/rte_policer.c
+++ b/examples/qos_meter/rte_policer.c
@@ -7,7 +7,7 @@
int
rte_phb_config(struct rte_phb *phb_table, uint32_t phb_table_index,
- enum rte_meter_color pre_meter, enum rte_meter_color post_meter, enum rte_phb_action action)
+ enum rte_color pre_meter, enum rte_color post_meter, enum rte_phb_action action)
{
struct rte_phb *phb = NULL;
@@ -16,7 +16,7 @@ rte_phb_config(struct rte_phb *phb_table, uint32_t phb_table_index,
return -1;
}
- if ((pre_meter > e_RTE_METER_RED) || (post_meter > e_RTE_METER_RED) || (pre_meter > post_meter)) {
+ if ((pre_meter > RTE_COLOR_RED) || (post_meter > RTE_COLOR_RED) || (pre_meter > post_meter)) {
return -2;
}
diff --git a/examples/qos_meter/rte_policer.h b/examples/qos_meter/rte_policer.h
index 532a853dd..95efe5b85 100644
--- a/examples/qos_meter/rte_policer.h
+++ b/examples/qos_meter/rte_policer.h
@@ -9,22 +9,22 @@
#include <rte_meter.h>
enum rte_phb_action {
- e_RTE_PHB_ACTION_GREEN = e_RTE_METER_GREEN,
- e_RTE_PHB_ACTION_YELLOW = e_RTE_METER_YELLOW,
- e_RTE_PHB_ACTION_RED = e_RTE_METER_RED,
+ e_RTE_PHB_ACTION_GREEN = RTE_COLOR_GREEN,
+ e_RTE_PHB_ACTION_YELLOW = RTE_COLOR_YELLOW,
+ e_RTE_PHB_ACTION_RED = RTE_COLOR_RED,
e_RTE_PHB_ACTION_DROP = 3,
};
struct rte_phb {
- enum rte_phb_action actions[e_RTE_METER_COLORS][e_RTE_METER_COLORS];
+ enum rte_phb_action actions[RTE_COLORS][RTE_COLORS];
};
int
rte_phb_config(struct rte_phb *phb_table, uint32_t phb_table_index,
- enum rte_meter_color pre_meter, enum rte_meter_color post_meter, enum rte_phb_action action);
+ enum rte_color pre_meter, enum rte_color post_meter, enum rte_phb_action action);
static inline enum rte_phb_action
-policer_run(struct rte_phb *phb_table, uint32_t phb_table_index, enum rte_meter_color pre_meter, enum rte_meter_color post_meter)
+policer_run(struct rte_phb *phb_table, uint32_t phb_table_index, enum rte_color pre_meter, enum rte_color post_meter)
{
struct rte_phb *phb = &phb_table[phb_table_index];
enum rte_phb_action action = phb->actions[pre_meter][post_meter];
diff --git a/examples/qos_sched/app_thread.c b/examples/qos_sched/app_thread.c
index bec4deee3..e14b275e3 100644
--- a/examples/qos_sched/app_thread.c
+++ b/examples/qos_sched/app_thread.c
@@ -77,7 +77,7 @@ app_rx_thread(struct thread_conf **confs)
rx_mbufs[i],
subport, pipe,
traffic_class, queue,
- (enum rte_meter_color) color);
+ (enum rte_color) color);
}
if (unlikely(rte_ring_sp_enqueue_bulk(conf->rx_ring,
diff --git a/lib/librte_ethdev/rte_mtr.c b/lib/librte_ethdev/rte_mtr.c
index 1046cb5fd..12b815406 100644
--- a/lib/librte_ethdev/rte_mtr.c
+++ b/lib/librte_ethdev/rte_mtr.c
@@ -153,7 +153,7 @@ rte_mtr_meter_profile_update(uint16_t port_id,
int __rte_experimental
rte_mtr_meter_dscp_table_update(uint16_t port_id,
uint32_t mtr_id,
- enum rte_mtr_color *dscp_table,
+ enum rte_color *dscp_table,
struct rte_mtr_error *error)
{
struct rte_eth_dev *dev = &rte_eth_devices[port_id];
diff --git a/lib/librte_ethdev/rte_mtr.h b/lib/librte_ethdev/rte_mtr.h
index c667f87e1..e6831bc70 100644
--- a/lib/librte_ethdev/rte_mtr.h
+++ b/lib/librte_ethdev/rte_mtr.h
@@ -123,10 +123,10 @@ enum rte_mtr_stats_type {
*/
struct rte_mtr_stats {
/** Number of packets passed by the policer (per color). */
- uint64_t n_pkts[RTE_MTR_COLORS];
+ uint64_t n_pkts[RTE_COLORS];
/** Number of bytes passed by the policer (per color). */
- uint64_t n_bytes[RTE_MTR_COLORS];
+ uint64_t n_bytes[RTE_COLORS];
/** Number of packets dropped by the policer. */
uint64_t n_pkts_dropped;
@@ -258,7 +258,7 @@ struct rte_mtr_params {
* at least one yellow or red color element, then the color aware mode
* is configured.
*/
- enum rte_mtr_color *dscp_table;
+ enum rte_color *dscp_table;
/** Non-zero to enable the meter, zero to disable the meter at the time
* of MTR object creation. Ignored when the meter profile indicated by
@@ -268,7 +268,7 @@ struct rte_mtr_params {
int meter_enable;
/** Policer actions (per meter output color). */
- enum rte_mtr_policer_action action[RTE_MTR_COLORS];
+ enum rte_mtr_policer_action action[RTE_COLORS];
/** Set of stats counters to be enabled.
* @see enum rte_mtr_stats_type
@@ -634,7 +634,7 @@ rte_mtr_meter_profile_update(uint16_t port_id,
int __rte_experimental
rte_mtr_meter_dscp_table_update(uint16_t port_id,
uint32_t mtr_id,
- enum rte_mtr_color *dscp_table,
+ enum rte_color *dscp_table,
struct rte_mtr_error *error);
/**
diff --git a/lib/librte_ethdev/rte_mtr_driver.h b/lib/librte_ethdev/rte_mtr_driver.h
index c9a6d7c38..3ec7ffa2a 100644
--- a/lib/librte_ethdev/rte_mtr_driver.h
+++ b/lib/librte_ethdev/rte_mtr_driver.h
@@ -70,7 +70,7 @@ typedef int (*rte_mtr_meter_profile_update_t)(struct rte_eth_dev *dev,
typedef int (*rte_mtr_meter_dscp_table_update_t)(struct rte_eth_dev *dev,
uint32_t mtr_id,
- enum rte_mtr_color *dscp_table,
+ enum rte_color *dscp_table,
struct rte_mtr_error *error);
/**< @internal MTR object meter DSCP table update */
diff --git a/lib/librte_ethdev/rte_tm.h b/lib/librte_ethdev/rte_tm.h
index c4a788b85..980bf4419 100644
--- a/lib/librte_ethdev/rte_tm.h
+++ b/lib/librte_ethdev/rte_tm.h
@@ -177,12 +177,12 @@ struct rte_tm_node_stats {
/** Number of packets dropped by current leaf node per each
* color.
*/
- uint64_t n_pkts_dropped[RTE_TM_COLORS];
+ uint64_t n_pkts_dropped[RTE_COLORS];
/** Number of bytes dropped by current leaf node per each
* color.
*/
- uint64_t n_bytes_dropped[RTE_TM_COLORS];
+ uint64_t n_bytes_dropped[RTE_COLORS];
/** Number of packets currently waiting in the packet queue of
* current leaf node.
@@ -433,16 +433,16 @@ struct rte_tm_capabilities {
uint32_t cman_wred_context_shared_n_contexts_per_node_max;
/** Support for VLAN DEI packet marking (per color). */
- int mark_vlan_dei_supported[RTE_TM_COLORS];
+ int mark_vlan_dei_supported[RTE_COLORS];
/** Support for IPv4/IPv6 ECN marking of TCP packets (per color). */
- int mark_ip_ecn_tcp_supported[RTE_TM_COLORS];
+ int mark_ip_ecn_tcp_supported[RTE_COLORS];
/** Support for IPv4/IPv6 ECN marking of SCTP packets (per color). */
- int mark_ip_ecn_sctp_supported[RTE_TM_COLORS];
+ int mark_ip_ecn_sctp_supported[RTE_COLORS];
/** Support for IPv4/IPv6 DSCP packet marking (per color). */
- int mark_ip_dscp_supported[RTE_TM_COLORS];
+ int mark_ip_dscp_supported[RTE_COLORS];
/** Set of supported dynamic update operations.
* @see enum rte_tm_dynamic_update_type
@@ -859,7 +859,7 @@ struct rte_tm_red_params {
*/
struct rte_tm_wred_params {
/** One set of RED parameters per packet color */
- struct rte_tm_red_params red_params[RTE_TM_COLORS];
+ struct rte_tm_red_params red_params[RTE_COLORS];
/** When non-zero, the *min_th* and *max_th* thresholds are specified
* in packets (WRED packet mode). When zero, the *min_th* and *max_th*
diff --git a/lib/librte_meter/Makefile b/lib/librte_meter/Makefile
index 2dc071e8e..79ad79744 100644
--- a/lib/librte_meter/Makefile
+++ b/lib/librte_meter/Makefile
@@ -16,7 +16,7 @@ LDLIBS += -lrte_eal
EXPORT_MAP := rte_meter_version.map
-LIBABIVER := 2
+LIBABIVER := 3
#
# all source are stored in SRCS-y
diff --git a/lib/librte_meter/meson.build b/lib/librte_meter/meson.build
index 947bc19e2..422123e20 100644
--- a/lib/librte_meter/meson.build
+++ b/lib/librte_meter/meson.build
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Intel Corporation
-version = 2
+version = 3
sources = files('rte_meter.c')
headers = files('rte_meter.h')
diff --git a/lib/librte_meter/rte_meter.h b/lib/librte_meter/rte_meter.h
index 005e4eeee..3e383d2e8 100644
--- a/lib/librte_meter/rte_meter.h
+++ b/lib/librte_meter/rte_meter.h
@@ -40,13 +40,6 @@ enum rte_color {
RTE_COLORS /**< Number of colors */
};
-/* New rte_color is defined and used to deprecate rte_meter_color soon. */
-#define rte_meter_color rte_color
-#define e_RTE_METER_GREEN RTE_COLOR_GREEN
-#define e_RTE_METER_YELLOW RTE_COLOR_YELLOW
-#define e_RTE_METER_RED RTE_COLOR_RED
-#define e_RTE_METER_COLORS RTE_COLORS
-
/** srTCM parameters per metered traffic flow. The CIR, CBS and EBS parameters only
count bytes of IP packets and do not include link specific headers. At least one of
the CBS or EBS parameters has to be greater than zero. */
@@ -211,7 +204,7 @@ rte_meter_trtcm_rfc4115_config(struct rte_meter_trtcm_rfc4115 *m,
* @return
* Color assigned to the current IP packet
*/
-static inline enum rte_meter_color
+static inline enum rte_color
rte_meter_srtcm_color_blind_check(struct rte_meter_srtcm *m,
struct rte_meter_srtcm_profile *p,
uint64_t time,
@@ -233,12 +226,12 @@ rte_meter_srtcm_color_blind_check(struct rte_meter_srtcm *m,
* @return
* Color assigned to the current IP packet
*/
-static inline enum rte_meter_color
+static inline enum rte_color
rte_meter_srtcm_color_aware_check(struct rte_meter_srtcm *m,
struct rte_meter_srtcm_profile *p,
uint64_t time,
uint32_t pkt_len,
- enum rte_meter_color pkt_color);
+ enum rte_color pkt_color);
/**
* trTCM color blind traffic metering
@@ -254,7 +247,7 @@ rte_meter_srtcm_color_aware_check(struct rte_meter_srtcm *m,
* @return
* Color assigned to the current IP packet
*/
-static inline enum rte_meter_color
+static inline enum rte_color
rte_meter_trtcm_color_blind_check(struct rte_meter_trtcm *m,
struct rte_meter_trtcm_profile *p,
uint64_t time,
@@ -276,12 +269,12 @@ rte_meter_trtcm_color_blind_check(struct rte_meter_trtcm *m,
* @return
* Color assigned to the current IP packet
*/
-static inline enum rte_meter_color
+static inline enum rte_color
rte_meter_trtcm_color_aware_check(struct rte_meter_trtcm *m,
struct rte_meter_trtcm_profile *p,
uint64_t time,
uint32_t pkt_len,
- enum rte_meter_color pkt_color);
+ enum rte_color pkt_color);
/**
* @warning
@@ -300,7 +293,7 @@ rte_meter_trtcm_color_aware_check(struct rte_meter_trtcm *m,
* @return
* Color assigned to the current IP packet
*/
-static inline enum rte_meter_color __rte_experimental
+static inline enum rte_color __rte_experimental
rte_meter_trtcm_rfc4115_color_blind_check(
struct rte_meter_trtcm_rfc4115 *m,
struct rte_meter_trtcm_rfc4115_profile *p,
@@ -326,13 +319,13 @@ rte_meter_trtcm_rfc4115_color_blind_check(
* @return
* Color assigned to the current IP packet
*/
-static inline enum rte_meter_color __rte_experimental
+static inline enum rte_color __rte_experimental
rte_meter_trtcm_rfc4115_color_aware_check(
struct rte_meter_trtcm_rfc4115 *m,
struct rte_meter_trtcm_rfc4115_profile *p,
uint64_t time,
uint32_t pkt_len,
- enum rte_meter_color pkt_color);
+ enum rte_color pkt_color);
/*
* Inline implementation of run-time methods
@@ -417,7 +410,7 @@ struct rte_meter_trtcm_rfc4115 {
/**< Number of bytes currently available in the excess(E) token bucket */
};
-static inline enum rte_meter_color
+static inline enum rte_color
rte_meter_srtcm_color_blind_check(struct rte_meter_srtcm *m,
struct rte_meter_srtcm_profile *p,
uint64_t time,
@@ -444,26 +437,26 @@ rte_meter_srtcm_color_blind_check(struct rte_meter_srtcm *m,
if (tc >= pkt_len) {
m->tc = tc - pkt_len;
m->te = te;
- return e_RTE_METER_GREEN;
+ return RTE_COLOR_GREEN;
}
if (te >= pkt_len) {
m->tc = tc;
m->te = te - pkt_len;
- return e_RTE_METER_YELLOW;
+ return RTE_COLOR_YELLOW;
}
m->tc = tc;
m->te = te;
- return e_RTE_METER_RED;
+ return RTE_COLOR_RED;
}
-static inline enum rte_meter_color
+static inline enum rte_color
rte_meter_srtcm_color_aware_check(struct rte_meter_srtcm *m,
struct rte_meter_srtcm_profile *p,
uint64_t time,
uint32_t pkt_len,
- enum rte_meter_color pkt_color)
+ enum rte_color pkt_color)
{
uint64_t time_diff, n_periods, tc, te;
@@ -483,24 +476,24 @@ rte_meter_srtcm_color_aware_check(struct rte_meter_srtcm *m,
}
/* Color logic */
- if ((pkt_color == e_RTE_METER_GREEN) && (tc >= pkt_len)) {
+ if ((pkt_color == RTE_COLOR_GREEN) && (tc >= pkt_len)) {
m->tc = tc - pkt_len;
m->te = te;
- return e_RTE_METER_GREEN;
+ return RTE_COLOR_GREEN;
}
- if ((pkt_color != e_RTE_METER_RED) && (te >= pkt_len)) {
+ if ((pkt_color != RTE_COLOR_RED) && (te >= pkt_len)) {
m->tc = tc;
m->te = te - pkt_len;
- return e_RTE_METER_YELLOW;
+ return RTE_COLOR_YELLOW;
}
m->tc = tc;
m->te = te;
- return e_RTE_METER_RED;
+ return RTE_COLOR_RED;
}
-static inline enum rte_meter_color
+static inline enum rte_color
rte_meter_trtcm_color_blind_check(struct rte_meter_trtcm *m,
struct rte_meter_trtcm_profile *p,
uint64_t time,
@@ -528,26 +521,26 @@ rte_meter_trtcm_color_blind_check(struct rte_meter_trtcm *m,
if (tp < pkt_len) {
m->tc = tc;
m->tp = tp;
- return e_RTE_METER_RED;
+ return RTE_COLOR_RED;
}
if (tc < pkt_len) {
m->tc = tc;
m->tp = tp - pkt_len;
- return e_RTE_METER_YELLOW;
+ return RTE_COLOR_YELLOW;
}
m->tc = tc - pkt_len;
m->tp = tp - pkt_len;
- return e_RTE_METER_GREEN;
+ return RTE_COLOR_GREEN;
}
-static inline enum rte_meter_color
+static inline enum rte_color
rte_meter_trtcm_color_aware_check(struct rte_meter_trtcm *m,
struct rte_meter_trtcm_profile *p,
uint64_t time,
uint32_t pkt_len,
- enum rte_meter_color pkt_color)
+ enum rte_color pkt_color)
{
uint64_t time_diff_tc, time_diff_tp, n_periods_tc, n_periods_tp, tc, tp;
@@ -568,24 +561,24 @@ rte_meter_trtcm_color_aware_check(struct rte_meter_trtcm *m,
tp = p->pbs;
/* Color logic */
- if ((pkt_color == e_RTE_METER_RED) || (tp < pkt_len)) {
+ if ((pkt_color == RTE_COLOR_RED) || (tp < pkt_len)) {
m->tc = tc;
m->tp = tp;
- return e_RTE_METER_RED;
+ return RTE_COLOR_RED;
}
- if ((pkt_color == e_RTE_METER_YELLOW) || (tc < pkt_len)) {
+ if ((pkt_color == RTE_COLOR_YELLOW) || (tc < pkt_len)) {
m->tc = tc;
m->tp = tp - pkt_len;
- return e_RTE_METER_YELLOW;
+ return RTE_COLOR_YELLOW;
}
m->tc = tc - pkt_len;
m->tp = tp - pkt_len;
- return e_RTE_METER_GREEN;
+ return RTE_COLOR_GREEN;
}
-static inline enum rte_meter_color __rte_experimental
+static inline enum rte_color __rte_experimental
rte_meter_trtcm_rfc4115_color_blind_check(
struct rte_meter_trtcm_rfc4115 *m,
struct rte_meter_trtcm_rfc4115_profile *p,
@@ -614,27 +607,27 @@ rte_meter_trtcm_rfc4115_color_blind_check(
if (tc >= pkt_len) {
m->tc = tc - pkt_len;
m->te = te;
- return e_RTE_METER_GREEN;
+ return RTE_COLOR_GREEN;
}
if (te >= pkt_len) {
m->tc = tc;
m->te = te - pkt_len;
- return e_RTE_METER_YELLOW;
+ return RTE_COLOR_YELLOW;
}
/* If we end up here the color is RED */
m->tc = tc;
m->te = te;
- return e_RTE_METER_RED;
+ return RTE_COLOR_RED;
}
-static inline enum rte_meter_color __rte_experimental
+static inline enum rte_color __rte_experimental
rte_meter_trtcm_rfc4115_color_aware_check(
struct rte_meter_trtcm_rfc4115 *m,
struct rte_meter_trtcm_rfc4115_profile *p,
uint64_t time,
uint32_t pkt_len,
- enum rte_meter_color pkt_color)
+ enum rte_color pkt_color)
{
uint64_t time_diff_tc, time_diff_te, n_periods_tc, n_periods_te, tc, te;
@@ -655,22 +648,22 @@ rte_meter_trtcm_rfc4115_color_aware_check(
te = p->ebs;
/* Color logic */
- if ((pkt_color == e_RTE_METER_GREEN) && (tc >= pkt_len)) {
+ if ((pkt_color == RTE_COLOR_GREEN) && (tc >= pkt_len)) {
m->tc = tc - pkt_len;
m->te = te;
- return e_RTE_METER_GREEN;
+ return RTE_COLOR_GREEN;
}
- if ((pkt_color != e_RTE_METER_RED) && (te >= pkt_len)) {
+ if ((pkt_color != RTE_COLOR_RED) && (te >= pkt_len)) {
m->tc = tc;
m->te = te - pkt_len;
- return e_RTE_METER_YELLOW;
+ return RTE_COLOR_YELLOW;
}
/* If we end up here the color is RED */
m->tc = tc;
m->te = te;
- return e_RTE_METER_RED;
+ return RTE_COLOR_RED;
}
diff --git a/lib/librte_pipeline/rte_table_action.c b/lib/librte_pipeline/rte_table_action.c
index 8a2bb13dc..54d622f3f 100644
--- a/lib/librte_pipeline/rte_table_action.c
+++ b/lib/librte_pipeline/rte_table_action.c
@@ -109,29 +109,29 @@ mtr_cfg_check(struct rte_table_action_mtr_config *mtr)
struct mtr_trtcm_data {
struct rte_meter_trtcm trtcm;
- uint64_t stats[e_RTE_METER_COLORS];
+ uint64_t stats[RTE_COLORS];
} __attribute__((__packed__));
#define MTR_TRTCM_DATA_METER_PROFILE_ID_GET(data) \
- (((data)->stats[e_RTE_METER_GREEN] & 0xF8LLU) >> 3)
+ (((data)->stats[RTE_COLOR_GREEN] & 0xF8LLU) >> 3)
static void
mtr_trtcm_data_meter_profile_id_set(struct mtr_trtcm_data *data,
uint32_t profile_id)
{
- data->stats[e_RTE_METER_GREEN] &= ~0xF8LLU;
- data->stats[e_RTE_METER_GREEN] |= (profile_id % 32) << 3;
+ data->stats[RTE_COLOR_GREEN] &= ~0xF8LLU;
+ data->stats[RTE_COLOR_GREEN] |= (profile_id % 32) << 3;
}
#define MTR_TRTCM_DATA_POLICER_ACTION_DROP_GET(data, color)\
(((data)->stats[(color)] & 4LLU) >> 2)
#define MTR_TRTCM_DATA_POLICER_ACTION_COLOR_GET(data, color)\
- ((enum rte_meter_color)((data)->stats[(color)] & 3LLU))
+ ((enum rte_color)((data)->stats[(color)] & 3LLU))
static void
mtr_trtcm_data_policer_action_set(struct mtr_trtcm_data *data,
- enum rte_meter_color color,
+ enum rte_color color,
enum rte_table_action_policer action)
{
if (action == RTE_TABLE_ACTION_POLICER_DROP) {
@@ -144,14 +144,14 @@ mtr_trtcm_data_policer_action_set(struct mtr_trtcm_data *data,
static uint64_t
mtr_trtcm_data_stats_get(struct mtr_trtcm_data *data,
- enum rte_meter_color color)
+ enum rte_color color)
{
return data->stats[color] >> 8;
}
static void
mtr_trtcm_data_stats_reset(struct mtr_trtcm_data *data,
- enum rte_meter_color color)
+ enum rte_color color)
{
data->stats[color] &= 0xFFLU;
}
@@ -166,7 +166,7 @@ mtr_data_size(struct rte_table_action_mtr_config *mtr)
}
struct dscp_table_entry_data {
- enum rte_meter_color color;
+ enum rte_color color;
uint16_t tc;
uint16_t tc_queue;
};
@@ -287,16 +287,16 @@ mtr_apply(struct mtr_trtcm_data *data,
/* Policer actions */
mtr_trtcm_data_policer_action_set(data_tc,
- e_RTE_METER_GREEN,
- p_tc->policer[e_RTE_METER_GREEN]);
+ RTE_COLOR_GREEN,
+ p_tc->policer[RTE_COLOR_GREEN]);
mtr_trtcm_data_policer_action_set(data_tc,
- e_RTE_METER_YELLOW,
- p_tc->policer[e_RTE_METER_YELLOW]);
+ RTE_COLOR_YELLOW,
+ p_tc->policer[RTE_COLOR_YELLOW]);
mtr_trtcm_data_policer_action_set(data_tc,
- e_RTE_METER_RED,
- p_tc->policer[e_RTE_METER_RED]);
+ RTE_COLOR_RED,
+ p_tc->policer[RTE_COLOR_RED]);
}
return 0;
@@ -313,7 +313,7 @@ pkt_work_mtr(struct rte_mbuf *mbuf,
{
uint64_t drop_mask;
struct dscp_table_entry_data *dscp_entry = &dscp_table->entry[dscp];
- enum rte_meter_color color_in, color_meter, color_policer;
+ enum rte_color color_in, color_meter, color_policer;
uint32_t tc, mp_id;
tc = dscp_entry->tc;
@@ -2672,14 +2672,14 @@ rte_table_action_meter_read(struct rte_table_action *action,
if ((tc_mask & (1 << i)) == 0)
continue;
- dst->n_packets[e_RTE_METER_GREEN] =
- mtr_trtcm_data_stats_get(src, e_RTE_METER_GREEN);
+ dst->n_packets[RTE_COLOR_GREEN] =
+ mtr_trtcm_data_stats_get(src, RTE_COLOR_GREEN);
- dst->n_packets[e_RTE_METER_YELLOW] =
- mtr_trtcm_data_stats_get(src, e_RTE_METER_YELLOW);
+ dst->n_packets[RTE_COLOR_YELLOW] =
+ mtr_trtcm_data_stats_get(src, RTE_COLOR_YELLOW);
- dst->n_packets[e_RTE_METER_RED] =
- mtr_trtcm_data_stats_get(src, e_RTE_METER_RED);
+ dst->n_packets[RTE_COLOR_RED] =
+ mtr_trtcm_data_stats_get(src, RTE_COLOR_RED);
dst->n_packets_valid = 1;
dst->n_bytes_valid = 0;
@@ -2696,9 +2696,9 @@ rte_table_action_meter_read(struct rte_table_action *action,
if ((tc_mask & (1 << i)) == 0)
continue;
- mtr_trtcm_data_stats_reset(src, e_RTE_METER_GREEN);
- mtr_trtcm_data_stats_reset(src, e_RTE_METER_YELLOW);
- mtr_trtcm_data_stats_reset(src, e_RTE_METER_RED);
+ mtr_trtcm_data_stats_reset(src, RTE_COLOR_GREEN);
+ mtr_trtcm_data_stats_reset(src, RTE_COLOR_YELLOW);
+ mtr_trtcm_data_stats_reset(src, RTE_COLOR_RED);
}
diff --git a/lib/librte_pipeline/rte_table_action.h b/lib/librte_pipeline/rte_table_action.h
index c96061291..bb28dfc54 100644
--- a/lib/librte_pipeline/rte_table_action.h
+++ b/lib/librte_pipeline/rte_table_action.h
@@ -202,7 +202,7 @@ struct rte_table_action_dscp_table_entry {
/** Packet color. Used by the meter action as the packet input color
* for the color aware mode of the traffic metering algorithm.
*/
- enum rte_meter_color color;
+ enum rte_color color;
};
/** DSCP translation table. */
@@ -259,7 +259,7 @@ struct rte_table_action_mtr_tc_params {
uint32_t meter_profile_id;
/** Policer actions. */
- enum rte_table_action_policer policer[e_RTE_METER_COLORS];
+ enum rte_table_action_policer policer[RTE_COLORS];
};
/** Meter action statistics counters per traffic class. */
@@ -268,13 +268,13 @@ struct rte_table_action_mtr_counters_tc {
* and before the policer actions are executed. Only valid when
* *n_packets_valid* is non-zero.
*/
- uint64_t n_packets[e_RTE_METER_COLORS];
+ uint64_t n_packets[RTE_COLORS];
/** Number of packet bytes per color at the output of the traffic
* metering and before the policer actions are executed. Only valid when
* *n_bytes_valid* is non-zero.
*/
- uint64_t n_bytes[e_RTE_METER_COLORS];
+ uint64_t n_bytes[RTE_COLORS];
/** When non-zero, the *n_packets* field is valid. */
int n_packets_valid;
diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
index 77aed9fb2..a60ddf97e 100644
--- a/lib/librte_sched/rte_sched.c
+++ b/lib/librte_sched/rte_sched.c
@@ -177,7 +177,7 @@ struct rte_sched_port {
uint32_t n_pipe_profiles;
uint32_t pipe_tc3_rate_max;
#ifdef RTE_SCHED_RED
- struct rte_red_config red_config[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE][e_RTE_METER_COLORS];
+ struct rte_red_config red_config[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE][RTE_COLORS];
#endif
/* Timing */
@@ -642,7 +642,7 @@ rte_sched_port_config(struct rte_sched_port_params *params)
for (i = 0; i < RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE; i++) {
uint32_t j;
- for (j = 0; j < e_RTE_METER_COLORS; j++) {
+ for (j = 0; j < RTE_COLORS; j++) {
/* if min/max are both zero, then RED is disabled */
if ((params->red_params[i][j].min_th |
params->red_params[i][j].max_th) == 0) {
@@ -1015,7 +1015,7 @@ rte_sched_port_pkt_write(struct rte_sched_port *port,
struct rte_mbuf *pkt,
uint32_t subport, uint32_t pipe,
uint32_t traffic_class,
- uint32_t queue, enum rte_meter_color color)
+ uint32_t queue, enum rte_color color)
{
uint32_t queue_id = rte_sched_port_qindex(port, subport, pipe,
traffic_class, queue);
@@ -1037,10 +1037,10 @@ rte_sched_port_pkt_read_tree_path(struct rte_sched_port *port,
*queue = queue_id & (RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS - 1);
}
-enum rte_meter_color
+enum rte_color
rte_sched_port_pkt_read_color(const struct rte_mbuf *pkt)
{
- return (enum rte_meter_color)rte_mbuf_sched_color_get(pkt);
+ return (enum rte_color)rte_mbuf_sched_color_get(pkt);
}
int
@@ -1188,7 +1188,7 @@ rte_sched_port_red_drop(struct rte_sched_port *port, struct rte_mbuf *pkt, uint3
struct rte_red_config *red_cfg;
struct rte_red *red;
uint32_t tc_index;
- enum rte_meter_color color;
+ enum rte_color color;
tc_index = (qindex >> 2) & 0x3;
color = rte_sched_port_pkt_read_color(pkt);
diff --git a/lib/librte_sched/rte_sched.h b/lib/librte_sched/rte_sched.h
index 243efa1d4..904d09d88 100644
--- a/lib/librte_sched/rte_sched.h
+++ b/lib/librte_sched/rte_sched.h
@@ -205,7 +205,7 @@ struct rte_sched_port_params {
* Every pipe is configured using one of the profiles from this table. */
uint32_t n_pipe_profiles; /**< Profiles in the pipe profile table */
#ifdef RTE_SCHED_RED
- struct rte_red_params red_params[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE][e_RTE_METER_COLORS]; /**< RED parameters */
+ struct rte_red_params red_params[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE][RTE_COLORS]; /**< RED parameters */
#endif
};
@@ -374,7 +374,7 @@ void
rte_sched_port_pkt_write(struct rte_sched_port *port,
struct rte_mbuf *pkt,
uint32_t subport, uint32_t pipe, uint32_t traffic_class,
- uint32_t queue, enum rte_meter_color color);
+ uint32_t queue, enum rte_color color);
/**
* Scheduler hierarchy path read from packet descriptor (struct
@@ -402,7 +402,7 @@ rte_sched_port_pkt_read_tree_path(struct rte_sched_port *port,
uint32_t *subport, uint32_t *pipe,
uint32_t *traffic_class, uint32_t *queue);
-enum rte_meter_color
+enum rte_color
rte_sched_port_pkt_read_color(const struct rte_mbuf *pkt);
/**
--
2.17.1
^ permalink raw reply [relevance 1%]
* [dpdk-dev] [PATCH v4] service: fix parameter type
` (2 preceding siblings ...)
2019-02-15 10:29 4% ` [dpdk-dev] [PATCH v3] " Nikhil Rao
@ 2019-03-28 6:29 4% ` Nikhil Rao
2019-03-28 6:29 4% ` Nikhil Rao
3 siblings, 1 reply; 200+ results
From: Nikhil Rao @ 2019-03-28 6:29 UTC (permalink / raw)
To: harry.van.haaren; +Cc: ferruh.yigit, dev, thomas, Nikhil Rao
The type of value parameter to rte_service_attr_get
should be uint64_t *, since the attributes
are of type uint64_t.
Fixes: 4d55194d76a4 ("service: add attribute get function")
Reviewed-by: Gage Eads <gage.eads@intel.com>
Signed-off-by: Nikhil Rao <nikhil.rao@intel.com>
Acked-by: Harry van Haaren <harry.van.haaren@intel.com>
Reviewed-by: Rami Rosen <ramirose@gmail.com>
---
lib/librte_eal/common/include/rte_service.h | 2 +-
app/test/test_service_cores.c | 2 +-
lib/librte_eal/common/rte_service.c | 2 +-
doc/guides/rel_notes/deprecation.rst | 4 ----
doc/guides/rel_notes/release_19_05.rst | 5 ++++-
lib/librte_eal/bsdapp/eal/Makefile | 2 +-
lib/librte_eal/linuxapp/eal/Makefile | 2 +-
lib/librte_eal/meson.build | 2 +-
8 files changed, 10 insertions(+), 11 deletions(-)
v2:
* Update release notes.
* Update library version in makefiles.
v3:
* Remove deprecation notice.
v4:
* Update path for test_service_cores.c.
* Fix whitespace in release_19_05.rst.
diff --git a/lib/librte_eal/common/include/rte_service.h b/lib/librte_eal/common/include/rte_service.h
index 34b41af..670c89a 100644
--- a/lib/librte_eal/common/include/rte_service.h
+++ b/lib/librte_eal/common/include/rte_service.h
@@ -372,7 +372,7 @@ int32_t rte_service_run_iter_on_app_lcore(uint32_t id,
* -EINVAL Invalid id, attr_id or attr_value was NULL.
*/
int32_t rte_service_attr_get(uint32_t id, uint32_t attr_id,
- uint32_t *attr_value);
+ uint64_t *attr_value);
/**
* Reset all attribute values of a service.
diff --git a/app/test/test_service_cores.c b/app/test/test_service_cores.c
index ec31882..82bb2ce 100644
--- a/app/test/test_service_cores.c
+++ b/app/test/test_service_cores.c
@@ -259,7 +259,7 @@ static int32_t dummy_mt_safe_cb(void *args)
rte_service_set_stats_enable(id, 1);
uint32_t attr_id = UINT32_MAX;
- uint32_t attr_value = 0xdead;
+ uint64_t attr_value = 0xdead;
/* check error return values */
TEST_ASSERT_EQUAL(-EINVAL, rte_service_attr_get(id, attr_id,
&attr_value),
diff --git a/lib/librte_eal/common/rte_service.c b/lib/librte_eal/common/rte_service.c
index 03fde97..5f75e5a 100644
--- a/lib/librte_eal/common/rte_service.c
+++ b/lib/librte_eal/common/rte_service.c
@@ -734,7 +734,7 @@ int32_t rte_service_run_iter_on_app_lcore(uint32_t id,
}
int32_t
-rte_service_attr_get(uint32_t id, uint32_t attr_id, uint32_t *attr_value)
+rte_service_attr_get(uint32_t id, uint32_t attr_id, uint64_t *attr_value)
{
struct rte_service_spec_impl *s;
SERVICE_VALID_GET_OR_ERR_RET(id, s, -EINVAL);
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 1b4fcb7..93ed31f 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -20,10 +20,6 @@ Deprecation Notices
* kvargs: The function ``rte_kvargs_process`` will get a new parameter
for returning key match count. It will ease handling of no-match case.
-* eal: The ``attr_value`` parameter of ``rte_service_attr_get()``
- will be changed from ``uint32_t *`` to ``uint64_t *``
- as the attributes are of type ``uint64_t``.
-
* eal: both declaring and identifying devices will be streamlined in v18.11.
New functions will appear to query a specific port from buses, classes of
device and device drivers. Device declaration will be made coherent with the
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 4a3e2a7..67e221a 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -106,6 +106,9 @@ API Changes
Also, make sure to start the actual text at the margin.
=========================================================
+eal: as shown in the 19.02 deprecation notice, the type of the ``attr_value``
+ parameter of the function ``rte_service_attr_get()`` has been changed
+ from ``uint32_t *`` to ``uint64_t *``.
ABI Changes
-----------
@@ -155,7 +158,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_compressdev.so.1
librte_cryptodev.so.6
librte_distributor.so.1
- librte_eal.so.9
+ + librte_eal.so.10
librte_efd.so.1
librte_ethdev.so.11
librte_eventdev.so.6
diff --git a/lib/librte_eal/bsdapp/eal/Makefile b/lib/librte_eal/bsdapp/eal/Makefile
index bfeddaa..4bc8555 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -22,7 +22,7 @@ LDLIBS += -lrte_kvargs
EXPORT_MAP := ../../rte_eal_version.map
-LIBABIVER := 9
+LIBABIVER := 10
# specific to bsdapp exec-env
SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) := eal.c
diff --git a/lib/librte_eal/linuxapp/eal/Makefile b/lib/librte_eal/linuxapp/eal/Makefile
index 51deb57..db6aca3 100644
--- a/lib/librte_eal/linuxapp/eal/Makefile
+++ b/lib/librte_eal/linuxapp/eal/Makefile
@@ -10,7 +10,7 @@ ARCH_DIR ?= $(RTE_ARCH)
EXPORT_MAP := ../../rte_eal_version.map
VPATH += $(RTE_SDK)/lib/librte_eal/common/arch/$(ARCH_DIR)
-LIBABIVER := 9
+LIBABIVER := 10
VPATH += $(RTE_SDK)/lib/librte_eal/common
diff --git a/lib/librte_eal/meson.build b/lib/librte_eal/meson.build
index 98c1d1f..290239d 100644
--- a/lib/librte_eal/meson.build
+++ b/lib/librte_eal/meson.build
@@ -21,7 +21,7 @@ else
error('unsupported system type "@0@"'.format(host_machine.system()))
endif
-version = 9 # the version of the EAL API
+version = 10 # the version of the EAL API
allow_experimental_apis = true
deps += 'kvargs'
if dpdk_conf.has('RTE_USE_LIBBSD')
--
1.8.3.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v4] service: fix parameter type
2019-03-28 6:29 4% ` [dpdk-dev] [PATCH v4] " Nikhil Rao
@ 2019-03-28 6:29 4% ` Nikhil Rao
0 siblings, 0 replies; 200+ results
From: Nikhil Rao @ 2019-03-28 6:29 UTC (permalink / raw)
To: harry.van.haaren; +Cc: ferruh.yigit, dev, thomas, Nikhil Rao
The type of value parameter to rte_service_attr_get
should be uint64_t *, since the attributes
are of type uint64_t.
Fixes: 4d55194d76a4 ("service: add attribute get function")
Reviewed-by: Gage Eads <gage.eads@intel.com>
Signed-off-by: Nikhil Rao <nikhil.rao@intel.com>
Acked-by: Harry van Haaren <harry.van.haaren@intel.com>
Reviewed-by: Rami Rosen <ramirose@gmail.com>
---
lib/librte_eal/common/include/rte_service.h | 2 +-
app/test/test_service_cores.c | 2 +-
lib/librte_eal/common/rte_service.c | 2 +-
doc/guides/rel_notes/deprecation.rst | 4 ----
doc/guides/rel_notes/release_19_05.rst | 5 ++++-
lib/librte_eal/bsdapp/eal/Makefile | 2 +-
lib/librte_eal/linuxapp/eal/Makefile | 2 +-
lib/librte_eal/meson.build | 2 +-
8 files changed, 10 insertions(+), 11 deletions(-)
v2:
* Update release notes.
* Update library version in makefiles.
v3:
* Remove deprecation notice.
v4:
* Update path for test_service_cores.c.
* Fix whitespace in release_19_05.rst.
diff --git a/lib/librte_eal/common/include/rte_service.h b/lib/librte_eal/common/include/rte_service.h
index 34b41af..670c89a 100644
--- a/lib/librte_eal/common/include/rte_service.h
+++ b/lib/librte_eal/common/include/rte_service.h
@@ -372,7 +372,7 @@ int32_t rte_service_run_iter_on_app_lcore(uint32_t id,
* -EINVAL Invalid id, attr_id or attr_value was NULL.
*/
int32_t rte_service_attr_get(uint32_t id, uint32_t attr_id,
- uint32_t *attr_value);
+ uint64_t *attr_value);
/**
* Reset all attribute values of a service.
diff --git a/app/test/test_service_cores.c b/app/test/test_service_cores.c
index ec31882..82bb2ce 100644
--- a/app/test/test_service_cores.c
+++ b/app/test/test_service_cores.c
@@ -259,7 +259,7 @@ static int32_t dummy_mt_safe_cb(void *args)
rte_service_set_stats_enable(id, 1);
uint32_t attr_id = UINT32_MAX;
- uint32_t attr_value = 0xdead;
+ uint64_t attr_value = 0xdead;
/* check error return values */
TEST_ASSERT_EQUAL(-EINVAL, rte_service_attr_get(id, attr_id,
&attr_value),
diff --git a/lib/librte_eal/common/rte_service.c b/lib/librte_eal/common/rte_service.c
index 03fde97..5f75e5a 100644
--- a/lib/librte_eal/common/rte_service.c
+++ b/lib/librte_eal/common/rte_service.c
@@ -734,7 +734,7 @@ int32_t rte_service_run_iter_on_app_lcore(uint32_t id,
}
int32_t
-rte_service_attr_get(uint32_t id, uint32_t attr_id, uint32_t *attr_value)
+rte_service_attr_get(uint32_t id, uint32_t attr_id, uint64_t *attr_value)
{
struct rte_service_spec_impl *s;
SERVICE_VALID_GET_OR_ERR_RET(id, s, -EINVAL);
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 1b4fcb7..93ed31f 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -20,10 +20,6 @@ Deprecation Notices
* kvargs: The function ``rte_kvargs_process`` will get a new parameter
for returning key match count. It will ease handling of no-match case.
-* eal: The ``attr_value`` parameter of ``rte_service_attr_get()``
- will be changed from ``uint32_t *`` to ``uint64_t *``
- as the attributes are of type ``uint64_t``.
-
* eal: both declaring and identifying devices will be streamlined in v18.11.
New functions will appear to query a specific port from buses, classes of
device and device drivers. Device declaration will be made coherent with the
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index 4a3e2a7..67e221a 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -106,6 +106,9 @@ API Changes
Also, make sure to start the actual text at the margin.
=========================================================
+eal: as shown in the 19.02 deprecation notice, the type of the ``attr_value``
+ parameter of the function ``rte_service_attr_get()`` has been changed
+ from ``uint32_t *`` to ``uint64_t *``.
ABI Changes
-----------
@@ -155,7 +158,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_compressdev.so.1
librte_cryptodev.so.6
librte_distributor.so.1
- librte_eal.so.9
+ + librte_eal.so.10
librte_efd.so.1
librte_ethdev.so.11
librte_eventdev.so.6
diff --git a/lib/librte_eal/bsdapp/eal/Makefile b/lib/librte_eal/bsdapp/eal/Makefile
index bfeddaa..4bc8555 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -22,7 +22,7 @@ LDLIBS += -lrte_kvargs
EXPORT_MAP := ../../rte_eal_version.map
-LIBABIVER := 9
+LIBABIVER := 10
# specific to bsdapp exec-env
SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) := eal.c
diff --git a/lib/librte_eal/linuxapp/eal/Makefile b/lib/librte_eal/linuxapp/eal/Makefile
index 51deb57..db6aca3 100644
--- a/lib/librte_eal/linuxapp/eal/Makefile
+++ b/lib/librte_eal/linuxapp/eal/Makefile
@@ -10,7 +10,7 @@ ARCH_DIR ?= $(RTE_ARCH)
EXPORT_MAP := ../../rte_eal_version.map
VPATH += $(RTE_SDK)/lib/librte_eal/common/arch/$(ARCH_DIR)
-LIBABIVER := 9
+LIBABIVER := 10
VPATH += $(RTE_SDK)/lib/librte_eal/common
diff --git a/lib/librte_eal/meson.build b/lib/librte_eal/meson.build
index 98c1d1f..290239d 100644
--- a/lib/librte_eal/meson.build
+++ b/lib/librte_eal/meson.build
@@ -21,7 +21,7 @@ else
error('unsupported system type "@0@"'.format(host_machine.system()))
endif
-version = 9 # the version of the EAL API
+version = 10 # the version of the EAL API
allow_experimental_apis = true
deps += 'kvargs'
if dpdk_conf.has('RTE_USE_LIBBSD')
--
1.8.3.1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v7 1/2] ring: add reset API to flush the ring when not in use
@ 2019-03-29 14:17 3% ` Olivier Matz
2019-03-29 14:17 3% ` Olivier Matz
0 siblings, 1 reply; 200+ results
From: Olivier Matz @ 2019-03-29 14:17 UTC (permalink / raw)
To: Gavin Hu
Cc: dev, nd, thomas, jerinj, hemant.agrawal, nipun.gupta,
Honnappa.Nagarahalli, i.maximets, stable
Hi,
On Fri, Mar 15, 2019 at 11:31:25AM +0800, Gavin Hu wrote:
> Currently, the flush is done by dequeuing the ring in a while loop. It is
> much simpler to flush the queue by resetting the head and tail indices.
>
> Fixes: af75078fece3 ("first public release")
> Cc: stable@dpdk.org
>
> Signed-off-by: Gavin Hu <gavin.hu@arm.com>
> Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
> Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> ---
> lib/librte_ring/rte_ring.h | 20 ++++++++++++++++++++
> lib/librte_ring/rte_ring_version.map | 7 +++++++
> 2 files changed, 27 insertions(+)
>
> diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
> index af5444a..2830300 100644
> --- a/lib/librte_ring/rte_ring.h
> +++ b/lib/librte_ring/rte_ring.h
> @@ -671,6 +671,26 @@ rte_ring_dequeue(struct rte_ring *r, void **obj_p)
> }
>
> /**
> + * Flush a ring.
> + *
> + * This function flush all the elements in a ring
> + *
> + * @b EXPERIMENTAL: this API may change without prior notice
> + *
> + * @warning
> + * Make sure the ring is not in use while calling this function.
> + *
> + * @param r
> + * A pointer to the ring structure.
> + */
> +static inline void __rte_experimental
> +rte_ring_reset(struct rte_ring *r)
> +{
> + r->prod.head = r->cons.head = 0;
> + r->prod.tail = r->cons.tail = 0;
> +}
> +
> +/**
> * Return the number of entries in a ring.
> *
> * @param r
> diff --git a/lib/librte_ring/rte_ring_version.map b/lib/librte_ring/rte_ring_version.map
> index d935efd..581d9ca 100644
> --- a/lib/librte_ring/rte_ring_version.map
> +++ b/lib/librte_ring/rte_ring_version.map
> @@ -17,3 +17,10 @@ DPDK_2.2 {
> rte_ring_free;
>
> } DPDK_2.0;
> +
> +EXPERIMENTAL {
> + global:
> +
> + rte_ring_reset;
> +
> +};
> --
> 2.7.4
>
To me, a static inline function does not need to be added in
rte_ring_version.map (or is it due to a check script checking the
__rte_experimental tag ?). I found at least one commit where it
is not the case:
c277b34c1b3b ("mbuf: add function returning buffer address")
There are 2 options:
1- remove the rte_ring_version.map part of the patch.
2- change the static inline function into a standard function.
I would prefer 2-, because it allows to keep an api/abi compat
layer in the future.
Regards
Olivier
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v7 1/2] ring: add reset API to flush the ring when not in use
2019-03-29 14:17 3% ` Olivier Matz
@ 2019-03-29 14:17 3% ` Olivier Matz
0 siblings, 0 replies; 200+ results
From: Olivier Matz @ 2019-03-29 14:17 UTC (permalink / raw)
To: Gavin Hu
Cc: dev, nd, thomas, jerinj, hemant.agrawal, nipun.gupta,
Honnappa.Nagarahalli, i.maximets, stable
Hi,
On Fri, Mar 15, 2019 at 11:31:25AM +0800, Gavin Hu wrote:
> Currently, the flush is done by dequeuing the ring in a while loop. It is
> much simpler to flush the queue by resetting the head and tail indices.
>
> Fixes: af75078fece3 ("first public release")
> Cc: stable@dpdk.org
>
> Signed-off-by: Gavin Hu <gavin.hu@arm.com>
> Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
> Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> ---
> lib/librte_ring/rte_ring.h | 20 ++++++++++++++++++++
> lib/librte_ring/rte_ring_version.map | 7 +++++++
> 2 files changed, 27 insertions(+)
>
> diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
> index af5444a..2830300 100644
> --- a/lib/librte_ring/rte_ring.h
> +++ b/lib/librte_ring/rte_ring.h
> @@ -671,6 +671,26 @@ rte_ring_dequeue(struct rte_ring *r, void **obj_p)
> }
>
> /**
> + * Flush a ring.
> + *
> + * This function flush all the elements in a ring
> + *
> + * @b EXPERIMENTAL: this API may change without prior notice
> + *
> + * @warning
> + * Make sure the ring is not in use while calling this function.
> + *
> + * @param r
> + * A pointer to the ring structure.
> + */
> +static inline void __rte_experimental
> +rte_ring_reset(struct rte_ring *r)
> +{
> + r->prod.head = r->cons.head = 0;
> + r->prod.tail = r->cons.tail = 0;
> +}
> +
> +/**
> * Return the number of entries in a ring.
> *
> * @param r
> diff --git a/lib/librte_ring/rte_ring_version.map b/lib/librte_ring/rte_ring_version.map
> index d935efd..581d9ca 100644
> --- a/lib/librte_ring/rte_ring_version.map
> +++ b/lib/librte_ring/rte_ring_version.map
> @@ -17,3 +17,10 @@ DPDK_2.2 {
> rte_ring_free;
>
> } DPDK_2.0;
> +
> +EXPERIMENTAL {
> + global:
> +
> + rte_ring_reset;
> +
> +};
> --
> 2.7.4
>
To me, a static inline function does not need to be added in
rte_ring_version.map (or is it due to a check script checking the
__rte_experimental tag ?). I found at least one commit where it
is not the case:
c277b34c1b3b ("mbuf: add function returning buffer address")
There are 2 options:
1- remove the rte_ring_version.map part of the patch.
2- change the static inline function into a standard function.
I would prefer 2-, because it allows to keep an api/abi compat
layer in the future.
Regards
Olivier
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2] doc: announce ABI change for cryptodev config
2019-03-07 15:25 4% ` Trahe, Fiona
@ 2019-03-29 14:23 4% ` Akhil Goyal
2019-03-29 14:23 4% ` Akhil Goyal
0 siblings, 1 reply; 200+ results
From: Akhil Goyal @ 2019-03-29 14:23 UTC (permalink / raw)
To: Trahe, Fiona, Anoob Joseph, De Lara Guarch, Pablo
Cc: Jerin Jacob Kollanukkaran, Narayana Prasad Raju Athreya,
Shally Verma, Suheil Chandran, dev
On 3/7/2019 8:55 PM, Trahe, Fiona wrote:
>
>> -----Original Message-----
>> From: Anoob Joseph [mailto:anoobj@marvell.com]
>> Sent: Thursday, March 7, 2019 10:40 AM
>> To: Akhil Goyal <akhil.goyal@nxp.com>; Trahe, Fiona <fiona.trahe@intel.com>; De Lara Guarch, Pablo
>> <pablo.de.lara.guarch@intel.com>
>> Cc: Anoob Joseph <anoobj@marvell.com>; Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana
>> Prasad Raju Athreya <pathreya@marvell.com>; Shally Verma <shallyv@marvell.com>; Suheil Chandran
>> <schandran@marvell.com>; dev@dpdk.org
>> Subject: [PATCH v2] doc: announce ABI change for cryptodev config
>>
>> Add new field ff_disable in rte_cryptodev_config. This enables
>> applications to control the features enabled on the crypto device.
>>
>> Proposed new layout:
>>
>> /** Crypto device configuration structure */
>> struct rte_cryptodev_config {
>> int socket_id; /**< Socket to allocate resources on */
>> uint16_t nb_queue_pairs;
>> /**< Number of queue pairs to configure on device */
>> + uint64_t ff_disable;
>> + /**< Feature flags to be disabled. Only the following features are
>> + * allowed to be disabled,
>> + * - RTE_CRYPTODEV_FF_SYMMETRIC_CRYPTO
>> + * - RTE_CRYPTODEV_FF_ASYMMETRIC_CRYPTO
>> + * - RTE_CRYTPODEV_FF_SECURITY
>> + */
>> };
>>
>> For eth devices, rte_eth_conf.rx_mode.offloads and
>> rte_eth_conf.tx_mode.offloads fields are used by applications to
>> control the offloads enabled on the eth device. This proposal adds a
>> similar ability for the crypto device.
>>
>> Signed-off-by: Anoob Joseph <anoobj@marvell.com>
> Acked-by: Fiona Trahe <fiona.trahe@intel.com>
>
Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
Applied to dpdk-next-crypto
Thanks.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v2] doc: announce ABI change for cryptodev config
2019-03-29 14:23 4% ` Akhil Goyal
@ 2019-03-29 14:23 4% ` Akhil Goyal
0 siblings, 0 replies; 200+ results
From: Akhil Goyal @ 2019-03-29 14:23 UTC (permalink / raw)
To: Trahe, Fiona, Anoob Joseph, De Lara Guarch, Pablo
Cc: Jerin Jacob Kollanukkaran, Narayana Prasad Raju Athreya,
Shally Verma, Suheil Chandran, dev
On 3/7/2019 8:55 PM, Trahe, Fiona wrote:
>
>> -----Original Message-----
>> From: Anoob Joseph [mailto:anoobj@marvell.com]
>> Sent: Thursday, March 7, 2019 10:40 AM
>> To: Akhil Goyal <akhil.goyal@nxp.com>; Trahe, Fiona <fiona.trahe@intel.com>; De Lara Guarch, Pablo
>> <pablo.de.lara.guarch@intel.com>
>> Cc: Anoob Joseph <anoobj@marvell.com>; Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Narayana
>> Prasad Raju Athreya <pathreya@marvell.com>; Shally Verma <shallyv@marvell.com>; Suheil Chandran
>> <schandran@marvell.com>; dev@dpdk.org
>> Subject: [PATCH v2] doc: announce ABI change for cryptodev config
>>
>> Add new field ff_disable in rte_cryptodev_config. This enables
>> applications to control the features enabled on the crypto device.
>>
>> Proposed new layout:
>>
>> /** Crypto device configuration structure */
>> struct rte_cryptodev_config {
>> int socket_id; /**< Socket to allocate resources on */
>> uint16_t nb_queue_pairs;
>> /**< Number of queue pairs to configure on device */
>> + uint64_t ff_disable;
>> + /**< Feature flags to be disabled. Only the following features are
>> + * allowed to be disabled,
>> + * - RTE_CRYPTODEV_FF_SYMMETRIC_CRYPTO
>> + * - RTE_CRYPTODEV_FF_ASYMMETRIC_CRYPTO
>> + * - RTE_CRYTPODEV_FF_SECURITY
>> + */
>> };
>>
>> For eth devices, rte_eth_conf.rx_mode.offloads and
>> rte_eth_conf.tx_mode.offloads fields are used by applications to
>> control the offloads enabled on the eth device. This proposal adds a
>> similar ability for the crypto device.
>>
>> Signed-off-by: Anoob Joseph <anoobj@marvell.com>
> Acked-by: Fiona Trahe <fiona.trahe@intel.com>
>
Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
Applied to dpdk-next-crypto
Thanks.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v3] crypto/aesni_mb: support newer version library only
2019-03-26 15:43 0% ` Akhil Goyal
2019-03-26 15:43 0% ` Akhil Goyal
@ 2019-03-29 14:38 0% ` Akhil Goyal
2019-03-29 14:38 0% ` Akhil Goyal
1 sibling, 1 reply; 200+ results
From: Akhil Goyal @ 2019-03-29 14:38 UTC (permalink / raw)
To: Zhang, Roy Fan, dev; +Cc: De Lara Guarch, Pablo, Yigit, Ferruh
On 3/26/2019 9:13 PM, Akhil Goyal wrote:
>
> On 3/26/2019 9:05 PM, Zhang, Roy Fan wrote:
>> Hi Akhil,
>>
>> I have discussed with Ferruh in relation to the updating release note
>> for this change.
>> However the change seems not apply to any section under the release note.
>>
>> The change does not introduce new feature, nor breaks ABI/API -
>> it only changes the requirement of the dependent external library version,
>> and makefile/meson will pop up error when the library version is too old and
>> prevents compiling.
>>
>> Regards,
>> Fan
> ok. I will pick the patch.
>>> -----Original Message-----
>>> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
>>> Sent: Tuesday, March 26, 2019 9:11 AM
>>> To: Zhang, Roy Fan <roy.fan.zhang@intel.com>; dev@dpdk.org
>>> Cc: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
>>> Subject: Re: [dpdk-dev] [PATCH v3] crypto/aesni_mb: support newer version
>>> library only
>>> I think this deserve to be updated in the release note as well.
>>>
Applied to dpdk-next-crypto
Thanks.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3] crypto/aesni_mb: support newer version library only
2019-03-29 14:38 0% ` Akhil Goyal
@ 2019-03-29 14:38 0% ` Akhil Goyal
0 siblings, 0 replies; 200+ results
From: Akhil Goyal @ 2019-03-29 14:38 UTC (permalink / raw)
To: Zhang, Roy Fan, dev; +Cc: De Lara Guarch, Pablo, Yigit, Ferruh
On 3/26/2019 9:13 PM, Akhil Goyal wrote:
>
> On 3/26/2019 9:05 PM, Zhang, Roy Fan wrote:
>> Hi Akhil,
>>
>> I have discussed with Ferruh in relation to the updating release note
>> for this change.
>> However the change seems not apply to any section under the release note.
>>
>> The change does not introduce new feature, nor breaks ABI/API -
>> it only changes the requirement of the dependent external library version,
>> and makefile/meson will pop up error when the library version is too old and
>> prevents compiling.
>>
>> Regards,
>> Fan
> ok. I will pick the patch.
>>> -----Original Message-----
>>> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
>>> Sent: Tuesday, March 26, 2019 9:11 AM
>>> To: Zhang, Roy Fan <roy.fan.zhang@intel.com>; dev@dpdk.org
>>> Cc: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
>>> Subject: Re: [dpdk-dev] [PATCH v3] crypto/aesni_mb: support newer version
>>> library only
>>> I think this deserve to be updated in the release note as well.
>>>
Applied to dpdk-next-crypto
Thanks.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v3 1/7] ethdev: add min/max MTU to device info
2019-03-22 13:01 12% ` [dpdk-dev] [PATCH v2 1/7] " Ian Stokes
@ 2019-03-29 17:52 11% ` Ferruh Yigit
2019-03-29 17:52 11% ` Ferruh Yigit
2019-03-29 17:56 0% ` Ferruh Yigit
1 sibling, 2 replies; 200+ results
From: Ferruh Yigit @ 2019-03-29 17:52 UTC (permalink / raw)
To: Neil Horman, John McNamara, Marko Kovacevic, Thomas Monjalon,
Andrew Rybchenko
Cc: dev, Stephen Hemminger, Ian Stokes
From: Stephen Hemminger <stephen@networkplumber.org>
This addresses the usability issue raised by OVS at DPDK Userspace
summit. It adds general min/max mtu into device info. For compatiablity,
and to save space, it fits in a hole in existing structure.
The initial version sets max mtu to normal Ethernet, it is up to
PMD to set larger value if it supports Jumbo frames.
Also remove the deprecation notice introduced in 18.11 regarding this
change and bump ethdev ABI version.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Ian Stokes <ian.stokes@intel.com>
Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 12 ----------
doc/guides/rel_notes/release_19_05.rst | 9 ++++++-
lib/librte_ethdev/Makefile | 2 +-
lib/librte_ethdev/meson.build | 2 +-
lib/librte_ethdev/rte_ethdev.c | 15 ++++++++++++
lib/librte_ethdev/rte_ethdev.h | 33 +++++++++++++++++++++++++-
6 files changed, 57 insertions(+), 16 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 73bfa9d4a..6f55c4740 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -52,18 +52,6 @@ Deprecation Notices
Target release for removal of the legacy API will be defined once most
PMDs have switched to rte_flow.
-* ethdev: Maximum and minimum MTU values vary between hardware devices. In
- hardware agnostic DPDK applications access to such information would allow
- a more accurate way of validating and setting supported MTU values on a per
- device basis rather than using a defined default for all devices. To
- resolve this, the following members will be added to ``rte_eth_dev_info``.
- Note: these can be added to fit a hole in the existing structure for amd64
- but not for 32-bit, as such ABI change will occur as size of the structure
- will increase.
-
- - Member ``uint16_t min_mtu`` the minimum MTU allowed.
- - Member ``uint16_t max_mtu`` the maximum MTU allowed.
-
* kni: remove KNI ethtool support. To clarify, this is not to remove the KNI,
but only to remove ethtool support of it that is disabled by default and
can be enabled via ``CONFIG_RTE_KNI_KMOD_ETHTOOL`` config option.
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index cddd800e4..8d2d8a7e9 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -164,6 +164,13 @@ ABI Changes
Also, make sure to start the actual text at the margin.
=========================================================
+* ethdev: Additional fields in rte_eth_dev_info.
+
+ The ``rte_eth_dev_info`` structure has had two extra fields
+ added: ``min_mtu`` and ``max_mtu``. Each of these are of type ``uint16_t``.
+ The values of these fields can be set specifically by the PMD drivers as
+ supported values can vary from device to device.
+
* cryptodev: in 18.08 new structure ``rte_crypto_asym_op`` was introduced and
included into ``rte_crypto_op``. As ``rte_crypto_asym_op`` structure was
defined as cache-line aligned that caused unintended changes in
@@ -206,7 +213,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_distributor.so.1
+ librte_eal.so.10
librte_efd.so.1
- librte_ethdev.so.11
+ + librte_ethdev.so.12
librte_eventdev.so.6
librte_flow_classify.so.1
librte_gro.so.1
diff --git a/lib/librte_ethdev/Makefile b/lib/librte_ethdev/Makefile
index e09c4263a..8d4a02630 100644
--- a/lib/librte_ethdev/Makefile
+++ b/lib/librte_ethdev/Makefile
@@ -16,7 +16,7 @@ LDLIBS += -lrte_mbuf -lrte_kvargs -lrte_cmdline -lrte_meter
EXPORT_MAP := rte_ethdev_version.map
-LIBABIVER := 11
+LIBABIVER := 12
SRCS-y += ethdev_private.c
SRCS-y += rte_ethdev.c
diff --git a/lib/librte_ethdev/meson.build b/lib/librte_ethdev/meson.build
index e98942ff8..8d6165b2a 100644
--- a/lib/librte_ethdev/meson.build
+++ b/lib/librte_ethdev/meson.build
@@ -2,7 +2,7 @@
# Copyright(c) 2017 Intel Corporation
name = 'ethdev'
-version = 11
+version = 12
allow_experimental_apis = true
sources = files('ethdev_private.c',
'ethdev_profile.c',
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 12b66b68c..10bdfb37e 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -2532,6 +2532,8 @@ rte_eth_dev_info_get(uint16_t port_id, struct rte_eth_dev_info *dev_info)
dev_info->rx_desc_lim = lim;
dev_info->tx_desc_lim = lim;
dev_info->device = dev->device;
+ dev_info->min_mtu = ETHER_MIN_MTU;
+ dev_info->max_mtu = UINT16_MAX;
RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get);
(*dev->dev_ops->dev_infos_get)(dev, dev_info);
@@ -2595,12 +2597,25 @@ int
rte_eth_dev_set_mtu(uint16_t port_id, uint16_t mtu)
{
int ret;
+ struct rte_eth_dev_info dev_info;
struct rte_eth_dev *dev;
RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
dev = &rte_eth_devices[port_id];
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->mtu_set, -ENOTSUP);
+ /*
+ * Check if the device supports dev_infos_get, if it does not
+ * skip min_mtu/max_mtu validation here as this requires values
+ * that are populated within the call to rte_eth_dev_info_get()
+ * which relies on dev->dev_ops->dev_infos_get.
+ */
+ if (*dev->dev_ops->dev_infos_get != NULL) {
+ rte_eth_dev_info_get(port_id, &dev_info);
+ if (mtu < dev_info.min_mtu || mtu > dev_info.max_mtu)
+ return -EINVAL;
+ }
+
ret = (*dev->dev_ops->mtu_set)(dev, mtu);
if (!ret)
dev->data->mtu = mtu;
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index 2be9b4ba1..b6023c050 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1088,6 +1088,8 @@ struct rte_eth_dev_info {
const char *driver_name; /**< Device Driver name. */
unsigned int if_index; /**< Index to bound host interface, or 0 if none.
Use if_indextoname() to translate into an interface name. */
+ uint16_t min_mtu; /**< Minimum MTU allowed */
+ uint16_t max_mtu; /**< Maximum MTU allowed */
const uint32_t *dev_flags; /**< Device flags */
uint32_t min_rx_bufsize; /**< Minimum size of RX buffer. */
uint32_t max_rx_pktlen; /**< Maximum configurable length of RX pkt. */
@@ -2204,6 +2206,33 @@ void rte_eth_macaddr_get(uint16_t port_id, struct ether_addr *mac_addr);
/**
* Retrieve the contextual information of an Ethernet device.
*
+ * As part of this function, a number of of fields in dev_info will be
+ * initialized as follows:
+ *
+ * rx_desc_lim = lim
+ * tx_desc_lim = lim
+ *
+ * Where lim is defined within the rte_eth_dev_info_get as
+ *
+ * const struct rte_eth_desc_lim lim = {
+ * .nb_max = UINT16_MAX,
+ * .nb_min = 0,
+ * .nb_align = 1,
+ * };
+ *
+ * device = dev->device
+ * min_mtu = ETHER_MIN_MTU
+ * max_mtu = UINT16_MAX
+ *
+ * The following fields will be populated if support for dev_infos_get()
+ * exists for the device and the rte_eth_dev 'dev' has been populated
+ * successfully with a call to it:
+ *
+ * driver_name = dev->device->driver->name
+ * nb_rx_queues = dev->data->nb_rx_queues
+ * nb_tx_queues = dev->data->nb_tx_queues
+ * dev_flags = &dev->data->dev_flags
+ *
* @param port_id
* The port identifier of the Ethernet device.
* @param dev_info
@@ -2300,7 +2329,9 @@ int rte_eth_dev_get_mtu(uint16_t port_id, uint16_t *mtu);
* - (-ENOTSUP) if operation is not supported.
* - (-ENODEV) if *port_id* invalid.
* - (-EIO) if device is removed.
- * - (-EINVAL) if *mtu* invalid.
+ * - (-EINVAL) if *mtu* invalid, validation of mtu can occur within
+ * rte_eth_dev_set_mtu if dev_infos_get is supported by the device or
+ * when the mtu is set using dev->dev_ops->mtu_set.
* - (-EBUSY) if operation is not allowed when the port is running
*/
int rte_eth_dev_set_mtu(uint16_t port_id, uint16_t mtu);
--
2.20.1
^ permalink raw reply [relevance 11%]
* [dpdk-dev] [PATCH v3 1/7] ethdev: add min/max MTU to device info
2019-03-29 17:52 11% ` [dpdk-dev] [PATCH v3 " Ferruh Yigit
@ 2019-03-29 17:52 11% ` Ferruh Yigit
2019-03-29 17:56 0% ` Ferruh Yigit
1 sibling, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-03-29 17:52 UTC (permalink / raw)
To: Neil Horman, John McNamara, Marko Kovacevic, Thomas Monjalon,
Andrew Rybchenko
Cc: dev, Stephen Hemminger, Ian Stokes
From: Stephen Hemminger <stephen@networkplumber.org>
This addresses the usability issue raised by OVS at DPDK Userspace
summit. It adds general min/max mtu into device info. For compatiablity,
and to save space, it fits in a hole in existing structure.
The initial version sets max mtu to normal Ethernet, it is up to
PMD to set larger value if it supports Jumbo frames.
Also remove the deprecation notice introduced in 18.11 regarding this
change and bump ethdev ABI version.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Ian Stokes <ian.stokes@intel.com>
Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 12 ----------
doc/guides/rel_notes/release_19_05.rst | 9 ++++++-
lib/librte_ethdev/Makefile | 2 +-
lib/librte_ethdev/meson.build | 2 +-
lib/librte_ethdev/rte_ethdev.c | 15 ++++++++++++
lib/librte_ethdev/rte_ethdev.h | 33 +++++++++++++++++++++++++-
6 files changed, 57 insertions(+), 16 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 73bfa9d4a..6f55c4740 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -52,18 +52,6 @@ Deprecation Notices
Target release for removal of the legacy API will be defined once most
PMDs have switched to rte_flow.
-* ethdev: Maximum and minimum MTU values vary between hardware devices. In
- hardware agnostic DPDK applications access to such information would allow
- a more accurate way of validating and setting supported MTU values on a per
- device basis rather than using a defined default for all devices. To
- resolve this, the following members will be added to ``rte_eth_dev_info``.
- Note: these can be added to fit a hole in the existing structure for amd64
- but not for 32-bit, as such ABI change will occur as size of the structure
- will increase.
-
- - Member ``uint16_t min_mtu`` the minimum MTU allowed.
- - Member ``uint16_t max_mtu`` the maximum MTU allowed.
-
* kni: remove KNI ethtool support. To clarify, this is not to remove the KNI,
but only to remove ethtool support of it that is disabled by default and
can be enabled via ``CONFIG_RTE_KNI_KMOD_ETHTOOL`` config option.
diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst
index cddd800e4..8d2d8a7e9 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -164,6 +164,13 @@ ABI Changes
Also, make sure to start the actual text at the margin.
=========================================================
+* ethdev: Additional fields in rte_eth_dev_info.
+
+ The ``rte_eth_dev_info`` structure has had two extra fields
+ added: ``min_mtu`` and ``max_mtu``. Each of these are of type ``uint16_t``.
+ The values of these fields can be set specifically by the PMD drivers as
+ supported values can vary from device to device.
+
* cryptodev: in 18.08 new structure ``rte_crypto_asym_op`` was introduced and
included into ``rte_crypto_op``. As ``rte_crypto_asym_op`` structure was
defined as cache-line aligned that caused unintended changes in
@@ -206,7 +213,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_distributor.so.1
+ librte_eal.so.10
librte_efd.so.1
- librte_ethdev.so.11
+ + librte_ethdev.so.12
librte_eventdev.so.6
librte_flow_classify.so.1
librte_gro.so.1
diff --git a/lib/librte_ethdev/Makefile b/lib/librte_ethdev/Makefile
index e09c4263a..8d4a02630 100644
--- a/lib/librte_ethdev/Makefile
+++ b/lib/librte_ethdev/Makefile
@@ -16,7 +16,7 @@ LDLIBS += -lrte_mbuf -lrte_kvargs -lrte_cmdline -lrte_meter
EXPORT_MAP := rte_ethdev_version.map
-LIBABIVER := 11
+LIBABIVER := 12
SRCS-y += ethdev_private.c
SRCS-y += rte_ethdev.c
diff --git a/lib/librte_ethdev/meson.build b/lib/librte_ethdev/meson.build
index e98942ff8..8d6165b2a 100644
--- a/lib/librte_ethdev/meson.build
+++ b/lib/librte_ethdev/meson.build
@@ -2,7 +2,7 @@
# Copyright(c) 2017 Intel Corporation
name = 'ethdev'
-version = 11
+version = 12
allow_experimental_apis = true
sources = files('ethdev_private.c',
'ethdev_profile.c',
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 12b66b68c..10bdfb37e 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -2532,6 +2532,8 @@ rte_eth_dev_info_get(uint16_t port_id, struct rte_eth_dev_info *dev_info)
dev_info->rx_desc_lim = lim;
dev_info->tx_desc_lim = lim;
dev_info->device = dev->device;
+ dev_info->min_mtu = ETHER_MIN_MTU;
+ dev_info->max_mtu = UINT16_MAX;
RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get);
(*dev->dev_ops->dev_infos_get)(dev, dev_info);
@@ -2595,12 +2597,25 @@ int
rte_eth_dev_set_mtu(uint16_t port_id, uint16_t mtu)
{
int ret;
+ struct rte_eth_dev_info dev_info;
struct rte_eth_dev *dev;
RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
dev = &rte_eth_devices[port_id];
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->mtu_set, -ENOTSUP);
+ /*
+ * Check if the device supports dev_infos_get, if it does not
+ * skip min_mtu/max_mtu validation here as this requires values
+ * that are populated within the call to rte_eth_dev_info_get()
+ * which relies on dev->dev_ops->dev_infos_get.
+ */
+ if (*dev->dev_ops->dev_infos_get != NULL) {
+ rte_eth_dev_info_get(port_id, &dev_info);
+ if (mtu < dev_info.min_mtu || mtu > dev_info.max_mtu)
+ return -EINVAL;
+ }
+
ret = (*dev->dev_ops->mtu_set)(dev, mtu);
if (!ret)
dev->data->mtu = mtu;
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index 2be9b4ba1..b6023c050 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1088,6 +1088,8 @@ struct rte_eth_dev_info {
const char *driver_name; /**< Device Driver name. */
unsigned int if_index; /**< Index to bound host interface, or 0 if none.
Use if_indextoname() to translate into an interface name. */
+ uint16_t min_mtu; /**< Minimum MTU allowed */
+ uint16_t max_mtu; /**< Maximum MTU allowed */
const uint32_t *dev_flags; /**< Device flags */
uint32_t min_rx_bufsize; /**< Minimum size of RX buffer. */
uint32_t max_rx_pktlen; /**< Maximum configurable length of RX pkt. */
@@ -2204,6 +2206,33 @@ void rte_eth_macaddr_get(uint16_t port_id, struct ether_addr *mac_addr);
/**
* Retrieve the contextual information of an Ethernet device.
*
+ * As part of this function, a number of of fields in dev_info will be
+ * initialized as follows:
+ *
+ * rx_desc_lim = lim
+ * tx_desc_lim = lim
+ *
+ * Where lim is defined within the rte_eth_dev_info_get as
+ *
+ * const struct rte_eth_desc_lim lim = {
+ * .nb_max = UINT16_MAX,
+ * .nb_min = 0,
+ * .nb_align = 1,
+ * };
+ *
+ * device = dev->device
+ * min_mtu = ETHER_MIN_MTU
+ * max_mtu = UINT16_MAX
+ *
+ * The following fields will be populated if support for dev_infos_get()
+ * exists for the device and the rte_eth_dev 'dev' has been populated
+ * successfully with a call to it:
+ *
+ * driver_name = dev->device->driver->name
+ * nb_rx_queues = dev->data->nb_rx_queues
+ * nb_tx_queues = dev->data->nb_tx_queues
+ * dev_flags = &dev->data->dev_flags
+ *
* @param port_id
* The port identifier of the Ethernet device.
* @param dev_info
@@ -2300,7 +2329,9 @@ int rte_eth_dev_get_mtu(uint16_t port_id, uint16_t *mtu);
* - (-ENOTSUP) if operation is not supported.
* - (-ENODEV) if *port_id* invalid.
* - (-EIO) if device is removed.
- * - (-EINVAL) if *mtu* invalid.
+ * - (-EINVAL) if *mtu* invalid, validation of mtu can occur within
+ * rte_eth_dev_set_mtu if dev_infos_get is supported by the device or
+ * when the mtu is set using dev->dev_ops->mtu_set.
* - (-EBUSY) if operation is not allowed when the port is running
*/
int rte_eth_dev_set_mtu(uint16_t port_id, uint16_t mtu);
--
2.20.1
^ permalink raw reply [relevance 11%]
* Re: [dpdk-dev] [PATCH v3 1/7] ethdev: add min/max MTU to device info
2019-03-29 17:52 11% ` [dpdk-dev] [PATCH v3 " Ferruh Yigit
2019-03-29 17:52 11% ` Ferruh Yigit
@ 2019-03-29 17:56 0% ` Ferruh Yigit
2019-03-29 17:56 0% ` Ferruh Yigit
2019-03-29 18:05 0% ` Ferruh Yigit
1 sibling, 2 replies; 200+ results
From: Ferruh Yigit @ 2019-03-29 17:56 UTC (permalink / raw)
To: Neil Horman, John McNamara, Marko Kovacevic, Thomas Monjalon,
Andrew Rybchenko
Cc: dev, Stephen Hemminger, Ian Stokes
On 3/29/2019 5:52 PM, Ferruh Yigit wrote:
> From: Stephen Hemminger <stephen@networkplumber.org>
>
> This addresses the usability issue raised by OVS at DPDK Userspace
> summit. It adds general min/max mtu into device info. For compatiablity,
> and to save space, it fits in a hole in existing structure.
>
> The initial version sets max mtu to normal Ethernet, it is up to
> PMD to set larger value if it supports Jumbo frames.
>
> Also remove the deprecation notice introduced in 18.11 regarding this
> change and bump ethdev ABI version.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> Signed-off-by: Ian Stokes <ian.stokes@intel.com>
> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
> Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
(series re-sent only for change in 7/7 to add a log for failure, rest is same,
kept all authors/sign-off as it is)
For series,
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3 1/7] ethdev: add min/max MTU to device info
2019-03-29 17:56 0% ` Ferruh Yigit
@ 2019-03-29 17:56 0% ` Ferruh Yigit
2019-03-29 18:05 0% ` Ferruh Yigit
1 sibling, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-03-29 17:56 UTC (permalink / raw)
To: Neil Horman, John McNamara, Marko Kovacevic, Thomas Monjalon,
Andrew Rybchenko
Cc: dev, Stephen Hemminger, Ian Stokes
On 3/29/2019 5:52 PM, Ferruh Yigit wrote:
> From: Stephen Hemminger <stephen@networkplumber.org>
>
> This addresses the usability issue raised by OVS at DPDK Userspace
> summit. It adds general min/max mtu into device info. For compatiablity,
> and to save space, it fits in a hole in existing structure.
>
> The initial version sets max mtu to normal Ethernet, it is up to
> PMD to set larger value if it supports Jumbo frames.
>
> Also remove the deprecation notice introduced in 18.11 regarding this
> change and bump ethdev ABI version.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> Signed-off-by: Ian Stokes <ian.stokes@intel.com>
> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
> Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
(series re-sent only for change in 7/7 to add a log for failure, rest is same,
kept all authors/sign-off as it is)
For series,
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3 1/7] ethdev: add min/max MTU to device info
2019-03-29 17:56 0% ` Ferruh Yigit
2019-03-29 17:56 0% ` Ferruh Yigit
@ 2019-03-29 18:05 0% ` Ferruh Yigit
2019-03-29 18:05 0% ` Ferruh Yigit
1 sibling, 1 reply; 200+ results
From: Ferruh Yigit @ 2019-03-29 18:05 UTC (permalink / raw)
To: Neil Horman, John McNamara, Marko Kovacevic, Thomas Monjalon,
Andrew Rybchenko
Cc: dev, Stephen Hemminger, Ian Stokes
On 3/29/2019 5:56 PM, Ferruh Yigit wrote:
> On 3/29/2019 5:52 PM, Ferruh Yigit wrote:
>> From: Stephen Hemminger <stephen@networkplumber.org>
>>
>> This addresses the usability issue raised by OVS at DPDK Userspace
>> summit. It adds general min/max mtu into device info. For compatiablity,
>> and to save space, it fits in a hole in existing structure.
>>
>> The initial version sets max mtu to normal Ethernet, it is up to
>> PMD to set larger value if it supports Jumbo frames.
>>
>> Also remove the deprecation notice introduced in 18.11 regarding this
>> change and bump ethdev ABI version.
>>
>> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>> Signed-off-by: Ian Stokes <ian.stokes@intel.com>
>> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
>> Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
>
> (series re-sent only for change in 7/7 to add a log for failure, rest is same,
> kept all authors/sign-off as it is)
>
> For series,
> Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
>
Series applied to dpdk-next-net/master, thanks.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3 1/7] ethdev: add min/max MTU to device info
2019-03-29 18:05 0% ` Ferruh Yigit
@ 2019-03-29 18:05 0% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-03-29 18:05 UTC (permalink / raw)
To: Neil Horman, John McNamara, Marko Kovacevic, Thomas Monjalon,
Andrew Rybchenko
Cc: dev, Stephen Hemminger, Ian Stokes
On 3/29/2019 5:56 PM, Ferruh Yigit wrote:
> On 3/29/2019 5:52 PM, Ferruh Yigit wrote:
>> From: Stephen Hemminger <stephen@networkplumber.org>
>>
>> This addresses the usability issue raised by OVS at DPDK Userspace
>> summit. It adds general min/max mtu into device info. For compatiablity,
>> and to save space, it fits in a hole in existing structure.
>>
>> The initial version sets max mtu to normal Ethernet, it is up to
>> PMD to set larger value if it supports Jumbo frames.
>>
>> Also remove the deprecation notice introduced in 18.11 regarding this
>> change and bump ethdev ABI version.
>>
>> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>> Signed-off-by: Ian Stokes <ian.stokes@intel.com>
>> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
>> Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
>
> (series re-sent only for change in 7/7 to add a log for failure, rest is same,
> kept all authors/sign-off as it is)
>
> For series,
> Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
>
Series applied to dpdk-next-net/master, thanks.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 1/6] vfio: allow DMA map of memory for the default vfio fd
2019-03-10 8:27 5% ` [dpdk-dev] [PATCH v4 1/6] vfio: allow DMA map of memory for the default vfio fd Shahaf Shuler
@ 2019-03-30 0:23 3% ` Thomas Monjalon
2019-03-30 0:23 3% ` Thomas Monjalon
2019-03-30 14:29 0% ` Thomas Monjalon
0 siblings, 2 replies; 200+ results
From: Thomas Monjalon @ 2019-03-30 0:23 UTC (permalink / raw)
To: Shahaf Shuler
Cc: dev, anatoly.burakov, yskoh, ferruh.yigit, nhorman, gaetan.rivet
10/03/2019 09:27, Shahaf Shuler:
> Enable users the option to call rte_vfio_dma_map with request to map
> to the default vfio fd.
>
> Signed-off-by: Shahaf Shuler <shahafs@mellanox.com>
> Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
> ---
> --- a/doc/guides/rel_notes/release_19_05.rst
> +++ b/doc/guides/rel_notes/release_19_05.rst
> @@ -136,6 +136,9 @@ ABI Changes
> +* vfio: Functions ``rte_vfio_container_dma_map`` and
> + ``rte_vfio_container_dma_unmap`` have been extended with an option to
> + request mapping or un-mapping to the default vfio container fd.
Isn't it an API change rather than ABI?
It is adding -1 as a special value, I think it is not breaking
previous interface, and does not require a notification in the release notes.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v4 1/6] vfio: allow DMA map of memory for the default vfio fd
2019-03-30 0:23 3% ` Thomas Monjalon
@ 2019-03-30 0:23 3% ` Thomas Monjalon
2019-03-30 14:29 0% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-03-30 0:23 UTC (permalink / raw)
To: Shahaf Shuler
Cc: dev, anatoly.burakov, yskoh, ferruh.yigit, nhorman, gaetan.rivet
10/03/2019 09:27, Shahaf Shuler:
> Enable users the option to call rte_vfio_dma_map with request to map
> to the default vfio fd.
>
> Signed-off-by: Shahaf Shuler <shahafs@mellanox.com>
> Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
> ---
> --- a/doc/guides/rel_notes/release_19_05.rst
> +++ b/doc/guides/rel_notes/release_19_05.rst
> @@ -136,6 +136,9 @@ ABI Changes
> +* vfio: Functions ``rte_vfio_container_dma_map`` and
> + ``rte_vfio_container_dma_unmap`` have been extended with an option to
> + request mapping or un-mapping to the default vfio container fd.
Isn't it an API change rather than ABI?
It is adding -1 as a special value, I think it is not breaking
previous interface, and does not require a notification in the release notes.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v4 1/6] vfio: allow DMA map of memory for the default vfio fd
2019-03-30 0:23 3% ` Thomas Monjalon
2019-03-30 0:23 3% ` Thomas Monjalon
@ 2019-03-30 14:29 0% ` Thomas Monjalon
2019-03-30 14:29 0% ` Thomas Monjalon
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-03-30 14:29 UTC (permalink / raw)
To: Shahaf Shuler
Cc: dev, anatoly.burakov, yskoh, ferruh.yigit, nhorman, gaetan.rivet
30/03/2019 01:23, Thomas Monjalon:
> 10/03/2019 09:27, Shahaf Shuler:
> > Enable users the option to call rte_vfio_dma_map with request to map
> > to the default vfio fd.
> >
> > Signed-off-by: Shahaf Shuler <shahafs@mellanox.com>
> > Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
> > ---
> > --- a/doc/guides/rel_notes/release_19_05.rst
> > +++ b/doc/guides/rel_notes/release_19_05.rst
> > @@ -136,6 +136,9 @@ ABI Changes
> > +* vfio: Functions ``rte_vfio_container_dma_map`` and
> > + ``rte_vfio_container_dma_unmap`` have been extended with an option to
> > + request mapping or un-mapping to the default vfio container fd.
>
> Isn't it an API change rather than ABI?
> It is adding -1 as a special value, I think it is not breaking
> previous interface, and does not require a notification in the release notes.
I will move it to the "API changes" section.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 1/6] vfio: allow DMA map of memory for the default vfio fd
2019-03-30 14:29 0% ` Thomas Monjalon
@ 2019-03-30 14:29 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-03-30 14:29 UTC (permalink / raw)
To: Shahaf Shuler
Cc: dev, anatoly.burakov, yskoh, ferruh.yigit, nhorman, gaetan.rivet
30/03/2019 01:23, Thomas Monjalon:
> 10/03/2019 09:27, Shahaf Shuler:
> > Enable users the option to call rte_vfio_dma_map with request to map
> > to the default vfio fd.
> >
> > Signed-off-by: Shahaf Shuler <shahafs@mellanox.com>
> > Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
> > ---
> > --- a/doc/guides/rel_notes/release_19_05.rst
> > +++ b/doc/guides/rel_notes/release_19_05.rst
> > @@ -136,6 +136,9 @@ ABI Changes
> > +* vfio: Functions ``rte_vfio_container_dma_map`` and
> > + ``rte_vfio_container_dma_unmap`` have been extended with an option to
> > + request mapping or un-mapping to the default vfio container fd.
>
> Isn't it an API change rather than ABI?
> It is adding -1 as a special value, I think it is not breaking
> previous interface, and does not require a notification in the release notes.
I will move it to the "API changes" section.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 0/6] Add lock-free ring and mempool handler
2019-03-19 15:51 3% ` Stephen Hemminger
2019-03-19 15:51 3% ` Stephen Hemminger
@ 2019-04-01 19:23 0% ` Eads, Gage
2019-04-01 19:23 0% ` Eads, Gage
2019-04-02 10:16 0% ` Ola Liljedahl
1 sibling, 2 replies; 200+ results
From: Eads, Gage @ 2019-04-01 19:23 UTC (permalink / raw)
To: Stephen Hemminger
Cc: dev, olivier.matz, arybchenko, Richardson, Bruce, Ananyev,
Konstantin, jerinj, mczekaj, nd, Ola.Liljedahl
>
> On Mon, 18 Mar 2019 21:49:44 +0000
> "Eads, Gage" <gage.eads@intel.com> wrote:
>
> > Hi all,
> >
> > Friendly reminder that in order to get this feature into 19.08 (assuming
> folks also want that :)), the API deprecation notice needs to be merged into
> 19.05.
> >
> > Thanks,
> > Gage
>
> Given the recent API/ABI stability discussion, this is the kind of patch that
> really needs to be examined and justified.
Can you point me to the discussion (assuming it was on the ML)? I'm aware of Ferruh's changes to the docs, but not the discussion you referenced.
The lock-free ring functionality itself is a valuable addition to DPDK, primarily because it lacks the standard ring's non-preemptive constraint. The non-preemptive constraint is important in an application with both high priority, performance-sensitive data-plane components and low-priority control-plane components. This was important enough to warrant further clarification recently[1], and has been a discussion topic for some time[2][3].
The modified API, rte_ring_get_memsize(), was added to allow users to initialize rings in separately allocated memory. This function isn't called in DPDK's examples/apps/drivers, and a quick google search didn't turn up any open source projects that call the function, so I suspect that a majority of ring code uses rte_ring_create() instead of rte_ring_get_memsize() + rte_ring_init(). So I suspect this interface change will affect a small percentage of DPDK users.
As a straw-man counter-proposal, we could instead introduce a lock-free specific function rte_lf_ring_get_memsize() that lock-free ring users would call instead of rte_ring_get_memsize(). This would avoid the API modification, but:
- It's awkward to have one rte_lf_ring_* function and otherwise access the lock-free ring through rte_ring_* functions.
- It's also easy to envision a user incorrectly calling rte_ring_get_memsize() rather than rte_lf_ring_get_memsize() for a lock-free ring, since otherwise rte_ring_* functions are used. DPDK would have no way to detect that the allocated memory is too small, and if such a bug occurs it would manifest itself as memory corruption.
- Changing rte_ring_get_memsize() to take a flags argument may be the better long-term design, if another flag is introduced that likewise uses a different ring size.
Another approach is to break out the lock-free ring into a fully separate API. One of the goals of my patchset was to allow applications to switch to lock-free rings with minimal code change; I think the value of the lock-free ring warrants such an approach.
(Unfortunately without hard numbers on the cost or benefit of such a change, these arguments are fairly subjective.)
Thanks,
Gage
[1] https://patches.dpdk.org/patch/43122/
[2] http://mails.dpdk.org/archives/dev/2013-November/000714.html
[3] http://mails.dpdk.org/archives/dev/2014-January/001163.html
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 0/6] Add lock-free ring and mempool handler
2019-04-01 19:23 0% ` Eads, Gage
@ 2019-04-01 19:23 0% ` Eads, Gage
2019-04-02 10:16 0% ` Ola Liljedahl
1 sibling, 0 replies; 200+ results
From: Eads, Gage @ 2019-04-01 19:23 UTC (permalink / raw)
To: Stephen Hemminger
Cc: dev, olivier.matz, arybchenko, Richardson, Bruce, Ananyev,
Konstantin, jerinj, mczekaj, nd, Ola.Liljedahl
>
> On Mon, 18 Mar 2019 21:49:44 +0000
> "Eads, Gage" <gage.eads@intel.com> wrote:
>
> > Hi all,
> >
> > Friendly reminder that in order to get this feature into 19.08 (assuming
> folks also want that :)), the API deprecation notice needs to be merged into
> 19.05.
> >
> > Thanks,
> > Gage
>
> Given the recent API/ABI stability discussion, this is the kind of patch that
> really needs to be examined and justified.
Can you point me to the discussion (assuming it was on the ML)? I'm aware of Ferruh's changes to the docs, but not the discussion you referenced.
The lock-free ring functionality itself is a valuable addition to DPDK, primarily because it lacks the standard ring's non-preemptive constraint. The non-preemptive constraint is important in an application with both high priority, performance-sensitive data-plane components and low-priority control-plane components. This was important enough to warrant further clarification recently[1], and has been a discussion topic for some time[2][3].
The modified API, rte_ring_get_memsize(), was added to allow users to initialize rings in separately allocated memory. This function isn't called in DPDK's examples/apps/drivers, and a quick google search didn't turn up any open source projects that call the function, so I suspect that a majority of ring code uses rte_ring_create() instead of rte_ring_get_memsize() + rte_ring_init(). So I suspect this interface change will affect a small percentage of DPDK users.
As a straw-man counter-proposal, we could instead introduce a lock-free specific function rte_lf_ring_get_memsize() that lock-free ring users would call instead of rte_ring_get_memsize(). This would avoid the API modification, but:
- It's awkward to have one rte_lf_ring_* function and otherwise access the lock-free ring through rte_ring_* functions.
- It's also easy to envision a user incorrectly calling rte_ring_get_memsize() rather than rte_lf_ring_get_memsize() for a lock-free ring, since otherwise rte_ring_* functions are used. DPDK would have no way to detect that the allocated memory is too small, and if such a bug occurs it would manifest itself as memory corruption.
- Changing rte_ring_get_memsize() to take a flags argument may be the better long-term design, if another flag is introduced that likewise uses a different ring size.
Another approach is to break out the lock-free ring into a fully separate API. One of the goals of my patchset was to allow applications to switch to lock-free rings with minimal code change; I think the value of the lock-free ring warrants such an approach.
(Unfortunately without hard numbers on the cost or benefit of such a change, these arguments are fairly subjective.)
Thanks,
Gage
[1] https://patches.dpdk.org/patch/43122/
[2] http://mails.dpdk.org/archives/dev/2013-November/000714.html
[3] http://mails.dpdk.org/archives/dev/2014-January/001163.html
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 0/6] Add lock-free ring and mempool handler
2019-04-01 19:23 0% ` Eads, Gage
2019-04-01 19:23 0% ` Eads, Gage
@ 2019-04-02 10:16 0% ` Ola Liljedahl
2019-04-02 10:16 0% ` Ola Liljedahl
1 sibling, 1 reply; 200+ results
From: Ola Liljedahl @ 2019-04-02 10:16 UTC (permalink / raw)
To: stephen, gage.eads
Cc: jerinj, mczekaj, nd, konstantin.ananyev, bruce.richardson, dev,
olivier.matz, arybchenko
On Mon, 2019-04-01 at 19:23 +0000, Eads, Gage wrote:
> >
> >
> > On Mon, 18 Mar 2019 21:49:44 +0000
> > "Eads, Gage" <gage.eads@intel.com> wrote:
> >
> > >
> > > Hi all,
> > >
> > > Friendly reminder that in order to get this feature into 19.08 (assuming
> > folks also want that :)), the API deprecation notice needs to be merged into
> > 19.05.
> > >
> > >
> > > Thanks,
> > > Gage
> > Given the recent API/ABI stability discussion, this is the kind of patch
> > that
> > really needs to be examined and justified.
> Can you point me to the discussion (assuming it was on the ML)? I'm aware of
> Ferruh's changes to the docs, but not the discussion you referenced.
>
> The lock-free ring functionality itself is a valuable addition to DPDK,
> primarily because it lacks the standard ring's non-preemptive constraint. The
> non-preemptive constraint is important in an application with both high
> priority, performance-sensitive data-plane components and low-priority
> control-plane components. This was important enough to warrant further
> clarification recently[1], and has been a discussion topic for some
> time[2][3].
>
> The modified API, rte_ring_get_memsize(), was added to allow users to
> initialize rings in separately allocated memory. This function isn't called in
> DPDK's examples/apps/drivers, and a quick google search didn't turn up any
> open source projects that call the function, so I suspect that a majority of
> ring code uses rte_ring_create() instead of rte_ring_get_memsize() +
> rte_ring_init(). So I suspect this interface change will affect a small
> percentage of DPDK users.
>
> As a straw-man counter-proposal, we could instead introduce a lock-free
> specific function rte_lf_ring_get_memsize() that lock-free ring users would
> call instead of rte_ring_get_memsize(). This would avoid the API modification,
> but:
> - It's awkward to have one rte_lf_ring_* function and otherwise access the
> lock-free ring through rte_ring_* functions.
> - It's also easy to envision a user incorrectly calling rte_ring_get_memsize()
> rather than rte_lf_ring_get_memsize() for a lock-free ring, since otherwise
> rte_ring_* functions are used. DPDK would have no way to detect that the
> allocated memory is too small, and if such a bug occurs it would manifest
> itself as memory corruption.
> - Changing rte_ring_get_memsize() to take a flags argument may be the better
> long-term design, if another flag is introduced that likewise uses a different
> ring size.
>
> Another approach is to break out the lock-free ring into a fully separate API.
As in the RFC I posted: http://patches.dpdk.org/patch/50095/
Cleaner API, simpler implementation.
One of the goals of my patchset was to allow applications to switch to lock-free rings with minimal code change; I think the value of the lock-free ring warrants such an approach.
A noble goal but personally I think DPDK API's and implementations are getting
more and more messy and thus difficult to use and difficult to maintain.
Is it so much worse to have separate but structurally equivalent API's?
Yes, blocking vs non-blocking can no longer be selected at runtime (startup
time), I think this is the biggest limitation.
-- Ola
(Unfortunately without hard numbers on the cost or benefit of such a change, these arguments are fairly subjective.)
Thanks,
Gage
[1] https://patches.dpdk.org/patch/43122/
[2] http://mails.dpdk.org/archives/dev/2013-November/000714.html
[3] http://mails.dpdk.org/archives/dev/2014-January/001163.html
--
Ola Liljedahl, Networking System Architect, Arm
Phone +46706866373, Skype ola.liljedahl
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 0/6] Add lock-free ring and mempool handler
2019-04-02 10:16 0% ` Ola Liljedahl
@ 2019-04-02 10:16 0% ` Ola Liljedahl
0 siblings, 0 replies; 200+ results
From: Ola Liljedahl @ 2019-04-02 10:16 UTC (permalink / raw)
To: stephen, gage.eads
Cc: jerinj, mczekaj, nd, konstantin.ananyev, bruce.richardson, dev,
olivier.matz, arybchenko
On Mon, 2019-04-01 at 19:23 +0000, Eads, Gage wrote:
> >
> >
> > On Mon, 18 Mar 2019 21:49:44 +0000
> > "Eads, Gage" <gage.eads@intel.com> wrote:
> >
> > >
> > > Hi all,
> > >
> > > Friendly reminder that in order to get this feature into 19.08 (assuming
> > folks also want that :)), the API deprecation notice needs to be merged into
> > 19.05.
> > >
> > >
> > > Thanks,
> > > Gage
> > Given the recent API/ABI stability discussion, this is the kind of patch
> > that
> > really needs to be examined and justified.
> Can you point me to the discussion (assuming it was on the ML)? I'm aware of
> Ferruh's changes to the docs, but not the discussion you referenced.
>
> The lock-free ring functionality itself is a valuable addition to DPDK,
> primarily because it lacks the standard ring's non-preemptive constraint. The
> non-preemptive constraint is important in an application with both high
> priority, performance-sensitive data-plane components and low-priority
> control-plane components. This was important enough to warrant further
> clarification recently[1], and has been a discussion topic for some
> time[2][3].
>
> The modified API, rte_ring_get_memsize(), was added to allow users to
> initialize rings in separately allocated memory. This function isn't called in
> DPDK's examples/apps/drivers, and a quick google search didn't turn up any
> open source projects that call the function, so I suspect that a majority of
> ring code uses rte_ring_create() instead of rte_ring_get_memsize() +
> rte_ring_init(). So I suspect this interface change will affect a small
> percentage of DPDK users.
>
> As a straw-man counter-proposal, we could instead introduce a lock-free
> specific function rte_lf_ring_get_memsize() that lock-free ring users would
> call instead of rte_ring_get_memsize(). This would avoid the API modification,
> but:
> - It's awkward to have one rte_lf_ring_* function and otherwise access the
> lock-free ring through rte_ring_* functions.
> - It's also easy to envision a user incorrectly calling rte_ring_get_memsize()
> rather than rte_lf_ring_get_memsize() for a lock-free ring, since otherwise
> rte_ring_* functions are used. DPDK would have no way to detect that the
> allocated memory is too small, and if such a bug occurs it would manifest
> itself as memory corruption.
> - Changing rte_ring_get_memsize() to take a flags argument may be the better
> long-term design, if another flag is introduced that likewise uses a different
> ring size.
>
> Another approach is to break out the lock-free ring into a fully separate API.
As in the RFC I posted: http://patches.dpdk.org/patch/50095/
Cleaner API, simpler implementation.
One of the goals of my patchset was to allow applications to switch to lock-free rings with minimal code change; I think the value of the lock-free ring warrants such an approach.
A noble goal but personally I think DPDK API's and implementations are getting
more and more messy and thus difficult to use and difficult to maintain.
Is it so much worse to have separate but structurally equivalent API's?
Yes, blocking vs non-blocking can no longer be selected at runtime (startup
time), I think this is the biggest limitation.
-- Ola
(Unfortunately without hard numbers on the cost or benefit of such a change, these arguments are fairly subjective.)
Thanks,
Gage
[1] https://patches.dpdk.org/patch/43122/
[2] http://mails.dpdk.org/archives/dev/2013-November/000714.html
[3] http://mails.dpdk.org/archives/dev/2014-January/001163.html
--
Ola Liljedahl, Networking System Architect, Arm
Phone +46706866373, Skype ola.liljedahl
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v8 0/1] AF_XDP PMD
` (6 preceding siblings ...)
2019-03-27 9:00 2% ` [dpdk-dev] [PATCH v7 " Xiaolong Ye
@ 2019-04-02 10:45 2% ` Xiaolong Ye
2019-04-02 10:45 2% ` Xiaolong Ye
2019-04-02 15:46 2% ` [dpdk-dev] [PATCH v9 0/1] Introduce " Xiaolong Ye
8 siblings, 1 reply; 200+ results
From: Xiaolong Ye @ 2019-04-02 10:45 UTC (permalink / raw)
To: dev, David Marchand, Andrew Rybchenko, Olivier Matz
Cc: Qi Zhang, Karlsson Magnus, Topel Bjorn, Maxime Coquelin,
Stephen Hemminger, Ferruh Yigit, Luca Boccassi, Bruce Richardson,
Ananyev Konstantin, Xiaolong Ye
Hi, all
Overview
========
This patchset adds a new PMD driver for AF_XDP which is a proposed
faster version of AF_PACKET interface in Linux, see below links [1] [2] for
details of AF_XDP introduction:
AF_XDP roadmap
==============
- AF_XDP is included in upstream kernel since 4.18, and AF_XDP support
in libbpf has been merged in v5.1-rc1.
- Now i40e and ixgbe drivers have supported zero copy mode.
Change logs
===========
v8:
- address Ferruh's comments on V7
- replace posix_memalign with rte_memzone_reserve_aligned to get better
performance
- keep the first patch only as Oliver suggested as zero copy part
implementation is still in suspense, we may provide the related patch
later.
v7:
- mention mtu limitation in af_xdp.rst
- fix the vdev name in af_xdp.rst
V6:
- remove the newline in AF_XDP_LOG definition to avoid double new lines
issue.
- rename MEMPOOL_F_PAGE_ALIGN to MEMPOOL_CHUNK_F_PAGE_ALIGN.
V5:
- disable AF_XDP pmd by default due to it requires kernel more recent
than minimum kernel version supported by DPDK
- address other review comments of Maxime
V4:
- change vdev name to net_af_xdp
- adopt dynamic log type for all logging
- Fix other style issues raised by Stephen
V3:
- Fix all style issues pointed by Stephen, Mattias, David.
- Drop the testpmd change as we'll adopt Jerin's suggestion to add a new
mempool driver to handle the application use of AF_XDP's zero copy feature.
V2:
- Fix a NULL pointer reference crash issue
- Fix txonly stop sending traffic in zc mode
- Refactor rte_mbuf.c to avoid ABI breakage.
- Fix multiple style issues pointed by Ferruh, David, Stephen, Luca.
changes vs RFC sent by Qi last Aug:
- Re-work base on AF_XDP's interface changes since the new libbpf has
provided higher-level APIs that hide many of the details of the AP_XDP
uapi. After the rework, it helps to reduce 300+ lines of code.
- multi-queues is not supported due to current libbpf doesn't support
multi-sockets on a single umem.
- No extra steps to load xdp program manually, since the current behavior of
libbpf would load a default xdp program when user calls xsk_socket__create.
userspace application only needs to handle the cleanup.
How to try
==========
1. take the kernel >= v5.1-rc1, build kernel and replace your host
kernel with it.
make sure you turn on XDP sockets when compiling
Networking support -->
Networking options -->
[ * ] XDP sockets
2. build libbpf in tools/lib/bpf, and copy the libbpf.a and libbpf.so to /usr/lib64
cd tools/lib/bpf
make
3. ethtool -L enp59s0f0 combined 1
4. extra step to build dpdk
explicitly enable AF_XDP pmd by adding below line to
config/common_linux
CONFIG_RTE_LIBRTE_PMD_AF_XDP=y
5. start testpmd
./build/app/testpmd -c 0xc -n 4 --vdev net_af_xdp,iface=enp59s0f0,queue=0 -- -i --rxq=1 --txq=1
in this case, default xdp program will be loaded and linked to queue 0 of enp59s0f0,
network traffics travel to queue 0 will be redirected to af_xdp socket.
Xiaolong Ye (1):
net/af_xdp: introduce AF XDP PMD driver
MAINTAINERS | 7 +
config/common_base | 5 +
doc/guides/nics/af_xdp.rst | 48 +
doc/guides/nics/features/af_xdp.ini | 11 +
doc/guides/nics/index.rst | 1 +
doc/guides/rel_notes/release_19_05.rst | 7 +
drivers/net/Makefile | 1 +
drivers/net/af_xdp/Makefile | 32 +
drivers/net/af_xdp/meson.build | 21 +
drivers/net/af_xdp/rte_eth_af_xdp.c | 945 ++++++++++++++++++
drivers/net/af_xdp/rte_pmd_af_xdp_version.map | 3 +
drivers/net/meson.build | 1 +
mk/rte.app.mk | 1 +
13 files changed, 1083 insertions(+)
create mode 100644 doc/guides/nics/af_xdp.rst
create mode 100644 doc/guides/nics/features/af_xdp.ini
create mode 100644 drivers/net/af_xdp/Makefile
create mode 100644 drivers/net/af_xdp/meson.build
create mode 100644 drivers/net/af_xdp/rte_eth_af_xdp.c
create mode 100644 drivers/net/af_xdp/rte_pmd_af_xdp_version.map
--
2.17.1
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v8 0/1] AF_XDP PMD
2019-04-02 10:45 2% ` [dpdk-dev] [PATCH v8 0/1] " Xiaolong Ye
@ 2019-04-02 10:45 2% ` Xiaolong Ye
0 siblings, 0 replies; 200+ results
From: Xiaolong Ye @ 2019-04-02 10:45 UTC (permalink / raw)
To: dev, David Marchand, Andrew Rybchenko, Olivier Matz
Cc: Qi Zhang, Karlsson Magnus, Topel Bjorn, Maxime Coquelin,
Stephen Hemminger, Ferruh Yigit, Luca Boccassi, Bruce Richardson,
Ananyev Konstantin, Xiaolong Ye
Hi, all
Overview
========
This patchset adds a new PMD driver for AF_XDP which is a proposed
faster version of AF_PACKET interface in Linux, see below links [1] [2] for
details of AF_XDP introduction:
AF_XDP roadmap
==============
- AF_XDP is included in upstream kernel since 4.18, and AF_XDP support
in libbpf has been merged in v5.1-rc1.
- Now i40e and ixgbe drivers have supported zero copy mode.
Change logs
===========
v8:
- address Ferruh's comments on V7
- replace posix_memalign with rte_memzone_reserve_aligned to get better
performance
- keep the first patch only as Oliver suggested as zero copy part
implementation is still in suspense, we may provide the related patch
later.
v7:
- mention mtu limitation in af_xdp.rst
- fix the vdev name in af_xdp.rst
V6:
- remove the newline in AF_XDP_LOG definition to avoid double new lines
issue.
- rename MEMPOOL_F_PAGE_ALIGN to MEMPOOL_CHUNK_F_PAGE_ALIGN.
V5:
- disable AF_XDP pmd by default due to it requires kernel more recent
than minimum kernel version supported by DPDK
- address other review comments of Maxime
V4:
- change vdev name to net_af_xdp
- adopt dynamic log type for all logging
- Fix other style issues raised by Stephen
V3:
- Fix all style issues pointed by Stephen, Mattias, David.
- Drop the testpmd change as we'll adopt Jerin's suggestion to add a new
mempool driver to handle the application use of AF_XDP's zero copy feature.
V2:
- Fix a NULL pointer reference crash issue
- Fix txonly stop sending traffic in zc mode
- Refactor rte_mbuf.c to avoid ABI breakage.
- Fix multiple style issues pointed by Ferruh, David, Stephen, Luca.
changes vs RFC sent by Qi last Aug:
- Re-work base on AF_XDP's interface changes since the new libbpf has
provided higher-level APIs that hide many of the details of the AP_XDP
uapi. After the rework, it helps to reduce 300+ lines of code.
- multi-queues is not supported due to current libbpf doesn't support
multi-sockets on a single umem.
- No extra steps to load xdp program manually, since the current behavior of
libbpf would load a default xdp program when user calls xsk_socket__create.
userspace application only needs to handle the cleanup.
How to try
==========
1. take the kernel >= v5.1-rc1, build kernel and replace your host
kernel with it.
make sure you turn on XDP sockets when compiling
Networking support -->
Networking options -->
[ * ] XDP sockets
2. build libbpf in tools/lib/bpf, and copy the libbpf.a and libbpf.so to /usr/lib64
cd tools/lib/bpf
make
3. ethtool -L enp59s0f0 combined 1
4. extra step to build dpdk
explicitly enable AF_XDP pmd by adding below line to
config/common_linux
CONFIG_RTE_LIBRTE_PMD_AF_XDP=y
5. start testpmd
./build/app/testpmd -c 0xc -n 4 --vdev net_af_xdp,iface=enp59s0f0,queue=0 -- -i --rxq=1 --txq=1
in this case, default xdp program will be loaded and linked to queue 0 of enp59s0f0,
network traffics travel to queue 0 will be redirected to af_xdp socket.
Xiaolong Ye (1):
net/af_xdp: introduce AF XDP PMD driver
MAINTAINERS | 7 +
config/common_base | 5 +
doc/guides/nics/af_xdp.rst | 48 +
doc/guides/nics/features/af_xdp.ini | 11 +
doc/guides/nics/index.rst | 1 +
doc/guides/rel_notes/release_19_05.rst | 7 +
drivers/net/Makefile | 1 +
drivers/net/af_xdp/Makefile | 32 +
drivers/net/af_xdp/meson.build | 21 +
drivers/net/af_xdp/rte_eth_af_xdp.c | 945 ++++++++++++++++++
drivers/net/af_xdp/rte_pmd_af_xdp_version.map | 3 +
drivers/net/meson.build | 1 +
mk/rte.app.mk | 1 +
13 files changed, 1083 insertions(+)
create mode 100644 doc/guides/nics/af_xdp.rst
create mode 100644 doc/guides/nics/features/af_xdp.ini
create mode 100644 drivers/net/af_xdp/Makefile
create mode 100644 drivers/net/af_xdp/meson.build
create mode 100644 drivers/net/af_xdp/rte_eth_af_xdp.c
create mode 100644 drivers/net/af_xdp/rte_pmd_af_xdp_version.map
--
2.17.1
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v9 0/1] Introduce AF_XDP PMD
` (7 preceding siblings ...)
2019-04-02 10:45 2% ` [dpdk-dev] [PATCH v8 0/1] " Xiaolong Ye
@ 2019-04-02 15:46 2% ` Xiaolong Ye
2019-04-02 15:46 2% ` Xiaolong Ye
8 siblings, 1 reply; 200+ results
From: Xiaolong Ye @ 2019-04-02 15:46 UTC (permalink / raw)
To: dev, Stephen Hemminger, Ferruh Yigit
Cc: Qi Zhang, Karlsson Magnus, Topel Bjorn, Maxime Coquelin,
Luca Boccassi, Bruce Richardson, Ananyev Konstantin,
David Marchand, Andrew Rybchenko, Olivier Matz, Xiaolong Ye
Overview
========
This patchset adds a new PMD driver for AF_XDP which is a proposed
faster version of AF_PACKET interface in Linux, see below links [1] [2] for
details of AF_XDP introduction:
AF_XDP roadmap
==============
- AF_XDP is included in upstream kernel since 4.18, and AF_XDP support
in libbpf has been merged in v5.1-rc1.
- Now i40e and ixgbe drivers have supported zero copy mode.
Change logs
===========
V9:
- adjust header files order according to Stephen's suggestion
v8:
- address Ferruh's comments on V7
- replace posix_memalign with rte_memzone_reserve_aligned to get better
performance
- keep the first patch only as Oliver suggested as zero copy part
implementation is still in suspense, we may provide the related patch
later.
v7:
- mention mtu limitation in af_xdp.rst
- fix the vdev name in af_xdp.rst
V6:
- remove the newline in AF_XDP_LOG definition to avoid double new lines
issue.
- rename MEMPOOL_F_PAGE_ALIGN to MEMPOOL_CHUNK_F_PAGE_ALIGN.
V5:
- disable AF_XDP pmd by default due to it requires kernel more recent
than minimum kernel version supported by DPDK
- address other review comments of Maxime
V4:
- change vdev name to net_af_xdp
- adopt dynamic log type for all logging
- Fix other style issues raised by Stephen
V3:
- Fix all style issues pointed by Stephen, Mattias, David.
- Drop the testpmd change as we'll adopt Jerin's suggestion to add a new
mempool driver to handle the application use of AF_XDP's zero copy feature.
V2:
- Fix a NULL pointer reference crash issue
- Fix txonly stop sending traffic in zc mode
- Refactor rte_mbuf.c to avoid ABI breakage.
- Fix multiple style issues pointed by Ferruh, David, Stephen, Luca.
changes vs RFC sent by Qi last Aug:
- Re-work base on AF_XDP's interface changes since the new libbpf has
provided higher-level APIs that hide many of the details of the AP_XDP
uapi. After the rework, it helps to reduce 300+ lines of code.
- multi-queues is not supported due to current libbpf doesn't support
multi-sockets on a single umem.
- No extra steps to load xdp program manually, since the current behavior of
libbpf would load a default xdp program when user calls xsk_socket__create.
userspace application only needs to handle the cleanup.
How to try
==========
1. take the kernel >= v5.1-rc1, build kernel and replace your host
kernel with it.
make sure you turn on XDP sockets when compiling
Networking support -->
Networking options -->
[ * ] XDP sockets
2. build libbpf in tools/lib/bpf, and copy the libbpf.a and libbpf.so to /usr/lib64
cd tools/lib/bpf
make
3. ethtool -L enp59s0f0 combined 1
4. extra step to build dpdk
explicitly enable AF_XDP pmd by adding below line to
config/common_linux
CONFIG_RTE_LIBRTE_PMD_AF_XDP=y
5. start testpmd
./build/app/testpmd -c 0xc -n 4 --vdev net_af_xdp,iface=enp59s0f0,queue=0 -- -i --rxq=1 --txq=1
in this case, default xdp program will be loaded and linked to queue 0 of enp59s0f0,
network traffics travel to queue 0 will be redirected to af_xdp socket.
Xiaolong Ye (1):
net/af_xdp: introduce AF XDP PMD driver
MAINTAINERS | 7 +
config/common_base | 5 +
doc/guides/nics/af_xdp.rst | 48 +
doc/guides/nics/features/af_xdp.ini | 11 +
doc/guides/nics/index.rst | 1 +
doc/guides/rel_notes/release_19_05.rst | 7 +
drivers/net/Makefile | 1 +
drivers/net/af_xdp/Makefile | 32 +
drivers/net/af_xdp/meson.build | 21 +
drivers/net/af_xdp/rte_eth_af_xdp.c | 956 ++++++++++++++++++
drivers/net/af_xdp/rte_pmd_af_xdp_version.map | 3 +
drivers/net/meson.build | 1 +
mk/rte.app.mk | 1 +
13 files changed, 1094 insertions(+)
create mode 100644 doc/guides/nics/af_xdp.rst
create mode 100644 doc/guides/nics/features/af_xdp.ini
create mode 100644 drivers/net/af_xdp/Makefile
create mode 100644 drivers/net/af_xdp/meson.build
create mode 100644 drivers/net/af_xdp/rte_eth_af_xdp.c
create mode 100644 drivers/net/af_xdp/rte_pmd_af_xdp_version.map
--
2.17.1
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v9 0/1] Introduce AF_XDP PMD
2019-04-02 15:46 2% ` [dpdk-dev] [PATCH v9 0/1] Introduce " Xiaolong Ye
@ 2019-04-02 15:46 2% ` Xiaolong Ye
0 siblings, 0 replies; 200+ results
From: Xiaolong Ye @ 2019-04-02 15:46 UTC (permalink / raw)
To: dev, Stephen Hemminger, Ferruh Yigit
Cc: Qi Zhang, Karlsson Magnus, Topel Bjorn, Maxime Coquelin,
Luca Boccassi, Bruce Richardson, Ananyev Konstantin,
David Marchand, Andrew Rybchenko, Olivier Matz, Xiaolong Ye
Overview
========
This patchset adds a new PMD driver for AF_XDP which is a proposed
faster version of AF_PACKET interface in Linux, see below links [1] [2] for
details of AF_XDP introduction:
AF_XDP roadmap
==============
- AF_XDP is included in upstream kernel since 4.18, and AF_XDP support
in libbpf has been merged in v5.1-rc1.
- Now i40e and ixgbe drivers have supported zero copy mode.
Change logs
===========
V9:
- adjust header files order according to Stephen's suggestion
v8:
- address Ferruh's comments on V7
- replace posix_memalign with rte_memzone_reserve_aligned to get better
performance
- keep the first patch only as Oliver suggested as zero copy part
implementation is still in suspense, we may provide the related patch
later.
v7:
- mention mtu limitation in af_xdp.rst
- fix the vdev name in af_xdp.rst
V6:
- remove the newline in AF_XDP_LOG definition to avoid double new lines
issue.
- rename MEMPOOL_F_PAGE_ALIGN to MEMPOOL_CHUNK_F_PAGE_ALIGN.
V5:
- disable AF_XDP pmd by default due to it requires kernel more recent
than minimum kernel version supported by DPDK
- address other review comments of Maxime
V4:
- change vdev name to net_af_xdp
- adopt dynamic log type for all logging
- Fix other style issues raised by Stephen
V3:
- Fix all style issues pointed by Stephen, Mattias, David.
- Drop the testpmd change as we'll adopt Jerin's suggestion to add a new
mempool driver to handle the application use of AF_XDP's zero copy feature.
V2:
- Fix a NULL pointer reference crash issue
- Fix txonly stop sending traffic in zc mode
- Refactor rte_mbuf.c to avoid ABI breakage.
- Fix multiple style issues pointed by Ferruh, David, Stephen, Luca.
changes vs RFC sent by Qi last Aug:
- Re-work base on AF_XDP's interface changes since the new libbpf has
provided higher-level APIs that hide many of the details of the AP_XDP
uapi. After the rework, it helps to reduce 300+ lines of code.
- multi-queues is not supported due to current libbpf doesn't support
multi-sockets on a single umem.
- No extra steps to load xdp program manually, since the current behavior of
libbpf would load a default xdp program when user calls xsk_socket__create.
userspace application only needs to handle the cleanup.
How to try
==========
1. take the kernel >= v5.1-rc1, build kernel and replace your host
kernel with it.
make sure you turn on XDP sockets when compiling
Networking support -->
Networking options -->
[ * ] XDP sockets
2. build libbpf in tools/lib/bpf, and copy the libbpf.a and libbpf.so to /usr/lib64
cd tools/lib/bpf
make
3. ethtool -L enp59s0f0 combined 1
4. extra step to build dpdk
explicitly enable AF_XDP pmd by adding below line to
config/common_linux
CONFIG_RTE_LIBRTE_PMD_AF_XDP=y
5. start testpmd
./build/app/testpmd -c 0xc -n 4 --vdev net_af_xdp,iface=enp59s0f0,queue=0 -- -i --rxq=1 --txq=1
in this case, default xdp program will be loaded and linked to queue 0 of enp59s0f0,
network traffics travel to queue 0 will be redirected to af_xdp socket.
Xiaolong Ye (1):
net/af_xdp: introduce AF XDP PMD driver
MAINTAINERS | 7 +
config/common_base | 5 +
doc/guides/nics/af_xdp.rst | 48 +
doc/guides/nics/features/af_xdp.ini | 11 +
doc/guides/nics/index.rst | 1 +
doc/guides/rel_notes/release_19_05.rst | 7 +
drivers/net/Makefile | 1 +
drivers/net/af_xdp/Makefile | 32 +
drivers/net/af_xdp/meson.build | 21 +
drivers/net/af_xdp/rte_eth_af_xdp.c | 956 ++++++++++++++++++
drivers/net/af_xdp/rte_pmd_af_xdp_version.map | 3 +
drivers/net/meson.build | 1 +
mk/rte.app.mk | 1 +
13 files changed, 1094 insertions(+)
create mode 100644 doc/guides/nics/af_xdp.rst
create mode 100644 doc/guides/nics/features/af_xdp.ini
create mode 100644 drivers/net/af_xdp/Makefile
create mode 100644 drivers/net/af_xdp/meson.build
create mode 100644 drivers/net/af_xdp/rte_eth_af_xdp.c
create mode 100644 drivers/net/af_xdp/rte_pmd_af_xdp_version.map
--
2.17.1
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [pull-request] next-crypto 19.05 rc1
@ 2019-04-02 16:08 2% Akhil Goyal
2019-04-02 16:08 2% ` Akhil Goyal
0 siblings, 1 reply; 200+ results
From: Akhil Goyal @ 2019-04-02 16:08 UTC (permalink / raw)
To: thomas; +Cc: dev
The following changes since commit dfc6b2fd8da344095567c53f3e087cae3b4690b9:
mbuf: remove Intel offload checks from generic API (2019-04-02 16:42:52 +0200)
are available in the Git repository at:
http://dpdk.org/git/next/dpdk-next-crypto
for you to fetch changes up to 56e837a425a41a1e095cc29a156130e08d68813c:
doc: add ipsec lib into shared libraries list (2019-04-02 20:20:24 +0530)
----------------------------------------------------------------
Akhil Goyal (6):
crypto/dpaa2_sec: fix session clear
crypto/dpaa2_sec: fix offset calculation for gcm
drivers/crypto: update inline desc for sharing mode
crypto/dpaa2_sec: remove unnecessary flc configurations
crypto/dpaa_sec: fix session qp attach/detach
crypto/dpaa2_sec: support multi process
Anoob Joseph (1):
doc: announce ABI change for cryptodev config
Arek Kusztal (4):
common/qat: add headers for asymmetric crypto
crypto/qat: add asymmetric cryptography PMD
crypto/qat: add modular exponentiation for asym
crypto/qat: add modular inverse for asym
Ayuj Verma (3):
cryptodev: add rsa priv key feature flag
crypto/openssl: set rsa private op feature flag
test/crypto: check for key type ff in asym unit test
Damian Nowak (1):
test: new test structure for asymmetric crypto
Fan Zhang (3):
crypto/aesni_mb: enable out of place processing
test: add out of place test for AESNI-MB
crypto/aesni_mb: support newer version library only
Konstantin Ananyev (12):
examples/ipsec-secgw: fix invalid out-of-bound check
examples/ipsec_secgw: fix possible NULL dereference
examples/ipsec-secgw: fix typo in test script
mbuf: new function to generate raw Tx offload value
ipsec: add Tx offload template into SA
ipsec: change the order in filling crypto op
ipsec: change the way unprocessed mbufs are accounted
ipsec: move inbound and outbound code into different files
ipsec: reorder packet check for esp inbound
ipsec: reorder packet process for esp inbound
ipsec: de-duplicate crypto op prepare code-path
doc: add ipsec lib into shared libraries list
Lee Daly (1):
compress/isal: add appropriate flag on overflow
Lukasz Krakowiak (1):
test: add snow3g test cases when digest is encrypted
Tomasz Cel (2):
compress/isal: fix compression stream initialization
compress/isal: fix getting information about CPU
Tomasz Jozwiak (3):
compress/qat: add dynamic sgl allocation
drivers/qat: fix qp numa node
app/compress-perf: add incompressible data handling
app/test-compress-perf/comp_perf_options.h | 5 +
app/test-compress-perf/comp_perf_options_parse.c | 11 +-
app/test-compress-perf/comp_perf_test_benchmark.c | 9 +-
app/test-compress-perf/comp_perf_test_verify.c | 9 +-
app/test-compress-perf/main.c | 34 +-
app/test/test_cryptodev.c | 91 +-
app/test/test_cryptodev.h | 1 +
app/test/test_cryptodev_aes_test_vectors.h | 110 +-
app/test/test_cryptodev_asym.c | 344 +++++
app/test/test_cryptodev_blockcipher.c | 83 +-
app/test/test_cryptodev_blockcipher.h | 3 +
app/test/test_cryptodev_des_test_vectors.h | 24 +-
app/test/test_cryptodev_mod_test_vectors.h | 967 ++++++++++++
app/test/test_cryptodev_snow3g_test_vectors.h | 132 +-
app/test/test_mbuf.c | 101 +-
config/common_base | 2 +-
doc/guides/compressdevs/qat_comp.rst | 1 -
doc/guides/cryptodevs/aesni_mb.rst | 8 +-
doc/guides/cryptodevs/features/aesni_mb.ini | 1 +
doc/guides/cryptodevs/features/default.ini | 2 +
doc/guides/cryptodevs/features/openssl.ini | 2 +
doc/guides/cryptodevs/overview.rst | 6 +
doc/guides/cryptodevs/qat.rst | 15 +-
doc/guides/rel_notes/deprecation.rst | 15 +-
doc/guides/rel_notes/release_19_05.rst | 5 +
drivers/bus/fslmc/portal/dpaa2_hw_pvt.h | 2 +-
drivers/common/qat/Makefile | 8 +
drivers/common/qat/qat_adf/icp_qat_fw_mmp_ids.h | 1538 ++++++++++++++++++++
drivers/common/qat/qat_adf/icp_qat_fw_pke.h | 426 ++++++
.../qat/qat_adf/qat_pke_functionality_arrays.h | 52 +
drivers/common/qat/qat_device.h | 12 +-
drivers/common/qat/qat_qp.c | 22 +-
drivers/compress/isal/isal_compress_pmd.c | 26 +-
drivers/compress/isal/isal_compress_pmd_ops.c | 16 +-
drivers/compress/qat/qat_comp.c | 58 +-
drivers/compress/qat/qat_comp.h | 14 +-
drivers/compress/qat/qat_comp_pmd.c | 58 +-
drivers/crypto/aesni_mb/Makefile | 21 +-
drivers/crypto/aesni_mb/aesni_mb_ops.h | 302 ----
drivers/crypto/aesni_mb/meson.build | 13 +-
drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 102 +-
drivers/crypto/aesni_mb/rte_aesni_mb_pmd_compat.c | 1313 -----------------
.../crypto/aesni_mb/rte_aesni_mb_pmd_ops_compat.c | 745 ----------
drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h | 37 -
drivers/crypto/caam_jr/caam_jr.c | 13 +-
drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c | 74 +-
drivers/crypto/dpaa2_sec/hw/desc/algo.h | 18 +-
drivers/crypto/dpaa2_sec/hw/desc/ipsec.h | 10 +-
drivers/crypto/dpaa_sec/dpaa_sec.c | 27 +-
drivers/crypto/openssl/rte_openssl_pmd.c | 4 +-
drivers/crypto/qat/meson.build | 5 +-
drivers/crypto/qat/qat_asym.c | 420 ++++++
drivers/crypto/qat/qat_asym.h | 106 ++
drivers/crypto/qat/qat_asym_capabilities.h | 42 +
drivers/crypto/qat/qat_asym_pmd.c | 309 ++++
drivers/crypto/qat/qat_asym_pmd.h | 50 +
drivers/crypto/qat/qat_sym_pmd.c | 1 -
drivers/crypto/qat/qat_sym_pmd.h | 3 +-
examples/ipsec-secgw/ipsec-secgw.c | 2 +-
examples/ipsec-secgw/ipsec_process.c | 11 +-
examples/ipsec-secgw/test/run_test.sh | 2 +-
lib/librte_cryptodev/rte_cryptodev.c | 4 +
lib/librte_cryptodev/rte_cryptodev.h | 4 +
lib/librte_ipsec/Makefile | 2 +
lib/librte_ipsec/crypto.h | 17 +
lib/librte_ipsec/esp_inb.c | 547 +++++++
lib/librte_ipsec/esp_outb.c | 580 ++++++++
lib/librte_ipsec/ipsec_sqn.h | 34 -
lib/librte_ipsec/meson.build | 2 +-
lib/librte_ipsec/misc.h | 41 +
lib/librte_ipsec/sa.c | 1072 +-------------
lib/librte_ipsec/sa.h | 45 +
lib/librte_mbuf/rte_mbuf.h | 101 +-
mk/rte.app.mk | 1 +
74 files changed, 6584 insertions(+), 3709 deletions(-)
create mode 100644 drivers/common/qat/qat_adf/icp_qat_fw_mmp_ids.h
create mode 100644 drivers/common/qat/qat_adf/icp_qat_fw_pke.h
create mode 100644 drivers/common/qat/qat_adf/qat_pke_functionality_arrays.h
delete mode 100644 drivers/crypto/aesni_mb/aesni_mb_ops.h
delete mode 100644 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_compat.c
delete mode 100644 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops_compat.c
create mode 100644 drivers/crypto/qat/qat_asym.c
create mode 100644 drivers/crypto/qat/qat_asym.h
create mode 100644 drivers/crypto/qat/qat_asym_capabilities.h
create mode 100644 drivers/crypto/qat/qat_asym_pmd.c
create mode 100644 drivers/crypto/qat/qat_asym_pmd.h
create mode 100644 lib/librte_ipsec/esp_inb.c
create mode 100644 lib/librte_ipsec/esp_outb.c
create mode 100644 lib/librte_ipsec/misc.h
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [pull-request] next-crypto 19.05 rc1
2019-04-02 16:08 2% [dpdk-dev] [pull-request] next-crypto 19.05 rc1 Akhil Goyal
@ 2019-04-02 16:08 2% ` Akhil Goyal
0 siblings, 0 replies; 200+ results
From: Akhil Goyal @ 2019-04-02 16:08 UTC (permalink / raw)
To: thomas; +Cc: dev
The following changes since commit dfc6b2fd8da344095567c53f3e087cae3b4690b9:
mbuf: remove Intel offload checks from generic API (2019-04-02 16:42:52 +0200)
are available in the Git repository at:
http://dpdk.org/git/next/dpdk-next-crypto
for you to fetch changes up to 56e837a425a41a1e095cc29a156130e08d68813c:
doc: add ipsec lib into shared libraries list (2019-04-02 20:20:24 +0530)
----------------------------------------------------------------
Akhil Goyal (6):
crypto/dpaa2_sec: fix session clear
crypto/dpaa2_sec: fix offset calculation for gcm
drivers/crypto: update inline desc for sharing mode
crypto/dpaa2_sec: remove unnecessary flc configurations
crypto/dpaa_sec: fix session qp attach/detach
crypto/dpaa2_sec: support multi process
Anoob Joseph (1):
doc: announce ABI change for cryptodev config
Arek Kusztal (4):
common/qat: add headers for asymmetric crypto
crypto/qat: add asymmetric cryptography PMD
crypto/qat: add modular exponentiation for asym
crypto/qat: add modular inverse for asym
Ayuj Verma (3):
cryptodev: add rsa priv key feature flag
crypto/openssl: set rsa private op feature flag
test/crypto: check for key type ff in asym unit test
Damian Nowak (1):
test: new test structure for asymmetric crypto
Fan Zhang (3):
crypto/aesni_mb: enable out of place processing
test: add out of place test for AESNI-MB
crypto/aesni_mb: support newer version library only
Konstantin Ananyev (12):
examples/ipsec-secgw: fix invalid out-of-bound check
examples/ipsec_secgw: fix possible NULL dereference
examples/ipsec-secgw: fix typo in test script
mbuf: new function to generate raw Tx offload value
ipsec: add Tx offload template into SA
ipsec: change the order in filling crypto op
ipsec: change the way unprocessed mbufs are accounted
ipsec: move inbound and outbound code into different files
ipsec: reorder packet check for esp inbound
ipsec: reorder packet process for esp inbound
ipsec: de-duplicate crypto op prepare code-path
doc: add ipsec lib into shared libraries list
Lee Daly (1):
compress/isal: add appropriate flag on overflow
Lukasz Krakowiak (1):
test: add snow3g test cases when digest is encrypted
Tomasz Cel (2):
compress/isal: fix compression stream initialization
compress/isal: fix getting information about CPU
Tomasz Jozwiak (3):
compress/qat: add dynamic sgl allocation
drivers/qat: fix qp numa node
app/compress-perf: add incompressible data handling
app/test-compress-perf/comp_perf_options.h | 5 +
app/test-compress-perf/comp_perf_options_parse.c | 11 +-
app/test-compress-perf/comp_perf_test_benchmark.c | 9 +-
app/test-compress-perf/comp_perf_test_verify.c | 9 +-
app/test-compress-perf/main.c | 34 +-
app/test/test_cryptodev.c | 91 +-
app/test/test_cryptodev.h | 1 +
app/test/test_cryptodev_aes_test_vectors.h | 110 +-
app/test/test_cryptodev_asym.c | 344 +++++
app/test/test_cryptodev_blockcipher.c | 83 +-
app/test/test_cryptodev_blockcipher.h | 3 +
app/test/test_cryptodev_des_test_vectors.h | 24 +-
app/test/test_cryptodev_mod_test_vectors.h | 967 ++++++++++++
app/test/test_cryptodev_snow3g_test_vectors.h | 132 +-
app/test/test_mbuf.c | 101 +-
config/common_base | 2 +-
doc/guides/compressdevs/qat_comp.rst | 1 -
doc/guides/cryptodevs/aesni_mb.rst | 8 +-
doc/guides/cryptodevs/features/aesni_mb.ini | 1 +
doc/guides/cryptodevs/features/default.ini | 2 +
doc/guides/cryptodevs/features/openssl.ini | 2 +
doc/guides/cryptodevs/overview.rst | 6 +
doc/guides/cryptodevs/qat.rst | 15 +-
doc/guides/rel_notes/deprecation.rst | 15 +-
doc/guides/rel_notes/release_19_05.rst | 5 +
drivers/bus/fslmc/portal/dpaa2_hw_pvt.h | 2 +-
drivers/common/qat/Makefile | 8 +
drivers/common/qat/qat_adf/icp_qat_fw_mmp_ids.h | 1538 ++++++++++++++++++++
drivers/common/qat/qat_adf/icp_qat_fw_pke.h | 426 ++++++
.../qat/qat_adf/qat_pke_functionality_arrays.h | 52 +
drivers/common/qat/qat_device.h | 12 +-
drivers/common/qat/qat_qp.c | 22 +-
drivers/compress/isal/isal_compress_pmd.c | 26 +-
drivers/compress/isal/isal_compress_pmd_ops.c | 16 +-
drivers/compress/qat/qat_comp.c | 58 +-
drivers/compress/qat/qat_comp.h | 14 +-
drivers/compress/qat/qat_comp_pmd.c | 58 +-
drivers/crypto/aesni_mb/Makefile | 21 +-
drivers/crypto/aesni_mb/aesni_mb_ops.h | 302 ----
drivers/crypto/aesni_mb/meson.build | 13 +-
drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 102 +-
drivers/crypto/aesni_mb/rte_aesni_mb_pmd_compat.c | 1313 -----------------
.../crypto/aesni_mb/rte_aesni_mb_pmd_ops_compat.c | 745 ----------
drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h | 37 -
drivers/crypto/caam_jr/caam_jr.c | 13 +-
drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c | 74 +-
drivers/crypto/dpaa2_sec/hw/desc/algo.h | 18 +-
drivers/crypto/dpaa2_sec/hw/desc/ipsec.h | 10 +-
drivers/crypto/dpaa_sec/dpaa_sec.c | 27 +-
drivers/crypto/openssl/rte_openssl_pmd.c | 4 +-
drivers/crypto/qat/meson.build | 5 +-
drivers/crypto/qat/qat_asym.c | 420 ++++++
drivers/crypto/qat/qat_asym.h | 106 ++
drivers/crypto/qat/qat_asym_capabilities.h | 42 +
drivers/crypto/qat/qat_asym_pmd.c | 309 ++++
drivers/crypto/qat/qat_asym_pmd.h | 50 +
drivers/crypto/qat/qat_sym_pmd.c | 1 -
drivers/crypto/qat/qat_sym_pmd.h | 3 +-
examples/ipsec-secgw/ipsec-secgw.c | 2 +-
examples/ipsec-secgw/ipsec_process.c | 11 +-
examples/ipsec-secgw/test/run_test.sh | 2 +-
lib/librte_cryptodev/rte_cryptodev.c | 4 +
lib/librte_cryptodev/rte_cryptodev.h | 4 +
lib/librte_ipsec/Makefile | 2 +
lib/librte_ipsec/crypto.h | 17 +
lib/librte_ipsec/esp_inb.c | 547 +++++++
lib/librte_ipsec/esp_outb.c | 580 ++++++++
lib/librte_ipsec/ipsec_sqn.h | 34 -
lib/librte_ipsec/meson.build | 2 +-
lib/librte_ipsec/misc.h | 41 +
lib/librte_ipsec/sa.c | 1072 +-------------
lib/librte_ipsec/sa.h | 45 +
lib/librte_mbuf/rte_mbuf.h | 101 +-
mk/rte.app.mk | 1 +
74 files changed, 6584 insertions(+), 3709 deletions(-)
create mode 100644 drivers/common/qat/qat_adf/icp_qat_fw_mmp_ids.h
create mode 100644 drivers/common/qat/qat_adf/icp_qat_fw_pke.h
create mode 100644 drivers/common/qat/qat_adf/qat_pke_functionality_arrays.h
delete mode 100644 drivers/crypto/aesni_mb/aesni_mb_ops.h
delete mode 100644 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_compat.c
delete mode 100644 drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops_compat.c
create mode 100644 drivers/crypto/qat/qat_asym.c
create mode 100644 drivers/crypto/qat/qat_asym.h
create mode 100644 drivers/crypto/qat/qat_asym_capabilities.h
create mode 100644 drivers/crypto/qat/qat_asym_pmd.c
create mode 100644 drivers/crypto/qat/qat_asym_pmd.h
create mode 100644 lib/librte_ipsec/esp_inb.c
create mode 100644 lib/librte_ipsec/esp_outb.c
create mode 100644 lib/librte_ipsec/misc.h
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [PATCH v2 1/3] rte_ethdev: Add API function to read dev clock
@ 2019-04-02 17:46 3% ` Ferruh Yigit
2019-04-02 17:46 3% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2019-04-02 17:46 UTC (permalink / raw)
To: Tom Barbette, dev
Cc: bruce.richardson, john.mcnamara, Thomas Monjalon,
Andrew Rybchenko, Shahaf Shuler, Yongseok Koh, Olivier MATZ
On 3/27/2019 6:19 AM, Tom Barbette wrote:
> Add rte_eth_read_clock to read the raw clock of a devide.
>
> The main use is to get the device clock conversion co-efficients to be
> able to translate the raw clock of the timestamp field of the pkt mbuf
> to a local synced time value.
>
> This function was missing to allow users to convert the RX timestamp field
> to real time without the complexity of the rte_timesync* facility. One can
> derivate the clock frequency by calling twice read_clock and then keep a
> common time base.
>
> Signed-off-by: Tom Barbette <barbette@kth.se>
> ---
> doc/guides/nics/features.rst | 1 +
> lib/librte_ethdev/rte_ethdev.c | 13 +++++++
> lib/librte_ethdev/rte_ethdev.h | 44 ++++++++++++++++++++++++
> lib/librte_ethdev/rte_ethdev_core.h | 6 ++++
> lib/librte_ethdev/rte_ethdev_version.map | 1 +
> lib/librte_mbuf/rte_mbuf.h | 2 ++
> 6 files changed, 67 insertions(+)
>
> diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
> index c5bf32222..1e6adfb0b 100644
> --- a/doc/guides/nics/features.rst
> +++ b/doc/guides/nics/features.rst
> @@ -602,6 +602,7 @@ Supports Timestamp.
> * **[provides] mbuf**: ``mbuf.ol_flags:PKT_RX_TIMESTAMP``.
> * **[provides] mbuf**: ``mbuf.timestamp``.
> * **[provides] rte_eth_dev_info**: ``rx_offload_capa,rx_queue_offload_capa: DEV_RX_OFFLOAD_TIMESTAMP``.
> +* **[implements] eth_dev_ops**: ``read_clock``.
This means for a PMD to claim 'timestamp' support, it should implement the
'read_clock' dev_ops, is it really the case?
Should we say 'related' instead of 'implements' ?
>
> .. _nic_features_macsec_offload:
>
> diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
> index 85c179496..7de0f35b5 100644
> --- a/lib/librte_ethdev/rte_ethdev.c
> +++ b/lib/librte_ethdev/rte_ethdev.c
> @@ -4127,6 +4127,19 @@ rte_eth_timesync_write_time(uint16_t port_id, const struct timespec *timestamp)
> timestamp));
> }
>
> +int
> +rte_eth_read_clock(uint16_t port_id, uint64_t *timestamp)
> +{
> + struct rte_eth_dev *dev;
> +
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> + dev = &rte_eth_devices[port_id];
> +
> + RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->read_clock, -ENOTSUP);
> + return eth_err(port_id, (*dev->dev_ops->read_clock)(dev,
> + timestamp));
Please fix the syntax.
> +}
> +
> int
> rte_eth_dev_get_reg_info(uint16_t port_id, struct rte_dev_reg_info *info)
> {
> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
> index a3c864a13..e254da8b1 100644
> --- a/lib/librte_ethdev/rte_ethdev.h
> +++ b/lib/librte_ethdev/rte_ethdev.h
> @@ -3642,6 +3642,50 @@ int rte_eth_timesync_read_time(uint16_t port_id, struct timespec *time);
> */
> int rte_eth_timesync_write_time(uint16_t port_id, const struct timespec *time);
>
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Read the current clock counter of an Ethernet device
> + *
> + * This returns the current raw clock value of an Ethernet device.
> + * The value returned here is from the same clock than the one
> + * filling timestamp field of RX packets. Therefore it can be used
> + * to compute a precise conversion of the device clock to the real time.
> + *
> + * E.g, a simple heuristic to derivate the frequency would be:
> + * uint64_t start, end;
> + * rte_eth_read_clock(port, start);
> + * rte_delay_ms(100);
> + * rte_eth_read_clock(port, end);
> + * double freq = (end - start) * 10;
> + *
> + * Compute a common reference with:
> + * uint64_t base_time_sec = current_time();
> + * uint64_t base_clock;
> + * rte_eth_read_clock(port, base_clock);
> + *
> + * Then, convert the raw mbuf timestamp with:
> + * base_time_sec + (double)(mbuf->timestamp - base_clock) / freq;
> + *
> + * This simple example will not provide a very good accuracy. One must
> + * at least measure multiple times the frequency and do a regression.
> + * To avoid deviation from the system time, the common reference can
> + * be repeated from time to time. The integer division can also be
> + * converted by a multiplication and a shift for better performance.
> + *
> + * @param port_id
> + * The port identifier of the Ethernet device.
> + * @param time
> + * Pointer to the uint64_t that holds the raw clock value.
> + *
> + * @return
> + * - 0: Success.
> + * - -ENODEV: The port ID is invalid.
> + * - -ENOTSUP: The function is not supported by the Ethernet driver.
Can PMD return a fail?
> + */
> +int __rte_experimental rte_eth_read_clock(uint16_t port_id, uint64_t *time);
s/time/timestamp to match implementation param name, (reminder of updating
doxygen when this updated)
And I can see both syntax in use currently, but I think specially with
__rte_experimental tag, it looks cleaner to me as following:
int __rte_experimental
rte_eth_read_clock(uint16_t port_id, uint64_t *timestamp);
> +
> /**
> * Config l2 tunnel ether type of an Ethernet device for filtering specific
> * tunnel packets by ether type.
> diff --git a/lib/librte_ethdev/rte_ethdev_core.h b/lib/librte_ethdev/rte_ethdev_core.h
> index 8f03f83f6..86806b3eb 100644
> --- a/lib/librte_ethdev/rte_ethdev_core.h
> +++ b/lib/librte_ethdev/rte_ethdev_core.h
> @@ -322,6 +322,10 @@ typedef int (*eth_timesync_write_time)(struct rte_eth_dev *dev,
> const struct timespec *timestamp);
> /**< @internal Function used to get time from the device clock */
>
> +typedef int (*eth_read_clock)(struct rte_eth_dev *dev,
> + uint64_t *timestamp);
> +/**< @internal Function used to get the current value of the device clock. */
> +
> typedef int (*eth_get_reg_t)(struct rte_eth_dev *dev,
> struct rte_dev_reg_info *info);
> /**< @internal Retrieve registers */
> @@ -496,6 +500,8 @@ struct eth_dev_ops {
> eth_timesync_read_time timesync_read_time; /** Get the device clock time. */
> eth_timesync_write_time timesync_write_time; /** Set the device clock time. */
>
> + eth_read_clock read_clock;
> +
Isn't this ABI breakage?
I guess it can be OK since we already increasing the ethdev ABIVER this version,
any comments?
> eth_xstats_get_by_id_t xstats_get_by_id;
> /**< Get extended device statistic values by ID. */
> eth_xstats_get_names_by_id_t xstats_get_names_by_id;
> diff --git a/lib/librte_ethdev/rte_ethdev_version.map b/lib/librte_ethdev/rte_ethdev_version.map
> index 92ac3de25..12d6c3c1d 100644
> --- a/lib/librte_ethdev/rte_ethdev_version.map
> +++ b/lib/librte_ethdev/rte_ethdev_version.map
> @@ -249,6 +249,7 @@ EXPERIMENTAL {
> rte_eth_switch_domain_free;
> rte_flow_conv;
> rte_flow_expand_rss;
> + rte_eth_read_clock;
Can you please put this alphabetically sorted?
> rte_mtr_capabilities_get;
> rte_mtr_create;
> rte_mtr_destroy;
> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> index d961ccaf6..dd55b942c 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -619,6 +619,8 @@ struct rte_mbuf {
>
> /** Valid if PKT_RX_TIMESTAMP is set. The unit and time reference
> * are not normalized but are always the same for a given port.
> + * Some devices allow to query rte_eth_read_clock that will return the
> + * current device timestamp.
cc'ed Olivier.
> */
> uint64_t timestamp;
>
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2 1/3] rte_ethdev: Add API function to read dev clock
2019-04-02 17:46 3% ` Ferruh Yigit
@ 2019-04-02 17:46 3% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-04-02 17:46 UTC (permalink / raw)
To: Tom Barbette, dev
Cc: bruce.richardson, john.mcnamara, Thomas Monjalon,
Andrew Rybchenko, Shahaf Shuler, Yongseok Koh, Olivier MATZ
On 3/27/2019 6:19 AM, Tom Barbette wrote:
> Add rte_eth_read_clock to read the raw clock of a devide.
>
> The main use is to get the device clock conversion co-efficients to be
> able to translate the raw clock of the timestamp field of the pkt mbuf
> to a local synced time value.
>
> This function was missing to allow users to convert the RX timestamp field
> to real time without the complexity of the rte_timesync* facility. One can
> derivate the clock frequency by calling twice read_clock and then keep a
> common time base.
>
> Signed-off-by: Tom Barbette <barbette@kth.se>
> ---
> doc/guides/nics/features.rst | 1 +
> lib/librte_ethdev/rte_ethdev.c | 13 +++++++
> lib/librte_ethdev/rte_ethdev.h | 44 ++++++++++++++++++++++++
> lib/librte_ethdev/rte_ethdev_core.h | 6 ++++
> lib/librte_ethdev/rte_ethdev_version.map | 1 +
> lib/librte_mbuf/rte_mbuf.h | 2 ++
> 6 files changed, 67 insertions(+)
>
> diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
> index c5bf32222..1e6adfb0b 100644
> --- a/doc/guides/nics/features.rst
> +++ b/doc/guides/nics/features.rst
> @@ -602,6 +602,7 @@ Supports Timestamp.
> * **[provides] mbuf**: ``mbuf.ol_flags:PKT_RX_TIMESTAMP``.
> * **[provides] mbuf**: ``mbuf.timestamp``.
> * **[provides] rte_eth_dev_info**: ``rx_offload_capa,rx_queue_offload_capa: DEV_RX_OFFLOAD_TIMESTAMP``.
> +* **[implements] eth_dev_ops**: ``read_clock``.
This means for a PMD to claim 'timestamp' support, it should implement the
'read_clock' dev_ops, is it really the case?
Should we say 'related' instead of 'implements' ?
>
> .. _nic_features_macsec_offload:
>
> diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
> index 85c179496..7de0f35b5 100644
> --- a/lib/librte_ethdev/rte_ethdev.c
> +++ b/lib/librte_ethdev/rte_ethdev.c
> @@ -4127,6 +4127,19 @@ rte_eth_timesync_write_time(uint16_t port_id, const struct timespec *timestamp)
> timestamp));
> }
>
> +int
> +rte_eth_read_clock(uint16_t port_id, uint64_t *timestamp)
> +{
> + struct rte_eth_dev *dev;
> +
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> + dev = &rte_eth_devices[port_id];
> +
> + RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->read_clock, -ENOTSUP);
> + return eth_err(port_id, (*dev->dev_ops->read_clock)(dev,
> + timestamp));
Please fix the syntax.
> +}
> +
> int
> rte_eth_dev_get_reg_info(uint16_t port_id, struct rte_dev_reg_info *info)
> {
> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
> index a3c864a13..e254da8b1 100644
> --- a/lib/librte_ethdev/rte_ethdev.h
> +++ b/lib/librte_ethdev/rte_ethdev.h
> @@ -3642,6 +3642,50 @@ int rte_eth_timesync_read_time(uint16_t port_id, struct timespec *time);
> */
> int rte_eth_timesync_write_time(uint16_t port_id, const struct timespec *time);
>
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice.
> + *
> + * Read the current clock counter of an Ethernet device
> + *
> + * This returns the current raw clock value of an Ethernet device.
> + * The value returned here is from the same clock than the one
> + * filling timestamp field of RX packets. Therefore it can be used
> + * to compute a precise conversion of the device clock to the real time.
> + *
> + * E.g, a simple heuristic to derivate the frequency would be:
> + * uint64_t start, end;
> + * rte_eth_read_clock(port, start);
> + * rte_delay_ms(100);
> + * rte_eth_read_clock(port, end);
> + * double freq = (end - start) * 10;
> + *
> + * Compute a common reference with:
> + * uint64_t base_time_sec = current_time();
> + * uint64_t base_clock;
> + * rte_eth_read_clock(port, base_clock);
> + *
> + * Then, convert the raw mbuf timestamp with:
> + * base_time_sec + (double)(mbuf->timestamp - base_clock) / freq;
> + *
> + * This simple example will not provide a very good accuracy. One must
> + * at least measure multiple times the frequency and do a regression.
> + * To avoid deviation from the system time, the common reference can
> + * be repeated from time to time. The integer division can also be
> + * converted by a multiplication and a shift for better performance.
> + *
> + * @param port_id
> + * The port identifier of the Ethernet device.
> + * @param time
> + * Pointer to the uint64_t that holds the raw clock value.
> + *
> + * @return
> + * - 0: Success.
> + * - -ENODEV: The port ID is invalid.
> + * - -ENOTSUP: The function is not supported by the Ethernet driver.
Can PMD return a fail?
> + */
> +int __rte_experimental rte_eth_read_clock(uint16_t port_id, uint64_t *time);
s/time/timestamp to match implementation param name, (reminder of updating
doxygen when this updated)
And I can see both syntax in use currently, but I think specially with
__rte_experimental tag, it looks cleaner to me as following:
int __rte_experimental
rte_eth_read_clock(uint16_t port_id, uint64_t *timestamp);
> +
> /**
> * Config l2 tunnel ether type of an Ethernet device for filtering specific
> * tunnel packets by ether type.
> diff --git a/lib/librte_ethdev/rte_ethdev_core.h b/lib/librte_ethdev/rte_ethdev_core.h
> index 8f03f83f6..86806b3eb 100644
> --- a/lib/librte_ethdev/rte_ethdev_core.h
> +++ b/lib/librte_ethdev/rte_ethdev_core.h
> @@ -322,6 +322,10 @@ typedef int (*eth_timesync_write_time)(struct rte_eth_dev *dev,
> const struct timespec *timestamp);
> /**< @internal Function used to get time from the device clock */
>
> +typedef int (*eth_read_clock)(struct rte_eth_dev *dev,
> + uint64_t *timestamp);
> +/**< @internal Function used to get the current value of the device clock. */
> +
> typedef int (*eth_get_reg_t)(struct rte_eth_dev *dev,
> struct rte_dev_reg_info *info);
> /**< @internal Retrieve registers */
> @@ -496,6 +500,8 @@ struct eth_dev_ops {
> eth_timesync_read_time timesync_read_time; /** Get the device clock time. */
> eth_timesync_write_time timesync_write_time; /** Set the device clock time. */
>
> + eth_read_clock read_clock;
> +
Isn't this ABI breakage?
I guess it can be OK since we already increasing the ethdev ABIVER this version,
any comments?
> eth_xstats_get_by_id_t xstats_get_by_id;
> /**< Get extended device statistic values by ID. */
> eth_xstats_get_names_by_id_t xstats_get_names_by_id;
> diff --git a/lib/librte_ethdev/rte_ethdev_version.map b/lib/librte_ethdev/rte_ethdev_version.map
> index 92ac3de25..12d6c3c1d 100644
> --- a/lib/librte_ethdev/rte_ethdev_version.map
> +++ b/lib/librte_ethdev/rte_ethdev_version.map
> @@ -249,6 +249,7 @@ EXPERIMENTAL {
> rte_eth_switch_domain_free;
> rte_flow_conv;
> rte_flow_expand_rss;
> + rte_eth_read_clock;
Can you please put this alphabetically sorted?
> rte_mtr_capabilities_get;
> rte_mtr_create;
> rte_mtr_destroy;
> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> index d961ccaf6..dd55b942c 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -619,6 +619,8 @@ struct rte_mbuf {
>
> /** Valid if PKT_RX_TIMESTAMP is set. The unit and time reference
> * are not normalized but are always the same for a given port.
> + * Some devices allow to query rte_eth_read_clock that will return the
> + * current device timestamp.
cc'ed Olivier.
> */
> uint64_t timestamp;
>
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2] eal: rename state values in rte_lcore_state
@ 2019-04-02 21:07 4% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-04-02 21:07 UTC (permalink / raw)
To: David Marchand; +Cc: dev
On Tue, 2 Apr 2019 23:03:06 +0200
David Marchand <david.marchand@redhat.com> wrote:
> On Tue, Apr 2, 2019 at 10:48 PM Stephen Hemminger <
> stephen@networkplumber.org> wrote:
>
> > On Tue, 2 Apr 2019 22:15:40 +0200
> > David Marchand <david.marchand@redhat.com> wrote:
> >
> > > On Tue, Apr 2, 2019 at 5:57 PM Stephen Hemminger <
> > stephen@networkplumber.org>
> > > wrote:
> > >
> > > > C language does not really treat enum's as first class symbols.
> > > > The values in an enum live in a global namespace. That means if
> > > > DPDK defines "RUNNING" it can't be used by another enum in an
> > > > application using DPDK.
> > > >
> > > > To solve this add a prefix "RTE_LCORE_" to the enum values, and
> > > > make them grammatically consistent.
> > > >
> > >
> > > Well, I understand this is not clean, but this patch breaks the API.
> >
> > The lcore state was marked as internal in the header file, code that
> > ignores that is going to have problems. The values are the same.
> >
> > We could defer this to 19.11 (next LTS) since it is cosmetic.
> >
>
> We must announce it before changing.
I disagree, if an API is marked as internal it can be changed at any
time (as long as ABI is maintained).
>
>
> At that time, I am willing to do more work to make lcore_config hidden;
> > ie no inline's to access it.
> >
>
> Ah I was looking at that, to see if we could at least shoot the direct
> accesses by calling the existing API.
> I can see we are missing one wrapper for the cpu id...
>
> And there are quite some odds things in with cpu affinity in dpaa:
> drivers/bus/dpaa/dpaa_bus.c: cpu = lcore_config[lcore].core_id;
> drivers/bus/dpaa/dpaa_bus.c:
> &lcore_config[lcore].cpuset);
> drivers/bus/fslmc/portal/dpaa2_hw_dpio.c: if
> (CPU_ISSET(i, &lcore_config[lcore_id].cpuset)) {
>
>
Drivers have no API/ABI restriction, it is only user code.
^ permalink raw reply [relevance 4%]
Results 5201-5400 of ~18000 next (newer) | prev (older) | reverse | sort options + mbox downloads above
-- links below jump to the message on this page --
2018-10-24 8:18 [dpdk-dev] [RFC 00/14] prefix network structures Olivier Matz
2018-12-20 21:59 ` Ferruh Yigit
2018-12-20 23:48 ` Stephen Hemminger
2018-12-21 14:38 ` Wiles, Keith
2018-12-21 15:14 ` Ferruh Yigit
2018-12-27 9:35 ` Olivier Matz
2019-02-13 11:48 0% ` Yigit, Ferruh
2019-02-18 12:37 0% ` Ferruh Yigit
2019-02-18 16:58 0% ` Olivier Matz
2018-12-07 17:52 [dpdk-dev] [PATCH v2 0/2] Timer library changes Erik Gabriel Carrillo
2018-12-13 22:26 ` [dpdk-dev] [PATCH v3 " Erik Gabriel Carrillo
2019-03-05 22:41 0% ` Carrillo, Erik G
2019-03-06 17:20 5% ` [dpdk-dev] [PATCH v4 " Erik Gabriel Carrillo
2018-12-12 6:24 [dpdk-dev] [PATCH v1 0/2] add rte_ring_reset and use it to flush a ring Gavin Hu
2019-03-15 3:31 ` [dpdk-dev] [PATCH v7 1/2] ring: add reset API to flush the ring when not in use Gavin Hu
2019-03-29 14:17 3% ` Olivier Matz
2019-03-29 14:17 3% ` Olivier Matz
2019-01-10 11:11 [dpdk-dev] [PATCH] compat: merge compat library into EAL Bruce Richardson
2019-02-06 11:01 4% ` [dpdk-dev] [PATCH v3] " Bruce Richardson
2019-02-06 12:22 0% ` Neil Horman
2019-01-10 13:38 [dpdk-dev] [PATCH] eal: fix strdup usages in internal config Anatoly Burakov
2019-01-31 11:21 0% ` Kevin Traynor
2019-01-31 14:10 0% ` Burakov, Anatoly
2019-01-31 14:15 0% ` Kevin Traynor
2019-01-31 15:04 0% ` Thomas Monjalon
2019-01-31 15:55 0% ` Burakov, Anatoly
2019-01-31 15:57 0% ` Kevin Traynor
2019-01-15 23:52 [dpdk-dev] [PATCH v2 0/5] Add non-blocking ring Gage Eads
2019-01-18 15:23 ` [dpdk-dev] [PATCH v3 " Gage Eads
2019-01-22 9:27 ` Ola Liljedahl
2019-01-23 16:02 ` Jerin Jacob Kollanukkaran
2019-01-23 16:29 ` Ola Liljedahl
2019-01-28 13:10 0% ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
2019-01-25 5:20 0% ` [dpdk-dev] " Honnappa Nagarahalli
2019-01-25 17:42 0% ` Eads, Gage
2019-01-25 17:56 0% ` Eads, Gage
2019-01-28 10:41 0% ` Ola Liljedahl
2019-01-28 18:14 3% ` [dpdk-dev] [PATCH v4 " Gage Eads
2019-01-28 18:14 2% ` [dpdk-dev] [PATCH v4 1/5] ring: add 64-bit headtail structure Gage Eads
2019-01-29 12:56 0% ` Ola Liljedahl
2019-03-05 17:40 2% ` [dpdk-dev] [PATCH v5 0/6] Add lock-free ring and mempool handler Gage Eads
2019-03-05 17:40 2% ` [dpdk-dev] [PATCH v5 1/6] ring: add a pointer-width headtail structure Gage Eads
2019-03-06 15:03 2% ` [dpdk-dev] [PATCH v6 0/6] Add lock-free ring and mempool handler Gage Eads
2019-03-06 15:03 2% ` [dpdk-dev] [PATCH v6 1/6] ring: add a pointer-width headtail structure Gage Eads
2019-03-18 21:35 2% ` [dpdk-dev] [PATCH v7 0/6] Add lock-free ring and mempool handler Gage Eads
2019-03-18 21:35 2% ` Gage Eads
2019-03-18 21:35 2% ` [dpdk-dev] [PATCH v7 1/6] ring: add a pointer-width headtail structure Gage Eads
2019-03-18 21:35 2% ` Gage Eads
2019-03-18 21:49 ` [dpdk-dev] [PATCH v7 0/6] Add lock-free ring and mempool handler Eads, Gage
2019-03-19 15:51 3% ` Stephen Hemminger
2019-03-19 15:51 3% ` Stephen Hemminger
2019-04-01 19:23 0% ` Eads, Gage
2019-04-01 19:23 0% ` Eads, Gage
2019-04-02 10:16 0% ` Ola Liljedahl
2019-04-02 10:16 0% ` Ola Liljedahl
2019-03-19 1:20 2% ` [dpdk-dev] [PATCH v8 " Gage Eads
2019-03-19 1:20 2% ` Gage Eads
2019-03-19 1:20 2% ` [dpdk-dev] [PATCH v8 1/6] ring: add a pointer-width headtail structure Gage Eads
2019-03-19 1:20 2% ` Gage Eads
2019-01-17 9:39 [dpdk-dev] [PATCH] doc: announce ABI change for cryptodev config Anoob Joseph
2019-01-31 9:53 4% ` Akhil Goyal
2019-02-01 11:14 4% ` Thomas Monjalon
2019-02-01 11:49 4% ` Trahe, Fiona
2019-02-28 10:02 4% ` Akhil Goyal
2019-02-28 10:54 4% ` Anoob Joseph
2019-03-07 10:39 4% ` [dpdk-dev] [PATCH v2] " Anoob Joseph
2019-03-07 15:25 4% ` Trahe, Fiona
2019-03-29 14:23 4% ` Akhil Goyal
2019-03-29 14:23 4% ` Akhil Goyal
2019-01-18 15:31 [dpdk-dev] [PATCH v3] doc: announce ring API change Gage Eads
2019-02-01 14:36 3% ` [dpdk-dev] [PATCH v4] " Gage Eads
2019-01-19 14:01 [dpdk-dev] [PATCH] service: fix parameter type Nikhil Rao
2019-01-21 11:43 ` Van Haaren, Harry
2019-02-08 15:01 0% ` Ferruh Yigit
2019-02-14 9:56 4% ` [dpdk-dev] [PATCH v2] " Nikhil Rao
2019-02-15 10:29 4% ` [dpdk-dev] [PATCH v3] " Nikhil Rao
2019-02-18 20:27 0% ` Rami Rosen
2019-03-28 6:29 4% ` [dpdk-dev] [PATCH v4] " Nikhil Rao
2019-03-28 6:29 4% ` Nikhil Rao
2019-01-22 16:23 [dpdk-dev] [PATCH v3 1/3] doc: clean ABI/API policy guide Ferruh Yigit
2019-01-24 18:10 ` [dpdk-dev] [PATCH v4 " Ferruh Yigit
2019-01-31 17:46 4% ` Kevin Traynor
2019-03-01 17:32 35% ` [dpdk-dev] [PATCH v5 " Ferruh Yigit
2019-03-01 17:32 17% ` [dpdk-dev] [PATCH v5 2/3] doc: make RTE_NEXT_ABI optional Ferruh Yigit
2019-01-23 22:07 [dpdk-dev] [PATCH] Introduce travis builds for github repositories Michael Santana
2019-01-24 19:26 ` Honnappa Nagarahalli
2019-01-24 19:51 0% ` Michael Santana Francisco
2019-01-30 22:16 ` [dpdk-dev] [PATCH v2 0/2] Introduce travis support Michael Santana
2019-01-30 22:16 3% ` [dpdk-dev] [PATCH v2 2/2] ci: Introduce travis builds for github repositories Michael Santana
2019-02-01 16:48 ` [dpdk-dev] [PATCH v3 0/2] Introduce travis support Michael Santana
2019-02-01 16:48 3% ` [dpdk-dev] [PATCH v3 2/2] ci: Introduce travis builds for github repositories Michael Santana
2019-02-06 19:17 0% ` Honnappa Nagarahalli
2019-02-06 20:18 0% ` Aaron Conole
2019-02-06 22:13 ` [dpdk-dev] [PATCH v4 0/2] Introduce travis support Michael Santana
2019-02-06 22:13 3% ` [dpdk-dev] [PATCH v4 2/2] ci: Introduce travis builds for github repositories Michael Santana
2019-02-07 22:01 ` [dpdk-dev] [PATCH v5 0/2] Introduce travis support Michael Santana
2019-02-07 22:01 3% ` [dpdk-dev] [PATCH v5 2/2] ci: Introduce travis builds for github repositories Michael Santana
2019-03-04 16:12 ` [dpdk-dev] [PATCH v6 0/1] Introduce travis support Michael Santana
2019-03-04 16:12 3% ` [dpdk-dev] [PATCH v6 1/1] ci: Introduce travis builds for github repositories Michael Santana
2019-03-22 16:56 3% ` [dpdk-dev] [PATCH v7] " Michael Santana
2019-03-22 16:56 3% ` Michael Santana
2019-03-25 15:32 3% ` [dpdk-dev] [PATCH v8] " Michael Santana
2019-03-25 15:32 3% ` Michael Santana
2019-01-31 16:24 3% [dpdk-dev] [PATCH v1] doc: update release notes for 19.02 John McNamara
2019-02-01 9:23 3% ` [dpdk-dev] [PATCH v3] " John McNamara
2019-01-31 17:39 3% [dpdk-dev] [PATCH v2] " John McNamara
2019-02-02 15:34 6% [dpdk-dev] [PATCH] version: 19.05-rc0 Thomas Monjalon
2019-02-04 11:26 [dpdk-dev] [PATCH] lib/cryptodev: fix driver name comparison Anoob Joseph
2019-02-20 15:41 ` Anoob Joseph
2019-02-21 17:03 3% ` Trahe, Fiona
2019-02-22 4:47 0% ` Anoob Joseph
2019-02-22 15:39 0% ` Trahe, Fiona
2019-02-23 6:11 3% ` Anoob Joseph
2019-02-25 11:52 3% ` Trahe, Fiona
2019-02-28 6:48 0% ` Anoob Joseph
2019-02-28 8:51 3% ` Akhil Goyal
2019-02-28 9:27 0% ` Anoob Joseph
2019-02-28 10:20 0% ` Akhil Goyal
2019-02-28 14:30 0% ` Trahe, Fiona
2019-03-01 6:24 0% ` Anoob Joseph
2019-03-07 5:51 0% ` Anoob Joseph
2019-02-08 11:13 [dpdk-dev] [PATCH v2 0/3] crypotodev: add result field to modular operations Arek Kusztal
2019-02-08 11:13 ` [dpdk-dev] [PATCH v2 1/3] cryptodev: add result field to mod exp and inverse operations Arek Kusztal
2019-02-12 10:55 ` Shally Verma
2019-02-28 9:59 3% ` Akhil Goyal
2019-02-28 10:44 0% ` Kusztal, ArkadiuszX
2019-02-28 10:52 0% ` Akhil Goyal
2019-02-14 15:42 [dpdk-dev] [PATCH 0/5] display testpmd forwarding engine stats on the fly David Marchand
2019-02-14 17:39 ` [dpdk-dev] [PATCH 3/5] app/testpmd: add missing transmit errors stats David Marchand
2019-02-14 18:51 ` David Marchand
2019-02-15 8:57 ` Thomas Monjalon
2019-02-15 9:33 3% ` David Marchand
2019-02-15 14:05 0% ` Bruce Richardson
2019-02-15 14:13 0% ` Wiles, Keith
2019-02-15 15:04 0% ` David Marchand
2019-02-15 16:19 4% ` Thomas Monjalon
2019-02-15 17:32 0% ` David Marchand
2019-02-15 18:15 0% ` Ananyev, Konstantin
2019-02-20 15:57 [dpdk-dev] [RFC 0/6] ethdev: add min/max MTU to device info Ian Stokes
2019-02-20 15:57 5% ` [dpdk-dev] [RFC 1/6] " Ian Stokes
2019-02-25 7:51 [dpdk-dev] [PATCH] vhost: add virtio configuration space access socket messages Changpeng Liu
[not found] ` <CGME20190225135328eucas1p1560252488ef0f0db87f0509d2bb7813c@eucas1p1.samsung.com>
2019-02-25 13:53 3% ` [dpdk-dev] " Ilya Maximets
2019-02-26 7:02 0% ` Liu, Changpeng
2019-02-26 12:57 [dpdk-dev] [PATCH] net/nfb: new netcope driver Rastislav Cernay
2019-03-01 14:37 ` [dpdk-dev] [PATCH v3] " Rastislav Cernay
2019-03-04 11:34 ` David Marchand
2019-03-04 14:33 ` Rastislav Černay
2019-03-04 12:35 3% ` David Marchand
2019-02-27 21:45 [dpdk-dev] [PATCH v1 0/6] ethdev: add min/max MTU to device info Ian Stokes
2019-02-27 21:45 13% ` [dpdk-dev] [PATCH v1 1/6] " Ian Stokes
2019-03-19 16:15 0% ` Ferruh Yigit
2019-03-19 16:15 0% ` Ferruh Yigit
2019-03-21 12:50 0% ` Ian Stokes
2019-03-21 12:50 0% ` Ian Stokes
2019-03-21 14:06 0% ` Ferruh Yigit
2019-03-21 14:06 0% ` Ferruh Yigit
2019-03-21 14:59 0% ` Ian Stokes
2019-03-21 14:59 0% ` Ian Stokes
2019-03-01 8:09 [dpdk-dev] [PATCH v1 0/6] Introduce AF_XDP PMD Xiaolong Ye
2019-03-01 8:09 ` [dpdk-dev] [PATCH v1 2/6] lib/mbuf: enable parse flags when create mempool Xiaolong Ye
2019-03-05 8:30 3% ` David Marchand
2019-03-07 3:07 0% ` Ye Xiaolong
2019-03-19 7:12 3% ` [dpdk-dev] [PATCH v2 0/6] Introduce AF_XDP PMD Xiaolong Ye
2019-03-19 7:12 3% ` Xiaolong Ye
2019-03-21 9:18 3% ` [dpdk-dev] [PATCH v3 0/5] " Xiaolong Ye
2019-03-21 9:18 3% ` Xiaolong Ye
2019-03-22 13:01 3% ` [dpdk-dev] [PATCH v4 " Xiaolong Ye
2019-03-22 13:01 3% ` Xiaolong Ye
2019-03-25 6:03 2% ` [dpdk-dev] [PATCH v5 " Xiaolong Ye
2019-03-25 6:03 2% ` Xiaolong Ye
2019-03-26 12:20 2% ` [dpdk-dev] [PATCH v6 " Xiaolong Ye
2019-03-26 12:20 2% ` Xiaolong Ye
2019-03-27 9:00 2% ` [dpdk-dev] [PATCH v7 " Xiaolong Ye
2019-03-27 9:00 2% ` Xiaolong Ye
2019-04-02 10:45 2% ` [dpdk-dev] [PATCH v8 0/1] " Xiaolong Ye
2019-04-02 10:45 2% ` Xiaolong Ye
2019-04-02 15:46 2% ` [dpdk-dev] [PATCH v9 0/1] Introduce " Xiaolong Ye
2019-04-02 15:46 2% ` Xiaolong Ye
2019-03-04 11:47 1% [dpdk-dev] [PATCH] crypto/aesni_mb: support newer version library only Fan Zhang
2019-03-04 14:47 0% ` Trahe, Fiona
2019-03-04 14:57 [dpdk-dev] [PATCH v2] " Fan Zhang
2019-03-25 13:58 ` [dpdk-dev] [PATCH v3] " Fan Zhang
2019-03-26 9:10 ` Akhil Goyal
2019-03-26 15:35 3% ` Zhang, Roy Fan
2019-03-26 15:35 3% ` Zhang, Roy Fan
2019-03-26 15:43 0% ` Akhil Goyal
2019-03-26 15:43 0% ` Akhil Goyal
2019-03-29 14:38 0% ` Akhil Goyal
2019-03-29 14:38 0% ` Akhil Goyal
2019-03-05 13:59 [dpdk-dev] [PATCH v3 0/6] introduce DMA memory mapping for external memory Shahaf Shuler
2019-02-21 14:50 ` [dpdk-dev] [PATCH v2 " Shahaf Shuler
2019-02-13 9:10 ` [dpdk-dev] [PATCH " Shahaf Shuler
2019-02-21 14:50 5% ` [dpdk-dev] [PATCH v2 1/6] vfio: allow DMA map of memory for the default vfio fd Shahaf Shuler
2019-03-05 13:59 5% ` [dpdk-dev] [PATCH v3 " Shahaf Shuler
2019-03-10 8:27 ` [dpdk-dev] [PATCH v4 0/6] introduce DMA memory mapping for external memory Shahaf Shuler
2019-03-10 8:27 5% ` [dpdk-dev] [PATCH v4 1/6] vfio: allow DMA map of memory for the default vfio fd Shahaf Shuler
2019-03-30 0:23 3% ` Thomas Monjalon
2019-03-30 0:23 3% ` Thomas Monjalon
2019-03-30 14:29 0% ` Thomas Monjalon
2019-03-30 14:29 0% ` Thomas Monjalon
2019-03-06 4:16 [dpdk-dev] [PATCH v2 0/6] HelloWorld example for windows Anand Rawat
2019-03-26 6:02 ` [dpdk-dev] [PATCH v5 0/8] " Anand Rawat
2019-03-26 6:02 ` [dpdk-dev] [PATCH v5 3/8] kvargs: adding a module definition file Anand Rawat
2019-03-26 10:32 ` Jerin Jacob Kollanukkaran
2019-03-26 10:58 3% ` Bruce Richardson
2019-03-26 10:58 3% ` Bruce Richardson
2019-03-26 13:37 0% ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
2019-03-26 13:37 0% ` Jerin Jacob Kollanukkaran
2019-03-06 16:22 1% [dpdk-dev] [RFC PATCH 0/6] change legacy linuxapp/bsdapp names Bruce Richardson
2019-03-06 16:22 7% ` [dpdk-dev] [PATCH 6/6] build: allow linux and freebsd in build configs Bruce Richardson
2019-03-07 14:13 8% [dpdk-dev] [PATCH] cryptodev: fix restore crypto op alignment and layout Konstantin Ananyev
2019-03-08 12:59 0% ` Trahe, Fiona
2019-03-12 12:04 0% ` Shally Verma
2019-03-19 13:33 3% ` Akhil Goyal
2019-03-19 13:33 3% ` Akhil Goyal
2019-03-19 14:00 0% ` Akhil Goyal
2019-03-19 14:00 0% ` Akhil Goyal
2019-03-13 19:48 [dpdk-dev] [PATCH 0/4] rte_power APIs enhancement Hajkowski
2019-03-13 19:48 4% ` [dpdk-dev] [PATCH 1/4] power: fix non thread-safe power env modification Hajkowski
2019-03-13 19:48 4% ` Hajkowski
2019-03-13 19:48 4% ` [dpdk-dev] [PATCH 2/4] power: return error in set env when power env already set Hajkowski
2019-03-13 19:48 4% ` Hajkowski
2019-03-14 15:12 [dpdk-dev] [PATCH 00/12] rxq q_errors[] statistics fixes David Marchand
2019-03-14 15:13 ` [dpdk-dev] [RFC PATCH 1/2] ethdev: introduce internal rxq/txq stats API David Marchand
2019-03-19 17:18 4% ` Ferruh Yigit
2019-03-19 17:18 4% ` Ferruh Yigit
2019-03-19 17:54 3% ` Stephen Hemminger
2019-03-19 17:54 3% ` Stephen Hemminger
2019-03-26 9:29 0% ` David Marchand
2019-03-26 9:29 0% ` David Marchand
2019-03-15 9:34 [dpdk-dev] [PATCH 0/4] rte_power APIs enhancement Hajkowski
2019-03-15 9:34 4% ` [dpdk-dev] [PATCH 1/4] power: fix non thread-safe power env modification Hajkowski
2019-03-15 9:34 4% ` Hajkowski
2019-03-15 9:34 4% ` [dpdk-dev] [PATCH 2/4] power: return error in set env when power env already set Hajkowski
2019-03-15 9:34 4% ` Hajkowski
2019-03-18 11:56 4% [dpdk-dev] [PATCH v2 1/4] power: fix non thread-safe power env modification Hajkowski
2019-03-18 11:56 4% ` Hajkowski
2019-03-18 11:56 4% ` [dpdk-dev] [PATCH v2 2/4] power: return error in set env when power env already set Hajkowski
2019-03-18 11:56 4% ` Hajkowski
2019-03-18 15:41 [dpdk-dev] [PATCH v3 0/5] Supported VXLAN-GPE in i40e Qiming Yang
2019-03-19 16:36 ` [dpdk-dev] [PATCH v4 " Qiming Yang
2019-03-19 16:36 ` [dpdk-dev] [PATCH v4 1/5] eal: add VXLAN-GPE macro Qiming Yang
2019-03-19 13:50 4% ` David Marchand
2019-03-19 13:50 4% ` David Marchand
2019-03-19 16:34 0% ` Ferruh Yigit
2019-03-19 16:34 0% ` Ferruh Yigit
2019-03-19 14:05 29% [dpdk-dev] [PATCH] doc: fix abi check script examples David Marchand
2019-03-19 14:05 29% ` David Marchand
2019-03-19 17:19 4% ` Neil Horman
2019-03-19 17:19 4% ` Neil Horman
2019-03-22 13:01 [dpdk-dev] [PATCH v2 0/7] ethdev: add min/max MTU to device info Ian Stokes
2019-03-22 13:01 12% ` [dpdk-dev] [PATCH v2 1/7] " Ian Stokes
2019-03-22 13:01 12% ` Ian Stokes
2019-03-25 14:26 0% ` Ferruh Yigit
2019-03-25 14:26 0% ` Ferruh Yigit
2019-03-29 17:52 11% ` [dpdk-dev] [PATCH v3 " Ferruh Yigit
2019-03-29 17:52 11% ` Ferruh Yigit
2019-03-29 17:56 0% ` Ferruh Yigit
2019-03-29 17:56 0% ` Ferruh Yigit
2019-03-29 18:05 0% ` Ferruh Yigit
2019-03-29 18:05 0% ` Ferruh Yigit
2019-03-26 19:25 [dpdk-dev] [RFC] eal: rename state values in rte_lcore_state Stephen Hemminger
2019-04-02 15:57 ` [dpdk-dev] [PATCH v2] " Stephen Hemminger
2019-04-02 20:15 ` David Marchand
2019-04-02 20:48 ` Stephen Hemminger
2019-04-02 21:03 ` David Marchand
2019-04-02 21:07 4% ` Stephen Hemminger
2019-03-27 6:19 [dpdk-dev] [PATCH v2 0/3] Add rte_eth_read_clock API Tom Barbette
2019-03-27 6:19 ` [dpdk-dev] [PATCH v2 1/3] rte_ethdev: Add API function to read dev clock Tom Barbette
2019-04-02 17:46 3% ` Ferruh Yigit
2019-04-02 17:46 3% ` Ferruh Yigit
2019-03-27 15:44 1% [dpdk-dev] [PATCH] meter: replace color definitions with rte_color values Jasvinder Singh
2019-03-27 15:44 1% ` Jasvinder Singh
2019-04-02 16:08 2% [dpdk-dev] [pull-request] next-crypto 19.05 rc1 Akhil Goyal
2019-04-02 16:08 2% ` Akhil Goyal
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).