* 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
0 siblings, 0 replies; 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%]
* [dpdk-dev] [PATCH] cryptodev: fix restore crypto op alignment and layout
@ 2019-03-07 14:13 8% Konstantin Ananyev
0 siblings, 0 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%]
* [dpdk-dev] [PATCH v2] doc: announce ABI change for cryptodev config
2019-01-17 9:39 4% [dpdk-dev] [PATCH] doc: announce ABI change for cryptodev config Anoob Joseph
2019-01-17 11:37 4% ` Trahe, Fiona
2019-01-31 9:53 4% ` Akhil Goyal
@ 2019-03-07 10:39 4% ` Anoob Joseph
2019-03-07 15:25 4% ` Trahe, Fiona
2 siblings, 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%]
* 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%]
* 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%]
* [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%]
* [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] [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 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
1 sibling, 1 reply; 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] [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
0 siblings, 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%]
* 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 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%]
* [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 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%]
* 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 v6 1/1] ci: Introduce travis builds for github repositories
@ 2019-03-04 16:12 3% ` Michael Santana
0 siblings, 0 replies; 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] 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%]
* 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%]
* [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%]
* [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 v5 1/3] doc: clean ABI/API policy guide
2019-01-24 18:10 35% ` [dpdk-dev] [PATCH v4 " Ferruh Yigit
2019-01-24 18:10 17% ` [dpdk-dev] [PATCH v4 2/3] doc: make RTE_NEXT_ABI optional Ferruh Yigit
2019-01-31 17:46 4% ` [dpdk-dev] [PATCH v4 1/3] doc: clean ABI/API policy guide 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
2 siblings, 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%]
* 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%]
* 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] 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 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 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] 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] 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 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] 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] 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-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%]
* [dpdk-dev] [PATCH v1 1/6] ethdev: add min/max MTU to device info
@ 2019-02-27 21:45 13% ` Ian Stokes
0 siblings, 0 replies; 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] 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%]
* 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] [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] [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-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-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-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%]
* [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%]
* [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%]
* 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%]
* 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] [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] [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] [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 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 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 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 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%]
* [dpdk-dev] [PATCH v3] service: fix parameter type
2019-01-19 14:01 3% [dpdk-dev] [PATCH] service: fix parameter type Nikhil Rao
2019-01-21 11:43 3% ` Van Haaren, Harry
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
2 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
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 v2] service: fix parameter type
2019-01-19 14:01 3% [dpdk-dev] [PATCH] service: fix parameter type Nikhil Rao
2019-01-21 11:43 3% ` Van Haaren, Harry
@ 2019-02-14 9:56 4% ` Nikhil Rao
2019-02-15 10:29 4% ` [dpdk-dev] [PATCH v3] " Nikhil Rao
2 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] [RFC 00/14] prefix network structures
2018-12-27 9:35 0% ` Olivier Matz
@ 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%]
* Re: [dpdk-dev] [PATCH] service: fix parameter type
2019-01-21 11:43 3% ` Van Haaren, Harry
@ 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%]
* [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%]
* [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%]
* 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%]
* 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] 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%]
* [dpdk-dev] [PATCH v3] compat: merge compat library into EAL
2019-01-10 13:47 4% ` [dpdk-dev] [PATCH v2] " Bruce Richardson
@ 2019-02-06 11:01 4% ` Bruce Richardson
2019-02-06 12:22 0% ` Neil Horman
1 sibling, 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%]
* [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 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 v4] doc: announce ring API change
2019-01-18 15:31 3% ` [dpdk-dev] [PATCH v3] " Gage Eads
@ 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%]
* 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%]
* 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%]
* [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 v4 1/3] doc: clean ABI/API policy guide
2019-01-24 18:10 35% ` [dpdk-dev] [PATCH v4 " Ferruh Yigit
2019-01-24 18:10 17% ` [dpdk-dev] [PATCH v4 2/3] doc: make RTE_NEXT_ABI optional Ferruh Yigit
@ 2019-01-31 17:46 4% ` Kevin Traynor
2019-03-01 17:32 35% ` [dpdk-dev] [PATCH v5 " Ferruh Yigit
2 siblings, 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 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%]
* [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%]
* 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%]
* 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 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 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 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-10 13:38 2% [dpdk-dev] [PATCH] eal: fix strdup usages in internal config Anatoly Burakov
2019-01-14 14:18 0% ` Thomas Monjalon
@ 2019-01-31 11:21 0% ` Kevin Traynor
2019-01-31 14:10 0% ` Burakov, Anatoly
1 sibling, 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] doc: announce ABI change for cryptodev config
2019-01-17 9:39 4% [dpdk-dev] [PATCH] doc: announce ABI change for cryptodev config Anoob Joseph
2019-01-17 11:37 4% ` Trahe, Fiona
@ 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
2 siblings, 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%]
* [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 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 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%]
* [dpdk-dev] [PATCH v4 0/5] Add non-blocking ring
2019-01-18 15:23 3% ` [dpdk-dev] [PATCH v3 " Gage Eads
` (2 preceding siblings ...)
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
3 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%]
* Re: [dpdk-dev] [EXT] Re: [PATCH v3 0/5] Add non-blocking ring
2019-01-23 16:29 0% ` Ola Liljedahl
@ 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%]
* 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] [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 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-18 15:23 3% ` [dpdk-dev] [PATCH v3 " Gage Eads
2019-01-18 15:23 2% ` [dpdk-dev] [PATCH v3 1/5] ring: add 64-bit headtail structure Gage Eads
2019-01-22 9:27 0% ` [dpdk-dev] [PATCH v3 0/5] Add non-blocking ring Ola Liljedahl
@ 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
3 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] Introduce travis builds for github repositories
2019-01-24 19:26 0% ` Honnappa Nagarahalli
@ 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] Introduce travis builds for github repositories
2019-01-23 22:07 4% [dpdk-dev] [PATCH] Introduce travis builds for github repositories Michael Santana
@ 2019-01-24 19:26 0% ` Honnappa Nagarahalli
2019-01-24 19:51 0% ` Michael Santana Francisco
1 sibling, 1 reply; 200+ results
From: Honnappa Nagarahalli @ 2019-01-24 19:26 UTC (permalink / raw)
To: Michael Santana, dev
Cc: Aaron Conole, Bruce Richardson, thomas, Ferruh Yigit, nd,
Honnappa Nagarahalli, nd
>
> 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%]
* [dpdk-dev] [PATCH v4 2/3] doc: make RTE_NEXT_ABI optional
2019-01-24 18:10 35% ` [dpdk-dev] [PATCH v4 " Ferruh Yigit
@ 2019-01-24 18:10 17% ` Ferruh Yigit
2019-01-31 17:46 4% ` [dpdk-dev] [PATCH v4 1/3] doc: clean ABI/API policy guide Kevin Traynor
2019-03-01 17:32 35% ` [dpdk-dev] [PATCH v5 " Ferruh Yigit
2 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-01-24 18:10 UTC (permalink / raw)
To: dev, John McNamara, Marko Kovacevic
Cc: Luca Boccassi, Kevin Traynor, Yongseok Koh, Neil Horman
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 19af56cd2..bfc27fbe0 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.17.2
^ permalink raw reply [relevance 17%]
* [dpdk-dev] [PATCH v4 1/3] doc: clean ABI/API policy guide
2019-01-22 16:23 35% ` [dpdk-dev] [PATCH v3 1/3] " Ferruh Yigit
2019-01-22 16:23 17% ` [dpdk-dev] [PATCH v3 2/3] doc: make RTE_NEXT_ABI optional Ferruh Yigit
2019-01-23 8:13 4% ` [dpdk-dev] [PATCH v3 1/3] doc: clean ABI/API policy guide Neil Horman
@ 2019-01-24 18:10 35% ` Ferruh Yigit
2019-01-24 18:10 17% ` [dpdk-dev] [PATCH v4 2/3] doc: make RTE_NEXT_ABI optional Ferruh Yigit
` (2 more replies)
2 siblings, 3 replies; 200+ results
From: Ferruh Yigit @ 2019-01-24 18:10 UTC (permalink / raw)
To: dev, John McNamara, Marko Kovacevic
Cc: Luca Boccassi, Kevin Traynor, Yongseok Koh, Neil Horman
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 01b36247e..19af56cd2 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.17.2
^ permalink raw reply [relevance 35%]
* [dpdk-dev] [PATCH] Introduce travis builds for github repositories
@ 2019-01-23 22:07 4% Michael Santana
2019-01-24 19:26 0% ` Honnappa Nagarahalli
0 siblings, 2 replies; 200+ results
From: Michael Santana @ 2019-01-23 22:07 UTC (permalink / raw)
To: dev; +Cc: Aaron Conole, Bruce Richardson, Thomas Monjalon, Ferruh Yigit
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}
+ 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 4%]
* Re: [dpdk-dev] [PATCH v3 0/5] Add non-blocking ring
2019-01-23 16:02 0% ` Jerin Jacob Kollanukkaran
@ 2019-01-23 16:29 0% ` Ola Liljedahl
2019-01-28 13:10 0% ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
0 siblings, 1 reply; 200+ results
From: Ola Liljedahl @ 2019-01-23 16:29 UTC (permalink / raw)
To: jerinj, gage.eads, dev
Cc: olivier.matz, stephen, nd, bruce.richardson, arybchenko,
konstantin.ananyev
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
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 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%]
* Re: [dpdk-dev] [PATCH v3 0/5] Add non-blocking ring
2019-01-22 9:27 0% ` [dpdk-dev] [PATCH v3 0/5] Add non-blocking ring Ola Liljedahl
2019-01-22 10:15 0% ` Ola Liljedahl
2019-01-22 19:15 0% ` Eads, Gage
@ 2019-01-23 16:02 0% ` Jerin Jacob Kollanukkaran
2019-01-23 16:29 0% ` Ola Liljedahl
2 siblings, 1 reply; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-01-23 16:02 UTC (permalink / raw)
To: Ola.Liljedahl, gage.eads, dev
Cc: olivier.matz, stephen, bruce.richardson, arybchenko, konstantin.ananyev
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, We can not detect the presese of LSE support in compile time.
Right?
The dynamic one will be costly like,
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
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3 1/3] doc: clean ABI/API policy guide
2019-01-22 16:23 35% ` [dpdk-dev] [PATCH v3 1/3] " Ferruh Yigit
2019-01-22 16:23 17% ` [dpdk-dev] [PATCH v3 2/3] doc: make RTE_NEXT_ABI optional Ferruh Yigit
@ 2019-01-23 8:13 4% ` Neil Horman
2019-01-24 18:10 35% ` [dpdk-dev] [PATCH v4 " Ferruh Yigit
2 siblings, 0 replies; 200+ results
From: Neil Horman @ 2019-01-23 8:13 UTC (permalink / raw)
To: Ferruh Yigit
Cc: dev, John McNamara, Marko Kovacevic, Luca Boccassi,
Kevin Traynor, Yongseok Koh
On Tue, Jan 22, 2019 at 04:23:08PM +0000, 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>
> ---
> 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 01b36247e..19af56cd2 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.17.2
>
>
Series
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v3 0/5] Add non-blocking ring
2019-01-22 9:27 0% ` [dpdk-dev] [PATCH v3 0/5] Add non-blocking ring Ola Liljedahl
2019-01-22 10:15 0% ` Ola Liljedahl
@ 2019-01-22 19:15 0% ` Eads, Gage
2019-01-23 16:02 0% ` Jerin Jacob Kollanukkaran
2 siblings, 0 replies; 200+ results
From: Eads, Gage @ 2019-01-22 19:15 UTC (permalink / raw)
To: Ola Liljedahl, dev
Cc: olivier.matz, stephen, Richardson, Bruce, arybchenko, Ananyev,
Konstantin
> -----Original Message-----
> From: Ola Liljedahl [mailto:Ola.Liljedahl@arm.com]
> Sent: Tuesday, January 22, 2019 3:28 AM
> To: Eads, Gage <gage.eads@intel.com>; dev@dpdk.org
> Cc: olivier.matz@6wind.com; stephen@networkplumber.org; Richardson, Bruce
> <bruce.richardson@intel.com>; arybchenko@solarflare.com; Ananyev,
> Konstantin <konstantin.ananyev@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v3 0/5] Add non-blocking ring
>
> On Fri, 2019-01-18 at 09:23 -0600, Gage Eads wrote:
> > 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.
> ARMv8.0 should be able to implement a 128-bit atomic compare exchange
> operation using LDXP/STXP.
I see, I wasn't aware these instructions were available.
>
> From an ARM perspective, I want all atomic operations to take memory ordering
> arguments (e.g. acquire, release). Not all usages of e.g.
> 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
>
Sure, I'll address this in the next patchset.
Thanks,
Gage
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 1/6] ring: change head and tail to pointer-width size
@ 2019-01-22 18:27 3% ` Eads, Gage
0 siblings, 0 replies; 200+ results
From: Eads, Gage @ 2019-01-22 18:27 UTC (permalink / raw)
To: Burakov, Anatoly, Richardson, Bruce
Cc: dev, olivier.matz, arybchenko, Ananyev, Konstantin
> -----Original Message-----
> From: Burakov, Anatoly
> Sent: Monday, January 21, 2019 8:15 AM
> To: Eads, Gage <gage.eads@intel.com>; Richardson, Bruce
> <bruce.richardson@intel.com>
> Cc: dev@dpdk.org; olivier.matz@6wind.com; arybchenko@solarflare.com;
> Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Subject: Re: [dpdk-dev] [PATCH 1/6] ring: change head and tail to pointer-width
> size
>
> On 11-Jan-19 7:27 PM, Eads, Gage wrote:
> >
> >
> >> -----Original Message-----
> >> From: Richardson, Bruce
> >> Sent: Friday, January 11, 2019 5:59 AM
> >> To: Burakov, Anatoly <anatoly.burakov@intel.com>
> >> Cc: Eads, Gage <gage.eads@intel.com>; dev@dpdk.org;
> >> olivier.matz@6wind.com; arybchenko@solarflare.com; Ananyev,
> >> Konstantin <konstantin.ananyev@intel.com>
> >> Subject: Re: [dpdk-dev] [PATCH 1/6] ring: change head and tail to
> >> pointer-width size
> >>
> >> On Fri, Jan 11, 2019 at 11:30:24AM +0000, Burakov, Anatoly wrote:
> >>> On 11-Jan-19 10:58 AM, Bruce Richardson wrote:
> >>>> On Fri, Jan 11, 2019 at 10:40:19AM +0000, Burakov, Anatoly wrote:
> >>>>> <...>
> >>>>>
> >>>>>> + * Copyright(c) 2016-2019 Intel Corporation
> >>>>>> */
> >>>>>> /**
> >>>>>> @@ -88,7 +88,7 @@ rte_event_ring_enqueue_burst(struct
> >> rte_event_ring *r,
> >>>>>> const struct rte_event *events,
> >>>>>> unsigned int n, uint16_t *free_space)
> >>>>>> {
> >>>>>> - uint32_t prod_head, prod_next;
> >>>>>> + uintptr_t prod_head, prod_next;
> >>>>>
> >>>>> I would also question the use of uinptr_t. I think semnatically,
> >>>>> size_t is more appropriate.
> >>>>>
> >>>> Yes, it would, but I believe in this case they want to use the
> >>>> largest size of (unsigned)int where there exists an atomic for
> >>>> manipulating 2 of them simultaneously. [The largest size is to
> >>>> minimize any chance of an ABA issue occuring]. Therefore we need
> >>>> 32-bit values on 32-bit and 64-bit on 64, and I suspect the best
> >>>> way to guarantee this is to use pointer-sized values. If size_t is
> >>>> guaranteed across all OS's to have the same size as uintptr_t it
> >>>> could also be
> >> used, though.
> >>>>
> >>>> /Bruce
> >>>>
> >>>
> >>> Technically, size_t and uintptr_t are not guaranteed to match. In
> >>> practice, they won't match only on architectures that DPDK doesn't
> >>> intend to run on (such as 16-bit segmented archs, where size_t would
> >>> be 16-bit but uinptr_t would be 32-bit).
> >>>
> >>> In all the rest of DPDK code, we use size_t for this kind of thing.
> >>>
> >>
> >> Ok.
> >> If we do use size_t, I think we also need to add a compile-time check
> >> into the build too, to error out if sizeof(size_t) != sizeof(uintptr_t).
> >
> > Ok, I wasn't aware of the precedent of using size_t for this purpose. I'll change
> it and look into adding a static assert.
>
> RTE_BUILD_BUG_ON?
Appreciate the pointer, but with the changes needed to preserve ABI compatibility* this is no longer necessary.
*http://mails.dpdk.org/archives/dev/2019-January/123775.html
>
> >
> > Thanks,
> > Gage
> >
>
>
> --
> Thanks,
> Anatoly
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v3 2/3] doc: make RTE_NEXT_ABI optional
2019-01-22 16:23 35% ` [dpdk-dev] [PATCH v3 1/3] " Ferruh Yigit
@ 2019-01-22 16:23 17% ` Ferruh Yigit
2019-01-23 8:13 4% ` [dpdk-dev] [PATCH v3 1/3] doc: clean ABI/API policy guide Neil Horman
2019-01-24 18:10 35% ` [dpdk-dev] [PATCH v4 " Ferruh Yigit
2 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-01-22 16:23 UTC (permalink / raw)
To: dev, John McNamara, Marko Kovacevic
Cc: Luca Boccassi, Kevin Traynor, Yongseok Koh, Neil Horman
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>
---
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 19af56cd2..bfc27fbe0 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.17.2
^ permalink raw reply [relevance 17%]
* [dpdk-dev] [PATCH v3 1/3] doc: clean ABI/API policy guide
2018-12-21 15:57 35% ` [dpdk-dev] [PATCH v2 " Ferruh Yigit
@ 2019-01-22 16:23 35% ` Ferruh Yigit
2019-01-22 16:23 17% ` [dpdk-dev] [PATCH v3 2/3] doc: make RTE_NEXT_ABI optional Ferruh Yigit
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Ferruh Yigit @ 2019-01-22 16:23 UTC (permalink / raw)
To: dev, John McNamara, Marko Kovacevic
Cc: Luca Boccassi, Kevin Traynor, Yongseok Koh, Neil Horman
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>
---
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 01b36247e..19af56cd2 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.17.2
^ permalink raw reply [relevance 35%]
* Re: [dpdk-dev] [PATCH v3 0/5] Add non-blocking ring
2019-01-22 9:27 0% ` [dpdk-dev] [PATCH v3 0/5] Add non-blocking ring Ola Liljedahl
@ 2019-01-22 10:15 0% ` Ola Liljedahl
2019-01-22 19:15 0% ` Eads, Gage
2019-01-23 16:02 0% ` Jerin Jacob Kollanukkaran
2 siblings, 0 replies; 200+ results
From: Ola Liljedahl @ 2019-01-22 10:15 UTC (permalink / raw)
To: gage.eads, dev
Cc: olivier.matz, stephen, bruce.richardson, arybchenko, konstantin.ananyev
Sorry about the confidental footer. I tried to remove it using some Exhange
magic but it seems not to work with Evolution. I'll try some other way.
-- Ola
On Tue, 2019-01-22 at 09:27 +0000, Ola Liljedahl wrote:
> On Fri, 2019-01-18 at 09:23 -0600, Gage Eads wrote:
> >
> > 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.
> >
I. 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.
> ARMv8.0 should be able to implement a 128-bit atomic compare exchange
> operation using 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.
> 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
>
> >
> >
> > 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
> >
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for cryptodev config
2019-01-18 6:59 4% ` Shally Verma
@ 2019-01-22 9:31 4% ` Anoob Joseph
0 siblings, 0 replies; 200+ results
From: Anoob Joseph @ 2019-01-22 9:31 UTC (permalink / raw)
To: Trahe, Fiona, Akhil Goyal, De Lara Guarch, Pablo
Cc: Jerin Jacob Kollanukkaran, Narayana Prasad Raju Athreya,
Shally Verma, dev
Hi Fiona,
Any more comments on this?
@ Akhil, Pablo
Can you review this change and share your thoughts?
Thanks,
Anoob
> -----Original Message-----
> From: Shally Verma
> Sent: 18 January 2019 12:29
> To: Anoob Joseph <anoobj@marvell.com>; Trahe, Fiona
> <fiona.trahe@intel.com>; Akhil Goyal <akhil.goyal@nxp.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
> Subject: RE: [PATCH] doc: announce ABI change for cryptodev config
>
> HI Fiona, Anoob
>
> >-----Original Message-----
> >From: Anoob Joseph
> >Sent: 17 January 2019 19:17
> >To: Trahe, Fiona <fiona.trahe@intel.com>; Akhil Goyal
> ><akhil.goyal@nxp.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>; Shally Verma
> ><shallyv@marvell.com>; dev@dpdk.org
> >Subject: RE: [PATCH] doc: announce ABI change for cryptodev config
> >
> >Hi Fiona,
> >
> >Please see inline.
> >
> >Thanks,
> >Anoob
> >
> >> -----Original Message-----
> >> From: Trahe, Fiona <fiona.trahe@intel.com>
> >> Sent: 17 January 2019 17:07
> >> To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal
> >> <akhil.goyal@nxp.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>; Shally Verma
> >> <shallyv@marvell.com>; dev@dpdk.org; Trahe, Fiona
> >> <fiona.trahe@intel.com>
> >> Subject: RE: [PATCH] doc: announce ABI change for cryptodev config
> >>
> >> Hi Joseph,
> >>
> >> > -----Original Message-----
> >> > From: Anoob Joseph [mailto:anoobj@marvell.com]
> >> > Sent: Thursday, January 17, 2019 9:40 AM
> >> > To: Akhil Goyal <akhil.goyal@nxp.com>; De Lara Guarch, Pablo
> >> > <pablo.de.lara.guarch@intel.com>; Trahe, Fiona
> >> > <fiona.trahe@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>;
> >> > dev@dpdk.org
> >> > Subject: [PATCH] doc: announce ABI change for cryptodev config
> >> >
> >> > 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.
> >> [Fiona] I'm unfamiliar with eth config so can you explain a bit more
> >> how this works?
> >
> >[Anoob] For eth devices, application would first do
> >rte_eth_dev_info_get() and gets the capabilities. The device would
> >expose it's capabilities using dev_info.rx_offload_capa &
> dev_info.tx_offload_capa. The application can enable/disable these features
> while configuring the eth ports.
> >
> >From ipsec-secgw:
> >https://git.dpdk.org/dpdk/tree/examples/ipsec-secgw/ipsec-secgw.c#n1866
> >
> >if (frame_size) {
> > local_port_conf.rxmode.max_rx_pkt_len = frame_size;
> > local_port_conf.rxmode.offloads |=
> DEV_RX_OFFLOAD_JUMBO_FRAME;
> > }
> >
> ><snip>
> >
> >ret = rte_eth_dev_configure(portid, nb_rx_queue, nb_tx_queue,
> > &local_port_conf);
> >
> ><snip>
> >
> >This way application can choose to disable unwanted offloads.
> >
> >Port init in ipsec-secgw:
> >https://git.dpdk.org/dpdk/tree/examples/ipsec-secgw/ipsec-secgw.c#n1826
> >
> >> e.g. if a crypto device's info says it supports
> >> RTE_CRYPTODEV_FF_SYMMETRIC_CRYPTO
> >> RTE_CRYPTODEV_FF_SYM_OPERATION_CHAINING
> >> RTE_CRYPTODEV_FF_CPU_AESNI
> >> RTE_CRYPTODEV_FF_SECURITY
> >> RTE_CRYPTODEV_FF_OOP_LB_IN_LB_OUT
> >> these things are all already enabled.
> >> Is the param a way to disable some of them?
> >
> >[Anoob] Yes. There are few other flags in addition to the above. Like
> RTE_CRYPTODEV_FF_ASYMMETRIC_CRYPTO.
> >
> >> If so, it would be better to call it ff_disable.
> >
> >[Anoob] Calling it ff_enable is to make it similar to how it's done with eth
> devices. Either way should be fine.
> [Shally] keeping it as "ff_enable" will require application to set these flags to
> configure PMD. If we define it other way around, then it would be mean to mask
> out unwanted features which can be quite many.
> Though purpose can be achieved both ways but keeping it as "enable" looks
> more easy to use, readable and inline with how ethdev handle multi feature
> support.
> So I would prefer to keep it as "ff_enable"
>
> Thanks
> Shally
>
> >
> >> And to limit it to the subset of features that it makes sense to disable.
> >> i.e. why would an application disable chaining or any of the SGL
> >> flags? It would just add extra cycles in the PMD to error check on
> >> these cases, instead the appl can just not send such commands.
> >> And it doesn't make sense to disable AESNI or
> >> RTE_CRYPTODEV_FF_HW_ACCELERATED.
> >> Actually I can't see what an application would want to achieve by
> >> disabling any flag?
> >
> >[Anoob] Features like ASYMMETRIC or SECURITY is not required for every
> >application. SECURITY is added for eth devices also. But since the
> >feature can be disabled while configuring the port, applications are given a
> choice to disable it. That way apps like l2fwd doesn't enable SECURITY. With
> crypto this option is not available.
> >
> >If the unused offloads can be communicated to the PMD before initialization,
> the PMD will be allowed to optimize hardware usage.
> >Otherwise, supporting more features would affect performance, even if
> application is not making use of those features.
> >
> >Ex: test-crypto-perf doesn't use ASYM/SECURITY. Now adding these features
> would affect the performance of this app.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v3 0/5] Add non-blocking ring
2019-01-18 15:23 3% ` [dpdk-dev] [PATCH v3 " Gage Eads
2019-01-18 15:23 2% ` [dpdk-dev] [PATCH v3 1/5] ring: add 64-bit headtail structure Gage Eads
@ 2019-01-22 9:27 0% ` Ola Liljedahl
2019-01-22 10:15 0% ` Ola Liljedahl
` (2 more replies)
2019-01-25 5:20 0% ` [dpdk-dev] " Honnappa Nagarahalli
2019-01-28 18:14 3% ` [dpdk-dev] [PATCH v4 " Gage Eads
3 siblings, 3 replies; 200+ results
From: Ola Liljedahl @ 2019-01-22 9:27 UTC (permalink / raw)
To: gage.eads, dev
Cc: olivier.matz, stephen, bruce.richardson, arybchenko, konstantin.ananyev
On Fri, 2019-01-18 at 09:23 -0600, Gage Eads wrote:
> 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.
ARMv8.0 should be able to implement a 128-bit atomic compare exchange
operation using 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.
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
>
> 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
>
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] dev Digest, Vol 231, Issue 6
[not found] <mailman.14255.1548076743.7586.dev@dpdk.org>
@ 2019-01-21 13:23 0% ` Anudeep Kumar
0 siblings, 0 replies; 200+ results
From: Anudeep Kumar @ 2019-01-21 13:23 UTC (permalink / raw)
To: dev
Hi,
I am unable to run l3fwd in dpdk. Please provide steps to run.
Regards,
Anudeep
On Mon, Jan 21, 2019, 18:49 <dev-request@dpdk.org wrote:
> Send dev mailing list submissions to
> dev@dpdk.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mails.dpdk.org/listinfo/dev
> or, via email, send a message with subject or body 'help' to
> dev-request@dpdk.org
>
> You can reach the person managing the list at
> dev-owner@dpdk.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dev digest..."
>
>
> Today's Topics:
>
> 1. [PATCH v6 2/4] examples/ip_pipeline: support QinQ PPPoE encap
> (Nemanja Marjanovic)
> 2. [PATCH v6 1/4] pipeline: support QinQ PPPoE encap
> (Nemanja Marjanovic)
> 3. [PATCH v6 3/4] net/softnic: support QinQ PPPoE encap
> (Nemanja Marjanovic)
> 4. [PATCH v6 4/4] net: add PPPoE ethertypes (Nemanja Marjanovic)
> 5. Re: [PATCH] doc: add deprecation notice to remove rte meter
> color (Mohammad Abdul Awal)
> 6. Re: [PATCH] service: fix parameter type (Van Haaren, Harry)
> 7. Re: [PATCH] vhost: fix possible out of bound access for
> indirect descs (Maxime Coquelin)
> 8. Re: IXGBE, IOMMU DMAR DRHD handling fault issue (Hu, Xuekun)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 21 Jan 2019 11:11:22 +0000
> From: Nemanja Marjanovic <nemanja.marjanovic@intel.com>
> To: dev@dpdk.org
> Cc: jasvinder.singh@intel.com, cristian.dumitrescu@intel.com, "Nemanja
> Marjanovic" <nemanja.marjanovic@intel.com>
> Subject: [dpdk-dev] [PATCH v6 2/4] examples/ip_pipeline: support QinQ
> PPPoE encap
> Message-ID: <20190121111124.16362-2-nemanja.marjanovic@intel.com>
>
> From: "Nemanja Marjanovic" <nemanja.marjanovic@intel.com>
>
> Add implementation of QinQ PPPoE packet encapsulation action.
>
> Signed-off-by: Nemanja Marjanovic <nemanja.marjanovic@intel.com>
> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> ---
> v5:Removing footer from patch.
> v6:Added missing acks.
> ---
> examples/ip_pipeline/cli.c | 46 ++++++++++++++++++++++++++++++++++++--
> 1 file changed, 44 insertions(+), 2 deletions(-)
>
> diff --git a/examples/ip_pipeline/cli.c b/examples/ip_pipeline/cli.c
> index 910386282..dd05393ef 100644
> --- a/examples/ip_pipeline/cli.c
> +++ b/examples/ip_pipeline/cli.c
> @@ -1022,7 +1022,7 @@ static const char cmd_table_action_profile_help[] =
> " tc <n_tc>\n"
> " stats none | pkts | bytes | both]\n"
> " [tm spp <n_subports_per_port> pps <n_pipes_per_subport>]\n"
> -" [encap ether | vlan | qinq | mpls | pppoe |\n"
> +" [encap ether | vlan | qinq | mpls | pppoe | qinq_pppoe \n"
> " vxlan offset <ether_offset> ipv4 | ipv6 vlan on | off]\n"
> " [nat src | dst\n"
> " proto udp | tcp]\n"
> @@ -1290,7 +1290,10 @@ cmd_table_action_profile(char **tokens,
>
> p.encap.encap_mask = 1LLU <<
> RTE_TABLE_ACTION_ENCAP_VXLAN;
> n_extra_tokens = 5;
> - } else {
> + } else if (strcmp(tokens[t0 + 1], "qinq_pppoe") == 0)
> + p.encap.encap_mask =
> + 1LLU << RTE_TABLE_ACTION_ENCAP_QINQ_PPPOE;
> + else {
> snprintf(out, out_size, MSG_ARG_MISMATCH, "encap");
> return;
> }
> @@ -3090,6 +3093,7 @@ parse_match(char **tokens,
> * ether <da> <sa>
> * | vlan <da> <sa> <pcp> <dei> <vid>
> * | qinq <da> <sa> <pcp> <dei> <vid> <pcp> <dei> <vid>
> + * | qinq_pppoe <da> <sa> <pcp> <dei> <vid> <pcp> <dei> <vid>
> <session_id>
> * | mpls unicast | multicast
> * <da> <sa>
> * label0 <label> <tc> <ttl>
> @@ -3391,6 +3395,44 @@ parse_table_action_encap(char **tokens,
> return 1 + 9;
> }
>
> + /* qinq_pppoe */
> + if (n_tokens && (strcmp(tokens[0], "qinq_pppoe") == 0)) {
> + uint32_t svlan_pcp, svlan_dei, svlan_vid;
> + uint32_t cvlan_pcp, cvlan_dei, cvlan_vid;
> +
> + if ((n_tokens < 10) ||
> + parse_mac_addr(tokens[1],
> + &a->encap.qinq_pppoe.ether.da) ||
> + parse_mac_addr(tokens[2],
> + &a->encap.qinq_pppoe.ether.sa) ||
> + parser_read_uint32(&svlan_pcp, tokens[3]) ||
> + (svlan_pcp > 0x7) ||
> + parser_read_uint32(&svlan_dei, tokens[4]) ||
> + (svlan_dei > 0x1) ||
> + parser_read_uint32(&svlan_vid, tokens[5]) ||
> + (svlan_vid > 0xFFF) ||
> + parser_read_uint32(&cvlan_pcp, tokens[6]) ||
> + (cvlan_pcp > 0x7) ||
> + parser_read_uint32(&cvlan_dei, tokens[7]) ||
> + (cvlan_dei > 0x1) ||
> + parser_read_uint32(&cvlan_vid, tokens[8]) ||
> + (cvlan_vid > 0xFFF) ||
> +
> parser_read_uint16(&a->encap.qinq_pppoe.pppoe.session_id,
> + tokens[9]))
> + return 0;
> +
> + a->encap.qinq_pppoe.svlan.pcp = svlan_pcp & 0x7;
> + a->encap.qinq_pppoe.svlan.dei = svlan_dei & 0x1;
> + a->encap.qinq_pppoe.svlan.vid = svlan_vid & 0xFFF;
> + a->encap.qinq_pppoe.cvlan.pcp = cvlan_pcp & 0x7;
> + a->encap.qinq_pppoe.cvlan.dei = cvlan_dei & 0x1;
> + a->encap.qinq_pppoe.cvlan.vid = cvlan_vid & 0xFFF;
> + a->encap.type = RTE_TABLE_ACTION_ENCAP_QINQ_PPPOE;
> + a->action_mask |= 1 << RTE_TABLE_ACTION_ENCAP;
> + return 1 + 10;
> +
> + }
> +
> /* mpls */
> if (n_tokens && (strcmp(tokens[0], "mpls") == 0)) {
> uint32_t label, tc, ttl;
> --
> 2.17.1
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 21 Jan 2019 11:11:21 +0000
> From: Nemanja Marjanovic <nemanja.marjanovic@intel.com>
> To: dev@dpdk.org
> Cc: jasvinder.singh@intel.com, cristian.dumitrescu@intel.com, "Nemanja
> Marjanovic" <nemanja.marjanovic@intel.com>
> Subject: [dpdk-dev] [PATCH v6 1/4] pipeline: support QinQ PPPoE encap
> Message-ID: <20190121111124.16362-1-nemanja.marjanovic@intel.com>
>
> From: "Nemanja Marjanovic" <nemanja.marjanovic@intel.com>
>
> Add support of QinQ PPPoE packet encapsulation action.
>
> Signed-off-by: Nemanja Marjanovic <nemanja.marjanovic@intel.com>
> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> ---
> v5:Removing footer from patch.
> v6:Added missing acks.
> ---
> lib/librte_pipeline/rte_table_action.c | 61 ++++++++++++++++++++++++++
> lib/librte_pipeline/rte_table_action.h | 16 +++++++
> 2 files changed, 77 insertions(+)
>
> diff --git a/lib/librte_pipeline/rte_table_action.c
> b/lib/librte_pipeline/rte_table_action.c
> index 7c7c8dd82..466019934 100644
> --- a/lib/librte_pipeline/rte_table_action.c
> +++ b/lib/librte_pipeline/rte_table_action.c
> @@ -432,6 +432,7 @@ encap_valid(enum rte_table_action_encap_type encap)
> case RTE_TABLE_ACTION_ENCAP_MPLS:
> case RTE_TABLE_ACTION_ENCAP_PPPOE:
> case RTE_TABLE_ACTION_ENCAP_VXLAN:
> + case RTE_TABLE_ACTION_ENCAP_QINQ_PPPOE:
> return 1;
> default:
> return 0;
> @@ -532,6 +533,13 @@ struct encap_vxlan_ipv6_vlan_data {
> struct vxlan_hdr vxlan;
> } __attribute__((__packed__));
>
> +struct encap_qinq_pppoe_data {
> + struct ether_hdr ether;
> + struct vlan_hdr svlan;
> + struct vlan_hdr cvlan;
> + struct pppoe_ppp_hdr pppoe_ppp;
> +} __attribute__((__packed__));
> +
> static size_t
> encap_data_size(struct rte_table_action_encap_config *encap)
> {
> @@ -563,6 +571,9 @@ encap_data_size(struct rte_table_action_encap_config
> *encap)
> else
> return sizeof(struct
> encap_vxlan_ipv6_data);
>
> + case 1LLU << RTE_TABLE_ACTION_ENCAP_QINQ_PPPOE:
> + return sizeof(struct encap_qinq_pppoe_data);
> +
> default:
> return 0;
> }
> @@ -599,6 +610,9 @@ encap_apply_check(struct rte_table_action_encap_params
> *p,
> case RTE_TABLE_ACTION_ENCAP_VXLAN:
> return 0;
>
> + case RTE_TABLE_ACTION_ENCAP_QINQ_PPPOE:
> + return 0;
> +
> default:
> return -EINVAL;
> }
> @@ -676,6 +690,38 @@ encap_qinq_apply(void *data,
> return 0;
> }
>
> +static int
> +encap_qinq_pppoe_apply(void *data,
> + struct rte_table_action_encap_params *p)
> +{
> + struct encap_qinq_pppoe_data *d = data;
> +
> + /* Ethernet */
> + ether_addr_copy(&p->qinq.ether.da, &d->ether.d_addr);
> + ether_addr_copy(&p->qinq.ether.sa, &d->ether.s_addr);
> + d->ether.ether_type = rte_htons(ETHER_TYPE_VLAN);
> +
> + /* SVLAN */
> + d->svlan.vlan_tci = rte_htons(VLAN(p->qinq.svlan.pcp,
> + p->qinq.svlan.dei,
> + p->qinq.svlan.vid));
> + d->svlan.eth_proto = rte_htons(ETHER_TYPE_VLAN);
> +
> + /* CVLAN */
> + d->cvlan.vlan_tci = rte_htons(VLAN(p->qinq.cvlan.pcp,
> + p->qinq.cvlan.dei,
> + p->qinq.cvlan.vid));
> + d->cvlan.eth_proto = rte_htons(ETHER_TYPE_PPPOE_SESSION);
> +
> + /* PPPoE and PPP*/
> + d->pppoe_ppp.ver_type_code = rte_htons(0x1100);
> + d->pppoe_ppp.session_id =
> rte_htons(p->qinq_pppoe.pppoe.session_id);
> + d->pppoe_ppp.length = 0; /* not pre-computed */
> + d->pppoe_ppp.protocol = rte_htons(PPP_PROTOCOL_IP);
> +
> + return 0;
> +}
> +
> static int
> encap_mpls_apply(void *data,
> struct rte_table_action_encap_params *p)
> @@ -921,6 +967,9 @@ encap_apply(void *data,
> case RTE_TABLE_ACTION_ENCAP_VXLAN:
> return encap_vxlan_apply(data, p, cfg);
>
> + case RTE_TABLE_ACTION_ENCAP_QINQ_PPPOE:
> + return encap_qinq_pppoe_apply(data, p);
> +
> default:
> return -EINVAL;
> }
> @@ -1119,6 +1168,18 @@ pkt_work_encap(struct rte_mbuf *mbuf,
> break;
> }
>
> + case 1LLU << RTE_TABLE_ACTION_ENCAP_QINQ_PPPOE:
> + {
> + struct encap_qinq_pppoe_data *qinq_pppoe =
> + encap(ip, data, sizeof(struct
> encap_qinq_pppoe_data));
> + qinq_pppoe->pppoe_ppp.length = rte_htons(total_length + 2);
> + mbuf->data_off = ip_offset - (sizeof(struct rte_mbuf) +
> + sizeof(struct encap_qinq_pppoe_data));
> + mbuf->pkt_len = mbuf->data_len = total_length +
> + sizeof(struct encap_qinq_pppoe_data);
> + break;
> + }
> +
> case 1LLU << RTE_TABLE_ACTION_ENCAP_VXLAN:
> {
> if (cfg->vxlan.ip_version)
> diff --git a/lib/librte_pipeline/rte_table_action.h
> b/lib/librte_pipeline/rte_table_action.h
> index c96061291..53d16af8a 100644
> --- a/lib/librte_pipeline/rte_table_action.h
> +++ b/lib/librte_pipeline/rte_table_action.h
> @@ -380,6 +380,9 @@ enum rte_table_action_encap_type {
> * Ether -> { Ether | VLAN | IP | UDP | VXLAN | Ether }
> */
> RTE_TABLE_ACTION_ENCAP_VXLAN,
> +
> + /** IP -> { Ether | S-VLAN | C-VLAN | PPPoE | PPP | IP } */
> + RTE_TABLE_ACTION_ENCAP_QINQ_PPPOE,
> };
>
> /** Pre-computed Ethernet header fields for encapsulation action. */
> @@ -529,6 +532,16 @@ struct rte_table_action_encap_config {
> };
> };
>
> +/** QinQ_PPPoE encap paramaeters. */
> +struct rte_table_encap_ether_qinq_pppoe {
> +
> + /** Only valid when *type* is set to QinQ. */
> + struct rte_table_action_ether_hdr ether;
> + struct rte_table_action_vlan_hdr svlan; /**< Service VLAN header.
> */
> + struct rte_table_action_vlan_hdr cvlan; /**< Customer VLAN header.
> */
> + struct rte_table_action_pppoe_hdr pppoe; /**< PPPoE/PPP headers. */
> +};
> +
> /** Encap action parameters (per table rule). */
> struct rte_table_action_encap_params {
> /** Encapsulation type. */
> @@ -553,6 +566,9 @@ struct rte_table_action_encap_params {
>
> /** Only valid when *type* is set to VXLAN. */
> struct rte_table_action_encap_vxlan_params vxlan;
> +
> + /** Only valid when *type* is set to QinQ_PPPoE. */
> + struct rte_table_encap_ether_qinq_pppoe qinq_pppoe;
> };
> };
>
> --
> 2.17.1
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 21 Jan 2019 11:11:23 +0000
> From: Nemanja Marjanovic <nemanja.marjanovic@intel.com>
> To: dev@dpdk.org
> Cc: jasvinder.singh@intel.com, cristian.dumitrescu@intel.com, "Nemanja
> Marjanovic" <nemanja.marjanovic@intel.com>
> Subject: [dpdk-dev] [PATCH v6 3/4] net/softnic: support QinQ PPPoE
> encap
> Message-ID: <20190121111124.16362-3-nemanja.marjanovic@intel.com>
>
> From: "Nemanja Marjanovic" <nemanja.marjanovic@intel.com>
>
> Add implementation of QinQ PPPoE packet encapsulation action.
>
> Signed-off-by: Nemanja Marjanovic <nemanja.marjanovic@intel.com>
> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> ---
> v5:Removing footer from patch.
> v6:Added missing acks.
> ---
> drivers/net/softnic/rte_eth_softnic_cli.c | 44 ++++++++++++++++++++++-
> 1 file changed, 43 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/softnic/rte_eth_softnic_cli.c
> b/drivers/net/softnic/rte_eth_softnic_cli.c
> index 57b623377..c15b57b5b 100644
> --- a/drivers/net/softnic/rte_eth_softnic_cli.c
> +++ b/drivers/net/softnic/rte_eth_softnic_cli.c
> @@ -1335,7 +1335,7 @@ cmd_port_in_action_profile(struct pmd_internals
> *softnic,
> * tc <n_tc>
> * stats none | pkts | bytes | both]
> * [tm spp <n_subports_per_port> pps <n_pipes_per_subport>]
> - * [encap ether | vlan | qinq | mpls | pppoe |
> + * [encap ether | vlan | qinq | mpls | pppoe | qinq_pppoe |
> * vxlan offset <ether_offset> ipv4 | ipv6 vlan on | off]
> * [nat src | dst
> * proto udp | tcp]
> @@ -1612,10 +1612,14 @@ cmd_table_action_profile(struct pmd_internals
> *softnic,
> p.encap.encap_mask = 1LLU <<
> RTE_TABLE_ACTION_ENCAP_VXLAN;
> n_extra_tokens = 5;
>
> + } else if (strcmp(tokens[t0 + 1], "qinq_pppoe") == 0) {
> + p.encap.encap_mask =
> + 1LLU << RTE_TABLE_ACTION_ENCAP_QINQ_PPPOE;
> } else {
> snprintf(out, out_size, MSG_ARG_MISMATCH, "encap");
> return;
> }
> +
> p.action_mask |= 1LLU << RTE_TABLE_ACTION_ENCAP;
> t0 += 2 + n_extra_tokens;
> } /* encap */
> @@ -3353,6 +3357,7 @@ parse_match(char **tokens,
> * ether <da> <sa>
> * | vlan <da> <sa> <pcp> <dei> <vid>
> * | qinq <da> <sa> <pcp> <dei> <vid> <pcp> <dei> <vid>
> + * | qinq_pppoe <da> <sa> <pcp> <dei> <vid> <pcp> <dei> <vid>
> <session_id>
> * | mpls unicast | multicast
> * <da> <sa>
> * label0 <label> <tc> <ttl>
> @@ -3658,6 +3663,43 @@ parse_table_action_encap(char **tokens,
> return 1 + 9;
> }
>
> + /* qinq_pppoe */
> + if (n_tokens && (strcmp(tokens[0], "qinq_pppoe") == 0)) {
> + uint32_t svlan_pcp, svlan_dei, svlan_vid;
> + uint32_t cvlan_pcp, cvlan_dei, cvlan_vid;
> +
> + if (n_tokens < 10 ||
> + softnic_parse_mac_addr(tokens[1],
> + &a->encap.qinq_pppoe.ether.da) ||
> + softnic_parse_mac_addr(tokens[2],
> + &a->encap.qinq_pppoe.ether.sa) ||
> + softnic_parser_read_uint32(&svlan_pcp, tokens[3])
> ||
> + svlan_pcp > 0x7 ||
> + softnic_parser_read_uint32(&svlan_dei, tokens[4])
> ||
> + svlan_dei > 0x1 ||
> + softnic_parser_read_uint32(&svlan_vid, tokens[5])
> ||
> + svlan_vid > 0xFFF ||
> + softnic_parser_read_uint32(&cvlan_pcp, tokens[6])
> ||
> + cvlan_pcp > 0x7 ||
> + softnic_parser_read_uint32(&cvlan_dei, tokens[7])
> ||
> + cvlan_dei > 0x1 ||
> + softnic_parser_read_uint32(&cvlan_vid, tokens[8])
> ||
> + cvlan_vid > 0xFFF ||
> +
> softnic_parser_read_uint16(&a->encap.qinq_pppoe.pppoe.session_id,
> + tokens[9]))
> + return 0;
> +
> + a->encap.qinq_pppoe.svlan.pcp = svlan_pcp & 0x7;
> + a->encap.qinq_pppoe.svlan.dei = svlan_dei & 0x1;
> + a->encap.qinq_pppoe.svlan.vid = svlan_vid & 0xFFF;
> + a->encap.qinq_pppoe.cvlan.pcp = cvlan_pcp & 0x7;
> + a->encap.qinq_pppoe.cvlan.dei = cvlan_dei & 0x1;
> + a->encap.qinq_pppoe.cvlan.vid = cvlan_vid & 0xFFF;
> + a->encap.type = RTE_TABLE_ACTION_ENCAP_QINQ_PPPOE;
> + a->action_mask |= 1 << RTE_TABLE_ACTION_ENCAP;
> + return 1 + 10;
> + }
> +
> /* mpls */
> if (n_tokens && (strcmp(tokens[0], "mpls") == 0)) {
> uint32_t label, tc, ttl;
> --
> 2.17.1
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 21 Jan 2019 11:11:24 +0000
> From: Nemanja Marjanovic <nemanja.marjanovic@intel.com>
> To: dev@dpdk.org
> Cc: jasvinder.singh@intel.com, cristian.dumitrescu@intel.com, "Nemanja
> Marjanovic" <nemanja.marjanovic@intel.com>
> Subject: [dpdk-dev] [PATCH v6 4/4] net: add PPPoE ethertypes
> Message-ID: <20190121111124.16362-4-nemanja.marjanovic@intel.com>
>
> From: "Nemanja Marjanovic" <nemanja.marjanovic@intel.com>
>
> Add PPPoE ethertypes in to rte_ether.h.
>
> Signed-off-by: Nemanja Marjanovic <nemanja.marjanovic@intel.com>
> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> ---
> v5:Removing footer from patch.
> v6:Added missing acks.
> ---
> lib/librte_net/rte_ether.h | 2 ++
> lib/librte_pipeline/rte_table_action.c | 2 --
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lib/librte_net/rte_ether.h b/lib/librte_net/rte_ether.h
> index c2c5e249f..54822df75 100644
> --- a/lib/librte_net/rte_ether.h
> +++ b/lib/librte_net/rte_ether.h
> @@ -301,6 +301,8 @@ struct vxlan_hdr {
> #define ETHER_TYPE_RARP 0x8035 /**< Reverse Arp Protocol. */
> #define ETHER_TYPE_VLAN 0x8100 /**< IEEE 802.1Q VLAN tagging. */
> #define ETHER_TYPE_QINQ 0x88A8 /**< IEEE 802.1ad QinQ tagging. */
> +#define ETHER_TYPE_PPPOE_DISCOVERY 0x8863 /**< PPPoE Discovery Stage. */
> +#define ETHER_TYPE_PPPOE_SESSION 0x8864 /**< PPPoE Session Stage. */
> #define ETHER_TYPE_ETAG 0x893F /**< IEEE 802.1BR E-Tag. */
> #define ETHER_TYPE_1588 0x88F7 /**< IEEE 802.1AS 1588 Precise Time
> Protocol. */
> #define ETHER_TYPE_SLOW 0x8809 /**< Slow protocols (LACP and Marker). */
> diff --git a/lib/librte_pipeline/rte_table_action.c
> b/lib/librte_pipeline/rte_table_action.c
> index 466019934..ac8109f00 100644
> --- a/lib/librte_pipeline/rte_table_action.c
> +++ b/lib/librte_pipeline/rte_table_action.c
> @@ -485,8 +485,6 @@ struct encap_mpls_data {
> uint32_t mpls_count;
> } __attribute__((__packed__));
>
> -#define ETHER_TYPE_PPPOE_SESSION 0x8864
> -
> #define PPP_PROTOCOL_IP 0x0021
>
> struct pppoe_ppp_hdr {
> --
> 2.17.1
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 21 Jan 2019 11:39:09 +0000
> From: Mohammad Abdul Awal <mohammad.abdul.awal@intel.com>
> To: Reshma Pattan <reshma.pattan@intel.com>, dev@dpdk.org
> Cc: jasvinder.singh@intel.com
> Subject: Re: [dpdk-dev] [PATCH] doc: add deprecation notice to remove
> rte meter color
> Message-ID: <398165c5-c5c3-dcc3-a9ef-d688f94db81c@intel.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
>
> On 12/12/2018 16:38, Reshma Pattan wrote:
> > Added deprecation notice to replace rte_meter_color
> > with rte_color.
> >
> > Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> > Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> > ---
> > doc/guides/rel_notes/deprecation.rst | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> > index b48486d36..bf1fdf369 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -105,3 +105,8 @@ Deprecation Notices
> > - ``rte_pdump_set_socket_dir`` will be removed;
> > - The parameter, ``path``, of ``rte_pdump_init`` will be removed;
> > - The enum ``rte_pdump_socktype`` will be removed.
> > +
> > +* 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.
> Acked-by: Mohammad Abdul Awal <mohammad.abdul.awal@intel.com>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 21 Jan 2019 11:43:59 +0000
> From: "Van Haaren, Harry" <harry.van.haaren@intel.com>
> To: "Rao, Nikhil" <nikhil.rao@intel.com>
> Cc: "dev@dpdk.org" <dev@dpdk.org>
> Subject: Re: [dpdk-dev] [PATCH] service: fix parameter type
> Message-ID:
> <
> E923DB57A917B54B9182A2E928D00FA6757C579E@IRSMSX102.ger.corp.intel.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> > -----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.
>
> Thanks for the fixup, -Harry
>
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 21 Jan 2019 13:43:55 +0100
> From: Maxime Coquelin <maxime.coquelin@redhat.com>
> To: Tiwei Bie <tiwei.bie@intel.com>, zhihong.wang@intel.com,
> dev@dpdk.org
> Cc: haiyue.wang@intel.com, stable@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] vhost: fix possible out of bound
> access for indirect descs
> Message-ID: <1173420b-78cf-ba5b-c2f5-54ab47d0792f@redhat.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
>
>
> On 1/21/19 9:12 AM, Tiwei Bie wrote:
> > Fix a possible out of bound access which may happen when handling
> > indirect descs in split ring.
> >
> > Fixes: 1be4ebb1c464 ("vhost: support indirect descriptor in mergeable
> Rx")
> > Cc: stable@dpdk.org
> >
> > Reported-by: Haiyue Wang <haiyue.wang@intel.com>
> > Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>
> > ---
> > lib/librte_vhost/virtio_net.c | 8 ++------
> > 1 file changed, 2 insertions(+), 6 deletions(-)
> >
>
>
> Applide to dpdk-next-virtio/master.
>
> Thanks,
> Maxime
>
>
>
> ------------------------------
>
> Message: 8
> Date: Mon, 21 Jan 2019 13:18:57 +0000
> From: "Hu, Xuekun" <xuekun.hu@intel.com>
> To: "Burakov, Anatoly" <anatoly.burakov@intel.com>, Ravi Kerur
> <rkerur@gmail.com>
> Cc: "dev@dpdk.org" <dev@dpdk.org>, "Ananyev, Konstantin"
> <konstantin.ananyev@intel.com>, "Lu, Wenzhuo" <
> wenzhuo.lu@intel.com>
> Subject: Re: [dpdk-dev] IXGBE, IOMMU DMAR DRHD handling fault issue
> Message-ID:
> <
> 88A92D351643BA4CB23E30315517062663547499@SHSMSX103.ccr.corp.intel.com>
>
> Content-Type: text/plain; charset="utf-8"
>
>
> > You might also want to look here:
> https://bugs.dpdk.org/show_bug.cgi?id=76
>
> > There are apparently issues with some kernel versions that will manifest
> themselves as problems with using VF devices with IOMMU in a VM.
>
> Thanks, Anatoly. By updating host kernel to 4.18, the issue is gone. ?
>
> End of dev Digest, Vol 231, Issue 6
> ***********************************
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] service: fix parameter type
2019-01-19 14:01 3% [dpdk-dev] [PATCH] service: fix parameter type Nikhil Rao
@ 2019-01-21 11:43 3% ` 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
2 siblings, 1 reply; 200+ results
From: Van Haaren, Harry @ 2019-01-21 11:43 UTC (permalink / raw)
To: Rao, Nikhil; +Cc: dev
> -----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.
Thanks for the fixup, -Harry
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH] service: fix parameter type
@ 2019-01-19 14:01 3% Nikhil Rao
2019-01-21 11:43 3% ` Van Haaren, Harry
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Nikhil Rao @ 2019-01-19 14:01 UTC (permalink / raw)
To: harry.van.haaren; +Cc: 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>
---
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.
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),
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v3] doc: announce ring API change
2019-01-18 15:28 3% ` [dpdk-dev] [PATCH v2] doc: announce ring API change Gage Eads
@ 2019-01-18 15:31 3% ` Gage Eads
2019-02-01 14:36 3% ` [dpdk-dev] [PATCH v4] " Gage Eads
0 siblings, 1 reply; 200+ results
From: Gage Eads @ 2019-01-18 15:31 UTC (permalink / raw)
To: dev
Cc: olivier.matz, arybchenko, bruce.richardson, konstantin.ananyev, stephen
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.05.
[1] http://mails.dpdk.org/archives/dev/2019-January/123774.html
Signed-off-by: Gage Eads <gage.eads@intel.com>
---
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..91e048a6a 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.05:
+
+ - 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 v2] doc: announce ring API change
2019-01-15 23:59 7% [dpdk-dev] [PATCH] doc: announce ring ABI and API changes Gage Eads
2019-01-16 0:34 7% ` Stephen Hemminger
@ 2019-01-18 15:28 3% ` Gage Eads
2019-01-18 15:31 3% ` [dpdk-dev] [PATCH v3] " Gage Eads
1 sibling, 1 reply; 200+ results
From: Gage Eads @ 2019-01-18 15:28 UTC (permalink / raw)
To: dev
Cc: olivier.matz, arybchenko, bruce.richardson, konstantin.ananyev, stephen
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.05.
[1] http://mails.dpdk.org/archives/dev/2019-January/123774.html
Signed-off-by: Gage Eads <gage.eads@intel.com>
---
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..5b74a2aa7 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: two changes are planned for rte_ring in v19.05:
+
+ - 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 1/5] ring: add 64-bit headtail structure
2019-01-18 15:23 3% ` [dpdk-dev] [PATCH v3 " Gage Eads
@ 2019-01-18 15:23 2% ` Gage Eads
2019-01-22 9:27 0% ` [dpdk-dev] [PATCH v3 0/5] Add non-blocking ring Ola Liljedahl
` (2 subsequent siblings)
3 siblings, 0 replies; 200+ results
From: Gage Eads @ 2019-01-18 15:23 UTC (permalink / raw)
To: dev
Cc: olivier.matz, arybchenko, bruce.richardson, konstantin.ananyev, stephen
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 important in 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_eventdev/rte_event_ring.h | 2 +-
lib/librte_ring/Makefile | 3 +-
lib/librte_ring/rte_ring.h | 24 +++++-
lib/librte_ring/rte_ring_generic_64.h | 152 ++++++++++++++++++++++++++++++++++
4 files changed, 176 insertions(+), 5 deletions(-)
create mode 100644 lib/librte_ring/rte_ring_generic_64.h
diff --git a/lib/librte_eventdev/rte_event_ring.h b/lib/librte_eventdev/rte_event_ring.h
index 827a3209e..5fcb2d5f7 100644
--- a/lib/librte_eventdev/rte_event_ring.h
+++ b/lib/librte_eventdev/rte_event_ring.h
@@ -1,5 +1,5 @@
/* SPDX-License-Identifier: BSD-3-Clause
- * Copyright(c) 2016-2017 Intel Corporation
+ * Copyright(c) 2016-2019 Intel Corporation
*/
/**
diff --git a/lib/librte_ring/Makefile b/lib/librte_ring/Makefile
index 21a36770d..18c48fbc8 100644
--- a/lib/librte_ring/Makefile
+++ b/lib/librte_ring/Makefile
@@ -19,6 +19,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_RING) := rte_ring.c
# install includes
SYMLINK-$(CONFIG_RTE_LIBRTE_RING)-include := rte_ring.h \
rte_ring_generic.h \
- rte_ring_c11_mem.h
+ rte_ring_c11_mem.h \
+ rte_ring_generic_64.h
include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
index af5444a9f..b270a4746 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 */
};
@@ -312,6 +329,7 @@ void rte_ring_dump(FILE *f, const struct rte_ring *r);
#else
#include "rte_ring_generic.h"
#endif
+#include "rte_ring_generic_64.h"
/**
* @internal Enqueue several objects on the ring
diff --git a/lib/librte_ring/rte_ring_generic_64.h b/lib/librte_ring/rte_ring_generic_64.h
new file mode 100644
index 000000000..58de144c6
--- /dev/null
+++ b/lib/librte_ring/rte_ring_generic_64.h
@@ -0,0 +1,152 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ *
+ * Copyright (c) 2010-2019 Intel Corporation
+ * Copyright (c) 2007-2009 Kip Macy kmacy@freebsd.org
+ * All rights reserved.
+ * Derived from FreeBSD's bufring.h
+ * Used as BSD-3 Licensed with permission from Kip Macy.
+ */
+
+#ifndef _RTE_RING_GENERIC_64_H_
+#define _RTE_RING_GENERIC_64_H_
+
+/**
+ * @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_64_H_ */
--
2.13.6
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v3 0/5] Add non-blocking ring
2019-01-15 23:52 3% ` [dpdk-dev] [PATCH v2 0/5] Add non-blocking ring Gage Eads
2019-01-16 0:26 3% ` Stephen Hemminger
@ 2019-01-18 15:23 3% ` Gage Eads
2019-01-18 15:23 2% ` [dpdk-dev] [PATCH v3 1/5] ring: add 64-bit headtail structure Gage Eads
` (3 more replies)
1 sibling, 4 replies; 200+ results
From: Gage Eads @ 2019-01-18 15:23 UTC (permalink / raw)
To: dev
Cc: olivier.matz, arybchenko, bruce.richardson, konstantin.ananyev, stephen
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 3%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for cryptodev config
2019-01-17 13:47 4% ` Anoob Joseph
@ 2019-01-18 6:59 4% ` Shally Verma
2019-01-22 9:31 4% ` Anoob Joseph
0 siblings, 1 reply; 200+ results
From: Shally Verma @ 2019-01-18 6:59 UTC (permalink / raw)
To: Anoob Joseph, Trahe, Fiona, Akhil Goyal, De Lara Guarch, Pablo
Cc: Jerin Jacob Kollanukkaran, Narayana Prasad Raju Athreya, dev
HI Fiona, Anoob
>-----Original Message-----
>From: Anoob Joseph
>Sent: 17 January 2019 19:17
>To: Trahe, Fiona <fiona.trahe@intel.com>; Akhil Goyal <akhil.goyal@nxp.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>; Shally Verma
><shallyv@marvell.com>; dev@dpdk.org
>Subject: RE: [PATCH] doc: announce ABI change for cryptodev config
>
>Hi Fiona,
>
>Please see inline.
>
>Thanks,
>Anoob
>
>> -----Original Message-----
>> From: Trahe, Fiona <fiona.trahe@intel.com>
>> Sent: 17 January 2019 17:07
>> To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal <akhil.goyal@nxp.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>; Shally Verma <shallyv@marvell.com>;
>> dev@dpdk.org; Trahe, Fiona <fiona.trahe@intel.com>
>> Subject: RE: [PATCH] doc: announce ABI change for cryptodev config
>>
>> Hi Joseph,
>>
>> > -----Original Message-----
>> > From: Anoob Joseph [mailto:anoobj@marvell.com]
>> > Sent: Thursday, January 17, 2019 9:40 AM
>> > To: Akhil Goyal <akhil.goyal@nxp.com>; De Lara Guarch, Pablo
>> > <pablo.de.lara.guarch@intel.com>; Trahe, Fiona <fiona.trahe@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>;
>> > dev@dpdk.org
>> > Subject: [PATCH] doc: announce ABI change for cryptodev config
>> >
>> > 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.
>> [Fiona] I'm unfamiliar with eth config so can you explain a bit more how this
>> works?
>
>[Anoob] For eth devices, application would first do rte_eth_dev_info_get() and gets the capabilities. The device would expose it's
>capabilities using dev_info.rx_offload_capa & dev_info.tx_offload_capa. The application can enable/disable these features while
>configuring the eth ports.
>
>From ipsec-secgw:
>https://git.dpdk.org/dpdk/tree/examples/ipsec-secgw/ipsec-secgw.c#n1866
>
>if (frame_size) {
> local_port_conf.rxmode.max_rx_pkt_len = frame_size;
> local_port_conf.rxmode.offloads |= DEV_RX_OFFLOAD_JUMBO_FRAME;
> }
>
><snip>
>
>ret = rte_eth_dev_configure(portid, nb_rx_queue, nb_tx_queue,
> &local_port_conf);
>
><snip>
>
>This way application can choose to disable unwanted offloads.
>
>Port init in ipsec-secgw: https://git.dpdk.org/dpdk/tree/examples/ipsec-secgw/ipsec-secgw.c#n1826
>
>> e.g. if a crypto device's info says it supports
>> RTE_CRYPTODEV_FF_SYMMETRIC_CRYPTO
>> RTE_CRYPTODEV_FF_SYM_OPERATION_CHAINING
>> RTE_CRYPTODEV_FF_CPU_AESNI
>> RTE_CRYPTODEV_FF_SECURITY
>> RTE_CRYPTODEV_FF_OOP_LB_IN_LB_OUT
>> these things are all already enabled.
>> Is the param a way to disable some of them?
>
>[Anoob] Yes. There are few other flags in addition to the above. Like RTE_CRYPTODEV_FF_ASYMMETRIC_CRYPTO.
>
>> If so, it would be better to call it ff_disable.
>
>[Anoob] Calling it ff_enable is to make it similar to how it's done with eth devices. Either way should be fine.
[Shally] keeping it as "ff_enable" will require application to set these flags to configure PMD. If we define it other way around, then it would be mean to mask out unwanted features which can be quite many.
Though purpose can be achieved both ways but keeping it as "enable" looks more easy to use, readable and inline with how ethdev handle multi feature support.
So I would prefer to keep it as "ff_enable"
Thanks
Shally
>
>> And to limit it to the subset of features that it makes sense to disable.
>> i.e. why would an application disable chaining or any of the SGL flags? It would
>> just add extra cycles in the PMD to error check on these cases, instead the appl
>> can just not send such commands.
>> And it doesn't make sense to disable AESNI or
>> RTE_CRYPTODEV_FF_HW_ACCELERATED.
>> Actually I can't see what an application would want to achieve by disabling any
>> flag?
>
>[Anoob] Features like ASYMMETRIC or SECURITY is not required for every application. SECURITY is added for eth devices also. But
>since the feature can be disabled while configuring the port, applications are given a choice to disable it. That way apps like l2fwd
>doesn't enable SECURITY. With crypto this option is not available.
>
>If the unused offloads can be communicated to the PMD before initialization, the PMD will be allowed to optimize hardware usage.
>Otherwise, supporting more features would affect performance, even if application is not making use of those features.
>
>Ex: test-crypto-perf doesn't use ASYM/SECURITY. Now adding these features would affect the performance of this app.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for cryptodev config
2019-01-17 11:37 4% ` Trahe, Fiona
@ 2019-01-17 13:47 4% ` Anoob Joseph
2019-01-18 6:59 4% ` Shally Verma
0 siblings, 1 reply; 200+ results
From: Anoob Joseph @ 2019-01-17 13:47 UTC (permalink / raw)
To: Trahe, Fiona, Akhil Goyal, De Lara Guarch, Pablo
Cc: Jerin Jacob Kollanukkaran, Narayana Prasad Raju Athreya,
Shally Verma, dev
Hi Fiona,
Please see inline.
Thanks,
Anoob
> -----Original Message-----
> From: Trahe, Fiona <fiona.trahe@intel.com>
> Sent: 17 January 2019 17:07
> To: Anoob Joseph <anoobj@marvell.com>; Akhil Goyal <akhil.goyal@nxp.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>; Shally Verma <shallyv@marvell.com>;
> dev@dpdk.org; Trahe, Fiona <fiona.trahe@intel.com>
> Subject: RE: [PATCH] doc: announce ABI change for cryptodev config
>
> Hi Joseph,
>
> > -----Original Message-----
> > From: Anoob Joseph [mailto:anoobj@marvell.com]
> > Sent: Thursday, January 17, 2019 9:40 AM
> > To: Akhil Goyal <akhil.goyal@nxp.com>; De Lara Guarch, Pablo
> > <pablo.de.lara.guarch@intel.com>; Trahe, Fiona <fiona.trahe@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>;
> > dev@dpdk.org
> > Subject: [PATCH] doc: announce ABI change for cryptodev config
> >
> > 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.
> [Fiona] I'm unfamiliar with eth config so can you explain a bit more how this
> works?
[Anoob] For eth devices, application would first do rte_eth_dev_info_get() and gets the capabilities. The device would expose it's capabilities using dev_info.rx_offload_capa & dev_info.tx_offload_capa. The application can enable/disable these features while configuring the eth ports.
>From ipsec-secgw:
https://git.dpdk.org/dpdk/tree/examples/ipsec-secgw/ipsec-secgw.c#n1866
if (frame_size) {
local_port_conf.rxmode.max_rx_pkt_len = frame_size;
local_port_conf.rxmode.offloads |= DEV_RX_OFFLOAD_JUMBO_FRAME;
}
<snip>
ret = rte_eth_dev_configure(portid, nb_rx_queue, nb_tx_queue,
&local_port_conf);
<snip>
This way application can choose to disable unwanted offloads.
Port init in ipsec-secgw: https://git.dpdk.org/dpdk/tree/examples/ipsec-secgw/ipsec-secgw.c#n1826
> e.g. if a crypto device's info says it supports
> RTE_CRYPTODEV_FF_SYMMETRIC_CRYPTO
> RTE_CRYPTODEV_FF_SYM_OPERATION_CHAINING
> RTE_CRYPTODEV_FF_CPU_AESNI
> RTE_CRYPTODEV_FF_SECURITY
> RTE_CRYPTODEV_FF_OOP_LB_IN_LB_OUT
> these things are all already enabled.
> Is the param a way to disable some of them?
[Anoob] Yes. There are few other flags in addition to the above. Like RTE_CRYPTODEV_FF_ASYMMETRIC_CRYPTO.
> If so, it would be better to call it ff_disable.
[Anoob] Calling it ff_enable is to make it similar to how it's done with eth devices. Either way should be fine.
> And to limit it to the subset of features that it makes sense to disable.
> i.e. why would an application disable chaining or any of the SGL flags? It would
> just add extra cycles in the PMD to error check on these cases, instead the appl
> can just not send such commands.
> And it doesn't make sense to disable AESNI or
> RTE_CRYPTODEV_FF_HW_ACCELERATED.
> Actually I can't see what an application would want to achieve by disabling any
> flag?
[Anoob] Features like ASYMMETRIC or SECURITY is not required for every application. SECURITY is added for eth devices also. But since the feature can be disabled while configuring the port, applications are given a choice to disable it. That way apps like l2fwd doesn't enable SECURITY. With crypto this option is not available.
If the unused offloads can be communicated to the PMD before initialization, the PMD will be allowed to optimize hardware usage. Otherwise, supporting more features would affect performance, even if application is not making use of those features.
Ex: test-crypto-perf doesn't use ASYM/SECURITY. Now adding these features would affect the performance of this app.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for cryptodev config
2019-01-17 9:39 4% [dpdk-dev] [PATCH] doc: announce ABI change for cryptodev config Anoob Joseph
@ 2019-01-17 11:37 4% ` Trahe, Fiona
2019-01-17 13:47 4% ` Anoob Joseph
2019-01-31 9:53 4% ` Akhil Goyal
2019-03-07 10:39 4% ` [dpdk-dev] [PATCH v2] " Anoob Joseph
2 siblings, 1 reply; 200+ results
From: Trahe, Fiona @ 2019-01-17 11:37 UTC (permalink / raw)
To: Anoob Joseph, Akhil Goyal, De Lara Guarch, Pablo
Cc: Jerin Jacob Kollanukkaran, Narayana Prasad Raju Athreya,
Shally Verma, dev, Trahe, Fiona
Hi Joseph,
> -----Original Message-----
> From: Anoob Joseph [mailto:anoobj@marvell.com]
> Sent: Thursday, January 17, 2019 9:40 AM
> To: Akhil Goyal <akhil.goyal@nxp.com>; De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Trahe,
> Fiona <fiona.trahe@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>; dev@dpdk.org
> Subject: [PATCH] doc: announce ABI change for cryptodev config
>
> 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.
[Fiona] I'm unfamiliar with eth config so can you explain a bit more how this works?
e.g. if a crypto device's info says it supports
RTE_CRYPTODEV_FF_SYMMETRIC_CRYPTO
RTE_CRYPTODEV_FF_SYM_OPERATION_CHAINING
RTE_CRYPTODEV_FF_CPU_AESNI
RTE_CRYPTODEV_FF_SECURITY
RTE_CRYPTODEV_FF_OOP_LB_IN_LB_OUT
these things are all already enabled.
Is the param a way to disable some of them?
If so, it would be better to call it ff_disable.
And to limit it to the subset of features that it makes sense to disable.
i.e. why would an application disable chaining or any of the SGL flags? It would just add extra cycles
in the PMD to error check on these cases, instead the appl can just not send such commands.
And it doesn't make sense to disable AESNI or RTE_CRYPTODEV_FF_HW_ACCELERATED.
Actually I can't see what an application would want to achieve by disabling any flag?
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] doc: announce ABI change for cryptodev config
@ 2019-01-17 9:39 4% Anoob Joseph
2019-01-17 11:37 4% ` Trahe, Fiona
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Anoob Joseph @ 2019-01-17 9:39 UTC (permalink / raw)
To: Akhil Goyal, Pablo de Lara, Fiona Trahe
Cc: Anoob Joseph, Jerin Jacob Kollanukkaran,
Narayana Prasad Raju Athreya, Shally Verma, dev
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>
---
doc/guides/rel_notes/deprecation.rst | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 5f03443..e289c2d 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -66,3 +66,13 @@ 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
+ specify the features to be enabled on the crypto device. For eth devices,
+ applications can use ``rte_eth_conf.rxmode.offloads`` and
+ ``rte_eth_conf.txmode.offloads`` to control the offloads enabled. Adding
+ a similar field to facilitate efficient usage of HW/SW offloads.
+
+ - Member ``uint64_t ff_enable`` in ``rte_cryptodev_config``
+
+ The field would be added in v19.05.
--
2.7.4
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ring ABI and API changes
2019-01-16 0:34 7% ` Stephen Hemminger
@ 2019-01-16 18:21 8% ` Eads, Gage
0 siblings, 0 replies; 200+ results
From: Eads, Gage @ 2019-01-16 18:21 UTC (permalink / raw)
To: Stephen Hemminger
Cc: dev, olivier.matz, arybchenko, Richardson, Bruce, Ananyev, Konstantin
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Tuesday, January 15, 2019 6:34 PM
> To: Eads, Gage <gage.eads@intel.com>
> Cc: dev@dpdk.org; olivier.matz@6wind.com; arybchenko@solarflare.com;
> Richardson, Bruce <bruce.richardson@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>
> Subject: Re: [PATCH] doc: announce ring ABI and API changes
>
> On Tue, 15 Jan 2019 17:59:34 -0600
> Gage Eads <gage.eads@intel.com> wrote:
>
> > In order to support the non-blocking ring[1], one ABI change and one
> > API change are required in librte_ring. This commit updates the
> > deprecation notice to pave the way for their inclusion in 19.05.
> >
> > [1] http://mails.dpdk.org/archives/dev/2019-January/123475.html
> >
> > Signed-off-by: Gage Eads <gage.eads@intel.com>
> > ---
> > doc/guides/rel_notes/deprecation.rst | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/doc/guides/rel_notes/deprecation.rst
> > b/doc/guides/rel_notes/deprecation.rst
> > index d4aea4b46..d74cff467 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -83,3 +83,14 @@ 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: two changes are planned for rte_ring in v19.05:
> > +
> > + - The ring head and tail values are planned to be changed from ``uint32_t``
> > + to ``size_t``. This reduces the likelihood of wrap-around to effectively
> > + zero for 64-bit builds, which is important in avoiding the ABA problem in
> > + the upcoming non-blocking ring implementation. (32-bit builds are
> > + unaffected by this change.)
> > + - 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).
>
>
> Would it be possible to support new and old ring types, either through naming
> tricks and/or new ring flag? Changing things like ring buffer and mbuf are
> basically a flag day for all users.
>
> I admit to having a personal interest in this since the API/ABI churn is this project
> causes vendors to stay on older code. And older code does not correctly support
> newer networks.
Fair enough -- I appreciate the additional context wrt avoiding churn.
This might be doable with the following change:
"
@@ -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 */
};
"
The ABI compatibility hinges on the fact that today's prod and cons are both padded out to a full cache line, and the 64-bit version fits within a single cache line. (Confirmed with pahole.)
abi-compliance-checker reports two issues, but both appear to be false positives:
1. "Field cons has been removed from this type"
2. "Field prod has been removed from this type"
I need to do more work to see whether/how the ring functions are affected by such a change, but I first want to check if the community agrees with this approach. Note that I don't see any way to avoid the API change to rte_ring_get_memsize, but I doubt that would have near the impact of a ring data structure change.
Thanks,
Gage
^ permalink raw reply [relevance 8%]
* [dpdk-dev] [PATCH] doc: increase minimal supported Linux version
@ 2019-01-16 11:45 5% Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-01-16 11:45 UTC (permalink / raw)
To: dev; +Cc: john.mcnamara, marko.kovacevic, Kevin Traynor, Stephen Hemminger
Update the Linux user guide to restrict the supported kernels
to reasonnably recent enough versions.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
Cc: Kevin Traynor <ktraynor@redhat.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
---
doc/guides/linux_gsg/sys_reqs.rst | 10 ++--------
doc/guides/rel_notes/deprecation.rst | 6 ------
2 files changed, 2 insertions(+), 14 deletions(-)
diff --git a/doc/guides/linux_gsg/sys_reqs.rst b/doc/guides/linux_gsg/sys_reqs.rst
index 29c5f47a5..8ec3af491 100644
--- a/doc/guides/linux_gsg/sys_reqs.rst
+++ b/doc/guides/linux_gsg/sys_reqs.rst
@@ -98,22 +98,16 @@ System Software
**Required:**
-* Kernel version >= 3.2
+* Kernel version >= 3.16
The kernel version required is based on the oldest long term stable kernel available
at kernel.org when the DPDK version is in development.
+ Compatibility for recent distribution kernels will be kept, notably RHEL/CentOS 7.
The kernel version in use can be checked using the command::
uname -r
-.. note::
-
- Kernel version 3.2 is no longer a kernel.org longterm stable kernel.
- For DPDK 19.02 the minimum required kernel will be updated to
- the current kernel.org oldest longterm stable supported kernel 3.16,
- or recent versions of common distributions, notably RHEL/CentOS 7.
-
* glibc >= 2.7 (for features related to cpuset)
The version can be checked using the ``ldd --version`` command.
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 5f03443f8..f9a1f8188 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -11,12 +11,6 @@ API and ABI deprecation notices are to be posted here.
Deprecation Notices
-------------------
-* linux: Linux kernel version 3.2 (which is the current minimum required
- version for the DPDK) is not maintained anymore. Therefore the planned
- minimum required kernel version for DPDK 19.02 will be the next oldest
- Long Term Stable (LTS) version which is 3.16, but compatibility for
- recent distribution kernels will be kept.
-
* kvargs: The function ``rte_kvargs_process`` will get a new parameter
for returning key match count. It will ease handling of no-match case.
--
2.20.1
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format for sched field
2019-01-16 9:33 0% ` Dumitrescu, Cristian
@ 2019-01-16 10:09 0% ` Singh, Jasvinder
0 siblings, 0 replies; 200+ results
From: Singh, Jasvinder @ 2019-01-16 10:09 UTC (permalink / raw)
To: Dumitrescu, Cristian, Pattan, Reshma, Stephen Hemminger
Cc: dev, jerin.jacob, Rao, Nikhil, olivier.matz, thomas, Ananyev, Konstantin
<snip>
> >
> > > -----Original Message-----
> > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > Sent: Tuesday, January 15, 2019 10:37 PM
> > > To: Pattan, Reshma <reshma.pattan@intel.com>
> > > Cc: dev@dpdk.org; jerin.jacob@caviumnetworks.com; Rao, Nikhil
> > > <nikhil.rao@intel.com>; olivier.matz@6wind.com; thomas@monjalon.net;
> > > Singh, Jasvinder <jasvinder.singh@intel.com>; Dumitrescu, Cristian
> > > <cristian.dumitrescu@intel.com>; Ananyev, Konstantin
> > > <konstantin.ananyev@intel.com>
> > > Subject: Re: [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic
> > > format
> > for
> > > sched field
> > >
> > > On Thu, 20 Dec 2018 12:16:09 +0000
> > > Reshma Pattan <reshma.pattan@intel.com> wrote:
> > >
> > > > This patch implements the changes proposed in the deprecation
> > > > notes [1][2].
> > > >
> > > > librte_mbuf changes:
> > > > The mbuf->hash.sched field is updated to support generic
> > > > definition in line with the ethdev traffic manager and meter APIs.
> > > > The new generic format contains: queue ID, traffic class, color.
> > > >
> > > > Added public APIs to set and get these new fields to and from mbuf.
> > > >
> > > > librte_sched changes:
> > > > In addtion, following API functions of the sched library have been
> > > > modified with an additional parameter of type struct
> > > > rte_sched_port to accommodate the changes made to mbuf sched field.
> > > > (i)rte_sched_port_pkt_write()
> > > > (ii) rte_sched_port_pkt_read_tree_path()
> > > >
> > > > librte_pipeline, qos_sched UT, qos_sched app are updated to make
> > > > use of new changes.
> > > >
> > > > Also mbuf->hash.txadapter has been added for eventdev txq,
> > > > rte_event_eth_tx_adapter_txq_set and
> > > > rte_event_eth_tx_adapter_txq_get()
> > > > are updated to use mbuf->hash.txadapter.txq.
> > > >
> > > > doc:
> > > > Release notes updated.
> > > > Removed deprecation notice for mbuf->hash.sched and sched API.
> > > >
> > > > [1] http://mails.dpdk.org/archives/dev/2018-February/090651.html
> > > > [2] https://mails.dpdk.org/archives/dev/2018-November/119051.html
> > > >
> > > > Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
> > > > Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> > > > Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> > > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > >
> > >
> > > This patch breaks build of VPP because it refers to sched.hi and sched.lo.
> > > Breaking source compatibility is as bad (if not worse) than ABI breakage.
> > >
> >
> > Yes this breaks the build and we have actions to fix VPP Qos Sched
> > when DPDK 19.02 is formally integrated to VPP.
> >
> > Thanks,
> > Reshma
>
> Yes, Jasvinder is the maintainer of the VPP HQoS code, this is on his plate to fix
> in VPP for the next VPP release using DPDK release 19
Yes, patch will be up streamed as soon as dpdk19.02 is out.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] DPDK techboard minutes of January 2
@ 2019-01-16 9:55 3% Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-01-16 9:55 UTC (permalink / raw)
To: dev; +Cc: techboard
Meeting notes for the DPDK technical board meeting held on 2019-01-02
Attendees: 7/9
- Ferruh Yigit
- Jerin Jacob
- Konstantin Ananyev
- Maxime Coquelin
- Olivier Matz
- Stephen Hemminger
- Thomas Monjalon
1) Mentoring
Stephen will check Google Code and other possible initiatives.
Project scope must be well defined, useful, easy to ramp up and testable.
Idea of projects: automatic testing of vhost/virtio or Hyper-V.
AWS and Azure can be some targets.
Project suggestions will be discussed on the mailing list.
We are looking for mentors. Maxime proposed to mentor vhost/virtio testing.
2) Deprecation process
- How new API or ABI is introduced
No need to require introducing new code in RTE_NEXT_ABI ifdef
while sending deprecation notice.
Instead, a draft of the new code (RFC patch) must be submitted
and referenced in the deprecation notice.
So the deprecation notice may be better discussed before giving ack,
and the users can prepare their application for the next DPDK release.
- How old API is removed
We must not remove a deprecated API if the replacement is still experimental.
It is recommended to remove deprecated APIs after a LTS release.
The process change must adjusted by Ferruh. Initial proposal was sent:
https://patches.dpdk.org/project/dpdk/list/?series=2927
3) Next techboard meeting
- It will be on January 16
- Bruce Richardson will chair it
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format for sched field
2019-01-16 9:19 0% ` Pattan, Reshma
@ 2019-01-16 9:33 0% ` Dumitrescu, Cristian
2019-01-16 10:09 0% ` Singh, Jasvinder
0 siblings, 1 reply; 200+ results
From: Dumitrescu, Cristian @ 2019-01-16 9:33 UTC (permalink / raw)
To: Pattan, Reshma, Stephen Hemminger
Cc: dev, jerin.jacob, Rao, Nikhil, olivier.matz, thomas, Singh,
Jasvinder, Ananyev, Konstantin
> -----Original Message-----
> From: Pattan, Reshma
> Sent: Wednesday, January 16, 2019 9:19 AM
> To: Stephen Hemminger <stephen@networkplumber.org>
> Cc: dev@dpdk.org; jerin.jacob@caviumnetworks.com; Rao, Nikhil
> <nikhil.rao@intel.com>; olivier.matz@6wind.com; thomas@monjalon.net;
> Singh, Jasvinder <jasvinder.singh@intel.com>; Dumitrescu, Cristian
> <cristian.dumitrescu@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>
> Subject: RE: [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format for
> sched field
>
> Hi
>
> > -----Original Message-----
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Tuesday, January 15, 2019 10:37 PM
> > To: Pattan, Reshma <reshma.pattan@intel.com>
> > Cc: dev@dpdk.org; jerin.jacob@caviumnetworks.com; Rao, Nikhil
> > <nikhil.rao@intel.com>; olivier.matz@6wind.com; thomas@monjalon.net;
> > Singh, Jasvinder <jasvinder.singh@intel.com>; Dumitrescu, Cristian
> > <cristian.dumitrescu@intel.com>; Ananyev, Konstantin
> > <konstantin.ananyev@intel.com>
> > Subject: Re: [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format
> for
> > sched field
> >
> > On Thu, 20 Dec 2018 12:16:09 +0000
> > Reshma Pattan <reshma.pattan@intel.com> wrote:
> >
> > > This patch implements the changes proposed in the deprecation notes
> > > [1][2].
> > >
> > > librte_mbuf changes:
> > > The mbuf->hash.sched field is updated to support generic definition in
> > > line with the ethdev traffic manager and meter APIs.
> > > The new generic format contains: queue ID, traffic class, color.
> > >
> > > Added public APIs to set and get these new fields to and from mbuf.
> > >
> > > librte_sched changes:
> > > In addtion, following API functions of the sched library have been
> > > modified with an additional parameter of type struct rte_sched_port to
> > > accommodate the changes made to mbuf sched field.
> > > (i)rte_sched_port_pkt_write()
> > > (ii) rte_sched_port_pkt_read_tree_path()
> > >
> > > librte_pipeline, qos_sched UT, qos_sched app are updated to make use
> > > of new changes.
> > >
> > > Also mbuf->hash.txadapter has been added for eventdev txq,
> > > rte_event_eth_tx_adapter_txq_set and
> > > rte_event_eth_tx_adapter_txq_get()
> > > are updated to use mbuf->hash.txadapter.txq.
> > >
> > > doc:
> > > Release notes updated.
> > > Removed deprecation notice for mbuf->hash.sched and sched API.
> > >
> > > [1] http://mails.dpdk.org/archives/dev/2018-February/090651.html
> > > [2] https://mails.dpdk.org/archives/dev/2018-November/119051.html
> > >
> > > Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
> > > Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> > > Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> > > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> >
> >
> > This patch breaks build of VPP because it refers to sched.hi and sched.lo.
> > Breaking source compatibility is as bad (if not worse) than ABI breakage.
> >
>
> Yes this breaks the build and we have actions to fix VPP Qos Sched when
> DPDK 19.02 is formally integrated to VPP.
>
> Thanks,
> Reshma
Yes, Jasvinder is the maintainer of the VPP HQoS code, this is on his plate to fix in VPP for the next VPP release using DPDK release 19.02.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format for sched field
2019-01-15 22:37 3% ` Stephen Hemminger
@ 2019-01-16 9:19 0% ` Pattan, Reshma
2019-01-16 9:33 0% ` Dumitrescu, Cristian
0 siblings, 1 reply; 200+ results
From: Pattan, Reshma @ 2019-01-16 9:19 UTC (permalink / raw)
To: Stephen Hemminger
Cc: dev, jerin.jacob, Rao, Nikhil, olivier.matz, thomas, Singh,
Jasvinder, Dumitrescu, Cristian, Ananyev, Konstantin
Hi
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Tuesday, January 15, 2019 10:37 PM
> To: Pattan, Reshma <reshma.pattan@intel.com>
> Cc: dev@dpdk.org; jerin.jacob@caviumnetworks.com; Rao, Nikhil
> <nikhil.rao@intel.com>; olivier.matz@6wind.com; thomas@monjalon.net;
> Singh, Jasvinder <jasvinder.singh@intel.com>; Dumitrescu, Cristian
> <cristian.dumitrescu@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format for
> sched field
>
> On Thu, 20 Dec 2018 12:16:09 +0000
> Reshma Pattan <reshma.pattan@intel.com> wrote:
>
> > This patch implements the changes proposed in the deprecation notes
> > [1][2].
> >
> > librte_mbuf changes:
> > The mbuf->hash.sched field is updated to support generic definition in
> > line with the ethdev traffic manager and meter APIs.
> > The new generic format contains: queue ID, traffic class, color.
> >
> > Added public APIs to set and get these new fields to and from mbuf.
> >
> > librte_sched changes:
> > In addtion, following API functions of the sched library have been
> > modified with an additional parameter of type struct rte_sched_port to
> > accommodate the changes made to mbuf sched field.
> > (i)rte_sched_port_pkt_write()
> > (ii) rte_sched_port_pkt_read_tree_path()
> >
> > librte_pipeline, qos_sched UT, qos_sched app are updated to make use
> > of new changes.
> >
> > Also mbuf->hash.txadapter has been added for eventdev txq,
> > rte_event_eth_tx_adapter_txq_set and
> > rte_event_eth_tx_adapter_txq_get()
> > are updated to use mbuf->hash.txadapter.txq.
> >
> > doc:
> > Release notes updated.
> > Removed deprecation notice for mbuf->hash.sched and sched API.
> >
> > [1] http://mails.dpdk.org/archives/dev/2018-February/090651.html
> > [2] https://mails.dpdk.org/archives/dev/2018-November/119051.html
> >
> > Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
> > Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> > Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> > Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
>
>
> This patch breaks build of VPP because it refers to sched.hi and sched.lo.
> Breaking source compatibility is as bad (if not worse) than ABI breakage.
>
Yes this breaks the build and we have actions to fix VPP Qos Sched when DPDK 19.02 is formally integrated to VPP.
Thanks,
Reshma
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format for sched field
2019-01-15 23:11 4% ` Stephen Hemminger
@ 2019-01-16 8:41 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-01-16 8:41 UTC (permalink / raw)
To: dev
Cc: Stephen Hemminger, Reshma Pattan, jerin.jacob, nikhil.rao,
olivier.matz, jasvinder.singh, cristian.dumitrescu,
konstantin.ananyev
16/01/2019 00:11, Stephen Hemminger:
> On Thu, 20 Dec 2018 12:16:09 +0000
> Reshma Pattan <reshma.pattan@intel.com> wrote:
>
> > void
> > -rte_sched_port_pkt_write(struct rte_mbuf *pkt,
> > - uint32_t subport, uint32_t pipe, uint32_t traffic_class,
> > +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)
>
> Sorry I didn't notice this earlier, but changing the function signature like
> this is a complete ABI breakage. Old code will be passing different arguments than
> new code; therefore this change breaks both source and binary compatibility.
>
> Is 19.02 supposed to be an ABI/API breaking release? Or only an incremental update.
It is an API breaking release.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] doc: announce ring ABI and API changes
2019-01-15 23:59 7% [dpdk-dev] [PATCH] doc: announce ring ABI and API changes Gage Eads
@ 2019-01-16 0:34 7% ` Stephen Hemminger
2019-01-16 18:21 8% ` Eads, Gage
2019-01-18 15:28 3% ` [dpdk-dev] [PATCH v2] doc: announce ring API change Gage Eads
1 sibling, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-01-16 0:34 UTC (permalink / raw)
To: Gage Eads
Cc: dev, olivier.matz, arybchenko, bruce.richardson, konstantin.ananyev
On Tue, 15 Jan 2019 17:59:34 -0600
Gage Eads <gage.eads@intel.com> wrote:
> In order to support the non-blocking ring[1], one ABI change and one API
> change are required in librte_ring. This commit updates the deprecation
> notice to pave the way for their inclusion in 19.05.
>
> [1] http://mails.dpdk.org/archives/dev/2019-January/123475.html
>
> Signed-off-by: Gage Eads <gage.eads@intel.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index d4aea4b46..d74cff467 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -83,3 +83,14 @@ 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: two changes are planned for rte_ring in v19.05:
> +
> + - The ring head and tail values are planned to be changed from ``uint32_t``
> + to ``size_t``. This reduces the likelihood of wrap-around to effectively
> + zero for 64-bit builds, which is important in avoiding the ABA problem in
> + the upcoming non-blocking ring implementation. (32-bit builds are
> + unaffected by this change.)
> + - 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).
Would it be possible to support new and old ring types, either through naming
tricks and/or new ring flag? Changing things like ring buffer and mbuf are basically
a flag day for all users.
I admit to having a personal interest in this since the API/ABI churn is this
project causes vendors to stay on older code. And older code does not correctly
support newer networks.
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [PATCH v2 0/5] Add non-blocking ring
2019-01-15 23:52 3% ` [dpdk-dev] [PATCH v2 0/5] Add non-blocking ring Gage Eads
@ 2019-01-16 0:26 3% ` Stephen Hemminger
2019-01-18 15:23 3% ` [dpdk-dev] [PATCH v3 " Gage Eads
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-01-16 0:26 UTC (permalink / raw)
To: Gage Eads
Cc: dev, olivier.matz, arybchenko, bruce.richardson, konstantin.ananyev
On Tue, 15 Jan 2019 17:52:22 -0600
Gage Eads <gage.eads@intel.com> wrote:
> 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 limited to x86_64 machines.
>
> 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 ABI and API changes; 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/123470.html
>
> 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: change head and tail to pointer-width size
> 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/rte_mempool_ring.c | 58 ++-
> lib/librte_eventdev/rte_event_ring.h | 6 +-
> lib/librte_ring/Makefile | 2 +-
> lib/librte_ring/meson.build | 2 +-
> lib/librte_ring/rte_ring.c | 53 ++-
> lib/librte_ring/rte_ring.h | 564 ++++++++++++++++++++++--
> lib/librte_ring/rte_ring_generic.h | 16 +-
> lib/librte_ring/rte_ring_version.map | 7 +
> test/test/test_ring.c | 57 ++-
> test/test/test_ring_perf.c | 19 +-
> 11 files changed, 699 insertions(+), 87 deletions(-)
>
Just bumping the version number is not enough.
This looks like an ABI breakage for existing users.
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH] doc: announce ring ABI and API changes
@ 2019-01-15 23:59 7% Gage Eads
2019-01-16 0:34 7% ` Stephen Hemminger
2019-01-18 15:28 3% ` [dpdk-dev] [PATCH v2] doc: announce ring API change Gage Eads
0 siblings, 2 replies; 200+ results
From: Gage Eads @ 2019-01-15 23:59 UTC (permalink / raw)
To: dev
Cc: olivier.matz, arybchenko, bruce.richardson, konstantin.ananyev, stephen
In order to support the non-blocking ring[1], one ABI change and one API
change are required in librte_ring. This commit updates the deprecation
notice to pave the way for their inclusion in 19.05.
[1] http://mails.dpdk.org/archives/dev/2019-January/123475.html
Signed-off-by: Gage Eads <gage.eads@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index d4aea4b46..d74cff467 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -83,3 +83,14 @@ 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: two changes are planned for rte_ring in v19.05:
+
+ - The ring head and tail values are planned to be changed from ``uint32_t``
+ to ``size_t``. This reduces the likelihood of wrap-around to effectively
+ zero for 64-bit builds, which is important in avoiding the ABA problem in
+ the upcoming non-blocking ring implementation. (32-bit builds are
+ unaffected by this change.)
+ - 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 7%]
* [dpdk-dev] [PATCH v2 0/5] Add non-blocking ring
2019-01-10 21:01 4% [dpdk-dev] [PATCH 0/6] Add non-blocking ring Gage Eads
@ 2019-01-15 23:52 3% ` Gage Eads
2019-01-16 0:26 3% ` Stephen Hemminger
2019-01-18 15:23 3% ` [dpdk-dev] [PATCH v3 " Gage Eads
1 sibling, 2 replies; 200+ results
From: Gage Eads @ 2019-01-15 23:52 UTC (permalink / raw)
To: dev
Cc: olivier.matz, arybchenko, bruce.richardson, konstantin.ananyev, stephen
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 limited to x86_64 machines.
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 ABI and API changes; 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/123470.html
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: change head and tail to pointer-width size
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/rte_mempool_ring.c | 58 ++-
lib/librte_eventdev/rte_event_ring.h | 6 +-
lib/librte_ring/Makefile | 2 +-
lib/librte_ring/meson.build | 2 +-
lib/librte_ring/rte_ring.c | 53 ++-
lib/librte_ring/rte_ring.h | 564 ++++++++++++++++++++++--
lib/librte_ring/rte_ring_generic.h | 16 +-
lib/librte_ring/rte_ring_version.map | 7 +
test/test/test_ring.c | 57 ++-
test/test/test_ring_perf.c | 19 +-
11 files changed, 699 insertions(+), 87 deletions(-)
--
2.13.6
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format for sched field
2018-12-20 12:16 1% ` [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format for sched field Reshma Pattan
2018-12-20 14:55 0% ` Rao, Nikhil
2019-01-15 22:37 3% ` Stephen Hemminger
@ 2019-01-15 23:11 4% ` Stephen Hemminger
2019-01-16 8:41 0% ` Thomas Monjalon
2 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-01-15 23:11 UTC (permalink / raw)
To: Reshma Pattan
Cc: dev, jerin.jacob, nikhil.rao, olivier.matz, thomas,
jasvinder.singh, cristian.dumitrescu, konstantin.ananyev
On Thu, 20 Dec 2018 12:16:09 +0000
Reshma Pattan <reshma.pattan@intel.com> wrote:
> void
> -rte_sched_port_pkt_write(struct rte_mbuf *pkt,
> - uint32_t subport, uint32_t pipe, uint32_t traffic_class,
> +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)
Sorry I didn't notice this earlier, but changing the function signature like
this is a complete ABI breakage. Old code will be passing different arguments than
new code; therefore this change breaks both source and binary compatibility.
Is 19.02 supposed to be an ABI/API breaking release? Or only an incremental update.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format for sched field
2018-12-20 12:16 1% ` [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format for sched field Reshma Pattan
2018-12-20 14:55 0% ` Rao, Nikhil
@ 2019-01-15 22:37 3% ` Stephen Hemminger
2019-01-16 9:19 0% ` Pattan, Reshma
2019-01-15 23:11 4% ` Stephen Hemminger
2 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-01-15 22:37 UTC (permalink / raw)
To: Reshma Pattan
Cc: dev, jerin.jacob, nikhil.rao, olivier.matz, thomas,
jasvinder.singh, cristian.dumitrescu, konstantin.ananyev
On Thu, 20 Dec 2018 12:16:09 +0000
Reshma Pattan <reshma.pattan@intel.com> wrote:
> This patch implements the changes proposed in the deprecation
> notes [1][2].
>
> librte_mbuf changes:
> The mbuf->hash.sched field is updated to support generic
> definition in line with the ethdev traffic manager and meter APIs.
> The new generic format contains: queue ID, traffic class, color.
>
> Added public APIs to set and get these new fields to and from mbuf.
>
> librte_sched changes:
> In addtion, following API functions of the sched library have
> been modified with an additional parameter of type struct
> rte_sched_port to accommodate the changes made to mbuf sched field.
> (i)rte_sched_port_pkt_write()
> (ii) rte_sched_port_pkt_read_tree_path()
>
> librte_pipeline, qos_sched UT, qos_sched app are updated
> to make use of new changes.
>
> Also mbuf->hash.txadapter has been added for eventdev txq,
> rte_event_eth_tx_adapter_txq_set and rte_event_eth_tx_adapter_txq_get()
> are updated to use mbuf->hash.txadapter.txq.
>
> doc:
> Release notes updated.
> Removed deprecation notice for mbuf->hash.sched and sched API.
>
> [1] http://mails.dpdk.org/archives/dev/2018-February/090651.html
> [2] https://mails.dpdk.org/archives/dev/2018-November/119051.html
>
> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
> Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
This patch breaks build of VPP because it refers to sched.hi and sched.lo.
Breaking source compatibility is as bad (if not worse) than ABI breakage.
Maybe make the sched field a union?
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 1/6] ring: change head and tail to pointer-width size
2019-01-11 19:55 3% ` Stephen Hemminger
@ 2019-01-15 15:48 4% ` Eads, Gage
0 siblings, 0 replies; 200+ results
From: Eads, Gage @ 2019-01-15 15:48 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Burakov, Anatoly, dev, olivier.matz, arybchenko, Richardson,
Bruce, Ananyev, Konstantin
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Friday, January 11, 2019 1:55 PM
> To: Eads, Gage <gage.eads@intel.com>
> Cc: Burakov, Anatoly <anatoly.burakov@intel.com>; dev@dpdk.org;
> olivier.matz@6wind.com; arybchenko@solarflare.com; Richardson, Bruce
> <bruce.richardson@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>
> Subject: Re: [dpdk-dev] [PATCH 1/6] ring: change head and tail to pointer-width
> size
>
> On Fri, 11 Jan 2019 19:12:40 +0000
> "Eads, Gage" <gage.eads@intel.com> wrote:
>
> > > -----Original Message-----
> > > From: Burakov, Anatoly
> > > Sent: Friday, January 11, 2019 4:25 AM
> > > 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>
> > > Subject: Re: [dpdk-dev] [PATCH 1/6] ring: change head and tail to
> > > pointer-width size
> > >
> > > On 10-Jan-19 9:01 PM, Gage Eads wrote:
> > > > For 64-bit architectures, doubling the 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 important in 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.
> > > >
> > > > I tested this commit's performance impact with an x86_64 build on
> > > > a dual-socket Xeon E5-2699 v4 using ring_perf_autotest, and the
> > > > change made no significant difference -- the few differences
> > > > appear to be system
> > > noise.
> > > > (The test ran on isolcpus cores using a tickless scheduler, but
> > > > some variation was stll observed.) Each test was run three times
> > > > and the results were averaged:
> > > >
> > > > | 64b head/tail cycle cost minus
> > > > Test | 32b head/tail cycle cost
> > > > ------------------------------------------------------------------
> > > > SP/SC single enq/dequeue | 0.33
> > > > MP/MC single enq/dequeue | 0.00
> > > > SP/SC burst enq/dequeue (size 8) | 0.00 MP/MC burst enq/dequeue
> > > > (size
> > > > 8) | 1.00 SP/SC burst enq/dequeue (size 32) | 0.00 MP/MC burst
> > > > enq/dequeue (size 32) | -1.00
> > > > SC empty dequeue | 0.01
> > > > MC empty dequeue | 0.00
> > > >
> > > > Single lcore:
> > > > SP/SC bulk enq/dequeue (size 8) | -0.36
> > > > MP/MC bulk enq/dequeue (size 8) | 0.99
> > > > SP/SC bulk enq/dequeue (size 32) | -0.40 MP/MC bulk enq/dequeue
> > > > (size
> > > > 32) | -0.57
> > > >
> > > > Two physical cores:
> > > > SP/SC bulk enq/dequeue (size 8) | -0.49
> > > > MP/MC bulk enq/dequeue (size 8) | 0.19
> > > > SP/SC bulk enq/dequeue (size 32) | -0.28 MP/MC bulk enq/dequeue
> > > > (size
> > > > 32) | -0.62
> > > >
> > > > Two NUMA nodes:
> > > > SP/SC bulk enq/dequeue (size 8) | 3.25
> > > > MP/MC bulk enq/dequeue (size 8) | 1.87
> > > > SP/SC bulk enq/dequeue (size 32) | -0.44 MP/MC bulk enq/dequeue
> > > > (size
> > > > 32) | -1.10
> > > >
> > > > An earlier version of this patch changed the head and tail indexes
> > > > to uint64_t, but that caused a performance drop on 32-bit builds.
> > > > With uintptr_t, no performance difference is observed on an i686 build.
> > > >
> > > > Signed-off-by: Gage Eads <gage.eads@intel.com>
> > > > ---
> > >
> > > You're breaking the ABI - version bump for affected libraries is needed.
> > >
> > > --
> > > Thanks,
> > > Anatoly
> >
> > If I'm reading the versioning guidelines correctly, I'll need to gate the changes
> with the RTE_NEXT_ABI macro and provide a deprecation notice, then after a
> full deprecation cycle we can revert that and bump the library version. Not to
> mention the 3 ML ACKs.
> >
> > I'll address this in v2.
>
> My understanding is that RTE_NEXT_API method is not used any more. Replaced
> by rte_experimental.
> But this kind of change is more of a flag day event. Which means it needs to be
> pushed off to a release that is planned as an ABI break (usually once a year)
> which would mean 19.11.
In recent release notes, I see ABI changes can happen more frequently than once per year; 18.11, 18.05, 17.11, and 17.08 have ABI changes -- and soon 19.02 will too.
At any rate, I'll create a separate deprecation notice patch and update this patchset accordingly.
Thanks,
Gage
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [EXT] [PATCH v3 5/6] spinlock: reimplement with atomic one-way barrier builtins
2019-01-14 7:39 0% ` Jerin Jacob Kollanukkaran
@ 2019-01-14 17:08 0% ` Gavin Hu (Arm Technology China)
0 siblings, 0 replies; 200+ results
From: Gavin Hu (Arm Technology China) @ 2019-01-14 17:08 UTC (permalink / raw)
To: jerinj, Honnappa Nagarahalli, dev
Cc: david.marchand, chaozhu, nd, bruce.richardson, thomas,
Joyce Kong (Arm Technology China),
hemant.agrawal, stephen
> > > > > *sl); static
> > > > > inline void rte_spinlock_lock(rte_spinlock_t *sl) {
> > > > > - while (__sync_lock_test_and_set(&sl->locked, 1))
> > > > > - while(sl->locked)
> > > > > + int exp = 0;
> > > > > +
> > > > > + while (!__atomic_compare_exchange_n(&sl->locked, &exp,
> > > > > 1, 0,
> > > > > + __ATOMIC_ACQUIRE,
> > > > > __ATOMIC_RELAXED))
> > > > {
> > > >
> > > > How about remove explict exp = 0 and change to
> > > > __atomic_test_and_set(flag, __ATOMIC_ACQUIRE);
> > >
> > > Yes, __atomic_test_and_set means simpler code and better, but
> > > __atomic_test_and_set takes the first argument as a pointer to type
> > > bool or
> > > char, in our case, sl->locked is of type uint32.
> > > We can force it to uint8, or just pass in the 32bit pointer, only
> > > one byte/bit is
> > > really used in this case, is that ok?
> > >
> > > "It should be only used for operands of type bool or char. For
> > > other types only
> > > part of the value may be set."
> > > https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/_005f_005fatomic-
> > > Builtins.html
> > >
> > > From performance perspective, in our testing, the performance was
> > > very close,
> > > compared to __atomic.
> > If performance is close, I suggest we go with the existing patch.
> > Changing sl->locked to bool/char would be an ABI change and will
> > affect x86 TM based implementation as well.
> > Jerin, what do you think?
>
> Looks good to me.
>
I tested __atomic_test_and_test based patch(I did not push this, it is in internal review), it caused 10 times performance degradation on ThunderX2.
In the internal review, Ola Liljedahl's comment well explained the degradation:
"Unlike the old code, the new code will write the lock location (and thus get exclusive access to the whole cache line) repeatedly while it is busy waiting. This is bad for the lock owner if it is accessing other data located in the same cache line as the lock (which is often the case)."
The real difference is __atomic_test_and_test keeps writing the lock location(whether it is locked or not) and monopolizing the cache line, it is bad to the lock owner and other contenders.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] eal: fix strdup usages in internal config
2019-01-10 13:38 2% [dpdk-dev] [PATCH] eal: fix strdup usages in internal config Anatoly Burakov
@ 2019-01-14 14:18 0% ` Thomas Monjalon
2019-01-31 11:21 0% ` Kevin Traynor
1 sibling, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-01-14 14:18 UTC (permalink / raw)
To: Anatoly Burakov; +Cc: dev, Bruce Richardson, ferruh.yigit, andy01011501
10/01/2019 14:38, Anatoly Burakov:
> 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
>
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Applied, thanks
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [EXT] [PATCH v3 5/6] spinlock: reimplement with atomic one-way barrier builtins
2019-01-14 5:54 3% ` Honnappa Nagarahalli
2019-01-14 7:39 0% ` Jerin Jacob Kollanukkaran
@ 2019-01-14 7:57 0% ` Gavin Hu (Arm Technology China)
1 sibling, 0 replies; 200+ results
From: Gavin Hu (Arm Technology China) @ 2019-01-14 7:57 UTC (permalink / raw)
To: Honnappa Nagarahalli, jerinj, dev
Cc: david.marchand, chaozhu, nd, bruce.richardson, thomas,
hemant.agrawal, stephen, Joyce Kong (Arm Technology China),
nd
> -----Original Message-----
> From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> Sent: Monday, January 14, 2019 1:55 PM
> To: Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>;
> jerinj@marvell.com; dev@dpdk.org
> Cc: david.marchand@redhat.com; chaozhu@linux.vnet.ibm.com; nd
> <nd@arm.com>; bruce.richardson@intel.com; thomas@monjalon.net;
> hemant.agrawal@nxp.com; stephen@networkplumber.org; Joyce Kong (Arm
> Technology China) <Joyce.Kong@arm.com>; nd <nd@arm.com>
> Subject: RE: [EXT] [PATCH v3 5/6] spinlock: reimplement with atomic one-
> way barrier builtins
>
> > >
> > > On Thu, 2018-12-27 at 12:13 +0800, Gavin Hu wrote:
> > > -------------------------------------------------------------------
> > > > ---
> > > > The __sync builtin based implementation generates full memory
> > > > barriers ('dmb ish') on Arm platforms. Using C11 atomic builtins to
> > > > generate one way barriers.
> > > >
> > > > Here is the assembly code of __sync_compare_and_swap builtin.
> > > > __sync_bool_compare_and_swap(dst, exp, src);
> > > > 0x000000000090f1b0 <+16>: e0 07 40 f9 ldr x0, [sp, #8]
> > > > 0x000000000090f1b4 <+20>: e1 0f 40 79 ldrh w1, [sp, #6]
> > > > 0x000000000090f1b8 <+24>: e2 0b 40 79 ldrh w2, [sp, #4]
> > > > 0x000000000090f1bc <+28>: 21 3c 00 12 and w1, w1, #0xffff
> > > > 0x000000000090f1c0 <+32>: 03 7c 5f 48 ldxrh w3, [x0]
> > > > 0x000000000090f1c4 <+36>: 7f 00 01 6b cmp w3, w1
> > > > 0x000000000090f1c8 <+40>: 61 00 00 54 b.ne 0x90f1d4
> > > > <rte_atomic16_cmpset+52> // b.any
> > > > 0x000000000090f1cc <+44>: 02 fc 04 48 stlxrh w4, w2, [x0]
> > > > 0x000000000090f1d0 <+48>: 84 ff ff 35 cbnz w4, 0x90f1c0
> > > > <rte_atomic16_cmpset+32>
> > > > 0x000000000090f1d4 <+52>: bf 3b 03 d5 dmb ish
> > > > 0x000000000090f1d8 <+56>: e0 17 9f 1a cset w0, eq // eq =
> > > > none
> > > >
> > > > The benchmarking results showed 3X performance gain on Cavium
> > > > ThunderX2 and
> > > > 13% on Qualcomm Falmon and 3.7% on 4-A72 Marvell macchiatobin.
> > > > Here is the example test result on TX2:
> > > >
> > > > *** spinlock_autotest without this patch *** Core [123] Cost Time =
> > > > 639822 us Core [124] Cost Time = 633253 us Core [125] Cost Time =
> > > > 646030 us Core [126] Cost Time = 643189 us Core [127] Cost Time =
> > > > 647039 us Total Cost Time = 95433298 us
> > > >
> > > > *** spinlock_autotest with this patch *** Core [123] Cost Time =
> > > > 163615 us Core [124] Cost Time = 166471 us Core [125] Cost Time =
> > > > 189044 us Core [126] Cost Time = 195745 us Core [127] Cost Time =
> > > > 78423 us Total Cost Time = 27339656 us
> > > >
> > > > Signed-off-by: Gavin Hu <gavin.hu@arm.com>
> > > > Reviewed-by: Phil Yang <phil.yang@arm.com>
> > > > Reviewed-by: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> > > > Reviewed-by: Ola Liljedahl <Ola.Liljedahl@arm.com>
> > > > Reviewed-by: Steve Capper <Steve.Capper@arm.com>
> > > > ---
> > > > lib/librte_eal/common/include/generic/rte_spinlock.h | 18
> > > > +++++++++++++-----
> > > > 1 file changed, 13 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/lib/librte_eal/common/include/generic/rte_spinlock.h
> > > > b/lib/librte_eal/common/include/generic/rte_spinlock.h
> > > > index c4c3fc31e..87ae7a4f1 100644
> > > > --- a/lib/librte_eal/common/include/generic/rte_spinlock.h
> > > > +++ b/lib/librte_eal/common/include/generic/rte_spinlock.h
> > > > @@ -61,9 +61,14 @@ rte_spinlock_lock(rte_spinlock_t *sl); static
> > > > inline void rte_spinlock_lock(rte_spinlock_t *sl) {
> > > > - while (__sync_lock_test_and_set(&sl->locked, 1))
> > > > - while(sl->locked)
> > > > + int exp = 0;
> > > > +
> > > > + while (!__atomic_compare_exchange_n(&sl->locked, &exp, 1, 0,
> > > > + __ATOMIC_ACQUIRE, __ATOMIC_RELAXED))
> > > {
> > >
> > > How about remove explict exp = 0 and change to
> > > __atomic_test_and_set(flag, __ATOMIC_ACQUIRE);
> >
> > Yes, __atomic_test_and_set means simpler code and better, but
> > __atomic_test_and_set takes the first argument as a pointer to type bool
> or
> > char, in our case, sl->locked is of type uint32.
> > We can force it to uint8, or just pass in the 32bit pointer, only one byte/bit
> is
> > really used in this case, is that ok?
> >
> > "It should be only used for operands of type bool or char. For other types
> only
> > part of the value may be set."
> > https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/_005f_005fatomic-
> > Builtins.html
> >
> > From performance perspective, in our testing, the performance was very
> close,
> > compared to __atomic.
> If performance is close, I suggest we go with the existing patch. Changing sl-
> >locked to bool/char would be an ABI change and will affect x86 TM based
> implementation as well.
> Jerin, what do you think?
I have benchmarked on Qualcomm, ThunderX2 and Context A72.
In comparison to the existing patch, on the new patch using __atomic_test_and_set, Qualcomm Falkor gained 60% performance, 4-core A72 degraded 13%, ThunderX2 even worse, degraded 10 times.
I am not sure why ThunderX2 degraded so much, maybe it was caused by two many cores (128 cores) with high contention?
>
> >
> > >
> > > i.e
> > > while (_atomic_test_and_set(flag, __ATOMIC_ACQUIRE))
> > >
> > >
> > >
> > > > + while (__atomic_load_n(&sl->locked, __ATOMIC_RELAXED))
> > > > rte_pause();
> > > > + exp = 0;
> > >
> > > We can remove exp = 0 with above scheme.
> > >
> > > > + }
> > > > }
> > > > #endif
> > > >
> > > > @@ -80,7 +85,7 @@ rte_spinlock_unlock (rte_spinlock_t *sl); static
> > > > inline void rte_spinlock_unlock (rte_spinlock_t *sl) {
> > > > - __sync_lock_release(&sl->locked);
> > > > + __atomic_store_n(&sl->locked, 0, __ATOMIC_RELEASE);
> > > }
> > > > #endif
> > > >
> > > > @@ -99,7 +104,10 @@ rte_spinlock_trylock (rte_spinlock_t *sl);
> > > > static inline int rte_spinlock_trylock (rte_spinlock_t *sl) {
> > > > - return __sync_lock_test_and_set(&sl->locked,1) == 0;
> > > > + int exp = 0;
> > > > + return __atomic_compare_exchange_n(&sl->locked, &exp, 1,
> > > > + 0, /* disallow spurious failure */
> > > > + __ATOMIC_ACQUIRE, __ATOMIC_RELAXED);
> > >
> > > Here to remove explicit exp.
> > >
> > > return (__atomic_test_and_set(flag, __ATOMIC_ACQUIRE) == 0)
> > >
> > >
> > > > }
> > > > #endif
> > > >
> > > > @@ -113,7 +121,7 @@ rte_spinlock_trylock (rte_spinlock_t *sl)
> > > > */
> > > > static inline int rte_spinlock_is_locked (rte_spinlock_t *sl) {
> > > > - return sl->locked;
> > > > + return __atomic_load_n(&sl->locked, __ATOMIC_ACQUIRE);
> > >
> > > __ATOMIC_RELAXED would be enough here. Right ?
> > >
> > >
> > > > }
> > > >
> > > > /**
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [EXT] [PATCH v3 5/6] spinlock: reimplement with atomic one-way barrier builtins
2019-01-14 5:54 3% ` Honnappa Nagarahalli
@ 2019-01-14 7:39 0% ` Jerin Jacob Kollanukkaran
2019-01-14 17:08 0% ` Gavin Hu (Arm Technology China)
2019-01-14 7:57 0% ` Gavin Hu (Arm Technology China)
1 sibling, 1 reply; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-01-14 7:39 UTC (permalink / raw)
To: Honnappa.Nagarahalli, Gavin.Hu, dev
Cc: david.marchand, chaozhu, nd, bruce.richardson, thomas,
Joyce.Kong, hemant.agrawal, stephen
On Mon, 2019-01-14 at 05:54 +0000, Honnappa Nagarahalli wrote:
> > > On Thu, 2018-12-27 at 12:13 +0800, Gavin Hu wrote:
> > > ---------------------------------------------------------------
> > > ----
> > > > ---
> > > > The __sync builtin based implementation generates full memory
> > > > barriers ('dmb ish') on Arm platforms. Using C11 atomic
> > > > builtins to
> > > > generate one way barriers.
> > > >
> > > > Here is the assembly code of __sync_compare_and_swap builtin.
> > > > __sync_bool_compare_and_swap(dst, exp, src);
> > > > 0x000000000090f1b0 <+16>: e0 07 40 f9 ldr x0, [sp, #8]
> > > > 0x000000000090f1b4 <+20>: e1 0f 40 79 ldrh w1, [sp,
> > > > #6]
> > > > 0x000000000090f1b8 <+24>: e2 0b 40 79 ldrh w2, [sp,
> > > > #4]
> > > > 0x000000000090f1bc <+28>: 21 3c 00 12 and w1, w1, #0xffff
> > > > 0x000000000090f1c0 <+32>: 03 7c 5f 48 ldxrh w3, [x0]
> > > > 0x000000000090f1c4 <+36>: 7f 00 01 6b cmp w3, w1
> > > > 0x000000000090f1c8 <+40>: 61 00 00 54 b.ne 0x90f1d4
> > > > <rte_atomic16_cmpset+52> // b.any
> > > > 0x000000000090f1cc <+44>: 02 fc 04 48 stlxrh w4, w2,
> > > > [x0]
> > > > 0x000000000090f1d0 <+48>: 84 ff ff 35 cbnz w4,
> > > > 0x90f1c0
> > > > <rte_atomic16_cmpset+32>
> > > > 0x000000000090f1d4 <+52>: bf 3b 03 d5 dmb ish
> > > > 0x000000000090f1d8 <+56>: e0 17 9f 1a cset w0, eq //
> > > > eq =
> > > > none
> > > >
> > > > The benchmarking results showed 3X performance gain on Cavium
> > > > ThunderX2 and
> > > > 13% on Qualcomm Falmon and 3.7% on 4-A72 Marvell macchiatobin.
> > > > Here is the example test result on TX2:
> > > >
> > > > *** spinlock_autotest without this patch *** Core [123] Cost
> > > > Time =
> > > > 639822 us Core [124] Cost Time = 633253 us Core [125] Cost Time
> > > > =
> > > > 646030 us Core [126] Cost Time = 643189 us Core [127] Cost Time
> > > > =
> > > > 647039 us Total Cost Time = 95433298 us
> > > >
> > > > *** spinlock_autotest with this patch *** Core [123] Cost Time
> > > > =
> > > > 163615 us Core [124] Cost Time = 166471 us Core [125] Cost Time
> > > > =
> > > > 189044 us Core [126] Cost Time = 195745 us Core [127] Cost Time
> > > > =
> > > > 78423 us Total Cost Time = 27339656 us
> > > >
> > > > Signed-off-by: Gavin Hu <gavin.hu@arm.com>
> > > > Reviewed-by: Phil Yang <phil.yang@arm.com>
> > > > Reviewed-by: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com
> > > > >
> > > > Reviewed-by: Ola Liljedahl <Ola.Liljedahl@arm.com>
> > > > Reviewed-by: Steve Capper <Steve.Capper@arm.com>
> > > > ---
> > > > lib/librte_eal/common/include/generic/rte_spinlock.h | 18
> > > > +++++++++++++-----
> > > > 1 file changed, 13 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git
> > > > a/lib/librte_eal/common/include/generic/rte_spinlock.h
> > > > b/lib/librte_eal/common/include/generic/rte_spinlock.h
> > > > index c4c3fc31e..87ae7a4f1 100644
> > > > --- a/lib/librte_eal/common/include/generic/rte_spinlock.h
> > > > +++ b/lib/librte_eal/common/include/generic/rte_spinlock.h
> > > > @@ -61,9 +61,14 @@ rte_spinlock_lock(rte_spinlock_t
> > > > *sl); static
> > > > inline void rte_spinlock_lock(rte_spinlock_t *sl) {
> > > > - while (__sync_lock_test_and_set(&sl->locked, 1))
> > > > - while(sl->locked)
> > > > + int exp = 0;
> > > > +
> > > > + while (!__atomic_compare_exchange_n(&sl->locked, &exp,
> > > > 1, 0,
> > > > + __ATOMIC_ACQUIRE,
> > > > __ATOMIC_RELAXED))
> > > {
> > >
> > > How about remove explict exp = 0 and change to
> > > __atomic_test_and_set(flag, __ATOMIC_ACQUIRE);
> >
> > Yes, __atomic_test_and_set means simpler code and better, but
> > __atomic_test_and_set takes the first argument as a pointer to type
> > bool or
> > char, in our case, sl->locked is of type uint32.
> > We can force it to uint8, or just pass in the 32bit pointer, only
> > one byte/bit is
> > really used in this case, is that ok?
> >
> > "It should be only used for operands of type bool or char. For
> > other types only
> > part of the value may be set."
> > https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/_005f_005fatomic-
> > Builtins.html
> >
> > From performance perspective, in our testing, the performance was
> > very close,
> > compared to __atomic.
> If performance is close, I suggest we go with the existing patch.
> Changing sl->locked to bool/char would be an ABI change and will
> affect x86 TM based implementation as well.
> Jerin, what do you think?
Looks good to me.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [EXT] [PATCH v3 5/6] spinlock: reimplement with atomic one-way barrier builtins
@ 2019-01-14 5:54 3% ` Honnappa Nagarahalli
2019-01-14 7:39 0% ` Jerin Jacob Kollanukkaran
2019-01-14 7:57 0% ` Gavin Hu (Arm Technology China)
0 siblings, 2 replies; 200+ results
From: Honnappa Nagarahalli @ 2019-01-14 5:54 UTC (permalink / raw)
To: Gavin Hu (Arm Technology China), jerinj, dev
Cc: david.marchand, chaozhu, nd, bruce.richardson, thomas,
hemant.agrawal, stephen, Joyce Kong (Arm Technology China),
nd
> >
> > On Thu, 2018-12-27 at 12:13 +0800, Gavin Hu wrote:
> > -------------------------------------------------------------------
> > > ---
> > > The __sync builtin based implementation generates full memory
> > > barriers ('dmb ish') on Arm platforms. Using C11 atomic builtins to
> > > generate one way barriers.
> > >
> > > Here is the assembly code of __sync_compare_and_swap builtin.
> > > __sync_bool_compare_and_swap(dst, exp, src);
> > > 0x000000000090f1b0 <+16>: e0 07 40 f9 ldr x0, [sp, #8]
> > > 0x000000000090f1b4 <+20>: e1 0f 40 79 ldrh w1, [sp, #6]
> > > 0x000000000090f1b8 <+24>: e2 0b 40 79 ldrh w2, [sp, #4]
> > > 0x000000000090f1bc <+28>: 21 3c 00 12 and w1, w1, #0xffff
> > > 0x000000000090f1c0 <+32>: 03 7c 5f 48 ldxrh w3, [x0]
> > > 0x000000000090f1c4 <+36>: 7f 00 01 6b cmp w3, w1
> > > 0x000000000090f1c8 <+40>: 61 00 00 54 b.ne 0x90f1d4
> > > <rte_atomic16_cmpset+52> // b.any
> > > 0x000000000090f1cc <+44>: 02 fc 04 48 stlxrh w4, w2, [x0]
> > > 0x000000000090f1d0 <+48>: 84 ff ff 35 cbnz w4, 0x90f1c0
> > > <rte_atomic16_cmpset+32>
> > > 0x000000000090f1d4 <+52>: bf 3b 03 d5 dmb ish
> > > 0x000000000090f1d8 <+56>: e0 17 9f 1a cset w0, eq // eq =
> > > none
> > >
> > > The benchmarking results showed 3X performance gain on Cavium
> > > ThunderX2 and
> > > 13% on Qualcomm Falmon and 3.7% on 4-A72 Marvell macchiatobin.
> > > Here is the example test result on TX2:
> > >
> > > *** spinlock_autotest without this patch *** Core [123] Cost Time =
> > > 639822 us Core [124] Cost Time = 633253 us Core [125] Cost Time =
> > > 646030 us Core [126] Cost Time = 643189 us Core [127] Cost Time =
> > > 647039 us Total Cost Time = 95433298 us
> > >
> > > *** spinlock_autotest with this patch *** Core [123] Cost Time =
> > > 163615 us Core [124] Cost Time = 166471 us Core [125] Cost Time =
> > > 189044 us Core [126] Cost Time = 195745 us Core [127] Cost Time =
> > > 78423 us Total Cost Time = 27339656 us
> > >
> > > Signed-off-by: Gavin Hu <gavin.hu@arm.com>
> > > Reviewed-by: Phil Yang <phil.yang@arm.com>
> > > Reviewed-by: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> > > Reviewed-by: Ola Liljedahl <Ola.Liljedahl@arm.com>
> > > Reviewed-by: Steve Capper <Steve.Capper@arm.com>
> > > ---
> > > lib/librte_eal/common/include/generic/rte_spinlock.h | 18
> > > +++++++++++++-----
> > > 1 file changed, 13 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/lib/librte_eal/common/include/generic/rte_spinlock.h
> > > b/lib/librte_eal/common/include/generic/rte_spinlock.h
> > > index c4c3fc31e..87ae7a4f1 100644
> > > --- a/lib/librte_eal/common/include/generic/rte_spinlock.h
> > > +++ b/lib/librte_eal/common/include/generic/rte_spinlock.h
> > > @@ -61,9 +61,14 @@ rte_spinlock_lock(rte_spinlock_t *sl); static
> > > inline void rte_spinlock_lock(rte_spinlock_t *sl) {
> > > - while (__sync_lock_test_and_set(&sl->locked, 1))
> > > - while(sl->locked)
> > > + int exp = 0;
> > > +
> > > + while (!__atomic_compare_exchange_n(&sl->locked, &exp, 1, 0,
> > > + __ATOMIC_ACQUIRE, __ATOMIC_RELAXED))
> > {
> >
> > How about remove explict exp = 0 and change to
> > __atomic_test_and_set(flag, __ATOMIC_ACQUIRE);
>
> Yes, __atomic_test_and_set means simpler code and better, but
> __atomic_test_and_set takes the first argument as a pointer to type bool or
> char, in our case, sl->locked is of type uint32.
> We can force it to uint8, or just pass in the 32bit pointer, only one byte/bit is
> really used in this case, is that ok?
>
> "It should be only used for operands of type bool or char. For other types only
> part of the value may be set."
> https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/_005f_005fatomic-
> Builtins.html
>
> From performance perspective, in our testing, the performance was very close,
> compared to __atomic.
If performance is close, I suggest we go with the existing patch. Changing sl->locked to bool/char would be an ABI change and will affect x86 TM based implementation as well.
Jerin, what do you think?
>
> >
> > i.e
> > while (_atomic_test_and_set(flag, __ATOMIC_ACQUIRE))
> >
> >
> >
> > > + while (__atomic_load_n(&sl->locked, __ATOMIC_RELAXED))
> > > rte_pause();
> > > + exp = 0;
> >
> > We can remove exp = 0 with above scheme.
> >
> > > + }
> > > }
> > > #endif
> > >
> > > @@ -80,7 +85,7 @@ rte_spinlock_unlock (rte_spinlock_t *sl); static
> > > inline void rte_spinlock_unlock (rte_spinlock_t *sl) {
> > > - __sync_lock_release(&sl->locked);
> > > + __atomic_store_n(&sl->locked, 0, __ATOMIC_RELEASE);
> > }
> > > #endif
> > >
> > > @@ -99,7 +104,10 @@ rte_spinlock_trylock (rte_spinlock_t *sl);
> > > static inline int rte_spinlock_trylock (rte_spinlock_t *sl) {
> > > - return __sync_lock_test_and_set(&sl->locked,1) == 0;
> > > + int exp = 0;
> > > + return __atomic_compare_exchange_n(&sl->locked, &exp, 1,
> > > + 0, /* disallow spurious failure */
> > > + __ATOMIC_ACQUIRE, __ATOMIC_RELAXED);
> >
> > Here to remove explicit exp.
> >
> > return (__atomic_test_and_set(flag, __ATOMIC_ACQUIRE) == 0)
> >
> >
> > > }
> > > #endif
> > >
> > > @@ -113,7 +121,7 @@ rte_spinlock_trylock (rte_spinlock_t *sl)
> > > */
> > > static inline int rte_spinlock_is_locked (rte_spinlock_t *sl) {
> > > - return sl->locked;
> > > + return __atomic_load_n(&sl->locked, __ATOMIC_ACQUIRE);
> >
> > __ATOMIC_RELAXED would be enough here. Right ?
> >
> >
> > > }
> > >
> > > /**
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH 1/2] mbuf: remove deprecated macro
@ 2019-01-14 5:20 4% Yongseok Koh
0 siblings, 0 replies; 200+ results
From: Yongseok Koh @ 2019-01-14 5:20 UTC (permalink / raw)
To: konstantin.ananyev, olivier.matz, thomas; +Cc: dev
RTE_MBUF_INDIRECT() is replaced with RTE_MBUF_CLONED() and removed.
This macro was deprecated in release 18.05 when EXT_ATTACHED_MBUF was
introduced.
Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
---
doc/guides/rel_notes/deprecation.rst | 7 -------
doc/guides/rel_notes/release_19_02.rst | 3 +++
drivers/net/mlx4/mlx4_rxtx.h | 2 +-
drivers/net/mlx5/mlx5_rxtx.h | 2 +-
lib/librte_mbuf/rte_mbuf.h | 8 +-------
test/bpf/mbuf.h | 13 ++++++++++---
6 files changed, 16 insertions(+), 19 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index bab82865fb..5f03443f88 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -44,13 +44,6 @@ Deprecation Notices
structure would be made internal (or removed if all dependencies are cleared)
in future releases.
-* mbuf: the macro ``RTE_MBUF_INDIRECT()`` will be removed in v18.08 or later and
- replaced with ``RTE_MBUF_CLONED()`` which is already added in v18.05. As
- ``EXT_ATTACHED_MBUF`` is newly introduced in v18.05, ``RTE_MBUF_INDIRECT()``
- can no longer be mutually exclusive with ``RTE_MBUF_DIRECT()`` if the new
- experimental API ``rte_pktmbuf_attach_extbuf()`` is used. Removal of the macro
- is to fix this semantic inconsistency.
-
* ethdev: the legacy filter API, including
``rte_eth_dev_filter_supported()``, ``rte_eth_dev_filter_ctrl()`` as well
as filter types MACVLAN, ETHERTYPE, FLEXIBLE, SYN, NTUPLE, TUNNEL, FDIR,
diff --git a/doc/guides/rel_notes/release_19_02.rst b/doc/guides/rel_notes/release_19_02.rst
index 5a46f1acdc..c4ad072412 100644
--- a/doc/guides/rel_notes/release_19_02.rst
+++ b/doc/guides/rel_notes/release_19_02.rst
@@ -210,6 +210,9 @@ API Changes
function from now on. Failed to do so will cause
``rte_cryptodev_sym_session_create()`` function call return error.
+* mbuf: ``RTE_MBUF_INDIRECT()``, which was deprecated in 18.05, was replaced
+ with ``RTE_MBUF_CLONED()`` and removed in 19.02.
+
ABI Changes
-----------
diff --git a/drivers/net/mlx4/mlx4_rxtx.h b/drivers/net/mlx4/mlx4_rxtx.h
index d7ec4e0c5f..a5ef5c2ae8 100644
--- a/drivers/net/mlx4/mlx4_rxtx.h
+++ b/drivers/net/mlx4/mlx4_rxtx.h
@@ -179,7 +179,7 @@ uint32_t mlx4_tx_update_ext_mp(struct txq *txq, uintptr_t addr,
static inline struct rte_mempool *
mlx4_mb2mp(struct rte_mbuf *buf)
{
- if (unlikely(RTE_MBUF_INDIRECT(buf)))
+ if (unlikely(RTE_MBUF_CLONED(buf)))
return rte_mbuf_from_indirect(buf)->pool;
return buf->pool;
}
diff --git a/drivers/net/mlx5/mlx5_rxtx.h b/drivers/net/mlx5/mlx5_rxtx.h
index 75194a3fac..c2529f96bc 100644
--- a/drivers/net/mlx5/mlx5_rxtx.h
+++ b/drivers/net/mlx5/mlx5_rxtx.h
@@ -622,7 +622,7 @@ mlx5_tx_complete(struct mlx5_txq_data *txq)
static inline struct rte_mempool *
mlx5_mb2mp(struct rte_mbuf *buf)
{
- if (unlikely(RTE_MBUF_INDIRECT(buf)))
+ if (unlikely(RTE_MBUF_CLONED(buf)))
return rte_mbuf_from_indirect(buf)->pool;
return buf->pool;
}
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index bc562dc8a9..6f1f7e3d8e 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -831,12 +831,6 @@ rte_mbuf_to_priv(struct rte_mbuf *m)
#define RTE_MBUF_CLONED(mb) ((mb)->ol_flags & IND_ATTACHED_MBUF)
/**
- * Deprecated.
- * Use RTE_MBUF_CLONED().
- */
-#define RTE_MBUF_INDIRECT(mb) RTE_MBUF_CLONED(mb)
-
-/**
* Returns TRUE if given mbuf has an external buffer, or FALSE otherwise.
*
* External buffer is a user-provided anonymous buffer.
@@ -1629,7 +1623,7 @@ __rte_pktmbuf_free_direct(struct rte_mbuf *m)
{
struct rte_mbuf *md;
- RTE_ASSERT(RTE_MBUF_INDIRECT(m));
+ RTE_ASSERT(RTE_MBUF_CLONED(m));
md = rte_mbuf_from_indirect(m);
diff --git a/test/bpf/mbuf.h b/test/bpf/mbuf.h
index f24f908d72..b623d8694f 100644
--- a/test/bpf/mbuf.h
+++ b/test/bpf/mbuf.h
@@ -520,14 +520,21 @@ struct rte_mbuf {
/**
- * Returns TRUE if given mbuf is indirect, or FALSE otherwise.
+ * Returns TRUE if given mbuf is cloned by mbuf indirection, or FALSE
+ * otherwise.
+ *
+ * If a mbuf has its data in another mbuf and references it by mbuf
+ * indirection, this mbuf can be defined as a cloned mbuf.
*/
-#define RTE_MBUF_INDIRECT(mb) ((mb)->ol_flags & IND_ATTACHED_MBUF)
+#define RTE_MBUF_CLONED(mb) ((mb)->ol_flags & IND_ATTACHED_MBUF)
/**
* Returns TRUE if given mbuf is direct, or FALSE otherwise.
+ *
+ * If a mbuf embeds its own data after the rte_mbuf structure, this mbuf
+ * can be defined as a direct mbuf.
*/
-#define RTE_MBUF_DIRECT(mb) (!RTE_MBUF_INDIRECT(mb))
+#define RTE_MBUF_DIRECT(mb) (!RTE_MBUF_CLONED(mb))
/**
* Private data in case of pktmbuf pool.
--
2.11.0
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 1/6] ring: change head and tail to pointer-width size
2019-01-11 19:12 0% ` Eads, Gage
@ 2019-01-11 19:55 3% ` Stephen Hemminger
2019-01-15 15:48 4% ` Eads, Gage
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-01-11 19:55 UTC (permalink / raw)
To: Eads, Gage
Cc: Burakov, Anatoly, dev, olivier.matz, arybchenko, Richardson,
Bruce, Ananyev, Konstantin
On Fri, 11 Jan 2019 19:12:40 +0000
"Eads, Gage" <gage.eads@intel.com> wrote:
> > -----Original Message-----
> > From: Burakov, Anatoly
> > Sent: Friday, January 11, 2019 4:25 AM
> > 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>
> > Subject: Re: [dpdk-dev] [PATCH 1/6] ring: change head and tail to pointer-width
> > size
> >
> > On 10-Jan-19 9:01 PM, Gage Eads wrote:
> > > For 64-bit architectures, doubling the 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 important in 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.
> > >
> > > I tested this commit's performance impact with an x86_64 build on a
> > > dual-socket Xeon E5-2699 v4 using ring_perf_autotest, and the change
> > > made no significant difference -- the few differences appear to be system
> > noise.
> > > (The test ran on isolcpus cores using a tickless scheduler, but some
> > > variation was stll observed.) Each test was run three times and the
> > > results were averaged:
> > >
> > > | 64b head/tail cycle cost minus
> > > Test | 32b head/tail cycle cost
> > > ------------------------------------------------------------------
> > > SP/SC single enq/dequeue | 0.33
> > > MP/MC single enq/dequeue | 0.00
> > > SP/SC burst enq/dequeue (size 8) | 0.00 MP/MC burst enq/dequeue (size
> > > 8) | 1.00 SP/SC burst enq/dequeue (size 32) | 0.00 MP/MC burst
> > > enq/dequeue (size 32) | -1.00
> > > SC empty dequeue | 0.01
> > > MC empty dequeue | 0.00
> > >
> > > Single lcore:
> > > SP/SC bulk enq/dequeue (size 8) | -0.36
> > > MP/MC bulk enq/dequeue (size 8) | 0.99
> > > SP/SC bulk enq/dequeue (size 32) | -0.40 MP/MC bulk enq/dequeue (size
> > > 32) | -0.57
> > >
> > > Two physical cores:
> > > SP/SC bulk enq/dequeue (size 8) | -0.49
> > > MP/MC bulk enq/dequeue (size 8) | 0.19
> > > SP/SC bulk enq/dequeue (size 32) | -0.28 MP/MC bulk enq/dequeue (size
> > > 32) | -0.62
> > >
> > > Two NUMA nodes:
> > > SP/SC bulk enq/dequeue (size 8) | 3.25
> > > MP/MC bulk enq/dequeue (size 8) | 1.87
> > > SP/SC bulk enq/dequeue (size 32) | -0.44 MP/MC bulk enq/dequeue (size
> > > 32) | -1.10
> > >
> > > An earlier version of this patch changed the head and tail indexes to
> > > uint64_t, but that caused a performance drop on 32-bit builds. With
> > > uintptr_t, no performance difference is observed on an i686 build.
> > >
> > > Signed-off-by: Gage Eads <gage.eads@intel.com>
> > > ---
> >
> > You're breaking the ABI - version bump for affected libraries is needed.
> >
> > --
> > Thanks,
> > Anatoly
>
> If I'm reading the versioning guidelines correctly, I'll need to gate the changes with the RTE_NEXT_ABI macro and provide a deprecation notice, then after a full deprecation cycle we can revert that and bump the library version. Not to mention the 3 ML ACKs.
>
> I'll address this in v2.
My understanding is that RTE_NEXT_API method is not used any more. Replaced by rte_experimental.
But this kind of change is more of a flag day event. Which means it needs to be pushed
off to a release that is planned as an ABI break (usually once a year) which would
mean 19.11.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 1/6] ring: change head and tail to pointer-width size
2019-01-11 10:25 3% ` Burakov, Anatoly
@ 2019-01-11 19:12 0% ` Eads, Gage
2019-01-11 19:55 3% ` Stephen Hemminger
0 siblings, 1 reply; 200+ results
From: Eads, Gage @ 2019-01-11 19:12 UTC (permalink / raw)
To: Burakov, Anatoly, dev
Cc: olivier.matz, arybchenko, Richardson, Bruce, Ananyev, Konstantin
> -----Original Message-----
> From: Burakov, Anatoly
> Sent: Friday, January 11, 2019 4:25 AM
> 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>
> Subject: Re: [dpdk-dev] [PATCH 1/6] ring: change head and tail to pointer-width
> size
>
> On 10-Jan-19 9:01 PM, Gage Eads wrote:
> > For 64-bit architectures, doubling the 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 important in 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.
> >
> > I tested this commit's performance impact with an x86_64 build on a
> > dual-socket Xeon E5-2699 v4 using ring_perf_autotest, and the change
> > made no significant difference -- the few differences appear to be system
> noise.
> > (The test ran on isolcpus cores using a tickless scheduler, but some
> > variation was stll observed.) Each test was run three times and the
> > results were averaged:
> >
> > | 64b head/tail cycle cost minus
> > Test | 32b head/tail cycle cost
> > ------------------------------------------------------------------
> > SP/SC single enq/dequeue | 0.33
> > MP/MC single enq/dequeue | 0.00
> > SP/SC burst enq/dequeue (size 8) | 0.00 MP/MC burst enq/dequeue (size
> > 8) | 1.00 SP/SC burst enq/dequeue (size 32) | 0.00 MP/MC burst
> > enq/dequeue (size 32) | -1.00
> > SC empty dequeue | 0.01
> > MC empty dequeue | 0.00
> >
> > Single lcore:
> > SP/SC bulk enq/dequeue (size 8) | -0.36
> > MP/MC bulk enq/dequeue (size 8) | 0.99
> > SP/SC bulk enq/dequeue (size 32) | -0.40 MP/MC bulk enq/dequeue (size
> > 32) | -0.57
> >
> > Two physical cores:
> > SP/SC bulk enq/dequeue (size 8) | -0.49
> > MP/MC bulk enq/dequeue (size 8) | 0.19
> > SP/SC bulk enq/dequeue (size 32) | -0.28 MP/MC bulk enq/dequeue (size
> > 32) | -0.62
> >
> > Two NUMA nodes:
> > SP/SC bulk enq/dequeue (size 8) | 3.25
> > MP/MC bulk enq/dequeue (size 8) | 1.87
> > SP/SC bulk enq/dequeue (size 32) | -0.44 MP/MC bulk enq/dequeue (size
> > 32) | -1.10
> >
> > An earlier version of this patch changed the head and tail indexes to
> > uint64_t, but that caused a performance drop on 32-bit builds. With
> > uintptr_t, no performance difference is observed on an i686 build.
> >
> > Signed-off-by: Gage Eads <gage.eads@intel.com>
> > ---
>
> You're breaking the ABI - version bump for affected libraries is needed.
>
> --
> Thanks,
> Anatoly
If I'm reading the versioning guidelines correctly, I'll need to gate the changes with the RTE_NEXT_ABI macro and provide a deprecation notice, then after a full deprecation cycle we can revert that and bump the library version. Not to mention the 3 ML ACKs.
I'll address this in v2.
Thanks,
Gage
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 1/6] ring: change head and tail to pointer-width size
2019-01-11 4:38 3% ` Stephen Hemminger
@ 2019-01-11 19:07 3% ` Eads, Gage
0 siblings, 0 replies; 200+ results
From: Eads, Gage @ 2019-01-11 19:07 UTC (permalink / raw)
To: Stephen Hemminger
Cc: dev, olivier.matz, arybchenko, Richardson, Bruce, Ananyev, Konstantin
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Thursday, January 10, 2019 10:39 PM
> To: Eads, Gage <gage.eads@intel.com>
> Cc: dev@dpdk.org; olivier.matz@6wind.com; arybchenko@solarflare.com;
> Richardson, Bruce <bruce.richardson@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>
> Subject: Re: [dpdk-dev] [PATCH 1/6] ring: change head and tail to pointer-width
> size
>
> On Thu, 10 Jan 2019 15:01:17 -0600
> Gage Eads <gage.eads@intel.com> wrote:
>
> > For 64-bit architectures, doubling the 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 important in 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.
> >
> > I tested this commit's performance impact with an x86_64 build on a
> > dual-socket Xeon E5-2699 v4 using ring_perf_autotest, and the change
> > made no significant difference -- the few differences appear to be system
> noise.
> > (The test ran on isolcpus cores using a tickless scheduler, but some
> > variation was stll observed.) Each test was run three times and the
> > results were averaged:
> >
> > | 64b head/tail cycle cost minus
> > Test | 32b head/tail cycle cost
> > ------------------------------------------------------------------
> > SP/SC single enq/dequeue | 0.33
> > MP/MC single enq/dequeue | 0.00
> > SP/SC burst enq/dequeue (size 8) | 0.00 MP/MC burst enq/dequeue (size
> > 8) | 1.00 SP/SC burst enq/dequeue (size 32) | 0.00 MP/MC burst
> > enq/dequeue (size 32) | -1.00
> > SC empty dequeue | 0.01
> > MC empty dequeue | 0.00
> >
> > Single lcore:
> > SP/SC bulk enq/dequeue (size 8) | -0.36
> > MP/MC bulk enq/dequeue (size 8) | 0.99
> > SP/SC bulk enq/dequeue (size 32) | -0.40 MP/MC bulk enq/dequeue (size
> > 32) | -0.57
> >
> > Two physical cores:
> > SP/SC bulk enq/dequeue (size 8) | -0.49
> > MP/MC bulk enq/dequeue (size 8) | 0.19
> > SP/SC bulk enq/dequeue (size 32) | -0.28 MP/MC bulk enq/dequeue (size
> > 32) | -0.62
> >
> > Two NUMA nodes:
> > SP/SC bulk enq/dequeue (size 8) | 3.25
> > MP/MC bulk enq/dequeue (size 8) | 1.87
> > SP/SC bulk enq/dequeue (size 32) | -0.44 MP/MC bulk enq/dequeue (size
> > 32) | -1.10
> >
> > An earlier version of this patch changed the head and tail indexes to
> > uint64_t, but that caused a performance drop on 32-bit builds. With
> > uintptr_t, no performance difference is observed on an i686 build.
> >
> > Signed-off-by: Gage Eads <gage.eads@intel.com>
> > ---
> > lib/librte_eventdev/rte_event_ring.h | 6 +++---
> > lib/librte_ring/rte_ring.c | 10 +++++-----
> > lib/librte_ring/rte_ring.h | 20 ++++++++++----------
> > lib/librte_ring/rte_ring_generic.h | 16 +++++++++-------
> > 4 files changed, 27 insertions(+), 25 deletions(-)
> >
> > diff --git a/lib/librte_eventdev/rte_event_ring.h
> > b/lib/librte_eventdev/rte_event_ring.h
> > index 827a3209e..eae70f904 100644
> > --- a/lib/librte_eventdev/rte_event_ring.h
> > +++ b/lib/librte_eventdev/rte_event_ring.h
> > @@ -1,5 +1,5 @@
> > /* SPDX-License-Identifier: BSD-3-Clause
> > - * Copyright(c) 2016-2017 Intel Corporation
> > + * Copyright(c) 2016-2019 Intel Corporation
> > */
> >
> > /**
> > @@ -88,7 +88,7 @@ rte_event_ring_enqueue_burst(struct rte_event_ring *r,
> > const struct rte_event *events,
> > unsigned int n, uint16_t *free_space) {
> > - uint32_t prod_head, prod_next;
> > + uintptr_t prod_head, prod_next;
> > uint32_t free_entries;
> >
> > n = __rte_ring_move_prod_head(&r->r, r->r.prod.single, n, @@ -129,7
> > +129,7 @@ rte_event_ring_dequeue_burst(struct rte_event_ring *r,
> > struct rte_event *events,
> > unsigned int n, uint16_t *available) {
> > - uint32_t cons_head, cons_next;
> > + uintptr_t cons_head, cons_next;
> > uint32_t entries;
> >
> > n = __rte_ring_move_cons_head(&r->r, r->r.cons.single, n, diff --git
> > a/lib/librte_ring/rte_ring.c b/lib/librte_ring/rte_ring.c index
> > d215acecc..b15ee0eb3 100644
> > --- a/lib/librte_ring/rte_ring.c
> > +++ b/lib/librte_ring/rte_ring.c
> > @@ -1,6 +1,6 @@
> > /* SPDX-License-Identifier: BSD-3-Clause
> > *
> > - * Copyright (c) 2010-2015 Intel Corporation
> > + * Copyright (c) 2010-2019 Intel Corporation
> > * Copyright (c) 2007,2008 Kip Macy kmacy@freebsd.org
> > * All rights reserved.
> > * Derived from FreeBSD's bufring.h
> > @@ -227,10 +227,10 @@ rte_ring_dump(FILE *f, const struct rte_ring *r)
> > fprintf(f, " flags=%x\n", r->flags);
> > fprintf(f, " size=%"PRIu32"\n", r->size);
> > fprintf(f, " capacity=%"PRIu32"\n", r->capacity);
> > - fprintf(f, " ct=%"PRIu32"\n", r->cons.tail);
> > - fprintf(f, " ch=%"PRIu32"\n", r->cons.head);
> > - fprintf(f, " pt=%"PRIu32"\n", r->prod.tail);
> > - fprintf(f, " ph=%"PRIu32"\n", r->prod.head);
> > + fprintf(f, " ct=%"PRIuPTR"\n", r->cons.tail);
> > + fprintf(f, " ch=%"PRIuPTR"\n", r->cons.head);
> > + fprintf(f, " pt=%"PRIuPTR"\n", r->prod.tail);
> > + fprintf(f, " ph=%"PRIuPTR"\n", r->prod.head);
> > fprintf(f, " used=%u\n", rte_ring_count(r));
> > fprintf(f, " avail=%u\n", rte_ring_free_count(r)); } diff --git
> > a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h index
> > af5444a9f..12af64e13 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
> > @@ -65,8 +65,8 @@ struct rte_memzone; /* forward declaration, so as
> > not to require memzone.h */
> >
> > /* structure to hold a pair of head/tail values and other metadata */
> > struct rte_ring_headtail {
> > - volatile uint32_t head; /**< Prod/consumer head. */
> > - volatile uint32_t tail; /**< Prod/consumer tail. */
> > + volatile uintptr_t head; /**< Prod/consumer head. */
> > + volatile uintptr_t tail; /**< Prod/consumer tail. */
> > uint32_t single; /**< True if single prod/cons */
> > };
>
> Isn't this a major ABI change which will break existing applications?
Correct, and this patch needs to be reworked with the RTE_NEXT_ABI ifdef, as described in the versioning guidelines. I had misunderstood the ABI change procedure, but I'll fix this in v2.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 1/6] ring: change head and tail to pointer-width size
2019-01-11 4:38 3% ` Stephen Hemminger
@ 2019-01-11 10:25 3% ` Burakov, Anatoly
2019-01-11 19:12 0% ` Eads, Gage
2 siblings, 1 reply; 200+ results
From: Burakov, Anatoly @ 2019-01-11 10:25 UTC (permalink / raw)
To: Gage Eads, dev
Cc: olivier.matz, arybchenko, bruce.richardson, konstantin.ananyev
On 10-Jan-19 9:01 PM, Gage Eads wrote:
> For 64-bit architectures, doubling the 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 important in
> 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.
>
> I tested this commit's performance impact with an x86_64 build on a
> dual-socket Xeon E5-2699 v4 using ring_perf_autotest, and the change made
> no significant difference -- the few differences appear to be system noise.
> (The test ran on isolcpus cores using a tickless scheduler, but some
> variation was stll observed.) Each test was run three times and the results
> were averaged:
>
> | 64b head/tail cycle cost minus
> Test | 32b head/tail cycle cost
> ------------------------------------------------------------------
> SP/SC single enq/dequeue | 0.33
> MP/MC single enq/dequeue | 0.00
> SP/SC burst enq/dequeue (size 8) | 0.00
> MP/MC burst enq/dequeue (size 8) | 1.00
> SP/SC burst enq/dequeue (size 32) | 0.00
> MP/MC burst enq/dequeue (size 32) | -1.00
> SC empty dequeue | 0.01
> MC empty dequeue | 0.00
>
> Single lcore:
> SP/SC bulk enq/dequeue (size 8) | -0.36
> MP/MC bulk enq/dequeue (size 8) | 0.99
> SP/SC bulk enq/dequeue (size 32) | -0.40
> MP/MC bulk enq/dequeue (size 32) | -0.57
>
> Two physical cores:
> SP/SC bulk enq/dequeue (size 8) | -0.49
> MP/MC bulk enq/dequeue (size 8) | 0.19
> SP/SC bulk enq/dequeue (size 32) | -0.28
> MP/MC bulk enq/dequeue (size 32) | -0.62
>
> Two NUMA nodes:
> SP/SC bulk enq/dequeue (size 8) | 3.25
> MP/MC bulk enq/dequeue (size 8) | 1.87
> SP/SC bulk enq/dequeue (size 32) | -0.44
> MP/MC bulk enq/dequeue (size 32) | -1.10
>
> An earlier version of this patch changed the head and tail indexes to
> uint64_t, but that caused a performance drop on 32-bit builds. With
> uintptr_t, no performance difference is observed on an i686 build.
>
> Signed-off-by: Gage Eads <gage.eads@intel.com>
> ---
You're breaking the ABI - version bump for affected libraries is needed.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 1/6] ring: change head and tail to pointer-width size
@ 2019-01-11 4:38 3% ` Stephen Hemminger
2019-01-11 19:07 3% ` Eads, Gage
2019-01-11 10:25 3% ` Burakov, Anatoly
2 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-01-11 4:38 UTC (permalink / raw)
To: Gage Eads
Cc: dev, olivier.matz, arybchenko, bruce.richardson, konstantin.ananyev
On Thu, 10 Jan 2019 15:01:17 -0600
Gage Eads <gage.eads@intel.com> wrote:
> For 64-bit architectures, doubling the 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 important in
> 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.
>
> I tested this commit's performance impact with an x86_64 build on a
> dual-socket Xeon E5-2699 v4 using ring_perf_autotest, and the change made
> no significant difference -- the few differences appear to be system noise.
> (The test ran on isolcpus cores using a tickless scheduler, but some
> variation was stll observed.) Each test was run three times and the results
> were averaged:
>
> | 64b head/tail cycle cost minus
> Test | 32b head/tail cycle cost
> ------------------------------------------------------------------
> SP/SC single enq/dequeue | 0.33
> MP/MC single enq/dequeue | 0.00
> SP/SC burst enq/dequeue (size 8) | 0.00
> MP/MC burst enq/dequeue (size 8) | 1.00
> SP/SC burst enq/dequeue (size 32) | 0.00
> MP/MC burst enq/dequeue (size 32) | -1.00
> SC empty dequeue | 0.01
> MC empty dequeue | 0.00
>
> Single lcore:
> SP/SC bulk enq/dequeue (size 8) | -0.36
> MP/MC bulk enq/dequeue (size 8) | 0.99
> SP/SC bulk enq/dequeue (size 32) | -0.40
> MP/MC bulk enq/dequeue (size 32) | -0.57
>
> Two physical cores:
> SP/SC bulk enq/dequeue (size 8) | -0.49
> MP/MC bulk enq/dequeue (size 8) | 0.19
> SP/SC bulk enq/dequeue (size 32) | -0.28
> MP/MC bulk enq/dequeue (size 32) | -0.62
>
> Two NUMA nodes:
> SP/SC bulk enq/dequeue (size 8) | 3.25
> MP/MC bulk enq/dequeue (size 8) | 1.87
> SP/SC bulk enq/dequeue (size 32) | -0.44
> MP/MC bulk enq/dequeue (size 32) | -1.10
>
> An earlier version of this patch changed the head and tail indexes to
> uint64_t, but that caused a performance drop on 32-bit builds. With
> uintptr_t, no performance difference is observed on an i686 build.
>
> Signed-off-by: Gage Eads <gage.eads@intel.com>
> ---
> lib/librte_eventdev/rte_event_ring.h | 6 +++---
> lib/librte_ring/rte_ring.c | 10 +++++-----
> lib/librte_ring/rte_ring.h | 20 ++++++++++----------
> lib/librte_ring/rte_ring_generic.h | 16 +++++++++-------
> 4 files changed, 27 insertions(+), 25 deletions(-)
>
> diff --git a/lib/librte_eventdev/rte_event_ring.h b/lib/librte_eventdev/rte_event_ring.h
> index 827a3209e..eae70f904 100644
> --- a/lib/librte_eventdev/rte_event_ring.h
> +++ b/lib/librte_eventdev/rte_event_ring.h
> @@ -1,5 +1,5 @@
> /* SPDX-License-Identifier: BSD-3-Clause
> - * Copyright(c) 2016-2017 Intel Corporation
> + * Copyright(c) 2016-2019 Intel Corporation
> */
>
> /**
> @@ -88,7 +88,7 @@ rte_event_ring_enqueue_burst(struct rte_event_ring *r,
> const struct rte_event *events,
> unsigned int n, uint16_t *free_space)
> {
> - uint32_t prod_head, prod_next;
> + uintptr_t prod_head, prod_next;
> uint32_t free_entries;
>
> n = __rte_ring_move_prod_head(&r->r, r->r.prod.single, n,
> @@ -129,7 +129,7 @@ rte_event_ring_dequeue_burst(struct rte_event_ring *r,
> struct rte_event *events,
> unsigned int n, uint16_t *available)
> {
> - uint32_t cons_head, cons_next;
> + uintptr_t cons_head, cons_next;
> uint32_t entries;
>
> n = __rte_ring_move_cons_head(&r->r, r->r.cons.single, n,
> diff --git a/lib/librte_ring/rte_ring.c b/lib/librte_ring/rte_ring.c
> index d215acecc..b15ee0eb3 100644
> --- a/lib/librte_ring/rte_ring.c
> +++ b/lib/librte_ring/rte_ring.c
> @@ -1,6 +1,6 @@
> /* SPDX-License-Identifier: BSD-3-Clause
> *
> - * Copyright (c) 2010-2015 Intel Corporation
> + * Copyright (c) 2010-2019 Intel Corporation
> * Copyright (c) 2007,2008 Kip Macy kmacy@freebsd.org
> * All rights reserved.
> * Derived from FreeBSD's bufring.h
> @@ -227,10 +227,10 @@ rte_ring_dump(FILE *f, const struct rte_ring *r)
> fprintf(f, " flags=%x\n", r->flags);
> fprintf(f, " size=%"PRIu32"\n", r->size);
> fprintf(f, " capacity=%"PRIu32"\n", r->capacity);
> - fprintf(f, " ct=%"PRIu32"\n", r->cons.tail);
> - fprintf(f, " ch=%"PRIu32"\n", r->cons.head);
> - fprintf(f, " pt=%"PRIu32"\n", r->prod.tail);
> - fprintf(f, " ph=%"PRIu32"\n", r->prod.head);
> + fprintf(f, " ct=%"PRIuPTR"\n", r->cons.tail);
> + fprintf(f, " ch=%"PRIuPTR"\n", r->cons.head);
> + fprintf(f, " pt=%"PRIuPTR"\n", r->prod.tail);
> + fprintf(f, " ph=%"PRIuPTR"\n", r->prod.head);
> fprintf(f, " used=%u\n", rte_ring_count(r));
> fprintf(f, " avail=%u\n", rte_ring_free_count(r));
> }
> diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
> index af5444a9f..12af64e13 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
> @@ -65,8 +65,8 @@ struct rte_memzone; /* forward declaration, so as not to require memzone.h */
>
> /* structure to hold a pair of head/tail values and other metadata */
> struct rte_ring_headtail {
> - volatile uint32_t head; /**< Prod/consumer head. */
> - volatile uint32_t tail; /**< Prod/consumer tail. */
> + volatile uintptr_t head; /**< Prod/consumer head. */
> + volatile uintptr_t tail; /**< Prod/consumer tail. */
> uint32_t single; /**< True if single prod/cons */
> };
Isn't this a major ABI change which will break existing applications?
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v6 00/10] ipsec: new library for IPsec data-path processing
2019-01-03 20:16 2% ` [dpdk-dev] [PATCH v6 00/10] ipsec: new library for IPsec data-path processing Konstantin Ananyev
@ 2019-01-11 1:09 2% ` Xu, Yanjie
0 siblings, 0 replies; 200+ results
From: Xu, Yanjie @ 2019-01-11 1:09 UTC (permalink / raw)
To: Ananyev, Konstantin, dev, dev; +Cc: akhil.goyal
The patch series latest versions be tested by yanjie xu, which work for crypto and inline ipsec cases.
-----Original Message-----
From: Ananyev, Konstantin
Sent: Friday, January 4, 2019 4:16 AM
To: dev@dpdk.org; dev@dpdk.org
Cc: akhil.goyal@nxp.com; Ananyev, Konstantin <konstantin.ananyev@intel.com>
Subject: [PATCH v6 00/10] ipsec: new library for IPsec data-path processing
v5 -> v6
- Fix issues reported by Akhil:
rte_ipsec_session_prepare() fails for lookaside-proto
v4 -> v5
- Fix issue with SQN overflows
- Address Akhil comments:
documentation update
spell checks spacing etc.
fix input crypto_xform check/prepcess
test cases for lookaside and inline proto
v3 -> v4
- Changes to adress Declan comments
- Update docs
v2 -> v3
- Several fixes for IPv6 support
- Extra checks for input parameters in public APi functions
v1 -> v2
- Changes to get into account l2_len for outbound transport packets
(Qi comments)
- Several bug fixes
- Some code restructured
- Update MAINTAINERS file
RFCv2 -> v1
- Changes per Jerin comments
- Implement transport mode
- Several bug fixes
- UT largely reworked and extended
This patch introduces a new library within DPDK: librte_ipsec.
The aim is to provide DPDK native high performance library for IPsec data-path processing.
The library is supposed to utilize existing DPDK crypto-dev and security API to provide application with transparent IPsec processing API.
The library is concentrated on data-path protocols processing (ESP and AH), IKE protocol(s) implementation is out of scope for that library.
Current patch introduces SA-level API.
SA (low) level API
==================
API described below operates on SA level.
It provides functionality that allows user for given SA to process inbound and outbound IPsec packets.
To be more specific:
- for inbound ESP/AH packets perform decryption, authentication,
integrity checking, remove ESP/AH related headers
- for outbound packets perform payload encryption, attach ICV,
update/add IP headers, add ESP/AH headers/trailers,
setup related mbuf felids (ol_flags, tx_offloads, etc.).
- initialize/un-initialize given SA based on user provided parameters.
The following functionality:
- match inbound/outbound packets to particular SA
- manage crypto/security devices
- provide SAD/SPD related functionality
- determine what crypto/security device has to be used
for given packet(s)
is out of scope for SA-level API.
SA-level API is based on top of crypto-dev/security API and relies on them to perform actual cipher and integrity checking.
To have an ability to easily map crypto/security sessions into related IPSec SA opaque userdata field was added into rte_cryptodev_sym_session and rte_security_session structures.
That implies ABI change for both librte_crytpodev and librte_security.
Due to the nature of crypto-dev API (enqueue/deque model) we use asynchronous API for IPsec packets destined to be processed by crypto-device.
Expected API call sequence would be:
/* enqueue for processing by crypto-device */
rte_ipsec_pkt_crypto_prepare(...);
rte_cryptodev_enqueue_burst(...);
/* dequeue from crypto-device and do final processing (if any) */
rte_cryptodev_dequeue_burst(...);
rte_ipsec_pkt_crypto_group(...); /* optional */
rte_ipsec_pkt_process(...);
Though for packets destined for inline processing no extra overhead is required and synchronous API call: rte_ipsec_pkt_process() is sufficient for that case.
Current implementation supports all four currently defined rte_security types.
Though to accommodate future custom implementations function pointers model is used for both for *crypto_prepare* and *process* impelementations.
Konstantin Ananyev (10):
cryptodev: add opaque userdata pointer into crypto sym session
security: add opaque userdata pointer into security session
net: add ESP trailer structure definition
lib: introduce ipsec library
ipsec: add SA data-path API
ipsec: implement SA data-path API
ipsec: rework SA replay window/SQN for MT environment
ipsec: helper functions to group completed crypto-ops
test/ipsec: introduce functional test
doc: add IPsec library guide
MAINTAINERS | 8 +-
config/common_base | 5 +
doc/guides/prog_guide/index.rst | 1 +
doc/guides/prog_guide/ipsec_lib.rst | 168 ++
doc/guides/rel_notes/release_19_02.rst | 11 +
lib/Makefile | 2 +
lib/librte_cryptodev/rte_cryptodev.h | 2 +
lib/librte_ipsec/Makefile | 27 +
lib/librte_ipsec/crypto.h | 123 ++
lib/librte_ipsec/iph.h | 84 +
lib/librte_ipsec/ipsec_sqn.h | 343 ++++
lib/librte_ipsec/meson.build | 10 +
lib/librte_ipsec/pad.h | 45 +
lib/librte_ipsec/rte_ipsec.h | 154 ++
lib/librte_ipsec/rte_ipsec_group.h | 151 ++
lib/librte_ipsec/rte_ipsec_sa.h | 174 ++
lib/librte_ipsec/rte_ipsec_version.map | 15 +
lib/librte_ipsec/sa.c | 1527 ++++++++++++++
lib/librte_ipsec/sa.h | 106 +
lib/librte_ipsec/ses.c | 52 +
lib/librte_net/rte_esp.h | 10 +-
lib/librte_security/rte_security.h | 2 +
lib/meson.build | 2 +
mk/rte.app.mk | 2 +
test/test/Makefile | 3 +
test/test/meson.build | 3 +
test/test/test_ipsec.c | 2555 ++++++++++++++++++++++++
27 files changed, 5583 insertions(+), 2 deletions(-) create mode 100644 doc/guides/prog_guide/ipsec_lib.rst
create mode 100644 lib/librte_ipsec/Makefile create mode 100644 lib/librte_ipsec/crypto.h create mode 100644 lib/librte_ipsec/iph.h create mode 100644 lib/librte_ipsec/ipsec_sqn.h create mode 100644 lib/librte_ipsec/meson.build create mode 100644 lib/librte_ipsec/pad.h create mode 100644 lib/librte_ipsec/rte_ipsec.h create mode 100644 lib/librte_ipsec/rte_ipsec_group.h
create mode 100644 lib/librte_ipsec/rte_ipsec_sa.h create mode 100644 lib/librte_ipsec/rte_ipsec_version.map
create mode 100644 lib/librte_ipsec/sa.c create mode 100644 lib/librte_ipsec/sa.h create mode 100644 lib/librte_ipsec/ses.c create mode 100644 test/test/test_ipsec.c
--
2.17.1
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v8 1/9] security: add opaque userdata pointer into security session
2019-01-10 14:20 5% ` [dpdk-dev] [PATCH v7 01/10] cryptodev: add opaque userdata pointer into crypto sym session Konstantin Ananyev
2019-01-10 21:06 4% ` [dpdk-dev] [PATCH v8 0/9] ipsec: new library for IPsec data-path processing Konstantin Ananyev
@ 2019-01-10 21:06 5% ` Konstantin Ananyev
1 sibling, 0 replies; 200+ results
From: Konstantin Ananyev @ 2019-01-10 21:06 UTC (permalink / raw)
To: dev; +Cc: akhil.goyal, pablo.de.lara.guarch, thomas, Konstantin Ananyev
Add 'uint64_t opaque_data' inside struct rte_security_session.
That allows upper layer to easily associate some user defined
data with the session.
Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
Acked-by: Mohammad Abdul Awal <mohammad.abdul.awal@intel.com>
Acked-by: Declan Doherty <declan.doherty@intel.com>
Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
---
doc/guides/rel_notes/deprecation.rst | 4 ----
doc/guides/rel_notes/release_19_02.rst | 6 +++++-
lib/librte_security/Makefile | 4 ++--
lib/librte_security/meson.build | 3 ++-
lib/librte_security/rte_security.h | 2 ++
5 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 07a5b4cea..bab82865f 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -71,9 +71,5 @@ Deprecation Notices
- Member ``uint16_t min_mtu`` the minimum MTU allowed.
- Member ``uint16_t max_mtu`` the maximum MTU allowed.
-* security: New field ``uint64_t opaque_data`` is planned to be added into
- ``rte_security_session`` structure. That would allow upper layer to easily
- associate/de-associate some user defined data with the security session.
-
* 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_02.rst b/doc/guides/rel_notes/release_19_02.rst
index 86880275a..1aebd27c7 100644
--- a/doc/guides/rel_notes/release_19_02.rst
+++ b/doc/guides/rel_notes/release_19_02.rst
@@ -212,6 +212,10 @@ ABI Changes
``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
+ ``rte_security_session`` structure. That would allow upper layer to easily
+ associate/de-associate some user defined data with the security session.
+
Shared Library Versions
-----------------------
@@ -282,7 +286,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_reorder.so.1
librte_ring.so.2
+ librte_sched.so.2
- librte_security.so.1
+ + librte_security.so.2
librte_table.so.3
librte_timer.so.1
librte_vhost.so.4
diff --git a/lib/librte_security/Makefile b/lib/librte_security/Makefile
index bd92343bd..6708effdb 100644
--- a/lib/librte_security/Makefile
+++ b/lib/librte_security/Makefile
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: BSD-3-Clause
-# Copyright(c) 2017 Intel Corporation
+# Copyright(c) 2017-2019 Intel Corporation
include $(RTE_SDK)/mk/rte.vars.mk
@@ -7,7 +7,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
LIB = librte_security.a
# library version
-LIBABIVER := 1
+LIBABIVER := 2
# build flags
CFLAGS += -O3
diff --git a/lib/librte_security/meson.build b/lib/librte_security/meson.build
index 532953fcc..a5130d2f6 100644
--- a/lib/librte_security/meson.build
+++ b/lib/librte_security/meson.build
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
-# Copyright(c) 2017 Intel Corporation
+# Copyright(c) 2017-2019 Intel Corporation
+version = 2
sources = files('rte_security.c')
headers = files('rte_security.h', 'rte_security_driver.h')
deps += ['mempool', 'cryptodev']
diff --git a/lib/librte_security/rte_security.h b/lib/librte_security/rte_security.h
index 718147e00..c8e438fdd 100644
--- a/lib/librte_security/rte_security.h
+++ b/lib/librte_security/rte_security.h
@@ -317,6 +317,8 @@ struct rte_security_session_conf {
struct rte_security_session {
void *sess_private_data;
/**< Private session material */
+ uint64_t opaque_data;
+ /**< Opaque user defined data */
};
/**
--
2.17.1
^ permalink raw reply [relevance 5%]
* [dpdk-dev] [PATCH v8 0/9] ipsec: new library for IPsec data-path processing
2019-01-10 14:20 5% ` [dpdk-dev] [PATCH v7 01/10] cryptodev: add opaque userdata pointer into crypto sym session Konstantin Ananyev
@ 2019-01-10 21:06 4% ` Konstantin Ananyev
2019-01-10 21:06 5% ` [dpdk-dev] [PATCH v8 1/9] security: add opaque userdata pointer into security session Konstantin Ananyev
1 sibling, 0 replies; 200+ results
From: Konstantin Ananyev @ 2019-01-10 21:06 UTC (permalink / raw)
To: dev; +Cc: akhil.goyal, pablo.de.lara.guarch, thomas, Konstantin Ananyev
v7 -> v8
- update release notes with new version for librte_security
- rebase on top of crypto-next
v6 -> v7
- Changes to address Thomas comments:
bump ABI version
remove related deprecation notice
update release notes, ABI changes section
v5 -> v6
- Fix issues reported by Akhil:
rte_ipsec_session_prepare() fails for lookaside-proto
v4 -> v5
- Fix issue with SQN overflows
- Address Akhil comments:
documentation update
spell checks spacing etc.
fix input crypto_xform check/prepcess
test cases for lookaside and inline proto
v3 -> v4
- Changes to address Declan comments
- Update docs
v2 -> v3
- Several fixes for IPv6 support
- Extra checks for input parameters in public APi functions
v1 -> v2
- Changes to get into account l2_len for outbound transport packets
(Qi comments)
- Several bug fixes
- Some code restructured
- Update MAINTAINERS file
RFCv2 -> v1
- Changes per Jerin comments
- Implement transport mode
- Several bug fixes
- UT largely reworked and extended
This patch introduces a new library within DPDK: librte_ipsec.
The aim is to provide DPDK native high performance library for IPsec
data-path processing.
The library is supposed to utilize existing DPDK crypto-dev and
security API to provide application with transparent IPsec
processing API.
The library is concentrated on data-path protocols processing
(ESP and AH), IKE protocol(s) implementation is out of scope
for that library.
Current patch introduces SA-level API.
SA level API
============
API described below operates on SA level.
It provides functionality that allows user for given SA to process
inbound and outbound IPsec packets.
To be more specific:
- for inbound ESP/AH packets perform decryption, authentication,
integrity checking, remove ESP/AH related headers
- for outbound packets perform payload encryption, attach ICV,
update/add IP headers, add ESP/AH headers/trailers,
setup related mbuf felids (ol_flags, tx_offloads, etc.).
- initialize/un-initialize given SA based on user provided parameters.
The following functionality:
- match inbound/outbound packets to particular SA
- manage crypto/security devices
- provide SAD/SPD related functionality
- determine what crypto/security device has to be used
for given packet(s)
is out of scope for SA-level API.
SA-level API is based on top of crypto-dev/security API and relies on
them
to perform actual cipher and integrity checking.
To have an ability to easily map crypto/security sessions into related
IPSec SA opaque userdata field was added into
rte_cryptodev_sym_session and rte_security_session structures.
That implies ABI change for both librte_crytpodev and librte_security.
Due to the nature of crypto-dev API (enqueue/deque model) we use
asynchronous API for IPsec packets destined to be processed by
crypto-device.
Expected API call sequence would be:
/* enqueue for processing by crypto-device */
rte_ipsec_pkt_crypto_prepare(...);
rte_cryptodev_enqueue_burst(...);
/* dequeue from crypto-device and do final processing (if any) */
rte_cryptodev_dequeue_burst(...);
rte_ipsec_pkt_crypto_group(...); /* optional */
rte_ipsec_pkt_process(...);
Though for packets destined for inline processing no extra overhead
is required and synchronous API call: rte_ipsec_pkt_process()
is sufficient for that case.
Current implementation supports all four currently defined
rte_security types.
Though to accommodate future custom implementations function pointers
model is used for both for *crypto_prepare* and *process*
impelementations.
Konstantin Ananyev (9):
security: add opaque userdata pointer into security session
net: add ESP trailer structure definition
lib: introduce ipsec library
ipsec: add SA data-path API
ipsec: implement SA data-path API
ipsec: rework SA replay window/SQN for MT environment
ipsec: helper functions to group completed crypto-ops
test/ipsec: introduce functional test
doc: add IPsec library guide
MAINTAINERS | 8 +-
config/common_base | 5 +
doc/guides/prog_guide/index.rst | 1 +
doc/guides/prog_guide/ipsec_lib.rst | 168 ++
doc/guides/rel_notes/deprecation.rst | 4 -
doc/guides/rel_notes/release_19_02.rst | 17 +-
lib/Makefile | 2 +
lib/librte_ipsec/Makefile | 27 +
lib/librte_ipsec/crypto.h | 123 ++
lib/librte_ipsec/iph.h | 84 +
lib/librte_ipsec/ipsec_sqn.h | 343 ++++
lib/librte_ipsec/meson.build | 10 +
lib/librte_ipsec/pad.h | 45 +
lib/librte_ipsec/rte_ipsec.h | 154 ++
lib/librte_ipsec/rte_ipsec_group.h | 151 ++
lib/librte_ipsec/rte_ipsec_sa.h | 174 ++
lib/librte_ipsec/rte_ipsec_version.map | 15 +
lib/librte_ipsec/sa.c | 1527 ++++++++++++++
lib/librte_ipsec/sa.h | 106 +
lib/librte_ipsec/ses.c | 52 +
lib/librte_net/rte_esp.h | 10 +-
lib/librte_security/Makefile | 4 +-
lib/librte_security/meson.build | 3 +-
lib/librte_security/rte_security.h | 2 +
lib/meson.build | 2 +
mk/rte.app.mk | 2 +
test/test/Makefile | 3 +
test/test/meson.build | 3 +
test/test/test_ipsec.c | 2565 ++++++++++++++++++++++++
29 files changed, 5600 insertions(+), 10 deletions(-)
create mode 100644 doc/guides/prog_guide/ipsec_lib.rst
create mode 100644 lib/librte_ipsec/Makefile
create mode 100644 lib/librte_ipsec/crypto.h
create mode 100644 lib/librte_ipsec/iph.h
create mode 100644 lib/librte_ipsec/ipsec_sqn.h
create mode 100644 lib/librte_ipsec/meson.build
create mode 100644 lib/librte_ipsec/pad.h
create mode 100644 lib/librte_ipsec/rte_ipsec.h
create mode 100644 lib/librte_ipsec/rte_ipsec_group.h
create mode 100644 lib/librte_ipsec/rte_ipsec_sa.h
create mode 100644 lib/librte_ipsec/rte_ipsec_version.map
create mode 100644 lib/librte_ipsec/sa.c
create mode 100644 lib/librte_ipsec/sa.h
create mode 100644 lib/librte_ipsec/ses.c
create mode 100644 test/test/test_ipsec.c
--
2.17.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH 0/6] Add non-blocking ring
@ 2019-01-10 21:01 4% Gage Eads
2019-01-15 23:52 3% ` [dpdk-dev] [PATCH v2 0/5] Add non-blocking ring Gage Eads
0 siblings, 2 replies; 200+ results
From: Gage Eads @ 2019-01-10 21:01 UTC (permalink / raw)
To: dev; +Cc: olivier.matz, arybchenko, bruce.richardson, konstantin.ananyev
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 limited to x86_64 machines.
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 ABI changes, and thus an ABI update announcement and
deprecation cycle are required.
This patchset depends on the non-blocking stack patchset[1].
[1] http://mails.dpdk.org/archives/dev/2019-January/122923.html
Gage Eads (6):
ring: change head and tail to pointer-width size
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: add NB ring comment to EAL "known issues"
doc/guides/prog_guide/env_abstraction_layer.rst | 2 +-
drivers/mempool/ring/rte_mempool_ring.c | 58 ++-
lib/librte_eventdev/rte_event_ring.h | 6 +-
lib/librte_ring/rte_ring.c | 53 ++-
lib/librte_ring/rte_ring.h | 555 ++++++++++++++++++++++--
lib/librte_ring/rte_ring_generic.h | 16 +-
lib/librte_ring/rte_ring_version.map | 7 +
test/test/test_ring.c | 57 ++-
test/test/test_ring_perf.c | 19 +-
9 files changed, 689 insertions(+), 84 deletions(-)
--
2.13.6
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v7 00/10] ipsec: new library for IPsec data-path processing
2019-01-10 15:00 0% ` Akhil Goyal
@ 2019-01-10 15:09 0% ` Akhil Goyal
0 siblings, 0 replies; 200+ results
From: Akhil Goyal @ 2019-01-10 15:09 UTC (permalink / raw)
To: Ananyev, Konstantin, Thomas Monjalon; +Cc: dev, De Lara Guarch, Pablo
On 1/10/2019 8:30 PM, Akhil Goyal wrote:
>
> On 1/10/2019 8:28 PM, Ananyev, Konstantin wrote:
>>> -----Original Message-----
>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
>>> Sent: Thursday, January 10, 2019 2:55 PM
>>> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
>>> Cc: dev@dpdk.org; akhil.goyal@nxp.com; De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
>>> Subject: Re: [PATCH v7 00/10] ipsec: new library for IPsec data-path processing
>>>
>>> 10/01/2019 15:52, Ananyev, Konstantin:
>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
>>>>> 10/01/2019 15:20, Konstantin Ananyev:
>>>>>> v6 -> v7
>>>>>> - Changes to address Thomas comments:
>>>>>> bump ABI version
>>>>>> remove related deprecation notice
>>>>>> update release notes, ABI changes section
>>>>> You did not update the lib versions in the release notes.
>>>> For 'security: add opaque userdata pointer into security session':
>>>> 1) removed deprecation notice
>>>> 2) add ABI change into release note:
>>>> +* security: New field ``uint64_t opaque_data`` is added into
>>>> + ``rte_security_session`` structure. That would allow upper layer to easily
>>>> + associate/de-associate some user defined data with the security session.
>>>> +
>>>> 3) Bumbed version in Makefile and meson.build
>>>>
>>>> What else needs to be done here?
>>> Like I said, "update the lib versions in the release notes".
>>> Please check at the bottom of the page, there is a list of libraries.
>> Ah, ok.
>> Will submit v8 then.
> Wait a for Pablo to apply the Fan's patchset. I think he would be
> applying soon.
> There will be conflict in 2-3 patches. You can rebase it and then send it
You can also fix the warnings of the check-git-log as well as you are
sending another version for app and lib
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 00/10] ipsec: new library for IPsec data-path processing
2019-01-10 14:58 0% ` Ananyev, Konstantin
@ 2019-01-10 15:00 0% ` Akhil Goyal
2019-01-10 15:09 0% ` Akhil Goyal
0 siblings, 1 reply; 200+ results
From: Akhil Goyal @ 2019-01-10 15:00 UTC (permalink / raw)
To: Ananyev, Konstantin, Thomas Monjalon; +Cc: dev, De Lara Guarch, Pablo
On 1/10/2019 8:28 PM, Ananyev, Konstantin wrote:
>
>> -----Original Message-----
>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
>> Sent: Thursday, January 10, 2019 2:55 PM
>> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
>> Cc: dev@dpdk.org; akhil.goyal@nxp.com; De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
>> Subject: Re: [PATCH v7 00/10] ipsec: new library for IPsec data-path processing
>>
>> 10/01/2019 15:52, Ananyev, Konstantin:
>>> From: Thomas Monjalon [mailto:thomas@monjalon.net]
>>>> 10/01/2019 15:20, Konstantin Ananyev:
>>>>> v6 -> v7
>>>>> - Changes to address Thomas comments:
>>>>> bump ABI version
>>>>> remove related deprecation notice
>>>>> update release notes, ABI changes section
>>>> You did not update the lib versions in the release notes.
>>> For 'security: add opaque userdata pointer into security session':
>>> 1) removed deprecation notice
>>> 2) add ABI change into release note:
>>> +* security: New field ``uint64_t opaque_data`` is added into
>>> + ``rte_security_session`` structure. That would allow upper layer to easily
>>> + associate/de-associate some user defined data with the security session.
>>> +
>>> 3) Bumbed version in Makefile and meson.build
>>>
>>> What else needs to be done here?
>> Like I said, "update the lib versions in the release notes".
>> Please check at the bottom of the page, there is a list of libraries.
> Ah, ok.
> Will submit v8 then.
Wait a for Pablo to apply the Fan's patchset. I think he would be
applying soon.
There will be conflict in 2-3 patches. You can rebase it and then send it
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 00/10] ipsec: new library for IPsec data-path processing
2019-01-10 14:54 0% ` Thomas Monjalon
@ 2019-01-10 14:58 0% ` Ananyev, Konstantin
2019-01-10 15:00 0% ` Akhil Goyal
0 siblings, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2019-01-10 14:58 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, akhil.goyal, De Lara Guarch, Pablo
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Thursday, January 10, 2019 2:55 PM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Cc: dev@dpdk.org; akhil.goyal@nxp.com; De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> Subject: Re: [PATCH v7 00/10] ipsec: new library for IPsec data-path processing
>
> 10/01/2019 15:52, Ananyev, Konstantin:
> > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > > 10/01/2019 15:20, Konstantin Ananyev:
> > > > v6 -> v7
> > > > - Changes to address Thomas comments:
> > > > bump ABI version
> > > > remove related deprecation notice
> > > > update release notes, ABI changes section
> > >
> > > You did not update the lib versions in the release notes.
> >
> > For 'security: add opaque userdata pointer into security session':
> > 1) removed deprecation notice
> > 2) add ABI change into release note:
> > +* security: New field ``uint64_t opaque_data`` is added into
> > + ``rte_security_session`` structure. That would allow upper layer to easily
> > + associate/de-associate some user defined data with the security session.
> > +
> > 3) Bumbed version in Makefile and meson.build
> >
> > What else needs to be done here?
>
> Like I said, "update the lib versions in the release notes".
> Please check at the bottom of the page, there is a list of libraries.
Ah, ok.
Will submit v8 then.
>
> > > I think you missed a deprecation notice removal in patch 1.
> > As Pablo noticed that would happen in "cryptodev: update symmetric session",
> > this patch will be just dropped from the series.
>
> OK
>
> > > Have you checked the doxygen warnings in last patch?
> > I think I fixed that in v7, are still seeing them?
>
> OK
> I did not check. It was just a question because it is not in the changelog.
>
>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 00/10] ipsec: new library for IPsec data-path processing
2019-01-10 14:52 3% ` Ananyev, Konstantin
@ 2019-01-10 14:54 0% ` Thomas Monjalon
2019-01-10 14:58 0% ` Ananyev, Konstantin
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-01-10 14:54 UTC (permalink / raw)
To: Ananyev, Konstantin; +Cc: dev, akhil.goyal, De Lara Guarch, Pablo
10/01/2019 15:52, Ananyev, Konstantin:
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > 10/01/2019 15:20, Konstantin Ananyev:
> > > v6 -> v7
> > > - Changes to address Thomas comments:
> > > bump ABI version
> > > remove related deprecation notice
> > > update release notes, ABI changes section
> >
> > You did not update the lib versions in the release notes.
>
> For 'security: add opaque userdata pointer into security session':
> 1) removed deprecation notice
> 2) add ABI change into release note:
> +* security: New field ``uint64_t opaque_data`` is added into
> + ``rte_security_session`` structure. That would allow upper layer to easily
> + associate/de-associate some user defined data with the security session.
> +
> 3) Bumbed version in Makefile and meson.build
>
> What else needs to be done here?
Like I said, "update the lib versions in the release notes".
Please check at the bottom of the page, there is a list of libraries.
> > I think you missed a deprecation notice removal in patch 1.
> As Pablo noticed that would happen in "cryptodev: update symmetric session",
> this patch will be just dropped from the series.
OK
> > Have you checked the doxygen warnings in last patch?
> I think I fixed that in v7, are still seeing them?
OK
I did not check. It was just a question because it is not in the changelog.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 00/10] ipsec: new library for IPsec data-path processing
2019-01-10 14:25 0% ` Thomas Monjalon
2019-01-10 14:40 0% ` De Lara Guarch, Pablo
@ 2019-01-10 14:52 3% ` Ananyev, Konstantin
2019-01-10 14:54 0% ` Thomas Monjalon
1 sibling, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2019-01-10 14:52 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, akhil.goyal, De Lara Guarch, Pablo
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Thursday, January 10, 2019 2:25 PM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Cc: dev@dpdk.org; akhil.goyal@nxp.com; De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> Subject: Re: [PATCH v7 00/10] ipsec: new library for IPsec data-path processing
>
> 10/01/2019 15:20, Konstantin Ananyev:
> > v6 -> v7
> > - Changes to address Thomas comments:
> > bump ABI version
> > remove related deprecation notice
> > update release notes, ABI changes section
>
> You did not update the lib versions in the release notes.
For 'security: add opaque userdata pointer into security session':
1) removed deprecation notice
2) add ABI change into release note:
+* security: New field ``uint64_t opaque_data`` is added into
+ ``rte_security_session`` structure. That would allow upper layer to easily
+ associate/de-associate some user defined data with the security session.
+
3) Bumbed version in Makefile and meson.build
What else needs to be done here?
> I think you missed a deprecation notice removal in patch 1.
As Pablo noticed that would happen in "cryptodev: update symmetric session",
this patch will be just dropped from the series.
> Have you checked the doxygen warnings in last patch?
I think I fixed that in v7, are still seeing them?
Konstantin
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v7 00/10] ipsec: new library for IPsec data-path processing
2019-01-10 14:20 4% ` [dpdk-dev] [PATCH v7 00/10] ipsec: new library for IPsec data-path processing Konstantin Ananyev
2019-01-10 14:25 0% ` Thomas Monjalon
@ 2019-01-10 14:51 0% ` Akhil Goyal
1 sibling, 0 replies; 200+ results
From: Akhil Goyal @ 2019-01-10 14:51 UTC (permalink / raw)
To: Konstantin Ananyev, dev, pablo.de.lara.guarch; +Cc: thomas
On 1/10/2019 7:50 PM, Konstantin Ananyev wrote:
> v6 -> v7
> - Changes to address Thomas comments:
> bump ABI version
> remove related deprecation notice
> update release notes, ABI changes section
>
As Pablo suggested patch 1 can be dropped as Fan's patchset already
takes care of that.
Apart from that
Series Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v5 09/12] cryptodev: update symmetric session structure
2019-01-10 14:50 3% ` [dpdk-dev] [PATCH v5 01/12] cryptodev: change queue pair configure structure Fan Zhang
2019-01-10 14:50 3% ` [dpdk-dev] [PATCH v5 02/12] cryptodev: add sym session mempool create Fan Zhang
@ 2019-01-10 14:50 5% ` Fan Zhang
2 siblings, 0 replies; 200+ results
From: Fan Zhang @ 2019-01-10 14:50 UTC (permalink / raw)
To: dev; +Cc: akhil.goyal, pablo.de.lara.guarch, fiona.trahe
This patch updates the rte_cryptodev_sym_session structure for
cryptodev library. The updates include a changed session private
data array and an added nb_drivers field. They are used to
calculate the correct session header size and ensure safe access
of the session private data.
Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
Acked-by: Fiona Trahe <fiona.trahe@intel.com>
---
doc/guides/prog_guide/img/cryptodev_sym_sess.svg | 701 ++++++++++++-----------
doc/guides/rel_notes/deprecation.rst | 6 -
doc/guides/rel_notes/release_19_02.rst | 7 +-
lib/librte_cryptodev/rte_cryptodev.c | 100 +++-
lib/librte_cryptodev/rte_cryptodev.h | 8 +-
lib/librte_cryptodev/rte_cryptodev_pmd.h | 13 +-
6 files changed, 444 insertions(+), 391 deletions(-)
diff --git a/doc/guides/prog_guide/img/cryptodev_sym_sess.svg b/doc/guides/prog_guide/img/cryptodev_sym_sess.svg
index a807cebac..5c843f736 100644
--- a/doc/guides/prog_guide/img/cryptodev_sym_sess.svg
+++ b/doc/guides/prog_guide/img/cryptodev_sym_sess.svg
@@ -19,33 +19,31 @@
id="svg70"
sodipodi:docname="cryptodev_sym_sess.svg"
style="font-size:12px;overflow:visible;color-interpolation-filters:sRGB;fill:none;fill-rule:evenodd;stroke-linecap:square;stroke-miterlimit:3"
- inkscape:version="0.92.1 r15371"><metadata
- id="metadata74"><rdf:RDF><cc:Work
- rdf:about=""><dc:format>image/svg+xml</dc:format><dc:type
- rdf:resource="http://purl.org/dc/dcmitype/StillImage" /><dc:title /></cc:Work></rdf:RDF></metadata><sodipodi:namedview
- pagecolor="#ffffff"
- bordercolor="#666666"
- borderopacity="1"
- objecttolerance="10"
- gridtolerance="10"
- guidetolerance="10"
- inkscape:pageopacity="0"
- inkscape:pageshadow="2"
- inkscape:window-width="1920"
- inkscape:window-height="1051"
- id="namedview72"
- showgrid="false"
- inkscape:zoom="1.7495789"
- inkscape:cx="208.74719"
- inkscape:cy="216.52777"
- inkscape:window-x="-9"
- inkscape:window-y="-9"
- inkscape:window-maximized="0"
- inkscape:current-layer="g68-0" />
- <style
- type="text/css"
- id="style2">
- <![CDATA[
+ inkscape:version="0.92.2 (5c3e80d, 2017-08-06)"><metadata
+ id="metadata74"><rdf:RDF><cc:Work
+ rdf:about=""><dc:format>image/svg+xml</dc:format><dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" /><dc:title /></cc:Work></rdf:RDF></metadata><sodipodi:namedview
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1"
+ objecttolerance="10"
+ gridtolerance="10"
+ guidetolerance="10"
+ inkscape:pageopacity="0"
+ inkscape:pageshadow="2"
+ inkscape:window-width="1920"
+ inkscape:window-height="956"
+ id="namedview72"
+ showgrid="false"
+ inkscape:zoom="1.7495789"
+ inkscape:cx="208.74719"
+ inkscape:cy="216.52777"
+ inkscape:window-x="0"
+ inkscape:window-y="27"
+ inkscape:window-maximized="1"
+ inkscape:current-layer="shape18-1-4" /><style
+ type="text/css"
+ id="style2"><![CDATA[
.st1 {fill:url(#grad0-4);stroke:#386288;stroke-width:0.75}
.st2 {fill:#386288;font-family:Calibri;font-size:0.833336em}
.st3 {visibility:visible}
@@ -56,337 +54,340 @@
.st8 {font-size:0.799995em}
.st9 {font-size:0.799995em;font-weight:bold}
.st10 {fill:none;fill-rule:evenodd;font-size:12px;overflow:visible;stroke-linecap:square;stroke-miterlimit:3}
- ]]>
- </style>
-
- <defs
- id="Patterns_And_Gradients"><marker
- inkscape:isstock="true"
- style="overflow:visible"
- id="marker5421"
- refX="0"
- refY="0"
- orient="auto"
- inkscape:stockid="Arrow2Lend"><path
- transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
- d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
- style="fill:#41719c;fill-opacity:1;fill-rule:evenodd;stroke:#41719c;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
- id="path5419"
- inkscape:connector-curvature="0" /></marker><marker
- inkscape:stockid="Arrow2Lend"
- orient="auto"
- refY="0"
- refX="0"
- id="Arrow2Lend"
- style="overflow:visible"
- inkscape:isstock="true"><path
- id="path5004"
- style="fill:#41719c;fill-opacity:1;fill-rule:evenodd;stroke:#41719c;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
- d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
- transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
- inkscape:connector-curvature="0" /></marker><marker
- inkscape:stockid="Arrow1Lend"
- orient="auto"
- refY="0"
- refX="0"
- id="Arrow1Lend"
- style="overflow:visible"
- inkscape:isstock="true"><path
- id="path4986"
- d="M 0,0 5,-5 -12.5,0 5,5 Z"
- style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000003pt;stroke-opacity:1"
- transform="matrix(-0.8,0,0,-0.8,-10,0)"
- inkscape:connector-curvature="0" /></marker>
- <linearGradient
- id="grad0-4"
- x1="0"
- y1="0"
- x2="1"
- y2="0"
- gradientTransform="rotate(60,0.5,0.5)">
- <stop
- offset="0"
- stop-color="#e8ebef"
- stop-opacity="1"
- id="stop4" />
- <stop
- offset="0.24"
- stop-color="#f4f5f7"
- stop-opacity="1"
- id="stop6" />
- <stop
- offset="0.54"
- stop-color="#feffff"
- stop-opacity="1"
- id="stop8" />
- </linearGradient>
- <filter
- id="filter_2-4"><feGaussianBlur
- stdDeviation="2"
- id="feGaussianBlur12-0" /></filter><linearGradient
- inkscape:collect="always"
- xlink:href="#grad0-4"
- id="linearGradient189"
- gradientTransform="scale(0.8787489,1.1379815)"
- x1="-0.42674366"
- y1="0.98859203"
- x2="176.71146"
- y2="0.98859203"
- gradientUnits="userSpaceOnUse" /><filter
- id="filter_2-5"><feGaussianBlur
- stdDeviation="2"
- id="feGaussianBlur12-8" /></filter><filter
- id="filter_2-3"><feGaussianBlur
- stdDeviation="2"
- id="feGaussianBlur12-2" /></filter><linearGradient
- inkscape:collect="always"
- xlink:href="#grad0-4"
- id="linearGradient189-7"
- gradientTransform="scale(0.8787489,1.1379815)"
- x1="-0.42674366"
- y1="0.98859203"
- x2="176.71146"
- y2="0.98859203"
- gradientUnits="userSpaceOnUse" /><linearGradient
- inkscape:collect="always"
- xlink:href="#grad0-4"
- id="linearGradient500"
- gradientTransform="matrix(0.8787489,0,0,1.1379815,12.431599,21.739241)"
- x1="-0.42674366"
- y1="0.98859203"
- x2="176.71146"
- y2="0.98859203"
- gradientUnits="userSpaceOnUse" /></defs>
- <defs
- id="Filters">
- <filter
- id="filter_2">
- <feGaussianBlur
- stdDeviation="2"
- id="feGaussianBlur12" />
- </filter>
- </defs>
- <g
- id="g68"
- transform="matrix(1,0,0,0.41409874,-12.807629,-5.4621159)">
- <title
- id="title16">Page-1</title>
- <g
- id="shape18-1"
- transform="translate(0.749889,-0.75)">
- <title
- id="title18">Rounded Rectangle.12</title>
- <desc
- id="desc20">Crypto Symmetric Session</desc>
- <path
- d="M 19.211599,224.06924 H 160.5716 a 6.77735,6.77735 0 0 0 6.77,-6.77 V 30.019241 a 6.77735,6.77735 0 0 0 -6.77,-6.78 H 19.211599 a 6.77735,6.77735 0 0 0 -6.78,6.78 V 217.29924 a 6.77735,6.77735 0 0 0 6.78,6.77 z"
- class="st1"
- id="path22"
- style="fill:url(#linearGradient500);stroke:#386288;stroke-width:0.75"
- inkscape:connector-curvature="0" />
- <text
- x="63.123039"
- y="28.531481"
- class="st2"
- id="text24"
- style="font-size:16.97244835px;font-family:Calibri;fill:#386288;stroke-width:1.69723928"
- transform="scale(0.58919214,1.6972392)">Crypto Symmetric Session</text>
-
- </g>
- <g
- id="shape19-6"
- transform="translate(10.6711,-9.82087)">
- <title
- id="title27">Rounded Rectangle.13</title>
- <desc
- id="desc29">Private Session Data</desc>
- </g>
- <g
- id="shape20-12"
- transform="matrix(1,0,0,2.5278193,23.531375,-309.78186)">
- <title
- id="title39">Rounded Rectangle.15</title>
- <desc
- id="desc41">void *sess_private_data[]</desc>
- <path
- d="m 5.91,202.33 h 123.25 a 5.90925,5.90925 -180 0 0 5.91,-5.9 v -36.37 a 5.90925,5.90925 -180 0 0 -5.91,-5.91 H 5.91 A 5.90925,5.90925 -180 0 0 0,160.06 v 36.37 a 5.90925,5.90925 -180 0 0 5.91,5.9 z"
- class="st7"
- id="path43"
- inkscape:connector-curvature="0"
- style="fill:#ffffff;stroke:#41719c;stroke-width:0.75" />
- <text
- x="14.072042"
- y="159.1931"
- class="st6"
- id="text65"
- style="font-size:11.41061592px;font-family:Calibri;fill:#41719c;stroke-width:1.14105785"
- transform="scale(0.92359087,1.0827305)">void *sess_private_data[] <tspan
- x="-3.5230706"
- class="st9"
- id="tspan47"
- style="font-weight:bold;font-size:9.12843513px;stroke-width:1.14105785" /></text>
-
- <rect
- style="fill:none;fill-opacity:1;stroke:#41719c;stroke-width:0.73305672;stroke-opacity:1"
- id="rect4604"
- width="15.968175"
- height="14.230948"
- x="13.494645"
- y="181.68814" /><rect
- style="font-size:12px;overflow:visible;color-interpolation-filters:sRGB;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#41719c;stroke-width:0.73305672;stroke-linecap:square;stroke-miterlimit:3;stroke-opacity:1"
- id="rect4604-7"
- width="15.968174"
- height="14.230948"
- x="29.46282"
- y="181.68814" /><rect
- style="font-size:12px;overflow:visible;color-interpolation-filters:sRGB;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#41719c;stroke-width:0.73305672;stroke-linecap:square;stroke-miterlimit:3;stroke-opacity:1"
- id="rect4604-7-6"
- width="15.968174"
- height="14.230948"
- x="45.430992"
- y="181.68814" /><rect
- style="font-size:12px;overflow:visible;color-interpolation-filters:sRGB;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#41719c;stroke-width:0.73305672;stroke-linecap:square;stroke-miterlimit:3;stroke-opacity:1"
- id="rect4604-7-6-9"
- width="15.968174"
- height="14.230948"
- x="61.399166"
- y="181.68814" /><rect
- style="font-size:12px;overflow:visible;color-interpolation-filters:sRGB;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#41719c;stroke-width:0.73305672;stroke-linecap:square;stroke-miterlimit:3;stroke-opacity:1"
- id="rect4604-7-6-9-8"
- width="15.968174"
- height="14.230948"
- x="77.36734"
- y="181.68814" /><rect
- style="font-size:12px;overflow:visible;color-interpolation-filters:sRGB;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#41719c;stroke-width:0.73305672;stroke-linecap:square;stroke-miterlimit:3;stroke-opacity:1"
- id="rect4604-7-6-9-8-9"
- width="15.968174"
- height="14.230948"
- x="93.33551"
- y="181.68814" /><rect
- style="font-size:12px;overflow:visible;color-interpolation-filters:sRGB;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#41719c;stroke-width:0.73305672;stroke-linecap:square;stroke-miterlimit:3;stroke-opacity:1"
- id="rect4604-7-6-9-8-9-6"
- width="15.968174"
- height="14.230948"
- x="109.30369"
- y="181.68814" /><path
- style="fill:none;fill-opacity:1;stroke:#41719c;stroke-width:0.72427988px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow2Lend)"
- d="m 117.64885,196.01764 0.22164,18.77485 44.6966,-0.0725 -0.22163,-20.00716 16.84434,0.43494"
- id="path5030"
- inkscape:connector-curvature="0" /></g>
- </g>
-<g
- transform="translate(190.70887,-0.53319281)"
- id="g68-0"><title
- id="title16-2">Page-1</title><g
- id="shape18-1-4"
- transform="matrix(1,0,0,0.57815109,0.749889,-0.11722686)"><title
- id="title18-4">Rounded Rectangle.12</title><desc
- id="desc20-6">Crypto Symmetric Session</desc><path
- inkscape:connector-curvature="0"
- d="m 6.78,202.33 h 141.36 a 6.77735,6.77735 -180 0 0 6.77,-6.77 V 8.28 A 6.77735,6.77735 -180 0 0 148.14,1.5 H 6.78 A 6.77735,6.77735 -180 0 0 0,8.28 v 187.28 a 6.77735,6.77735 -180 0 0 6.78,6.77 z"
- class="st1"
- id="path22-0"
- style="fill:url(#linearGradient189);stroke:#386288;stroke-width:0.75" /><text
- x="26.317923"
- y="17.335487"
- class="st2"
- id="text24-5"
- style="font-size:14.02988338px;font-family:Calibri;fill:#386288;stroke-width:1.40298378"
- transform="scale(0.71276665,1.4029837)">Crypto Driver Private Session</text>
-
-</g><g
- id="shape19-6-5"
- transform="matrix(1.022976,0,0,0.71529071,9.1114734,-39.403506)"><title
- id="title27-2">Rounded Rectangle.13</title><desc
- id="desc29-0">Private Session Data</desc><g
- id="shadow19-7-1"
- transform="translate(0.345598,1.97279)"
- class="st3"
- style="visibility:visible"><path
+ ]]></style><defs
+ id="Patterns_And_Gradients"><marker
+ inkscape:isstock="true"
+ style="overflow:visible"
+ id="marker5421"
+ refX="0"
+ refY="0"
+ orient="auto"
+ inkscape:stockid="Arrow2Lend"><path
+ transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
+ d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+ style="fill:#41719c;fill-opacity:1;fill-rule:evenodd;stroke:#41719c;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+ id="path5419"
+ inkscape:connector-curvature="0" /></marker><marker
+ inkscape:stockid="Arrow2Lend"
+ orient="auto"
+ refY="0"
+ refX="0"
+ id="Arrow2Lend"
+ style="overflow:visible"
+ inkscape:isstock="true"><path
+ id="path5004"
+ style="fill:#41719c;fill-opacity:1;fill-rule:evenodd;stroke:#41719c;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+ d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+ transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
+ inkscape:connector-curvature="0" /></marker><marker
+ inkscape:stockid="Arrow1Lend"
+ orient="auto"
+ refY="0"
+ refX="0"
+ id="Arrow1Lend"
+ style="overflow:visible"
+ inkscape:isstock="true"><path
+ id="path4986"
+ d="M 0,0 5,-5 -12.5,0 5,5 Z"
+ style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000003pt;stroke-opacity:1"
+ transform="matrix(-0.8,0,0,-0.8,-10,0)"
+ inkscape:connector-curvature="0" /></marker><linearGradient
+ id="grad0-4"
+ x1="0"
+ y1="0"
+ x2="1"
+ y2="0"
+ gradientTransform="rotate(60,0.5,0.5)"><stop
+ offset="0"
+ stop-color="#e8ebef"
+ stop-opacity="1"
+ id="stop4" /><stop
+ offset="0.24"
+ stop-color="#f4f5f7"
+ stop-opacity="1"
+ id="stop6" /><stop
+ offset="0.54"
+ stop-color="#feffff"
+ stop-opacity="1"
+ id="stop8" /></linearGradient><filter
+ id="filter_2-4"><feGaussianBlur
+ stdDeviation="2"
+ id="feGaussianBlur12-0" /></filter><linearGradient
+ inkscape:collect="always"
+ xlink:href="#grad0-4"
+ id="linearGradient189"
+ gradientTransform="scale(0.8787489,1.1379815)"
+ x1="-0.42674366"
+ y1="0.98859203"
+ x2="176.71146"
+ y2="0.98859203"
+ gradientUnits="userSpaceOnUse" /><filter
+ id="filter_2-5"><feGaussianBlur
+ stdDeviation="2"
+ id="feGaussianBlur12-8" /></filter><filter
+ id="filter_2-3"><feGaussianBlur
+ stdDeviation="2"
+ id="feGaussianBlur12-2" /></filter><linearGradient
+ inkscape:collect="always"
+ xlink:href="#grad0-4"
+ id="linearGradient189-7"
+ gradientTransform="scale(0.8787489,1.1379815)"
+ x1="-0.42674366"
+ y1="0.98859203"
+ x2="176.71146"
+ y2="0.98859203"
+ gradientUnits="userSpaceOnUse" /><linearGradient
+ inkscape:collect="always"
+ xlink:href="#grad0-4"
+ id="linearGradient500"
+ gradientTransform="matrix(0.87785006,0,0,2.0116303,15.940232,20.619826)"
+ x1="-0.42674366"
+ y1="0.98859203"
+ x2="176.71146"
+ y2="0.98859203"
+ gradientUnits="userSpaceOnUse" /></defs><defs
+ id="Filters"><filter
+ id="filter_2"><feGaussianBlur
+ stdDeviation="2"
+ id="feGaussianBlur12" /></filter></defs><g
+ transform="matrix(1,0,0,0.41409874,-12.05774,-5.77269)"
+ id="shape18-1"><title
+ id="title18">Rounded Rectangle.12</title><desc
+ id="desc20">Crypto Symmetric Session</desc><path
+ inkscape:connector-curvature="0"
+ style="fill:url(#linearGradient500);stroke:#386288;stroke-width:0.99665654"
+ id="path22"
+ class="st1"
+ d="M 22.713297,378.28219 H 163.92871 a 6.7704177,11.980443 0 0 0 6.76307,-11.96745 V 35.256532 A 6.7704177,11.980443 0 0 0 163.92871,23.271405 H 22.713297 A 6.7704177,11.980443 0 0 0 15.940232,35.256532 V 366.31474 a 6.7704177,11.980443 0 0 0 6.773065,11.96745 z" /></g><g
+ transform="matrix(1,0,0,0.41409874,-2.136529,-9.5289258)"
+ id="shape19-6"><title
+ id="title27">Rounded Rectangle.13</title><desc
+ id="desc29">Private Session Data</desc></g><g
+ id="g4079"
+ transform="matrix(0.9997031,0,0,1.070998,206.15511,-5.6465883)"><path
+ style="fill:#ffffff;stroke:#41719c;stroke-width:1.15444767"
+ inkscape:connector-curvature="0"
+ id="path43"
+ class="st7"
+ d="m -189.55935,139.62776 h 123.25 a 5.90925,14.000977 0 0 0 5.91,-13.97905 V 39.476089 a 5.90925,14.000977 0 0 0 -5.91,-14.002757 h -123.25 a 5.90925,14.000977 0 0 0 -5.91,14.002757 v 86.172621 a 5.90925,14.000977 0 0 0 5.91,13.97905 z" /><rect
+ y="118.60072"
+ x="-181.11736"
+ height="14.896484"
+ width="15.968175"
+ id="rect4604"
+ style="fill:none;fill-opacity:1;stroke:#41719c;stroke-width:0.75000221;stroke-opacity:1" /><rect
+ y="118.60072"
+ x="-165.14919"
+ height="14.896484"
+ width="15.968174"
+ id="rect4604-7"
+ style="font-size:12px;overflow:visible;color-interpolation-filters:sRGB;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#41719c;stroke-width:0.75000221;stroke-linecap:square;stroke-miterlimit:3;stroke-opacity:1" /><rect
+ y="118.60072"
+ x="-149.181"
+ height="14.896484"
+ width="15.968174"
+ id="rect4604-7-6"
+ style="font-size:12px;overflow:visible;color-interpolation-filters:sRGB;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#41719c;stroke-width:0.75000221;stroke-linecap:square;stroke-miterlimit:3;stroke-opacity:1" /><rect
+ y="118.60072"
+ x="-133.21283"
+ height="14.896484"
+ width="15.968174"
+ id="rect4604-7-6-9"
+ style="font-size:12px;overflow:visible;color-interpolation-filters:sRGB;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#41719c;stroke-width:0.75000221;stroke-linecap:square;stroke-miterlimit:3;stroke-opacity:1" /><rect
+ y="118.60072"
+ x="-117.24466"
+ height="14.896484"
+ width="15.968174"
+ id="rect4604-7-6-9-8"
+ style="font-size:12px;overflow:visible;color-interpolation-filters:sRGB;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#41719c;stroke-width:0.75000221;stroke-linecap:square;stroke-miterlimit:3;stroke-opacity:1" /><rect
+ y="118.60072"
+ x="-101.27649"
+ height="14.896484"
+ width="15.968174"
+ id="rect4604-7-6-9-8-9"
+ style="font-size:12px;overflow:visible;color-interpolation-filters:sRGB;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#41719c;stroke-width:0.75000221;stroke-linecap:square;stroke-miterlimit:3;stroke-opacity:1" /><rect
+ y="118.60072"
+ x="-85.308311"
+ height="14.896484"
+ width="15.968174"
+ id="rect4604-7-6-9-8-9-6"
+ style="font-size:12px;overflow:visible;color-interpolation-filters:sRGB;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#41719c;stroke-width:0.75000221;stroke-linecap:square;stroke-miterlimit:3;stroke-opacity:1" /><text
+ transform="scale(0.48757738,2.0509565)"
+ style="font-size:21.61449814px;font-family:Calibri;overflow:visible;color-interpolation-filters:sRGB;fill:#41719c;fill-rule:evenodd;stroke-width:2.16144276;stroke-linecap:square;stroke-miterlimit:3"
+ id="text65-3"
+ class="st6"
+ y="50.793892"
+ x="-374.07562" />
+<text
+ xml:space="preserve"
+ style="font-style:normal;font-weight:normal;font-size:28.99296951px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.72482425"
+ x="-172.30693"
+ y="83.585136"
+ id="text4129"
+ transform="scale(1.035044,0.96614251)"><tspan
+ sodipodi:role="line"
+ id="tspan4127"
+ x="-172.30693"
+ y="109.23712"
+ style="stroke-width:0.72482425"></tspan></text>
+<text
+ xml:space="preserve"
+ style="font-style:normal;font-weight:normal;font-size:28.99296951px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.72482425"
+ x="-174.79263"
+ y="75.713715"
+ id="text4139"
+ transform="scale(1.035044,0.96614251)"><tspan
+ sodipodi:role="line"
+ id="tspan4137"
+ x="-174.79263"
+ y="101.3657"
+ style="stroke-width:0.72482425"></tspan></text>
+</g><path
+ style="fill:none;fill-opacity:1;stroke:#41719c;stroke-width:0.86738265px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow2Lend)"
+ d="m 128.80127,137.90141 -0.20704,20.06801 44.6966,-0.10399 0.20705,-93.424256 16.84434,0.62379"
+ id="path5030"
inkscape:connector-curvature="0"
- d="m 5.91,202.33 h 123.25 a 5.90925,5.90925 -180 0 0 5.91,-5.9 v -92.78 a 5.90925,5.90925 -180 0 0 -5.91,-5.91 H 5.91 A 5.90925,5.90925 -180 0 0 0,103.65 v 92.78 a 5.90925,5.90925 -180 0 0 5.91,5.9 z"
- class="st4"
- id="path31-8"
- style="fill:#bdd0e9;fill-opacity:0.25;stroke:#bdd0e9;stroke-opacity:0.25;filter:url(#filter_2)" /></g><path
- inkscape:connector-curvature="0"
- d="m 5.91,202.33 h 123.25 a 5.90925,5.90925 -180 0 0 5.91,-5.9 v -92.78 a 5.90925,5.90925 -180 0 0 -5.91,-5.91 H 5.91 A 5.90925,5.90925 -180 0 0 0,103.65 v 92.78 a 5.90925,5.90925 -180 0 0 5.91,5.9 z"
- class="st5"
- id="path34-8"
- style="fill:#a6b6cd;stroke:#41719c;stroke-width:0.75" /><text
- x="34.639763"
- y="119.96548"
- class="st6"
- id="text36-7"
- style="font-size:13.15105343px;font-family:Calibri;fill:#41719c;stroke-width:1.31510115"
- transform="scale(0.76039781,1.3151011)">Private Session Data</text>
-
+ sodipodi:nodetypes="ccccc" /><g
+ transform="matrix(1,0,0,0.57815109,191.45876,-0.65041967)"
+ id="shape18-1-4"><title
+ id="title18-4">Rounded Rectangle.12</title><desc
+ id="desc20-6">Crypto Symmetric Session</desc><path
+ style="fill:url(#linearGradient189);stroke:#386288;stroke-width:0.75"
+ id="path22-0"
+ class="st1"
+ d="m 6.78,202.33 h 141.36 a 6.77735,6.77735 -180 0 0 6.77,-6.77 V 8.28 A 6.77735,6.77735 -180 0 0 148.14,1.5 H 6.78 A 6.77735,6.77735 -180 0 0 0,8.28 v 187.28 a 6.77735,6.77735 -180 0 0 6.78,6.77 z"
+ inkscape:connector-curvature="0" /><text
+ transform="scale(0.71276665,1.4029837)"
+ style="font-size:14.02988338px;font-family:Calibri;fill:#386288;stroke-width:1.40298378"
+ id="text24-5"
+ class="st2"
+ y="17.335487"
+ x="26.317923">Crypto Driver Private Session</text>
+<text
+ transform="scale(0.71276665,1.4029837)"
+ style="font-size:14.02988338px;font-family:Calibri;overflow:visible;color-interpolation-filters:sRGB;fill:#386288;fill-rule:evenodd;stroke-width:1.40298378;stroke-linecap:square;stroke-miterlimit:3"
+ id="text24-5-3"
+ class="st2"
+ y="19.076277"
+ x="-240.04274">Crypto Symmetric Session</text>
+<text
+ transform="scale(0.71276665,1.4029837)"
+ style="font-size:14.02988338px;font-family:Calibri;overflow:visible;color-interpolation-filters:sRGB;fill:#386288;fill-rule:evenodd;stroke-width:1.40298378;stroke-linecap:square;stroke-miterlimit:3"
+ id="text24-5-5"
+ class="st2"
+ y="46.557648"
+ x="-241.24557">uint16_t nb_drivers;</text>
+<text
+ transform="scale(0.71276665,1.4029837)"
+ style="font-size:14.02988338px;font-family:Calibri;overflow:visible;color-interpolation-filters:sRGB;fill:#386288;fill-rule:evenodd;stroke-width:1.40298378;stroke-linecap:square;stroke-miterlimit:3"
+ id="text24-5-6"
+ class="st2"
+ y="98.349464"
+ x="-240.04272">struct {</text>
+<text
+ transform="scale(0.71276665,1.4029837)"
+ style="font-size:14.02988338px;font-family:Calibri;overflow:visible;color-interpolation-filters:sRGB;fill:#386288;fill-rule:evenodd;stroke-width:1.40298378;stroke-linecap:square;stroke-miterlimit:3"
+ id="text24-5-2"
+ class="st2"
+ y="115.26107"
+ x="-204.55865">void *data;</text>
+<text
+ transform="scale(0.71276665,1.4029837)"
+ style="font-size:14.02988338px;font-family:Calibri;overflow:visible;color-interpolation-filters:sRGB;fill:#386288;fill-rule:evenodd;stroke-width:1.40298378;stroke-linecap:square;stroke-miterlimit:3"
+ id="text24-5-9"
+ class="st2"
+ y="144.3279"
+ x="-240.04274">} session_data[];</text>
</g><g
- id="shape18-1-4-7"
- transform="matrix(1,0,0,0.57815109,0.90591369,163.94402)"><title
- id="title18-4-3">Rounded Rectangle.12</title><desc
- id="desc20-6-5">Crypto Symmetric Session</desc><path
- inkscape:connector-curvature="0"
- d="m 6.78,202.33 h 141.36 a 6.77735,6.77735 -180 0 0 6.77,-6.77 V 8.28 A 6.77735,6.77735 -180 0 0 148.14,1.5 H 6.78 A 6.77735,6.77735 -180 0 0 0,8.28 v 187.28 a 6.77735,6.77735 -180 0 0 6.78,6.77 z"
- class="st1"
- id="path22-0-8"
- style="fill:url(#linearGradient189-7);stroke:#386288;stroke-width:0.75" /><text
- x="26.317923"
- y="17.335487"
- class="st2"
- id="text24-5-1"
- style="font-size:14.02988338px;font-family:Calibri;fill:#386288;stroke-width:1.40298378"
- transform="scale(0.71276665,1.4029837)">Crypto Driver Private Session</text>
-
+ transform="matrix(1.022976,0,0,0.71529071,199.82034,-39.936699)"
+ id="shape19-6-5"><title
+ id="title27-2">Rounded Rectangle.13</title><desc
+ id="desc29-0">Private Session Data</desc><g
+ style="visibility:visible"
+ class="st3"
+ transform="translate(0.345598,1.97279)"
+ id="shadow19-7-1"><path
+ style="fill:#bdd0e9;fill-opacity:0.25;stroke:#bdd0e9;stroke-opacity:0.25;filter:url(#filter_2)"
+ id="path31-8"
+ class="st4"
+ d="m 5.91,202.33 h 123.25 a 5.90925,5.90925 -180 0 0 5.91,-5.9 v -92.78 a 5.90925,5.90925 -180 0 0 -5.91,-5.91 H 5.91 A 5.90925,5.90925 -180 0 0 0,103.65 v 92.78 a 5.90925,5.90925 -180 0 0 5.91,5.9 z"
+ inkscape:connector-curvature="0" /></g><path
+ style="fill:#a6b6cd;stroke:#41719c;stroke-width:0.75"
+ id="path34-8"
+ class="st5"
+ d="m 5.91,202.33 h 123.25 a 5.90925,5.90925 -180 0 0 5.91,-5.9 v -92.78 a 5.90925,5.90925 -180 0 0 -5.91,-5.91 H 5.91 A 5.90925,5.90925 -180 0 0 0,103.65 v 92.78 a 5.90925,5.90925 -180 0 0 5.91,5.9 z"
+ inkscape:connector-curvature="0" /><text
+ transform="scale(0.76039781,1.3151011)"
+ style="font-size:13.15105343px;font-family:Calibri;fill:#41719c;stroke-width:1.31510115"
+ id="text36-7"
+ class="st6"
+ y="119.96548"
+ x="34.639763">Private Session Data</text>
</g><g
- id="shape19-6-5-1"
- transform="matrix(1.022976,0,0,0.71529071,9.2675037,124.65774)"><title
- id="title27-2-4">Rounded Rectangle.13</title><desc
- id="desc29-0-9">Private Session Data</desc><g
- id="shadow19-7-1-8"
- transform="translate(0.345598,1.97279)"
- class="st3"
- style="visibility:visible"><path
- inkscape:connector-curvature="0"
- d="m 5.91,202.33 h 123.25 a 5.90925,5.90925 -180 0 0 5.91,-5.9 v -92.78 a 5.90925,5.90925 -180 0 0 -5.91,-5.91 H 5.91 A 5.90925,5.90925 -180 0 0 0,103.65 v 92.78 a 5.90925,5.90925 -180 0 0 5.91,5.9 z"
- class="st4"
- id="path31-8-4"
- style="fill:#bdd0e9;fill-opacity:0.25;stroke:#bdd0e9;stroke-opacity:0.25;filter:url(#filter_2-3)" /></g><path
- inkscape:connector-curvature="0"
- d="m 5.91,202.33 h 123.25 a 5.90925,5.90925 -180 0 0 5.91,-5.9 v -92.78 a 5.90925,5.90925 -180 0 0 -5.91,-5.91 H 5.91 A 5.90925,5.90925 -180 0 0 0,103.65 v 92.78 a 5.90925,5.90925 -180 0 0 5.91,5.9 z"
- class="st5"
- id="path34-8-3"
- style="fill:#a6b6cd;stroke:#41719c;stroke-width:0.75" /><text
- x="34.639763"
- y="119.96548"
- class="st6"
- id="text36-7-6"
- style="font-size:13.15105343px;font-family:Calibri;fill:#41719c;stroke-width:1.31510115"
- transform="scale(0.76039781,1.3151011)">Private Session Data</text>
-
+ transform="matrix(1,0,0,0.57815109,191.61478,163.41083)"
+ id="shape18-1-4-7"><title
+ id="title18-4-3">Rounded Rectangle.12</title><desc
+ id="desc20-6-5">Crypto Symmetric Session</desc><path
+ style="fill:url(#linearGradient189-7);stroke:#386288;stroke-width:0.75"
+ id="path22-0-8"
+ class="st1"
+ d="m 6.78,202.33 h 141.36 a 6.77735,6.77735 -180 0 0 6.77,-6.77 V 8.28 A 6.77735,6.77735 -180 0 0 148.14,1.5 H 6.78 A 6.77735,6.77735 -180 0 0 0,8.28 v 187.28 a 6.77735,6.77735 -180 0 0 6.78,6.77 z"
+ inkscape:connector-curvature="0" /><text
+ transform="scale(0.71276665,1.4029837)"
+ style="font-size:14.02988338px;font-family:Calibri;fill:#386288;stroke-width:1.40298378"
+ id="text24-5-1"
+ class="st2"
+ y="17.335487"
+ x="26.317923">Crypto Driver Private Session</text>
+</g><g
+ transform="matrix(1.022976,0,0,0.71529071,199.97637,124.12455)"
+ id="shape19-6-5-1"><title
+ id="title27-2-4">Rounded Rectangle.13</title><desc
+ id="desc29-0-9">Private Session Data</desc><g
+ style="visibility:visible"
+ class="st3"
+ transform="translate(0.345598,1.97279)"
+ id="shadow19-7-1-8"><path
+ style="fill:#bdd0e9;fill-opacity:0.25;stroke:#bdd0e9;stroke-opacity:0.25;filter:url(#filter_2-3)"
+ id="path31-8-4"
+ class="st4"
+ d="m 5.91,202.33 h 123.25 a 5.90925,5.90925 -180 0 0 5.91,-5.9 v -92.78 a 5.90925,5.90925 -180 0 0 -5.91,-5.91 H 5.91 A 5.90925,5.90925 -180 0 0 0,103.65 v 92.78 a 5.90925,5.90925 -180 0 0 5.91,5.9 z"
+ inkscape:connector-curvature="0" /></g><path
+ style="fill:#a6b6cd;stroke:#41719c;stroke-width:0.75"
+ id="path34-8-3"
+ class="st5"
+ d="m 5.91,202.33 h 123.25 a 5.90925,5.90925 -180 0 0 5.91,-5.9 v -92.78 a 5.90925,5.90925 -180 0 0 -5.91,-5.91 H 5.91 A 5.90925,5.90925 -180 0 0 0,103.65 v 92.78 a 5.90925,5.90925 -180 0 0 5.91,5.9 z"
+ inkscape:connector-curvature="0" /><text
+ transform="scale(0.76039781,1.3151011)"
+ style="font-size:13.15105343px;font-family:Calibri;fill:#41719c;stroke-width:1.31510115"
+ id="text36-7-6"
+ class="st6"
+ y="119.96548"
+ x="34.639763">Private Session Data</text>
</g><text
- xml:space="preserve"
+ id="text5070"
+ y="145.4136"
+ x="248.24945"
style="font-style:normal;font-weight:normal;font-size:30.00008774px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.75000221"
- x="57.540585"
- y="145.94679"
- id="text5070"><tspan
- sodipodi:role="line"
+ xml:space="preserve"><tspan
+ style="stroke-width:0.75000221"
+ y="171.95665"
+ x="248.24945"
id="tspan5068"
- x="57.540585"
- y="173.31679"
- style="stroke-width:0.75000221"></tspan></text>
+ sodipodi:role="line" /></text>
<text
- xml:space="preserve"
+ id="text5074"
+ y="142.68553"
+ x="251.28064"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:22.00006485px;line-height:1.25;font-family:sans-serif;-inkscape-font-specification:'sans-serif, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.75000221"
- x="60.571766"
- y="143.21872"
- id="text5074"><tspan
- sodipodi:role="line"
+ xml:space="preserve"><tspan
+ style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:22.00006485px;font-family:sans-serif;-inkscape-font-specification:'sans-serif, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;writing-mode:lr-tb;text-anchor:start;stroke-width:0.75000221"
+ y="142.68553"
+ x="251.28064"
id="tspan5072"
- x="60.571766"
- y="143.21872"
- style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:22.00006485px;font-family:sans-serif;-inkscape-font-specification:'sans-serif, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;writing-mode:lr-tb;text-anchor:start;stroke-width:0.75000221">...</tspan></text>
+ sodipodi:role="line">...</tspan></text>
<path
- style="fill:none;stroke:#41719c;stroke-width:0.74499911px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#marker5421)"
- d="M -158.57624,71.371238 -157.38,232.04055 -1.1215065,232.19212"
+ inkscape:connector-curvature="0"
id="path5076"
- inkscape:connector-curvature="0" /></g></svg>
+ d="m 32.13263,137.96494 1.19624,93.60569 156.25849,0.0883"
+ style="fill:none;stroke:#41719c;stroke-width:0.56864393px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#marker5421)" /></svg>
\ No newline at end of file
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index df12835eb..f1ca879cc 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -74,9 +74,3 @@ Deprecation Notices
* security: New field ``uint64_t opaque_data`` is planned to be added into
``rte_security_session`` structure. That would allow upper layer to easily
associate/de-associate some user defined data with the security session.
-
-* cryptodev: several API and ABI changes are planned for rte_cryptodev
- in v19.02:
-
- - The size and layout of ``rte_cryptodev_sym_session`` will change
- to fix existing issues.
diff --git a/doc/guides/rel_notes/release_19_02.rst b/doc/guides/rel_notes/release_19_02.rst
index ace4bcfe7..b488a6d35 100644
--- a/doc/guides/rel_notes/release_19_02.rst
+++ b/doc/guides/rel_notes/release_19_02.rst
@@ -170,7 +170,8 @@ API Changes
* cryptodev: a new function ``rte_cryptodev_sym_session_pool_create()`` is
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.
+ function from now on. Failed to do so will cause
+ ``rte_cryptodev_sym_session_create()`` function call return error.
ABI Changes
@@ -195,6 +196,10 @@ ABI Changes
``rte_cryptodev_qp_conf`` has been added two parameters of 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.
+
Shared Library Versions
-----------------------
diff --git a/lib/librte_cryptodev/rte_cryptodev.c b/lib/librte_cryptodev/rte_cryptodev.c
index 4a105b08d..2a8e07d27 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -978,6 +978,30 @@ rte_cryptodev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
return -EINVAL;
}
+ if (qp_conf->mp_session) {
+ struct rte_cryptodev_sym_session_pool_private_data *pool_priv;
+ uint32_t obj_size = qp_conf->mp_session->elt_size;
+ uint32_t obj_priv_size = qp_conf->mp_session_private->elt_size;
+ struct rte_cryptodev_sym_session s = {0};
+
+ pool_priv = rte_mempool_get_priv(qp_conf->mp_session);
+ if (!pool_priv || qp_conf->mp_session->private_data_size <
+ sizeof(*pool_priv)) {
+ CDEV_LOG_ERR("Invalid mempool\n");
+ return -EINVAL;
+ }
+
+ s.nb_drivers = pool_priv->nb_drivers;
+
+ if ((rte_cryptodev_sym_get_existing_header_session_size(&s) >
+ obj_size) || (s.nb_drivers <= dev->driver_id) ||
+ rte_cryptodev_sym_get_private_session_size(dev_id) >
+ obj_priv_size) {
+ CDEV_LOG_ERR("Invalid mempool\n");
+ return -EINVAL;
+ }
+ }
+
if (dev->data->dev_started) {
CDEV_LOG_ERR(
"device %d must be stopped to allow configuration", dev_id);
@@ -1172,6 +1196,8 @@ rte_cryptodev_sym_session_init(uint8_t dev_id,
struct rte_mempool *mp)
{
struct rte_cryptodev *dev;
+ uint32_t sess_priv_sz = rte_cryptodev_sym_get_private_session_size(
+ dev_id);
uint8_t index;
int ret;
@@ -1180,11 +1206,16 @@ rte_cryptodev_sym_session_init(uint8_t dev_id,
if (sess == NULL || xforms == NULL || dev == NULL)
return -EINVAL;
+ if (mp->elt_size < sess_priv_sz)
+ return -EINVAL;
+
index = dev->driver_id;
+ if (index >= sess->nb_drivers)
+ return -EINVAL;
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->sym_session_configure, -ENOTSUP);
- if (sess->sess_private_data[index] == NULL) {
+ if (sess->sess_data[index].data == NULL) {
ret = dev->dev_ops->sym_session_configure(dev, xforms,
sess, mp);
if (ret < 0) {
@@ -1273,10 +1304,29 @@ rte_cryptodev_sym_session_pool_create(const char *name, uint32_t nb_elts,
return mp;
}
+static unsigned int
+rte_cryptodev_sym_session_data_size(struct rte_cryptodev_sym_session *sess)
+{
+ return (sizeof(sess->sess_data[0]) * sess->nb_drivers);
+}
+
struct rte_cryptodev_sym_session *
rte_cryptodev_sym_session_create(struct rte_mempool *mp)
{
struct rte_cryptodev_sym_session *sess;
+ struct rte_cryptodev_sym_session_pool_private_data *pool_priv;
+
+ if (!mp) {
+ CDEV_LOG_ERR("Invalid mempool\n");
+ return NULL;
+ }
+
+ pool_priv = rte_mempool_get_priv(mp);
+
+ if (!pool_priv || mp->private_data_size < sizeof(*pool_priv)) {
+ CDEV_LOG_ERR("Invalid mempool\n");
+ return NULL;
+ }
/* Allocate a session structure from the session pool */
if (rte_mempool_get(mp, (void **)&sess)) {
@@ -1284,10 +1334,14 @@ rte_cryptodev_sym_session_create(struct rte_mempool *mp)
return NULL;
}
+ sess->nb_drivers = pool_priv->nb_drivers;
+
+
/* Clear device session pointer.
* Include the flag indicating presence of user data
*/
- memset(sess, 0, (sizeof(void *) * nb_drivers) + sizeof(uint8_t));
+ memset(sess->sess_data, 0,
+ rte_cryptodev_sym_session_data_size(sess));
return sess;
}
@@ -1395,16 +1449,20 @@ rte_cryptodev_asym_session_free(struct rte_cryptodev_asym_session *sess)
return 0;
}
-
unsigned int
rte_cryptodev_sym_get_header_session_size(void)
{
/*
- * Header contains pointers to the private data
- * of all registered drivers, and a flag which
- * indicates presence of user data
+ * Header contains pointers to the private data of all registered
+ * drivers and all necessary information to ensure safely clear
+ * or free al session.
*/
- return ((sizeof(void *) * nb_drivers) + sizeof(uint8_t));
+ struct rte_cryptodev_sym_session s = {0};
+
+ s.nb_drivers = nb_drivers;
+
+ return (unsigned int)(sizeof(s) +
+ rte_cryptodev_sym_session_data_size(&s));
}
unsigned int __rte_experimental
@@ -1414,7 +1472,8 @@ rte_cryptodev_sym_get_existing_header_session_size(
if (!sess)
return 0;
else
- return rte_cryptodev_sym_get_header_session_size();
+ return (unsigned int)(sizeof(*sess) +
+ rte_cryptodev_sym_session_data_size(sess));
}
unsigned int __rte_experimental
@@ -1432,7 +1491,6 @@ unsigned int
rte_cryptodev_sym_get_private_session_size(uint8_t dev_id)
{
struct rte_cryptodev *dev;
- unsigned int header_size = sizeof(void *) * nb_drivers;
unsigned int priv_sess_size;
if (!rte_cryptodev_pmd_is_valid_dev(dev_id))
@@ -1445,16 +1503,7 @@ rte_cryptodev_sym_get_private_session_size(uint8_t dev_id)
priv_sess_size = (*dev->dev_ops->sym_session_get_size)(dev);
- /*
- * If size is less than session header size,
- * return the latter, as this guarantees that
- * sessionless operations will work
- */
- if (priv_sess_size < header_size)
- return header_size;
-
return priv_sess_size;
-
}
unsigned int __rte_experimental
@@ -1486,15 +1535,10 @@ rte_cryptodev_sym_session_set_user_data(
void *data,
uint16_t size)
{
- uint16_t off_set = sizeof(void *) * nb_drivers;
- uint8_t *user_data_present = (uint8_t *)sess + off_set;
-
if (sess == NULL)
return -EINVAL;
- *user_data_present = 1;
- off_set += sizeof(uint8_t);
- rte_memcpy((uint8_t *)sess + off_set, data, size);
+ rte_memcpy(sess->sess_data + sess->nb_drivers, data, size);
return 0;
}
@@ -1502,14 +1546,10 @@ void * __rte_experimental
rte_cryptodev_sym_session_get_user_data(
struct rte_cryptodev_sym_session *sess)
{
- uint16_t off_set = sizeof(void *) * nb_drivers;
- uint8_t *user_data_present = (uint8_t *)sess + off_set;
-
- if (sess == NULL || !*user_data_present)
+ if (sess == NULL)
return NULL;
- off_set += sizeof(uint8_t);
- return (uint8_t *)sess + off_set;
+ return (void *)(sess->sess_data + sess->nb_drivers);
}
/** Initialise rte_crypto_op mempool element */
diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
index 39e3bfffb..cc22a1878 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -957,8 +957,12 @@ rte_cryptodev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
* has a fixed algo, key, op-type, digest_len etc.
*/
struct rte_cryptodev_sym_session {
- __extension__ void *sess_private_data[0];
- /**< Private symmetric session material */
+ uint16_t nb_drivers;
+ /**< number of elements in sess_data array */
+ __extension__ struct {
+ void *data;
+ } sess_data[0];
+ /**< Driver specific session material, variable size */
};
/** Cryptodev asymmetric crypto session */
diff --git a/lib/librte_cryptodev/rte_cryptodev_pmd.h b/lib/librte_cryptodev/rte_cryptodev_pmd.h
index f15c9af30..defe05ea0 100644
--- a/lib/librte_cryptodev/rte_cryptodev_pmd.h
+++ b/lib/librte_cryptodev/rte_cryptodev_pmd.h
@@ -475,14 +475,23 @@ RTE_INIT(init_ ##driver_id)\
static inline void *
get_sym_session_private_data(const struct rte_cryptodev_sym_session *sess,
uint8_t driver_id) {
- return sess->sess_private_data[driver_id];
+ if (unlikely(sess->nb_drivers <= driver_id))
+ return NULL;
+
+ return sess->sess_data[driver_id].data;
}
static inline void
set_sym_session_private_data(struct rte_cryptodev_sym_session *sess,
uint8_t driver_id, void *private_data)
{
- sess->sess_private_data[driver_id] = private_data;
+ if (unlikely(sess->nb_drivers <= driver_id)) {
+ CDEV_LOG_ERR("Set private data for driver %u not allowed\n",
+ driver_id);
+ return;
+ }
+
+ sess->sess_data[driver_id].data = private_data;
}
static inline void *
--
2.13.6
^ permalink raw reply [relevance 5%]
* [dpdk-dev] [PATCH v5 02/12] cryptodev: add sym session mempool create
2019-01-10 14:50 3% ` [dpdk-dev] [PATCH v5 01/12] cryptodev: change queue pair configure structure Fan Zhang
@ 2019-01-10 14:50 3% ` Fan Zhang
2019-01-10 14:50 5% ` [dpdk-dev] [PATCH v5 09/12] cryptodev: update symmetric session structure Fan Zhang
2 siblings, 0 replies; 200+ results
From: Fan Zhang @ 2019-01-10 14:50 UTC (permalink / raw)
To: dev; +Cc: akhil.goyal, pablo.de.lara.guarch, fiona.trahe
This patch adds a new API "rte_cryptodev_sym_session_pool_create()" to
cryptodev library. All applications are required to use this API to
create sym session mempool as it adds private data and nb_drivers
information to the mempool private data.
Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
Acked-by: Fiona Trahe <fiona.trahe@intel.com>
---
doc/guides/prog_guide/cryptodev_lib.rst | 69 ++++++++++++++++++--------
doc/guides/rel_notes/release_19_02.rst | 5 ++
lib/librte_cryptodev/rte_cryptodev.c | 50 +++++++++++++++++++
lib/librte_cryptodev/rte_cryptodev.h | 31 ++++++++++++
lib/librte_cryptodev/rte_cryptodev_version.map | 1 +
5 files changed, 134 insertions(+), 22 deletions(-)
diff --git a/doc/guides/prog_guide/cryptodev_lib.rst b/doc/guides/prog_guide/cryptodev_lib.rst
index 0bb6a8841..f68fb72d3 100644
--- a/doc/guides/prog_guide/cryptodev_lib.rst
+++ b/doc/guides/prog_guide/cryptodev_lib.rst
@@ -455,21 +455,23 @@ Crypto workloads.
.. figure:: img/cryptodev_sym_sess.*
-The Crypto device framework provides APIs to allocate and initialize sessions
-for crypto devices, where sessions are mempool objects.
-It is the application's responsibility to create and manage the session mempools.
-This approach allows for different scenarios such as having a single session
-mempool for all crypto devices (where the mempool object size is big
-enough to hold the private session of any crypto device), as well as having
-multiple session mempools of different sizes for better memory usage.
-
-An application can use ``rte_cryptodev_sym_get_private_session_size()`` to
-get the private session size of given crypto device. This function would allow
-an application to calculate the max device session size of all crypto devices
-to create a single session mempool.
-If instead an application creates multiple session mempools, the Crypto device
-framework also provides ``rte_cryptodev_sym_get_header_session_size`` to get
-the size of an uninitialized session.
+The Crypto device framework provides APIs to create session mempool and allocate
+and initialize sessions for crypto devices, where sessions are mempool objects.
+The application has to use ``rte_cryptodev_sym_session_pool_create()`` to
+create the session header mempool that creates a mempool with proper element
+size automatically and stores necessary information for safely accessing the
+session in the mempool's private data field.
+
+To create a mempool for storing session private data, the application has two
+options. The first is to create another mempool with elt size equal to or
+bigger than the maximum session private data size of all crypto devices that
+will share the same session header. The creation of the mempool shall use the
+traditional ``rte_mempool_create()`` with the correct ``elt_size``. The other
+option is to change the ``elt_size`` parameter in
+``rte_cryptodev_sym_session_pool_create()`` to the correct value. The first
+option is more complex to implement but may result in better memory usage as
+a session header normally takes smaller memory footprint as the session private
+data.
Once the session mempools have been created, ``rte_cryptodev_sym_session_create()``
is used to allocate an uninitialized session from the given mempool.
@@ -623,7 +625,8 @@ using one of the crypto PMDs available in DPDK.
#define IV_OFFSET (sizeof(struct rte_crypto_op) + \
sizeof(struct rte_crypto_sym_op))
- struct rte_mempool *mbuf_pool, *crypto_op_pool, *session_pool;
+ struct rte_mempool *mbuf_pool, *crypto_op_pool;
+ struct rte_mempool *session_pool, *session_priv_pool;
unsigned int session_size;
int ret;
@@ -673,28 +676,50 @@ using one of the crypto PMDs available in DPDK.
/* Get private session data size. */
session_size = rte_cryptodev_sym_get_private_session_size(cdev_id);
+ #ifdef USE_TWO_MEMPOOLS
+ /* Create session mempool for the session header. */
+ session_pool = rte_cryptodev_sym_session_pool_create("session_pool",
+ MAX_SESSIONS,
+ 0,
+ POOL_CACHE_SIZE,
+ 0,
+ socket_id);
+
/*
- * Create session mempool, with two objects per session,
- * one for the session header and another one for the
+ * Create session private data mempool for the
* private session data for the crypto device.
*/
- session_pool = rte_mempool_create("session_pool",
- MAX_SESSIONS * 2,
+ session_priv_pool = rte_mempool_create("session_pool",
+ MAX_SESSIONS,
session_size,
POOL_CACHE_SIZE,
0, NULL, NULL, NULL,
NULL, socket_id,
0);
+ #else
+ /* Use of the same mempool for session header and private data */
+ session_pool = rte_cryptodev_sym_session_pool_create("session_pool",
+ MAX_SESSIONS * 2,
+ session_size,
+ POOL_CACHE_SIZE,
+ 0,
+ socket_id);
+
+ session_priv_pool = session_pool;
+
+ #endif
+
/* Configure the crypto device. */
struct rte_cryptodev_config conf = {
.nb_queue_pairs = 1,
.socket_id = socket_id
};
+
struct rte_cryptodev_qp_conf qp_conf = {
.nb_descriptors = 2048,
.mp_session = session_pool,
- .mp_session_private = session_pool
+ .mp_session_private = session_priv_pool
};
if (rte_cryptodev_configure(cdev_id, &conf) < 0)
@@ -732,7 +757,7 @@ using one of the crypto PMDs available in DPDK.
rte_exit(EXIT_FAILURE, "Session could not be created\n");
if (rte_cryptodev_sym_session_init(cdev_id, session,
- &cipher_xform, session_pool) < 0)
+ &cipher_xform, session_priv_pool) < 0)
rte_exit(EXIT_FAILURE, "Session could not be initialized "
"for the crypto device\n");
diff --git a/doc/guides/rel_notes/release_19_02.rst b/doc/guides/rel_notes/release_19_02.rst
index 527705926..ace4bcfe7 100644
--- a/doc/guides/rel_notes/release_19_02.rst
+++ b/doc/guides/rel_notes/release_19_02.rst
@@ -167,6 +167,11 @@ 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
+ 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.
+
ABI Changes
-----------
diff --git a/lib/librte_cryptodev/rte_cryptodev.c b/lib/librte_cryptodev/rte_cryptodev.c
index 4929d0451..ccc4c2132 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -189,6 +189,16 @@ const char *rte_crypto_asym_op_strings[] = {
[RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE] = "sharedsecret_compute",
};
+/**
+ * The private data structure stored in the session mempool private data.
+ */
+struct rte_cryptodev_sym_session_pool_private_data {
+ uint16_t nb_drivers;
+ /**< number of elements in sess_data array */
+ uint16_t user_data_sz;
+ /**< session user data will be placed after sess_data */
+};
+
int
rte_cryptodev_get_cipher_algo_enum(enum rte_crypto_cipher_algorithm *algo_enum,
const char *algo_string)
@@ -1223,6 +1233,46 @@ rte_cryptodev_asym_session_init(uint8_t dev_id,
return 0;
}
+struct rte_mempool * __rte_experimental
+rte_cryptodev_sym_session_pool_create(const char *name, uint32_t nb_elts,
+ uint32_t elt_size, uint32_t cache_size, uint16_t user_data_size,
+ int socket_id)
+{
+ struct rte_mempool *mp;
+ struct rte_cryptodev_sym_session_pool_private_data *pool_priv;
+ uint32_t obj_sz;
+
+ obj_sz = rte_cryptodev_sym_get_header_session_size() + user_data_size;
+ if (obj_sz > elt_size)
+ CDEV_LOG_INFO("elt_size %u is expanded to %u\n", elt_size,
+ obj_sz);
+ else
+ obj_sz = elt_size;
+
+ mp = rte_mempool_create(name, nb_elts, obj_sz, cache_size,
+ (uint32_t)(sizeof(*pool_priv)),
+ NULL, NULL, NULL, NULL,
+ socket_id, 0);
+ if (mp == NULL) {
+ CDEV_LOG_ERR("%s(name=%s) failed, rte_errno=%d\n",
+ __func__, name, rte_errno);
+ return NULL;
+ }
+
+ pool_priv = rte_mempool_get_priv(mp);
+ if (!pool_priv) {
+ CDEV_LOG_ERR("%s(name=%s) failed to get private data\n",
+ __func__, name);
+ rte_mempool_free(mp);
+ return NULL;
+ }
+
+ pool_priv->nb_drivers = nb_drivers;
+ pool_priv->user_data_sz = user_data_size;
+
+ return mp;
+}
+
struct rte_cryptodev_sym_session *
rte_cryptodev_sym_session_create(struct rte_mempool *mp)
{
diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
index f9e7507da..052213e1f 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -968,6 +968,37 @@ struct rte_cryptodev_asym_session {
};
/**
+ * Create a symmetric session mempool.
+ *
+ * @param name
+ * The unique mempool name.
+ * @param nb_elts
+ * The number of elements in the mempool.
+ * @param elt_size
+ * The size of the element. This value will be ignored if it is smaller than
+ * the minimum session header size required for the system. For the user who
+ * want to use the same mempool for sym session and session private data it
+ * can be the maximum value of all existing devices' private data and session
+ * header sizes.
+ * @param cache_size
+ * The number of per-lcore cache elements
+ * @param priv_size
+ * The private data size of each session.
+ * @param socket_id
+ * The *socket_id* argument is the socket identifier in the case of
+ * NUMA. The value can be *SOCKET_ID_ANY* if there is no NUMA
+ * constraint for the reserved zone.
+ *
+ * @return
+ * - On success return size of the session
+ * - On failure returns 0
+ */
+struct rte_mempool * __rte_experimental
+rte_cryptodev_sym_session_pool_create(const char *name, uint32_t nb_elts,
+ uint32_t elt_size, uint32_t cache_size, uint16_t priv_size,
+ int socket_id);
+
+/**
* Create symmetric crypto session header (generic with no private data)
*
* @param mempool Symmetric session mempool to allocate session
diff --git a/lib/librte_cryptodev/rte_cryptodev_version.map b/lib/librte_cryptodev/rte_cryptodev_version.map
index a695b61dc..5609da04b 100644
--- a/lib/librte_cryptodev/rte_cryptodev_version.map
+++ b/lib/librte_cryptodev/rte_cryptodev_version.map
@@ -102,6 +102,7 @@ EXPERIMENTAL {
rte_cryptodev_asym_xform_capability_check_modlen;
rte_cryptodev_asym_xform_capability_check_optype;
rte_cryptodev_sym_session_get_user_data;
+ rte_cryptodev_sym_session_pool_create;
rte_cryptodev_sym_session_set_user_data;
rte_crypto_asym_op_strings;
rte_crypto_asym_xform_strings;
--
2.13.6
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v5 01/12] cryptodev: change queue pair configure structure
@ 2019-01-10 14:50 3% ` Fan Zhang
2019-01-10 14:50 3% ` [dpdk-dev] [PATCH v5 02/12] cryptodev: add sym session mempool create Fan Zhang
2019-01-10 14:50 5% ` [dpdk-dev] [PATCH v5 09/12] cryptodev: update symmetric session structure Fan Zhang
2 siblings, 0 replies; 200+ results
From: Fan Zhang @ 2019-01-10 14:50 UTC (permalink / raw)
To: dev; +Cc: akhil.goyal, pablo.de.lara.guarch, fiona.trahe
This patch changes the cryptodev queue pair configure structure
to enable two mempool passed into cryptodev PMD simutaneously.
Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
Acked-by: Fiona Trahe <fiona.trahe@@intel.com>
---
app/test-crypto-perf/main.c | 6 ++--
doc/guides/prog_guide/cryptodev_lib.rst | 19 ++++++++---
doc/guides/rel_notes/deprecation.rst | 3 --
doc/guides/rel_notes/release_19_02.rst | 9 +++++-
drivers/crypto/aesni_gcm/aesni_gcm_pmd.c | 7 ++--
drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c | 5 +--
drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h | 2 ++
drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 7 ++--
drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c | 5 +--
drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h | 2 ++
drivers/crypto/armv8/rte_armv8_pmd.c | 7 ++--
drivers/crypto/armv8/rte_armv8_pmd_ops.c | 5 +--
drivers/crypto/armv8/rte_armv8_pmd_private.h | 2 ++
drivers/crypto/caam_jr/caam_jr.c | 3 +-
drivers/crypto/ccp/ccp_pmd_ops.c | 5 +--
drivers/crypto/ccp/ccp_pmd_private.h | 2 ++
drivers/crypto/ccp/rte_ccp_pmd.c | 9 +++++-
drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c | 3 +-
drivers/crypto/dpaa_sec/dpaa_sec.c | 3 +-
drivers/crypto/kasumi/rte_kasumi_pmd.c | 7 ++--
drivers/crypto/kasumi/rte_kasumi_pmd_ops.c | 5 +--
drivers/crypto/kasumi/rte_kasumi_pmd_private.h | 2 ++
drivers/crypto/mvsam/rte_mrvl_pmd_ops.c | 5 +--
drivers/crypto/mvsam/rte_mrvl_pmd_private.h | 3 ++
drivers/crypto/null/null_crypto_pmd.c | 5 +--
drivers/crypto/null/null_crypto_pmd_ops.c | 5 +--
drivers/crypto/null/null_crypto_pmd_private.h | 2 ++
drivers/crypto/octeontx/otx_cryptodev_ops.c | 3 +-
drivers/crypto/openssl/rte_openssl_pmd.c | 7 ++--
drivers/crypto/openssl/rte_openssl_pmd_ops.c | 5 +--
drivers/crypto/openssl/rte_openssl_pmd_private.h | 2 ++
drivers/crypto/qat/qat_sym_pmd.c | 2 +-
drivers/crypto/scheduler/scheduler_pmd_ops.c | 5 ++-
drivers/crypto/snow3g/rte_snow3g_pmd.c | 7 ++--
drivers/crypto/snow3g/rte_snow3g_pmd_ops.c | 5 +--
drivers/crypto/snow3g/rte_snow3g_pmd_private.h | 2 ++
drivers/crypto/virtio/virtio_cryptodev.c | 6 ++--
drivers/crypto/zuc/rte_zuc_pmd.c | 7 ++--
drivers/crypto/zuc/rte_zuc_pmd_ops.c | 5 +--
drivers/crypto/zuc/rte_zuc_pmd_private.h | 2 ++
drivers/net/softnic/rte_eth_softnic_cryptodev.c | 2 +-
examples/fips_validation/main.c | 4 +--
examples/ip_pipeline/cryptodev.c | 2 +-
examples/ipsec-secgw/ipsec-secgw.c | 7 ++--
examples/l2fwd-crypto/main.c | 4 ++-
examples/vhost_crypto/main.c | 9 ++++--
lib/librte_cryptodev/Makefile | 4 +--
lib/librte_cryptodev/meson.build | 4 +--
lib/librte_cryptodev/rte_cryptodev.c | 16 ++++++++--
lib/librte_cryptodev/rte_cryptodev.h | 7 ++--
lib/librte_cryptodev/rte_cryptodev_pmd.h | 3 +-
test/test/test_cryptodev.c | 37 +++++++++-------------
test/test/test_cryptodev_asym.c | 8 ++---
test/test/test_event_crypto_adapter.c | 5 +--
54 files changed, 189 insertions(+), 119 deletions(-)
diff --git a/app/test-crypto-perf/main.c b/app/test-crypto-perf/main.c
index 953e058c9..38a2e429f 100644
--- a/app/test-crypto-perf/main.c
+++ b/app/test-crypto-perf/main.c
@@ -218,6 +218,9 @@ cperf_initialize_cryptodev(struct cperf_options *opts, uint8_t *enabled_cdevs,
session_pool_socket[socket_id] = sess_mp;
}
+ qp_conf.mp_session = session_pool_socket[socket_id];
+ qp_conf.mp_session_private = session_pool_socket[socket_id];
+
ret = rte_cryptodev_configure(cdev_id, &conf);
if (ret < 0) {
printf("Failed to configure cryptodev %u", cdev_id);
@@ -226,8 +229,7 @@ cperf_initialize_cryptodev(struct cperf_options *opts, uint8_t *enabled_cdevs,
for (j = 0; j < opts->nb_qps; j++) {
ret = rte_cryptodev_queue_pair_setup(cdev_id, j,
- &qp_conf, socket_id,
- session_pool_socket[socket_id]);
+ &qp_conf, socket_id);
if (ret < 0) {
printf("Failed to setup queue pair %u on "
"cryptodev %u", j, cdev_id);
diff --git a/doc/guides/prog_guide/cryptodev_lib.rst b/doc/guides/prog_guide/cryptodev_lib.rst
index 8ee33c875..0bb6a8841 100644
--- a/doc/guides/prog_guide/cryptodev_lib.rst
+++ b/doc/guides/prog_guide/cryptodev_lib.rst
@@ -121,11 +121,21 @@ Each queue pairs resources may be allocated on a specified socket.
const struct rte_cryptodev_qp_conf *qp_conf,
int socket_id)
- struct rte_cryptodev_qp_conf {
+ struct rte_cryptodev_qp_conf {
uint32_t nb_descriptors; /**< Number of descriptors per queue pair */
+ struct rte_mempool *mp_session;
+ /**< The mempool for creating session in sessionless mode */
+ struct rte_mempool *mp_session_private;
+ /**< The mempool for creating sess private data in sessionless mode */
};
+The fields ``mp_session`` and ``mp_session_private`` are used for creating
+temporary session to process the crypto operations in the session-less mode.
+They can be the same other different mempools. Please note not all Cryptodev
+PMDs supports session-less mode.
+
+
Logical Cores, Memory and Queues Pair Relationships
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -682,14 +692,15 @@ using one of the crypto PMDs available in DPDK.
.socket_id = socket_id
};
struct rte_cryptodev_qp_conf qp_conf = {
- .nb_descriptors = 2048
+ .nb_descriptors = 2048,
+ .mp_session = session_pool,
+ .mp_session_private = session_pool
};
if (rte_cryptodev_configure(cdev_id, &conf) < 0)
rte_exit(EXIT_FAILURE, "Failed to configure cryptodev %u", cdev_id);
- if (rte_cryptodev_queue_pair_setup(cdev_id, 0, &qp_conf,
- socket_id, session_pool) < 0)
+ if (rte_cryptodev_queue_pair_setup(cdev_id, 0, &qp_conf, socket_id) < 0)
rte_exit(EXIT_FAILURE, "Failed to setup queue pair\n");
if (rte_cryptodev_start(cdev_id) < 0)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index d4aea4b46..df12835eb 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -80,6 +80,3 @@ Deprecation Notices
- The size and layout of ``rte_cryptodev_sym_session`` will change
to fix existing issues.
- - 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.
diff --git a/doc/guides/rel_notes/release_19_02.rst b/doc/guides/rel_notes/release_19_02.rst
index e3b2055d0..527705926 100644
--- a/doc/guides/rel_notes/release_19_02.rst
+++ b/doc/guides/rel_notes/release_19_02.rst
@@ -164,6 +164,9 @@ API Changes
``rte_pdump_init()`` and enum ``rte_pdump_socktype`` were deprecated
since 18.05 and are removed in this release.
+* cryptodev: The parameter ``session_pool`` in the function
+ ``rte_cryptodev_queue_pair_setup()`` is removed.
+
ABI Changes
-----------
@@ -183,6 +186,10 @@ ABI Changes
* mbuf: The format of the sched field of ``rte_mbuf`` has been changed
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
+ mempool and symmetric session private data mempool.
+
Shared Library Versions
-----------------------
@@ -214,7 +221,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_cfgfile.so.2
librte_cmdline.so.2
librte_compressdev.so.1
- librte_cryptodev.so.5
+ + librte_cryptodev.so.6
librte_distributor.so.1
librte_eal.so.9
librte_efd.so.1
diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
index ebdf7c35a..abc7a6d5f 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
@@ -151,7 +151,8 @@ aesni_gcm_get_session(struct aesni_gcm_qp *qp, struct rte_crypto_op *op)
if (rte_mempool_get(qp->sess_mp, (void **)&_sess))
return NULL;
- if (rte_mempool_get(qp->sess_mp, (void **)&_sess_private_data))
+ if (rte_mempool_get(qp->sess_mp_priv,
+ (void **)&_sess_private_data))
return NULL;
sess = (struct aesni_gcm_session *)_sess_private_data;
@@ -159,7 +160,7 @@ aesni_gcm_get_session(struct aesni_gcm_qp *qp, struct rte_crypto_op *op)
if (unlikely(aesni_gcm_set_session_parameters(qp->ops,
sess, sym_op->xform) != 0)) {
rte_mempool_put(qp->sess_mp, _sess);
- rte_mempool_put(qp->sess_mp, _sess_private_data);
+ rte_mempool_put(qp->sess_mp_priv, _sess_private_data);
sess = NULL;
}
sym_op->session = (struct rte_cryptodev_sym_session *)_sess;
@@ -419,7 +420,7 @@ handle_completed_gcm_crypto_op(struct aesni_gcm_qp *qp,
memset(sess, 0, sizeof(struct aesni_gcm_session));
memset(op->sym->session, 0,
rte_cryptodev_sym_get_header_session_size());
- rte_mempool_put(qp->sess_mp, sess);
+ rte_mempool_put(qp->sess_mp_priv, sess);
rte_mempool_put(qp->sess_mp, op->sym->session);
op->sym->session = NULL;
}
diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c b/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
index cd15245bd..bf69dde54 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
@@ -206,7 +206,7 @@ aesni_gcm_pmd_qp_create_processed_pkts_ring(struct aesni_gcm_qp *qp,
static int
aesni_gcm_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool)
+ int socket_id)
{
struct aesni_gcm_qp *qp = NULL;
struct aesni_gcm_private *internals = dev->data->dev_private;
@@ -234,7 +234,8 @@ aesni_gcm_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
if (qp->processed_pkts == NULL)
goto qp_setup_cleanup;
- qp->sess_mp = session_pool;
+ qp->sess_mp = qp_conf->mp_session;
+ qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->qp_stats, 0, sizeof(qp->qp_stats));
diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h b/drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h
index 92b041354..903e7503d 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h
@@ -48,6 +48,8 @@ struct aesni_gcm_qp {
/**< Queue pair statistics */
struct rte_mempool *sess_mp;
/**< Session Mempool */
+ struct rte_mempool *sess_mp_priv;
+ /**< Session Private Data Mempool */
uint16_t id;
/**< Queue Pair Identifier */
char name[RTE_CRYPTODEV_NAME_MAX_LEN];
diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
index 83250e32c..b0f5c4d67 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
@@ -668,7 +668,8 @@ get_session(struct aesni_mb_qp *qp, struct rte_crypto_op *op)
if (rte_mempool_get(qp->sess_mp, (void **)&_sess))
return NULL;
- if (rte_mempool_get(qp->sess_mp, (void **)&_sess_private_data))
+ if (rte_mempool_get(qp->sess_mp_priv,
+ (void **)&_sess_private_data))
return NULL;
sess = (struct aesni_mb_session *)_sess_private_data;
@@ -676,7 +677,7 @@ get_session(struct aesni_mb_qp *qp, struct rte_crypto_op *op)
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, _sess_private_data);
+ rte_mempool_put(qp->sess_mp_priv, _sess_private_data);
sess = NULL;
}
op->sym->session = (struct rte_cryptodev_sym_session *)_sess;
@@ -951,7 +952,7 @@ post_process_mb_job(struct aesni_mb_qp *qp, JOB_AES_HMAC *job)
memset(sess, 0, sizeof(struct aesni_mb_session));
memset(op->sym->session, 0,
rte_cryptodev_sym_get_header_session_size());
- rte_mempool_put(qp->sess_mp, sess);
+ rte_mempool_put(qp->sess_mp_priv, sess);
rte_mempool_put(qp->sess_mp, op->sym->session);
op->sym->session = NULL;
}
diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c
index f3eff2685..af3021616 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c
@@ -566,7 +566,7 @@ aesni_mb_pmd_qp_create_processed_ops_ring(struct aesni_mb_qp *qp,
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 rte_mempool *session_pool)
+ int socket_id)
{
struct aesni_mb_qp *qp = NULL;
struct aesni_mb_private *internals = dev->data->dev_private;
@@ -604,7 +604,8 @@ aesni_mb_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
goto qp_setup_cleanup;
}
- qp->sess_mp = session_pool;
+ qp->sess_mp = qp_conf->mp_session;
+ qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->stats, 0, sizeof(qp->stats));
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 d8021cdaa..923403336 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h
@@ -131,6 +131,8 @@ struct aesni_mb_qp {
/**< Ring for placing operations ready for processing */
struct rte_mempool *sess_mp;
/**< Session Mempool */
+ struct rte_mempool *sess_mp_priv;
+ /**< Session Private Data Mempool */
struct rte_cryptodev_stats stats;
/**< Queue pair statistics */
uint8_t digest_idx;
diff --git a/drivers/crypto/armv8/rte_armv8_pmd.c b/drivers/crypto/armv8/rte_armv8_pmd.c
index 9d15fee53..3b2d7fb2f 100644
--- a/drivers/crypto/armv8/rte_armv8_pmd.c
+++ b/drivers/crypto/armv8/rte_armv8_pmd.c
@@ -514,7 +514,8 @@ get_session(struct armv8_crypto_qp *qp, struct rte_crypto_op *op)
if (rte_mempool_get(qp->sess_mp, (void **)&_sess))
return NULL;
- if (rte_mempool_get(qp->sess_mp, (void **)&_sess_private_data))
+ if (rte_mempool_get(qp->sess_mp_priv,
+ (void **)&_sess_private_data))
return NULL;
sess = (struct armv8_crypto_session *)_sess_private_data;
@@ -522,7 +523,7 @@ get_session(struct armv8_crypto_qp *qp, struct rte_crypto_op *op)
if (unlikely(armv8_crypto_set_session_parameters(sess,
op->sym->xform) != 0)) {
rte_mempool_put(qp->sess_mp, _sess);
- rte_mempool_put(qp->sess_mp, _sess_private_data);
+ rte_mempool_put(qp->sess_mp_priv, _sess_private_data);
sess = NULL;
}
op->sym->session = (struct rte_cryptodev_sym_session *)_sess;
@@ -656,7 +657,7 @@ process_op(struct armv8_crypto_qp *qp, struct rte_crypto_op *op,
memset(op->sym->session, 0,
rte_cryptodev_sym_get_header_session_size());
rte_mempool_put(qp->sess_mp, sess);
- rte_mempool_put(qp->sess_mp, op->sym->session);
+ rte_mempool_put(qp->sess_mp_priv, op->sym->session);
op->sym->session = NULL;
}
diff --git a/drivers/crypto/armv8/rte_armv8_pmd_ops.c b/drivers/crypto/armv8/rte_armv8_pmd_ops.c
index ae03117ea..a4fee83a8 100644
--- a/drivers/crypto/armv8/rte_armv8_pmd_ops.c
+++ b/drivers/crypto/armv8/rte_armv8_pmd_ops.c
@@ -220,7 +220,7 @@ armv8_crypto_pmd_qp_create_processed_ops_ring(struct armv8_crypto_qp *qp,
static int
armv8_crypto_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool)
+ int socket_id)
{
struct armv8_crypto_qp *qp = NULL;
@@ -245,7 +245,8 @@ armv8_crypto_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
if (qp->processed_ops == NULL)
goto qp_setup_cleanup;
- qp->sess_mp = session_pool;
+ qp->sess_mp = qp_conf->mp_session;
+ qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->stats, 0, sizeof(qp->stats));
diff --git a/drivers/crypto/armv8/rte_armv8_pmd_private.h b/drivers/crypto/armv8/rte_armv8_pmd_private.h
index 7feb021db..0afd9c7c5 100644
--- a/drivers/crypto/armv8/rte_armv8_pmd_private.h
+++ b/drivers/crypto/armv8/rte_armv8_pmd_private.h
@@ -116,6 +116,8 @@ struct armv8_crypto_qp {
/**< Ring for placing process packets */
struct rte_mempool *sess_mp;
/**< Session Mempool */
+ struct rte_mempool *sess_mp_priv;
+ /**< Session Private Data Mempool */
struct rte_cryptodev_stats stats;
/**< Queue pair statistics */
char name[RTE_CRYPTODEV_NAME_MAX_LEN];
diff --git a/drivers/crypto/caam_jr/caam_jr.c b/drivers/crypto/caam_jr/caam_jr.c
index f505adf6b..45b281331 100644
--- a/drivers/crypto/caam_jr/caam_jr.c
+++ b/drivers/crypto/caam_jr/caam_jr.c
@@ -1540,8 +1540,7 @@ static int
caam_jr_queue_pair_setup(
struct rte_cryptodev *dev, uint16_t qp_id,
__rte_unused const struct rte_cryptodev_qp_conf *qp_conf,
- __rte_unused int socket_id,
- __rte_unused struct rte_mempool *session_pool)
+ __rte_unused int socket_id)
{
struct sec_job_ring_t *internals;
struct caam_jr_qp *qp = NULL;
diff --git a/drivers/crypto/ccp/ccp_pmd_ops.c b/drivers/crypto/ccp/ccp_pmd_ops.c
index 6984913f1..d5041f0ec 100644
--- a/drivers/crypto/ccp/ccp_pmd_ops.c
+++ b/drivers/crypto/ccp/ccp_pmd_ops.c
@@ -685,7 +685,7 @@ ccp_pmd_qp_create_batch_info_ring(struct ccp_qp *qp,
static int
ccp_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool)
+ int socket_id)
{
struct ccp_private *internals = dev->data->dev_private;
struct ccp_qp *qp;
@@ -726,7 +726,8 @@ ccp_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
goto qp_setup_cleanup;
}
- qp->sess_mp = session_pool;
+ qp->sess_mp = qp_conf->mp_session;
+ qp->sess_mp_priv = qp_conf->mp_session_private;
/* mempool for batch info */
qp->batch_mp = rte_mempool_create(
diff --git a/drivers/crypto/ccp/ccp_pmd_private.h b/drivers/crypto/ccp/ccp_pmd_private.h
index 79752f687..7f2979e89 100644
--- a/drivers/crypto/ccp/ccp_pmd_private.h
+++ b/drivers/crypto/ccp/ccp_pmd_private.h
@@ -76,6 +76,8 @@ struct ccp_qp {
/**< Ring for placing process packets */
struct rte_mempool *sess_mp;
/**< Session Mempool */
+ struct rte_mempool *sess_mp_priv;
+ /**< Session Private Data Mempool */
struct rte_mempool *batch_mp;
/**< Session Mempool for batch info */
struct rte_cryptodev_stats qp_stats;
diff --git a/drivers/crypto/ccp/rte_ccp_pmd.c b/drivers/crypto/ccp/rte_ccp_pmd.c
index 92d8a9559..b4bb5528f 100644
--- a/drivers/crypto/ccp/rte_ccp_pmd.c
+++ b/drivers/crypto/ccp/rte_ccp_pmd.c
@@ -179,7 +179,7 @@ get_ccp_session(struct ccp_qp *qp, struct rte_crypto_op *op)
if (unlikely(ccp_set_session_parameters(sess, op->sym->xform,
internals) != 0)) {
rte_mempool_put(qp->sess_mp, _sess);
- rte_mempool_put(qp->sess_mp, _sess_private_data);
+ rte_mempool_put(qp->sess_mp_priv, _sess_private_data);
sess = NULL;
}
op->sym->session = (struct rte_cryptodev_sym_session *)_sess;
@@ -241,6 +241,13 @@ ccp_pmd_dequeue_burst(void *queue_pair, struct rte_crypto_op **ops,
for (i = 0; i < nb_dequeued; i++)
if (unlikely(ops[i]->sess_type ==
RTE_CRYPTO_OP_SESSIONLESS)) {
+ struct ccp_session *sess = (struct ccp_session *)
+ get_sym_session_private_data(
+ ops[i]->sym->session,
+ ccp_cryptodev_driver_id);
+
+ rte_mempool_put(qp->sess_mp_priv,
+ sess);
rte_mempool_put(qp->sess_mp,
ops[i]->sym->session);
ops[i]->sym->session = NULL;
diff --git a/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c b/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
index 6095c6021..82220ac4f 100644
--- a/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
+++ b/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
@@ -1518,8 +1518,7 @@ dpaa2_sec_queue_pair_release(struct rte_cryptodev *dev, uint16_t queue_pair_id)
static int
dpaa2_sec_queue_pair_setup(struct rte_cryptodev *dev, uint16_t qp_id,
__rte_unused const struct rte_cryptodev_qp_conf *qp_conf,
- __rte_unused int socket_id,
- __rte_unused struct rte_mempool *session_pool)
+ __rte_unused int socket_id)
{
struct dpaa2_sec_dev_private *priv = dev->data->dev_private;
struct dpaa2_sec_qp *qp;
diff --git a/drivers/crypto/dpaa_sec/dpaa_sec.c b/drivers/crypto/dpaa_sec/dpaa_sec.c
index d83e74541..c95e43b7f 100644
--- a/drivers/crypto/dpaa_sec/dpaa_sec.c
+++ b/drivers/crypto/dpaa_sec/dpaa_sec.c
@@ -1661,8 +1661,7 @@ dpaa_sec_queue_pair_release(struct rte_cryptodev *dev,
static int
dpaa_sec_queue_pair_setup(struct rte_cryptodev *dev, uint16_t qp_id,
__rte_unused const struct rte_cryptodev_qp_conf *qp_conf,
- __rte_unused int socket_id,
- __rte_unused struct rte_mempool *session_pool)
+ __rte_unused int socket_id)
{
struct dpaa_sec_dev_private *internals;
struct dpaa_sec_qp *qp = NULL;
diff --git a/drivers/crypto/kasumi/rte_kasumi_pmd.c b/drivers/crypto/kasumi/rte_kasumi_pmd.c
index 239a1cf44..6df645a23 100644
--- a/drivers/crypto/kasumi/rte_kasumi_pmd.c
+++ b/drivers/crypto/kasumi/rte_kasumi_pmd.c
@@ -145,7 +145,8 @@ kasumi_get_session(struct kasumi_qp *qp, struct rte_crypto_op *op)
if (rte_mempool_get(qp->sess_mp, (void **)&_sess))
return NULL;
- if (rte_mempool_get(qp->sess_mp, (void **)&_sess_private_data))
+ if (rte_mempool_get(qp->sess_mp_priv,
+ (void **)&_sess_private_data))
return NULL;
sess = (struct kasumi_session *)_sess_private_data;
@@ -153,7 +154,7 @@ kasumi_get_session(struct kasumi_qp *qp, struct rte_crypto_op *op)
if (unlikely(kasumi_set_session_parameters(sess,
op->sym->xform) != 0)) {
rte_mempool_put(qp->sess_mp, _sess);
- rte_mempool_put(qp->sess_mp, _sess_private_data);
+ rte_mempool_put(qp->sess_mp_priv, _sess_private_data);
sess = NULL;
}
op->sym->session = (struct rte_cryptodev_sym_session *)_sess;
@@ -325,7 +326,7 @@ process_ops(struct rte_crypto_op **ops, struct kasumi_session *session,
memset(session, 0, sizeof(struct kasumi_session));
memset(ops[i]->sym->session, 0,
rte_cryptodev_sym_get_header_session_size());
- rte_mempool_put(qp->sess_mp, session);
+ rte_mempool_put(qp->sess_mp_priv, session);
rte_mempool_put(qp->sess_mp, ops[i]->sym->session);
ops[i]->sym->session = NULL;
}
diff --git a/drivers/crypto/kasumi/rte_kasumi_pmd_ops.c b/drivers/crypto/kasumi/rte_kasumi_pmd_ops.c
index 9e4bf1b52..a4982f091 100644
--- a/drivers/crypto/kasumi/rte_kasumi_pmd_ops.c
+++ b/drivers/crypto/kasumi/rte_kasumi_pmd_ops.c
@@ -192,7 +192,7 @@ kasumi_pmd_qp_create_processed_ops_ring(struct kasumi_qp *qp,
static int
kasumi_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool)
+ int socket_id)
{
struct kasumi_qp *qp = NULL;
@@ -217,7 +217,8 @@ kasumi_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
if (qp->processed_ops == NULL)
goto qp_setup_cleanup;
- qp->sess_mp = session_pool;
+ qp->sess_mp = qp_conf->mp_session;
+ qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->qp_stats, 0, sizeof(qp->qp_stats));
diff --git a/drivers/crypto/kasumi/rte_kasumi_pmd_private.h b/drivers/crypto/kasumi/rte_kasumi_pmd_private.h
index 488777ca8..76f746c03 100644
--- a/drivers/crypto/kasumi/rte_kasumi_pmd_private.h
+++ b/drivers/crypto/kasumi/rte_kasumi_pmd_private.h
@@ -36,6 +36,8 @@ struct kasumi_qp {
/**< Ring for placing processed ops */
struct rte_mempool *sess_mp;
/**< Session Mempool */
+ struct rte_mempool *sess_mp_priv;
+ /**< Session Private Data Mempool */
struct rte_cryptodev_stats qp_stats;
/**< Queue pair statistics */
uint8_t temp_digest[KASUMI_DIGEST_LENGTH];
diff --git a/drivers/crypto/mvsam/rte_mrvl_pmd_ops.c b/drivers/crypto/mvsam/rte_mrvl_pmd_ops.c
index 9956f051f..ef520356f 100644
--- a/drivers/crypto/mvsam/rte_mrvl_pmd_ops.c
+++ b/drivers/crypto/mvsam/rte_mrvl_pmd_ops.c
@@ -633,7 +633,7 @@ mrvl_crypto_pmd_close(struct rte_cryptodev *dev)
static int
mrvl_crypto_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool)
+ int socket_id)
{
struct mrvl_crypto_qp *qp = NULL;
char match[RTE_CRYPTODEV_NAME_MAX_LEN];
@@ -690,7 +690,8 @@ mrvl_crypto_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
if (sam_cio_init(&qp->cio_params, &qp->cio) < 0)
break;
- qp->sess_mp = session_pool;
+ qp->sess_mp = qp_conf->mp_session;
+ qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->stats, 0, sizeof(qp->stats));
dev->data->queue_pairs[qp_id] = qp;
diff --git a/drivers/crypto/mvsam/rte_mrvl_pmd_private.h b/drivers/crypto/mvsam/rte_mrvl_pmd_private.h
index 6f8cf5624..deb80c55d 100644
--- a/drivers/crypto/mvsam/rte_mrvl_pmd_private.h
+++ b/drivers/crypto/mvsam/rte_mrvl_pmd_private.h
@@ -51,6 +51,9 @@ struct mrvl_crypto_qp {
/** Session Mempool. */
struct rte_mempool *sess_mp;
+ /** Session Private Data Mempool. */
+ struct rte_mempool *sess_mp_priv;
+
/** Queue pair statistics. */
struct rte_cryptodev_stats stats;
diff --git a/drivers/crypto/null/null_crypto_pmd.c b/drivers/crypto/null/null_crypto_pmd.c
index 6e29a21a6..d5e3064f2 100644
--- a/drivers/crypto/null/null_crypto_pmd.c
+++ b/drivers/crypto/null/null_crypto_pmd.c
@@ -87,7 +87,8 @@ get_session(struct null_crypto_qp *qp, struct rte_crypto_op *op)
if (rte_mempool_get(qp->sess_mp, (void **)&_sess))
return NULL;
- if (rte_mempool_get(qp->sess_mp, (void **)&_sess_private_data))
+ if (rte_mempool_get(qp->sess_mp_priv,
+ (void **)&_sess_private_data))
return NULL;
sess = (struct null_crypto_session *)_sess_private_data;
@@ -95,7 +96,7 @@ get_session(struct null_crypto_qp *qp, struct rte_crypto_op *op)
if (unlikely(null_crypto_set_session_parameters(sess,
sym_op->xform) != 0)) {
rte_mempool_put(qp->sess_mp, _sess);
- rte_mempool_put(qp->sess_mp, _sess_private_data);
+ rte_mempool_put(qp->sess_mp_priv, _sess_private_data);
sess = NULL;
}
sym_op->session = (struct rte_cryptodev_sym_session *)_sess;
diff --git a/drivers/crypto/null/null_crypto_pmd_ops.c b/drivers/crypto/null/null_crypto_pmd_ops.c
index 2bdcd019e..941d62bed 100644
--- a/drivers/crypto/null/null_crypto_pmd_ops.c
+++ b/drivers/crypto/null/null_crypto_pmd_ops.c
@@ -184,7 +184,7 @@ null_crypto_pmd_qp_create_processed_pkts_ring(struct null_crypto_qp *qp,
static int
null_crypto_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool)
+ int socket_id)
{
struct null_crypto_private *internals = dev->data->dev_private;
struct null_crypto_qp *qp;
@@ -228,7 +228,8 @@ null_crypto_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
goto qp_setup_cleanup;
}
- qp->sess_mp = session_pool;
+ qp->sess_mp = qp_conf->mp_session;
+ qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->qp_stats, 0, sizeof(qp->qp_stats));
diff --git a/drivers/crypto/null/null_crypto_pmd_private.h b/drivers/crypto/null/null_crypto_pmd_private.h
index d5905afd8..d7bfd9cc8 100644
--- a/drivers/crypto/null/null_crypto_pmd_private.h
+++ b/drivers/crypto/null/null_crypto_pmd_private.h
@@ -31,6 +31,8 @@ struct null_crypto_qp {
/**< Ring for placing process packets */
struct rte_mempool *sess_mp;
/**< Session Mempool */
+ struct rte_mempool *sess_mp_priv;
+ /**< Session Mempool */
struct rte_cryptodev_stats qp_stats;
/**< Queue pair statistics */
} __rte_cache_aligned;
diff --git a/drivers/crypto/octeontx/otx_cryptodev_ops.c b/drivers/crypto/octeontx/otx_cryptodev_ops.c
index 90d0c14b8..6a0cf83f4 100644
--- a/drivers/crypto/octeontx/otx_cryptodev_ops.c
+++ b/drivers/crypto/octeontx/otx_cryptodev_ops.c
@@ -186,8 +186,7 @@ static int
otx_cpt_que_pair_setup(struct rte_cryptodev *dev,
uint16_t que_pair_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id __rte_unused,
- struct rte_mempool *session_pool __rte_unused)
+ int socket_id __rte_unused)
{
void *cptvf = dev->data->dev_private;
struct cpt_instance *instance = NULL;
diff --git a/drivers/crypto/openssl/rte_openssl_pmd.c b/drivers/crypto/openssl/rte_openssl_pmd.c
index a0ccacb1e..a193af642 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd.c
@@ -768,7 +768,8 @@ get_session(struct openssl_qp *qp, struct rte_crypto_op *op)
if (rte_mempool_get(qp->sess_mp, (void **)&_sess))
return NULL;
- if (rte_mempool_get(qp->sess_mp, (void **)&_sess_private_data))
+ if (rte_mempool_get(qp->sess_mp_priv,
+ (void **)&_sess_private_data))
return NULL;
sess = (struct openssl_session *)_sess_private_data;
@@ -776,7 +777,7 @@ get_session(struct openssl_qp *qp, struct rte_crypto_op *op)
if (unlikely(openssl_set_session_parameters(sess,
op->sym->xform) != 0)) {
rte_mempool_put(qp->sess_mp, _sess);
- rte_mempool_put(qp->sess_mp, _sess_private_data);
+ rte_mempool_put(qp->sess_mp_priv, _sess_private_data);
sess = NULL;
}
op->sym->session = (struct rte_cryptodev_sym_session *)_sess;
@@ -2020,7 +2021,7 @@ process_op(struct openssl_qp *qp, struct rte_crypto_op *op,
memset(sess, 0, sizeof(struct openssl_session));
memset(op->sym->session, 0,
rte_cryptodev_sym_get_header_session_size());
- rte_mempool_put(qp->sess_mp, sess);
+ rte_mempool_put(qp->sess_mp_priv, sess);
rte_mempool_put(qp->sess_mp, op->sym->session);
op->sym->session = NULL;
}
diff --git a/drivers/crypto/openssl/rte_openssl_pmd_ops.c b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
index d382476a6..40217cf0d 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd_ops.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
@@ -715,7 +715,7 @@ openssl_pmd_qp_create_processed_ops_ring(struct openssl_qp *qp,
static int
openssl_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool)
+ int socket_id)
{
struct openssl_qp *qp = NULL;
@@ -740,7 +740,8 @@ openssl_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
if (qp->processed_ops == NULL)
goto qp_setup_cleanup;
- qp->sess_mp = session_pool;
+ qp->sess_mp = qp_conf->mp_session;
+ qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->stats, 0, sizeof(qp->stats));
diff --git a/drivers/crypto/openssl/rte_openssl_pmd_private.h b/drivers/crypto/openssl/rte_openssl_pmd_private.h
index a8f2c8482..43ac3813d 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd_private.h
+++ b/drivers/crypto/openssl/rte_openssl_pmd_private.h
@@ -64,6 +64,8 @@ struct openssl_qp {
/**< Ring for placing process packets */
struct rte_mempool *sess_mp;
/**< Session Mempool */
+ struct rte_mempool *sess_mp_priv;
+ /**< Session Private Data Mempool */
struct rte_cryptodev_stats stats;
/**< Queue pair statistics */
uint8_t temp_digest[DIGEST_LENGTH_MAX];
diff --git a/drivers/crypto/qat/qat_sym_pmd.c b/drivers/crypto/qat/qat_sym_pmd.c
index c3f700406..31ccab32e 100644
--- a/drivers/crypto/qat/qat_sym_pmd.c
+++ b/drivers/crypto/qat/qat_sym_pmd.c
@@ -127,7 +127,7 @@ static int qat_sym_qp_release(struct rte_cryptodev *dev, uint16_t queue_pair_id)
static int qat_sym_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool __rte_unused)
+ int socket_id)
{
struct qat_qp *qp;
int ret = 0;
diff --git a/drivers/crypto/scheduler/scheduler_pmd_ops.c b/drivers/crypto/scheduler/scheduler_pmd_ops.c
index 939105aa8..cf70218b7 100644
--- a/drivers/crypto/scheduler/scheduler_pmd_ops.c
+++ b/drivers/crypto/scheduler/scheduler_pmd_ops.c
@@ -390,8 +390,7 @@ scheduler_pmd_qp_release(struct rte_cryptodev *dev, uint16_t qp_id)
/** Setup a queue pair */
static int
scheduler_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
- const struct rte_cryptodev_qp_conf *qp_conf, int socket_id,
- struct rte_mempool *session_pool)
+ const struct rte_cryptodev_qp_conf *qp_conf, int socket_id)
{
struct scheduler_ctx *sched_ctx = dev->data->dev_private;
struct scheduler_qp_ctx *qp_ctx;
@@ -419,7 +418,7 @@ scheduler_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
* must be big enough for all the drivers used.
*/
ret = rte_cryptodev_queue_pair_setup(slave_id, qp_id,
- qp_conf, socket_id, session_pool);
+ qp_conf, socket_id);
if (ret < 0)
return ret;
}
diff --git a/drivers/crypto/snow3g/rte_snow3g_pmd.c b/drivers/crypto/snow3g/rte_snow3g_pmd.c
index a17536b77..7d131f780 100644
--- a/drivers/crypto/snow3g/rte_snow3g_pmd.c
+++ b/drivers/crypto/snow3g/rte_snow3g_pmd.c
@@ -147,7 +147,8 @@ snow3g_get_session(struct snow3g_qp *qp, struct rte_crypto_op *op)
if (rte_mempool_get(qp->sess_mp, (void **)&_sess))
return NULL;
- if (rte_mempool_get(qp->sess_mp, (void **)&_sess_private_data))
+ if (rte_mempool_get(qp->sess_mp_priv,
+ (void **)&_sess_private_data))
return NULL;
sess = (struct snow3g_session *)_sess_private_data;
@@ -155,7 +156,7 @@ snow3g_get_session(struct snow3g_qp *qp, struct rte_crypto_op *op)
if (unlikely(snow3g_set_session_parameters(sess,
op->sym->xform) != 0)) {
rte_mempool_put(qp->sess_mp, _sess);
- rte_mempool_put(qp->sess_mp, _sess_private_data);
+ rte_mempool_put(qp->sess_mp_priv, _sess_private_data);
sess = NULL;
}
op->sym->session = (struct rte_cryptodev_sym_session *)_sess;
@@ -340,7 +341,7 @@ process_ops(struct rte_crypto_op **ops, struct snow3g_session *session,
memset(session, 0, sizeof(struct snow3g_session));
memset(ops[i]->sym->session, 0,
rte_cryptodev_sym_get_header_session_size());
- rte_mempool_put(qp->sess_mp, session);
+ rte_mempool_put(qp->sess_mp_priv, session);
rte_mempool_put(qp->sess_mp, ops[i]->sym->session);
ops[i]->sym->session = NULL;
}
diff --git a/drivers/crypto/snow3g/rte_snow3g_pmd_ops.c b/drivers/crypto/snow3g/rte_snow3g_pmd_ops.c
index a367ee9a0..d2125233f 100644
--- a/drivers/crypto/snow3g/rte_snow3g_pmd_ops.c
+++ b/drivers/crypto/snow3g/rte_snow3g_pmd_ops.c
@@ -198,7 +198,7 @@ snow3g_pmd_qp_create_processed_ops_ring(struct snow3g_qp *qp,
static int
snow3g_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool)
+ int socket_id)
{
struct snow3g_qp *qp = NULL;
@@ -223,7 +223,8 @@ snow3g_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
if (qp->processed_ops == NULL)
goto qp_setup_cleanup;
- qp->sess_mp = session_pool;
+ qp->sess_mp = qp_conf->mp_session;
+ qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->qp_stats, 0, sizeof(qp->qp_stats));
diff --git a/drivers/crypto/snow3g/rte_snow3g_pmd_private.h b/drivers/crypto/snow3g/rte_snow3g_pmd_private.h
index b7807b621..df5c6092b 100644
--- a/drivers/crypto/snow3g/rte_snow3g_pmd_private.h
+++ b/drivers/crypto/snow3g/rte_snow3g_pmd_private.h
@@ -36,6 +36,8 @@ struct snow3g_qp {
/**< Ring for placing processed ops */
struct rte_mempool *sess_mp;
/**< Session Mempool */
+ struct rte_mempool *sess_mp_priv;
+ /**< Session Private Data Mempool */
struct rte_cryptodev_stats qp_stats;
/**< Queue pair statistics */
uint8_t temp_digest[SNOW3G_DIGEST_LENGTH];
diff --git a/drivers/crypto/virtio/virtio_cryptodev.c b/drivers/crypto/virtio/virtio_cryptodev.c
index 568b5a406..4bae3b865 100644
--- a/drivers/crypto/virtio/virtio_cryptodev.c
+++ b/drivers/crypto/virtio/virtio_cryptodev.c
@@ -36,8 +36,7 @@ static void virtio_crypto_dev_stats_reset(struct rte_cryptodev *dev);
static int virtio_crypto_qp_setup(struct rte_cryptodev *dev,
uint16_t queue_pair_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id,
- struct rte_mempool *session_pool);
+ int socket_id);
static int virtio_crypto_qp_release(struct rte_cryptodev *dev,
uint16_t queue_pair_id);
static void virtio_crypto_dev_free_mbufs(struct rte_cryptodev *dev);
@@ -585,8 +584,7 @@ virtio_crypto_dev_stats_reset(struct rte_cryptodev *dev)
static int
virtio_crypto_qp_setup(struct rte_cryptodev *dev, uint16_t queue_pair_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id,
- struct rte_mempool *session_pool __rte_unused)
+ int socket_id)
{
int ret;
struct virtqueue *vq;
diff --git a/drivers/crypto/zuc/rte_zuc_pmd.c b/drivers/crypto/zuc/rte_zuc_pmd.c
index 313f4590b..997c2092f 100644
--- a/drivers/crypto/zuc/rte_zuc_pmd.c
+++ b/drivers/crypto/zuc/rte_zuc_pmd.c
@@ -144,7 +144,8 @@ zuc_get_session(struct zuc_qp *qp, struct rte_crypto_op *op)
if (rte_mempool_get(qp->sess_mp, (void **)&_sess))
return NULL;
- if (rte_mempool_get(qp->sess_mp, (void **)&_sess_private_data))
+ if (rte_mempool_get(qp->sess_mp_priv,
+ (void **)&_sess_private_data))
return NULL;
sess = (struct zuc_session *)_sess_private_data;
@@ -152,7 +153,7 @@ zuc_get_session(struct zuc_qp *qp, struct rte_crypto_op *op)
if (unlikely(zuc_set_session_parameters(sess,
op->sym->xform) != 0)) {
rte_mempool_put(qp->sess_mp, _sess);
- rte_mempool_put(qp->sess_mp, _sess_private_data);
+ rte_mempool_put(qp->sess_mp_priv, _sess_private_data);
sess = NULL;
}
op->sym->session = (struct rte_cryptodev_sym_session *)_sess;
@@ -327,7 +328,7 @@ process_ops(struct rte_crypto_op **ops, enum zuc_operation op_type,
memset(sessions[i], 0, sizeof(struct zuc_session));
memset(ops[i]->sym->session, 0,
rte_cryptodev_sym_get_header_session_size());
- rte_mempool_put(qp->sess_mp, sessions[i]);
+ rte_mempool_put(qp->sess_mp_priv, sessions[i]);
rte_mempool_put(qp->sess_mp, ops[i]->sym->session);
ops[i]->sym->session = NULL;
}
diff --git a/drivers/crypto/zuc/rte_zuc_pmd_ops.c b/drivers/crypto/zuc/rte_zuc_pmd_ops.c
index 04d45e449..1b88947eb 100644
--- a/drivers/crypto/zuc/rte_zuc_pmd_ops.c
+++ b/drivers/crypto/zuc/rte_zuc_pmd_ops.c
@@ -198,7 +198,7 @@ zuc_pmd_qp_create_processed_ops_ring(struct zuc_qp *qp,
static int
zuc_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool)
+ int socket_id)
{
struct zuc_qp *qp = NULL;
@@ -223,7 +223,8 @@ zuc_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
if (qp->processed_ops == NULL)
goto qp_setup_cleanup;
- qp->sess_mp = session_pool;
+ qp->sess_mp = qp_conf->mp_session;
+ qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->qp_stats, 0, sizeof(qp->qp_stats));
diff --git a/drivers/crypto/zuc/rte_zuc_pmd_private.h b/drivers/crypto/zuc/rte_zuc_pmd_private.h
index 5e5906ddb..aa73c0016 100644
--- a/drivers/crypto/zuc/rte_zuc_pmd_private.h
+++ b/drivers/crypto/zuc/rte_zuc_pmd_private.h
@@ -36,6 +36,8 @@ struct zuc_qp {
/**< Ring for placing processed ops */
struct rte_mempool *sess_mp;
/**< Session Mempool */
+ struct rte_mempool *sess_mp_priv;
+ /**< Session Private Data Mempool */
struct rte_cryptodev_stats qp_stats;
/**< Queue pair statistics */
uint8_t temp_digest[ZUC_DIGEST_LENGTH];
diff --git a/drivers/net/softnic/rte_eth_softnic_cryptodev.c b/drivers/net/softnic/rte_eth_softnic_cryptodev.c
index 1480f6dd5..f031d8803 100644
--- a/drivers/net/softnic/rte_eth_softnic_cryptodev.c
+++ b/drivers/net/softnic/rte_eth_softnic_cryptodev.c
@@ -101,7 +101,7 @@ softnic_cryptodev_create(struct pmd_internals *p,
queue_conf.nb_descriptors = params->queue_size;
for (i = 0; i < params->n_queues; i++) {
status = rte_cryptodev_queue_pair_setup(dev_id, i,
- &queue_conf, socket_id, NULL);
+ &queue_conf, socket_id);
if (status < 0)
return NULL;
}
diff --git a/examples/fips_validation/main.c b/examples/fips_validation/main.c
index e7559c633..384b7a240 100644
--- a/examples/fips_validation/main.c
+++ b/examples/fips_validation/main.c
@@ -39,7 +39,7 @@ static int
cryptodev_fips_validate_app_int(void)
{
struct rte_cryptodev_config conf = {rte_socket_id(), 1};
- struct rte_cryptodev_qp_conf qp_conf = {128};
+ struct rte_cryptodev_qp_conf qp_conf = {128, NULL, NULL};
int ret;
ret = rte_cryptodev_configure(env.dev_id, &conf);
@@ -52,7 +52,7 @@ cryptodev_fips_validate_app_int(void)
return ret;
ret = rte_cryptodev_queue_pair_setup(env.dev_id, 0, &qp_conf,
- rte_socket_id(), env.mpool);
+ rte_socket_id());
if (ret < 0)
return ret;
diff --git a/examples/ip_pipeline/cryptodev.c b/examples/ip_pipeline/cryptodev.c
index c4ba72bec..b365810de 100644
--- a/examples/ip_pipeline/cryptodev.c
+++ b/examples/ip_pipeline/cryptodev.c
@@ -93,7 +93,7 @@ cryptodev_create(const char *name, struct cryptodev_params *params)
queue_conf.nb_descriptors = params->queue_size;
for (i = 0; i < params->n_queues; i++) {
status = rte_cryptodev_queue_pair_setup(dev_id, i,
- &queue_conf, socket_id, NULL);
+ &queue_conf, socket_id);
if (status < 0)
return NULL;
}
diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-secgw/ipsec-secgw.c
index 1bc0b5b50..a0ff8f7f7 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -1493,10 +1493,13 @@ cryptodevs_init(void)
cdev_id);
qp_conf.nb_descriptors = CDEV_QUEUE_DESC;
+ qp_conf.mp_session =
+ socket_ctx[dev_conf.socket_id].session_pool;
+ qp_conf.mp_session_private =
+ socket_ctx[dev_conf.socket_id].session_pool;
for (qp = 0; qp < dev_conf.nb_queue_pairs; qp++)
if (rte_cryptodev_queue_pair_setup(cdev_id, qp,
- &qp_conf, dev_conf.socket_id,
- socket_ctx[dev_conf.socket_id].session_pool))
+ &qp_conf, dev_conf.socket_id))
rte_panic("Failed to setup queue %u for "
"cdev_id %u\n", 0, cdev_id);
diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index f12fd266e..1df7ba743 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -2443,9 +2443,11 @@ initialize_cryptodevs(struct l2fwd_crypto_options *options, unsigned nb_ports,
}
qp_conf.nb_descriptors = 2048;
+ qp_conf.mp_session = session_pool_socket[socket_id];
+ qp_conf.mp_session_private = session_pool_socket[socket_id];
retval = rte_cryptodev_queue_pair_setup(cdev_id, 0, &qp_conf,
- socket_id, session_pool_socket[socket_id]);
+ socket_id);
if (retval < 0) {
printf("Failed to setup queue pair %u on cryptodev %u",
0, cdev_id);
diff --git a/examples/vhost_crypto/main.c b/examples/vhost_crypto/main.c
index 3deb5263f..cb30f84c0 100644
--- a/examples/vhost_crypto/main.c
+++ b/examples/vhost_crypto/main.c
@@ -463,7 +463,7 @@ free_resource(void)
int
main(int argc, char *argv[])
{
- struct rte_cryptodev_qp_conf qp_conf = {NB_CRYPTO_DESCRIPTORS};
+ struct rte_cryptodev_qp_conf qp_conf;
struct rte_cryptodev_config config;
struct rte_cryptodev_info dev_info;
char name[128];
@@ -551,11 +551,14 @@ main(int argc, char *argv[])
options.infos[i] = info;
+ qp_conf.nb_descriptors = NB_CRYPTO_DESCRIPTORS;
+ qp_conf.mp_session = info->sess_pool;
+ qp_conf.mp_session_private = info->sess_pool;
+
for (j = 0; j < dev_info.max_nb_queue_pairs; j++) {
ret = rte_cryptodev_queue_pair_setup(info->cid, j,
&qp_conf, rte_lcore_to_socket_id(
- lo->lcore_id),
- info->sess_pool);
+ lo->lcore_id));
if (ret < 0) {
RTE_LOG(ERR, USER1, "Failed to configure qp\n");
goto error_exit;
diff --git a/lib/librte_cryptodev/Makefile b/lib/librte_cryptodev/Makefile
index a8f94c097..e38018183 100644
--- a/lib/librte_cryptodev/Makefile
+++ b/lib/librte_cryptodev/Makefile
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: BSD-3-Clause
-# Copyright(c) 2015 Intel Corporation
+# Copyright(c) 2015-2019 Intel Corporation
include $(RTE_SDK)/mk/rte.vars.mk
@@ -7,7 +7,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
LIB = librte_cryptodev.a
# library version
-LIBABIVER := 5
+LIBABIVER := 6
# build flags
CFLAGS += -O3
diff --git a/lib/librte_cryptodev/meson.build b/lib/librte_cryptodev/meson.build
index 990dd3d44..44bd83212 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 Intel Corporation
+# Copyright(c) 2017-2019 Intel Corporation
-version = 5
+version = 6
sources = files('rte_cryptodev.c', 'rte_cryptodev_pmd.c')
headers = files('rte_cryptodev.h',
'rte_cryptodev_pmd.h',
diff --git a/lib/librte_cryptodev/rte_cryptodev.c b/lib/librte_cryptodev/rte_cryptodev.c
index a52eaaa45..4929d0451 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -941,8 +941,7 @@ rte_cryptodev_close(uint8_t dev_id)
int
rte_cryptodev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
- const struct rte_cryptodev_qp_conf *qp_conf, int socket_id,
- struct rte_mempool *session_pool)
+ const struct rte_cryptodev_qp_conf *qp_conf, int socket_id)
{
struct rte_cryptodev *dev;
@@ -958,6 +957,17 @@ rte_cryptodev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
return -EINVAL;
}
+ if (!qp_conf) {
+ CDEV_LOG_ERR("qp_conf cannot be NULL\n");
+ return -EINVAL;
+ }
+
+ if ((qp_conf->mp_session && !qp_conf->mp_session_private) ||
+ (!qp_conf->mp_session && qp_conf->mp_session_private)) {
+ CDEV_LOG_ERR("Invalid mempools\n");
+ return -EINVAL;
+ }
+
if (dev->data->dev_started) {
CDEV_LOG_ERR(
"device %d must be stopped to allow configuration", dev_id);
@@ -967,7 +977,7 @@ rte_cryptodev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->queue_pair_setup, -ENOTSUP);
return (*dev->dev_ops->queue_pair_setup)(dev, queue_pair_id, qp_conf,
- socket_id, session_pool);
+ socket_id);
}
diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
index 4099823f1..f9e7507da 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -495,6 +495,10 @@ enum rte_cryptodev_event_type {
/** Crypto device queue pair configuration structure. */
struct rte_cryptodev_qp_conf {
uint32_t nb_descriptors; /**< Number of descriptors per queue pair */
+ struct rte_mempool *mp_session;
+ /**< The mempool for creating session in sessionless mode */
+ struct rte_mempool *mp_session_private;
+ /**< The mempool for creating sess private data in sessionless mode */
};
/**
@@ -689,8 +693,7 @@ rte_cryptodev_close(uint8_t dev_id);
*/
extern int
rte_cryptodev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
- const struct rte_cryptodev_qp_conf *qp_conf, int socket_id,
- struct rte_mempool *session_pool);
+ const struct rte_cryptodev_qp_conf *qp_conf, int socket_id);
/**
* Get the number of queue pairs on a specific crypto device
diff --git a/lib/librte_cryptodev/rte_cryptodev_pmd.h b/lib/librte_cryptodev/rte_cryptodev_pmd.h
index 1b6cafd17..f15c9af30 100644
--- a/lib/librte_cryptodev/rte_cryptodev_pmd.h
+++ b/lib/librte_cryptodev/rte_cryptodev_pmd.h
@@ -188,13 +188,12 @@ typedef void (*cryptodev_info_get_t)(struct rte_cryptodev *dev,
* @param qp_id Queue Pair Index
* @param qp_conf Queue configuration structure
* @param socket_id Socket Index
- * @param session_pool Pointer to device session mempool
*
* @return Returns 0 on success.
*/
typedef int (*cryptodev_queue_pair_setup_t)(struct rte_cryptodev *dev,
uint16_t qp_id, const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool);
+ int socket_id);
/**
* Release memory resources allocated by given queue pair.
diff --git a/test/test/test_cryptodev.c b/test/test/test_cryptodev.c
index 84065eb49..aac0b1f0b 100644
--- a/test/test/test_cryptodev.c
+++ b/test/test/test_cryptodev.c
@@ -461,12 +461,13 @@ testsuite_setup(void)
dev_id, ts_params->conf.nb_queue_pairs);
ts_params->qp_conf.nb_descriptors = DEFAULT_NUM_OPS_INFLIGHT;
+ ts_params->qp_conf.mp_session = ts_params->session_mpool;
+ ts_params->qp_conf.mp_session_private = ts_params->session_mpool;
for (qp_id = 0; qp_id < info.max_nb_queue_pairs; qp_id++) {
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
dev_id, qp_id, &ts_params->qp_conf,
- rte_cryptodev_socket_id(dev_id),
- ts_params->session_mpool),
+ rte_cryptodev_socket_id(dev_id)),
"Failed to setup queue pair %u on cryptodev %u",
qp_id, dev_id);
}
@@ -519,8 +520,7 @@ ut_setup(void)
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0], qp_id,
&ts_params->qp_conf,
- rte_cryptodev_socket_id(ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ rte_cryptodev_socket_id(ts_params->valid_devs[0])),
"Failed to setup queue pair %u on cryptodev %u",
qp_id, ts_params->valid_devs[0]);
}
@@ -709,13 +709,14 @@ test_queue_pair_descriptor_setup(void)
* freed so are re-used if ring is released and re-created.
*/
qp_conf.nb_descriptors = MIN_NUM_OPS_INFLIGHT; /* min size*/
+ qp_conf.mp_session = ts_params->session_mpool;
+ qp_conf.mp_session_private = ts_params->session_mpool;
for (qp_id = 0; qp_id < ts_params->conf.nb_queue_pairs; qp_id++) {
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0], qp_id, &qp_conf,
rte_cryptodev_socket_id(
- ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ ts_params->valid_devs[0])),
"Failed test for "
"rte_cryptodev_queue_pair_setup: num_inflights "
"%u on qp %u on cryptodev %u",
@@ -729,8 +730,7 @@ test_queue_pair_descriptor_setup(void)
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0], qp_id, &qp_conf,
rte_cryptodev_socket_id(
- ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ ts_params->valid_devs[0])),
"Failed test for"
" rte_cryptodev_queue_pair_setup: num_inflights"
" %u on qp %u on cryptodev %u",
@@ -744,8 +744,7 @@ test_queue_pair_descriptor_setup(void)
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0], qp_id, &qp_conf,
rte_cryptodev_socket_id(
- ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ ts_params->valid_devs[0])),
"Failed test for "
"rte_cryptodev_queue_pair_setup: num_inflights"
" %u on qp %u on cryptodev %u",
@@ -760,8 +759,7 @@ test_queue_pair_descriptor_setup(void)
TEST_ASSERT_FAIL(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0], qp_id, &qp_conf,
rte_cryptodev_socket_id(
- ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ ts_params->valid_devs[0])),
"Unexpectedly passed test for "
"rte_cryptodev_queue_pair_setup:"
"num_inflights %u on qp %u on cryptodev %u",
@@ -776,8 +774,7 @@ test_queue_pair_descriptor_setup(void)
TEST_ASSERT_FAIL(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0], qp_id, &qp_conf,
rte_cryptodev_socket_id(
- ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ ts_params->valid_devs[0])),
"Unexpectedly passed test for "
"rte_cryptodev_queue_pair_setup:"
"num_inflights %u on qp %u on cryptodev %u",
@@ -791,8 +788,7 @@ test_queue_pair_descriptor_setup(void)
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0], qp_id, &qp_conf,
rte_cryptodev_socket_id(
- ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ ts_params->valid_devs[0])),
"Failed test for"
" rte_cryptodev_queue_pair_setup:"
"num_inflights %u on qp %u on cryptodev %u",
@@ -807,8 +803,7 @@ test_queue_pair_descriptor_setup(void)
TEST_ASSERT_FAIL(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0], qp_id, &qp_conf,
rte_cryptodev_socket_id(
- ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ ts_params->valid_devs[0])),
"Unexpectedly passed test for "
"rte_cryptodev_queue_pair_setup:"
"num_inflights %u on qp %u on cryptodev %u",
@@ -824,8 +819,7 @@ test_queue_pair_descriptor_setup(void)
TEST_ASSERT_FAIL(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0],
qp_id, &qp_conf,
- rte_cryptodev_socket_id(ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ rte_cryptodev_socket_id(ts_params->valid_devs[0])),
"Failed test for rte_cryptodev_queue_pair_setup:"
"invalid qp %u on cryptodev %u",
qp_id, ts_params->valid_devs[0]);
@@ -835,8 +829,7 @@ test_queue_pair_descriptor_setup(void)
TEST_ASSERT_FAIL(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0],
qp_id, &qp_conf,
- rte_cryptodev_socket_id(ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ rte_cryptodev_socket_id(ts_params->valid_devs[0])),
"Failed test for rte_cryptodev_queue_pair_setup:"
"invalid qp %u on cryptodev %u",
qp_id, ts_params->valid_devs[0]);
diff --git a/test/test/test_cryptodev_asym.c b/test/test/test_cryptodev_asym.c
index a899f9973..0f6fc5767 100644
--- a/test/test/test_cryptodev_asym.c
+++ b/test/test/test_cryptodev_asym.c
@@ -383,11 +383,12 @@ testsuite_setup(void)
/* configure qp */
ts_params->qp_conf.nb_descriptors = DEFAULT_NUM_OPS_INFLIGHT;
+ ts_params->qp_conf.mp_session = ts_params->session_mpool;
+ ts_params->qp_conf.mp_session_private = ts_params->session_mpool;
for (qp_id = 0; qp_id < info.max_nb_queue_pairs; qp_id++) {
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
dev_id, qp_id, &ts_params->qp_conf,
- rte_cryptodev_socket_id(dev_id),
- ts_params->session_mpool),
+ rte_cryptodev_socket_id(dev_id)),
"Failed to setup queue pair %u on cryptodev %u ASYM",
qp_id, dev_id);
}
@@ -449,8 +450,7 @@ ut_setup(void)
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0], qp_id,
&ts_params->qp_conf,
- rte_cryptodev_socket_id(ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ rte_cryptodev_socket_id(ts_params->valid_devs[0])),
"Failed to setup queue pair %u on cryptodev %u",
qp_id, ts_params->valid_devs[0]);
}
diff --git a/test/test/test_event_crypto_adapter.c b/test/test/test_event_crypto_adapter.c
index de258c346..54717870e 100644
--- a/test/test/test_event_crypto_adapter.c
+++ b/test/test/test_event_crypto_adapter.c
@@ -546,11 +546,12 @@ configure_cryptodev(void)
TEST_CDEV_ID, conf.nb_queue_pairs);
qp_conf.nb_descriptors = DEFAULT_NUM_OPS_INFLIGHT;
+ qp_conf.mp_session = params.session_mpool;
+ qp_conf.mp_session_private = params.session_mpool;
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
TEST_CDEV_ID, TEST_CDEV_QP_ID, &qp_conf,
- rte_cryptodev_socket_id(TEST_CDEV_ID),
- params.session_mpool),
+ rte_cryptodev_socket_id(TEST_CDEV_ID)),
"Failed to setup queue pair %u on cryptodev %u\n",
TEST_CDEV_QP_ID, TEST_CDEV_ID);
--
2.13.6
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v7 00/10] ipsec: new library for IPsec data-path processing
2019-01-10 14:25 0% ` Thomas Monjalon
@ 2019-01-10 14:40 0% ` De Lara Guarch, Pablo
2019-01-10 14:52 3% ` Ananyev, Konstantin
1 sibling, 0 replies; 200+ results
From: De Lara Guarch, Pablo @ 2019-01-10 14:40 UTC (permalink / raw)
To: Thomas Monjalon, Ananyev, Konstantin; +Cc: dev, akhil.goyal
Hi Thomas,
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Thursday, January 10, 2019 2:25 PM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Cc: dev@dpdk.org; akhil.goyal@nxp.com; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>
> Subject: Re: [PATCH v7 00/10] ipsec: new library for IPsec data-path
> processing
>
> 10/01/2019 15:20, Konstantin Ananyev:
> > v6 -> v7
> > - Changes to address Thomas comments:
> > bump ABI version
> > remove related deprecation notice
> > update release notes, ABI changes section
>
> You did not update the lib versions in the release notes.
> I think you missed a deprecation notice removal in patch 1.
> Have you checked the doxygen warnings in last patch?
>
>
It doesn't matter. Fan is modifying that structure too and he is making these changes, so I will drop this patch after applying his patchset. Therefore, this won't be relevant anymore.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 00/10] ipsec: new library for IPsec data-path processing
2019-01-10 14:20 4% ` [dpdk-dev] [PATCH v7 00/10] ipsec: new library for IPsec data-path processing Konstantin Ananyev
@ 2019-01-10 14:25 0% ` Thomas Monjalon
2019-01-10 14:40 0% ` De Lara Guarch, Pablo
2019-01-10 14:52 3% ` Ananyev, Konstantin
2019-01-10 14:51 0% ` Akhil Goyal
1 sibling, 2 replies; 200+ results
From: Thomas Monjalon @ 2019-01-10 14:25 UTC (permalink / raw)
To: Konstantin Ananyev; +Cc: dev, akhil.goyal, pablo.de.lara.guarch
10/01/2019 15:20, Konstantin Ananyev:
> v6 -> v7
> - Changes to address Thomas comments:
> bump ABI version
> remove related deprecation notice
> update release notes, ABI changes section
You did not update the lib versions in the release notes.
I think you missed a deprecation notice removal in patch 1.
Have you checked the doxygen warnings in last patch?
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v7 02/10] security: add opaque userdata pointer into security session
` (2 preceding siblings ...)
2019-01-10 14:20 5% ` [dpdk-dev] [PATCH v7 01/10] cryptodev: add opaque userdata pointer into crypto sym session Konstantin Ananyev
@ 2019-01-10 14:20 9% ` Konstantin Ananyev
3 siblings, 0 replies; 200+ results
From: Konstantin Ananyev @ 2019-01-10 14:20 UTC (permalink / raw)
To: dev; +Cc: akhil.goyal, pablo.de.lara.guarch, thomas, Konstantin Ananyev
Add 'uint64_t opaque_data' inside struct rte_security_session.
That allows upper layer to easily associate some user defined
data with the session.
Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
Acked-by: Mohammad Abdul Awal <mohammad.abdul.awal@intel.com>
Acked-by: Declan Doherty <declan.doherty@intel.com>
Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
---
doc/guides/rel_notes/deprecation.rst | 4 ----
doc/guides/rel_notes/release_19_02.rst | 4 ++++
lib/librte_security/Makefile | 4 ++--
lib/librte_security/meson.build | 3 ++-
lib/librte_security/rte_security.h | 2 ++
5 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index d4aea4b46..2ea1b86bc 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -71,10 +71,6 @@ Deprecation Notices
- Member ``uint16_t min_mtu`` the minimum MTU allowed.
- Member ``uint16_t max_mtu`` the maximum MTU allowed.
-* security: New field ``uint64_t opaque_data`` is planned to be added into
- ``rte_security_session`` structure. That would allow upper layer to easily
- associate/de-associate some user defined data with the security session.
-
* cryptodev: several API and ABI changes are planned for rte_cryptodev
in v19.02:
diff --git a/doc/guides/rel_notes/release_19_02.rst b/doc/guides/rel_notes/release_19_02.rst
index 9aa482a84..fafed0416 100644
--- a/doc/guides/rel_notes/release_19_02.rst
+++ b/doc/guides/rel_notes/release_19_02.rst
@@ -183,6 +183,10 @@ ABI Changes
easily associate/de-associate some user defined data with the
cryptodev session.
+* security: New field ``uint64_t opaque_data`` is added into
+ ``rte_security_session`` structure. That would allow upper layer to easily
+ associate/de-associate some user defined data with the security session.
+
Shared Library Versions
-----------------------
diff --git a/lib/librte_security/Makefile b/lib/librte_security/Makefile
index bd92343bd..6708effdb 100644
--- a/lib/librte_security/Makefile
+++ b/lib/librte_security/Makefile
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: BSD-3-Clause
-# Copyright(c) 2017 Intel Corporation
+# Copyright(c) 2017-2019 Intel Corporation
include $(RTE_SDK)/mk/rte.vars.mk
@@ -7,7 +7,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
LIB = librte_security.a
# library version
-LIBABIVER := 1
+LIBABIVER := 2
# build flags
CFLAGS += -O3
diff --git a/lib/librte_security/meson.build b/lib/librte_security/meson.build
index 532953fcc..a5130d2f6 100644
--- a/lib/librte_security/meson.build
+++ b/lib/librte_security/meson.build
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
-# Copyright(c) 2017 Intel Corporation
+# Copyright(c) 2017-2019 Intel Corporation
+version = 2
sources = files('rte_security.c')
headers = files('rte_security.h', 'rte_security_driver.h')
deps += ['mempool', 'cryptodev']
diff --git a/lib/librte_security/rte_security.h b/lib/librte_security/rte_security.h
index 718147e00..c8e438fdd 100644
--- a/lib/librte_security/rte_security.h
+++ b/lib/librte_security/rte_security.h
@@ -317,6 +317,8 @@ struct rte_security_session_conf {
struct rte_security_session {
void *sess_private_data;
/**< Private session material */
+ uint64_t opaque_data;
+ /**< Opaque user defined data */
};
/**
--
2.17.1
^ permalink raw reply [relevance 9%]
* [dpdk-dev] [PATCH v7 01/10] cryptodev: add opaque userdata pointer into crypto sym session
2019-01-04 0:25 3% ` Stephen Hemminger
2019-01-10 14:20 4% ` [dpdk-dev] [PATCH v7 00/10] ipsec: new library for IPsec data-path processing Konstantin Ananyev
@ 2019-01-10 14:20 5% ` Konstantin Ananyev
2019-01-10 21:06 4% ` [dpdk-dev] [PATCH v8 0/9] ipsec: new library for IPsec data-path processing Konstantin Ananyev
2019-01-10 21:06 5% ` [dpdk-dev] [PATCH v8 1/9] security: add opaque userdata pointer into security session Konstantin Ananyev
2019-01-10 14:20 9% ` [dpdk-dev] [PATCH v7 02/10] " Konstantin Ananyev
3 siblings, 2 replies; 200+ results
From: Konstantin Ananyev @ 2019-01-10 14:20 UTC (permalink / raw)
To: dev; +Cc: akhil.goyal, pablo.de.lara.guarch, thomas, Konstantin Ananyev
Add 'uint64_t opaque_data' inside struct rte_cryptodev_sym_session.
That allows upper layer to easily associate some user defined
data with the session.
Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
Acked-by: Fiona Trahe <fiona.trahe@intel.com>
Acked-by: Mohammad Abdul Awal <mohammad.abdul.awal@intel.com>
Acked-by: Declan Doherty <declan.doherty@intel.com>
Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
---
doc/guides/rel_notes/release_19_02.rst | 5 +++++
lib/librte_cryptodev/Makefile | 4 ++--
lib/librte_cryptodev/meson.build | 4 ++--
lib/librte_cryptodev/rte_cryptodev.h | 2 ++
4 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_02.rst b/doc/guides/rel_notes/release_19_02.rst
index 22c2dff4e..9aa482a84 100644
--- a/doc/guides/rel_notes/release_19_02.rst
+++ b/doc/guides/rel_notes/release_19_02.rst
@@ -178,6 +178,11 @@ ABI Changes
* mbuf: The format of the sched field of ``rte_mbuf`` has been changed
to include the following fields: ``queue ID``, ``traffic class``, ``color``.
+* cryptodev: New field ``uint64_t opaque_data`` is added into
+ ``rte_cryptodev_sym_session`` structure. That would allow upper layer to
+ easily associate/de-associate some user defined data with the
+ cryptodev session.
+
Shared Library Versions
-----------------------
diff --git a/lib/librte_cryptodev/Makefile b/lib/librte_cryptodev/Makefile
index a8f94c097..e38018183 100644
--- a/lib/librte_cryptodev/Makefile
+++ b/lib/librte_cryptodev/Makefile
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: BSD-3-Clause
-# Copyright(c) 2015 Intel Corporation
+# Copyright(c) 2015-2019 Intel Corporation
include $(RTE_SDK)/mk/rte.vars.mk
@@ -7,7 +7,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
LIB = librte_cryptodev.a
# library version
-LIBABIVER := 5
+LIBABIVER := 6
# build flags
CFLAGS += -O3
diff --git a/lib/librte_cryptodev/meson.build b/lib/librte_cryptodev/meson.build
index 990dd3d44..44bd83212 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 Intel Corporation
+# Copyright(c) 2017-2019 Intel Corporation
-version = 5
+version = 6
sources = files('rte_cryptodev.c', 'rte_cryptodev_pmd.c')
headers = files('rte_cryptodev.h',
'rte_cryptodev_pmd.h',
diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
index 4099823f1..009860e7b 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -954,6 +954,8 @@ rte_cryptodev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
* has a fixed algo, key, op-type, digest_len etc.
*/
struct rte_cryptodev_sym_session {
+ uint64_t opaque_data;
+ /**< Opaque user defined data */
__extension__ void *sess_private_data[0];
/**< Private symmetric session material */
};
--
2.17.1
^ permalink raw reply [relevance 5%]
* [dpdk-dev] [PATCH v7 00/10] ipsec: new library for IPsec data-path processing
2019-01-04 0:25 3% ` Stephen Hemminger
@ 2019-01-10 14:20 4% ` Konstantin Ananyev
2019-01-10 14:25 0% ` Thomas Monjalon
2019-01-10 14:51 0% ` Akhil Goyal
2019-01-10 14:20 5% ` [dpdk-dev] [PATCH v7 01/10] cryptodev: add opaque userdata pointer into crypto sym session Konstantin Ananyev
2019-01-10 14:20 9% ` [dpdk-dev] [PATCH v7 02/10] " Konstantin Ananyev
3 siblings, 2 replies; 200+ results
From: Konstantin Ananyev @ 2019-01-10 14:20 UTC (permalink / raw)
To: dev; +Cc: akhil.goyal, pablo.de.lara.guarch, thomas, Konstantin Ananyev
v6 -> v7
- Changes to address Thomas comments:
bump ABI version
remove related deprecation notice
update release notes, ABI changes section
v5 -> v6
- Fix issues reported by Akhil:
rte_ipsec_session_prepare() fails for lookaside-proto
v4 -> v5
- Fix issue with SQN overflows
- Address Akhil comments:
documentation update
spell checks spacing etc.
fix input crypto_xform check/prepcess
test cases for lookaside and inline proto
v3 -> v4
- Changes to address Declan comments
- Update docs
v2 -> v3
- Several fixes for IPv6 support
- Extra checks for input parameters in public APi functions
v1 -> v2
- Changes to get into account l2_len for outbound transport packets
(Qi comments)
- Several bug fixes
- Some code restructured
- Update MAINTAINERS file
RFCv2 -> v1
- Changes per Jerin comments
- Implement transport mode
- Several bug fixes
- UT largely reworked and extended
This patch introduces a new library within DPDK: librte_ipsec.
The aim is to provide DPDK native high performance library for IPsec
data-path processing.
The library is supposed to utilize existing DPDK crypto-dev and
security API to provide application with transparent IPsec
processing API.
The library is concentrated on data-path protocols processing
(ESP and AH), IKE protocol(s) implementation is out of scope
for that library.
Current patch introduces SA-level API.
SA level API
============
API described below operates on SA level.
It provides functionality that allows user for given SA to process
inbound and outbound IPsec packets.
To be more specific:
- for inbound ESP/AH packets perform decryption, authentication,
integrity checking, remove ESP/AH related headers
- for outbound packets perform payload encryption, attach ICV,
update/add IP headers, add ESP/AH headers/trailers,
setup related mbuf felids (ol_flags, tx_offloads, etc.).
- initialize/un-initialize given SA based on user provided parameters.
The following functionality:
- match inbound/outbound packets to particular SA
- manage crypto/security devices
- provide SAD/SPD related functionality
- determine what crypto/security device has to be used
for given packet(s)
is out of scope for SA-level API.
SA-level API is based on top of crypto-dev/security API and relies on them
to perform actual cipher and integrity checking.
To have an ability to easily map crypto/security sessions into related
IPSec SA opaque userdata field was added into
rte_cryptodev_sym_session and rte_security_session structures.
That implies ABI change for both librte_crytpodev and librte_security.
Due to the nature of crypto-dev API (enqueue/deque model) we use
asynchronous API for IPsec packets destined to be processed by
crypto-device.
Expected API call sequence would be:
/* enqueue for processing by crypto-device */
rte_ipsec_pkt_crypto_prepare(...);
rte_cryptodev_enqueue_burst(...);
/* dequeue from crypto-device and do final processing (if any) */
rte_cryptodev_dequeue_burst(...);
rte_ipsec_pkt_crypto_group(...); /* optional */
rte_ipsec_pkt_process(...);
Though for packets destined for inline processing no extra overhead
is required and synchronous API call: rte_ipsec_pkt_process()
is sufficient for that case.
Current implementation supports all four currently defined
rte_security types.
Though to accommodate future custom implementations function pointers
model is used for both for *crypto_prepare* and *process* impelementations.
Konstantin Ananyev (10):
cryptodev: add opaque userdata pointer into crypto sym session
security: add opaque userdata pointer into security session
net: add ESP trailer structure definition
lib: introduce ipsec library
ipsec: add SA data-path API
ipsec: implement SA data-path API
ipsec: rework SA replay window/SQN for MT environment
ipsec: helper functions to group completed crypto-ops
test/ipsec: introduce functional test
doc: add IPsec library guide
MAINTAINERS | 8 +-
config/common_base | 5 +
doc/guides/prog_guide/index.rst | 1 +
doc/guides/prog_guide/ipsec_lib.rst | 168 ++
doc/guides/rel_notes/deprecation.rst | 4 -
doc/guides/rel_notes/release_19_02.rst | 20 +
lib/Makefile | 2 +
lib/librte_cryptodev/Makefile | 4 +-
lib/librte_cryptodev/meson.build | 4 +-
lib/librte_cryptodev/rte_cryptodev.h | 2 +
lib/librte_ipsec/Makefile | 27 +
lib/librte_ipsec/crypto.h | 123 ++
lib/librte_ipsec/iph.h | 84 +
lib/librte_ipsec/ipsec_sqn.h | 343 ++++
lib/librte_ipsec/meson.build | 10 +
lib/librte_ipsec/pad.h | 45 +
lib/librte_ipsec/rte_ipsec.h | 154 ++
lib/librte_ipsec/rte_ipsec_group.h | 151 ++
lib/librte_ipsec/rte_ipsec_sa.h | 174 ++
lib/librte_ipsec/rte_ipsec_version.map | 15 +
lib/librte_ipsec/sa.c | 1527 ++++++++++++++
lib/librte_ipsec/sa.h | 106 +
lib/librte_ipsec/ses.c | 52 +
lib/librte_net/rte_esp.h | 10 +-
lib/librte_security/Makefile | 4 +-
lib/librte_security/meson.build | 3 +-
lib/librte_security/rte_security.h | 2 +
lib/meson.build | 2 +
mk/rte.app.mk | 2 +
test/test/Makefile | 3 +
test/test/meson.build | 3 +
test/test/test_ipsec.c | 2555 ++++++++++++++++++++++++
32 files changed, 5600 insertions(+), 13 deletions(-)
create mode 100644 doc/guides/prog_guide/ipsec_lib.rst
create mode 100644 lib/librte_ipsec/Makefile
create mode 100644 lib/librte_ipsec/crypto.h
create mode 100644 lib/librte_ipsec/iph.h
create mode 100644 lib/librte_ipsec/ipsec_sqn.h
create mode 100644 lib/librte_ipsec/meson.build
create mode 100644 lib/librte_ipsec/pad.h
create mode 100644 lib/librte_ipsec/rte_ipsec.h
create mode 100644 lib/librte_ipsec/rte_ipsec_group.h
create mode 100644 lib/librte_ipsec/rte_ipsec_sa.h
create mode 100644 lib/librte_ipsec/rte_ipsec_version.map
create mode 100644 lib/librte_ipsec/sa.c
create mode 100644 lib/librte_ipsec/sa.h
create mode 100644 lib/librte_ipsec/ses.c
create mode 100644 test/test/test_ipsec.c
--
2.17.1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v2] compat: merge compat library into EAL
2019-01-10 13:57 0% ` David Marchand
@ 2019-01-10 14:01 0% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2019-01-10 14:01 UTC (permalink / raw)
To: David Marchand
Cc: dev, Thomas Monjalon, Burakov, Anatoly, dpdk stable, nhorman
On Thu, Jan 10, 2019 at 02:57:41PM +0100, David Marchand wrote:
> On Thu, Jan 10, 2019 at 2:48 PM Bruce Richardson
> <[1]bruce.richardson@intel.com> 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 later 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.
>
> CC stable.
>
Not needed. Defect introduced in a commit earlier in this release.
> Fixes: a8499f65a1d1 ("log: add missing experimental tag")
> Signed-off-by: Bruce Richardson <[2]bruce.richardson@intel.com>
> ---
> 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/[3]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 470f36b9c..4dbb111a0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -121,7 +121,6 @@ F: buildtools/symlink-drivers-solibs.sh
> ABI versioning
> M: Neil Horman <[4]nhorman@tuxdriver.com>
> -F: lib/librte_compat/
>
> Maybe ?
> +F: lib/librte_eal/common/include/rte_compat.h
> Tested-by: David Marchand <[5]david.marchand@redhat.com>
> Reviewed-by: David Marchand <[6]david.marchand@redhat.com>
> --
CC: Neil
Not sure. I was thinking it would be covered just as part of the EAL
generally, but I'm ok if Neil still wants explicit ownership of the file.
If it is to be added, hopefully that could just be done on apply.
/Bruce
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] compat: merge compat library into EAL
2019-01-10 13:47 4% ` [dpdk-dev] [PATCH v2] " Bruce Richardson
@ 2019-01-10 13:57 0% ` David Marchand
2019-01-10 14:01 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2019-01-10 13:57 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev, Thomas Monjalon, Burakov, Anatoly, dpdk stable
On Thu, Jan 10, 2019 at 2:48 PM Bruce Richardson <bruce.richardson@intel.com>
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 later 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.
>
CC stable.
>
> Fixes: a8499f65a1d1 ("log: add missing experimental tag")
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
>
> ---
> 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 470f36b9c..4dbb111a0 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/
>
Maybe ?
+F: lib/librte_eal/common/include/rte_compat.h
Tested-by: David Marchand <david.marchand@redhat.com>
Reviewed-by: David Marchand <david.marchand@redhat.com>
--
David Marchand
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v2] compat: merge compat library into EAL
@ 2019-01-10 13:47 4% ` Bruce Richardson
2019-01-10 13:57 0% ` David Marchand
2019-02-06 11:01 4% ` [dpdk-dev] [PATCH v3] " Bruce Richardson
1 sibling, 1 reply; 200+ results
From: Bruce Richardson @ 2019-01-10 13:47 UTC (permalink / raw)
To: dev; +Cc: David Marchand, Thomas Monjalon, anatoly.burakov, Bruce Richardson
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 later 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")
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
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 470f36b9c..4dbb111a0 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 77ba327a8..498306c51 100644
--- a/doc/api/doxy-api.conf.in
+++ b/doc/api/doxy-api.conf.in
@@ -22,7 +22,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 c28a95c34..ad33d9e46 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 8dbdc9bca..91a8de4af 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 93d7901d4..46ba363ce 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 7cee3c94a..29944f127 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%]
* [dpdk-dev] [PATCH] eal: fix strdup usages in internal config
@ 2019-01-10 13:38 2% Anatoly Burakov
2019-01-14 14:18 0% ` Thomas Monjalon
2019-01-31 11:21 0% ` Kevin Traynor
0 siblings, 2 replies; 200+ results
From: Anatoly Burakov @ 2019-01-10 13:38 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson, thomas, ferruh.yigit, andy01011501
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
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
---
lib/librte_eal/bsdapp/eal/eal.c | 19 +++++++--
lib/librte_eal/common/eal_common_options.c | 25 +++++++++++-
lib/librte_eal/common/eal_filesystem.h | 6 ++-
lib/librte_eal/common/eal_internal_cfg.h | 6 +--
lib/librte_eal/common/eal_options.h | 1 +
lib/librte_eal/linuxapp/eal/eal.c | 46 ++++++++++++++++++----
lib/librte_eal/linuxapp/eal/eal_memory.c | 2 +-
7 files changed, 87 insertions(+), 18 deletions(-)
diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c
index c8e0da097..1ba9bd7cf 100644
--- a/lib/librte_eal/bsdapp/eal/eal.c
+++ b/lib/librte_eal/bsdapp/eal/eal.c
@@ -117,7 +117,7 @@ eal_create_runtime_dir(void)
/* create prefix-specific subdirectory under DPDK runtime dir */
ret = snprintf(runtime_dir, sizeof(runtime_dir), "%s/%s",
- tmp, internal_config.hugefile_prefix);
+ tmp, eal_get_hugefile_prefix());
if (ret < 0 || ret == sizeof(runtime_dir)) {
RTE_LOG(ERR, EAL, "Error creating prefix-specific runtime path name\n");
return -1;
@@ -535,9 +535,21 @@ eal_parse_args(int argc, char **argv)
switch (opt) {
case OPT_MBUF_POOL_OPS_NAME_NUM:
- internal_config.user_mbuf_pool_ops_name =
- strdup(optarg);
+ {
+ char *ops_name = strdup(optarg);
+ if (ops_name == NULL)
+ RTE_LOG(ERR, EAL, "Could not store mbuf pool ops name\n");
+ else {
+ /* free old ops name */
+ if (internal_config.user_mbuf_pool_ops_name !=
+ NULL)
+ free(internal_config.user_mbuf_pool_ops_name);
+
+ internal_config.user_mbuf_pool_ops_name =
+ ops_name;
+ }
break;
+ }
case 'h':
eal_usage(prgname);
exit(EXIT_SUCCESS);
@@ -923,6 +935,7 @@ rte_eal_cleanup(void)
{
rte_service_finalize();
rte_mp_channel_cleanup();
+ eal_cleanup_config(&internal_config);
return 0;
}
diff --git a/lib/librte_eal/common/eal_common_options.c b/lib/librte_eal/common/eal_common_options.c
index 6e3a83b98..a2d862b5f 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -169,6 +169,14 @@ eal_option_device_parse(void)
return ret;
}
+const char *
+eal_get_hugefile_prefix(void)
+{
+ if (internal_config.hugefile_prefix != NULL)
+ return internal_config.hugefile_prefix;
+ return HUGEFILE_PREFIX_DEFAULT;
+}
+
void
eal_reset_internal_config(struct internal_config *internal_cfg)
{
@@ -177,7 +185,7 @@ eal_reset_internal_config(struct internal_config *internal_cfg)
internal_cfg->memory = 0;
internal_cfg->force_nrank = 0;
internal_cfg->force_nchannel = 0;
- internal_cfg->hugefile_prefix = HUGEFILE_PREFIX_DEFAULT;
+ internal_cfg->hugefile_prefix = NULL;
internal_cfg->hugepage_dir = NULL;
internal_cfg->force_sockets = 0;
/* zero out the NUMA config */
@@ -1347,6 +1355,19 @@ eal_auto_detect_cores(struct rte_config *cfg)
cfg->lcore_count -= removed;
}
+int
+eal_cleanup_config(struct internal_config *internal_cfg)
+{
+ if (internal_cfg->hugefile_prefix != NULL)
+ free(internal_cfg->hugefile_prefix);
+ if (internal_cfg->hugepage_dir != NULL)
+ free(internal_cfg->hugepage_dir);
+ if (internal_cfg->user_mbuf_pool_ops_name != NULL)
+ free(internal_cfg->user_mbuf_pool_ops_name);
+
+ return 0;
+}
+
int
eal_adjust_config(struct internal_config *internal_cfg)
{
@@ -1387,7 +1408,7 @@ eal_check_common_options(struct internal_config *internal_cfg)
RTE_LOG(ERR, EAL, "Invalid process type specified\n");
return -1;
}
- if (index(internal_cfg->hugefile_prefix, '%') != NULL) {
+ if (index(eal_get_hugefile_prefix(), '%') != NULL) {
RTE_LOG(ERR, EAL, "Invalid char, '%%', in --"OPT_FILE_PREFIX" "
"option\n");
return -1;
diff --git a/lib/librte_eal/common/eal_filesystem.h b/lib/librte_eal/common/eal_filesystem.h
index 64a028db7..89a3added 100644
--- a/lib/librte_eal/common/eal_filesystem.h
+++ b/lib/librte_eal/common/eal_filesystem.h
@@ -28,6 +28,10 @@ eal_create_runtime_dir(void);
int
eal_clean_runtime_dir(void);
+/** Function to return hugefile prefix that's currently set up */
+const char *
+eal_get_hugefile_prefix(void);
+
#define RUNTIME_CONFIG_FNAME "config"
static inline const char *
eal_runtime_config_path(void)
@@ -89,7 +93,7 @@ static inline const char *
eal_get_hugefile_path(char *buffer, size_t buflen, const char *hugedir, int f_id)
{
snprintf(buffer, buflen, HUGEFILE_FMT, hugedir,
- internal_config.hugefile_prefix, f_id);
+ eal_get_hugefile_prefix(), f_id);
buffer[buflen - 1] = '\0';
return buffer;
}
diff --git a/lib/librte_eal/common/eal_internal_cfg.h b/lib/librte_eal/common/eal_internal_cfg.h
index 98e314fef..60eaead8f 100644
--- a/lib/librte_eal/common/eal_internal_cfg.h
+++ b/lib/librte_eal/common/eal_internal_cfg.h
@@ -66,9 +66,9 @@ struct internal_config {
volatile int syslog_facility; /**< facility passed to openlog() */
/** default interrupt mode for VFIO */
volatile enum rte_intr_mode vfio_intr_mode;
- const char *hugefile_prefix; /**< the base filename of hugetlbfs files */
- const char *hugepage_dir; /**< specific hugetlbfs directory to use */
- const char *user_mbuf_pool_ops_name;
+ char *hugefile_prefix; /**< the base filename of hugetlbfs files */
+ char *hugepage_dir; /**< specific hugetlbfs directory to use */
+ char *user_mbuf_pool_ops_name;
/**< user defined mbuf pool ops name */
unsigned num_hugepage_sizes; /**< how many sizes on this system */
struct hugepage_info hugepage_info[MAX_HUGEPAGE_SIZES];
diff --git a/lib/librte_eal/common/eal_options.h b/lib/librte_eal/common/eal_options.h
index 1480c5d77..58ee9ae33 100644
--- a/lib/librte_eal/common/eal_options.h
+++ b/lib/librte_eal/common/eal_options.h
@@ -77,6 +77,7 @@ int eal_parse_common_option(int opt, const char *argv,
struct internal_config *conf);
int eal_option_device_parse(void);
int eal_adjust_config(struct internal_config *internal_cfg);
+int eal_cleanup_config(struct internal_config *internal_cfg);
int eal_check_common_options(struct internal_config *internal_cfg);
void eal_common_usage(void);
enum rte_proc_type_t eal_proc_type_detect(void);
diff --git a/lib/librte_eal/linuxapp/eal/eal.c b/lib/librte_eal/linuxapp/eal/eal.c
index 2d8d470b8..a386829f3 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -125,7 +125,7 @@ eal_create_runtime_dir(void)
/* create prefix-specific subdirectory under DPDK runtime dir */
ret = snprintf(runtime_dir, sizeof(runtime_dir), "%s/%s",
- tmp, internal_config.hugefile_prefix);
+ tmp, eal_get_hugefile_prefix());
if (ret < 0 || ret == sizeof(runtime_dir)) {
RTE_LOG(ERR, EAL, "Error creating prefix-specific runtime path name\n");
return -1;
@@ -727,13 +727,31 @@ eal_parse_args(int argc, char **argv)
exit(EXIT_SUCCESS);
case OPT_HUGE_DIR_NUM:
- internal_config.hugepage_dir = strdup(optarg);
+ {
+ char *hdir = strdup(optarg);
+ if (hdir == NULL)
+ RTE_LOG(ERR, EAL, "Could not store hugepage directory\n");
+ else {
+ /* free old hugepage dir */
+ if (internal_config.hugepage_dir != NULL)
+ free(internal_config.hugepage_dir);
+ internal_config.hugepage_dir = hdir;
+ }
break;
-
+ }
case OPT_FILE_PREFIX_NUM:
- internal_config.hugefile_prefix = strdup(optarg);
+ {
+ char *prefix = strdup(optarg);
+ if (prefix == NULL)
+ RTE_LOG(ERR, EAL, "Could not store file prefix\n");
+ else {
+ /* free old prefix */
+ if (internal_config.hugefile_prefix != NULL)
+ free(internal_config.hugefile_prefix);
+ internal_config.hugefile_prefix = prefix;
+ }
break;
-
+ }
case OPT_SOCKET_MEM_NUM:
if (eal_parse_socket_arg(optarg,
internal_config.socket_mem) < 0) {
@@ -783,10 +801,21 @@ eal_parse_args(int argc, char **argv)
break;
case OPT_MBUF_POOL_OPS_NAME_NUM:
- internal_config.user_mbuf_pool_ops_name =
- strdup(optarg);
- break;
+ {
+ char *ops_name = strdup(optarg);
+ if (ops_name == NULL)
+ RTE_LOG(ERR, EAL, "Could not store mbuf pool ops name\n");
+ else {
+ /* free old ops name */
+ if (internal_config.user_mbuf_pool_ops_name !=
+ NULL)
+ free(internal_config.user_mbuf_pool_ops_name);
+ internal_config.user_mbuf_pool_ops_name =
+ ops_name;
+ }
+ break;
+ }
case OPT_MATCH_ALLOCATIONS_NUM:
internal_config.match_allocations = 1;
break;
@@ -1238,6 +1267,7 @@ rte_eal_cleanup(void)
rte_memseg_walk(mark_freeable, NULL);
rte_service_finalize();
rte_mp_channel_cleanup();
+ eal_cleanup_config(&internal_config);
return 0;
}
diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c b/lib/librte_eal/linuxapp/eal/eal_memory.c
index 7d922a965..1b96b576e 100644
--- a/lib/librte_eal/linuxapp/eal/eal_memory.c
+++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
@@ -438,7 +438,7 @@ find_numasocket(struct hugepage_file *hugepg_tbl, struct hugepage_info *hpi)
}
snprintf(hugedir_str, sizeof(hugedir_str),
- "%s/%s", hpi->hugedir, internal_config.hugefile_prefix);
+ "%s/%s", hpi->hugedir, eal_get_hugefile_prefix());
/* parse numa map */
while (fgets(buf, sizeof(buf), f) != NULL) {
--
2.17.1
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [PATCH v4 01/12] cryptodev: change queue pair configure structure
2019-01-10 9:47 3% ` De Lara Guarch, Pablo
@ 2019-01-10 11:24 0% ` De Lara Guarch, Pablo
0 siblings, 0 replies; 200+ results
From: De Lara Guarch, Pablo @ 2019-01-10 11:24 UTC (permalink / raw)
To: De Lara Guarch, Pablo, Zhang, Roy Fan, dev; +Cc: akhil.goyal, Trahe, Fiona
Hi,
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of De Lara Guarch,
> Pablo
> Sent: Thursday, January 10, 2019 9:47 AM
> To: Zhang, Roy Fan <roy.fan.zhang@intel.com>; dev@dpdk.org
> Cc: akhil.goyal@nxp.com; Trahe, Fiona <fiona.trahe@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v4 01/12] cryptodev: change queue pair
> configure structure
>
>
>
> > -----Original Message-----
> > From: Zhang, Roy Fan
> > Sent: Wednesday, January 9, 2019 10:56 PM
> > To: dev@dpdk.org
> > Cc: akhil.goyal@nxp.com; De Lara Guarch, Pablo
> > <pablo.de.lara.guarch@intel.com>; Trahe, Fiona <fiona.trahe@intel.com>
> > Subject: [PATCH v4 01/12] cryptodev: change queue pair configure
> > structure
> >
> > This patch changes the cryptodev queue pair configure structure to
> > enable two mempool passed into cryptodev PMD simutaneously.
> >
> > Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
> > Acked-by: Fiona Trahe <fiona.trahe@@intel.com>
> > ---
>
> ...
>
> > diff --git a/app/test-crypto-perf/main.c b/app/test-crypto-perf/main.c
> > index 953e058c9..38a2e429f 100644
>
> ...
>
> > +++ b/doc/guides/prog_guide/cryptodev_lib.rst
>
> Could you also update the sample code which calls queue_pair_setup?
>
> > +
> > +
> > Logical Cores, Memory and Queues Pair Relationships
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > diff --git a/doc/guides/rel_notes/release_19_02.rst
> > b/doc/guides/rel_notes/release_19_02.rst
> > index e3b2055d0..75128f8f2 100644
> > --- a/doc/guides/rel_notes/release_19_02.rst
> > +++ b/doc/guides/rel_notes/release_19_02.rst
> > @@ -164,6 +164,9 @@ API Changes
> > ``rte_pdump_init()`` and enum ``rte_pdump_socktype`` were deprecated
> > since 18.05 and are removed in this release.
> >
> > +* cryptodev: as shown in the the 18.11 deprecation notice, the last
> > parameter
> > + of ``rte_cryptodev_queue_pair_setup()``, ``session_pool``, is removed.
> > +
>
> ABI versioning should be bumped in this document.
>
>
> >
> > ABI Changes
> > -----------
> > @@ -183,6 +186,10 @@ ABI Changes
> > * mbuf: The format of the sched field of ``rte_mbuf`` has been changed
> > 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
> > + mempool and symmetric session private data mempool.
> > +
> >
> > Shared Library Versions
> > -----------------------
> > diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
> > b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
> > index ebdf7c35a..abc7a6d5f 100644
>
> ...
>
> > +++ b/lib/librte_cryptodev/Makefile
> > @@ -1,5 +1,5 @@
> > # SPDX-License-Identifier: BSD-3-Clause -# Copyright(c) 2015 Intel
> > Corporation
> > +# Copyright(c) 2015-2018 Intel Corporation
>
> Welcome to 2019 :D
>
> >
> > include $(RTE_SDK)/mk/rte.vars.mk
> >
> > @@ -7,7 +7,7 @@ include $(RTE_SDK)/mk/rte.vars.mk LIB =
> > librte_cryptodev.a
> >
> > # library version
> > -LIBABIVER := 5
> > +LIBABIVER := 6
>
> Version should also be bumped in the meson.build file.
>
> >
> > # build flags
> > CFLAGS += -O3
Forgot to say that the deprecation notice sent for the structure and
the API changed needs to be removed from deprecation.rst.
Apart from that:
Acked-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 02/12] cryptodev: add sym session mempool create
2019-01-09 22:55 3% ` [dpdk-dev] [PATCH v4 02/12] cryptodev: add sym session mempool create Fan Zhang
@ 2019-01-10 11:22 0% ` De Lara Guarch, Pablo
0 siblings, 0 replies; 200+ results
From: De Lara Guarch, Pablo @ 2019-01-10 11:22 UTC (permalink / raw)
To: Zhang, Roy Fan, dev; +Cc: akhil.goyal, Trahe, Fiona
> -----Original Message-----
> From: Zhang, Roy Fan
> Sent: Wednesday, January 9, 2019 10:56 PM
> To: dev@dpdk.org
> Cc: akhil.goyal@nxp.com; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; Trahe, Fiona <fiona.trahe@intel.com>
> Subject: [PATCH v4 02/12] cryptodev: add sym session mempool create
>
> This patch adds a new API "rte_cryptodev_sym_session_pool_create()" to
> cryptodev library. All applications are required to use this API to create sym
> session mempool as it adds private data and nb_drivers information to the
> mempool private data.
>
> Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
> Acked-by: Fiona Trahe <fiona.trahe@intel.com>
> ---
> doc/guides/prog_guide/cryptodev_lib.rst | 28 ++++++++++-----
> doc/guides/rel_notes/release_19_02.rst | 5 +++
> lib/librte_cryptodev/rte_cryptodev.c | 50
> ++++++++++++++++++++++++++
> lib/librte_cryptodev/rte_cryptodev.h | 31 ++++++++++++++++
> lib/librte_cryptodev/rte_cryptodev_version.map | 7 ++++
> 5 files changed, 112 insertions(+), 9 deletions(-)
>
> diff --git a/doc/guides/prog_guide/cryptodev_lib.rst
> b/doc/guides/prog_guide/cryptodev_lib.rst
> index 050a58dc4..366508618 100644
> --- a/doc/guides/prog_guide/cryptodev_lib.rst
> +++ b/doc/guides/prog_guide/cryptodev_lib.rst
> @@ -455,13 +455,15 @@ Crypto workloads.
>
> .. figure:: img/cryptodev_sym_sess.*
>
> -The Crypto device framework provides APIs to allocate and initialize
> sessions -for crypto devices, where sessions are mempool objects.
> +The Crypto device framework provides APIs to create session mempool and
> +allocate and initialize sessions for crypto devices, where sessions are
> mempool objects.
> It is the application's responsibility to create and manage the session
> mempools.
> This approach allows for different scenarios such as having a single session
> mempool for all crypto devices (where the mempool object size is big
> enough to hold the private session of any crypto device), as well as having -
> multiple session mempools of different sizes for better memory usage.
> +multiple session mempools of different sizes for better memory usage.
> +However, the application is required to use
> +``rte_cryptodev_sym_session_pool_create()``
> +to create symmetric session mempool.
>
> An application can use ``rte_cryptodev_sym_get_private_session_size()`` to
> get the private session size of given crypto device. This function would allow
> @@ -623,7 +625,8 @@ using one of the crypto PMDs available in DPDK.
> #define IV_OFFSET (sizeof(struct rte_crypto_op) + \
> sizeof(struct rte_crypto_sym_op))
>
> - struct rte_mempool *mbuf_pool, *crypto_op_pool, *session_pool;
> + struct rte_mempool *mbuf_pool, *crypto_op_pool;
> + struct *session_pool, *session_priv_pool;
Missing rte_mempool here.
> unsigned int session_size;
> int ret;
>
...
> +++ b/doc/guides/rel_notes/release_19_02.rst
> @@ -167,6 +167,11 @@ API Changes
> * cryptodev: as shown in the the 18.11 deprecation notice, the last
> parameter
> of ``rte_cryptodev_queue_pair_setup()`` is removed.
>
> +* cryptodev: a new function ``rte_cryptodev_sym_session_pool_create()``
> +is
> + introduced. This function is used to create symmetric session mempool
> +safely
> + and all crypto applications are required to use this function to
> +create
> + symmetric session mempool from now on.
Even though this is new API, it is replacing a necessary call to
rte_mempool_create() which was used to create the session pools.
I think we should also include that it needs to be used instead of mempool_create (being more explicit).
> +
>
> ABI Changes
> -----------
...
> +++ b/lib/librte_cryptodev/rte_cryptodev_version.map
> @@ -88,6 +88,13 @@ DPDK_18.05 {
>
> } DPDK_17.11;
>
> +DPDK_19.02 {
> + global:
> +
> + rte_cryptodev_sym_session_pool_create;
Just saw that check-symbol-change is complaining about this new API being stable.
Apologies for having you changing from experimental to stable, when the API needs to be experimental.
> +
> +} DPDK_18.05;
> +
> EXPERIMENTAL {
> global:
>
> --
> 2.13.6
Apart from this, patch looks ok to me:
Acked-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 01/12] cryptodev: change queue pair configure structure
2019-01-09 22:55 3% ` [dpdk-dev] [PATCH v4 01/12] cryptodev: change queue pair configure structure Fan Zhang
@ 2019-01-10 9:47 3% ` De Lara Guarch, Pablo
2019-01-10 11:24 0% ` De Lara Guarch, Pablo
0 siblings, 1 reply; 200+ results
From: De Lara Guarch, Pablo @ 2019-01-10 9:47 UTC (permalink / raw)
To: Zhang, Roy Fan, dev; +Cc: akhil.goyal, Trahe, Fiona
> -----Original Message-----
> From: Zhang, Roy Fan
> Sent: Wednesday, January 9, 2019 10:56 PM
> To: dev@dpdk.org
> Cc: akhil.goyal@nxp.com; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; Trahe, Fiona <fiona.trahe@intel.com>
> Subject: [PATCH v4 01/12] cryptodev: change queue pair configure structure
>
> This patch changes the cryptodev queue pair configure structure
> to enable two mempool passed into cryptodev PMD simutaneously.
>
> Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
> Acked-by: Fiona Trahe <fiona.trahe@@intel.com>
> ---
...
> diff --git a/app/test-crypto-perf/main.c b/app/test-crypto-perf/main.c
> index 953e058c9..38a2e429f 100644
...
> +++ b/doc/guides/prog_guide/cryptodev_lib.rst
Could you also update the sample code which calls queue_pair_setup?
> +
> +
> Logical Cores, Memory and Queues Pair Relationships
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> diff --git a/doc/guides/rel_notes/release_19_02.rst
> b/doc/guides/rel_notes/release_19_02.rst
> index e3b2055d0..75128f8f2 100644
> --- a/doc/guides/rel_notes/release_19_02.rst
> +++ b/doc/guides/rel_notes/release_19_02.rst
> @@ -164,6 +164,9 @@ API Changes
> ``rte_pdump_init()`` and enum ``rte_pdump_socktype`` were deprecated
> since 18.05 and are removed in this release.
>
> +* cryptodev: as shown in the the 18.11 deprecation notice, the last
> parameter
> + of ``rte_cryptodev_queue_pair_setup()``, ``session_pool``, is removed.
> +
ABI versioning should be bumped in this document.
>
> ABI Changes
> -----------
> @@ -183,6 +186,10 @@ ABI Changes
> * mbuf: The format of the sched field of ``rte_mbuf`` has been changed
> 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
> + mempool and symmetric session private data mempool.
> +
>
> Shared Library Versions
> -----------------------
> diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
> b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
> index ebdf7c35a..abc7a6d5f 100644
...
> +++ b/lib/librte_cryptodev/Makefile
> @@ -1,5 +1,5 @@
> # SPDX-License-Identifier: BSD-3-Clause
> -# Copyright(c) 2015 Intel Corporation
> +# Copyright(c) 2015-2018 Intel Corporation
Welcome to 2019 :D
>
> include $(RTE_SDK)/mk/rte.vars.mk
>
> @@ -7,7 +7,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
> LIB = librte_cryptodev.a
>
> # library version
> -LIBABIVER := 5
> +LIBABIVER := 6
Version should also be bumped in the meson.build file.
>
> # build flags
> CFLAGS += -O3
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] ethdev: support double precision RED queue weight
@ 2019-01-10 6:23 0% ` Rao, Nikhil
0 siblings, 0 replies; 200+ results
From: Rao, Nikhil @ 2019-01-10 6:23 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Dumitrescu, Cristian, Singh, Jasvinder, dev
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Monday, December 10, 2018 9:31 PM
Hi Stephen,
> To: Rao, Nikhil <nikhil.rao@intel.com>
> Cc: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Singh, Jasvinder
> <jasvinder.singh@intel.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] ethdev: support double precision RED queue
> weight
>
> On Mon, 10 Dec 2018 05:43:37 +0000
> "Rao, Nikhil" <nikhil.rao@intel.com> wrote:
>
> > > -----Original Message-----
> > > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > > Sent: Thursday, November 29, 2018 11:43 AM
> > > To: Rao, Nikhil <nikhil.rao@intel.com>
> > > Cc: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Singh,
> > > Jasvinder <jasvinder.singh@intel.com>; dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH] ethdev: support double precision RED
> > > queue weight
> > >
> > > On Thu, 29 Nov 2018 11:24:42 +0530
> > > Nikhil Rao <nikhil.rao@intel.com> wrote:
> > >
> > > > RED queue weight is currently specified as a negated log of 2.
> > > >
> > > > Add support for RED queue weight to be specified in double
> > > > precision and TM capability flags for double precision and negated
> > > > log2 RED queue weight support.
> > > >
> > > > Signed-off-by: Nikhil Rao <nikhil.rao@intel.com>
> > >
> > > Since this is an ABI break anyway, why not just commit to the new format?
> >
> > Hi Stephen,
> >
> > Can you please provide more detail on your comment ? are you suggesting
> replacing the wq_log2/wq_dp with a double ?
> >
> > Thanks,
> > Nikhil
>
>
> My comment is that since you are changing a structure layout, which would
> break existing users; why not go farther and just fix the API to a better
> version. I don't think any projects use this code anyway, see my talk
> (https://github.com/shemminger/dpdk-metrics).
Sorry for the delay. I don't get your reference to a better version, the structure supports both formats using a union,
similar to how it's done in other DPDK APIs (struct rte_crypto_sym_xform for example). If you have a suggestion for a better layout,
please let me know.
>
> Isn't floating point going to be expensive. Or is it only during the setup
> process, not enqueue/dequeue.
Yes, floating point may end up to be more expensive (and the RED computation is invoked at every enqueue)
Nikhil
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v6 01/10] cryptodev: add opaque userdata pointer into crypto sym session
2019-01-04 9:29 0% ` Ananyev, Konstantin
@ 2019-01-09 23:41 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-01-09 23:41 UTC (permalink / raw)
To: Ananyev, Konstantin; +Cc: dev, Stephen Hemminger, akhil.goyal
04/01/2019 10:29, Ananyev, Konstantin:
>
> > -----Original Message-----
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Friday, January 4, 2019 12:26 AM
> > To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> > Cc: dev@dpdk.org; akhil.goyal@nxp.com
> > Subject: Re: [dpdk-dev] [PATCH v6 01/10] cryptodev: add opaque userdata pointer into crypto sym session
> >
> > On Thu, 3 Jan 2019 20:16:17 +0000
> > Konstantin Ananyev <konstantin.ananyev@intel.com> wrote:
> >
> > > Add 'uint64_t opaque_data' inside struct rte_cryptodev_sym_session.
> > > That allows upper layer to easily associate some user defined
> > > data with the session.
> > >
> > > Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > > Acked-by: Fiona Trahe <fiona.trahe@intel.com>
> > > Acked-by: Mohammad Abdul Awal <mohammad.abdul.awal@intel.com>
> > > Acked-by: Declan Doherty <declan.doherty@intel.com>
> > > Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
> > > ---
> > > lib/librte_cryptodev/rte_cryptodev.h | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
> > > index 4099823f1..009860e7b 100644
> > > --- a/lib/librte_cryptodev/rte_cryptodev.h
> > > +++ b/lib/librte_cryptodev/rte_cryptodev.h
> > > @@ -954,6 +954,8 @@ rte_cryptodev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
> > > * has a fixed algo, key, op-type, digest_len etc.
> > > */
> > > struct rte_cryptodev_sym_session {
> > > + uint64_t opaque_data;
> > > + /**< Opaque user defined data */
> > > __extension__ void *sess_private_data[0];
> > > /**< Private symmetric session material */
> > > };
> >
> > This will cause ABI breakage.
>
> Yes, it surely would.
> That's why we submitted deprecation notice in 18.11 and got 3 acks for it.
So you should remove the deprecation notice in this patch,
and bump the ABI version,
and update the release notes for ABI + version changes.
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v4 09/12] cryptodev: update symmetric session structure
` (2 preceding siblings ...)
2019-01-09 22:56 3% ` [dpdk-dev] [PATCH v4 08/12] cryptodev: add sym session header size API Fan Zhang
@ 2019-01-09 22:56 1% ` Fan Zhang
4 siblings, 0 replies; 200+ results
From: Fan Zhang @ 2019-01-09 22:56 UTC (permalink / raw)
To: dev; +Cc: akhil.goyal, pablo.de.lara.guarch, fiona.trahe
This patch updates the rte_cryptodev_sym_session structure for
cryptodev library. The updates include a changed session private
data array and an added nb_drivers field. They are used to
calculate the correct session header size and ensure safe access
of the session private data.
Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
Acked-by: Fiona Trahe <fiona.trahe@intel.com>
---
doc/guides/prog_guide/img/cryptodev_sym_sess.svg | 701 ++++++++++++-----------
doc/guides/rel_notes/release_19_02.rst | 7 +-
lib/librte_cryptodev/rte_cryptodev.c | 100 +++-
lib/librte_cryptodev/rte_cryptodev.h | 8 +-
lib/librte_cryptodev/rte_cryptodev_pmd.h | 13 +-
5 files changed, 444 insertions(+), 385 deletions(-)
diff --git a/doc/guides/prog_guide/img/cryptodev_sym_sess.svg b/doc/guides/prog_guide/img/cryptodev_sym_sess.svg
index a807cebac..5c843f736 100644
--- a/doc/guides/prog_guide/img/cryptodev_sym_sess.svg
+++ b/doc/guides/prog_guide/img/cryptodev_sym_sess.svg
@@ -19,33 +19,31 @@
id="svg70"
sodipodi:docname="cryptodev_sym_sess.svg"
style="font-size:12px;overflow:visible;color-interpolation-filters:sRGB;fill:none;fill-rule:evenodd;stroke-linecap:square;stroke-miterlimit:3"
- inkscape:version="0.92.1 r15371"><metadata
- id="metadata74"><rdf:RDF><cc:Work
- rdf:about=""><dc:format>image/svg+xml</dc:format><dc:type
- rdf:resource="http://purl.org/dc/dcmitype/StillImage" /><dc:title /></cc:Work></rdf:RDF></metadata><sodipodi:namedview
- pagecolor="#ffffff"
- bordercolor="#666666"
- borderopacity="1"
- objecttolerance="10"
- gridtolerance="10"
- guidetolerance="10"
- inkscape:pageopacity="0"
- inkscape:pageshadow="2"
- inkscape:window-width="1920"
- inkscape:window-height="1051"
- id="namedview72"
- showgrid="false"
- inkscape:zoom="1.7495789"
- inkscape:cx="208.74719"
- inkscape:cy="216.52777"
- inkscape:window-x="-9"
- inkscape:window-y="-9"
- inkscape:window-maximized="0"
- inkscape:current-layer="g68-0" />
- <style
- type="text/css"
- id="style2">
- <![CDATA[
+ inkscape:version="0.92.2 (5c3e80d, 2017-08-06)"><metadata
+ id="metadata74"><rdf:RDF><cc:Work
+ rdf:about=""><dc:format>image/svg+xml</dc:format><dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" /><dc:title /></cc:Work></rdf:RDF></metadata><sodipodi:namedview
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1"
+ objecttolerance="10"
+ gridtolerance="10"
+ guidetolerance="10"
+ inkscape:pageopacity="0"
+ inkscape:pageshadow="2"
+ inkscape:window-width="1920"
+ inkscape:window-height="956"
+ id="namedview72"
+ showgrid="false"
+ inkscape:zoom="1.7495789"
+ inkscape:cx="208.74719"
+ inkscape:cy="216.52777"
+ inkscape:window-x="0"
+ inkscape:window-y="27"
+ inkscape:window-maximized="1"
+ inkscape:current-layer="shape18-1-4" /><style
+ type="text/css"
+ id="style2"><![CDATA[
.st1 {fill:url(#grad0-4);stroke:#386288;stroke-width:0.75}
.st2 {fill:#386288;font-family:Calibri;font-size:0.833336em}
.st3 {visibility:visible}
@@ -56,337 +54,340 @@
.st8 {font-size:0.799995em}
.st9 {font-size:0.799995em;font-weight:bold}
.st10 {fill:none;fill-rule:evenodd;font-size:12px;overflow:visible;stroke-linecap:square;stroke-miterlimit:3}
- ]]>
- </style>
-
- <defs
- id="Patterns_And_Gradients"><marker
- inkscape:isstock="true"
- style="overflow:visible"
- id="marker5421"
- refX="0"
- refY="0"
- orient="auto"
- inkscape:stockid="Arrow2Lend"><path
- transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
- d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
- style="fill:#41719c;fill-opacity:1;fill-rule:evenodd;stroke:#41719c;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
- id="path5419"
- inkscape:connector-curvature="0" /></marker><marker
- inkscape:stockid="Arrow2Lend"
- orient="auto"
- refY="0"
- refX="0"
- id="Arrow2Lend"
- style="overflow:visible"
- inkscape:isstock="true"><path
- id="path5004"
- style="fill:#41719c;fill-opacity:1;fill-rule:evenodd;stroke:#41719c;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
- d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
- transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
- inkscape:connector-curvature="0" /></marker><marker
- inkscape:stockid="Arrow1Lend"
- orient="auto"
- refY="0"
- refX="0"
- id="Arrow1Lend"
- style="overflow:visible"
- inkscape:isstock="true"><path
- id="path4986"
- d="M 0,0 5,-5 -12.5,0 5,5 Z"
- style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000003pt;stroke-opacity:1"
- transform="matrix(-0.8,0,0,-0.8,-10,0)"
- inkscape:connector-curvature="0" /></marker>
- <linearGradient
- id="grad0-4"
- x1="0"
- y1="0"
- x2="1"
- y2="0"
- gradientTransform="rotate(60,0.5,0.5)">
- <stop
- offset="0"
- stop-color="#e8ebef"
- stop-opacity="1"
- id="stop4" />
- <stop
- offset="0.24"
- stop-color="#f4f5f7"
- stop-opacity="1"
- id="stop6" />
- <stop
- offset="0.54"
- stop-color="#feffff"
- stop-opacity="1"
- id="stop8" />
- </linearGradient>
- <filter
- id="filter_2-4"><feGaussianBlur
- stdDeviation="2"
- id="feGaussianBlur12-0" /></filter><linearGradient
- inkscape:collect="always"
- xlink:href="#grad0-4"
- id="linearGradient189"
- gradientTransform="scale(0.8787489,1.1379815)"
- x1="-0.42674366"
- y1="0.98859203"
- x2="176.71146"
- y2="0.98859203"
- gradientUnits="userSpaceOnUse" /><filter
- id="filter_2-5"><feGaussianBlur
- stdDeviation="2"
- id="feGaussianBlur12-8" /></filter><filter
- id="filter_2-3"><feGaussianBlur
- stdDeviation="2"
- id="feGaussianBlur12-2" /></filter><linearGradient
- inkscape:collect="always"
- xlink:href="#grad0-4"
- id="linearGradient189-7"
- gradientTransform="scale(0.8787489,1.1379815)"
- x1="-0.42674366"
- y1="0.98859203"
- x2="176.71146"
- y2="0.98859203"
- gradientUnits="userSpaceOnUse" /><linearGradient
- inkscape:collect="always"
- xlink:href="#grad0-4"
- id="linearGradient500"
- gradientTransform="matrix(0.8787489,0,0,1.1379815,12.431599,21.739241)"
- x1="-0.42674366"
- y1="0.98859203"
- x2="176.71146"
- y2="0.98859203"
- gradientUnits="userSpaceOnUse" /></defs>
- <defs
- id="Filters">
- <filter
- id="filter_2">
- <feGaussianBlur
- stdDeviation="2"
- id="feGaussianBlur12" />
- </filter>
- </defs>
- <g
- id="g68"
- transform="matrix(1,0,0,0.41409874,-12.807629,-5.4621159)">
- <title
- id="title16">Page-1</title>
- <g
- id="shape18-1"
- transform="translate(0.749889,-0.75)">
- <title
- id="title18">Rounded Rectangle.12</title>
- <desc
- id="desc20">Crypto Symmetric Session</desc>
- <path
- d="M 19.211599,224.06924 H 160.5716 a 6.77735,6.77735 0 0 0 6.77,-6.77 V 30.019241 a 6.77735,6.77735 0 0 0 -6.77,-6.78 H 19.211599 a 6.77735,6.77735 0 0 0 -6.78,6.78 V 217.29924 a 6.77735,6.77735 0 0 0 6.78,6.77 z"
- class="st1"
- id="path22"
- style="fill:url(#linearGradient500);stroke:#386288;stroke-width:0.75"
- inkscape:connector-curvature="0" />
- <text
- x="63.123039"
- y="28.531481"
- class="st2"
- id="text24"
- style="font-size:16.97244835px;font-family:Calibri;fill:#386288;stroke-width:1.69723928"
- transform="scale(0.58919214,1.6972392)">Crypto Symmetric Session</text>
-
- </g>
- <g
- id="shape19-6"
- transform="translate(10.6711,-9.82087)">
- <title
- id="title27">Rounded Rectangle.13</title>
- <desc
- id="desc29">Private Session Data</desc>
- </g>
- <g
- id="shape20-12"
- transform="matrix(1,0,0,2.5278193,23.531375,-309.78186)">
- <title
- id="title39">Rounded Rectangle.15</title>
- <desc
- id="desc41">void *sess_private_data[]</desc>
- <path
- d="m 5.91,202.33 h 123.25 a 5.90925,5.90925 -180 0 0 5.91,-5.9 v -36.37 a 5.90925,5.90925 -180 0 0 -5.91,-5.91 H 5.91 A 5.90925,5.90925 -180 0 0 0,160.06 v 36.37 a 5.90925,5.90925 -180 0 0 5.91,5.9 z"
- class="st7"
- id="path43"
- inkscape:connector-curvature="0"
- style="fill:#ffffff;stroke:#41719c;stroke-width:0.75" />
- <text
- x="14.072042"
- y="159.1931"
- class="st6"
- id="text65"
- style="font-size:11.41061592px;font-family:Calibri;fill:#41719c;stroke-width:1.14105785"
- transform="scale(0.92359087,1.0827305)">void *sess_private_data[] <tspan
- x="-3.5230706"
- class="st9"
- id="tspan47"
- style="font-weight:bold;font-size:9.12843513px;stroke-width:1.14105785" /></text>
-
- <rect
- style="fill:none;fill-opacity:1;stroke:#41719c;stroke-width:0.73305672;stroke-opacity:1"
- id="rect4604"
- width="15.968175"
- height="14.230948"
- x="13.494645"
- y="181.68814" /><rect
- style="font-size:12px;overflow:visible;color-interpolation-filters:sRGB;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#41719c;stroke-width:0.73305672;stroke-linecap:square;stroke-miterlimit:3;stroke-opacity:1"
- id="rect4604-7"
- width="15.968174"
- height="14.230948"
- x="29.46282"
- y="181.68814" /><rect
- style="font-size:12px;overflow:visible;color-interpolation-filters:sRGB;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#41719c;stroke-width:0.73305672;stroke-linecap:square;stroke-miterlimit:3;stroke-opacity:1"
- id="rect4604-7-6"
- width="15.968174"
- height="14.230948"
- x="45.430992"
- y="181.68814" /><rect
- style="font-size:12px;overflow:visible;color-interpolation-filters:sRGB;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#41719c;stroke-width:0.73305672;stroke-linecap:square;stroke-miterlimit:3;stroke-opacity:1"
- id="rect4604-7-6-9"
- width="15.968174"
- height="14.230948"
- x="61.399166"
- y="181.68814" /><rect
- style="font-size:12px;overflow:visible;color-interpolation-filters:sRGB;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#41719c;stroke-width:0.73305672;stroke-linecap:square;stroke-miterlimit:3;stroke-opacity:1"
- id="rect4604-7-6-9-8"
- width="15.968174"
- height="14.230948"
- x="77.36734"
- y="181.68814" /><rect
- style="font-size:12px;overflow:visible;color-interpolation-filters:sRGB;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#41719c;stroke-width:0.73305672;stroke-linecap:square;stroke-miterlimit:3;stroke-opacity:1"
- id="rect4604-7-6-9-8-9"
- width="15.968174"
- height="14.230948"
- x="93.33551"
- y="181.68814" /><rect
- style="font-size:12px;overflow:visible;color-interpolation-filters:sRGB;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#41719c;stroke-width:0.73305672;stroke-linecap:square;stroke-miterlimit:3;stroke-opacity:1"
- id="rect4604-7-6-9-8-9-6"
- width="15.968174"
- height="14.230948"
- x="109.30369"
- y="181.68814" /><path
- style="fill:none;fill-opacity:1;stroke:#41719c;stroke-width:0.72427988px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow2Lend)"
- d="m 117.64885,196.01764 0.22164,18.77485 44.6966,-0.0725 -0.22163,-20.00716 16.84434,0.43494"
- id="path5030"
- inkscape:connector-curvature="0" /></g>
- </g>
-<g
- transform="translate(190.70887,-0.53319281)"
- id="g68-0"><title
- id="title16-2">Page-1</title><g
- id="shape18-1-4"
- transform="matrix(1,0,0,0.57815109,0.749889,-0.11722686)"><title
- id="title18-4">Rounded Rectangle.12</title><desc
- id="desc20-6">Crypto Symmetric Session</desc><path
- inkscape:connector-curvature="0"
- d="m 6.78,202.33 h 141.36 a 6.77735,6.77735 -180 0 0 6.77,-6.77 V 8.28 A 6.77735,6.77735 -180 0 0 148.14,1.5 H 6.78 A 6.77735,6.77735 -180 0 0 0,8.28 v 187.28 a 6.77735,6.77735 -180 0 0 6.78,6.77 z"
- class="st1"
- id="path22-0"
- style="fill:url(#linearGradient189);stroke:#386288;stroke-width:0.75" /><text
- x="26.317923"
- y="17.335487"
- class="st2"
- id="text24-5"
- style="font-size:14.02988338px;font-family:Calibri;fill:#386288;stroke-width:1.40298378"
- transform="scale(0.71276665,1.4029837)">Crypto Driver Private Session</text>
-
-</g><g
- id="shape19-6-5"
- transform="matrix(1.022976,0,0,0.71529071,9.1114734,-39.403506)"><title
- id="title27-2">Rounded Rectangle.13</title><desc
- id="desc29-0">Private Session Data</desc><g
- id="shadow19-7-1"
- transform="translate(0.345598,1.97279)"
- class="st3"
- style="visibility:visible"><path
+ ]]></style><defs
+ id="Patterns_And_Gradients"><marker
+ inkscape:isstock="true"
+ style="overflow:visible"
+ id="marker5421"
+ refX="0"
+ refY="0"
+ orient="auto"
+ inkscape:stockid="Arrow2Lend"><path
+ transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
+ d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+ style="fill:#41719c;fill-opacity:1;fill-rule:evenodd;stroke:#41719c;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+ id="path5419"
+ inkscape:connector-curvature="0" /></marker><marker
+ inkscape:stockid="Arrow2Lend"
+ orient="auto"
+ refY="0"
+ refX="0"
+ id="Arrow2Lend"
+ style="overflow:visible"
+ inkscape:isstock="true"><path
+ id="path5004"
+ style="fill:#41719c;fill-opacity:1;fill-rule:evenodd;stroke:#41719c;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+ d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+ transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
+ inkscape:connector-curvature="0" /></marker><marker
+ inkscape:stockid="Arrow1Lend"
+ orient="auto"
+ refY="0"
+ refX="0"
+ id="Arrow1Lend"
+ style="overflow:visible"
+ inkscape:isstock="true"><path
+ id="path4986"
+ d="M 0,0 5,-5 -12.5,0 5,5 Z"
+ style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000003pt;stroke-opacity:1"
+ transform="matrix(-0.8,0,0,-0.8,-10,0)"
+ inkscape:connector-curvature="0" /></marker><linearGradient
+ id="grad0-4"
+ x1="0"
+ y1="0"
+ x2="1"
+ y2="0"
+ gradientTransform="rotate(60,0.5,0.5)"><stop
+ offset="0"
+ stop-color="#e8ebef"
+ stop-opacity="1"
+ id="stop4" /><stop
+ offset="0.24"
+ stop-color="#f4f5f7"
+ stop-opacity="1"
+ id="stop6" /><stop
+ offset="0.54"
+ stop-color="#feffff"
+ stop-opacity="1"
+ id="stop8" /></linearGradient><filter
+ id="filter_2-4"><feGaussianBlur
+ stdDeviation="2"
+ id="feGaussianBlur12-0" /></filter><linearGradient
+ inkscape:collect="always"
+ xlink:href="#grad0-4"
+ id="linearGradient189"
+ gradientTransform="scale(0.8787489,1.1379815)"
+ x1="-0.42674366"
+ y1="0.98859203"
+ x2="176.71146"
+ y2="0.98859203"
+ gradientUnits="userSpaceOnUse" /><filter
+ id="filter_2-5"><feGaussianBlur
+ stdDeviation="2"
+ id="feGaussianBlur12-8" /></filter><filter
+ id="filter_2-3"><feGaussianBlur
+ stdDeviation="2"
+ id="feGaussianBlur12-2" /></filter><linearGradient
+ inkscape:collect="always"
+ xlink:href="#grad0-4"
+ id="linearGradient189-7"
+ gradientTransform="scale(0.8787489,1.1379815)"
+ x1="-0.42674366"
+ y1="0.98859203"
+ x2="176.71146"
+ y2="0.98859203"
+ gradientUnits="userSpaceOnUse" /><linearGradient
+ inkscape:collect="always"
+ xlink:href="#grad0-4"
+ id="linearGradient500"
+ gradientTransform="matrix(0.87785006,0,0,2.0116303,15.940232,20.619826)"
+ x1="-0.42674366"
+ y1="0.98859203"
+ x2="176.71146"
+ y2="0.98859203"
+ gradientUnits="userSpaceOnUse" /></defs><defs
+ id="Filters"><filter
+ id="filter_2"><feGaussianBlur
+ stdDeviation="2"
+ id="feGaussianBlur12" /></filter></defs><g
+ transform="matrix(1,0,0,0.41409874,-12.05774,-5.77269)"
+ id="shape18-1"><title
+ id="title18">Rounded Rectangle.12</title><desc
+ id="desc20">Crypto Symmetric Session</desc><path
+ inkscape:connector-curvature="0"
+ style="fill:url(#linearGradient500);stroke:#386288;stroke-width:0.99665654"
+ id="path22"
+ class="st1"
+ d="M 22.713297,378.28219 H 163.92871 a 6.7704177,11.980443 0 0 0 6.76307,-11.96745 V 35.256532 A 6.7704177,11.980443 0 0 0 163.92871,23.271405 H 22.713297 A 6.7704177,11.980443 0 0 0 15.940232,35.256532 V 366.31474 a 6.7704177,11.980443 0 0 0 6.773065,11.96745 z" /></g><g
+ transform="matrix(1,0,0,0.41409874,-2.136529,-9.5289258)"
+ id="shape19-6"><title
+ id="title27">Rounded Rectangle.13</title><desc
+ id="desc29">Private Session Data</desc></g><g
+ id="g4079"
+ transform="matrix(0.9997031,0,0,1.070998,206.15511,-5.6465883)"><path
+ style="fill:#ffffff;stroke:#41719c;stroke-width:1.15444767"
+ inkscape:connector-curvature="0"
+ id="path43"
+ class="st7"
+ d="m -189.55935,139.62776 h 123.25 a 5.90925,14.000977 0 0 0 5.91,-13.97905 V 39.476089 a 5.90925,14.000977 0 0 0 -5.91,-14.002757 h -123.25 a 5.90925,14.000977 0 0 0 -5.91,14.002757 v 86.172621 a 5.90925,14.000977 0 0 0 5.91,13.97905 z" /><rect
+ y="118.60072"
+ x="-181.11736"
+ height="14.896484"
+ width="15.968175"
+ id="rect4604"
+ style="fill:none;fill-opacity:1;stroke:#41719c;stroke-width:0.75000221;stroke-opacity:1" /><rect
+ y="118.60072"
+ x="-165.14919"
+ height="14.896484"
+ width="15.968174"
+ id="rect4604-7"
+ style="font-size:12px;overflow:visible;color-interpolation-filters:sRGB;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#41719c;stroke-width:0.75000221;stroke-linecap:square;stroke-miterlimit:3;stroke-opacity:1" /><rect
+ y="118.60072"
+ x="-149.181"
+ height="14.896484"
+ width="15.968174"
+ id="rect4604-7-6"
+ style="font-size:12px;overflow:visible;color-interpolation-filters:sRGB;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#41719c;stroke-width:0.75000221;stroke-linecap:square;stroke-miterlimit:3;stroke-opacity:1" /><rect
+ y="118.60072"
+ x="-133.21283"
+ height="14.896484"
+ width="15.968174"
+ id="rect4604-7-6-9"
+ style="font-size:12px;overflow:visible;color-interpolation-filters:sRGB;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#41719c;stroke-width:0.75000221;stroke-linecap:square;stroke-miterlimit:3;stroke-opacity:1" /><rect
+ y="118.60072"
+ x="-117.24466"
+ height="14.896484"
+ width="15.968174"
+ id="rect4604-7-6-9-8"
+ style="font-size:12px;overflow:visible;color-interpolation-filters:sRGB;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#41719c;stroke-width:0.75000221;stroke-linecap:square;stroke-miterlimit:3;stroke-opacity:1" /><rect
+ y="118.60072"
+ x="-101.27649"
+ height="14.896484"
+ width="15.968174"
+ id="rect4604-7-6-9-8-9"
+ style="font-size:12px;overflow:visible;color-interpolation-filters:sRGB;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#41719c;stroke-width:0.75000221;stroke-linecap:square;stroke-miterlimit:3;stroke-opacity:1" /><rect
+ y="118.60072"
+ x="-85.308311"
+ height="14.896484"
+ width="15.968174"
+ id="rect4604-7-6-9-8-9-6"
+ style="font-size:12px;overflow:visible;color-interpolation-filters:sRGB;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#41719c;stroke-width:0.75000221;stroke-linecap:square;stroke-miterlimit:3;stroke-opacity:1" /><text
+ transform="scale(0.48757738,2.0509565)"
+ style="font-size:21.61449814px;font-family:Calibri;overflow:visible;color-interpolation-filters:sRGB;fill:#41719c;fill-rule:evenodd;stroke-width:2.16144276;stroke-linecap:square;stroke-miterlimit:3"
+ id="text65-3"
+ class="st6"
+ y="50.793892"
+ x="-374.07562" />
+<text
+ xml:space="preserve"
+ style="font-style:normal;font-weight:normal;font-size:28.99296951px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.72482425"
+ x="-172.30693"
+ y="83.585136"
+ id="text4129"
+ transform="scale(1.035044,0.96614251)"><tspan
+ sodipodi:role="line"
+ id="tspan4127"
+ x="-172.30693"
+ y="109.23712"
+ style="stroke-width:0.72482425"></tspan></text>
+<text
+ xml:space="preserve"
+ style="font-style:normal;font-weight:normal;font-size:28.99296951px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.72482425"
+ x="-174.79263"
+ y="75.713715"
+ id="text4139"
+ transform="scale(1.035044,0.96614251)"><tspan
+ sodipodi:role="line"
+ id="tspan4137"
+ x="-174.79263"
+ y="101.3657"
+ style="stroke-width:0.72482425"></tspan></text>
+</g><path
+ style="fill:none;fill-opacity:1;stroke:#41719c;stroke-width:0.86738265px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow2Lend)"
+ d="m 128.80127,137.90141 -0.20704,20.06801 44.6966,-0.10399 0.20705,-93.424256 16.84434,0.62379"
+ id="path5030"
inkscape:connector-curvature="0"
- d="m 5.91,202.33 h 123.25 a 5.90925,5.90925 -180 0 0 5.91,-5.9 v -92.78 a 5.90925,5.90925 -180 0 0 -5.91,-5.91 H 5.91 A 5.90925,5.90925 -180 0 0 0,103.65 v 92.78 a 5.90925,5.90925 -180 0 0 5.91,5.9 z"
- class="st4"
- id="path31-8"
- style="fill:#bdd0e9;fill-opacity:0.25;stroke:#bdd0e9;stroke-opacity:0.25;filter:url(#filter_2)" /></g><path
- inkscape:connector-curvature="0"
- d="m 5.91,202.33 h 123.25 a 5.90925,5.90925 -180 0 0 5.91,-5.9 v -92.78 a 5.90925,5.90925 -180 0 0 -5.91,-5.91 H 5.91 A 5.90925,5.90925 -180 0 0 0,103.65 v 92.78 a 5.90925,5.90925 -180 0 0 5.91,5.9 z"
- class="st5"
- id="path34-8"
- style="fill:#a6b6cd;stroke:#41719c;stroke-width:0.75" /><text
- x="34.639763"
- y="119.96548"
- class="st6"
- id="text36-7"
- style="font-size:13.15105343px;font-family:Calibri;fill:#41719c;stroke-width:1.31510115"
- transform="scale(0.76039781,1.3151011)">Private Session Data</text>
-
+ sodipodi:nodetypes="ccccc" /><g
+ transform="matrix(1,0,0,0.57815109,191.45876,-0.65041967)"
+ id="shape18-1-4"><title
+ id="title18-4">Rounded Rectangle.12</title><desc
+ id="desc20-6">Crypto Symmetric Session</desc><path
+ style="fill:url(#linearGradient189);stroke:#386288;stroke-width:0.75"
+ id="path22-0"
+ class="st1"
+ d="m 6.78,202.33 h 141.36 a 6.77735,6.77735 -180 0 0 6.77,-6.77 V 8.28 A 6.77735,6.77735 -180 0 0 148.14,1.5 H 6.78 A 6.77735,6.77735 -180 0 0 0,8.28 v 187.28 a 6.77735,6.77735 -180 0 0 6.78,6.77 z"
+ inkscape:connector-curvature="0" /><text
+ transform="scale(0.71276665,1.4029837)"
+ style="font-size:14.02988338px;font-family:Calibri;fill:#386288;stroke-width:1.40298378"
+ id="text24-5"
+ class="st2"
+ y="17.335487"
+ x="26.317923">Crypto Driver Private Session</text>
+<text
+ transform="scale(0.71276665,1.4029837)"
+ style="font-size:14.02988338px;font-family:Calibri;overflow:visible;color-interpolation-filters:sRGB;fill:#386288;fill-rule:evenodd;stroke-width:1.40298378;stroke-linecap:square;stroke-miterlimit:3"
+ id="text24-5-3"
+ class="st2"
+ y="19.076277"
+ x="-240.04274">Crypto Symmetric Session</text>
+<text
+ transform="scale(0.71276665,1.4029837)"
+ style="font-size:14.02988338px;font-family:Calibri;overflow:visible;color-interpolation-filters:sRGB;fill:#386288;fill-rule:evenodd;stroke-width:1.40298378;stroke-linecap:square;stroke-miterlimit:3"
+ id="text24-5-5"
+ class="st2"
+ y="46.557648"
+ x="-241.24557">uint16_t nb_drivers;</text>
+<text
+ transform="scale(0.71276665,1.4029837)"
+ style="font-size:14.02988338px;font-family:Calibri;overflow:visible;color-interpolation-filters:sRGB;fill:#386288;fill-rule:evenodd;stroke-width:1.40298378;stroke-linecap:square;stroke-miterlimit:3"
+ id="text24-5-6"
+ class="st2"
+ y="98.349464"
+ x="-240.04272">struct {</text>
+<text
+ transform="scale(0.71276665,1.4029837)"
+ style="font-size:14.02988338px;font-family:Calibri;overflow:visible;color-interpolation-filters:sRGB;fill:#386288;fill-rule:evenodd;stroke-width:1.40298378;stroke-linecap:square;stroke-miterlimit:3"
+ id="text24-5-2"
+ class="st2"
+ y="115.26107"
+ x="-204.55865">void *data;</text>
+<text
+ transform="scale(0.71276665,1.4029837)"
+ style="font-size:14.02988338px;font-family:Calibri;overflow:visible;color-interpolation-filters:sRGB;fill:#386288;fill-rule:evenodd;stroke-width:1.40298378;stroke-linecap:square;stroke-miterlimit:3"
+ id="text24-5-9"
+ class="st2"
+ y="144.3279"
+ x="-240.04274">} session_data[];</text>
</g><g
- id="shape18-1-4-7"
- transform="matrix(1,0,0,0.57815109,0.90591369,163.94402)"><title
- id="title18-4-3">Rounded Rectangle.12</title><desc
- id="desc20-6-5">Crypto Symmetric Session</desc><path
- inkscape:connector-curvature="0"
- d="m 6.78,202.33 h 141.36 a 6.77735,6.77735 -180 0 0 6.77,-6.77 V 8.28 A 6.77735,6.77735 -180 0 0 148.14,1.5 H 6.78 A 6.77735,6.77735 -180 0 0 0,8.28 v 187.28 a 6.77735,6.77735 -180 0 0 6.78,6.77 z"
- class="st1"
- id="path22-0-8"
- style="fill:url(#linearGradient189-7);stroke:#386288;stroke-width:0.75" /><text
- x="26.317923"
- y="17.335487"
- class="st2"
- id="text24-5-1"
- style="font-size:14.02988338px;font-family:Calibri;fill:#386288;stroke-width:1.40298378"
- transform="scale(0.71276665,1.4029837)">Crypto Driver Private Session</text>
-
+ transform="matrix(1.022976,0,0,0.71529071,199.82034,-39.936699)"
+ id="shape19-6-5"><title
+ id="title27-2">Rounded Rectangle.13</title><desc
+ id="desc29-0">Private Session Data</desc><g
+ style="visibility:visible"
+ class="st3"
+ transform="translate(0.345598,1.97279)"
+ id="shadow19-7-1"><path
+ style="fill:#bdd0e9;fill-opacity:0.25;stroke:#bdd0e9;stroke-opacity:0.25;filter:url(#filter_2)"
+ id="path31-8"
+ class="st4"
+ d="m 5.91,202.33 h 123.25 a 5.90925,5.90925 -180 0 0 5.91,-5.9 v -92.78 a 5.90925,5.90925 -180 0 0 -5.91,-5.91 H 5.91 A 5.90925,5.90925 -180 0 0 0,103.65 v 92.78 a 5.90925,5.90925 -180 0 0 5.91,5.9 z"
+ inkscape:connector-curvature="0" /></g><path
+ style="fill:#a6b6cd;stroke:#41719c;stroke-width:0.75"
+ id="path34-8"
+ class="st5"
+ d="m 5.91,202.33 h 123.25 a 5.90925,5.90925 -180 0 0 5.91,-5.9 v -92.78 a 5.90925,5.90925 -180 0 0 -5.91,-5.91 H 5.91 A 5.90925,5.90925 -180 0 0 0,103.65 v 92.78 a 5.90925,5.90925 -180 0 0 5.91,5.9 z"
+ inkscape:connector-curvature="0" /><text
+ transform="scale(0.76039781,1.3151011)"
+ style="font-size:13.15105343px;font-family:Calibri;fill:#41719c;stroke-width:1.31510115"
+ id="text36-7"
+ class="st6"
+ y="119.96548"
+ x="34.639763">Private Session Data</text>
</g><g
- id="shape19-6-5-1"
- transform="matrix(1.022976,0,0,0.71529071,9.2675037,124.65774)"><title
- id="title27-2-4">Rounded Rectangle.13</title><desc
- id="desc29-0-9">Private Session Data</desc><g
- id="shadow19-7-1-8"
- transform="translate(0.345598,1.97279)"
- class="st3"
- style="visibility:visible"><path
- inkscape:connector-curvature="0"
- d="m 5.91,202.33 h 123.25 a 5.90925,5.90925 -180 0 0 5.91,-5.9 v -92.78 a 5.90925,5.90925 -180 0 0 -5.91,-5.91 H 5.91 A 5.90925,5.90925 -180 0 0 0,103.65 v 92.78 a 5.90925,5.90925 -180 0 0 5.91,5.9 z"
- class="st4"
- id="path31-8-4"
- style="fill:#bdd0e9;fill-opacity:0.25;stroke:#bdd0e9;stroke-opacity:0.25;filter:url(#filter_2-3)" /></g><path
- inkscape:connector-curvature="0"
- d="m 5.91,202.33 h 123.25 a 5.90925,5.90925 -180 0 0 5.91,-5.9 v -92.78 a 5.90925,5.90925 -180 0 0 -5.91,-5.91 H 5.91 A 5.90925,5.90925 -180 0 0 0,103.65 v 92.78 a 5.90925,5.90925 -180 0 0 5.91,5.9 z"
- class="st5"
- id="path34-8-3"
- style="fill:#a6b6cd;stroke:#41719c;stroke-width:0.75" /><text
- x="34.639763"
- y="119.96548"
- class="st6"
- id="text36-7-6"
- style="font-size:13.15105343px;font-family:Calibri;fill:#41719c;stroke-width:1.31510115"
- transform="scale(0.76039781,1.3151011)">Private Session Data</text>
-
+ transform="matrix(1,0,0,0.57815109,191.61478,163.41083)"
+ id="shape18-1-4-7"><title
+ id="title18-4-3">Rounded Rectangle.12</title><desc
+ id="desc20-6-5">Crypto Symmetric Session</desc><path
+ style="fill:url(#linearGradient189-7);stroke:#386288;stroke-width:0.75"
+ id="path22-0-8"
+ class="st1"
+ d="m 6.78,202.33 h 141.36 a 6.77735,6.77735 -180 0 0 6.77,-6.77 V 8.28 A 6.77735,6.77735 -180 0 0 148.14,1.5 H 6.78 A 6.77735,6.77735 -180 0 0 0,8.28 v 187.28 a 6.77735,6.77735 -180 0 0 6.78,6.77 z"
+ inkscape:connector-curvature="0" /><text
+ transform="scale(0.71276665,1.4029837)"
+ style="font-size:14.02988338px;font-family:Calibri;fill:#386288;stroke-width:1.40298378"
+ id="text24-5-1"
+ class="st2"
+ y="17.335487"
+ x="26.317923">Crypto Driver Private Session</text>
+</g><g
+ transform="matrix(1.022976,0,0,0.71529071,199.97637,124.12455)"
+ id="shape19-6-5-1"><title
+ id="title27-2-4">Rounded Rectangle.13</title><desc
+ id="desc29-0-9">Private Session Data</desc><g
+ style="visibility:visible"
+ class="st3"
+ transform="translate(0.345598,1.97279)"
+ id="shadow19-7-1-8"><path
+ style="fill:#bdd0e9;fill-opacity:0.25;stroke:#bdd0e9;stroke-opacity:0.25;filter:url(#filter_2-3)"
+ id="path31-8-4"
+ class="st4"
+ d="m 5.91,202.33 h 123.25 a 5.90925,5.90925 -180 0 0 5.91,-5.9 v -92.78 a 5.90925,5.90925 -180 0 0 -5.91,-5.91 H 5.91 A 5.90925,5.90925 -180 0 0 0,103.65 v 92.78 a 5.90925,5.90925 -180 0 0 5.91,5.9 z"
+ inkscape:connector-curvature="0" /></g><path
+ style="fill:#a6b6cd;stroke:#41719c;stroke-width:0.75"
+ id="path34-8-3"
+ class="st5"
+ d="m 5.91,202.33 h 123.25 a 5.90925,5.90925 -180 0 0 5.91,-5.9 v -92.78 a 5.90925,5.90925 -180 0 0 -5.91,-5.91 H 5.91 A 5.90925,5.90925 -180 0 0 0,103.65 v 92.78 a 5.90925,5.90925 -180 0 0 5.91,5.9 z"
+ inkscape:connector-curvature="0" /><text
+ transform="scale(0.76039781,1.3151011)"
+ style="font-size:13.15105343px;font-family:Calibri;fill:#41719c;stroke-width:1.31510115"
+ id="text36-7-6"
+ class="st6"
+ y="119.96548"
+ x="34.639763">Private Session Data</text>
</g><text
- xml:space="preserve"
+ id="text5070"
+ y="145.4136"
+ x="248.24945"
style="font-style:normal;font-weight:normal;font-size:30.00008774px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.75000221"
- x="57.540585"
- y="145.94679"
- id="text5070"><tspan
- sodipodi:role="line"
+ xml:space="preserve"><tspan
+ style="stroke-width:0.75000221"
+ y="171.95665"
+ x="248.24945"
id="tspan5068"
- x="57.540585"
- y="173.31679"
- style="stroke-width:0.75000221"></tspan></text>
+ sodipodi:role="line" /></text>
<text
- xml:space="preserve"
+ id="text5074"
+ y="142.68553"
+ x="251.28064"
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:22.00006485px;line-height:1.25;font-family:sans-serif;-inkscape-font-specification:'sans-serif, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.75000221"
- x="60.571766"
- y="143.21872"
- id="text5074"><tspan
- sodipodi:role="line"
+ xml:space="preserve"><tspan
+ style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:22.00006485px;font-family:sans-serif;-inkscape-font-specification:'sans-serif, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;writing-mode:lr-tb;text-anchor:start;stroke-width:0.75000221"
+ y="142.68553"
+ x="251.28064"
id="tspan5072"
- x="60.571766"
- y="143.21872"
- style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:22.00006485px;font-family:sans-serif;-inkscape-font-specification:'sans-serif, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:start;writing-mode:lr-tb;text-anchor:start;stroke-width:0.75000221">...</tspan></text>
+ sodipodi:role="line">...</tspan></text>
<path
- style="fill:none;stroke:#41719c;stroke-width:0.74499911px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#marker5421)"
- d="M -158.57624,71.371238 -157.38,232.04055 -1.1215065,232.19212"
+ inkscape:connector-curvature="0"
id="path5076"
- inkscape:connector-curvature="0" /></g></svg>
+ d="m 32.13263,137.96494 1.19624,93.60569 156.25849,0.0883"
+ style="fill:none;stroke:#41719c;stroke-width:0.56864393px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#marker5421)" /></svg>
\ No newline at end of file
diff --git a/doc/guides/rel_notes/release_19_02.rst b/doc/guides/rel_notes/release_19_02.rst
index 445d6a809..740b24dd7 100644
--- a/doc/guides/rel_notes/release_19_02.rst
+++ b/doc/guides/rel_notes/release_19_02.rst
@@ -170,7 +170,8 @@ API Changes
* cryptodev: a new function ``rte_cryptodev_sym_session_pool_create()`` is
introduced. This function is used to create symmetric session mempool safely
and all crypto applications are required to use this function to create
- symmetric session mempool from now on.
+ symmetric session mempool from now on. Failed to do so will cause
+ ``rte_cryptodev_sym_session_create()`` function call return error.
* cryptodev: introduced a new function
``rte_cryptodev_sym_get_existing_header_session_size()``. The function is
@@ -202,6 +203,10 @@ ABI Changes
``rte_cryptodev_qp_conf`` has been added two parameters of 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.
+
Shared Library Versions
-----------------------
diff --git a/lib/librte_cryptodev/rte_cryptodev.c b/lib/librte_cryptodev/rte_cryptodev.c
index f4f1cf598..ea61f9269 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -978,6 +978,30 @@ rte_cryptodev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
return -EINVAL;
}
+ if (qp_conf->mp_session) {
+ struct rte_cryptodev_sym_session_pool_private_data *pool_priv;
+ uint32_t obj_size = qp_conf->mp_session->elt_size;
+ uint32_t obj_priv_size = qp_conf->mp_session_private->elt_size;
+ struct rte_cryptodev_sym_session s = {0};
+
+ pool_priv = rte_mempool_get_priv(qp_conf->mp_session);
+ if (!pool_priv || qp_conf->mp_session->private_data_size <
+ sizeof(*pool_priv)) {
+ CDEV_LOG_ERR("Invalid mempool\n");
+ return -EINVAL;
+ }
+
+ s.nb_drivers = pool_priv->nb_drivers;
+
+ if ((rte_cryptodev_sym_get_existing_header_session_size(&s) >
+ obj_size) || (s.nb_drivers <= dev->driver_id) ||
+ rte_cryptodev_sym_get_private_session_size(dev_id) >
+ obj_priv_size) {
+ CDEV_LOG_ERR("Invalid mempool\n");
+ return -EINVAL;
+ }
+ }
+
if (dev->data->dev_started) {
CDEV_LOG_ERR(
"device %d must be stopped to allow configuration", dev_id);
@@ -1172,6 +1196,8 @@ rte_cryptodev_sym_session_init(uint8_t dev_id,
struct rte_mempool *mp)
{
struct rte_cryptodev *dev;
+ uint32_t sess_priv_sz = rte_cryptodev_sym_get_private_session_size(
+ dev_id);
uint8_t index;
int ret;
@@ -1180,11 +1206,16 @@ rte_cryptodev_sym_session_init(uint8_t dev_id,
if (sess == NULL || xforms == NULL || dev == NULL)
return -EINVAL;
+ if (mp->elt_size < sess_priv_sz)
+ return -EINVAL;
+
index = dev->driver_id;
+ if (index >= sess->nb_drivers)
+ return -EINVAL;
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->sym_session_configure, -ENOTSUP);
- if (sess->sess_private_data[index] == NULL) {
+ if (sess->sess_data[index].data == NULL) {
ret = dev->dev_ops->sym_session_configure(dev, xforms,
sess, mp);
if (ret < 0) {
@@ -1273,10 +1304,29 @@ rte_cryptodev_sym_session_pool_create(const char *name, uint32_t nb_elts,
return mp;
}
+static unsigned int
+rte_cryptodev_sym_session_data_size(struct rte_cryptodev_sym_session *sess)
+{
+ return (sizeof(sess->sess_data[0]) * sess->nb_drivers);
+}
+
struct rte_cryptodev_sym_session *
rte_cryptodev_sym_session_create(struct rte_mempool *mp)
{
struct rte_cryptodev_sym_session *sess;
+ struct rte_cryptodev_sym_session_pool_private_data *pool_priv;
+
+ if (!mp) {
+ CDEV_LOG_ERR("Invalid mempool\n");
+ return NULL;
+ }
+
+ pool_priv = rte_mempool_get_priv(mp);
+
+ if (!pool_priv || mp->private_data_size < sizeof(*pool_priv)) {
+ CDEV_LOG_ERR("Invalid mempool\n");
+ return NULL;
+ }
/* Allocate a session structure from the session pool */
if (rte_mempool_get(mp, (void **)&sess)) {
@@ -1284,10 +1334,14 @@ rte_cryptodev_sym_session_create(struct rte_mempool *mp)
return NULL;
}
+ sess->nb_drivers = pool_priv->nb_drivers;
+
+
/* Clear device session pointer.
* Include the flag indicating presence of user data
*/
- memset(sess, 0, (sizeof(void *) * nb_drivers) + sizeof(uint8_t));
+ memset(sess->sess_data, 0,
+ rte_cryptodev_sym_session_data_size(sess));
return sess;
}
@@ -1395,16 +1449,20 @@ rte_cryptodev_asym_session_free(struct rte_cryptodev_asym_session *sess)
return 0;
}
-
unsigned int
rte_cryptodev_sym_get_header_session_size(void)
{
/*
- * Header contains pointers to the private data
- * of all registered drivers, and a flag which
- * indicates presence of user data
+ * Header contains pointers to the private data of all registered
+ * drivers and all necessary information to ensure safely clear
+ * or free al session.
*/
- return ((sizeof(void *) * nb_drivers) + sizeof(uint8_t));
+ struct rte_cryptodev_sym_session s = {0};
+
+ s.nb_drivers = nb_drivers;
+
+ return (unsigned int)(sizeof(s) +
+ rte_cryptodev_sym_session_data_size(&s));
}
unsigned int
@@ -1414,7 +1472,8 @@ rte_cryptodev_sym_get_existing_header_session_size(
if (!sess)
return 0;
else
- return rte_cryptodev_sym_get_header_session_size();
+ return (unsigned int)(sizeof(*sess) +
+ rte_cryptodev_sym_session_data_size(sess));
}
unsigned int __rte_experimental
@@ -1432,7 +1491,6 @@ unsigned int
rte_cryptodev_sym_get_private_session_size(uint8_t dev_id)
{
struct rte_cryptodev *dev;
- unsigned int header_size = sizeof(void *) * nb_drivers;
unsigned int priv_sess_size;
if (!rte_cryptodev_pmd_is_valid_dev(dev_id))
@@ -1445,16 +1503,7 @@ rte_cryptodev_sym_get_private_session_size(uint8_t dev_id)
priv_sess_size = (*dev->dev_ops->sym_session_get_size)(dev);
- /*
- * If size is less than session header size,
- * return the latter, as this guarantees that
- * sessionless operations will work
- */
- if (priv_sess_size < header_size)
- return header_size;
-
return priv_sess_size;
-
}
unsigned int __rte_experimental
@@ -1486,15 +1535,10 @@ rte_cryptodev_sym_session_set_user_data(
void *data,
uint16_t size)
{
- uint16_t off_set = sizeof(void *) * nb_drivers;
- uint8_t *user_data_present = (uint8_t *)sess + off_set;
-
if (sess == NULL)
return -EINVAL;
- *user_data_present = 1;
- off_set += sizeof(uint8_t);
- rte_memcpy((uint8_t *)sess + off_set, data, size);
+ rte_memcpy(sess->sess_data + sess->nb_drivers, data, size);
return 0;
}
@@ -1502,14 +1546,10 @@ void * __rte_experimental
rte_cryptodev_sym_session_get_user_data(
struct rte_cryptodev_sym_session *sess)
{
- uint16_t off_set = sizeof(void *) * nb_drivers;
- uint8_t *user_data_present = (uint8_t *)sess + off_set;
-
- if (sess == NULL || !*user_data_present)
+ if (sess == NULL)
return NULL;
- off_set += sizeof(uint8_t);
- return (uint8_t *)sess + off_set;
+ return (void *)(sess->sess_data + sess->nb_drivers);
}
/** Initialise rte_crypto_op mempool element */
diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
index c4db3aa0b..81b7fd1aa 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -957,8 +957,12 @@ rte_cryptodev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
* has a fixed algo, key, op-type, digest_len etc.
*/
struct rte_cryptodev_sym_session {
- __extension__ void *sess_private_data[0];
- /**< Private symmetric session material */
+ uint16_t nb_drivers;
+ /**< number of elements in sess_data array */
+ __extension__ struct {
+ void *data;
+ } sess_data[0];
+ /**< Driver specific session material, variable size */
};
/** Cryptodev asymmetric crypto session */
diff --git a/lib/librte_cryptodev/rte_cryptodev_pmd.h b/lib/librte_cryptodev/rte_cryptodev_pmd.h
index f15c9af30..defe05ea0 100644
--- a/lib/librte_cryptodev/rte_cryptodev_pmd.h
+++ b/lib/librte_cryptodev/rte_cryptodev_pmd.h
@@ -475,14 +475,23 @@ RTE_INIT(init_ ##driver_id)\
static inline void *
get_sym_session_private_data(const struct rte_cryptodev_sym_session *sess,
uint8_t driver_id) {
- return sess->sess_private_data[driver_id];
+ if (unlikely(sess->nb_drivers <= driver_id))
+ return NULL;
+
+ return sess->sess_data[driver_id].data;
}
static inline void
set_sym_session_private_data(struct rte_cryptodev_sym_session *sess,
uint8_t driver_id, void *private_data)
{
- sess->sess_private_data[driver_id] = private_data;
+ if (unlikely(sess->nb_drivers <= driver_id)) {
+ CDEV_LOG_ERR("Set private data for driver %u not allowed\n",
+ driver_id);
+ return;
+ }
+
+ sess->sess_data[driver_id].data = private_data;
}
static inline void *
--
2.13.6
^ permalink raw reply [relevance 1%]
* [dpdk-dev] [PATCH v4 08/12] cryptodev: add sym session header size API
2019-01-09 22:55 3% ` [dpdk-dev] [PATCH v4 01/12] cryptodev: change queue pair configure structure Fan Zhang
2019-01-09 22:55 3% ` [dpdk-dev] [PATCH v4 02/12] cryptodev: add sym session mempool create Fan Zhang
@ 2019-01-09 22:56 3% ` Fan Zhang
2019-01-09 22:56 1% ` [dpdk-dev] [PATCH v4 09/12] cryptodev: update symmetric session structure Fan Zhang
4 siblings, 0 replies; 200+ results
From: Fan Zhang @ 2019-01-09 22:56 UTC (permalink / raw)
To: dev; +Cc: akhil.goyal, pablo.de.lara.guarch, fiona.trahe
This patch adds a new API in Cryptodev Framework. The API is used
to get the header size for the created symmetric Cryptodev session.
Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
Acked-by: Fiona Trahe <fiona.trahe@intel.com>
---
doc/guides/prog_guide/cryptodev_lib.rst | 3 ++-
doc/guides/rel_notes/release_19_02.rst | 7 +++++++
drivers/crypto/aesni_gcm/aesni_gcm_pmd.c | 3 ++-
drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 3 ++-
drivers/crypto/armv8/rte_armv8_pmd.c | 3 ++-
drivers/crypto/kasumi/rte_kasumi_pmd.c | 3 ++-
drivers/crypto/openssl/rte_openssl_pmd.c | 3 ++-
drivers/crypto/snow3g/rte_snow3g_pmd.c | 3 ++-
drivers/crypto/zuc/rte_zuc_pmd.c | 3 ++-
lib/librte_cryptodev/rte_cryptodev.c | 10 ++++++++++
lib/librte_cryptodev/rte_cryptodev.h | 15 +++++++++++++++
lib/librte_cryptodev/rte_cryptodev_version.map | 1 +
12 files changed, 49 insertions(+), 8 deletions(-)
diff --git a/doc/guides/prog_guide/cryptodev_lib.rst b/doc/guides/prog_guide/cryptodev_lib.rst
index 366508618..9dc2d2aa4 100644
--- a/doc/guides/prog_guide/cryptodev_lib.rst
+++ b/doc/guides/prog_guide/cryptodev_lib.rst
@@ -471,7 +471,8 @@ an application to calculate the max device session size of all crypto devices
to create a single session mempool.
If instead an application creates multiple session mempools, the Crypto device
framework also provides ``rte_cryptodev_sym_get_header_session_size`` to get
-the size of an uninitialized session.
+the size of an uninitialized session. For the initialized session, the function
+``rte_cryptodev_sym_get_existing_header_session_size`` should be used instead.
Once the session mempools have been created, ``rte_cryptodev_sym_session_create()``
is used to allocate an uninitialized session from the given mempool.
diff --git a/doc/guides/rel_notes/release_19_02.rst b/doc/guides/rel_notes/release_19_02.rst
index 0b3c30c80..445d6a809 100644
--- a/doc/guides/rel_notes/release_19_02.rst
+++ b/doc/guides/rel_notes/release_19_02.rst
@@ -172,6 +172,13 @@ API Changes
and all crypto applications are required to use this function to create
symmetric session mempool from now on.
+* cryptodev: introduced a new function
+ ``rte_cryptodev_sym_get_existing_header_session_size()``. The function is
+ used to get the session header size from existing symmetric session. Since
+ different sessions may be created from the mempools with different elt size,
+ using this function help pinpoint the exact header data for the session
+ header.
+
ABI Changes
-----------
diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
index abc7a6d5f..948ff0763 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
@@ -419,7 +419,8 @@ handle_completed_gcm_crypto_op(struct aesni_gcm_qp *qp,
if (op->sess_type == RTE_CRYPTO_OP_SESSIONLESS) {
memset(sess, 0, sizeof(struct aesni_gcm_session));
memset(op->sym->session, 0,
- rte_cryptodev_sym_get_header_session_size());
+ 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;
diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
index b0f5c4d67..f3b270d09 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
@@ -951,7 +951,8 @@ post_process_mb_job(struct aesni_mb_qp *qp, JOB_AES_HMAC *job)
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_header_session_size());
+ 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;
diff --git a/drivers/crypto/armv8/rte_armv8_pmd.c b/drivers/crypto/armv8/rte_armv8_pmd.c
index 3b2d7fb2f..0d4649adc 100644
--- a/drivers/crypto/armv8/rte_armv8_pmd.c
+++ b/drivers/crypto/armv8/rte_armv8_pmd.c
@@ -655,7 +655,8 @@ process_op(struct armv8_crypto_qp *qp, struct rte_crypto_op *op,
if (op->sess_type == RTE_CRYPTO_OP_SESSIONLESS) {
memset(sess, 0, sizeof(struct armv8_crypto_session));
memset(op->sym->session, 0,
- rte_cryptodev_sym_get_header_session_size());
+ rte_cryptodev_sym_get_existing_header_session_size(
+ op->sym->session));
rte_mempool_put(qp->sess_mp, sess);
rte_mempool_put(qp->sess_mp_priv, op->sym->session);
op->sym->session = NULL;
diff --git a/drivers/crypto/kasumi/rte_kasumi_pmd.c b/drivers/crypto/kasumi/rte_kasumi_pmd.c
index 6df645a23..3abdb01a9 100644
--- a/drivers/crypto/kasumi/rte_kasumi_pmd.c
+++ b/drivers/crypto/kasumi/rte_kasumi_pmd.c
@@ -325,7 +325,8 @@ process_ops(struct rte_crypto_op **ops, struct kasumi_session *session,
if (ops[i]->sess_type == RTE_CRYPTO_OP_SESSIONLESS) {
memset(session, 0, sizeof(struct kasumi_session));
memset(ops[i]->sym->session, 0,
- rte_cryptodev_sym_get_header_session_size());
+ rte_cryptodev_sym_get_existing_header_session_size(
+ ops[i]->sym->session));
rte_mempool_put(qp->sess_mp_priv, session);
rte_mempool_put(qp->sess_mp, ops[i]->sym->session);
ops[i]->sym->session = NULL;
diff --git a/drivers/crypto/openssl/rte_openssl_pmd.c b/drivers/crypto/openssl/rte_openssl_pmd.c
index a193af642..ea5aac69e 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd.c
@@ -2020,7 +2020,8 @@ process_op(struct openssl_qp *qp, struct rte_crypto_op *op,
openssl_reset_session(sess);
memset(sess, 0, sizeof(struct openssl_session));
memset(op->sym->session, 0,
- rte_cryptodev_sym_get_header_session_size());
+ 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;
diff --git a/drivers/crypto/snow3g/rte_snow3g_pmd.c b/drivers/crypto/snow3g/rte_snow3g_pmd.c
index 7d131f780..5fd94b686 100644
--- a/drivers/crypto/snow3g/rte_snow3g_pmd.c
+++ b/drivers/crypto/snow3g/rte_snow3g_pmd.c
@@ -340,7 +340,8 @@ process_ops(struct rte_crypto_op **ops, struct snow3g_session *session,
if (ops[i]->sess_type == RTE_CRYPTO_OP_SESSIONLESS) {
memset(session, 0, sizeof(struct snow3g_session));
memset(ops[i]->sym->session, 0,
- rte_cryptodev_sym_get_header_session_size());
+ rte_cryptodev_sym_get_existing_header_session_size(
+ ops[i]->sym->session));
rte_mempool_put(qp->sess_mp_priv, session);
rte_mempool_put(qp->sess_mp, ops[i]->sym->session);
ops[i]->sym->session = NULL;
diff --git a/drivers/crypto/zuc/rte_zuc_pmd.c b/drivers/crypto/zuc/rte_zuc_pmd.c
index 997c2092f..637994dfd 100644
--- a/drivers/crypto/zuc/rte_zuc_pmd.c
+++ b/drivers/crypto/zuc/rte_zuc_pmd.c
@@ -327,7 +327,8 @@ process_ops(struct rte_crypto_op **ops, enum zuc_operation op_type,
if (ops[i]->sess_type == RTE_CRYPTO_OP_SESSIONLESS) {
memset(sessions[i], 0, sizeof(struct zuc_session));
memset(ops[i]->sym->session, 0,
- rte_cryptodev_sym_get_header_session_size());
+ rte_cryptodev_sym_get_existing_header_session_size(
+ ops[i]->sym->session));
rte_mempool_put(qp->sess_mp_priv, sessions[i]);
rte_mempool_put(qp->sess_mp, ops[i]->sym->session);
ops[i]->sym->session = NULL;
diff --git a/lib/librte_cryptodev/rte_cryptodev.c b/lib/librte_cryptodev/rte_cryptodev.c
index 5b1449d14..f4f1cf598 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -1407,6 +1407,16 @@ rte_cryptodev_sym_get_header_session_size(void)
return ((sizeof(void *) * nb_drivers) + sizeof(uint8_t));
}
+unsigned int
+rte_cryptodev_sym_get_existing_header_session_size(
+ struct rte_cryptodev_sym_session *sess)
+{
+ if (!sess)
+ return 0;
+ else
+ return rte_cryptodev_sym_get_header_session_size();
+}
+
unsigned int __rte_experimental
rte_cryptodev_asym_get_header_session_size(void)
{
diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
index 265f02cbe..c4db3aa0b 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -1137,6 +1137,21 @@ unsigned int
rte_cryptodev_sym_get_header_session_size(void);
/**
+ * Get the size of the header session from created session.
+ *
+ * @param sess
+ * The sym cryptodev session pointer
+ *
+ * @return
+ * - If sess is not NULL, return the size of the header session including
+ * the private data size defined within sess.
+ * - If sess is NULL, return 0.
+ */
+unsigned int
+rte_cryptodev_sym_get_existing_header_session_size(
+ struct rte_cryptodev_sym_session *sess);
+
+/**
* Get the size of the asymmetric session header, for all registered drivers.
*
* @return
diff --git a/lib/librte_cryptodev/rte_cryptodev_version.map b/lib/librte_cryptodev/rte_cryptodev_version.map
index 5b6b679f5..0c8d67223 100644
--- a/lib/librte_cryptodev/rte_cryptodev_version.map
+++ b/lib/librte_cryptodev/rte_cryptodev_version.map
@@ -91,6 +91,7 @@ DPDK_18.05 {
DPDK_19.02 {
global:
+ rte_cryptodev_sym_get_existing_header_session_size;
rte_cryptodev_sym_session_pool_create;
} DPDK_18.05;
--
2.13.6
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v4 02/12] cryptodev: add sym session mempool create
2019-01-09 22:55 3% ` [dpdk-dev] [PATCH v4 01/12] cryptodev: change queue pair configure structure Fan Zhang
@ 2019-01-09 22:55 3% ` Fan Zhang
2019-01-10 11:22 0% ` De Lara Guarch, Pablo
2019-01-09 22:56 3% ` [dpdk-dev] [PATCH v4 08/12] cryptodev: add sym session header size API Fan Zhang
` (2 subsequent siblings)
4 siblings, 1 reply; 200+ results
From: Fan Zhang @ 2019-01-09 22:55 UTC (permalink / raw)
To: dev; +Cc: akhil.goyal, pablo.de.lara.guarch, fiona.trahe
This patch adds a new API "rte_cryptodev_sym_session_pool_create()" to
cryptodev library. All applications are required to use this API to
create sym session mempool as it adds private data and nb_drivers
information to the mempool private data.
Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
Acked-by: Fiona Trahe <fiona.trahe@intel.com>
---
doc/guides/prog_guide/cryptodev_lib.rst | 28 ++++++++++-----
doc/guides/rel_notes/release_19_02.rst | 5 +++
lib/librte_cryptodev/rte_cryptodev.c | 50 ++++++++++++++++++++++++++
lib/librte_cryptodev/rte_cryptodev.h | 31 ++++++++++++++++
lib/librte_cryptodev/rte_cryptodev_version.map | 7 ++++
5 files changed, 112 insertions(+), 9 deletions(-)
diff --git a/doc/guides/prog_guide/cryptodev_lib.rst b/doc/guides/prog_guide/cryptodev_lib.rst
index 050a58dc4..366508618 100644
--- a/doc/guides/prog_guide/cryptodev_lib.rst
+++ b/doc/guides/prog_guide/cryptodev_lib.rst
@@ -455,13 +455,15 @@ Crypto workloads.
.. figure:: img/cryptodev_sym_sess.*
-The Crypto device framework provides APIs to allocate and initialize sessions
-for crypto devices, where sessions are mempool objects.
+The Crypto device framework provides APIs to create session mempool and allocate
+and initialize sessions for crypto devices, where sessions are mempool objects.
It is the application's responsibility to create and manage the session mempools.
This approach allows for different scenarios such as having a single session
mempool for all crypto devices (where the mempool object size is big
enough to hold the private session of any crypto device), as well as having
-multiple session mempools of different sizes for better memory usage.
+multiple session mempools of different sizes for better memory usage. However,
+the application is required to use ``rte_cryptodev_sym_session_pool_create()``
+to create symmetric session mempool.
An application can use ``rte_cryptodev_sym_get_private_session_size()`` to
get the private session size of given crypto device. This function would allow
@@ -623,7 +625,8 @@ using one of the crypto PMDs available in DPDK.
#define IV_OFFSET (sizeof(struct rte_crypto_op) + \
sizeof(struct rte_crypto_sym_op))
- struct rte_mempool *mbuf_pool, *crypto_op_pool, *session_pool;
+ struct rte_mempool *mbuf_pool, *crypto_op_pool;
+ struct *session_pool, *session_priv_pool;
unsigned int session_size;
int ret;
@@ -673,13 +676,20 @@ using one of the crypto PMDs available in DPDK.
/* Get private session data size. */
session_size = rte_cryptodev_sym_get_private_session_size(cdev_id);
+ /* Create session mempool for the session header. */
+ session_pool = rte_cryptodev_sym_session_pool_create("session_pool",
+ MAX_SESSIONS,
+ 0,
+ POOL_CACHE_SIZE,
+ 0,
+ socket_id);
+
/*
- * Create session mempool, with two objects per session,
- * one for the session header and another one for the
+ * Create session private data mempool for the
* private session data for the crypto device.
*/
- session_pool = rte_mempool_create("session_pool",
- MAX_SESSIONS * 2,
+ session_priv_pool = rte_mempool_create("session_pool",
+ MAX_SESSIONS,
session_size,
POOL_CACHE_SIZE,
0, NULL, NULL, NULL,
@@ -731,7 +741,7 @@ using one of the crypto PMDs available in DPDK.
rte_exit(EXIT_FAILURE, "Session could not be created\n");
if (rte_cryptodev_sym_session_init(cdev_id, session,
- &cipher_xform, session_pool) < 0)
+ &cipher_xform, session_priv_pool) < 0)
rte_exit(EXIT_FAILURE, "Session could not be initialized "
"for the crypto device\n");
diff --git a/doc/guides/rel_notes/release_19_02.rst b/doc/guides/rel_notes/release_19_02.rst
index 75128f8f2..0b3c30c80 100644
--- a/doc/guides/rel_notes/release_19_02.rst
+++ b/doc/guides/rel_notes/release_19_02.rst
@@ -167,6 +167,11 @@ API Changes
* cryptodev: as shown in the the 18.11 deprecation notice, the last parameter
of ``rte_cryptodev_queue_pair_setup()`` is removed.
+* cryptodev: a new function ``rte_cryptodev_sym_session_pool_create()`` is
+ introduced. This function is used to create symmetric session mempool safely
+ and all crypto applications are required to use this function to create
+ symmetric session mempool from now on.
+
ABI Changes
-----------
diff --git a/lib/librte_cryptodev/rte_cryptodev.c b/lib/librte_cryptodev/rte_cryptodev.c
index 4929d0451..5b1449d14 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -189,6 +189,16 @@ const char *rte_crypto_asym_op_strings[] = {
[RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE] = "sharedsecret_compute",
};
+/**
+ * The private data structure stored in the session mempool private data.
+ */
+struct rte_cryptodev_sym_session_pool_private_data {
+ uint16_t nb_drivers;
+ /**< number of elements in sess_data array */
+ uint16_t user_data_sz;
+ /**< session user data will be placed after sess_data */
+};
+
int
rte_cryptodev_get_cipher_algo_enum(enum rte_crypto_cipher_algorithm *algo_enum,
const char *algo_string)
@@ -1223,6 +1233,46 @@ rte_cryptodev_asym_session_init(uint8_t dev_id,
return 0;
}
+struct rte_mempool *
+rte_cryptodev_sym_session_pool_create(const char *name, uint32_t nb_elts,
+ uint32_t elt_size, uint32_t cache_size, uint16_t user_data_size,
+ int socket_id)
+{
+ struct rte_mempool *mp;
+ struct rte_cryptodev_sym_session_pool_private_data *pool_priv;
+ uint32_t obj_sz;
+
+ obj_sz = rte_cryptodev_sym_get_header_session_size() + user_data_size;
+ if (obj_sz > elt_size)
+ CDEV_LOG_INFO("elt_size %u is expanded to %u\n", elt_size,
+ obj_sz);
+ else
+ obj_sz = elt_size;
+
+ mp = rte_mempool_create(name, nb_elts, obj_sz, cache_size,
+ (uint32_t)(sizeof(*pool_priv)),
+ NULL, NULL, NULL, NULL,
+ socket_id, 0);
+ if (mp == NULL) {
+ CDEV_LOG_ERR("%s(name=%s) failed, rte_errno=%d\n",
+ __func__, name, rte_errno);
+ return NULL;
+ }
+
+ pool_priv = rte_mempool_get_priv(mp);
+ if (!pool_priv) {
+ CDEV_LOG_ERR("%s(name=%s) failed to get private data\n",
+ __func__, name);
+ rte_mempool_free(mp);
+ return NULL;
+ }
+
+ pool_priv->nb_drivers = nb_drivers;
+ pool_priv->user_data_sz = user_data_size;
+
+ return mp;
+}
+
struct rte_cryptodev_sym_session *
rte_cryptodev_sym_session_create(struct rte_mempool *mp)
{
diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
index f9e7507da..265f02cbe 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -968,6 +968,37 @@ struct rte_cryptodev_asym_session {
};
/**
+ * Create a symmetric session mempool.
+ *
+ * @param name
+ * The unique mempool name.
+ * @param nb_elts
+ * The number of elements in the mempool.
+ * @param elt_size
+ * The size of the element. This value will be ignored if it is smaller than
+ * the minimum session header size required for the system. For the user who
+ * want to use the same mempool for sym session and session private data it
+ * can be the maximum value of all existing devices' private data and session
+ * header sizes.
+ * @param cache_size
+ * The number of per-lcore cache elements
+ * @param priv_size
+ * The private data size of each session.
+ * @param socket_id
+ * The *socket_id* argument is the socket identifier in the case of
+ * NUMA. The value can be *SOCKET_ID_ANY* if there is no NUMA
+ * constraint for the reserved zone.
+ *
+ * @return
+ * - On success return size of the session
+ * - On failure returns 0
+ */
+struct rte_mempool *
+rte_cryptodev_sym_session_pool_create(const char *name, uint32_t nb_elts,
+ uint32_t elt_size, uint32_t cache_size, uint16_t priv_size,
+ int socket_id);
+
+/**
* Create symmetric crypto session header (generic with no private data)
*
* @param mempool Symmetric session mempool to allocate session
diff --git a/lib/librte_cryptodev/rte_cryptodev_version.map b/lib/librte_cryptodev/rte_cryptodev_version.map
index a695b61dc..5b6b679f5 100644
--- a/lib/librte_cryptodev/rte_cryptodev_version.map
+++ b/lib/librte_cryptodev/rte_cryptodev_version.map
@@ -88,6 +88,13 @@ DPDK_18.05 {
} DPDK_17.11;
+DPDK_19.02 {
+ global:
+
+ rte_cryptodev_sym_session_pool_create;
+
+} DPDK_18.05;
+
EXPERIMENTAL {
global:
--
2.13.6
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v4 01/12] cryptodev: change queue pair configure structure
@ 2019-01-09 22:55 3% ` Fan Zhang
2019-01-10 9:47 3% ` De Lara Guarch, Pablo
2019-01-09 22:55 3% ` [dpdk-dev] [PATCH v4 02/12] cryptodev: add sym session mempool create Fan Zhang
` (3 subsequent siblings)
4 siblings, 1 reply; 200+ results
From: Fan Zhang @ 2019-01-09 22:55 UTC (permalink / raw)
To: dev; +Cc: akhil.goyal, pablo.de.lara.guarch, fiona.trahe
This patch changes the cryptodev queue pair configure structure
to enable two mempool passed into cryptodev PMD simutaneously.
Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
Acked-by: Fiona Trahe <fiona.trahe@@intel.com>
---
app/test-crypto-perf/main.c | 6 ++--
doc/guides/prog_guide/cryptodev_lib.rst | 12 ++++++-
doc/guides/rel_notes/release_19_02.rst | 7 ++++
drivers/crypto/aesni_gcm/aesni_gcm_pmd.c | 7 ++--
drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c | 5 +--
drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h | 2 ++
drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 7 ++--
drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c | 5 +--
drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h | 2 ++
drivers/crypto/armv8/rte_armv8_pmd.c | 7 ++--
drivers/crypto/armv8/rte_armv8_pmd_ops.c | 5 +--
drivers/crypto/armv8/rte_armv8_pmd_private.h | 2 ++
drivers/crypto/caam_jr/caam_jr.c | 3 +-
drivers/crypto/ccp/ccp_pmd_ops.c | 5 +--
drivers/crypto/ccp/ccp_pmd_private.h | 2 ++
drivers/crypto/ccp/rte_ccp_pmd.c | 9 +++++-
drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c | 3 +-
drivers/crypto/dpaa_sec/dpaa_sec.c | 3 +-
drivers/crypto/kasumi/rte_kasumi_pmd.c | 7 ++--
drivers/crypto/kasumi/rte_kasumi_pmd_ops.c | 5 +--
drivers/crypto/kasumi/rte_kasumi_pmd_private.h | 2 ++
drivers/crypto/mvsam/rte_mrvl_pmd_ops.c | 5 +--
drivers/crypto/mvsam/rte_mrvl_pmd_private.h | 3 ++
drivers/crypto/null/null_crypto_pmd.c | 5 +--
drivers/crypto/null/null_crypto_pmd_ops.c | 5 +--
drivers/crypto/null/null_crypto_pmd_private.h | 2 ++
drivers/crypto/octeontx/otx_cryptodev_ops.c | 3 +-
drivers/crypto/openssl/rte_openssl_pmd.c | 7 ++--
drivers/crypto/openssl/rte_openssl_pmd_ops.c | 5 +--
drivers/crypto/openssl/rte_openssl_pmd_private.h | 2 ++
drivers/crypto/qat/qat_sym_pmd.c | 2 +-
drivers/crypto/scheduler/scheduler_pmd_ops.c | 5 ++-
drivers/crypto/snow3g/rte_snow3g_pmd.c | 7 ++--
drivers/crypto/snow3g/rte_snow3g_pmd_ops.c | 5 +--
drivers/crypto/snow3g/rte_snow3g_pmd_private.h | 2 ++
drivers/crypto/virtio/virtio_cryptodev.c | 6 ++--
drivers/crypto/zuc/rte_zuc_pmd.c | 7 ++--
drivers/crypto/zuc/rte_zuc_pmd_ops.c | 5 +--
drivers/crypto/zuc/rte_zuc_pmd_private.h | 2 ++
drivers/net/softnic/rte_eth_softnic_cryptodev.c | 2 +-
examples/fips_validation/main.c | 4 +--
examples/ip_pipeline/cryptodev.c | 2 +-
examples/ipsec-secgw/ipsec-secgw.c | 7 ++--
examples/l2fwd-crypto/main.c | 4 ++-
examples/vhost_crypto/main.c | 9 ++++--
lib/librte_cryptodev/Makefile | 4 +--
lib/librte_cryptodev/rte_cryptodev.c | 16 ++++++++--
lib/librte_cryptodev/rte_cryptodev.h | 7 ++--
lib/librte_cryptodev/rte_cryptodev_pmd.h | 3 +-
test/test/test_cryptodev.c | 37 +++++++++-------------
test/test/test_cryptodev_asym.c | 8 ++---
test/test/test_event_crypto_adapter.c | 5 +--
52 files changed, 182 insertions(+), 110 deletions(-)
diff --git a/app/test-crypto-perf/main.c b/app/test-crypto-perf/main.c
index 953e058c9..38a2e429f 100644
--- a/app/test-crypto-perf/main.c
+++ b/app/test-crypto-perf/main.c
@@ -218,6 +218,9 @@ cperf_initialize_cryptodev(struct cperf_options *opts, uint8_t *enabled_cdevs,
session_pool_socket[socket_id] = sess_mp;
}
+ qp_conf.mp_session = session_pool_socket[socket_id];
+ qp_conf.mp_session_private = session_pool_socket[socket_id];
+
ret = rte_cryptodev_configure(cdev_id, &conf);
if (ret < 0) {
printf("Failed to configure cryptodev %u", cdev_id);
@@ -226,8 +229,7 @@ cperf_initialize_cryptodev(struct cperf_options *opts, uint8_t *enabled_cdevs,
for (j = 0; j < opts->nb_qps; j++) {
ret = rte_cryptodev_queue_pair_setup(cdev_id, j,
- &qp_conf, socket_id,
- session_pool_socket[socket_id]);
+ &qp_conf, socket_id);
if (ret < 0) {
printf("Failed to setup queue pair %u on "
"cryptodev %u", j, cdev_id);
diff --git a/doc/guides/prog_guide/cryptodev_lib.rst b/doc/guides/prog_guide/cryptodev_lib.rst
index 8ee33c875..050a58dc4 100644
--- a/doc/guides/prog_guide/cryptodev_lib.rst
+++ b/doc/guides/prog_guide/cryptodev_lib.rst
@@ -121,11 +121,21 @@ Each queue pairs resources may be allocated on a specified socket.
const struct rte_cryptodev_qp_conf *qp_conf,
int socket_id)
- struct rte_cryptodev_qp_conf {
+ struct rte_cryptodev_qp_conf {
uint32_t nb_descriptors; /**< Number of descriptors per queue pair */
+ struct rte_mempool *mp_session;
+ /**< The mempool for creating session in sessionless mode */
+ struct rte_mempool *mp_session_private;
+ /**< The mempool for creating sess private data in sessionless mode */
};
+The fields ``mp_session`` and ``mp_session_private`` are used for creating
+temporary session to process the crypto operations in the session-less mode.
+They can be the same other different mempools. Please note not all Cryptodev
+PMDs supports session-less mode.
+
+
Logical Cores, Memory and Queues Pair Relationships
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/doc/guides/rel_notes/release_19_02.rst b/doc/guides/rel_notes/release_19_02.rst
index e3b2055d0..75128f8f2 100644
--- a/doc/guides/rel_notes/release_19_02.rst
+++ b/doc/guides/rel_notes/release_19_02.rst
@@ -164,6 +164,9 @@ API Changes
``rte_pdump_init()`` and enum ``rte_pdump_socktype`` were deprecated
since 18.05 and are removed in this release.
+* cryptodev: as shown in the the 18.11 deprecation notice, the last parameter
+ of ``rte_cryptodev_queue_pair_setup()``, ``session_pool``, is removed.
+
ABI Changes
-----------
@@ -183,6 +186,10 @@ ABI Changes
* mbuf: The format of the sched field of ``rte_mbuf`` has been changed
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
+ mempool and symmetric session private data mempool.
+
Shared Library Versions
-----------------------
diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
index ebdf7c35a..abc7a6d5f 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
@@ -151,7 +151,8 @@ aesni_gcm_get_session(struct aesni_gcm_qp *qp, struct rte_crypto_op *op)
if (rte_mempool_get(qp->sess_mp, (void **)&_sess))
return NULL;
- if (rte_mempool_get(qp->sess_mp, (void **)&_sess_private_data))
+ if (rte_mempool_get(qp->sess_mp_priv,
+ (void **)&_sess_private_data))
return NULL;
sess = (struct aesni_gcm_session *)_sess_private_data;
@@ -159,7 +160,7 @@ aesni_gcm_get_session(struct aesni_gcm_qp *qp, struct rte_crypto_op *op)
if (unlikely(aesni_gcm_set_session_parameters(qp->ops,
sess, sym_op->xform) != 0)) {
rte_mempool_put(qp->sess_mp, _sess);
- rte_mempool_put(qp->sess_mp, _sess_private_data);
+ rte_mempool_put(qp->sess_mp_priv, _sess_private_data);
sess = NULL;
}
sym_op->session = (struct rte_cryptodev_sym_session *)_sess;
@@ -419,7 +420,7 @@ handle_completed_gcm_crypto_op(struct aesni_gcm_qp *qp,
memset(sess, 0, sizeof(struct aesni_gcm_session));
memset(op->sym->session, 0,
rte_cryptodev_sym_get_header_session_size());
- rte_mempool_put(qp->sess_mp, sess);
+ rte_mempool_put(qp->sess_mp_priv, sess);
rte_mempool_put(qp->sess_mp, op->sym->session);
op->sym->session = NULL;
}
diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c b/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
index cd15245bd..bf69dde54 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
@@ -206,7 +206,7 @@ aesni_gcm_pmd_qp_create_processed_pkts_ring(struct aesni_gcm_qp *qp,
static int
aesni_gcm_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool)
+ int socket_id)
{
struct aesni_gcm_qp *qp = NULL;
struct aesni_gcm_private *internals = dev->data->dev_private;
@@ -234,7 +234,8 @@ aesni_gcm_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
if (qp->processed_pkts == NULL)
goto qp_setup_cleanup;
- qp->sess_mp = session_pool;
+ qp->sess_mp = qp_conf->mp_session;
+ qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->qp_stats, 0, sizeof(qp->qp_stats));
diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h b/drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h
index 92b041354..903e7503d 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h
@@ -48,6 +48,8 @@ struct aesni_gcm_qp {
/**< Queue pair statistics */
struct rte_mempool *sess_mp;
/**< Session Mempool */
+ struct rte_mempool *sess_mp_priv;
+ /**< Session Private Data Mempool */
uint16_t id;
/**< Queue Pair Identifier */
char name[RTE_CRYPTODEV_NAME_MAX_LEN];
diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
index 83250e32c..b0f5c4d67 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
@@ -668,7 +668,8 @@ get_session(struct aesni_mb_qp *qp, struct rte_crypto_op *op)
if (rte_mempool_get(qp->sess_mp, (void **)&_sess))
return NULL;
- if (rte_mempool_get(qp->sess_mp, (void **)&_sess_private_data))
+ if (rte_mempool_get(qp->sess_mp_priv,
+ (void **)&_sess_private_data))
return NULL;
sess = (struct aesni_mb_session *)_sess_private_data;
@@ -676,7 +677,7 @@ get_session(struct aesni_mb_qp *qp, struct rte_crypto_op *op)
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, _sess_private_data);
+ rte_mempool_put(qp->sess_mp_priv, _sess_private_data);
sess = NULL;
}
op->sym->session = (struct rte_cryptodev_sym_session *)_sess;
@@ -951,7 +952,7 @@ post_process_mb_job(struct aesni_mb_qp *qp, JOB_AES_HMAC *job)
memset(sess, 0, sizeof(struct aesni_mb_session));
memset(op->sym->session, 0,
rte_cryptodev_sym_get_header_session_size());
- rte_mempool_put(qp->sess_mp, sess);
+ rte_mempool_put(qp->sess_mp_priv, sess);
rte_mempool_put(qp->sess_mp, op->sym->session);
op->sym->session = NULL;
}
diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c
index f3eff2685..af3021616 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c
@@ -566,7 +566,7 @@ aesni_mb_pmd_qp_create_processed_ops_ring(struct aesni_mb_qp *qp,
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 rte_mempool *session_pool)
+ int socket_id)
{
struct aesni_mb_qp *qp = NULL;
struct aesni_mb_private *internals = dev->data->dev_private;
@@ -604,7 +604,8 @@ aesni_mb_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
goto qp_setup_cleanup;
}
- qp->sess_mp = session_pool;
+ qp->sess_mp = qp_conf->mp_session;
+ qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->stats, 0, sizeof(qp->stats));
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 d8021cdaa..923403336 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h
@@ -131,6 +131,8 @@ struct aesni_mb_qp {
/**< Ring for placing operations ready for processing */
struct rte_mempool *sess_mp;
/**< Session Mempool */
+ struct rte_mempool *sess_mp_priv;
+ /**< Session Private Data Mempool */
struct rte_cryptodev_stats stats;
/**< Queue pair statistics */
uint8_t digest_idx;
diff --git a/drivers/crypto/armv8/rte_armv8_pmd.c b/drivers/crypto/armv8/rte_armv8_pmd.c
index 9d15fee53..3b2d7fb2f 100644
--- a/drivers/crypto/armv8/rte_armv8_pmd.c
+++ b/drivers/crypto/armv8/rte_armv8_pmd.c
@@ -514,7 +514,8 @@ get_session(struct armv8_crypto_qp *qp, struct rte_crypto_op *op)
if (rte_mempool_get(qp->sess_mp, (void **)&_sess))
return NULL;
- if (rte_mempool_get(qp->sess_mp, (void **)&_sess_private_data))
+ if (rte_mempool_get(qp->sess_mp_priv,
+ (void **)&_sess_private_data))
return NULL;
sess = (struct armv8_crypto_session *)_sess_private_data;
@@ -522,7 +523,7 @@ get_session(struct armv8_crypto_qp *qp, struct rte_crypto_op *op)
if (unlikely(armv8_crypto_set_session_parameters(sess,
op->sym->xform) != 0)) {
rte_mempool_put(qp->sess_mp, _sess);
- rte_mempool_put(qp->sess_mp, _sess_private_data);
+ rte_mempool_put(qp->sess_mp_priv, _sess_private_data);
sess = NULL;
}
op->sym->session = (struct rte_cryptodev_sym_session *)_sess;
@@ -656,7 +657,7 @@ process_op(struct armv8_crypto_qp *qp, struct rte_crypto_op *op,
memset(op->sym->session, 0,
rte_cryptodev_sym_get_header_session_size());
rte_mempool_put(qp->sess_mp, sess);
- rte_mempool_put(qp->sess_mp, op->sym->session);
+ rte_mempool_put(qp->sess_mp_priv, op->sym->session);
op->sym->session = NULL;
}
diff --git a/drivers/crypto/armv8/rte_armv8_pmd_ops.c b/drivers/crypto/armv8/rte_armv8_pmd_ops.c
index ae03117ea..a4fee83a8 100644
--- a/drivers/crypto/armv8/rte_armv8_pmd_ops.c
+++ b/drivers/crypto/armv8/rte_armv8_pmd_ops.c
@@ -220,7 +220,7 @@ armv8_crypto_pmd_qp_create_processed_ops_ring(struct armv8_crypto_qp *qp,
static int
armv8_crypto_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool)
+ int socket_id)
{
struct armv8_crypto_qp *qp = NULL;
@@ -245,7 +245,8 @@ armv8_crypto_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
if (qp->processed_ops == NULL)
goto qp_setup_cleanup;
- qp->sess_mp = session_pool;
+ qp->sess_mp = qp_conf->mp_session;
+ qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->stats, 0, sizeof(qp->stats));
diff --git a/drivers/crypto/armv8/rte_armv8_pmd_private.h b/drivers/crypto/armv8/rte_armv8_pmd_private.h
index 7feb021db..0afd9c7c5 100644
--- a/drivers/crypto/armv8/rte_armv8_pmd_private.h
+++ b/drivers/crypto/armv8/rte_armv8_pmd_private.h
@@ -116,6 +116,8 @@ struct armv8_crypto_qp {
/**< Ring for placing process packets */
struct rte_mempool *sess_mp;
/**< Session Mempool */
+ struct rte_mempool *sess_mp_priv;
+ /**< Session Private Data Mempool */
struct rte_cryptodev_stats stats;
/**< Queue pair statistics */
char name[RTE_CRYPTODEV_NAME_MAX_LEN];
diff --git a/drivers/crypto/caam_jr/caam_jr.c b/drivers/crypto/caam_jr/caam_jr.c
index f505adf6b..45b281331 100644
--- a/drivers/crypto/caam_jr/caam_jr.c
+++ b/drivers/crypto/caam_jr/caam_jr.c
@@ -1540,8 +1540,7 @@ static int
caam_jr_queue_pair_setup(
struct rte_cryptodev *dev, uint16_t qp_id,
__rte_unused const struct rte_cryptodev_qp_conf *qp_conf,
- __rte_unused int socket_id,
- __rte_unused struct rte_mempool *session_pool)
+ __rte_unused int socket_id)
{
struct sec_job_ring_t *internals;
struct caam_jr_qp *qp = NULL;
diff --git a/drivers/crypto/ccp/ccp_pmd_ops.c b/drivers/crypto/ccp/ccp_pmd_ops.c
index 6984913f1..d5041f0ec 100644
--- a/drivers/crypto/ccp/ccp_pmd_ops.c
+++ b/drivers/crypto/ccp/ccp_pmd_ops.c
@@ -685,7 +685,7 @@ ccp_pmd_qp_create_batch_info_ring(struct ccp_qp *qp,
static int
ccp_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool)
+ int socket_id)
{
struct ccp_private *internals = dev->data->dev_private;
struct ccp_qp *qp;
@@ -726,7 +726,8 @@ ccp_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
goto qp_setup_cleanup;
}
- qp->sess_mp = session_pool;
+ qp->sess_mp = qp_conf->mp_session;
+ qp->sess_mp_priv = qp_conf->mp_session_private;
/* mempool for batch info */
qp->batch_mp = rte_mempool_create(
diff --git a/drivers/crypto/ccp/ccp_pmd_private.h b/drivers/crypto/ccp/ccp_pmd_private.h
index 79752f687..7f2979e89 100644
--- a/drivers/crypto/ccp/ccp_pmd_private.h
+++ b/drivers/crypto/ccp/ccp_pmd_private.h
@@ -76,6 +76,8 @@ struct ccp_qp {
/**< Ring for placing process packets */
struct rte_mempool *sess_mp;
/**< Session Mempool */
+ struct rte_mempool *sess_mp_priv;
+ /**< Session Private Data Mempool */
struct rte_mempool *batch_mp;
/**< Session Mempool for batch info */
struct rte_cryptodev_stats qp_stats;
diff --git a/drivers/crypto/ccp/rte_ccp_pmd.c b/drivers/crypto/ccp/rte_ccp_pmd.c
index 92d8a9559..b4bb5528f 100644
--- a/drivers/crypto/ccp/rte_ccp_pmd.c
+++ b/drivers/crypto/ccp/rte_ccp_pmd.c
@@ -179,7 +179,7 @@ get_ccp_session(struct ccp_qp *qp, struct rte_crypto_op *op)
if (unlikely(ccp_set_session_parameters(sess, op->sym->xform,
internals) != 0)) {
rte_mempool_put(qp->sess_mp, _sess);
- rte_mempool_put(qp->sess_mp, _sess_private_data);
+ rte_mempool_put(qp->sess_mp_priv, _sess_private_data);
sess = NULL;
}
op->sym->session = (struct rte_cryptodev_sym_session *)_sess;
@@ -241,6 +241,13 @@ ccp_pmd_dequeue_burst(void *queue_pair, struct rte_crypto_op **ops,
for (i = 0; i < nb_dequeued; i++)
if (unlikely(ops[i]->sess_type ==
RTE_CRYPTO_OP_SESSIONLESS)) {
+ struct ccp_session *sess = (struct ccp_session *)
+ get_sym_session_private_data(
+ ops[i]->sym->session,
+ ccp_cryptodev_driver_id);
+
+ rte_mempool_put(qp->sess_mp_priv,
+ sess);
rte_mempool_put(qp->sess_mp,
ops[i]->sym->session);
ops[i]->sym->session = NULL;
diff --git a/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c b/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
index 6095c6021..82220ac4f 100644
--- a/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
+++ b/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
@@ -1518,8 +1518,7 @@ dpaa2_sec_queue_pair_release(struct rte_cryptodev *dev, uint16_t queue_pair_id)
static int
dpaa2_sec_queue_pair_setup(struct rte_cryptodev *dev, uint16_t qp_id,
__rte_unused const struct rte_cryptodev_qp_conf *qp_conf,
- __rte_unused int socket_id,
- __rte_unused struct rte_mempool *session_pool)
+ __rte_unused int socket_id)
{
struct dpaa2_sec_dev_private *priv = dev->data->dev_private;
struct dpaa2_sec_qp *qp;
diff --git a/drivers/crypto/dpaa_sec/dpaa_sec.c b/drivers/crypto/dpaa_sec/dpaa_sec.c
index d83e74541..c95e43b7f 100644
--- a/drivers/crypto/dpaa_sec/dpaa_sec.c
+++ b/drivers/crypto/dpaa_sec/dpaa_sec.c
@@ -1661,8 +1661,7 @@ dpaa_sec_queue_pair_release(struct rte_cryptodev *dev,
static int
dpaa_sec_queue_pair_setup(struct rte_cryptodev *dev, uint16_t qp_id,
__rte_unused const struct rte_cryptodev_qp_conf *qp_conf,
- __rte_unused int socket_id,
- __rte_unused struct rte_mempool *session_pool)
+ __rte_unused int socket_id)
{
struct dpaa_sec_dev_private *internals;
struct dpaa_sec_qp *qp = NULL;
diff --git a/drivers/crypto/kasumi/rte_kasumi_pmd.c b/drivers/crypto/kasumi/rte_kasumi_pmd.c
index 239a1cf44..6df645a23 100644
--- a/drivers/crypto/kasumi/rte_kasumi_pmd.c
+++ b/drivers/crypto/kasumi/rte_kasumi_pmd.c
@@ -145,7 +145,8 @@ kasumi_get_session(struct kasumi_qp *qp, struct rte_crypto_op *op)
if (rte_mempool_get(qp->sess_mp, (void **)&_sess))
return NULL;
- if (rte_mempool_get(qp->sess_mp, (void **)&_sess_private_data))
+ if (rte_mempool_get(qp->sess_mp_priv,
+ (void **)&_sess_private_data))
return NULL;
sess = (struct kasumi_session *)_sess_private_data;
@@ -153,7 +154,7 @@ kasumi_get_session(struct kasumi_qp *qp, struct rte_crypto_op *op)
if (unlikely(kasumi_set_session_parameters(sess,
op->sym->xform) != 0)) {
rte_mempool_put(qp->sess_mp, _sess);
- rte_mempool_put(qp->sess_mp, _sess_private_data);
+ rte_mempool_put(qp->sess_mp_priv, _sess_private_data);
sess = NULL;
}
op->sym->session = (struct rte_cryptodev_sym_session *)_sess;
@@ -325,7 +326,7 @@ process_ops(struct rte_crypto_op **ops, struct kasumi_session *session,
memset(session, 0, sizeof(struct kasumi_session));
memset(ops[i]->sym->session, 0,
rte_cryptodev_sym_get_header_session_size());
- rte_mempool_put(qp->sess_mp, session);
+ rte_mempool_put(qp->sess_mp_priv, session);
rte_mempool_put(qp->sess_mp, ops[i]->sym->session);
ops[i]->sym->session = NULL;
}
diff --git a/drivers/crypto/kasumi/rte_kasumi_pmd_ops.c b/drivers/crypto/kasumi/rte_kasumi_pmd_ops.c
index 9e4bf1b52..a4982f091 100644
--- a/drivers/crypto/kasumi/rte_kasumi_pmd_ops.c
+++ b/drivers/crypto/kasumi/rte_kasumi_pmd_ops.c
@@ -192,7 +192,7 @@ kasumi_pmd_qp_create_processed_ops_ring(struct kasumi_qp *qp,
static int
kasumi_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool)
+ int socket_id)
{
struct kasumi_qp *qp = NULL;
@@ -217,7 +217,8 @@ kasumi_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
if (qp->processed_ops == NULL)
goto qp_setup_cleanup;
- qp->sess_mp = session_pool;
+ qp->sess_mp = qp_conf->mp_session;
+ qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->qp_stats, 0, sizeof(qp->qp_stats));
diff --git a/drivers/crypto/kasumi/rte_kasumi_pmd_private.h b/drivers/crypto/kasumi/rte_kasumi_pmd_private.h
index 488777ca8..76f746c03 100644
--- a/drivers/crypto/kasumi/rte_kasumi_pmd_private.h
+++ b/drivers/crypto/kasumi/rte_kasumi_pmd_private.h
@@ -36,6 +36,8 @@ struct kasumi_qp {
/**< Ring for placing processed ops */
struct rte_mempool *sess_mp;
/**< Session Mempool */
+ struct rte_mempool *sess_mp_priv;
+ /**< Session Private Data Mempool */
struct rte_cryptodev_stats qp_stats;
/**< Queue pair statistics */
uint8_t temp_digest[KASUMI_DIGEST_LENGTH];
diff --git a/drivers/crypto/mvsam/rte_mrvl_pmd_ops.c b/drivers/crypto/mvsam/rte_mrvl_pmd_ops.c
index 9956f051f..ef520356f 100644
--- a/drivers/crypto/mvsam/rte_mrvl_pmd_ops.c
+++ b/drivers/crypto/mvsam/rte_mrvl_pmd_ops.c
@@ -633,7 +633,7 @@ mrvl_crypto_pmd_close(struct rte_cryptodev *dev)
static int
mrvl_crypto_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool)
+ int socket_id)
{
struct mrvl_crypto_qp *qp = NULL;
char match[RTE_CRYPTODEV_NAME_MAX_LEN];
@@ -690,7 +690,8 @@ mrvl_crypto_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
if (sam_cio_init(&qp->cio_params, &qp->cio) < 0)
break;
- qp->sess_mp = session_pool;
+ qp->sess_mp = qp_conf->mp_session;
+ qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->stats, 0, sizeof(qp->stats));
dev->data->queue_pairs[qp_id] = qp;
diff --git a/drivers/crypto/mvsam/rte_mrvl_pmd_private.h b/drivers/crypto/mvsam/rte_mrvl_pmd_private.h
index 6f8cf5624..deb80c55d 100644
--- a/drivers/crypto/mvsam/rte_mrvl_pmd_private.h
+++ b/drivers/crypto/mvsam/rte_mrvl_pmd_private.h
@@ -51,6 +51,9 @@ struct mrvl_crypto_qp {
/** Session Mempool. */
struct rte_mempool *sess_mp;
+ /** Session Private Data Mempool. */
+ struct rte_mempool *sess_mp_priv;
+
/** Queue pair statistics. */
struct rte_cryptodev_stats stats;
diff --git a/drivers/crypto/null/null_crypto_pmd.c b/drivers/crypto/null/null_crypto_pmd.c
index 6e29a21a6..d5e3064f2 100644
--- a/drivers/crypto/null/null_crypto_pmd.c
+++ b/drivers/crypto/null/null_crypto_pmd.c
@@ -87,7 +87,8 @@ get_session(struct null_crypto_qp *qp, struct rte_crypto_op *op)
if (rte_mempool_get(qp->sess_mp, (void **)&_sess))
return NULL;
- if (rte_mempool_get(qp->sess_mp, (void **)&_sess_private_data))
+ if (rte_mempool_get(qp->sess_mp_priv,
+ (void **)&_sess_private_data))
return NULL;
sess = (struct null_crypto_session *)_sess_private_data;
@@ -95,7 +96,7 @@ get_session(struct null_crypto_qp *qp, struct rte_crypto_op *op)
if (unlikely(null_crypto_set_session_parameters(sess,
sym_op->xform) != 0)) {
rte_mempool_put(qp->sess_mp, _sess);
- rte_mempool_put(qp->sess_mp, _sess_private_data);
+ rte_mempool_put(qp->sess_mp_priv, _sess_private_data);
sess = NULL;
}
sym_op->session = (struct rte_cryptodev_sym_session *)_sess;
diff --git a/drivers/crypto/null/null_crypto_pmd_ops.c b/drivers/crypto/null/null_crypto_pmd_ops.c
index 2bdcd019e..941d62bed 100644
--- a/drivers/crypto/null/null_crypto_pmd_ops.c
+++ b/drivers/crypto/null/null_crypto_pmd_ops.c
@@ -184,7 +184,7 @@ null_crypto_pmd_qp_create_processed_pkts_ring(struct null_crypto_qp *qp,
static int
null_crypto_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool)
+ int socket_id)
{
struct null_crypto_private *internals = dev->data->dev_private;
struct null_crypto_qp *qp;
@@ -228,7 +228,8 @@ null_crypto_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
goto qp_setup_cleanup;
}
- qp->sess_mp = session_pool;
+ qp->sess_mp = qp_conf->mp_session;
+ qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->qp_stats, 0, sizeof(qp->qp_stats));
diff --git a/drivers/crypto/null/null_crypto_pmd_private.h b/drivers/crypto/null/null_crypto_pmd_private.h
index d5905afd8..d7bfd9cc8 100644
--- a/drivers/crypto/null/null_crypto_pmd_private.h
+++ b/drivers/crypto/null/null_crypto_pmd_private.h
@@ -31,6 +31,8 @@ struct null_crypto_qp {
/**< Ring for placing process packets */
struct rte_mempool *sess_mp;
/**< Session Mempool */
+ struct rte_mempool *sess_mp_priv;
+ /**< Session Mempool */
struct rte_cryptodev_stats qp_stats;
/**< Queue pair statistics */
} __rte_cache_aligned;
diff --git a/drivers/crypto/octeontx/otx_cryptodev_ops.c b/drivers/crypto/octeontx/otx_cryptodev_ops.c
index 90d0c14b8..6a0cf83f4 100644
--- a/drivers/crypto/octeontx/otx_cryptodev_ops.c
+++ b/drivers/crypto/octeontx/otx_cryptodev_ops.c
@@ -186,8 +186,7 @@ static int
otx_cpt_que_pair_setup(struct rte_cryptodev *dev,
uint16_t que_pair_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id __rte_unused,
- struct rte_mempool *session_pool __rte_unused)
+ int socket_id __rte_unused)
{
void *cptvf = dev->data->dev_private;
struct cpt_instance *instance = NULL;
diff --git a/drivers/crypto/openssl/rte_openssl_pmd.c b/drivers/crypto/openssl/rte_openssl_pmd.c
index a0ccacb1e..a193af642 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd.c
@@ -768,7 +768,8 @@ get_session(struct openssl_qp *qp, struct rte_crypto_op *op)
if (rte_mempool_get(qp->sess_mp, (void **)&_sess))
return NULL;
- if (rte_mempool_get(qp->sess_mp, (void **)&_sess_private_data))
+ if (rte_mempool_get(qp->sess_mp_priv,
+ (void **)&_sess_private_data))
return NULL;
sess = (struct openssl_session *)_sess_private_data;
@@ -776,7 +777,7 @@ get_session(struct openssl_qp *qp, struct rte_crypto_op *op)
if (unlikely(openssl_set_session_parameters(sess,
op->sym->xform) != 0)) {
rte_mempool_put(qp->sess_mp, _sess);
- rte_mempool_put(qp->sess_mp, _sess_private_data);
+ rte_mempool_put(qp->sess_mp_priv, _sess_private_data);
sess = NULL;
}
op->sym->session = (struct rte_cryptodev_sym_session *)_sess;
@@ -2020,7 +2021,7 @@ process_op(struct openssl_qp *qp, struct rte_crypto_op *op,
memset(sess, 0, sizeof(struct openssl_session));
memset(op->sym->session, 0,
rte_cryptodev_sym_get_header_session_size());
- rte_mempool_put(qp->sess_mp, sess);
+ rte_mempool_put(qp->sess_mp_priv, sess);
rte_mempool_put(qp->sess_mp, op->sym->session);
op->sym->session = NULL;
}
diff --git a/drivers/crypto/openssl/rte_openssl_pmd_ops.c b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
index d382476a6..40217cf0d 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd_ops.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
@@ -715,7 +715,7 @@ openssl_pmd_qp_create_processed_ops_ring(struct openssl_qp *qp,
static int
openssl_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool)
+ int socket_id)
{
struct openssl_qp *qp = NULL;
@@ -740,7 +740,8 @@ openssl_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
if (qp->processed_ops == NULL)
goto qp_setup_cleanup;
- qp->sess_mp = session_pool;
+ qp->sess_mp = qp_conf->mp_session;
+ qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->stats, 0, sizeof(qp->stats));
diff --git a/drivers/crypto/openssl/rte_openssl_pmd_private.h b/drivers/crypto/openssl/rte_openssl_pmd_private.h
index a8f2c8482..43ac3813d 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd_private.h
+++ b/drivers/crypto/openssl/rte_openssl_pmd_private.h
@@ -64,6 +64,8 @@ struct openssl_qp {
/**< Ring for placing process packets */
struct rte_mempool *sess_mp;
/**< Session Mempool */
+ struct rte_mempool *sess_mp_priv;
+ /**< Session Private Data Mempool */
struct rte_cryptodev_stats stats;
/**< Queue pair statistics */
uint8_t temp_digest[DIGEST_LENGTH_MAX];
diff --git a/drivers/crypto/qat/qat_sym_pmd.c b/drivers/crypto/qat/qat_sym_pmd.c
index c3f700406..31ccab32e 100644
--- a/drivers/crypto/qat/qat_sym_pmd.c
+++ b/drivers/crypto/qat/qat_sym_pmd.c
@@ -127,7 +127,7 @@ static int qat_sym_qp_release(struct rte_cryptodev *dev, uint16_t queue_pair_id)
static int qat_sym_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool __rte_unused)
+ int socket_id)
{
struct qat_qp *qp;
int ret = 0;
diff --git a/drivers/crypto/scheduler/scheduler_pmd_ops.c b/drivers/crypto/scheduler/scheduler_pmd_ops.c
index 939105aa8..cf70218b7 100644
--- a/drivers/crypto/scheduler/scheduler_pmd_ops.c
+++ b/drivers/crypto/scheduler/scheduler_pmd_ops.c
@@ -390,8 +390,7 @@ scheduler_pmd_qp_release(struct rte_cryptodev *dev, uint16_t qp_id)
/** Setup a queue pair */
static int
scheduler_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
- const struct rte_cryptodev_qp_conf *qp_conf, int socket_id,
- struct rte_mempool *session_pool)
+ const struct rte_cryptodev_qp_conf *qp_conf, int socket_id)
{
struct scheduler_ctx *sched_ctx = dev->data->dev_private;
struct scheduler_qp_ctx *qp_ctx;
@@ -419,7 +418,7 @@ scheduler_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
* must be big enough for all the drivers used.
*/
ret = rte_cryptodev_queue_pair_setup(slave_id, qp_id,
- qp_conf, socket_id, session_pool);
+ qp_conf, socket_id);
if (ret < 0)
return ret;
}
diff --git a/drivers/crypto/snow3g/rte_snow3g_pmd.c b/drivers/crypto/snow3g/rte_snow3g_pmd.c
index a17536b77..7d131f780 100644
--- a/drivers/crypto/snow3g/rte_snow3g_pmd.c
+++ b/drivers/crypto/snow3g/rte_snow3g_pmd.c
@@ -147,7 +147,8 @@ snow3g_get_session(struct snow3g_qp *qp, struct rte_crypto_op *op)
if (rte_mempool_get(qp->sess_mp, (void **)&_sess))
return NULL;
- if (rte_mempool_get(qp->sess_mp, (void **)&_sess_private_data))
+ if (rte_mempool_get(qp->sess_mp_priv,
+ (void **)&_sess_private_data))
return NULL;
sess = (struct snow3g_session *)_sess_private_data;
@@ -155,7 +156,7 @@ snow3g_get_session(struct snow3g_qp *qp, struct rte_crypto_op *op)
if (unlikely(snow3g_set_session_parameters(sess,
op->sym->xform) != 0)) {
rte_mempool_put(qp->sess_mp, _sess);
- rte_mempool_put(qp->sess_mp, _sess_private_data);
+ rte_mempool_put(qp->sess_mp_priv, _sess_private_data);
sess = NULL;
}
op->sym->session = (struct rte_cryptodev_sym_session *)_sess;
@@ -340,7 +341,7 @@ process_ops(struct rte_crypto_op **ops, struct snow3g_session *session,
memset(session, 0, sizeof(struct snow3g_session));
memset(ops[i]->sym->session, 0,
rte_cryptodev_sym_get_header_session_size());
- rte_mempool_put(qp->sess_mp, session);
+ rte_mempool_put(qp->sess_mp_priv, session);
rte_mempool_put(qp->sess_mp, ops[i]->sym->session);
ops[i]->sym->session = NULL;
}
diff --git a/drivers/crypto/snow3g/rte_snow3g_pmd_ops.c b/drivers/crypto/snow3g/rte_snow3g_pmd_ops.c
index a367ee9a0..d2125233f 100644
--- a/drivers/crypto/snow3g/rte_snow3g_pmd_ops.c
+++ b/drivers/crypto/snow3g/rte_snow3g_pmd_ops.c
@@ -198,7 +198,7 @@ snow3g_pmd_qp_create_processed_ops_ring(struct snow3g_qp *qp,
static int
snow3g_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool)
+ int socket_id)
{
struct snow3g_qp *qp = NULL;
@@ -223,7 +223,8 @@ snow3g_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
if (qp->processed_ops == NULL)
goto qp_setup_cleanup;
- qp->sess_mp = session_pool;
+ qp->sess_mp = qp_conf->mp_session;
+ qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->qp_stats, 0, sizeof(qp->qp_stats));
diff --git a/drivers/crypto/snow3g/rte_snow3g_pmd_private.h b/drivers/crypto/snow3g/rte_snow3g_pmd_private.h
index b7807b621..df5c6092b 100644
--- a/drivers/crypto/snow3g/rte_snow3g_pmd_private.h
+++ b/drivers/crypto/snow3g/rte_snow3g_pmd_private.h
@@ -36,6 +36,8 @@ struct snow3g_qp {
/**< Ring for placing processed ops */
struct rte_mempool *sess_mp;
/**< Session Mempool */
+ struct rte_mempool *sess_mp_priv;
+ /**< Session Private Data Mempool */
struct rte_cryptodev_stats qp_stats;
/**< Queue pair statistics */
uint8_t temp_digest[SNOW3G_DIGEST_LENGTH];
diff --git a/drivers/crypto/virtio/virtio_cryptodev.c b/drivers/crypto/virtio/virtio_cryptodev.c
index 568b5a406..4bae3b865 100644
--- a/drivers/crypto/virtio/virtio_cryptodev.c
+++ b/drivers/crypto/virtio/virtio_cryptodev.c
@@ -36,8 +36,7 @@ static void virtio_crypto_dev_stats_reset(struct rte_cryptodev *dev);
static int virtio_crypto_qp_setup(struct rte_cryptodev *dev,
uint16_t queue_pair_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id,
- struct rte_mempool *session_pool);
+ int socket_id);
static int virtio_crypto_qp_release(struct rte_cryptodev *dev,
uint16_t queue_pair_id);
static void virtio_crypto_dev_free_mbufs(struct rte_cryptodev *dev);
@@ -585,8 +584,7 @@ virtio_crypto_dev_stats_reset(struct rte_cryptodev *dev)
static int
virtio_crypto_qp_setup(struct rte_cryptodev *dev, uint16_t queue_pair_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id,
- struct rte_mempool *session_pool __rte_unused)
+ int socket_id)
{
int ret;
struct virtqueue *vq;
diff --git a/drivers/crypto/zuc/rte_zuc_pmd.c b/drivers/crypto/zuc/rte_zuc_pmd.c
index 313f4590b..997c2092f 100644
--- a/drivers/crypto/zuc/rte_zuc_pmd.c
+++ b/drivers/crypto/zuc/rte_zuc_pmd.c
@@ -144,7 +144,8 @@ zuc_get_session(struct zuc_qp *qp, struct rte_crypto_op *op)
if (rte_mempool_get(qp->sess_mp, (void **)&_sess))
return NULL;
- if (rte_mempool_get(qp->sess_mp, (void **)&_sess_private_data))
+ if (rte_mempool_get(qp->sess_mp_priv,
+ (void **)&_sess_private_data))
return NULL;
sess = (struct zuc_session *)_sess_private_data;
@@ -152,7 +153,7 @@ zuc_get_session(struct zuc_qp *qp, struct rte_crypto_op *op)
if (unlikely(zuc_set_session_parameters(sess,
op->sym->xform) != 0)) {
rte_mempool_put(qp->sess_mp, _sess);
- rte_mempool_put(qp->sess_mp, _sess_private_data);
+ rte_mempool_put(qp->sess_mp_priv, _sess_private_data);
sess = NULL;
}
op->sym->session = (struct rte_cryptodev_sym_session *)_sess;
@@ -327,7 +328,7 @@ process_ops(struct rte_crypto_op **ops, enum zuc_operation op_type,
memset(sessions[i], 0, sizeof(struct zuc_session));
memset(ops[i]->sym->session, 0,
rte_cryptodev_sym_get_header_session_size());
- rte_mempool_put(qp->sess_mp, sessions[i]);
+ rte_mempool_put(qp->sess_mp_priv, sessions[i]);
rte_mempool_put(qp->sess_mp, ops[i]->sym->session);
ops[i]->sym->session = NULL;
}
diff --git a/drivers/crypto/zuc/rte_zuc_pmd_ops.c b/drivers/crypto/zuc/rte_zuc_pmd_ops.c
index 04d45e449..1b88947eb 100644
--- a/drivers/crypto/zuc/rte_zuc_pmd_ops.c
+++ b/drivers/crypto/zuc/rte_zuc_pmd_ops.c
@@ -198,7 +198,7 @@ zuc_pmd_qp_create_processed_ops_ring(struct zuc_qp *qp,
static int
zuc_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool)
+ int socket_id)
{
struct zuc_qp *qp = NULL;
@@ -223,7 +223,8 @@ zuc_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
if (qp->processed_ops == NULL)
goto qp_setup_cleanup;
- qp->sess_mp = session_pool;
+ qp->sess_mp = qp_conf->mp_session;
+ qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->qp_stats, 0, sizeof(qp->qp_stats));
diff --git a/drivers/crypto/zuc/rte_zuc_pmd_private.h b/drivers/crypto/zuc/rte_zuc_pmd_private.h
index 5e5906ddb..aa73c0016 100644
--- a/drivers/crypto/zuc/rte_zuc_pmd_private.h
+++ b/drivers/crypto/zuc/rte_zuc_pmd_private.h
@@ -36,6 +36,8 @@ struct zuc_qp {
/**< Ring for placing processed ops */
struct rte_mempool *sess_mp;
/**< Session Mempool */
+ struct rte_mempool *sess_mp_priv;
+ /**< Session Private Data Mempool */
struct rte_cryptodev_stats qp_stats;
/**< Queue pair statistics */
uint8_t temp_digest[ZUC_DIGEST_LENGTH];
diff --git a/drivers/net/softnic/rte_eth_softnic_cryptodev.c b/drivers/net/softnic/rte_eth_softnic_cryptodev.c
index 1480f6dd5..f031d8803 100644
--- a/drivers/net/softnic/rte_eth_softnic_cryptodev.c
+++ b/drivers/net/softnic/rte_eth_softnic_cryptodev.c
@@ -101,7 +101,7 @@ softnic_cryptodev_create(struct pmd_internals *p,
queue_conf.nb_descriptors = params->queue_size;
for (i = 0; i < params->n_queues; i++) {
status = rte_cryptodev_queue_pair_setup(dev_id, i,
- &queue_conf, socket_id, NULL);
+ &queue_conf, socket_id);
if (status < 0)
return NULL;
}
diff --git a/examples/fips_validation/main.c b/examples/fips_validation/main.c
index e7559c633..384b7a240 100644
--- a/examples/fips_validation/main.c
+++ b/examples/fips_validation/main.c
@@ -39,7 +39,7 @@ static int
cryptodev_fips_validate_app_int(void)
{
struct rte_cryptodev_config conf = {rte_socket_id(), 1};
- struct rte_cryptodev_qp_conf qp_conf = {128};
+ struct rte_cryptodev_qp_conf qp_conf = {128, NULL, NULL};
int ret;
ret = rte_cryptodev_configure(env.dev_id, &conf);
@@ -52,7 +52,7 @@ cryptodev_fips_validate_app_int(void)
return ret;
ret = rte_cryptodev_queue_pair_setup(env.dev_id, 0, &qp_conf,
- rte_socket_id(), env.mpool);
+ rte_socket_id());
if (ret < 0)
return ret;
diff --git a/examples/ip_pipeline/cryptodev.c b/examples/ip_pipeline/cryptodev.c
index c4ba72bec..b365810de 100644
--- a/examples/ip_pipeline/cryptodev.c
+++ b/examples/ip_pipeline/cryptodev.c
@@ -93,7 +93,7 @@ cryptodev_create(const char *name, struct cryptodev_params *params)
queue_conf.nb_descriptors = params->queue_size;
for (i = 0; i < params->n_queues; i++) {
status = rte_cryptodev_queue_pair_setup(dev_id, i,
- &queue_conf, socket_id, NULL);
+ &queue_conf, socket_id);
if (status < 0)
return NULL;
}
diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-secgw/ipsec-secgw.c
index 1bc0b5b50..a0ff8f7f7 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -1493,10 +1493,13 @@ cryptodevs_init(void)
cdev_id);
qp_conf.nb_descriptors = CDEV_QUEUE_DESC;
+ qp_conf.mp_session =
+ socket_ctx[dev_conf.socket_id].session_pool;
+ qp_conf.mp_session_private =
+ socket_ctx[dev_conf.socket_id].session_pool;
for (qp = 0; qp < dev_conf.nb_queue_pairs; qp++)
if (rte_cryptodev_queue_pair_setup(cdev_id, qp,
- &qp_conf, dev_conf.socket_id,
- socket_ctx[dev_conf.socket_id].session_pool))
+ &qp_conf, dev_conf.socket_id))
rte_panic("Failed to setup queue %u for "
"cdev_id %u\n", 0, cdev_id);
diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index f12fd266e..1df7ba743 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -2443,9 +2443,11 @@ initialize_cryptodevs(struct l2fwd_crypto_options *options, unsigned nb_ports,
}
qp_conf.nb_descriptors = 2048;
+ qp_conf.mp_session = session_pool_socket[socket_id];
+ qp_conf.mp_session_private = session_pool_socket[socket_id];
retval = rte_cryptodev_queue_pair_setup(cdev_id, 0, &qp_conf,
- socket_id, session_pool_socket[socket_id]);
+ socket_id);
if (retval < 0) {
printf("Failed to setup queue pair %u on cryptodev %u",
0, cdev_id);
diff --git a/examples/vhost_crypto/main.c b/examples/vhost_crypto/main.c
index 3deb5263f..cb30f84c0 100644
--- a/examples/vhost_crypto/main.c
+++ b/examples/vhost_crypto/main.c
@@ -463,7 +463,7 @@ free_resource(void)
int
main(int argc, char *argv[])
{
- struct rte_cryptodev_qp_conf qp_conf = {NB_CRYPTO_DESCRIPTORS};
+ struct rte_cryptodev_qp_conf qp_conf;
struct rte_cryptodev_config config;
struct rte_cryptodev_info dev_info;
char name[128];
@@ -551,11 +551,14 @@ main(int argc, char *argv[])
options.infos[i] = info;
+ qp_conf.nb_descriptors = NB_CRYPTO_DESCRIPTORS;
+ qp_conf.mp_session = info->sess_pool;
+ qp_conf.mp_session_private = info->sess_pool;
+
for (j = 0; j < dev_info.max_nb_queue_pairs; j++) {
ret = rte_cryptodev_queue_pair_setup(info->cid, j,
&qp_conf, rte_lcore_to_socket_id(
- lo->lcore_id),
- info->sess_pool);
+ lo->lcore_id));
if (ret < 0) {
RTE_LOG(ERR, USER1, "Failed to configure qp\n");
goto error_exit;
diff --git a/lib/librte_cryptodev/Makefile b/lib/librte_cryptodev/Makefile
index a8f94c097..b734d144a 100644
--- a/lib/librte_cryptodev/Makefile
+++ b/lib/librte_cryptodev/Makefile
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: BSD-3-Clause
-# Copyright(c) 2015 Intel Corporation
+# Copyright(c) 2015-2018 Intel Corporation
include $(RTE_SDK)/mk/rte.vars.mk
@@ -7,7 +7,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
LIB = librte_cryptodev.a
# library version
-LIBABIVER := 5
+LIBABIVER := 6
# build flags
CFLAGS += -O3
diff --git a/lib/librte_cryptodev/rte_cryptodev.c b/lib/librte_cryptodev/rte_cryptodev.c
index a52eaaa45..4929d0451 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -941,8 +941,7 @@ rte_cryptodev_close(uint8_t dev_id)
int
rte_cryptodev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
- const struct rte_cryptodev_qp_conf *qp_conf, int socket_id,
- struct rte_mempool *session_pool)
+ const struct rte_cryptodev_qp_conf *qp_conf, int socket_id)
{
struct rte_cryptodev *dev;
@@ -958,6 +957,17 @@ rte_cryptodev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
return -EINVAL;
}
+ if (!qp_conf) {
+ CDEV_LOG_ERR("qp_conf cannot be NULL\n");
+ return -EINVAL;
+ }
+
+ if ((qp_conf->mp_session && !qp_conf->mp_session_private) ||
+ (!qp_conf->mp_session && qp_conf->mp_session_private)) {
+ CDEV_LOG_ERR("Invalid mempools\n");
+ return -EINVAL;
+ }
+
if (dev->data->dev_started) {
CDEV_LOG_ERR(
"device %d must be stopped to allow configuration", dev_id);
@@ -967,7 +977,7 @@ rte_cryptodev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->queue_pair_setup, -ENOTSUP);
return (*dev->dev_ops->queue_pair_setup)(dev, queue_pair_id, qp_conf,
- socket_id, session_pool);
+ socket_id);
}
diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
index 4099823f1..f9e7507da 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -495,6 +495,10 @@ enum rte_cryptodev_event_type {
/** Crypto device queue pair configuration structure. */
struct rte_cryptodev_qp_conf {
uint32_t nb_descriptors; /**< Number of descriptors per queue pair */
+ struct rte_mempool *mp_session;
+ /**< The mempool for creating session in sessionless mode */
+ struct rte_mempool *mp_session_private;
+ /**< The mempool for creating sess private data in sessionless mode */
};
/**
@@ -689,8 +693,7 @@ rte_cryptodev_close(uint8_t dev_id);
*/
extern int
rte_cryptodev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
- const struct rte_cryptodev_qp_conf *qp_conf, int socket_id,
- struct rte_mempool *session_pool);
+ const struct rte_cryptodev_qp_conf *qp_conf, int socket_id);
/**
* Get the number of queue pairs on a specific crypto device
diff --git a/lib/librte_cryptodev/rte_cryptodev_pmd.h b/lib/librte_cryptodev/rte_cryptodev_pmd.h
index 1b6cafd17..f15c9af30 100644
--- a/lib/librte_cryptodev/rte_cryptodev_pmd.h
+++ b/lib/librte_cryptodev/rte_cryptodev_pmd.h
@@ -188,13 +188,12 @@ typedef void (*cryptodev_info_get_t)(struct rte_cryptodev *dev,
* @param qp_id Queue Pair Index
* @param qp_conf Queue configuration structure
* @param socket_id Socket Index
- * @param session_pool Pointer to device session mempool
*
* @return Returns 0 on success.
*/
typedef int (*cryptodev_queue_pair_setup_t)(struct rte_cryptodev *dev,
uint16_t qp_id, const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool);
+ int socket_id);
/**
* Release memory resources allocated by given queue pair.
diff --git a/test/test/test_cryptodev.c b/test/test/test_cryptodev.c
index 84065eb49..aac0b1f0b 100644
--- a/test/test/test_cryptodev.c
+++ b/test/test/test_cryptodev.c
@@ -461,12 +461,13 @@ testsuite_setup(void)
dev_id, ts_params->conf.nb_queue_pairs);
ts_params->qp_conf.nb_descriptors = DEFAULT_NUM_OPS_INFLIGHT;
+ ts_params->qp_conf.mp_session = ts_params->session_mpool;
+ ts_params->qp_conf.mp_session_private = ts_params->session_mpool;
for (qp_id = 0; qp_id < info.max_nb_queue_pairs; qp_id++) {
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
dev_id, qp_id, &ts_params->qp_conf,
- rte_cryptodev_socket_id(dev_id),
- ts_params->session_mpool),
+ rte_cryptodev_socket_id(dev_id)),
"Failed to setup queue pair %u on cryptodev %u",
qp_id, dev_id);
}
@@ -519,8 +520,7 @@ ut_setup(void)
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0], qp_id,
&ts_params->qp_conf,
- rte_cryptodev_socket_id(ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ rte_cryptodev_socket_id(ts_params->valid_devs[0])),
"Failed to setup queue pair %u on cryptodev %u",
qp_id, ts_params->valid_devs[0]);
}
@@ -709,13 +709,14 @@ test_queue_pair_descriptor_setup(void)
* freed so are re-used if ring is released and re-created.
*/
qp_conf.nb_descriptors = MIN_NUM_OPS_INFLIGHT; /* min size*/
+ qp_conf.mp_session = ts_params->session_mpool;
+ qp_conf.mp_session_private = ts_params->session_mpool;
for (qp_id = 0; qp_id < ts_params->conf.nb_queue_pairs; qp_id++) {
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0], qp_id, &qp_conf,
rte_cryptodev_socket_id(
- ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ ts_params->valid_devs[0])),
"Failed test for "
"rte_cryptodev_queue_pair_setup: num_inflights "
"%u on qp %u on cryptodev %u",
@@ -729,8 +730,7 @@ test_queue_pair_descriptor_setup(void)
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0], qp_id, &qp_conf,
rte_cryptodev_socket_id(
- ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ ts_params->valid_devs[0])),
"Failed test for"
" rte_cryptodev_queue_pair_setup: num_inflights"
" %u on qp %u on cryptodev %u",
@@ -744,8 +744,7 @@ test_queue_pair_descriptor_setup(void)
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0], qp_id, &qp_conf,
rte_cryptodev_socket_id(
- ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ ts_params->valid_devs[0])),
"Failed test for "
"rte_cryptodev_queue_pair_setup: num_inflights"
" %u on qp %u on cryptodev %u",
@@ -760,8 +759,7 @@ test_queue_pair_descriptor_setup(void)
TEST_ASSERT_FAIL(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0], qp_id, &qp_conf,
rte_cryptodev_socket_id(
- ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ ts_params->valid_devs[0])),
"Unexpectedly passed test for "
"rte_cryptodev_queue_pair_setup:"
"num_inflights %u on qp %u on cryptodev %u",
@@ -776,8 +774,7 @@ test_queue_pair_descriptor_setup(void)
TEST_ASSERT_FAIL(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0], qp_id, &qp_conf,
rte_cryptodev_socket_id(
- ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ ts_params->valid_devs[0])),
"Unexpectedly passed test for "
"rte_cryptodev_queue_pair_setup:"
"num_inflights %u on qp %u on cryptodev %u",
@@ -791,8 +788,7 @@ test_queue_pair_descriptor_setup(void)
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0], qp_id, &qp_conf,
rte_cryptodev_socket_id(
- ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ ts_params->valid_devs[0])),
"Failed test for"
" rte_cryptodev_queue_pair_setup:"
"num_inflights %u on qp %u on cryptodev %u",
@@ -807,8 +803,7 @@ test_queue_pair_descriptor_setup(void)
TEST_ASSERT_FAIL(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0], qp_id, &qp_conf,
rte_cryptodev_socket_id(
- ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ ts_params->valid_devs[0])),
"Unexpectedly passed test for "
"rte_cryptodev_queue_pair_setup:"
"num_inflights %u on qp %u on cryptodev %u",
@@ -824,8 +819,7 @@ test_queue_pair_descriptor_setup(void)
TEST_ASSERT_FAIL(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0],
qp_id, &qp_conf,
- rte_cryptodev_socket_id(ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ rte_cryptodev_socket_id(ts_params->valid_devs[0])),
"Failed test for rte_cryptodev_queue_pair_setup:"
"invalid qp %u on cryptodev %u",
qp_id, ts_params->valid_devs[0]);
@@ -835,8 +829,7 @@ test_queue_pair_descriptor_setup(void)
TEST_ASSERT_FAIL(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0],
qp_id, &qp_conf,
- rte_cryptodev_socket_id(ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ rte_cryptodev_socket_id(ts_params->valid_devs[0])),
"Failed test for rte_cryptodev_queue_pair_setup:"
"invalid qp %u on cryptodev %u",
qp_id, ts_params->valid_devs[0]);
diff --git a/test/test/test_cryptodev_asym.c b/test/test/test_cryptodev_asym.c
index a899f9973..0f6fc5767 100644
--- a/test/test/test_cryptodev_asym.c
+++ b/test/test/test_cryptodev_asym.c
@@ -383,11 +383,12 @@ testsuite_setup(void)
/* configure qp */
ts_params->qp_conf.nb_descriptors = DEFAULT_NUM_OPS_INFLIGHT;
+ ts_params->qp_conf.mp_session = ts_params->session_mpool;
+ ts_params->qp_conf.mp_session_private = ts_params->session_mpool;
for (qp_id = 0; qp_id < info.max_nb_queue_pairs; qp_id++) {
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
dev_id, qp_id, &ts_params->qp_conf,
- rte_cryptodev_socket_id(dev_id),
- ts_params->session_mpool),
+ rte_cryptodev_socket_id(dev_id)),
"Failed to setup queue pair %u on cryptodev %u ASYM",
qp_id, dev_id);
}
@@ -449,8 +450,7 @@ ut_setup(void)
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0], qp_id,
&ts_params->qp_conf,
- rte_cryptodev_socket_id(ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ rte_cryptodev_socket_id(ts_params->valid_devs[0])),
"Failed to setup queue pair %u on cryptodev %u",
qp_id, ts_params->valid_devs[0]);
}
diff --git a/test/test/test_event_crypto_adapter.c b/test/test/test_event_crypto_adapter.c
index de258c346..54717870e 100644
--- a/test/test/test_event_crypto_adapter.c
+++ b/test/test/test_event_crypto_adapter.c
@@ -546,11 +546,12 @@ configure_cryptodev(void)
TEST_CDEV_ID, conf.nb_queue_pairs);
qp_conf.nb_descriptors = DEFAULT_NUM_OPS_INFLIGHT;
+ qp_conf.mp_session = params.session_mpool;
+ qp_conf.mp_session_private = params.session_mpool;
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
TEST_CDEV_ID, TEST_CDEV_QP_ID, &qp_conf,
- rte_cryptodev_socket_id(TEST_CDEV_ID),
- params.session_mpool),
+ rte_cryptodev_socket_id(TEST_CDEV_ID)),
"Failed to setup queue pair %u on cryptodev %u\n",
TEST_CDEV_QP_ID, TEST_CDEV_ID);
--
2.13.6
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v3 1/2] cryptodev: change queue pair configure structure
2019-01-08 23:20 3% ` De Lara Guarch, Pablo
@ 2019-01-09 11:30 0% ` Zhang, Roy Fan
0 siblings, 0 replies; 200+ results
From: Zhang, Roy Fan @ 2019-01-09 11:30 UTC (permalink / raw)
To: De Lara Guarch, Pablo, dev; +Cc: akhil.goyal, Trahe, Fiona
Hi Pablo,
Thanks for the review.
Comments inline.
> -----Original Message-----
> From: De Lara Guarch, Pablo
> Sent: Tuesday, January 8, 2019 11:21 PM
> To: Zhang, Roy Fan <roy.fan.zhang@intel.com>; dev@dpdk.org
> Cc: akhil.goyal@nxp.com; Trahe, Fiona <fiona.trahe@intel.com>
> Subject: RE: [PATCH v3 1/2] cryptodev: change queue pair configure
> structure
>
>
>
> > -----Original Message-----
> > From: Zhang, Roy Fan
> > Sent: Friday, December 21, 2018 1:56 PM
> > To: dev@dpdk.org
> > Cc: akhil.goyal@nxp.com; De Lara Guarch, Pablo
> > <pablo.de.lara.guarch@intel.com>; Trahe, Fiona <fiona.trahe@intel.com>
> > Subject: [PATCH v3 1/2] cryptodev: change queue pair configure
> > structure
> >
> > This patch changes the cryptodev queue pair configure structure to
> > enable two mempool passed into cryptodev PMD simutaneously.
> >
> > Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
> > Acked-by: Fiona Trahe <fiona.trahe@@intel.com>
>
> ...
>
> > diff --git a/doc/guides/rel_notes/release_19_02.rst
> > b/doc/guides/rel_notes/release_19_02.rst
> > index 47768288a..4420c2441 100644
> > --- a/doc/guides/rel_notes/release_19_02.rst
> > +++ b/doc/guides/rel_notes/release_19_02.rst
> > @@ -130,6 +130,11 @@ API Changes
> > ``rte_pdump_init()`` and enum ``rte_pdump_socktype`` were deprecated
> > since 18.05 and are removed in this release.
> >
> > +* cryptodev: as shown in the the 18.08 deprecation notice, the
> > +structure
>
> Typo. "the 18.11" deprecation notice.
[Fan: Will change]
>
> > + ``rte_cryptodev_qp_conf`` has been added two parameters of
> > + symmetric
> > session
> > + mempool and symmetric session private data mempool, and the last
> > parameter of
> > + ``rte_cryptodev_queue_pair_setup()`` is removed.
> > +
> >
> > ABI Changes
> > -----------
>
> I think we need to bump the ABI version of cryptodev due to this, in release
> notes.
> Also, the deprecation notice added for this change, should be removed in
> this patch.
[Fan: Will do]
>
> > diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
> > b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
> > index ebdf7c35a..abc7a6d5f 100644
>
> ...
>
> > --- a/examples/fips_validation/main.c
> > +++ b/examples/fips_validation/main.c
> > @@ -39,7 +39,7 @@ static int
> > cryptodev_fips_validate_app_int(void)
> > {
> > struct rte_cryptodev_config conf = {rte_socket_id(), 1};
> > - struct rte_cryptodev_qp_conf qp_conf = {128};
> > + struct rte_cryptodev_qp_conf qp_conf = {128, NULL, NULL};
>
> Is this OK? Below, it looks like a mempool was passes (env.mpool), but now it
> is NULL here.
[Fan: we do not need a mempool here as none of the session-less scheme will be tested]
>
> > int ret;
> >
> > ret = rte_cryptodev_configure(env.dev_id, &conf); @@ -52,7 +52,7
> @@
> > cryptodev_fips_validate_app_int(void)
> > return ret;
> >
> > ret = rte_cryptodev_queue_pair_setup(env.dev_id, 0, &qp_conf,
> > - rte_socket_id(), env.mpool);
> > + rte_socket_id());
> > if (ret < 0)
> > return ret;
> >
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3 1/2] cryptodev: change queue pair configure structure
2018-12-21 13:55 1% ` [dpdk-dev] [PATCH v3 1/2] cryptodev: change queue pair configure structure Fan Zhang
@ 2019-01-08 23:20 3% ` De Lara Guarch, Pablo
2019-01-09 11:30 0% ` Zhang, Roy Fan
0 siblings, 1 reply; 200+ results
From: De Lara Guarch, Pablo @ 2019-01-08 23:20 UTC (permalink / raw)
To: Zhang, Roy Fan, dev; +Cc: akhil.goyal, Trahe, Fiona
> -----Original Message-----
> From: Zhang, Roy Fan
> Sent: Friday, December 21, 2018 1:56 PM
> To: dev@dpdk.org
> Cc: akhil.goyal@nxp.com; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; Trahe, Fiona <fiona.trahe@intel.com>
> Subject: [PATCH v3 1/2] cryptodev: change queue pair configure structure
>
> This patch changes the cryptodev queue pair configure structure
> to enable two mempool passed into cryptodev PMD simutaneously.
>
> Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
> Acked-by: Fiona Trahe <fiona.trahe@@intel.com>
...
> diff --git a/doc/guides/rel_notes/release_19_02.rst
> b/doc/guides/rel_notes/release_19_02.rst
> index 47768288a..4420c2441 100644
> --- a/doc/guides/rel_notes/release_19_02.rst
> +++ b/doc/guides/rel_notes/release_19_02.rst
> @@ -130,6 +130,11 @@ API Changes
> ``rte_pdump_init()`` and enum ``rte_pdump_socktype`` were deprecated
> since 18.05 and are removed in this release.
>
> +* cryptodev: as shown in the the 18.08 deprecation notice, the structure
Typo. "the 18.11" deprecation notice.
> + ``rte_cryptodev_qp_conf`` has been added two parameters of symmetric
> session
> + mempool and symmetric session private data mempool, and the last
> parameter of
> + ``rte_cryptodev_queue_pair_setup()`` is removed.
> +
>
> ABI Changes
> -----------
I think we need to bump the ABI version of cryptodev due to this, in release notes.
Also, the deprecation notice added for this change, should be removed in this patch.
> diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
> b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
> index ebdf7c35a..abc7a6d5f 100644
...
> --- a/examples/fips_validation/main.c
> +++ b/examples/fips_validation/main.c
> @@ -39,7 +39,7 @@ static int
> cryptodev_fips_validate_app_int(void)
> {
> struct rte_cryptodev_config conf = {rte_socket_id(), 1};
> - struct rte_cryptodev_qp_conf qp_conf = {128};
> + struct rte_cryptodev_qp_conf qp_conf = {128, NULL, NULL};
Is this OK? Below, it looks like a mempool was passes (env.mpool), but now it is NULL here.
> int ret;
>
> ret = rte_cryptodev_configure(env.dev_id, &conf);
> @@ -52,7 +52,7 @@ cryptodev_fips_validate_app_int(void)
> return ret;
>
> ret = rte_cryptodev_queue_pair_setup(env.dev_id, 0, &qp_conf,
> - rte_socket_id(), env.mpool);
> + rte_socket_id());
> if (ret < 0)
> return ret;
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v6 01/10] cryptodev: add opaque userdata pointer into crypto sym session
2019-01-04 0:25 3% ` Stephen Hemminger
@ 2019-01-04 9:29 0% ` Ananyev, Konstantin
2019-01-09 23:41 4% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2019-01-04 9:29 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev, akhil.goyal
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Friday, January 4, 2019 12:26 AM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Cc: dev@dpdk.org; akhil.goyal@nxp.com
> Subject: Re: [dpdk-dev] [PATCH v6 01/10] cryptodev: add opaque userdata pointer into crypto sym session
>
> On Thu, 3 Jan 2019 20:16:17 +0000
> Konstantin Ananyev <konstantin.ananyev@intel.com> wrote:
>
> > Add 'uint64_t opaque_data' inside struct rte_cryptodev_sym_session.
> > That allows upper layer to easily associate some user defined
> > data with the session.
> >
> > Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > Acked-by: Fiona Trahe <fiona.trahe@intel.com>
> > Acked-by: Mohammad Abdul Awal <mohammad.abdul.awal@intel.com>
> > Acked-by: Declan Doherty <declan.doherty@intel.com>
> > Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
> > ---
> > lib/librte_cryptodev/rte_cryptodev.h | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
> > index 4099823f1..009860e7b 100644
> > --- a/lib/librte_cryptodev/rte_cryptodev.h
> > +++ b/lib/librte_cryptodev/rte_cryptodev.h
> > @@ -954,6 +954,8 @@ rte_cryptodev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
> > * has a fixed algo, key, op-type, digest_len etc.
> > */
> > struct rte_cryptodev_sym_session {
> > + uint64_t opaque_data;
> > + /**< Opaque user defined data */
> > __extension__ void *sess_private_data[0];
> > /**< Private symmetric session material */
> > };
>
> This will cause ABI breakage.
Yes, it surely would.
That's why we submitted deprecation notice in 18.11 and got 3 acks for it.
Konstantin
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v6 01/10] cryptodev: add opaque userdata pointer into crypto sym session
@ 2019-01-04 0:25 3% ` Stephen Hemminger
2019-01-04 9:29 0% ` Ananyev, Konstantin
2019-01-10 14:20 4% ` [dpdk-dev] [PATCH v7 00/10] ipsec: new library for IPsec data-path processing Konstantin Ananyev
` (2 subsequent siblings)
3 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-01-04 0:25 UTC (permalink / raw)
To: Konstantin Ananyev; +Cc: dev, akhil.goyal
On Thu, 3 Jan 2019 20:16:17 +0000
Konstantin Ananyev <konstantin.ananyev@intel.com> wrote:
> Add 'uint64_t opaque_data' inside struct rte_cryptodev_sym_session.
> That allows upper layer to easily associate some user defined
> data with the session.
>
> Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> Acked-by: Fiona Trahe <fiona.trahe@intel.com>
> Acked-by: Mohammad Abdul Awal <mohammad.abdul.awal@intel.com>
> Acked-by: Declan Doherty <declan.doherty@intel.com>
> Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
> ---
> lib/librte_cryptodev/rte_cryptodev.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
> index 4099823f1..009860e7b 100644
> --- a/lib/librte_cryptodev/rte_cryptodev.h
> +++ b/lib/librte_cryptodev/rte_cryptodev.h
> @@ -954,6 +954,8 @@ rte_cryptodev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
> * has a fixed algo, key, op-type, digest_len etc.
> */
> struct rte_cryptodev_sym_session {
> + uint64_t opaque_data;
> + /**< Opaque user defined data */
> __extension__ void *sess_private_data[0];
> /**< Private symmetric session material */
> };
This will cause ABI breakage.
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v6 00/10] ipsec: new library for IPsec data-path processing
@ 2019-01-03 20:16 2% ` Konstantin Ananyev
2019-01-11 1:09 2% ` Xu, Yanjie
1 sibling, 1 reply; 200+ results
From: Konstantin Ananyev @ 2019-01-03 20:16 UTC (permalink / raw)
To: dev, dev; +Cc: akhil.goyal, Konstantin Ananyev
v5 -> v6
- Fix issues reported by Akhil:
rte_ipsec_session_prepare() fails for lookaside-proto
v4 -> v5
- Fix issue with SQN overflows
- Address Akhil comments:
documentation update
spell checks spacing etc.
fix input crypto_xform check/prepcess
test cases for lookaside and inline proto
v3 -> v4
- Changes to adress Declan comments
- Update docs
v2 -> v3
- Several fixes for IPv6 support
- Extra checks for input parameters in public APi functions
v1 -> v2
- Changes to get into account l2_len for outbound transport packets
(Qi comments)
- Several bug fixes
- Some code restructured
- Update MAINTAINERS file
RFCv2 -> v1
- Changes per Jerin comments
- Implement transport mode
- Several bug fixes
- UT largely reworked and extended
This patch introduces a new library within DPDK: librte_ipsec.
The aim is to provide DPDK native high performance library for IPsec
data-path processing.
The library is supposed to utilize existing DPDK crypto-dev and
security API to provide application with transparent IPsec
processing API.
The library is concentrated on data-path protocols processing
(ESP and AH), IKE protocol(s) implementation is out of scope
for that library.
Current patch introduces SA-level API.
SA (low) level API
==================
API described below operates on SA level.
It provides functionality that allows user for given SA to process
inbound and outbound IPsec packets.
To be more specific:
- for inbound ESP/AH packets perform decryption, authentication,
integrity checking, remove ESP/AH related headers
- for outbound packets perform payload encryption, attach ICV,
update/add IP headers, add ESP/AH headers/trailers,
setup related mbuf felids (ol_flags, tx_offloads, etc.).
- initialize/un-initialize given SA based on user provided parameters.
The following functionality:
- match inbound/outbound packets to particular SA
- manage crypto/security devices
- provide SAD/SPD related functionality
- determine what crypto/security device has to be used
for given packet(s)
is out of scope for SA-level API.
SA-level API is based on top of crypto-dev/security API and relies on them
to perform actual cipher and integrity checking.
To have an ability to easily map crypto/security sessions into related
IPSec SA opaque userdata field was added into
rte_cryptodev_sym_session and rte_security_session structures.
That implies ABI change for both librte_crytpodev and librte_security.
Due to the nature of crypto-dev API (enqueue/deque model) we use
asynchronous API for IPsec packets destined to be processed by
crypto-device.
Expected API call sequence would be:
/* enqueue for processing by crypto-device */
rte_ipsec_pkt_crypto_prepare(...);
rte_cryptodev_enqueue_burst(...);
/* dequeue from crypto-device and do final processing (if any) */
rte_cryptodev_dequeue_burst(...);
rte_ipsec_pkt_crypto_group(...); /* optional */
rte_ipsec_pkt_process(...);
Though for packets destined for inline processing no extra overhead
is required and synchronous API call: rte_ipsec_pkt_process()
is sufficient for that case.
Current implementation supports all four currently defined
rte_security types.
Though to accommodate future custom implementations function pointers
model is used for both for *crypto_prepare* and *process*
impelementations.
Konstantin Ananyev (10):
cryptodev: add opaque userdata pointer into crypto sym session
security: add opaque userdata pointer into security session
net: add ESP trailer structure definition
lib: introduce ipsec library
ipsec: add SA data-path API
ipsec: implement SA data-path API
ipsec: rework SA replay window/SQN for MT environment
ipsec: helper functions to group completed crypto-ops
test/ipsec: introduce functional test
doc: add IPsec library guide
MAINTAINERS | 8 +-
config/common_base | 5 +
doc/guides/prog_guide/index.rst | 1 +
doc/guides/prog_guide/ipsec_lib.rst | 168 ++
doc/guides/rel_notes/release_19_02.rst | 11 +
lib/Makefile | 2 +
lib/librte_cryptodev/rte_cryptodev.h | 2 +
lib/librte_ipsec/Makefile | 27 +
lib/librte_ipsec/crypto.h | 123 ++
lib/librte_ipsec/iph.h | 84 +
lib/librte_ipsec/ipsec_sqn.h | 343 ++++
lib/librte_ipsec/meson.build | 10 +
lib/librte_ipsec/pad.h | 45 +
lib/librte_ipsec/rte_ipsec.h | 154 ++
lib/librte_ipsec/rte_ipsec_group.h | 151 ++
lib/librte_ipsec/rte_ipsec_sa.h | 174 ++
lib/librte_ipsec/rte_ipsec_version.map | 15 +
lib/librte_ipsec/sa.c | 1527 ++++++++++++++
lib/librte_ipsec/sa.h | 106 +
lib/librte_ipsec/ses.c | 52 +
lib/librte_net/rte_esp.h | 10 +-
lib/librte_security/rte_security.h | 2 +
lib/meson.build | 2 +
mk/rte.app.mk | 2 +
test/test/Makefile | 3 +
test/test/meson.build | 3 +
test/test/test_ipsec.c | 2555 ++++++++++++++++++++++++
27 files changed, 5583 insertions(+), 2 deletions(-)
create mode 100644 doc/guides/prog_guide/ipsec_lib.rst
create mode 100644 lib/librte_ipsec/Makefile
create mode 100644 lib/librte_ipsec/crypto.h
create mode 100644 lib/librte_ipsec/iph.h
create mode 100644 lib/librte_ipsec/ipsec_sqn.h
create mode 100644 lib/librte_ipsec/meson.build
create mode 100644 lib/librte_ipsec/pad.h
create mode 100644 lib/librte_ipsec/rte_ipsec.h
create mode 100644 lib/librte_ipsec/rte_ipsec_group.h
create mode 100644 lib/librte_ipsec/rte_ipsec_sa.h
create mode 100644 lib/librte_ipsec/rte_ipsec_version.map
create mode 100644 lib/librte_ipsec/sa.c
create mode 100644 lib/librte_ipsec/sa.h
create mode 100644 lib/librte_ipsec/ses.c
create mode 100644 test/test/test_ipsec.c
--
2.17.1
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v5 00/10] ipsec: new library for IPsec data-path processing
@ 2018-12-28 15:17 2% ` Konstantin Ananyev
0 siblings, 0 replies; 200+ results
From: Konstantin Ananyev @ 2018-12-28 15:17 UTC (permalink / raw)
To: dev, dev; +Cc: akhil.goyal, Konstantin Ananyev
v4 -> v5
- Fix issue with SQN overflows
- Address Akhil comments:
documentation update
spell checks spacing etc.
fix input crypto_xform check/prepcess
test cases for lookaside and inline proto
v3 -> v4
- Changes to adress Declan comments
- Update docs
v2 -> v3
- Several fixes for IPv6 support
- Extra checks for input parameters in public APi functions
v1 -> v2
- Changes to get into account l2_len for outbound transport packets
(Qi comments)
- Several bug fixes
- Some code restructured
- Update MAINTAINERS file
RFCv2 -> v1
- Changes per Jerin comments
- Implement transport mode
- Several bug fixes
- UT largely reworked and extended
This patch introduces a new library within DPDK: librte_ipsec.
The aim is to provide DPDK native high performance library for IPsec
data-path processing.
The library is supposed to utilize existing DPDK crypto-dev and
security API to provide application with transparent IPsec
processing API.
The library is concentrated on data-path protocols processing
(ESP and AH), IKE protocol(s) implementation is out of scope
for that library.
Current patch introduces SA-level API.
SA (low) level API
==================
API described below operates on SA level.
It provides functionality that allows user for given SA to process
inbound and outbound IPsec packets.
To be more specific:
- for inbound ESP/AH packets perform decryption, authentication,
integrity checking, remove ESP/AH related headers
- for outbound packets perform payload encryption, attach ICV,
update/add IP headers, add ESP/AH headers/trailers,
setup related mbuf felids (ol_flags, tx_offloads, etc.).
- initialize/un-initialize given SA based on user provided parameters.
The following functionality:
- match inbound/outbound packets to particular SA
- manage crypto/security devices
- provide SAD/SPD related functionality
- determine what crypto/security device has to be used
for given packet(s)
is out of scope for SA-level API.
SA-level API is based on top of crypto-dev/security API and relies on them
to perform actual cipher and integrity checking.
To have an ability to easily map crypto/security sessions into related
IPSec SA opaque userdata field was added into
rte_cryptodev_sym_session and rte_security_session structures.
That implies ABI change for both librte_crytpodev and librte_security.
Due to the nature of crypto-dev API (enqueue/deque model) we use
asynchronous API for IPsec packets destined to be processed by crypto-device.
Expected API call sequence would be:
/* enqueue for processing by crypto-device */
rte_ipsec_pkt_crypto_prepare(...);
rte_cryptodev_enqueue_burst(...);
/* dequeue from crypto-device and do final processing (if any) */
rte_cryptodev_dequeue_burst(...);
rte_ipsec_pkt_crypto_group(...); /* optional */
rte_ipsec_pkt_process(...);
Though for packets destined for inline processing no extra overhead
is required and synchronous API call: rte_ipsec_pkt_process()
is sufficient for that case.
Current implementation supports all four currently defined
rte_security types.
Though to accommodate future custom implementations function pointers
model is used for both for *crypto_prepare* and *process* impelementations.
Konstantin Ananyev (10):
cryptodev: add opaque userdata pointer into crypto sym session
security: add opaque userdata pointer into security session
net: add ESP trailer structure definition
lib: introduce ipsec library
ipsec: add SA data-path API
ipsec: implement SA data-path API
ipsec: rework SA replay window/SQN for MT environment
ipsec: helper functions to group completed crypto-ops
test/ipsec: introduce functional test
doc: add IPsec library guide
MAINTAINERS | 8 +-
config/common_base | 5 +
doc/guides/prog_guide/index.rst | 1 +
doc/guides/prog_guide/ipsec_lib.rst | 168 ++
doc/guides/rel_notes/release_19_02.rst | 11 +
lib/Makefile | 2 +
lib/librte_cryptodev/rte_cryptodev.h | 2 +
lib/librte_ipsec/Makefile | 27 +
lib/librte_ipsec/crypto.h | 123 ++
lib/librte_ipsec/iph.h | 84 +
lib/librte_ipsec/ipsec_sqn.h | 343 ++++
lib/librte_ipsec/meson.build | 10 +
lib/librte_ipsec/pad.h | 45 +
lib/librte_ipsec/rte_ipsec.h | 154 ++
lib/librte_ipsec/rte_ipsec_group.h | 151 ++
lib/librte_ipsec/rte_ipsec_sa.h | 174 ++
lib/librte_ipsec/rte_ipsec_version.map | 15 +
lib/librte_ipsec/sa.c | 1527 ++++++++++++++
lib/librte_ipsec/sa.h | 106 +
lib/librte_ipsec/ses.c | 45 +
lib/librte_net/rte_esp.h | 10 +-
lib/librte_security/rte_security.h | 2 +
lib/meson.build | 2 +
mk/rte.app.mk | 2 +
test/test/Makefile | 3 +
test/test/meson.build | 3 +
test/test/test_ipsec.c | 2555 ++++++++++++++++++++++++
27 files changed, 5576 insertions(+), 2 deletions(-)
create mode 100644 doc/guides/prog_guide/ipsec_lib.rst
create mode 100644 lib/librte_ipsec/Makefile
create mode 100644 lib/librte_ipsec/crypto.h
create mode 100644 lib/librte_ipsec/iph.h
create mode 100644 lib/librte_ipsec/ipsec_sqn.h
create mode 100644 lib/librte_ipsec/meson.build
create mode 100644 lib/librte_ipsec/pad.h
create mode 100644 lib/librte_ipsec/rte_ipsec.h
create mode 100644 lib/librte_ipsec/rte_ipsec_group.h
create mode 100644 lib/librte_ipsec/rte_ipsec_sa.h
create mode 100644 lib/librte_ipsec/rte_ipsec_version.map
create mode 100644 lib/librte_ipsec/sa.c
create mode 100644 lib/librte_ipsec/sa.h
create mode 100644 lib/librte_ipsec/ses.c
create mode 100644 test/test/test_ipsec.c
--
2.17.1
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [RFC 00/14] prefix network structures
2018-12-21 15:14 0% ` Ferruh Yigit
@ 2018-12-27 9:35 0% ` Olivier Matz
2019-02-13 11:48 0% ` Yigit, Ferruh
0 siblings, 1 reply; 200+ results
From: Olivier Matz @ 2018-12-27 9:35 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: Wiles, Keith, Stephen Hemminger, dpdk-dev, Richardson, Bruce
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?
Olivier
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] net/mlx5: modify-header support using Direct Verbs
2018-12-25 11:38 3% ` Shahaf Shuler
@ 2018-12-25 16:00 0% ` Dekel Peled
0 siblings, 0 replies; 200+ results
From: Dekel Peled @ 2018-12-25 16:00 UTC (permalink / raw)
To: Shahaf Shuler, Yongseok Koh; +Cc: dev, Ori Kam
Thanks, PSB.
> -----Original Message-----
> From: Shahaf Shuler
> Sent: Tuesday, December 25, 2018 1:38 PM
> To: Dekel Peled <dekelp@mellanox.com>; Yongseok Koh
> <yskoh@mellanox.com>
> Cc: dev@dpdk.org; Ori Kam <orika@mellanox.com>; Dekel Peled
> <dekelp@mellanox.com>
> Subject: RE: [PATCH] net/mlx5: modify-header support using Direct Verbs
>
> Hi Dekel,
>
> See some comments below,
>
> Sunday, December 23, 2018 11:58 AM, Dekel Peled:
> > Subject: [PATCH] net/mlx5: modify-header support using Direct Verbs
>
> Maybe title can be: "support modify header using Direct Verbs"
OK, I'll change it.
>
> >
> > This patch implements the set of actions to support offload of packet
> > header modifications to MLX5 NIC.
> >
> > Implamantation is based on RFC [1].
> >
> > [1] http://mails.dpdk.org/archives/dev/2018-November/119971.html
> >
> > Signed-off-by: Dekel Peled <dekelp@mellanox.com>
> > ---
> > drivers/net/mlx5/mlx5.h | 1 +
> > drivers/net/mlx5/mlx5_flow.h | 56 ++-
> > drivers/net/mlx5/mlx5_flow_dv.c | 998
> > +++++++++++++++++++++++++++++++++++++++-
> > drivers/net/mlx5/mlx5_glue.c | 22 +
> > drivers/net/mlx5/mlx5_glue.h | 5 +
> > drivers/net/mlx5/mlx5_prm.h | 11 +-
> > 6 files changed, 1084 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h index
> > 75aeeb2..b2fe5cb 100644
> > --- a/drivers/net/mlx5/mlx5.h
> > +++ b/drivers/net/mlx5/mlx5.h
> > @@ -227,6 +227,7 @@ struct priv {
> > LIST_HEAD(ind_tables, mlx5_ind_table_ibv) ind_tbls;
> > LIST_HEAD(matchers, mlx5_flow_dv_matcher) matchers;
> > LIST_HEAD(encap_decap, mlx5_flow_dv_encap_decap_resource)
> > encaps_decaps;
> > + LIST_HEAD(modify_cmd, mlx5_flow_dv_modify_hdr_resource)
> > modify_cmds;
> > uint32_t link_speed_capa; /* Link speed capabilities. */
> > struct mlx5_xstats_ctrl xstats_ctrl; /* Extended stats control. */
> > struct mlx5_stats_ctrl stats_ctrl; /* Stats control. */ diff --git
> > a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h index
> > 4a7c052..cb1e6fd 100644
> > --- a/drivers/net/mlx5/mlx5_flow.h
> > +++ b/drivers/net/mlx5/mlx5_flow.h
> > @@ -69,6 +69,18 @@
> > (MLX5_FLOW_LAYER_INNER_L2 | MLX5_FLOW_LAYER_INNER_L3 | \
> > MLX5_FLOW_LAYER_INNER_L4)
> >
> > +/* Layer Masks. */
> > +#define MLX5_FLOW_LAYER_L2 \
> > + (MLX5_FLOW_LAYER_OUTER_L2 | MLX5_FLOW_LAYER_INNER_L2)
> > #define
> > +MLX5_FLOW_LAYER_L3_IPV4 \
> > + (MLX5_FLOW_LAYER_OUTER_L3_IPV4 |
> > MLX5_FLOW_LAYER_INNER_L3_IPV4)
> > +#define MLX5_FLOW_LAYER_L3_IPV6 \
> > + (MLX5_FLOW_LAYER_OUTER_L3_IPV6 |
> > MLX5_FLOW_LAYER_INNER_L3_IPV6)
> > +#define MLX5_FLOW_LAYER_L3 \
> > + (MLX5_FLOW_LAYER_L3_IPV4 | MLX5_FLOW_LAYER_L3_IPV6)
> #define
> > +MLX5_FLOW_LAYER_L4 \
> > + (MLX5_FLOW_LAYER_OUTER_L4 | MLX5_FLOW_LAYER_INNER_L4)
> > +
> > /* Actions */
> > #define MLX5_FLOW_ACTION_DROP (1u << 0) #define
> > MLX5_FLOW_ACTION_QUEUE (1u << 1) @@ -110,6 +122,17 @@
> > MLX5_FLOW_ACTION_NVGRE_DECAP | \
> > MLX5_FLOW_ACTION_RAW_DECAP)
> >
> > +#define MLX5_FLOW_MODIFY_HDR_ACTIONS
> > (MLX5_FLOW_ACTION_SET_IPV4_SRC | \
> > + MLX5_FLOW_ACTION_SET_IPV4_DST | \
> > + MLX5_FLOW_ACTION_SET_IPV6_SRC | \
> > + MLX5_FLOW_ACTION_SET_IPV6_DST | \
> > + MLX5_FLOW_ACTION_SET_TP_SRC | \
> > + MLX5_FLOW_ACTION_SET_TP_DST | \
> > + MLX5_FLOW_ACTION_SET_TTL | \
> > + MLX5_FLOW_ACTION_DEC_TTL | \
> > + MLX5_FLOW_ACTION_SET_MAC_SRC | \
> > + MLX5_FLOW_ACTION_SET_MAC_DST)
> > +
> > #ifndef IPPROTO_MPLS
> > #define IPPROTO_MPLS 137
> > #endif
> > @@ -153,9 +176,6 @@
> > /* IBV hash source bits for IPV6. */ #define MLX5_IPV6_IBV_RX_HASH
> > (IBV_RX_HASH_SRC_IPV6 |
> > IBV_RX_HASH_DST_IPV6)
> >
> > -/* Max number of actions per DV flow. */ -#define
> > MLX5_DV_MAX_NUMBER_OF_ACTIONS 8
> > -
> > enum mlx5_flow_drv_type {
> > MLX5_FLOW_TYPE_MIN,
> > MLX5_FLOW_TYPE_DV,
> > @@ -172,9 +192,6 @@ struct mlx5_flow_dv_match_params {
> > /**< Matcher value. This value is used as the mask or as a key. */
> > };
> >
> > -#define MLX5_DV_MAX_NUMBER_OF_ACTIONS 8 -#define
> MLX5_ENCAP_MAX_LEN
> > 132
> > -
> > /* Matcher structure. */
> > struct mlx5_flow_dv_matcher {
> > LIST_ENTRY(mlx5_flow_dv_matcher) next; @@ -187,6 +204,8 @@
> struct
> > mlx5_flow_dv_matcher {
> > struct mlx5_flow_dv_match_params mask; /**< Matcher mask. */ };
> >
> > +#define MLX5_ENCAP_MAX_LEN 132
> > +
> > /* Encap/decap resource structure. */ struct
> > mlx5_flow_dv_encap_decap_resource {
> > LIST_ENTRY(mlx5_flow_dv_encap_decap_resource) next; @@ -
> 200,6
> > +219,29 @@ struct mlx5_flow_dv_encap_decap_resource {
> > uint8_t ft_type;
> > };
> >
> > +/* Number of modification commands. */ #define MLX5_MODIFY_NUM 8
> > +
> > +/* Modify resource structure */
> > +struct mlx5_flow_dv_modify_hdr_resource {
> > + LIST_ENTRY(mlx5_flow_dv_modify_hdr_resource) next;
> > + /* Pointer to next element. */
> > + rte_atomic32_t refcnt; /**< Reference counter. */
> > + struct ibv_flow_action *verbs_action;
> > + /**< Verbs modify header action object. */
> > + uint8_t ft_type; /**< Flow table type, Rx or Tx. */
> > + uint32_t actions_num; /**< Number of modification actions. */
> > + struct mlx5_modification_cmd actions[MLX5_MODIFY_NUM];
> > + /**< Modification actions. */
> > +};
> > +
> > +/*
> > + * Max number of actions per DV flow.
> > + * See CREATE_FLOW_MAX_FLOW_ACTIONS_SUPPORTED
> > + * In rdma-core file providers/mlx5/verbs.c */ #define
> > +MLX5_DV_MAX_NUMBER_OF_ACTIONS 8
> > +
> > /* DV flows structure. */
> > struct mlx5_flow_dv {
> > uint64_t hash_fields; /**< Fields that participate in the hash. */
> > @@ -
> > 210,6 +252,8 @@ struct mlx5_flow_dv {
> > /**< Holds the value that the packet is compared to. */
> > struct mlx5_flow_dv_encap_decap_resource *encap_decap;
> > /**< Pointer to encap/decap resource in cache. */
> > + struct mlx5_flow_dv_modify_hdr_resource *modify_hdr;
> > + /**< Pointer to modify header resource in cache. */
> > struct ibv_flow *flow; /**< Installed flow. */ #ifdef
> > HAVE_IBV_FLOW_DV_SUPPORT
> > struct mlx5dv_flow_action_attr
> > actions[MLX5_DV_MAX_NUMBER_OF_ACTIONS];
> > diff --git a/drivers/net/mlx5/mlx5_flow_dv.c
> > b/drivers/net/mlx5/mlx5_flow_dv.c index 1f31874..ad4e501 100644
> > --- a/drivers/net/mlx5/mlx5_flow_dv.c
> > +++ b/drivers/net/mlx5/mlx5_flow_dv.c
> > @@ -35,6 +35,504 @@
> >
> > #ifdef HAVE_IBV_FLOW_DV_SUPPORT
> >
> > +union flow_dv_attr {
> > + struct {
> > + uint32_t valid:1;
> > + uint32_t ipv4:1;
> > + uint32_t ipv6:1;
> > + uint32_t tcp:1;
> > + uint32_t udp:1;
> > + uint32_t reserved:27;
> > + };
> > + uint32_t attr;
> > +};
> > +
> > +static void
> > +flow_dv_attr_init(const struct rte_flow_item *item, union
> > +flow_dv_attr
> > +*attr) {
>
> Can we avoid this duplicated parsing and use the parsing done on translate
> when traversing the items list (using item_flags)?
> it will require to do the item translate before the actions translate.
I tried to avoid it but couldn't.
It used to be items before actions, changed in http://git.dpdk.org/dpdk/commit/?id=e31b6a4151bc8ef97b0fb1ac951b33d811d52969.
The duplicate parsing will occur at most once per flow rule, and only if specific items are present.
> Koh, Ori what do you think?
>
> If yes, then the swap between the item and action translate should be on a
> separate patch to ease the patch review.
>
> > + for (; item->type != RTE_FLOW_ITEM_TYPE_END; item++) {
> > + switch (item->type) {
> > + case RTE_FLOW_ITEM_TYPE_IPV4:
> > + attr->ipv4 = 1;
> > + break;
> > + case RTE_FLOW_ITEM_TYPE_IPV6:
> > + attr->ipv6 = 1;
> > + break;
> > + case RTE_FLOW_ITEM_TYPE_UDP:
> > + attr->udp = 1;
> > + break;
> > + case RTE_FLOW_ITEM_TYPE_TCP:
> > + attr->tcp = 1;
> > + break;
> > + default:
> > + break;
> > + }
> > + }
> > + attr->valid = 1;
> > +}
> > +
> > +struct field_modify_info {
> > + int bits; /* Offset of field in protocol header, in bits. */
> > + enum mlx5_modification_field outer_type;
> > + enum mlx5_modification_field inner_type; };
> > +
> > +struct field_modify_info modify_eth[] = {
> > + {4 * 8, MLX5_MODI_OUT_DMAC_47_16,
> > MLX5_MODI_IN_DMAC_47_16},
> > + {2 * 8, MLX5_MODI_OUT_DMAC_15_0,
> > MLX5_MODI_IN_DMAC_15_0},
> > + {4 * 8, MLX5_MODI_OUT_SMAC_47_16,
> > MLX5_MODI_IN_SMAC_47_16},
> > + {2 * 8, MLX5_MODI_OUT_SMAC_15_0,
> MLX5_MODI_IN_SMAC_15_0},
> > + {2 * 8, MLX5_MODI_OUT_ETHERTYPE, MLX5_MODI_IN_ETHERTYPE},
> > + {0, 0, 0},
> > +};
> > +
> > +struct field_modify_info modify_ipv4[] = {
> > + {1 * 8, 0, 0}, /* Ver,len. */
> > + {1 * 8, MLX5_MODI_OUT_IP_DSCP, MLX5_MODI_IN_IP_DSCP},
> > + {2 * 8, 0, 0}, /* Data length. */
> > + {4 * 8, 0, 0}, /* Fragment info. */
> > + {1 * 8, MLX5_MODI_OUT_IPV4_TTL, MLX5_MODI_IN_IPV4_TTL},
> > + {3 * 8, 0, 0}, /* Protocol and checksum. */
> > + {4 * 8, MLX5_MODI_OUT_SIPV4, MLX5_MODI_IN_SIPV4},
> > + {4 * 8, MLX5_MODI_OUT_DIPV4, MLX5_MODI_IN_DIPV4},
> > + {0, 0, 0},
> > +};
> > +
> > +struct field_modify_info modify_ipv6[] = {
> > + {6 * 8, 0, 0}, /* Ver... */
> > + {2 * 8, MLX5_MODI_OUT_IPV6_HOPLIMIT,
> > MLX5_MODI_IN_IPV6_HOPLIMIT},
> > + {4 * 8, MLX5_MODI_OUT_SIPV6_127_96,
> > MLX5_MODI_IN_SIPV6_127_96},
> > + {4 * 8, MLX5_MODI_OUT_SIPV6_95_64,
> > MLX5_MODI_IN_SIPV6_95_64},
> > + {4 * 8, MLX5_MODI_OUT_SIPV6_63_32,
> > MLX5_MODI_IN_SIPV6_63_32},
> > + {4 * 8, MLX5_MODI_OUT_SIPV6_31_0,
> MLX5_MODI_IN_SIPV6_31_0},
> > + {4 * 8, MLX5_MODI_OUT_DIPV6_127_96,
> > MLX5_MODI_IN_DIPV6_127_96},
> > + {4 * 8, MLX5_MODI_OUT_DIPV6_95_64,
> > MLX5_MODI_IN_DIPV6_95_64},
> > + {4 * 8, MLX5_MODI_OUT_DIPV6_63_32,
> > MLX5_MODI_IN_DIPV6_63_32},
> > + {4 * 8, MLX5_MODI_OUT_DIPV6_31_0,
> MLX5_MODI_IN_DIPV6_31_0},
> > + {0, 0, 0},
> > +};
> > +
> > +struct field_modify_info modify_udp[] = {
> > + {2 * 8, MLX5_MODI_OUT_UDP_SPORT,
> MLX5_MODI_IN_UDP_SPORT},
> > + {2 * 8, MLX5_MODI_OUT_UDP_DPORT,
> > MLX5_MODI_IN_UDP_DPORT},
> > + {4 * 8, 0, 0}, /* Length and checksum. */
> > + {0, 0, 0},
> > +};
> > +
> > +struct field_modify_info modify_tcp[] = {
> > + {2 * 8, MLX5_MODI_OUT_TCP_SPORT,
> MLX5_MODI_IN_TCP_SPORT},
> > + {2 * 8, MLX5_MODI_OUT_TCP_DPORT,
> MLX5_MODI_IN_TCP_DPORT},
> > + {9 * 8, 0, 0}, /* Seq, ack and data offset. */
> > + {1 * 8, MLX5_MODI_OUT_TCP_FLAGS,
> MLX5_MODI_IN_TCP_FLAGS},
> > + {6 * 8, 0, 0}, /* Window, checksum and urgent pointer. */
> > + {0, 0, 0},
> > +};
> > +
> > +/**
> > + * Convert modify-header action to DV specification.
> > + *
> > + * @param[in] item
> > + * Pointer to item specification.
> > + * @param[in] field
> > + * Pointer to field modification information.
> > + * @param[in,out] resource
> > + * Pointer to the modify-header resource.
> > + * @param[in] type
> > + * Type of modification.
> > + * @param[out] error
> > + * Pointer to the error structure.
> > + *
> > + * @return
> > + * 0 on success, a negative errno value otherwise and rte_errno is set.
> > + */
> > +static int
> > +flow_dv_convert_modify_action(struct rte_flow_item *item,
> > + struct field_modify_info *field,
> > + struct mlx5_flow_dv_modify_hdr_resource
> > *resource,
> > + uint32_t type,
> > + struct rte_flow_error *error) {
> > + uint32_t bits_offset;
> > + int bits;
> > + uint32_t i = resource->actions_num;
> > + struct mlx5_modification_cmd *actions = resource->actions;
> > + int found = 0;
> > + int j;
> > + int set;
> > + const uint8_t *spec = item->spec;
> > + const uint8_t *mask = item->mask;
> > +
> > + for (bits_offset = 0; field->bits > 0; field++) {
> > + bits = field->bits;
> > + /* Scan and generate modify commands for each mask
> > segment. */
> > + for (j = 0; j < bits; ++j) {
> > + set = mask[(bits_offset + j) / 8] & (1 << (j % 8));
>
> I don't understand this logic. Let's say I would like to set the TCP source port.
> The mask item will have 0xff on the tcp.sport, the rest will be 0.
> The first field will be the TCP source port which located in 2B offset of the TCP
> header. meaning bits = 16, j = 0, base_offset = 0.
> So it looks like the mask will be checked for offset 0, while in fact the source
> port located in offset of 16bits.
>
> I also don't understand why the whole logic is in bits granularity and not
> bytes.
I will change it to bytes and simplify the logic.
>
>
> > + if (set && found && j != bits - 1)
> > + continue;
> > + if (set && !found) {
> > + if (!field->outer_type)
> > + DRV_LOG(DEBUG,
> > + "unsupported modification"
> > + " field");
> > + actions[i].type = type;
> > + actions[i].src_offset = j;
> > + actions[i].src_field = field->outer_type;
> > + found = 1;
> > + continue;
> > + }
> > + if ((set && (j == bits - 1)) || (found && !set)) {
> > + /* Reach end of mask or end of mask
> segment.
> > */
> > + actions[i].bits = j - actions[i].src_offset;
> > + if (j == bits - 1)
> > + actions[i].bits++;
> > + rte_memcpy(&actions[i].data[4 - bits / 8],
> > + &spec[bits_offset / 8], bits / 8);
> > + actions[i].data0 =
> > + rte_cpu_to_be_32(actions[i].data0);
> > + found = 0;
> > + ++i;
> > + if (i > MLX5_MODIFY_NUM)
> > + return rte_flow_error_set(error,
> > EINVAL,
> > +
> > RTE_FLOW_ERROR_TYPE_ACTION,
> > + NULL,
> > + "too many items to modify");
> > + }
> > + if (resource->actions_num != i)
> > + resource->actions_num = i;
> > + }
> > + bits_offset += field->bits;
> > + }
> > + if (!resource->actions_num)
> > + return rte_flow_error_set(error, EINVAL,
> > + RTE_FLOW_ERROR_TYPE_ACTION,
> > + NULL,
> > + "invalid modification flow item");
> > + return 0;
> > +}
> > +
> > +/**
> > + * Convert modify-header set IPv4 address action to DV specification.
> > + *
> > + * @param[in,out] resource
> > + * Pointer to the modify-header resource.
> > + * @param[in] action
> > + * Pointer to action specification.
> > + * @param[out] error
> > + * Pointer to the error structure.
> > + *
> > + * @return
> > + * 0 on success, a negative errno value otherwise and rte_errno is set.
> > + */
> > +static int
> > +flow_dv_convert_action_modify_ipv4
> > + (struct mlx5_flow_dv_modify_hdr_resource
> *resource,
> > + const struct rte_flow_action *action,
> > + struct rte_flow_error *error)
> > +{
> > + const struct rte_flow_action_set_ipv4 *conf =
> > + (const struct rte_flow_action_set_ipv4 *)(action->conf);
> > + struct rte_flow_item item = { .type = RTE_FLOW_ITEM_TYPE_IPV4 };
> > + struct rte_flow_item_ipv4 ipv4;
> > + struct rte_flow_item_ipv4 ipv4_mask;
> > +
> > + memset(&ipv4, 0, sizeof(ipv4));
> > + memset(&ipv4_mask, 0, sizeof(ipv4_mask));
> > + if (action->type == RTE_FLOW_ACTION_TYPE_SET_IPV4_SRC) {
> > + ipv4.hdr.src_addr = conf->ipv4_addr;
> > + ipv4_mask.hdr.src_addr =
> > rte_flow_item_ipv4_mask.hdr.src_addr;
> > + } else {
> > + ipv4.hdr.dst_addr = conf->ipv4_addr;
> > + ipv4_mask.hdr.dst_addr =
> > rte_flow_item_ipv4_mask.hdr.dst_addr;
> > + }
> > + item.spec = &ipv4;
> > + item.mask = &ipv4_mask;
> > + return flow_dv_convert_modify_action(&item, modify_ipv4,
> resource,
> > + MLX5_MODIFICATION_TYPE_SET,
> > error); }
> > +
> > +/**
> > + * Convert modify-header set IPv6 address action to DV specification.
> > + *
> > + * @param[in,out] resource
> > + * Pointer to the modify-header resource.
> > + * @param[in] action
> > + * Pointer to action specification.
> > + * @param[out] error
> > + * Pointer to the error structure.
> > + *
> > + * @return
> > + * 0 on success, a negative errno value otherwise and rte_errno is set.
> > + */
> > +static int
> > +flow_dv_convert_action_modify_ipv6
> > + (struct mlx5_flow_dv_modify_hdr_resource
> *resource,
> > + const struct rte_flow_action *action,
> > + struct rte_flow_error *error)
> > +{
> > + const struct rte_flow_action_set_ipv6 *conf =
> > + (const struct rte_flow_action_set_ipv6 *)(action->conf);
> > + struct rte_flow_item item = { .type = RTE_FLOW_ITEM_TYPE_IPV6 };
> > + struct rte_flow_item_ipv6 ipv6;
> > + struct rte_flow_item_ipv6 ipv6_mask;
> > +
> > + memset(&ipv6, 0, sizeof(ipv6));
> > + memset(&ipv6_mask, 0, sizeof(ipv6_mask));
> > + if (action->type == RTE_FLOW_ACTION_TYPE_SET_IPV6_SRC) {
> > + memcpy(&ipv6.hdr.src_addr, &conf->ipv6_addr,
> > + sizeof(ipv6.hdr.src_addr));
> > + memcpy(&ipv6_mask.hdr.src_addr,
> > + &rte_flow_item_ipv6_mask.hdr.src_addr,
> > + sizeof(ipv6.hdr.src_addr));
> > + } else {
> > + memcpy(&ipv6.hdr.dst_addr, &conf->ipv6_addr,
> > + sizeof(ipv6.hdr.dst_addr));
> > + memcpy(&ipv6_mask.hdr.dst_addr,
> > + &rte_flow_item_ipv6_mask.hdr.dst_addr,
> > + sizeof(ipv6.hdr.dst_addr));
> > + }
> > + item.spec = &ipv6;
> > + item.mask = &ipv6_mask;
> > + return flow_dv_convert_modify_action(&item, modify_ipv6,
> resource,
> > + MLX5_MODIFICATION_TYPE_SET,
> > error); }
> > +
> > +/**
> > + * Convert modify-header set MAC address action to DV specification.
> > + *
> > + * @param[in,out] resource
> > + * Pointer to the modify-header resource.
> > + * @param[in] action
> > + * Pointer to action specification.
> > + * @param[out] error
> > + * Pointer to the error structure.
> > + *
> > + * @return
> > + * 0 on success, a negative errno value otherwise and rte_errno is set.
> > + */
> > +static int
> > +flow_dv_convert_action_modify_mac
> > + (struct mlx5_flow_dv_modify_hdr_resource
> *resource,
> > + const struct rte_flow_action *action,
> > + struct rte_flow_error *error)
> > +{
> > + const struct rte_flow_action_set_mac *conf =
> > + (const struct rte_flow_action_set_mac *)(action->conf);
> > + struct rte_flow_item item = { .type = RTE_FLOW_ITEM_TYPE_ETH };
> > + struct rte_flow_item_eth eth;
> > + struct rte_flow_item_eth eth_mask;
> > +
> > + memset(ð, 0, sizeof(eth));
> > + memset(ð_mask, 0, sizeof(eth_mask));
> > + if (action->type == RTE_FLOW_ACTION_TYPE_SET_MAC_SRC) {
> > + memcpy(ð.src.addr_bytes, &conf->mac_addr,
> > + sizeof(eth.src.addr_bytes));
> > + memcpy(ð_mask.src.addr_bytes,
> > + &rte_flow_item_eth_mask.src.addr_bytes,
> > + sizeof(eth_mask.src.addr_bytes));
> > + } else {
> > + memcpy(ð.dst.addr_bytes, &conf->mac_addr,
> > + sizeof(eth.dst.addr_bytes));
> > + memcpy(ð_mask.dst.addr_bytes,
> > + &rte_flow_item_eth_mask.dst.addr_bytes,
> > + sizeof(eth_mask.dst.addr_bytes));
> > + }
> > + item.spec = ð
> > + item.mask = ð_mask;
> > + return flow_dv_convert_modify_action(&item, modify_eth,
> resource,
> > + MLX5_MODIFICATION_TYPE_SET,
> > error); }
> > +
> > +/**
> > + * Convert modify-header set TP action to DV specification.
> > + *
> > + * @param[in,out] resource
> > + * Pointer to the modify-header resource.
> > + * @param[in] action
> > + * Pointer to action specification.
> > + * @param[in] items
> > + * Pointer to rte_flow_item objects list.
> > + * @param[in] attr
> > + * Pointer to flow attributes structure.
> > + * @param[out] error
> > + * Pointer to the error structure.
> > + *
> > + * @return
> > + * 0 on success, a negative errno value otherwise and rte_errno is set.
> > + */
> > +static int
> > +flow_dv_convert_action_modify_tp
> > + (struct mlx5_flow_dv_modify_hdr_resource
> *resource,
> > + const struct rte_flow_action *action,
> > + const struct rte_flow_item *items,
> > + union flow_dv_attr *attr,
> > + struct rte_flow_error *error)
> > +{
> > + const struct rte_flow_action_set_tp *conf =
> > + (const struct rte_flow_action_set_tp *)(action->conf);
> > + struct rte_flow_item item;
> > + struct rte_flow_item_udp udp;
> > + struct rte_flow_item_udp udp_mask;
> > + struct rte_flow_item_tcp tcp;
> > + struct rte_flow_item_tcp tcp_mask;
> > + struct field_modify_info *field;
> > +
> > + if (!attr->valid)
> > + flow_dv_attr_init(items, attr);
> > + if (attr->udp) {
> > + memset(&udp, 0, sizeof(udp));
> > + memset(&udp_mask, 0, sizeof(udp_mask));
> > + if (action->type == RTE_FLOW_ACTION_TYPE_SET_TP_SRC) {
> > + udp.hdr.src_port = conf->port;
> > + udp_mask.hdr.src_port =
> > +
> > rte_flow_item_udp_mask.hdr.src_port;
> > + } else {
> > + udp.hdr.dst_port = conf->port;
> > + udp_mask.hdr.dst_port =
> > +
> > rte_flow_item_udp_mask.hdr.dst_port;
> > + }
> > + item.type = RTE_FLOW_ITEM_TYPE_UDP;
> > + item.spec = &udp;
> > + item.mask = &udp_mask;
> > + field = modify_udp;
> > + }
> > + if (attr->tcp) {
> > + memset(&tcp, 0, sizeof(tcp));
> > + memset(&tcp_mask, 0, sizeof(tcp_mask));
> > + if (action->type == RTE_FLOW_ACTION_TYPE_SET_TP_SRC) {
> > + tcp.hdr.src_port = conf->port;
> > + tcp_mask.hdr.src_port =
> > +
> rte_flow_item_tcp_mask.hdr.src_port;
> > + } else {
> > + tcp.hdr.dst_port = conf->port;
> > + tcp_mask.hdr.dst_port =
> > +
> rte_flow_item_tcp_mask.hdr.dst_port;
> > + }
> > + item.type = RTE_FLOW_ITEM_TYPE_TCP;
> > + item.spec = &tcp;
> > + item.mask = &tcp_mask;
> > + field = modify_tcp;
> > + }
> > + return flow_dv_convert_modify_action(&item, field, resource,
> > + MLX5_MODIFICATION_TYPE_SET,
> > error); }
> > +
> > +/**
> > + * Convert modify-header set TTL action to DV specification.
> > + *
> > + * @param[in,out] resource
> > + * Pointer to the modify-header resource.
> > + * @param[in] action
> > + * Pointer to action specification.
> > + * @param[in] items
> > + * Pointer to rte_flow_item objects list.
> > + * @param[in] attr
> > + * Pointer to flow attributes structure.
> > + * @param[out] error
> > + * Pointer to the error structure.
> > + *
> > + * @return
> > + * 0 on success, a negative errno value otherwise and rte_errno is set.
> > + */
> > +static int
> > +flow_dv_convert_action_modify_ttl
> > + (struct mlx5_flow_dv_modify_hdr_resource
> *resource,
> > + const struct rte_flow_action *action,
> > + const struct rte_flow_item *items,
> > + union flow_dv_attr *attr,
> > + struct rte_flow_error *error)
> > +{
> > + const struct rte_flow_action_set_ttl *conf =
> > + (const struct rte_flow_action_set_ttl *)(action->conf);
> > + struct rte_flow_item item;
> > + struct rte_flow_item_ipv4 ipv4;
> > + struct rte_flow_item_ipv4 ipv4_mask;
> > + struct rte_flow_item_ipv6 ipv6;
> > + struct rte_flow_item_ipv6 ipv6_mask;
> > + struct field_modify_info *field;
> > +
> > + if (!attr->valid)
> > + flow_dv_attr_init(items, attr);
> > + if (attr->ipv4) {
> > + memset(&ipv4, 0, sizeof(ipv4));
> > + memset(&ipv4_mask, 0, sizeof(ipv4_mask));
> > + ipv4.hdr.time_to_live = conf->ttl_value;
> > + ipv4_mask.hdr.time_to_live = 0xFF;
> > + item.type = RTE_FLOW_ITEM_TYPE_IPV4;
> > + item.spec = &ipv4;
> > + item.mask = &ipv4_mask;
> > + field = modify_ipv4;
> > + }
> > + if (attr->ipv6) {
> > + memset(&ipv6, 0, sizeof(ipv6));
> > + memset(&ipv6_mask, 0, sizeof(ipv6_mask));
> > + ipv6.hdr.hop_limits = conf->ttl_value;
> > + ipv6_mask.hdr.hop_limits = 0xFF;
> > + item.type = RTE_FLOW_ITEM_TYPE_IPV6;
> > + item.spec = &ipv6;
> > + item.mask = &ipv6_mask;
> > + field = modify_ipv6;
> > + }
> > + return flow_dv_convert_modify_action(&item, field, resource,
> > + MLX5_MODIFICATION_TYPE_SET,
> > error); }
> > +
> > +/**
> > + * Convert modify-header decrement TTL action to DV specification.
> > + *
> > + * @param[in,out] resource
> > + * Pointer to the modify-header resource.
> > + * @param[in] action
> > + * Pointer to action specification.
> > + * @param[in] items
> > + * Pointer to rte_flow_item objects list.
> > + * @param[in] attr
> > + * Pointer to flow attributes structure.
> > + * @param[out] error
> > + * Pointer to the error structure.
> > + *
> > + * @return
> > + * 0 on success, a negative errno value otherwise and rte_errno is set.
> > + */
> > +static int
> > +flow_dv_convert_action_modify_dec_ttl
> > + (struct mlx5_flow_dv_modify_hdr_resource
> *resource,
> > + const struct rte_flow_item *items,
> > + union flow_dv_attr *attr,
> > + struct rte_flow_error *error)
> > +{
> > + struct rte_flow_item item;
> > + struct rte_flow_item_ipv4 ipv4;
> > + struct rte_flow_item_ipv4 ipv4_mask;
> > + struct rte_flow_item_ipv6 ipv6;
> > + struct rte_flow_item_ipv6 ipv6_mask;
> > + struct field_modify_info *field;
> > +
> > + if (!attr->valid)
> > + flow_dv_attr_init(items, attr);
> > + if (attr->ipv4) {
> > + memset(&ipv4, 0, sizeof(ipv4));
> > + memset(&ipv4_mask, 0, sizeof(ipv4_mask));
> > + ipv4.hdr.time_to_live = 0xFF;
> > + ipv4_mask.hdr.time_to_live = 0xFF;
> > + item.type = RTE_FLOW_ITEM_TYPE_IPV4;
> > + item.spec = &ipv4;
> > + item.mask = &ipv4_mask;
> > + field = modify_ipv4;
> > + }
> > + if (attr->ipv6) {
> > + memset(&ipv6, 0, sizeof(ipv6));
> > + memset(&ipv6_mask, 0, sizeof(ipv6_mask));
> > + ipv6.hdr.hop_limits = 0xFF;
> > + ipv6_mask.hdr.hop_limits = 0xFF;
> > + item.type = RTE_FLOW_ITEM_TYPE_IPV6;
> > + item.spec = &ipv6;
> > + item.mask = &ipv6_mask;
> > + field = modify_ipv6;
> > + }
> > + return flow_dv_convert_modify_action(&item, field, resource,
> > + MLX5_MODIFICATION_TYPE_ADD,
> > error); }
> > +
> > /**
> > * Validate META item.
> > *
> > @@ -166,6 +664,11 @@
> > RTE_FLOW_ERROR_TYPE_ACTION,
> > NULL,
> > "can only have a single encap or"
> > " decap action in a flow");
> > + if (action_flags & MLX5_FLOW_MODIFY_HDR_ACTIONS)
> > + return rte_flow_error_set(error, EINVAL,
> > + RTE_FLOW_ERROR_TYPE_ACTION,
> > NULL,
> > + "can't have decap action after"
> > + " modify action");
> > if (attr->egress)
> > return rte_flow_error_set(error, ENOTSUP,
> >
> > RTE_FLOW_ERROR_TYPE_ATTR_EGRESS, @@ -254,6 +757,11 @@
> > RTE_FLOW_ERROR_TYPE_ACTION,
> > NULL,
> > "can only have a single decap"
> > " action in a flow");
> > + if (action_flags & MLX5_FLOW_MODIFY_HDR_ACTIONS)
> > + return rte_flow_error_set(error, EINVAL,
> > + RTE_FLOW_ERROR_TYPE_ACTION,
> > NULL,
> > + "can't have decap action after"
> > + " modify action");
> > /* decap action is valid on egress only if it is followed by encap */
> > if (attr->egress) {
> > for (; action->type != RTE_FLOW_ACTION_TYPE_END &&
> @@ -
> > 270,7 +778,6 @@
> > return 0;
> > }
> >
> > -
> > /**
> > * Find existing encap/decap resource or create and register a new one.
> > *
> > @@ -704,6 +1211,302 @@
> > }
> >
> > /**
> > + * Validate the modify-header actions.
> > + *
> > + * @param[in] action_flags
> > + * Holds the actions detected until now.
> > + * @param[in] action
> > + * Pointer to the modify action.
> > + * @param[out] error
> > + * Pointer to error structure.
> > + *
> > + * @return
> > + * 0 on success, a negative errno value otherwise and rte_errno is set.
> > + */
> > +static int
> > +flow_dv_validate_action_modify_hdr(const uint64_t action_flags,
> > + const struct rte_flow_action *action,
> > + struct rte_flow_error *error)
> > +{
> > + if (action->type != RTE_FLOW_ACTION_TYPE_DEC_TTL && !action-
> > >conf)
> > + return rte_flow_error_set(error, EINVAL,
> > +
> > RTE_FLOW_ERROR_TYPE_ACTION_CONF,
> > + NULL, "action configuration not
> set");
> > + if (action_flags & MLX5_FLOW_ENCAP_ACTIONS)
> > + return rte_flow_error_set(error, EINVAL,
> > + RTE_FLOW_ERROR_TYPE_ACTION,
> > NULL,
> > + "can't have encap action before"
> > + " modify action");
> > + return 0;
> > +}
> > +
> > +/**
> > + * Validate the modify-header MAC address actions.
> > + *
> > + * @param[in] action_flags
> > + * Holds the actions detected until now.
> > + * @param[in] action
> > + * Pointer to the modify action.
> > + * @param[in] item_flags
> > + * Holds the items detected.
> > + * @param[out] error
> > + * Pointer to error structure.
> > + *
> > + * @return
> > + * 0 on success, a negative errno value otherwise and rte_errno is set.
> > + */
> > +static int
> > +flow_dv_validate_action_modify_mac(const uint64_t action_flags,
> > + const struct rte_flow_action *action,
> > + const uint64_t item_flags,
> > + struct rte_flow_error *error)
> > +{
> > + int ret = 0;
> > +
> > + ret = flow_dv_validate_action_modify_hdr(action_flags, action,
> error);
> > + if (!ret) {
> > + if (!(item_flags & MLX5_FLOW_LAYER_L2))
> > + return rte_flow_error_set(error, EINVAL,
> > +
> > RTE_FLOW_ERROR_TYPE_ACTION,
> > + NULL,
> > + "no L2 item in pattern");
> > + if (action_flags & MLX5_FLOW_DECAP_ACTIONS)
> > + return rte_flow_error_set(error, EINVAL,
> > +
> > RTE_FLOW_ERROR_TYPE_ACTION,
> > + NULL, "after decap no L2 "
> > + "item in pattern");
> > + }
>
> I didn't get this part, why there is no L2?
> Same question for the other verifications present here.
My mistake, will remove this validation here and elsewhere.
>
> > + return ret;
> > +}
> > +
> > +/**
> > + * Validate the modify-header IPv4 address actions.
> > + *
> > + * @param[in] action_flags
> > + * Holds the actions detected until now.
> > + * @param[in] action
> > + * Pointer to the modify action.
> > + * @param[in] item_flags
> > + * Holds the items detected.
> > + * @param[out] error
> > + * Pointer to error structure.
> > + *
> > + * @return
> > + * 0 on success, a negative errno value otherwise and rte_errno is set.
> > + */
> > +static int
> > +flow_dv_validate_action_modify_ipv4(const uint64_t action_flags,
> > + const struct rte_flow_action *action,
> > + const uint64_t item_flags,
> > + struct rte_flow_error *error) {
> > + int ret = 0;
> > +
> > + ret = flow_dv_validate_action_modify_hdr(action_flags, action,
> error);
> > + if (!ret) {
> > + if (!(item_flags & MLX5_FLOW_LAYER_L3_IPV4))
> > + return rte_flow_error_set(error, EINVAL,
> > +
> > RTE_FLOW_ERROR_TYPE_ACTION,
> > + NULL,
> > + "no ipv4 item in pattern");
> > + if (action_flags & MLX5_FLOW_DECAP_ACTIONS)
> > + return rte_flow_error_set(error, EINVAL,
> > +
> > RTE_FLOW_ERROR_TYPE_ACTION,
> > + NULL, "after decap "
> > + "no ipv4 item in pattern");
> > + }
> > + return ret;
> > +}
> > +
> > +/**
> > + * Validate the modify-header IPv6 address actions.
> > + *
> > + * @param[in] action_flags
> > + * Holds the actions detected until now.
> > + * @param[in] action
> > + * Pointer to the modify action.
> > + * @param[in] item_flags
> > + * Holds the items detected.
> > + * @param[out] error
> > + * Pointer to error structure.
> > + *
> > + * @return
> > + * 0 on success, a negative errno value otherwise and rte_errno is set.
> > + */
> > +static int
> > +flow_dv_validate_action_modify_ipv6(const uint64_t action_flags,
> > + const struct rte_flow_action *action,
> > + const uint64_t item_flags,
> > + struct rte_flow_error *error) {
> > + int ret = 0;
> > +
> > + ret = flow_dv_validate_action_modify_hdr(action_flags, action,
> error);
> > + if (!ret) {
> > + if (!(item_flags & MLX5_FLOW_LAYER_L3_IPV6))
> > + return rte_flow_error_set(error, EINVAL,
> > +
> > RTE_FLOW_ERROR_TYPE_ACTION,
> > + NULL,
> > + "no ipv6 item in pattern");
> > + if (action_flags & MLX5_FLOW_DECAP_ACTIONS)
> > + return rte_flow_error_set(error, EINVAL,
> > +
> > RTE_FLOW_ERROR_TYPE_ACTION,
> > + NULL, "after decap "
> > + "no ipv6 item in pattern");
> > + }
> > + return ret;
> > +}
> > +
> > +/**
> > + * Validate the modify-header TP actions.
> > + *
> > + * @param[in] action_flags
> > + * Holds the actions detected until now.
> > + * @param[in] action
> > + * Pointer to the modify action.
> > + * @param[in] item_flags
> > + * Holds the items detected.
> > + * @param[out] error
> > + * Pointer to error structure.
> > + *
> > + * @return
> > + * 0 on success, a negative errno value otherwise and rte_errno is set.
> > + */
> > +static int
> > +flow_dv_validate_action_modify_tp(const uint64_t action_flags,
> > + const struct rte_flow_action *action,
> > + const uint64_t item_flags,
> > + struct rte_flow_error *error)
> > +{
> > + int ret = 0;
> > +
> > + ret = flow_dv_validate_action_modify_hdr(action_flags, action,
> error);
> > + if (!ret) {
> > + if (!(item_flags & MLX5_FLOW_LAYER_L4))
> > + return rte_flow_error_set(error, EINVAL,
> > +
> > RTE_FLOW_ERROR_TYPE_ACTION,
> > + NULL, "no transport layer "
> > + "in pattern");
> > + if (action_flags & MLX5_FLOW_DECAP_ACTIONS)
> > + return rte_flow_error_set(error, EINVAL,
> > +
> > RTE_FLOW_ERROR_TYPE_ACTION,
> > + NULL, "after decap no "
> > + "transport layer in pattern");
> > + }
> > + return ret;
> > +}
> > +
> > +/**
> > + * Validate the modify-header TTL actions.
> > + *
> > + * @param[in] action_flags
> > + * Holds the actions detected until now.
> > + * @param[in] action
> > + * Pointer to the modify action.
> > + * @param[in] item_flags
> > + * Holds the items detected.
> > + * @param[out] error
> > + * Pointer to error structure.
> > + *
> > + * @return
> > + * 0 on success, a negative errno value otherwise and rte_errno is set.
> > + */
> > +static int
> > +flow_dv_validate_action_modify_ttl(const uint64_t action_flags,
> > + const struct rte_flow_action *action,
> > + const uint64_t item_flags,
> > + struct rte_flow_error *error)
> > +{
> > + int ret = 0;
> > +
> > + ret = flow_dv_validate_action_modify_hdr(action_flags, action,
> error);
> > + if (!ret) {
> > + if (!(item_flags & MLX5_FLOW_LAYER_L3))
> > + return rte_flow_error_set(error, EINVAL,
> > +
> > RTE_FLOW_ERROR_TYPE_ACTION,
> > + NULL,
> > + "no IP protocol in pattern");
> > + if (action_flags & MLX5_FLOW_DECAP_ACTIONS)
> > + return rte_flow_error_set(error, EINVAL,
> > +
> > RTE_FLOW_ERROR_TYPE_ACTION,
> > + NULL, "after decap "
> > + "no IP protocol in pattern");
> > + }
> > + return ret;
> > +}
> > +
> > +/**
> > + * Find existing modify-header resource or create and register a new one.
> > + *
> > + * @param dev[in, out]
> > + * Pointer to rte_eth_dev structure.
> > + * @param[in, out] resource
> > + * Pointer to modify-header resource.
> > + * @parm[in, out] dev_flow
> > + * Pointer to the dev_flow.
> > + * @param[out] error
> > + * pointer to error structure.
> > + *
> > + * @return
> > + * 0 on success otherwise -errno and errno is set.
> > + */
> > +static int
> > +flow_dv_modify_hdr_resource_register
> > + (struct rte_eth_dev *dev,
> > + struct mlx5_flow_dv_modify_hdr_resource
> *resource,
> > + struct mlx5_flow *dev_flow,
> > + struct rte_flow_error *error)
> > +{
> > + struct priv *priv = dev->data->dev_private;
> > + struct mlx5_flow_dv_modify_hdr_resource *cache_resource;
> > +
> > + /* Lookup a matching resource from cache. */
> > + LIST_FOREACH(cache_resource, &priv->modify_cmds, next) {
> > + if (resource->ft_type == cache_resource->ft_type &&
> > + resource->actions_num == cache_resource->actions_num
> > &&
> > + !memcmp((const void *)resource->actions,
> > + (const void *)cache_resource->actions,
> > + (resource->actions_num *
> > + sizeof(resource->actions[0])))) {
> > + DRV_LOG(DEBUG, "modify-header resource %p:
> refcnt
> > %d++",
> > + (void *)cache_resource,
> > + rte_atomic32_read(&cache_resource-
> > >refcnt));
> > + rte_atomic32_inc(&cache_resource->refcnt);
> > + dev_flow->dv.modify_hdr = cache_resource;
> > + return 0;
> > + }
> > + }
> > + /* Register new modify-header resource. */
> > + cache_resource = rte_calloc(__func__, 1, sizeof(*cache_resource),
> 0);
> > + if (!cache_resource)
> > + return rte_flow_error_set(error, ENOMEM,
> > +
> > RTE_FLOW_ERROR_TYPE_UNSPECIFIED, NULL,
> > + "cannot allocate resource
> memory");
> > + *cache_resource = *resource;
> > + cache_resource->verbs_action =
> > + mlx5_glue->dv_create_flow_action_modify_header
> > + (priv->ctx,
> > + cache_resource->actions_num *
> > + sizeof(cache_resource->actions[0]),
> > + (uint64_t *)cache_resource-
> >actions,
> > + cache_resource->ft_type);
> > + if (!cache_resource->verbs_action) {
> > + rte_free(cache_resource);
> > + return rte_flow_error_set(error, ENOMEM,
> > +
> > RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
> > + NULL, "cannot create action");
> > + }
> > + rte_atomic32_init(&cache_resource->refcnt);
> > + rte_atomic32_inc(&cache_resource->refcnt);
> > + LIST_INSERT_HEAD(&priv->modify_cmds, cache_resource, next);
> > + dev_flow->dv.modify_hdr = cache_resource;
> > + DRV_LOG(DEBUG, "new modify-header resource %p: refcnt %d++",
> > + (void *)cache_resource,
> > + rte_atomic32_read(&cache_resource->refcnt));
> > + return 0;
> > +}
> > +
> > +/**
> > * Verify the @p attributes will be correctly understood by the NIC and
> store
> > * them in the @p flow if everything is correct.
> > *
> > @@ -1014,6 +1817,87 @@
> > action_flags |= MLX5_FLOW_ACTION_RAW_DECAP;
> > ++actions_n;
> > break;
> > + case RTE_FLOW_ACTION_TYPE_SET_MAC_SRC:
> > + case RTE_FLOW_ACTION_TYPE_SET_MAC_DST:
> > + ret =
> > flow_dv_validate_action_modify_mac(action_flags,
> > + actions,
> > + item_flags,
> > + error);
> > + if (ret < 0)
> > + return ret;
> > + /* Count all modify-header actions as one action. */
> > + if (!(action_flags &
> > MLX5_FLOW_MODIFY_HDR_ACTIONS))
> > + ++actions_n;
> > + action_flags |= actions->type ==
> > +
> > RTE_FLOW_ACTION_TYPE_SET_MAC_SRC ?
> > +
> > MLX5_FLOW_ACTION_SET_MAC_SRC :
> > +
> > MLX5_FLOW_ACTION_SET_MAC_DST;
> > + break;
> > +
> > + case RTE_FLOW_ACTION_TYPE_SET_IPV4_SRC:
> > + case RTE_FLOW_ACTION_TYPE_SET_IPV4_DST:
> > + ret =
> > flow_dv_validate_action_modify_ipv4(action_flags,
> > + actions,
> > + item_flags,
> > + error);
> > + if (ret < 0)
> > + return ret;
> > + /* Count all modify-header actions as one action. */
> > + if (!(action_flags &
> > MLX5_FLOW_MODIFY_HDR_ACTIONS))
> > + ++actions_n;
> > + action_flags |= actions->type ==
> > +
> > RTE_FLOW_ACTION_TYPE_SET_IPV4_SRC ?
> > +
> > MLX5_FLOW_ACTION_SET_IPV4_SRC :
> > +
> > MLX5_FLOW_ACTION_SET_IPV4_DST;
> > + break;
> > + case RTE_FLOW_ACTION_TYPE_SET_IPV6_SRC:
> > + case RTE_FLOW_ACTION_TYPE_SET_IPV6_DST:
> > + ret =
> > flow_dv_validate_action_modify_ipv6(action_flags,
> > + actions,
> > + item_flags,
> > + error);
> > + if (ret < 0)
> > + return ret;
> > + /* Count all modify-header actions as one action. */
> > + if (!(action_flags &
> > MLX5_FLOW_MODIFY_HDR_ACTIONS))
> > + ++actions_n;
> > + action_flags |= actions->type ==
> > +
> > RTE_FLOW_ACTION_TYPE_SET_IPV6_SRC ?
> > +
> > MLX5_FLOW_ACTION_SET_IPV6_SRC :
> > +
> > MLX5_FLOW_ACTION_SET_IPV6_DST;
> > + break;
> > + case RTE_FLOW_ACTION_TYPE_SET_TP_SRC:
> > + case RTE_FLOW_ACTION_TYPE_SET_TP_DST:
> > + ret =
> flow_dv_validate_action_modify_tp(action_flags,
> > + actions,
> > + item_flags,
> > + error);
> > + if (ret < 0)
> > + return ret;
> > + /* Count all modify-header actions as one action. */
> > + if (!(action_flags &
> > MLX5_FLOW_MODIFY_HDR_ACTIONS))
> > + ++actions_n;
> > + action_flags |= actions->type ==
> > +
> > RTE_FLOW_ACTION_TYPE_SET_TP_SRC ?
> > +
> > MLX5_FLOW_ACTION_SET_TP_SRC :
> > +
> > MLX5_FLOW_ACTION_SET_TP_DST;
> > + break;
> > + case RTE_FLOW_ACTION_TYPE_DEC_TTL:
> > + case RTE_FLOW_ACTION_TYPE_SET_TTL:
> > + ret =
> flow_dv_validate_action_modify_ttl(action_flags,
> > + actions,
> > + item_flags,
> > + error);
> > + if (ret < 0)
> > + return ret;
> > + /* Count all modify-header actions as one action. */
> > + if (!(action_flags &
> > MLX5_FLOW_MODIFY_HDR_ACTIONS))
> > + ++actions_n;
> > + action_flags |= actions->type ==
> > + RTE_FLOW_ACTION_TYPE_SET_TTL ?
> > +
> > MLX5_FLOW_ACTION_SET_TTL :
> > +
> > MLX5_FLOW_ACTION_DEC_TTL;
> > + break;
> > default:
> > return rte_flow_error_set(error, ENOTSUP,
> >
> > RTE_FLOW_ERROR_TYPE_ACTION,
> > @@ -1895,10 +2779,16 @@
> > },
> > };
> > int actions_n = 0;
> > + bool actions_end = false;
> > + struct mlx5_flow_dv_modify_hdr_resource res = {
> > + .ft_type = attr->egress ?
> MLX5DV_FLOW_TABLE_TYPE_NIC_TX
> > :
> > +
> > MLX5DV_FLOW_TABLE_TYPE_NIC_RX
> > + };
> > + union flow_dv_attr flow_attr = { .attr = 0 };
> >
> > if (priority == MLX5_FLOW_PRIO_RSVD)
> > priority = priv->config.flow_prio - 1;
> > - for (; actions->type != RTE_FLOW_ACTION_TYPE_END; actions++) {
> > + for (; !actions_end ; actions++) {
> > const struct rte_flow_action_queue *queue;
> > const struct rte_flow_action_rss *rss;
> > const struct rte_flow_action *action = actions; @@ -2025,6
> > +2915,77 @@
> > /* If decap is followed by encap, handle it at encap.
> */
> > action_flags |= MLX5_FLOW_ACTION_RAW_DECAP;
> > break;
> > + case RTE_FLOW_ACTION_TYPE_SET_MAC_SRC:
> > + case RTE_FLOW_ACTION_TYPE_SET_MAC_DST:
> > + if (flow_dv_convert_action_modify_mac(&res,
> actions,
> > + error))
> > + return -rte_errno;
> > + action_flags |= actions->type ==
> > +
> > RTE_FLOW_ACTION_TYPE_SET_MAC_SRC ?
> > +
> MLX5_FLOW_ACTION_SET_MAC_SRC
> > :
> > +
> MLX5_FLOW_ACTION_SET_MAC_DST;
> > + break;
> > + case RTE_FLOW_ACTION_TYPE_SET_IPV4_SRC:
> > + case RTE_FLOW_ACTION_TYPE_SET_IPV4_DST:
> > + if (flow_dv_convert_action_modify_ipv4(&res,
> actions,
> > + error))
> > + return -rte_errno;
> > + action_flags |= actions->type ==
> > +
> > RTE_FLOW_ACTION_TYPE_SET_IPV4_SRC ?
> > + MLX5_FLOW_ACTION_SET_IPV4_SRC
> :
> > +
> MLX5_FLOW_ACTION_SET_IPV4_DST;
> > + break;
> > + case RTE_FLOW_ACTION_TYPE_SET_IPV6_SRC:
> > + case RTE_FLOW_ACTION_TYPE_SET_IPV6_DST:
> > + if (flow_dv_convert_action_modify_ipv6(&res,
> actions,
> > + error))
> > + return -rte_errno;
> > + action_flags |= actions->type ==
> > +
> > RTE_FLOW_ACTION_TYPE_SET_IPV6_SRC ?
> > + MLX5_FLOW_ACTION_SET_IPV6_SRC
> :
> > +
> MLX5_FLOW_ACTION_SET_IPV6_DST;
> > + break;
> > + case RTE_FLOW_ACTION_TYPE_SET_TP_SRC:
> > + case RTE_FLOW_ACTION_TYPE_SET_TP_DST:
> > + if (flow_dv_convert_action_modify_tp(&res, actions,
> > + items, &flow_attr,
> > + error))
> > + return -rte_errno;
> > + action_flags |= actions->type ==
> > +
> > RTE_FLOW_ACTION_TYPE_SET_TP_SRC ?
> > + MLX5_FLOW_ACTION_SET_TP_SRC :
> > + MLX5_FLOW_ACTION_SET_TP_DST;
> > + break;
> > + case RTE_FLOW_ACTION_TYPE_DEC_TTL:
> > + if (flow_dv_convert_action_modify_dec_ttl(&res,
> > items,
> > + &flow_attr,
> > + error))
> > + return -rte_errno;
> > + action_flags |= MLX5_FLOW_ACTION_DEC_TTL;
> > + break;
> > + case RTE_FLOW_ACTION_TYPE_SET_TTL:
> > + if (flow_dv_convert_action_modify_ttl(&res, actions,
> > + items, &flow_attr,
> > + error))
> > + return -rte_errno;
> > + action_flags |= MLX5_FLOW_ACTION_SET_TTL;
> > + break;
> > + case RTE_FLOW_ACTION_TYPE_END:
> > + actions_end = true;
> > + if (action_flags &
> > MLX5_FLOW_MODIFY_HDR_ACTIONS) {
> > + /* create modify action if needed. */
> > + if (flow_dv_modify_hdr_resource_register
> > + (dev, &res,
> > + dev_flow,
> > + error))
> > + return -rte_errno;
> > + dev_flow->dv.actions[actions_n].type =
> > +
> > MLX5DV_FLOW_ACTION_IBV_FLOW_ACTION;
> > + dev_flow->dv.actions[actions_n].action =
> > + dev_flow->dv.modify_hdr-
> > >verbs_action;
> > + actions_n++;
> > + }
> > + break;
> > default:
> > break;
> > }
> > @@ -2309,6 +3270,37 @@
> > }
> >
> > /**
> > + * Release a modify-header resource.
> > + *
> > + * @param flow
> > + * Pointer to mlx5_flow.
> > + *
> > + * @return
> > + * 1 while a reference on it exists, 0 when freed.
> > + */
> > +static int
> > +flow_dv_modify_hdr_resource_release(struct mlx5_flow *flow) {
> > + struct mlx5_flow_dv_modify_hdr_resource *cache_resource =
> > + flow->dv.modify_hdr;
> > +
> > + assert(cache_resource->verbs_action);
> > + DRV_LOG(DEBUG, "modify-header resource %p: refcnt %d--",
> > + (void *)cache_resource,
> > + rte_atomic32_read(&cache_resource->refcnt));
> > + if (rte_atomic32_dec_and_test(&cache_resource->refcnt)) {
> > + claim_zero(mlx5_glue->destroy_flow_action
> > + (cache_resource->verbs_action));
> > + LIST_REMOVE(cache_resource, next);
> > + rte_free(cache_resource);
> > + DRV_LOG(DEBUG, "modify-header resource %p: removed",
> > + (void *)cache_resource);
> > + return 0;
> > + }
> > + return 1;
> > +}
> > +
> > +/**
> > * Remove the flow from the NIC but keeps it in memory.
> > *
> > * @param[in] dev
> > @@ -2365,6 +3357,8 @@
> > flow_dv_matcher_release(dev, dev_flow);
> > if (dev_flow->dv.encap_decap)
> >
> flow_dv_encap_decap_resource_release(dev_flow);
> > + if (dev_flow->dv.modify_hdr)
> > + flow_dv_modify_hdr_resource_release(dev_flow);
> > rte_free(dev_flow);
> > }
> > }
> > diff --git a/drivers/net/mlx5/mlx5_glue.c
> > b/drivers/net/mlx5/mlx5_glue.c index
> > dd10ad6..a806d92 100644
> > --- a/drivers/net/mlx5/mlx5_glue.c
> > +++ b/drivers/net/mlx5/mlx5_glue.c
> > @@ -479,6 +479,26 @@
> > #endif
> > }
> >
> > +static struct ibv_flow_action *
> > +mlx5_glue_dv_create_flow_action_modify_header
> > + (struct ibv_context *ctx,
> > + size_t actions_sz,
> > + uint64_t actions[],
> > + enum mlx5dv_flow_table_type
> > ft_type) { #ifdef
> > +HAVE_IBV_FLOW_DV_SUPPORT
> > + return mlx5dv_create_flow_action_modify_header(ctx, actions_sz,
> > + actions, ft_type);
> > +#else
> > + (void)ctx;
> > + (void)actions_sz;
> > + (void)actions;
> > + (void)ft_type;
> > + return NULL;
> > +#endif
> > +}
> > +
> > +
> > alignas(RTE_CACHE_LINE_SIZE)
> > const struct mlx5_glue *mlx5_glue = &(const struct mlx5_glue){
> > .version = MLX5_GLUE_VERSION,
> > @@ -535,4 +555,6 @@
> > .dv_create_flow = mlx5_glue_dv_create_flow,
> > .dv_create_flow_action_packet_reformat =
> >
> mlx5_glue_dv_create_flow_action_packet_reformat,
> > + .dv_create_flow_action_modify_header =
> > + mlx5_glue_dv_create_flow_action_modify_header,
> > };
> > diff --git a/drivers/net/mlx5/mlx5_glue.h
> > b/drivers/net/mlx5/mlx5_glue.h index 2d92ba8..9cfe836 100644
> > --- a/drivers/net/mlx5/mlx5_glue.h
> > +++ b/drivers/net/mlx5/mlx5_glue.h
> > @@ -164,6 +164,11 @@ struct mlx5_glue {
> > void *data,
> > enum mlx5dv_flow_action_packet_reformat_type
> > reformat_type,
> > enum mlx5dv_flow_table_type ft_type);
> > + struct ibv_flow_action *(*dv_create_flow_action_modify_header)
> > + (struct ibv_context *ctx,
> > + size_t actions_sz,
> > + uint64_t actions[],
> > + enum mlx5dv_flow_table_type
> > ft_type);
>
> Need to bump up the LIB_GLUE_VERSION due to this ABI change.
I will change it.
>
> > };
> >
> > const struct mlx5_glue *mlx5_glue;
> > diff --git a/drivers/net/mlx5/mlx5_prm.h b/drivers/net/mlx5/mlx5_prm.h
> > index 29742b1..545f84a 100644
> > --- a/drivers/net/mlx5/mlx5_prm.h
> > +++ b/drivers/net/mlx5/mlx5_prm.h
> > @@ -280,8 +280,17 @@ struct mlx5_cqe {
> > /* CQE format value. */
> > #define MLX5_COMPRESSED 0x3
> >
> > +/* Write a specific data value to a field. */ #define
> > +MLX5_MODIFICATION_TYPE_SET 1
> > +
> > +/* Add a specific data value to a field. */ #define
> > +MLX5_MODIFICATION_TYPE_ADD 2
> > +
> > +/* Copy a specific data value to another one in a packet. */ #define
> > +MLX5_MODIFICATION_TYPE_COPY 3
> > +
> > /* The field of packet to be modified. */ -enum
> > mlx5_modificaiton_field {
> > +enum mlx5_modification_field {
> > MLX5_MODI_OUT_SMAC_47_16 = 1,
> > MLX5_MODI_OUT_SMAC_15_0,
> > MLX5_MODI_OUT_ETHERTYPE,
> > --
> > 1.8.3.1
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] net/mlx5: modify-header support using Direct Verbs
@ 2018-12-25 11:38 3% ` Shahaf Shuler
2018-12-25 16:00 0% ` Dekel Peled
0 siblings, 1 reply; 200+ results
From: Shahaf Shuler @ 2018-12-25 11:38 UTC (permalink / raw)
To: Dekel Peled, Yongseok Koh; +Cc: dev, Ori Kam, Dekel Peled
Hi Dekel,
See some comments below,
Sunday, December 23, 2018 11:58 AM, Dekel Peled:
> Subject: [PATCH] net/mlx5: modify-header support using Direct Verbs
Maybe title can be: "support modify header using Direct Verbs"
>
> This patch implements the set of actions to support offload of packet header
> modifications to MLX5 NIC.
>
> Implamantation is based on RFC [1].
>
> [1] http://mails.dpdk.org/archives/dev/2018-November/119971.html
>
> Signed-off-by: Dekel Peled <dekelp@mellanox.com>
> ---
> drivers/net/mlx5/mlx5.h | 1 +
> drivers/net/mlx5/mlx5_flow.h | 56 ++-
> drivers/net/mlx5/mlx5_flow_dv.c | 998
> +++++++++++++++++++++++++++++++++++++++-
> drivers/net/mlx5/mlx5_glue.c | 22 +
> drivers/net/mlx5/mlx5_glue.h | 5 +
> drivers/net/mlx5/mlx5_prm.h | 11 +-
> 6 files changed, 1084 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h index
> 75aeeb2..b2fe5cb 100644
> --- a/drivers/net/mlx5/mlx5.h
> +++ b/drivers/net/mlx5/mlx5.h
> @@ -227,6 +227,7 @@ struct priv {
> LIST_HEAD(ind_tables, mlx5_ind_table_ibv) ind_tbls;
> LIST_HEAD(matchers, mlx5_flow_dv_matcher) matchers;
> LIST_HEAD(encap_decap, mlx5_flow_dv_encap_decap_resource)
> encaps_decaps;
> + LIST_HEAD(modify_cmd, mlx5_flow_dv_modify_hdr_resource)
> modify_cmds;
> uint32_t link_speed_capa; /* Link speed capabilities. */
> struct mlx5_xstats_ctrl xstats_ctrl; /* Extended stats control. */
> struct mlx5_stats_ctrl stats_ctrl; /* Stats control. */ diff --git
> a/drivers/net/mlx5/mlx5_flow.h b/drivers/net/mlx5/mlx5_flow.h index
> 4a7c052..cb1e6fd 100644
> --- a/drivers/net/mlx5/mlx5_flow.h
> +++ b/drivers/net/mlx5/mlx5_flow.h
> @@ -69,6 +69,18 @@
> (MLX5_FLOW_LAYER_INNER_L2 | MLX5_FLOW_LAYER_INNER_L3 | \
> MLX5_FLOW_LAYER_INNER_L4)
>
> +/* Layer Masks. */
> +#define MLX5_FLOW_LAYER_L2 \
> + (MLX5_FLOW_LAYER_OUTER_L2 | MLX5_FLOW_LAYER_INNER_L2)
> #define
> +MLX5_FLOW_LAYER_L3_IPV4 \
> + (MLX5_FLOW_LAYER_OUTER_L3_IPV4 |
> MLX5_FLOW_LAYER_INNER_L3_IPV4)
> +#define MLX5_FLOW_LAYER_L3_IPV6 \
> + (MLX5_FLOW_LAYER_OUTER_L3_IPV6 |
> MLX5_FLOW_LAYER_INNER_L3_IPV6)
> +#define MLX5_FLOW_LAYER_L3 \
> + (MLX5_FLOW_LAYER_L3_IPV4 | MLX5_FLOW_LAYER_L3_IPV6) #define
> +MLX5_FLOW_LAYER_L4 \
> + (MLX5_FLOW_LAYER_OUTER_L4 | MLX5_FLOW_LAYER_INNER_L4)
> +
> /* Actions */
> #define MLX5_FLOW_ACTION_DROP (1u << 0) #define
> MLX5_FLOW_ACTION_QUEUE (1u << 1) @@ -110,6 +122,17 @@
> MLX5_FLOW_ACTION_NVGRE_DECAP | \
> MLX5_FLOW_ACTION_RAW_DECAP)
>
> +#define MLX5_FLOW_MODIFY_HDR_ACTIONS
> (MLX5_FLOW_ACTION_SET_IPV4_SRC | \
> + MLX5_FLOW_ACTION_SET_IPV4_DST | \
> + MLX5_FLOW_ACTION_SET_IPV6_SRC | \
> + MLX5_FLOW_ACTION_SET_IPV6_DST | \
> + MLX5_FLOW_ACTION_SET_TP_SRC | \
> + MLX5_FLOW_ACTION_SET_TP_DST | \
> + MLX5_FLOW_ACTION_SET_TTL | \
> + MLX5_FLOW_ACTION_DEC_TTL | \
> + MLX5_FLOW_ACTION_SET_MAC_SRC | \
> + MLX5_FLOW_ACTION_SET_MAC_DST)
> +
> #ifndef IPPROTO_MPLS
> #define IPPROTO_MPLS 137
> #endif
> @@ -153,9 +176,6 @@
> /* IBV hash source bits for IPV6. */
> #define MLX5_IPV6_IBV_RX_HASH (IBV_RX_HASH_SRC_IPV6 |
> IBV_RX_HASH_DST_IPV6)
>
> -/* Max number of actions per DV flow. */ -#define
> MLX5_DV_MAX_NUMBER_OF_ACTIONS 8
> -
> enum mlx5_flow_drv_type {
> MLX5_FLOW_TYPE_MIN,
> MLX5_FLOW_TYPE_DV,
> @@ -172,9 +192,6 @@ struct mlx5_flow_dv_match_params {
> /**< Matcher value. This value is used as the mask or as a key. */ };
>
> -#define MLX5_DV_MAX_NUMBER_OF_ACTIONS 8 -#define
> MLX5_ENCAP_MAX_LEN 132
> -
> /* Matcher structure. */
> struct mlx5_flow_dv_matcher {
> LIST_ENTRY(mlx5_flow_dv_matcher) next; @@ -187,6 +204,8 @@
> struct mlx5_flow_dv_matcher {
> struct mlx5_flow_dv_match_params mask; /**< Matcher mask. */ };
>
> +#define MLX5_ENCAP_MAX_LEN 132
> +
> /* Encap/decap resource structure. */
> struct mlx5_flow_dv_encap_decap_resource {
> LIST_ENTRY(mlx5_flow_dv_encap_decap_resource) next; @@ -200,6
> +219,29 @@ struct mlx5_flow_dv_encap_decap_resource {
> uint8_t ft_type;
> };
>
> +/* Number of modification commands. */
> +#define MLX5_MODIFY_NUM 8
> +
> +/* Modify resource structure */
> +struct mlx5_flow_dv_modify_hdr_resource {
> + LIST_ENTRY(mlx5_flow_dv_modify_hdr_resource) next;
> + /* Pointer to next element. */
> + rte_atomic32_t refcnt; /**< Reference counter. */
> + struct ibv_flow_action *verbs_action;
> + /**< Verbs modify header action object. */
> + uint8_t ft_type; /**< Flow table type, Rx or Tx. */
> + uint32_t actions_num; /**< Number of modification actions. */
> + struct mlx5_modification_cmd actions[MLX5_MODIFY_NUM];
> + /**< Modification actions. */
> +};
> +
> +/*
> + * Max number of actions per DV flow.
> + * See CREATE_FLOW_MAX_FLOW_ACTIONS_SUPPORTED
> + * In rdma-core file providers/mlx5/verbs.c */ #define
> +MLX5_DV_MAX_NUMBER_OF_ACTIONS 8
> +
> /* DV flows structure. */
> struct mlx5_flow_dv {
> uint64_t hash_fields; /**< Fields that participate in the hash. */ @@ -
> 210,6 +252,8 @@ struct mlx5_flow_dv {
> /**< Holds the value that the packet is compared to. */
> struct mlx5_flow_dv_encap_decap_resource *encap_decap;
> /**< Pointer to encap/decap resource in cache. */
> + struct mlx5_flow_dv_modify_hdr_resource *modify_hdr;
> + /**< Pointer to modify header resource in cache. */
> struct ibv_flow *flow; /**< Installed flow. */ #ifdef
> HAVE_IBV_FLOW_DV_SUPPORT
> struct mlx5dv_flow_action_attr
> actions[MLX5_DV_MAX_NUMBER_OF_ACTIONS];
> diff --git a/drivers/net/mlx5/mlx5_flow_dv.c
> b/drivers/net/mlx5/mlx5_flow_dv.c index 1f31874..ad4e501 100644
> --- a/drivers/net/mlx5/mlx5_flow_dv.c
> +++ b/drivers/net/mlx5/mlx5_flow_dv.c
> @@ -35,6 +35,504 @@
>
> #ifdef HAVE_IBV_FLOW_DV_SUPPORT
>
> +union flow_dv_attr {
> + struct {
> + uint32_t valid:1;
> + uint32_t ipv4:1;
> + uint32_t ipv6:1;
> + uint32_t tcp:1;
> + uint32_t udp:1;
> + uint32_t reserved:27;
> + };
> + uint32_t attr;
> +};
> +
> +static void
> +flow_dv_attr_init(const struct rte_flow_item *item, union flow_dv_attr
> +*attr) {
Can we avoid this duplicated parsing and use the parsing done on translate when traversing the items list (using item_flags)?
it will require to do the item translate before the actions translate.
Koh, Ori what do you think?
If yes, then the swap between the item and action translate should be on a separate patch to ease the patch review.
> + for (; item->type != RTE_FLOW_ITEM_TYPE_END; item++) {
> + switch (item->type) {
> + case RTE_FLOW_ITEM_TYPE_IPV4:
> + attr->ipv4 = 1;
> + break;
> + case RTE_FLOW_ITEM_TYPE_IPV6:
> + attr->ipv6 = 1;
> + break;
> + case RTE_FLOW_ITEM_TYPE_UDP:
> + attr->udp = 1;
> + break;
> + case RTE_FLOW_ITEM_TYPE_TCP:
> + attr->tcp = 1;
> + break;
> + default:
> + break;
> + }
> + }
> + attr->valid = 1;
> +}
> +
> +struct field_modify_info {
> + int bits; /* Offset of field in protocol header, in bits. */
> + enum mlx5_modification_field outer_type;
> + enum mlx5_modification_field inner_type; };
> +
> +struct field_modify_info modify_eth[] = {
> + {4 * 8, MLX5_MODI_OUT_DMAC_47_16,
> MLX5_MODI_IN_DMAC_47_16},
> + {2 * 8, MLX5_MODI_OUT_DMAC_15_0,
> MLX5_MODI_IN_DMAC_15_0},
> + {4 * 8, MLX5_MODI_OUT_SMAC_47_16,
> MLX5_MODI_IN_SMAC_47_16},
> + {2 * 8, MLX5_MODI_OUT_SMAC_15_0, MLX5_MODI_IN_SMAC_15_0},
> + {2 * 8, MLX5_MODI_OUT_ETHERTYPE, MLX5_MODI_IN_ETHERTYPE},
> + {0, 0, 0},
> +};
> +
> +struct field_modify_info modify_ipv4[] = {
> + {1 * 8, 0, 0}, /* Ver,len. */
> + {1 * 8, MLX5_MODI_OUT_IP_DSCP, MLX5_MODI_IN_IP_DSCP},
> + {2 * 8, 0, 0}, /* Data length. */
> + {4 * 8, 0, 0}, /* Fragment info. */
> + {1 * 8, MLX5_MODI_OUT_IPV4_TTL, MLX5_MODI_IN_IPV4_TTL},
> + {3 * 8, 0, 0}, /* Protocol and checksum. */
> + {4 * 8, MLX5_MODI_OUT_SIPV4, MLX5_MODI_IN_SIPV4},
> + {4 * 8, MLX5_MODI_OUT_DIPV4, MLX5_MODI_IN_DIPV4},
> + {0, 0, 0},
> +};
> +
> +struct field_modify_info modify_ipv6[] = {
> + {6 * 8, 0, 0}, /* Ver... */
> + {2 * 8, MLX5_MODI_OUT_IPV6_HOPLIMIT,
> MLX5_MODI_IN_IPV6_HOPLIMIT},
> + {4 * 8, MLX5_MODI_OUT_SIPV6_127_96,
> MLX5_MODI_IN_SIPV6_127_96},
> + {4 * 8, MLX5_MODI_OUT_SIPV6_95_64,
> MLX5_MODI_IN_SIPV6_95_64},
> + {4 * 8, MLX5_MODI_OUT_SIPV6_63_32,
> MLX5_MODI_IN_SIPV6_63_32},
> + {4 * 8, MLX5_MODI_OUT_SIPV6_31_0, MLX5_MODI_IN_SIPV6_31_0},
> + {4 * 8, MLX5_MODI_OUT_DIPV6_127_96,
> MLX5_MODI_IN_DIPV6_127_96},
> + {4 * 8, MLX5_MODI_OUT_DIPV6_95_64,
> MLX5_MODI_IN_DIPV6_95_64},
> + {4 * 8, MLX5_MODI_OUT_DIPV6_63_32,
> MLX5_MODI_IN_DIPV6_63_32},
> + {4 * 8, MLX5_MODI_OUT_DIPV6_31_0, MLX5_MODI_IN_DIPV6_31_0},
> + {0, 0, 0},
> +};
> +
> +struct field_modify_info modify_udp[] = {
> + {2 * 8, MLX5_MODI_OUT_UDP_SPORT, MLX5_MODI_IN_UDP_SPORT},
> + {2 * 8, MLX5_MODI_OUT_UDP_DPORT,
> MLX5_MODI_IN_UDP_DPORT},
> + {4 * 8, 0, 0}, /* Length and checksum. */
> + {0, 0, 0},
> +};
> +
> +struct field_modify_info modify_tcp[] = {
> + {2 * 8, MLX5_MODI_OUT_TCP_SPORT, MLX5_MODI_IN_TCP_SPORT},
> + {2 * 8, MLX5_MODI_OUT_TCP_DPORT, MLX5_MODI_IN_TCP_DPORT},
> + {9 * 8, 0, 0}, /* Seq, ack and data offset. */
> + {1 * 8, MLX5_MODI_OUT_TCP_FLAGS, MLX5_MODI_IN_TCP_FLAGS},
> + {6 * 8, 0, 0}, /* Window, checksum and urgent pointer. */
> + {0, 0, 0},
> +};
> +
> +/**
> + * Convert modify-header action to DV specification.
> + *
> + * @param[in] item
> + * Pointer to item specification.
> + * @param[in] field
> + * Pointer to field modification information.
> + * @param[in,out] resource
> + * Pointer to the modify-header resource.
> + * @param[in] type
> + * Type of modification.
> + * @param[out] error
> + * Pointer to the error structure.
> + *
> + * @return
> + * 0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +static int
> +flow_dv_convert_modify_action(struct rte_flow_item *item,
> + struct field_modify_info *field,
> + struct mlx5_flow_dv_modify_hdr_resource
> *resource,
> + uint32_t type,
> + struct rte_flow_error *error)
> +{
> + uint32_t bits_offset;
> + int bits;
> + uint32_t i = resource->actions_num;
> + struct mlx5_modification_cmd *actions = resource->actions;
> + int found = 0;
> + int j;
> + int set;
> + const uint8_t *spec = item->spec;
> + const uint8_t *mask = item->mask;
> +
> + for (bits_offset = 0; field->bits > 0; field++) {
> + bits = field->bits;
> + /* Scan and generate modify commands for each mask
> segment. */
> + for (j = 0; j < bits; ++j) {
> + set = mask[(bits_offset + j) / 8] & (1 << (j % 8));
I don't understand this logic. Let's say I would like to set the TCP source port. The mask item will have 0xff on the tcp.sport, the rest will be 0.
The first field will be the TCP source port which located in 2B offset of the TCP header. meaning bits = 16, j = 0, base_offset = 0.
So it looks like the mask will be checked for offset 0, while in fact the source port located in offset of 16bits.
I also don't understand why the whole logic is in bits granularity and not bytes.
> + if (set && found && j != bits - 1)
> + continue;
> + if (set && !found) {
> + if (!field->outer_type)
> + DRV_LOG(DEBUG,
> + "unsupported modification"
> + " field");
> + actions[i].type = type;
> + actions[i].src_offset = j;
> + actions[i].src_field = field->outer_type;
> + found = 1;
> + continue;
> + }
> + if ((set && (j == bits - 1)) || (found && !set)) {
> + /* Reach end of mask or end of mask segment.
> */
> + actions[i].bits = j - actions[i].src_offset;
> + if (j == bits - 1)
> + actions[i].bits++;
> + rte_memcpy(&actions[i].data[4 - bits / 8],
> + &spec[bits_offset / 8], bits / 8);
> + actions[i].data0 =
> + rte_cpu_to_be_32(actions[i].data0);
> + found = 0;
> + ++i;
> + if (i > MLX5_MODIFY_NUM)
> + return rte_flow_error_set(error,
> EINVAL,
> +
> RTE_FLOW_ERROR_TYPE_ACTION,
> + NULL,
> + "too many items to modify");
> + }
> + if (resource->actions_num != i)
> + resource->actions_num = i;
> + }
> + bits_offset += field->bits;
> + }
> + if (!resource->actions_num)
> + return rte_flow_error_set(error, EINVAL,
> + RTE_FLOW_ERROR_TYPE_ACTION,
> + NULL,
> + "invalid modification flow item");
> + return 0;
> +}
> +
> +/**
> + * Convert modify-header set IPv4 address action to DV specification.
> + *
> + * @param[in,out] resource
> + * Pointer to the modify-header resource.
> + * @param[in] action
> + * Pointer to action specification.
> + * @param[out] error
> + * Pointer to the error structure.
> + *
> + * @return
> + * 0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +static int
> +flow_dv_convert_action_modify_ipv4
> + (struct mlx5_flow_dv_modify_hdr_resource *resource,
> + const struct rte_flow_action *action,
> + struct rte_flow_error *error)
> +{
> + const struct rte_flow_action_set_ipv4 *conf =
> + (const struct rte_flow_action_set_ipv4 *)(action->conf);
> + struct rte_flow_item item = { .type = RTE_FLOW_ITEM_TYPE_IPV4 };
> + struct rte_flow_item_ipv4 ipv4;
> + struct rte_flow_item_ipv4 ipv4_mask;
> +
> + memset(&ipv4, 0, sizeof(ipv4));
> + memset(&ipv4_mask, 0, sizeof(ipv4_mask));
> + if (action->type == RTE_FLOW_ACTION_TYPE_SET_IPV4_SRC) {
> + ipv4.hdr.src_addr = conf->ipv4_addr;
> + ipv4_mask.hdr.src_addr =
> rte_flow_item_ipv4_mask.hdr.src_addr;
> + } else {
> + ipv4.hdr.dst_addr = conf->ipv4_addr;
> + ipv4_mask.hdr.dst_addr =
> rte_flow_item_ipv4_mask.hdr.dst_addr;
> + }
> + item.spec = &ipv4;
> + item.mask = &ipv4_mask;
> + return flow_dv_convert_modify_action(&item, modify_ipv4, resource,
> + MLX5_MODIFICATION_TYPE_SET,
> error); }
> +
> +/**
> + * Convert modify-header set IPv6 address action to DV specification.
> + *
> + * @param[in,out] resource
> + * Pointer to the modify-header resource.
> + * @param[in] action
> + * Pointer to action specification.
> + * @param[out] error
> + * Pointer to the error structure.
> + *
> + * @return
> + * 0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +static int
> +flow_dv_convert_action_modify_ipv6
> + (struct mlx5_flow_dv_modify_hdr_resource *resource,
> + const struct rte_flow_action *action,
> + struct rte_flow_error *error)
> +{
> + const struct rte_flow_action_set_ipv6 *conf =
> + (const struct rte_flow_action_set_ipv6 *)(action->conf);
> + struct rte_flow_item item = { .type = RTE_FLOW_ITEM_TYPE_IPV6 };
> + struct rte_flow_item_ipv6 ipv6;
> + struct rte_flow_item_ipv6 ipv6_mask;
> +
> + memset(&ipv6, 0, sizeof(ipv6));
> + memset(&ipv6_mask, 0, sizeof(ipv6_mask));
> + if (action->type == RTE_FLOW_ACTION_TYPE_SET_IPV6_SRC) {
> + memcpy(&ipv6.hdr.src_addr, &conf->ipv6_addr,
> + sizeof(ipv6.hdr.src_addr));
> + memcpy(&ipv6_mask.hdr.src_addr,
> + &rte_flow_item_ipv6_mask.hdr.src_addr,
> + sizeof(ipv6.hdr.src_addr));
> + } else {
> + memcpy(&ipv6.hdr.dst_addr, &conf->ipv6_addr,
> + sizeof(ipv6.hdr.dst_addr));
> + memcpy(&ipv6_mask.hdr.dst_addr,
> + &rte_flow_item_ipv6_mask.hdr.dst_addr,
> + sizeof(ipv6.hdr.dst_addr));
> + }
> + item.spec = &ipv6;
> + item.mask = &ipv6_mask;
> + return flow_dv_convert_modify_action(&item, modify_ipv6, resource,
> + MLX5_MODIFICATION_TYPE_SET,
> error); }
> +
> +/**
> + * Convert modify-header set MAC address action to DV specification.
> + *
> + * @param[in,out] resource
> + * Pointer to the modify-header resource.
> + * @param[in] action
> + * Pointer to action specification.
> + * @param[out] error
> + * Pointer to the error structure.
> + *
> + * @return
> + * 0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +static int
> +flow_dv_convert_action_modify_mac
> + (struct mlx5_flow_dv_modify_hdr_resource *resource,
> + const struct rte_flow_action *action,
> + struct rte_flow_error *error)
> +{
> + const struct rte_flow_action_set_mac *conf =
> + (const struct rte_flow_action_set_mac *)(action->conf);
> + struct rte_flow_item item = { .type = RTE_FLOW_ITEM_TYPE_ETH };
> + struct rte_flow_item_eth eth;
> + struct rte_flow_item_eth eth_mask;
> +
> + memset(ð, 0, sizeof(eth));
> + memset(ð_mask, 0, sizeof(eth_mask));
> + if (action->type == RTE_FLOW_ACTION_TYPE_SET_MAC_SRC) {
> + memcpy(ð.src.addr_bytes, &conf->mac_addr,
> + sizeof(eth.src.addr_bytes));
> + memcpy(ð_mask.src.addr_bytes,
> + &rte_flow_item_eth_mask.src.addr_bytes,
> + sizeof(eth_mask.src.addr_bytes));
> + } else {
> + memcpy(ð.dst.addr_bytes, &conf->mac_addr,
> + sizeof(eth.dst.addr_bytes));
> + memcpy(ð_mask.dst.addr_bytes,
> + &rte_flow_item_eth_mask.dst.addr_bytes,
> + sizeof(eth_mask.dst.addr_bytes));
> + }
> + item.spec = ð
> + item.mask = ð_mask;
> + return flow_dv_convert_modify_action(&item, modify_eth, resource,
> + MLX5_MODIFICATION_TYPE_SET,
> error); }
> +
> +/**
> + * Convert modify-header set TP action to DV specification.
> + *
> + * @param[in,out] resource
> + * Pointer to the modify-header resource.
> + * @param[in] action
> + * Pointer to action specification.
> + * @param[in] items
> + * Pointer to rte_flow_item objects list.
> + * @param[in] attr
> + * Pointer to flow attributes structure.
> + * @param[out] error
> + * Pointer to the error structure.
> + *
> + * @return
> + * 0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +static int
> +flow_dv_convert_action_modify_tp
> + (struct mlx5_flow_dv_modify_hdr_resource *resource,
> + const struct rte_flow_action *action,
> + const struct rte_flow_item *items,
> + union flow_dv_attr *attr,
> + struct rte_flow_error *error)
> +{
> + const struct rte_flow_action_set_tp *conf =
> + (const struct rte_flow_action_set_tp *)(action->conf);
> + struct rte_flow_item item;
> + struct rte_flow_item_udp udp;
> + struct rte_flow_item_udp udp_mask;
> + struct rte_flow_item_tcp tcp;
> + struct rte_flow_item_tcp tcp_mask;
> + struct field_modify_info *field;
> +
> + if (!attr->valid)
> + flow_dv_attr_init(items, attr);
> + if (attr->udp) {
> + memset(&udp, 0, sizeof(udp));
> + memset(&udp_mask, 0, sizeof(udp_mask));
> + if (action->type == RTE_FLOW_ACTION_TYPE_SET_TP_SRC) {
> + udp.hdr.src_port = conf->port;
> + udp_mask.hdr.src_port =
> +
> rte_flow_item_udp_mask.hdr.src_port;
> + } else {
> + udp.hdr.dst_port = conf->port;
> + udp_mask.hdr.dst_port =
> +
> rte_flow_item_udp_mask.hdr.dst_port;
> + }
> + item.type = RTE_FLOW_ITEM_TYPE_UDP;
> + item.spec = &udp;
> + item.mask = &udp_mask;
> + field = modify_udp;
> + }
> + if (attr->tcp) {
> + memset(&tcp, 0, sizeof(tcp));
> + memset(&tcp_mask, 0, sizeof(tcp_mask));
> + if (action->type == RTE_FLOW_ACTION_TYPE_SET_TP_SRC) {
> + tcp.hdr.src_port = conf->port;
> + tcp_mask.hdr.src_port =
> + rte_flow_item_tcp_mask.hdr.src_port;
> + } else {
> + tcp.hdr.dst_port = conf->port;
> + tcp_mask.hdr.dst_port =
> + rte_flow_item_tcp_mask.hdr.dst_port;
> + }
> + item.type = RTE_FLOW_ITEM_TYPE_TCP;
> + item.spec = &tcp;
> + item.mask = &tcp_mask;
> + field = modify_tcp;
> + }
> + return flow_dv_convert_modify_action(&item, field, resource,
> + MLX5_MODIFICATION_TYPE_SET,
> error); }
> +
> +/**
> + * Convert modify-header set TTL action to DV specification.
> + *
> + * @param[in,out] resource
> + * Pointer to the modify-header resource.
> + * @param[in] action
> + * Pointer to action specification.
> + * @param[in] items
> + * Pointer to rte_flow_item objects list.
> + * @param[in] attr
> + * Pointer to flow attributes structure.
> + * @param[out] error
> + * Pointer to the error structure.
> + *
> + * @return
> + * 0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +static int
> +flow_dv_convert_action_modify_ttl
> + (struct mlx5_flow_dv_modify_hdr_resource *resource,
> + const struct rte_flow_action *action,
> + const struct rte_flow_item *items,
> + union flow_dv_attr *attr,
> + struct rte_flow_error *error)
> +{
> + const struct rte_flow_action_set_ttl *conf =
> + (const struct rte_flow_action_set_ttl *)(action->conf);
> + struct rte_flow_item item;
> + struct rte_flow_item_ipv4 ipv4;
> + struct rte_flow_item_ipv4 ipv4_mask;
> + struct rte_flow_item_ipv6 ipv6;
> + struct rte_flow_item_ipv6 ipv6_mask;
> + struct field_modify_info *field;
> +
> + if (!attr->valid)
> + flow_dv_attr_init(items, attr);
> + if (attr->ipv4) {
> + memset(&ipv4, 0, sizeof(ipv4));
> + memset(&ipv4_mask, 0, sizeof(ipv4_mask));
> + ipv4.hdr.time_to_live = conf->ttl_value;
> + ipv4_mask.hdr.time_to_live = 0xFF;
> + item.type = RTE_FLOW_ITEM_TYPE_IPV4;
> + item.spec = &ipv4;
> + item.mask = &ipv4_mask;
> + field = modify_ipv4;
> + }
> + if (attr->ipv6) {
> + memset(&ipv6, 0, sizeof(ipv6));
> + memset(&ipv6_mask, 0, sizeof(ipv6_mask));
> + ipv6.hdr.hop_limits = conf->ttl_value;
> + ipv6_mask.hdr.hop_limits = 0xFF;
> + item.type = RTE_FLOW_ITEM_TYPE_IPV6;
> + item.spec = &ipv6;
> + item.mask = &ipv6_mask;
> + field = modify_ipv6;
> + }
> + return flow_dv_convert_modify_action(&item, field, resource,
> + MLX5_MODIFICATION_TYPE_SET,
> error); }
> +
> +/**
> + * Convert modify-header decrement TTL action to DV specification.
> + *
> + * @param[in,out] resource
> + * Pointer to the modify-header resource.
> + * @param[in] action
> + * Pointer to action specification.
> + * @param[in] items
> + * Pointer to rte_flow_item objects list.
> + * @param[in] attr
> + * Pointer to flow attributes structure.
> + * @param[out] error
> + * Pointer to the error structure.
> + *
> + * @return
> + * 0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +static int
> +flow_dv_convert_action_modify_dec_ttl
> + (struct mlx5_flow_dv_modify_hdr_resource *resource,
> + const struct rte_flow_item *items,
> + union flow_dv_attr *attr,
> + struct rte_flow_error *error)
> +{
> + struct rte_flow_item item;
> + struct rte_flow_item_ipv4 ipv4;
> + struct rte_flow_item_ipv4 ipv4_mask;
> + struct rte_flow_item_ipv6 ipv6;
> + struct rte_flow_item_ipv6 ipv6_mask;
> + struct field_modify_info *field;
> +
> + if (!attr->valid)
> + flow_dv_attr_init(items, attr);
> + if (attr->ipv4) {
> + memset(&ipv4, 0, sizeof(ipv4));
> + memset(&ipv4_mask, 0, sizeof(ipv4_mask));
> + ipv4.hdr.time_to_live = 0xFF;
> + ipv4_mask.hdr.time_to_live = 0xFF;
> + item.type = RTE_FLOW_ITEM_TYPE_IPV4;
> + item.spec = &ipv4;
> + item.mask = &ipv4_mask;
> + field = modify_ipv4;
> + }
> + if (attr->ipv6) {
> + memset(&ipv6, 0, sizeof(ipv6));
> + memset(&ipv6_mask, 0, sizeof(ipv6_mask));
> + ipv6.hdr.hop_limits = 0xFF;
> + ipv6_mask.hdr.hop_limits = 0xFF;
> + item.type = RTE_FLOW_ITEM_TYPE_IPV6;
> + item.spec = &ipv6;
> + item.mask = &ipv6_mask;
> + field = modify_ipv6;
> + }
> + return flow_dv_convert_modify_action(&item, field, resource,
> + MLX5_MODIFICATION_TYPE_ADD,
> error); }
> +
> /**
> * Validate META item.
> *
> @@ -166,6 +664,11 @@
> RTE_FLOW_ERROR_TYPE_ACTION,
> NULL,
> "can only have a single encap or"
> " decap action in a flow");
> + if (action_flags & MLX5_FLOW_MODIFY_HDR_ACTIONS)
> + return rte_flow_error_set(error, EINVAL,
> + RTE_FLOW_ERROR_TYPE_ACTION,
> NULL,
> + "can't have decap action after"
> + " modify action");
> if (attr->egress)
> return rte_flow_error_set(error, ENOTSUP,
>
> RTE_FLOW_ERROR_TYPE_ATTR_EGRESS, @@ -254,6 +757,11 @@
> RTE_FLOW_ERROR_TYPE_ACTION,
> NULL,
> "can only have a single decap"
> " action in a flow");
> + if (action_flags & MLX5_FLOW_MODIFY_HDR_ACTIONS)
> + return rte_flow_error_set(error, EINVAL,
> + RTE_FLOW_ERROR_TYPE_ACTION,
> NULL,
> + "can't have decap action after"
> + " modify action");
> /* decap action is valid on egress only if it is followed by encap */
> if (attr->egress) {
> for (; action->type != RTE_FLOW_ACTION_TYPE_END && @@ -
> 270,7 +778,6 @@
> return 0;
> }
>
> -
> /**
> * Find existing encap/decap resource or create and register a new one.
> *
> @@ -704,6 +1211,302 @@
> }
>
> /**
> + * Validate the modify-header actions.
> + *
> + * @param[in] action_flags
> + * Holds the actions detected until now.
> + * @param[in] action
> + * Pointer to the modify action.
> + * @param[out] error
> + * Pointer to error structure.
> + *
> + * @return
> + * 0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +static int
> +flow_dv_validate_action_modify_hdr(const uint64_t action_flags,
> + const struct rte_flow_action *action,
> + struct rte_flow_error *error)
> +{
> + if (action->type != RTE_FLOW_ACTION_TYPE_DEC_TTL && !action-
> >conf)
> + return rte_flow_error_set(error, EINVAL,
> +
> RTE_FLOW_ERROR_TYPE_ACTION_CONF,
> + NULL, "action configuration not set");
> + if (action_flags & MLX5_FLOW_ENCAP_ACTIONS)
> + return rte_flow_error_set(error, EINVAL,
> + RTE_FLOW_ERROR_TYPE_ACTION,
> NULL,
> + "can't have encap action before"
> + " modify action");
> + return 0;
> +}
> +
> +/**
> + * Validate the modify-header MAC address actions.
> + *
> + * @param[in] action_flags
> + * Holds the actions detected until now.
> + * @param[in] action
> + * Pointer to the modify action.
> + * @param[in] item_flags
> + * Holds the items detected.
> + * @param[out] error
> + * Pointer to error structure.
> + *
> + * @return
> + * 0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +static int
> +flow_dv_validate_action_modify_mac(const uint64_t action_flags,
> + const struct rte_flow_action *action,
> + const uint64_t item_flags,
> + struct rte_flow_error *error)
> +{
> + int ret = 0;
> +
> + ret = flow_dv_validate_action_modify_hdr(action_flags, action, error);
> + if (!ret) {
> + if (!(item_flags & MLX5_FLOW_LAYER_L2))
> + return rte_flow_error_set(error, EINVAL,
> +
> RTE_FLOW_ERROR_TYPE_ACTION,
> + NULL,
> + "no L2 item in pattern");
> + if (action_flags & MLX5_FLOW_DECAP_ACTIONS)
> + return rte_flow_error_set(error, EINVAL,
> +
> RTE_FLOW_ERROR_TYPE_ACTION,
> + NULL, "after decap no L2 "
> + "item in pattern");
> + }
I didn't get this part, why there is no L2?
Same question for the other verifications present here.
> + return ret;
> +}
> +
> +/**
> + * Validate the modify-header IPv4 address actions.
> + *
> + * @param[in] action_flags
> + * Holds the actions detected until now.
> + * @param[in] action
> + * Pointer to the modify action.
> + * @param[in] item_flags
> + * Holds the items detected.
> + * @param[out] error
> + * Pointer to error structure.
> + *
> + * @return
> + * 0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +static int
> +flow_dv_validate_action_modify_ipv4(const uint64_t action_flags,
> + const struct rte_flow_action *action,
> + const uint64_t item_flags,
> + struct rte_flow_error *error)
> +{
> + int ret = 0;
> +
> + ret = flow_dv_validate_action_modify_hdr(action_flags, action, error);
> + if (!ret) {
> + if (!(item_flags & MLX5_FLOW_LAYER_L3_IPV4))
> + return rte_flow_error_set(error, EINVAL,
> +
> RTE_FLOW_ERROR_TYPE_ACTION,
> + NULL,
> + "no ipv4 item in pattern");
> + if (action_flags & MLX5_FLOW_DECAP_ACTIONS)
> + return rte_flow_error_set(error, EINVAL,
> +
> RTE_FLOW_ERROR_TYPE_ACTION,
> + NULL, "after decap "
> + "no ipv4 item in pattern");
> + }
> + return ret;
> +}
> +
> +/**
> + * Validate the modify-header IPv6 address actions.
> + *
> + * @param[in] action_flags
> + * Holds the actions detected until now.
> + * @param[in] action
> + * Pointer to the modify action.
> + * @param[in] item_flags
> + * Holds the items detected.
> + * @param[out] error
> + * Pointer to error structure.
> + *
> + * @return
> + * 0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +static int
> +flow_dv_validate_action_modify_ipv6(const uint64_t action_flags,
> + const struct rte_flow_action *action,
> + const uint64_t item_flags,
> + struct rte_flow_error *error)
> +{
> + int ret = 0;
> +
> + ret = flow_dv_validate_action_modify_hdr(action_flags, action, error);
> + if (!ret) {
> + if (!(item_flags & MLX5_FLOW_LAYER_L3_IPV6))
> + return rte_flow_error_set(error, EINVAL,
> +
> RTE_FLOW_ERROR_TYPE_ACTION,
> + NULL,
> + "no ipv6 item in pattern");
> + if (action_flags & MLX5_FLOW_DECAP_ACTIONS)
> + return rte_flow_error_set(error, EINVAL,
> +
> RTE_FLOW_ERROR_TYPE_ACTION,
> + NULL, "after decap "
> + "no ipv6 item in pattern");
> + }
> + return ret;
> +}
> +
> +/**
> + * Validate the modify-header TP actions.
> + *
> + * @param[in] action_flags
> + * Holds the actions detected until now.
> + * @param[in] action
> + * Pointer to the modify action.
> + * @param[in] item_flags
> + * Holds the items detected.
> + * @param[out] error
> + * Pointer to error structure.
> + *
> + * @return
> + * 0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +static int
> +flow_dv_validate_action_modify_tp(const uint64_t action_flags,
> + const struct rte_flow_action *action,
> + const uint64_t item_flags,
> + struct rte_flow_error *error)
> +{
> + int ret = 0;
> +
> + ret = flow_dv_validate_action_modify_hdr(action_flags, action, error);
> + if (!ret) {
> + if (!(item_flags & MLX5_FLOW_LAYER_L4))
> + return rte_flow_error_set(error, EINVAL,
> +
> RTE_FLOW_ERROR_TYPE_ACTION,
> + NULL, "no transport layer "
> + "in pattern");
> + if (action_flags & MLX5_FLOW_DECAP_ACTIONS)
> + return rte_flow_error_set(error, EINVAL,
> +
> RTE_FLOW_ERROR_TYPE_ACTION,
> + NULL, "after decap no "
> + "transport layer in pattern");
> + }
> + return ret;
> +}
> +
> +/**
> + * Validate the modify-header TTL actions.
> + *
> + * @param[in] action_flags
> + * Holds the actions detected until now.
> + * @param[in] action
> + * Pointer to the modify action.
> + * @param[in] item_flags
> + * Holds the items detected.
> + * @param[out] error
> + * Pointer to error structure.
> + *
> + * @return
> + * 0 on success, a negative errno value otherwise and rte_errno is set.
> + */
> +static int
> +flow_dv_validate_action_modify_ttl(const uint64_t action_flags,
> + const struct rte_flow_action *action,
> + const uint64_t item_flags,
> + struct rte_flow_error *error)
> +{
> + int ret = 0;
> +
> + ret = flow_dv_validate_action_modify_hdr(action_flags, action, error);
> + if (!ret) {
> + if (!(item_flags & MLX5_FLOW_LAYER_L3))
> + return rte_flow_error_set(error, EINVAL,
> +
> RTE_FLOW_ERROR_TYPE_ACTION,
> + NULL,
> + "no IP protocol in pattern");
> + if (action_flags & MLX5_FLOW_DECAP_ACTIONS)
> + return rte_flow_error_set(error, EINVAL,
> +
> RTE_FLOW_ERROR_TYPE_ACTION,
> + NULL, "after decap "
> + "no IP protocol in pattern");
> + }
> + return ret;
> +}
> +
> +/**
> + * Find existing modify-header resource or create and register a new one.
> + *
> + * @param dev[in, out]
> + * Pointer to rte_eth_dev structure.
> + * @param[in, out] resource
> + * Pointer to modify-header resource.
> + * @parm[in, out] dev_flow
> + * Pointer to the dev_flow.
> + * @param[out] error
> + * pointer to error structure.
> + *
> + * @return
> + * 0 on success otherwise -errno and errno is set.
> + */
> +static int
> +flow_dv_modify_hdr_resource_register
> + (struct rte_eth_dev *dev,
> + struct mlx5_flow_dv_modify_hdr_resource *resource,
> + struct mlx5_flow *dev_flow,
> + struct rte_flow_error *error)
> +{
> + struct priv *priv = dev->data->dev_private;
> + struct mlx5_flow_dv_modify_hdr_resource *cache_resource;
> +
> + /* Lookup a matching resource from cache. */
> + LIST_FOREACH(cache_resource, &priv->modify_cmds, next) {
> + if (resource->ft_type == cache_resource->ft_type &&
> + resource->actions_num == cache_resource->actions_num
> &&
> + !memcmp((const void *)resource->actions,
> + (const void *)cache_resource->actions,
> + (resource->actions_num *
> + sizeof(resource->actions[0])))) {
> + DRV_LOG(DEBUG, "modify-header resource %p: refcnt
> %d++",
> + (void *)cache_resource,
> + rte_atomic32_read(&cache_resource-
> >refcnt));
> + rte_atomic32_inc(&cache_resource->refcnt);
> + dev_flow->dv.modify_hdr = cache_resource;
> + return 0;
> + }
> + }
> + /* Register new modify-header resource. */
> + cache_resource = rte_calloc(__func__, 1, sizeof(*cache_resource), 0);
> + if (!cache_resource)
> + return rte_flow_error_set(error, ENOMEM,
> +
> RTE_FLOW_ERROR_TYPE_UNSPECIFIED, NULL,
> + "cannot allocate resource memory");
> + *cache_resource = *resource;
> + cache_resource->verbs_action =
> + mlx5_glue->dv_create_flow_action_modify_header
> + (priv->ctx,
> + cache_resource->actions_num *
> + sizeof(cache_resource->actions[0]),
> + (uint64_t *)cache_resource->actions,
> + cache_resource->ft_type);
> + if (!cache_resource->verbs_action) {
> + rte_free(cache_resource);
> + return rte_flow_error_set(error, ENOMEM,
> +
> RTE_FLOW_ERROR_TYPE_UNSPECIFIED,
> + NULL, "cannot create action");
> + }
> + rte_atomic32_init(&cache_resource->refcnt);
> + rte_atomic32_inc(&cache_resource->refcnt);
> + LIST_INSERT_HEAD(&priv->modify_cmds, cache_resource, next);
> + dev_flow->dv.modify_hdr = cache_resource;
> + DRV_LOG(DEBUG, "new modify-header resource %p: refcnt %d++",
> + (void *)cache_resource,
> + rte_atomic32_read(&cache_resource->refcnt));
> + return 0;
> +}
> +
> +/**
> * Verify the @p attributes will be correctly understood by the NIC and store
> * them in the @p flow if everything is correct.
> *
> @@ -1014,6 +1817,87 @@
> action_flags |= MLX5_FLOW_ACTION_RAW_DECAP;
> ++actions_n;
> break;
> + case RTE_FLOW_ACTION_TYPE_SET_MAC_SRC:
> + case RTE_FLOW_ACTION_TYPE_SET_MAC_DST:
> + ret =
> flow_dv_validate_action_modify_mac(action_flags,
> + actions,
> + item_flags,
> + error);
> + if (ret < 0)
> + return ret;
> + /* Count all modify-header actions as one action. */
> + if (!(action_flags &
> MLX5_FLOW_MODIFY_HDR_ACTIONS))
> + ++actions_n;
> + action_flags |= actions->type ==
> +
> RTE_FLOW_ACTION_TYPE_SET_MAC_SRC ?
> +
> MLX5_FLOW_ACTION_SET_MAC_SRC :
> +
> MLX5_FLOW_ACTION_SET_MAC_DST;
> + break;
> +
> + case RTE_FLOW_ACTION_TYPE_SET_IPV4_SRC:
> + case RTE_FLOW_ACTION_TYPE_SET_IPV4_DST:
> + ret =
> flow_dv_validate_action_modify_ipv4(action_flags,
> + actions,
> + item_flags,
> + error);
> + if (ret < 0)
> + return ret;
> + /* Count all modify-header actions as one action. */
> + if (!(action_flags &
> MLX5_FLOW_MODIFY_HDR_ACTIONS))
> + ++actions_n;
> + action_flags |= actions->type ==
> +
> RTE_FLOW_ACTION_TYPE_SET_IPV4_SRC ?
> +
> MLX5_FLOW_ACTION_SET_IPV4_SRC :
> +
> MLX5_FLOW_ACTION_SET_IPV4_DST;
> + break;
> + case RTE_FLOW_ACTION_TYPE_SET_IPV6_SRC:
> + case RTE_FLOW_ACTION_TYPE_SET_IPV6_DST:
> + ret =
> flow_dv_validate_action_modify_ipv6(action_flags,
> + actions,
> + item_flags,
> + error);
> + if (ret < 0)
> + return ret;
> + /* Count all modify-header actions as one action. */
> + if (!(action_flags &
> MLX5_FLOW_MODIFY_HDR_ACTIONS))
> + ++actions_n;
> + action_flags |= actions->type ==
> +
> RTE_FLOW_ACTION_TYPE_SET_IPV6_SRC ?
> +
> MLX5_FLOW_ACTION_SET_IPV6_SRC :
> +
> MLX5_FLOW_ACTION_SET_IPV6_DST;
> + break;
> + case RTE_FLOW_ACTION_TYPE_SET_TP_SRC:
> + case RTE_FLOW_ACTION_TYPE_SET_TP_DST:
> + ret = flow_dv_validate_action_modify_tp(action_flags,
> + actions,
> + item_flags,
> + error);
> + if (ret < 0)
> + return ret;
> + /* Count all modify-header actions as one action. */
> + if (!(action_flags &
> MLX5_FLOW_MODIFY_HDR_ACTIONS))
> + ++actions_n;
> + action_flags |= actions->type ==
> +
> RTE_FLOW_ACTION_TYPE_SET_TP_SRC ?
> +
> MLX5_FLOW_ACTION_SET_TP_SRC :
> +
> MLX5_FLOW_ACTION_SET_TP_DST;
> + break;
> + case RTE_FLOW_ACTION_TYPE_DEC_TTL:
> + case RTE_FLOW_ACTION_TYPE_SET_TTL:
> + ret = flow_dv_validate_action_modify_ttl(action_flags,
> + actions,
> + item_flags,
> + error);
> + if (ret < 0)
> + return ret;
> + /* Count all modify-header actions as one action. */
> + if (!(action_flags &
> MLX5_FLOW_MODIFY_HDR_ACTIONS))
> + ++actions_n;
> + action_flags |= actions->type ==
> + RTE_FLOW_ACTION_TYPE_SET_TTL ?
> +
> MLX5_FLOW_ACTION_SET_TTL :
> +
> MLX5_FLOW_ACTION_DEC_TTL;
> + break;
> default:
> return rte_flow_error_set(error, ENOTSUP,
>
> RTE_FLOW_ERROR_TYPE_ACTION,
> @@ -1895,10 +2779,16 @@
> },
> };
> int actions_n = 0;
> + bool actions_end = false;
> + struct mlx5_flow_dv_modify_hdr_resource res = {
> + .ft_type = attr->egress ? MLX5DV_FLOW_TABLE_TYPE_NIC_TX
> :
> +
> MLX5DV_FLOW_TABLE_TYPE_NIC_RX
> + };
> + union flow_dv_attr flow_attr = { .attr = 0 };
>
> if (priority == MLX5_FLOW_PRIO_RSVD)
> priority = priv->config.flow_prio - 1;
> - for (; actions->type != RTE_FLOW_ACTION_TYPE_END; actions++) {
> + for (; !actions_end ; actions++) {
> const struct rte_flow_action_queue *queue;
> const struct rte_flow_action_rss *rss;
> const struct rte_flow_action *action = actions; @@ -2025,6
> +2915,77 @@
> /* If decap is followed by encap, handle it at encap. */
> action_flags |= MLX5_FLOW_ACTION_RAW_DECAP;
> break;
> + case RTE_FLOW_ACTION_TYPE_SET_MAC_SRC:
> + case RTE_FLOW_ACTION_TYPE_SET_MAC_DST:
> + if (flow_dv_convert_action_modify_mac(&res, actions,
> + error))
> + return -rte_errno;
> + action_flags |= actions->type ==
> +
> RTE_FLOW_ACTION_TYPE_SET_MAC_SRC ?
> + MLX5_FLOW_ACTION_SET_MAC_SRC
> :
> + MLX5_FLOW_ACTION_SET_MAC_DST;
> + break;
> + case RTE_FLOW_ACTION_TYPE_SET_IPV4_SRC:
> + case RTE_FLOW_ACTION_TYPE_SET_IPV4_DST:
> + if (flow_dv_convert_action_modify_ipv4(&res, actions,
> + error))
> + return -rte_errno;
> + action_flags |= actions->type ==
> +
> RTE_FLOW_ACTION_TYPE_SET_IPV4_SRC ?
> + MLX5_FLOW_ACTION_SET_IPV4_SRC :
> + MLX5_FLOW_ACTION_SET_IPV4_DST;
> + break;
> + case RTE_FLOW_ACTION_TYPE_SET_IPV6_SRC:
> + case RTE_FLOW_ACTION_TYPE_SET_IPV6_DST:
> + if (flow_dv_convert_action_modify_ipv6(&res, actions,
> + error))
> + return -rte_errno;
> + action_flags |= actions->type ==
> +
> RTE_FLOW_ACTION_TYPE_SET_IPV6_SRC ?
> + MLX5_FLOW_ACTION_SET_IPV6_SRC :
> + MLX5_FLOW_ACTION_SET_IPV6_DST;
> + break;
> + case RTE_FLOW_ACTION_TYPE_SET_TP_SRC:
> + case RTE_FLOW_ACTION_TYPE_SET_TP_DST:
> + if (flow_dv_convert_action_modify_tp(&res, actions,
> + items, &flow_attr,
> + error))
> + return -rte_errno;
> + action_flags |= actions->type ==
> +
> RTE_FLOW_ACTION_TYPE_SET_TP_SRC ?
> + MLX5_FLOW_ACTION_SET_TP_SRC :
> + MLX5_FLOW_ACTION_SET_TP_DST;
> + break;
> + case RTE_FLOW_ACTION_TYPE_DEC_TTL:
> + if (flow_dv_convert_action_modify_dec_ttl(&res,
> items,
> + &flow_attr,
> + error))
> + return -rte_errno;
> + action_flags |= MLX5_FLOW_ACTION_DEC_TTL;
> + break;
> + case RTE_FLOW_ACTION_TYPE_SET_TTL:
> + if (flow_dv_convert_action_modify_ttl(&res, actions,
> + items, &flow_attr,
> + error))
> + return -rte_errno;
> + action_flags |= MLX5_FLOW_ACTION_SET_TTL;
> + break;
> + case RTE_FLOW_ACTION_TYPE_END:
> + actions_end = true;
> + if (action_flags &
> MLX5_FLOW_MODIFY_HDR_ACTIONS) {
> + /* create modify action if needed. */
> + if (flow_dv_modify_hdr_resource_register
> + (dev, &res,
> + dev_flow,
> + error))
> + return -rte_errno;
> + dev_flow->dv.actions[actions_n].type =
> +
> MLX5DV_FLOW_ACTION_IBV_FLOW_ACTION;
> + dev_flow->dv.actions[actions_n].action =
> + dev_flow->dv.modify_hdr-
> >verbs_action;
> + actions_n++;
> + }
> + break;
> default:
> break;
> }
> @@ -2309,6 +3270,37 @@
> }
>
> /**
> + * Release a modify-header resource.
> + *
> + * @param flow
> + * Pointer to mlx5_flow.
> + *
> + * @return
> + * 1 while a reference on it exists, 0 when freed.
> + */
> +static int
> +flow_dv_modify_hdr_resource_release(struct mlx5_flow *flow) {
> + struct mlx5_flow_dv_modify_hdr_resource *cache_resource =
> + flow->dv.modify_hdr;
> +
> + assert(cache_resource->verbs_action);
> + DRV_LOG(DEBUG, "modify-header resource %p: refcnt %d--",
> + (void *)cache_resource,
> + rte_atomic32_read(&cache_resource->refcnt));
> + if (rte_atomic32_dec_and_test(&cache_resource->refcnt)) {
> + claim_zero(mlx5_glue->destroy_flow_action
> + (cache_resource->verbs_action));
> + LIST_REMOVE(cache_resource, next);
> + rte_free(cache_resource);
> + DRV_LOG(DEBUG, "modify-header resource %p: removed",
> + (void *)cache_resource);
> + return 0;
> + }
> + return 1;
> +}
> +
> +/**
> * Remove the flow from the NIC but keeps it in memory.
> *
> * @param[in] dev
> @@ -2365,6 +3357,8 @@
> flow_dv_matcher_release(dev, dev_flow);
> if (dev_flow->dv.encap_decap)
> flow_dv_encap_decap_resource_release(dev_flow);
> + if (dev_flow->dv.modify_hdr)
> + flow_dv_modify_hdr_resource_release(dev_flow);
> rte_free(dev_flow);
> }
> }
> diff --git a/drivers/net/mlx5/mlx5_glue.c b/drivers/net/mlx5/mlx5_glue.c index
> dd10ad6..a806d92 100644
> --- a/drivers/net/mlx5/mlx5_glue.c
> +++ b/drivers/net/mlx5/mlx5_glue.c
> @@ -479,6 +479,26 @@
> #endif
> }
>
> +static struct ibv_flow_action *
> +mlx5_glue_dv_create_flow_action_modify_header
> + (struct ibv_context *ctx,
> + size_t actions_sz,
> + uint64_t actions[],
> + enum mlx5dv_flow_table_type
> ft_type) { #ifdef
> +HAVE_IBV_FLOW_DV_SUPPORT
> + return mlx5dv_create_flow_action_modify_header(ctx, actions_sz,
> + actions, ft_type);
> +#else
> + (void)ctx;
> + (void)actions_sz;
> + (void)actions;
> + (void)ft_type;
> + return NULL;
> +#endif
> +}
> +
> +
> alignas(RTE_CACHE_LINE_SIZE)
> const struct mlx5_glue *mlx5_glue = &(const struct mlx5_glue){
> .version = MLX5_GLUE_VERSION,
> @@ -535,4 +555,6 @@
> .dv_create_flow = mlx5_glue_dv_create_flow,
> .dv_create_flow_action_packet_reformat =
> mlx5_glue_dv_create_flow_action_packet_reformat,
> + .dv_create_flow_action_modify_header =
> + mlx5_glue_dv_create_flow_action_modify_header,
> };
> diff --git a/drivers/net/mlx5/mlx5_glue.h b/drivers/net/mlx5/mlx5_glue.h
> index 2d92ba8..9cfe836 100644
> --- a/drivers/net/mlx5/mlx5_glue.h
> +++ b/drivers/net/mlx5/mlx5_glue.h
> @@ -164,6 +164,11 @@ struct mlx5_glue {
> void *data,
> enum mlx5dv_flow_action_packet_reformat_type
> reformat_type,
> enum mlx5dv_flow_table_type ft_type);
> + struct ibv_flow_action *(*dv_create_flow_action_modify_header)
> + (struct ibv_context *ctx,
> + size_t actions_sz,
> + uint64_t actions[],
> + enum mlx5dv_flow_table_type
> ft_type);
Need to bump up the LIB_GLUE_VERSION due to this ABI change.
> };
>
> const struct mlx5_glue *mlx5_glue;
> diff --git a/drivers/net/mlx5/mlx5_prm.h b/drivers/net/mlx5/mlx5_prm.h index
> 29742b1..545f84a 100644
> --- a/drivers/net/mlx5/mlx5_prm.h
> +++ b/drivers/net/mlx5/mlx5_prm.h
> @@ -280,8 +280,17 @@ struct mlx5_cqe {
> /* CQE format value. */
> #define MLX5_COMPRESSED 0x3
>
> +/* Write a specific data value to a field. */ #define
> +MLX5_MODIFICATION_TYPE_SET 1
> +
> +/* Add a specific data value to a field. */ #define
> +MLX5_MODIFICATION_TYPE_ADD 2
> +
> +/* Copy a specific data value to another one in a packet. */ #define
> +MLX5_MODIFICATION_TYPE_COPY 3
> +
> /* The field of packet to be modified. */ -enum mlx5_modificaiton_field {
> +enum mlx5_modification_field {
> MLX5_MODI_OUT_SMAC_47_16 = 1,
> MLX5_MODI_OUT_SMAC_15_0,
> MLX5_MODI_OUT_ETHERTYPE,
> --
> 1.8.3.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v2 1/2] doc: clean ABI/API policy guide
@ 2018-12-21 15:57 35% ` Ferruh Yigit
2019-01-22 16:23 35% ` [dpdk-dev] [PATCH v3 1/3] " Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2018-12-21 15:57 UTC (permalink / raw)
To: Ferruh Yigit, John McNamara, Marko Kovacevic
Cc: dev, Luca Boccassi, Kevin Traynor, Yongseok Koh, Neil Horman
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>
---
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 01b36247e..19af56cd2 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.17.2
^ permalink raw reply [relevance 35%]
* Re: [dpdk-dev] [RFC 00/14] prefix network structures
2018-12-21 14:38 0% ` Wiles, Keith
@ 2018-12-21 15:14 0% ` Ferruh Yigit
2018-12-27 9:35 0% ` Olivier Matz
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2018-12-21 15:14 UTC (permalink / raw)
To: Wiles, Keith, Stephen Hemminger; +Cc: Olivier MATZ, dpdk-dev, Richardson, Bruce
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 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
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?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC 00/14] prefix network structures
2018-12-20 23:48 0% ` Stephen Hemminger
@ 2018-12-21 14:38 0% ` Wiles, Keith
2018-12-21 15:14 0% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Wiles, Keith @ 2018-12-21 14:38 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Yigit, Ferruh, Olivier MATZ, dpdk-dev, Richardson, Bruce
> 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 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
Regards,
Keith
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v3 2/2] cryptodev: change symmetric session structure
2018-12-21 13:55 1% ` [dpdk-dev] [PATCH v3 1/2] cryptodev: change queue pair configure structure Fan Zhang
@ 2018-12-21 13:55 1% ` Fan Zhang
2 siblings, 0 replies; 200+ results
From: Fan Zhang @ 2018-12-21 13:55 UTC (permalink / raw)
To: dev; +Cc: akhil.goyal, pablo.de.lara.guarch, fiona.trahe
This patch changes the symmetric session structure of cryptodev.
The symmetric session now contains extra information for secure
access purposes. The patch also includes the updates to the
PMDs, test applications, and examples to fit the change.
Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
---
app/test-crypto-perf/cperf.h | 1 +
app/test-crypto-perf/cperf_ops.c | 11 +-
app/test-crypto-perf/cperf_ops.h | 2 +-
app/test-crypto-perf/cperf_test_latency.c | 5 +-
app/test-crypto-perf/cperf_test_latency.h | 1 +
app/test-crypto-perf/cperf_test_pmd_cyclecount.c | 5 +-
app/test-crypto-perf/cperf_test_pmd_cyclecount.h | 1 +
app/test-crypto-perf/cperf_test_throughput.c | 5 +-
app/test-crypto-perf/cperf_test_throughput.h | 1 +
app/test-crypto-perf/cperf_test_verify.c | 5 +-
app/test-crypto-perf/cperf_test_verify.h | 1 +
app/test-crypto-perf/main.c | 103 ++++++----
doc/guides/rel_notes/release_19_02.rst | 14 ++
drivers/crypto/aesni_gcm/Makefile | 1 +
drivers/crypto/aesni_gcm/aesni_gcm_pmd.c | 3 +-
drivers/crypto/aesni_gcm/meson.build | 1 +
drivers/crypto/aesni_mb/Makefile | 1 +
drivers/crypto/aesni_mb/meson.build | 2 +
drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 3 +-
drivers/crypto/armv8/Makefile | 1 +
drivers/crypto/armv8/rte_armv8_pmd.c | 3 +-
drivers/crypto/kasumi/Makefile | 1 +
drivers/crypto/kasumi/meson.build | 1 +
drivers/crypto/kasumi/rte_kasumi_pmd.c | 3 +-
drivers/crypto/openssl/Makefile | 1 +
drivers/crypto/openssl/meson.build | 1 +
drivers/crypto/openssl/rte_openssl_pmd.c | 3 +-
drivers/crypto/snow3g/Makefile | 1 +
drivers/crypto/snow3g/rte_snow3g_pmd.c | 3 +-
drivers/crypto/zuc/Makefile | 1 +
drivers/crypto/zuc/meson.build | 1 +
drivers/crypto/zuc/rte_zuc_pmd.c | 3 +-
drivers/net/softnic/rte_eth_softnic_cli.c | 52 ++++-
drivers/net/softnic/rte_eth_softnic_cryptodev.c | 50 ++++-
drivers/net/softnic/rte_eth_softnic_internals.h | 3 +
examples/fips_validation/main.c | 34 +++-
examples/ip_pipeline/cli.c | 49 +++--
examples/ip_pipeline/cryptodev.c | 49 ++++-
examples/ip_pipeline/cryptodev.h | 3 +
examples/ip_pipeline/examples/flow_crypto.cli | 9 +-
examples/ipsec-secgw/ipsec-secgw.c | 48 +++--
examples/ipsec-secgw/ipsec.c | 2 +-
examples/ipsec-secgw/ipsec.h | 2 +
examples/l2fwd-crypto/main.c | 66 ++++---
examples/vhost_crypto/main.c | 13 +-
lib/librte_cryptodev/Makefile | 1 +
lib/librte_cryptodev/meson.build | 1 +
lib/librte_cryptodev/rte_cryptodev.c | 190 +++++++++++++++----
lib/librte_cryptodev/rte_cryptodev.h | 65 ++++++-
lib/librte_cryptodev/rte_cryptodev_pmd.h | 13 +-
lib/librte_cryptodev/rte_cryptodev_version.map | 2 +
lib/librte_vhost/rte_vhost_crypto.h | 9 +-
lib/librte_vhost/vhost_crypto.c | 8 +-
test/test/test_cryptodev.c | 229 ++++++++++++++---------
test/test/test_cryptodev_blockcipher.c | 7 +-
test/test/test_cryptodev_blockcipher.h | 1 +
test/test/test_event_crypto_adapter.c | 32 +++-
57 files changed, 845 insertions(+), 282 deletions(-)
diff --git a/app/test-crypto-perf/cperf.h b/app/test-crypto-perf/cperf.h
index db58228dc..2b0aad095 100644
--- a/app/test-crypto-perf/cperf.h
+++ b/app/test-crypto-perf/cperf.h
@@ -15,6 +15,7 @@ struct cperf_op_fns;
typedef void *(*cperf_constructor_t)(
struct rte_mempool *sess_mp,
+ struct rte_mempool *sess_priv_mp,
uint8_t dev_id,
uint16_t qp_id,
const struct cperf_options *options,
diff --git a/app/test-crypto-perf/cperf_ops.c b/app/test-crypto-perf/cperf_ops.c
index 44808f50a..f59568b80 100644
--- a/app/test-crypto-perf/cperf_ops.c
+++ b/app/test-crypto-perf/cperf_ops.c
@@ -469,6 +469,7 @@ cperf_set_ops_aead(struct rte_crypto_op **ops,
static struct rte_cryptodev_sym_session *
cperf_create_session(struct rte_mempool *sess_mp,
+ struct rte_mempool *priv_mp,
uint8_t dev_id,
const struct cperf_options *options,
const struct cperf_test_vector *test_vector,
@@ -505,7 +506,7 @@ cperf_create_session(struct rte_mempool *sess_mp,
}
/* create crypto session */
rte_cryptodev_sym_session_init(dev_id, sess, &cipher_xform,
- sess_mp);
+ priv_mp);
/*
* auth only
*/
@@ -533,7 +534,7 @@ cperf_create_session(struct rte_mempool *sess_mp,
}
/* create crypto session */
rte_cryptodev_sym_session_init(dev_id, sess, &auth_xform,
- sess_mp);
+ priv_mp);
/*
* cipher and auth
*/
@@ -592,12 +593,12 @@ cperf_create_session(struct rte_mempool *sess_mp,
cipher_xform.next = &auth_xform;
/* create crypto session */
rte_cryptodev_sym_session_init(dev_id,
- sess, &cipher_xform, sess_mp);
+ sess, &cipher_xform, priv_mp);
} else { /* auth then cipher */
auth_xform.next = &cipher_xform;
/* create crypto session */
rte_cryptodev_sym_session_init(dev_id,
- sess, &auth_xform, sess_mp);
+ sess, &auth_xform, priv_mp);
}
} else { /* options->op_type == CPERF_AEAD */
aead_xform.type = RTE_CRYPTO_SYM_XFORM_AEAD;
@@ -618,7 +619,7 @@ cperf_create_session(struct rte_mempool *sess_mp,
/* Create crypto session */
rte_cryptodev_sym_session_init(dev_id,
- sess, &aead_xform, sess_mp);
+ sess, &aead_xform, priv_mp);
}
return sess;
diff --git a/app/test-crypto-perf/cperf_ops.h b/app/test-crypto-perf/cperf_ops.h
index 29e109f2a..ff125d12c 100644
--- a/app/test-crypto-perf/cperf_ops.h
+++ b/app/test-crypto-perf/cperf_ops.h
@@ -13,7 +13,7 @@
typedef struct rte_cryptodev_sym_session *(*cperf_sessions_create_t)(
- struct rte_mempool *sess_mp,
+ struct rte_mempool *sess_mp, struct rte_mempool *sess_priv_mp,
uint8_t dev_id, const struct cperf_options *options,
const struct cperf_test_vector *test_vector,
uint16_t iv_offset);
diff --git a/app/test-crypto-perf/cperf_test_latency.c b/app/test-crypto-perf/cperf_test_latency.c
index c9c98dc50..0fc3a6680 100644
--- a/app/test-crypto-perf/cperf_test_latency.c
+++ b/app/test-crypto-perf/cperf_test_latency.c
@@ -62,6 +62,7 @@ cperf_latency_test_free(struct cperf_latency_ctx *ctx)
void *
cperf_latency_test_constructor(struct rte_mempool *sess_mp,
+ struct rte_mempool *sess_priv_mp,
uint8_t dev_id, uint16_t qp_id,
const struct cperf_options *options,
const struct cperf_test_vector *test_vector,
@@ -86,8 +87,8 @@ cperf_latency_test_constructor(struct rte_mempool *sess_mp,
sizeof(struct rte_crypto_sym_op) +
sizeof(struct cperf_op_result *);
- ctx->sess = op_fns->sess_create(sess_mp, dev_id, options, test_vector,
- iv_offset);
+ ctx->sess = op_fns->sess_create(sess_mp, sess_priv_mp, dev_id, options,
+ test_vector, iv_offset);
if (ctx->sess == NULL)
goto err;
diff --git a/app/test-crypto-perf/cperf_test_latency.h b/app/test-crypto-perf/cperf_test_latency.h
index d3fc3218d..ed5b0a07b 100644
--- a/app/test-crypto-perf/cperf_test_latency.h
+++ b/app/test-crypto-perf/cperf_test_latency.h
@@ -17,6 +17,7 @@
void *
cperf_latency_test_constructor(
struct rte_mempool *sess_mp,
+ struct rte_mempool *sess_priv_mp,
uint8_t dev_id,
uint16_t qp_id,
const struct cperf_options *options,
diff --git a/app/test-crypto-perf/cperf_test_pmd_cyclecount.c b/app/test-crypto-perf/cperf_test_pmd_cyclecount.c
index c8d16db6d..92af5ec90 100644
--- a/app/test-crypto-perf/cperf_test_pmd_cyclecount.c
+++ b/app/test-crypto-perf/cperf_test_pmd_cyclecount.c
@@ -80,6 +80,7 @@ cperf_pmd_cyclecount_test_free(struct cperf_pmd_cyclecount_ctx *ctx)
void *
cperf_pmd_cyclecount_test_constructor(struct rte_mempool *sess_mp,
+ struct rte_mempool *sess_priv_mp,
uint8_t dev_id, uint16_t qp_id,
const struct cperf_options *options,
const struct cperf_test_vector *test_vector,
@@ -106,8 +107,8 @@ cperf_pmd_cyclecount_test_constructor(struct rte_mempool *sess_mp,
uint16_t iv_offset = sizeof(struct rte_crypto_op) +
sizeof(struct rte_crypto_sym_op);
- ctx->sess = op_fns->sess_create(
- sess_mp, dev_id, options, test_vector, iv_offset);
+ ctx->sess = op_fns->sess_create(sess_mp, sess_priv_mp, dev_id, options,
+ test_vector, iv_offset);
if (ctx->sess == NULL)
goto err;
diff --git a/app/test-crypto-perf/cperf_test_pmd_cyclecount.h b/app/test-crypto-perf/cperf_test_pmd_cyclecount.h
index beb441991..3084038a1 100644
--- a/app/test-crypto-perf/cperf_test_pmd_cyclecount.h
+++ b/app/test-crypto-perf/cperf_test_pmd_cyclecount.h
@@ -18,6 +18,7 @@
void *
cperf_pmd_cyclecount_test_constructor(
struct rte_mempool *sess_mp,
+ struct rte_mempool *sess_priv_mp,
uint8_t dev_id,
uint16_t qp_id,
const struct cperf_options *options,
diff --git a/app/test-crypto-perf/cperf_test_throughput.c b/app/test-crypto-perf/cperf_test_throughput.c
index 8766d6e9b..2767f4ea8 100644
--- a/app/test-crypto-perf/cperf_test_throughput.c
+++ b/app/test-crypto-perf/cperf_test_throughput.c
@@ -47,6 +47,7 @@ cperf_throughput_test_free(struct cperf_throughput_ctx *ctx)
void *
cperf_throughput_test_constructor(struct rte_mempool *sess_mp,
+ struct rte_mempool *sess_priv_mp,
uint8_t dev_id, uint16_t qp_id,
const struct cperf_options *options,
const struct cperf_test_vector *test_vector,
@@ -69,8 +70,8 @@ cperf_throughput_test_constructor(struct rte_mempool *sess_mp,
uint16_t iv_offset = sizeof(struct rte_crypto_op) +
sizeof(struct rte_crypto_sym_op);
- ctx->sess = op_fns->sess_create(sess_mp, dev_id, options, test_vector,
- iv_offset);
+ ctx->sess = op_fns->sess_create(sess_mp, sess_priv_mp, dev_id, options,
+ test_vector, iv_offset);
if (ctx->sess == NULL)
goto err;
diff --git a/app/test-crypto-perf/cperf_test_throughput.h b/app/test-crypto-perf/cperf_test_throughput.h
index 439ec8e55..91e1a4b70 100644
--- a/app/test-crypto-perf/cperf_test_throughput.h
+++ b/app/test-crypto-perf/cperf_test_throughput.h
@@ -18,6 +18,7 @@
void *
cperf_throughput_test_constructor(
struct rte_mempool *sess_mp,
+ struct rte_mempool *sess_priv_mp,
uint8_t dev_id,
uint16_t qp_id,
const struct cperf_options *options,
diff --git a/app/test-crypto-perf/cperf_test_verify.c b/app/test-crypto-perf/cperf_test_verify.c
index 9134b921e..0497cf9a1 100644
--- a/app/test-crypto-perf/cperf_test_verify.c
+++ b/app/test-crypto-perf/cperf_test_verify.c
@@ -51,6 +51,7 @@ cperf_verify_test_free(struct cperf_verify_ctx *ctx)
void *
cperf_verify_test_constructor(struct rte_mempool *sess_mp,
+ struct rte_mempool *sess_priv_mp,
uint8_t dev_id, uint16_t qp_id,
const struct cperf_options *options,
const struct cperf_test_vector *test_vector,
@@ -73,8 +74,8 @@ cperf_verify_test_constructor(struct rte_mempool *sess_mp,
uint16_t iv_offset = sizeof(struct rte_crypto_op) +
sizeof(struct rte_crypto_sym_op);
- ctx->sess = op_fns->sess_create(sess_mp, dev_id, options, test_vector,
- iv_offset);
+ ctx->sess = op_fns->sess_create(sess_mp, sess_priv_mp, dev_id, options,
+ test_vector, iv_offset);
if (ctx->sess == NULL)
goto err;
diff --git a/app/test-crypto-perf/cperf_test_verify.h b/app/test-crypto-perf/cperf_test_verify.h
index 9f70ad87b..ac2192ba9 100644
--- a/app/test-crypto-perf/cperf_test_verify.h
+++ b/app/test-crypto-perf/cperf_test_verify.h
@@ -18,6 +18,7 @@
void *
cperf_verify_test_constructor(
struct rte_mempool *sess_mp,
+ struct rte_mempool *sess_priv_mp,
uint8_t dev_id,
uint16_t qp_id,
const struct cperf_options *options,
diff --git a/app/test-crypto-perf/main.c b/app/test-crypto-perf/main.c
index 38a2e429f..175c639fb 100644
--- a/app/test-crypto-perf/main.c
+++ b/app/test-crypto-perf/main.c
@@ -21,6 +21,10 @@
#include "cperf_test_verify.h"
#include "cperf_test_pmd_cyclecount.h"
+static struct {
+ struct rte_mempool *sess_mp;
+ struct rte_mempool *priv_mp;
+} session_pool_socket[RTE_MAX_NUMA_NODES];
const char *cperf_test_type_strs[] = {
[CPERF_TEST_TYPE_THROUGHPUT] = "throughput",
@@ -61,8 +65,58 @@ const struct cperf_test cperf_testmap[] = {
};
static int
-cperf_initialize_cryptodev(struct cperf_options *opts, uint8_t *enabled_cdevs,
- struct rte_mempool *session_pool_socket[])
+fill_session_pool_socket(int32_t socket_id, uint32_t session_priv_size,
+ uint32_t nb_sessions)
+{
+ char mp_name[RTE_MEMPOOL_NAMESIZE];
+ struct rte_mempool *sess_mp;
+
+ if (session_pool_socket[socket_id].priv_mp == NULL) {
+ snprintf(mp_name, RTE_MEMPOOL_NAMESIZE,
+ "priv_sess_mp_%u", socket_id);
+
+ sess_mp = rte_mempool_create(mp_name,
+ nb_sessions,
+ session_priv_size,
+ 0, 0, NULL, NULL, NULL,
+ NULL, socket_id,
+ 0);
+
+ if (sess_mp == NULL) {
+ printf("Cannot create pool \"%s\" on socket %d\n",
+ mp_name, socket_id);
+ return -ENOMEM;
+ }
+
+ printf("Allocated pool \"%s\" on socket %d\n",
+ mp_name, socket_id);
+ session_pool_socket[socket_id].priv_mp = sess_mp;
+ }
+
+ if (session_pool_socket[socket_id].sess_mp == NULL) {
+
+ snprintf(mp_name, RTE_MEMPOOL_NAMESIZE,
+ "sess_mp_%u", socket_id);
+
+ sess_mp = rte_cryptodev_sym_session_pool_create(mp_name,
+ nb_sessions, 0, 0, 0, socket_id);
+
+ if (sess_mp == NULL) {
+ printf("Cannot create pool \"%s\" on socket %d\n",
+ mp_name, socket_id);
+ return -ENOMEM;
+ }
+
+ printf("Allocated pool \"%s\" on socket %d\n",
+ mp_name, socket_id);
+ session_pool_socket[socket_id].sess_mp = sess_mp;
+ }
+
+ return 0;
+}
+
+static int
+cperf_initialize_cryptodev(struct cperf_options *opts, uint8_t *enabled_cdevs)
{
uint8_t enabled_cdev_count = 0, nb_lcores, cdev_id;
uint32_t sessions_needed = 0;
@@ -177,11 +231,11 @@ cperf_initialize_cryptodev(struct cperf_options *opts, uint8_t *enabled_cdevs,
rte_cryptodev_scheduler_slaves_get(cdev_id,
NULL);
- sessions_needed = 2 * enabled_cdev_count *
+ sessions_needed = enabled_cdev_count *
opts->nb_qps * nb_slaves;
#endif
} else
- sessions_needed = 2 * enabled_cdev_count *
+ sessions_needed = enabled_cdev_count *
opts->nb_qps;
/*
@@ -194,32 +248,15 @@ cperf_initialize_cryptodev(struct cperf_options *opts, uint8_t *enabled_cdevs,
"%u sessions\n", opts->nb_qps);
return -ENOTSUP;
}
- if (session_pool_socket[socket_id] == NULL) {
- char mp_name[RTE_MEMPOOL_NAMESIZE];
- struct rte_mempool *sess_mp;
-
- snprintf(mp_name, RTE_MEMPOOL_NAMESIZE,
- "sess_mp_%u", socket_id);
- sess_mp = rte_mempool_create(mp_name,
- sessions_needed,
- max_sess_size,
- 0,
- 0, NULL, NULL, NULL,
- NULL, socket_id,
- 0);
-
- if (sess_mp == NULL) {
- printf("Cannot create session pool on socket %d\n",
- socket_id);
- return -ENOMEM;
- }
- printf("Allocated session pool on socket %d\n", socket_id);
- session_pool_socket[socket_id] = sess_mp;
- }
+ ret = fill_session_pool_socket(socket_id, max_sess_size,
+ sessions_needed);
+ if (ret < 0)
+ return ret;
- qp_conf.mp_session = session_pool_socket[socket_id];
- qp_conf.mp_session_private = session_pool_socket[socket_id];
+ qp_conf.mp_session = session_pool_socket[socket_id].sess_mp;
+ qp_conf.mp_session_private =
+ session_pool_socket[socket_id].priv_mp;
ret = rte_cryptodev_configure(cdev_id, &conf);
if (ret < 0) {
@@ -453,10 +490,7 @@ main(int argc, char **argv)
struct cperf_options opts = {0};
struct cperf_test_vector *t_vec = NULL;
struct cperf_op_fns op_fns;
-
void *ctx[RTE_MAX_LCORE] = { };
- struct rte_mempool *session_pool_socket[RTE_MAX_NUMA_NODES] = { 0 };
-
int nb_cryptodevs = 0;
uint16_t total_nb_qps = 0;
uint8_t cdev_id, i;
@@ -489,8 +523,7 @@ main(int argc, char **argv)
goto err;
}
- nb_cryptodevs = cperf_initialize_cryptodev(&opts, enabled_cdevs,
- session_pool_socket);
+ nb_cryptodevs = cperf_initialize_cryptodev(&opts, enabled_cdevs);
if (!opts.silent)
cperf_options_dump(&opts);
@@ -558,7 +591,9 @@ main(int argc, char **argv)
uint8_t socket_id = rte_cryptodev_socket_id(cdev_id);
ctx[i] = cperf_testmap[opts.test].constructor(
- session_pool_socket[socket_id], cdev_id, qp_id,
+ session_pool_socket[socket_id].sess_mp,
+ session_pool_socket[socket_id].priv_mp,
+ cdev_id, qp_id,
&opts, t_vec, &op_fns);
if (ctx[i] == NULL) {
RTE_LOG(ERR, USER1, "Test run constructor failed\n");
diff --git a/doc/guides/rel_notes/release_19_02.rst b/doc/guides/rel_notes/release_19_02.rst
index 4420c2441..7dbba15fe 100644
--- a/doc/guides/rel_notes/release_19_02.rst
+++ b/doc/guides/rel_notes/release_19_02.rst
@@ -135,6 +135,20 @@ API Changes
mempool and symmetric session private data mempool, and the last parameter of
``rte_cryptodev_queue_pair_setup()`` is removed.
+* cryptodev: as shown in the the 18.08 deprecation notice, the structure
+ ``rte_cryptodev_sym_session`` has been updated to contain more information
+ to ensure safely accessing driver private data and user data area. The
+ creation of mempool for ``rte_cryptodev_sym_session`` objects is now enforced
+ to use new function ``rte_cryptodev_sym_session_pool_create()`` so that
+ the correct session information is set. Failed to do so will cause
+ ``rte_cryptodev_sym_session_create()`` function call failed. With the change
+ cryptodev does no longer enforce using the same mempool for symmetric session
+ header and the driver specific private data, and prevent the segmentation
+ faults caused by the incorrect access to both the session's private data and
+ user data. All cryptodev related applications (test applications and sample
+ applications) have been updated to demonstrate how to use this new
+ method.
+
ABI Changes
-----------
diff --git a/drivers/crypto/aesni_gcm/Makefile b/drivers/crypto/aesni_gcm/Makefile
index 0a5c1a872..9241ad762 100644
--- a/drivers/crypto/aesni_gcm/Makefile
+++ b/drivers/crypto/aesni_gcm/Makefile
@@ -8,6 +8,7 @@ LIB = librte_pmd_aesni_gcm.a
# build flags
CFLAGS += -O3
+CFLAGS += -DALLOW_EXPERIMENTAL_API
CFLAGS += $(WERROR_FLAGS)
# library version
diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
index abc7a6d5f..948ff0763 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
@@ -419,7 +419,8 @@ handle_completed_gcm_crypto_op(struct aesni_gcm_qp *qp,
if (op->sess_type == RTE_CRYPTO_OP_SESSIONLESS) {
memset(sess, 0, sizeof(struct aesni_gcm_session));
memset(op->sym->session, 0,
- rte_cryptodev_sym_get_header_session_size());
+ 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;
diff --git a/drivers/crypto/aesni_gcm/meson.build b/drivers/crypto/aesni_gcm/meson.build
index a02da1ef5..70f57ad73 100644
--- a/drivers/crypto/aesni_gcm/meson.build
+++ b/drivers/crypto/aesni_gcm/meson.build
@@ -8,5 +8,6 @@ else
ext_deps += lib
endif
+allow_experimental_apis = true
sources = files('aesni_gcm_pmd.c', 'aesni_gcm_pmd_ops.c')
deps += ['bus_vdev']
diff --git a/drivers/crypto/aesni_mb/Makefile b/drivers/crypto/aesni_mb/Makefile
index 806a95eb8..a6fa071ec 100644
--- a/drivers/crypto/aesni_mb/Makefile
+++ b/drivers/crypto/aesni_mb/Makefile
@@ -9,6 +9,7 @@ LIB = librte_pmd_aesni_mb.a
# build flags
CFLAGS += -O3
CFLAGS += $(WERROR_FLAGS)
+CFLAGS += -DALLOW_EXPERIMENTAL_API
# library version
LIBABIVER := 1
diff --git a/drivers/crypto/aesni_mb/meson.build b/drivers/crypto/aesni_mb/meson.build
index aae0995e5..145c3d984 100644
--- a/drivers/crypto/aesni_mb/meson.build
+++ b/drivers/crypto/aesni_mb/meson.build
@@ -9,4 +9,6 @@ else
endif
sources = files('rte_aesni_mb_pmd.c', 'rte_aesni_mb_pmd_ops.c')
+allow_experimental_apis = true
+
deps += ['bus_vdev']
diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
index b0f5c4d67..f3b270d09 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
@@ -951,7 +951,8 @@ post_process_mb_job(struct aesni_mb_qp *qp, JOB_AES_HMAC *job)
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_header_session_size());
+ 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;
diff --git a/drivers/crypto/armv8/Makefile b/drivers/crypto/armv8/Makefile
index e862af72e..f71f6b14a 100644
--- a/drivers/crypto/armv8/Makefile
+++ b/drivers/crypto/armv8/Makefile
@@ -28,6 +28,7 @@ EXPORT_MAP := rte_pmd_armv8_version.map
# external library dependencies
CFLAGS += -I$(ARMV8_CRYPTO_LIB_PATH)
CFLAGS += -I$(ARMV8_CRYPTO_LIB_PATH)/asm/include
+CFLAGS += -DALLOW_EXPERIMENTAL_API
LDLIBS += -L$(ARMV8_CRYPTO_LIB_PATH) -larmv8_crypto
LDLIBS += -lrte_eal -lrte_mbuf -lrte_mempool -lrte_ring
LDLIBS += -lrte_cryptodev
diff --git a/drivers/crypto/armv8/rte_armv8_pmd.c b/drivers/crypto/armv8/rte_armv8_pmd.c
index 3b2d7fb2f..0d4649adc 100644
--- a/drivers/crypto/armv8/rte_armv8_pmd.c
+++ b/drivers/crypto/armv8/rte_armv8_pmd.c
@@ -655,7 +655,8 @@ process_op(struct armv8_crypto_qp *qp, struct rte_crypto_op *op,
if (op->sess_type == RTE_CRYPTO_OP_SESSIONLESS) {
memset(sess, 0, sizeof(struct armv8_crypto_session));
memset(op->sym->session, 0,
- rte_cryptodev_sym_get_header_session_size());
+ rte_cryptodev_sym_get_existing_header_session_size(
+ op->sym->session));
rte_mempool_put(qp->sess_mp, sess);
rte_mempool_put(qp->sess_mp_priv, op->sym->session);
op->sym->session = NULL;
diff --git a/drivers/crypto/kasumi/Makefile b/drivers/crypto/kasumi/Makefile
index cafe94986..3de2f97ed 100644
--- a/drivers/crypto/kasumi/Makefile
+++ b/drivers/crypto/kasumi/Makefile
@@ -15,6 +15,7 @@ LIB = librte_pmd_kasumi.a
# build flags
CFLAGS += -O3
CFLAGS += $(WERROR_FLAGS)
+CFLAGS += -DALLOW_EXPERIMENTAL_API
# library version
LIBABIVER := 1
diff --git a/drivers/crypto/kasumi/meson.build b/drivers/crypto/kasumi/meson.build
index a09b0e251..80f13cd24 100644
--- a/drivers/crypto/kasumi/meson.build
+++ b/drivers/crypto/kasumi/meson.build
@@ -8,5 +8,6 @@ else
ext_deps += lib
endif
+allow_experimental_apis = true
sources = files('rte_kasumi_pmd.c', 'rte_kasumi_pmd_ops.c')
deps += ['bus_vdev']
diff --git a/drivers/crypto/kasumi/rte_kasumi_pmd.c b/drivers/crypto/kasumi/rte_kasumi_pmd.c
index 6df645a23..3abdb01a9 100644
--- a/drivers/crypto/kasumi/rte_kasumi_pmd.c
+++ b/drivers/crypto/kasumi/rte_kasumi_pmd.c
@@ -325,7 +325,8 @@ process_ops(struct rte_crypto_op **ops, struct kasumi_session *session,
if (ops[i]->sess_type == RTE_CRYPTO_OP_SESSIONLESS) {
memset(session, 0, sizeof(struct kasumi_session));
memset(ops[i]->sym->session, 0,
- rte_cryptodev_sym_get_header_session_size());
+ rte_cryptodev_sym_get_existing_header_session_size(
+ ops[i]->sym->session));
rte_mempool_put(qp->sess_mp_priv, session);
rte_mempool_put(qp->sess_mp, ops[i]->sym->session);
ops[i]->sym->session = NULL;
diff --git a/drivers/crypto/openssl/Makefile b/drivers/crypto/openssl/Makefile
index 8fe086b90..ae6c3bcac 100644
--- a/drivers/crypto/openssl/Makefile
+++ b/drivers/crypto/openssl/Makefile
@@ -9,6 +9,7 @@ LIB = librte_pmd_openssl.a
# build flags
CFLAGS += -O3
CFLAGS += $(WERROR_FLAGS)
+CFLAGS += -DALLOW_EXPERIMENTAL_API
# library version
LIBABIVER := 1
diff --git a/drivers/crypto/openssl/meson.build b/drivers/crypto/openssl/meson.build
index c2a0dd8ba..77a6596d7 100644
--- a/drivers/crypto/openssl/meson.build
+++ b/drivers/crypto/openssl/meson.build
@@ -5,6 +5,7 @@ dep = dependency('libcrypto', required: false)
if not dep.found()
build = false
endif
+allow_experimental_apis = true
deps += 'bus_vdev'
sources = files('rte_openssl_pmd.c', 'rte_openssl_pmd_ops.c')
ext_deps += dep
diff --git a/drivers/crypto/openssl/rte_openssl_pmd.c b/drivers/crypto/openssl/rte_openssl_pmd.c
index a193af642..ea5aac69e 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd.c
@@ -2020,7 +2020,8 @@ process_op(struct openssl_qp *qp, struct rte_crypto_op *op,
openssl_reset_session(sess);
memset(sess, 0, sizeof(struct openssl_session));
memset(op->sym->session, 0,
- rte_cryptodev_sym_get_header_session_size());
+ 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;
diff --git a/drivers/crypto/snow3g/Makefile b/drivers/crypto/snow3g/Makefile
index ee5027d0c..37f77dbf8 100644
--- a/drivers/crypto/snow3g/Makefile
+++ b/drivers/crypto/snow3g/Makefile
@@ -15,6 +15,7 @@ LIB = librte_pmd_snow3g.a
# build flags
CFLAGS += -O3
CFLAGS += $(WERROR_FLAGS)
+CFLAGS += -DALLOW_EXPERIMENTAL_API
# library version
LIBABIVER := 1
diff --git a/drivers/crypto/snow3g/rte_snow3g_pmd.c b/drivers/crypto/snow3g/rte_snow3g_pmd.c
index 7d131f780..5fd94b686 100644
--- a/drivers/crypto/snow3g/rte_snow3g_pmd.c
+++ b/drivers/crypto/snow3g/rte_snow3g_pmd.c
@@ -340,7 +340,8 @@ process_ops(struct rte_crypto_op **ops, struct snow3g_session *session,
if (ops[i]->sess_type == RTE_CRYPTO_OP_SESSIONLESS) {
memset(session, 0, sizeof(struct snow3g_session));
memset(ops[i]->sym->session, 0,
- rte_cryptodev_sym_get_header_session_size());
+ rte_cryptodev_sym_get_existing_header_session_size(
+ ops[i]->sym->session));
rte_mempool_put(qp->sess_mp_priv, session);
rte_mempool_put(qp->sess_mp, ops[i]->sym->session);
ops[i]->sym->session = NULL;
diff --git a/drivers/crypto/zuc/Makefile b/drivers/crypto/zuc/Makefile
index 68d84eebc..8d625aa01 100644
--- a/drivers/crypto/zuc/Makefile
+++ b/drivers/crypto/zuc/Makefile
@@ -15,6 +15,7 @@ LIB = librte_pmd_zuc.a
# build flags
CFLAGS += -O3
CFLAGS += $(WERROR_FLAGS)
+CFLAGS += -DALLOW_EXPERIMENTAL_API
# library version
LIBABIVER := 1
diff --git a/drivers/crypto/zuc/meson.build b/drivers/crypto/zuc/meson.build
index b8ca7107e..63f2a5298 100644
--- a/drivers/crypto/zuc/meson.build
+++ b/drivers/crypto/zuc/meson.build
@@ -8,5 +8,6 @@ else
ext_deps += lib
endif
+allow_experimental_apis = true
sources = files('rte_zuc_pmd.c', 'rte_zuc_pmd_ops.c')
deps += ['bus_vdev']
diff --git a/drivers/crypto/zuc/rte_zuc_pmd.c b/drivers/crypto/zuc/rte_zuc_pmd.c
index 997c2092f..637994dfd 100644
--- a/drivers/crypto/zuc/rte_zuc_pmd.c
+++ b/drivers/crypto/zuc/rte_zuc_pmd.c
@@ -327,7 +327,8 @@ process_ops(struct rte_crypto_op **ops, enum zuc_operation op_type,
if (ops[i]->sess_type == RTE_CRYPTO_OP_SESSIONLESS) {
memset(sessions[i], 0, sizeof(struct zuc_session));
memset(ops[i]->sym->session, 0,
- rte_cryptodev_sym_get_header_session_size());
+ rte_cryptodev_sym_get_existing_header_session_size(
+ ops[i]->sym->session));
rte_mempool_put(qp->sess_mp_priv, sessions[i]);
rte_mempool_put(qp->sess_mp, ops[i]->sym->session);
ops[i]->sym->session = NULL;
diff --git a/drivers/net/softnic/rte_eth_softnic_cli.c b/drivers/net/softnic/rte_eth_softnic_cli.c
index 57b623377..76136c2e2 100644
--- a/drivers/net/softnic/rte_eth_softnic_cli.c
+++ b/drivers/net/softnic/rte_eth_softnic_cli.c
@@ -1092,7 +1092,7 @@ cmd_tap(struct pmd_internals *softnic,
/**
* cryptodev <tap_name> dev <device_name> | dev_id <device_id>
- * queue <n_queues> <queue_size>
+ * queue <n_queues> <queue_size> max_sessions <n_sessions>
**/
static void
@@ -1106,7 +1106,7 @@ cmd_cryptodev(struct pmd_internals *softnic,
char *name;
memset(¶ms, 0, sizeof(params));
- if (n_tokens != 7) {
+ if (n_tokens != 9) {
snprintf(out, out_size, MSG_ARG_MISMATCH, tokens[0]);
return;
}
@@ -1145,6 +1145,19 @@ cmd_cryptodev(struct pmd_internals *softnic,
return;
}
+ if (strcmp(tokens[7], "max_sessions")) {
+ snprintf(out, out_size, MSG_ARG_NOT_FOUND,
+ "4");
+ return;
+ }
+
+ if (softnic_parser_read_uint32(¶ms.session_pool_size, tokens[8])
+ < 0) {
+ snprintf(out, out_size, MSG_ARG_INVALID,
+ "q");
+ return;
+ }
+
if (softnic_cryptodev_create(softnic, name, ¶ms) == NULL) {
snprintf(out, out_size, MSG_CMD_FAIL, tokens[0]);
return;
@@ -1739,6 +1752,41 @@ cmd_table_action_profile(struct pmd_internals *softnic,
t0 += 1;
} /* decap */
+ if (t0 < n_tokens && (strcmp(tokens[t0], "sym_crypto") == 0)) {
+ struct softnic_cryptodev *cryptodev;
+
+ if (n_tokens < t0 + 5 ||
+ strcmp(tokens[t0 + 1], "dev") ||
+ strcmp(tokens[t0 + 3], "offset")) {
+ snprintf(out, out_size, MSG_ARG_MISMATCH,
+ "table action profile sym_crypto");
+ return;
+ }
+
+ cryptodev = softnic_cryptodev_find(softnic, tokens[t0 + 2]);
+ if (cryptodev == NULL) {
+ snprintf(out, out_size, MSG_ARG_INVALID,
+ "table action profile sym_crypto");
+ return;
+ }
+
+ p.sym_crypto.cryptodev_id = cryptodev->dev_id;
+
+ if (softnic_parser_read_uint32(&p.sym_crypto.op_offset,
+ tokens[t0 + 4]) != 0) {
+ snprintf(out, out_size, MSG_ARG_INVALID,
+ "table action profile sym_crypto");
+ return;
+ }
+
+ p.sym_crypto.mp_create = cryptodev->mp_create;
+ p.sym_crypto.mp_init = cryptodev->mp_init;
+
+ p.action_mask |= 1LLU << RTE_TABLE_ACTION_SYM_CRYPTO;
+
+ t0 += 5;
+ } /* sym_crypto */
+
if (t0 < n_tokens) {
snprintf(out, out_size, MSG_ARG_MISMATCH, tokens[0]);
return;
diff --git a/drivers/net/softnic/rte_eth_softnic_cryptodev.c b/drivers/net/softnic/rte_eth_softnic_cryptodev.c
index f031d8803..18a52ed05 100644
--- a/drivers/net/softnic/rte_eth_softnic_cryptodev.c
+++ b/drivers/net/softnic/rte_eth_softnic_cryptodev.c
@@ -11,6 +11,8 @@
#include "rte_eth_softnic_internals.h"
+#define SOFTNIC_CRYPTO_SESSION_CACHE_SIZE 128
+
int
softnic_cryptodev_init(struct pmd_internals *p)
{
@@ -61,13 +63,16 @@ softnic_cryptodev_create(struct pmd_internals *p,
struct softnic_cryptodev *cryptodev;
uint32_t dev_id, i;
uint32_t socket_id;
+ uint32_t cache_size;
+ char mp_name[NAME_SIZE];
int status;
/* Check input params */
if ((name == NULL) ||
softnic_cryptodev_find(p, name) ||
(params->n_queues == 0) ||
- (params->queue_size == 0))
+ (params->queue_size == 0) ||
+ (params->session_pool_size == 0))
return NULL;
if (params->dev_name) {
@@ -83,6 +88,12 @@ softnic_cryptodev_create(struct pmd_internals *p,
dev_id = params->dev_id;
}
+ cache_size = (params->session_pool_size / 2 <
+ SOFTNIC_CRYPTO_SESSION_CACHE_SIZE) ?
+ (params->session_pool_size / 2) :
+ SOFTNIC_CRYPTO_SESSION_CACHE_SIZE;
+
+
socket_id = rte_cryptodev_socket_id(dev_id);
rte_cryptodev_info_get(dev_id, &dev_info);
@@ -119,7 +130,44 @@ softnic_cryptodev_create(struct pmd_internals *p,
cryptodev->dev_id = dev_id;
cryptodev->n_queues = params->n_queues;
+ snprintf(mp_name, NAME_SIZE, "%s_mp%u", name, dev_id);
+ cryptodev->mp_create = rte_cryptodev_sym_session_pool_create(
+ mp_name,
+ params->session_pool_size,
+ 0,
+ cache_size,
+ 0,
+ socket_id);
+ if (!cryptodev->mp_create)
+ goto error_exit;
+
+ snprintf(mp_name, NAME_SIZE, "%s_priv_mp%u", name, dev_id);
+ cryptodev->mp_init = rte_mempool_create(
+ mp_name,
+ params->session_pool_size,
+ rte_cryptodev_sym_get_private_session_size(dev_id),
+ cache_size,
+ 0,
+ NULL,
+ NULL,
+ NULL,
+ NULL,
+ socket_id,
+ 0);
+ if (!cryptodev->mp_init)
+ goto error_exit;
+
TAILQ_INSERT_TAIL(&p->cryptodev_list, cryptodev, node);
return cryptodev;
+
+error_exit:
+ if (cryptodev->mp_create)
+ rte_mempool_free(cryptodev->mp_create);
+ if (cryptodev->mp_init)
+ rte_mempool_free(cryptodev->mp_init);
+
+ free(cryptodev);
+
+ return NULL;
}
diff --git a/drivers/net/softnic/rte_eth_softnic_internals.h b/drivers/net/softnic/rte_eth_softnic_internals.h
index 31698b9f0..685058be6 100644
--- a/drivers/net/softnic/rte_eth_softnic_internals.h
+++ b/drivers/net/softnic/rte_eth_softnic_internals.h
@@ -286,6 +286,7 @@ struct softnic_cryptodev_params {
uint32_t dev_id; /**< Valid only when *dev_name* is NULL. */
uint32_t n_queues;
uint32_t queue_size;
+ uint32_t session_pool_size;
};
struct softnic_cryptodev {
@@ -293,6 +294,8 @@ struct softnic_cryptodev {
char name[NAME_SIZE];
uint16_t dev_id;
uint32_t n_queues;
+ struct rte_mempool *mp_create;
+ struct rte_mempool *mp_init;
};
TAILQ_HEAD(softnic_cryptodev_list, softnic_cryptodev);
diff --git a/examples/fips_validation/main.c b/examples/fips_validation/main.c
index 384b7a240..bd9aa9018 100644
--- a/examples/fips_validation/main.c
+++ b/examples/fips_validation/main.c
@@ -29,6 +29,8 @@ struct cryptodev_fips_validate_env {
uint32_t is_path_folder;
uint32_t dev_id;
struct rte_mempool *mpool;
+ struct rte_mempool *sess_mpool;
+ struct rte_mempool *sess_priv_mpool;
struct rte_mempool *op_pool;
struct rte_mbuf *mbuf;
struct rte_crypto_op *op;
@@ -40,6 +42,8 @@ cryptodev_fips_validate_app_int(void)
{
struct rte_cryptodev_config conf = {rte_socket_id(), 1};
struct rte_cryptodev_qp_conf qp_conf = {128, NULL, NULL};
+ uint32_t sess_sz = rte_cryptodev_sym_get_private_session_size(
+ env.dev_id);
int ret;
ret = rte_cryptodev_configure(env.dev_id, &conf);
@@ -58,6 +62,17 @@ cryptodev_fips_validate_app_int(void)
ret = -ENOMEM;
+ env.sess_mpool = rte_cryptodev_sym_session_pool_create(
+ "FIPS_SESS_MEMPOOL", 16, 0, 0, 0, rte_socket_id());
+ if (!env.sess_mpool)
+ goto error_exit;
+
+ env.sess_priv_mpool = rte_mempool_create("FIPS_SESS_PRIV_MEMPOOL",
+ 16, sess_sz, 0, 0, NULL, NULL, NULL,
+ NULL, rte_socket_id(), 0);
+ if (!env.sess_priv_mpool)
+ goto error_exit;
+
env.op_pool = rte_crypto_op_pool_create(
"FIPS_OP_POOL",
RTE_CRYPTO_OP_TYPE_SYMMETRIC,
@@ -75,10 +90,23 @@ cryptodev_fips_validate_app_int(void)
if (!env.op)
goto error_exit;
+ qp_conf.mp_session = env.sess_mpool;
+ qp_conf.mp_session_private = env.sess_priv_mpool;
+
+ ret = rte_cryptodev_queue_pair_setup(env.dev_id, 0, &qp_conf,
+ rte_socket_id());
+ if (ret < 0)
+ goto error_exit;
+
return 0;
error_exit:
+
rte_mempool_free(env.mpool);
+ if (env.sess_mpool)
+ rte_mempool_free(env.sess_mpool);
+ if (env.sess_priv_mpool)
+ rte_mempool_free(env.sess_priv_mpool);
if (env.op_pool)
rte_mempool_free(env.op_pool);
@@ -93,6 +121,8 @@ cryptodev_fips_validate_app_uninit(void)
rte_cryptodev_sym_session_clear(env.dev_id, env.sess);
rte_cryptodev_sym_session_free(env.sess);
rte_mempool_free(env.mpool);
+ rte_mempool_free(env.sess_mpool);
+ rte_mempool_free(env.sess_priv_mpool);
rte_mempool_free(env.op_pool);
}
@@ -797,12 +827,12 @@ fips_run_test(void)
if (ret < 0)
return ret;
- env.sess = rte_cryptodev_sym_session_create(env.mpool);
+ env.sess = rte_cryptodev_sym_session_create(env.sess_mpool);
if (!env.sess)
return -ENOMEM;
ret = rte_cryptodev_sym_session_init(env.dev_id,
- env.sess, &xform, env.mpool);
+ env.sess, &xform, env.sess_priv_mpool);
if (ret < 0) {
RTE_LOG(ERR, USER1, "Error %i: Init session\n",
ret);
diff --git a/examples/ip_pipeline/cli.c b/examples/ip_pipeline/cli.c
index 910386282..a92467e63 100644
--- a/examples/ip_pipeline/cli.c
+++ b/examples/ip_pipeline/cli.c
@@ -790,7 +790,8 @@ cmd_kni(char **tokens,
static const char cmd_cryptodev_help[] =
"cryptodev <cryptodev_name>\n"
" dev <device_name> | dev_id <device_id>\n"
-" queue <n_queues> <queue_size>\n";
+" queue <n_queues> <queue_size>\n"
+" max_sessions <n_sessions>";
static void
cmd_cryptodev(char **tokens,
@@ -802,7 +803,7 @@ cmd_cryptodev(char **tokens,
char *name;
memset(¶ms, 0, sizeof(params));
- if (n_tokens != 7) {
+ if (n_tokens != 9) {
snprintf(out, out_size, MSG_ARG_MISMATCH, tokens[0]);
return;
}
@@ -825,7 +826,7 @@ cmd_cryptodev(char **tokens,
if (strcmp(tokens[4], "queue")) {
snprintf(out, out_size, MSG_ARG_NOT_FOUND,
- "4");
+ "queue");
return;
}
@@ -841,6 +842,18 @@ cmd_cryptodev(char **tokens,
return;
}
+ if (strcmp(tokens[7], "max_sessions")) {
+ snprintf(out, out_size, MSG_ARG_NOT_FOUND,
+ "max_sessions");
+ return;
+ }
+
+ if (parser_read_uint32(¶ms.session_pool_size, tokens[8]) < 0) {
+ snprintf(out, out_size, MSG_ARG_INVALID,
+ "queue_size");
+ return;
+ }
+
if (cryptodev_create(name, ¶ms) == NULL) {
snprintf(out, out_size, MSG_CMD_FAIL, tokens[0]);
return;
@@ -1030,9 +1043,7 @@ static const char cmd_table_action_profile_help[] =
" stats none | pkts]\n"
" [stats pkts | bytes | both]\n"
" [time]\n"
-" [sym_crypto dev <CRYPTODEV_NAME> offset <op_offset> "
-" mempool_create <mempool_name>\n"
-" mempool_init <mempool_name>]\n"
+" [sym_crypto dev <CRYPTODEV_NAME> offset <op_offset>]\n"
" [tag]\n"
" [decap]\n";
@@ -1404,13 +1415,10 @@ cmd_table_action_profile(char **tokens,
if ((t0 < n_tokens) && (strcmp(tokens[t0], "sym_crypto") == 0)) {
struct cryptodev *cryptodev;
- struct mempool *mempool;
- if (n_tokens < t0 + 9 ||
+ if (n_tokens < t0 + 5 ||
strcmp(tokens[t0 + 1], "dev") ||
- strcmp(tokens[t0 + 3], "offset") ||
- strcmp(tokens[t0 + 5], "mempool_create") ||
- strcmp(tokens[t0 + 7], "mempool_init")) {
+ strcmp(tokens[t0 + 3], "offset")) {
snprintf(out, out_size, MSG_ARG_MISMATCH,
"table action profile sym_crypto");
return;
@@ -1432,25 +1440,12 @@ cmd_table_action_profile(char **tokens,
return;
}
- mempool = mempool_find(tokens[t0 + 6]);
- if (mempool == NULL) {
- snprintf(out, out_size, MSG_ARG_INVALID,
- "table action profile sym_crypto");
- return;
- }
- p.sym_crypto.mp_create = mempool->m;
-
- mempool = mempool_find(tokens[t0 + 8]);
- if (mempool == NULL) {
- snprintf(out, out_size, MSG_ARG_INVALID,
- "table action profile sym_crypto");
- return;
- }
- p.sym_crypto.mp_init = mempool->m;
+ p.sym_crypto.mp_create = cryptodev->mp_create;
+ p.sym_crypto.mp_init = cryptodev->mp_init;
p.action_mask |= 1LLU << RTE_TABLE_ACTION_SYM_CRYPTO;
- t0 += 9;
+ t0 += 5;
} /* sym_crypto */
if ((t0 < n_tokens) && (strcmp(tokens[t0], "tag") == 0)) {
diff --git a/examples/ip_pipeline/cryptodev.c b/examples/ip_pipeline/cryptodev.c
index b365810de..ac1e38d6a 100644
--- a/examples/ip_pipeline/cryptodev.c
+++ b/examples/ip_pipeline/cryptodev.c
@@ -11,6 +11,8 @@
#include "cryptodev.h"
+#define PIPELINE_CRYPTO_SESSION_CACHE_SIZE 128
+
static struct cryptodev_list cryptodev_list;
int
@@ -53,13 +55,16 @@ cryptodev_create(const char *name, struct cryptodev_params *params)
struct cryptodev *cryptodev;
uint32_t dev_id, i;
uint32_t socket_id;
+ uint32_t cache_size;
+ char mp_name[NAME_SIZE];
int status;
/* Check input params */
if ((name == NULL) ||
cryptodev_find(name) ||
(params->n_queues == 0) ||
- (params->queue_size == 0))
+ (params->queue_size == 0) ||
+ (params->session_pool_size == 0))
return NULL;
if (params->dev_name) {
@@ -75,6 +80,11 @@ cryptodev_create(const char *name, struct cryptodev_params *params)
dev_id = params->dev_id;
}
+ cache_size = (params->session_pool_size / 2 <
+ PIPELINE_CRYPTO_SESSION_CACHE_SIZE) ?
+ (params->session_pool_size / 2) :
+ PIPELINE_CRYPTO_SESSION_CACHE_SIZE;
+
socket_id = rte_cryptodev_socket_id(dev_id);
rte_cryptodev_info_get(dev_id, &dev_info);
@@ -111,7 +121,44 @@ cryptodev_create(const char *name, struct cryptodev_params *params)
cryptodev->dev_id = dev_id;
cryptodev->n_queues = params->n_queues;
+ snprintf(mp_name, NAME_SIZE, "%s_mp%u", name, dev_id);
+ cryptodev->mp_create = rte_cryptodev_sym_session_pool_create(
+ mp_name,
+ params->session_pool_size,
+ 0,
+ cache_size,
+ 0,
+ socket_id);
+ if (!cryptodev->mp_create)
+ goto error_exit;
+
+ snprintf(mp_name, NAME_SIZE, "%s_mp_priv%u", name, dev_id);
+ cryptodev->mp_init = rte_mempool_create(
+ NULL,
+ params->session_pool_size,
+ rte_cryptodev_sym_get_private_session_size(dev_id),
+ cache_size,
+ 0,
+ NULL,
+ NULL,
+ NULL,
+ NULL,
+ socket_id,
+ 0);
+ if (!cryptodev->mp_init)
+ goto error_exit;
+
TAILQ_INSERT_TAIL(&cryptodev_list, cryptodev, node);
return cryptodev;
+
+error_exit:
+ if (cryptodev->mp_create)
+ rte_mempool_free(cryptodev->mp_create);
+ if (cryptodev->mp_init)
+ rte_mempool_free(cryptodev->mp_init);
+
+ free(cryptodev);
+
+ return NULL;
}
diff --git a/examples/ip_pipeline/cryptodev.h b/examples/ip_pipeline/cryptodev.h
index d06b3f2f1..d00434379 100644
--- a/examples/ip_pipeline/cryptodev.h
+++ b/examples/ip_pipeline/cryptodev.h
@@ -17,6 +17,8 @@ struct cryptodev {
char name[NAME_SIZE];
uint16_t dev_id;
uint32_t n_queues;
+ struct rte_mempool *mp_create;
+ struct rte_mempool *mp_init;
};
TAILQ_HEAD(cryptodev_list, cryptodev);
@@ -35,6 +37,7 @@ struct cryptodev_params {
uint32_t dev_id; /**< Valid only when *dev_name* is NULL. */
uint32_t n_queues;
uint32_t queue_size;
+ uint32_t session_pool_size;
};
struct cryptodev *
diff --git a/examples/ip_pipeline/examples/flow_crypto.cli b/examples/ip_pipeline/examples/flow_crypto.cli
index 9b639deb7..849f9d5fe 100644
--- a/examples/ip_pipeline/examples/flow_crypto.cli
+++ b/examples/ip_pipeline/examples/flow_crypto.cli
@@ -21,14 +21,13 @@
; 5 Crypto Operation 1792 160
mempool MEMPOOL0 buffer 2304 pool 32K cache 256 cpu 1
-mempool MEMPOOL_SESSION0 buffer 1024 pool 1024 cache 128 cpu 1
-link LINK0 dev 0000:81:00.0 rxq 1 128 MEMPOOL0 txq 1 512 promiscuous on
+link LINK0 dev 81:00.0 rxq 1 128 MEMPOOL0 txq 1 512 promiscuous on
#Cryptodev
-cryptodev CRYPTO0 dev crypto_aesni_gcm0 queue 1 1024
+cryptodev CRYPTO0 dev crypto_aesni_gcm0 queue 1 1024 max_sessions 512
-table action profile AP0 ipv4 offset 270 fwd sym_crypto dev CRYPTO0 offset 1792 mempool_create MEMPOOL_SESSION0 mempool_init MEMPOOL_SESSION0
+table action profile AP0 ipv4 offset 270 fwd sym_crypto dev CRYPTO0 offset 1792
table action profile AP1 ipv4 offset 270 fwd
pipeline PIPELINE0 period 10 offset_port_id 0 cpu 1
@@ -46,7 +45,7 @@ pipeline PIPELINE0 table match stub action AP1
pipeline PIPELINE0 port in 0 table 0
pipeline PIPELINE0 port in 1 table 1
-thread 24 pipeline PIPELINE0 enable
+thread 2 pipeline PIPELINE0 enable
pipeline PIPELINE0 table 0 rule add match default action fwd port 2
diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-secgw/ipsec-secgw.c
index a0ff8f7f7..fc102a396 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -55,7 +55,7 @@
#define CDEV_QUEUE_DESC 2048
#define CDEV_MAP_ENTRIES 16384
-#define CDEV_MP_NB_OBJS 2048
+#define CDEV_MP_NB_OBJS 1024
#define CDEV_MP_CACHE_SZ 64
#define MAX_QUEUE_PAIRS 1
@@ -820,11 +820,15 @@ main_loop(__attribute__((unused)) void *dummy)
qconf->inbound.sa_ctx = socket_ctx[socket_id].sa_in;
qconf->inbound.cdev_map = cdev_map_in;
qconf->inbound.session_pool = socket_ctx[socket_id].session_pool;
+ qconf->inbound.session_priv_pool =
+ socket_ctx[socket_id].session_priv_pool;
qconf->outbound.sp4_ctx = socket_ctx[socket_id].sp_ip4_out;
qconf->outbound.sp6_ctx = socket_ctx[socket_id].sp_ip6_out;
qconf->outbound.sa_ctx = socket_ctx[socket_id].sa_out;
qconf->outbound.cdev_map = cdev_map_out;
qconf->outbound.session_pool = socket_ctx[socket_id].session_pool;
+ qconf->outbound.session_priv_pool =
+ socket_ctx[socket_id].session_priv_pool;
if (qconf->nb_rx_queue == 0) {
RTE_LOG(INFO, IPSEC, "lcore %u has nothing to do\n", lcore_id);
@@ -1460,10 +1464,10 @@ cryptodevs_init(void)
dev_conf.nb_queue_pairs = qp;
uint32_t dev_max_sess = cdev_info.sym.max_nb_sessions;
- if (dev_max_sess != 0 && dev_max_sess < (CDEV_MP_NB_OBJS / 2))
+ if (dev_max_sess != 0 && dev_max_sess < CDEV_MP_NB_OBJS)
rte_exit(EXIT_FAILURE,
"Device does not support at least %u "
- "sessions", CDEV_MP_NB_OBJS / 2);
+ "sessions", CDEV_MP_NB_OBJS);
if (!socket_ctx[dev_conf.socket_id].session_pool) {
char mp_name[RTE_MEMPOOL_NAMESIZE];
@@ -1471,6 +1475,19 @@ cryptodevs_init(void)
snprintf(mp_name, RTE_MEMPOOL_NAMESIZE,
"sess_mp_%u", dev_conf.socket_id);
+ sess_mp = rte_cryptodev_sym_session_pool_create(
+ mp_name, CDEV_MP_NB_OBJS,
+ 0, CDEV_MP_CACHE_SZ, 0,
+ dev_conf.socket_id);
+ socket_ctx[dev_conf.socket_id].session_pool = sess_mp;
+ }
+
+ if (!socket_ctx[dev_conf.socket_id].session_priv_pool) {
+ char mp_name[RTE_MEMPOOL_NAMESIZE];
+ struct rte_mempool *sess_mp;
+
+ snprintf(mp_name, RTE_MEMPOOL_NAMESIZE,
+ "sess_mp_priv_%u", dev_conf.socket_id);
sess_mp = rte_mempool_create(mp_name,
CDEV_MP_NB_OBJS,
max_sess_sz,
@@ -1478,25 +1495,28 @@ cryptodevs_init(void)
0, NULL, NULL, NULL,
NULL, dev_conf.socket_id,
0);
- if (sess_mp == NULL)
- rte_exit(EXIT_FAILURE,
- "Cannot create session pool on socket %d\n",
- dev_conf.socket_id);
- else
- printf("Allocated session pool on socket %d\n",
- dev_conf.socket_id);
- socket_ctx[dev_conf.socket_id].session_pool = sess_mp;
+ socket_ctx[dev_conf.socket_id].session_priv_pool =
+ sess_mp;
}
+ if (!socket_ctx[dev_conf.socket_id].session_priv_pool ||
+ !socket_ctx[dev_conf.socket_id].session_pool)
+ rte_exit(EXIT_FAILURE,
+ "Cannot create session pool on socket %d\n",
+ dev_conf.socket_id);
+ else
+ printf("Allocated session pool on socket %d\n",
+ dev_conf.socket_id);
+
if (rte_cryptodev_configure(cdev_id, &dev_conf))
rte_panic("Failed to initialize cryptodev %u\n",
cdev_id);
qp_conf.nb_descriptors = CDEV_QUEUE_DESC;
qp_conf.mp_session =
- socket_ctx[dev_conf.socket_id].session_pool;
+ socket_ctx[dev_conf.socket_id].session_pool;
qp_conf.mp_session_private =
- socket_ctx[dev_conf.socket_id].session_pool;
+ socket_ctx[dev_conf.socket_id].session_priv_pool;
for (qp = 0; qp < dev_conf.nb_queue_pairs; qp++)
if (rte_cryptodev_queue_pair_setup(cdev_id, qp,
&qp_conf, dev_conf.socket_id))
@@ -1521,7 +1541,7 @@ cryptodevs_init(void)
snprintf(mp_name, RTE_MEMPOOL_NAMESIZE,
"sess_mp_%u", socket_id);
sess_mp = rte_mempool_create(mp_name,
- CDEV_MP_NB_OBJS,
+ (CDEV_MP_NB_OBJS * 2),
max_sess_sz,
CDEV_MP_CACHE_SZ,
0, NULL, NULL, NULL,
diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
index 3d415f1af..9dc6e173c 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -323,7 +323,7 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa *sa)
ipsec_ctx->session_pool);
rte_cryptodev_sym_session_init(ipsec_ctx->tbl[cdev_id_qp].id,
sa->crypto_session, sa->xforms,
- ipsec_ctx->session_pool);
+ ipsec_ctx->session_priv_pool);
rte_cryptodev_info_get(ipsec_ctx->tbl[cdev_id_qp].id,
&cdev_info);
diff --git a/examples/ipsec-secgw/ipsec.h b/examples/ipsec-secgw/ipsec.h
index c998c8076..f35552857 100644
--- a/examples/ipsec-secgw/ipsec.h
+++ b/examples/ipsec-secgw/ipsec.h
@@ -144,6 +144,7 @@ struct ipsec_ctx {
uint16_t last_qp;
struct cdev_qp tbl[MAX_QP_PER_LCORE];
struct rte_mempool *session_pool;
+ struct rte_mempool *session_priv_pool;
struct rte_mbuf *ol_pkts[MAX_PKT_BURST] __rte_aligned(sizeof(void *));
uint16_t ol_pkts_cnt;
};
@@ -166,6 +167,7 @@ struct socket_ctx {
struct rt_ctx *rt_ip6;
struct rte_mempool *mbuf_pool;
struct rte_mempool *session_pool;
+ struct rte_mempool *session_priv_pool;
};
struct cnt_blk {
diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index 1df7ba743..9982f07e9 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -221,7 +221,10 @@ static struct rte_eth_conf port_conf = {
struct rte_mempool *l2fwd_pktmbuf_pool;
struct rte_mempool *l2fwd_crypto_op_pool;
-struct rte_mempool *session_pool_socket[RTE_MAX_NUMA_NODES] = { 0 };
+static struct {
+ struct rte_mempool *sess_mp;
+ struct rte_mempool *priv_mp;
+} session_pool_socket[RTE_MAX_NUMA_NODES];
/* Per-port statistics struct */
struct l2fwd_port_statistics {
@@ -645,7 +648,6 @@ initialize_crypto_session(struct l2fwd_crypto_options *options, uint8_t cdev_id)
return NULL;
uint8_t socket_id = (uint8_t) retval;
- struct rte_mempool *sess_mp = session_pool_socket[socket_id];
if (options->xform_chain == L2FWD_CRYPTO_AEAD) {
first_xform = &options->aead_xform;
@@ -661,13 +663,14 @@ initialize_crypto_session(struct l2fwd_crypto_options *options, uint8_t cdev_id)
first_xform = &options->auth_xform;
}
- session = rte_cryptodev_sym_session_create(sess_mp);
-
+ session = rte_cryptodev_sym_session_create(
+ session_pool_socket[socket_id].sess_mp);
if (session == NULL)
return NULL;
if (rte_cryptodev_sym_session_init(cdev_id, session,
- first_xform, sess_mp) < 0)
+ first_xform,
+ session_pool_socket[socket_id].priv_mp) < 0)
return NULL;
return session;
@@ -2267,38 +2270,54 @@ initialize_cryptodevs(struct l2fwd_crypto_options *options, unsigned nb_ports,
rte_cryptodev_scheduler_slaves_get(cdev_id,
NULL);
- sessions_needed = 2 * enabled_cdev_count * nb_slaves;
+ sessions_needed = enabled_cdev_count * nb_slaves;
#endif
} else
- sessions_needed = 2 * enabled_cdev_count;
+ sessions_needed = enabled_cdev_count;
- if (session_pool_socket[socket_id] == NULL) {
+ if (session_pool_socket[socket_id].priv_mp == NULL) {
char mp_name[RTE_MEMPOOL_NAMESIZE];
- struct rte_mempool *sess_mp;
snprintf(mp_name, RTE_MEMPOOL_NAMESIZE,
- "sess_mp_%u", socket_id);
+ "priv_sess_mp_%u", socket_id);
- /*
- * Create enough objects for session headers and
- * device private data
- */
- sess_mp = rte_mempool_create(mp_name,
+ session_pool_socket[socket_id].priv_mp =
+ rte_mempool_create(mp_name,
sessions_needed,
max_sess_sz,
- SESSION_POOL_CACHE_SIZE,
- 0, NULL, NULL, NULL,
+ 0, 0, NULL, NULL, NULL,
NULL, socket_id,
0);
- if (sess_mp == NULL) {
- printf("Cannot create session pool on socket %d\n",
+ if (session_pool_socket[socket_id].priv_mp == NULL) {
+ printf("Cannot create pool on socket %d\n",
+ socket_id);
+ return -ENOMEM;
+ }
+
+ printf("Allocated pool \"%s\" on socket %d\n",
+ mp_name, socket_id);
+ }
+
+ if (session_pool_socket[socket_id].sess_mp == NULL) {
+ char mp_name[RTE_MEMPOOL_NAMESIZE];
+ snprintf(mp_name, RTE_MEMPOOL_NAMESIZE,
+ "sess_mp_%u", socket_id);
+
+ session_pool_socket[socket_id].sess_mp =
+ rte_cryptodev_sym_session_pool_create(
+ mp_name,
+ sessions_needed,
+ 0, 0, 0, socket_id);
+
+ if (session_pool_socket[socket_id].sess_mp == NULL) {
+ printf("Cannot create pool on socket %d\n",
socket_id);
return -ENOMEM;
}
- printf("Allocated session pool on socket %d\n", socket_id);
- session_pool_socket[socket_id] = sess_mp;
+ printf("Allocated pool \"%s\" on socket %d\n",
+ mp_name, socket_id);
}
/* Set AEAD parameters */
@@ -2443,8 +2462,9 @@ initialize_cryptodevs(struct l2fwd_crypto_options *options, unsigned nb_ports,
}
qp_conf.nb_descriptors = 2048;
- qp_conf.mp_session = session_pool_socket[socket_id];
- qp_conf.mp_session_private = session_pool_socket[socket_id];
+ qp_conf.mp_session = session_pool_socket[socket_id].sess_mp;
+ qp_conf.mp_session_private =
+ session_pool_socket[socket_id].priv_mp;
retval = rte_cryptodev_queue_pair_setup(cdev_id, 0, &qp_conf,
socket_id);
diff --git a/examples/vhost_crypto/main.c b/examples/vhost_crypto/main.c
index cb30f84c0..8bdcb3a9c 100644
--- a/examples/vhost_crypto/main.c
+++ b/examples/vhost_crypto/main.c
@@ -46,6 +46,7 @@ struct vhost_crypto_info {
int vids[MAX_NB_SOCKETS];
uint32_t nb_vids;
struct rte_mempool *sess_pool;
+ struct rte_mempool *sess_priv_pool;
struct rte_mempool *cop_pool;
uint8_t cid;
uint32_t qid;
@@ -289,6 +290,7 @@ new_device(int vid)
}
ret = rte_vhost_crypto_create(vid, info->cid, info->sess_pool,
+ info->sess_priv_pool,
rte_lcore_to_socket_id(options.los[i].lcore_id));
if (ret) {
RTE_LOG(ERR, USER1, "Cannot create vhost crypto\n");
@@ -448,6 +450,7 @@ free_resource(void)
rte_mempool_free(info->cop_pool);
rte_mempool_free(info->sess_pool);
+ rte_mempool_free(info->sess_priv_pool);
for (j = 0; j < lo->nb_sockets; j++) {
rte_vhost_driver_unregister(lo->socket_files[i]);
@@ -528,11 +531,17 @@ main(int argc, char *argv[])
}
snprintf(name, 127, "SESS_POOL_%u", lo->lcore_id);
- info->sess_pool = rte_mempool_create(name, SESSION_MAP_ENTRIES,
+ info->sess_pool = rte_cryptodev_sym_session_pool_create(name,
+ SESSION_MAP_ENTRIES, 0, 0, 0,
+ rte_lcore_to_socket_id(lo->lcore_id));
+
+ snprintf(name, 127, "SESS_POOL_PRIV_%u", lo->lcore_id);
+ info->sess_priv_pool = rte_mempool_create(name,
+ SESSION_MAP_ENTRIES,
rte_cryptodev_sym_get_private_session_size(
info->cid), 64, 0, NULL, NULL, NULL, NULL,
rte_lcore_to_socket_id(lo->lcore_id), 0);
- if (!info->sess_pool) {
+ if (!info->sess_priv_pool || info->sess_pool) {
RTE_LOG(ERR, USER1, "Failed to create mempool");
goto error_exit;
}
diff --git a/lib/librte_cryptodev/Makefile b/lib/librte_cryptodev/Makefile
index a8f94c097..ade108b90 100644
--- a/lib/librte_cryptodev/Makefile
+++ b/lib/librte_cryptodev/Makefile
@@ -12,6 +12,7 @@ LIBABIVER := 5
# build flags
CFLAGS += -O3
CFLAGS += $(WERROR_FLAGS)
+CFLAGS += -DALLOW_EXPERIMENTAL_API
LDLIBS += -lrte_eal -lrte_mempool -lrte_ring -lrte_mbuf
LDLIBS += -lrte_kvargs
diff --git a/lib/librte_cryptodev/meson.build b/lib/librte_cryptodev/meson.build
index 990dd3d44..40ccce37a 100644
--- a/lib/librte_cryptodev/meson.build
+++ b/lib/librte_cryptodev/meson.build
@@ -2,6 +2,7 @@
# Copyright(c) 2017 Intel Corporation
version = 5
+allow_experimental_apis = true
sources = files('rte_cryptodev.c', 'rte_cryptodev_pmd.c')
headers = files('rte_cryptodev.h',
'rte_cryptodev_pmd.h',
diff --git a/lib/librte_cryptodev/rte_cryptodev.c b/lib/librte_cryptodev/rte_cryptodev.c
index 11776b6ac..e5e60f7e2 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -189,6 +189,16 @@ const char *rte_crypto_asym_op_strings[] = {
[RTE_CRYPTO_ASYM_OP_SHARED_SECRET_COMPUTE] = "sharedsecret_compute",
};
+/**
+ * The private data structure stored in the session mempool private data.
+ */
+struct rte_cryptodev_sym_session_pool_private_data {
+ uint16_t nb_drivers;
+ /**< number of elements in sess_data array */
+ uint16_t user_data_sz;
+ /**< session user data will be placed after sess_data */
+};
+
int
rte_cryptodev_get_cipher_algo_enum(enum rte_crypto_cipher_algorithm *algo_enum,
const char *algo_string)
@@ -951,7 +961,45 @@ rte_cryptodev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
return -EINVAL;
}
+ if (!qp_conf) {
+ CDEV_LOG_ERR("qp_conf cannot be NULL\n");
+ return -EINVAL;
+ }
+
+ if ((qp_conf->mp_session && !qp_conf->mp_session_private) ||
+ (!qp_conf->mp_session && qp_conf->mp_session_private)) {
+ CDEV_LOG_ERR("Invalid mempools\n");
+ return -EINVAL;
+ }
+
dev = &rte_crypto_devices[dev_id];
+
+ if (qp_conf->mp_session) {
+ struct rte_cryptodev_sym_session_pool_private_data *pool_priv;
+ uint32_t obj_size = qp_conf->mp_session->elt_size;
+ uint32_t obj_priv_size = qp_conf->mp_session_private->elt_size;
+ struct rte_cryptodev_sym_session s = {0};
+
+ pool_priv = rte_mempool_get_priv(qp_conf->mp_session);
+ if (!pool_priv || qp_conf->mp_session->private_data_size <
+ sizeof(*pool_priv)) {
+ CDEV_LOG_ERR("Invalid mempool\n");
+ return -EINVAL;
+ }
+
+ s.nb_drivers = pool_priv->nb_drivers;
+ s.user_data_sz = pool_priv->user_data_sz;
+
+ if ((rte_cryptodev_sym_get_existing_header_session_size(&s) >
+ obj_size) || (s.nb_drivers <= dev->driver_id) ||
+ rte_cryptodev_sym_get_private_session_size(dev_id) >
+ obj_priv_size) {
+ CDEV_LOG_ERR("Invalid mempool\n");
+ return -EINVAL;
+ }
+
+ }
+
if (queue_pair_id >= dev->data->nb_queue_pairs) {
CDEV_LOG_ERR("Invalid queue_pair_id=%d", queue_pair_id);
return -EINVAL;
@@ -969,7 +1017,6 @@ rte_cryptodev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
socket_id);
}
-
int
rte_cryptodev_stats_get(uint8_t dev_id, struct rte_cryptodev_stats *stats)
{
@@ -1143,7 +1190,6 @@ rte_cryptodev_pmd_callback_process(struct rte_cryptodev *dev,
rte_spinlock_unlock(&rte_cryptodev_cb_lock);
}
-
int
rte_cryptodev_sym_session_init(uint8_t dev_id,
struct rte_cryptodev_sym_session *sess,
@@ -1160,12 +1206,15 @@ rte_cryptodev_sym_session_init(uint8_t dev_id,
return -EINVAL;
index = dev->driver_id;
+ if (index >= sess->nb_drivers)
+ return -EINVAL;
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->sym_session_configure, -ENOTSUP);
- if (sess->sess_private_data[index] == NULL) {
+ if (sess->sess_data[index].refcnt == 0) {
ret = dev->dev_ops->sym_session_configure(dev, xforms,
- sess, mp);
+ sess, mp);
+
if (ret < 0) {
CDEV_LOG_ERR(
"dev_id %d failed to configure session details",
@@ -1174,6 +1223,7 @@ rte_cryptodev_sym_session_init(uint8_t dev_id,
}
}
+ sess->sess_data[index].refcnt++;
return 0;
}
@@ -1212,10 +1262,70 @@ rte_cryptodev_asym_session_init(uint8_t dev_id,
return 0;
}
+struct rte_mempool *__rte_experimental
+rte_cryptodev_sym_session_pool_create(const char *name, uint32_t nb_elts,
+ uint32_t elt_size, uint32_t cache_size, uint16_t user_data_size,
+ int socket_id)
+{
+ struct rte_mempool *mp;
+ struct rte_cryptodev_sym_session_pool_private_data *pool_priv;
+ uint32_t obj_sz;
+
+ obj_sz = rte_cryptodev_sym_get_header_session_size() + user_data_size;
+ if (obj_sz > elt_size)
+ CDEV_LOG_INFO("elt_size %u is expanded to %u\n", elt_size,
+ obj_sz);
+ else
+ obj_sz = elt_size;
+
+ mp = rte_mempool_create(name, nb_elts, obj_sz, cache_size,
+ (uint32_t)(sizeof(*pool_priv)),
+ NULL, NULL, NULL, NULL,
+ socket_id, 0);
+ if (mp == NULL) {
+ CDEV_LOG_ERR("%s(name=%s) failed, rte_errno=%d\n",
+ __func__, name, rte_errno);
+ return NULL;
+ }
+
+ pool_priv = rte_mempool_get_priv(mp);
+ if (!pool_priv) {
+ CDEV_LOG_ERR("%s(name=%s) failed to get private data\n",
+ __func__, name);
+ rte_mempool_free(mp);
+ return NULL;
+ }
+
+ pool_priv->nb_drivers = nb_drivers;
+ pool_priv->user_data_sz = user_data_size;
+
+ return mp;
+}
+
+static unsigned int
+rte_cryptodev_sym_session_data_size(struct rte_cryptodev_sym_session *sess)
+{
+ return (sizeof(sess->sess_data[0]) * sess->nb_drivers) +
+ sess->user_data_sz;
+}
+
struct rte_cryptodev_sym_session *
rte_cryptodev_sym_session_create(struct rte_mempool *mp)
{
struct rte_cryptodev_sym_session *sess;
+ struct rte_cryptodev_sym_session_pool_private_data *pool_priv;
+
+ if (!mp) {
+ CDEV_LOG_ERR("Invalid mempool\n");
+ return NULL;
+ }
+
+ pool_priv = rte_mempool_get_priv(mp);
+
+ if (!pool_priv || mp->private_data_size < sizeof(*pool_priv)) {
+ CDEV_LOG_ERR("Invalid mempool\n");
+ return NULL;
+ }
/* Allocate a session structure from the session pool */
if (rte_mempool_get(mp, (void **)&sess)) {
@@ -1226,7 +1336,12 @@ rte_cryptodev_sym_session_create(struct rte_mempool *mp)
/* Clear device session pointer.
* Include the flag indicating presence of user data
*/
- memset(sess, 0, (sizeof(void *) * nb_drivers) + sizeof(uint8_t));
+ sess->nb_drivers = pool_priv->nb_drivers;
+ sess->user_data_sz = pool_priv->user_data_sz;
+ sess->opaque_data = 0;
+
+ memset(sess->sess_data, 0,
+ rte_cryptodev_sym_session_data_size(sess));
return sess;
}
@@ -1255,12 +1370,17 @@ rte_cryptodev_sym_session_clear(uint8_t dev_id,
struct rte_cryptodev_sym_session *sess)
{
struct rte_cryptodev *dev;
+ uint8_t driver_id;
dev = rte_cryptodev_pmd_get_dev(dev_id);
if (dev == NULL || sess == NULL)
return -EINVAL;
+ driver_id = dev->driver_id;
+ if (--sess->sess_data[driver_id].refcnt != 0)
+ return -EBUSY;
+
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->sym_session_clear, -ENOTSUP);
dev->dev_ops->sym_session_clear(dev, sess);
@@ -1290,16 +1410,15 @@ int
rte_cryptodev_sym_session_free(struct rte_cryptodev_sym_session *sess)
{
uint8_t i;
- void *sess_priv;
struct rte_mempool *sess_mp;
if (sess == NULL)
return -EINVAL;
/* Check that all device private data has been freed */
- for (i = 0; i < nb_drivers; i++) {
- sess_priv = get_sym_session_private_data(sess, i);
- if (sess_priv != NULL)
+ /* Check that all device private data has been freed */
+ for (i = 0; i < sess->nb_drivers; i++) {
+ if (sess->sess_data[i].refcnt != 0)
return -EBUSY;
}
@@ -1334,16 +1453,32 @@ rte_cryptodev_asym_session_free(struct rte_cryptodev_asym_session *sess)
return 0;
}
-
unsigned int
rte_cryptodev_sym_get_header_session_size(void)
{
/*
- * Header contains pointers to the private data
- * of all registered drivers, and a flag which
- * indicates presence of user data
+ * Header contains all pointers to the private data
+ * of all registered drivers with a reference count, and the
+ * information of maximum number of drivers in the system and the user
+ * data size.
*/
- return ((sizeof(void *) * nb_drivers) + sizeof(uint8_t));
+ struct rte_cryptodev_sym_session s = {0};
+ s.nb_drivers = nb_drivers;
+ s.user_data_sz = 0;
+
+ return (unsigned int)(sizeof(s) +
+ rte_cryptodev_sym_session_data_size(&s));
+}
+
+unsigned int __rte_experimental
+rte_cryptodev_sym_get_existing_header_session_size(
+ struct rte_cryptodev_sym_session *sess)
+{
+ if (!sess)
+ return 0;
+ else
+ return (unsigned int)(sizeof(*sess) +
+ rte_cryptodev_sym_session_data_size(sess));
}
unsigned int __rte_experimental
@@ -1361,7 +1496,6 @@ unsigned int
rte_cryptodev_sym_get_private_session_size(uint8_t dev_id)
{
struct rte_cryptodev *dev;
- unsigned int header_size = sizeof(void *) * nb_drivers;
unsigned int priv_sess_size;
if (!rte_cryptodev_pmd_is_valid_dev(dev_id))
@@ -1374,14 +1508,6 @@ rte_cryptodev_sym_get_private_session_size(uint8_t dev_id)
priv_sess_size = (*dev->dev_ops->sym_session_get_size)(dev);
- /*
- * If size is less than session header size,
- * return the latter, as this guarantees that
- * sessionless operations will work
- */
- if (priv_sess_size < header_size)
- return header_size;
-
return priv_sess_size;
}
@@ -1415,15 +1541,13 @@ rte_cryptodev_sym_session_set_user_data(
void *data,
uint16_t size)
{
- uint16_t off_set = sizeof(void *) * nb_drivers;
- uint8_t *user_data_present = (uint8_t *)sess + off_set;
-
if (sess == NULL)
return -EINVAL;
- *user_data_present = 1;
- off_set += sizeof(uint8_t);
- rte_memcpy((uint8_t *)sess + off_set, data, size);
+ if (sess->user_data_sz < size)
+ return -ENOMEM;
+
+ rte_memcpy(sess->sess_data + sess->nb_drivers, data, size);
return 0;
}
@@ -1431,14 +1555,10 @@ void * __rte_experimental
rte_cryptodev_sym_session_get_user_data(
struct rte_cryptodev_sym_session *sess)
{
- uint16_t off_set = sizeof(void *) * nb_drivers;
- uint8_t *user_data_present = (uint8_t *)sess + off_set;
-
- if (sess == NULL || !*user_data_present)
+ if (sess == NULL || sess->user_data_sz == 0)
return NULL;
- off_set += sizeof(uint8_t);
- return (uint8_t *)sess + off_set;
+ return (void *)(sess->sess_data + sess->nb_drivers);
}
/** Initialise rte_crypto_op mempool element */
diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
index f9e7507da..698a859f3 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -951,14 +951,22 @@ rte_cryptodev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
dev->data->queue_pairs[qp_id], ops, nb_ops);
}
-
/** Cryptodev symmetric crypto session
* Each session is derived from a fixed xform chain. Therefore each session
* has a fixed algo, key, op-type, digest_len etc.
*/
struct rte_cryptodev_sym_session {
- __extension__ void *sess_private_data[0];
- /**< Private symmetric session material */
+ uint64_t opaque_data;
+ /**< Can be used for external metadata */
+ uint16_t nb_drivers;
+ /**< number of elements in sess_data array */
+ uint16_t user_data_sz;
+ /**< session user data will be placed after sess_data */
+ __extension__ struct {
+ void *data;
+ uint16_t refcnt;
+ } sess_data[0];
+ /**< Driver specific session material, variable size */
};
/** Cryptodev asymmetric crypto session */
@@ -968,6 +976,37 @@ struct rte_cryptodev_asym_session {
};
/**
+ * Create a symmetric session mempool.
+ *
+ * @param name
+ * The unique mempool name.
+ * @param nb_elts
+ * The number of elements in the mempool.
+ * @param elt_size
+ * The size of the element. This value will be ignored if it is smaller than
+ * the minimum session header size required for the system. For the user who
+ * want to use the same mempool for sym session and session private data it
+ * can be the maximum value of all existing devices' private data and session
+ * header sizes.
+ * @param cache_size
+ * The number of per-lcore cache elements
+ * @param priv_size
+ * The private data size of each session.
+ * @param socket_id
+ * The *socket_id* argument is the socket identifier in the case of
+ * NUMA. The value can be *SOCKET_ID_ANY* if there is no NUMA
+ * constraint for the reserved zone.
+ *
+ * @return
+ * - On success return size of the session
+ * - On failure returns 0
+ */
+struct rte_mempool * __rte_experimental
+rte_cryptodev_sym_session_pool_create(const char *name, uint32_t nb_elts,
+ uint32_t elt_size, uint32_t cache_size, uint16_t priv_size,
+ int socket_id);
+
+/**
* Create symmetric crypto session header (generic with no private data)
*
* @param mempool Symmetric session mempool to allocate session
@@ -1097,15 +1136,31 @@ rte_cryptodev_asym_session_clear(uint8_t dev_id,
struct rte_cryptodev_asym_session *sess);
/**
- * Get the size of the header session, for all registered drivers.
+ * Get the size of the header session, for all registered drivers excluding
+ * the user data size.
*
* @return
- * Size of the symmetric eader session.
+ * Size of the symmetric header session.
*/
unsigned int
rte_cryptodev_sym_get_header_session_size(void);
/**
+ * Get the size of the header session from created session.
+ *
+ * @param sess
+ * The sym cryptodev session pointer
+ *
+ * @return
+ * - If sess is not NULL, return the size of the header session including
+ * the private data size defined within sess.
+ * - If sess is NULL, return 0.
+ */
+unsigned int __rte_experimental
+rte_cryptodev_sym_get_existing_header_session_size(
+ struct rte_cryptodev_sym_session *sess);
+
+/**
* Get the size of the asymmetric session header, for all registered drivers.
*
* @return
diff --git a/lib/librte_cryptodev/rte_cryptodev_pmd.h b/lib/librte_cryptodev/rte_cryptodev_pmd.h
index f15c9af30..defe05ea0 100644
--- a/lib/librte_cryptodev/rte_cryptodev_pmd.h
+++ b/lib/librte_cryptodev/rte_cryptodev_pmd.h
@@ -475,14 +475,23 @@ RTE_INIT(init_ ##driver_id)\
static inline void *
get_sym_session_private_data(const struct rte_cryptodev_sym_session *sess,
uint8_t driver_id) {
- return sess->sess_private_data[driver_id];
+ if (unlikely(sess->nb_drivers <= driver_id))
+ return NULL;
+
+ return sess->sess_data[driver_id].data;
}
static inline void
set_sym_session_private_data(struct rte_cryptodev_sym_session *sess,
uint8_t driver_id, void *private_data)
{
- sess->sess_private_data[driver_id] = private_data;
+ if (unlikely(sess->nb_drivers <= driver_id)) {
+ CDEV_LOG_ERR("Set private data for driver %u not allowed\n",
+ driver_id);
+ return;
+ }
+
+ sess->sess_data[driver_id].data = private_data;
}
static inline void *
diff --git a/lib/librte_cryptodev/rte_cryptodev_version.map b/lib/librte_cryptodev/rte_cryptodev_version.map
index a695b61dc..0d0f3bc28 100644
--- a/lib/librte_cryptodev/rte_cryptodev_version.map
+++ b/lib/librte_cryptodev/rte_cryptodev_version.map
@@ -105,4 +105,6 @@ EXPERIMENTAL {
rte_cryptodev_sym_session_set_user_data;
rte_crypto_asym_op_strings;
rte_crypto_asym_xform_strings;
+ rte_cryptodev_sym_session_pool_create;
+ rte_cryptodev_sym_get_existing_header_session_size;
};
diff --git a/lib/librte_vhost/rte_vhost_crypto.h b/lib/librte_vhost/rte_vhost_crypto.h
index f9fbc0548..d08e0ffab 100644
--- a/lib/librte_vhost/rte_vhost_crypto.h
+++ b/lib/librte_vhost/rte_vhost_crypto.h
@@ -26,8 +26,9 @@ enum rte_vhost_crypto_zero_copy {
* The identifier of DPDK Cryptodev, the same cryptodev_id can be assigned to
* multiple Vhost-crypto devices.
* @param sess_pool
- * The pointer to the created cryptodev session pool with the private data size
- * matches the target DPDK Cryptodev.
+ * The pointer to the created cryptodev session pool.
+ * @param sess_priv_pool
+ * The pointer to the created cryptodev session private data mempool.
* @param socket_id
* NUMA Socket ID to allocate resources on. *
* @return
@@ -36,7 +37,9 @@ enum rte_vhost_crypto_zero_copy {
*/
int __rte_experimental
rte_vhost_crypto_create(int vid, uint8_t cryptodev_id,
- struct rte_mempool *sess_pool, int socket_id);
+ struct rte_mempool *sess_pool,
+ struct rte_mempool *sess_priv_pool,
+ int socket_id);
/**
* Free the Vhost-crypto instance
diff --git a/lib/librte_vhost/vhost_crypto.c b/lib/librte_vhost/vhost_crypto.c
index dd01afc08..598196fb7 100644
--- a/lib/librte_vhost/vhost_crypto.c
+++ b/lib/librte_vhost/vhost_crypto.c
@@ -198,6 +198,7 @@ struct vhost_crypto {
struct rte_hash *session_map;
struct rte_mempool *mbuf_pool;
struct rte_mempool *sess_pool;
+ struct rte_mempool *sess_priv_pool;
struct rte_mempool *wb_pool;
/** DPDK cryptodev ID */
@@ -369,7 +370,7 @@ vhost_crypto_create_sess(struct vhost_crypto *vcrypto,
}
if (rte_cryptodev_sym_session_init(vcrypto->cid, session, &xform1,
- vcrypto->sess_pool) < 0) {
+ vcrypto->sess_priv_pool) < 0) {
VC_LOG_ERR("Failed to initialize session");
sess_param->session_id = -VIRTIO_CRYPTO_ERR;
return;
@@ -1293,7 +1294,9 @@ vhost_crypto_complete_one_vm_requests(struct rte_crypto_op **ops,
int __rte_experimental
rte_vhost_crypto_create(int vid, uint8_t cryptodev_id,
- struct rte_mempool *sess_pool, int socket_id)
+ struct rte_mempool *sess_pool,
+ struct rte_mempool *sess_priv_pool,
+ int socket_id)
{
struct virtio_net *dev = get_device(vid);
struct rte_hash_parameters params = {0};
@@ -1321,6 +1324,7 @@ rte_vhost_crypto_create(int vid, uint8_t cryptodev_id,
}
vcrypto->sess_pool = sess_pool;
+ vcrypto->sess_priv_pool = sess_priv_pool;
vcrypto->cid = cryptodev_id;
vcrypto->cache_session_id = UINT64_MAX;
vcrypto->last_session_id = 1;
diff --git a/test/test/test_cryptodev.c b/test/test/test_cryptodev.c
index aac0b1f0b..238b7dd34 100644
--- a/test/test/test_cryptodev.c
+++ b/test/test/test_cryptodev.c
@@ -48,6 +48,7 @@ struct crypto_testsuite_params {
struct rte_mempool *large_mbuf_pool;
struct rte_mempool *op_mpool;
struct rte_mempool *session_mpool;
+ struct rte_mempool *session_priv_mpool;
struct rte_cryptodev_config conf;
struct rte_cryptodev_qp_conf qp_conf;
@@ -444,17 +445,24 @@ testsuite_setup(void)
return TEST_FAILED;
}
- ts_params->session_mpool = rte_mempool_create(
- "test_sess_mp",
- MAX_NB_SESSIONS * 2,
- session_size,
- 0, 0, NULL, NULL, NULL,
- NULL, SOCKET_ID_ANY,
- 0);
-
+ ts_params->session_mpool = rte_cryptodev_sym_session_pool_create(
+ "test_sess_mp", MAX_NB_SESSIONS, 0, 0, 0,
+ SOCKET_ID_ANY);
TEST_ASSERT_NOT_NULL(ts_params->session_mpool,
"session mempool allocation failed");
+ ts_params->session_priv_mpool = rte_mempool_create(
+ "test_sess_mp_priv",
+ MAX_NB_SESSIONS,
+ session_size,
+ 0, 0, NULL, NULL, NULL,
+ NULL, SOCKET_ID_ANY,
+ 0);
+ TEST_ASSERT_NOT_NULL(ts_params->session_priv_mpool,
+ "session mempool allocation failed");
+
+
+
TEST_ASSERT_SUCCESS(rte_cryptodev_configure(dev_id,
&ts_params->conf),
"Failed to configure cryptodev %u with %u qps",
@@ -462,7 +470,7 @@ testsuite_setup(void)
ts_params->qp_conf.nb_descriptors = DEFAULT_NUM_OPS_INFLIGHT;
ts_params->qp_conf.mp_session = ts_params->session_mpool;
- ts_params->qp_conf.mp_session_private = ts_params->session_mpool;
+ ts_params->qp_conf.mp_session_private = ts_params->session_priv_mpool;
for (qp_id = 0; qp_id < info.max_nb_queue_pairs; qp_id++) {
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
@@ -491,6 +499,11 @@ testsuite_teardown(void)
}
/* Free session mempools */
+ if (ts_params->session_priv_mpool != NULL) {
+ rte_mempool_free(ts_params->session_priv_mpool);
+ ts_params->session_priv_mpool = NULL;
+ }
+
if (ts_params->session_mpool != NULL) {
rte_mempool_free(ts_params->session_mpool);
ts_params->session_mpool = NULL;
@@ -510,6 +523,9 @@ ut_setup(void)
/* Reconfigure device to default parameters */
ts_params->conf.socket_id = SOCKET_ID_ANY;
+ ts_params->qp_conf.nb_descriptors = MAX_NUM_OPS_INFLIGHT;
+ ts_params->qp_conf.mp_session = ts_params->session_mpool;
+ ts_params->qp_conf.mp_session_private = ts_params->session_priv_mpool;
TEST_ASSERT_SUCCESS(rte_cryptodev_configure(ts_params->valid_devs[0],
&ts_params->conf),
@@ -710,7 +726,7 @@ test_queue_pair_descriptor_setup(void)
*/
qp_conf.nb_descriptors = MIN_NUM_OPS_INFLIGHT; /* min size*/
qp_conf.mp_session = ts_params->session_mpool;
- qp_conf.mp_session_private = ts_params->session_mpool;
+ qp_conf.mp_session_private = ts_params->session_priv_mpool;
for (qp_id = 0; qp_id < ts_params->conf.nb_queue_pairs; qp_id++) {
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
@@ -1337,7 +1353,7 @@ test_AES_CBC_HMAC_SHA1_encrypt_digest(void)
/* Create crypto session*/
rte_cryptodev_sym_session_init(ts_params->valid_devs[0],
ut_params->sess, &ut_params->cipher_xform,
- ts_params->session_mpool);
+ ts_params->session_priv_mpool);
TEST_ASSERT_NOT_NULL(ut_params->sess, "Session creation failed");
/* Generate crypto op data structure */
@@ -1551,7 +1567,7 @@ test_AES_cipheronly_mb_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_AESNI_MB_PMD)),
@@ -1570,7 +1586,7 @@ test_AES_docsis_mb_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_AESNI_MB_PMD)),
@@ -1589,7 +1605,7 @@ test_AES_docsis_qat_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_QAT_SYM_PMD)),
@@ -1608,7 +1624,7 @@ test_DES_docsis_qat_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_QAT_SYM_PMD)),
@@ -1627,7 +1643,7 @@ test_authonly_mb_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_AESNI_MB_PMD)),
@@ -1646,7 +1662,7 @@ test_authonly_qat_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_QAT_SYM_PMD)),
@@ -1664,7 +1680,7 @@ test_AES_chain_mb_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_AESNI_MB_PMD)),
@@ -1685,7 +1701,7 @@ test_AES_cipheronly_scheduler_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_SCHEDULER_PMD)),
@@ -1704,7 +1720,7 @@ test_AES_chain_scheduler_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_SCHEDULER_PMD)),
@@ -1723,7 +1739,7 @@ test_authonly_scheduler_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_SCHEDULER_PMD)),
@@ -1744,7 +1760,7 @@ test_AES_chain_openssl_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_OPENSSL_PMD)),
@@ -1763,7 +1779,7 @@ test_AES_cipheronly_openssl_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_OPENSSL_PMD)),
@@ -1782,7 +1798,7 @@ test_AES_chain_ccp_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_CCP_PMD)),
@@ -1801,7 +1817,7 @@ test_AES_cipheronly_ccp_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_CCP_PMD)),
@@ -1820,7 +1836,7 @@ test_AES_chain_qat_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_QAT_SYM_PMD)),
@@ -1839,7 +1855,7 @@ test_AES_cipheronly_qat_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_QAT_SYM_PMD)),
@@ -1858,7 +1874,7 @@ test_AES_cipheronly_virtio_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_VIRTIO_PMD)),
@@ -1877,7 +1893,7 @@ test_AES_chain_caam_jr_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_CAAM_JR_PMD)),
@@ -1896,7 +1912,7 @@ test_AES_cipheronly_caam_jr_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_CAAM_JR_PMD)),
@@ -1915,7 +1931,7 @@ test_authonly_caam_jr_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_CAAM_JR_PMD)),
@@ -1935,7 +1951,7 @@ test_AES_chain_dpaa_sec_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_DPAA_SEC_PMD)),
@@ -1954,7 +1970,7 @@ test_AES_cipheronly_dpaa_sec_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_DPAA_SEC_PMD)),
@@ -1973,7 +1989,7 @@ test_authonly_dpaa_sec_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_DPAA_SEC_PMD)),
@@ -1992,7 +2008,7 @@ test_AES_chain_dpaa2_sec_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_DPAA2_SEC_PMD)),
@@ -2011,7 +2027,7 @@ test_AES_cipheronly_dpaa2_sec_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_DPAA2_SEC_PMD)),
@@ -2030,7 +2046,7 @@ test_authonly_dpaa2_sec_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_DPAA2_SEC_PMD)),
@@ -2049,7 +2065,7 @@ test_authonly_openssl_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_OPENSSL_PMD)),
@@ -2068,7 +2084,7 @@ test_authonly_ccp_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_CCP_PMD)),
@@ -2087,7 +2103,7 @@ test_AES_chain_armv8_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_ARMV8_PMD)),
@@ -2106,7 +2122,7 @@ test_AES_chain_mrvl_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_MVSAM_PMD)),
@@ -2125,7 +2141,7 @@ test_AES_cipheronly_mrvl_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_MVSAM_PMD)),
@@ -2144,7 +2160,7 @@ test_authonly_mrvl_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_MVSAM_PMD)),
@@ -2163,7 +2179,7 @@ test_3DES_chain_mrvl_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_MVSAM_PMD)),
@@ -2182,7 +2198,7 @@ test_3DES_cipheronly_mrvl_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_MVSAM_PMD)),
@@ -2201,6 +2217,7 @@ test_AES_chain_octeontx_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool, ts_params->session_mpool,
+ ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_OCTEONTX_SYM_PMD)),
@@ -2219,6 +2236,7 @@ test_AES_cipheronly_octeontx_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool, ts_params->session_mpool,
+ ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_OCTEONTX_SYM_PMD)),
@@ -2237,6 +2255,7 @@ test_3DES_chain_octeontx_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool, ts_params->session_mpool,
+ ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_OCTEONTX_SYM_PMD)),
@@ -2255,6 +2274,7 @@ test_3DES_cipheronly_octeontx_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool, ts_params->session_mpool,
+ ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_OCTEONTX_SYM_PMD)),
@@ -2273,6 +2293,7 @@ test_authonly_octeontx_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool, ts_params->session_mpool,
+ ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_OCTEONTX_SYM_PMD)),
@@ -2315,7 +2336,8 @@ create_wireless_algo_hash_session(uint8_t dev_id,
ts_params->session_mpool);
rte_cryptodev_sym_session_init(dev_id, ut_params->sess,
- &ut_params->auth_xform, ts_params->session_mpool);
+ &ut_params->auth_xform,
+ ts_params->session_priv_mpool);
TEST_ASSERT_NOT_NULL(ut_params->sess, "Session creation failed");
return 0;
}
@@ -2352,7 +2374,8 @@ create_wireless_algo_cipher_session(uint8_t dev_id,
ts_params->session_mpool);
rte_cryptodev_sym_session_init(dev_id, ut_params->sess,
- &ut_params->cipher_xform, ts_params->session_mpool);
+ &ut_params->cipher_xform,
+ ts_params->session_priv_mpool);
TEST_ASSERT_NOT_NULL(ut_params->sess, "Session creation failed");
return 0;
}
@@ -2468,7 +2491,8 @@ create_wireless_algo_cipher_auth_session(uint8_t dev_id,
ts_params->session_mpool);
rte_cryptodev_sym_session_init(dev_id, ut_params->sess,
- &ut_params->cipher_xform, ts_params->session_mpool);
+ &ut_params->cipher_xform,
+ ts_params->session_priv_mpool);
TEST_ASSERT_NOT_NULL(ut_params->sess, "Session creation failed");
return 0;
@@ -2527,7 +2551,8 @@ create_wireless_cipher_auth_session(uint8_t dev_id,
ts_params->session_mpool);
rte_cryptodev_sym_session_init(dev_id, ut_params->sess,
- &ut_params->cipher_xform, ts_params->session_mpool);
+ &ut_params->cipher_xform,
+ ts_params->session_priv_mpool);
TEST_ASSERT_NOT_NULL(ut_params->sess, "Session creation failed");
return 0;
@@ -2589,7 +2614,8 @@ create_wireless_algo_auth_cipher_session(uint8_t dev_id,
ts_params->session_mpool);
rte_cryptodev_sym_session_init(dev_id, ut_params->sess,
- &ut_params->auth_xform, ts_params->session_mpool);
+ &ut_params->auth_xform,
+ ts_params->session_priv_mpool);
TEST_ASSERT_NOT_NULL(ut_params->sess, "Session creation failed");
@@ -5075,7 +5101,7 @@ test_3DES_chain_qat_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_QAT_SYM_PMD)),
@@ -5094,7 +5120,7 @@ test_DES_cipheronly_qat_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_QAT_SYM_PMD)),
@@ -5113,7 +5139,7 @@ test_DES_cipheronly_openssl_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_OPENSSL_PMD)),
@@ -5132,7 +5158,7 @@ test_DES_docsis_openssl_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_OPENSSL_PMD)),
@@ -5151,7 +5177,7 @@ test_DES_cipheronly_mb_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_AESNI_MB_PMD)),
@@ -5169,7 +5195,7 @@ test_3DES_cipheronly_mb_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_AESNI_MB_PMD)),
@@ -5188,7 +5214,7 @@ test_DES_docsis_mb_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_AESNI_MB_PMD)),
@@ -5207,7 +5233,7 @@ test_3DES_chain_caam_jr_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_CAAM_JR_PMD)),
@@ -5226,7 +5252,7 @@ test_3DES_cipheronly_caam_jr_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_CAAM_JR_PMD)),
@@ -5245,7 +5271,7 @@ test_3DES_chain_dpaa_sec_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_DPAA_SEC_PMD)),
@@ -5264,7 +5290,7 @@ test_3DES_cipheronly_dpaa_sec_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_DPAA_SEC_PMD)),
@@ -5283,7 +5309,7 @@ test_3DES_chain_dpaa2_sec_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_DPAA2_SEC_PMD)),
@@ -5302,7 +5328,7 @@ test_3DES_cipheronly_dpaa2_sec_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_DPAA2_SEC_PMD)),
@@ -5321,7 +5347,7 @@ test_3DES_chain_ccp_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_CCP_PMD)),
@@ -5340,7 +5366,7 @@ test_3DES_cipheronly_ccp_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_CCP_PMD)),
@@ -5359,7 +5385,7 @@ test_3DES_cipheronly_qat_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_QAT_SYM_PMD)),
@@ -5378,7 +5404,7 @@ test_3DES_chain_openssl_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_OPENSSL_PMD)),
@@ -5397,7 +5423,7 @@ test_3DES_cipheronly_openssl_all(void)
status = test_blockcipher_all_tests(ts_params->mbuf_pool,
ts_params->op_mpool,
- ts_params->session_mpool,
+ ts_params->session_mpool, ts_params->session_priv_mpool,
ts_params->valid_devs[0],
rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_OPENSSL_PMD)),
@@ -5443,7 +5469,8 @@ create_aead_session(uint8_t dev_id, enum rte_crypto_aead_algorithm algo,
ts_params->session_mpool);
rte_cryptodev_sym_session_init(dev_id, ut_params->sess,
- &ut_params->aead_xform, ts_params->session_mpool);
+ &ut_params->aead_xform,
+ ts_params->session_priv_mpool);
TEST_ASSERT_NOT_NULL(ut_params->sess, "Session creation failed");
@@ -6547,7 +6574,7 @@ static int MD5_HMAC_create_session(struct crypto_testsuite_params *ts_params,
rte_cryptodev_sym_session_init(ts_params->valid_devs[0],
ut_params->sess, &ut_params->auth_xform,
- ts_params->session_mpool);
+ ts_params->session_priv_mpool);
if (ut_params->sess == NULL)
return TEST_FAILED;
@@ -6728,7 +6755,7 @@ test_multi_session(void)
rte_cryptodev_sym_session_init(ts_params->valid_devs[0],
sessions[i], &ut_params->auth_xform,
- ts_params->session_mpool);
+ ts_params->session_priv_mpool);
TEST_ASSERT_NOT_NULL(sessions[i],
"Session creation failed at session number %u",
i);
@@ -6766,7 +6793,7 @@ test_multi_session(void)
/* Next session create should fail */
rte_cryptodev_sym_session_init(ts_params->valid_devs[0],
sessions[i], &ut_params->auth_xform,
- ts_params->session_mpool);
+ ts_params->session_priv_mpool);
TEST_ASSERT_NULL(sessions[i],
"Session creation succeeded unexpectedly!");
@@ -6847,7 +6874,7 @@ test_multi_session_random_usage(void)
ts_params->valid_devs[0],
sessions[i],
&ut_paramz[i].ut_params.auth_xform,
- ts_params->session_mpool);
+ ts_params->session_priv_mpool);
TEST_ASSERT_NOT_NULL(sessions[i],
"Session creation failed at session number %u",
@@ -6925,7 +6952,7 @@ test_null_cipher_only_operation(void)
rte_cryptodev_sym_session_init(ts_params->valid_devs[0],
ut_params->sess,
&ut_params->cipher_xform,
- ts_params->session_mpool);
+ ts_params->session_priv_mpool);
TEST_ASSERT_NOT_NULL(ut_params->sess, "Session creation failed");
/* Generate Crypto op data structure */
@@ -6998,7 +7025,7 @@ test_null_auth_only_operation(void)
/* Create Crypto session*/
rte_cryptodev_sym_session_init(ts_params->valid_devs[0],
ut_params->sess, &ut_params->auth_xform,
- ts_params->session_mpool);
+ ts_params->session_priv_mpool);
TEST_ASSERT_NOT_NULL(ut_params->sess, "Session creation failed");
/* Generate Crypto op data structure */
@@ -7077,7 +7104,7 @@ test_null_cipher_auth_operation(void)
/* Create Crypto session*/
rte_cryptodev_sym_session_init(ts_params->valid_devs[0],
ut_params->sess, &ut_params->cipher_xform,
- ts_params->session_mpool);
+ ts_params->session_priv_mpool);
TEST_ASSERT_NOT_NULL(ut_params->sess, "Session creation failed");
/* Generate Crypto op data structure */
@@ -7165,7 +7192,7 @@ test_null_auth_cipher_operation(void)
/* Create Crypto session*/
rte_cryptodev_sym_session_init(ts_params->valid_devs[0],
ut_params->sess, &ut_params->cipher_xform,
- ts_params->session_mpool);
+ ts_params->session_priv_mpool);
TEST_ASSERT_NOT_NULL(ut_params->sess, "Session creation failed");
/* Generate Crypto op data structure */
@@ -7235,7 +7262,7 @@ test_null_invalid_operation(void)
/* Create Crypto session*/
ret = rte_cryptodev_sym_session_init(ts_params->valid_devs[0],
ut_params->sess, &ut_params->cipher_xform,
- ts_params->session_mpool);
+ ts_params->session_priv_mpool);
TEST_ASSERT(ret < 0,
"Session creation succeeded unexpectedly");
@@ -7253,7 +7280,7 @@ test_null_invalid_operation(void)
/* Create Crypto session*/
ret = rte_cryptodev_sym_session_init(ts_params->valid_devs[0],
ut_params->sess, &ut_params->auth_xform,
- ts_params->session_mpool);
+ ts_params->session_priv_mpool);
TEST_ASSERT(ret < 0,
"Session creation succeeded unexpectedly");
@@ -7294,7 +7321,7 @@ test_null_burst_operation(void)
/* Create Crypto session*/
rte_cryptodev_sym_session_init(ts_params->valid_devs[0],
ut_params->sess, &ut_params->cipher_xform,
- ts_params->session_mpool);
+ ts_params->session_priv_mpool);
TEST_ASSERT_NOT_NULL(ut_params->sess, "Session creation failed");
TEST_ASSERT_EQUAL(rte_crypto_op_bulk_alloc(ts_params->op_mpool,
@@ -7429,7 +7456,7 @@ static int create_gmac_session(uint8_t dev_id,
rte_cryptodev_sym_session_init(dev_id, ut_params->sess,
&ut_params->auth_xform,
- ts_params->session_mpool);
+ ts_params->session_priv_mpool);
TEST_ASSERT_NOT_NULL(ut_params->sess, "Session creation failed");
@@ -7809,7 +7836,7 @@ create_auth_session(struct crypto_unittest_params *ut_params,
rte_cryptodev_sym_session_init(dev_id, ut_params->sess,
&ut_params->auth_xform,
- ts_params->session_mpool);
+ ts_params->session_priv_mpool);
TEST_ASSERT_NOT_NULL(ut_params->sess, "Session creation failed");
@@ -7862,7 +7889,7 @@ create_auth_cipher_session(struct crypto_unittest_params *ut_params,
rte_cryptodev_sym_session_init(dev_id, ut_params->sess,
&ut_params->auth_xform,
- ts_params->session_mpool);
+ ts_params->session_priv_mpool);
TEST_ASSERT_NOT_NULL(ut_params->sess, "Session creation failed");
@@ -8740,12 +8767,14 @@ test_scheduler_attach_slave_op(void)
for (i = 0; i < rte_cryptodev_count() && nb_devs_attached < 2;
i++) {
struct rte_cryptodev_info info;
+ unsigned int session_size;
rte_cryptodev_info_get(i, &info);
if (info.driver_id != rte_cryptodev_driver_id_get(
RTE_STR(CRYPTODEV_NAME_AESNI_MB_PMD)))
continue;
+ session_size = rte_cryptodev_sym_get_private_session_size(i);
/*
* Create the session mempool again, since now there are new devices
* to use the mempool.
@@ -8754,8 +8783,10 @@ test_scheduler_attach_slave_op(void)
rte_mempool_free(ts_params->session_mpool);
ts_params->session_mpool = NULL;
}
- unsigned int session_size =
- rte_cryptodev_sym_get_private_session_size(i);
+ if (ts_params->session_priv_mpool) {
+ rte_mempool_free(ts_params->session_priv_mpool);
+ ts_params->session_priv_mpool = NULL;
+ }
if (info.sym.max_nb_sessions != 0 &&
info.sym.max_nb_sessions < MAX_NB_SESSIONS) {
@@ -8766,22 +8797,40 @@ test_scheduler_attach_slave_op(void)
return TEST_FAILED;
}
/*
- * Create mempool with maximum number of sessions * 2,
+ * Create mempool with maximum number of sessions,
* to include the session headers
*/
if (ts_params->session_mpool == NULL) {
- ts_params->session_mpool = rte_mempool_create(
- "test_sess_mp",
- MAX_NB_SESSIONS * 2,
+ ts_params->session_mpool =
+ rte_cryptodev_sym_session_pool_create(
+ "test_sess_mp",
+ MAX_NB_SESSIONS, 0, 0, 0,
+ SOCKET_ID_ANY);
+ TEST_ASSERT_NOT_NULL(ts_params->session_mpool,
+ "session mempool allocation failed");
+ }
+
+ /*
+ * Create mempool with maximum number of sessions,
+ * to include device specific session private data
+ */
+ if (ts_params->session_priv_mpool == NULL) {
+ ts_params->session_priv_mpool = rte_mempool_create(
+ "test_sess_mp_priv",
+ MAX_NB_SESSIONS,
session_size,
0, 0, NULL, NULL, NULL,
NULL, SOCKET_ID_ANY,
0);
- TEST_ASSERT_NOT_NULL(ts_params->session_mpool,
+ TEST_ASSERT_NOT_NULL(ts_params->session_priv_mpool,
"session mempool allocation failed");
}
+ ts_params->qp_conf.mp_session = ts_params->session_mpool;
+ ts_params->qp_conf.mp_session_private =
+ ts_params->session_priv_mpool;
+
ret = rte_cryptodev_scheduler_slave_attach(sched_id,
(uint8_t)i);
diff --git a/test/test/test_cryptodev_blockcipher.c b/test/test/test_cryptodev_blockcipher.c
index 1c3f29f6b..4d6f46a6e 100644
--- a/test/test/test_cryptodev_blockcipher.c
+++ b/test/test/test_cryptodev_blockcipher.c
@@ -25,6 +25,7 @@ test_blockcipher_one_case(const struct blockcipher_test_case *t,
struct rte_mempool *mbuf_pool,
struct rte_mempool *op_mpool,
struct rte_mempool *sess_mpool,
+ struct rte_mempool *sess_priv_mpool,
uint8_t dev_id,
int driver_id,
char *test_msg)
@@ -347,7 +348,7 @@ test_blockcipher_one_case(const struct blockcipher_test_case *t,
sess = rte_cryptodev_sym_session_create(sess_mpool);
rte_cryptodev_sym_session_init(dev_id, sess, init_xform,
- sess_mpool);
+ sess_priv_mpool);
if (!sess) {
snprintf(test_msg, BLOCKCIPHER_TEST_MSG_LEN, "line %u "
"FAILED: %s", __LINE__,
@@ -615,6 +616,7 @@ int
test_blockcipher_all_tests(struct rte_mempool *mbuf_pool,
struct rte_mempool *op_mpool,
struct rte_mempool *sess_mpool,
+ struct rte_mempool *sess_priv_mpool,
uint8_t dev_id,
int driver_id,
enum blockcipher_test_type test_type)
@@ -730,7 +732,8 @@ test_blockcipher_all_tests(struct rte_mempool *mbuf_pool,
continue;
status = test_blockcipher_one_case(tc, mbuf_pool, op_mpool,
- sess_mpool, dev_id, driver_id, test_msg);
+ sess_mpool, sess_priv_mpool, dev_id, driver_id,
+ test_msg);
printf(" %u) TestCase %s %s\n", test_index ++,
tc->test_descr, test_msg);
diff --git a/test/test/test_cryptodev_blockcipher.h b/test/test/test_cryptodev_blockcipher.h
index f8bd85838..5c22d5da6 100644
--- a/test/test/test_cryptodev_blockcipher.h
+++ b/test/test/test_cryptodev_blockcipher.h
@@ -104,6 +104,7 @@ int
test_blockcipher_all_tests(struct rte_mempool *mbuf_pool,
struct rte_mempool *op_mpool,
struct rte_mempool *sess_mpool,
+ struct rte_mempool *sess_priv_mpool,
uint8_t dev_id,
int driver_id,
enum blockcipher_test_type test_type);
diff --git a/test/test/test_event_crypto_adapter.c b/test/test/test_event_crypto_adapter.c
index 54717870e..f750ce3d8 100644
--- a/test/test/test_event_crypto_adapter.c
+++ b/test/test/test_event_crypto_adapter.c
@@ -61,6 +61,7 @@ struct event_crypto_adapter_test_params {
struct rte_mempool *mbuf_pool;
struct rte_mempool *op_mpool;
struct rte_mempool *session_mpool;
+ struct rte_mempool *session_priv_mpool;
struct rte_cryptodev_config *config;
uint8_t crypto_event_port_id;
};
@@ -193,12 +194,13 @@ test_op_forward_mode(uint8_t session_less)
sym_op = op->sym;
if (!session_less) {
- sess = rte_cryptodev_sym_session_create(params.session_mpool);
+ sess = rte_cryptodev_sym_session_create(
+ params.session_mpool);
TEST_ASSERT_NOT_NULL(sess, "Session creation failed\n");
/* Create Crypto session*/
rte_cryptodev_sym_session_init(TEST_CDEV_ID, sess,
- &cipher_xform, params.session_mpool);
+ &cipher_xform, params.session_priv_mpool);
ret = rte_event_crypto_adapter_caps_get(TEST_ADAPTER_ID,
evdev, &cap);
@@ -381,7 +383,8 @@ test_op_new_mode(uint8_t session_less)
sym_op = op->sym;
if (!session_less) {
- sess = rte_cryptodev_sym_session_create(params.session_mpool);
+ sess = rte_cryptodev_sym_session_create(
+ params.session_mpool);
TEST_ASSERT_NOT_NULL(sess, "Session creation failed\n");
ret = rte_event_crypto_adapter_caps_get(TEST_ADAPTER_ID,
@@ -396,7 +399,7 @@ test_op_new_mode(uint8_t session_less)
&m_data, sizeof(m_data));
}
rte_cryptodev_sym_session_init(TEST_CDEV_ID, sess,
- &cipher_xform, params.session_mpool);
+ &cipher_xform, params.session_priv_mpool);
rte_crypto_op_attach_sym_session(op, sess);
} else {
struct rte_crypto_sym_xform *first_xform;
@@ -526,15 +529,20 @@ configure_cryptodev(void)
session_size = rte_cryptodev_sym_get_private_session_size(TEST_CDEV_ID);
session_size += sizeof(union rte_event_crypto_metadata);
- params.session_mpool = rte_mempool_create(
- "CRYPTO_ADAPTER_SESSION_MP",
- MAX_NB_SESSIONS * 2,
+ params.session_mpool = rte_cryptodev_sym_session_pool_create(
+ "CRYPTO_ADAPTER_SESSION_MP",
+ MAX_NB_SESSIONS, 0, 0, 0, SOCKET_ID_ANY);
+ TEST_ASSERT_NOT_NULL(params.session_mpool,
+ "session mempool allocation failed\n");
+
+ params.session_priv_mpool = rte_mempool_create(
+ "CRYPTO_ADAPTER_SESSION_MP_PRIV",
+ MAX_NB_SESSIONS,
session_size,
0, 0, NULL, NULL, NULL,
NULL, SOCKET_ID_ANY,
0);
-
- TEST_ASSERT_NOT_NULL(params.session_mpool,
+ TEST_ASSERT_NOT_NULL(params.session_priv_mpool,
"session mempool allocation failed\n");
rte_cryptodev_info_get(TEST_CDEV_ID, &info);
@@ -547,7 +555,7 @@ configure_cryptodev(void)
qp_conf.nb_descriptors = DEFAULT_NUM_OPS_INFLIGHT;
qp_conf.mp_session = params.session_mpool;
- qp_conf.mp_session_private = params.session_mpool;
+ qp_conf.mp_session_private = params.session_priv_mpool;
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
TEST_CDEV_ID, TEST_CDEV_QP_ID, &qp_conf,
@@ -859,6 +867,10 @@ crypto_teardown(void)
rte_mempool_free(params.session_mpool);
params.session_mpool = NULL;
}
+ if (params.session_priv_mpool != NULL) {
+ rte_mempool_free(params.session_priv_mpool);
+ params.session_priv_mpool = NULL;
+ }
/* Free ops mempool */
if (params.op_mpool != NULL) {
--
2.13.6
^ permalink raw reply [relevance 1%]
* [dpdk-dev] [PATCH v3 1/2] cryptodev: change queue pair configure structure
@ 2018-12-21 13:55 1% ` Fan Zhang
2019-01-08 23:20 3% ` De Lara Guarch, Pablo
2018-12-21 13:55 1% ` [dpdk-dev] [PATCH v3 2/2] cryptodev: change symmetric session structure Fan Zhang
2 siblings, 1 reply; 200+ results
From: Fan Zhang @ 2018-12-21 13:55 UTC (permalink / raw)
To: dev; +Cc: akhil.goyal, pablo.de.lara.guarch, fiona.trahe
This patch changes the cryptodev queue pair configure structure
to enable two mempool passed into cryptodev PMD simutaneously.
Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
Acked-by: Fiona Trahe <fiona.trahe@@intel.com>
---
app/test-crypto-perf/main.c | 6 ++--
doc/guides/rel_notes/release_19_02.rst | 5 +++
drivers/crypto/aesni_gcm/aesni_gcm_pmd.c | 7 ++--
drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c | 5 +--
drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h | 2 ++
drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 7 ++--
drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c | 5 +--
drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h | 2 ++
drivers/crypto/armv8/rte_armv8_pmd.c | 7 ++--
drivers/crypto/armv8/rte_armv8_pmd_ops.c | 5 +--
drivers/crypto/armv8/rte_armv8_pmd_private.h | 2 ++
drivers/crypto/caam_jr/caam_jr.c | 3 +-
drivers/crypto/ccp/ccp_pmd_ops.c | 5 +--
drivers/crypto/ccp/ccp_pmd_private.h | 2 ++
drivers/crypto/ccp/rte_ccp_pmd.c | 9 +++++-
drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c | 3 +-
drivers/crypto/dpaa_sec/dpaa_sec.c | 3 +-
drivers/crypto/kasumi/rte_kasumi_pmd.c | 7 ++--
drivers/crypto/kasumi/rte_kasumi_pmd_ops.c | 5 +--
drivers/crypto/kasumi/rte_kasumi_pmd_private.h | 2 ++
drivers/crypto/mvsam/rte_mrvl_pmd_ops.c | 5 +--
drivers/crypto/mvsam/rte_mrvl_pmd_private.h | 3 ++
drivers/crypto/null/null_crypto_pmd.c | 5 +--
drivers/crypto/null/null_crypto_pmd_ops.c | 5 +--
drivers/crypto/null/null_crypto_pmd_private.h | 2 ++
drivers/crypto/octeontx/otx_cryptodev_ops.c | 3 +-
drivers/crypto/openssl/rte_openssl_pmd.c | 7 ++--
drivers/crypto/openssl/rte_openssl_pmd_ops.c | 5 +--
drivers/crypto/openssl/rte_openssl_pmd_private.h | 2 ++
drivers/crypto/qat/qat_sym_pmd.c | 2 +-
drivers/crypto/scheduler/scheduler_pmd_ops.c | 5 ++-
drivers/crypto/snow3g/rte_snow3g_pmd.c | 7 ++--
drivers/crypto/snow3g/rte_snow3g_pmd_ops.c | 5 +--
drivers/crypto/snow3g/rte_snow3g_pmd_private.h | 2 ++
drivers/crypto/virtio/virtio_cryptodev.c | 6 ++--
drivers/crypto/zuc/rte_zuc_pmd.c | 7 ++--
drivers/crypto/zuc/rte_zuc_pmd_ops.c | 5 +--
drivers/crypto/zuc/rte_zuc_pmd_private.h | 2 ++
drivers/net/softnic/rte_eth_softnic_cryptodev.c | 2 +-
examples/fips_validation/main.c | 4 +--
examples/ip_pipeline/cryptodev.c | 2 +-
examples/ipsec-secgw/ipsec-secgw.c | 7 ++--
examples/l2fwd-crypto/main.c | 4 ++-
examples/vhost_crypto/main.c | 9 ++++--
lib/librte_cryptodev/rte_cryptodev.c | 5 ++-
lib/librte_cryptodev/rte_cryptodev.h | 7 ++--
lib/librte_cryptodev/rte_cryptodev_pmd.h | 3 +-
test/test/test_cryptodev.c | 37 +++++++++-------------
test/test/test_cryptodev_asym.c | 8 ++---
test/test/test_event_crypto_adapter.c | 5 +--
50 files changed, 156 insertions(+), 107 deletions(-)
diff --git a/app/test-crypto-perf/main.c b/app/test-crypto-perf/main.c
index 953e058c9..38a2e429f 100644
--- a/app/test-crypto-perf/main.c
+++ b/app/test-crypto-perf/main.c
@@ -218,6 +218,9 @@ cperf_initialize_cryptodev(struct cperf_options *opts, uint8_t *enabled_cdevs,
session_pool_socket[socket_id] = sess_mp;
}
+ qp_conf.mp_session = session_pool_socket[socket_id];
+ qp_conf.mp_session_private = session_pool_socket[socket_id];
+
ret = rte_cryptodev_configure(cdev_id, &conf);
if (ret < 0) {
printf("Failed to configure cryptodev %u", cdev_id);
@@ -226,8 +229,7 @@ cperf_initialize_cryptodev(struct cperf_options *opts, uint8_t *enabled_cdevs,
for (j = 0; j < opts->nb_qps; j++) {
ret = rte_cryptodev_queue_pair_setup(cdev_id, j,
- &qp_conf, socket_id,
- session_pool_socket[socket_id]);
+ &qp_conf, socket_id);
if (ret < 0) {
printf("Failed to setup queue pair %u on "
"cryptodev %u", j, cdev_id);
diff --git a/doc/guides/rel_notes/release_19_02.rst b/doc/guides/rel_notes/release_19_02.rst
index 47768288a..4420c2441 100644
--- a/doc/guides/rel_notes/release_19_02.rst
+++ b/doc/guides/rel_notes/release_19_02.rst
@@ -130,6 +130,11 @@ API Changes
``rte_pdump_init()`` and enum ``rte_pdump_socktype`` were deprecated
since 18.05 and are removed in this release.
+* cryptodev: as shown in the the 18.08 deprecation notice, the structure
+ ``rte_cryptodev_qp_conf`` has been added two parameters of symmetric session
+ mempool and symmetric session private data mempool, and the last parameter of
+ ``rte_cryptodev_queue_pair_setup()`` is removed.
+
ABI Changes
-----------
diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
index ebdf7c35a..abc7a6d5f 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
@@ -151,7 +151,8 @@ aesni_gcm_get_session(struct aesni_gcm_qp *qp, struct rte_crypto_op *op)
if (rte_mempool_get(qp->sess_mp, (void **)&_sess))
return NULL;
- if (rte_mempool_get(qp->sess_mp, (void **)&_sess_private_data))
+ if (rte_mempool_get(qp->sess_mp_priv,
+ (void **)&_sess_private_data))
return NULL;
sess = (struct aesni_gcm_session *)_sess_private_data;
@@ -159,7 +160,7 @@ aesni_gcm_get_session(struct aesni_gcm_qp *qp, struct rte_crypto_op *op)
if (unlikely(aesni_gcm_set_session_parameters(qp->ops,
sess, sym_op->xform) != 0)) {
rte_mempool_put(qp->sess_mp, _sess);
- rte_mempool_put(qp->sess_mp, _sess_private_data);
+ rte_mempool_put(qp->sess_mp_priv, _sess_private_data);
sess = NULL;
}
sym_op->session = (struct rte_cryptodev_sym_session *)_sess;
@@ -419,7 +420,7 @@ handle_completed_gcm_crypto_op(struct aesni_gcm_qp *qp,
memset(sess, 0, sizeof(struct aesni_gcm_session));
memset(op->sym->session, 0,
rte_cryptodev_sym_get_header_session_size());
- rte_mempool_put(qp->sess_mp, sess);
+ rte_mempool_put(qp->sess_mp_priv, sess);
rte_mempool_put(qp->sess_mp, op->sym->session);
op->sym->session = NULL;
}
diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c b/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
index c343a393f..2f70f2a1a 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
@@ -201,7 +201,7 @@ aesni_gcm_pmd_qp_create_processed_pkts_ring(struct aesni_gcm_qp *qp,
static int
aesni_gcm_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool)
+ int socket_id)
{
struct aesni_gcm_qp *qp = NULL;
struct aesni_gcm_private *internals = dev->data->dev_private;
@@ -229,7 +229,8 @@ aesni_gcm_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
if (qp->processed_pkts == NULL)
goto qp_setup_cleanup;
- qp->sess_mp = session_pool;
+ qp->sess_mp = qp_conf->mp_session;
+ qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->qp_stats, 0, sizeof(qp->qp_stats));
diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h b/drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h
index 92b041354..903e7503d 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h
@@ -48,6 +48,8 @@ struct aesni_gcm_qp {
/**< Queue pair statistics */
struct rte_mempool *sess_mp;
/**< Session Mempool */
+ struct rte_mempool *sess_mp_priv;
+ /**< Session Private Data Mempool */
uint16_t id;
/**< Queue Pair Identifier */
char name[RTE_CRYPTODEV_NAME_MAX_LEN];
diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
index 83250e32c..b0f5c4d67 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
@@ -668,7 +668,8 @@ get_session(struct aesni_mb_qp *qp, struct rte_crypto_op *op)
if (rte_mempool_get(qp->sess_mp, (void **)&_sess))
return NULL;
- if (rte_mempool_get(qp->sess_mp, (void **)&_sess_private_data))
+ if (rte_mempool_get(qp->sess_mp_priv,
+ (void **)&_sess_private_data))
return NULL;
sess = (struct aesni_mb_session *)_sess_private_data;
@@ -676,7 +677,7 @@ get_session(struct aesni_mb_qp *qp, struct rte_crypto_op *op)
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, _sess_private_data);
+ rte_mempool_put(qp->sess_mp_priv, _sess_private_data);
sess = NULL;
}
op->sym->session = (struct rte_cryptodev_sym_session *)_sess;
@@ -951,7 +952,7 @@ post_process_mb_job(struct aesni_mb_qp *qp, JOB_AES_HMAC *job)
memset(sess, 0, sizeof(struct aesni_mb_session));
memset(op->sym->session, 0,
rte_cryptodev_sym_get_header_session_size());
- rte_mempool_put(qp->sess_mp, sess);
+ rte_mempool_put(qp->sess_mp_priv, sess);
rte_mempool_put(qp->sess_mp, op->sym->session);
op->sym->session = NULL;
}
diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c
index f3eff2685..af3021616 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c
@@ -566,7 +566,7 @@ aesni_mb_pmd_qp_create_processed_ops_ring(struct aesni_mb_qp *qp,
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 rte_mempool *session_pool)
+ int socket_id)
{
struct aesni_mb_qp *qp = NULL;
struct aesni_mb_private *internals = dev->data->dev_private;
@@ -604,7 +604,8 @@ aesni_mb_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
goto qp_setup_cleanup;
}
- qp->sess_mp = session_pool;
+ qp->sess_mp = qp_conf->mp_session;
+ qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->stats, 0, sizeof(qp->stats));
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 d8021cdaa..923403336 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h
@@ -131,6 +131,8 @@ struct aesni_mb_qp {
/**< Ring for placing operations ready for processing */
struct rte_mempool *sess_mp;
/**< Session Mempool */
+ struct rte_mempool *sess_mp_priv;
+ /**< Session Private Data Mempool */
struct rte_cryptodev_stats stats;
/**< Queue pair statistics */
uint8_t digest_idx;
diff --git a/drivers/crypto/armv8/rte_armv8_pmd.c b/drivers/crypto/armv8/rte_armv8_pmd.c
index 9d15fee53..3b2d7fb2f 100644
--- a/drivers/crypto/armv8/rte_armv8_pmd.c
+++ b/drivers/crypto/armv8/rte_armv8_pmd.c
@@ -514,7 +514,8 @@ get_session(struct armv8_crypto_qp *qp, struct rte_crypto_op *op)
if (rte_mempool_get(qp->sess_mp, (void **)&_sess))
return NULL;
- if (rte_mempool_get(qp->sess_mp, (void **)&_sess_private_data))
+ if (rte_mempool_get(qp->sess_mp_priv,
+ (void **)&_sess_private_data))
return NULL;
sess = (struct armv8_crypto_session *)_sess_private_data;
@@ -522,7 +523,7 @@ get_session(struct armv8_crypto_qp *qp, struct rte_crypto_op *op)
if (unlikely(armv8_crypto_set_session_parameters(sess,
op->sym->xform) != 0)) {
rte_mempool_put(qp->sess_mp, _sess);
- rte_mempool_put(qp->sess_mp, _sess_private_data);
+ rte_mempool_put(qp->sess_mp_priv, _sess_private_data);
sess = NULL;
}
op->sym->session = (struct rte_cryptodev_sym_session *)_sess;
@@ -656,7 +657,7 @@ process_op(struct armv8_crypto_qp *qp, struct rte_crypto_op *op,
memset(op->sym->session, 0,
rte_cryptodev_sym_get_header_session_size());
rte_mempool_put(qp->sess_mp, sess);
- rte_mempool_put(qp->sess_mp, op->sym->session);
+ rte_mempool_put(qp->sess_mp_priv, op->sym->session);
op->sym->session = NULL;
}
diff --git a/drivers/crypto/armv8/rte_armv8_pmd_ops.c b/drivers/crypto/armv8/rte_armv8_pmd_ops.c
index ae03117ea..a4fee83a8 100644
--- a/drivers/crypto/armv8/rte_armv8_pmd_ops.c
+++ b/drivers/crypto/armv8/rte_armv8_pmd_ops.c
@@ -220,7 +220,7 @@ armv8_crypto_pmd_qp_create_processed_ops_ring(struct armv8_crypto_qp *qp,
static int
armv8_crypto_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool)
+ int socket_id)
{
struct armv8_crypto_qp *qp = NULL;
@@ -245,7 +245,8 @@ armv8_crypto_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
if (qp->processed_ops == NULL)
goto qp_setup_cleanup;
- qp->sess_mp = session_pool;
+ qp->sess_mp = qp_conf->mp_session;
+ qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->stats, 0, sizeof(qp->stats));
diff --git a/drivers/crypto/armv8/rte_armv8_pmd_private.h b/drivers/crypto/armv8/rte_armv8_pmd_private.h
index 7feb021db..0afd9c7c5 100644
--- a/drivers/crypto/armv8/rte_armv8_pmd_private.h
+++ b/drivers/crypto/armv8/rte_armv8_pmd_private.h
@@ -116,6 +116,8 @@ struct armv8_crypto_qp {
/**< Ring for placing process packets */
struct rte_mempool *sess_mp;
/**< Session Mempool */
+ struct rte_mempool *sess_mp_priv;
+ /**< Session Private Data Mempool */
struct rte_cryptodev_stats stats;
/**< Queue pair statistics */
char name[RTE_CRYPTODEV_NAME_MAX_LEN];
diff --git a/drivers/crypto/caam_jr/caam_jr.c b/drivers/crypto/caam_jr/caam_jr.c
index f505adf6b..45b281331 100644
--- a/drivers/crypto/caam_jr/caam_jr.c
+++ b/drivers/crypto/caam_jr/caam_jr.c
@@ -1540,8 +1540,7 @@ static int
caam_jr_queue_pair_setup(
struct rte_cryptodev *dev, uint16_t qp_id,
__rte_unused const struct rte_cryptodev_qp_conf *qp_conf,
- __rte_unused int socket_id,
- __rte_unused struct rte_mempool *session_pool)
+ __rte_unused int socket_id)
{
struct sec_job_ring_t *internals;
struct caam_jr_qp *qp = NULL;
diff --git a/drivers/crypto/ccp/ccp_pmd_ops.c b/drivers/crypto/ccp/ccp_pmd_ops.c
index 6984913f1..d5041f0ec 100644
--- a/drivers/crypto/ccp/ccp_pmd_ops.c
+++ b/drivers/crypto/ccp/ccp_pmd_ops.c
@@ -685,7 +685,7 @@ ccp_pmd_qp_create_batch_info_ring(struct ccp_qp *qp,
static int
ccp_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool)
+ int socket_id)
{
struct ccp_private *internals = dev->data->dev_private;
struct ccp_qp *qp;
@@ -726,7 +726,8 @@ ccp_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
goto qp_setup_cleanup;
}
- qp->sess_mp = session_pool;
+ qp->sess_mp = qp_conf->mp_session;
+ qp->sess_mp_priv = qp_conf->mp_session_private;
/* mempool for batch info */
qp->batch_mp = rte_mempool_create(
diff --git a/drivers/crypto/ccp/ccp_pmd_private.h b/drivers/crypto/ccp/ccp_pmd_private.h
index 79752f687..7f2979e89 100644
--- a/drivers/crypto/ccp/ccp_pmd_private.h
+++ b/drivers/crypto/ccp/ccp_pmd_private.h
@@ -76,6 +76,8 @@ struct ccp_qp {
/**< Ring for placing process packets */
struct rte_mempool *sess_mp;
/**< Session Mempool */
+ struct rte_mempool *sess_mp_priv;
+ /**< Session Private Data Mempool */
struct rte_mempool *batch_mp;
/**< Session Mempool for batch info */
struct rte_cryptodev_stats qp_stats;
diff --git a/drivers/crypto/ccp/rte_ccp_pmd.c b/drivers/crypto/ccp/rte_ccp_pmd.c
index 92d8a9559..b4bb5528f 100644
--- a/drivers/crypto/ccp/rte_ccp_pmd.c
+++ b/drivers/crypto/ccp/rte_ccp_pmd.c
@@ -179,7 +179,7 @@ get_ccp_session(struct ccp_qp *qp, struct rte_crypto_op *op)
if (unlikely(ccp_set_session_parameters(sess, op->sym->xform,
internals) != 0)) {
rte_mempool_put(qp->sess_mp, _sess);
- rte_mempool_put(qp->sess_mp, _sess_private_data);
+ rte_mempool_put(qp->sess_mp_priv, _sess_private_data);
sess = NULL;
}
op->sym->session = (struct rte_cryptodev_sym_session *)_sess;
@@ -241,6 +241,13 @@ ccp_pmd_dequeue_burst(void *queue_pair, struct rte_crypto_op **ops,
for (i = 0; i < nb_dequeued; i++)
if (unlikely(ops[i]->sess_type ==
RTE_CRYPTO_OP_SESSIONLESS)) {
+ struct ccp_session *sess = (struct ccp_session *)
+ get_sym_session_private_data(
+ ops[i]->sym->session,
+ ccp_cryptodev_driver_id);
+
+ rte_mempool_put(qp->sess_mp_priv,
+ sess);
rte_mempool_put(qp->sess_mp,
ops[i]->sym->session);
ops[i]->sym->session = NULL;
diff --git a/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c b/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
index 6095c6021..82220ac4f 100644
--- a/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
+++ b/drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c
@@ -1518,8 +1518,7 @@ dpaa2_sec_queue_pair_release(struct rte_cryptodev *dev, uint16_t queue_pair_id)
static int
dpaa2_sec_queue_pair_setup(struct rte_cryptodev *dev, uint16_t qp_id,
__rte_unused const struct rte_cryptodev_qp_conf *qp_conf,
- __rte_unused int socket_id,
- __rte_unused struct rte_mempool *session_pool)
+ __rte_unused int socket_id)
{
struct dpaa2_sec_dev_private *priv = dev->data->dev_private;
struct dpaa2_sec_qp *qp;
diff --git a/drivers/crypto/dpaa_sec/dpaa_sec.c b/drivers/crypto/dpaa_sec/dpaa_sec.c
index d83e74541..c95e43b7f 100644
--- a/drivers/crypto/dpaa_sec/dpaa_sec.c
+++ b/drivers/crypto/dpaa_sec/dpaa_sec.c
@@ -1661,8 +1661,7 @@ dpaa_sec_queue_pair_release(struct rte_cryptodev *dev,
static int
dpaa_sec_queue_pair_setup(struct rte_cryptodev *dev, uint16_t qp_id,
__rte_unused const struct rte_cryptodev_qp_conf *qp_conf,
- __rte_unused int socket_id,
- __rte_unused struct rte_mempool *session_pool)
+ __rte_unused int socket_id)
{
struct dpaa_sec_dev_private *internals;
struct dpaa_sec_qp *qp = NULL;
diff --git a/drivers/crypto/kasumi/rte_kasumi_pmd.c b/drivers/crypto/kasumi/rte_kasumi_pmd.c
index 239a1cf44..6df645a23 100644
--- a/drivers/crypto/kasumi/rte_kasumi_pmd.c
+++ b/drivers/crypto/kasumi/rte_kasumi_pmd.c
@@ -145,7 +145,8 @@ kasumi_get_session(struct kasumi_qp *qp, struct rte_crypto_op *op)
if (rte_mempool_get(qp->sess_mp, (void **)&_sess))
return NULL;
- if (rte_mempool_get(qp->sess_mp, (void **)&_sess_private_data))
+ if (rte_mempool_get(qp->sess_mp_priv,
+ (void **)&_sess_private_data))
return NULL;
sess = (struct kasumi_session *)_sess_private_data;
@@ -153,7 +154,7 @@ kasumi_get_session(struct kasumi_qp *qp, struct rte_crypto_op *op)
if (unlikely(kasumi_set_session_parameters(sess,
op->sym->xform) != 0)) {
rte_mempool_put(qp->sess_mp, _sess);
- rte_mempool_put(qp->sess_mp, _sess_private_data);
+ rte_mempool_put(qp->sess_mp_priv, _sess_private_data);
sess = NULL;
}
op->sym->session = (struct rte_cryptodev_sym_session *)_sess;
@@ -325,7 +326,7 @@ process_ops(struct rte_crypto_op **ops, struct kasumi_session *session,
memset(session, 0, sizeof(struct kasumi_session));
memset(ops[i]->sym->session, 0,
rte_cryptodev_sym_get_header_session_size());
- rte_mempool_put(qp->sess_mp, session);
+ rte_mempool_put(qp->sess_mp_priv, session);
rte_mempool_put(qp->sess_mp, ops[i]->sym->session);
ops[i]->sym->session = NULL;
}
diff --git a/drivers/crypto/kasumi/rte_kasumi_pmd_ops.c b/drivers/crypto/kasumi/rte_kasumi_pmd_ops.c
index 9e4bf1b52..a4982f091 100644
--- a/drivers/crypto/kasumi/rte_kasumi_pmd_ops.c
+++ b/drivers/crypto/kasumi/rte_kasumi_pmd_ops.c
@@ -192,7 +192,7 @@ kasumi_pmd_qp_create_processed_ops_ring(struct kasumi_qp *qp,
static int
kasumi_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool)
+ int socket_id)
{
struct kasumi_qp *qp = NULL;
@@ -217,7 +217,8 @@ kasumi_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
if (qp->processed_ops == NULL)
goto qp_setup_cleanup;
- qp->sess_mp = session_pool;
+ qp->sess_mp = qp_conf->mp_session;
+ qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->qp_stats, 0, sizeof(qp->qp_stats));
diff --git a/drivers/crypto/kasumi/rte_kasumi_pmd_private.h b/drivers/crypto/kasumi/rte_kasumi_pmd_private.h
index 488777ca8..76f746c03 100644
--- a/drivers/crypto/kasumi/rte_kasumi_pmd_private.h
+++ b/drivers/crypto/kasumi/rte_kasumi_pmd_private.h
@@ -36,6 +36,8 @@ struct kasumi_qp {
/**< Ring for placing processed ops */
struct rte_mempool *sess_mp;
/**< Session Mempool */
+ struct rte_mempool *sess_mp_priv;
+ /**< Session Private Data Mempool */
struct rte_cryptodev_stats qp_stats;
/**< Queue pair statistics */
uint8_t temp_digest[KASUMI_DIGEST_LENGTH];
diff --git a/drivers/crypto/mvsam/rte_mrvl_pmd_ops.c b/drivers/crypto/mvsam/rte_mrvl_pmd_ops.c
index 9956f051f..ef520356f 100644
--- a/drivers/crypto/mvsam/rte_mrvl_pmd_ops.c
+++ b/drivers/crypto/mvsam/rte_mrvl_pmd_ops.c
@@ -633,7 +633,7 @@ mrvl_crypto_pmd_close(struct rte_cryptodev *dev)
static int
mrvl_crypto_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool)
+ int socket_id)
{
struct mrvl_crypto_qp *qp = NULL;
char match[RTE_CRYPTODEV_NAME_MAX_LEN];
@@ -690,7 +690,8 @@ mrvl_crypto_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
if (sam_cio_init(&qp->cio_params, &qp->cio) < 0)
break;
- qp->sess_mp = session_pool;
+ qp->sess_mp = qp_conf->mp_session;
+ qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->stats, 0, sizeof(qp->stats));
dev->data->queue_pairs[qp_id] = qp;
diff --git a/drivers/crypto/mvsam/rte_mrvl_pmd_private.h b/drivers/crypto/mvsam/rte_mrvl_pmd_private.h
index 6f8cf5624..deb80c55d 100644
--- a/drivers/crypto/mvsam/rte_mrvl_pmd_private.h
+++ b/drivers/crypto/mvsam/rte_mrvl_pmd_private.h
@@ -51,6 +51,9 @@ struct mrvl_crypto_qp {
/** Session Mempool. */
struct rte_mempool *sess_mp;
+ /** Session Private Data Mempool. */
+ struct rte_mempool *sess_mp_priv;
+
/** Queue pair statistics. */
struct rte_cryptodev_stats stats;
diff --git a/drivers/crypto/null/null_crypto_pmd.c b/drivers/crypto/null/null_crypto_pmd.c
index 6e29a21a6..d5e3064f2 100644
--- a/drivers/crypto/null/null_crypto_pmd.c
+++ b/drivers/crypto/null/null_crypto_pmd.c
@@ -87,7 +87,8 @@ get_session(struct null_crypto_qp *qp, struct rte_crypto_op *op)
if (rte_mempool_get(qp->sess_mp, (void **)&_sess))
return NULL;
- if (rte_mempool_get(qp->sess_mp, (void **)&_sess_private_data))
+ if (rte_mempool_get(qp->sess_mp_priv,
+ (void **)&_sess_private_data))
return NULL;
sess = (struct null_crypto_session *)_sess_private_data;
@@ -95,7 +96,7 @@ get_session(struct null_crypto_qp *qp, struct rte_crypto_op *op)
if (unlikely(null_crypto_set_session_parameters(sess,
sym_op->xform) != 0)) {
rte_mempool_put(qp->sess_mp, _sess);
- rte_mempool_put(qp->sess_mp, _sess_private_data);
+ rte_mempool_put(qp->sess_mp_priv, _sess_private_data);
sess = NULL;
}
sym_op->session = (struct rte_cryptodev_sym_session *)_sess;
diff --git a/drivers/crypto/null/null_crypto_pmd_ops.c b/drivers/crypto/null/null_crypto_pmd_ops.c
index 2bdcd019e..941d62bed 100644
--- a/drivers/crypto/null/null_crypto_pmd_ops.c
+++ b/drivers/crypto/null/null_crypto_pmd_ops.c
@@ -184,7 +184,7 @@ null_crypto_pmd_qp_create_processed_pkts_ring(struct null_crypto_qp *qp,
static int
null_crypto_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool)
+ int socket_id)
{
struct null_crypto_private *internals = dev->data->dev_private;
struct null_crypto_qp *qp;
@@ -228,7 +228,8 @@ null_crypto_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
goto qp_setup_cleanup;
}
- qp->sess_mp = session_pool;
+ qp->sess_mp = qp_conf->mp_session;
+ qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->qp_stats, 0, sizeof(qp->qp_stats));
diff --git a/drivers/crypto/null/null_crypto_pmd_private.h b/drivers/crypto/null/null_crypto_pmd_private.h
index d5905afd8..d7bfd9cc8 100644
--- a/drivers/crypto/null/null_crypto_pmd_private.h
+++ b/drivers/crypto/null/null_crypto_pmd_private.h
@@ -31,6 +31,8 @@ struct null_crypto_qp {
/**< Ring for placing process packets */
struct rte_mempool *sess_mp;
/**< Session Mempool */
+ struct rte_mempool *sess_mp_priv;
+ /**< Session Mempool */
struct rte_cryptodev_stats qp_stats;
/**< Queue pair statistics */
} __rte_cache_aligned;
diff --git a/drivers/crypto/octeontx/otx_cryptodev_ops.c b/drivers/crypto/octeontx/otx_cryptodev_ops.c
index 90d0c14b8..6a0cf83f4 100644
--- a/drivers/crypto/octeontx/otx_cryptodev_ops.c
+++ b/drivers/crypto/octeontx/otx_cryptodev_ops.c
@@ -186,8 +186,7 @@ static int
otx_cpt_que_pair_setup(struct rte_cryptodev *dev,
uint16_t que_pair_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id __rte_unused,
- struct rte_mempool *session_pool __rte_unused)
+ int socket_id __rte_unused)
{
void *cptvf = dev->data->dev_private;
struct cpt_instance *instance = NULL;
diff --git a/drivers/crypto/openssl/rte_openssl_pmd.c b/drivers/crypto/openssl/rte_openssl_pmd.c
index a0ccacb1e..a193af642 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd.c
@@ -768,7 +768,8 @@ get_session(struct openssl_qp *qp, struct rte_crypto_op *op)
if (rte_mempool_get(qp->sess_mp, (void **)&_sess))
return NULL;
- if (rte_mempool_get(qp->sess_mp, (void **)&_sess_private_data))
+ if (rte_mempool_get(qp->sess_mp_priv,
+ (void **)&_sess_private_data))
return NULL;
sess = (struct openssl_session *)_sess_private_data;
@@ -776,7 +777,7 @@ get_session(struct openssl_qp *qp, struct rte_crypto_op *op)
if (unlikely(openssl_set_session_parameters(sess,
op->sym->xform) != 0)) {
rte_mempool_put(qp->sess_mp, _sess);
- rte_mempool_put(qp->sess_mp, _sess_private_data);
+ rte_mempool_put(qp->sess_mp_priv, _sess_private_data);
sess = NULL;
}
op->sym->session = (struct rte_cryptodev_sym_session *)_sess;
@@ -2020,7 +2021,7 @@ process_op(struct openssl_qp *qp, struct rte_crypto_op *op,
memset(sess, 0, sizeof(struct openssl_session));
memset(op->sym->session, 0,
rte_cryptodev_sym_get_header_session_size());
- rte_mempool_put(qp->sess_mp, sess);
+ rte_mempool_put(qp->sess_mp_priv, sess);
rte_mempool_put(qp->sess_mp, op->sym->session);
op->sym->session = NULL;
}
diff --git a/drivers/crypto/openssl/rte_openssl_pmd_ops.c b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
index bdaf937a3..5644f593a 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd_ops.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
@@ -710,7 +710,7 @@ openssl_pmd_qp_create_processed_ops_ring(struct openssl_qp *qp,
static int
openssl_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool)
+ int socket_id)
{
struct openssl_qp *qp = NULL;
@@ -735,7 +735,8 @@ openssl_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
if (qp->processed_ops == NULL)
goto qp_setup_cleanup;
- qp->sess_mp = session_pool;
+ qp->sess_mp = qp_conf->mp_session;
+ qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->stats, 0, sizeof(qp->stats));
diff --git a/drivers/crypto/openssl/rte_openssl_pmd_private.h b/drivers/crypto/openssl/rte_openssl_pmd_private.h
index a8f2c8482..43ac3813d 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd_private.h
+++ b/drivers/crypto/openssl/rte_openssl_pmd_private.h
@@ -64,6 +64,8 @@ struct openssl_qp {
/**< Ring for placing process packets */
struct rte_mempool *sess_mp;
/**< Session Mempool */
+ struct rte_mempool *sess_mp_priv;
+ /**< Session Private Data Mempool */
struct rte_cryptodev_stats stats;
/**< Queue pair statistics */
uint8_t temp_digest[DIGEST_LENGTH_MAX];
diff --git a/drivers/crypto/qat/qat_sym_pmd.c b/drivers/crypto/qat/qat_sym_pmd.c
index c3f700406..31ccab32e 100644
--- a/drivers/crypto/qat/qat_sym_pmd.c
+++ b/drivers/crypto/qat/qat_sym_pmd.c
@@ -127,7 +127,7 @@ static int qat_sym_qp_release(struct rte_cryptodev *dev, uint16_t queue_pair_id)
static int qat_sym_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool __rte_unused)
+ int socket_id)
{
struct qat_qp *qp;
int ret = 0;
diff --git a/drivers/crypto/scheduler/scheduler_pmd_ops.c b/drivers/crypto/scheduler/scheduler_pmd_ops.c
index 939105aa8..cf70218b7 100644
--- a/drivers/crypto/scheduler/scheduler_pmd_ops.c
+++ b/drivers/crypto/scheduler/scheduler_pmd_ops.c
@@ -390,8 +390,7 @@ scheduler_pmd_qp_release(struct rte_cryptodev *dev, uint16_t qp_id)
/** Setup a queue pair */
static int
scheduler_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
- const struct rte_cryptodev_qp_conf *qp_conf, int socket_id,
- struct rte_mempool *session_pool)
+ const struct rte_cryptodev_qp_conf *qp_conf, int socket_id)
{
struct scheduler_ctx *sched_ctx = dev->data->dev_private;
struct scheduler_qp_ctx *qp_ctx;
@@ -419,7 +418,7 @@ scheduler_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
* must be big enough for all the drivers used.
*/
ret = rte_cryptodev_queue_pair_setup(slave_id, qp_id,
- qp_conf, socket_id, session_pool);
+ qp_conf, socket_id);
if (ret < 0)
return ret;
}
diff --git a/drivers/crypto/snow3g/rte_snow3g_pmd.c b/drivers/crypto/snow3g/rte_snow3g_pmd.c
index a17536b77..7d131f780 100644
--- a/drivers/crypto/snow3g/rte_snow3g_pmd.c
+++ b/drivers/crypto/snow3g/rte_snow3g_pmd.c
@@ -147,7 +147,8 @@ snow3g_get_session(struct snow3g_qp *qp, struct rte_crypto_op *op)
if (rte_mempool_get(qp->sess_mp, (void **)&_sess))
return NULL;
- if (rte_mempool_get(qp->sess_mp, (void **)&_sess_private_data))
+ if (rte_mempool_get(qp->sess_mp_priv,
+ (void **)&_sess_private_data))
return NULL;
sess = (struct snow3g_session *)_sess_private_data;
@@ -155,7 +156,7 @@ snow3g_get_session(struct snow3g_qp *qp, struct rte_crypto_op *op)
if (unlikely(snow3g_set_session_parameters(sess,
op->sym->xform) != 0)) {
rte_mempool_put(qp->sess_mp, _sess);
- rte_mempool_put(qp->sess_mp, _sess_private_data);
+ rte_mempool_put(qp->sess_mp_priv, _sess_private_data);
sess = NULL;
}
op->sym->session = (struct rte_cryptodev_sym_session *)_sess;
@@ -340,7 +341,7 @@ process_ops(struct rte_crypto_op **ops, struct snow3g_session *session,
memset(session, 0, sizeof(struct snow3g_session));
memset(ops[i]->sym->session, 0,
rte_cryptodev_sym_get_header_session_size());
- rte_mempool_put(qp->sess_mp, session);
+ rte_mempool_put(qp->sess_mp_priv, session);
rte_mempool_put(qp->sess_mp, ops[i]->sym->session);
ops[i]->sym->session = NULL;
}
diff --git a/drivers/crypto/snow3g/rte_snow3g_pmd_ops.c b/drivers/crypto/snow3g/rte_snow3g_pmd_ops.c
index cfbc9522a..fad483c75 100644
--- a/drivers/crypto/snow3g/rte_snow3g_pmd_ops.c
+++ b/drivers/crypto/snow3g/rte_snow3g_pmd_ops.c
@@ -193,7 +193,7 @@ snow3g_pmd_qp_create_processed_ops_ring(struct snow3g_qp *qp,
static int
snow3g_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool)
+ int socket_id)
{
struct snow3g_qp *qp = NULL;
@@ -218,7 +218,8 @@ snow3g_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
if (qp->processed_ops == NULL)
goto qp_setup_cleanup;
- qp->sess_mp = session_pool;
+ qp->sess_mp = qp_conf->mp_session;
+ qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->qp_stats, 0, sizeof(qp->qp_stats));
diff --git a/drivers/crypto/snow3g/rte_snow3g_pmd_private.h b/drivers/crypto/snow3g/rte_snow3g_pmd_private.h
index b7807b621..df5c6092b 100644
--- a/drivers/crypto/snow3g/rte_snow3g_pmd_private.h
+++ b/drivers/crypto/snow3g/rte_snow3g_pmd_private.h
@@ -36,6 +36,8 @@ struct snow3g_qp {
/**< Ring for placing processed ops */
struct rte_mempool *sess_mp;
/**< Session Mempool */
+ struct rte_mempool *sess_mp_priv;
+ /**< Session Private Data Mempool */
struct rte_cryptodev_stats qp_stats;
/**< Queue pair statistics */
uint8_t temp_digest[SNOW3G_DIGEST_LENGTH];
diff --git a/drivers/crypto/virtio/virtio_cryptodev.c b/drivers/crypto/virtio/virtio_cryptodev.c
index 568b5a406..4bae3b865 100644
--- a/drivers/crypto/virtio/virtio_cryptodev.c
+++ b/drivers/crypto/virtio/virtio_cryptodev.c
@@ -36,8 +36,7 @@ static void virtio_crypto_dev_stats_reset(struct rte_cryptodev *dev);
static int virtio_crypto_qp_setup(struct rte_cryptodev *dev,
uint16_t queue_pair_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id,
- struct rte_mempool *session_pool);
+ int socket_id);
static int virtio_crypto_qp_release(struct rte_cryptodev *dev,
uint16_t queue_pair_id);
static void virtio_crypto_dev_free_mbufs(struct rte_cryptodev *dev);
@@ -585,8 +584,7 @@ virtio_crypto_dev_stats_reset(struct rte_cryptodev *dev)
static int
virtio_crypto_qp_setup(struct rte_cryptodev *dev, uint16_t queue_pair_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id,
- struct rte_mempool *session_pool __rte_unused)
+ int socket_id)
{
int ret;
struct virtqueue *vq;
diff --git a/drivers/crypto/zuc/rte_zuc_pmd.c b/drivers/crypto/zuc/rte_zuc_pmd.c
index 313f4590b..997c2092f 100644
--- a/drivers/crypto/zuc/rte_zuc_pmd.c
+++ b/drivers/crypto/zuc/rte_zuc_pmd.c
@@ -144,7 +144,8 @@ zuc_get_session(struct zuc_qp *qp, struct rte_crypto_op *op)
if (rte_mempool_get(qp->sess_mp, (void **)&_sess))
return NULL;
- if (rte_mempool_get(qp->sess_mp, (void **)&_sess_private_data))
+ if (rte_mempool_get(qp->sess_mp_priv,
+ (void **)&_sess_private_data))
return NULL;
sess = (struct zuc_session *)_sess_private_data;
@@ -152,7 +153,7 @@ zuc_get_session(struct zuc_qp *qp, struct rte_crypto_op *op)
if (unlikely(zuc_set_session_parameters(sess,
op->sym->xform) != 0)) {
rte_mempool_put(qp->sess_mp, _sess);
- rte_mempool_put(qp->sess_mp, _sess_private_data);
+ rte_mempool_put(qp->sess_mp_priv, _sess_private_data);
sess = NULL;
}
op->sym->session = (struct rte_cryptodev_sym_session *)_sess;
@@ -327,7 +328,7 @@ process_ops(struct rte_crypto_op **ops, enum zuc_operation op_type,
memset(sessions[i], 0, sizeof(struct zuc_session));
memset(ops[i]->sym->session, 0,
rte_cryptodev_sym_get_header_session_size());
- rte_mempool_put(qp->sess_mp, sessions[i]);
+ rte_mempool_put(qp->sess_mp_priv, sessions[i]);
rte_mempool_put(qp->sess_mp, ops[i]->sym->session);
ops[i]->sym->session = NULL;
}
diff --git a/drivers/crypto/zuc/rte_zuc_pmd_ops.c b/drivers/crypto/zuc/rte_zuc_pmd_ops.c
index 6da396542..7bd985fc1 100644
--- a/drivers/crypto/zuc/rte_zuc_pmd_ops.c
+++ b/drivers/crypto/zuc/rte_zuc_pmd_ops.c
@@ -193,7 +193,7 @@ zuc_pmd_qp_create_processed_ops_ring(struct zuc_qp *qp,
static int
zuc_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool)
+ int socket_id)
{
struct zuc_qp *qp = NULL;
@@ -218,7 +218,8 @@ zuc_pmd_qp_setup(struct rte_cryptodev *dev, uint16_t qp_id,
if (qp->processed_ops == NULL)
goto qp_setup_cleanup;
- qp->sess_mp = session_pool;
+ qp->sess_mp = qp_conf->mp_session;
+ qp->sess_mp_priv = qp_conf->mp_session_private;
memset(&qp->qp_stats, 0, sizeof(qp->qp_stats));
diff --git a/drivers/crypto/zuc/rte_zuc_pmd_private.h b/drivers/crypto/zuc/rte_zuc_pmd_private.h
index 5e5906ddb..aa73c0016 100644
--- a/drivers/crypto/zuc/rte_zuc_pmd_private.h
+++ b/drivers/crypto/zuc/rte_zuc_pmd_private.h
@@ -36,6 +36,8 @@ struct zuc_qp {
/**< Ring for placing processed ops */
struct rte_mempool *sess_mp;
/**< Session Mempool */
+ struct rte_mempool *sess_mp_priv;
+ /**< Session Private Data Mempool */
struct rte_cryptodev_stats qp_stats;
/**< Queue pair statistics */
uint8_t temp_digest[ZUC_DIGEST_LENGTH];
diff --git a/drivers/net/softnic/rte_eth_softnic_cryptodev.c b/drivers/net/softnic/rte_eth_softnic_cryptodev.c
index 1480f6dd5..f031d8803 100644
--- a/drivers/net/softnic/rte_eth_softnic_cryptodev.c
+++ b/drivers/net/softnic/rte_eth_softnic_cryptodev.c
@@ -101,7 +101,7 @@ softnic_cryptodev_create(struct pmd_internals *p,
queue_conf.nb_descriptors = params->queue_size;
for (i = 0; i < params->n_queues; i++) {
status = rte_cryptodev_queue_pair_setup(dev_id, i,
- &queue_conf, socket_id, NULL);
+ &queue_conf, socket_id);
if (status < 0)
return NULL;
}
diff --git a/examples/fips_validation/main.c b/examples/fips_validation/main.c
index e7559c633..384b7a240 100644
--- a/examples/fips_validation/main.c
+++ b/examples/fips_validation/main.c
@@ -39,7 +39,7 @@ static int
cryptodev_fips_validate_app_int(void)
{
struct rte_cryptodev_config conf = {rte_socket_id(), 1};
- struct rte_cryptodev_qp_conf qp_conf = {128};
+ struct rte_cryptodev_qp_conf qp_conf = {128, NULL, NULL};
int ret;
ret = rte_cryptodev_configure(env.dev_id, &conf);
@@ -52,7 +52,7 @@ cryptodev_fips_validate_app_int(void)
return ret;
ret = rte_cryptodev_queue_pair_setup(env.dev_id, 0, &qp_conf,
- rte_socket_id(), env.mpool);
+ rte_socket_id());
if (ret < 0)
return ret;
diff --git a/examples/ip_pipeline/cryptodev.c b/examples/ip_pipeline/cryptodev.c
index c4ba72bec..b365810de 100644
--- a/examples/ip_pipeline/cryptodev.c
+++ b/examples/ip_pipeline/cryptodev.c
@@ -93,7 +93,7 @@ cryptodev_create(const char *name, struct cryptodev_params *params)
queue_conf.nb_descriptors = params->queue_size;
for (i = 0; i < params->n_queues; i++) {
status = rte_cryptodev_queue_pair_setup(dev_id, i,
- &queue_conf, socket_id, NULL);
+ &queue_conf, socket_id);
if (status < 0)
return NULL;
}
diff --git a/examples/ipsec-secgw/ipsec-secgw.c b/examples/ipsec-secgw/ipsec-secgw.c
index 1bc0b5b50..a0ff8f7f7 100644
--- a/examples/ipsec-secgw/ipsec-secgw.c
+++ b/examples/ipsec-secgw/ipsec-secgw.c
@@ -1493,10 +1493,13 @@ cryptodevs_init(void)
cdev_id);
qp_conf.nb_descriptors = CDEV_QUEUE_DESC;
+ qp_conf.mp_session =
+ socket_ctx[dev_conf.socket_id].session_pool;
+ qp_conf.mp_session_private =
+ socket_ctx[dev_conf.socket_id].session_pool;
for (qp = 0; qp < dev_conf.nb_queue_pairs; qp++)
if (rte_cryptodev_queue_pair_setup(cdev_id, qp,
- &qp_conf, dev_conf.socket_id,
- socket_ctx[dev_conf.socket_id].session_pool))
+ &qp_conf, dev_conf.socket_id))
rte_panic("Failed to setup queue %u for "
"cdev_id %u\n", 0, cdev_id);
diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index f12fd266e..1df7ba743 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -2443,9 +2443,11 @@ initialize_cryptodevs(struct l2fwd_crypto_options *options, unsigned nb_ports,
}
qp_conf.nb_descriptors = 2048;
+ qp_conf.mp_session = session_pool_socket[socket_id];
+ qp_conf.mp_session_private = session_pool_socket[socket_id];
retval = rte_cryptodev_queue_pair_setup(cdev_id, 0, &qp_conf,
- socket_id, session_pool_socket[socket_id]);
+ socket_id);
if (retval < 0) {
printf("Failed to setup queue pair %u on cryptodev %u",
0, cdev_id);
diff --git a/examples/vhost_crypto/main.c b/examples/vhost_crypto/main.c
index 3deb5263f..cb30f84c0 100644
--- a/examples/vhost_crypto/main.c
+++ b/examples/vhost_crypto/main.c
@@ -463,7 +463,7 @@ free_resource(void)
int
main(int argc, char *argv[])
{
- struct rte_cryptodev_qp_conf qp_conf = {NB_CRYPTO_DESCRIPTORS};
+ struct rte_cryptodev_qp_conf qp_conf;
struct rte_cryptodev_config config;
struct rte_cryptodev_info dev_info;
char name[128];
@@ -551,11 +551,14 @@ main(int argc, char *argv[])
options.infos[i] = info;
+ qp_conf.nb_descriptors = NB_CRYPTO_DESCRIPTORS;
+ qp_conf.mp_session = info->sess_pool;
+ qp_conf.mp_session_private = info->sess_pool;
+
for (j = 0; j < dev_info.max_nb_queue_pairs; j++) {
ret = rte_cryptodev_queue_pair_setup(info->cid, j,
&qp_conf, rte_lcore_to_socket_id(
- lo->lcore_id),
- info->sess_pool);
+ lo->lcore_id));
if (ret < 0) {
RTE_LOG(ERR, USER1, "Failed to configure qp\n");
goto error_exit;
diff --git a/lib/librte_cryptodev/rte_cryptodev.c b/lib/librte_cryptodev/rte_cryptodev.c
index a52eaaa45..11776b6ac 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -941,8 +941,7 @@ rte_cryptodev_close(uint8_t dev_id)
int
rte_cryptodev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
- const struct rte_cryptodev_qp_conf *qp_conf, int socket_id,
- struct rte_mempool *session_pool)
+ const struct rte_cryptodev_qp_conf *qp_conf, int socket_id)
{
struct rte_cryptodev *dev;
@@ -967,7 +966,7 @@ rte_cryptodev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->queue_pair_setup, -ENOTSUP);
return (*dev->dev_ops->queue_pair_setup)(dev, queue_pair_id, qp_conf,
- socket_id, session_pool);
+ socket_id);
}
diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
index 4099823f1..f9e7507da 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -495,6 +495,10 @@ enum rte_cryptodev_event_type {
/** Crypto device queue pair configuration structure. */
struct rte_cryptodev_qp_conf {
uint32_t nb_descriptors; /**< Number of descriptors per queue pair */
+ struct rte_mempool *mp_session;
+ /**< The mempool for creating session in sessionless mode */
+ struct rte_mempool *mp_session_private;
+ /**< The mempool for creating sess private data in sessionless mode */
};
/**
@@ -689,8 +693,7 @@ rte_cryptodev_close(uint8_t dev_id);
*/
extern int
rte_cryptodev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id,
- const struct rte_cryptodev_qp_conf *qp_conf, int socket_id,
- struct rte_mempool *session_pool);
+ const struct rte_cryptodev_qp_conf *qp_conf, int socket_id);
/**
* Get the number of queue pairs on a specific crypto device
diff --git a/lib/librte_cryptodev/rte_cryptodev_pmd.h b/lib/librte_cryptodev/rte_cryptodev_pmd.h
index 1b6cafd17..f15c9af30 100644
--- a/lib/librte_cryptodev/rte_cryptodev_pmd.h
+++ b/lib/librte_cryptodev/rte_cryptodev_pmd.h
@@ -188,13 +188,12 @@ typedef void (*cryptodev_info_get_t)(struct rte_cryptodev *dev,
* @param qp_id Queue Pair Index
* @param qp_conf Queue configuration structure
* @param socket_id Socket Index
- * @param session_pool Pointer to device session mempool
*
* @return Returns 0 on success.
*/
typedef int (*cryptodev_queue_pair_setup_t)(struct rte_cryptodev *dev,
uint16_t qp_id, const struct rte_cryptodev_qp_conf *qp_conf,
- int socket_id, struct rte_mempool *session_pool);
+ int socket_id);
/**
* Release memory resources allocated by given queue pair.
diff --git a/test/test/test_cryptodev.c b/test/test/test_cryptodev.c
index 84065eb49..aac0b1f0b 100644
--- a/test/test/test_cryptodev.c
+++ b/test/test/test_cryptodev.c
@@ -461,12 +461,13 @@ testsuite_setup(void)
dev_id, ts_params->conf.nb_queue_pairs);
ts_params->qp_conf.nb_descriptors = DEFAULT_NUM_OPS_INFLIGHT;
+ ts_params->qp_conf.mp_session = ts_params->session_mpool;
+ ts_params->qp_conf.mp_session_private = ts_params->session_mpool;
for (qp_id = 0; qp_id < info.max_nb_queue_pairs; qp_id++) {
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
dev_id, qp_id, &ts_params->qp_conf,
- rte_cryptodev_socket_id(dev_id),
- ts_params->session_mpool),
+ rte_cryptodev_socket_id(dev_id)),
"Failed to setup queue pair %u on cryptodev %u",
qp_id, dev_id);
}
@@ -519,8 +520,7 @@ ut_setup(void)
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0], qp_id,
&ts_params->qp_conf,
- rte_cryptodev_socket_id(ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ rte_cryptodev_socket_id(ts_params->valid_devs[0])),
"Failed to setup queue pair %u on cryptodev %u",
qp_id, ts_params->valid_devs[0]);
}
@@ -709,13 +709,14 @@ test_queue_pair_descriptor_setup(void)
* freed so are re-used if ring is released and re-created.
*/
qp_conf.nb_descriptors = MIN_NUM_OPS_INFLIGHT; /* min size*/
+ qp_conf.mp_session = ts_params->session_mpool;
+ qp_conf.mp_session_private = ts_params->session_mpool;
for (qp_id = 0; qp_id < ts_params->conf.nb_queue_pairs; qp_id++) {
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0], qp_id, &qp_conf,
rte_cryptodev_socket_id(
- ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ ts_params->valid_devs[0])),
"Failed test for "
"rte_cryptodev_queue_pair_setup: num_inflights "
"%u on qp %u on cryptodev %u",
@@ -729,8 +730,7 @@ test_queue_pair_descriptor_setup(void)
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0], qp_id, &qp_conf,
rte_cryptodev_socket_id(
- ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ ts_params->valid_devs[0])),
"Failed test for"
" rte_cryptodev_queue_pair_setup: num_inflights"
" %u on qp %u on cryptodev %u",
@@ -744,8 +744,7 @@ test_queue_pair_descriptor_setup(void)
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0], qp_id, &qp_conf,
rte_cryptodev_socket_id(
- ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ ts_params->valid_devs[0])),
"Failed test for "
"rte_cryptodev_queue_pair_setup: num_inflights"
" %u on qp %u on cryptodev %u",
@@ -760,8 +759,7 @@ test_queue_pair_descriptor_setup(void)
TEST_ASSERT_FAIL(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0], qp_id, &qp_conf,
rte_cryptodev_socket_id(
- ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ ts_params->valid_devs[0])),
"Unexpectedly passed test for "
"rte_cryptodev_queue_pair_setup:"
"num_inflights %u on qp %u on cryptodev %u",
@@ -776,8 +774,7 @@ test_queue_pair_descriptor_setup(void)
TEST_ASSERT_FAIL(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0], qp_id, &qp_conf,
rte_cryptodev_socket_id(
- ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ ts_params->valid_devs[0])),
"Unexpectedly passed test for "
"rte_cryptodev_queue_pair_setup:"
"num_inflights %u on qp %u on cryptodev %u",
@@ -791,8 +788,7 @@ test_queue_pair_descriptor_setup(void)
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0], qp_id, &qp_conf,
rte_cryptodev_socket_id(
- ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ ts_params->valid_devs[0])),
"Failed test for"
" rte_cryptodev_queue_pair_setup:"
"num_inflights %u on qp %u on cryptodev %u",
@@ -807,8 +803,7 @@ test_queue_pair_descriptor_setup(void)
TEST_ASSERT_FAIL(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0], qp_id, &qp_conf,
rte_cryptodev_socket_id(
- ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ ts_params->valid_devs[0])),
"Unexpectedly passed test for "
"rte_cryptodev_queue_pair_setup:"
"num_inflights %u on qp %u on cryptodev %u",
@@ -824,8 +819,7 @@ test_queue_pair_descriptor_setup(void)
TEST_ASSERT_FAIL(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0],
qp_id, &qp_conf,
- rte_cryptodev_socket_id(ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ rte_cryptodev_socket_id(ts_params->valid_devs[0])),
"Failed test for rte_cryptodev_queue_pair_setup:"
"invalid qp %u on cryptodev %u",
qp_id, ts_params->valid_devs[0]);
@@ -835,8 +829,7 @@ test_queue_pair_descriptor_setup(void)
TEST_ASSERT_FAIL(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0],
qp_id, &qp_conf,
- rte_cryptodev_socket_id(ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ rte_cryptodev_socket_id(ts_params->valid_devs[0])),
"Failed test for rte_cryptodev_queue_pair_setup:"
"invalid qp %u on cryptodev %u",
qp_id, ts_params->valid_devs[0]);
diff --git a/test/test/test_cryptodev_asym.c b/test/test/test_cryptodev_asym.c
index a899f9973..0f6fc5767 100644
--- a/test/test/test_cryptodev_asym.c
+++ b/test/test/test_cryptodev_asym.c
@@ -383,11 +383,12 @@ testsuite_setup(void)
/* configure qp */
ts_params->qp_conf.nb_descriptors = DEFAULT_NUM_OPS_INFLIGHT;
+ ts_params->qp_conf.mp_session = ts_params->session_mpool;
+ ts_params->qp_conf.mp_session_private = ts_params->session_mpool;
for (qp_id = 0; qp_id < info.max_nb_queue_pairs; qp_id++) {
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
dev_id, qp_id, &ts_params->qp_conf,
- rte_cryptodev_socket_id(dev_id),
- ts_params->session_mpool),
+ rte_cryptodev_socket_id(dev_id)),
"Failed to setup queue pair %u on cryptodev %u ASYM",
qp_id, dev_id);
}
@@ -449,8 +450,7 @@ ut_setup(void)
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
ts_params->valid_devs[0], qp_id,
&ts_params->qp_conf,
- rte_cryptodev_socket_id(ts_params->valid_devs[0]),
- ts_params->session_mpool),
+ rte_cryptodev_socket_id(ts_params->valid_devs[0])),
"Failed to setup queue pair %u on cryptodev %u",
qp_id, ts_params->valid_devs[0]);
}
diff --git a/test/test/test_event_crypto_adapter.c b/test/test/test_event_crypto_adapter.c
index de258c346..54717870e 100644
--- a/test/test/test_event_crypto_adapter.c
+++ b/test/test/test_event_crypto_adapter.c
@@ -546,11 +546,12 @@ configure_cryptodev(void)
TEST_CDEV_ID, conf.nb_queue_pairs);
qp_conf.nb_descriptors = DEFAULT_NUM_OPS_INFLIGHT;
+ qp_conf.mp_session = params.session_mpool;
+ qp_conf.mp_session_private = params.session_mpool;
TEST_ASSERT_SUCCESS(rte_cryptodev_queue_pair_setup(
TEST_CDEV_ID, TEST_CDEV_QP_ID, &qp_conf,
- rte_cryptodev_socket_id(TEST_CDEV_ID),
- params.session_mpool),
+ rte_cryptodev_socket_id(TEST_CDEV_ID)),
"Failed to setup queue pair %u on cryptodev %u\n",
TEST_CDEV_QP_ID, TEST_CDEV_ID);
--
2.13.6
^ permalink raw reply [relevance 1%]
* Re: [dpdk-dev] [PATCH 19.02 v2] malloc: fix deadlock when using malloc stats
2018-12-21 12:26 4% ` [dpdk-dev] [PATCH 19.02 v2] " Anatoly Burakov
@ 2018-12-21 13:35 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2018-12-21 13:35 UTC (permalink / raw)
To: Anatoly Burakov; +Cc: dev, John McNamara, Marko Kovacevic, stable
21/12/2018 13:26, Anatoly Burakov:
> Currently, malloc statistics and external heap creation code
> use memory hotplug lock as a way to synchronize accesses to
> heaps (as in, locking the hotplug lock to prevent list of heaps
> from changing under our feet). At the same time, malloc
> statistics code will also lock the heap because it needs to
> access heap data and does not want any other thread to allocate
> anything from that heap.
>
> In such scheme, it is possible to enter a deadlock with the
> following sequence of events:
>
> thread 1 thread 2
> rte_malloc()
> rte_malloc_dump_stats()
> take heap lock
> take hotplug lock
> failed to allocate,
> attempt to take
> hotplug lock
> attempt to take heap lock
>
> Neither thread will be able to continue, as both of them are
> waiting for the other one to drop the lock. Adding an
> additional lock will require an ABI change, so instead of
> that, make malloc statistics calls thread-unsafe with
> respect to creating/destroying heaps.
>
> Fixes: 72cf92b31855 ("malloc: index heaps using heap ID rather than NUMA node")
> Cc: stable@dpdk.org
>
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> ---
>
> Notes:
> This is the best we can do for 19.02 without breaking ABI.
Applied, thanks
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 00/10] ipsec: new library for IPsec data-path processing
@ 2018-12-21 13:32 0% ` Akhil Goyal
0 siblings, 0 replies; 200+ results
From: Akhil Goyal @ 2018-12-21 13:32 UTC (permalink / raw)
To: Konstantin Ananyev, dev; +Cc: Thomas Monjalon
Hi Konstantin,
I am done with the review, will be running the code in early next week
after I finish the review of changes in ipsec application.
key points for review were
- some code may be generic and can be moved in appropriate files
- documentation update
- spell checks spacing etc.
- some cases like cipher only need to be looked appropriately
- test cases for lookaside and inline proto
- checksum/ttl update
With these comments we cannot make this to RC1, but RC2 can be looked upon.
Thanks,
Akhil
On 12/14/2018 9:59 PM, Konstantin Ananyev wrote:
> This patch series depends on the patch:
> http://patches.dpdk.org/patch/48044/
> to be applied first.
>
> v3 -> v4
> - Changes to adress Declan comments
> - Update docs
>
> v2 -> v3
> - Several fixes for IPv6 support
> - Extra checks for input parameters in public APi functions
>
> v1 -> v2
> - Changes to get into account l2_len for outbound transport packets
> (Qi comments)
> - Several bug fixes
> - Some code restructured
> - Update MAINTAINERS file
>
> RFCv2 -> v1
> - Changes per Jerin comments
> - Implement transport mode
> - Several bug fixes
> - UT largely reworked and extended
>
> This patch introduces a new library within DPDK: librte_ipsec.
> The aim is to provide DPDK native high performance library for IPsec
> data-path processing.
> The library is supposed to utilize existing DPDK crypto-dev and
> security API to provide application with transparent IPsec
> processing API.
> The library is concentrated on data-path protocols processing
> (ESP and AH), IKE protocol(s) implementation is out of scope
> for that library.
> Current patch introduces SA-level API.
>
> SA (low) level API
> ==================
>
> API described below operates on SA level.
> It provides functionality that allows user for given SA to process
> inbound and outbound IPsec packets.
> To be more specific:
> - for inbound ESP/AH packets perform decryption, authentication,
> integrity checking, remove ESP/AH related headers
> - for outbound packets perform payload encryption, attach ICV,
> update/add IP headers, add ESP/AH headers/trailers,
> setup related mbuf felids (ol_flags, tx_offloads, etc.).
> - initialize/un-initialize given SA based on user provided parameters.
>
> The following functionality:
> - match inbound/outbound packets to particular SA
> - manage crypto/security devices
> - provide SAD/SPD related functionality
> - determine what crypto/security device has to be used
> for given packet(s)
> is out of scope for SA-level API.
>
> SA-level API is based on top of crypto-dev/security API and relies on
> them
> to perform actual cipher and integrity checking.
> To have an ability to easily map crypto/security sessions into related
> IPSec SA opaque userdata field was added into
> rte_cryptodev_sym_session and rte_security_session structures.
> That implies ABI change for both librte_crytpodev and librte_security.
>
> Due to the nature of crypto-dev API (enqueue/deque model) we use
> asynchronous API for IPsec packets destined to be processed
> by crypto-device.
> Expected API call sequence would be:
> /* enqueue for processing by crypto-device */
> rte_ipsec_pkt_crypto_prepare(...);
> rte_cryptodev_enqueue_burst(...);
> /* dequeue from crypto-device and do final processing (if any) */
> rte_cryptodev_dequeue_burst(...);
> rte_ipsec_pkt_crypto_group(...); /* optional */
> rte_ipsec_pkt_process(...);
>
> Though for packets destined for inline processing no extra overhead
> is required and synchronous API call: rte_ipsec_pkt_process()
> is sufficient for that case.
>
> Current implementation supports all four currently defined
> rte_security types.
> Though to accommodate future custom implementations function pointers
> model is used for both for *crypto_prepare* and *process*
> impelementations.
>
> Konstantin Ananyev (10):
> cryptodev: add opaque userdata pointer into crypto sym session
> security: add opaque userdata pointer into security session
> net: add ESP trailer structure definition
> lib: introduce ipsec library
> ipsec: add SA data-path API
> ipsec: implement SA data-path API
> ipsec: rework SA replay window/SQN for MT environment
> ipsec: helper functions to group completed crypto-ops
> test/ipsec: introduce functional test
> doc: add IPsec library guide
>
> MAINTAINERS | 5 +
> config/common_base | 5 +
> doc/guides/prog_guide/index.rst | 1 +
> doc/guides/prog_guide/ipsec_lib.rst | 74 +
> doc/guides/rel_notes/release_19_02.rst | 10 +
> lib/Makefile | 2 +
> lib/librte_cryptodev/rte_cryptodev.h | 2 +
> lib/librte_ipsec/Makefile | 27 +
> lib/librte_ipsec/crypto.h | 123 ++
> lib/librte_ipsec/iph.h | 84 +
> lib/librte_ipsec/ipsec_sqn.h | 343 ++++
> lib/librte_ipsec/meson.build | 10 +
> lib/librte_ipsec/pad.h | 45 +
> lib/librte_ipsec/rte_ipsec.h | 153 ++
> lib/librte_ipsec/rte_ipsec_group.h | 151 ++
> lib/librte_ipsec/rte_ipsec_sa.h | 172 ++
> lib/librte_ipsec/rte_ipsec_version.map | 15 +
> lib/librte_ipsec/sa.c | 1407 +++++++++++++++
> lib/librte_ipsec/sa.h | 98 ++
> lib/librte_ipsec/ses.c | 45 +
> lib/librte_net/rte_esp.h | 10 +-
> lib/librte_security/rte_security.h | 2 +
> lib/meson.build | 2 +
> mk/rte.app.mk | 2 +
> test/test/Makefile | 3 +
> test/test/meson.build | 3 +
> test/test/test_ipsec.c | 2209 ++++++++++++++++++++++++
> 27 files changed, 5002 insertions(+), 1 deletion(-)
> create mode 100644 doc/guides/prog_guide/ipsec_lib.rst
> create mode 100644 lib/librte_ipsec/Makefile
> create mode 100644 lib/librte_ipsec/crypto.h
> create mode 100644 lib/librte_ipsec/iph.h
> create mode 100644 lib/librte_ipsec/ipsec_sqn.h
> create mode 100644 lib/librte_ipsec/meson.build
> create mode 100644 lib/librte_ipsec/pad.h
> create mode 100644 lib/librte_ipsec/rte_ipsec.h
> create mode 100644 lib/librte_ipsec/rte_ipsec_group.h
> create mode 100644 lib/librte_ipsec/rte_ipsec_sa.h
> create mode 100644 lib/librte_ipsec/rte_ipsec_version.map
> create mode 100644 lib/librte_ipsec/sa.c
> create mode 100644 lib/librte_ipsec/sa.h
> create mode 100644 lib/librte_ipsec/ses.c
> create mode 100644 test/test/test_ipsec.c
>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH 19.02 v2] malloc: fix deadlock when using malloc stats
2018-12-21 12:09 0% ` Thomas Monjalon
@ 2018-12-21 12:26 4% ` Anatoly Burakov
2018-12-21 13:35 0% ` Thomas Monjalon
1 sibling, 1 reply; 200+ results
From: Anatoly Burakov @ 2018-12-21 12:26 UTC (permalink / raw)
To: dev; +Cc: John McNamara, Marko Kovacevic, thomas, stable
Currently, malloc statistics and external heap creation code
use memory hotplug lock as a way to synchronize accesses to
heaps (as in, locking the hotplug lock to prevent list of heaps
from changing under our feet). At the same time, malloc
statistics code will also lock the heap because it needs to
access heap data and does not want any other thread to allocate
anything from that heap.
In such scheme, it is possible to enter a deadlock with the
following sequence of events:
thread 1 thread 2
rte_malloc()
rte_malloc_dump_stats()
take heap lock
take hotplug lock
failed to allocate,
attempt to take
hotplug lock
attempt to take heap lock
Neither thread will be able to continue, as both of them are
waiting for the other one to drop the lock. Adding an
additional lock will require an ABI change, so instead of
that, make malloc statistics calls thread-unsafe with
respect to creating/destroying heaps.
Fixes: 72cf92b31855 ("malloc: index heaps using heap ID rather than NUMA node")
Cc: stable@dpdk.org
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
---
Notes:
This is the best we can do for 19.02 without breaking ABI.
doc/guides/rel_notes/release_19_02.rst | 4 ++++
lib/librte_eal/common/include/rte_malloc.h | 9 +++++++++
lib/librte_eal/common/rte_malloc.c | 19 +++----------------
3 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_02.rst b/doc/guides/rel_notes/release_19_02.rst
index 47768288a..0b248d55d 100644
--- a/doc/guides/rel_notes/release_19_02.rst
+++ b/doc/guides/rel_notes/release_19_02.rst
@@ -126,6 +126,10 @@ API Changes
- In cases where memfd support would have been required to provide segment
fd's (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
+ ``rte_malloc_heap_create()`` or ``rte_malloc_heap_destroy()`` function calls.
+
* pdump: The ``rte_pdump_set_socket_dir()``, the parameter ``path`` of
``rte_pdump_init()`` and enum ``rte_pdump_socktype`` were deprecated
since 18.05 and are removed in this release.
diff --git a/lib/librte_eal/common/include/rte_malloc.h b/lib/librte_eal/common/include/rte_malloc.h
index a5290b074..54a12467a 100644
--- a/lib/librte_eal/common/include/rte_malloc.h
+++ b/lib/librte_eal/common/include/rte_malloc.h
@@ -251,6 +251,9 @@ rte_malloc_validate(const void *ptr, size_t *size);
/**
* Get heap statistics for the specified heap.
*
+ * @note This function is not thread-safe with respect to
+ * ``rte_malloc_heap_create()``/``rte_malloc_heap_destroy()`` functions.
+ *
* @param socket
* An unsigned integer specifying the socket to get heap statistics for
* @param socket_stats
@@ -461,6 +464,9 @@ rte_malloc_heap_socket_is_external(int socket_id);
* Dump for the specified type to a file. If the type argument is
* NULL, all memory types will be dumped.
*
+ * @note This function is not thread-safe with respect to
+ * ``rte_malloc_heap_create()``/``rte_malloc_heap_destroy()`` functions.
+ *
* @param f
* A pointer to a file for output
* @param type
@@ -473,6 +479,9 @@ rte_malloc_dump_stats(FILE *f, const char *type);
/**
* Dump contents of all malloc heaps to a file.
*
+ * @note This function is not thread-safe with respect to
+ * ``rte_malloc_heap_create()``/``rte_malloc_heap_destroy()`` functions.
+ *
* @param f
* A pointer to a file for output
*/
diff --git a/lib/librte_eal/common/rte_malloc.c b/lib/librte_eal/common/rte_malloc.c
index 09051c236..b39de3c99 100644
--- a/lib/librte_eal/common/rte_malloc.c
+++ b/lib/librte_eal/common/rte_malloc.c
@@ -156,20 +156,14 @@ rte_malloc_get_socket_stats(int socket,
struct rte_malloc_socket_stats *socket_stats)
{
struct rte_mem_config *mcfg = rte_eal_get_configuration()->mem_config;
- int heap_idx, ret = -1;
-
- rte_rwlock_read_lock(&mcfg->memory_hotplug_lock);
+ int heap_idx;
heap_idx = malloc_socket_to_heap_id(socket);
if (heap_idx < 0)
- goto unlock;
+ return -1;
- ret = malloc_heap_get_stats(&mcfg->malloc_heaps[heap_idx],
+ return malloc_heap_get_stats(&mcfg->malloc_heaps[heap_idx],
socket_stats);
-unlock:
- rte_rwlock_read_unlock(&mcfg->memory_hotplug_lock);
-
- return ret;
}
/*
@@ -181,14 +175,10 @@ rte_malloc_dump_heaps(FILE *f)
struct rte_mem_config *mcfg = rte_eal_get_configuration()->mem_config;
unsigned int idx;
- rte_rwlock_read_lock(&mcfg->memory_hotplug_lock);
-
for (idx = 0; idx < RTE_MAX_HEAPS; idx++) {
fprintf(f, "Heap id: %u\n", idx);
malloc_heap_dump(&mcfg->malloc_heaps[idx], f);
}
-
- rte_rwlock_read_unlock(&mcfg->memory_hotplug_lock);
}
int
@@ -262,8 +252,6 @@ rte_malloc_dump_stats(FILE *f, __rte_unused const char *type)
unsigned int heap_id;
struct rte_malloc_socket_stats sock_stats;
- rte_rwlock_read_lock(&mcfg->memory_hotplug_lock);
-
/* Iterate through all initialised heaps */
for (heap_id = 0; heap_id < RTE_MAX_HEAPS; heap_id++) {
struct malloc_heap *heap = &mcfg->malloc_heaps[heap_id];
@@ -280,7 +268,6 @@ rte_malloc_dump_stats(FILE *f, __rte_unused const char *type)
fprintf(f, "\tAlloc_count:%u,\n",sock_stats.alloc_count);
fprintf(f, "\tFree_count:%u,\n", sock_stats.free_count);
}
- rte_rwlock_read_unlock(&mcfg->memory_hotplug_lock);
return;
}
--
2.17.1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 18.11] malloc: fix deadlock when using malloc stats
2018-12-21 12:09 0% ` Thomas Monjalon
@ 2018-12-21 12:12 0% ` Burakov, Anatoly
0 siblings, 0 replies; 200+ results
From: Burakov, Anatoly @ 2018-12-21 12:12 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev, stable, ferruh.yigit, bruce.richardson, arybchenko, olivier.matz
On 21-Dec-18 12:09 PM, Thomas Monjalon wrote:
> 04/12/2018 13:22, Anatoly Burakov:
>> Currently, malloc statistics and external heap creation code
>> use memory hotplug lock as a way to synchronize accesses to
>> heaps (as in, locking the hotplug lock to prevent list of heaps
>> from changing under our feet). At the same time, malloc
>> statistics code will also lock the heap because it needs to
>> access heap data and does not want any other thread to allocate
>> anything from that heap.
>>
>> In such scheme, it is possible to enter a deadlock with the
>> following sequence of events:
>>
>> thread 1 thread 2
>> rte_malloc()
>> rte_malloc_dump_stats()
>> take heap lock
>> take hotplug lock
>> failed to allocate,
>> attempt to take
>> hotplug lock
>> attempt to take heap lock
>>
>> Neither thread will be able to continue, as both of them are
>> waiting for the other one to drop the lock. Adding an
>> additional lock will require an ABI change, so instead of
>> that, make malloc statistics calls thread-unsafe with
>> respect to creating/destroying heaps.
>>
>> Fixes: 72cf92b31855 ("malloc: index heaps using heap ID rather than NUMA node")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
>> ---
>>
>> Notes:
>> IMO this is the best we can do for 18.11 without breaking ABI.
>> For 19.02, we can introduce a new global heap lock (something
>> i should've done in the first place...), so this patch is
>> not applicable to 19.02. For 19.02, we can fix this properly
>> by introducing another lock and breaking the EAL ABI.
>>
>> Not sure where to put docs update, feedback welcome.
>
> This patch is also changing the API, because functions become not thread-safe.
> I think you should note it in the release notes.
> About 19.02, do we want to take this patch (with release notes updated)?
>
Yes and yes.
Technically, they still are thread-safe when it comes to individual heap
access - they just aren't thread-safe with regards to
creating/destroying heaps (so, we may enter the dump function, and a
heap may be added/removed while we're iterating over the list of heaps).
I'll send a v2 with release notes update.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 18.11] malloc: fix deadlock when using malloc stats
@ 2018-12-21 12:09 0% ` Thomas Monjalon
2018-12-21 12:12 0% ` Burakov, Anatoly
2018-12-21 12:26 4% ` [dpdk-dev] [PATCH 19.02 v2] " Anatoly Burakov
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2018-12-21 12:09 UTC (permalink / raw)
To: Anatoly Burakov
Cc: dev, stable, ferruh.yigit, bruce.richardson, arybchenko, olivier.matz
04/12/2018 13:22, Anatoly Burakov:
> Currently, malloc statistics and external heap creation code
> use memory hotplug lock as a way to synchronize accesses to
> heaps (as in, locking the hotplug lock to prevent list of heaps
> from changing under our feet). At the same time, malloc
> statistics code will also lock the heap because it needs to
> access heap data and does not want any other thread to allocate
> anything from that heap.
>
> In such scheme, it is possible to enter a deadlock with the
> following sequence of events:
>
> thread 1 thread 2
> rte_malloc()
> rte_malloc_dump_stats()
> take heap lock
> take hotplug lock
> failed to allocate,
> attempt to take
> hotplug lock
> attempt to take heap lock
>
> Neither thread will be able to continue, as both of them are
> waiting for the other one to drop the lock. Adding an
> additional lock will require an ABI change, so instead of
> that, make malloc statistics calls thread-unsafe with
> respect to creating/destroying heaps.
>
> Fixes: 72cf92b31855 ("malloc: index heaps using heap ID rather than NUMA node")
> Cc: stable@dpdk.org
>
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> ---
>
> Notes:
> IMO this is the best we can do for 18.11 without breaking ABI.
> For 19.02, we can introduce a new global heap lock (something
> i should've done in the first place...), so this patch is
> not applicable to 19.02. For 19.02, we can fix this properly
> by introducing another lock and breaking the EAL ABI.
>
> Not sure where to put docs update, feedback welcome.
This patch is also changing the API, because functions become not thread-safe.
I think you should note it in the release notes.
About 19.02, do we want to take this patch (with release notes updated)?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4] libs/power: add p-state driver compatibility
2018-12-20 14:43 1% ` [dpdk-dev] [PATCH v4] " Liang Ma
@ 2018-12-21 0:34 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2018-12-21 0:34 UTC (permalink / raw)
To: Liang Ma; +Cc: dev, david.hunt, anatoly.burakov
20/12/2018 15:43, Liang Ma:
> Previously, in order to use the power library, it was necessary
> for the user to disable the intel_pstate driver by adding
> “intel_pstate=disable” to the kernel command line for the system,
> which causes the acpi_cpufreq driver to be loaded in its place.
>
> This patch adds the ability for the power library use the intel-pstate
> driver.
>
> It adds a new suite of functions behind the current power library API,
> and will seamlessly set up the user facing API function pointers to
> the relevant functions depending on whether the system is running with
> acpi_cpufreq kernel driver, intel_pstate kernel driver or in a guest,
> using kvm. The library API and ABI is unchanged.
>
> Signed-off-by: Liang Ma <liang.j.ma@intel.com>
> Reviewed-by: Anatoly Burakov <anatoly.burakov@intel.com>
> Acked-by: David Hunt <david.hunt@intel.com>
Applied, thanks
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3] libs/power: add p-state driver compatibility
2018-12-21 0:30 0% ` Thomas Monjalon
@ 2018-12-21 0:33 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2018-12-21 0:33 UTC (permalink / raw)
To: Hunt, David, Liang Ma; +Cc: dev, anatoly.burakov
21/12/2018 01:30, Thomas Monjalon:
> 20/12/2018 15:52, Hunt, David:
> > On 19/12/2018 8:31 PM, Thomas Monjalon wrote:
> > > 19/12/2018 10:09, Hunt, David:
> > >> On 19/12/2018 3:18 AM, Thomas Monjalon wrote:
> > >>> 14/12/2018 14:11, Liang Ma:
> > >>>> Previously, in order to use the power library, it was necessary
> > >>>> for the user to disable the intel_pstate driver by adding
> > >>>> “intel_pstate=disable” to the kernel command line for the system,
> > >>>> which causes the acpi_cpufreq driver to be loaded in its place.
> > >>>>
> > >>>> This patch adds the ability for the power library use the intel-pstate
> > >>>> driver.
> > >>>>
> > >>>> It adds a new suite of functions behind the current power library API,
> > >>>> and will seamlessly set up the user facing API function pointers to
> > >>>> the relevant functions depending on whether the system is running with
> > >>>> acpi_cpufreq kernel driver, intel_pstate kernel driver or in a guest,
> > >>>> using kvm. The library API and ABI is unchanged.
> > >>>>
> > >>>> Signed-off-by: Liang Ma <liang.j.ma@intel.com>
> > >>>>
> > >>>> Reviewed-by: Anatoly Burakov <anatoly.burakov@intel.com>
> > >>>> ---
> > >>> Please write a changelog when sending a new version.
> > >>>
> > >>> Dave, any comment on this patch?
> > >>
> > >> Looks good to me.
> > >>
> > >> Acked-by: David Hunt <david.hunt@intel.com>
> > >>
> > >>
> > >>>> --- /dev/null
> > >>>> +++ b/lib/librte_power/power_pstate_cpufreq.c
> > >>>> @@ -0,0 +1,770 @@
> > >>>> +/* SPDX-License-Identifier: BSD-3-Clause
> > >>>> + * Copyright(c) 2018-2018 Intel Corporation
> > >>> Something wrong here :)
> > >> Yes, should simply be "Copyright(c) 2018 Intel Corporation"
> > >
> > > There is also a compilation error with meson:
> > >
> > > lib/librte_power/rte_power_empty_poll.h:20:10: fatal error:
> > > rte_timer.h: No such file or directory
> > >
> > > Clearly, some quality checks are missing.
> > >
> > > I'm afraid we won't have any patch for power library in 19.02.
> >
> >
> > Hi Thomas,
> >
> > We have just pushed a v4, and tested with make, meson/ninja, and several
> > different build environments. I believe this version should be
> > acceptable for 19.02.
>
> I don't think so.
> I will give more comments in v4 and will give up for 19.02.
Sorry I looked at the wrong things.
The v4 looks OK.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3] libs/power: add p-state driver compatibility
2018-12-20 14:52 0% ` Hunt, David
@ 2018-12-21 0:30 0% ` Thomas Monjalon
2018-12-21 0:33 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2018-12-21 0:30 UTC (permalink / raw)
To: Hunt, David, Liang Ma; +Cc: dev, anatoly.burakov
20/12/2018 15:52, Hunt, David:
> On 19/12/2018 8:31 PM, Thomas Monjalon wrote:
> > 19/12/2018 10:09, Hunt, David:
> >> On 19/12/2018 3:18 AM, Thomas Monjalon wrote:
> >>> 14/12/2018 14:11, Liang Ma:
> >>>> Previously, in order to use the power library, it was necessary
> >>>> for the user to disable the intel_pstate driver by adding
> >>>> “intel_pstate=disable” to the kernel command line for the system,
> >>>> which causes the acpi_cpufreq driver to be loaded in its place.
> >>>>
> >>>> This patch adds the ability for the power library use the intel-pstate
> >>>> driver.
> >>>>
> >>>> It adds a new suite of functions behind the current power library API,
> >>>> and will seamlessly set up the user facing API function pointers to
> >>>> the relevant functions depending on whether the system is running with
> >>>> acpi_cpufreq kernel driver, intel_pstate kernel driver or in a guest,
> >>>> using kvm. The library API and ABI is unchanged.
> >>>>
> >>>> Signed-off-by: Liang Ma <liang.j.ma@intel.com>
> >>>>
> >>>> Reviewed-by: Anatoly Burakov <anatoly.burakov@intel.com>
> >>>> ---
> >>> Please write a changelog when sending a new version.
> >>>
> >>> Dave, any comment on this patch?
> >>
> >> Looks good to me.
> >>
> >> Acked-by: David Hunt <david.hunt@intel.com>
> >>
> >>
> >>>> --- /dev/null
> >>>> +++ b/lib/librte_power/power_pstate_cpufreq.c
> >>>> @@ -0,0 +1,770 @@
> >>>> +/* SPDX-License-Identifier: BSD-3-Clause
> >>>> + * Copyright(c) 2018-2018 Intel Corporation
> >>> Something wrong here :)
> >> Yes, should simply be "Copyright(c) 2018 Intel Corporation"
> >
> > There is also a compilation error with meson:
> >
> > lib/librte_power/rte_power_empty_poll.h:20:10: fatal error:
> > rte_timer.h: No such file or directory
> >
> > Clearly, some quality checks are missing.
> >
> > I'm afraid we won't have any patch for power library in 19.02.
>
>
> Hi Thomas,
>
> We have just pushed a v4, and tested with make, meson/ninja, and several
> different build environments. I believe this version should be
> acceptable for 19.02.
I don't think so.
I will give more comments in v4 and will give up for 19.02.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC 00/14] prefix network structures
2018-12-20 21:59 3% ` Ferruh Yigit
@ 2018-12-20 23:48 0% ` Stephen Hemminger
2018-12-21 14:38 0% ` Wiles, Keith
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2018-12-20 23:48 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: Olivier MATZ, dpdk-dev, Keith Wiles, Bruce Richardson
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 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.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC 00/14] prefix network structures
@ 2018-12-20 21:59 3% ` Ferruh Yigit
2018-12-20 23:48 0% ` Stephen Hemminger
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2018-12-20 21:59 UTC (permalink / raw)
To: Olivier MATZ, dpdk-dev; +Cc: Stephen Hemminger, Keith Wiles, Bruce Richardson
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
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2 0/4] hash: deprecate lock ellision and read/write concurreny flags
@ 2018-12-20 20:10 0% ` Yigit, Ferruh
0 siblings, 0 replies; 200+ results
From: Yigit, Ferruh @ 2018-12-20 20:10 UTC (permalink / raw)
To: Honnappa Nagarahalli, Bruce Richardson
Cc: pablo.de.lara.guarch, dev, Gavin Hu (Arm Technology China),
Dharmik Thakkar, nd, yipeng1.wang, sameh.gobriel
On 11/2/2018 5:38 PM, Honnappa Nagarahalli wrote:
>>
>> On Thu, Nov 01, 2018 at 06:25:18PM -0500, Honnappa Nagarahalli wrote:
>>> Various configuration flags in rte_hash library result in increase of
>>> number of test cases. Configuration flags for enabling transactional
>>> memory use and read/write concurrency are not required. These features
>>> should be supported by default. Please refer to [1] for more context.
>>>
>>> This patch marks these flags for deprecation in 19.02 release and
>>> cleans up the test cases.
>>>
>>> [1] http://mails.dpdk.org/archives/dev/2018-October/117268.html
>>>
>>> Honnappa Nagarahalli (4): hash: prepare for deprecation of flags hash:
>>> deprecate lock ellision and read/write concurreny flags test/hash:
>>> stop using lock ellision and read/write concurreny flags doc/hash:
>>> deprecate lock ellision and read/write concurreny flags
>>>
>> While I'd like to reduce the flags and do cleanup, I'm a little concerned about
>> putting this scope of changes in so late in the release. I wonder if less drastic
>> changes could work as well for this release, and do the cleanup later.
> Thank you Bruce for the review. This patch series is not fixing any user related problems, let us skip this for 18.11. It will give us time as well to think through and get this right.
There was no update in the scope of 19.02, I guess it will skip for 19.02 too.
Patchset updated as "Change requested" in patchwork.
>
>> For example, rather than deprecating the flags now, how about just change
>> the default for when no flags are set? If user has set flags, follow the existing
>> path - if flags is set to zero, then have the defaults be to use RW concurrency
>> or TSX.
> This changes the behavior of the library and what the flags mean, still requires ABI change, but does not need deprecation of flags (I guess this is what you meant). However, it will not solve the problem of losing the capability to disable TSX.
>
>>
>> /Bruce
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format for sched field
2018-12-20 12:16 1% ` [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format for sched field Reshma Pattan
@ 2018-12-20 14:55 0% ` Rao, Nikhil
2019-01-15 22:37 3% ` Stephen Hemminger
2019-01-15 23:11 4% ` Stephen Hemminger
2 siblings, 0 replies; 200+ results
From: Rao, Nikhil @ 2018-12-20 14:55 UTC (permalink / raw)
To: Pattan, Reshma, dev, jerin.jacob, olivier.matz, thomas, Singh,
Jasvinder, Dumitrescu, Cristian, Ananyev, Konstantin
> -----Original Message-----
> From: Pattan, Reshma
> Sent: Thursday, December 20, 2018 5:46 PM
> To: dev@dpdk.org; jerin.jacob@caviumnetworks.com; Rao, Nikhil
> <nikhil.rao@intel.com>; olivier.matz@6wind.com; thomas@monjalon.net;
> Singh, Jasvinder <jasvinder.singh@intel.com>; Dumitrescu, Cristian
> <cristian.dumitrescu@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>
> Cc: Pattan, Reshma <reshma.pattan@intel.com>
> Subject: [PATCH v7 2/2] mbuf: implement generic format for sched field
>
> This patch implements the changes proposed in the deprecation notes [1][2].
>
> librte_mbuf changes:
> The mbuf->hash.sched field is updated to support generic definition in line
> with the ethdev traffic manager and meter APIs.
> The new generic format contains: queue ID, traffic class, color.
>
> Added public APIs to set and get these new fields to and from mbuf.
>
> librte_sched changes:
> In addtion, following API functions of the sched library have been modified
> with an additional parameter of type struct rte_sched_port to accommodate
> the changes made to mbuf sched field.
> (i)rte_sched_port_pkt_write()
> (ii) rte_sched_port_pkt_read_tree_path()
>
> librte_pipeline, qos_sched UT, qos_sched app are updated to make use of
> new changes.
>
> Also mbuf->hash.txadapter has been added for eventdev txq,
> rte_event_eth_tx_adapter_txq_set and rte_event_eth_tx_adapter_txq_get()
> are updated to use mbuf->hash.txadapter.txq.
>
> doc:
> Release notes updated.
> Removed deprecation notice for mbuf->hash.sched and sched API.
>
> [1] http://mails.dpdk.org/archives/dev/2018-February/090651.html
> [2] https://mails.dpdk.org/archives/dev/2018-November/119051.html
>
> Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
> Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> ---
> v7:
>
> Edited the commit message.
> Moved rte_mbuf_sched inside the rte_mbuf struct.
> Added missing empty line in doxygen comments of sched set and get
> functions.
>
> v6: added scheduler comment
>
> v5:
> Removed librte_meter from librte_mbuf dependency list.
> Changed the mbuf set/get functions to use uint8_t for color.
>
> v4: converted mbuf->hash.sched as instantiation of rte_mbuf_sched.
>
> v3: addressed review comments given in the below link.
> http://patches.dpdk.org/patch/48587/
> Updated library ABI versioning in meson build.
> ---
> ---
> doc/guides/rel_notes/deprecation.rst | 10 --
> doc/guides/rel_notes/release_19_02.rst | 4 +-
> examples/qos_sched/app_thread.c | 7 +-
> examples/qos_sched/main.c | 1 +
> .../rte_event_eth_tx_adapter.h | 18 ++-
> lib/librte_mbuf/Makefile | 2 +-
> lib/librte_mbuf/meson.build | 2 +-
> lib/librte_mbuf/rte_mbuf.h | 119 +++++++++++++++++-
> lib/librte_pipeline/rte_table_action.c | 44 +++----
> lib/librte_sched/Makefile | 2 +-
> lib/librte_sched/meson.build | 1 +
> lib/librte_sched/rte_sched.c | 90 ++++++-------
> lib/librte_sched/rte_sched.h | 10 +-
> test/test/test_sched.c | 9 +-
> 14 files changed, 197 insertions(+), 122 deletions(-)
>
> diff --git a/lib/librte_eventdev/rte_event_eth_tx_adapter.h
> b/lib/librte_eventdev/rte_event_eth_tx_adapter.h
> index 81456d4a9..2a50656d9 100644
> --- a/lib/librte_eventdev/rte_event_eth_tx_adapter.h
> +++ b/lib/librte_eventdev/rte_event_eth_tx_adapter.h
> @@ -63,13 +63,11 @@
> * function can be used to retrieve the adapter's service function ID.
> *
> * The ethernet port and transmit queue index to transmit the mbuf on are
> - * specified using the mbuf port and the higher 16 bits of
> - * struct rte_mbuf::hash::sched:hi. The application should use the
> - * rte_event_eth_tx_adapter_txq_set() and
> rte_event_eth_tx_adapter_txq_get()
> - * functions to access the transmit queue index since it is expected that the
> - * transmit queue will be eventually defined within struct rte_mbuf and using
> - * these macros will help with minimizing application impact due to
> - * a change in how the transmit queue index is specified.
> + * specified using the mbuf port struct rte_mbuf::hash::txadapter:txq.
> + * The application should use the rte_event_eth_tx_adapter_txq_set()
> + * and rte_event_eth_tx_adapter_txq_get() functions to access the
> + transmit
> + * queue index, using these macros will help with minimizing
> + application
> + * impact due to a change in how the transmit queue index is specified.
> */
>
> #ifdef __cplusplus
> @@ -300,8 +298,7 @@ rte_event_eth_tx_adapter_queue_del(uint8_t id,
> static __rte_always_inline void __rte_experimental
> rte_event_eth_tx_adapter_txq_set(struct rte_mbuf *pkt, uint16_t queue) {
> - uint16_t *p = (uint16_t *)&pkt->hash.sched.hi;
> - p[1] = queue;
> + pkt->hash.txadapter.txq = queue;
> }
>
> /**
> @@ -320,8 +317,7 @@ rte_event_eth_tx_adapter_txq_set(struct rte_mbuf
> *pkt, uint16_t queue) static __rte_always_inline uint16_t
> __rte_experimental rte_event_eth_tx_adapter_txq_get(struct rte_mbuf
> *pkt) {
> - uint16_t *p = (uint16_t *)&pkt->hash.sched.hi;
> - return p[1];
> + return pkt->hash.txadapter.txq;
> }
>
Event Tx adapter changes
Tested-by: Nikhil Rao <nikhil.rao@intel.com>
Reviewed-by: Nikhil Rao <nikhil.rao@intel.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3] libs/power: add p-state driver compatibility
@ 2018-12-20 14:52 0% ` Hunt, David
2018-12-21 0:30 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Hunt, David @ 2018-12-20 14:52 UTC (permalink / raw)
To: Thomas Monjalon, Liang Ma; +Cc: dev, anatoly.burakov
On 19/12/2018 8:31 PM, Thomas Monjalon wrote:
> 19/12/2018 10:09, Hunt, David:
>> On 19/12/2018 3:18 AM, Thomas Monjalon wrote:
>>> 14/12/2018 14:11, Liang Ma:
>>>> Previously, in order to use the power library, it was necessary
>>>> for the user to disable the intel_pstate driver by adding
>>>> “intel_pstate=disable” to the kernel command line for the system,
>>>> which causes the acpi_cpufreq driver to be loaded in its place.
>>>>
>>>> This patch adds the ability for the power library use the intel-pstate
>>>> driver.
>>>>
>>>> It adds a new suite of functions behind the current power library API,
>>>> and will seamlessly set up the user facing API function pointers to
>>>> the relevant functions depending on whether the system is running with
>>>> acpi_cpufreq kernel driver, intel_pstate kernel driver or in a guest,
>>>> using kvm. The library API and ABI is unchanged.
>>>>
>>>> Signed-off-by: Liang Ma <liang.j.ma@intel.com>
>>>>
>>>> Reviewed-by: Anatoly Burakov <anatoly.burakov@intel.com>
>>>> ---
>>> Please write a changelog when sending a new version.
>>>
>>> Dave, any comment on this patch?
>>
>> Looks good to me.
>>
>> Acked-by: David Hunt <david.hunt@intel.com>
>>
>>
>>>> --- /dev/null
>>>> +++ b/lib/librte_power/power_pstate_cpufreq.c
>>>> @@ -0,0 +1,770 @@
>>>> +/* SPDX-License-Identifier: BSD-3-Clause
>>>> + * Copyright(c) 2018-2018 Intel Corporation
>>> Something wrong here :)
>> Yes, should simply be "Copyright(c) 2018 Intel Corporation"
>
> There is also a compilation error with meson:
>
> lib/librte_power/rte_power_empty_poll.h:20:10: fatal error:
> rte_timer.h: No such file or directory
>
> Clearly, some quality checks are missing.
>
> I'm afraid we won't have any patch for power library in 19.02.
Hi Thomas,
We have just pushed a v4, and tested with make, meson/ninja, and several
different build environments. I believe this version should be
acceptable for 19.02.
Regards,
Dave.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v4] libs/power: add p-state driver compatibility
@ 2018-12-20 14:43 1% ` Liang Ma
2018-12-21 0:34 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Liang Ma @ 2018-12-20 14:43 UTC (permalink / raw)
To: david.hunt; +Cc: dev, anatoly.burakov, Liang Ma
Previously, in order to use the power library, it was necessary
for the user to disable the intel_pstate driver by adding
“intel_pstate=disable” to the kernel command line for the system,
which causes the acpi_cpufreq driver to be loaded in its place.
This patch adds the ability for the power library use the intel-pstate
driver.
It adds a new suite of functions behind the current power library API,
and will seamlessly set up the user facing API function pointers to
the relevant functions depending on whether the system is running with
acpi_cpufreq kernel driver, intel_pstate kernel driver or in a guest,
using kvm. The library API and ABI is unchanged.
Signed-off-by: Liang Ma <liang.j.ma@intel.com>
Reviewed-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: David Hunt <david.hunt@intel.com>
---
Change Log:
v2 Code review rework
v3 Code review rework
v4 Fix the meson build failure
---
lib/librte_power/Makefile | 2 +
lib/librte_power/meson.build | 3 +-
lib/librte_power/power_pstate_cpufreq.c | 771 ++++++++++++++++++++++++++++++++
lib/librte_power/power_pstate_cpufreq.h | 218 +++++++++
lib/librte_power/rte_power.c | 48 +-
lib/librte_power/rte_power.h | 3 +-
6 files changed, 1033 insertions(+), 12 deletions(-)
create mode 100644 lib/librte_power/power_pstate_cpufreq.c
create mode 100644 lib/librte_power/power_pstate_cpufreq.h
diff --git a/lib/librte_power/Makefile b/lib/librte_power/Makefile
index 9bec668..ab77152 100644
--- a/lib/librte_power/Makefile
+++ b/lib/librte_power/Makefile
@@ -6,6 +6,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
# library name
LIB = librte_power.a
+CFLAGS += -DALLOW_EXPERIMENTAL_API
CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3 -fno-strict-aliasing
LDLIBS += -lrte_eal -lrte_timer
@@ -17,6 +18,7 @@ LIBABIVER := 1
SRCS-$(CONFIG_RTE_LIBRTE_POWER) := rte_power.c power_acpi_cpufreq.c
SRCS-$(CONFIG_RTE_LIBRTE_POWER) += power_kvm_vm.c guest_channel.c
SRCS-$(CONFIG_RTE_LIBRTE_POWER) += rte_power_empty_poll.c
+SRCS-$(CONFIG_RTE_LIBRTE_POWER) += power_pstate_cpufreq.c
# install this header file
SYMLINK-$(CONFIG_RTE_LIBRTE_POWER)-include := rte_power.h rte_power_empty_poll.h
diff --git a/lib/librte_power/meson.build b/lib/librte_power/meson.build
index 9ed8b56..02e0337 100644
--- a/lib/librte_power/meson.build
+++ b/lib/librte_power/meson.build
@@ -6,6 +6,7 @@ if host_machine.system() != 'linux'
endif
sources = files('rte_power.c', 'power_acpi_cpufreq.c',
'power_kvm_vm.c', 'guest_channel.c',
- 'rte_power_empty_poll.c')
+ 'rte_power_empty_poll.c',
+ 'power_pstate_cpufreq.c')
headers = files('rte_power.h','rte_power_empty_poll.h')
deps += ['timer']
diff --git a/lib/librte_power/power_pstate_cpufreq.c b/lib/librte_power/power_pstate_cpufreq.c
new file mode 100644
index 0000000..411d0eb
--- /dev/null
+++ b/lib/librte_power/power_pstate_cpufreq.c
@@ -0,0 +1,771 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2018 Intel Corporation
+ */
+
+#include <stdio.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <fcntl.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#include <signal.h>
+#include <limits.h>
+#include <errno.h>
+#include <inttypes.h>
+
+#include <rte_memcpy.h>
+#include <rte_atomic.h>
+
+#include "power_pstate_cpufreq.h"
+#include "power_common.h"
+
+
+#ifdef RTE_LIBRTE_POWER_DEBUG
+#define POWER_DEBUG_TRACE(fmt, args...) do { \
+ RTE_LOG(ERR, POWER, "%s: " fmt, __func__, ## args); \
+} while (0)
+#else
+#define POWER_DEBUG_TRACE(fmt, args...)
+#endif
+
+#define FOPEN_OR_ERR_RET(f, retval) do { \
+ if ((f) == NULL) { \
+ RTE_LOG(ERR, POWER, "File not openned\n"); \
+ return retval; \
+ } \
+} while (0)
+
+#define FOPS_OR_NULL_GOTO(ret, label) do { \
+ if ((ret) == NULL) { \
+ RTE_LOG(ERR, POWER, "fgets returns nothing\n"); \
+ goto label; \
+ } \
+} while (0)
+
+#define FOPS_OR_ERR_GOTO(ret, label) do { \
+ if ((ret) < 0) { \
+ RTE_LOG(ERR, POWER, "File operations failed\n"); \
+ goto label; \
+ } \
+} while (0)
+
+
+#define POWER_CONVERT_TO_DECIMAL 10
+#define BUS_FREQ 100000
+
+#define POWER_GOVERNOR_PERF "performance"
+#define POWER_SYSFILE_GOVERNOR \
+ "/sys/devices/system/cpu/cpu%u/cpufreq/scaling_governor"
+#define POWER_SYSFILE_MAX_FREQ \
+ "/sys/devices/system/cpu/cpu%u/cpufreq/scaling_max_freq"
+#define POWER_SYSFILE_MIN_FREQ \
+ "/sys/devices/system/cpu/cpu%u/cpufreq/scaling_min_freq"
+#define POWER_SYSFILE_CUR_FREQ \
+ "/sys/devices/system/cpu/cpu%u/cpufreq/scaling_cur_freq"
+#define POWER_SYSFILE_BASE_MAX_FREQ \
+ "/sys/devices/system/cpu/cpu%u/cpufreq/cpuinfo_max_freq"
+#define POWER_SYSFILE_BASE_MIN_FREQ \
+ "/sys/devices/system/cpu/cpu%u/cpufreq/cpuinfo_min_freq"
+#define POWER_MSR_PATH "/dev/cpu/%u/msr"
+
+/*
+ * MSR related
+ */
+#define PLATFORM_INFO 0x0CE
+#define NON_TURBO_MASK 0xFF00
+#define NON_TURBO_OFFSET 0x8
+
+
+enum power_state {
+ POWER_IDLE = 0,
+ POWER_ONGOING,
+ POWER_USED,
+ POWER_UNKNOWN
+};
+
+struct pstate_power_info {
+ unsigned int lcore_id; /**< Logical core id */
+ uint32_t freqs[RTE_MAX_LCORE_FREQS]; /**< Frequency array */
+ uint32_t nb_freqs; /**< number of available freqs */
+ FILE *f_cur_min; /**< FD of scaling_min */
+ FILE *f_cur_max; /**< FD of scaling_max */
+ char governor_ori[32]; /**< Original governor name */
+ uint32_t curr_idx; /**< Freq index in freqs array */
+ uint32_t non_turbo_max_ratio; /**< Non Turbo Max ratio */
+ uint32_t sys_max_freq; /**< system wide max freq */
+ volatile uint32_t state; /**< Power in use state */
+ uint16_t turbo_available; /**< Turbo Boost available */
+ uint16_t turbo_enable; /**< Turbo Boost enable/disable */
+} __rte_cache_aligned;
+
+
+static struct pstate_power_info lcore_power_info[RTE_MAX_LCORE];
+
+/**
+ * It is to read the specific MSR.
+ */
+
+static int32_t
+power_rdmsr(int msr, uint64_t *val, unsigned int lcore_id)
+{
+ int fd, ret;
+ char fullpath[PATH_MAX];
+
+ snprintf(fullpath, sizeof(fullpath), POWER_MSR_PATH, lcore_id);
+
+ fd = open(fullpath, O_RDONLY);
+
+ if (fd < 0) {
+ RTE_LOG(ERR, POWER, "Error opening '%s': %s\n", fullpath,
+ strerror(errno));
+ return fd;
+ }
+
+ ret = pread(fd, val, sizeof(uint64_t), msr);
+
+ if (ret < 0) {
+ RTE_LOG(ERR, POWER, "Error reading '%s': %s\n", fullpath,
+ strerror(errno));
+ goto out;
+ }
+
+ POWER_DEBUG_TRACE("MSR Path %s, offset 0x%X for lcore %u\n",
+ fullpath, msr, lcore_id);
+
+ POWER_DEBUG_TRACE("Ret value %d, content is 0x%"PRIx64"\n", ret, *val);
+
+out: close(fd);
+ return ret;
+}
+
+/**
+ * It is to fopen the sys file for the future setting the lcore frequency.
+ */
+static int
+power_init_for_setting_freq(struct pstate_power_info *pi)
+{
+ FILE *f_min, *f_max;
+ char fullpath_min[PATH_MAX];
+ char fullpath_max[PATH_MAX];
+ uint64_t max_non_turbo = 0;
+
+ snprintf(fullpath_min, sizeof(fullpath_min), POWER_SYSFILE_MIN_FREQ,
+ pi->lcore_id);
+
+ f_min = fopen(fullpath_min, "rw+");
+ FOPEN_OR_ERR_RET(f_min, -1);
+
+ snprintf(fullpath_max, sizeof(fullpath_max), POWER_SYSFILE_MAX_FREQ,
+ pi->lcore_id);
+
+ f_max = fopen(fullpath_max, "rw+");
+ FOPEN_OR_ERR_RET(f_max, -1);
+
+ pi->f_cur_min = f_min;
+ pi->f_cur_max = f_max;
+
+ /* Add MSR read to detect turbo status */
+
+ if (power_rdmsr(PLATFORM_INFO, &max_non_turbo, pi->lcore_id) < 0)
+ return -1;
+
+ max_non_turbo = (max_non_turbo&NON_TURBO_MASK)>>NON_TURBO_OFFSET;
+
+ POWER_DEBUG_TRACE("no turbo perf %"PRIu64"\n", max_non_turbo);
+
+ pi->non_turbo_max_ratio = max_non_turbo;
+
+ return 0;
+}
+
+static int
+set_freq_internal(struct pstate_power_info *pi, uint32_t idx)
+{
+ uint32_t target_freq = 0;
+
+ if (idx >= RTE_MAX_LCORE_FREQS || idx >= pi->nb_freqs) {
+ RTE_LOG(ERR, POWER, "Invalid frequency index %u, which "
+ "should be less than %u\n", idx, pi->nb_freqs);
+ return -1;
+ }
+
+ /* Check if it is the same as current */
+ if (idx == pi->curr_idx)
+ return 0;
+
+ /* Because Intel Pstate Driver only allow user change min/max hint
+ * User need change the min/max as same value.
+ */
+ if (fseek(pi->f_cur_min, 0, SEEK_SET) < 0) {
+ RTE_LOG(ERR, POWER, "Fail to set file position indicator to 0 "
+ "for setting frequency for lcore %u\n",
+ pi->lcore_id);
+ return -1;
+ }
+
+ if (fseek(pi->f_cur_max, 0, SEEK_SET) < 0) {
+ RTE_LOG(ERR, POWER, "Fail to set file position indicator to 0 "
+ "for setting frequency for lcore %u\n",
+ pi->lcore_id);
+ return -1;
+ }
+
+ /* Turbo is available and enabled, first freq bucket is sys max freq */
+ if (pi->turbo_available && pi->turbo_enable && (idx == 0))
+ target_freq = pi->sys_max_freq;
+ else
+ target_freq = pi->freqs[idx];
+
+ /* Decrease freq, the min freq should be updated first */
+ if (idx > pi->curr_idx) {
+
+ if (fprintf(pi->f_cur_min, "%u", target_freq) < 0) {
+ RTE_LOG(ERR, POWER, "Fail to write new frequency for "
+ "lcore %u\n", pi->lcore_id);
+ return -1;
+ }
+
+ if (fprintf(pi->f_cur_max, "%u", target_freq) < 0) {
+ RTE_LOG(ERR, POWER, "Fail to write new frequency for "
+ "lcore %u\n", pi->lcore_id);
+ return -1;
+ }
+
+ POWER_DEBUG_TRACE("Freqency '%u' to be set for lcore %u\n",
+ target_freq, pi->lcore_id);
+
+ fflush(pi->f_cur_min);
+ fflush(pi->f_cur_max);
+
+ }
+
+ /* Increase freq, the max freq should be updated first */
+ if (idx < pi->curr_idx) {
+
+ if (fprintf(pi->f_cur_max, "%u", target_freq) < 0) {
+ RTE_LOG(ERR, POWER, "Fail to write new frequency for "
+ "lcore %u\n", pi->lcore_id);
+ return -1;
+ }
+
+ if (fprintf(pi->f_cur_min, "%u", target_freq) < 0) {
+ RTE_LOG(ERR, POWER, "Fail to write new frequency for "
+ "lcore %u\n", pi->lcore_id);
+ return -1;
+ }
+
+ POWER_DEBUG_TRACE("Freqency '%u' to be set for lcore %u\n",
+ target_freq, pi->lcore_id);
+
+ fflush(pi->f_cur_max);
+ fflush(pi->f_cur_min);
+ }
+
+ pi->curr_idx = idx;
+
+ return 1;
+}
+
+/**
+ * It is to check the current scaling governor by reading sys file, and then
+ * set it into 'performance' if it is not by writing the sys file. The original
+ * governor will be saved for rolling back.
+ */
+static int
+power_set_governor_performance(struct pstate_power_info *pi)
+{
+ FILE *f;
+ int ret = -1;
+ char buf[BUFSIZ];
+ char fullpath[PATH_MAX];
+ char *s;
+ int val;
+
+ snprintf(fullpath, sizeof(fullpath), POWER_SYSFILE_GOVERNOR,
+ pi->lcore_id);
+ f = fopen(fullpath, "rw+");
+ FOPEN_OR_ERR_RET(f, ret);
+
+ s = fgets(buf, sizeof(buf), f);
+ FOPS_OR_NULL_GOTO(s, out);
+
+ /* Check if current governor is performance */
+ if (strncmp(buf, POWER_GOVERNOR_PERF,
+ sizeof(POWER_GOVERNOR_PERF)) == 0) {
+ ret = 0;
+ POWER_DEBUG_TRACE("Power management governor of lcore %u is "
+ "already performance\n", pi->lcore_id);
+ goto out;
+ }
+ /* Save the original governor */
+ snprintf(pi->governor_ori, sizeof(pi->governor_ori), "%s", buf);
+
+ /* Write 'performance' to the governor */
+ val = fseek(f, 0, SEEK_SET);
+ FOPS_OR_ERR_GOTO(val, out);
+
+ val = fputs(POWER_GOVERNOR_PERF, f);
+ FOPS_OR_ERR_GOTO(val, out);
+
+ ret = 0;
+ RTE_LOG(INFO, POWER, "Power management governor of lcore %u has been "
+ "set to performance successfully\n", pi->lcore_id);
+out:
+ fclose(f);
+
+ return ret;
+}
+
+/**
+ * It is to check the governor and then set the original governor back if
+ * needed by writing the sys file.
+ */
+static int
+power_set_governor_original(struct pstate_power_info *pi)
+{
+ FILE *f;
+ int ret = -1;
+ char buf[BUFSIZ];
+ char fullpath[PATH_MAX];
+ char *s;
+ int val;
+
+ snprintf(fullpath, sizeof(fullpath), POWER_SYSFILE_GOVERNOR,
+ pi->lcore_id);
+ f = fopen(fullpath, "rw+");
+ FOPEN_OR_ERR_RET(f, ret);
+
+ s = fgets(buf, sizeof(buf), f);
+ FOPS_OR_NULL_GOTO(s, out);
+
+ /* Check if the governor to be set is the same as current */
+ if (strncmp(buf, pi->governor_ori, sizeof(pi->governor_ori)) == 0) {
+ ret = 0;
+ POWER_DEBUG_TRACE("Power management governor of lcore %u "
+ "has already been set to %s\n",
+ pi->lcore_id, pi->governor_ori);
+ goto out;
+ }
+
+ /* Write back the original governor */
+ val = fseek(f, 0, SEEK_SET);
+ FOPS_OR_ERR_GOTO(val, out);
+
+ val = fputs(pi->governor_ori, f);
+ FOPS_OR_ERR_GOTO(val, out);
+
+ ret = 0;
+ RTE_LOG(INFO, POWER, "Power management governor of lcore %u "
+ "has been set back to %s successfully\n",
+ pi->lcore_id, pi->governor_ori);
+out:
+ fclose(f);
+
+ return ret;
+}
+
+/**
+ * It is to get the available frequencies of the specific lcore by reading the
+ * sys file.
+ */
+static int
+power_get_available_freqs(struct pstate_power_info *pi)
+{
+ FILE *f_min, *f_max;
+ int ret = -1;
+ char *p_min, *p_max;
+ char buf_min[BUFSIZ];
+ char buf_max[BUFSIZ];
+ char fullpath_min[PATH_MAX];
+ char fullpath_max[PATH_MAX];
+ char *s_min, *s_max;
+ uint32_t sys_min_freq = 0, sys_max_freq = 0, base_max_freq = 0;
+ uint32_t i, num_freqs = 0;
+
+ snprintf(fullpath_max, sizeof(fullpath_max),
+ POWER_SYSFILE_BASE_MAX_FREQ,
+ pi->lcore_id);
+ snprintf(fullpath_min, sizeof(fullpath_min),
+ POWER_SYSFILE_BASE_MIN_FREQ,
+ pi->lcore_id);
+
+ f_min = fopen(fullpath_min, "r");
+ FOPEN_OR_ERR_RET(f_min, ret);
+
+ f_max = fopen(fullpath_max, "r");
+ FOPEN_OR_ERR_RET(f_max, ret);
+
+ s_min = fgets(buf_min, sizeof(buf_min), f_min);
+ FOPS_OR_NULL_GOTO(s_min, out);
+
+ s_max = fgets(buf_max, sizeof(buf_max), f_max);
+ FOPS_OR_NULL_GOTO(s_max, out);
+
+
+ /* Strip the line break if there is */
+ p_min = strchr(buf_min, '\n');
+ if (p_min != NULL)
+ *p_min = 0;
+
+ p_max = strchr(buf_max, '\n');
+ if (p_max != NULL)
+ *p_max = 0;
+
+ sys_min_freq = strtoul(buf_min, &p_min, POWER_CONVERT_TO_DECIMAL);
+ sys_max_freq = strtoul(buf_max, &p_max, POWER_CONVERT_TO_DECIMAL);
+
+ if (sys_max_freq < sys_min_freq)
+ goto out;
+
+ pi->sys_max_freq = sys_max_freq;
+
+ base_max_freq = pi->non_turbo_max_ratio * BUS_FREQ;
+
+ POWER_DEBUG_TRACE("sys min %u, sys max %u, base_max %u\n",
+ sys_min_freq,
+ sys_max_freq,
+ base_max_freq);
+
+ if (base_max_freq < sys_max_freq)
+ pi->turbo_available = 1;
+ else
+ pi->turbo_available = 0;
+
+ /* If turbo is available then there is one extra freq bucket
+ * to store the sys max freq which value is base_max +1
+ */
+ num_freqs = (base_max_freq - sys_min_freq) / BUS_FREQ + 1 +
+ pi->turbo_available;
+
+ /* Generate the freq bucket array.
+ * If turbo is available the freq bucket[0] value is base_max +1
+ * the bucket[1] is base_max, bucket[2] is base_max - BUS_FREQ
+ * and so on.
+ * If turbo is not available bucket[0] is base_max and so on
+ */
+ for (i = 0, pi->nb_freqs = 0; i < num_freqs; i++) {
+ if ((i == 0) && pi->turbo_available)
+ pi->freqs[pi->nb_freqs++] = base_max_freq + 1;
+ else
+ pi->freqs[pi->nb_freqs++] =
+ base_max_freq - (i - pi->turbo_available) * BUS_FREQ;
+ }
+
+ ret = 0;
+
+ POWER_DEBUG_TRACE("%d frequency(s) of lcore %u are available\n",
+ num_freqs, pi->lcore_id);
+
+out:
+ fclose(f_min);
+ fclose(f_max);
+
+ return ret;
+}
+
+int
+power_pstate_cpufreq_init(unsigned int lcore_id)
+{
+ struct pstate_power_info *pi;
+
+ if (lcore_id >= RTE_MAX_LCORE) {
+ RTE_LOG(ERR, POWER, "Lcore id %u can not exceed %u\n",
+ lcore_id, RTE_MAX_LCORE - 1U);
+ return -1;
+ }
+
+ pi = &lcore_power_info[lcore_id];
+ if (rte_atomic32_cmpset(&(pi->state), POWER_IDLE, POWER_ONGOING)
+ == 0) {
+ RTE_LOG(INFO, POWER, "Power management of lcore %u is "
+ "in use\n", lcore_id);
+ return -1;
+ }
+
+ pi->lcore_id = lcore_id;
+ /* Check and set the governor */
+ if (power_set_governor_performance(pi) < 0) {
+ RTE_LOG(ERR, POWER, "Cannot set governor of lcore %u to "
+ "performance\n", lcore_id);
+ goto fail;
+ }
+ /* Init for setting lcore frequency */
+ if (power_init_for_setting_freq(pi) < 0) {
+ RTE_LOG(ERR, POWER, "Cannot init for setting frequency for "
+ "lcore %u\n", lcore_id);
+ goto fail;
+ }
+
+ /* Get the available frequencies */
+ if (power_get_available_freqs(pi) < 0) {
+ RTE_LOG(ERR, POWER, "Cannot get available frequencies of "
+ "lcore %u\n", lcore_id);
+ goto fail;
+ }
+
+
+ /* Set freq to max by default */
+ if (power_pstate_cpufreq_freq_max(lcore_id) < 0) {
+ RTE_LOG(ERR, POWER, "Cannot set frequency of lcore %u "
+ "to max\n", lcore_id);
+ goto fail;
+ }
+
+ RTE_LOG(INFO, POWER, "Initialized successfully for lcore %u "
+ "power management\n", lcore_id);
+ rte_atomic32_cmpset(&(pi->state), POWER_ONGOING, POWER_USED);
+
+ return 0;
+
+fail:
+ rte_atomic32_cmpset(&(pi->state), POWER_ONGOING, POWER_UNKNOWN);
+
+ return -1;
+}
+
+int
+power_pstate_cpufreq_exit(unsigned int lcore_id)
+{
+ struct pstate_power_info *pi;
+
+ if (lcore_id >= RTE_MAX_LCORE) {
+ RTE_LOG(ERR, POWER, "Lcore id %u can not exceeds %u\n",
+ lcore_id, RTE_MAX_LCORE - 1U);
+ return -1;
+ }
+ pi = &lcore_power_info[lcore_id];
+
+ if (rte_atomic32_cmpset(&(pi->state), POWER_USED, POWER_ONGOING)
+ == 0) {
+ RTE_LOG(INFO, POWER, "Power management of lcore %u is "
+ "not used\n", lcore_id);
+ return -1;
+ }
+
+ /* Close FD of setting freq */
+ fclose(pi->f_cur_min);
+ fclose(pi->f_cur_max);
+ pi->f_cur_min = NULL;
+ pi->f_cur_max = NULL;
+
+ /* Set the governor back to the original */
+ if (power_set_governor_original(pi) < 0) {
+ RTE_LOG(ERR, POWER, "Cannot set the governor of %u back "
+ "to the original\n", lcore_id);
+ goto fail;
+ }
+
+ RTE_LOG(INFO, POWER, "Power management of lcore %u has exited from "
+ "'performance' mode and been set back to the "
+ "original\n", lcore_id);
+ rte_atomic32_cmpset(&(pi->state), POWER_ONGOING, POWER_IDLE);
+
+ return 0;
+
+fail:
+ rte_atomic32_cmpset(&(pi->state), POWER_ONGOING, POWER_UNKNOWN);
+
+ return -1;
+}
+
+
+uint32_t
+power_pstate_cpufreq_freqs(unsigned int lcore_id, uint32_t *freqs, uint32_t num)
+{
+ struct pstate_power_info *pi;
+
+ if (lcore_id >= RTE_MAX_LCORE) {
+ RTE_LOG(ERR, POWER, "Invalid lcore ID\n");
+ return -1;
+ }
+
+ pi = &lcore_power_info[lcore_id];
+ if (num < pi->nb_freqs) {
+ RTE_LOG(ERR, POWER, "Buffer size is not enough\n");
+ return 0;
+ }
+ rte_memcpy(freqs, pi->freqs, pi->nb_freqs * sizeof(uint32_t));
+
+ return pi->nb_freqs;
+}
+
+uint32_t
+power_pstate_cpufreq_get_freq(unsigned int lcore_id)
+{
+ if (lcore_id >= RTE_MAX_LCORE) {
+ RTE_LOG(ERR, POWER, "Invalid lcore ID\n");
+ return RTE_POWER_INVALID_FREQ_INDEX;
+ }
+
+ return lcore_power_info[lcore_id].curr_idx;
+}
+
+
+int
+power_pstate_cpufreq_set_freq(unsigned int lcore_id, uint32_t index)
+{
+ if (lcore_id >= RTE_MAX_LCORE) {
+ RTE_LOG(ERR, POWER, "Invalid lcore ID\n");
+ return -1;
+ }
+
+ return set_freq_internal(&(lcore_power_info[lcore_id]), index);
+}
+
+int
+power_pstate_cpufreq_freq_up(unsigned int lcore_id)
+{
+ struct pstate_power_info *pi;
+
+ if (lcore_id >= RTE_MAX_LCORE) {
+ RTE_LOG(ERR, POWER, "Invalid lcore ID\n");
+ return -1;
+ }
+
+ pi = &lcore_power_info[lcore_id];
+ if (pi->curr_idx == 0)
+ return 0;
+
+ /* Frequencies in the array are from high to low. */
+ return set_freq_internal(pi, pi->curr_idx - 1);
+}
+
+int
+power_pstate_cpufreq_freq_down(unsigned int lcore_id)
+{
+ struct pstate_power_info *pi;
+
+ if (lcore_id >= RTE_MAX_LCORE) {
+ RTE_LOG(ERR, POWER, "Invalid lcore ID\n");
+ return -1;
+ }
+
+ pi = &lcore_power_info[lcore_id];
+ if (pi->curr_idx + 1 == pi->nb_freqs)
+ return 0;
+
+ /* Frequencies in the array are from high to low. */
+ return set_freq_internal(pi, pi->curr_idx + 1);
+}
+
+int
+power_pstate_cpufreq_freq_max(unsigned int lcore_id)
+{
+ if (lcore_id >= RTE_MAX_LCORE) {
+ RTE_LOG(ERR, POWER, "Invalid lcore ID\n");
+ return -1;
+ }
+
+ /* Frequencies in the array are from high to low. */
+ if (lcore_power_info[lcore_id].turbo_available) {
+ if (lcore_power_info[lcore_id].turbo_enable)
+ /* Set to Turbo */
+ return set_freq_internal(
+ &lcore_power_info[lcore_id], 0);
+ else
+ /* Set to max non-turbo */
+ return set_freq_internal(
+ &lcore_power_info[lcore_id], 1);
+ } else
+ return set_freq_internal(&lcore_power_info[lcore_id], 0);
+}
+
+
+int
+power_pstate_cpufreq_freq_min(unsigned int lcore_id)
+{
+ struct pstate_power_info *pi;
+
+ if (lcore_id >= RTE_MAX_LCORE) {
+ RTE_LOG(ERR, POWER, "Invalid lcore ID\n");
+ return -1;
+ }
+
+ pi = &lcore_power_info[lcore_id];
+
+ /* Frequencies in the array are from high to low. */
+ return set_freq_internal(pi, pi->nb_freqs - 1);
+}
+
+
+int
+power_pstate_turbo_status(unsigned int lcore_id)
+{
+ struct pstate_power_info *pi;
+
+ if (lcore_id >= RTE_MAX_LCORE) {
+ RTE_LOG(ERR, POWER, "Invalid lcore ID\n");
+ return -1;
+ }
+
+ pi = &lcore_power_info[lcore_id];
+
+ return pi->turbo_enable;
+}
+
+int
+power_pstate_enable_turbo(unsigned int lcore_id)
+{
+ struct pstate_power_info *pi;
+
+ if (lcore_id >= RTE_MAX_LCORE) {
+ RTE_LOG(ERR, POWER, "Invalid lcore ID\n");
+ return -1;
+ }
+
+ pi = &lcore_power_info[lcore_id];
+
+ if (pi->turbo_available)
+ pi->turbo_enable = 1;
+ else {
+ pi->turbo_enable = 0;
+ RTE_LOG(ERR, POWER,
+ "Failed to enable turbo on lcore %u\n",
+ lcore_id);
+ return -1;
+ }
+
+ return 0;
+}
+
+
+int
+power_pstate_disable_turbo(unsigned int lcore_id)
+{
+ struct pstate_power_info *pi;
+
+ if (lcore_id >= RTE_MAX_LCORE) {
+ RTE_LOG(ERR, POWER, "Invalid lcore ID\n");
+ return -1;
+ }
+
+ pi = &lcore_power_info[lcore_id];
+
+ pi->turbo_enable = 0;
+
+
+ return 0;
+}
+
+
+int power_pstate_get_capabilities(unsigned int lcore_id,
+ struct rte_power_core_capabilities *caps)
+{
+ struct pstate_power_info *pi;
+
+ if (lcore_id >= RTE_MAX_LCORE) {
+ RTE_LOG(ERR, POWER, "Invalid lcore ID\n");
+ return -1;
+ }
+ if (caps == NULL) {
+ RTE_LOG(ERR, POWER, "Invalid argument\n");
+ return -1;
+ }
+
+ pi = &lcore_power_info[lcore_id];
+ caps->capabilities = 0;
+ caps->turbo = !!(pi->turbo_available);
+
+ return 0;
+}
diff --git a/lib/librte_power/power_pstate_cpufreq.h b/lib/librte_power/power_pstate_cpufreq.h
new file mode 100644
index 0000000..6fd8018
--- /dev/null
+++ b/lib/librte_power/power_pstate_cpufreq.h
@@ -0,0 +1,218 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2018 Intel Corporation
+ */
+
+#ifndef _POWER_PSTATE_CPUFREQ_H
+#define _POWER_PSTATE_CPUFREQ_H
+
+/**
+ * @file
+ * RTE Power Management via Intel Pstate driver
+ */
+
+#include <rte_common.h>
+#include <rte_byteorder.h>
+#include <rte_log.h>
+#include <rte_string_fns.h>
+#include "rte_power.h"
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/**
+ * Initialize power management for a specific lcore. It will check and set the
+ * governor to performance for the lcore, get the available frequencies, and
+ * prepare to set new lcore frequency.
+ *
+ * @param lcore_id
+ * lcore id.
+ *
+ * @return
+ * - 0 on success.
+ * - Negative on error.
+ */
+int power_pstate_cpufreq_init(unsigned int lcore_id);
+
+/**
+ * Exit power management on a specific lcore. It will set the governor to which
+ * is before initialized.
+ *
+ * @param lcore_id
+ * lcore id.
+ *
+ * @return
+ * - 0 on success.
+ * - Negative on error.
+ */
+int power_pstate_cpufreq_exit(unsigned int lcore_id);
+
+/**
+ * Get the available frequencies of a specific lcore. The return value will be
+ * the minimal one of the total number of available frequencies and the number
+ * of buffer. The index of available frequencies used in other interfaces
+ * should be in the range of 0 to this return value.
+ * It should be protected outside of this function for threadsafe.
+ *
+ * @param lcore_id
+ * lcore id.
+ * @param freqs
+ * The buffer array to save the frequencies.
+ * @param num
+ * The number of frequencies to get.
+ *
+ * @return
+ * The number of available frequencies.
+ */
+uint32_t power_pstate_cpufreq_freqs(unsigned int lcore_id, uint32_t *freqs,
+ uint32_t num);
+
+/**
+ * Return the current index of available frequencies of a specific lcore.
+ * It should be protected outside of this function for threadsafe.
+ *
+ * @param lcore_id
+ * lcore id.
+ *
+ * @return
+ * The current index of available frequencies.
+ * If error, it will return 'RTE_POWER_INVALID_FREQ_INDEX = (~0)'.
+ */
+uint32_t power_pstate_cpufreq_get_freq(unsigned int lcore_id);
+
+/**
+ * Set the new frequency for a specific lcore by indicating the index of
+ * available frequencies.
+ * It should be protected outside of this function for threadsafe.
+ *
+ * @param lcore_id
+ * lcore id.
+ * @param index
+ * The index of available frequencies.
+ *
+ * @return
+ * - 1 on success with frequency changed.
+ * - 0 on success without frequency changed.
+ * - Negative on error.
+ */
+int power_pstate_cpufreq_set_freq(unsigned int lcore_id, uint32_t index);
+
+/**
+ * Scale up the frequency of a specific lcore according to the available
+ * frequencies.
+ * It should be protected outside of this function for threadsafe.
+ *
+ * @param lcore_id
+ * lcore id.
+ *
+ * @return
+ * - 1 on success with frequency changed.
+ * - 0 on success without frequency changed.
+ * - Negative on error.
+ */
+int power_pstate_cpufreq_freq_up(unsigned int lcore_id);
+
+/**
+ * Scale down the frequency of a specific lcore according to the available
+ * frequencies.
+ * It should be protected outside of this function for threadsafe.
+ *
+ * @param lcore_id
+ * lcore id.
+ *
+ * @return
+ * - 1 on success with frequency changed.
+ * - 0 on success without frequency changed.
+ * - Negative on error.
+ */
+int power_pstate_cpufreq_freq_down(unsigned int lcore_id);
+
+/**
+ * Scale up the frequency of a specific lcore to the highest according to the
+ * available frequencies.
+ * It should be protected outside of this function for threadsafe.
+ *
+ * @param lcore_id
+ * lcore id.
+ *
+ * @return
+ * - 1 on success with frequency changed.
+ * - 0 on success without frequency changed.
+ * - Negative on error.
+ */
+int power_pstate_cpufreq_freq_max(unsigned int lcore_id);
+
+/**
+ * Scale down the frequency of a specific lcore to the lowest according to the
+ * available frequencies.
+ * It should be protected outside of this function for threadsafe.
+ *
+ * @param lcore_id
+ * lcore id.
+ *
+ * @return
+ * - 1 on success with frequency changed.
+ * - 0 on success without frequency changed.
+ * - Negative on error.
+ */
+int power_pstate_cpufreq_freq_min(unsigned int lcore_id);
+
+/**
+ * Get the turbo status of a specific lcore.
+ * It should be protected outside of this function for threadsafe.
+ *
+ * @param lcore_id
+ * lcore id.
+ *
+ * @return
+ * - 1 Turbo Boost is enabled on this lcore.
+ * - 0 Turbo Boost is disabled on this lcore.
+ * - Negative on error.
+ */
+int power_pstate_turbo_status(unsigned int lcore_id);
+
+/**
+ * Enable Turbo Boost on a specific lcore.
+ * It should be protected outside of this function for threadsafe.
+ *
+ * @param lcore_id
+ * lcore id.
+ *
+ * @return
+ * - 0 Turbo Boost is enabled successfully on this lcore.
+ * - Negative on error.
+ */
+int power_pstate_enable_turbo(unsigned int lcore_id);
+
+/**
+ * Disable Turbo Boost on a specific lcore.
+ * It should be protected outside of this function for threadsafe.
+ *
+ * @param lcore_id
+ * lcore id.
+ *
+ * @return
+ * - 0 Turbo Boost disabled successfully on this lcore.
+ * - Negative on error.
+ */
+int power_pstate_disable_turbo(unsigned int lcore_id);
+
+/**
+ * Returns power capabilities for a specific lcore.
+ *
+ * @param lcore_id
+ * lcore id.
+ * @param caps
+ * pointer to rte_power_core_capabilities object.
+ *
+ * @return
+ * - 0 on success.
+ * - Negative on error.
+ */
+int power_pstate_get_capabilities(unsigned int lcore_id,
+ struct rte_power_core_capabilities *caps);
+#ifdef __cplusplus
+}
+#endif
+
+#endif
diff --git a/lib/librte_power/rte_power.c b/lib/librte_power/rte_power.c
index 208b791..a05fbef 100644
--- a/lib/librte_power/rte_power.c
+++ b/lib/librte_power/rte_power.c
@@ -7,6 +7,7 @@
#include "rte_power.h"
#include "power_acpi_cpufreq.h"
#include "power_kvm_vm.h"
+#include "power_pstate_cpufreq.h"
#include "power_common.h"
enum power_management_env global_default_env = PM_ENV_NOT_SET;
@@ -56,6 +57,19 @@ rte_power_set_env(enum power_management_env env)
rte_power_freq_enable_turbo = power_kvm_vm_enable_turbo;
rte_power_freq_disable_turbo = power_kvm_vm_disable_turbo;
rte_power_get_capabilities = power_kvm_vm_get_capabilities;
+ } else if (env == PM_ENV_PSTATE_CPUFREQ) {
+ rte_power_freqs = power_pstate_cpufreq_freqs;
+ rte_power_get_freq = power_pstate_cpufreq_get_freq;
+ rte_power_set_freq = power_pstate_cpufreq_set_freq;
+ rte_power_freq_up = power_pstate_cpufreq_freq_up;
+ rte_power_freq_down = power_pstate_cpufreq_freq_down;
+ rte_power_freq_min = power_pstate_cpufreq_freq_min;
+ rte_power_freq_max = power_pstate_cpufreq_freq_max;
+ rte_power_turbo_status = power_pstate_turbo_status;
+ rte_power_freq_enable_turbo = power_pstate_enable_turbo;
+ rte_power_freq_disable_turbo = power_pstate_disable_turbo;
+ rte_power_get_capabilities = power_pstate_get_capabilities;
+
} else {
RTE_LOG(ERR, POWER, "Invalid Power Management Environment(%d) set\n",
env);
@@ -64,7 +78,6 @@ rte_power_set_env(enum power_management_env env)
}
global_default_env = env;
return 0;
-
}
void
@@ -84,21 +97,32 @@ rte_power_init(unsigned int lcore_id)
{
int ret = -1;
- if (global_default_env == PM_ENV_ACPI_CPUFREQ) {
+ switch (global_default_env) {
+ case PM_ENV_ACPI_CPUFREQ:
return power_acpi_cpufreq_init(lcore_id);
- }
- if (global_default_env == PM_ENV_KVM_VM) {
+ case PM_ENV_KVM_VM:
return power_kvm_vm_init(lcore_id);
+ case PM_ENV_PSTATE_CPUFREQ:
+ return power_pstate_cpufreq_init(lcore_id);
+ default:
+ RTE_LOG(INFO, POWER, "Env isn't set yet!\n");
}
+
/* Auto detect Environment */
- RTE_LOG(INFO, POWER, "Attempting to initialise ACPI cpufreq power "
- "management...\n");
+ RTE_LOG(INFO, POWER, "Attempting to initialise ACPI cpufreq power management...\n");
ret = power_acpi_cpufreq_init(lcore_id);
if (ret == 0) {
rte_power_set_env(PM_ENV_ACPI_CPUFREQ);
goto out;
}
+ RTE_LOG(INFO, POWER, "Attempting to initialise PSTAT power management...\n");
+ ret = power_pstate_cpufreq_init(lcore_id);
+ if (ret == 0) {
+ rte_power_set_env(PM_ENV_PSTATE_CPUFREQ);
+ goto out;
+ }
+
RTE_LOG(INFO, POWER, "Attempting to initialise VM power management...\n");
ret = power_kvm_vm_init(lcore_id);
if (ret == 0) {
@@ -114,13 +138,17 @@ rte_power_init(unsigned int lcore_id)
int
rte_power_exit(unsigned int lcore_id)
{
- if (global_default_env == PM_ENV_ACPI_CPUFREQ)
+ switch (global_default_env) {
+ case PM_ENV_ACPI_CPUFREQ:
return power_acpi_cpufreq_exit(lcore_id);
- if (global_default_env == PM_ENV_KVM_VM)
+ case PM_ENV_KVM_VM:
return power_kvm_vm_exit(lcore_id);
+ case PM_ENV_PSTATE_CPUFREQ:
+ return power_pstate_cpufreq_exit(lcore_id);
+ default:
+ RTE_LOG(ERR, POWER, "Environment has not been set, unable to exit gracefully\n");
- RTE_LOG(ERR, POWER, "Environment has not been set, unable to exit "
- "gracefully\n");
+ }
return -1;
}
diff --git a/lib/librte_power/rte_power.h b/lib/librte_power/rte_power.h
index d70bc0b..c5e8f6b 100644
--- a/lib/librte_power/rte_power.h
+++ b/lib/librte_power/rte_power.h
@@ -20,7 +20,8 @@ extern "C" {
#endif
/* Power Management Environment State */
-enum power_management_env {PM_ENV_NOT_SET, PM_ENV_ACPI_CPUFREQ, PM_ENV_KVM_VM};
+enum power_management_env {PM_ENV_NOT_SET, PM_ENV_ACPI_CPUFREQ, PM_ENV_KVM_VM,
+ PM_ENV_PSTATE_CPUFREQ};
/**
* Set the default power management implementation. If this is not called prior
--
2.7.5
^ permalink raw reply [relevance 1%]
* [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format for sched field
@ 2018-12-20 12:16 1% ` Reshma Pattan
2018-12-20 14:55 0% ` Rao, Nikhil
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Reshma Pattan @ 2018-12-20 12:16 UTC (permalink / raw)
To: dev, jerin.jacob, nikhil.rao, olivier.matz, thomas,
jasvinder.singh, cristian.dumitrescu, konstantin.ananyev
Cc: Reshma Pattan
This patch implements the changes proposed in the deprecation
notes [1][2].
librte_mbuf changes:
The mbuf->hash.sched field is updated to support generic
definition in line with the ethdev traffic manager and meter APIs.
The new generic format contains: queue ID, traffic class, color.
Added public APIs to set and get these new fields to and from mbuf.
librte_sched changes:
In addtion, following API functions of the sched library have
been modified with an additional parameter of type struct
rte_sched_port to accommodate the changes made to mbuf sched field.
(i)rte_sched_port_pkt_write()
(ii) rte_sched_port_pkt_read_tree_path()
librte_pipeline, qos_sched UT, qos_sched app are updated
to make use of new changes.
Also mbuf->hash.txadapter has been added for eventdev txq,
rte_event_eth_tx_adapter_txq_set and rte_event_eth_tx_adapter_txq_get()
are updated to use mbuf->hash.txadapter.txq.
doc:
Release notes updated.
Removed deprecation notice for mbuf->hash.sched and sched API.
[1] http://mails.dpdk.org/archives/dev/2018-February/090651.html
[2] https://mails.dpdk.org/archives/dev/2018-November/119051.html
Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
---
v7:
Edited the commit message.
Moved rte_mbuf_sched inside the rte_mbuf struct.
Added missing empty line in doxygen comments of sched
set and get functions.
v6: added scheduler comment
v5:
Removed librte_meter from librte_mbuf dependency list.
Changed the mbuf set/get functions to use uint8_t for color.
v4: converted mbuf->hash.sched as instantiation of rte_mbuf_sched.
v3: addressed review comments given in the below link.
http://patches.dpdk.org/patch/48587/
Updated library ABI versioning in meson build.
---
---
doc/guides/rel_notes/deprecation.rst | 10 --
doc/guides/rel_notes/release_19_02.rst | 4 +-
examples/qos_sched/app_thread.c | 7 +-
examples/qos_sched/main.c | 1 +
.../rte_event_eth_tx_adapter.h | 18 ++-
lib/librte_mbuf/Makefile | 2 +-
lib/librte_mbuf/meson.build | 2 +-
lib/librte_mbuf/rte_mbuf.h | 119 +++++++++++++++++-
lib/librte_pipeline/rte_table_action.c | 44 +++----
lib/librte_sched/Makefile | 2 +-
lib/librte_sched/meson.build | 1 +
lib/librte_sched/rte_sched.c | 90 ++++++-------
lib/librte_sched/rte_sched.h | 10 +-
test/test/test_sched.c | 9 +-
14 files changed, 197 insertions(+), 122 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index ac7fb29a7..ec80dcc7b 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -49,16 +49,6 @@ Deprecation Notices
structure would be made internal (or removed if all dependencies are cleared)
in future releases.
-* mbuf: The opaque ``mbuf->hash.sched`` field will be updated to support generic
- definition in line with the ethdev TM and MTR APIs. Currently, this field
- is defined in librte_sched in a non-generic way. The new generic format
- will contain: queue ID, traffic class, color. Field size will not change.
-
-* sched: Some API functions will change prototype due to the above
- deprecation note for mbuf->hash.sched, e.g. ``rte_sched_port_pkt_write()``
- and ``rte_sched_port_pkt_read()`` will likely have an additional parameter
- of type ``struct rte_sched_port``.
-
* mbuf: the macro ``RTE_MBUF_INDIRECT()`` will be removed in v18.08 or later and
replaced with ``RTE_MBUF_CLONED()`` which is already added in v18.05. As
``EXT_ATTACHED_MBUF`` is newly introduced in v18.05, ``RTE_MBUF_INDIRECT()``
diff --git a/doc/guides/rel_notes/release_19_02.rst b/doc/guides/rel_notes/release_19_02.rst
index 8deb68b9a..1f9ec9fc1 100644
--- a/doc/guides/rel_notes/release_19_02.rst
+++ b/doc/guides/rel_notes/release_19_02.rst
@@ -156,7 +156,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_kvargs.so.1
librte_latencystats.so.1
librte_lpm.so.2
- librte_mbuf.so.4
+ + librte_mbuf.so.5
librte_member.so.1
librte_mempool.so.5
librte_meter.so.2
@@ -178,7 +178,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_rawdev.so.1
librte_reorder.so.1
librte_ring.so.2
- librte_sched.so.1
+ + librte_sched.so.2
librte_security.so.1
librte_table.so.3
librte_timer.so.1
diff --git a/examples/qos_sched/app_thread.c b/examples/qos_sched/app_thread.c
index a59274236..bec4deee3 100644
--- a/examples/qos_sched/app_thread.c
+++ b/examples/qos_sched/app_thread.c
@@ -73,8 +73,11 @@ app_rx_thread(struct thread_conf **confs)
for(i = 0; i < nb_rx; i++) {
get_pkt_sched(rx_mbufs[i],
&subport, &pipe, &traffic_class, &queue, &color);
- rte_sched_port_pkt_write(rx_mbufs[i], subport, pipe,
- traffic_class, queue, (enum rte_meter_color) color);
+ rte_sched_port_pkt_write(conf->sched_port,
+ rx_mbufs[i],
+ subport, pipe,
+ traffic_class, queue,
+ (enum rte_meter_color) color);
}
if (unlikely(rte_ring_sp_enqueue_bulk(conf->rx_ring,
diff --git a/examples/qos_sched/main.c b/examples/qos_sched/main.c
index e7c97bd64..c0ed16b68 100644
--- a/examples/qos_sched/main.c
+++ b/examples/qos_sched/main.c
@@ -55,6 +55,7 @@ app_main_loop(__attribute__((unused))void *dummy)
flow->rx_thread.rx_port = flow->rx_port;
flow->rx_thread.rx_ring = flow->rx_ring;
flow->rx_thread.rx_queue = flow->rx_queue;
+ flow->rx_thread.sched_port = flow->sched_port;
rx_confs[rx_idx++] = &flow->rx_thread;
diff --git a/lib/librte_eventdev/rte_event_eth_tx_adapter.h b/lib/librte_eventdev/rte_event_eth_tx_adapter.h
index 81456d4a9..2a50656d9 100644
--- a/lib/librte_eventdev/rte_event_eth_tx_adapter.h
+++ b/lib/librte_eventdev/rte_event_eth_tx_adapter.h
@@ -63,13 +63,11 @@
* function can be used to retrieve the adapter's service function ID.
*
* The ethernet port and transmit queue index to transmit the mbuf on are
- * specified using the mbuf port and the higher 16 bits of
- * struct rte_mbuf::hash::sched:hi. The application should use the
- * rte_event_eth_tx_adapter_txq_set() and rte_event_eth_tx_adapter_txq_get()
- * functions to access the transmit queue index since it is expected that the
- * transmit queue will be eventually defined within struct rte_mbuf and using
- * these macros will help with minimizing application impact due to
- * a change in how the transmit queue index is specified.
+ * specified using the mbuf port struct rte_mbuf::hash::txadapter:txq.
+ * The application should use the rte_event_eth_tx_adapter_txq_set()
+ * and rte_event_eth_tx_adapter_txq_get() functions to access the transmit
+ * queue index, using these macros will help with minimizing application
+ * impact due to a change in how the transmit queue index is specified.
*/
#ifdef __cplusplus
@@ -300,8 +298,7 @@ rte_event_eth_tx_adapter_queue_del(uint8_t id,
static __rte_always_inline void __rte_experimental
rte_event_eth_tx_adapter_txq_set(struct rte_mbuf *pkt, uint16_t queue)
{
- uint16_t *p = (uint16_t *)&pkt->hash.sched.hi;
- p[1] = queue;
+ pkt->hash.txadapter.txq = queue;
}
/**
@@ -320,8 +317,7 @@ rte_event_eth_tx_adapter_txq_set(struct rte_mbuf *pkt, uint16_t queue)
static __rte_always_inline uint16_t __rte_experimental
rte_event_eth_tx_adapter_txq_get(struct rte_mbuf *pkt)
{
- uint16_t *p = (uint16_t *)&pkt->hash.sched.hi;
- return p[1];
+ return pkt->hash.txadapter.txq;
}
/**
diff --git a/lib/librte_mbuf/Makefile b/lib/librte_mbuf/Makefile
index e2b98a254..8c4c7d790 100644
--- a/lib/librte_mbuf/Makefile
+++ b/lib/librte_mbuf/Makefile
@@ -11,7 +11,7 @@ LDLIBS += -lrte_eal -lrte_mempool
EXPORT_MAP := rte_mbuf_version.map
-LIBABIVER := 4
+LIBABIVER := 5
# all source are stored in SRCS-y
SRCS-$(CONFIG_RTE_LIBRTE_MBUF) := rte_mbuf.c rte_mbuf_ptype.c rte_mbuf_pool_ops.c
diff --git a/lib/librte_mbuf/meson.build b/lib/librte_mbuf/meson.build
index 94d9c4c96..e37da0250 100644
--- a/lib/librte_mbuf/meson.build
+++ b/lib/librte_mbuf/meson.build
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Intel Corporation
-version = 4
+version = 5
sources = files('rte_mbuf.c', 'rte_mbuf_ptype.c', 'rte_mbuf_pool_ops.c')
headers = files('rte_mbuf.h', 'rte_mbuf_ptype.h', 'rte_mbuf_pool_ops.h')
deps += ['mempool']
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 3dbc6695e..bc562dc8a 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -574,14 +574,25 @@ struct rte_mbuf {
* on PKT_RX_FDIR_* flag in ol_flags.
*/
} fdir; /**< Filter identifier if FDIR enabled */
+ struct rte_mbuf_sched {
+ uint32_t queue_id; /**< Queue ID. */
+ uint8_t traffic_class;
+ /**< Traffic class ID. Traffic class 0
+ * is the highest priority traffic class.
+ */
+ uint8_t color;
+ /**< Color. @see enum rte_color.*/
+ uint16_t reserved; /**< Reserved. */
+ } sched; /**< Hierarchical scheduler */
struct {
- uint32_t lo;
- uint32_t hi;
+ uint32_t reserved1;
+ uint16_t reserved2;
+ uint16_t txq;
/**< The event eth Tx adapter uses this field
* to store Tx queue id.
* @see rte_event_eth_tx_adapter_txq_set()
*/
- } sched; /**< Hierarchical scheduler */
+ } txadapter; /**< Eventdev ethdev Tx adapter */
/**< User defined tags. See rte_distributor_process() */
uint32_t usr;
} hash; /**< hash information */
@@ -2289,6 +2300,108 @@ rte_pktmbuf_linearize(struct rte_mbuf *mbuf)
*/
void rte_pktmbuf_dump(FILE *f, const struct rte_mbuf *m, unsigned dump_len);
+/**
+ * Get the value of mbuf sched queue_id field.
+ */
+static inline uint32_t
+rte_mbuf_sched_queue_get(const struct rte_mbuf *m)
+{
+ return m->hash.sched.queue_id;
+}
+
+/**
+ * Get the value of mbuf sched traffic_class field.
+ */
+static inline uint8_t
+rte_mbuf_sched_traffic_class_get(const struct rte_mbuf *m)
+{
+ return m->hash.sched.traffic_class;
+}
+
+/**
+ * Get the value of mbuf sched color field.
+ */
+static inline uint8_t
+rte_mbuf_sched_color_get(const struct rte_mbuf *m)
+{
+ return m->hash.sched.color;
+}
+
+/**
+ * Get the values of mbuf sched queue_id, traffic_class and color.
+ *
+ * @param m
+ * Mbuf to read
+ * @param queue_id
+ * Returns the queue id
+ * @param traffic_class
+ * Returns the traffic class id
+ * @param color
+ * Returns the colour id
+ */
+static inline void
+rte_mbuf_sched_get(const struct rte_mbuf *m, uint32_t *queue_id,
+ uint8_t *traffic_class,
+ uint8_t *color)
+{
+ struct rte_mbuf_sched sched = m->hash.sched;
+
+ *queue_id = sched.queue_id;
+ *traffic_class = sched.traffic_class;
+ *color = sched.color;
+}
+
+/**
+ * Set the mbuf sched queue_id to the defined value.
+ */
+static inline void
+rte_mbuf_sched_queue_set(struct rte_mbuf *m, uint32_t queue_id)
+{
+ m->hash.sched.queue_id = queue_id;
+}
+
+/**
+ * Set the mbuf sched traffic_class id to the defined value.
+ */
+static inline void
+rte_mbuf_sched_traffic_class_set(struct rte_mbuf *m, uint8_t traffic_class)
+{
+ m->hash.sched.traffic_class = traffic_class;
+}
+
+/**
+ * Set the mbuf sched color id to the defined value.
+ */
+static inline void
+rte_mbuf_sched_color_set(struct rte_mbuf *m, uint8_t color)
+{
+ m->hash.sched.color = color;
+}
+
+/**
+ * Set the mbuf sched queue_id, traffic_class and color.
+ *
+ * @param m
+ * Mbuf to set
+ * @param queue_id
+ * Queue id value to be set
+ * @param traffic_class
+ * Traffic class id value to be set
+ * @param color
+ * Color id to be set
+ */
+static inline void
+rte_mbuf_sched_set(struct rte_mbuf *m, uint32_t queue_id,
+ uint8_t traffic_class,
+ uint8_t color)
+{
+ m->hash.sched = (struct rte_mbuf_sched){
+ .queue_id = queue_id,
+ .traffic_class = traffic_class,
+ .color = color,
+ };
+}
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_pipeline/rte_table_action.c b/lib/librte_pipeline/rte_table_action.c
index 7c7c8dd82..8a2bb13dc 100644
--- a/lib/librte_pipeline/rte_table_action.c
+++ b/lib/librte_pipeline/rte_table_action.c
@@ -107,14 +107,6 @@ mtr_cfg_check(struct rte_table_action_mtr_config *mtr)
return 0;
}
-#define MBUF_SCHED_QUEUE_TC_COLOR(queue, tc, color) \
- ((uint16_t)((((uint64_t)(queue)) & 0x3) | \
- ((((uint64_t)(tc)) & 0x3) << 2) | \
- ((((uint64_t)(color)) & 0x3) << 4)))
-
-#define MBUF_SCHED_COLOR(sched, color) \
- (((sched) & (~0x30LLU)) | ((color) << 4))
-
struct mtr_trtcm_data {
struct rte_meter_trtcm trtcm;
uint64_t stats[e_RTE_METER_COLORS];
@@ -176,7 +168,7 @@ mtr_data_size(struct rte_table_action_mtr_config *mtr)
struct dscp_table_entry_data {
enum rte_meter_color color;
uint16_t tc;
- uint16_t queue_tc_color;
+ uint16_t tc_queue;
};
struct dscp_table_data {
@@ -319,8 +311,7 @@ pkt_work_mtr(struct rte_mbuf *mbuf,
uint32_t dscp,
uint16_t total_length)
{
- uint64_t drop_mask, sched;
- uint64_t *sched_ptr = (uint64_t *) &mbuf->hash.sched;
+ 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;
uint32_t tc, mp_id;
@@ -329,7 +320,6 @@ pkt_work_mtr(struct rte_mbuf *mbuf,
color_in = dscp_entry->color;
data += tc;
mp_id = MTR_TRTCM_DATA_METER_PROFILE_ID_GET(data);
- sched = *sched_ptr;
/* Meter */
color_meter = rte_meter_trtcm_color_aware_check(
@@ -346,7 +336,7 @@ pkt_work_mtr(struct rte_mbuf *mbuf,
drop_mask = MTR_TRTCM_DATA_POLICER_ACTION_DROP_GET(data, color_meter);
color_policer =
MTR_TRTCM_DATA_POLICER_ACTION_COLOR_GET(data, color_meter);
- *sched_ptr = MBUF_SCHED_COLOR(sched, color_policer);
+ rte_mbuf_sched_color_set(mbuf, (uint8_t)color_policer);
return drop_mask;
}
@@ -368,9 +358,8 @@ tm_cfg_check(struct rte_table_action_tm_config *tm)
}
struct tm_data {
- uint16_t queue_tc_color;
- uint16_t subport;
- uint32_t pipe;
+ uint32_t queue_id;
+ uint32_t reserved;
} __attribute__((__packed__));
static int
@@ -397,9 +386,9 @@ tm_apply(struct tm_data *data,
return status;
/* Apply */
- data->queue_tc_color = 0;
- data->subport = (uint16_t) p->subport_id;
- data->pipe = p->pipe_id;
+ data->queue_id = p->subport_id <<
+ (__builtin_ctz(cfg->n_pipes_per_subport) + 4) |
+ p->pipe_id << 4;
return 0;
}
@@ -411,12 +400,11 @@ pkt_work_tm(struct rte_mbuf *mbuf,
uint32_t dscp)
{
struct dscp_table_entry_data *dscp_entry = &dscp_table->entry[dscp];
- struct tm_data *sched_ptr = (struct tm_data *) &mbuf->hash.sched;
- struct tm_data sched;
-
- sched = *data;
- sched.queue_tc_color = dscp_entry->queue_tc_color;
- *sched_ptr = sched;
+ uint32_t queue_id = data->queue_id |
+ (dscp_entry->tc << 2) |
+ dscp_entry->tc_queue;
+ rte_mbuf_sched_set(mbuf, queue_id, dscp_entry->tc,
+ (uint8_t)dscp_entry->color);
}
/**
@@ -2580,17 +2568,13 @@ rte_table_action_dscp_table_update(struct rte_table_action *action,
&action->dscp_table.entry[i];
struct rte_table_action_dscp_table_entry *entry =
&table->entry[i];
- uint16_t queue_tc_color =
- MBUF_SCHED_QUEUE_TC_COLOR(entry->tc_queue_id,
- entry->tc_id,
- entry->color);
if ((dscp_mask & (1LLU << i)) == 0)
continue;
data->color = entry->color;
data->tc = entry->tc_id;
- data->queue_tc_color = queue_tc_color;
+ data->tc_queue = entry->tc_queue_id;
}
return 0;
diff --git a/lib/librte_sched/Makefile b/lib/librte_sched/Makefile
index 46c53ed71..644fd9d15 100644
--- a/lib/librte_sched/Makefile
+++ b/lib/librte_sched/Makefile
@@ -18,7 +18,7 @@ LDLIBS += -lrte_timer
EXPORT_MAP := rte_sched_version.map
-LIBABIVER := 1
+LIBABIVER := 2
#
# all source are stored in SRCS-y
diff --git a/lib/librte_sched/meson.build b/lib/librte_sched/meson.build
index f85d64df8..8e989e5f6 100644
--- a/lib/librte_sched/meson.build
+++ b/lib/librte_sched/meson.build
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Intel Corporation
+version = 2
sources = files('rte_sched.c', 'rte_red.c', 'rte_approx.c')
headers = files('rte_sched.h', 'rte_sched_common.h',
'rte_red.h', 'rte_approx.h')
diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
index 587d5e602..dd7739172 100644
--- a/lib/librte_sched/rte_sched.c
+++ b/lib/librte_sched/rte_sched.c
@@ -128,22 +128,6 @@ enum grinder_state {
e_GRINDER_READ_MBUF
};
-/*
- * Path through the scheduler hierarchy used by the scheduler enqueue
- * operation to identify the destination queue for the current
- * packet. Stored in the field pkt.hash.sched of struct rte_mbuf of
- * each packet, typically written by the classification stage and read
- * by scheduler enqueue.
- */
-struct rte_sched_port_hierarchy {
- uint16_t queue:2; /**< Queue ID (0 .. 3) */
- uint16_t traffic_class:2; /**< Traffic class ID (0 .. 3)*/
- uint32_t color:2; /**< Color */
- uint16_t unused:10;
- uint16_t subport; /**< Subport ID */
- uint32_t pipe; /**< Pipe ID */
-};
-
struct rte_sched_grinder {
/* Pipe cache */
uint16_t pcache_qmask[RTE_SCHED_GRINDER_PCACHE_SIZE];
@@ -185,6 +169,7 @@ struct rte_sched_port {
/* User parameters */
uint32_t n_subports_per_port;
uint32_t n_pipes_per_subport;
+ uint32_t n_pipes_per_subport_log2;
uint32_t rate;
uint32_t mtu;
uint32_t frame_overhead;
@@ -645,6 +630,8 @@ rte_sched_port_config(struct rte_sched_port_params *params)
/* User parameters */
port->n_subports_per_port = params->n_subports_per_port;
port->n_pipes_per_subport = params->n_pipes_per_subport;
+ port->n_pipes_per_subport_log2 =
+ __builtin_ctz(params->n_pipes_per_subport);
port->rate = params->rate;
port->mtu = params->mtu + params->frame_overhead;
port->frame_overhead = params->frame_overhead;
@@ -1006,44 +993,52 @@ rte_sched_port_pipe_profile_add(struct rte_sched_port *port,
return 0;
}
+static inline uint32_t
+rte_sched_port_qindex(struct rte_sched_port *port,
+ uint32_t subport,
+ uint32_t pipe,
+ uint32_t traffic_class,
+ uint32_t queue)
+{
+ return ((subport & (port->n_subports_per_port - 1)) <<
+ (port->n_pipes_per_subport_log2 + 4)) |
+ ((pipe & (port->n_pipes_per_subport - 1)) << 4) |
+ ((traffic_class &
+ (RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE - 1)) << 2) |
+ (queue & (RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS - 1));
+}
+
void
-rte_sched_port_pkt_write(struct rte_mbuf *pkt,
- uint32_t subport, uint32_t pipe, uint32_t traffic_class,
+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)
{
- struct rte_sched_port_hierarchy *sched
- = (struct rte_sched_port_hierarchy *) &pkt->hash.sched;
-
- RTE_BUILD_BUG_ON(sizeof(*sched) > sizeof(pkt->hash.sched));
-
- sched->color = (uint32_t) color;
- sched->subport = subport;
- sched->pipe = pipe;
- sched->traffic_class = traffic_class;
- sched->queue = queue;
+ uint32_t queue_id = rte_sched_port_qindex(port, subport, pipe,
+ traffic_class, queue);
+ rte_mbuf_sched_set(pkt, queue_id, traffic_class, (uint8_t)color);
}
void
-rte_sched_port_pkt_read_tree_path(const struct rte_mbuf *pkt,
+rte_sched_port_pkt_read_tree_path(struct rte_sched_port *port,
+ const struct rte_mbuf *pkt,
uint32_t *subport, uint32_t *pipe,
uint32_t *traffic_class, uint32_t *queue)
{
- const struct rte_sched_port_hierarchy *sched
- = (const struct rte_sched_port_hierarchy *) &pkt->hash.sched;
+ uint32_t queue_id = rte_mbuf_sched_queue_get(pkt);
- *subport = sched->subport;
- *pipe = sched->pipe;
- *traffic_class = sched->traffic_class;
- *queue = sched->queue;
+ *subport = queue_id >> (port->n_pipes_per_subport_log2 + 4);
+ *pipe = (queue_id >> 4) & (port->n_pipes_per_subport - 1);
+ *traffic_class = (queue_id >> 2) &
+ (RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE - 1);
+ *queue = queue_id & (RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS - 1);
}
enum rte_meter_color
rte_sched_port_pkt_read_color(const struct rte_mbuf *pkt)
{
- const struct rte_sched_port_hierarchy *sched
- = (const struct rte_sched_port_hierarchy *) &pkt->hash.sched;
-
- return (enum rte_meter_color) sched->color;
+ return (enum rte_meter_color)rte_mbuf_sched_color_get(pkt);
}
int
@@ -1100,18 +1095,6 @@ rte_sched_queue_read_stats(struct rte_sched_port *port,
return 0;
}
-static inline uint32_t
-rte_sched_port_qindex(struct rte_sched_port *port, uint32_t subport, uint32_t pipe, uint32_t traffic_class, uint32_t queue)
-{
- uint32_t result;
-
- result = subport * port->n_pipes_per_subport + pipe;
- result = result * RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE + traffic_class;
- result = result * RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS + queue;
-
- return result;
-}
-
#ifdef RTE_SCHED_DEBUG
static inline int
@@ -1272,11 +1255,8 @@ rte_sched_port_enqueue_qptrs_prefetch0(struct rte_sched_port *port,
#ifdef RTE_SCHED_COLLECT_STATS
struct rte_sched_queue_extra *qe;
#endif
- uint32_t subport, pipe, traffic_class, queue, qindex;
-
- rte_sched_port_pkt_read_tree_path(pkt, &subport, &pipe, &traffic_class, &queue);
+ uint32_t qindex = rte_mbuf_sched_queue_get(pkt);
- qindex = rte_sched_port_qindex(port, subport, pipe, traffic_class, queue);
q = port->queue + qindex;
rte_prefetch0(q);
#ifdef RTE_SCHED_COLLECT_STATS
diff --git a/lib/librte_sched/rte_sched.h b/lib/librte_sched/rte_sched.h
index 84fa896de..243efa1d4 100644
--- a/lib/librte_sched/rte_sched.h
+++ b/lib/librte_sched/rte_sched.h
@@ -355,6 +355,8 @@ rte_sched_queue_read_stats(struct rte_sched_port *port,
* Scheduler hierarchy path write to packet descriptor. Typically
* called by the packet classification stage.
*
+ * @param port
+ * Handle to port scheduler instance
* @param pkt
* Packet descriptor handle
* @param subport
@@ -369,7 +371,8 @@ rte_sched_queue_read_stats(struct rte_sched_port *port,
* Packet color set
*/
void
-rte_sched_port_pkt_write(struct rte_mbuf *pkt,
+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);
@@ -379,6 +382,8 @@ rte_sched_port_pkt_write(struct rte_mbuf *pkt,
* enqueue operation. The subport, pipe, traffic class and queue
* parameters need to be pre-allocated by the caller.
*
+ * @param port
+ * Handle to port scheduler instance
* @param pkt
* Packet descriptor handle
* @param subport
@@ -392,7 +397,8 @@ rte_sched_port_pkt_write(struct rte_mbuf *pkt,
*
*/
void
-rte_sched_port_pkt_read_tree_path(const struct rte_mbuf *pkt,
+rte_sched_port_pkt_read_tree_path(struct rte_sched_port *port,
+ const struct rte_mbuf *pkt,
uint32_t *subport, uint32_t *pipe,
uint32_t *traffic_class, uint32_t *queue);
diff --git a/test/test/test_sched.c b/test/test/test_sched.c
index 32e500ba9..40e411cab 100644
--- a/test/test/test_sched.c
+++ b/test/test/test_sched.c
@@ -76,7 +76,7 @@ create_mempool(void)
}
static void
-prepare_pkt(struct rte_mbuf *mbuf)
+prepare_pkt(struct rte_sched_port *port, struct rte_mbuf *mbuf)
{
struct ether_hdr *eth_hdr;
struct vlan_hdr *vlan1, *vlan2;
@@ -95,7 +95,8 @@ prepare_pkt(struct rte_mbuf *mbuf)
ip_hdr->dst_addr = IPv4(0,0,TC,QUEUE);
- rte_sched_port_pkt_write(mbuf, SUBPORT, PIPE, TC, QUEUE, e_RTE_METER_YELLOW);
+ rte_sched_port_pkt_write(port, mbuf, SUBPORT, PIPE, TC, QUEUE,
+ e_RTE_METER_YELLOW);
/* 64 byte packet */
mbuf->pkt_len = 60;
@@ -138,7 +139,7 @@ test_sched(void)
for (i = 0; i < 10; i++) {
in_mbufs[i] = rte_pktmbuf_alloc(mp);
TEST_ASSERT_NOT_NULL(in_mbufs[i], "Packet allocation failed\n");
- prepare_pkt(in_mbufs[i]);
+ prepare_pkt(port, in_mbufs[i]);
}
@@ -155,7 +156,7 @@ test_sched(void)
color = rte_sched_port_pkt_read_color(out_mbufs[i]);
TEST_ASSERT_EQUAL(color, e_RTE_METER_YELLOW, "Wrong color\n");
- rte_sched_port_pkt_read_tree_path(out_mbufs[i],
+ rte_sched_port_pkt_read_tree_path(port, out_mbufs[i],
&subport, &pipe, &traffic_class, &queue);
TEST_ASSERT_EQUAL(subport, SUBPORT, "Wrong subport\n");
--
2.17.1
^ permalink raw reply [relevance 1%]
* [dpdk-dev] [PATCH v2 1/4] bitmap: remove deprecated bsf64 function
@ 2018-12-20 12:09 4% ` Anatoly Burakov
2018-12-20 12:09 4% ` [dpdk-dev] [PATCH v2 2/4] common: add bsf64 and bsf32_safe functions Anatoly Burakov
1 sibling, 0 replies; 200+ results
From: Anatoly Burakov @ 2018-12-20 12:09 UTC (permalink / raw)
To: dev
Cc: Neil Horman, John McNamara, Marko Kovacevic, Cristian Dumitrescu,
jerin.jacob, thomas
The function rte_bsf64 was deprecated in a previous release, so
remove the function, and the deprecation notice associated with
it.
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 5 -----
doc/guides/rel_notes/release_19_02.rst | 4 ++++
lib/librte_eal/common/include/rte_bitmap.h | 6 ------
3 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index ac7fb29a7..61d94c7de 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -20,11 +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: 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
- will be added in the next release in ``rte_common.h`` that follows convention
- set by existing ``rte_bsf32`` function.
-
* 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_02.rst b/doc/guides/rel_notes/release_19_02.rst
index 069f429a7..c4cce4c98 100644
--- a/doc/guides/rel_notes/release_19_02.rst
+++ b/doc/guides/rel_notes/release_19_02.rst
@@ -99,6 +99,10 @@ API Changes
since 18.05 and are removed in this release.
+* eal: function ``rte_bsf64`` in ``rte_bitmap.h`` has been renamed to
+ ``rte_bsf64_safe`` and moved to ``rte_common.h``.
+
+
ABI Changes
-----------
diff --git a/lib/librte_eal/common/include/rte_bitmap.h b/lib/librte_eal/common/include/rte_bitmap.h
index 77727c828..6b846f251 100644
--- a/lib/librte_eal/common/include/rte_bitmap.h
+++ b/lib/librte_eal/common/include/rte_bitmap.h
@@ -93,12 +93,6 @@ __rte_bitmap_index2_set(struct rte_bitmap *bmp)
bmp->index2 = (((bmp->index1 << RTE_BITMAP_SLAB_BIT_SIZE_LOG2) + bmp->offset1) << RTE_BITMAP_CL_SLAB_SIZE_LOG2);
}
-static inline int __rte_deprecated
-rte_bsf64(uint64_t slab, uint32_t *pos)
-{
- return rte_bsf64_safe(slab, pos);
-}
-
static inline uint32_t
__rte_bitmap_get_memory_footprint(uint32_t n_bits,
uint32_t *array1_byte_offset, uint32_t *array1_slabs,
--
2.17.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v2 2/4] common: add bsf64 and bsf32_safe functions
2018-12-20 12:09 4% ` [dpdk-dev] [PATCH v2 1/4] " Anatoly Burakov
@ 2018-12-20 12:09 4% ` Anatoly Burakov
1 sibling, 0 replies; 200+ results
From: Anatoly Burakov @ 2018-12-20 12:09 UTC (permalink / raw)
To: dev; +Cc: John McNamara, Marko Kovacevic, jerin.jacob, thomas
Add an rte_bsf64 function that follows the convention of existing
rte_bsf32 function. Also, add missing implementation for safe
version of rte_bsf32, and implement unit tests for all recently
added bsf varieties.
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
---
doc/guides/rel_notes/release_19_02.rst | 4 +-
lib/librte_eal/common/include/rte_common.h | 43 +++++++++++++++++++++-
test/test/test_common.c | 41 ++++++++++++++++++++-
3 files changed, 84 insertions(+), 4 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_02.rst b/doc/guides/rel_notes/release_19_02.rst
index c4cce4c98..0f446ed74 100644
--- a/doc/guides/rel_notes/release_19_02.rst
+++ b/doc/guides/rel_notes/release_19_02.rst
@@ -100,7 +100,9 @@ API Changes
* eal: function ``rte_bsf64`` in ``rte_bitmap.h`` has been renamed to
- ``rte_bsf64_safe`` and moved to ``rte_common.h``.
+ ``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.
ABI Changes
diff --git a/lib/librte_eal/common/include/rte_common.h b/lib/librte_eal/common/include/rte_common.h
index 66cdf60b2..d102f2cec 100644
--- a/lib/librte_eal/common/include/rte_common.h
+++ b/lib/librte_eal/common/include/rte_common.h
@@ -447,6 +447,30 @@ rte_bsf32(uint32_t v)
return (uint32_t)__builtin_ctz(v);
}
+/**
+ * Searches the input parameter for the least significant set bit
+ * (starting from zero). Safe version (checks for input parameter being zero).
+ *
+ * @warning ``pos`` must be a valid pointer. It is not checked!
+ *
+ * @param v
+ * The input parameter.
+ * @param pos
+ * If ``v`` was not 0, this value will contain position of least significant
+ * bit within the input parameter.
+ * @return
+ * Returns 0 if ``v`` was 0, otherwise returns 1.
+ */
+static inline int
+rte_bsf32_safe(uint64_t v, uint32_t *pos)
+{
+ if (v == 0)
+ return 0;
+
+ *pos = rte_bsf32(v);
+ return 1;
+}
+
/**
* Return the rounded-up log2 of a integer.
*
@@ -482,6 +506,23 @@ rte_fls_u32(uint32_t x)
return (x == 0) ? 0 : 32 - __builtin_clz(x);
}
+/**
+ * Searches the input parameter for the least significant set bit
+ * (starting from zero).
+ * If a least significant 1 bit is found, its bit index is returned.
+ * If the content of the input parameter is zero, then the content of the return
+ * value is undefined.
+ * @param v
+ * input parameter, should not be zero.
+ * @return
+ * least significant set bit in the input parameter.
+ */
+static inline int
+rte_bsf64(uint64_t v)
+{
+ return (uint32_t)__builtin_ctzll(v);
+}
+
/**
* Searches the input parameter for the least significant set bit
* (starting from zero). Safe version (checks for input parameter being zero).
@@ -502,7 +543,7 @@ rte_bsf64_safe(uint64_t v, uint32_t *pos)
if (v == 0)
return 0;
- *pos = __builtin_ctzll(v);
+ *pos = rte_bsf64(v);
return 1;
}
diff --git a/test/test/test_common.c b/test/test/test_common.c
index c6d17baae..4a42aaed8 100644
--- a/test/test/test_common.c
+++ b/test/test/test_common.c
@@ -50,12 +50,48 @@ test_macros(int __rte_unused unused_parm)
return 0;
}
+static int
+test_bsf(void)
+{
+ uint32_t shift, pos;
+
+ /* safe versions should be able to handle 0 */
+ if (rte_bsf32_safe(0, &pos) != 0)
+ FAIL("rte_bsf32_safe");
+ if (rte_bsf64_safe(0, &pos) != 0)
+ FAIL("rte_bsf64_safe");
+
+ for (shift = 0; shift < 63; shift++) {
+ uint32_t val32;
+ uint64_t val64;
+
+ val64 = 1ULL << shift;
+ if ((uint32_t)rte_bsf64(val64) != shift)
+ FAIL("rte_bsf64");
+ if (rte_bsf64_safe(val64, &pos) != 1)
+ FAIL("rte_bsf64_safe");
+ if (pos != shift)
+ FAIL("rte_bsf64_safe");
+
+ if (shift > 31)
+ continue;
+
+ val32 = 1U << shift;
+ if ((uint32_t)rte_bsf32(val32) != shift)
+ FAIL("rte_bsf32");
+ if (rte_bsf32_safe(val32, &pos) != 1)
+ FAIL("rte_bsf32_safe");
+ if (pos != shift)
+ FAIL("rte_bsf32_safe");
+ }
+
+ return 0;
+}
+
static int
test_misc(void)
{
char memdump[] = "memdump_test";
- if (rte_bsf32(129))
- FAIL("rte_bsf32");
rte_memdump(stdout, "test", memdump, sizeof(memdump));
rte_hexdump(stdout, "test", memdump, sizeof(memdump));
@@ -226,6 +262,7 @@ test_common(void)
ret |= test_align();
ret |= test_macros(0);
ret |= test_misc();
+ ret |= test_bsf();
ret |= test_log2();
ret |= test_fls();
--
2.17.1
^ permalink raw reply [relevance 4%]
Results 8801-9000 of ~18000 next (older) | prev (newer) | 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 3% ` Ferruh Yigit
2018-12-20 23:48 0% ` Stephen Hemminger
2018-12-21 14:38 0% ` Wiles, Keith
2018-12-21 15:14 0% ` Ferruh Yigit
2018-12-27 9:35 0% ` 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-11-01 4:54 [dpdk-dev] [PATCH 1/3] hash: deprecate lock ellision and read/write concurreny flags Honnappa Nagarahalli
2018-11-01 23:25 ` [dpdk-dev] [PATCH v2 0/4] " Honnappa Nagarahalli
2018-11-02 11:25 ` Bruce Richardson
2018-11-02 17:38 ` Honnappa Nagarahalli
2018-12-20 20:10 0% ` Yigit, Ferruh
2018-11-29 5:54 [dpdk-dev] [PATCH] ethdev: support double precision RED queue weight Nikhil Rao
2018-11-29 6:12 ` Stephen Hemminger
2018-12-10 5:43 ` Rao, Nikhil
2018-12-10 16:01 ` Stephen Hemminger
2019-01-10 6:23 0% ` Rao, Nikhil
2018-12-04 12:22 [dpdk-dev] [PATCH 18.11] malloc: fix deadlock when using malloc stats Anatoly Burakov
2018-12-21 12:09 0% ` Thomas Monjalon
2018-12-21 12:12 0% ` Burakov, Anatoly
2018-12-21 12:26 4% ` [dpdk-dev] [PATCH 19.02 v2] " Anatoly Burakov
2018-12-21 13:35 0% ` Thomas Monjalon
2018-12-06 15:38 [dpdk-dev] [PATCH v3 1/9] cryptodev: add opaque userdata pointer into crypto sym session Konstantin Ananyev
2018-12-14 16:29 ` [dpdk-dev] [PATCH v4 00/10] ipsec: new library for IPsec data-path processing Konstantin Ananyev
2018-12-21 13:32 0% ` Akhil Goyal
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-11 10:34 [dpdk-dev] [PATCH v2 0/2] lib/cryptodev: change qp conf and sym session Fan Zhang
2018-12-21 13:55 ` [dpdk-dev] [PATCH v3 0/2] cryptodev: " Fan Zhang
2018-12-21 13:55 1% ` [dpdk-dev] [PATCH v3 1/2] cryptodev: change queue pair configure structure Fan Zhang
2019-01-08 23:20 3% ` De Lara Guarch, Pablo
2019-01-09 11:30 0% ` Zhang, Roy Fan
2018-12-21 13:55 1% ` [dpdk-dev] [PATCH v3 2/2] cryptodev: change symmetric session structure Fan Zhang
2019-01-09 22:55 ` [dpdk-dev] [PATCH v4 00/12] cryptodev: change qp conf and sym session Fan Zhang
2019-01-09 22:55 3% ` [dpdk-dev] [PATCH v4 01/12] cryptodev: change queue pair configure structure Fan Zhang
2019-01-10 9:47 3% ` De Lara Guarch, Pablo
2019-01-10 11:24 0% ` De Lara Guarch, Pablo
2019-01-09 22:55 3% ` [dpdk-dev] [PATCH v4 02/12] cryptodev: add sym session mempool create Fan Zhang
2019-01-10 11:22 0% ` De Lara Guarch, Pablo
2019-01-09 22:56 3% ` [dpdk-dev] [PATCH v4 08/12] cryptodev: add sym session header size API Fan Zhang
2019-01-09 22:56 1% ` [dpdk-dev] [PATCH v4 09/12] cryptodev: update symmetric session structure Fan Zhang
2019-01-10 14:50 ` [dpdk-dev] [PATCH v5 00/12] cryptodev: change qp conf and sym session Fan Zhang
2019-01-10 14:50 3% ` [dpdk-dev] [PATCH v5 01/12] cryptodev: change queue pair configure structure Fan Zhang
2019-01-10 14:50 3% ` [dpdk-dev] [PATCH v5 02/12] cryptodev: add sym session mempool create Fan Zhang
2019-01-10 14:50 5% ` [dpdk-dev] [PATCH v5 09/12] cryptodev: update symmetric session structure Fan Zhang
2018-12-11 17:57 [dpdk-dev] [PATCH 1/6] bitmap: remove deprecated bsf64 function Anatoly Burakov
2018-12-20 12:09 4% ` [dpdk-dev] [PATCH v2 1/4] " Anatoly Burakov
2018-12-20 12:09 4% ` [dpdk-dev] [PATCH v2 2/4] common: add bsf64 and bsf32_safe functions Anatoly Burakov
2018-12-14 11:13 [dpdk-dev] [PATCH v2] libs/power: add p-state driver compatibility Liang Ma
2018-12-19 3:18 ` [dpdk-dev] [PATCH v3] " Thomas Monjalon
2018-12-19 9:09 ` Hunt, David
2018-12-19 20:31 ` Thomas Monjalon
2018-12-20 14:52 0% ` Hunt, David
2018-12-21 0:30 0% ` Thomas Monjalon
2018-12-21 0:33 0% ` Thomas Monjalon
2018-12-14 13:11 Liang Ma
2018-12-20 14:43 1% ` [dpdk-dev] [PATCH v4] " Liang Ma
2018-12-21 0:34 0% ` Thomas Monjalon
2018-12-14 16:23 [dpdk-dev] [PATCH v4 01/10] cryptodev: add opaque userdata pointer into crypto sym session Konstantin Ananyev
2018-12-28 15:17 2% ` [dpdk-dev] [PATCH v5 00/10] ipsec: new library for IPsec data-path processing Konstantin Ananyev
2018-12-19 12:52 [dpdk-dev] [RFC 1/2] doc: clean ABI/API policy guide Ferruh Yigit
2018-12-21 15:57 35% ` [dpdk-dev] [PATCH v2 " Ferruh Yigit
2019-01-22 16:23 35% ` [dpdk-dev] [PATCH v3 1/3] " Ferruh Yigit
2019-01-22 16:23 17% ` [dpdk-dev] [PATCH v3 2/3] doc: make RTE_NEXT_ABI optional Ferruh Yigit
2019-01-23 8:13 4% ` [dpdk-dev] [PATCH v3 1/3] doc: clean ABI/API policy guide Neil Horman
2019-01-24 18:10 35% ` [dpdk-dev] [PATCH v4 " Ferruh Yigit
2019-01-24 18:10 17% ` [dpdk-dev] [PATCH v4 2/3] doc: make RTE_NEXT_ABI optional Ferruh Yigit
2019-01-31 17:46 4% ` [dpdk-dev] [PATCH v4 1/3] doc: clean ABI/API policy guide 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
2018-12-19 15:42 [dpdk-dev] [PATCH v6 1/2] meter: add new rte color definition Reshma Pattan
2018-12-20 12:16 ` [dpdk-dev] [PATCH v7 " Reshma Pattan
2018-12-20 12:16 1% ` [dpdk-dev] [PATCH v7 2/2] mbuf: implement generic format for sched field Reshma Pattan
2018-12-20 14:55 0% ` Rao, Nikhil
2019-01-15 22:37 3% ` Stephen Hemminger
2019-01-16 9:19 0% ` Pattan, Reshma
2019-01-16 9:33 0% ` Dumitrescu, Cristian
2019-01-16 10:09 0% ` Singh, Jasvinder
2019-01-15 23:11 4% ` Stephen Hemminger
2019-01-16 8:41 0% ` Thomas Monjalon
2018-12-23 9:58 [dpdk-dev] [PATCH] net/mlx5: modify-header support using Direct Verbs Dekel Peled
2018-12-25 11:38 3% ` Shahaf Shuler
2018-12-25 16:00 0% ` Dekel Peled
2018-12-27 4:13 [dpdk-dev] [PATCH v3 0/6] spinlock optimization and test case enhancements Gavin Hu
2018-12-27 4:13 ` [dpdk-dev] [PATCH v3 5/6] spinlock: reimplement with atomic one-way barrier builtins Gavin Hu
2018-12-27 7:42 ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
2019-01-11 13:52 ` Gavin Hu (Arm Technology China)
2019-01-14 5:54 3% ` Honnappa Nagarahalli
2019-01-14 7:39 0% ` Jerin Jacob Kollanukkaran
2019-01-14 17:08 0% ` Gavin Hu (Arm Technology China)
2019-01-14 7:57 0% ` Gavin Hu (Arm Technology China)
2018-12-28 15:17 [dpdk-dev] [PATCH v5 01/10] cryptodev: add opaque userdata pointer into crypto sym session Konstantin Ananyev
2019-01-03 20:16 2% ` [dpdk-dev] [PATCH v6 00/10] ipsec: new library for IPsec data-path processing Konstantin Ananyev
2019-01-11 1:09 2% ` Xu, Yanjie
2019-01-03 20:16 ` [dpdk-dev] [PATCH v6 01/10] cryptodev: add opaque userdata pointer into crypto sym session Konstantin Ananyev
2019-01-04 0:25 3% ` Stephen Hemminger
2019-01-04 9:29 0% ` Ananyev, Konstantin
2019-01-09 23:41 4% ` Thomas Monjalon
2019-01-10 14:20 4% ` [dpdk-dev] [PATCH v7 00/10] ipsec: new library for IPsec data-path processing Konstantin Ananyev
2019-01-10 14:25 0% ` Thomas Monjalon
2019-01-10 14:40 0% ` De Lara Guarch, Pablo
2019-01-10 14:52 3% ` Ananyev, Konstantin
2019-01-10 14:54 0% ` Thomas Monjalon
2019-01-10 14:58 0% ` Ananyev, Konstantin
2019-01-10 15:00 0% ` Akhil Goyal
2019-01-10 15:09 0% ` Akhil Goyal
2019-01-10 14:51 0% ` Akhil Goyal
2019-01-10 14:20 5% ` [dpdk-dev] [PATCH v7 01/10] cryptodev: add opaque userdata pointer into crypto sym session Konstantin Ananyev
2019-01-10 21:06 4% ` [dpdk-dev] [PATCH v8 0/9] ipsec: new library for IPsec data-path processing Konstantin Ananyev
2019-01-10 21:06 5% ` [dpdk-dev] [PATCH v8 1/9] security: add opaque userdata pointer into security session Konstantin Ananyev
2019-01-10 14:20 9% ` [dpdk-dev] [PATCH v7 02/10] " Konstantin Ananyev
2019-01-10 11:11 [dpdk-dev] [PATCH] compat: merge compat library into EAL Bruce Richardson
2019-01-10 13:47 4% ` [dpdk-dev] [PATCH v2] " Bruce Richardson
2019-01-10 13:57 0% ` David Marchand
2019-01-10 14:01 0% ` 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 2% [dpdk-dev] [PATCH] eal: fix strdup usages in internal config Anatoly Burakov
2019-01-14 14:18 0% ` Thomas Monjalon
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-10 21:01 4% [dpdk-dev] [PATCH 0/6] Add non-blocking ring Gage Eads
2019-01-10 21:01 ` [dpdk-dev] [PATCH 1/6] ring: change head and tail to pointer-width size Gage Eads
2019-01-11 4:38 3% ` Stephen Hemminger
2019-01-11 19:07 3% ` Eads, Gage
2019-01-11 10:25 3% ` Burakov, Anatoly
2019-01-11 19:12 0% ` Eads, Gage
2019-01-11 19:55 3% ` Stephen Hemminger
2019-01-15 15:48 4% ` Eads, Gage
2019-01-11 10:40 ` Burakov, Anatoly
2019-01-11 10:58 ` Bruce Richardson
2019-01-11 11:30 ` Burakov, Anatoly
[not found] ` <20190111115851.GC3336@bricha3-MOBL.ger.corp.intel.com>
2019-01-11 19:27 ` Eads, Gage
2019-01-21 14:14 ` Burakov, Anatoly
2019-01-22 18:27 3% ` Eads, Gage
2019-01-15 23:52 3% ` [dpdk-dev] [PATCH v2 0/5] Add non-blocking ring Gage Eads
2019-01-16 0:26 3% ` Stephen Hemminger
2019-01-18 15:23 3% ` [dpdk-dev] [PATCH v3 " Gage Eads
2019-01-18 15:23 2% ` [dpdk-dev] [PATCH v3 1/5] ring: add 64-bit headtail structure Gage Eads
2019-01-22 9:27 0% ` [dpdk-dev] [PATCH v3 0/5] Add non-blocking ring Ola Liljedahl
2019-01-22 10:15 0% ` Ola Liljedahl
2019-01-22 19:15 0% ` Eads, Gage
2019-01-23 16:02 0% ` Jerin Jacob Kollanukkaran
2019-01-23 16:29 0% ` 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-01-14 5:20 4% [dpdk-dev] [PATCH 1/2] mbuf: remove deprecated macro Yongseok Koh
2019-01-15 23:59 7% [dpdk-dev] [PATCH] doc: announce ring ABI and API changes Gage Eads
2019-01-16 0:34 7% ` Stephen Hemminger
2019-01-16 18:21 8% ` Eads, Gage
2019-01-18 15:28 3% ` [dpdk-dev] [PATCH v2] doc: announce ring API change Gage Eads
2019-01-18 15:31 3% ` [dpdk-dev] [PATCH v3] " Gage Eads
2019-02-01 14:36 3% ` [dpdk-dev] [PATCH v4] " Gage Eads
2019-01-16 9:55 3% [dpdk-dev] DPDK techboard minutes of January 2 Thomas Monjalon
2019-01-16 11:45 5% [dpdk-dev] [PATCH] doc: increase minimal supported Linux version Thomas Monjalon
2019-01-17 9:39 4% [dpdk-dev] [PATCH] doc: announce ABI change for cryptodev config Anoob Joseph
2019-01-17 11:37 4% ` Trahe, Fiona
2019-01-17 13:47 4% ` Anoob Joseph
2019-01-18 6:59 4% ` Shally Verma
2019-01-22 9:31 4% ` 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-01-19 14:01 3% [dpdk-dev] [PATCH] service: fix parameter type Nikhil Rao
2019-01-21 11:43 3% ` 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
[not found] <mailman.14255.1548076743.7586.dev@dpdk.org>
2019-01-21 13:23 0% ` [dpdk-dev] dev Digest, Vol 231, Issue 6 Anudeep Kumar
2019-01-23 22:07 4% [dpdk-dev] [PATCH] Introduce travis builds for github repositories Michael Santana
2019-01-24 19:26 0% ` 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-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-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-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-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-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
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).