* [dpdk-dev] [PATCH] malloc: deprecate unused set limit
@ 2019-06-26 22:32 4% Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-06-26 22:32 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
The function rte_malloc_set_limit was defined but never implemented.
Mark it as deprecated for now, and remove in next release.
There is no point in keeping dead code.
"You Aren't Going to Need It"
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
app/test/test_malloc.c | 21 ---------------------
doc/guides/rel_notes/release_19_08.rst | 3 +++
lib/librte_eal/common/include/rte_malloc.h | 2 +-
3 files changed, 4 insertions(+), 22 deletions(-)
diff --git a/app/test/test_malloc.c b/app/test/test_malloc.c
index f0e608cdaf22..7243e8389472 100644
--- a/app/test/test_malloc.c
+++ b/app/test/test_malloc.c
@@ -372,18 +372,6 @@ test_multi_alloc_statistics(void)
return 0;
}
-static int
-test_rte_malloc_type_limits(void)
-{
- /* The type-limits functionality is not yet implemented,
- * so always return 0 no matter what the retval.
- */
- const char *typename = "limit_test";
- rte_malloc_set_limit(typename, 64 * 1024);
- rte_malloc_dump_stats(stdout, typename);
- return 0;
-}
-
static int
test_realloc(void)
{
@@ -952,15 +940,6 @@ test_malloc(void)
}
else printf("test_random_alloc_free() passed\n");
- /*----------------------------*/
- ret = test_rte_malloc_type_limits();
- if (ret < 0){
- printf("test_rte_malloc_type_limits() failed\n");
- return ret;
- }
- /* TODO: uncomment following line once type limits are valid */
- /*else printf("test_rte_malloc_type_limits() passed\n");*/
-
/*----------------------------*/
ret = test_rte_malloc_validate();
if (ret < 0){
diff --git a/doc/guides/rel_notes/release_19_08.rst b/doc/guides/rel_notes/release_19_08.rst
index 3da26670550d..0e79390e16a1 100644
--- a/doc/guides/rel_notes/release_19_08.rst
+++ b/doc/guides/rel_notes/release_19_08.rst
@@ -135,6 +135,9 @@ API Changes
* The network structures, definitions and functions have
been prefixed by ``rte_`` to resolve conflicts with libc headers.
+* malloc: The function ``rte_malloc_set_limit`` was never implemented
+ is deprecated and will be removed in a future release.
+
ABI Changes
-----------
diff --git a/lib/librte_eal/common/include/rte_malloc.h b/lib/librte_eal/common/include/rte_malloc.h
index 5ff1a39a2e78..924a08605998 100644
--- a/lib/librte_eal/common/include/rte_malloc.h
+++ b/lib/librte_eal/common/include/rte_malloc.h
@@ -526,7 +526,7 @@ rte_malloc_dump_heaps(FILE *f);
* - 0: Success.
* - (-1): Error.
*/
-int
+int __rte_deprecated
rte_malloc_set_limit(const char *type, size_t max);
/**
--
2.20.1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 00/39] adding eventmode helper library
@ 2019-06-27 5:28 0% ` Anoob Joseph
2019-06-28 3:37 0% ` Jerin Jacob Kollanukkaran
0 siblings, 1 reply; 200+ results
From: Anoob Joseph @ 2019-06-27 5:28 UTC (permalink / raw)
To: Jerin Jacob Kollanukkaran, Mattias Rönnblom, Nikhil Rao,
Erik Gabriel Carrillo, Abhinandan Gujjar, Bruce Richardson,
Pablo de Lara
Cc: Narayana Prasad Raju Athreya, dev, Lukas Bartosik,
Pavan Nikhilesh Bhagavatula, Hemant Agrawal, Nipun Gupta,
Harry van Haaren, Liang Ma
Hi Jerin, Mattias,
Please see inline.
Thanks,
Anoob
> -----Original Message-----
> From: Jerin Jacob Kollanukkaran
> Sent: Tuesday, June 25, 2019 4:03 PM
> To: Anoob Joseph <anoobj@marvell.com>; Mattias Rönnblom
> <mattias.ronnblom@ericsson.com>; Nikhil Rao <nikhil.rao@intel.com>; Erik
> Gabriel Carrillo <erik.g.carrillo@intel.com>; Abhinandan Gujjar
> <abhinandan.gujjar@intel.com>; Bruce Richardson
> <bruce.richardson@intel.com>; Pablo de Lara
> <pablo.de.lara.guarch@intel.com>
> Cc: Narayana Prasad Raju Athreya <pathreya@marvell.com>; dev@dpdk.org;
> Lukas Bartosik <lbartosik@marvell.com>; Pavan Nikhilesh Bhagavatula
> <pbhagavatula@marvell.com>; Hemant Agrawal
> <hemant.agrawal@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>; Harry
> van Haaren <harry.van.haaren@intel.com>; Liang Ma
> <liang.j.ma@intel.com>
> Subject: RE: [dpdk-dev] Re: [PATCH 00/39] adding eventmode helper library
>
> > -----Original Message-----
> > From: Anoob Joseph
> > Sent: Thursday, June 20, 2019 9:15 AM
> > To: Mattias Rönnblom <mattias.ronnblom@ericsson.com>; Jerin Jacob
> > Kollanukkaran <jerinj@marvell.com>; Nikhil Rao <nikhil.rao@intel.com>;
> > Erik Gabriel Carrillo <erik.g.carrillo@intel.com>; Abhinandan Gujjar
> > <abhinandan.gujjar@intel.com>; Bruce Richardson
> > <bruce.richardson@intel.com>; Pablo de Lara
> > <pablo.de.lara.guarch@intel.com>
> > Cc: Narayana Prasad Raju Athreya <pathreya@marvell.com>;
> dev@dpdk.org;
> > Lukas Bartosik <lbartosik@marvell.com>; Pavan Nikhilesh Bhagavatula
> > <pbhagavatula@marvell.com>; Hemant Agrawal
> <hemant.agrawal@nxp.com>;
> > Nipun Gupta <nipun.gupta@nxp.com>; Harry van Haaren
> > <harry.van.haaren@intel.com>; Liang Ma <liang.j.ma@intel.com>
> > Subject: RE: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode
> > helper library
> > > However, the flexibility and many of the parameters are there for a
> > > reason (those there aren't should be deprecated). I would expect a
> > > real-world application to tweak quite a few of them. I know our
> > > applications
> > do.
> > >
> > > I worry I have is that if you put eventmode (in its current form)
> > > forward as a generic framework, applications might start using it,
> > > only to realize it's not flexible enough, and then eventmode is just
> > > an extra layer, increasing rather than reducing complexity. Or even
> > > worse, the application's developers are forced to do a big-bang
> > > switch over to using the event and ethernet device APIs directly, in
> > > case they can't patch DPDK to work around the eventmode-
> > > assumption-that-
> > didn't-hold-for-them.
> > >
> > > You could always add flexibility to the framework (as you encounter
> > > a need for it), but then it will grow in complexity as well.
> > >
> > > A less ambitious approach would be to instead do a properly
> > > modularized, non-trivial eventdev example application, for the
> > > applications to start off from, instead of a generic library.
> > >
> > > I would expect it to be very difficult to design a truly generic
> > > application framework for eventdev-based applications. Such a
> > > framework would tie everything that's needed in a non-trivial
> > > application together. If successful, it would be a huge step toward
> > > making DPDK an operating system for packet processing applications.
> >
> > [Anoob] The idea here is not to deprecate any event dev APIs. I do
> > agree that all the configuration exposed by eventdev & adapters are
> > required for various requirements in the real world applications. But
> > the requirement to understand & use all this configuration is making
> > the applications complicated and causes significant effort from anyone who
> would want to get started with event mode.
> > The idea of helper is to allow an easy framework for applications to
> > get started with eventmode, and then use various options from C/L or
> > config file (both
> > planned) to override the configuration as required. DPDK has
> > components like crypto-scheduler which abstracts lot of configuration
> > and simplify usage from application's perspective. This effort is on similar
> lines.
> >
> > My patchset is a followup to http://patches.dpdk.org/patch/37955 ,
> > wherein the approach of introducing a helper library for event mode
> > was mooted. The initial patch proposed additions in one application,
> > and that involved huge code additions just for doing the configuration.
> >
> > The helper library will be experimental while we add event-mode
> > support for other applications like l3fwd & ipsec-secgw. I expect the
> > helper library to be complete over the course of those applications also
> using the helper library.
>
>
> I have only concern about moving this as library inside eventdev that till we
> have mature version of helper library the eventdev library ABI will not
> stable(i.e .so file version needs to be incremented as when a change
> needed). Which align with Mattias thoughts for some other reason:. How
> about moving this code to
> 1) example/common or
> 2) to specific application itself, once at least two applications starts using it
> then move to Eventdev library.
>
> Thoughts?
[Anoob] Either location is not a problem if there is a consensus. Earlier the suggestion was to move it to library (when the patch was submitted with changes added in app).
Since there are other comments, which are being addressed, I would like to send the next series with the current layout itself. And when we have an agreement on the location to be used, I'll make the changes. Is that fine?
>
>
>
>
> >
> > >
> > > What event devices have you tested with?
> >
> > [Anoob] Eventmode helper is tested with the following combinations,
> > 1. event-octeontx event PMD & nicvf eth PMD
> > 2. event-octeontx event PMD & eth-octeontx eth PMD
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 28/28] sched: add release note
@ 2019-06-27 10:50 0% ` Singh, Jasvinder
0 siblings, 0 replies; 200+ results
From: Singh, Jasvinder @ 2019-06-27 10:50 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev, Dumitrescu, Cristian, Krakowiak, LukaszX, Tovar, AbrahamX
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Wednesday, June 26, 2019 10:31 PM
> To: Singh, Jasvinder <jasvinder.singh@intel.com>
> Cc: dev@dpdk.org; Dumitrescu, Cristian <cristian.dumitrescu@intel.com>;
> Krakowiak, LukaszX <lukaszx.krakowiak@intel.com>; Tovar, AbrahamX
> <abrahamx.tovar@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v2 28/28] sched: add release note
>
> 25/06/2019 17:32, Jasvinder Singh:
> > --- a/doc/guides/rel_notes/release_19_08.rst
> > +++ b/doc/guides/rel_notes/release_19_08.rst
> > @@ -135,6 +135,11 @@ API Changes
> > +* sched: To allow more traffic classes, flexible mapping of pipe queues to
> > + traffic classes, and subport level configuration of pipes and queues
> > + changes are made to public macros, data structures and API functions
> defined
> > + in "rte_sched.h".
>
> Does it make sense to merge this text in a code patch?
Will merge this code patch.
> > --- a/lib/librte_sched/Makefile
> > +++ b/lib/librte_sched/Makefile
> > -LIBABIVER := 2
> > +LIBABIVER := 3
>
> Please merge this change in the first patch breaking the ABI.
>
Will do that.
Thanks,
Jasvinder
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3] ethdev: support QinQ strip dynamic configuration
@ 2019-06-27 11:08 3% ` Ferruh Yigit
2019-07-01 10:07 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2019-06-27 11:08 UTC (permalink / raw)
To: viveksharma, thomas, arybchenko
Cc: dev, intoviveksharma, stephen, ramirose, Jerin Jacob Kollanukkaran
On 4/19/2019 6:59 AM, viveksharma@marvell.com wrote:
> From: Vivek Sharma <viveksharma@marvell.com>
>
> Enable missing support for runtime configuration (setting/getting)
> of QinQ strip rx offload for a given ethdev.
>
> Signed-off-by: Vivek Sharma <viveksharma@marvell.com>
<...>
> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
> index 40a068f..c1792f4 100644
> --- a/lib/librte_ethdev/rte_ethdev.h
> +++ b/lib/librte_ethdev/rte_ethdev.h
> @@ -550,11 +550,13 @@ struct rte_eth_rss_conf {
> #define ETH_VLAN_STRIP_OFFLOAD 0x0001 /**< VLAN Strip On/Off */
> #define ETH_VLAN_FILTER_OFFLOAD 0x0002 /**< VLAN Filter On/Off */
> #define ETH_VLAN_EXTEND_OFFLOAD 0x0004 /**< VLAN Extend On/Off */
> +#define ETH_QINQ_STRIP_OFFLOAD 0x0008 /**< QINQ Strip On/Off */
>
> /* Definitions used for mask VLAN setting */
> #define ETH_VLAN_STRIP_MASK 0x0001 /**< VLAN Strip setting mask */
> #define ETH_VLAN_FILTER_MASK 0x0002 /**< VLAN Filter setting mask*/
> #define ETH_VLAN_EXTEND_MASK 0x0004 /**< VLAN Extend setting mask*/
> +#define ETH_QINQ_STRIP_MASK 0x0008 /**< QINQ Strip setting mask */
> #define ETH_VLAN_ID_MAX 0x0FFF /**< VLAN ID is in lower 12 bits*/
On its own patch looks ok but a few high level questions:
1- Why we need this interim defines, instead of using actual offload values?
Although changing this will be API/ABI breakage.
2- Why we have specific function to set vlan offloads, for other offloads the
way is stop device and reconfigure it with new offload flags.
3- If devices can change offload configuration dynamically, do we need a generic
API to alter the offload configs? (similar to these vlan APIs but more generic)?
Related to the patch, what do you think about following options:
a)
- Get this patch
- Send a deprecation notice for 1) in this release
- Next release remove these flags, which will be practically reverse this patch
and more
b)
- Send a deprecation notice for 1) in this release
- Next release update the APIs and a smaller/different version of this patch
will be required.
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v3 09/14] eal: hide shared memory config
@ 2019-06-27 11:39 8% ` Anatoly Burakov
2019-06-27 11:39 3% ` [dpdk-dev] [PATCH v3 14/14] eal: prevent different primary/secondary process versions Anatoly Burakov
1 sibling, 0 replies; 200+ results
From: Anatoly Burakov @ 2019-06-27 11:39 UTC (permalink / raw)
To: dev
Cc: Neil Horman, John McNamara, Marko Kovacevic, Konstantin Ananyev,
David Hunt, Bruce Richardson, Byron Marohn, Pablo de Lara Guarch,
Yipeng Wang, Sameh Gobriel, Vladimir Medvedkin, Olivier Matz,
Andrew Rybchenko, Reshma Pattan, david.marchand, thomas, stephen
Now that everything that has ever accessed the shared memory
config is doing so through the public API's, we can make it
internal. Since we're removing quite a few headers from
rte_eal_memconfig.h, we need to add them back in places
where this header is used.
This bumps the ABI, so also change all build files and make
update documentation.
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
---
app/test/test_memzone.c | 1 +
app/test/test_tailq.c | 1 +
doc/guides/rel_notes/deprecation.rst | 3 -
doc/guides/rel_notes/release_19_08.rst | 8 +-
drivers/bus/pci/linux/pci_vfio.c | 1 +
lib/librte_acl/rte_acl.c | 2 +
lib/librte_distributor/rte_distributor.c | 1 +
lib/librte_distributor/rte_distributor_v20.c | 1 +
lib/librte_eal/common/eal_common_mcfg.c | 2 +
lib/librte_eal/common/eal_common_memory.c | 1 +
lib/librte_eal/common/eal_common_memzone.c | 1 +
lib/librte_eal/common/eal_common_tailqs.c | 1 +
lib/librte_eal/common/eal_memcfg.h | 79 +++++++++++++++++++
.../common/include/rte_eal_memconfig.h | 75 ++----------------
lib/librte_eal/common/malloc_heap.c | 2 +
lib/librte_eal/common/malloc_mp.c | 1 +
lib/librte_eal/common/rte_malloc.c | 1 +
lib/librte_eal/freebsd/eal/Makefile | 2 +-
lib/librte_eal/freebsd/eal/eal_memory.c | 1 +
lib/librte_eal/linux/eal/Makefile | 2 +-
lib/librte_eal/linux/eal/eal.c | 1 +
lib/librte_eal/linux/eal/eal_memalloc.c | 1 +
lib/librte_eal/linux/eal/eal_memory.c | 1 +
lib/librte_eal/linux/eal/eal_vfio.c | 1 +
lib/librte_eal/meson.build | 2 +-
lib/librte_efd/rte_efd.c | 1 +
lib/librte_hash/rte_cuckoo_hash.c | 1 +
lib/librte_hash/rte_fbk_hash.c | 1 +
lib/librte_lpm/rte_lpm.c | 1 +
lib/librte_lpm/rte_lpm6.c | 1 +
lib/librte_member/rte_member.c | 1 +
lib/librte_mempool/rte_mempool.c | 1 +
lib/librte_reorder/rte_reorder.c | 1 +
lib/librte_ring/rte_ring.c | 1 +
34 files changed, 125 insertions(+), 76 deletions(-)
create mode 100644 lib/librte_eal/common/eal_memcfg.h
diff --git a/app/test/test_memzone.c b/app/test/test_memzone.c
index 9fe465e62..7501b63c5 100644
--- a/app/test/test_memzone.c
+++ b/app/test/test_memzone.c
@@ -19,6 +19,7 @@
#include <rte_errno.h>
#include <rte_malloc.h>
#include "../../lib/librte_eal/common/malloc_elem.h"
+#include "../../lib/librte_eal/common/eal_memcfg.h"
#include "test.h"
diff --git a/app/test/test_tailq.c b/app/test/test_tailq.c
index a4ecea2d8..7c9b69fdb 100644
--- a/app/test/test_tailq.c
+++ b/app/test/test_tailq.c
@@ -12,6 +12,7 @@
#include <rte_eal.h>
#include <rte_eal_memconfig.h>
#include <rte_string_fns.h>
+#include <rte_tailq.h>
#include "test.h"
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index e2721fad6..583217da8 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -23,9 +23,6 @@ Deprecation Notices
* eal: The function ``rte_eal_remote_launch`` will return new error codes
after read or write error on the pipe, instead of calling ``rte_panic``.
-* eal: the ``rte_mem_config`` struct will be made private to remove it from the
- externally visible ABI and allow it to be updated in the future.
-
* 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_08.rst b/doc/guides/rel_notes/release_19_08.rst
index 3da266705..b6314431a 100644
--- a/doc/guides/rel_notes/release_19_08.rst
+++ b/doc/guides/rel_notes/release_19_08.rst
@@ -132,6 +132,10 @@ API Changes
Also, make sure to start the actual text at the margin.
=========================================================
+* The ``rte_mem_config`` structure has been made private. The new accessor
+ ``rte_mcfg_*`` functions were introduced to provide replacement for direct
+ access to the shared mem config.
+
* The network structures, definitions and functions have
been prefixed by ``rte_`` to resolve conflicts with libc headers.
@@ -151,6 +155,8 @@ ABI Changes
Also, make sure to start the actual text at the margin.
=========================================================
+* The ``rte_mem_config`` structure has been made private.
+
Shared Library Versions
-----------------------
@@ -184,7 +190,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_compressdev.so.1
librte_cryptodev.so.7
librte_distributor.so.1
- librte_eal.so.10
+ + librte_eal.so.11
librte_efd.so.1
librte_ethdev.so.12
librte_eventdev.so.6
diff --git a/drivers/bus/pci/linux/pci_vfio.c b/drivers/bus/pci/linux/pci_vfio.c
index ebf6ccd3c..1ceb1c07b 100644
--- a/drivers/bus/pci/linux/pci_vfio.c
+++ b/drivers/bus/pci/linux/pci_vfio.c
@@ -20,6 +20,7 @@
#include <rte_eal.h>
#include <rte_bus.h>
#include <rte_spinlock.h>
+#include <rte_tailq.h>
#include "eal_filesystem.h"
diff --git a/lib/librte_acl/rte_acl.c b/lib/librte_acl/rte_acl.c
index 7ff11d25f..bd7247cc3 100644
--- a/lib/librte_acl/rte_acl.c
+++ b/lib/librte_acl/rte_acl.c
@@ -4,6 +4,8 @@
#include <rte_string_fns.h>
#include <rte_acl.h>
+#include <rte_tailq.h>
+
#include "acl.h"
TAILQ_HEAD(rte_acl_list, rte_tailq_entry);
diff --git a/lib/librte_distributor/rte_distributor.c b/lib/librte_distributor/rte_distributor.c
index 9eb78b330..0a3213bbf 100644
--- a/lib/librte_distributor/rte_distributor.c
+++ b/lib/librte_distributor/rte_distributor.c
@@ -14,6 +14,7 @@
#include <rte_string_fns.h>
#include <rte_eal_memconfig.h>
#include <rte_pause.h>
+#include <rte_tailq.h>
#include "rte_distributor_private.h"
#include "rte_distributor.h"
diff --git a/lib/librte_distributor/rte_distributor_v20.c b/lib/librte_distributor/rte_distributor_v20.c
index 1fc03b971..cdc0969a8 100644
--- a/lib/librte_distributor/rte_distributor_v20.c
+++ b/lib/librte_distributor/rte_distributor_v20.c
@@ -13,6 +13,7 @@
#include <rte_string_fns.h>
#include <rte_eal_memconfig.h>
#include <rte_pause.h>
+#include <rte_tailq.h>
#include "rte_distributor_v20.h"
#include "rte_distributor_private.h"
diff --git a/lib/librte_eal/common/eal_common_mcfg.c b/lib/librte_eal/common/eal_common_mcfg.c
index ba2bc37b7..337890a61 100644
--- a/lib/librte_eal/common/eal_common_mcfg.c
+++ b/lib/librte_eal/common/eal_common_mcfg.c
@@ -5,6 +5,8 @@
#include <rte_config.h>
#include <rte_eal_memconfig.h>
+#include "eal_memcfg.h"
+
void
rte_mcfg_mem_read_lock(void)
{
diff --git a/lib/librte_eal/common/eal_common_memory.c b/lib/librte_eal/common/eal_common_memory.c
index e73a413cc..b33bc4b29 100644
--- a/lib/librte_eal/common/eal_common_memory.c
+++ b/lib/librte_eal/common/eal_common_memory.c
@@ -24,6 +24,7 @@
#include "eal_memalloc.h"
#include "eal_private.h"
#include "eal_internal_cfg.h"
+#include "eal_memcfg.h"
#include "malloc_heap.h"
/*
diff --git a/lib/librte_eal/common/eal_common_memzone.c b/lib/librte_eal/common/eal_common_memzone.c
index 521ad7ca1..ef6c909cb 100644
--- a/lib/librte_eal/common/eal_common_memzone.c
+++ b/lib/librte_eal/common/eal_common_memzone.c
@@ -24,6 +24,7 @@
#include "malloc_heap.h"
#include "malloc_elem.h"
#include "eal_private.h"
+#include "eal_memcfg.h"
static inline const struct rte_memzone *
memzone_lookup_thread_unsafe(const char *name)
diff --git a/lib/librte_eal/common/eal_common_tailqs.c b/lib/librte_eal/common/eal_common_tailqs.c
index dc2c13caa..ead06897b 100644
--- a/lib/librte_eal/common/eal_common_tailqs.c
+++ b/lib/librte_eal/common/eal_common_tailqs.c
@@ -23,6 +23,7 @@
#include <rte_debug.h>
#include "eal_private.h"
+#include "eal_memcfg.h"
TAILQ_HEAD(rte_tailq_elem_head, rte_tailq_elem);
/* local tailq list */
diff --git a/lib/librte_eal/common/eal_memcfg.h b/lib/librte_eal/common/eal_memcfg.h
new file mode 100644
index 000000000..466958352
--- /dev/null
+++ b/lib/librte_eal/common/eal_memcfg.h
@@ -0,0 +1,79 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2019 Intel Corporation
+ */
+
+#ifndef EAL_MEMCFG_H
+#define EAL_MEMCFG_H
+
+#include <rte_config.h>
+#include <rte_eal_memconfig.h>
+#include <rte_malloc_heap.h>
+#include <rte_memory.h>
+#include <rte_memzone.h>
+#include <rte_pause.h>
+#include <rte_rwlock.h>
+#include <rte_tailq.h>
+
+/**
+ * the structure for the memory configuration for the RTE.
+ * Used by the rte_config structure. It is separated out, as for multi-process
+ * support, the memory details should be shared across instances
+ */
+struct rte_mem_config {
+ volatile uint32_t magic; /**< Magic number - Sanity check. */
+
+ /* memory topology */
+ uint32_t nchannel; /**< Number of channels (0 if unknown). */
+ uint32_t nrank; /**< Number of ranks (0 if unknown). */
+
+ /**
+ * current lock nest order
+ * - qlock->mlock (ring/hash/lpm)
+ * - mplock->qlock->mlock (mempool)
+ * Notice:
+ * *ALWAYS* obtain qlock first if having to obtain both qlock and mlock
+ */
+ rte_rwlock_t mlock; /**< only used by memzone LIB for thread-safe. */
+ rte_rwlock_t qlock; /**< used for tailq operation for thread safe. */
+ rte_rwlock_t mplock; /**< only used by mempool LIB for thread-safe. */
+
+ rte_rwlock_t memory_hotplug_lock;
+ /**< indicates whether memory hotplug request is in progress. */
+
+ /* memory segments and zones */
+ struct rte_fbarray memzones; /**< Memzone descriptors. */
+
+ struct rte_memseg_list memsegs[RTE_MAX_MEMSEG_LISTS];
+ /**< list of dynamic arrays holding memsegs */
+
+ struct rte_tailq_head tailq_head[RTE_MAX_TAILQ];
+ /**< Tailqs for objects */
+
+ /* Heaps of Malloc */
+ struct malloc_heap malloc_heaps[RTE_MAX_HEAPS];
+
+ /* next socket ID for external malloc heap */
+ int next_socket_id;
+
+ /* address of mem_config in primary process. used to map shared config
+ * into exact same address the primary process maps it.
+ */
+ uint64_t mem_cfg_addr;
+
+ /* legacy mem and single file segments options are shared */
+ uint32_t legacy_mem;
+ uint32_t single_file_segments;
+
+ /* keeps the more restricted dma mask */
+ uint8_t dma_maskbits;
+} __attribute__((packed));
+
+static inline void
+rte_eal_mcfg_wait_complete(struct rte_mem_config *mcfg)
+{
+ /* wait until shared mem_config finish initialising */
+ while (mcfg->magic != RTE_MAGIC)
+ rte_pause();
+}
+
+#endif /* EAL_MEMCFG_H */
diff --git a/lib/librte_eal/common/include/rte_eal_memconfig.h b/lib/librte_eal/common/include/rte_eal_memconfig.h
index 58dcbb96d..1b615c892 100644
--- a/lib/librte_eal/common/include/rte_eal_memconfig.h
+++ b/lib/librte_eal/common/include/rte_eal_memconfig.h
@@ -5,13 +5,12 @@
#ifndef _RTE_EAL_MEMCONFIG_H_
#define _RTE_EAL_MEMCONFIG_H_
-#include <rte_config.h>
-#include <rte_tailq.h>
-#include <rte_memory.h>
-#include <rte_memzone.h>
-#include <rte_malloc_heap.h>
-#include <rte_rwlock.h>
-#include <rte_pause.h>
+/**
+ * @file
+ *
+ * This API allows access to EAL shared memory configuration through an API.
+ */
+
#include <rte_fbarray.h>
#ifdef __cplusplus
@@ -38,68 +37,6 @@ struct rte_memseg_list {
struct rte_fbarray memseg_arr;
};
-/**
- * the structure for the memory configuration for the RTE.
- * Used by the rte_config structure. It is separated out, as for multi-process
- * support, the memory details should be shared across instances
- */
-struct rte_mem_config {
- volatile uint32_t magic; /**< Magic number - Sanity check. */
-
- /* memory topology */
- uint32_t nchannel; /**< Number of channels (0 if unknown). */
- uint32_t nrank; /**< Number of ranks (0 if unknown). */
-
- /**
- * current lock nest order
- * - qlock->mlock (ring/hash/lpm)
- * - mplock->qlock->mlock (mempool)
- * Notice:
- * *ALWAYS* obtain qlock first if having to obtain both qlock and mlock
- */
- rte_rwlock_t mlock; /**< only used by memzone LIB for thread-safe. */
- rte_rwlock_t qlock; /**< used for tailq operation for thread safe. */
- rte_rwlock_t mplock; /**< only used by mempool LIB for thread-safe. */
-
- rte_rwlock_t memory_hotplug_lock;
- /**< indicates whether memory hotplug request is in progress. */
-
- /* memory segments and zones */
- struct rte_fbarray memzones; /**< Memzone descriptors. */
-
- struct rte_memseg_list memsegs[RTE_MAX_MEMSEG_LISTS];
- /**< list of dynamic arrays holding memsegs */
-
- struct rte_tailq_head tailq_head[RTE_MAX_TAILQ]; /**< Tailqs for objects */
-
- /* Heaps of Malloc */
- struct malloc_heap malloc_heaps[RTE_MAX_HEAPS];
-
- /* next socket ID for external malloc heap */
- int next_socket_id;
-
- /* address of mem_config in primary process. used to map shared config into
- * exact same address the primary process maps it.
- */
- uint64_t mem_cfg_addr;
-
- /* legacy mem and single file segments options are shared */
- uint32_t legacy_mem;
- uint32_t single_file_segments;
-
- /* keeps the more restricted dma mask */
- uint8_t dma_maskbits;
-} __attribute__((__packed__));
-
-
-inline static void
-rte_eal_mcfg_wait_complete(struct rte_mem_config* mcfg)
-{
- /* wait until shared mem_config finish initialising */
- while(mcfg->magic != RTE_MAGIC)
- rte_pause();
-}
-
/**
* Lock the internal EAL shared memory configuration for shared access.
*/
diff --git a/lib/librte_eal/common/malloc_heap.c b/lib/librte_eal/common/malloc_heap.c
index f1d31de0d..634ca212f 100644
--- a/lib/librte_eal/common/malloc_heap.c
+++ b/lib/librte_eal/common/malloc_heap.c
@@ -20,11 +20,13 @@
#include <rte_string_fns.h>
#include <rte_spinlock.h>
#include <rte_memcpy.h>
+#include <rte_memzone.h>
#include <rte_atomic.h>
#include <rte_fbarray.h>
#include "eal_internal_cfg.h"
#include "eal_memalloc.h"
+#include "eal_memcfg.h"
#include "malloc_elem.h"
#include "malloc_heap.h"
#include "malloc_mp.h"
diff --git a/lib/librte_eal/common/malloc_mp.c b/lib/librte_eal/common/malloc_mp.c
index 7c6112c4e..1f212f834 100644
--- a/lib/librte_eal/common/malloc_mp.c
+++ b/lib/librte_eal/common/malloc_mp.c
@@ -10,6 +10,7 @@
#include <rte_string_fns.h>
#include "eal_memalloc.h"
+#include "eal_memcfg.h"
#include "malloc_elem.h"
#include "malloc_mp.h"
diff --git a/lib/librte_eal/common/rte_malloc.c b/lib/librte_eal/common/rte_malloc.c
index 98e1bdd07..8d2ef8aeb 100644
--- a/lib/librte_eal/common/rte_malloc.c
+++ b/lib/librte_eal/common/rte_malloc.c
@@ -25,6 +25,7 @@
#include "malloc_elem.h"
#include "malloc_heap.h"
#include "eal_memalloc.h"
+#include "eal_memcfg.h"
/* Free the memory space back to heap */
diff --git a/lib/librte_eal/freebsd/eal/Makefile b/lib/librte_eal/freebsd/eal/Makefile
index dc56af582..0974518ab 100644
--- a/lib/librte_eal/freebsd/eal/Makefile
+++ b/lib/librte_eal/freebsd/eal/Makefile
@@ -22,7 +22,7 @@ LDLIBS += -lrte_kvargs
EXPORT_MAP := ../../rte_eal_version.map
-LIBABIVER := 10
+LIBABIVER := 11
# specific to freebsd exec-env
SRCS-$(CONFIG_RTE_EXEC_ENV_FREEBSD) := eal.c
diff --git a/lib/librte_eal/freebsd/eal/eal_memory.c b/lib/librte_eal/freebsd/eal/eal_memory.c
index 4b092e1f2..9b9a0577a 100644
--- a/lib/librte_eal/freebsd/eal/eal_memory.c
+++ b/lib/librte_eal/freebsd/eal/eal_memory.c
@@ -18,6 +18,7 @@
#include "eal_private.h"
#include "eal_internal_cfg.h"
#include "eal_filesystem.h"
+#include "eal_memcfg.h"
#define EAL_PAGE_SIZE (sysconf(_SC_PAGESIZE))
diff --git a/lib/librte_eal/linux/eal/Makefile b/lib/librte_eal/linux/eal/Makefile
index 3b2642eb8..9c885a9c9 100644
--- a/lib/librte_eal/linux/eal/Makefile
+++ b/lib/librte_eal/linux/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 := 10
+LIBABIVER := 11
VPATH += $(RTE_SDK)/lib/librte_eal/common
diff --git a/lib/librte_eal/linux/eal/eal.c b/lib/librte_eal/linux/eal/eal.c
index d96ed3a7c..1ab4cc769 100644
--- a/lib/librte_eal/linux/eal/eal.c
+++ b/lib/librte_eal/linux/eal/eal.c
@@ -57,6 +57,7 @@
#include "eal_internal_cfg.h"
#include "eal_filesystem.h"
#include "eal_hugepages.h"
+#include "eal_memcfg.h"
#include "eal_options.h"
#include "eal_vfio.h"
diff --git a/lib/librte_eal/linux/eal/eal_memalloc.c b/lib/librte_eal/linux/eal/eal_memalloc.c
index 2019636fb..1f6a7c18f 100644
--- a/lib/librte_eal/linux/eal/eal_memalloc.c
+++ b/lib/librte_eal/linux/eal/eal_memalloc.c
@@ -44,6 +44,7 @@
#include "eal_filesystem.h"
#include "eal_internal_cfg.h"
#include "eal_memalloc.h"
+#include "eal_memcfg.h"
#include "eal_private.h"
const int anonymous_hugepages_supported =
diff --git a/lib/librte_eal/linux/eal/eal_memory.c b/lib/librte_eal/linux/eal/eal_memory.c
index 1853acea5..9c948a374 100644
--- a/lib/librte_eal/linux/eal/eal_memory.c
+++ b/lib/librte_eal/linux/eal/eal_memory.c
@@ -46,6 +46,7 @@
#include "eal_private.h"
#include "eal_memalloc.h"
+#include "eal_memcfg.h"
#include "eal_internal_cfg.h"
#include "eal_filesystem.h"
#include "eal_hugepages.h"
diff --git a/lib/librte_eal/linux/eal/eal_vfio.c b/lib/librte_eal/linux/eal/eal_vfio.c
index 924cba526..5d679ca68 100644
--- a/lib/librte_eal/linux/eal/eal_vfio.c
+++ b/lib/librte_eal/linux/eal/eal_vfio.c
@@ -15,6 +15,7 @@
#include <rte_vfio.h>
#include "eal_filesystem.h"
+#include "eal_memcfg.h"
#include "eal_vfio.h"
#include "eal_private.h"
diff --git a/lib/librte_eal/meson.build b/lib/librte_eal/meson.build
index fa36b20e0..5c5023dd4 100644
--- a/lib/librte_eal/meson.build
+++ b/lib/librte_eal/meson.build
@@ -12,7 +12,7 @@ subdir('common') # defines common_sources, common_objs, etc.
dpdk_conf.set('RTE_EXEC_ENV_' + exec_env.to_upper(), 1)
subdir(exec_env + '/eal')
-version = 10 # the version of the EAL API
+version = 11 # the version of the EAL API
allow_experimental_apis = true
deps += 'kvargs'
if dpdk_conf.has('RTE_USE_LIBBSD')
diff --git a/lib/librte_efd/rte_efd.c b/lib/librte_efd/rte_efd.c
index b808ce99f..d3d019578 100644
--- a/lib/librte_efd/rte_efd.c
+++ b/lib/librte_efd/rte_efd.c
@@ -20,6 +20,7 @@
#include <rte_ring.h>
#include <rte_jhash.h>
#include <rte_hash_crc.h>
+#include <rte_tailq.h>
#include "rte_efd.h"
#if defined(RTE_ARCH_X86)
diff --git a/lib/librte_hash/rte_cuckoo_hash.c b/lib/librte_hash/rte_cuckoo_hash.c
index 865c744d9..b76518b4c 100644
--- a/lib/librte_hash/rte_cuckoo_hash.c
+++ b/lib/librte_hash/rte_cuckoo_hash.c
@@ -27,6 +27,7 @@
#include <rte_ring.h>
#include <rte_compat.h>
#include <rte_vect.h>
+#include <rte_tailq.h>
#include "rte_hash.h"
#include "rte_cuckoo_hash.h"
diff --git a/lib/librte_hash/rte_fbk_hash.c b/lib/librte_hash/rte_fbk_hash.c
index db118c930..576e8e666 100644
--- a/lib/librte_hash/rte_fbk_hash.c
+++ b/lib/librte_hash/rte_fbk_hash.c
@@ -20,6 +20,7 @@
#include <rte_cpuflags.h>
#include <rte_log.h>
#include <rte_spinlock.h>
+#include <rte_tailq.h>
#include "rte_fbk_hash.h"
diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
index b91f74216..70c24ac1f 100644
--- a/lib/librte_lpm/rte_lpm.c
+++ b/lib/librte_lpm/rte_lpm.c
@@ -21,6 +21,7 @@
#include <rte_errno.h>
#include <rte_rwlock.h>
#include <rte_spinlock.h>
+#include <rte_tailq.h>
#include "rte_lpm.h"
diff --git a/lib/librte_lpm/rte_lpm6.c b/lib/librte_lpm/rte_lpm6.c
index 5af74a539..9b8aeb972 100644
--- a/lib/librte_lpm/rte_lpm6.c
+++ b/lib/librte_lpm/rte_lpm6.c
@@ -24,6 +24,7 @@
#include <rte_hash.h>
#include <assert.h>
#include <rte_jhash.h>
+#include <rte_tailq.h>
#include "rte_lpm6.h"
diff --git a/lib/librte_member/rte_member.c b/lib/librte_member/rte_member.c
index efed28dd9..e0e7f127e 100644
--- a/lib/librte_member/rte_member.c
+++ b/lib/librte_member/rte_member.c
@@ -10,6 +10,7 @@
#include <rte_memory.h>
#include <rte_malloc.h>
#include <rte_errno.h>
+#include <rte_tailq.h>
#include "rte_member.h"
#include "rte_member_ht.h"
diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index 5c688d456..7260ce0be 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -30,6 +30,7 @@
#include <rte_errno.h>
#include <rte_string_fns.h>
#include <rte_spinlock.h>
+#include <rte_tailq.h>
#include "rte_mempool.h"
diff --git a/lib/librte_reorder/rte_reorder.c b/lib/librte_reorder/rte_reorder.c
index ae6e3f578..3c9f0e2d0 100644
--- a/lib/librte_reorder/rte_reorder.c
+++ b/lib/librte_reorder/rte_reorder.c
@@ -11,6 +11,7 @@
#include <rte_eal_memconfig.h>
#include <rte_errno.h>
#include <rte_malloc.h>
+#include <rte_tailq.h>
#include "rte_reorder.h"
diff --git a/lib/librte_ring/rte_ring.c b/lib/librte_ring/rte_ring.c
index 9ea26a631..b30b2aa7b 100644
--- a/lib/librte_ring/rte_ring.c
+++ b/lib/librte_ring/rte_ring.c
@@ -30,6 +30,7 @@
#include <rte_errno.h>
#include <rte_string_fns.h>
#include <rte_spinlock.h>
+#include <rte_tailq.h>
#include "rte_ring.h"
--
2.17.1
^ permalink raw reply [relevance 8%]
* [dpdk-dev] [PATCH v3 14/14] eal: prevent different primary/secondary process versions
2019-06-27 11:39 8% ` [dpdk-dev] [PATCH v3 09/14] eal: hide shared memory config Anatoly Burakov
@ 2019-06-27 11:39 3% ` Anatoly Burakov
1 sibling, 0 replies; 200+ results
From: Anatoly Burakov @ 2019-06-27 11:39 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson, david.marchand, thomas, stephen
Currently, nothing stops DPDK to attempt to run primary and
secondary processes while having different versions. This
can lead to all sorts of weird behavior and makes it harder
to maintain compatibility without breaking ABI every once
in a while.
Fix it by explicitly disallowing running different DPDK
versions as primary and secondary processes.
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
---
lib/librte_eal/common/eal_common_mcfg.c | 15 +++++++++++++++
lib/librte_eal/common/eal_memcfg.h | 6 ++++++
lib/librte_eal/freebsd/eal/eal.c | 5 ++++-
lib/librte_eal/linux/eal/eal.c | 5 ++++-
4 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_mcfg.c b/lib/librte_eal/common/eal_common_mcfg.c
index fe8d2b726..1825d9083 100644
--- a/lib/librte_eal/common/eal_common_mcfg.c
+++ b/lib/librte_eal/common/eal_common_mcfg.c
@@ -4,6 +4,7 @@
#include <rte_config.h>
#include <rte_eal_memconfig.h>
+#include <rte_version.h>
#include "eal_internal_cfg.h"
#include "eal_memcfg.h"
@@ -31,6 +32,18 @@ eal_mcfg_wait_complete(void)
rte_pause();
}
+int
+eal_mcfg_check_version(void)
+{
+ struct rte_mem_config *mcfg = rte_eal_get_configuration()->mem_config;
+
+ /* check if version from memconfig matches compiled in macro */
+ if (mcfg->version != RTE_VERSION)
+ return -1;
+
+ return 0;
+}
+
void
eal_mcfg_update_internal(void)
{
@@ -47,6 +60,8 @@ eal_mcfg_update_from_internal(void)
mcfg->legacy_mem = internal_config.legacy_mem;
mcfg->single_file_segments = internal_config.single_file_segments;
+ /* record current DPDK version */
+ mcfg->version = RTE_VERSION;
}
void
diff --git a/lib/librte_eal/common/eal_memcfg.h b/lib/librte_eal/common/eal_memcfg.h
index d02ac1621..a3d4b7fd1 100644
--- a/lib/librte_eal/common/eal_memcfg.h
+++ b/lib/librte_eal/common/eal_memcfg.h
@@ -21,6 +21,8 @@
*/
struct rte_mem_config {
volatile uint32_t magic; /**< Magic number - Sanity check. */
+ uint32_t version;
+ /**< Prevent secondary processes using different DPDK versions. */
/* memory topology */
uint32_t nchannel; /**< Number of channels (0 if unknown). */
@@ -80,6 +82,10 @@ eal_mcfg_update_from_internal(void);
void
eal_mcfg_wait_complete(void);
+/* check if DPDK version of current process matches one stored in the config */
+int
+eal_mcfg_check_version(void);
+
/* set mem config as complete */
void
eal_mcfg_complete(void);
diff --git a/lib/librte_eal/freebsd/eal/eal.c b/lib/librte_eal/freebsd/eal/eal.c
index 6bfe203fd..e2039927c 100644
--- a/lib/librte_eal/freebsd/eal/eal.c
+++ b/lib/librte_eal/freebsd/eal/eal.c
@@ -385,6 +385,10 @@ rte_config_init(void)
if (rte_eal_config_attach() < 0)
return -1;
eal_mcfg_wait_complete();
+ if (eal_mcfg_check_version() < 0) {
+ RTE_LOG(ERR, EAL, "Primary and secondary process DPDK version mismatch\n");
+ return -1;
+ }
if (rte_eal_config_reattach() < 0)
return -1;
eal_mcfg_update_from_internal();
@@ -395,7 +399,6 @@ rte_config_init(void)
rte_config.process_type);
return -1;
}
-
return 0;
}
diff --git a/lib/librte_eal/linux/eal/eal.c b/lib/librte_eal/linux/eal/eal.c
index fa205fd29..5421e934e 100644
--- a/lib/librte_eal/linux/eal/eal.c
+++ b/lib/librte_eal/linux/eal/eal.c
@@ -488,6 +488,10 @@ rte_config_init(void)
if (rte_eal_config_attach() < 0)
return -1;
eal_mcfg_wait_complete();
+ if (eal_mcfg_check_version() < 0) {
+ RTE_LOG(ERR, EAL, "Primary and secondary process DPDK version mismatch\n");
+ return -1;
+ }
if (rte_eal_config_reattach() < 0)
return -1;
eal_mcfg_update_internal();
@@ -498,7 +502,6 @@ rte_config_init(void)
rte_config.process_type);
return -1;
}
-
return 0;
}
--
2.17.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 00/39] adding eventmode helper library
2019-06-27 5:28 0% ` Anoob Joseph
@ 2019-06-28 3:37 0% ` Jerin Jacob Kollanukkaran
2019-06-28 8:02 0% ` Mattias Rönnblom
2019-06-28 8:40 0% ` Thomas Monjalon
0 siblings, 2 replies; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-06-28 3:37 UTC (permalink / raw)
To: Anoob Joseph, Mattias Rönnblom, Nikhil Rao,
Erik Gabriel Carrillo, Abhinandan Gujjar, Bruce Richardson,
Pablo de Lara
Cc: Narayana Prasad Raju Athreya, dev, Lukas Bartosik,
Pavan Nikhilesh Bhagavatula, Hemant Agrawal, Nipun Gupta,
Harry van Haaren, Liang Ma, techboard
> -----Original Message-----
> From: Anoob Joseph
> Sent: Thursday, June 27, 2019 10:58 AM
> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Mattias Rönnblom
> <mattias.ronnblom@ericsson.com>; Nikhil Rao <nikhil.rao@intel.com>; Erik
> Gabriel Carrillo <erik.g.carrillo@intel.com>; Abhinandan Gujjar
> <abhinandan.gujjar@intel.com>; Bruce Richardson
> <bruce.richardson@intel.com>; Pablo de Lara
> <pablo.de.lara.guarch@intel.com>
> Cc: Narayana Prasad Raju Athreya <pathreya@marvell.com>; dev@dpdk.org;
> Lukas Bartosik <lbartosik@marvell.com>; Pavan Nikhilesh Bhagavatula
> <pbhagavatula@marvell.com>; Hemant Agrawal
> <hemant.agrawal@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>; Harry
> van Haaren <harry.van.haaren@intel.com>; Liang Ma
> <liang.j.ma@intel.com>
> Subject: RE: [dpdk-dev] Re: [PATCH 00/39] adding eventmode helper library
>
> Hi Jerin, Mattias,
>
> Please see inline.
>
> Thanks,
> Anoob
>
> > -----Original Message-----
> > From: Jerin Jacob Kollanukkaran
> > Sent: Tuesday, June 25, 2019 4:03 PM
> > To: Anoob Joseph <anoobj@marvell.com>; Mattias Rönnblom
> > <mattias.ronnblom@ericsson.com>; Nikhil Rao <nikhil.rao@intel.com>;
> > Erik Gabriel Carrillo <erik.g.carrillo@intel.com>; Abhinandan Gujjar
> > <abhinandan.gujjar@intel.com>; Bruce Richardson
> > <bruce.richardson@intel.com>; Pablo de Lara
> > <pablo.de.lara.guarch@intel.com>
> > Cc: Narayana Prasad Raju Athreya <pathreya@marvell.com>;
> dev@dpdk.org;
> > Lukas Bartosik <lbartosik@marvell.com>; Pavan Nikhilesh Bhagavatula
> > <pbhagavatula@marvell.com>; Hemant Agrawal
> <hemant.agrawal@nxp.com>;
> > Nipun Gupta <nipun.gupta@nxp.com>; Harry van Haaren
> > <harry.van.haaren@intel.com>; Liang Ma <liang.j.ma@intel.com>
> > Subject: RE: [dpdk-dev] Re: [PATCH 00/39] adding eventmode helper
> > library
> >
> > > -----Original Message-----
> > > From: Anoob Joseph
> > > Sent: Thursday, June 20, 2019 9:15 AM
> > > To: Mattias Rönnblom <mattias.ronnblom@ericsson.com>; Jerin Jacob
> > > Kollanukkaran <jerinj@marvell.com>; Nikhil Rao
> > > <nikhil.rao@intel.com>; Erik Gabriel Carrillo
> > > <erik.g.carrillo@intel.com>; Abhinandan Gujjar
> > > <abhinandan.gujjar@intel.com>; Bruce Richardson
> > > <bruce.richardson@intel.com>; Pablo de Lara
> > > <pablo.de.lara.guarch@intel.com>
> > > Cc: Narayana Prasad Raju Athreya <pathreya@marvell.com>;
> > dev@dpdk.org;
> > > Lukas Bartosik <lbartosik@marvell.com>; Pavan Nikhilesh Bhagavatula
> > > <pbhagavatula@marvell.com>; Hemant Agrawal
> > <hemant.agrawal@nxp.com>;
> > > Nipun Gupta <nipun.gupta@nxp.com>; Harry van Haaren
> > > <harry.van.haaren@intel.com>; Liang Ma <liang.j.ma@intel.com>
> > > Subject: RE: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode
> > > helper library
> > > > However, the flexibility and many of the parameters are there for
> > > > a reason (those there aren't should be deprecated). I would expect
> > > > a real-world application to tweak quite a few of them. I know our
> > > > applications
> > > do.
> > > >
> > > > I worry I have is that if you put eventmode (in its current form)
> > > > forward as a generic framework, applications might start using it,
> > > > only to realize it's not flexible enough, and then eventmode is
> > > > just an extra layer, increasing rather than reducing complexity.
> > > > Or even worse, the application's developers are forced to do a
> > > > big-bang switch over to using the event and ethernet device APIs
> > > > directly, in case they can't patch DPDK to work around the
> > > > eventmode-
> > > > assumption-that-
> > > didn't-hold-for-them.
> > > >
> > > > You could always add flexibility to the framework (as you
> > > > encounter a need for it), but then it will grow in complexity as well.
> > > >
> > > > A less ambitious approach would be to instead do a properly
> > > > modularized, non-trivial eventdev example application, for the
> > > > applications to start off from, instead of a generic library.
> > > >
> > > > I would expect it to be very difficult to design a truly generic
> > > > application framework for eventdev-based applications. Such a
> > > > framework would tie everything that's needed in a non-trivial
> > > > application together. If successful, it would be a huge step
> > > > toward making DPDK an operating system for packet processing
> applications.
> > >
> > > [Anoob] The idea here is not to deprecate any event dev APIs. I do
> > > agree that all the configuration exposed by eventdev & adapters are
> > > required for various requirements in the real world applications.
> > > But the requirement to understand & use all this configuration is
> > > making the applications complicated and causes significant effort
> > > from anyone who
> > would want to get started with event mode.
> > > The idea of helper is to allow an easy framework for applications to
> > > get started with eventmode, and then use various options from C/L or
> > > config file (both
> > > planned) to override the configuration as required. DPDK has
> > > components like crypto-scheduler which abstracts lot of
> > > configuration and simplify usage from application's perspective.
> > > This effort is on similar
> > lines.
> > >
> > > My patchset is a followup to http://patches.dpdk.org/patch/37955 ,
> > > wherein the approach of introducing a helper library for event mode
> > > was mooted. The initial patch proposed additions in one application,
> > > and that involved huge code additions just for doing the configuration.
> > >
> > > The helper library will be experimental while we add event-mode
> > > support for other applications like l3fwd & ipsec-secgw. I expect
> > > the helper library to be complete over the course of those
> > > applications also
> > using the helper library.
> >
> >
> > I have only concern about moving this as library inside eventdev that
> > till we have mature version of helper library the eventdev library ABI
> > will not stable(i.e .so file version needs to be incremented as when a
> > change needed). Which align with Mattias thoughts for some other
> > reason:. How about moving this code to
> > 1) example/common or
> > 2) to specific application itself, once at least two applications
> > starts using it then move to Eventdev library.
> >
> > Thoughts?
>
> [Anoob] Either location is not a problem if there is a consensus. Earlier the
> suggestion was to move it to library (when the patch was submitted with
> changes added in app).
If there NO objections then lets move to example/common.
Cc: techboard@dpdk.org for final decision on the location.
>
> Since there are other comments, which are being addressed, I would like to
> send the next series with the current layout itself. And when we have an
> agreement on the location to be used, I'll make the changes. Is that fine?
>
> >
> >
> >
> >
> > >
> > > >
> > > > What event devices have you tested with?
> > >
> > > [Anoob] Eventmode helper is tested with the following combinations,
> > > 1. event-octeontx event PMD & nicvf eth PMD
> > > 2. event-octeontx event PMD & eth-octeontx eth PMD
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 00/39] adding eventmode helper library
2019-06-28 3:37 0% ` Jerin Jacob Kollanukkaran
@ 2019-06-28 8:02 0% ` Mattias Rönnblom
2019-06-28 8:40 0% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Mattias Rönnblom @ 2019-06-28 8:02 UTC (permalink / raw)
To: Jerin Jacob Kollanukkaran, Anoob Joseph, Nikhil Rao,
Erik Gabriel Carrillo, Abhinandan Gujjar, Bruce Richardson,
Pablo de Lara
Cc: Narayana Prasad Raju Athreya, dev, Lukas Bartosik,
Pavan Nikhilesh Bhagavatula, Hemant Agrawal, Nipun Gupta,
Harry van Haaren, Liang Ma, techboard
On 2019-06-28 05:37, Jerin Jacob Kollanukkaran wrote:
>>>
>>> I have only concern about moving this as library inside eventdev that
>>> till we have mature version of helper library the eventdev library ABI
>>> will not stable(i.e .so file version needs to be incremented as when a
>>> change needed). Which align with Mattias thoughts for some other
>>> reason:. How about moving this code to
>>> 1) example/common or
>>> 2) to specific application itself, once at least two applications
>>> starts using it then move to Eventdev library.
>>>
>>> Thoughts?
>>
>> [Anoob] Either location is not a problem if there is a consensus. Earlier the
>> suggestion was to move it to library (when the patch was submitted with
>> changes added in app).
>
>
> If there NO objections then lets move to example/common.
>
That sounds like a good idea to me.
I wish I had more time to devote to eventmode, so I could be more
constructive than basically just saying "it's a hard problem" and "the
proposed solution seems not generic-enough by far" - but I don't at the
moment.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 00/39] adding eventmode helper library
2019-06-28 3:37 0% ` Jerin Jacob Kollanukkaran
2019-06-28 8:02 0% ` Mattias Rönnblom
@ 2019-06-28 8:40 0% ` Thomas Monjalon
2019-06-28 9:07 0% ` Mattias Rönnblom
2019-06-28 11:34 0% ` [dpdk-dev] [EXT] " Anoob Joseph
1 sibling, 2 replies; 200+ results
From: Thomas Monjalon @ 2019-06-28 8:40 UTC (permalink / raw)
To: Jerin Jacob Kollanukkaran, Anoob Joseph
Cc: dev, Mattias Rönnblom, Nikhil Rao, Erik Gabriel Carrillo,
Abhinandan Gujjar, Bruce Richardson, Pablo de Lara,
Narayana Prasad Raju Athreya, Lukas Bartosik,
Pavan Nikhilesh Bhagavatula, Hemant Agrawal, Nipun Gupta,
Harry van Haaren, Liang Ma, techboard
28/06/2019 05:37, Jerin Jacob Kollanukkaran:
> From: Anoob Joseph
> > From: Jerin Jacob Kollanukkaran
> > > From: Anoob Joseph
> > > > The helper library will be experimental while we add event-mode
> > > > support for other applications like l3fwd & ipsec-secgw. I expect
> > > > the helper library to be complete over the course of those
> > > > applications also using the helper library.
You are doing a copy of l2fwd example to add event mode.
It was the decision from the techboard to not complicate the original
l2fwd. But it makes me nervous to see some code duplicated,
especially if you plan to do the same for l3fwd and ipsec-secgw.
We are not going to duplicate every examples. We should re-consider.
> > > I have only concern about moving this as library inside eventdev that
> > > till we have mature version of helper library the eventdev library ABI
> > > will not stable(i.e .so file version needs to be incremented as when a
> > > change needed). Which align with Mattias thoughts for some other
> > > reason:. How about moving this code to
> > > 1) example/common or
> > > 2) to specific application itself, once at least two applications
> > > starts using it then move to Eventdev library.
> > >
> > > Thoughts?
> >
> > [Anoob] Either location is not a problem if there is a consensus. Earlier the
> > suggestion was to move it to library (when the patch was submitted with
> > changes added in app).
If there is only one user, making it grow in the application looks to be
the best thing to do.
Should we use it in more applications before it is more mature?
If not, we could move the code in eventdev library when we will
use it in more examples.
> If there NO objections then lets move to example/common.
If we really want to have this library standalone in examples,
I suggest to give it a name and not use a "common" directory.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 00/39] adding eventmode helper library
2019-06-28 8:40 0% ` Thomas Monjalon
@ 2019-06-28 9:07 0% ` Mattias Rönnblom
2019-06-28 11:34 0% ` [dpdk-dev] [EXT] " Anoob Joseph
1 sibling, 0 replies; 200+ results
From: Mattias Rönnblom @ 2019-06-28 9:07 UTC (permalink / raw)
To: Thomas Monjalon, Jerin Jacob Kollanukkaran, Anoob Joseph
Cc: dev, Nikhil Rao, Erik Gabriel Carrillo, Abhinandan Gujjar,
Bruce Richardson, Pablo de Lara, Narayana Prasad Raju Athreya,
Lukas Bartosik, Pavan Nikhilesh Bhagavatula, Hemant Agrawal,
Nipun Gupta, Harry van Haaren, Liang Ma, techboard
On 2019-06-28 10:40, Thomas Monjalon wrote:
> 28/06/2019 05:37, Jerin Jacob Kollanukkaran:
>> From: Anoob Joseph
>>> From: Jerin Jacob Kollanukkaran
>>>> From: Anoob Joseph
>>>>> The helper library will be experimental while we add event-mode
>>>>> support for other applications like l3fwd & ipsec-secgw. I expect
>>>>> the helper library to be complete over the course of those
>>>>> applications also using the helper library.
>
> You are doing a copy of l2fwd example to add event mode.
> It was the decision from the techboard to not complicate the original
> l2fwd. But it makes me nervous to see some code duplicated,
> especially if you plan to do the same for l3fwd and ipsec-secgw.
> We are not going to duplicate every examples. We should re-consider.
>
>>>> I have only concern about moving this as library inside eventdev that
>>>> till we have mature version of helper library the eventdev library ABI
>>>> will not stable(i.e .so file version needs to be incremented as when a
>>>> change needed). Which align with Mattias thoughts for some other
>>>> reason:. How about moving this code to
>>>> 1) example/common or
>>>> 2) to specific application itself, once at least two applications
>>>> starts using it then move to Eventdev library.
>>>>
>>>> Thoughts?
>>>
>>> [Anoob] Either location is not a problem if there is a consensus. Earlier the
>>> suggestion was to move it to library (when the patch was submitted with
>>> changes added in app).
>
> If there is only one user, making it grow in the application looks to be
> the best thing to do.
> Should we use it in more applications before it is more mature?
> If not, we could move the code in eventdev library when we will
> use it in more examples.
>
>> If there NO objections then lets move to example/common.
>
> If we really want to have this library standalone in examples,
> I suggest to give it a name and not use a "common" directory.
>
>
Another solution would be to keep it in a separate git repo, potentially
together with a few forked DPDK example applications and new
purpose-built example applications, until it's mature enough.
It's a bolt-on, not an integral part of eventdev or any other
lower-layer infrastructure, so you don't need the whole DPDK tree.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper library
2019-06-28 8:40 0% ` Thomas Monjalon
2019-06-28 9:07 0% ` Mattias Rönnblom
@ 2019-06-28 11:34 0% ` Anoob Joseph
2019-07-02 14:17 0% ` Anoob Joseph
1 sibling, 1 reply; 200+ results
From: Anoob Joseph @ 2019-06-28 11:34 UTC (permalink / raw)
To: Thomas Monjalon, Jerin Jacob Kollanukkaran
Cc: dev, Mattias Rönnblom, Nikhil Rao, Erik Gabriel Carrillo,
Abhinandan Gujjar, Bruce Richardson, Pablo de Lara,
Narayana Prasad Raju Athreya, Lukas Bartosik,
Pavan Nikhilesh Bhagavatula, Hemant Agrawal, Nipun Gupta,
Harry van Haaren, Liang Ma, techboard
Hi Thomas, Jerin,
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Thomas Monjalon
> Sent: Friday, June 28, 2019 2:10 PM
> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Anoob Joseph
> <anoobj@marvell.com>
> Cc: dev@dpdk.org; Mattias Rönnblom <mattias.ronnblom@ericsson.com>;
> Nikhil Rao <nikhil.rao@intel.com>; Erik Gabriel Carrillo
> <erik.g.carrillo@intel.com>; Abhinandan Gujjar
> <abhinandan.gujjar@intel.com>; Bruce Richardson
> <bruce.richardson@intel.com>; Pablo de Lara
> <pablo.de.lara.guarch@intel.com>; Narayana Prasad Raju Athreya
> <pathreya@marvell.com>; Lukas Bartosik <lbartosik@marvell.com>; Pavan
> Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Hemant Agrawal
> <hemant.agrawal@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>; Harry
> van Haaren <harry.van.haaren@intel.com>; Liang Ma
> <liang.j.ma@intel.com>; techboard@dpdk.org
> Subject: [EXT] Re: [dpdk-dev] [PATCH 00/39] adding eventmode helper
> library
>
> External Email
>
> ----------------------------------------------------------------------
> 28/06/2019 05:37, Jerin Jacob Kollanukkaran:
> > From: Anoob Joseph
> > > From: Jerin Jacob Kollanukkaran
> > > > From: Anoob Joseph
> > > > > The helper library will be experimental while we add event-mode
> > > > > support for other applications like l3fwd & ipsec-secgw. I
> > > > > expect the helper library to be complete over the course of
> > > > > those applications also using the helper library.
>
> You are doing a copy of l2fwd example to add event mode.
> It was the decision from the techboard to not complicate the original l2fwd.
> But it makes me nervous to see some code duplicated, especially if you plan
> to do the same for l3fwd and ipsec-secgw.
> We are not going to duplicate every examples. We should re-consider.
>
[Anoob] For l3fwd & ipsec-secgw, the plan is to add eventmode in the original application itself. If you have concerns about code duplication in l2fwd-event, the changes can be added to l2fwd itself. Please advise on how to proceed.
> > > > I have only concern about moving this as library inside eventdev
> > > > that till we have mature version of helper library the eventdev
> > > > library ABI will not stable(i.e .so file version needs to be
> > > > incremented as when a change needed). Which align with Mattias
> > > > thoughts for some other reason:. How about moving this code to
> > > > 1) example/common or
> > > > 2) to specific application itself, once at least two applications
> > > > starts using it then move to Eventdev library.
> > > >
> > > > Thoughts?
> > >
> > > [Anoob] Either location is not a problem if there is a consensus.
> > > Earlier the suggestion was to move it to library (when the patch was
> > > submitted with changes added in app).
>
> If there is only one user, making it grow in the application looks to be the
> best thing to do.
> Should we use it in more applications before it is more mature?
> If not, we could move the code in eventdev library when we will use it in
> more examples.
>
[Anoob] The proposal with l2fwd-event was to present an easy enough example so that the APIs can be decided before moving onto complex examples. Additions to l3fwd & ipsec-secgw is in the pipeline.
> > If there NO objections then lets move to example/common.
>
> If we really want to have this library standalone in examples, I suggest to give
> it a name and not use a "common" directory.
>
[Anoob] I would suggest to add the eventmode code in 'examples/utils'.
What is being added here can be treated as a utility library. Almost all examples have duplicated code for the entire conf parsing, ethdev init etc. Anyone who would attempt a new application will have to duplicate lot of code. So a similar exercise with regular poll mode is also possible.
As for build, we will have the following options,
1. From the examples/<example>/Makefile, build *helper*.o files ( '../utils/eventmode_helper.o') and prepare the binary. So each application will build its own version of *helper*.c
+SRCS-y += ../utils/eventmode_helper.c
2. Make 'examples/utils' a separate library. This way, all applications can directly link without having to build separately.
Please do suggest on which would be a good way to execute.
Thanks,
Anoob
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH 3/4] eal: allow checking CPU flags by name
@ 2019-06-28 13:34 3% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2019-06-28 13:34 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev
On Fri, Jun 28, 2019 at 2:40 PM Bruce Richardson <bruce.richardson@intel.com>
wrote:
> On Thu, Jun 27, 2019 at 03:22:14PM +0200, David Marchand wrote:
> > On Wed, May 29, 2019 at 5:42 PM Bruce Richardson
> > <[1]bruce.richardson@intel.com> wrote:
> >
> > Rather than using enum values for CPU flags, which means the symbols
> > don't
> > exist on other architectures, provide a flag lookup by name,
> > allowing us to
> > unconditionally check for a CPU flag.
> >
> > Did you consider passing a string for the CPU architecture rather than
> > an enum?
> > It would have to be compared to RTE_ARCH in
> > rte_cpu_get_flagname_enabled.
> > Or to accomodate with x86_64/i686, this could be a cpu arch family.
> > This avoids adding a new C type that seems quite limited wrt its uses.
> > --
> > David Marchand
> >
>
> I'm not sure I really see the value in having string names for the
> architecture values, I think it would be a lot more clunky to manage rather
> than having an enum value. The key difference vs the flags is that the
> flags are only valid per-architecture while the architecture defines can be
> globally valid, and secondly there is a finite, and small, number of
> architectures compared to the number of flags supported.
>
> If you feel strongly about it I can investigate it, but I'm not sure I see
> the value in doing so right now if the only benefit is avoiding the enum.
>
I suppose we won't have too much trouble handling ABI breakage (thinking
about when we will remove x86 support).
Ok, let's go with this.
--
David Marchand
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v4 10/10] doc: announce bbdev changes
@ 2019-06-30 23:04 0% ` Mokhtar, Amr
2019-07-01 11:14 4% ` Akhil Goyal
1 sibling, 0 replies; 200+ results
From: Mokhtar, Amr @ 2019-06-30 23:04 UTC (permalink / raw)
To: Chautru, Nicolas, akhil.goyal, dev; +Cc: thomas, Yigit, Ferruh
> -----Original Message-----
> From: Chautru, Nicolas
> Sent: Monday 24 June 2019 03:53
> To: akhil.goyal@nxp.com; dev@dpdk.org
> Cc: thomas@monjalon.net; Yigit, Ferruh <ferruh.yigit@intel.com>;
> Mokhtar, Amr <amr.mokhtar@intel.com>; Chautru, Nicolas
> <nicolas.chautru@intel.com>
> Subject: [PATCH v4 10/10] doc: announce bbdev changes
>
> Update of the release notes for BBDEV features add
> and extension of ABI in previous commit.
>
> Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
> ---
Acked-by: Amr Mokhtar <amr.mokhtar@intel.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3] ethdev: support QinQ strip dynamic configuration
2019-06-27 11:08 3% ` Ferruh Yigit
@ 2019-07-01 10:07 0% ` Andrew Rybchenko
2019-07-01 13:05 0% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Andrew Rybchenko @ 2019-07-01 10:07 UTC (permalink / raw)
To: Ferruh Yigit, viveksharma, thomas
Cc: dev, intoviveksharma, stephen, ramirose, Jerin Jacob Kollanukkaran
On 27.06.2019 14:08, Ferruh Yigit wrote:
> On 4/19/2019 6:59 AM, viveksharma@marvell.com wrote:
>> From: Vivek Sharma <viveksharma@marvell.com>
>>
>> Enable missing support for runtime configuration (setting/getting)
>> of QinQ strip rx offload for a given ethdev.
>>
>> Signed-off-by: Vivek Sharma <viveksharma@marvell.com>
> <...>
>
>> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
>> index 40a068f..c1792f4 100644
>> --- a/lib/librte_ethdev/rte_ethdev.h
>> +++ b/lib/librte_ethdev/rte_ethdev.h
>> @@ -550,11 +550,13 @@ struct rte_eth_rss_conf {
>> #define ETH_VLAN_STRIP_OFFLOAD 0x0001 /**< VLAN Strip On/Off */
>> #define ETH_VLAN_FILTER_OFFLOAD 0x0002 /**< VLAN Filter On/Off */
>> #define ETH_VLAN_EXTEND_OFFLOAD 0x0004 /**< VLAN Extend On/Off */
>> +#define ETH_QINQ_STRIP_OFFLOAD 0x0008 /**< QINQ Strip On/Off */
>>
>> /* Definitions used for mask VLAN setting */
>> #define ETH_VLAN_STRIP_MASK 0x0001 /**< VLAN Strip setting mask */
>> #define ETH_VLAN_FILTER_MASK 0x0002 /**< VLAN Filter setting mask*/
>> #define ETH_VLAN_EXTEND_MASK 0x0004 /**< VLAN Extend setting mask*/
>> +#define ETH_QINQ_STRIP_MASK 0x0008 /**< QINQ Strip setting mask */
>> #define ETH_VLAN_ID_MAX 0x0FFF /**< VLAN ID is in lower 12 bits*/
> On its own patch looks ok but a few high level questions:
>
> 1- Why we need this interim defines, instead of using actual offload values?
> Although changing this will be API/ABI breakage.
>
> 2- Why we have specific function to set vlan offloads, for other offloads the
> way is stop device and reconfigure it with new offload flags.
>
> 3- If devices can change offload configuration dynamically, do we need a generic
> API to alter the offload configs? (similar to these vlan APIs but more generic)?
If dynamic switching of offloads is really required, I think it would be
good if it is unified. If so, we can deprecate
rte_eth_dev_{s,g}et_vlan_offload() and implement it using the new one
to remove the old one from driver interface at least.
It requires reporting of dynamically switchable offloads on device and
queue level. Or just dynamically switchable offloads in assumption that
if the offload is supported on queue level and dynamically switchable,
it is dynamically switchable on queue level.
> Related to the patch, what do you think about following options:
> a)
> - Get this patch
> - Send a deprecation notice for 1) in this release
> - Next release remove these flags, which will be practically reverse this patch
> and more
>
> b)
> - Send a deprecation notice for 1) in this release
> - Next release update the APIs and a smaller/different version of this patch
> will be required.
I'm OK with both options, but I think it would be fair to go (a) to avoid
postponing of the feature too long.
The patch itself should update rte_eth_dev_{s,g}et_vlan_offload()
descriptions which enumerate switchable offloads.
Andrew.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4 10/10] doc: announce bbdev changes
2019-06-30 23:04 0% ` Mokhtar, Amr
@ 2019-07-01 11:14 4% ` Akhil Goyal
2019-07-01 18:14 3% ` Chautru, Nicolas
1 sibling, 1 reply; 200+ results
From: Akhil Goyal @ 2019-07-01 11:14 UTC (permalink / raw)
To: Nicolas Chautru, dev; +Cc: thomas, ferruh.yigit, amr.mokhtar
Hi Nicolas,
>
> Update of the release notes for BBDEV features add
> and extension of ABI in previous commit.
>
> Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
> ---
> doc/guides/rel_notes/release_19_08.rst | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/doc/guides/rel_notes/release_19_08.rst
> b/doc/guides/rel_notes/release_19_08.rst
> index 8c3932d..35d3a09 100644
> --- a/doc/guides/rel_notes/release_19_08.rst
> +++ b/doc/guides/rel_notes/release_19_08.rst
> @@ -88,6 +88,19 @@ New Features
> * Added multi-queue support to allow one af_xdp vdev with multiple netdev
> queues
>
> +* **Added a FPGA_LTE_FEC bbdev PMD.**
> +
> + Added the new ``fpga_lte_fec`` bbdev driver for the Intel® FPGA PAC
> + (Programmable Acceleration Card) N3000. See the
> + :doc:`../bbdevs/fpga_lte_fec` BBDEV guide for more details on this new driver.
> +
> +* **Updated TURBO_SW bbdev PMD.**
> +
> + Updated the ``turbo_sw`` bbdev driver with changes including:
> +
> + * Added option to build the driver with or without dependency of external
> + SDK libraries.
> + * Added support for 5GNR encode/decode operations.
>
> Removed Items
> -------------
> @@ -140,6 +153,8 @@ ABI Changes
> Also, make sure to start the actual text at the margin.
> =========================================================
>
> +* bbdev: New parameters added to support 5GNR operations.
> +
>
> Shared Library Versions
> -----------------------
> --
> 1.8.3.1
Release note changes should be part of the same patch which is adding that change.
One more thing, if there is a change in ABI, should you also increment the bbdev ABI version?
Please also send a rebased version of your patchset, so that builds can be verified by CI. The dependent patches are applied on the sub-tree.
-Akhil
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v3] ethdev: support QinQ strip dynamic configuration
2019-07-01 10:07 0% ` Andrew Rybchenko
@ 2019-07-01 13:05 0% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-07-01 13:05 UTC (permalink / raw)
To: Andrew Rybchenko, viveksharma, thomas
Cc: dev, intoviveksharma, stephen, ramirose, Jerin Jacob Kollanukkaran
On 7/1/2019 11:07 AM, Andrew Rybchenko wrote:
> On 27.06.2019 14:08, Ferruh Yigit wrote:
>> On 4/19/2019 6:59 AM, viveksharma@marvell.com wrote:
>>> From: Vivek Sharma <viveksharma@marvell.com>
>>>
>>> Enable missing support for runtime configuration (setting/getting)
>>> of QinQ strip rx offload for a given ethdev.
>>>
>>> Signed-off-by: Vivek Sharma <viveksharma@marvell.com>
>> <...>
>>
>>> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
>>> index 40a068f..c1792f4 100644
>>> --- a/lib/librte_ethdev/rte_ethdev.h
>>> +++ b/lib/librte_ethdev/rte_ethdev.h
>>> @@ -550,11 +550,13 @@ struct rte_eth_rss_conf {
>>> #define ETH_VLAN_STRIP_OFFLOAD 0x0001 /**< VLAN Strip On/Off */
>>> #define ETH_VLAN_FILTER_OFFLOAD 0x0002 /**< VLAN Filter On/Off */
>>> #define ETH_VLAN_EXTEND_OFFLOAD 0x0004 /**< VLAN Extend On/Off */
>>> +#define ETH_QINQ_STRIP_OFFLOAD 0x0008 /**< QINQ Strip On/Off */
>>>
>>> /* Definitions used for mask VLAN setting */
>>> #define ETH_VLAN_STRIP_MASK 0x0001 /**< VLAN Strip setting mask */
>>> #define ETH_VLAN_FILTER_MASK 0x0002 /**< VLAN Filter setting mask*/
>>> #define ETH_VLAN_EXTEND_MASK 0x0004 /**< VLAN Extend setting mask*/
>>> +#define ETH_QINQ_STRIP_MASK 0x0008 /**< QINQ Strip setting mask */
>>> #define ETH_VLAN_ID_MAX 0x0FFF /**< VLAN ID is in lower 12 bits*/
>> On its own patch looks ok but a few high level questions:
>>
>> 1- Why we need this interim defines, instead of using actual offload values?
>> Although changing this will be API/ABI breakage.
>>
>> 2- Why we have specific function to set vlan offloads, for other offloads the
>> way is stop device and reconfigure it with new offload flags.
>>
>> 3- If devices can change offload configuration dynamically, do we need a generic
>> API to alter the offload configs? (similar to these vlan APIs but more generic)?
>
> If dynamic switching of offloads is really required, I think it would be
> good if it is unified. If so, we can deprecate
> rte_eth_dev_{s,g}et_vlan_offload() and implement it using the new one
> to remove the old one from driver interface at least.
> It requires reporting of dynamically switchable offloads on device and
> queue level. Or just dynamically switchable offloads in assumption that
> if the offload is supported on queue level and dynamically switchable,
> it is dynamically switchable on queue level.
Not sure if "dynamic switching of offloads" required, but I agree we may need to
add "dynamically switchable offload" reporting for that.
>
>> Related to the patch, what do you think about following options:
>> a)
>> - Get this patch
>> - Send a deprecation notice for 1) in this release
>> - Next release remove these flags, which will be practically reverse this patch
>> and more
>>
>> b)
>> - Send a deprecation notice for 1) in this release
>> - Next release update the APIs and a smaller/different version of this patch
>> will be required.
>
> I'm OK with both options, but I think it would be fair to go (a) to avoid
> postponing of the feature too long.
OK
>
> The patch itself should update rte_eth_dev_{s,g}et_vlan_offload()
> descriptions which enumerate switchable offloads.
+1
@Vivek, can you please send a new version with this update?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] ether: mark ethernet addresses as being 2-byte aligned
@ 2019-07-01 13:11 3% ` Olivier Matz
0 siblings, 1 reply; 200+ results
From: Olivier Matz @ 2019-07-01 13:11 UTC (permalink / raw)
To: Bruce Richardson; +Cc: Stephen Hemminger, DPDK Dev List
Hi Bruce,
On Thu, May 16, 2019 at 04:54:57PM +0100, Bruce Richardson wrote:
> When including the rte_ether.h header in applications with warnings
> enabled, a warning was given because of the assumption of 2-byte alignment
> of ethernet addresses when processing them.
>
> .../include/rte_ether.h:149:2: warning: converting a packed ‘const
> struct ether_addr’ pointer (alignment 1) to a ‘unaligned_uint16_t’
> {aka ‘const short unsigned int’} pointer (alignment 2) may result in
> an unaligned pointer value [-Waddress-of-packed-member]
> 149 | const unaligned_uint16_t *ea_words = (const unaligned_uint16_t *)ea;
> | ^~~~~
>
> Since ethernet addresses should always be aligned on a two-byte boundary,
I'm a bit reserved about this last assumption. The ethernet address
structure may be used in a private structure, whose alignment is 1. Are
we sure that there is no (funny) protocol that carries unaligned
ethernet addresses?
Shouldn't we change the definition of unaligned_uint16_t instead?
Or change the rte_is_broadcast_ether_addr() function?
> we can just inform the compiler of this assumption to remove the warnings
> and allow us to always access the addresses using 16-bit operations.
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
>
> ---
>
> Although this is an ABI break, the network structures are all being renamed
> in this release, and a deprecation notice was previously posted for it.
Yes, but the network renaming is identified in the release note as an
API break, not an ABI break.
> ---
> lib/librte_net/rte_ether.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_net/rte_ether.h b/lib/librte_net/rte_ether.h
> index 3a87ff184..8090b7c01 100644
> --- a/lib/librte_net/rte_ether.h
> +++ b/lib/librte_net/rte_ether.h
> @@ -55,7 +55,8 @@ extern "C" {
> * See http://standards.ieee.org/regauth/groupmac/tutorial.html
> */
> struct ether_addr {
> - uint8_t addr_bytes[ETHER_ADDR_LEN]; /**< Addr bytes in tx order */
> + /** Addr bytes in tx order */
> + uint8_t addr_bytes[ETHER_ADDR_LEN] __rte_aligned(2);
> } __attribute__((__packed__));
>
> #define ETHER_LOCAL_ADMIN_ADDR 0x02 /**< Locally assigned Eth. address. */
> --
> 2.21.0
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] ether: mark ethernet addresses as being 2-byte aligned
@ 2019-07-01 14:14 5% ` Olivier Matz
2019-07-01 14:28 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Olivier Matz @ 2019-07-01 14:14 UTC (permalink / raw)
To: Bruce Richardson; +Cc: Stephen Hemminger, DPDK Dev List
Hi Bruce,
On Mon, Jul 01, 2019 at 02:38:43PM +0100, Bruce Richardson wrote:
> On Mon, Jul 01, 2019 at 03:11:12PM +0200, Olivier Matz wrote:
> > Hi Bruce,
> >
> > On Thu, May 16, 2019 at 04:54:57PM +0100, Bruce Richardson wrote:
> > > When including the rte_ether.h header in applications with warnings
> > > enabled, a warning was given because of the assumption of 2-byte alignment
> > > of ethernet addresses when processing them.
> > >
> > > .../include/rte_ether.h:149:2: warning: converting a packed ‘const
> > > struct ether_addr’ pointer (alignment 1) to a ‘unaligned_uint16_t’
> > > {aka ‘const short unsigned int’} pointer (alignment 2) may result in
> > > an unaligned pointer value [-Waddress-of-packed-member]
> > > 149 | const unaligned_uint16_t *ea_words = (const unaligned_uint16_t *)ea;
> > > | ^~~~~
> > >
> > > Since ethernet addresses should always be aligned on a two-byte boundary,
> >
> > I'm a bit reserved about this last assumption. The ethernet address
> > structure may be used in a private structure, whose alignment is 1. Are
> > we sure that there is no (funny) protocol that carries unaligned
> > ethernet addresses?
> >
> > Shouldn't we change the definition of unaligned_uint16_t instead?
> > Or change the rte_is_broadcast_ether_addr() function?
> >
>
> We could, but I believe the correct behaviour is to make the addresses
> always 2-byte aligned, unless someone actually has a real-world case where
> there is a protocol that doesn't have the data 2-byte aligned.
Maybe you missed that part of my previous answer, I'm copy it again here:
> Although this is an ABI break, the network structures are all being renamed
> in this release, and a deprecation notice was previously posted for it.
Yes, but the network renaming is identified in the release note as an
API break, not an ABI break.
I thought we agreed to limit ABI breakages to cases where there is no
other solution. Here, this is surely a "small" ABI breakage, but I
suppose there is a way to do differently.
If we really want to do that way, it's better to announce it as an ABI
break.
Olivier
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH] ether: mark ethernet addresses as being 2-byte aligned
2019-07-01 14:14 5% ` Olivier Matz
@ 2019-07-01 14:28 0% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2019-07-01 14:28 UTC (permalink / raw)
To: Olivier Matz; +Cc: Stephen Hemminger, DPDK Dev List
On Mon, Jul 01, 2019 at 04:14:30PM +0200, Olivier Matz wrote:
> Hi Bruce,
>
> On Mon, Jul 01, 2019 at 02:38:43PM +0100, Bruce Richardson wrote:
> > On Mon, Jul 01, 2019 at 03:11:12PM +0200, Olivier Matz wrote:
> > > Hi Bruce,
> > >
> > > On Thu, May 16, 2019 at 04:54:57PM +0100, Bruce Richardson wrote:
> > > > When including the rte_ether.h header in applications with warnings
> > > > enabled, a warning was given because of the assumption of 2-byte
> > > > alignment of ethernet addresses when processing them.
> > > >
> > > > .../include/rte_ether.h:149:2: warning: converting a packed ‘const
> > > > struct ether_addr’ pointer (alignment 1) to a ‘unaligned_uint16_t’
> > > > {aka ‘const short unsigned int’} pointer (alignment 2) may result
> > > > in an unaligned pointer value [-Waddress-of-packed-member] 149 |
> > > > const unaligned_uint16_t *ea_words = (const unaligned_uint16_t
> > > > *)ea; | ^~~~~
> > > >
> > > > Since ethernet addresses should always be aligned on a two-byte
> > > > boundary,
> > >
> > > I'm a bit reserved about this last assumption. The ethernet address
> > > structure may be used in a private structure, whose alignment is 1.
> > > Are we sure that there is no (funny) protocol that carries unaligned
> > > ethernet addresses?
> > >
> > > Shouldn't we change the definition of unaligned_uint16_t instead? Or
> > > change the rte_is_broadcast_ether_addr() function?
> > >
> >
> > We could, but I believe the correct behaviour is to make the addresses
> > always 2-byte aligned, unless someone actually has a real-world case
> > where there is a protocol that doesn't have the data 2-byte aligned.
>
> Maybe you missed that part of my previous answer, I'm copy it again here:
>
> > Although this is an ABI break, the network structures are all being
> > renamed in this release, and a deprecation notice was previously
> > posted for it.
>
> Yes, but the network renaming is identified in the release note as an
> API break, not an ABI break.
>
> I thought we agreed to limit ABI breakages to cases where there is no
> other solution. Here, this is surely a "small" ABI breakage, but I
> suppose there is a way to do differently.
>
> If we really want to do that way, it's better to announce it as an ABI
> break.
>
At this stage, I'm ok with pushing this to 19.11 to follow the official
deprecation process.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v5 2/7] bbdev: extension of BBDEV API for 5G FEC
@ 2019-07-01 18:06 3% ` Nicolas Chautru
2019-07-01 18:06 2% ` [dpdk-dev] [PATCH v5 4/7] baseband/turbo_sw: extension of turbosw PMD for 5G Nicolas Chautru
1 sibling, 0 replies; 200+ results
From: Nicolas Chautru @ 2019-07-01 18:06 UTC (permalink / raw)
To: akhil.goyal, dev
Cc: ferruh.yigit, thomas, amr.mokhtar, kamilx.chalupnik, Nicolas Chautru
Extension to BBDEV operations to support 5G
on top of existing 4G operations.
Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
Acked-by: Amr Mokhtar <amr.mokhtar@intel.com>
---
doc/guides/rel_notes/release_19_08.rst | 4 +-
lib/librte_bbdev/rte_bbdev.c | 22 +-
lib/librte_bbdev/rte_bbdev.h | 138 +++++++-
lib/librte_bbdev/rte_bbdev_op.h | 567 ++++++++++++++++++++++++++-------
4 files changed, 608 insertions(+), 123 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_08.rst b/doc/guides/rel_notes/release_19_08.rst
index 335d24a..55ae8ee 100644
--- a/doc/guides/rel_notes/release_19_08.rst
+++ b/doc/guides/rel_notes/release_19_08.rst
@@ -126,7 +126,6 @@ New Features
Added telemetry mode to l3fwd-power application to report
application level busyness, empty and full polls of rte_eth_rx_burst().
-
Removed Items
-------------
@@ -192,6 +191,9 @@ ABI Changes
Disabling unused features would facilitate efficient usage of HW/SW offload.
+* bbdev: New operations and parameters added to support new 5GNR operations.
+ The bbdev ABI is still kept experimental.
+
Shared Library Versions
-----------------------
diff --git a/lib/librte_bbdev/rte_bbdev.c b/lib/librte_bbdev/rte_bbdev.c
index 0c35480..f6fe05a 100644
--- a/lib/librte_bbdev/rte_bbdev.c
+++ b/lib/librte_bbdev/rte_bbdev.c
@@ -6,7 +6,6 @@
#include <string.h>
#include <stdbool.h>
-#include <rte_string_fns.h>
#include <rte_compat.h>
#include <rte_common.h>
#include <rte_errno.h>
@@ -215,7 +214,7 @@ struct rte_bbdev *
bbdev->data->dev_id = dev_id;
bbdev->state = RTE_BBDEV_INITIALIZED;
- ret = strlcpy(bbdev->data->name, name, RTE_BBDEV_NAME_MAX_LEN);
+ ret = snprintf(bbdev->data->name, RTE_BBDEV_NAME_MAX_LEN, "%s", name);
if ((ret < 0) || (ret >= RTE_BBDEV_NAME_MAX_LEN)) {
rte_bbdev_log(ERR, "Copying device name \"%s\" failed", name);
return NULL;
@@ -499,7 +498,7 @@ struct rte_bbdev *
if (conf->op_type == RTE_BBDEV_OP_TURBO_DEC &&
conf->priority > dev_info.max_ul_queue_priority) {
rte_bbdev_log(ERR,
- "Priority (%u) of queue %u of bdev %u must be <= %u",
+ "Priority (%u) of queue %u of bbdev %u must be <= %u",
conf->priority, queue_id, dev_id,
dev_info.max_ul_queue_priority);
return -EINVAL;
@@ -507,7 +506,7 @@ struct rte_bbdev *
if (conf->op_type == RTE_BBDEV_OP_TURBO_ENC &&
conf->priority > dev_info.max_dl_queue_priority) {
rte_bbdev_log(ERR,
- "Priority (%u) of queue %u of bdev %u must be <= %u",
+ "Priority (%u) of queue %u of bbdev %u must be <= %u",
conf->priority, queue_id, dev_id,
dev_info.max_dl_queue_priority);
return -EINVAL;
@@ -796,7 +795,7 @@ struct rte_bbdev *
memset(dev_info, 0, sizeof(*dev_info));
dev_info->dev_name = dev->data->name;
dev_info->num_queues = dev->data->num_queues;
- dev_info->bus = rte_bus_find_by_device(dev->device);
+ dev_info->device = dev->device;
dev_info->socket_id = dev->data->socket_id;
dev_info->started = dev->data->started;
@@ -847,6 +846,12 @@ struct rte_bbdev *
case RTE_BBDEV_OP_TURBO_ENC:
result = sizeof(struct rte_bbdev_enc_op);
break;
+ case RTE_BBDEV_OP_LDPC_DEC:
+ result = sizeof(struct rte_bbdev_dec_op);
+ break;
+ case RTE_BBDEV_OP_LDPC_ENC:
+ result = sizeof(struct rte_bbdev_enc_op);
+ break;
default:
break;
}
@@ -861,11 +866,12 @@ struct rte_bbdev *
{
enum rte_bbdev_op_type type = *(enum rte_bbdev_op_type *)arg;
- if (type == RTE_BBDEV_OP_TURBO_DEC) {
+ if (type == RTE_BBDEV_OP_TURBO_DEC || type == RTE_BBDEV_OP_LDPC_DEC) {
struct rte_bbdev_dec_op *op = element;
memset(op, 0, mempool->elt_size);
op->mempool = mempool;
- } else if (type == RTE_BBDEV_OP_TURBO_ENC) {
+ } else if (type == RTE_BBDEV_OP_TURBO_ENC ||
+ type == RTE_BBDEV_OP_LDPC_ENC) {
struct rte_bbdev_enc_op *op = element;
memset(op, 0, mempool->elt_size);
op->mempool = mempool;
@@ -1117,6 +1123,8 @@ struct rte_mempool *
"RTE_BBDEV_OP_NONE",
"RTE_BBDEV_OP_TURBO_DEC",
"RTE_BBDEV_OP_TURBO_ENC",
+ "RTE_BBDEV_OP_LDPC_DEC",
+ "RTE_BBDEV_OP_LDPC_ENC",
};
if (op_type < RTE_BBDEV_OP_TYPE_COUNT)
diff --git a/lib/librte_bbdev/rte_bbdev.h b/lib/librte_bbdev/rte_bbdev.h
index c5175cc..591fb79 100644
--- a/lib/librte_bbdev/rte_bbdev.h
+++ b/lib/librte_bbdev/rte_bbdev.h
@@ -167,7 +167,7 @@ struct rte_bbdev_queue_conf {
/**
* Start a device.
- * This is the last step needed before enqueuing operations is possible.
+ * This is the last step needed before enqueueing operations is possible.
*
* @param dev_id
* The identifier of the device.
@@ -326,7 +326,7 @@ struct rte_bbdev_driver_info {
struct rte_bbdev_info {
int socket_id; /**< NUMA socket that device is on */
const char *dev_name; /**< Unique device name */
- const struct rte_bus *bus; /**< Bus information */
+ const struct rte_device *device; /**< Device Information */
uint16_t num_queues; /**< Number of queues currently configured */
bool started; /**< Set if device is currently started */
struct rte_bbdev_driver_info drv; /**< Info from device driver */
@@ -448,6 +448,14 @@ struct __rte_cache_aligned rte_bbdev {
rte_bbdev_dequeue_enc_ops_t dequeue_enc_ops;
/**< Dequeue decode function */
rte_bbdev_dequeue_dec_ops_t dequeue_dec_ops;
+ /**< Enqueue encode function */
+ rte_bbdev_enqueue_enc_ops_t enqueue_ldpc_enc_ops;
+ /**< Enqueue decode function */
+ rte_bbdev_enqueue_dec_ops_t enqueue_ldpc_dec_ops;
+ /**< Dequeue encode function */
+ rte_bbdev_dequeue_enc_ops_t dequeue_ldpc_enc_ops;
+ /**< Dequeue decode function */
+ rte_bbdev_dequeue_dec_ops_t dequeue_ldpc_dec_ops;
const struct rte_bbdev_ops *dev_ops; /**< Functions exported by PMD */
struct rte_bbdev_data *data; /**< Pointer to device data */
enum rte_bbdev_state state; /**< If device is currently used or not */
@@ -523,6 +531,69 @@ struct __rte_cache_aligned rte_bbdev {
}
/**
+ * Enqueue a burst of processed encode operations to a queue of the device.
+ * This functions only enqueues as many operations as currently possible and
+ * does not block until @p num_ops entries in the queue are available.
+ * This function does not provide any error notification to avoid the
+ * corresponding overhead.
+ *
+ * @param dev_id
+ * The identifier of the device.
+ * @param queue_id
+ * The index of the queue.
+ * @param ops
+ * Pointer array containing operations to be enqueued Must have at least
+ * @p num_ops entries
+ * @param num_ops
+ * The maximum number of operations to enqueue.
+ *
+ * @return
+ * The number of operations actually enqueued (this is the number of processed
+ * entries in the @p ops array).
+ */
+__rte_experimental
+static inline uint16_t
+rte_bbdev_enqueue_ldpc_enc_ops(uint16_t dev_id, uint16_t queue_id,
+ struct rte_bbdev_enc_op **ops, uint16_t num_ops)
+{
+ struct rte_bbdev *dev = &rte_bbdev_devices[dev_id];
+ struct rte_bbdev_queue_data *q_data = &dev->data->queues[queue_id];
+ return dev->enqueue_ldpc_enc_ops(q_data, ops, num_ops);
+}
+
+/**
+ * Enqueue a burst of processed decode operations to a queue of the device.
+ * This functions only enqueues as many operations as currently possible and
+ * does not block until @p num_ops entries in the queue are available.
+ * This function does not provide any error notification to avoid the
+ * corresponding overhead.
+ *
+ * @param dev_id
+ * The identifier of the device.
+ * @param queue_id
+ * The index of the queue.
+ * @param ops
+ * Pointer array containing operations to be enqueued Must have at least
+ * @p num_ops entries
+ * @param num_ops
+ * The maximum number of operations to enqueue.
+ *
+ * @return
+ * The number of operations actually enqueued (this is the number of processed
+ * entries in the @p ops array).
+ */
+__rte_experimental
+static inline uint16_t
+rte_bbdev_enqueue_ldpc_dec_ops(uint16_t dev_id, uint16_t queue_id,
+ struct rte_bbdev_dec_op **ops, uint16_t num_ops)
+{
+ struct rte_bbdev *dev = &rte_bbdev_devices[dev_id];
+ struct rte_bbdev_queue_data *q_data = &dev->data->queues[queue_id];
+ return dev->enqueue_ldpc_dec_ops(q_data, ops, num_ops);
+}
+
+
+/**
* Dequeue a burst of processed encode operations from a queue of the device.
* This functions returns only the current contents of the queue, and does not
* block until @ num_ops is available.
@@ -585,6 +656,69 @@ struct __rte_cache_aligned rte_bbdev {
return dev->dequeue_dec_ops(q_data, ops, num_ops);
}
+
+/**
+ * Dequeue a burst of processed encode operations from a queue of the device.
+ * This functions returns only the current contents of the queue, and does not
+ * block until @ num_ops is available.
+ * This function does not provide any error notification to avoid the
+ * corresponding overhead.
+ *
+ * @param dev_id
+ * The identifier of the device.
+ * @param queue_id
+ * The index of the queue.
+ * @param ops
+ * Pointer array where operations will be dequeued to. Must have at least
+ * @p num_ops entries
+ * @param num_ops
+ * The maximum number of operations to dequeue.
+ *
+ * @return
+ * The number of operations actually dequeued (this is the number of entries
+ * copied into the @p ops array).
+ */
+__rte_experimental
+static inline uint16_t
+rte_bbdev_dequeue_ldpc_enc_ops(uint16_t dev_id, uint16_t queue_id,
+ struct rte_bbdev_enc_op **ops, uint16_t num_ops)
+{
+ struct rte_bbdev *dev = &rte_bbdev_devices[dev_id];
+ struct rte_bbdev_queue_data *q_data = &dev->data->queues[queue_id];
+ return dev->dequeue_ldpc_enc_ops(q_data, ops, num_ops);
+}
+
+/**
+ * Dequeue a burst of processed decode operations from a queue of the device.
+ * This functions returns only the current contents of the queue, and does not
+ * block until @ num_ops is available.
+ * This function does not provide any error notification to avoid the
+ * corresponding overhead.
+ *
+ * @param dev_id
+ * The identifier of the device.
+ * @param queue_id
+ * The index of the queue.
+ * @param ops
+ * Pointer array where operations will be dequeued to. Must have at least
+ * @p num_ops entries
+ * @param num_ops
+ * The maximum number of operations to dequeue.
+ *
+ * @return
+ * The number of operations actually dequeued (this is the number of entries
+ * copied into the @p ops array).
+ */
+__rte_experimental
+static inline uint16_t
+rte_bbdev_dequeue_ldpc_dec_ops(uint16_t dev_id, uint16_t queue_id,
+ struct rte_bbdev_dec_op **ops, uint16_t num_ops)
+{
+ struct rte_bbdev *dev = &rte_bbdev_devices[dev_id];
+ struct rte_bbdev_queue_data *q_data = &dev->data->queues[queue_id];
+ return dev->dequeue_ldpc_dec_ops(q_data, ops, num_ops);
+}
+
/** Definitions of device event types */
enum rte_bbdev_event_type {
RTE_BBDEV_EVENT_UNKNOWN, /**< unknown event type */
diff --git a/lib/librte_bbdev/rte_bbdev_op.h b/lib/librte_bbdev/rte_bbdev_op.h
index d860989..1e119a7 100644
--- a/lib/librte_bbdev/rte_bbdev_op.h
+++ b/lib/librte_bbdev/rte_bbdev_op.h
@@ -31,57 +31,61 @@
#define RTE_BBDEV_TURBO_MAX_TB_SIZE (391656)
/* Maximum size of Code Block (36.212, Table 5.1.3-3) */
#define RTE_BBDEV_TURBO_MAX_CB_SIZE (6144)
+/* Maximum size of Code Block */
+#define RTE_BBDEV_LDPC_MAX_CB_SIZE (8448)
/* Minimum size of Code Block (36.212, Table 5.1.3-3) */
#define RTE_BBDEV_TURBO_MIN_CB_SIZE (40)
/* Maximum size of circular buffer */
#define RTE_BBDEV_TURBO_MAX_KW (18528)
/*
- * Maximum number of Code Blocks in Transport Block. It is calculated based on
- * maximum size of one Code Block and one Transport Block (considering CRC24A
- * and CRC24B):
+ * Turbo: Maximum number of Code Blocks in Transport Block. It is calculated
+ * based on maximum size of one Code Block and one Transport Block
+ * (considering CRC24A and CRC24B):
* (391656 + 24) / (6144 - 24) = 64
*/
#define RTE_BBDEV_TURBO_MAX_CODE_BLOCKS (64)
+/* LDPC: Maximum number of Code Blocks in Transport Block.*/
+#define RTE_BBDEV_LDPC_MAX_CODE_BLOCKS (256)
/** Flags for turbo decoder operation and capability structure */
enum rte_bbdev_op_td_flag_bitmasks {
- /**< If sub block de-interleaving is to be performed. */
+ /** If sub block de-interleaving is to be performed. */
RTE_BBDEV_TURBO_SUBBLOCK_DEINTERLEAVE = (1ULL << 0),
- /**< To use CRC Type 24B (otherwise use CRC Type 24A). */
+ /** To use CRC Type 24B (otherwise use CRC Type 24A). */
RTE_BBDEV_TURBO_CRC_TYPE_24B = (1ULL << 1),
- /**< If turbo equalization is to be performed. */
+ /** If turbo equalization is to be performed. */
RTE_BBDEV_TURBO_EQUALIZER = (1ULL << 2),
- /**< If set, saturate soft output to +/-127 */
+ /** If set, saturate soft output to +/-127 */
RTE_BBDEV_TURBO_SOFT_OUT_SATURATE = (1ULL << 3),
- /**< Set to 1 to start iteration from even, else odd; one iteration =
+ /** Set to 1 to start iteration from even, else odd; one iteration =
* max_iteration + 0.5
*/
RTE_BBDEV_TURBO_HALF_ITERATION_EVEN = (1ULL << 4),
- /**< If 0, TD stops after CRC matches; else if 1, runs to end of next
+ /** If 0, TD stops after CRC matches; else if 1, runs to end of next
* odd iteration after CRC matches
*/
RTE_BBDEV_TURBO_CONTINUE_CRC_MATCH = (1ULL << 5),
- /**< Set if soft output is required to be output */
+ /** Set if soft output is required to be output */
RTE_BBDEV_TURBO_SOFT_OUTPUT = (1ULL << 6),
- /**< Set to enable early termination mode */
+ /** Set to enable early termination mode */
RTE_BBDEV_TURBO_EARLY_TERMINATION = (1ULL << 7),
- /**< Set if a device supports decoder dequeue interrupts */
+ /** Set if a device supports decoder dequeue interrupts */
RTE_BBDEV_TURBO_DEC_INTERRUPTS = (1ULL << 9),
- /**< Set if positive LLR encoded input is supported. Positive LLR value
+ /** Set if positive LLR encoded input is supported. Positive LLR value
* represents the level of confidence for bit '1', and vice versa for
* bit '0'.
* This is mutually exclusive with RTE_BBDEV_TURBO_NEG_LLR_1_BIT_IN
* when used to formalize the input data format.
*/
RTE_BBDEV_TURBO_POS_LLR_1_BIT_IN = (1ULL << 10),
- /**< Set if negative LLR encoded input is supported. Negative LLR value
+ /** Set if negative LLR encoded input is supported. Negative LLR value
* represents the level of confidence for bit '1', and vice versa for
* bit '0'.
* This is mutually exclusive with RTE_BBDEV_TURBO_POS_LLR_1_BIT_IN
* when used to formalize the input data format.
*/
RTE_BBDEV_TURBO_NEG_LLR_1_BIT_IN = (1ULL << 11),
- /**< Set if positive LLR soft output is supported. Positive LLR value
+ /** Set if positive LLR soft output is supported. Positive LLR value
* represents the level of confidence for bit '1', and vice versa for
* bit '0'.
* This is mutually exclusive with
@@ -89,7 +93,7 @@ enum rte_bbdev_op_td_flag_bitmasks {
* the input data format.
*/
RTE_BBDEV_TURBO_POS_LLR_1_BIT_SOFT_OUT = (1ULL << 12),
- /**< Set if negative LLR soft output is supported. Negative LLR value
+ /** Set if negative LLR soft output is supported. Negative LLR value
* represents the level of confidence for bit '1', and vice versa for
* bit '0'.
* This is mutually exclusive with
@@ -97,43 +101,114 @@ enum rte_bbdev_op_td_flag_bitmasks {
* input data format.
*/
RTE_BBDEV_TURBO_NEG_LLR_1_BIT_SOFT_OUT = (1ULL << 13),
- /**< Set if driver supports flexible parallel MAP engine decoding. If
+ /** Set if driver supports flexible parallel MAP engine decoding. If
* not supported, num_maps (number of MAP engines) argument is unusable.
*/
RTE_BBDEV_TURBO_MAP_DEC = (1ULL << 14),
- /**< Set if a device supports scatter-gather functionality */
+ /** Set if a device supports scatter-gather functionality */
RTE_BBDEV_TURBO_DEC_SCATTER_GATHER = (1ULL << 15),
- /**< Set to keep CRC24B bits appended while decoding. Only usable when
+ /** Set to keep CRC24B bits appended while decoding. Only usable when
* decoding Transport Blocks (code_block_mode = 0).
*/
RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP = (1ULL << 16)
};
+
/** Flags for turbo encoder operation and capability structure */
enum rte_bbdev_op_te_flag_bitmasks {
- /**< Ignore rv_index and set K0 = 0 */
+ /** Ignore rv_index and set K0 = 0 */
RTE_BBDEV_TURBO_RV_INDEX_BYPASS = (1ULL << 0),
- /**< If rate matching is to be performed */
+ /** If rate matching is to be performed */
RTE_BBDEV_TURBO_RATE_MATCH = (1ULL << 1),
- /**< This bit must be set to enable CRC-24B generation */
+ /** This bit must be set to enable CRC-24B generation */
RTE_BBDEV_TURBO_CRC_24B_ATTACH = (1ULL << 2),
- /**< This bit must be set to enable CRC-24A generation */
+ /** This bit must be set to enable CRC-24A generation */
RTE_BBDEV_TURBO_CRC_24A_ATTACH = (1ULL << 3),
- /**< Set if a device supports encoder dequeue interrupts */
+ /** Set if a device supports encoder dequeue interrupts */
RTE_BBDEV_TURBO_ENC_INTERRUPTS = (1ULL << 4),
- /**< Set if a device supports scatter-gather functionality */
+ /** Set if a device supports scatter-gather functionality */
RTE_BBDEV_TURBO_ENC_SCATTER_GATHER = (1ULL << 5)
};
-/**< Data input and output buffer for BBDEV operations */
+/** Flags for LDPC decoder operation and capability structure */
+enum rte_bbdev_op_ldpcdec_flag_bitmasks {
+ /** Set for transport block CRC-24A checking */
+ RTE_BBDEV_LDPC_CRC_TYPE_24A_CHECK = (1ULL << 0),
+ /** Set for code block CRC-24B checking */
+ RTE_BBDEV_LDPC_CRC_TYPE_24B_CHECK = (1ULL << 1),
+ /** Set to drop the last CRC bits decoding output */
+ RTE_BBDEV_LDPC_CRC_TYPE_24B_DROP = (1ULL << 2),
+ /** Set for bit-level de-interleaver bypass on Rx stream. */
+ RTE_BBDEV_LDPC_DEINTERLEAVER_BYPASS = (1ULL << 3),
+ /** Set for HARQ combined input stream enable. */
+ RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE = (1ULL << 4),
+ /** Set for HARQ combined output stream enable. */
+ RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE = (1ULL << 5),
+ /** Set for LDPC decoder bypass.
+ * RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE must be set.
+ */
+ RTE_BBDEV_LDPC_DECODE_BYPASS = (1ULL << 6),
+ /** Set for soft-output stream enable */
+ RTE_BBDEV_LDPC_SOFT_OUT_ENABLE = (1ULL << 7),
+ /** Set for Rate-Matching bypass on soft-out stream. */
+ RTE_BBDEV_LDPC_SOFT_OUT_RM_BYPASS = (1ULL << 8),
+ /** Set for bit-level de-interleaver bypass on soft-output stream. */
+ RTE_BBDEV_LDPC_SOFT_OUT_DEINTERLEAVER_BYPASS = (1ULL << 9),
+ /** Set for iteration stopping on successful decode condition
+ * i.e. a successful syndrome check.
+ */
+ RTE_BBDEV_LDPC_ITERATION_STOP_ENABLE = (1ULL << 10),
+ /** Set if a device supports decoder dequeue interrupts. */
+ RTE_BBDEV_LDPC_DEC_INTERRUPTS = (1ULL << 11),
+ /** Set if a device supports scatter-gather functionality. */
+ RTE_BBDEV_LDPC_DEC_SCATTER_GATHER = (1ULL << 12),
+ /** Set if a device supports input/output HARQ compression. */
+ RTE_BBDEV_LDPC_HARQ_6BIT_COMPRESSION = (1ULL << 13),
+ /** Set if a device supports input LLR compression. */
+ RTE_BBDEV_LDPC_LLR_COMPRESSION = (1ULL << 14),
+ /** Set if a device supports HARQ input from
+ * device's internal memory.
+ */
+ RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_IN_ENABLE = (1ULL << 15),
+ /** Set if a device supports HARQ output to
+ * device's internal memory.
+ */
+ RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_OUT_ENABLE = (1ULL << 16),
+ /** Set if a device supports loop-back access to
+ * HARQ internal memory. Intended for troubleshooting.
+ */
+ RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_LOOPBACK = (1ULL << 17)
+};
+
+/** Flags for LDPC encoder operation and capability structure */
+enum rte_bbdev_op_ldpcenc_flag_bitmasks {
+ /** Set for bit-level interleaver bypass on output stream. */
+ RTE_BBDEV_LDPC_INTERLEAVER_BYPASS = (1ULL << 0),
+ /** If rate matching is to be performed */
+ RTE_BBDEV_LDPC_RATE_MATCH = (1ULL << 1),
+ /** Set for transport block CRC-24A attach */
+ RTE_BBDEV_LDPC_CRC_24A_ATTACH = (1ULL << 2),
+ /** Set for code block CRC-24B attach */
+ RTE_BBDEV_LDPC_CRC_24B_ATTACH = (1ULL << 3),
+ /** Set for code block CRC-16 attach */
+ RTE_BBDEV_LDPC_CRC_16_ATTACH = (1ULL << 4),
+ /** Set if a device supports encoder dequeue interrupts. */
+ RTE_BBDEV_LDPC_ENC_INTERRUPTS = (1ULL << 5),
+ /** Set if a device supports scatter-gather functionality. */
+ RTE_BBDEV_LDPC_ENC_SCATTER_GATHER = (1ULL << 6),
+ /** Set if a device supports concatenation of non byte aligned output */
+ RTE_BBDEV_LDPC_ENC_CONCATENATION = (1ULL << 7)
+};
+
+/** Data input and output buffer for BBDEV operations */
struct rte_bbdev_op_data {
- /**< The mbuf data structure representing the data for BBDEV operation.
+ /** The mbuf data structure representing the data for BBDEV operation.
*
* This mbuf pointer can point to one Code Block (CB) data buffer or
* multiple CBs contiguously located next to each other.
* A Transport Block (TB) represents a whole piece of data that is
* divided into one or more CBs. Maximum number of CBs can be contained
- * in one TB is defined by RTE_BBDEV_TURBO_MAX_CODE_BLOCKS.
+ * in one TB is defined by RTE_BBDEV_(TURBO/LDPC)_MAX_CODE_BLOCKS.
*
* An mbuf data structure cannot represent more than one TB. The
* smallest piece of data that can be contained in one mbuf is one CB.
@@ -145,8 +220,8 @@ struct rte_bbdev_op_data {
* then it is capable of collecting (gathering) non-contiguous
* (scattered) data from multiple locations in the memory.
* This capability is reported by the capability flags:
- * - RTE_BBDEV_TURBO_ENC_SCATTER_GATHER and
- * - RTE_BBDEV_TURBO_DEC_SCATTER_GATHER.
+ * - RTE_BBDEV_(TURBO/LDPC)_ENC_SCATTER_GATHER and
+ * - RTE_BBDEV_(TURBO/LDPC)_DEC_SCATTER_GATHER.
* Only if a BBDEV PMD supports this feature, chained mbuf data
* structures are accepted. A chained mbuf can represent one
* non-contiguous CB or multiple non-contiguous CBs.
@@ -157,7 +232,7 @@ struct rte_bbdev_op_data {
* was a chained mbuf.
*/
struct rte_mbuf *data;
- /**< The starting point of the BBDEV (encode/decode) operation,
+ /** The starting point of the BBDEV (encode/decode) operation,
* in bytes.
*
* BBDEV starts to read data past this offset.
@@ -165,13 +240,13 @@ struct rte_bbdev_op_data {
* segment.
*/
uint32_t offset;
- /**< The total data length to be processed in one operation, in bytes.
+ /** The total data length to be processed in one operation, in bytes.
*
* In case the mbuf data is representing one CB, this is the length of
* the CB undergoing the operation.
* If it's for multiple CBs, this is the total length of those CBs
* undergoing the operation.
- * If it's for one TB, this is the total length of the TB under
+ * If it is for one TB, this is the total length of the TB under
* operation.
*
* In case of chained mbuf, this data length includes the lengths of the
@@ -180,51 +255,83 @@ struct rte_bbdev_op_data {
uint32_t length;
};
-struct rte_bbdev_op_dec_cb_params {
- /**< The K size of the input CB, in bits [40:6144], as specified in
+/** Turbo decode code block parameters */
+struct rte_bbdev_op_dec_turbo_cb_params {
+ /** The K size of the input CB, in bits [40:6144], as specified in
* 3GPP TS 36.212.
* This size is inclusive of CRC bits, regardless whether it was
* pre-calculated by the application or not.
*/
uint16_t k;
- /**< The E length of the CB rate matched LLR output, in bytes, as in
+ /** The E length of the CB rate matched LLR output, in bytes, as in
* 3GPP TS 36.212.
*/
uint32_t e;
};
-struct rte_bbdev_op_dec_tb_params {
- /**< The K- size of the input CB, in bits [40:6144], that is in the
+/** LDPC decode code block parameters */
+struct rte_bbdev_op_dec_ldpc_cb_params {
+ /** Rate matching output sequence length in bits or LLRs.
+ * [3GPP TS38.212, section 5.4.2.1]
+ */
+ uint32_t e;
+};
+
+/** Turbo decode transport block parameters */
+struct rte_bbdev_op_dec_turbo_tb_params {
+ /** The K- size of the input CB, in bits [40:6144], that is in the
* Turbo operation when r < C-, as in 3GPP TS 36.212.
*/
uint16_t k_neg;
- /**< The K+ size of the input CB, in bits [40:6144], that is in the
+ /** The K+ size of the input CB, in bits [40:6144], that is in the
* Turbo operation when r >= C-, as in 3GPP TS 36.212.
*/
uint16_t k_pos;
- /**< The number of CBs that have K- size, [0:63] */
+ /** The number of CBs that have K- size, [0:63] */
uint8_t c_neg;
- /**< The total number of CBs in the TB, [1:RTE_BBDEV_TURBO_MAX_CODE_BLOCKS] */
+ /** The total number of CBs in the TB,
+ * [1:RTE_BBDEV_TURBO_MAX_CODE_BLOCKS]
+ */
uint8_t c;
- /**< The number of CBs that uses Ea before switching to Eb, [0:63] */
+ /** The number of CBs that uses Ea before switching to Eb, [0:63] */
uint8_t cab;
- /**< The E size of the CB rate matched output to use in the Turbo
+ /** The E size of the CB rate matched output to use in the Turbo
* operation when r < cab
*/
uint32_t ea;
- /**< The E size of the CB rate matched output to use in the Turbo
+ /** The E size of the CB rate matched output to use in the Turbo
* operation when r >= cab
*/
uint32_t eb;
- /**< The index of the first CB in the inbound mbuf data, default is 0 */
+ /** The index of the first CB in the inbound mbuf data, default is 0 */
uint8_t r;
};
-/**< Operation structure for Turbo decode.
- * An operation can perform on one CB at a time "CB-mode".
- * An operation can perform on one or multiple CBs that are logically belonging
- * to one TB "TB-mode".
- * The provided K size parameter of the CB is its size out coming from the
+/** LDPC decode transport block parameters */
+struct rte_bbdev_op_dec_ldpc_tb_params {
+ /** Ea, length after rate matching in bits, r < cab.
+ * [3GPP TS38.212, section 5.4.2.1]
+ */
+ uint32_t ea;
+ /** Eb, length after rate matching in bits, r >= cab.
+ * [3GPP TS38.212, section 5.4.2.1]
+ */
+ uint32_t eb;
+ /** The total number of CBs in the TB or partial TB
+ * [1:RTE_BBDEV_LDPC_MAX_CODE_BLOCKS]
+ */
+ uint8_t c;
+ /** The index of the first CB in the inbound mbuf data, default is 0 */
+ uint8_t r;
+ /** The number of CBs that use Ea before switching to Eb, [0:63] */
+ uint8_t cab;
+};
+
+/** Operation structure for Turbo decode.
+ * An operation can be performed on one CB at a time "CB-mode".
+ * An operation can be performed on one or multiple CBs that logically
+ * belong to one TB "TB-mode".
+ * The provided K size parameter of the CB is its size coming from the
* decode operation.
* CRC24A/B check is requested by the application by setting the flag
* RTE_BBDEV_TURBO_CRC_TYPE_24B for CRC24B check or CRC24A otherwise.
@@ -249,94 +356,192 @@ struct rte_bbdev_op_dec_tb_params {
* application with enough room for the output data.
*/
struct rte_bbdev_op_turbo_dec {
- /**< The Virtual Circular Buffer, wk, size 3*Kpi for each CB */
+ /** The Virtual Circular Buffer, wk, size 3*Kpi for each CB */
struct rte_bbdev_op_data input;
- /**< The hard decisions buffer for the decoded output,
+ /** The hard decisions buffer for the decoded output,
* size K for each CB
*/
struct rte_bbdev_op_data hard_output;
- /**< The soft LLR output buffer - optional */
+ /** The soft LLR output buffer - optional */
struct rte_bbdev_op_data soft_output;
- uint32_t op_flags; /**< Flags from rte_bbdev_op_td_flag_bitmasks */
- uint8_t rv_index; /**< Rv index for rate matching [0:3] */
- /**< The minimum number of iterations to perform in decoding all CBs in
+ /** Flags from rte_bbdev_op_td_flag_bitmasks */
+ uint32_t op_flags;
+
+ /** Rv index for rate matching [0:3] */
+ uint8_t rv_index;
+ /** The minimum number of iterations to perform in decoding all CBs in
* this operation - input
*/
uint8_t iter_min:4;
- /**< The maximum number of iterations to perform in decoding all CBs in
+ /** The maximum number of iterations to perform in decoding all CBs in
* this operation - input
*/
uint8_t iter_max:4;
- /**< The maximum number of iterations that were perform in decoding all
- * CBs in this decode operation - output
+ /** The maximum number of iterations that were performed in decoding
+ * all CBs in this decode operation - output
*/
uint8_t iter_count;
- /**< 5 bit extrinsic scale (scale factor on extrinsic info) */
+ /** 5 bit extrinsic scale (scale factor on extrinsic info) */
uint8_t ext_scale;
- /**< Number of MAP engines to use in decode,
- * must be power of 2 (or 0 to auto-select)
+ /** Number of MAP engines to use in decode,
+ * must be power of 2 (or 0 to auto-select)
*/
uint8_t num_maps;
- uint8_t code_block_mode; /**< [0 - TB : 1 - CB] */
+ /**< [0 - TB : 1 - CB] */
+ uint8_t code_block_mode;
union {
/**< Struct which stores Code Block specific parameters */
- struct rte_bbdev_op_dec_cb_params cb_params;
+ struct rte_bbdev_op_dec_turbo_cb_params cb_params;
/**< Struct which stores Transport Block specific parameters */
- struct rte_bbdev_op_dec_tb_params tb_params;
+ struct rte_bbdev_op_dec_turbo_tb_params tb_params;
};
};
+/** Operation structure for LDPC decode.
+ *
+ * An operation can be performed on one CB at a time "CB-mode".
+ * An operation can also be performed on one or multiple CBs that logically
+ * belong to a TB "TB-mode" (Currently not supported).
+ *
+ * The input encoded CB data is the Virtual Circular Buffer data stream.
+ *
+ * Each byte in the input circular buffer is the LLR value of each bit of the
+ * original CB.
+ *
+ * Hard output is a mandatory capability that all BBDEV PMDs support. This is
+ * the decoded CBs (CRC24A/B is the last 24-bit in each decoded CB).
+ *
+ * Soft output is an optional capability for BBDEV PMDs. If supported, an LLR
+ * rate matched output is computed in the soft_output buffer structure.
+ * These are A Posteriori Probabilities (APP) LLR samples for coded bits.
+ *
+ * HARQ combined output is an optional capability for BBDEV PMDs.
+ * If supported, a LLR output is streamed to the harq_combined_output
+ * buffer.
+ *
+ * HARQ combined input is an optional capability for BBDEV PMDs.
+ * If supported, a LLR input is streamed from the harq_combined_input
+ * buffer.
+ *
+ * The output mbuf data structure is expected to be allocated by the
+ * application with enough room for the output data.
+ */
+struct rte_bbdev_op_ldpc_dec {
+ /** The Virtual Circular Buffer for this code block, one LLR
+ * per bit of the original CB.
+ */
+ struct rte_bbdev_op_data input;
+ /** The hard decisions buffer for the decoded output,
+ * size K for each CB
+ */
+ struct rte_bbdev_op_data hard_output;
+ /** The soft LLR output LLR stream buffer - optional */
+ struct rte_bbdev_op_data soft_output;
+ /** The HARQ combined LLR stream input buffer - optional */
+ struct rte_bbdev_op_data harq_combined_input;
+ /** The HARQ combined LLR stream output buffer - optional */
+ struct rte_bbdev_op_data harq_combined_output;
+
+ /** Flags from rte_bbdev_op_ldpcdec_flag_bitmasks */
+ uint32_t op_flags;
+
+ /** Rate matching redundancy version
+ * [3GPP TS38.212, section 5.4.2.1]
+ */
+ uint8_t rv_index;
+ /** The maximum number of iterations to perform in decoding CB in
+ * this operation - input
+ */
+ uint8_t iter_max;
+ /** The number of iterations that were performed in decoding
+ * CB in this decode operation - output
+ */
+ uint8_t iter_count;
+ /** 1: LDPC Base graph 1, 2: LDPC Base graph 2.
+ * [3GPP TS38.212, section 5.2.2]
+ */
+ uint8_t basegraph;
+ /** Zc, LDPC lifting size.
+ * [3GPP TS38.212, section 5.2.2]
+ */
+ uint16_t z_c;
+ /** Ncb, length of the circular buffer in bits.
+ * [3GPP TS38.212, section 5.4.2.1]
+ */
+ uint16_t n_cb;
+ /** Qm, modulation order {1,2,4,6,8}.
+ * [3GPP TS38.212, section 5.4.2.2]
+ */
+ uint8_t q_m;
+ /** Number of Filler bits, n_filler = K – K’
+ * [3GPP TS38.212 section 5.2.2]
+ */
+ uint16_t n_filler;
+ /** [0 - TB : 1 - CB] */
+ uint8_t code_block_mode;
+ union {
+ /** Struct which stores Code Block specific parameters */
+ struct rte_bbdev_op_dec_ldpc_cb_params cb_params;
+ /** Struct which stores Transport Block specific parameters */
+ struct rte_bbdev_op_dec_ldpc_tb_params tb_params;
+ };
+};
+
+/** Turbo encode code block parameters */
struct rte_bbdev_op_enc_turbo_cb_params {
- /**< The K size of the input CB, in bits [40:6144], as specified in
+ /** The K size of the input CB, in bits [40:6144], as specified in
* 3GPP TS 36.212.
* This size is inclusive of CRC24A, regardless whether it was
* pre-calculated by the application or not.
*/
uint16_t k;
- /**< The E length of the CB rate matched output, in bits, as in
+ /** The E length of the CB rate matched output, in bits, as in
* 3GPP TS 36.212.
*/
uint32_t e;
- /**< The Ncb soft buffer size of the CB rate matched output [K:3*Kpi],
+ /** The Ncb soft buffer size of the CB rate matched output [K:3*Kpi],
* in bits, as specified in 3GPP TS 36.212.
*/
uint16_t ncb;
};
+/** Turbo encode transport block parameters */
struct rte_bbdev_op_enc_turbo_tb_params {
- /**< The K- size of the input CB, in bits [40:6144], that is in the
+ /** The K- size of the input CB, in bits [40:6144], that is in the
* Turbo operation when r < C-, as in 3GPP TS 36.212.
* This size is inclusive of CRC24B, regardless whether it was
* pre-calculated and appended by the application or not.
*/
uint16_t k_neg;
- /**< The K+ size of the input CB, in bits [40:6144], that is in the
+ /** The K+ size of the input CB, in bits [40:6144], that is in the
* Turbo operation when r >= C-, as in 3GPP TS 36.212.
* This size is inclusive of CRC24B, regardless whether it was
* pre-calculated and appended by the application or not.
*/
uint16_t k_pos;
- /**< The number of CBs that have K- size, [0:63] */
+ /** The number of CBs that have K- size, [0:63] */
uint8_t c_neg;
- /**< The total number of CBs in the TB, [1:RTE_BBDEV_TURBO_MAX_CODE_BLOCKS] */
+ /** The total number of CBs in the TB,
+ * [1:RTE_BBDEV_TURBO_MAX_CODE_BLOCKS]
+ */
uint8_t c;
- /**< The number of CBs that uses Ea before switching to Eb, [0:63] */
+ /** The number of CBs that uses Ea before switching to Eb, [0:63] */
uint8_t cab;
- /**< The E size of the CB rate matched output to use in the Turbo
+ /** The E size of the CB rate matched output to use in the Turbo
* operation when r < cab
*/
uint32_t ea;
- /**< The E size of the CB rate matched output to use in the Turbo
+ /** The E size of the CB rate matched output to use in the Turbo
* operation when r >= cab
*/
uint32_t eb;
- /**< The Ncb soft buffer size for the rate matched CB that is used in
+ /** The Ncb soft buffer size for the rate matched CB that is used in
* the Turbo operation when r < C-, [K:3*Kpi]
*/
uint16_t ncb_neg;
- /**< The Ncb soft buffer size for the rate matched CB that is used in
+ /** The Ncb soft buffer size for the rate matched CB that is used in
* the Turbo operation when r >= C-, [K:3*Kpi]
*/
uint16_t ncb_pos;
@@ -344,10 +549,38 @@ struct rte_bbdev_op_enc_turbo_tb_params {
uint8_t r;
};
-/**< Operation structure for Turbo encode.
- * An operation can perform on one CB at a time "CB-mode".
- * An operation can perform on one or multiple CBs that are logically
- * belonging to one TB "TB-mode".
+/** LDPC encode code block parameters */
+struct rte_bbdev_op_enc_ldpc_cb_params {
+ /** E, length after rate matching in bits.
+ * [3GPP TS38.212, section 5.4.2.1]
+ */
+ uint32_t e;
+};
+
+/** LDPC encode transport block parameters */
+struct rte_bbdev_op_enc_ldpc_tb_params {
+ /** Ea, length after rate matching in bits, r < cab.
+ * [3GPP TS38.212, section 5.4.2.1]
+ */
+ uint32_t ea;
+ /** Eb, length after rate matching in bits, r >= cab.
+ * [3GPP TS38.212, section 5.4.2.1]
+ */
+ uint32_t eb;
+ /** The total number of CBs in the TB or partial TB
+ * [1:RTE_BBDEV_LDPC_MAX_CODE_BLOCKS]
+ */
+ uint8_t c;
+ /** The index of the first CB in the inbound mbuf data, default is 0 */
+ uint8_t r;
+ /** The number of CBs that use Ea before switching to Eb, [0:63] */
+ uint8_t cab;
+};
+
+/** Operation structure for Turbo encode.
+ * An operation can be performed on one CB at a time "CB-mode".
+ * An operation can pbe erformd on one or multiple CBs that logically
+ * belong to one TB "TB-mode".
*
* In CB-mode, CRC24A/B is an optional operation. K size parameter is not
* affected by CRC24A/B inclusion, this only affects the inbound mbuf data
@@ -364,44 +597,131 @@ struct rte_bbdev_op_enc_turbo_tb_params {
* application with enough room for the output data.
*/
struct rte_bbdev_op_turbo_enc {
- /**< The input CB or TB data */
+ /** The input CB or TB data */
struct rte_bbdev_op_data input;
- /**< The rate matched CB or TB output buffer */
+ /** The rate matched CB or TB output buffer */
struct rte_bbdev_op_data output;
+ /** Flags from rte_bbdev_op_te_flag_bitmasks */
+ uint32_t op_flags;
- uint32_t op_flags; /**< Flags from rte_bbdev_op_te_flag_bitmasks */
- uint8_t rv_index; /**< Rv index for rate matching [0:3] */
-
- uint8_t code_block_mode; /**< [0 - TB : 1 - CB] */
+ /** Rv index for rate matching [0:3] */
+ uint8_t rv_index;
+ /** [0 - TB : 1 - CB] */
+ uint8_t code_block_mode;
union {
- /**< Struct which stores Code Block specific parameters */
+ /** Struct which stores Code Block specific parameters */
struct rte_bbdev_op_enc_turbo_cb_params cb_params;
- /**< Struct which stores Transport Block specific parameters */
+ /** Struct which stores Transport Block specific parameters */
struct rte_bbdev_op_enc_turbo_tb_params tb_params;
};
};
-/**< List of the capabilities for the Turbo Decoder */
+/** Operation structure for LDPC encode.
+ * An operation can be performed on one CB at a time "CB-mode".
+ * An operation can be performed on one or multiple CBs that logically
+ * belong to a TB "TB-mode".
+ *
+ * The input data is the CB or TB input to the decoder.
+ *
+ * The output data is the ratematched CB or TB data, or the output after
+ * bit-selection if RTE_BBDEV_LDPC_INTERLEAVER_BYPASS is set.
+ *
+ * The output mbuf data structure is expected to be allocated by the
+ * application with enough room for the output data.
+ */
+struct rte_bbdev_op_ldpc_enc {
+ /** The input TB or CB data */
+ struct rte_bbdev_op_data input;
+ /** The rate matched TB or CB output buffer */
+ struct rte_bbdev_op_data output;
+
+ /** Flags from rte_bbdev_op_ldpcenc_flag_bitmasks */
+ uint32_t op_flags;
+
+ /** Rate matching redundancy version */
+ uint8_t rv_index;
+ /** 1: LDPC Base graph 1, 2: LDPC Base graph 2.
+ * [3GPP TS38.212, section 5.2.2]
+ */
+ uint8_t basegraph;
+ /** Zc, LDPC lifting size.
+ * [3GPP TS38.212, section 5.2.2]
+ */
+ uint16_t z_c;
+ /** Ncb, length of the circular buffer in bits.
+ * [3GPP TS38.212, section 5.4.2.1]
+ */
+ uint16_t n_cb;
+ /** Qm, modulation order {2,4,6,8,10}.
+ * [3GPP TS38.212, section 5.4.2.2]
+ */
+ uint8_t q_m;
+ /** Number of Filler bits, n_filler = K – K’
+ * [3GPP TS38.212 section 5.2.2]
+ */
+ uint16_t n_filler;
+ /** [0 - TB : 1 - CB] */
+ uint8_t code_block_mode;
+ union {
+ /** Struct which stores Code Block specific parameters */
+ struct rte_bbdev_op_enc_ldpc_cb_params cb_params;
+ /** Struct which stores Transport Block specific parameters */
+ struct rte_bbdev_op_enc_ldpc_tb_params tb_params;
+ };
+};
+
+/** List of the capabilities for the Turbo Decoder */
struct rte_bbdev_op_cap_turbo_dec {
- /**< Flags from rte_bbdev_op_td_flag_bitmasks */
+ /** Flags from rte_bbdev_op_td_flag_bitmasks */
uint32_t capability_flags;
/** Maximal LLR absolute value. Acceptable LLR values lie in range
* [-max_llr_modulus, max_llr_modulus].
*/
int8_t max_llr_modulus;
+ /** Num input code block buffers */
uint8_t num_buffers_src; /**< Num input code block buffers */
- /**< Num hard output code block buffers */
+ /** Num hard output code block buffers */
uint8_t num_buffers_hard_out;
- /**< Num soft output code block buffers if supported by the driver */
+ /** Num soft output code block buffers if supported by the driver */
uint8_t num_buffers_soft_out;
};
-/**< List of the capabilities for the Turbo Encoder */
+/** List of the capabilities for the Turbo Encoder */
struct rte_bbdev_op_cap_turbo_enc {
- /**< Flags from rte_bbdev_op_te_flag_bitmasks */
+ /** Flags from rte_bbdev_op_te_flag_bitmasks */
uint32_t capability_flags;
- uint8_t num_buffers_src; /**< Num input code block buffers */
- uint8_t num_buffers_dst; /**< Num output code block buffers */
+ /** Num input code block buffers */
+ uint8_t num_buffers_src;
+ /** Num output code block buffers */
+ uint8_t num_buffers_dst;
+};
+
+/** List of the capabilities for the LDPC Decoder */
+struct rte_bbdev_op_cap_ldpc_dec {
+ /** Flags from rte_bbdev_op_ldpcdec_flag_bitmasks */
+ uint32_t capability_flags;
+ /** LLR size in bits. LLR is a two’s complement number. */
+ int8_t llr_size;
+ /** LLR numbers of decimals bit for arithmetic representation */
+ int8_t llr_decimals;
+ /** Amount of memory for HARQ in external DDR in MB */
+ uint16_t harq_memory_size;
+ /** Num input code block buffers */
+ uint16_t num_buffers_src;
+ /** Num hard output code block buffers */
+ uint16_t num_buffers_hard_out;
+ /** Num soft output code block buffers if supported by the driver */
+ uint16_t num_buffers_soft_out;
+};
+
+/** List of the capabilities for the LDPC Encoder */
+struct rte_bbdev_op_cap_ldpc_enc {
+ /** Flags from rte_bbdev_op_ldpcenc_flag_bitmasks */
+ uint32_t capability_flags;
+ /** Num input code block buffers */
+ uint16_t num_buffers_src;
+ /** Num output code block buffers */
+ uint16_t num_buffers_dst;
};
/** Different operation types supported by the device */
@@ -409,40 +729,59 @@ enum rte_bbdev_op_type {
RTE_BBDEV_OP_NONE, /**< Dummy operation that does nothing */
RTE_BBDEV_OP_TURBO_DEC, /**< Turbo decode */
RTE_BBDEV_OP_TURBO_ENC, /**< Turbo encode */
+ RTE_BBDEV_OP_LDPC_DEC, /**< LDPC decode */
+ RTE_BBDEV_OP_LDPC_ENC, /**< LDPC encode */
RTE_BBDEV_OP_TYPE_COUNT, /**< Count of different op types */
};
-/**< Bit indexes of possible errors reported through status field */
+/** Bit indexes of possible errors reported through status field */
enum {
RTE_BBDEV_DRV_ERROR,
RTE_BBDEV_DATA_ERROR,
RTE_BBDEV_CRC_ERROR,
+ RTE_BBDEV_SYNDROME_ERROR
};
-/**< Structure specifying a single encode operation */
+/** Structure specifying a single encode operation */
struct rte_bbdev_enc_op {
- int status; /**< Status of operation that was performed */
- struct rte_mempool *mempool; /**< Mempool which op instance is in */
- void *opaque_data; /**< Opaque pointer for user data */
- /**< Contains encoder specific parameters */
- struct rte_bbdev_op_turbo_enc turbo_enc;
+ /**< Status of operation that was performed */
+ int status;
+ /**< Mempool which op instance is in */
+ struct rte_mempool *mempool;
+ /**< Opaque pointer for user data */
+ void *opaque_data;
+ union {
+ /** Contains turbo decoder specific parameters */
+ struct rte_bbdev_op_turbo_enc turbo_enc;
+ /** Contains LDPC decoder specific parameters */
+ struct rte_bbdev_op_ldpc_enc ldpc_enc;
+ };
};
-/**< Structure specifying a single decode operation */
+/** Structure specifying a single decode operation */
struct rte_bbdev_dec_op {
- int status; /**< Status of operation that was performed */
- struct rte_mempool *mempool; /**< Mempool which op instance is in */
- void *opaque_data; /**< Opaque pointer for user data */
- /**< Contains decoder specific parameters */
- struct rte_bbdev_op_turbo_dec turbo_dec;
+ /** Status of operation that was performed */
+ int status;
+ /** Mempool which op instance is in */
+ struct rte_mempool *mempool;
+ /** Opaque pointer for user data */
+ void *opaque_data;
+ union {
+ /** Contains turbo decoder specific parameters */
+ struct rte_bbdev_op_turbo_dec turbo_dec;
+ /** Contains LDPC decoder specific parameters */
+ struct rte_bbdev_op_ldpc_dec ldpc_dec;
+ };
};
-/**< Operation capabilities supported by a device */
+/** Operation capabilities supported by a device */
struct rte_bbdev_op_cap {
enum rte_bbdev_op_type type; /**< Type of operation */
union {
struct rte_bbdev_op_cap_turbo_dec turbo_dec;
struct rte_bbdev_op_cap_turbo_enc turbo_enc;
+ struct rte_bbdev_op_cap_ldpc_dec ldpc_dec;
+ struct rte_bbdev_op_cap_ldpc_enc ldpc_enc;
} cap; /**< Operation-type specific capabilities */
};
@@ -516,7 +855,8 @@ struct rte_mempool *
/* Check type */
priv = (struct rte_bbdev_op_pool_private *)
rte_mempool_get_priv(mempool);
- if (unlikely(priv->type != RTE_BBDEV_OP_TURBO_ENC))
+ if (unlikely((priv->type != RTE_BBDEV_OP_TURBO_ENC) &&
+ (priv->type != RTE_BBDEV_OP_LDPC_ENC)))
return -EINVAL;
/* Get elements */
@@ -552,7 +892,8 @@ struct rte_mempool *
/* Check type */
priv = (struct rte_bbdev_op_pool_private *)
rte_mempool_get_priv(mempool);
- if (unlikely(priv->type != RTE_BBDEV_OP_TURBO_DEC))
+ if (unlikely((priv->type != RTE_BBDEV_OP_TURBO_DEC) &&
+ (priv->type != RTE_BBDEV_OP_LDPC_DEC)))
return -EINVAL;
/* Get elements */
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v5 4/7] baseband/turbo_sw: extension of turbosw PMD for 5G
2019-07-01 18:06 3% ` [dpdk-dev] [PATCH v5 2/7] bbdev: extension of BBDEV API for 5G FEC Nicolas Chautru
@ 2019-07-01 18:06 2% ` Nicolas Chautru
1 sibling, 0 replies; 200+ results
From: Nicolas Chautru @ 2019-07-01 18:06 UTC (permalink / raw)
To: akhil.goyal, dev
Cc: ferruh.yigit, thomas, amr.mokhtar, kamilx.chalupnik, Nicolas Chautru
Implementation still based on Intel SDK libraries
optimized for AVX512 instructions set and 5GNR.
This can be also build for AVX2 for 4G capability or
without SDK dependency for maintenance.
Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
Acked-by: Amr Mokhtar <amr.mokhtar@intel.com>
---
config/common_base | 1 +
doc/guides/rel_notes/release_19_08.rst | 15 +-
drivers/baseband/turbo_sw/Makefile | 15 +-
drivers/baseband/turbo_sw/bbdev_turbo_software.c | 677 ++++++++++++++++++++++-
drivers/baseband/turbo_sw/meson.build | 10 +
mk/rte.app.mk | 8 +-
6 files changed, 715 insertions(+), 11 deletions(-)
diff --git a/config/common_base b/config/common_base
index e5a4ebf..c2551b1 100644
--- a/config/common_base
+++ b/config/common_base
@@ -536,6 +536,7 @@ CONFIG_RTE_LIBRTE_BBDEV_DEBUG=n
CONFIG_RTE_BBDEV_MAX_DEVS=128
CONFIG_RTE_BBDEV_OFFLOAD_COST=y
CONFIG_RTE_BBDEV_SDK_AVX2=n
+CONFIG_RTE_BBDEV_SDK_AVX512=n
#
# Compile PMD for NULL bbdev device
diff --git a/doc/guides/rel_notes/release_19_08.rst b/doc/guides/rel_notes/release_19_08.rst
index 55ae8ee..7c508fc 100644
--- a/doc/guides/rel_notes/release_19_08.rst
+++ b/doc/guides/rel_notes/release_19_08.rst
@@ -126,6 +126,20 @@ New Features
Added telemetry mode to l3fwd-power application to report
application level busyness, empty and full polls of rte_eth_rx_burst().
+* **Added a FPGA_LTE_FEC bbdev PMD.**
+
+ Added the new ``fpga_lte_fec`` bbdev driver for the Intel® FPGA PAC
+ (Programmable Acceleration Card) N3000. See the
+ :doc:`../bbdevs/fpga_lte_fec` BBDEV guide for more details on this new driver.
+
+* **Updated TURBO_SW bbdev PMD.**
+
+ Updated the ``turbo_sw`` bbdev driver with changes including:
+
+ * Added option to build the driver with or without dependency of external
+ SDK libraries.
+ * Added support for 5GNR encode/decode operations.
+
Removed Items
-------------
@@ -165,7 +179,6 @@ API Changes
structure (``rte_crypto_cipher_xform``, ``rte_crypto_auth_xform``, and
``rte_crypto_aead_xform``) have been changed to ``const uint8_t *data``.
-
ABI Changes
-----------
diff --git a/drivers/baseband/turbo_sw/Makefile b/drivers/baseband/turbo_sw/Makefile
index 414d0d9..4aa05d2 100644
--- a/drivers/baseband/turbo_sw/Makefile
+++ b/drivers/baseband/turbo_sw/Makefile
@@ -3,7 +3,6 @@
include $(RTE_SDK)/mk/rte.vars.mk
-
# library name
LIB = librte_pmd_bbdev_turbo_sw.a
@@ -34,6 +33,20 @@ LDLIBS += -L$(FLEXRAN_SDK)/lib_common -lcommon
LDLIBS += -lstdc++ -lirc -limf -lipps -lsvml
endif
+ifeq ($(CONFIG_RTE_BBDEV_SDK_AVX512),y)
+ifeq ($(CONFIG_RTE_BBDEV_SDK_AVX2),n)
+$(error "CONFIG_RTE_BBDEV_SDK_AVX512 requires CONFIG_RTE_BBDEV_SDK_AVX2 set")
+endif
+CFLAGS += -I$(FLEXRAN_SDK)/lib_ldpc_encoder_5gnr
+CFLAGS += -I$(FLEXRAN_SDK)/lib_ldpc_decoder_5gnr
+CFLAGS += -I$(FLEXRAN_SDK)/lib_LDPC_ratematch_5gnr
+CFLAGS += -I$(FLEXRAN_SDK)/lib_rate_dematching_5gnr
+LDLIBS += -L$(FLEXRAN_SDK)/lib_ldpc_encoder_5gnr -lldpc_encoder_5gnr
+LDLIBS += -L$(FLEXRAN_SDK)/lib_ldpc_decoder_5gnr -lldpc_decoder_5gnr
+LDLIBS += -L$(FLEXRAN_SDK)/lib_LDPC_ratematch_5gnr -lLDPC_ratematch_5gnr
+LDLIBS += -L$(FLEXRAN_SDK)/lib_rate_dematching_5gnr -lrate_dematching_5gnr
+endif
+
# library version
LIBABIVER := 1
diff --git a/drivers/baseband/turbo_sw/bbdev_turbo_software.c b/drivers/baseband/turbo_sw/bbdev_turbo_software.c
index 5551f84..2f06369 100644
--- a/drivers/baseband/turbo_sw/bbdev_turbo_software.c
+++ b/drivers/baseband/turbo_sw/bbdev_turbo_software.c
@@ -14,11 +14,24 @@
#include <rte_bbdev.h>
#include <rte_bbdev_pmd.h>
+#include <rte_common.h>
+#include <rte_hexdump.h>
+#include <rte_log.h>
+
#ifdef RTE_BBDEV_SDK_AVX2
+#include <ipp.h>
+#include <ipps.h>
#include <phy_turbo.h>
#include <phy_crc.h>
#include <phy_rate_match.h>
#endif
+#ifdef RTE_BBDEV_SDK_AVX512
+#include <bit_reverse.h>
+#include <phy_ldpc_encoder_5gnr.h>
+#include <phy_ldpc_decoder_5gnr.h>
+#include <phy_LDPC_ratematch_5gnr.h>
+#include <phy_rate_dematching_5gnr.h>
+#endif
#define DRIVER_NAME baseband_turbo_sw
@@ -84,6 +97,7 @@ struct turbo_sw_queue {
enum rte_bbdev_op_type type;
} __rte_cache_aligned;
+
#ifdef RTE_BBDEV_SDK_AVX2
static inline char *
mbuf_append(struct rte_mbuf *m_head, struct rte_mbuf *m, uint16_t len)
@@ -180,20 +194,53 @@ struct turbo_sw_queue {
}
},
#endif
+#ifdef RTE_BBDEV_SDK_AVX512
+ {
+ .type = RTE_BBDEV_OP_LDPC_ENC,
+ .cap.ldpc_enc = {
+ .capability_flags =
+ RTE_BBDEV_LDPC_RATE_MATCH |
+ RTE_BBDEV_LDPC_CRC_24A_ATTACH |
+ RTE_BBDEV_LDPC_CRC_24B_ATTACH,
+ .num_buffers_src =
+ RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
+ .num_buffers_dst =
+ RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
+ }
+ },
+ {
+ .type = RTE_BBDEV_OP_LDPC_DEC,
+ .cap.ldpc_dec = {
+ .capability_flags =
+ RTE_BBDEV_LDPC_CRC_TYPE_24B_CHECK |
+ RTE_BBDEV_LDPC_CRC_TYPE_24A_CHECK |
+ RTE_BBDEV_LDPC_CRC_TYPE_24B_DROP |
+ RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE |
+ RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE |
+ RTE_BBDEV_LDPC_ITERATION_STOP_ENABLE,
+ .llr_size = 8,
+ .llr_decimals = 2,
+ .harq_memory_size = 0,
+ .num_buffers_src =
+ RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
+ .num_buffers_hard_out =
+ RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
+ .num_buffers_soft_out = 0,
+ }
+ },
+#endif
RTE_BBDEV_END_OF_CAPABILITIES_LIST()
};
static struct rte_bbdev_queue_conf default_queue_conf = {
.queue_size = RTE_BBDEV_QUEUE_SIZE_LIMIT,
};
-
#ifdef RTE_BBDEV_SDK_AVX2
static const enum rte_cpu_flag_t cpu_flag = RTE_CPUFLAG_SSE4_2;
dev_info->cpu_flag_reqs = &cpu_flag;
#else
dev_info->cpu_flag_reqs = NULL;
#endif
-
default_queue_conf.socket = dev->data->socket_id;
dev_info->driver_name = RTE_STR(DRIVER_NAME);
@@ -280,7 +327,7 @@ struct turbo_sw_queue {
return -ENAMETOOLONG;
}
q->enc_in = rte_zmalloc_socket(name,
- (RTE_BBDEV_TURBO_MAX_CB_SIZE >> 3) * sizeof(*q->enc_in),
+ (RTE_BBDEV_LDPC_MAX_CB_SIZE >> 3) * sizeof(*q->enc_in),
RTE_CACHE_LINE_SIZE, queue_conf->socket);
if (q->enc_in == NULL) {
rte_bbdev_log(ERR,
@@ -288,7 +335,7 @@ struct turbo_sw_queue {
goto free_q;
}
- /* Allocate memory for Aplha Gamma temp buffer. */
+ /* Allocate memory for Alpha Gamma temp buffer. */
ret = snprintf(name, RTE_RING_NAMESIZE, RTE_STR(DRIVER_NAME)"_ag%u:%u",
dev->data->dev_id, q_id);
if ((ret < 0) || (ret >= (int)RTE_RING_NAMESIZE)) {
@@ -423,6 +470,7 @@ struct turbo_sw_queue {
};
#ifdef RTE_BBDEV_SDK_AVX2
+#ifdef RTE_LIBRTE_BBDEV_DEBUG
/* Checks if the encoder input buffer is correct.
* Returns 0 if it's valid, -1 otherwise.
*/
@@ -478,16 +526,21 @@ struct turbo_sw_queue {
return 0;
}
#endif
+#endif
static inline void
process_enc_cb(struct turbo_sw_queue *q, struct rte_bbdev_enc_op *op,
uint8_t r, uint8_t c, uint16_t k, uint16_t ncb,
uint32_t e, struct rte_mbuf *m_in, struct rte_mbuf *m_out_head,
- struct rte_mbuf *m_out, uint16_t in_offset, uint16_t out_offset,
+ struct rte_mbuf *m_out, uint16_t in_offset, uint16_t out_offset,
uint16_t in_length, struct rte_bbdev_stats *q_stats)
{
#ifdef RTE_BBDEV_SDK_AVX2
+#ifdef RTE_LIBRTE_BBDEV_DEBUG
int ret;
+#else
+ RTE_SET_USED(in_length);
+#endif
int16_t k_idx;
uint16_t m;
uint8_t *in, *out0, *out1, *out2, *tmp_out, *rm_out;
@@ -511,11 +564,14 @@ struct turbo_sw_queue {
/* CRC24A (for TB) */
if ((enc->op_flags & RTE_BBDEV_TURBO_CRC_24A_ATTACH) &&
(enc->code_block_mode == 1)) {
+#ifdef RTE_LIBRTE_BBDEV_DEBUG
ret = is_enc_input_valid(k - 24, k_idx, in_length);
if (ret != 0) {
op->status |= 1 << RTE_BBDEV_DATA_ERROR;
return;
}
+#endif
+
crc_req.data = in;
crc_req.len = k - 24;
/* Check if there is a room for CRC bits if not use
@@ -544,11 +600,14 @@ struct turbo_sw_queue {
#endif
} else if (enc->op_flags & RTE_BBDEV_TURBO_CRC_24B_ATTACH) {
/* CRC24B */
+#ifdef RTE_LIBRTE_BBDEV_DEBUG
ret = is_enc_input_valid(k - 24, k_idx, in_length);
if (ret != 0) {
op->status |= 1 << RTE_BBDEV_DATA_ERROR;
return;
}
+#endif
+
crc_req.data = in;
crc_req.len = k - 24;
/* Check if there is a room for CRC bits if this is the last
@@ -575,13 +634,16 @@ struct turbo_sw_queue {
#ifdef RTE_BBDEV_OFFLOAD_COST
q_stats->acc_offload_cycles += rte_rdtsc_precise() - start_time;
#endif
- } else {
+ }
+#ifdef RTE_LIBRTE_BBDEV_DEBUG
+ else {
ret = is_enc_input_valid(k, k_idx, in_length);
if (ret != 0) {
op->status |= 1 << RTE_BBDEV_DATA_ERROR;
return;
}
}
+#endif
/* Turbo encoder */
@@ -757,6 +819,143 @@ struct turbo_sw_queue {
#endif
}
+
+static inline void
+process_ldpc_enc_cb(struct turbo_sw_queue *q, struct rte_bbdev_enc_op *op,
+ uint32_t e, struct rte_mbuf *m_in, struct rte_mbuf *m_out_head,
+ struct rte_mbuf *m_out, uint16_t in_offset, uint16_t out_offset,
+ uint16_t seg_total_left, struct rte_bbdev_stats *q_stats)
+{
+#ifdef RTE_BBDEV_SDK_AVX512
+ RTE_SET_USED(seg_total_left);
+ uint8_t *in, *rm_out;
+ struct rte_bbdev_op_ldpc_enc *enc = &op->ldpc_enc;
+ struct bblib_ldpc_encoder_5gnr_request ldpc_req;
+ struct bblib_ldpc_encoder_5gnr_response ldpc_resp;
+ struct bblib_LDPC_ratematch_5gnr_request rm_req;
+ struct bblib_LDPC_ratematch_5gnr_response rm_resp;
+ struct bblib_crc_request crc_req;
+ struct bblib_crc_response crc_resp;
+ uint16_t msgLen, puntBits, parity_offset, out_len;
+ uint16_t K = (enc->basegraph == 1 ? 22 : 10) * enc->z_c;
+ uint16_t in_length_in_bits = K - enc->n_filler;
+ uint16_t in_length_in_bytes = (in_length_in_bits + 7) >> 3;
+
+#ifdef RTE_BBDEV_OFFLOAD_COST
+ uint64_t start_time = rte_rdtsc_precise();
+#else
+ RTE_SET_USED(q_stats);
+#endif
+
+ in = rte_pktmbuf_mtod_offset(m_in, uint8_t *, in_offset);
+
+ /* Masking the Filler bits explicitly */
+ memset(q->enc_in + (in_length_in_bytes - 3), 0,
+ ((K + 7) >> 3) - (in_length_in_bytes - 3));
+ /* CRC Generation */
+ if (enc->op_flags & RTE_BBDEV_LDPC_CRC_24A_ATTACH) {
+ rte_memcpy(q->enc_in, in, in_length_in_bytes - 3);
+ crc_req.data = in;
+ crc_req.len = in_length_in_bits - 24;
+ crc_resp.data = q->enc_in;
+ bblib_lte_crc24a_gen(&crc_req, &crc_resp);
+ } else if (enc->op_flags & RTE_BBDEV_LDPC_CRC_24B_ATTACH) {
+ rte_memcpy(q->enc_in, in, in_length_in_bytes - 3);
+ crc_req.data = in;
+ crc_req.len = in_length_in_bits - 24;
+ crc_resp.data = q->enc_in;
+ bblib_lte_crc24b_gen(&crc_req, &crc_resp);
+ } else
+ rte_memcpy(q->enc_in, in, in_length_in_bytes);
+
+ /* LDPC Encoding */
+ ldpc_req.Zc = enc->z_c;
+ ldpc_req.baseGraph = enc->basegraph;
+ /* Number of rows set to maximum */
+ ldpc_req.nRows = ldpc_req.baseGraph == 1 ? 46 : 42;
+ ldpc_req.numberCodeblocks = 1;
+ ldpc_req.input[0] = (int8_t *) q->enc_in;
+ ldpc_resp.output[0] = (int8_t *) q->enc_out;
+
+ bblib_bit_reverse(ldpc_req.input[0], in_length_in_bytes << 3);
+
+ if (bblib_ldpc_encoder_5gnr(&ldpc_req, &ldpc_resp) != 0) {
+ op->status |= 1 << RTE_BBDEV_DRV_ERROR;
+ rte_bbdev_log(ERR, "LDPC Encoder failed");
+ return;
+ }
+
+ /*
+ * Systematic + Parity : Recreating stream with filler bits, ideally
+ * the bit select could handle this in the RM SDK
+ */
+ msgLen = (ldpc_req.baseGraph == 1 ? 22 : 10) * ldpc_req.Zc;
+ puntBits = 2 * ldpc_req.Zc;
+ parity_offset = msgLen - puntBits;
+ ippsCopyBE_1u(((uint8_t *) ldpc_req.input[0]) + (puntBits / 8),
+ puntBits%8, q->adapter_output, 0, parity_offset);
+ ippsCopyBE_1u(q->enc_out, 0, q->adapter_output + (parity_offset / 8),
+ parity_offset % 8, ldpc_req.nRows * ldpc_req.Zc);
+
+ out_len = (e + 7) >> 3;
+ /* get output data starting address */
+ rm_out = (uint8_t *)mbuf_append(m_out_head, m_out, out_len);
+ if (rm_out == NULL) {
+ op->status |= 1 << RTE_BBDEV_DATA_ERROR;
+ rte_bbdev_log(ERR,
+ "Too little space in output mbuf");
+ return;
+ }
+ /*
+ * rte_bbdev_op_data.offset can be different than the offset
+ * of the appended bytes
+ */
+ rm_out = rte_pktmbuf_mtod_offset(m_out, uint8_t *, out_offset);
+
+ /* Rate-Matching */
+ rm_req.E = e;
+ rm_req.Ncb = enc->n_cb;
+ rm_req.Qm = enc->q_m;
+ rm_req.Zc = enc->z_c;
+ rm_req.baseGraph = enc->basegraph;
+ rm_req.input = q->adapter_output;
+ rm_req.nLen = enc->n_filler;
+ rm_req.nullIndex = parity_offset - enc->n_filler;
+ rm_req.rvidx = enc->rv_index;
+ rm_resp.output = q->deint_output;
+
+ if (bblib_LDPC_ratematch_5gnr(&rm_req, &rm_resp) != 0) {
+ op->status |= 1 << RTE_BBDEV_DRV_ERROR;
+ rte_bbdev_log(ERR, "Rate matching failed");
+ return;
+ }
+
+ /* RM SDK may provide non zero bits on last byte */
+ if ((e % 8) != 0)
+ q->deint_output[out_len-1] &= (1 << (e % 8)) - 1;
+
+ bblib_bit_reverse((int8_t *) q->deint_output, out_len << 3);
+
+ rte_memcpy(rm_out, q->deint_output, out_len);
+ enc->output.length += out_len;
+
+#ifdef RTE_BBDEV_OFFLOAD_COST
+ q_stats->acc_offload_cycles += rte_rdtsc_precise() - start_time;
+#endif
+#else
+ RTE_SET_USED(q);
+ RTE_SET_USED(op);
+ RTE_SET_USED(e);
+ RTE_SET_USED(m_in);
+ RTE_SET_USED(m_out_head);
+ RTE_SET_USED(m_out);
+ RTE_SET_USED(in_offset);
+ RTE_SET_USED(out_offset);
+ RTE_SET_USED(seg_total_left);
+ RTE_SET_USED(q_stats);
+#endif
+}
+
static inline void
enqueue_enc_one_op(struct turbo_sw_queue *q, struct rte_bbdev_enc_op *op,
struct rte_bbdev_stats *queue_stats)
@@ -850,6 +1049,93 @@ struct turbo_sw_queue {
}
}
+
+static inline void
+enqueue_ldpc_enc_one_op(struct turbo_sw_queue *q, struct rte_bbdev_enc_op *op,
+ struct rte_bbdev_stats *queue_stats)
+{
+ uint8_t c, r, crc24_bits = 0;
+ uint32_t e;
+ struct rte_bbdev_op_ldpc_enc *enc = &op->ldpc_enc;
+ uint16_t in_offset = enc->input.offset;
+ uint16_t out_offset = enc->output.offset;
+ struct rte_mbuf *m_in = enc->input.data;
+ struct rte_mbuf *m_out = enc->output.data;
+ struct rte_mbuf *m_out_head = enc->output.data;
+ uint32_t in_length, mbuf_total_left = enc->input.length;
+
+ uint16_t seg_total_left;
+
+ /* Clear op status */
+ op->status = 0;
+
+ if (mbuf_total_left > RTE_BBDEV_TURBO_MAX_TB_SIZE >> 3) {
+ rte_bbdev_log(ERR, "TB size (%u) is too big, max: %d",
+ mbuf_total_left, RTE_BBDEV_TURBO_MAX_TB_SIZE);
+ op->status = 1 << RTE_BBDEV_DATA_ERROR;
+ return;
+ }
+
+ if (m_in == NULL || m_out == NULL) {
+ rte_bbdev_log(ERR, "Invalid mbuf pointer");
+ op->status = 1 << RTE_BBDEV_DATA_ERROR;
+ return;
+ }
+
+ if ((enc->op_flags & RTE_BBDEV_TURBO_CRC_24B_ATTACH) ||
+ (enc->op_flags & RTE_BBDEV_TURBO_CRC_24A_ATTACH))
+ crc24_bits = 24;
+
+ if (enc->code_block_mode == 0) { /* For Transport Block mode */
+ c = enc->tb_params.c;
+ r = enc->tb_params.r;
+ } else { /* For Code Block mode */
+ c = 1;
+ r = 0;
+ }
+
+ while (mbuf_total_left > 0 && r < c) {
+
+ seg_total_left = rte_pktmbuf_data_len(m_in) - in_offset;
+
+ if (enc->code_block_mode == 0) {
+ e = (r < enc->tb_params.cab) ?
+ enc->tb_params.ea : enc->tb_params.eb;
+ } else {
+ e = enc->cb_params.e;
+ }
+
+ process_ldpc_enc_cb(q, op, e, m_in, m_out_head,
+ m_out, in_offset, out_offset, seg_total_left,
+ queue_stats);
+ /* Update total_left */
+ in_length = (enc->basegraph == 1 ? 22 : 10) * enc->z_c;
+ in_length = ((in_length - crc24_bits - enc->n_filler) >> 3);
+ mbuf_total_left -= in_length;
+ /* Update offsets for next CBs (if exist) */
+ in_offset += in_length;
+ out_offset += (e + 7) >> 3;
+
+ /* Update offsets */
+ if (seg_total_left == in_length) {
+ /* Go to the next mbuf */
+ m_in = m_in->next;
+ m_out = m_out->next;
+ in_offset = 0;
+ out_offset = 0;
+ }
+ r++;
+ }
+
+ /* check if all input data was processed */
+ if (mbuf_total_left != 0) {
+ op->status |= 1 << RTE_BBDEV_DATA_ERROR;
+ rte_bbdev_log(ERR,
+ "Mismatch between mbuf length and included CBs sizes %d",
+ mbuf_total_left);
+ }
+}
+
static inline uint16_t
enqueue_enc_all_ops(struct turbo_sw_queue *q, struct rte_bbdev_enc_op **ops,
uint16_t nb_ops, struct rte_bbdev_stats *queue_stats)
@@ -866,6 +1152,23 @@ struct turbo_sw_queue {
NULL);
}
+static inline uint16_t
+enqueue_ldpc_enc_all_ops(struct turbo_sw_queue *q,
+ struct rte_bbdev_enc_op **ops,
+ uint16_t nb_ops, struct rte_bbdev_stats *queue_stats)
+{
+ uint16_t i;
+#ifdef RTE_BBDEV_OFFLOAD_COST
+ queue_stats->acc_offload_cycles = 0;
+#endif
+
+ for (i = 0; i < nb_ops; ++i)
+ enqueue_ldpc_enc_one_op(q, ops[i], queue_stats);
+
+ return rte_ring_enqueue_burst(q->processed_pkts, (void **)ops, nb_ops,
+ NULL);
+}
+
#ifdef RTE_BBDEV_SDK_AVX2
static inline void
move_padding_bytes(const uint8_t *in, uint8_t *out, uint16_t k,
@@ -890,7 +1193,11 @@ struct turbo_sw_queue {
struct rte_bbdev_stats *q_stats)
{
#ifdef RTE_BBDEV_SDK_AVX2
+#ifdef RTE_LIBRTE_BBDEV_DEBUG
int ret;
+#else
+ RTE_SET_USED(in_length);
+#endif
int32_t k_idx;
int32_t iter_cnt;
uint8_t *in, *out, *adapter_input;
@@ -908,11 +1215,13 @@ struct turbo_sw_queue {
k_idx = compute_idx(k);
+#ifdef RTE_LIBRTE_BBDEV_DEBUG
ret = is_dec_input_valid(k_idx, kw, in_length);
if (ret != 0) {
op->status |= 1 << RTE_BBDEV_DATA_ERROR;
return;
}
+#endif
in = rte_pktmbuf_mtod_offset(m_in, uint8_t *, in_offset);
ncb = kw;
@@ -928,11 +1237,12 @@ struct turbo_sw_queue {
deint_resp.pinteleavebuffer = q->deint_output;
#ifdef RTE_BBDEV_OFFLOAD_COST
- start_time = rte_rdtsc_precise();
+ start_time = rte_rdtsc_precise();
#endif
+ /* Sub-block De-Interleaving */
bblib_deinterleave_ul(&deint_req, &deint_resp);
#ifdef RTE_BBDEV_OFFLOAD_COST
- q_stats->acc_offload_cycles += rte_rdtsc_precise() - start_time;
+ q_stats->acc_offload_cycles += rte_rdtsc_precise() - start_time;
#endif
} else
move_padding_bytes(in, q->deint_output, k, ncb);
@@ -1025,6 +1335,202 @@ struct turbo_sw_queue {
}
static inline void
+process_ldpc_dec_cb(struct turbo_sw_queue *q, struct rte_bbdev_dec_op *op,
+ uint8_t c, uint16_t out_length, uint16_t e,
+ struct rte_mbuf *m_in,
+ struct rte_mbuf *m_out_head, struct rte_mbuf *m_out,
+ struct rte_mbuf *m_harq_in,
+ struct rte_mbuf *m_harq_out_head, struct rte_mbuf *m_harq_out,
+ uint16_t in_offset, uint16_t out_offset,
+ uint16_t harq_in_offset, uint16_t harq_out_offset,
+ bool check_crc_24b,
+ uint16_t crc24_overlap, uint16_t in_length,
+ struct rte_bbdev_stats *q_stats)
+{
+#ifdef RTE_BBDEV_SDK_AVX512
+ RTE_SET_USED(in_length);
+ RTE_SET_USED(c);
+ uint8_t *in, *out, *harq_in, *harq_out, *adapter_input;
+ struct bblib_rate_dematching_5gnr_request derm_req;
+ struct bblib_rate_dematching_5gnr_response derm_resp;
+ struct bblib_ldpc_decoder_5gnr_request dec_req;
+ struct bblib_ldpc_decoder_5gnr_response dec_resp;
+ struct bblib_crc_request crc_req;
+ struct bblib_crc_response crc_resp;
+ struct rte_bbdev_op_ldpc_dec *dec = &op->ldpc_dec;
+ uint16_t K, parity_offset, sys_cols, outLenWithCrc;
+ int16_t deRmOutSize, numRows;
+
+ /* Compute some LDPC BG lengths */
+ outLenWithCrc = out_length + (crc24_overlap >> 3);
+ sys_cols = (dec->basegraph == 1) ? 22 : 10;
+ K = sys_cols * dec->z_c;
+ parity_offset = K - 2 * dec->z_c;
+
+#ifdef RTE_BBDEV_OFFLOAD_COST
+ uint64_t start_time = rte_rdtsc_precise();
+#else
+ RTE_SET_USED(q_stats);
+#endif
+
+ in = rte_pktmbuf_mtod_offset(m_in, uint8_t *, in_offset);
+
+ if (check_bit(dec->op_flags, RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE)) {
+ /**
+ * Single contiguous block from the first LLR of the
+ * circular buffer.
+ */
+ harq_in = NULL;
+ if (m_harq_in != NULL)
+ harq_in = rte_pktmbuf_mtod_offset(m_harq_in,
+ uint8_t *, harq_in_offset);
+ if (harq_in == NULL) {
+ op->status |= 1 << RTE_BBDEV_DATA_ERROR;
+ rte_bbdev_log(ERR, "No space in harq input mbuf");
+ return;
+ }
+ uint16_t harq_in_length = RTE_MIN(
+ dec->harq_combined_input.length,
+ (uint32_t) dec->n_cb);
+ memset(q->ag + harq_in_length, 0,
+ dec->n_cb - harq_in_length);
+ rte_memcpy(q->ag, harq_in, harq_in_length);
+ }
+
+ derm_req.p_in = (int8_t *) in;
+ derm_req.p_harq = q->ag; /* This doesn't include the filler bits */
+ derm_req.base_graph = dec->basegraph;
+ derm_req.zc = dec->z_c;
+ derm_req.ncb = dec->n_cb;
+ derm_req.e = e;
+ derm_req.k0 = 0; /* Actual output from SDK */
+ derm_req.isretx = check_bit(dec->op_flags,
+ RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE);
+ derm_req.rvid = dec->rv_index;
+ derm_req.modulation_order = dec->q_m;
+ derm_req.start_null_index = parity_offset - dec->n_filler;
+ derm_req.num_of_null = dec->n_filler;
+
+ bblib_rate_dematching_5gnr(&derm_req, &derm_resp);
+
+ /* Compute RM out size and number of rows */
+ deRmOutSize = RTE_MIN(
+ derm_req.k0 + derm_req.e -
+ ((derm_req.k0 < derm_req.start_null_index) ?
+ 0 : dec->n_filler),
+ dec->n_cb - dec->n_filler);
+ if (m_harq_in != NULL)
+ deRmOutSize = RTE_MAX(deRmOutSize,
+ RTE_MIN(dec->n_cb - dec->n_filler,
+ m_harq_in->data_len));
+ numRows = ((deRmOutSize + dec->n_filler + dec->z_c - 1) / dec->z_c)
+ - sys_cols + 2;
+ numRows = RTE_MAX(4, numRows);
+
+ /* get output data starting address */
+ out = (uint8_t *)mbuf_append(m_out_head, m_out, out_length);
+ if (out == NULL) {
+ op->status |= 1 << RTE_BBDEV_DATA_ERROR;
+ rte_bbdev_log(ERR,
+ "Too little space in LDPC decoder output mbuf");
+ return;
+ }
+
+ /* rte_bbdev_op_data.offset can be different than the offset
+ * of the appended bytes
+ */
+ out = rte_pktmbuf_mtod_offset(m_out, uint8_t *, out_offset);
+ adapter_input = q->enc_out;
+
+ dec_req.Zc = dec->z_c;
+ dec_req.baseGraph = dec->basegraph;
+ dec_req.nRows = numRows;
+ dec_req.numChannelLlrs = deRmOutSize;
+ dec_req.varNodes = derm_req.p_harq;
+ dec_req.numFillerBits = dec->n_filler;
+ dec_req.maxIterations = dec->iter_max;
+ dec_req.enableEarlyTermination = check_bit(dec->op_flags,
+ RTE_BBDEV_LDPC_ITERATION_STOP_ENABLE);
+ dec_resp.varNodes = (int16_t *) q->adapter_output;
+ dec_resp.compactedMessageBytes = q->enc_out;
+
+ bblib_ldpc_decoder_5gnr(&dec_req, &dec_resp);
+
+ dec->iter_count = RTE_MAX(dec_resp.iterationAtTermination,
+ dec->iter_count);
+ if (!dec_resp.parityPassedAtTermination)
+ op->status |= 1 << RTE_BBDEV_SYNDROME_ERROR;
+
+ bblib_bit_reverse((int8_t *) q->enc_out, outLenWithCrc << 3);
+
+ if (check_bit(dec->op_flags, RTE_BBDEV_LDPC_CRC_TYPE_24A_CHECK) ||
+ check_bit(dec->op_flags,
+ RTE_BBDEV_LDPC_CRC_TYPE_24B_CHECK)) {
+ crc_req.data = adapter_input;
+ crc_req.len = K - dec->n_filler - 24;
+ crc_resp.check_passed = false;
+ crc_resp.data = adapter_input;
+ if (check_crc_24b)
+ bblib_lte_crc24b_check(&crc_req, &crc_resp);
+ else
+ bblib_lte_crc24a_check(&crc_req, &crc_resp);
+ if (!crc_resp.check_passed)
+ op->status |= 1 << RTE_BBDEV_CRC_ERROR;
+ }
+
+#ifdef RTE_BBDEV_OFFLOAD_COST
+ q_stats->acc_offload_cycles += rte_rdtsc_precise() - start_time;
+#endif
+ if (check_bit(dec->op_flags, RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE)) {
+ harq_out = NULL;
+ if (m_harq_out != NULL) {
+ /* Initialize HARQ data length since we overwrite */
+ m_harq_out->data_len = 0;
+ /* Check there is enough space
+ * in the HARQ outbound buffer
+ */
+ harq_out = (uint8_t *)mbuf_append(m_harq_out_head,
+ m_harq_out, deRmOutSize);
+ }
+ if (harq_out == NULL) {
+ op->status |= 1 << RTE_BBDEV_DATA_ERROR;
+ rte_bbdev_log(ERR, "No space in HARQ output mbuf");
+ return;
+ }
+ /* get output data starting address and overwrite the data */
+ harq_out = rte_pktmbuf_mtod_offset(m_harq_out, uint8_t *,
+ harq_out_offset);
+ rte_memcpy(harq_out, derm_req.p_harq, deRmOutSize);
+ dec->harq_combined_output.length += deRmOutSize;
+ }
+
+ rte_memcpy(out, adapter_input, out_length);
+ dec->hard_output.length += out_length;
+#else
+ RTE_SET_USED(q);
+ RTE_SET_USED(op);
+ RTE_SET_USED(c);
+ RTE_SET_USED(out_length);
+ RTE_SET_USED(e);
+ RTE_SET_USED(m_in);
+ RTE_SET_USED(m_out_head);
+ RTE_SET_USED(m_out);
+ RTE_SET_USED(m_harq_in);
+ RTE_SET_USED(m_harq_out_head);
+ RTE_SET_USED(m_harq_out);
+ RTE_SET_USED(harq_in_offset);
+ RTE_SET_USED(harq_out_offset);
+ RTE_SET_USED(in_offset);
+ RTE_SET_USED(out_offset);
+ RTE_SET_USED(check_crc_24b);
+ RTE_SET_USED(crc24_overlap);
+ RTE_SET_USED(in_length);
+ RTE_SET_USED(q_stats);
+#endif
+}
+
+
+static inline void
enqueue_dec_one_op(struct turbo_sw_queue *q, struct rte_bbdev_dec_op *op,
struct rte_bbdev_stats *queue_stats)
{
@@ -1083,6 +1589,7 @@ struct turbo_sw_queue {
in_offset, out_offset, check_bit(dec->op_flags,
RTE_BBDEV_TURBO_CRC_TYPE_24B), crc24_overlap,
seg_total_left, queue_stats);
+
/* To keep CRC24 attached to end of Code block, use
* RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP flag as it
* removed by default once verified.
@@ -1104,6 +1611,103 @@ struct turbo_sw_queue {
}
r++;
}
+
+ if (mbuf_total_left != 0) {
+ op->status |= 1 << RTE_BBDEV_DATA_ERROR;
+ rte_bbdev_log(ERR,
+ "Mismatch between mbuf length and included Circular buffer sizes");
+ }
+}
+
+static inline void
+enqueue_ldpc_dec_one_op(struct turbo_sw_queue *q, struct rte_bbdev_dec_op *op,
+ struct rte_bbdev_stats *queue_stats)
+{
+ uint8_t c, r = 0;
+ uint16_t e, out_length;
+ uint16_t crc24_overlap = 0;
+ struct rte_bbdev_op_ldpc_dec *dec = &op->ldpc_dec;
+ struct rte_mbuf *m_in = dec->input.data;
+ struct rte_mbuf *m_harq_in = dec->harq_combined_input.data;
+ struct rte_mbuf *m_harq_out = dec->harq_combined_output.data;
+ struct rte_mbuf *m_harq_out_head = dec->harq_combined_output.data;
+ struct rte_mbuf *m_out = dec->hard_output.data;
+ struct rte_mbuf *m_out_head = dec->hard_output.data;
+ uint16_t in_offset = dec->input.offset;
+ uint16_t harq_in_offset = dec->harq_combined_input.offset;
+ uint16_t harq_out_offset = dec->harq_combined_output.offset;
+ uint16_t out_offset = dec->hard_output.offset;
+ uint32_t mbuf_total_left = dec->input.length;
+ uint16_t seg_total_left;
+
+ /* Clear op status */
+ op->status = 0;
+
+ if (m_in == NULL || m_out == NULL) {
+ rte_bbdev_log(ERR, "Invalid mbuf pointer");
+ op->status = 1 << RTE_BBDEV_DATA_ERROR;
+ return;
+ }
+
+ if (dec->code_block_mode == 0) { /* For Transport Block mode */
+ c = dec->tb_params.c;
+ e = dec->tb_params.ea;
+ } else { /* For Code Block mode */
+ c = 1;
+ e = dec->cb_params.e;
+ }
+
+ if (check_bit(dec->op_flags, RTE_BBDEV_LDPC_CRC_TYPE_24B_DROP))
+ crc24_overlap = 24;
+
+ out_length = (dec->basegraph == 1 ? 22 : 10) * dec->z_c; /* K */
+ out_length = ((out_length - crc24_overlap - dec->n_filler) >> 3);
+
+ while (mbuf_total_left > 0) {
+ if (dec->code_block_mode == 0)
+ e = (r < dec->tb_params.cab) ?
+ dec->tb_params.ea : dec->tb_params.eb;
+
+ seg_total_left = rte_pktmbuf_data_len(m_in) - in_offset;
+
+ process_ldpc_dec_cb(q, op, c, out_length, e,
+ m_in, m_out_head, m_out,
+ m_harq_in, m_harq_out_head, m_harq_out,
+ in_offset, out_offset, harq_in_offset,
+ harq_out_offset,
+ check_bit(dec->op_flags,
+ RTE_BBDEV_LDPC_CRC_TYPE_24B_CHECK),
+ crc24_overlap,
+ seg_total_left, queue_stats);
+
+ /* To keep CRC24 attached to end of Code block, use
+ * RTE_BBDEV_LDPC_DEC_TB_CRC_24B_KEEP flag as it
+ * removed by default once verified.
+ */
+
+ mbuf_total_left -= e;
+
+ /* Update offsets */
+ if (seg_total_left == e) {
+ /* Go to the next mbuf */
+ m_in = m_in->next;
+ m_out = m_out->next;
+ if (m_harq_in != NULL)
+ m_harq_in = m_harq_in->next;
+ if (m_harq_out != NULL)
+ m_harq_out = m_harq_out->next;
+ in_offset = 0;
+ out_offset = 0;
+ harq_in_offset = 0;
+ harq_out_offset = 0;
+ } else {
+ /* Update offsets for next CBs (if exist) */
+ in_offset += e;
+ out_offset += out_length;
+ }
+ r++;
+ }
+
if (mbuf_total_left != 0) {
op->status |= 1 << RTE_BBDEV_DATA_ERROR;
rte_bbdev_log(ERR,
@@ -1127,6 +1731,23 @@ struct turbo_sw_queue {
NULL);
}
+static inline uint16_t
+enqueue_ldpc_dec_all_ops(struct turbo_sw_queue *q,
+ struct rte_bbdev_dec_op **ops,
+ uint16_t nb_ops, struct rte_bbdev_stats *queue_stats)
+{
+ uint16_t i;
+#ifdef RTE_BBDEV_OFFLOAD_COST
+ queue_stats->acc_offload_cycles = 0;
+#endif
+
+ for (i = 0; i < nb_ops; ++i)
+ enqueue_ldpc_dec_one_op(q, ops[i], queue_stats);
+
+ return rte_ring_enqueue_burst(q->processed_pkts, (void **)ops, nb_ops,
+ NULL);
+}
+
/* Enqueue burst */
static uint16_t
enqueue_enc_ops(struct rte_bbdev_queue_data *q_data,
@@ -1146,6 +1767,24 @@ struct turbo_sw_queue {
/* Enqueue burst */
static uint16_t
+enqueue_ldpc_enc_ops(struct rte_bbdev_queue_data *q_data,
+ struct rte_bbdev_enc_op **ops, uint16_t nb_ops)
+{
+ void *queue = q_data->queue_private;
+ struct turbo_sw_queue *q = queue;
+ uint16_t nb_enqueued = 0;
+
+ nb_enqueued = enqueue_ldpc_enc_all_ops(
+ q, ops, nb_ops, &q_data->queue_stats);
+
+ q_data->queue_stats.enqueue_err_count += nb_ops - nb_enqueued;
+ q_data->queue_stats.enqueued_count += nb_enqueued;
+
+ return nb_enqueued;
+}
+
+/* Enqueue burst */
+static uint16_t
enqueue_dec_ops(struct rte_bbdev_queue_data *q_data,
struct rte_bbdev_dec_op **ops, uint16_t nb_ops)
{
@@ -1161,6 +1800,24 @@ struct turbo_sw_queue {
return nb_enqueued;
}
+/* Enqueue burst */
+static uint16_t
+enqueue_ldpc_dec_ops(struct rte_bbdev_queue_data *q_data,
+ struct rte_bbdev_dec_op **ops, uint16_t nb_ops)
+{
+ void *queue = q_data->queue_private;
+ struct turbo_sw_queue *q = queue;
+ uint16_t nb_enqueued = 0;
+
+ nb_enqueued = enqueue_ldpc_dec_all_ops(q, ops, nb_ops,
+ &q_data->queue_stats);
+
+ q_data->queue_stats.enqueue_err_count += nb_ops - nb_enqueued;
+ q_data->queue_stats.enqueued_count += nb_enqueued;
+
+ return nb_enqueued;
+}
+
/* Dequeue decode burst */
static uint16_t
dequeue_dec_ops(struct rte_bbdev_queue_data *q_data,
@@ -1273,6 +1930,10 @@ struct turbo_sw_queue {
bbdev->dequeue_dec_ops = dequeue_dec_ops;
bbdev->enqueue_enc_ops = enqueue_enc_ops;
bbdev->enqueue_dec_ops = enqueue_dec_ops;
+ bbdev->dequeue_ldpc_enc_ops = dequeue_enc_ops;
+ bbdev->dequeue_ldpc_dec_ops = dequeue_dec_ops;
+ bbdev->enqueue_ldpc_enc_ops = enqueue_ldpc_enc_ops;
+ bbdev->enqueue_ldpc_dec_ops = enqueue_ldpc_dec_ops;
((struct bbdev_private *) bbdev->data->dev_private)->max_nb_queues =
init_params->queues_num;
diff --git a/drivers/baseband/turbo_sw/meson.build b/drivers/baseband/turbo_sw/meson.build
index 438b5a7..33345aa 100644
--- a/drivers/baseband/turbo_sw/meson.build
+++ b/drivers/baseband/turbo_sw/meson.build
@@ -23,6 +23,16 @@ if dpdk_conf.has('RTE_BBDEV_SDK_AVX2')
includes += include_directories(path + '/lib_common')
endif
endif
+if dpdk_conf.has('RTE_BBDEV_SDK_AVX512')
+ ext_deps += cc.find_library('libldpc_encoder_5gnr', dirs: [path + '/lib_ldpc_encoder_5gnr'], required: true)
+ ext_deps += cc.find_library('libldpc_decoder_5gnr', dirs: [path + '/lib_ldpc_decoder_5gnr'], required: true)
+ ext_deps += cc.find_library('libLDPC_ratematch_5gnr', dirs: [path + '/lib_LDPC_ratematch_5gnr'], required: true)
+ ext_deps += cc.find_library('librate_dematching_5gnr', dirs: [path + '/lib_rate_dematching_5gnr'], required: true)
+ includes += include_directories(path + '/lib_ldpc_encoder_5gnr')
+ includes += include_directories(path + '/lib_ldpc_decoder_5gnr')
+ includes += include_directories(path + '/lib_LDPC_ratematch_5gnr')
+ includes += include_directories(path + '/lib_rate_dematching_5gnr')
+endif
deps += ['bbdev', 'bus_vdev', 'ring']
name = 'bbdev_turbo_sw'
diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index c9fbdd6..1036df7 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -232,7 +232,13 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_BBDEV_TURBO_SW) += -L$(FLEXRAN_SDK)/lib_crc -lcr
_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_BBDEV_TURBO_SW) += -L$(FLEXRAN_SDK)/lib_turbo -lturbo
_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_BBDEV_TURBO_SW) += -L$(FLEXRAN_SDK)/lib_rate_matching -lrate_matching
_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_BBDEV_TURBO_SW) += -L$(FLEXRAN_SDK)/lib_common -lcommon
-_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_BBDEV_TURBO_SW) += -lirc -limf -lstdc++ -lipps
+_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_BBDEV_TURBO_SW) += -lirc -limf -lstdc++ -lipps -lsvml
+ifeq ($(CONFIG_RTE_BBDEV_SDK_AVX512),y)
+_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_BBDEV_TURBO_SW) += -L$(FLEXRAN_SDK)/lib_LDPC_ratematch_5gnr -lLDPC_ratematch_5gnr
+_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_BBDEV_TURBO_SW) += -L$(FLEXRAN_SDK)/lib_ldpc_encoder_5gnr -lldpc_encoder_5gnr
+_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_BBDEV_TURBO_SW) += -L$(FLEXRAN_SDK)/lib_ldpc_decoder_5gnr -lldpc_decoder_5gnr
+_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_BBDEV_TURBO_SW) += -L$(FLEXRAN_SDK)/lib_rate_dematching_5gnr -lrate_dematching_5gnr
+endif # CONFIG_RTE_BBDEV_SDK_AVX512
endif # CONFIG_RTE_BBDEV_SDK_AVX2
endif # CONFIG_RTE_LIBRTE_BBDEV
--
1.8.3.1
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [PATCH v4 10/10] doc: announce bbdev changes
2019-07-01 11:14 4% ` Akhil Goyal
@ 2019-07-01 18:14 3% ` Chautru, Nicolas
2019-07-01 19:17 3% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Chautru, Nicolas @ 2019-07-01 18:14 UTC (permalink / raw)
To: Akhil Goyal, dev; +Cc: thomas, Yigit, Ferruh, Mokhtar, Amr
Hi Akhil,
>>
>> Update of the release notes for BBDEV features add and extension of
>> ABI in previous commit.
>>
>> Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
>> ---
>> doc/guides/rel_notes/release_19_08.rst | 15 +++++++++++++++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git a/doc/guides/rel_notes/release_19_08.rst
>> b/doc/guides/rel_notes/release_19_08.rst
>> index 8c3932d..35d3a09 100644
>> --- a/doc/guides/rel_notes/release_19_08.rst
>> +++ b/doc/guides/rel_notes/release_19_08.rst
>> @@ -88,6 +88,19 @@ New Features
>> * Added multi-queue support to allow one af_xdp vdev with multiple netdev
>> queues
>>
>> +* **Added a FPGA_LTE_FEC bbdev PMD.**
>> +
>> + Added the new ``fpga_lte_fec`` bbdev driver for the Intel® FPGA
>> + PAC (Programmable Acceleration Card) N3000. See the
>> + :doc:`../bbdevs/fpga_lte_fec` BBDEV guide for more details on this new driver.
>> +
>> +* **Updated TURBO_SW bbdev PMD.**
>> +
>> + Updated the ``turbo_sw`` bbdev driver with changes including:
>> +
>> + * Added option to build the driver with or without dependency of external
>> + SDK libraries.
>> + * Added support for 5GNR encode/decode operations.
>>
>> Removed Items
>> -------------
>> @@ -140,6 +153,8 @@ ABI Changes
>> Also, make sure to start the actual text at the margin.
>> =========================================================
>>
>> +* bbdev: New parameters added to support 5GNR operations.
>> +
>>
>> Shared Library Versions
>> -----------------------
>> --
>> 1.8.3.1
>
>Release note changes should be part of the same patch which is adding that change.
No problem, I am pushing an updated serie : https://patches.dpdk.org/project/dpdk/list/?series=5259
>One more thing, if there is a change in ABI, should you also increment the bbdev ABI version?
The bbdev ABI is still marked as __rte_experimental hence I don't believe we have yet to increment it.
>Please also send a rebased version of your patchset, so that builds can be verified by CI. The dependent patches are applied on the sub-tree.
OK, I did this on the serie above. Note that the previous was already verified with CI since I kept the dependency within the previous serie. Still cleaner now, you should just have to apply the serie as is now.
Thanks!
Nic
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v4 10/10] doc: announce bbdev changes
2019-07-01 18:14 3% ` Chautru, Nicolas
@ 2019-07-01 19:17 3% ` Thomas Monjalon
2019-07-01 20:27 4% ` Chautru, Nicolas
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-07-01 19:17 UTC (permalink / raw)
To: Chautru, Nicolas; +Cc: Akhil Goyal, dev, Yigit, Ferruh, Mokhtar, Amr
01/07/2019 20:14, Chautru, Nicolas:
>
> >One more thing, if there is a change in ABI, should you also increment the bbdev ABI version?
>
> The bbdev ABI is still marked as __rte_experimental hence I don't believe we have yet to increment it.
ABI version and experimental state are two different things.
I think we should upgrade the version even for experimental libraries.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v4 10/10] doc: announce bbdev changes
2019-07-01 19:17 3% ` Thomas Monjalon
@ 2019-07-01 20:27 4% ` Chautru, Nicolas
2019-07-01 20:38 3% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Chautru, Nicolas @ 2019-07-01 20:27 UTC (permalink / raw)
To: Thomas Monjalon, Richardson, Bruce
Cc: Akhil Goyal, dev, Yigit, Ferruh, Mokhtar, Amr
>-----Original Message-----
>From: Thomas Monjalon [mailto:thomas@monjalon.net]
>Sent: Monday, July 1, 2019 12:18 PM
>To: Chautru, Nicolas <nicolas.chautru@intel.com>
>Cc: Akhil Goyal <akhil.goyal@nxp.com>; dev@dpdk.org; Yigit, Ferruh <ferruh.yigit@intel.com>; Mokhtar, Amr <amr.mokhtar@intel.com>
>Subject: Re: [PATCH v4 10/10] doc: announce bbdev changes
>
>01/07/2019 20:14, Chautru, Nicolas:
>>
>> >One more thing, if there is a change in ABI, should you also increment the bbdev ABI version?
>>
>> The bbdev ABI is still marked as __rte_experimental hence I don't believe we have yet to increment it.
>
>ABI version and experimental state are two different things.
>I think we should upgrade the version even for experimental libraries.
Thanks Thomas.
Bruce, Ferruh can you comment whether bumping ABI version is required for __rte_experimental API? Arguably the documentation may be interpreted either way : https://doc.dpdk.org/guides-18.08/contributing/versioning.html
In the specific case of bbdev change in that serie, note that only new operations (for 5GNR signal processing) and related symbols are being added.
Previous releases included BBDEV API changes without updating ABI version number ( librte_bbdev.so.1).
Thanks for letting me know, in both cases we may make it more explicit on the versioning page.
Nic
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v4 10/10] doc: announce bbdev changes
2019-07-01 20:27 4% ` Chautru, Nicolas
@ 2019-07-01 20:38 3% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2019-07-01 20:38 UTC (permalink / raw)
To: Chautru, Nicolas
Cc: Thomas Monjalon, Akhil Goyal, dev, Yigit, Ferruh, Mokhtar, Amr
On Mon, Jul 01, 2019 at 09:27:56PM +0100, Chautru, Nicolas wrote:
>
> >-----Original Message-----
> >From: Thomas Monjalon [mailto:thomas@monjalon.net]
> >Sent: Monday, July 1, 2019 12:18 PM
> >To: Chautru, Nicolas <nicolas.chautru@intel.com>
> >Cc: Akhil Goyal <akhil.goyal@nxp.com>; dev@dpdk.org; Yigit, Ferruh <ferruh.yigit@intel.com>; Mokhtar, Amr <amr.mokhtar@intel.com>
> >Subject: Re: [PATCH v4 10/10] doc: announce bbdev changes
> >
> >01/07/2019 20:14, Chautru, Nicolas:
> >>
> >> >One more thing, if there is a change in ABI, should you also increment the bbdev ABI version?
> >>
> >> The bbdev ABI is still marked as __rte_experimental hence I don't believe we have yet to increment it.
> >
> >ABI version and experimental state are two different things.
> >I think we should upgrade the version even for experimental libraries.
>
> Thanks Thomas.
>
> Bruce, Ferruh can you comment whether bumping ABI version is required for __rte_experimental API? Arguably the documentation may be interpreted either way : https://doc.dpdk.org/guides-18.08/contributing/versioning.html
>
> In the specific case of bbdev change in that serie, note that only new operations (for 5GNR signal processing) and related symbols are being added.
> Previous releases included BBDEV API changes without updating ABI version number ( librte_bbdev.so.1).
>
> Thanks for letting me know, in both cases we may make it more explicit on the versioning page.
> Nic
I think there may be some misunderstanding here, so long as no existing
APIs are changed or removed, we don't bump the ABI version.
/Bruce
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v3] eventdev: change Rx adapter callback and stats structure
@ 2019-07-02 4:52 0% Jerin Jacob Kollanukkaran
0 siblings, 0 replies; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-07-02 4:52 UTC (permalink / raw)
To: Nikhil Rao; +Cc: dev
> -----Original Message-----
> From: Nikhil Rao <nikhil.rao@intel.com>
> Sent: Tuesday, June 25, 2019 4:46 AM
> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> Cc: nikhil.rao@intel.com; dev@dpdk.org
> Subject: [EXT] [PATCH v3] eventdev: change Rx adapter callback and stats
> structure
>
> External Email
>
> ----------------------------------------------------------------------
> Replace the mbuf pointer array in the event eth Rx adapter callback with an
> event array. Using an event array allows the application to change attributes
> of the events enqueued by the SW adapter.
>
> The callback can drop packets and populate a callback argument with the
> number of dropped packets. Add a Rx adapter stats field to keep track of the
> total number of dropped packets.
>
> This commit removes the experimental tags from the callback and stats APIs,
> the experimental tag from eventdev is also removed and eventdev functions
> become part of the main DPDK API/ABI.
>
> Signed-off-by: Nikhil Rao <nikhil.rao@intel.com>
> ---
> lib/librte_eventdev/rte_event_eth_rx_adapter.h | 82 +++++++++++++-----
> -------- lib/librte_eventdev/rte_event_eth_rx_adapter.c | 34 ++++++-----
> MAINTAINERS | 2 +-
> doc/guides/rel_notes/release_19_08.rst | 20 ++++++-
> lib/librte_eventdev/Makefile | 2 +-
> lib/librte_eventdev/meson.build | 2 +-
> lib/librte_eventdev/rte_eventdev_version.map | 4 +-
> 7 files changed, 83 insertions(+), 63 deletions(-)
>
> v1:
> * add implementation to RFC
>
> v2:
> * Bump library version
> * Combine patch 1 & 2 into a single patch (single library version bump)
> * Mention API change in release notes
> * Remove __rte_experimental tag
> * Remove EXPERIMENTAL status for eventdev
>
> v3:
> * Update version = 7 in lib/librte_eventdev/meson.build
> * Update the "git comment and release notes" to mention the removal of
> experimental status
> * Reduce rte_event_eth_rx_adapter.c line count
Acked-by: Jerin Jacob <jerinj@marvell.com>
Applied to dpdk-next-eventdev/master. Thanks.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 4/5] examples/vdpa: support building from pkg-config info
@ 2019-07-02 7:57 3% ` Thomas Monjalon
2019-07-02 14:35 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-07-02 7:57 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev, bluca
17/05/2019 13:47, Bruce Richardson:
> The vdpa example app did not check for a libdpdk pkg-config file and
> attempt to build using that. Add support for that method of compile to
> align the app with the other examples.
I see an issue with the experimental tag:
clang -Wp,-MD,./.main.o.d.tmp -m64 -pthread -fPIC -Ilib/librte_eal/linux/eal/include -march=native -DRTE_MACHINE_CPUFLAG_SSE -DRTE_MACHINE_CPUFLAG_SSE2 -DRTE_MACHINE_CPUFLAG_SSE3 -DRTE_MACHINE_CPUFLAG_SSSE3 -DRTE_MACHINE_CPUFLAG_SSE4_1 -DRTE_MACHINE_CPUFLAG_SSE4_2 -DRTE_MACHINE_CPUFLAG_AES -DRTE_MACHINE_CPUFLAG_PCLMULQDQ -DRTE_MACHINE_CPUFLAG_AVX -DRTE_MACHINE_CPUFLAG_RDRAND -DRTE_MACHINE_CPUFLAG_RDSEED -DRTE_MACHINE_CPUFLAG_FSGSBASE -DRTE_MACHINE_CPUFLAG_F16C -DRTE_MACHINE_CPUFLAG_AVX2 -Ix86_64-native-linux-clang+shared+next+debug+ASSERT/examples/vdpa/x86_64-native-linux-clang+shared+next+debug+ASSERT/include -Ix86_64-native-linux-clang+shared+next+debug+ASSERT/include -include x86_64-native-linux-clang+shared+next+debug+ASSERT/include/rte_config.h -D_GNU_SOURCE -O2 -D_FILE_OFFSET_BITS=64 -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wold-style-definition -Wpointer-arith -Wnested-externs -Wcast-qual -Wformat-nonliteral -Wformat-security -Wundef -Wwrite-strings -Wdeprecated -Werror -Wno-missing-field-initializers -Wno-address-of-packed-member -D_GNU_SOURCE -o main.o -c examples/vdpa/main.c
examples/vdpa/main.c:172:8: error: 'rte_vhost_driver_attach_vdpa_device' is deprecated: Symbol is not yet part of stable ABI [-Werror,-Wdeprecated-declarations]
It seems "CFLAGS += -DALLOW_EXPERIMENTAL_API"
is reset by the call to pkg-config.
> +build/$(APP)-shared: $(SRCS-y) Makefile $(PC_FILE) | build
Better to use the real directory name as prerequisite,
instead of "build".
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper library
2019-06-28 11:34 0% ` [dpdk-dev] [EXT] " Anoob Joseph
@ 2019-07-02 14:17 0% ` Anoob Joseph
2019-07-02 14:26 0% ` Jerin Jacob Kollanukkaran
0 siblings, 1 reply; 200+ results
From: Anoob Joseph @ 2019-07-02 14:17 UTC (permalink / raw)
To: Thomas Monjalon, Jerin Jacob Kollanukkaran
Cc: dev, Mattias Rönnblom, Nikhil Rao, Erik Gabriel Carrillo,
Abhinandan Gujjar, Bruce Richardson, Pablo de Lara,
Narayana Prasad Raju Athreya, Lukas Bartosik,
Pavan Nikhilesh Bhagavatula, Hemant Agrawal, Nipun Gupta,
Harry van Haaren, Liang Ma, techboard
Hi Thomas, Jerin,
Is there any consensus on how we should proceed? Can this be taken up by techboard?
Thanks,
Anoob
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Anoob Joseph
> Sent: Friday, June 28, 2019 5:04 PM
> To: Thomas Monjalon <thomas@monjalon.net>; Jerin Jacob Kollanukkaran
> <jerinj@marvell.com>
> Cc: dev@dpdk.org; Mattias Rönnblom <mattias.ronnblom@ericsson.com>;
> Nikhil Rao <nikhil.rao@intel.com>; Erik Gabriel Carrillo
> <erik.g.carrillo@intel.com>; Abhinandan Gujjar <abhinandan.gujjar@intel.com>;
> Bruce Richardson <bruce.richardson@intel.com>; Pablo de Lara
> <pablo.de.lara.guarch@intel.com>; Narayana Prasad Raju Athreya
> <pathreya@marvell.com>; Lukas Bartosik <lbartosik@marvell.com>; Pavan
> Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Hemant Agrawal
> <hemant.agrawal@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>; Harry van
> Haaren <harry.van.haaren@intel.com>; Liang Ma <liang.j.ma@intel.com>;
> techboard@dpdk.org
> Subject: Re: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper
> library
>
> Hi Thomas, Jerin,
>
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Thomas Monjalon
> > Sent: Friday, June 28, 2019 2:10 PM
> > To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Anoob Joseph
> > <anoobj@marvell.com>
> > Cc: dev@dpdk.org; Mattias Rönnblom <mattias.ronnblom@ericsson.com>;
> > Nikhil Rao <nikhil.rao@intel.com>; Erik Gabriel Carrillo
> > <erik.g.carrillo@intel.com>; Abhinandan Gujjar
> > <abhinandan.gujjar@intel.com>; Bruce Richardson
> > <bruce.richardson@intel.com>; Pablo de Lara
> > <pablo.de.lara.guarch@intel.com>; Narayana Prasad Raju Athreya
> > <pathreya@marvell.com>; Lukas Bartosik <lbartosik@marvell.com>; Pavan
> > Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Hemant Agrawal
> > <hemant.agrawal@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>; Harry
> van
> > Haaren <harry.van.haaren@intel.com>; Liang Ma <liang.j.ma@intel.com>;
> > techboard@dpdk.org
> > Subject: [EXT] Re: [dpdk-dev] [PATCH 00/39] adding eventmode helper
> > library
> >
> > External Email
> >
> > ----------------------------------------------------------------------
> > 28/06/2019 05:37, Jerin Jacob Kollanukkaran:
> > > From: Anoob Joseph
> > > > From: Jerin Jacob Kollanukkaran
> > > > > From: Anoob Joseph
> > > > > > The helper library will be experimental while we add
> > > > > > event-mode support for other applications like l3fwd &
> > > > > > ipsec-secgw. I expect the helper library to be complete over
> > > > > > the course of those applications also using the helper library.
> >
> > You are doing a copy of l2fwd example to add event mode.
> > It was the decision from the techboard to not complicate the original l2fwd.
> > But it makes me nervous to see some code duplicated, especially if you
> > plan to do the same for l3fwd and ipsec-secgw.
> > We are not going to duplicate every examples. We should re-consider.
> >
>
> [Anoob] For l3fwd & ipsec-secgw, the plan is to add eventmode in the original
> application itself. If you have concerns about code duplication in l2fwd-event,
> the changes can be added to l2fwd itself. Please advise on how to proceed.
>
> > > > > I have only concern about moving this as library inside eventdev
> > > > > that till we have mature version of helper library the eventdev
> > > > > library ABI will not stable(i.e .so file version needs to be
> > > > > incremented as when a change needed). Which align with Mattias
> > > > > thoughts for some other reason:. How about moving this code to
> > > > > 1) example/common or
> > > > > 2) to specific application itself, once at least two
> > > > > applications starts using it then move to Eventdev library.
> > > > >
> > > > > Thoughts?
> > > >
> > > > [Anoob] Either location is not a problem if there is a consensus.
> > > > Earlier the suggestion was to move it to library (when the patch
> > > > was submitted with changes added in app).
> >
> > If there is only one user, making it grow in the application looks to
> > be the best thing to do.
> > Should we use it in more applications before it is more mature?
> > If not, we could move the code in eventdev library when we will use it
> > in more examples.
> >
>
> [Anoob] The proposal with l2fwd-event was to present an easy enough example
> so that the APIs can be decided before moving onto complex examples.
> Additions to l3fwd & ipsec-secgw is in the pipeline.
>
> > > If there NO objections then lets move to example/common.
> >
> > If we really want to have this library standalone in examples, I
> > suggest to give it a name and not use a "common" directory.
> >
>
> [Anoob] I would suggest to add the eventmode code in 'examples/utils'.
>
> What is being added here can be treated as a utility library. Almost all examples
> have duplicated code for the entire conf parsing, ethdev init etc. Anyone who
> would attempt a new application will have to duplicate lot of code. So a similar
> exercise with regular poll mode is also possible.
>
> As for build, we will have the following options,
>
> 1. From the examples/<example>/Makefile, build *helper*.o files (
> '../utils/eventmode_helper.o') and prepare the binary. So each application will
> build its own version of *helper*.c
> +SRCS-y += ../utils/eventmode_helper.c
>
> 2. Make 'examples/utils' a separate library. This way, all applications can directly
> link without having to build separately.
>
> Please do suggest on which would be a good way to execute.
>
> Thanks,
> Anoob
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper library
2019-07-02 14:17 0% ` Anoob Joseph
@ 2019-07-02 14:26 0% ` Jerin Jacob Kollanukkaran
0 siblings, 0 replies; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-07-02 14:26 UTC (permalink / raw)
To: Anoob Joseph, Thomas Monjalon
Cc: dev, Mattias Rönnblom, Nikhil Rao, Erik Gabriel Carrillo,
Abhinandan Gujjar, Bruce Richardson, Pablo de Lara,
Narayana Prasad Raju Athreya, Lukas Bartosik,
Pavan Nikhilesh Bhagavatula, Hemant Agrawal, Nipun Gupta,
Harry van Haaren, Liang Ma, techboard
> -----Original Message-----
> From: Anoob Joseph
> Sent: Tuesday, July 2, 2019 7:47 PM
> To: Thomas Monjalon <thomas@monjalon.net>; Jerin Jacob Kollanukkaran
> <jerinj@marvell.com>
> Cc: dev@dpdk.org; Mattias Rönnblom <mattias.ronnblom@ericsson.com>;
> Nikhil Rao <nikhil.rao@intel.com>; Erik Gabriel Carrillo
> <erik.g.carrillo@intel.com>; Abhinandan Gujjar <abhinandan.gujjar@intel.com>;
> Bruce Richardson <bruce.richardson@intel.com>; Pablo de Lara
> <pablo.de.lara.guarch@intel.com>; Narayana Prasad Raju Athreya
> <pathreya@marvell.com>; Lukas Bartosik <lbartosik@marvell.com>; Pavan
> Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Hemant Agrawal
> <hemant.agrawal@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>; Harry van
> Haaren <harry.van.haaren@intel.com>; Liang Ma <liang.j.ma@intel.com>;
> techboard@dpdk.org
> Subject: RE: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode helper
> library
>
> Hi Thomas, Jerin,
>
> Is there any consensus on how we should proceed? Can this be taken up by
> techboard?
For me it make sense to move these helper functions to examples/.. and make it as standalone(not as library)
Suggested directory(In the order of my preference). No strong preference on the directory name though
1) examples/helper or
2) examples/common or
3) examples/utils
Thomas? Bruce?
>
> Thanks,
> Anoob
>
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of Anoob Joseph
> > Sent: Friday, June 28, 2019 5:04 PM
> > To: Thomas Monjalon <thomas@monjalon.net>; Jerin Jacob Kollanukkaran
> > <jerinj@marvell.com>
> > Cc: dev@dpdk.org; Mattias Rönnblom <mattias.ronnblom@ericsson.com>;
> > Nikhil Rao <nikhil.rao@intel.com>; Erik Gabriel Carrillo
> > <erik.g.carrillo@intel.com>; Abhinandan Gujjar
> > <abhinandan.gujjar@intel.com>; Bruce Richardson
> > <bruce.richardson@intel.com>; Pablo de Lara
> > <pablo.de.lara.guarch@intel.com>; Narayana Prasad Raju Athreya
> > <pathreya@marvell.com>; Lukas Bartosik <lbartosik@marvell.com>; Pavan
> > Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Hemant Agrawal
> > <hemant.agrawal@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>; Harry
> van
> > Haaren <harry.van.haaren@intel.com>; Liang Ma <liang.j.ma@intel.com>;
> > techboard@dpdk.org
> > Subject: Re: [dpdk-dev] [EXT] Re: [PATCH 00/39] adding eventmode
> > helper library
> >
> > Hi Thomas, Jerin,
> >
> > > -----Original Message-----
> > > From: dev <dev-bounces@dpdk.org> On Behalf Of Thomas Monjalon
> > > Sent: Friday, June 28, 2019 2:10 PM
> > > To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Anoob Joseph
> > > <anoobj@marvell.com>
> > > Cc: dev@dpdk.org; Mattias Rönnblom <mattias.ronnblom@ericsson.com>;
> > > Nikhil Rao <nikhil.rao@intel.com>; Erik Gabriel Carrillo
> > > <erik.g.carrillo@intel.com>; Abhinandan Gujjar
> > > <abhinandan.gujjar@intel.com>; Bruce Richardson
> > > <bruce.richardson@intel.com>; Pablo de Lara
> > > <pablo.de.lara.guarch@intel.com>; Narayana Prasad Raju Athreya
> > > <pathreya@marvell.com>; Lukas Bartosik <lbartosik@marvell.com>;
> > > Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Hemant
> > > Agrawal <hemant.agrawal@nxp.com>; Nipun Gupta
> <nipun.gupta@nxp.com>;
> > > Harry
> > van
> > > Haaren <harry.van.haaren@intel.com>; Liang Ma
> > > <liang.j.ma@intel.com>; techboard@dpdk.org
> > > Subject: [EXT] Re: [dpdk-dev] [PATCH 00/39] adding eventmode helper
> > > library
> > >
> > > External Email
> > >
> > > --------------------------------------------------------------------
> > > --
> > > 28/06/2019 05:37, Jerin Jacob Kollanukkaran:
> > > > From: Anoob Joseph
> > > > > From: Jerin Jacob Kollanukkaran
> > > > > > From: Anoob Joseph
> > > > > > > The helper library will be experimental while we add
> > > > > > > event-mode support for other applications like l3fwd &
> > > > > > > ipsec-secgw. I expect the helper library to be complete over
> > > > > > > the course of those applications also using the helper library.
> > >
> > > You are doing a copy of l2fwd example to add event mode.
> > > It was the decision from the techboard to not complicate the original l2fwd.
> > > But it makes me nervous to see some code duplicated, especially if
> > > you plan to do the same for l3fwd and ipsec-secgw.
> > > We are not going to duplicate every examples. We should re-consider.
> > >
> >
> > [Anoob] For l3fwd & ipsec-secgw, the plan is to add eventmode in the
> > original application itself. If you have concerns about code
> > duplication in l2fwd-event, the changes can be added to l2fwd itself. Please
> advise on how to proceed.
> >
> > > > > > I have only concern about moving this as library inside
> > > > > > eventdev that till we have mature version of helper library
> > > > > > the eventdev library ABI will not stable(i.e .so file version
> > > > > > needs to be incremented as when a change needed). Which align
> > > > > > with Mattias thoughts for some other reason:. How about moving
> > > > > > this code to
> > > > > > 1) example/common or
> > > > > > 2) to specific application itself, once at least two
> > > > > > applications starts using it then move to Eventdev library.
> > > > > >
> > > > > > Thoughts?
> > > > >
> > > > > [Anoob] Either location is not a problem if there is a consensus.
> > > > > Earlier the suggestion was to move it to library (when the patch
> > > > > was submitted with changes added in app).
> > >
> > > If there is only one user, making it grow in the application looks
> > > to be the best thing to do.
> > > Should we use it in more applications before it is more mature?
> > > If not, we could move the code in eventdev library when we will use
> > > it in more examples.
> > >
> >
> > [Anoob] The proposal with l2fwd-event was to present an easy enough
> > example so that the APIs can be decided before moving onto complex
> examples.
> > Additions to l3fwd & ipsec-secgw is in the pipeline.
> >
> > > > If there NO objections then lets move to example/common.
> > >
> > > If we really want to have this library standalone in examples, I
> > > suggest to give it a name and not use a "common" directory.
> > >
> >
> > [Anoob] I would suggest to add the eventmode code in 'examples/utils'.
> >
> > What is being added here can be treated as a utility library. Almost
> > all examples have duplicated code for the entire conf parsing, ethdev
> > init etc. Anyone who would attempt a new application will have to
> > duplicate lot of code. So a similar exercise with regular poll mode is also
> possible.
> >
> > As for build, we will have the following options,
> >
> > 1. From the examples/<example>/Makefile, build *helper*.o files (
> > '../utils/eventmode_helper.o') and prepare the binary. So each
> > application will build its own version of *helper*.c
> > +SRCS-y += ../utils/eventmode_helper.c
> >
> > 2. Make 'examples/utils' a separate library. This way, all
> > applications can directly link without having to build separately.
> >
> > Please do suggest on which would be a good way to execute.
> >
> > Thanks,
> > Anoob
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 4/5] examples/vdpa: support building from pkg-config info
2019-07-02 7:57 3% ` Thomas Monjalon
@ 2019-07-02 14:35 0% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2019-07-02 14:35 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, bluca
On Tue, Jul 02, 2019 at 09:57:48AM +0200, Thomas Monjalon wrote:
> 17/05/2019 13:47, Bruce Richardson:
> > The vdpa example app did not check for a libdpdk pkg-config file and
> > attempt to build using that. Add support for that method of compile to
> > align the app with the other examples.
>
> I see an issue with the experimental tag:
>
> clang -Wp,-MD,./.main.o.d.tmp -m64 -pthread -fPIC -Ilib/librte_eal/linux/eal/include -march=native -DRTE_MACHINE_CPUFLAG_SSE -DRTE_MACHINE_CPUFLAG_SSE2 -DRTE_MACHINE_CPUFLAG_SSE3 -DRTE_MACHINE_CPUFLAG_SSSE3 -DRTE_MACHINE_CPUFLAG_SSE4_1 -DRTE_MACHINE_CPUFLAG_SSE4_2 -DRTE_MACHINE_CPUFLAG_AES -DRTE_MACHINE_CPUFLAG_PCLMULQDQ -DRTE_MACHINE_CPUFLAG_AVX -DRTE_MACHINE_CPUFLAG_RDRAND -DRTE_MACHINE_CPUFLAG_RDSEED -DRTE_MACHINE_CPUFLAG_FSGSBASE -DRTE_MACHINE_CPUFLAG_F16C -DRTE_MACHINE_CPUFLAG_AVX2 -Ix86_64-native-linux-clang+shared+next+debug+ASSERT/examples/vdpa/x86_64-native-linux-clang+shared+next+debug+ASSERT/include -Ix86_64-native-linux-clang+shared+next+debug+ASSERT/include -include x86_64-native-linux-clang+shared+next+debug+ASSERT/include/rte_config.h -D_GNU_SOURCE -O2 -D_FILE_OFFSET_BITS=64 -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wold-style-definition -Wpointer-arith -Wnested-externs -Wcast-qual -Wformat-nonliteral -Wformat-security -Wundef -Wwrite-strings -Wdeprecated -Werror -Wno-missing-field-initializers -Wno-address-of-packed-member -D_GNU_SOURCE -o main.o -c examples/vdpa/main.c
> examples/vdpa/main.c:172:8: error: 'rte_vhost_driver_attach_vdpa_device' is deprecated: Symbol is not yet part of stable ABI [-Werror,-Wdeprecated-declarations]
>
> It seems "CFLAGS += -DALLOW_EXPERIMENTAL_API"
> is reset by the call to pkg-config.
>
No, it's not, it's reset by the call to the DPDK make build system in
the other leg of the code. I'll fix this in the Makefile in v3.
> > +build/$(APP)-shared: $(SRCS-y) Makefile $(PC_FILE) | build
>
> Better to use the real directory name as prerequisite,
> instead of "build".
>
Not sure what you mean here, build is the name of the directory. [This is
also consistent with what is done in all the other example makefiles. If it
needs updating, then it should be done as a general patch to all examples
in 19.11 release timeframe.]
/Bruce
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC PATCH] bus/pci: avoid depending on private value in kernel source
@ 2019-07-03 8:26 3% ` David Marchand
2019-07-03 8:59 0% ` Tiwei Bie
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2019-07-03 8:26 UTC (permalink / raw)
To: Tiwei Bie; +Cc: dev, Burakov, Anatoly
On Wed, Jul 3, 2019 at 10:17 AM Tiwei Bie <tiwei.bie@intel.com> wrote:
> On Wed, Jul 03, 2019 at 10:01:44AM +0200, David Marchand wrote:
> > On Wed, Jul 3, 2019 at 9:58 AM Tiwei Bie <tiwei.bie@intel.com> wrote:
> >
> > On Wed, Jul 03, 2019 at 09:36:26AM +0200, David Marchand wrote:
> > > On Wed, Jul 3, 2019 at 9:35 AM Tiwei Bie <tiwei.bie@intel.com>
> wrote:
> > >
> > > Hi David,
> > >
> > > On Wed, Jul 03, 2019 at 09:02:59AM +0200, David Marchand wrote:
> > > > Hello,
> > > >
> > > > On Wed, Jul 3, 2019 at 7:47 AM Tiwei Bie <
> tiwei.bie@intel.com>
> > wrote:
> > > >
> > > > The value 40 used in VFIO_GET_REGION_ADDR() is a private
> value
> > > > (VFIO_PCI_OFFSET_SHIFT) defined in Linux kernel source
> [1]. It
> > > > is not part of VFIO API, and we should not depend on it.
> > > >
> > > > [1]
> https://github.com/torvalds/linux/blob/6fbc7275c7a9/drivers
> > /vfio/
> > > pci/
> > > > vfio_pci_private.h#L19
> > > >
> > > >
> > > >
> > > > I did not follow linux kernel changes, is there something
> that
> > would
> > > change
> > > > this offset?
> > > > It looks like a cleanup (did not look into the details yet),
> do we
> > need
> > > this
> > > > now?
> > >
> > > In VFIO/mdev [1], the offset can be something different. It
> depends
> > > on the parent device. It's not just a cleanup. It's a
> preparation
> > > for the mdev support in DPDK.
> > >
> > > [1]
> https://github.com/torvalds/linux/blob/master/Documentation/
> > > vfio-mediated-device.txt
> > >
> > >
> > >
> > > Ok, thanks.
> > > So we can wait for mdev to be ready before working on this.
> >
> > What do you mean by "mdev to be ready"? RFC ready? I don't see
> > anything blocking the discussion on this now.
> >
> > PS. I already sent a RFC series of the mdev support in DPDK
> > to the mailing list 3 month ago.
> >
> >
> > If you need it and the mdev support has been posted already, why not
> send a n+1
> > patchset with this patch in it?
> >
> > This patch alone looked odd to me.
>
> That series was using the old API which assumes the shift
> is 40 which may not work in some cases. And this patch is
> to fix the API. I think this patch is actually trying to
> fix a relatively independent issue -- i.e. switching to using
> the proper VFIO API to get the region offsets instead of
> depending on kernel code's internal value.
>
>
Fix, then there is something broken ?
You said this is for mdev support which is not currently part of the
features supported by DPDK.
This patch breaks the ABI by extending rte_pci_device.
You must rework it to avoid this break.
--
David Marchand
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC PATCH] bus/pci: avoid depending on private value in kernel source
2019-07-03 8:26 3% ` David Marchand
@ 2019-07-03 8:59 0% ` Tiwei Bie
2019-07-03 9:10 0% ` David Marchand
0 siblings, 1 reply; 200+ results
From: Tiwei Bie @ 2019-07-03 8:59 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Burakov, Anatoly
On Wed, Jul 03, 2019 at 10:26:39AM +0200, David Marchand wrote:
> On Wed, Jul 3, 2019 at 10:17 AM Tiwei Bie <tiwei.bie@intel.com> wrote:
>
> On Wed, Jul 03, 2019 at 10:01:44AM +0200, David Marchand wrote:
> > On Wed, Jul 3, 2019 at 9:58 AM Tiwei Bie <tiwei.bie@intel.com> wrote:
> >
> > On Wed, Jul 03, 2019 at 09:36:26AM +0200, David Marchand wrote:
> > > On Wed, Jul 3, 2019 at 9:35 AM Tiwei Bie <tiwei.bie@intel.com>
> wrote:
> > >
> > > Hi David,
> > >
> > > On Wed, Jul 03, 2019 at 09:02:59AM +0200, David Marchand wrote:
> > > > Hello,
> > > >
> > > > On Wed, Jul 3, 2019 at 7:47 AM Tiwei Bie <tiwei.bie@intel.com
> >
> > wrote:
> > > >
> > > > The value 40 used in VFIO_GET_REGION_ADDR() is a private
> value
> > > > (VFIO_PCI_OFFSET_SHIFT) defined in Linux kernel source
> [1]. It
> > > > is not part of VFIO API, and we should not depend on it.
> > > >
> > > > [1] https://github.com/torvalds/linux/blob/6fbc7275c7a9/
> drivers
> > /vfio/
> > > pci/
> > > > vfio_pci_private.h#L19
> > > >
> > > >
> > > >
> > > > I did not follow linux kernel changes, is there something
> that
> > would
> > > change
> > > > this offset?
> > > > It looks like a cleanup (did not look into the details yet),
> do we
> > need
> > > this
> > > > now?
> > >
> > > In VFIO/mdev [1], the offset can be something different. It
> depends
> > > on the parent device. It's not just a cleanup. It's a
> preparation
> > > for the mdev support in DPDK.
> > >
> > > [1] https://github.com/torvalds/linux/blob/master/Documentation
> /
> > > vfio-mediated-device.txt
> > >
> > >
> > >
> > > Ok, thanks.
> > > So we can wait for mdev to be ready before working on this.
> >
> > What do you mean by "mdev to be ready"? RFC ready? I don't see
> > anything blocking the discussion on this now.
> >
> > PS. I already sent a RFC series of the mdev support in DPDK
> > to the mailing list 3 month ago.
> >
> >
> > If you need it and the mdev support has been posted already, why not send
> a n+1
> > patchset with this patch in it?
> >
> > This patch alone looked odd to me.
>
> That series was using the old API which assumes the shift
> is 40 which may not work in some cases. And this patch is
> to fix the API. I think this patch is actually trying to
> fix a relatively independent issue -- i.e. switching to using
> the proper VFIO API to get the region offsets instead of
> depending on kernel code's internal value.
>
>
>
> Fix, then there is something broken ?
I should use "fix" (with "") actually :)
> You said this is for mdev support which is not currently part of the features
> supported by DPDK.
>
>
> This patch breaks the ABI by extending rte_pci_device.
> You must rework it to avoid this break.
I didn't expect it to be merged in this release. I just want
to draw other's attention on this and kick off the discussion
(it would be great if you would like to share your thoughts
on this). If there is a way to avoid extending rte_pci_device,
it would be definitely great. But if we have to break it, then
we would want to send out the announce as early as possible.
Thanks,
Tiwei
>
>
> --
> David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC PATCH] bus/pci: avoid depending on private value in kernel source
2019-07-03 8:59 0% ` Tiwei Bie
@ 2019-07-03 9:10 0% ` David Marchand
2019-07-03 9:25 0% ` Tiwei Bie
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2019-07-03 9:10 UTC (permalink / raw)
To: Tiwei Bie; +Cc: dev, Burakov, Anatoly
On Wed, Jul 3, 2019 at 11:01 AM Tiwei Bie <tiwei.bie@intel.com> wrote:
> On Wed, Jul 03, 2019 at 10:26:39AM +0200, David Marchand wrote:
> > This patch breaks the ABI by extending rte_pci_device.
> > You must rework it to avoid this break.
>
> I didn't expect it to be merged in this release. I just want
> to draw other's attention on this and kick off the discussion
> (it would be great if you would like to share your thoughts
> on this). If there is a way to avoid extending rte_pci_device,
> it would be definitely great. But if we have to break it, then
> we would want to send out the announce as early as possible.
>
What we have here is a vfio private thing, we don't need it to be exposed.
Did not think it through yet.
How about having an internal (as in, in the pci driver code) representation
of the pci devices?
This internal structure would embed the rte_pci_device exposed to the
others subsystems and the applications and the vfio code would just get
what it wants by using offsetof?
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC PATCH] bus/pci: avoid depending on private value in kernel source
2019-07-03 9:10 0% ` David Marchand
@ 2019-07-03 9:25 0% ` Tiwei Bie
0 siblings, 0 replies; 200+ results
From: Tiwei Bie @ 2019-07-03 9:25 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Burakov, Anatoly
On Wed, Jul 03, 2019 at 11:10:21AM +0200, David Marchand wrote:
>
> On Wed, Jul 3, 2019 at 11:01 AM Tiwei Bie <tiwei.bie@intel.com> wrote:
>
> On Wed, Jul 03, 2019 at 10:26:39AM +0200, David Marchand wrote:
> > This patch breaks the ABI by extending rte_pci_device.
> > You must rework it to avoid this break.
>
> I didn't expect it to be merged in this release. I just want
> to draw other's attention on this and kick off the discussion
> (it would be great if you would like to share your thoughts
> on this). If there is a way to avoid extending rte_pci_device,
> it would be definitely great. But if we have to break it, then
> we would want to send out the announce as early as possible.
>
>
> What we have here is a vfio private thing, we don't need it to be exposed.
>
> Did not think it through yet.
> How about having an internal (as in, in the pci driver code) representation of
> the pci devices?
> This internal structure would embed the rte_pci_device exposed to the others
> subsystems and the applications and the vfio code would just get what it wants
> by using offsetof?
I think it's a good idea! I'll give it a try.
Thanks!
Tiwei
>
>
> --
> David Marchand
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v3 2/8] cryptodev: add digest encrypted feature flag
@ 2019-07-03 11:15 4% ` Damian Nowak
0 siblings, 0 replies; 200+ results
From: Damian Nowak @ 2019-07-03 11:15 UTC (permalink / raw)
To: dev; +Cc: akhil.goyal, fiona.trahe, arkadiuszx.kusztal, Damian Nowak
Some PMDs can only support digest being
encrypted separately in auth-cipher operations.
Thus it is required to add feature flag in PMD
to reflect if it does support digest-appended
both: digest generation with encryption and
decryption with digest verification.
This patch also adds information about new
feature flag to the release notes.
Signed-off-by: Damian Nowak <damianx.nowak@intel.com>
---
doc/guides/cryptodevs/features/default.ini | 1 +
doc/guides/cryptodevs/overview.rst | 3 +++
doc/guides/rel_notes/release_19_08.rst | 3 +++
lib/librte_cryptodev/rte_cryptodev.c | 2 ++
lib/librte_cryptodev/rte_cryptodev.h | 2 ++
5 files changed, 11 insertions(+)
diff --git a/doc/guides/cryptodevs/features/default.ini b/doc/guides/cryptodevs/features/default.ini
index 0e06261..d3ee1af 100644
--- a/doc/guides/cryptodevs/features/default.ini
+++ b/doc/guides/cryptodevs/features/default.ini
@@ -25,6 +25,7 @@ OOP LB In SGL Out =
OOP LB In LB Out =
RSA PRIV OP KEY EXP =
RSA PRIV OP KEY QT =
+Digest encrypted =
;
; Supported crypto algorithms of a default crypto driver.
diff --git a/doc/guides/cryptodevs/overview.rst b/doc/guides/cryptodevs/overview.rst
index a972c79..e2a1e08 100644
--- a/doc/guides/cryptodevs/overview.rst
+++ b/doc/guides/cryptodevs/overview.rst
@@ -43,6 +43,9 @@ Supported Feature Flags
- "RSA PRIV OP KEY QT" feature flag means PMD support RSA private key
operation (Sign and Decrypt) using quintuple (crt) type key only.
+ - "Digest encrypted" feature flag means PMD support hash-cipher cases,
+ where generated digest is appended to and encrypted with the data.
+
Supported Cipher Algorithms
---------------------------
diff --git a/doc/guides/rel_notes/release_19_08.rst b/doc/guides/rel_notes/release_19_08.rst
index 644a74b..c82b7f5 100644
--- a/doc/guides/rel_notes/release_19_08.rst
+++ b/doc/guides/rel_notes/release_19_08.rst
@@ -169,6 +169,9 @@ API Changes
structure (``rte_crypto_cipher_xform``, ``rte_crypto_auth_xform``, and
``rte_crypto_aead_xform``) have been changed to ``const uint8_t *data``.
+* cryptodev: ``RTE_CRYPTODEV_FF_DIGEST_ENCRYPTED`` feature flag
+ has been introduced.
+
ABI Changes
-----------
diff --git a/lib/librte_cryptodev/rte_cryptodev.c b/lib/librte_cryptodev/rte_cryptodev.c
index 240b849..43bc335 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -490,6 +490,8 @@ rte_cryptodev_get_feature_name(uint64_t flag)
return "RSA_PRIV_OP_KEY_EXP";
case RTE_CRYPTODEV_FF_RSA_PRIV_OP_KEY_QT:
return "RSA_PRIV_OP_KEY_QT";
+ case RTE_CRYPTODEV_FF_DIGEST_ENCRYPTED:
+ return "DIGEST_ENCRYPTED";
default:
return NULL;
}
diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h
index d701eea..e175b83 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -446,6 +446,8 @@ rte_cryptodev_asym_get_xform_enum(enum rte_crypto_asym_xform_type *xform_enum,
/**< Support RSA Private Key OP with exponent */
#define RTE_CRYPTODEV_FF_RSA_PRIV_OP_KEY_QT (1ULL << 18)
/**< Support RSA Private Key OP with CRT (quintuple) Keys */
+#define RTE_CRYPTODEV_FF_DIGEST_ENCRYPTED (1ULL << 19)
+/**< Support encrypted-digest operations where digest is appended to data */
/**
--
2.7.4
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add GRE key field to flow API
@ 2019-07-03 15:25 4% ` Adrien Mazarguil
2019-07-04 2:43 0% ` Jack Min
0 siblings, 1 reply; 200+ results
From: Adrien Mazarguil @ 2019-07-03 15:25 UTC (permalink / raw)
To: Xiaoyu Min
Cc: orika, John McNamara, Marko Kovacevic, Thomas Monjalon,
Ferruh Yigit, Andrew Rybchenko, dev
On Tue, Jul 02, 2019 at 05:45:52PM +0800, Xiaoyu Min wrote:
> Add new rte_flow_item_gre_key in order to match the optional key field.
>
> Signed-off-by: Xiaoyu Min <jackmin@mellanox.com>
OK with adding this feature, however I still have a bunch of comments below.
> ---
> doc/guides/prog_guide/rte_flow.rst | 8 ++++++++
> lib/librte_ethdev/rte_flow.c | 1 +
> lib/librte_ethdev/rte_flow.h | 7 +++++++
> 3 files changed, 16 insertions(+)
>
> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> index a34d012e55..f4b7baa3c3 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -980,6 +980,14 @@ Matches a GRE header.
> - ``protocol``: protocol type.
> - Default ``mask`` matches protocol only.
>
> +Item: ``GRE_KEY``
> +^^^^^^^^^^^^^^^^^
> +
> +Matches a GRE key field.
> +This should be preceded by item ``GRE``
Nit: missing ending "."
> +
> +- Value to be matched is a big-endian 32 bit integer
> +
> Item: ``FUZZY``
> ^^^^^^^^^^^^^^^
>
> diff --git a/lib/librte_ethdev/rte_flow.c b/lib/librte_ethdev/rte_flow.c
> index 3277be1edb..f3e56d0bbe 100644
> --- a/lib/librte_ethdev/rte_flow.c
> +++ b/lib/librte_ethdev/rte_flow.c
> @@ -55,6 +55,7 @@ static const struct rte_flow_desc_data rte_flow_desc_item[] = {
> MK_FLOW_ITEM(NVGRE, sizeof(struct rte_flow_item_nvgre)),
> MK_FLOW_ITEM(MPLS, sizeof(struct rte_flow_item_mpls)),
> MK_FLOW_ITEM(GRE, sizeof(struct rte_flow_item_gre)),
> + MK_FLOW_ITEM(GRE_KEY, sizeof(rte_be32_t)),
Hmm? Adding a new item in the middle?
> MK_FLOW_ITEM(FUZZY, sizeof(struct rte_flow_item_fuzzy)),
> MK_FLOW_ITEM(GTP, sizeof(struct rte_flow_item_gtp)),
> MK_FLOW_ITEM(GTPC, sizeof(struct rte_flow_item_gtp)),
> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> index f3a8fb103f..5d3702a44c 100644
> --- a/lib/librte_ethdev/rte_flow.h
> +++ b/lib/librte_ethdev/rte_flow.h
> @@ -289,6 +289,13 @@ enum rte_flow_item_type {
> */
> RTE_FLOW_ITEM_TYPE_GRE,
>
> + /**
> + * Matches a GRE optional key field.
> + *
> + * The value should a big-endian 32bit integer.
> + */
> + RTE_FLOW_ITEM_TYPE_GRE_KEY,
> +
Same comment. While I understand the intent to group GRE and GRE_KEY, doing
so causes ABI breakage by shifting the value of all subsequent pattern
items (see IPV6 and IPV6_EXT for instance).
We could later decide to sort them while knowingly breaking ABI on purpose,
however right now there's no choice but adding new pattern items and actions
at the end of their respective enums, please do that.
--
Adrien Mazarguil
6WIND
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v6 2/7] bbdev: extension of BBDEV API for 5G FEC
@ 2019-07-03 15:24 3% ` Nicolas Chautru
2019-07-03 15:24 2% ` [dpdk-dev] [PATCH v6 4/7] baseband/turbo_sw: extension of turbosw PMD for 5G Nicolas Chautru
1 sibling, 0 replies; 200+ results
From: Nicolas Chautru @ 2019-07-03 15:24 UTC (permalink / raw)
To: akhil.goyal, dev
Cc: ferruh.yigit, thomas, amr.mokhtar, kamilx.chalupnik, Nicolas Chautru
Extension to BBDEV operations to support 5G
on top of existing 4G operations.
Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
Acked-by: Amr Mokhtar <amr.mokhtar@intel.com>
---
doc/guides/rel_notes/release_19_08.rst | 4 +-
lib/librte_bbdev/rte_bbdev.c | 22 +-
lib/librte_bbdev/rte_bbdev.h | 138 +++++++-
lib/librte_bbdev/rte_bbdev_op.h | 567 ++++++++++++++++++++++++++-------
4 files changed, 608 insertions(+), 123 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_08.rst b/doc/guides/rel_notes/release_19_08.rst
index 335d24a..55ae8ee 100644
--- a/doc/guides/rel_notes/release_19_08.rst
+++ b/doc/guides/rel_notes/release_19_08.rst
@@ -126,7 +126,6 @@ New Features
Added telemetry mode to l3fwd-power application to report
application level busyness, empty and full polls of rte_eth_rx_burst().
-
Removed Items
-------------
@@ -192,6 +191,9 @@ ABI Changes
Disabling unused features would facilitate efficient usage of HW/SW offload.
+* bbdev: New operations and parameters added to support new 5GNR operations.
+ The bbdev ABI is still kept experimental.
+
Shared Library Versions
-----------------------
diff --git a/lib/librte_bbdev/rte_bbdev.c b/lib/librte_bbdev/rte_bbdev.c
index 0c35480..f6fe05a 100644
--- a/lib/librte_bbdev/rte_bbdev.c
+++ b/lib/librte_bbdev/rte_bbdev.c
@@ -6,7 +6,6 @@
#include <string.h>
#include <stdbool.h>
-#include <rte_string_fns.h>
#include <rte_compat.h>
#include <rte_common.h>
#include <rte_errno.h>
@@ -215,7 +214,7 @@ struct rte_bbdev *
bbdev->data->dev_id = dev_id;
bbdev->state = RTE_BBDEV_INITIALIZED;
- ret = strlcpy(bbdev->data->name, name, RTE_BBDEV_NAME_MAX_LEN);
+ ret = snprintf(bbdev->data->name, RTE_BBDEV_NAME_MAX_LEN, "%s", name);
if ((ret < 0) || (ret >= RTE_BBDEV_NAME_MAX_LEN)) {
rte_bbdev_log(ERR, "Copying device name \"%s\" failed", name);
return NULL;
@@ -499,7 +498,7 @@ struct rte_bbdev *
if (conf->op_type == RTE_BBDEV_OP_TURBO_DEC &&
conf->priority > dev_info.max_ul_queue_priority) {
rte_bbdev_log(ERR,
- "Priority (%u) of queue %u of bdev %u must be <= %u",
+ "Priority (%u) of queue %u of bbdev %u must be <= %u",
conf->priority, queue_id, dev_id,
dev_info.max_ul_queue_priority);
return -EINVAL;
@@ -507,7 +506,7 @@ struct rte_bbdev *
if (conf->op_type == RTE_BBDEV_OP_TURBO_ENC &&
conf->priority > dev_info.max_dl_queue_priority) {
rte_bbdev_log(ERR,
- "Priority (%u) of queue %u of bdev %u must be <= %u",
+ "Priority (%u) of queue %u of bbdev %u must be <= %u",
conf->priority, queue_id, dev_id,
dev_info.max_dl_queue_priority);
return -EINVAL;
@@ -796,7 +795,7 @@ struct rte_bbdev *
memset(dev_info, 0, sizeof(*dev_info));
dev_info->dev_name = dev->data->name;
dev_info->num_queues = dev->data->num_queues;
- dev_info->bus = rte_bus_find_by_device(dev->device);
+ dev_info->device = dev->device;
dev_info->socket_id = dev->data->socket_id;
dev_info->started = dev->data->started;
@@ -847,6 +846,12 @@ struct rte_bbdev *
case RTE_BBDEV_OP_TURBO_ENC:
result = sizeof(struct rte_bbdev_enc_op);
break;
+ case RTE_BBDEV_OP_LDPC_DEC:
+ result = sizeof(struct rte_bbdev_dec_op);
+ break;
+ case RTE_BBDEV_OP_LDPC_ENC:
+ result = sizeof(struct rte_bbdev_enc_op);
+ break;
default:
break;
}
@@ -861,11 +866,12 @@ struct rte_bbdev *
{
enum rte_bbdev_op_type type = *(enum rte_bbdev_op_type *)arg;
- if (type == RTE_BBDEV_OP_TURBO_DEC) {
+ if (type == RTE_BBDEV_OP_TURBO_DEC || type == RTE_BBDEV_OP_LDPC_DEC) {
struct rte_bbdev_dec_op *op = element;
memset(op, 0, mempool->elt_size);
op->mempool = mempool;
- } else if (type == RTE_BBDEV_OP_TURBO_ENC) {
+ } else if (type == RTE_BBDEV_OP_TURBO_ENC ||
+ type == RTE_BBDEV_OP_LDPC_ENC) {
struct rte_bbdev_enc_op *op = element;
memset(op, 0, mempool->elt_size);
op->mempool = mempool;
@@ -1117,6 +1123,8 @@ struct rte_mempool *
"RTE_BBDEV_OP_NONE",
"RTE_BBDEV_OP_TURBO_DEC",
"RTE_BBDEV_OP_TURBO_ENC",
+ "RTE_BBDEV_OP_LDPC_DEC",
+ "RTE_BBDEV_OP_LDPC_ENC",
};
if (op_type < RTE_BBDEV_OP_TYPE_COUNT)
diff --git a/lib/librte_bbdev/rte_bbdev.h b/lib/librte_bbdev/rte_bbdev.h
index c5175cc..591fb79 100644
--- a/lib/librte_bbdev/rte_bbdev.h
+++ b/lib/librte_bbdev/rte_bbdev.h
@@ -167,7 +167,7 @@ struct rte_bbdev_queue_conf {
/**
* Start a device.
- * This is the last step needed before enqueuing operations is possible.
+ * This is the last step needed before enqueueing operations is possible.
*
* @param dev_id
* The identifier of the device.
@@ -326,7 +326,7 @@ struct rte_bbdev_driver_info {
struct rte_bbdev_info {
int socket_id; /**< NUMA socket that device is on */
const char *dev_name; /**< Unique device name */
- const struct rte_bus *bus; /**< Bus information */
+ const struct rte_device *device; /**< Device Information */
uint16_t num_queues; /**< Number of queues currently configured */
bool started; /**< Set if device is currently started */
struct rte_bbdev_driver_info drv; /**< Info from device driver */
@@ -448,6 +448,14 @@ struct __rte_cache_aligned rte_bbdev {
rte_bbdev_dequeue_enc_ops_t dequeue_enc_ops;
/**< Dequeue decode function */
rte_bbdev_dequeue_dec_ops_t dequeue_dec_ops;
+ /**< Enqueue encode function */
+ rte_bbdev_enqueue_enc_ops_t enqueue_ldpc_enc_ops;
+ /**< Enqueue decode function */
+ rte_bbdev_enqueue_dec_ops_t enqueue_ldpc_dec_ops;
+ /**< Dequeue encode function */
+ rte_bbdev_dequeue_enc_ops_t dequeue_ldpc_enc_ops;
+ /**< Dequeue decode function */
+ rte_bbdev_dequeue_dec_ops_t dequeue_ldpc_dec_ops;
const struct rte_bbdev_ops *dev_ops; /**< Functions exported by PMD */
struct rte_bbdev_data *data; /**< Pointer to device data */
enum rte_bbdev_state state; /**< If device is currently used or not */
@@ -523,6 +531,69 @@ struct __rte_cache_aligned rte_bbdev {
}
/**
+ * Enqueue a burst of processed encode operations to a queue of the device.
+ * This functions only enqueues as many operations as currently possible and
+ * does not block until @p num_ops entries in the queue are available.
+ * This function does not provide any error notification to avoid the
+ * corresponding overhead.
+ *
+ * @param dev_id
+ * The identifier of the device.
+ * @param queue_id
+ * The index of the queue.
+ * @param ops
+ * Pointer array containing operations to be enqueued Must have at least
+ * @p num_ops entries
+ * @param num_ops
+ * The maximum number of operations to enqueue.
+ *
+ * @return
+ * The number of operations actually enqueued (this is the number of processed
+ * entries in the @p ops array).
+ */
+__rte_experimental
+static inline uint16_t
+rte_bbdev_enqueue_ldpc_enc_ops(uint16_t dev_id, uint16_t queue_id,
+ struct rte_bbdev_enc_op **ops, uint16_t num_ops)
+{
+ struct rte_bbdev *dev = &rte_bbdev_devices[dev_id];
+ struct rte_bbdev_queue_data *q_data = &dev->data->queues[queue_id];
+ return dev->enqueue_ldpc_enc_ops(q_data, ops, num_ops);
+}
+
+/**
+ * Enqueue a burst of processed decode operations to a queue of the device.
+ * This functions only enqueues as many operations as currently possible and
+ * does not block until @p num_ops entries in the queue are available.
+ * This function does not provide any error notification to avoid the
+ * corresponding overhead.
+ *
+ * @param dev_id
+ * The identifier of the device.
+ * @param queue_id
+ * The index of the queue.
+ * @param ops
+ * Pointer array containing operations to be enqueued Must have at least
+ * @p num_ops entries
+ * @param num_ops
+ * The maximum number of operations to enqueue.
+ *
+ * @return
+ * The number of operations actually enqueued (this is the number of processed
+ * entries in the @p ops array).
+ */
+__rte_experimental
+static inline uint16_t
+rte_bbdev_enqueue_ldpc_dec_ops(uint16_t dev_id, uint16_t queue_id,
+ struct rte_bbdev_dec_op **ops, uint16_t num_ops)
+{
+ struct rte_bbdev *dev = &rte_bbdev_devices[dev_id];
+ struct rte_bbdev_queue_data *q_data = &dev->data->queues[queue_id];
+ return dev->enqueue_ldpc_dec_ops(q_data, ops, num_ops);
+}
+
+
+/**
* Dequeue a burst of processed encode operations from a queue of the device.
* This functions returns only the current contents of the queue, and does not
* block until @ num_ops is available.
@@ -585,6 +656,69 @@ struct __rte_cache_aligned rte_bbdev {
return dev->dequeue_dec_ops(q_data, ops, num_ops);
}
+
+/**
+ * Dequeue a burst of processed encode operations from a queue of the device.
+ * This functions returns only the current contents of the queue, and does not
+ * block until @ num_ops is available.
+ * This function does not provide any error notification to avoid the
+ * corresponding overhead.
+ *
+ * @param dev_id
+ * The identifier of the device.
+ * @param queue_id
+ * The index of the queue.
+ * @param ops
+ * Pointer array where operations will be dequeued to. Must have at least
+ * @p num_ops entries
+ * @param num_ops
+ * The maximum number of operations to dequeue.
+ *
+ * @return
+ * The number of operations actually dequeued (this is the number of entries
+ * copied into the @p ops array).
+ */
+__rte_experimental
+static inline uint16_t
+rte_bbdev_dequeue_ldpc_enc_ops(uint16_t dev_id, uint16_t queue_id,
+ struct rte_bbdev_enc_op **ops, uint16_t num_ops)
+{
+ struct rte_bbdev *dev = &rte_bbdev_devices[dev_id];
+ struct rte_bbdev_queue_data *q_data = &dev->data->queues[queue_id];
+ return dev->dequeue_ldpc_enc_ops(q_data, ops, num_ops);
+}
+
+/**
+ * Dequeue a burst of processed decode operations from a queue of the device.
+ * This functions returns only the current contents of the queue, and does not
+ * block until @ num_ops is available.
+ * This function does not provide any error notification to avoid the
+ * corresponding overhead.
+ *
+ * @param dev_id
+ * The identifier of the device.
+ * @param queue_id
+ * The index of the queue.
+ * @param ops
+ * Pointer array where operations will be dequeued to. Must have at least
+ * @p num_ops entries
+ * @param num_ops
+ * The maximum number of operations to dequeue.
+ *
+ * @return
+ * The number of operations actually dequeued (this is the number of entries
+ * copied into the @p ops array).
+ */
+__rte_experimental
+static inline uint16_t
+rte_bbdev_dequeue_ldpc_dec_ops(uint16_t dev_id, uint16_t queue_id,
+ struct rte_bbdev_dec_op **ops, uint16_t num_ops)
+{
+ struct rte_bbdev *dev = &rte_bbdev_devices[dev_id];
+ struct rte_bbdev_queue_data *q_data = &dev->data->queues[queue_id];
+ return dev->dequeue_ldpc_dec_ops(q_data, ops, num_ops);
+}
+
/** Definitions of device event types */
enum rte_bbdev_event_type {
RTE_BBDEV_EVENT_UNKNOWN, /**< unknown event type */
diff --git a/lib/librte_bbdev/rte_bbdev_op.h b/lib/librte_bbdev/rte_bbdev_op.h
index d860989..1e119a7 100644
--- a/lib/librte_bbdev/rte_bbdev_op.h
+++ b/lib/librte_bbdev/rte_bbdev_op.h
@@ -31,57 +31,61 @@
#define RTE_BBDEV_TURBO_MAX_TB_SIZE (391656)
/* Maximum size of Code Block (36.212, Table 5.1.3-3) */
#define RTE_BBDEV_TURBO_MAX_CB_SIZE (6144)
+/* Maximum size of Code Block */
+#define RTE_BBDEV_LDPC_MAX_CB_SIZE (8448)
/* Minimum size of Code Block (36.212, Table 5.1.3-3) */
#define RTE_BBDEV_TURBO_MIN_CB_SIZE (40)
/* Maximum size of circular buffer */
#define RTE_BBDEV_TURBO_MAX_KW (18528)
/*
- * Maximum number of Code Blocks in Transport Block. It is calculated based on
- * maximum size of one Code Block and one Transport Block (considering CRC24A
- * and CRC24B):
+ * Turbo: Maximum number of Code Blocks in Transport Block. It is calculated
+ * based on maximum size of one Code Block and one Transport Block
+ * (considering CRC24A and CRC24B):
* (391656 + 24) / (6144 - 24) = 64
*/
#define RTE_BBDEV_TURBO_MAX_CODE_BLOCKS (64)
+/* LDPC: Maximum number of Code Blocks in Transport Block.*/
+#define RTE_BBDEV_LDPC_MAX_CODE_BLOCKS (256)
/** Flags for turbo decoder operation and capability structure */
enum rte_bbdev_op_td_flag_bitmasks {
- /**< If sub block de-interleaving is to be performed. */
+ /** If sub block de-interleaving is to be performed. */
RTE_BBDEV_TURBO_SUBBLOCK_DEINTERLEAVE = (1ULL << 0),
- /**< To use CRC Type 24B (otherwise use CRC Type 24A). */
+ /** To use CRC Type 24B (otherwise use CRC Type 24A). */
RTE_BBDEV_TURBO_CRC_TYPE_24B = (1ULL << 1),
- /**< If turbo equalization is to be performed. */
+ /** If turbo equalization is to be performed. */
RTE_BBDEV_TURBO_EQUALIZER = (1ULL << 2),
- /**< If set, saturate soft output to +/-127 */
+ /** If set, saturate soft output to +/-127 */
RTE_BBDEV_TURBO_SOFT_OUT_SATURATE = (1ULL << 3),
- /**< Set to 1 to start iteration from even, else odd; one iteration =
+ /** Set to 1 to start iteration from even, else odd; one iteration =
* max_iteration + 0.5
*/
RTE_BBDEV_TURBO_HALF_ITERATION_EVEN = (1ULL << 4),
- /**< If 0, TD stops after CRC matches; else if 1, runs to end of next
+ /** If 0, TD stops after CRC matches; else if 1, runs to end of next
* odd iteration after CRC matches
*/
RTE_BBDEV_TURBO_CONTINUE_CRC_MATCH = (1ULL << 5),
- /**< Set if soft output is required to be output */
+ /** Set if soft output is required to be output */
RTE_BBDEV_TURBO_SOFT_OUTPUT = (1ULL << 6),
- /**< Set to enable early termination mode */
+ /** Set to enable early termination mode */
RTE_BBDEV_TURBO_EARLY_TERMINATION = (1ULL << 7),
- /**< Set if a device supports decoder dequeue interrupts */
+ /** Set if a device supports decoder dequeue interrupts */
RTE_BBDEV_TURBO_DEC_INTERRUPTS = (1ULL << 9),
- /**< Set if positive LLR encoded input is supported. Positive LLR value
+ /** Set if positive LLR encoded input is supported. Positive LLR value
* represents the level of confidence for bit '1', and vice versa for
* bit '0'.
* This is mutually exclusive with RTE_BBDEV_TURBO_NEG_LLR_1_BIT_IN
* when used to formalize the input data format.
*/
RTE_BBDEV_TURBO_POS_LLR_1_BIT_IN = (1ULL << 10),
- /**< Set if negative LLR encoded input is supported. Negative LLR value
+ /** Set if negative LLR encoded input is supported. Negative LLR value
* represents the level of confidence for bit '1', and vice versa for
* bit '0'.
* This is mutually exclusive with RTE_BBDEV_TURBO_POS_LLR_1_BIT_IN
* when used to formalize the input data format.
*/
RTE_BBDEV_TURBO_NEG_LLR_1_BIT_IN = (1ULL << 11),
- /**< Set if positive LLR soft output is supported. Positive LLR value
+ /** Set if positive LLR soft output is supported. Positive LLR value
* represents the level of confidence for bit '1', and vice versa for
* bit '0'.
* This is mutually exclusive with
@@ -89,7 +93,7 @@ enum rte_bbdev_op_td_flag_bitmasks {
* the input data format.
*/
RTE_BBDEV_TURBO_POS_LLR_1_BIT_SOFT_OUT = (1ULL << 12),
- /**< Set if negative LLR soft output is supported. Negative LLR value
+ /** Set if negative LLR soft output is supported. Negative LLR value
* represents the level of confidence for bit '1', and vice versa for
* bit '0'.
* This is mutually exclusive with
@@ -97,43 +101,114 @@ enum rte_bbdev_op_td_flag_bitmasks {
* input data format.
*/
RTE_BBDEV_TURBO_NEG_LLR_1_BIT_SOFT_OUT = (1ULL << 13),
- /**< Set if driver supports flexible parallel MAP engine decoding. If
+ /** Set if driver supports flexible parallel MAP engine decoding. If
* not supported, num_maps (number of MAP engines) argument is unusable.
*/
RTE_BBDEV_TURBO_MAP_DEC = (1ULL << 14),
- /**< Set if a device supports scatter-gather functionality */
+ /** Set if a device supports scatter-gather functionality */
RTE_BBDEV_TURBO_DEC_SCATTER_GATHER = (1ULL << 15),
- /**< Set to keep CRC24B bits appended while decoding. Only usable when
+ /** Set to keep CRC24B bits appended while decoding. Only usable when
* decoding Transport Blocks (code_block_mode = 0).
*/
RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP = (1ULL << 16)
};
+
/** Flags for turbo encoder operation and capability structure */
enum rte_bbdev_op_te_flag_bitmasks {
- /**< Ignore rv_index and set K0 = 0 */
+ /** Ignore rv_index and set K0 = 0 */
RTE_BBDEV_TURBO_RV_INDEX_BYPASS = (1ULL << 0),
- /**< If rate matching is to be performed */
+ /** If rate matching is to be performed */
RTE_BBDEV_TURBO_RATE_MATCH = (1ULL << 1),
- /**< This bit must be set to enable CRC-24B generation */
+ /** This bit must be set to enable CRC-24B generation */
RTE_BBDEV_TURBO_CRC_24B_ATTACH = (1ULL << 2),
- /**< This bit must be set to enable CRC-24A generation */
+ /** This bit must be set to enable CRC-24A generation */
RTE_BBDEV_TURBO_CRC_24A_ATTACH = (1ULL << 3),
- /**< Set if a device supports encoder dequeue interrupts */
+ /** Set if a device supports encoder dequeue interrupts */
RTE_BBDEV_TURBO_ENC_INTERRUPTS = (1ULL << 4),
- /**< Set if a device supports scatter-gather functionality */
+ /** Set if a device supports scatter-gather functionality */
RTE_BBDEV_TURBO_ENC_SCATTER_GATHER = (1ULL << 5)
};
-/**< Data input and output buffer for BBDEV operations */
+/** Flags for LDPC decoder operation and capability structure */
+enum rte_bbdev_op_ldpcdec_flag_bitmasks {
+ /** Set for transport block CRC-24A checking */
+ RTE_BBDEV_LDPC_CRC_TYPE_24A_CHECK = (1ULL << 0),
+ /** Set for code block CRC-24B checking */
+ RTE_BBDEV_LDPC_CRC_TYPE_24B_CHECK = (1ULL << 1),
+ /** Set to drop the last CRC bits decoding output */
+ RTE_BBDEV_LDPC_CRC_TYPE_24B_DROP = (1ULL << 2),
+ /** Set for bit-level de-interleaver bypass on Rx stream. */
+ RTE_BBDEV_LDPC_DEINTERLEAVER_BYPASS = (1ULL << 3),
+ /** Set for HARQ combined input stream enable. */
+ RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE = (1ULL << 4),
+ /** Set for HARQ combined output stream enable. */
+ RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE = (1ULL << 5),
+ /** Set for LDPC decoder bypass.
+ * RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE must be set.
+ */
+ RTE_BBDEV_LDPC_DECODE_BYPASS = (1ULL << 6),
+ /** Set for soft-output stream enable */
+ RTE_BBDEV_LDPC_SOFT_OUT_ENABLE = (1ULL << 7),
+ /** Set for Rate-Matching bypass on soft-out stream. */
+ RTE_BBDEV_LDPC_SOFT_OUT_RM_BYPASS = (1ULL << 8),
+ /** Set for bit-level de-interleaver bypass on soft-output stream. */
+ RTE_BBDEV_LDPC_SOFT_OUT_DEINTERLEAVER_BYPASS = (1ULL << 9),
+ /** Set for iteration stopping on successful decode condition
+ * i.e. a successful syndrome check.
+ */
+ RTE_BBDEV_LDPC_ITERATION_STOP_ENABLE = (1ULL << 10),
+ /** Set if a device supports decoder dequeue interrupts. */
+ RTE_BBDEV_LDPC_DEC_INTERRUPTS = (1ULL << 11),
+ /** Set if a device supports scatter-gather functionality. */
+ RTE_BBDEV_LDPC_DEC_SCATTER_GATHER = (1ULL << 12),
+ /** Set if a device supports input/output HARQ compression. */
+ RTE_BBDEV_LDPC_HARQ_6BIT_COMPRESSION = (1ULL << 13),
+ /** Set if a device supports input LLR compression. */
+ RTE_BBDEV_LDPC_LLR_COMPRESSION = (1ULL << 14),
+ /** Set if a device supports HARQ input from
+ * device's internal memory.
+ */
+ RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_IN_ENABLE = (1ULL << 15),
+ /** Set if a device supports HARQ output to
+ * device's internal memory.
+ */
+ RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_OUT_ENABLE = (1ULL << 16),
+ /** Set if a device supports loop-back access to
+ * HARQ internal memory. Intended for troubleshooting.
+ */
+ RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_LOOPBACK = (1ULL << 17)
+};
+
+/** Flags for LDPC encoder operation and capability structure */
+enum rte_bbdev_op_ldpcenc_flag_bitmasks {
+ /** Set for bit-level interleaver bypass on output stream. */
+ RTE_BBDEV_LDPC_INTERLEAVER_BYPASS = (1ULL << 0),
+ /** If rate matching is to be performed */
+ RTE_BBDEV_LDPC_RATE_MATCH = (1ULL << 1),
+ /** Set for transport block CRC-24A attach */
+ RTE_BBDEV_LDPC_CRC_24A_ATTACH = (1ULL << 2),
+ /** Set for code block CRC-24B attach */
+ RTE_BBDEV_LDPC_CRC_24B_ATTACH = (1ULL << 3),
+ /** Set for code block CRC-16 attach */
+ RTE_BBDEV_LDPC_CRC_16_ATTACH = (1ULL << 4),
+ /** Set if a device supports encoder dequeue interrupts. */
+ RTE_BBDEV_LDPC_ENC_INTERRUPTS = (1ULL << 5),
+ /** Set if a device supports scatter-gather functionality. */
+ RTE_BBDEV_LDPC_ENC_SCATTER_GATHER = (1ULL << 6),
+ /** Set if a device supports concatenation of non byte aligned output */
+ RTE_BBDEV_LDPC_ENC_CONCATENATION = (1ULL << 7)
+};
+
+/** Data input and output buffer for BBDEV operations */
struct rte_bbdev_op_data {
- /**< The mbuf data structure representing the data for BBDEV operation.
+ /** The mbuf data structure representing the data for BBDEV operation.
*
* This mbuf pointer can point to one Code Block (CB) data buffer or
* multiple CBs contiguously located next to each other.
* A Transport Block (TB) represents a whole piece of data that is
* divided into one or more CBs. Maximum number of CBs can be contained
- * in one TB is defined by RTE_BBDEV_TURBO_MAX_CODE_BLOCKS.
+ * in one TB is defined by RTE_BBDEV_(TURBO/LDPC)_MAX_CODE_BLOCKS.
*
* An mbuf data structure cannot represent more than one TB. The
* smallest piece of data that can be contained in one mbuf is one CB.
@@ -145,8 +220,8 @@ struct rte_bbdev_op_data {
* then it is capable of collecting (gathering) non-contiguous
* (scattered) data from multiple locations in the memory.
* This capability is reported by the capability flags:
- * - RTE_BBDEV_TURBO_ENC_SCATTER_GATHER and
- * - RTE_BBDEV_TURBO_DEC_SCATTER_GATHER.
+ * - RTE_BBDEV_(TURBO/LDPC)_ENC_SCATTER_GATHER and
+ * - RTE_BBDEV_(TURBO/LDPC)_DEC_SCATTER_GATHER.
* Only if a BBDEV PMD supports this feature, chained mbuf data
* structures are accepted. A chained mbuf can represent one
* non-contiguous CB or multiple non-contiguous CBs.
@@ -157,7 +232,7 @@ struct rte_bbdev_op_data {
* was a chained mbuf.
*/
struct rte_mbuf *data;
- /**< The starting point of the BBDEV (encode/decode) operation,
+ /** The starting point of the BBDEV (encode/decode) operation,
* in bytes.
*
* BBDEV starts to read data past this offset.
@@ -165,13 +240,13 @@ struct rte_bbdev_op_data {
* segment.
*/
uint32_t offset;
- /**< The total data length to be processed in one operation, in bytes.
+ /** The total data length to be processed in one operation, in bytes.
*
* In case the mbuf data is representing one CB, this is the length of
* the CB undergoing the operation.
* If it's for multiple CBs, this is the total length of those CBs
* undergoing the operation.
- * If it's for one TB, this is the total length of the TB under
+ * If it is for one TB, this is the total length of the TB under
* operation.
*
* In case of chained mbuf, this data length includes the lengths of the
@@ -180,51 +255,83 @@ struct rte_bbdev_op_data {
uint32_t length;
};
-struct rte_bbdev_op_dec_cb_params {
- /**< The K size of the input CB, in bits [40:6144], as specified in
+/** Turbo decode code block parameters */
+struct rte_bbdev_op_dec_turbo_cb_params {
+ /** The K size of the input CB, in bits [40:6144], as specified in
* 3GPP TS 36.212.
* This size is inclusive of CRC bits, regardless whether it was
* pre-calculated by the application or not.
*/
uint16_t k;
- /**< The E length of the CB rate matched LLR output, in bytes, as in
+ /** The E length of the CB rate matched LLR output, in bytes, as in
* 3GPP TS 36.212.
*/
uint32_t e;
};
-struct rte_bbdev_op_dec_tb_params {
- /**< The K- size of the input CB, in bits [40:6144], that is in the
+/** LDPC decode code block parameters */
+struct rte_bbdev_op_dec_ldpc_cb_params {
+ /** Rate matching output sequence length in bits or LLRs.
+ * [3GPP TS38.212, section 5.4.2.1]
+ */
+ uint32_t e;
+};
+
+/** Turbo decode transport block parameters */
+struct rte_bbdev_op_dec_turbo_tb_params {
+ /** The K- size of the input CB, in bits [40:6144], that is in the
* Turbo operation when r < C-, as in 3GPP TS 36.212.
*/
uint16_t k_neg;
- /**< The K+ size of the input CB, in bits [40:6144], that is in the
+ /** The K+ size of the input CB, in bits [40:6144], that is in the
* Turbo operation when r >= C-, as in 3GPP TS 36.212.
*/
uint16_t k_pos;
- /**< The number of CBs that have K- size, [0:63] */
+ /** The number of CBs that have K- size, [0:63] */
uint8_t c_neg;
- /**< The total number of CBs in the TB, [1:RTE_BBDEV_TURBO_MAX_CODE_BLOCKS] */
+ /** The total number of CBs in the TB,
+ * [1:RTE_BBDEV_TURBO_MAX_CODE_BLOCKS]
+ */
uint8_t c;
- /**< The number of CBs that uses Ea before switching to Eb, [0:63] */
+ /** The number of CBs that uses Ea before switching to Eb, [0:63] */
uint8_t cab;
- /**< The E size of the CB rate matched output to use in the Turbo
+ /** The E size of the CB rate matched output to use in the Turbo
* operation when r < cab
*/
uint32_t ea;
- /**< The E size of the CB rate matched output to use in the Turbo
+ /** The E size of the CB rate matched output to use in the Turbo
* operation when r >= cab
*/
uint32_t eb;
- /**< The index of the first CB in the inbound mbuf data, default is 0 */
+ /** The index of the first CB in the inbound mbuf data, default is 0 */
uint8_t r;
};
-/**< Operation structure for Turbo decode.
- * An operation can perform on one CB at a time "CB-mode".
- * An operation can perform on one or multiple CBs that are logically belonging
- * to one TB "TB-mode".
- * The provided K size parameter of the CB is its size out coming from the
+/** LDPC decode transport block parameters */
+struct rte_bbdev_op_dec_ldpc_tb_params {
+ /** Ea, length after rate matching in bits, r < cab.
+ * [3GPP TS38.212, section 5.4.2.1]
+ */
+ uint32_t ea;
+ /** Eb, length after rate matching in bits, r >= cab.
+ * [3GPP TS38.212, section 5.4.2.1]
+ */
+ uint32_t eb;
+ /** The total number of CBs in the TB or partial TB
+ * [1:RTE_BBDEV_LDPC_MAX_CODE_BLOCKS]
+ */
+ uint8_t c;
+ /** The index of the first CB in the inbound mbuf data, default is 0 */
+ uint8_t r;
+ /** The number of CBs that use Ea before switching to Eb, [0:63] */
+ uint8_t cab;
+};
+
+/** Operation structure for Turbo decode.
+ * An operation can be performed on one CB at a time "CB-mode".
+ * An operation can be performed on one or multiple CBs that logically
+ * belong to one TB "TB-mode".
+ * The provided K size parameter of the CB is its size coming from the
* decode operation.
* CRC24A/B check is requested by the application by setting the flag
* RTE_BBDEV_TURBO_CRC_TYPE_24B for CRC24B check or CRC24A otherwise.
@@ -249,94 +356,192 @@ struct rte_bbdev_op_dec_tb_params {
* application with enough room for the output data.
*/
struct rte_bbdev_op_turbo_dec {
- /**< The Virtual Circular Buffer, wk, size 3*Kpi for each CB */
+ /** The Virtual Circular Buffer, wk, size 3*Kpi for each CB */
struct rte_bbdev_op_data input;
- /**< The hard decisions buffer for the decoded output,
+ /** The hard decisions buffer for the decoded output,
* size K for each CB
*/
struct rte_bbdev_op_data hard_output;
- /**< The soft LLR output buffer - optional */
+ /** The soft LLR output buffer - optional */
struct rte_bbdev_op_data soft_output;
- uint32_t op_flags; /**< Flags from rte_bbdev_op_td_flag_bitmasks */
- uint8_t rv_index; /**< Rv index for rate matching [0:3] */
- /**< The minimum number of iterations to perform in decoding all CBs in
+ /** Flags from rte_bbdev_op_td_flag_bitmasks */
+ uint32_t op_flags;
+
+ /** Rv index for rate matching [0:3] */
+ uint8_t rv_index;
+ /** The minimum number of iterations to perform in decoding all CBs in
* this operation - input
*/
uint8_t iter_min:4;
- /**< The maximum number of iterations to perform in decoding all CBs in
+ /** The maximum number of iterations to perform in decoding all CBs in
* this operation - input
*/
uint8_t iter_max:4;
- /**< The maximum number of iterations that were perform in decoding all
- * CBs in this decode operation - output
+ /** The maximum number of iterations that were performed in decoding
+ * all CBs in this decode operation - output
*/
uint8_t iter_count;
- /**< 5 bit extrinsic scale (scale factor on extrinsic info) */
+ /** 5 bit extrinsic scale (scale factor on extrinsic info) */
uint8_t ext_scale;
- /**< Number of MAP engines to use in decode,
- * must be power of 2 (or 0 to auto-select)
+ /** Number of MAP engines to use in decode,
+ * must be power of 2 (or 0 to auto-select)
*/
uint8_t num_maps;
- uint8_t code_block_mode; /**< [0 - TB : 1 - CB] */
+ /**< [0 - TB : 1 - CB] */
+ uint8_t code_block_mode;
union {
/**< Struct which stores Code Block specific parameters */
- struct rte_bbdev_op_dec_cb_params cb_params;
+ struct rte_bbdev_op_dec_turbo_cb_params cb_params;
/**< Struct which stores Transport Block specific parameters */
- struct rte_bbdev_op_dec_tb_params tb_params;
+ struct rte_bbdev_op_dec_turbo_tb_params tb_params;
};
};
+/** Operation structure for LDPC decode.
+ *
+ * An operation can be performed on one CB at a time "CB-mode".
+ * An operation can also be performed on one or multiple CBs that logically
+ * belong to a TB "TB-mode" (Currently not supported).
+ *
+ * The input encoded CB data is the Virtual Circular Buffer data stream.
+ *
+ * Each byte in the input circular buffer is the LLR value of each bit of the
+ * original CB.
+ *
+ * Hard output is a mandatory capability that all BBDEV PMDs support. This is
+ * the decoded CBs (CRC24A/B is the last 24-bit in each decoded CB).
+ *
+ * Soft output is an optional capability for BBDEV PMDs. If supported, an LLR
+ * rate matched output is computed in the soft_output buffer structure.
+ * These are A Posteriori Probabilities (APP) LLR samples for coded bits.
+ *
+ * HARQ combined output is an optional capability for BBDEV PMDs.
+ * If supported, a LLR output is streamed to the harq_combined_output
+ * buffer.
+ *
+ * HARQ combined input is an optional capability for BBDEV PMDs.
+ * If supported, a LLR input is streamed from the harq_combined_input
+ * buffer.
+ *
+ * The output mbuf data structure is expected to be allocated by the
+ * application with enough room for the output data.
+ */
+struct rte_bbdev_op_ldpc_dec {
+ /** The Virtual Circular Buffer for this code block, one LLR
+ * per bit of the original CB.
+ */
+ struct rte_bbdev_op_data input;
+ /** The hard decisions buffer for the decoded output,
+ * size K for each CB
+ */
+ struct rte_bbdev_op_data hard_output;
+ /** The soft LLR output LLR stream buffer - optional */
+ struct rte_bbdev_op_data soft_output;
+ /** The HARQ combined LLR stream input buffer - optional */
+ struct rte_bbdev_op_data harq_combined_input;
+ /** The HARQ combined LLR stream output buffer - optional */
+ struct rte_bbdev_op_data harq_combined_output;
+
+ /** Flags from rte_bbdev_op_ldpcdec_flag_bitmasks */
+ uint32_t op_flags;
+
+ /** Rate matching redundancy version
+ * [3GPP TS38.212, section 5.4.2.1]
+ */
+ uint8_t rv_index;
+ /** The maximum number of iterations to perform in decoding CB in
+ * this operation - input
+ */
+ uint8_t iter_max;
+ /** The number of iterations that were performed in decoding
+ * CB in this decode operation - output
+ */
+ uint8_t iter_count;
+ /** 1: LDPC Base graph 1, 2: LDPC Base graph 2.
+ * [3GPP TS38.212, section 5.2.2]
+ */
+ uint8_t basegraph;
+ /** Zc, LDPC lifting size.
+ * [3GPP TS38.212, section 5.2.2]
+ */
+ uint16_t z_c;
+ /** Ncb, length of the circular buffer in bits.
+ * [3GPP TS38.212, section 5.4.2.1]
+ */
+ uint16_t n_cb;
+ /** Qm, modulation order {1,2,4,6,8}.
+ * [3GPP TS38.212, section 5.4.2.2]
+ */
+ uint8_t q_m;
+ /** Number of Filler bits, n_filler = K – K’
+ * [3GPP TS38.212 section 5.2.2]
+ */
+ uint16_t n_filler;
+ /** [0 - TB : 1 - CB] */
+ uint8_t code_block_mode;
+ union {
+ /** Struct which stores Code Block specific parameters */
+ struct rte_bbdev_op_dec_ldpc_cb_params cb_params;
+ /** Struct which stores Transport Block specific parameters */
+ struct rte_bbdev_op_dec_ldpc_tb_params tb_params;
+ };
+};
+
+/** Turbo encode code block parameters */
struct rte_bbdev_op_enc_turbo_cb_params {
- /**< The K size of the input CB, in bits [40:6144], as specified in
+ /** The K size of the input CB, in bits [40:6144], as specified in
* 3GPP TS 36.212.
* This size is inclusive of CRC24A, regardless whether it was
* pre-calculated by the application or not.
*/
uint16_t k;
- /**< The E length of the CB rate matched output, in bits, as in
+ /** The E length of the CB rate matched output, in bits, as in
* 3GPP TS 36.212.
*/
uint32_t e;
- /**< The Ncb soft buffer size of the CB rate matched output [K:3*Kpi],
+ /** The Ncb soft buffer size of the CB rate matched output [K:3*Kpi],
* in bits, as specified in 3GPP TS 36.212.
*/
uint16_t ncb;
};
+/** Turbo encode transport block parameters */
struct rte_bbdev_op_enc_turbo_tb_params {
- /**< The K- size of the input CB, in bits [40:6144], that is in the
+ /** The K- size of the input CB, in bits [40:6144], that is in the
* Turbo operation when r < C-, as in 3GPP TS 36.212.
* This size is inclusive of CRC24B, regardless whether it was
* pre-calculated and appended by the application or not.
*/
uint16_t k_neg;
- /**< The K+ size of the input CB, in bits [40:6144], that is in the
+ /** The K+ size of the input CB, in bits [40:6144], that is in the
* Turbo operation when r >= C-, as in 3GPP TS 36.212.
* This size is inclusive of CRC24B, regardless whether it was
* pre-calculated and appended by the application or not.
*/
uint16_t k_pos;
- /**< The number of CBs that have K- size, [0:63] */
+ /** The number of CBs that have K- size, [0:63] */
uint8_t c_neg;
- /**< The total number of CBs in the TB, [1:RTE_BBDEV_TURBO_MAX_CODE_BLOCKS] */
+ /** The total number of CBs in the TB,
+ * [1:RTE_BBDEV_TURBO_MAX_CODE_BLOCKS]
+ */
uint8_t c;
- /**< The number of CBs that uses Ea before switching to Eb, [0:63] */
+ /** The number of CBs that uses Ea before switching to Eb, [0:63] */
uint8_t cab;
- /**< The E size of the CB rate matched output to use in the Turbo
+ /** The E size of the CB rate matched output to use in the Turbo
* operation when r < cab
*/
uint32_t ea;
- /**< The E size of the CB rate matched output to use in the Turbo
+ /** The E size of the CB rate matched output to use in the Turbo
* operation when r >= cab
*/
uint32_t eb;
- /**< The Ncb soft buffer size for the rate matched CB that is used in
+ /** The Ncb soft buffer size for the rate matched CB that is used in
* the Turbo operation when r < C-, [K:3*Kpi]
*/
uint16_t ncb_neg;
- /**< The Ncb soft buffer size for the rate matched CB that is used in
+ /** The Ncb soft buffer size for the rate matched CB that is used in
* the Turbo operation when r >= C-, [K:3*Kpi]
*/
uint16_t ncb_pos;
@@ -344,10 +549,38 @@ struct rte_bbdev_op_enc_turbo_tb_params {
uint8_t r;
};
-/**< Operation structure for Turbo encode.
- * An operation can perform on one CB at a time "CB-mode".
- * An operation can perform on one or multiple CBs that are logically
- * belonging to one TB "TB-mode".
+/** LDPC encode code block parameters */
+struct rte_bbdev_op_enc_ldpc_cb_params {
+ /** E, length after rate matching in bits.
+ * [3GPP TS38.212, section 5.4.2.1]
+ */
+ uint32_t e;
+};
+
+/** LDPC encode transport block parameters */
+struct rte_bbdev_op_enc_ldpc_tb_params {
+ /** Ea, length after rate matching in bits, r < cab.
+ * [3GPP TS38.212, section 5.4.2.1]
+ */
+ uint32_t ea;
+ /** Eb, length after rate matching in bits, r >= cab.
+ * [3GPP TS38.212, section 5.4.2.1]
+ */
+ uint32_t eb;
+ /** The total number of CBs in the TB or partial TB
+ * [1:RTE_BBDEV_LDPC_MAX_CODE_BLOCKS]
+ */
+ uint8_t c;
+ /** The index of the first CB in the inbound mbuf data, default is 0 */
+ uint8_t r;
+ /** The number of CBs that use Ea before switching to Eb, [0:63] */
+ uint8_t cab;
+};
+
+/** Operation structure for Turbo encode.
+ * An operation can be performed on one CB at a time "CB-mode".
+ * An operation can pbe erformd on one or multiple CBs that logically
+ * belong to one TB "TB-mode".
*
* In CB-mode, CRC24A/B is an optional operation. K size parameter is not
* affected by CRC24A/B inclusion, this only affects the inbound mbuf data
@@ -364,44 +597,131 @@ struct rte_bbdev_op_enc_turbo_tb_params {
* application with enough room for the output data.
*/
struct rte_bbdev_op_turbo_enc {
- /**< The input CB or TB data */
+ /** The input CB or TB data */
struct rte_bbdev_op_data input;
- /**< The rate matched CB or TB output buffer */
+ /** The rate matched CB or TB output buffer */
struct rte_bbdev_op_data output;
+ /** Flags from rte_bbdev_op_te_flag_bitmasks */
+ uint32_t op_flags;
- uint32_t op_flags; /**< Flags from rte_bbdev_op_te_flag_bitmasks */
- uint8_t rv_index; /**< Rv index for rate matching [0:3] */
-
- uint8_t code_block_mode; /**< [0 - TB : 1 - CB] */
+ /** Rv index for rate matching [0:3] */
+ uint8_t rv_index;
+ /** [0 - TB : 1 - CB] */
+ uint8_t code_block_mode;
union {
- /**< Struct which stores Code Block specific parameters */
+ /** Struct which stores Code Block specific parameters */
struct rte_bbdev_op_enc_turbo_cb_params cb_params;
- /**< Struct which stores Transport Block specific parameters */
+ /** Struct which stores Transport Block specific parameters */
struct rte_bbdev_op_enc_turbo_tb_params tb_params;
};
};
-/**< List of the capabilities for the Turbo Decoder */
+/** Operation structure for LDPC encode.
+ * An operation can be performed on one CB at a time "CB-mode".
+ * An operation can be performed on one or multiple CBs that logically
+ * belong to a TB "TB-mode".
+ *
+ * The input data is the CB or TB input to the decoder.
+ *
+ * The output data is the ratematched CB or TB data, or the output after
+ * bit-selection if RTE_BBDEV_LDPC_INTERLEAVER_BYPASS is set.
+ *
+ * The output mbuf data structure is expected to be allocated by the
+ * application with enough room for the output data.
+ */
+struct rte_bbdev_op_ldpc_enc {
+ /** The input TB or CB data */
+ struct rte_bbdev_op_data input;
+ /** The rate matched TB or CB output buffer */
+ struct rte_bbdev_op_data output;
+
+ /** Flags from rte_bbdev_op_ldpcenc_flag_bitmasks */
+ uint32_t op_flags;
+
+ /** Rate matching redundancy version */
+ uint8_t rv_index;
+ /** 1: LDPC Base graph 1, 2: LDPC Base graph 2.
+ * [3GPP TS38.212, section 5.2.2]
+ */
+ uint8_t basegraph;
+ /** Zc, LDPC lifting size.
+ * [3GPP TS38.212, section 5.2.2]
+ */
+ uint16_t z_c;
+ /** Ncb, length of the circular buffer in bits.
+ * [3GPP TS38.212, section 5.4.2.1]
+ */
+ uint16_t n_cb;
+ /** Qm, modulation order {2,4,6,8,10}.
+ * [3GPP TS38.212, section 5.4.2.2]
+ */
+ uint8_t q_m;
+ /** Number of Filler bits, n_filler = K – K’
+ * [3GPP TS38.212 section 5.2.2]
+ */
+ uint16_t n_filler;
+ /** [0 - TB : 1 - CB] */
+ uint8_t code_block_mode;
+ union {
+ /** Struct which stores Code Block specific parameters */
+ struct rte_bbdev_op_enc_ldpc_cb_params cb_params;
+ /** Struct which stores Transport Block specific parameters */
+ struct rte_bbdev_op_enc_ldpc_tb_params tb_params;
+ };
+};
+
+/** List of the capabilities for the Turbo Decoder */
struct rte_bbdev_op_cap_turbo_dec {
- /**< Flags from rte_bbdev_op_td_flag_bitmasks */
+ /** Flags from rte_bbdev_op_td_flag_bitmasks */
uint32_t capability_flags;
/** Maximal LLR absolute value. Acceptable LLR values lie in range
* [-max_llr_modulus, max_llr_modulus].
*/
int8_t max_llr_modulus;
+ /** Num input code block buffers */
uint8_t num_buffers_src; /**< Num input code block buffers */
- /**< Num hard output code block buffers */
+ /** Num hard output code block buffers */
uint8_t num_buffers_hard_out;
- /**< Num soft output code block buffers if supported by the driver */
+ /** Num soft output code block buffers if supported by the driver */
uint8_t num_buffers_soft_out;
};
-/**< List of the capabilities for the Turbo Encoder */
+/** List of the capabilities for the Turbo Encoder */
struct rte_bbdev_op_cap_turbo_enc {
- /**< Flags from rte_bbdev_op_te_flag_bitmasks */
+ /** Flags from rte_bbdev_op_te_flag_bitmasks */
uint32_t capability_flags;
- uint8_t num_buffers_src; /**< Num input code block buffers */
- uint8_t num_buffers_dst; /**< Num output code block buffers */
+ /** Num input code block buffers */
+ uint8_t num_buffers_src;
+ /** Num output code block buffers */
+ uint8_t num_buffers_dst;
+};
+
+/** List of the capabilities for the LDPC Decoder */
+struct rte_bbdev_op_cap_ldpc_dec {
+ /** Flags from rte_bbdev_op_ldpcdec_flag_bitmasks */
+ uint32_t capability_flags;
+ /** LLR size in bits. LLR is a two’s complement number. */
+ int8_t llr_size;
+ /** LLR numbers of decimals bit for arithmetic representation */
+ int8_t llr_decimals;
+ /** Amount of memory for HARQ in external DDR in MB */
+ uint16_t harq_memory_size;
+ /** Num input code block buffers */
+ uint16_t num_buffers_src;
+ /** Num hard output code block buffers */
+ uint16_t num_buffers_hard_out;
+ /** Num soft output code block buffers if supported by the driver */
+ uint16_t num_buffers_soft_out;
+};
+
+/** List of the capabilities for the LDPC Encoder */
+struct rte_bbdev_op_cap_ldpc_enc {
+ /** Flags from rte_bbdev_op_ldpcenc_flag_bitmasks */
+ uint32_t capability_flags;
+ /** Num input code block buffers */
+ uint16_t num_buffers_src;
+ /** Num output code block buffers */
+ uint16_t num_buffers_dst;
};
/** Different operation types supported by the device */
@@ -409,40 +729,59 @@ enum rte_bbdev_op_type {
RTE_BBDEV_OP_NONE, /**< Dummy operation that does nothing */
RTE_BBDEV_OP_TURBO_DEC, /**< Turbo decode */
RTE_BBDEV_OP_TURBO_ENC, /**< Turbo encode */
+ RTE_BBDEV_OP_LDPC_DEC, /**< LDPC decode */
+ RTE_BBDEV_OP_LDPC_ENC, /**< LDPC encode */
RTE_BBDEV_OP_TYPE_COUNT, /**< Count of different op types */
};
-/**< Bit indexes of possible errors reported through status field */
+/** Bit indexes of possible errors reported through status field */
enum {
RTE_BBDEV_DRV_ERROR,
RTE_BBDEV_DATA_ERROR,
RTE_BBDEV_CRC_ERROR,
+ RTE_BBDEV_SYNDROME_ERROR
};
-/**< Structure specifying a single encode operation */
+/** Structure specifying a single encode operation */
struct rte_bbdev_enc_op {
- int status; /**< Status of operation that was performed */
- struct rte_mempool *mempool; /**< Mempool which op instance is in */
- void *opaque_data; /**< Opaque pointer for user data */
- /**< Contains encoder specific parameters */
- struct rte_bbdev_op_turbo_enc turbo_enc;
+ /**< Status of operation that was performed */
+ int status;
+ /**< Mempool which op instance is in */
+ struct rte_mempool *mempool;
+ /**< Opaque pointer for user data */
+ void *opaque_data;
+ union {
+ /** Contains turbo decoder specific parameters */
+ struct rte_bbdev_op_turbo_enc turbo_enc;
+ /** Contains LDPC decoder specific parameters */
+ struct rte_bbdev_op_ldpc_enc ldpc_enc;
+ };
};
-/**< Structure specifying a single decode operation */
+/** Structure specifying a single decode operation */
struct rte_bbdev_dec_op {
- int status; /**< Status of operation that was performed */
- struct rte_mempool *mempool; /**< Mempool which op instance is in */
- void *opaque_data; /**< Opaque pointer for user data */
- /**< Contains decoder specific parameters */
- struct rte_bbdev_op_turbo_dec turbo_dec;
+ /** Status of operation that was performed */
+ int status;
+ /** Mempool which op instance is in */
+ struct rte_mempool *mempool;
+ /** Opaque pointer for user data */
+ void *opaque_data;
+ union {
+ /** Contains turbo decoder specific parameters */
+ struct rte_bbdev_op_turbo_dec turbo_dec;
+ /** Contains LDPC decoder specific parameters */
+ struct rte_bbdev_op_ldpc_dec ldpc_dec;
+ };
};
-/**< Operation capabilities supported by a device */
+/** Operation capabilities supported by a device */
struct rte_bbdev_op_cap {
enum rte_bbdev_op_type type; /**< Type of operation */
union {
struct rte_bbdev_op_cap_turbo_dec turbo_dec;
struct rte_bbdev_op_cap_turbo_enc turbo_enc;
+ struct rte_bbdev_op_cap_ldpc_dec ldpc_dec;
+ struct rte_bbdev_op_cap_ldpc_enc ldpc_enc;
} cap; /**< Operation-type specific capabilities */
};
@@ -516,7 +855,8 @@ struct rte_mempool *
/* Check type */
priv = (struct rte_bbdev_op_pool_private *)
rte_mempool_get_priv(mempool);
- if (unlikely(priv->type != RTE_BBDEV_OP_TURBO_ENC))
+ if (unlikely((priv->type != RTE_BBDEV_OP_TURBO_ENC) &&
+ (priv->type != RTE_BBDEV_OP_LDPC_ENC)))
return -EINVAL;
/* Get elements */
@@ -552,7 +892,8 @@ struct rte_mempool *
/* Check type */
priv = (struct rte_bbdev_op_pool_private *)
rte_mempool_get_priv(mempool);
- if (unlikely(priv->type != RTE_BBDEV_OP_TURBO_DEC))
+ if (unlikely((priv->type != RTE_BBDEV_OP_TURBO_DEC) &&
+ (priv->type != RTE_BBDEV_OP_LDPC_DEC)))
return -EINVAL;
/* Get elements */
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v6 4/7] baseband/turbo_sw: extension of turbosw PMD for 5G
2019-07-03 15:24 3% ` [dpdk-dev] [PATCH v6 2/7] bbdev: extension of BBDEV API for 5G FEC Nicolas Chautru
@ 2019-07-03 15:24 2% ` Nicolas Chautru
1 sibling, 0 replies; 200+ results
From: Nicolas Chautru @ 2019-07-03 15:24 UTC (permalink / raw)
To: akhil.goyal, dev
Cc: ferruh.yigit, thomas, amr.mokhtar, kamilx.chalupnik, Nicolas Chautru
Implementation still based on Intel SDK libraries
optimized for AVX512 instructions set and 5GNR.
This can be also build for AVX2 for 4G capability or
without SDK dependency for maintenance.
Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
Acked-by: Amr Mokhtar <amr.mokhtar@intel.com>
---
config/common_base | 1 +
doc/guides/rel_notes/release_19_08.rst | 15 +-
drivers/baseband/turbo_sw/Makefile | 15 +-
drivers/baseband/turbo_sw/bbdev_turbo_software.c | 677 ++++++++++++++++++++++-
drivers/baseband/turbo_sw/meson.build | 10 +
mk/rte.app.mk | 8 +-
6 files changed, 715 insertions(+), 11 deletions(-)
diff --git a/config/common_base b/config/common_base
index e5a4ebf..c2551b1 100644
--- a/config/common_base
+++ b/config/common_base
@@ -536,6 +536,7 @@ CONFIG_RTE_LIBRTE_BBDEV_DEBUG=n
CONFIG_RTE_BBDEV_MAX_DEVS=128
CONFIG_RTE_BBDEV_OFFLOAD_COST=y
CONFIG_RTE_BBDEV_SDK_AVX2=n
+CONFIG_RTE_BBDEV_SDK_AVX512=n
#
# Compile PMD for NULL bbdev device
diff --git a/doc/guides/rel_notes/release_19_08.rst b/doc/guides/rel_notes/release_19_08.rst
index 55ae8ee..7c508fc 100644
--- a/doc/guides/rel_notes/release_19_08.rst
+++ b/doc/guides/rel_notes/release_19_08.rst
@@ -126,6 +126,20 @@ New Features
Added telemetry mode to l3fwd-power application to report
application level busyness, empty and full polls of rte_eth_rx_burst().
+* **Added a FPGA_LTE_FEC bbdev PMD.**
+
+ Added the new ``fpga_lte_fec`` bbdev driver for the Intel® FPGA PAC
+ (Programmable Acceleration Card) N3000. See the
+ :doc:`../bbdevs/fpga_lte_fec` BBDEV guide for more details on this new driver.
+
+* **Updated TURBO_SW bbdev PMD.**
+
+ Updated the ``turbo_sw`` bbdev driver with changes including:
+
+ * Added option to build the driver with or without dependency of external
+ SDK libraries.
+ * Added support for 5GNR encode/decode operations.
+
Removed Items
-------------
@@ -165,7 +179,6 @@ API Changes
structure (``rte_crypto_cipher_xform``, ``rte_crypto_auth_xform``, and
``rte_crypto_aead_xform``) have been changed to ``const uint8_t *data``.
-
ABI Changes
-----------
diff --git a/drivers/baseband/turbo_sw/Makefile b/drivers/baseband/turbo_sw/Makefile
index 414d0d9..4aa05d2 100644
--- a/drivers/baseband/turbo_sw/Makefile
+++ b/drivers/baseband/turbo_sw/Makefile
@@ -3,7 +3,6 @@
include $(RTE_SDK)/mk/rte.vars.mk
-
# library name
LIB = librte_pmd_bbdev_turbo_sw.a
@@ -34,6 +33,20 @@ LDLIBS += -L$(FLEXRAN_SDK)/lib_common -lcommon
LDLIBS += -lstdc++ -lirc -limf -lipps -lsvml
endif
+ifeq ($(CONFIG_RTE_BBDEV_SDK_AVX512),y)
+ifeq ($(CONFIG_RTE_BBDEV_SDK_AVX2),n)
+$(error "CONFIG_RTE_BBDEV_SDK_AVX512 requires CONFIG_RTE_BBDEV_SDK_AVX2 set")
+endif
+CFLAGS += -I$(FLEXRAN_SDK)/lib_ldpc_encoder_5gnr
+CFLAGS += -I$(FLEXRAN_SDK)/lib_ldpc_decoder_5gnr
+CFLAGS += -I$(FLEXRAN_SDK)/lib_LDPC_ratematch_5gnr
+CFLAGS += -I$(FLEXRAN_SDK)/lib_rate_dematching_5gnr
+LDLIBS += -L$(FLEXRAN_SDK)/lib_ldpc_encoder_5gnr -lldpc_encoder_5gnr
+LDLIBS += -L$(FLEXRAN_SDK)/lib_ldpc_decoder_5gnr -lldpc_decoder_5gnr
+LDLIBS += -L$(FLEXRAN_SDK)/lib_LDPC_ratematch_5gnr -lLDPC_ratematch_5gnr
+LDLIBS += -L$(FLEXRAN_SDK)/lib_rate_dematching_5gnr -lrate_dematching_5gnr
+endif
+
# library version
LIBABIVER := 1
diff --git a/drivers/baseband/turbo_sw/bbdev_turbo_software.c b/drivers/baseband/turbo_sw/bbdev_turbo_software.c
index 5551f84..2f06369 100644
--- a/drivers/baseband/turbo_sw/bbdev_turbo_software.c
+++ b/drivers/baseband/turbo_sw/bbdev_turbo_software.c
@@ -14,11 +14,24 @@
#include <rte_bbdev.h>
#include <rte_bbdev_pmd.h>
+#include <rte_common.h>
+#include <rte_hexdump.h>
+#include <rte_log.h>
+
#ifdef RTE_BBDEV_SDK_AVX2
+#include <ipp.h>
+#include <ipps.h>
#include <phy_turbo.h>
#include <phy_crc.h>
#include <phy_rate_match.h>
#endif
+#ifdef RTE_BBDEV_SDK_AVX512
+#include <bit_reverse.h>
+#include <phy_ldpc_encoder_5gnr.h>
+#include <phy_ldpc_decoder_5gnr.h>
+#include <phy_LDPC_ratematch_5gnr.h>
+#include <phy_rate_dematching_5gnr.h>
+#endif
#define DRIVER_NAME baseband_turbo_sw
@@ -84,6 +97,7 @@ struct turbo_sw_queue {
enum rte_bbdev_op_type type;
} __rte_cache_aligned;
+
#ifdef RTE_BBDEV_SDK_AVX2
static inline char *
mbuf_append(struct rte_mbuf *m_head, struct rte_mbuf *m, uint16_t len)
@@ -180,20 +194,53 @@ struct turbo_sw_queue {
}
},
#endif
+#ifdef RTE_BBDEV_SDK_AVX512
+ {
+ .type = RTE_BBDEV_OP_LDPC_ENC,
+ .cap.ldpc_enc = {
+ .capability_flags =
+ RTE_BBDEV_LDPC_RATE_MATCH |
+ RTE_BBDEV_LDPC_CRC_24A_ATTACH |
+ RTE_BBDEV_LDPC_CRC_24B_ATTACH,
+ .num_buffers_src =
+ RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
+ .num_buffers_dst =
+ RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
+ }
+ },
+ {
+ .type = RTE_BBDEV_OP_LDPC_DEC,
+ .cap.ldpc_dec = {
+ .capability_flags =
+ RTE_BBDEV_LDPC_CRC_TYPE_24B_CHECK |
+ RTE_BBDEV_LDPC_CRC_TYPE_24A_CHECK |
+ RTE_BBDEV_LDPC_CRC_TYPE_24B_DROP |
+ RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE |
+ RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE |
+ RTE_BBDEV_LDPC_ITERATION_STOP_ENABLE,
+ .llr_size = 8,
+ .llr_decimals = 2,
+ .harq_memory_size = 0,
+ .num_buffers_src =
+ RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
+ .num_buffers_hard_out =
+ RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
+ .num_buffers_soft_out = 0,
+ }
+ },
+#endif
RTE_BBDEV_END_OF_CAPABILITIES_LIST()
};
static struct rte_bbdev_queue_conf default_queue_conf = {
.queue_size = RTE_BBDEV_QUEUE_SIZE_LIMIT,
};
-
#ifdef RTE_BBDEV_SDK_AVX2
static const enum rte_cpu_flag_t cpu_flag = RTE_CPUFLAG_SSE4_2;
dev_info->cpu_flag_reqs = &cpu_flag;
#else
dev_info->cpu_flag_reqs = NULL;
#endif
-
default_queue_conf.socket = dev->data->socket_id;
dev_info->driver_name = RTE_STR(DRIVER_NAME);
@@ -280,7 +327,7 @@ struct turbo_sw_queue {
return -ENAMETOOLONG;
}
q->enc_in = rte_zmalloc_socket(name,
- (RTE_BBDEV_TURBO_MAX_CB_SIZE >> 3) * sizeof(*q->enc_in),
+ (RTE_BBDEV_LDPC_MAX_CB_SIZE >> 3) * sizeof(*q->enc_in),
RTE_CACHE_LINE_SIZE, queue_conf->socket);
if (q->enc_in == NULL) {
rte_bbdev_log(ERR,
@@ -288,7 +335,7 @@ struct turbo_sw_queue {
goto free_q;
}
- /* Allocate memory for Aplha Gamma temp buffer. */
+ /* Allocate memory for Alpha Gamma temp buffer. */
ret = snprintf(name, RTE_RING_NAMESIZE, RTE_STR(DRIVER_NAME)"_ag%u:%u",
dev->data->dev_id, q_id);
if ((ret < 0) || (ret >= (int)RTE_RING_NAMESIZE)) {
@@ -423,6 +470,7 @@ struct turbo_sw_queue {
};
#ifdef RTE_BBDEV_SDK_AVX2
+#ifdef RTE_LIBRTE_BBDEV_DEBUG
/* Checks if the encoder input buffer is correct.
* Returns 0 if it's valid, -1 otherwise.
*/
@@ -478,16 +526,21 @@ struct turbo_sw_queue {
return 0;
}
#endif
+#endif
static inline void
process_enc_cb(struct turbo_sw_queue *q, struct rte_bbdev_enc_op *op,
uint8_t r, uint8_t c, uint16_t k, uint16_t ncb,
uint32_t e, struct rte_mbuf *m_in, struct rte_mbuf *m_out_head,
- struct rte_mbuf *m_out, uint16_t in_offset, uint16_t out_offset,
+ struct rte_mbuf *m_out, uint16_t in_offset, uint16_t out_offset,
uint16_t in_length, struct rte_bbdev_stats *q_stats)
{
#ifdef RTE_BBDEV_SDK_AVX2
+#ifdef RTE_LIBRTE_BBDEV_DEBUG
int ret;
+#else
+ RTE_SET_USED(in_length);
+#endif
int16_t k_idx;
uint16_t m;
uint8_t *in, *out0, *out1, *out2, *tmp_out, *rm_out;
@@ -511,11 +564,14 @@ struct turbo_sw_queue {
/* CRC24A (for TB) */
if ((enc->op_flags & RTE_BBDEV_TURBO_CRC_24A_ATTACH) &&
(enc->code_block_mode == 1)) {
+#ifdef RTE_LIBRTE_BBDEV_DEBUG
ret = is_enc_input_valid(k - 24, k_idx, in_length);
if (ret != 0) {
op->status |= 1 << RTE_BBDEV_DATA_ERROR;
return;
}
+#endif
+
crc_req.data = in;
crc_req.len = k - 24;
/* Check if there is a room for CRC bits if not use
@@ -544,11 +600,14 @@ struct turbo_sw_queue {
#endif
} else if (enc->op_flags & RTE_BBDEV_TURBO_CRC_24B_ATTACH) {
/* CRC24B */
+#ifdef RTE_LIBRTE_BBDEV_DEBUG
ret = is_enc_input_valid(k - 24, k_idx, in_length);
if (ret != 0) {
op->status |= 1 << RTE_BBDEV_DATA_ERROR;
return;
}
+#endif
+
crc_req.data = in;
crc_req.len = k - 24;
/* Check if there is a room for CRC bits if this is the last
@@ -575,13 +634,16 @@ struct turbo_sw_queue {
#ifdef RTE_BBDEV_OFFLOAD_COST
q_stats->acc_offload_cycles += rte_rdtsc_precise() - start_time;
#endif
- } else {
+ }
+#ifdef RTE_LIBRTE_BBDEV_DEBUG
+ else {
ret = is_enc_input_valid(k, k_idx, in_length);
if (ret != 0) {
op->status |= 1 << RTE_BBDEV_DATA_ERROR;
return;
}
}
+#endif
/* Turbo encoder */
@@ -757,6 +819,143 @@ struct turbo_sw_queue {
#endif
}
+
+static inline void
+process_ldpc_enc_cb(struct turbo_sw_queue *q, struct rte_bbdev_enc_op *op,
+ uint32_t e, struct rte_mbuf *m_in, struct rte_mbuf *m_out_head,
+ struct rte_mbuf *m_out, uint16_t in_offset, uint16_t out_offset,
+ uint16_t seg_total_left, struct rte_bbdev_stats *q_stats)
+{
+#ifdef RTE_BBDEV_SDK_AVX512
+ RTE_SET_USED(seg_total_left);
+ uint8_t *in, *rm_out;
+ struct rte_bbdev_op_ldpc_enc *enc = &op->ldpc_enc;
+ struct bblib_ldpc_encoder_5gnr_request ldpc_req;
+ struct bblib_ldpc_encoder_5gnr_response ldpc_resp;
+ struct bblib_LDPC_ratematch_5gnr_request rm_req;
+ struct bblib_LDPC_ratematch_5gnr_response rm_resp;
+ struct bblib_crc_request crc_req;
+ struct bblib_crc_response crc_resp;
+ uint16_t msgLen, puntBits, parity_offset, out_len;
+ uint16_t K = (enc->basegraph == 1 ? 22 : 10) * enc->z_c;
+ uint16_t in_length_in_bits = K - enc->n_filler;
+ uint16_t in_length_in_bytes = (in_length_in_bits + 7) >> 3;
+
+#ifdef RTE_BBDEV_OFFLOAD_COST
+ uint64_t start_time = rte_rdtsc_precise();
+#else
+ RTE_SET_USED(q_stats);
+#endif
+
+ in = rte_pktmbuf_mtod_offset(m_in, uint8_t *, in_offset);
+
+ /* Masking the Filler bits explicitly */
+ memset(q->enc_in + (in_length_in_bytes - 3), 0,
+ ((K + 7) >> 3) - (in_length_in_bytes - 3));
+ /* CRC Generation */
+ if (enc->op_flags & RTE_BBDEV_LDPC_CRC_24A_ATTACH) {
+ rte_memcpy(q->enc_in, in, in_length_in_bytes - 3);
+ crc_req.data = in;
+ crc_req.len = in_length_in_bits - 24;
+ crc_resp.data = q->enc_in;
+ bblib_lte_crc24a_gen(&crc_req, &crc_resp);
+ } else if (enc->op_flags & RTE_BBDEV_LDPC_CRC_24B_ATTACH) {
+ rte_memcpy(q->enc_in, in, in_length_in_bytes - 3);
+ crc_req.data = in;
+ crc_req.len = in_length_in_bits - 24;
+ crc_resp.data = q->enc_in;
+ bblib_lte_crc24b_gen(&crc_req, &crc_resp);
+ } else
+ rte_memcpy(q->enc_in, in, in_length_in_bytes);
+
+ /* LDPC Encoding */
+ ldpc_req.Zc = enc->z_c;
+ ldpc_req.baseGraph = enc->basegraph;
+ /* Number of rows set to maximum */
+ ldpc_req.nRows = ldpc_req.baseGraph == 1 ? 46 : 42;
+ ldpc_req.numberCodeblocks = 1;
+ ldpc_req.input[0] = (int8_t *) q->enc_in;
+ ldpc_resp.output[0] = (int8_t *) q->enc_out;
+
+ bblib_bit_reverse(ldpc_req.input[0], in_length_in_bytes << 3);
+
+ if (bblib_ldpc_encoder_5gnr(&ldpc_req, &ldpc_resp) != 0) {
+ op->status |= 1 << RTE_BBDEV_DRV_ERROR;
+ rte_bbdev_log(ERR, "LDPC Encoder failed");
+ return;
+ }
+
+ /*
+ * Systematic + Parity : Recreating stream with filler bits, ideally
+ * the bit select could handle this in the RM SDK
+ */
+ msgLen = (ldpc_req.baseGraph == 1 ? 22 : 10) * ldpc_req.Zc;
+ puntBits = 2 * ldpc_req.Zc;
+ parity_offset = msgLen - puntBits;
+ ippsCopyBE_1u(((uint8_t *) ldpc_req.input[0]) + (puntBits / 8),
+ puntBits%8, q->adapter_output, 0, parity_offset);
+ ippsCopyBE_1u(q->enc_out, 0, q->adapter_output + (parity_offset / 8),
+ parity_offset % 8, ldpc_req.nRows * ldpc_req.Zc);
+
+ out_len = (e + 7) >> 3;
+ /* get output data starting address */
+ rm_out = (uint8_t *)mbuf_append(m_out_head, m_out, out_len);
+ if (rm_out == NULL) {
+ op->status |= 1 << RTE_BBDEV_DATA_ERROR;
+ rte_bbdev_log(ERR,
+ "Too little space in output mbuf");
+ return;
+ }
+ /*
+ * rte_bbdev_op_data.offset can be different than the offset
+ * of the appended bytes
+ */
+ rm_out = rte_pktmbuf_mtod_offset(m_out, uint8_t *, out_offset);
+
+ /* Rate-Matching */
+ rm_req.E = e;
+ rm_req.Ncb = enc->n_cb;
+ rm_req.Qm = enc->q_m;
+ rm_req.Zc = enc->z_c;
+ rm_req.baseGraph = enc->basegraph;
+ rm_req.input = q->adapter_output;
+ rm_req.nLen = enc->n_filler;
+ rm_req.nullIndex = parity_offset - enc->n_filler;
+ rm_req.rvidx = enc->rv_index;
+ rm_resp.output = q->deint_output;
+
+ if (bblib_LDPC_ratematch_5gnr(&rm_req, &rm_resp) != 0) {
+ op->status |= 1 << RTE_BBDEV_DRV_ERROR;
+ rte_bbdev_log(ERR, "Rate matching failed");
+ return;
+ }
+
+ /* RM SDK may provide non zero bits on last byte */
+ if ((e % 8) != 0)
+ q->deint_output[out_len-1] &= (1 << (e % 8)) - 1;
+
+ bblib_bit_reverse((int8_t *) q->deint_output, out_len << 3);
+
+ rte_memcpy(rm_out, q->deint_output, out_len);
+ enc->output.length += out_len;
+
+#ifdef RTE_BBDEV_OFFLOAD_COST
+ q_stats->acc_offload_cycles += rte_rdtsc_precise() - start_time;
+#endif
+#else
+ RTE_SET_USED(q);
+ RTE_SET_USED(op);
+ RTE_SET_USED(e);
+ RTE_SET_USED(m_in);
+ RTE_SET_USED(m_out_head);
+ RTE_SET_USED(m_out);
+ RTE_SET_USED(in_offset);
+ RTE_SET_USED(out_offset);
+ RTE_SET_USED(seg_total_left);
+ RTE_SET_USED(q_stats);
+#endif
+}
+
static inline void
enqueue_enc_one_op(struct turbo_sw_queue *q, struct rte_bbdev_enc_op *op,
struct rte_bbdev_stats *queue_stats)
@@ -850,6 +1049,93 @@ struct turbo_sw_queue {
}
}
+
+static inline void
+enqueue_ldpc_enc_one_op(struct turbo_sw_queue *q, struct rte_bbdev_enc_op *op,
+ struct rte_bbdev_stats *queue_stats)
+{
+ uint8_t c, r, crc24_bits = 0;
+ uint32_t e;
+ struct rte_bbdev_op_ldpc_enc *enc = &op->ldpc_enc;
+ uint16_t in_offset = enc->input.offset;
+ uint16_t out_offset = enc->output.offset;
+ struct rte_mbuf *m_in = enc->input.data;
+ struct rte_mbuf *m_out = enc->output.data;
+ struct rte_mbuf *m_out_head = enc->output.data;
+ uint32_t in_length, mbuf_total_left = enc->input.length;
+
+ uint16_t seg_total_left;
+
+ /* Clear op status */
+ op->status = 0;
+
+ if (mbuf_total_left > RTE_BBDEV_TURBO_MAX_TB_SIZE >> 3) {
+ rte_bbdev_log(ERR, "TB size (%u) is too big, max: %d",
+ mbuf_total_left, RTE_BBDEV_TURBO_MAX_TB_SIZE);
+ op->status = 1 << RTE_BBDEV_DATA_ERROR;
+ return;
+ }
+
+ if (m_in == NULL || m_out == NULL) {
+ rte_bbdev_log(ERR, "Invalid mbuf pointer");
+ op->status = 1 << RTE_BBDEV_DATA_ERROR;
+ return;
+ }
+
+ if ((enc->op_flags & RTE_BBDEV_TURBO_CRC_24B_ATTACH) ||
+ (enc->op_flags & RTE_BBDEV_TURBO_CRC_24A_ATTACH))
+ crc24_bits = 24;
+
+ if (enc->code_block_mode == 0) { /* For Transport Block mode */
+ c = enc->tb_params.c;
+ r = enc->tb_params.r;
+ } else { /* For Code Block mode */
+ c = 1;
+ r = 0;
+ }
+
+ while (mbuf_total_left > 0 && r < c) {
+
+ seg_total_left = rte_pktmbuf_data_len(m_in) - in_offset;
+
+ if (enc->code_block_mode == 0) {
+ e = (r < enc->tb_params.cab) ?
+ enc->tb_params.ea : enc->tb_params.eb;
+ } else {
+ e = enc->cb_params.e;
+ }
+
+ process_ldpc_enc_cb(q, op, e, m_in, m_out_head,
+ m_out, in_offset, out_offset, seg_total_left,
+ queue_stats);
+ /* Update total_left */
+ in_length = (enc->basegraph == 1 ? 22 : 10) * enc->z_c;
+ in_length = ((in_length - crc24_bits - enc->n_filler) >> 3);
+ mbuf_total_left -= in_length;
+ /* Update offsets for next CBs (if exist) */
+ in_offset += in_length;
+ out_offset += (e + 7) >> 3;
+
+ /* Update offsets */
+ if (seg_total_left == in_length) {
+ /* Go to the next mbuf */
+ m_in = m_in->next;
+ m_out = m_out->next;
+ in_offset = 0;
+ out_offset = 0;
+ }
+ r++;
+ }
+
+ /* check if all input data was processed */
+ if (mbuf_total_left != 0) {
+ op->status |= 1 << RTE_BBDEV_DATA_ERROR;
+ rte_bbdev_log(ERR,
+ "Mismatch between mbuf length and included CBs sizes %d",
+ mbuf_total_left);
+ }
+}
+
static inline uint16_t
enqueue_enc_all_ops(struct turbo_sw_queue *q, struct rte_bbdev_enc_op **ops,
uint16_t nb_ops, struct rte_bbdev_stats *queue_stats)
@@ -866,6 +1152,23 @@ struct turbo_sw_queue {
NULL);
}
+static inline uint16_t
+enqueue_ldpc_enc_all_ops(struct turbo_sw_queue *q,
+ struct rte_bbdev_enc_op **ops,
+ uint16_t nb_ops, struct rte_bbdev_stats *queue_stats)
+{
+ uint16_t i;
+#ifdef RTE_BBDEV_OFFLOAD_COST
+ queue_stats->acc_offload_cycles = 0;
+#endif
+
+ for (i = 0; i < nb_ops; ++i)
+ enqueue_ldpc_enc_one_op(q, ops[i], queue_stats);
+
+ return rte_ring_enqueue_burst(q->processed_pkts, (void **)ops, nb_ops,
+ NULL);
+}
+
#ifdef RTE_BBDEV_SDK_AVX2
static inline void
move_padding_bytes(const uint8_t *in, uint8_t *out, uint16_t k,
@@ -890,7 +1193,11 @@ struct turbo_sw_queue {
struct rte_bbdev_stats *q_stats)
{
#ifdef RTE_BBDEV_SDK_AVX2
+#ifdef RTE_LIBRTE_BBDEV_DEBUG
int ret;
+#else
+ RTE_SET_USED(in_length);
+#endif
int32_t k_idx;
int32_t iter_cnt;
uint8_t *in, *out, *adapter_input;
@@ -908,11 +1215,13 @@ struct turbo_sw_queue {
k_idx = compute_idx(k);
+#ifdef RTE_LIBRTE_BBDEV_DEBUG
ret = is_dec_input_valid(k_idx, kw, in_length);
if (ret != 0) {
op->status |= 1 << RTE_BBDEV_DATA_ERROR;
return;
}
+#endif
in = rte_pktmbuf_mtod_offset(m_in, uint8_t *, in_offset);
ncb = kw;
@@ -928,11 +1237,12 @@ struct turbo_sw_queue {
deint_resp.pinteleavebuffer = q->deint_output;
#ifdef RTE_BBDEV_OFFLOAD_COST
- start_time = rte_rdtsc_precise();
+ start_time = rte_rdtsc_precise();
#endif
+ /* Sub-block De-Interleaving */
bblib_deinterleave_ul(&deint_req, &deint_resp);
#ifdef RTE_BBDEV_OFFLOAD_COST
- q_stats->acc_offload_cycles += rte_rdtsc_precise() - start_time;
+ q_stats->acc_offload_cycles += rte_rdtsc_precise() - start_time;
#endif
} else
move_padding_bytes(in, q->deint_output, k, ncb);
@@ -1025,6 +1335,202 @@ struct turbo_sw_queue {
}
static inline void
+process_ldpc_dec_cb(struct turbo_sw_queue *q, struct rte_bbdev_dec_op *op,
+ uint8_t c, uint16_t out_length, uint16_t e,
+ struct rte_mbuf *m_in,
+ struct rte_mbuf *m_out_head, struct rte_mbuf *m_out,
+ struct rte_mbuf *m_harq_in,
+ struct rte_mbuf *m_harq_out_head, struct rte_mbuf *m_harq_out,
+ uint16_t in_offset, uint16_t out_offset,
+ uint16_t harq_in_offset, uint16_t harq_out_offset,
+ bool check_crc_24b,
+ uint16_t crc24_overlap, uint16_t in_length,
+ struct rte_bbdev_stats *q_stats)
+{
+#ifdef RTE_BBDEV_SDK_AVX512
+ RTE_SET_USED(in_length);
+ RTE_SET_USED(c);
+ uint8_t *in, *out, *harq_in, *harq_out, *adapter_input;
+ struct bblib_rate_dematching_5gnr_request derm_req;
+ struct bblib_rate_dematching_5gnr_response derm_resp;
+ struct bblib_ldpc_decoder_5gnr_request dec_req;
+ struct bblib_ldpc_decoder_5gnr_response dec_resp;
+ struct bblib_crc_request crc_req;
+ struct bblib_crc_response crc_resp;
+ struct rte_bbdev_op_ldpc_dec *dec = &op->ldpc_dec;
+ uint16_t K, parity_offset, sys_cols, outLenWithCrc;
+ int16_t deRmOutSize, numRows;
+
+ /* Compute some LDPC BG lengths */
+ outLenWithCrc = out_length + (crc24_overlap >> 3);
+ sys_cols = (dec->basegraph == 1) ? 22 : 10;
+ K = sys_cols * dec->z_c;
+ parity_offset = K - 2 * dec->z_c;
+
+#ifdef RTE_BBDEV_OFFLOAD_COST
+ uint64_t start_time = rte_rdtsc_precise();
+#else
+ RTE_SET_USED(q_stats);
+#endif
+
+ in = rte_pktmbuf_mtod_offset(m_in, uint8_t *, in_offset);
+
+ if (check_bit(dec->op_flags, RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE)) {
+ /**
+ * Single contiguous block from the first LLR of the
+ * circular buffer.
+ */
+ harq_in = NULL;
+ if (m_harq_in != NULL)
+ harq_in = rte_pktmbuf_mtod_offset(m_harq_in,
+ uint8_t *, harq_in_offset);
+ if (harq_in == NULL) {
+ op->status |= 1 << RTE_BBDEV_DATA_ERROR;
+ rte_bbdev_log(ERR, "No space in harq input mbuf");
+ return;
+ }
+ uint16_t harq_in_length = RTE_MIN(
+ dec->harq_combined_input.length,
+ (uint32_t) dec->n_cb);
+ memset(q->ag + harq_in_length, 0,
+ dec->n_cb - harq_in_length);
+ rte_memcpy(q->ag, harq_in, harq_in_length);
+ }
+
+ derm_req.p_in = (int8_t *) in;
+ derm_req.p_harq = q->ag; /* This doesn't include the filler bits */
+ derm_req.base_graph = dec->basegraph;
+ derm_req.zc = dec->z_c;
+ derm_req.ncb = dec->n_cb;
+ derm_req.e = e;
+ derm_req.k0 = 0; /* Actual output from SDK */
+ derm_req.isretx = check_bit(dec->op_flags,
+ RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE);
+ derm_req.rvid = dec->rv_index;
+ derm_req.modulation_order = dec->q_m;
+ derm_req.start_null_index = parity_offset - dec->n_filler;
+ derm_req.num_of_null = dec->n_filler;
+
+ bblib_rate_dematching_5gnr(&derm_req, &derm_resp);
+
+ /* Compute RM out size and number of rows */
+ deRmOutSize = RTE_MIN(
+ derm_req.k0 + derm_req.e -
+ ((derm_req.k0 < derm_req.start_null_index) ?
+ 0 : dec->n_filler),
+ dec->n_cb - dec->n_filler);
+ if (m_harq_in != NULL)
+ deRmOutSize = RTE_MAX(deRmOutSize,
+ RTE_MIN(dec->n_cb - dec->n_filler,
+ m_harq_in->data_len));
+ numRows = ((deRmOutSize + dec->n_filler + dec->z_c - 1) / dec->z_c)
+ - sys_cols + 2;
+ numRows = RTE_MAX(4, numRows);
+
+ /* get output data starting address */
+ out = (uint8_t *)mbuf_append(m_out_head, m_out, out_length);
+ if (out == NULL) {
+ op->status |= 1 << RTE_BBDEV_DATA_ERROR;
+ rte_bbdev_log(ERR,
+ "Too little space in LDPC decoder output mbuf");
+ return;
+ }
+
+ /* rte_bbdev_op_data.offset can be different than the offset
+ * of the appended bytes
+ */
+ out = rte_pktmbuf_mtod_offset(m_out, uint8_t *, out_offset);
+ adapter_input = q->enc_out;
+
+ dec_req.Zc = dec->z_c;
+ dec_req.baseGraph = dec->basegraph;
+ dec_req.nRows = numRows;
+ dec_req.numChannelLlrs = deRmOutSize;
+ dec_req.varNodes = derm_req.p_harq;
+ dec_req.numFillerBits = dec->n_filler;
+ dec_req.maxIterations = dec->iter_max;
+ dec_req.enableEarlyTermination = check_bit(dec->op_flags,
+ RTE_BBDEV_LDPC_ITERATION_STOP_ENABLE);
+ dec_resp.varNodes = (int16_t *) q->adapter_output;
+ dec_resp.compactedMessageBytes = q->enc_out;
+
+ bblib_ldpc_decoder_5gnr(&dec_req, &dec_resp);
+
+ dec->iter_count = RTE_MAX(dec_resp.iterationAtTermination,
+ dec->iter_count);
+ if (!dec_resp.parityPassedAtTermination)
+ op->status |= 1 << RTE_BBDEV_SYNDROME_ERROR;
+
+ bblib_bit_reverse((int8_t *) q->enc_out, outLenWithCrc << 3);
+
+ if (check_bit(dec->op_flags, RTE_BBDEV_LDPC_CRC_TYPE_24A_CHECK) ||
+ check_bit(dec->op_flags,
+ RTE_BBDEV_LDPC_CRC_TYPE_24B_CHECK)) {
+ crc_req.data = adapter_input;
+ crc_req.len = K - dec->n_filler - 24;
+ crc_resp.check_passed = false;
+ crc_resp.data = adapter_input;
+ if (check_crc_24b)
+ bblib_lte_crc24b_check(&crc_req, &crc_resp);
+ else
+ bblib_lte_crc24a_check(&crc_req, &crc_resp);
+ if (!crc_resp.check_passed)
+ op->status |= 1 << RTE_BBDEV_CRC_ERROR;
+ }
+
+#ifdef RTE_BBDEV_OFFLOAD_COST
+ q_stats->acc_offload_cycles += rte_rdtsc_precise() - start_time;
+#endif
+ if (check_bit(dec->op_flags, RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE)) {
+ harq_out = NULL;
+ if (m_harq_out != NULL) {
+ /* Initialize HARQ data length since we overwrite */
+ m_harq_out->data_len = 0;
+ /* Check there is enough space
+ * in the HARQ outbound buffer
+ */
+ harq_out = (uint8_t *)mbuf_append(m_harq_out_head,
+ m_harq_out, deRmOutSize);
+ }
+ if (harq_out == NULL) {
+ op->status |= 1 << RTE_BBDEV_DATA_ERROR;
+ rte_bbdev_log(ERR, "No space in HARQ output mbuf");
+ return;
+ }
+ /* get output data starting address and overwrite the data */
+ harq_out = rte_pktmbuf_mtod_offset(m_harq_out, uint8_t *,
+ harq_out_offset);
+ rte_memcpy(harq_out, derm_req.p_harq, deRmOutSize);
+ dec->harq_combined_output.length += deRmOutSize;
+ }
+
+ rte_memcpy(out, adapter_input, out_length);
+ dec->hard_output.length += out_length;
+#else
+ RTE_SET_USED(q);
+ RTE_SET_USED(op);
+ RTE_SET_USED(c);
+ RTE_SET_USED(out_length);
+ RTE_SET_USED(e);
+ RTE_SET_USED(m_in);
+ RTE_SET_USED(m_out_head);
+ RTE_SET_USED(m_out);
+ RTE_SET_USED(m_harq_in);
+ RTE_SET_USED(m_harq_out_head);
+ RTE_SET_USED(m_harq_out);
+ RTE_SET_USED(harq_in_offset);
+ RTE_SET_USED(harq_out_offset);
+ RTE_SET_USED(in_offset);
+ RTE_SET_USED(out_offset);
+ RTE_SET_USED(check_crc_24b);
+ RTE_SET_USED(crc24_overlap);
+ RTE_SET_USED(in_length);
+ RTE_SET_USED(q_stats);
+#endif
+}
+
+
+static inline void
enqueue_dec_one_op(struct turbo_sw_queue *q, struct rte_bbdev_dec_op *op,
struct rte_bbdev_stats *queue_stats)
{
@@ -1083,6 +1589,7 @@ struct turbo_sw_queue {
in_offset, out_offset, check_bit(dec->op_flags,
RTE_BBDEV_TURBO_CRC_TYPE_24B), crc24_overlap,
seg_total_left, queue_stats);
+
/* To keep CRC24 attached to end of Code block, use
* RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP flag as it
* removed by default once verified.
@@ -1104,6 +1611,103 @@ struct turbo_sw_queue {
}
r++;
}
+
+ if (mbuf_total_left != 0) {
+ op->status |= 1 << RTE_BBDEV_DATA_ERROR;
+ rte_bbdev_log(ERR,
+ "Mismatch between mbuf length and included Circular buffer sizes");
+ }
+}
+
+static inline void
+enqueue_ldpc_dec_one_op(struct turbo_sw_queue *q, struct rte_bbdev_dec_op *op,
+ struct rte_bbdev_stats *queue_stats)
+{
+ uint8_t c, r = 0;
+ uint16_t e, out_length;
+ uint16_t crc24_overlap = 0;
+ struct rte_bbdev_op_ldpc_dec *dec = &op->ldpc_dec;
+ struct rte_mbuf *m_in = dec->input.data;
+ struct rte_mbuf *m_harq_in = dec->harq_combined_input.data;
+ struct rte_mbuf *m_harq_out = dec->harq_combined_output.data;
+ struct rte_mbuf *m_harq_out_head = dec->harq_combined_output.data;
+ struct rte_mbuf *m_out = dec->hard_output.data;
+ struct rte_mbuf *m_out_head = dec->hard_output.data;
+ uint16_t in_offset = dec->input.offset;
+ uint16_t harq_in_offset = dec->harq_combined_input.offset;
+ uint16_t harq_out_offset = dec->harq_combined_output.offset;
+ uint16_t out_offset = dec->hard_output.offset;
+ uint32_t mbuf_total_left = dec->input.length;
+ uint16_t seg_total_left;
+
+ /* Clear op status */
+ op->status = 0;
+
+ if (m_in == NULL || m_out == NULL) {
+ rte_bbdev_log(ERR, "Invalid mbuf pointer");
+ op->status = 1 << RTE_BBDEV_DATA_ERROR;
+ return;
+ }
+
+ if (dec->code_block_mode == 0) { /* For Transport Block mode */
+ c = dec->tb_params.c;
+ e = dec->tb_params.ea;
+ } else { /* For Code Block mode */
+ c = 1;
+ e = dec->cb_params.e;
+ }
+
+ if (check_bit(dec->op_flags, RTE_BBDEV_LDPC_CRC_TYPE_24B_DROP))
+ crc24_overlap = 24;
+
+ out_length = (dec->basegraph == 1 ? 22 : 10) * dec->z_c; /* K */
+ out_length = ((out_length - crc24_overlap - dec->n_filler) >> 3);
+
+ while (mbuf_total_left > 0) {
+ if (dec->code_block_mode == 0)
+ e = (r < dec->tb_params.cab) ?
+ dec->tb_params.ea : dec->tb_params.eb;
+
+ seg_total_left = rte_pktmbuf_data_len(m_in) - in_offset;
+
+ process_ldpc_dec_cb(q, op, c, out_length, e,
+ m_in, m_out_head, m_out,
+ m_harq_in, m_harq_out_head, m_harq_out,
+ in_offset, out_offset, harq_in_offset,
+ harq_out_offset,
+ check_bit(dec->op_flags,
+ RTE_BBDEV_LDPC_CRC_TYPE_24B_CHECK),
+ crc24_overlap,
+ seg_total_left, queue_stats);
+
+ /* To keep CRC24 attached to end of Code block, use
+ * RTE_BBDEV_LDPC_DEC_TB_CRC_24B_KEEP flag as it
+ * removed by default once verified.
+ */
+
+ mbuf_total_left -= e;
+
+ /* Update offsets */
+ if (seg_total_left == e) {
+ /* Go to the next mbuf */
+ m_in = m_in->next;
+ m_out = m_out->next;
+ if (m_harq_in != NULL)
+ m_harq_in = m_harq_in->next;
+ if (m_harq_out != NULL)
+ m_harq_out = m_harq_out->next;
+ in_offset = 0;
+ out_offset = 0;
+ harq_in_offset = 0;
+ harq_out_offset = 0;
+ } else {
+ /* Update offsets for next CBs (if exist) */
+ in_offset += e;
+ out_offset += out_length;
+ }
+ r++;
+ }
+
if (mbuf_total_left != 0) {
op->status |= 1 << RTE_BBDEV_DATA_ERROR;
rte_bbdev_log(ERR,
@@ -1127,6 +1731,23 @@ struct turbo_sw_queue {
NULL);
}
+static inline uint16_t
+enqueue_ldpc_dec_all_ops(struct turbo_sw_queue *q,
+ struct rte_bbdev_dec_op **ops,
+ uint16_t nb_ops, struct rte_bbdev_stats *queue_stats)
+{
+ uint16_t i;
+#ifdef RTE_BBDEV_OFFLOAD_COST
+ queue_stats->acc_offload_cycles = 0;
+#endif
+
+ for (i = 0; i < nb_ops; ++i)
+ enqueue_ldpc_dec_one_op(q, ops[i], queue_stats);
+
+ return rte_ring_enqueue_burst(q->processed_pkts, (void **)ops, nb_ops,
+ NULL);
+}
+
/* Enqueue burst */
static uint16_t
enqueue_enc_ops(struct rte_bbdev_queue_data *q_data,
@@ -1146,6 +1767,24 @@ struct turbo_sw_queue {
/* Enqueue burst */
static uint16_t
+enqueue_ldpc_enc_ops(struct rte_bbdev_queue_data *q_data,
+ struct rte_bbdev_enc_op **ops, uint16_t nb_ops)
+{
+ void *queue = q_data->queue_private;
+ struct turbo_sw_queue *q = queue;
+ uint16_t nb_enqueued = 0;
+
+ nb_enqueued = enqueue_ldpc_enc_all_ops(
+ q, ops, nb_ops, &q_data->queue_stats);
+
+ q_data->queue_stats.enqueue_err_count += nb_ops - nb_enqueued;
+ q_data->queue_stats.enqueued_count += nb_enqueued;
+
+ return nb_enqueued;
+}
+
+/* Enqueue burst */
+static uint16_t
enqueue_dec_ops(struct rte_bbdev_queue_data *q_data,
struct rte_bbdev_dec_op **ops, uint16_t nb_ops)
{
@@ -1161,6 +1800,24 @@ struct turbo_sw_queue {
return nb_enqueued;
}
+/* Enqueue burst */
+static uint16_t
+enqueue_ldpc_dec_ops(struct rte_bbdev_queue_data *q_data,
+ struct rte_bbdev_dec_op **ops, uint16_t nb_ops)
+{
+ void *queue = q_data->queue_private;
+ struct turbo_sw_queue *q = queue;
+ uint16_t nb_enqueued = 0;
+
+ nb_enqueued = enqueue_ldpc_dec_all_ops(q, ops, nb_ops,
+ &q_data->queue_stats);
+
+ q_data->queue_stats.enqueue_err_count += nb_ops - nb_enqueued;
+ q_data->queue_stats.enqueued_count += nb_enqueued;
+
+ return nb_enqueued;
+}
+
/* Dequeue decode burst */
static uint16_t
dequeue_dec_ops(struct rte_bbdev_queue_data *q_data,
@@ -1273,6 +1930,10 @@ struct turbo_sw_queue {
bbdev->dequeue_dec_ops = dequeue_dec_ops;
bbdev->enqueue_enc_ops = enqueue_enc_ops;
bbdev->enqueue_dec_ops = enqueue_dec_ops;
+ bbdev->dequeue_ldpc_enc_ops = dequeue_enc_ops;
+ bbdev->dequeue_ldpc_dec_ops = dequeue_dec_ops;
+ bbdev->enqueue_ldpc_enc_ops = enqueue_ldpc_enc_ops;
+ bbdev->enqueue_ldpc_dec_ops = enqueue_ldpc_dec_ops;
((struct bbdev_private *) bbdev->data->dev_private)->max_nb_queues =
init_params->queues_num;
diff --git a/drivers/baseband/turbo_sw/meson.build b/drivers/baseband/turbo_sw/meson.build
index 438b5a7..33345aa 100644
--- a/drivers/baseband/turbo_sw/meson.build
+++ b/drivers/baseband/turbo_sw/meson.build
@@ -23,6 +23,16 @@ if dpdk_conf.has('RTE_BBDEV_SDK_AVX2')
includes += include_directories(path + '/lib_common')
endif
endif
+if dpdk_conf.has('RTE_BBDEV_SDK_AVX512')
+ ext_deps += cc.find_library('libldpc_encoder_5gnr', dirs: [path + '/lib_ldpc_encoder_5gnr'], required: true)
+ ext_deps += cc.find_library('libldpc_decoder_5gnr', dirs: [path + '/lib_ldpc_decoder_5gnr'], required: true)
+ ext_deps += cc.find_library('libLDPC_ratematch_5gnr', dirs: [path + '/lib_LDPC_ratematch_5gnr'], required: true)
+ ext_deps += cc.find_library('librate_dematching_5gnr', dirs: [path + '/lib_rate_dematching_5gnr'], required: true)
+ includes += include_directories(path + '/lib_ldpc_encoder_5gnr')
+ includes += include_directories(path + '/lib_ldpc_decoder_5gnr')
+ includes += include_directories(path + '/lib_LDPC_ratematch_5gnr')
+ includes += include_directories(path + '/lib_rate_dematching_5gnr')
+endif
deps += ['bbdev', 'bus_vdev', 'ring']
name = 'bbdev_turbo_sw'
diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index c9fbdd6..1036df7 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -232,7 +232,13 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_BBDEV_TURBO_SW) += -L$(FLEXRAN_SDK)/lib_crc -lcr
_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_BBDEV_TURBO_SW) += -L$(FLEXRAN_SDK)/lib_turbo -lturbo
_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_BBDEV_TURBO_SW) += -L$(FLEXRAN_SDK)/lib_rate_matching -lrate_matching
_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_BBDEV_TURBO_SW) += -L$(FLEXRAN_SDK)/lib_common -lcommon
-_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_BBDEV_TURBO_SW) += -lirc -limf -lstdc++ -lipps
+_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_BBDEV_TURBO_SW) += -lirc -limf -lstdc++ -lipps -lsvml
+ifeq ($(CONFIG_RTE_BBDEV_SDK_AVX512),y)
+_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_BBDEV_TURBO_SW) += -L$(FLEXRAN_SDK)/lib_LDPC_ratematch_5gnr -lLDPC_ratematch_5gnr
+_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_BBDEV_TURBO_SW) += -L$(FLEXRAN_SDK)/lib_ldpc_encoder_5gnr -lldpc_encoder_5gnr
+_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_BBDEV_TURBO_SW) += -L$(FLEXRAN_SDK)/lib_ldpc_decoder_5gnr -lldpc_decoder_5gnr
+_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_BBDEV_TURBO_SW) += -L$(FLEXRAN_SDK)/lib_rate_dematching_5gnr -lrate_dematching_5gnr
+endif # CONFIG_RTE_BBDEV_SDK_AVX512
endif # CONFIG_RTE_BBDEV_SDK_AVX2
endif # CONFIG_RTE_LIBRTE_BBDEV
--
1.8.3.1
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [PATCH v4 1/4] ethdev: add GRE key field to flow API
2019-07-03 15:25 4% ` Adrien Mazarguil
@ 2019-07-04 2:43 0% ` Jack Min
0 siblings, 0 replies; 200+ results
From: Jack Min @ 2019-07-04 2:43 UTC (permalink / raw)
To: Adrien Mazarguil
Cc: Ori Kam, John McNamara, Marko Kovacevic, Thomas Monjalon,
Ferruh Yigit, Andrew Rybchenko, dev
On Wed, 19-07-03, 17:25, Adrien Mazarguil wrote:
> On Tue, Jul 02, 2019 at 05:45:52PM +0800, Xiaoyu Min wrote:
> > Add new rte_flow_item_gre_key in order to match the optional key field.
> >
> > Signed-off-by: Xiaoyu Min <jackmin@mellanox.com>
>
> OK with adding this feature, however I still have a bunch of comments below.
>
> > ---
> > doc/guides/prog_guide/rte_flow.rst | 8 ++++++++
> > lib/librte_ethdev/rte_flow.c | 1 +
> > lib/librte_ethdev/rte_flow.h | 7 +++++++
> > 3 files changed, 16 insertions(+)
> >
> > diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> > index a34d012e55..f4b7baa3c3 100644
> > --- a/doc/guides/prog_guide/rte_flow.rst
> > +++ b/doc/guides/prog_guide/rte_flow.rst
> > @@ -980,6 +980,14 @@ Matches a GRE header.
> > - ``protocol``: protocol type.
> > - Default ``mask`` matches protocol only.
> >
> > +Item: ``GRE_KEY``
> > +^^^^^^^^^^^^^^^^^
> > +
> > +Matches a GRE key field.
> > +This should be preceded by item ``GRE``
>
> Nit: missing ending "."
>
Ok, I'll add it.
> > +
> > +- Value to be matched is a big-endian 32 bit integer
> > +
> > Item: ``FUZZY``
> > ^^^^^^^^^^^^^^^
> >
> > diff --git a/lib/librte_ethdev/rte_flow.c b/lib/librte_ethdev/rte_flow.c
> > index 3277be1edb..f3e56d0bbe 100644
> > --- a/lib/librte_ethdev/rte_flow.c
> > +++ b/lib/librte_ethdev/rte_flow.c
> > @@ -55,6 +55,7 @@ static const struct rte_flow_desc_data rte_flow_desc_item[] = {
> > MK_FLOW_ITEM(NVGRE, sizeof(struct rte_flow_item_nvgre)),
> > MK_FLOW_ITEM(MPLS, sizeof(struct rte_flow_item_mpls)),
> > MK_FLOW_ITEM(GRE, sizeof(struct rte_flow_item_gre)),
> > + MK_FLOW_ITEM(GRE_KEY, sizeof(rte_be32_t)),
>
> Hmm? Adding a new item in the middle?
>
I'll add it at the end.
> > MK_FLOW_ITEM(FUZZY, sizeof(struct rte_flow_item_fuzzy)),
> > MK_FLOW_ITEM(GTP, sizeof(struct rte_flow_item_gtp)),
> > MK_FLOW_ITEM(GTPC, sizeof(struct rte_flow_item_gtp)),
> > diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> > index f3a8fb103f..5d3702a44c 100644
> > --- a/lib/librte_ethdev/rte_flow.h
> > +++ b/lib/librte_ethdev/rte_flow.h
> > @@ -289,6 +289,13 @@ enum rte_flow_item_type {
> > */
> > RTE_FLOW_ITEM_TYPE_GRE,
> >
> > + /**
> > + * Matches a GRE optional key field.
> > + *
> > + * The value should a big-endian 32bit integer.
> > + */
> > + RTE_FLOW_ITEM_TYPE_GRE_KEY,
> > +
>
> Same comment. While I understand the intent to group GRE and GRE_KEY, doing
> so causes ABI breakage by shifting the value of all subsequent pattern
> items (see IPV6 and IPV6_EXT for instance).
>
Oh, I was't aware of this. Thank you for explaination.
> We could later decide to sort them while knowingly breaking ABI on purpose,
> however right now there's no choice but adding new pattern items and actions
> at the end of their respective enums, please do that.
>
Yes, I'll do this.
> --
> Adrien Mazarguil
> 6WIND
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v1 1/2] lib/ring: add enqueue-dequeue callabck
@ 2019-07-04 5:04 0% ` Varghese, Vipin
0 siblings, 0 replies; 200+ results
From: Varghese, Vipin @ 2019-07-04 5:04 UTC (permalink / raw)
To: Honnappa Nagarahalli, olivier.matz, Pattan, Reshma, Wiles, Keith, dev
Cc: Padubidri, Sanjay A, nd, nd
Thanks Honnappa, will work on the changes suggested.
> -----Original Message-----
> From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> Sent: Tuesday, June 11, 2019 9:48 AM
> To: Varghese, Vipin <vipin.varghese@intel.com>; olivier.matz@6wind.com;
> Pattan, Reshma <reshma.pattan@intel.com>; Wiles, Keith
> <keith.wiles@intel.com>; dev@dpdk.org
> Cc: Padubidri, Sanjay A <sanjay.padubidri@intel.com>; Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com>; nd <nd@arm.com>; nd <nd@arm.com>
> Subject: RE: [dpdk-dev] [PATCH v1 1/2] lib/ring: add enqueue-dequeue callabck
>
> >
> > Hi Honnappa,
> >
> > snipped
> > > >
> > > > Add callback event handler for enqueue dequeue operation on ring.
> > > > The pre-enqueue and post-dequeue operation on ring is selected to
> > > > invoke user callback handler.
> > > Can you provide a use case for this to better understand the need?
> > Use cases:
> > - allow user to investigate the contents pre-enqueue.
> > - allow user to investigate the contents post-dequeue.
> > - modify pre-enqueue and post-dequeue stage content.
> > - investigate PMD meta data for debug in field nodes.
> >
> > snipped
> > > > + struct rte_ring_enq_cb_list enq_cbs;
> > > > + struct rte_ring_deq_cb_list deq_cbs; };
> > > This breaks ABI compatibility
> > Can you help me understand this more clearly?
> 'struct rte_ring' is exposed to the application. It is possible that the application has
> declared a variable of type 'struct rte_ring'. Any addition to this structure will
> increase the size of 'struct rte_ring'. Hence, it won't be compatible.
>
> >
> > snipped
> > > > -rte_ring_enqueue_burst(struct rte_ring *r, void * const
> > > > *obj_table,
> > > > +rte_ring_enqueue_burst(struct rte_ring *r, void **obj_table,
> > > > unsigned int n, unsigned int *free_space) {
> > > > +#ifdef RTE_RING_ENQDEQ_CALLBACKS
> > > > + struct rte_ring_callback *cb = NULL;
> > > > +
> > > > + TAILQ_FOREACH(cb, &(r->enq_cbs), next) {
> > > Need to take the TAILQ lock before this. For ex: what happens if a
> > > un-register is called concurrently?
> > Let me check this, using rx|tx callback as reference.
> >
> > > Also, traversing a linked list for every enqueue call would be too
> > > costly. May be, understanding the use case will help.
> > Internal testing with SP-SC is 0.1% (with extra cost of user
> > function). But I will try to explore other alternatives too.
> >
> > Snipped
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH] doc: announce ABI change for RSS hash funtion
@ 2019-07-04 4:43 4% simei
2019-08-06 11:34 4% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: simei @ 2019-07-04 4:43 UTC (permalink / raw)
To: qi.z.zhang, jingjing.wu, beilei.xing, qiming.yang; +Cc: dev, simei.su
From: Simei Su <simei.su@intel.com>
Add new field SYMMETRIC_TOEPLITZ in rte_eth_hash_function. This
can support symmetric hash function by rte_flow RSS action.
Signed-off-by: Simei Su <simei.su@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 2 ++
1 file changed, 2 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index e2721fa..540285b 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -99,3 +99,5 @@ Deprecation Notices
to set new power environment if power environment was already initialized.
In this case the function will return -1 unless the environment is unset first
(using ``rte_power_unset_env``). Other function usage scenarios will not change.
+
+* ethdev: New member in ``rte_eth_hash_funtion`` to support symmetric hash funtion.
--
1.8.3.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH] doc: announce ABI change for rte flow RSS action
@ 2019-07-04 4:46 4% simei
2019-08-06 11:31 4% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: simei @ 2019-07-04 4:46 UTC (permalink / raw)
To: qi.z.zhang, jingjing.wu, beilei.xing, qiming.yang; +Cc: dev, simei.su
From: Simei Su <simei.su@intel.com>
Add new structure inputset in rte_flow_action_rss. This
can support input set configuration by rte_flow RSS action.
Signed-off-by: Simei Su <simei.su@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 3 +++
1 file changed, 3 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index e2721fa..5cd360c 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -99,3 +99,6 @@ Deprecation Notices
to set new power environment if power environment was already initialized.
In this case the function will return -1 unless the environment is unset first
(using ``rte_power_unset_env``). Other function usage scenarios will not change.
+
+* ethdev: New member in ``rte_flow_action_rss`` to support input set change
+ by rte_flow RSS action. It ignores spec and focuses on mask only.
--
1.8.3.1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v3 00/14] Make shared memory config non-public
@ 2019-07-04 8:09 3% ` David Marchand
2019-07-04 19:52 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2019-07-04 8:09 UTC (permalink / raw)
To: Anatoly Burakov; +Cc: dev, Thomas Monjalon, Stephen Hemminger
On Wed, Jul 3, 2019 at 11:38 AM David Marchand <david.marchand@redhat.com>
wrote:
> Hello Anatoly,
>
> On Thu, Jun 27, 2019 at 1:39 PM Anatoly Burakov <anatoly.burakov@intel.com>
> wrote:
>
>> This patchset removes the shared memory config from public
>> API, and replaces all usages of said config with new API
>> calls.
>>
>> A lot of the patchset is a search-and-replace job and should
>> be pretty easy to review. The rest are pretty trivial EAL
>> changes.
>>
>> This patchset depends on FreeBSD fixes patchset:
>>
>> http://patches.dpdk.org/project/dpdk/list/?series=5196
>>
>> v3:
>> - Rebase on top of latest master
>>
>> v2:
>> - Collapsed all changes into fewer patches
>> - Addressed review comments
>> - Created a new file to store the code
>> - Changed namespace to "rte_mcfg_"
>> - Added some unification around config init
>> - Removed "packed" attribute from mem config
>> - Removed unnecessary inlining
>> - Added a check to explicitly forbid running multiprocess
>> applications that differ in their DPDK versions
>>
>
>
> For the parts I already had a look at, I still think the changes are in
> too many patches.
> A lot of this is just search/replace we can have it with the patch that
> introduces it.
> - patch 1, 2 and 3 could be squashed as a single one (plus removing the
> unused macro from patch 8)
> - idem with patch 4 and 5
> - idem with patch 6 and 7 (plus removing the unused macro from patch 8)
>
>
Overall, I am ok with the changes, once the patch 13 is fixed.
You can add my ack on the n+1 patchset.
I just want to state two approaches to merge these changes:
- the first one would be to split this series in two
- take the first part of this series now, but mark the new API
"experimental"
- postpone the merge to 19.11 of the second part, which starts at the
hiding rte_mem_config patch
- the second one is taking these changes in one go
The second one is the quicker and the more straightforward but it leaves
the risk of having missed something and we must break the ABI again in
19.11.
The risk is quite low, given the changes.
Thomas, comments?
--
David Marchand
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC] ethdev: support symmetric hash function
@ 2019-07-04 9:06 3% ` Adrien Mazarguil
2019-07-04 12:48 3% ` Zhang, Qi Z
0 siblings, 1 reply; 200+ results
From: Adrien Mazarguil @ 2019-07-04 9:06 UTC (permalink / raw)
To: simei
Cc: qi.z.zhang, jingjing.wu, beilei.xing, qiming.yang, dev,
Shahaf Shuler, Yongseok Koh
On Thu, Jul 04, 2019 at 12:46:07PM +0800, simei wrote:
> From: Simei Su <simei.su@intel.com>
>
> Currently, there are DEFAULT,TOEPLITZ and SIMPLE_XOR hash funtion.
> To support symmetric hash by rte_flow RSS action, this RFC introduces
> SYMMETRIC_TOEPLITZ to rte_eth_hash_function.
>
> Signed-off-by: Simei Su <simei.su@intel.com>
> ---
> lib/librte_ethdev/rte_flow.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> index f3a8fb1..e3c4fe5 100644
> --- a/lib/librte_ethdev/rte_flow.h
> +++ b/lib/librte_ethdev/rte_flow.h
> @@ -1744,6 +1744,7 @@ enum rte_eth_hash_function {
> RTE_ETH_HASH_FUNCTION_DEFAULT = 0,
> RTE_ETH_HASH_FUNCTION_TOEPLITZ, /**< Toeplitz */
> RTE_ETH_HASH_FUNCTION_SIMPLE_XOR, /**< Simple XOR */
> + RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ, /**< Symmetric TOEPLITZ */
"Symmetric TOEPLITZ" => "Symmetric Toeplitz."
> RTE_ETH_HASH_FUNCTION_MAX,
> };
Other than that, no problem with this change (no ABI impact, no need for
deprecation). Please update testpmd a part of the same patch:
- Wherever "toeplitz" is mentioned in test-pmd/cmdline.c.
- Ditto for flow command, i.e. add ACTION_RSS_FUNC_SYMMETRIC_TOEPLITZ to
test-pmd/cmdline_flow.c.
- Update "set_hash_global_config" documentation section in
testpmd_app_ug/testpmd_funcs.rst.
Note to Shahaf/Yongseok, since mlx5 supports both but defaults to symmetric
Toeplitz on vanilla Linux and standard Toeplitz when using OFED, how about
using this chance to make the algorithm configurable as well?
Thanks.
--
Adrien Mazarguil
6WIND
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC] ethdev: support input set change by RSS action
@ 2019-07-04 9:07 3% ` Adrien Mazarguil
2019-07-04 13:55 0% ` Zhang, Qi Z
0 siblings, 1 reply; 200+ results
From: Adrien Mazarguil @ 2019-07-04 9:07 UTC (permalink / raw)
To: simei; +Cc: qi.z.zhang, jingjing.wu, beilei.xing, qiming.yang, dev
On Thu, Jul 04, 2019 at 12:47:09PM +0800, simei wrote:
> From: Simei Su <simei.su@intel.com>
>
> This RFC introduces inputset structure to rte_flow_action_rss to
> support input set specific configuration by rte_flow RSS action.
>
> We can give an testpmd command line example to make it more clear.
>
> For example, below flow selects the l4 port as inputset for any
> eth/ipv4/tcp packet: #flow create 0 ingress pattern eth / ipv4 / tcp /
> end actions rss inputset tcp src mask 0xffff dst mask 0xffff /end
>
> Signed-off-by: Simei Su <simei.su@intel.com>
> ---
> lib/librte_ethdev/rte_flow.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h
> index f3a8fb1..2a455b6 100644
> --- a/lib/librte_ethdev/rte_flow.h
> +++ b/lib/librte_ethdev/rte_flow.h
> @@ -1796,6 +1796,9 @@ struct rte_flow_action_rss {
> uint32_t queue_num; /**< Number of entries in @p queue. */
> const uint8_t *key; /**< Hash key. */
> const uint16_t *queue; /**< Queue indices to use. */
> + struct rte_flow_item *inputset; /** Provide more specific inputset configuration.
> + * ignore spec, only mask.
> + */
> };
>
> /**
To make sure I understand, is this kind of a more flexible version of
rte_flow_action_rss.types?
For instance while specifying .types = ETH_RSS_IPV4 normally covers both
source and destination addresses, does this approach enable users to perform
RSS on source IP only? In which case, what value does the Toeplitz algorithm
assume for the destination, 0x0? (note: must be documented)
My opinion is that, unless you know of a hardware which can perform RSS on
random bytes of a packet, this approach is a bit overkill at this point.
How about simply adding the needed ETH_RSS_* definitions
(e.g. ETH_RSS_IPV4_(SRC|DST))? How many are needed?
There are currently 20 used bits and struct rte_flow_action_rss.types is
64-bit wide. I'm sure we can manage something without harming the ABI. Even
better, you wouldn't need a deprecation notice.
If you use the suggested approach, please update testpmd and its
documentation as part of the same patch, thanks.
--
Adrien Mazarguil
6WIND
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2 4/4] rawdev: pass device id as parameter to selftest
@ 2019-07-04 9:33 0% ` Shreyansh Jain
0 siblings, 0 replies; 200+ results
From: Shreyansh Jain @ 2019-07-04 9:33 UTC (permalink / raw)
To: Bruce Richardson, dev
> -----Original Message-----
> From: Bruce Richardson <bruce.richardson@intel.com>
> Sent: Friday, June 21, 2019 9:27 PM
> To: dev@dpdk.org
> Cc: Bruce Richardson <bruce.richardson@intel.com>; Shreyansh Jain
> <shreyansh.jain@nxp.com>
> Subject: [PATCH v2 4/4] rawdev: pass device id as parameter to selftest
>
> When running self-tests, the driver needs to know the device on which to
> run the tests, so we need to take the device ID as parameter. Only the
> skeleton driver is providing this selftest capability right now, so we
> can
> easily update it for this change.
>
> Cc: shreyansh.jain@nxp.com
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
>
> Since this change only affects the internals of the drivers, it's not an
> ABI or API change
>
> ---
Sorry for delay in responding to this. If not already merged:
Acked-by: Shreyansh Jain <shreyansh.jain@nxp.com>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH] Changes to ABI Policy introducing major ABI versions
@ 2019-07-04 12:26 11% Ray Kinsella
2019-07-04 12:26 31% ` [dpdk-dev] [PATCH] doc: " Ray Kinsella
0 siblings, 1 reply; 200+ results
From: Ray Kinsella @ 2019-07-04 12:26 UTC (permalink / raw)
To: dev; +Cc: mdr
TL;DR Abbreviation:
A major ABI version that all DPDK releases during a two year period
support. ABI versioning is managed at a project-level, in place of library-level
management. ABI changes to add new features are permitted, as long as ABI
compatibility with the major ABI version is maintained.
Detail:
This patch introduces a two year major ABI version, aligned with the LTS release
and supported by all subsequent releases within that two year period, including
the subsequent LTS release.
ABI changes that preserve ABI compatibility with the major ABI version are
permitted in subsequent releases. ABI changes, follow similar approval rules as
before with the additional gate of now requiring technical board approval. The
merging and release of ABI breaking changes would now be pushed to the
declaration of the next major ABI version.
This change encourages developers to maintain ABI compatibility with the
major ABI version, by promoting a permissive culture around those changes
that preserve ABI compatibility. This approach aligns DPDK with those projects
that declare major ABI versions (e.g. version 2.x, 3.x) and support those
versions for some period, typically two years or more.
To provide an example of how this might work in practice:
* DPDK v20 is declared as the supported ABI version for two years, aligned with
the DPDK v19.11 (LTS) release. All library sonames are updated to reflect the
new ABI version, e.g. librte_eal.so.20, librte_acl.so.20...
* DPDK v20.02 .. v21.08 releases are ABI compatible with the DPDK v20 ABI. ABI
changes are permitted from DPDK v20.02 onwards, with the condition that ABI
compatibility with DPDK v20 is preserved.
* DPDK v21 is declared as the new supported ABI version for two years, aligned
with the DPDK v21.11 (LTS) release. The DPDK v20 ABI is now depreciated,
library sonames are updated to v21 and ABI compatibility breaking changes may
be introduced.
Ray Kinsella (1):
doc: Changes to ABI Policy introducing major ABI versions
doc/guides/contributing/stable.rst | 10 +-
doc/guides/contributing/versioning.rst | 462 ++++++++++++++++++++++-----------
2 files changed, 314 insertions(+), 158 deletions(-)
--
2.7.4
^ permalink raw reply [relevance 11%]
* [dpdk-dev] [PATCH] doc: Changes to ABI Policy introducing major ABI versions
2019-07-04 12:26 11% [dpdk-dev] [PATCH] Changes to ABI Policy introducing major ABI versions Ray Kinsella
@ 2019-07-04 12:26 31% ` Ray Kinsella
2019-07-30 10:34 10% ` Mcnamara, John
0 siblings, 1 reply; 200+ results
From: Ray Kinsella @ 2019-07-04 12:26 UTC (permalink / raw)
To: dev; +Cc: mdr
This policy change introduces major ABI versions, these are
declared every two years, typically aligned with the LTS release
and are supported by subsequent releases for the next two years.
This change is intended to improve ABI stabilty for those projects
consuming DPDK.
Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
---
doc/guides/contributing/stable.rst | 10 +-
doc/guides/contributing/versioning.rst | 462 ++++++++++++++++++++++-----------
2 files changed, 314 insertions(+), 158 deletions(-)
diff --git a/doc/guides/contributing/stable.rst b/doc/guides/contributing/stable.rst
index 6a5eee9..0a678be 100644
--- a/doc/guides/contributing/stable.rst
+++ b/doc/guides/contributing/stable.rst
@@ -53,6 +53,9 @@ year's November (X.11) release will be maintained as an LTS for 2 years.
After the X.11 release, an LTS branch will be created for it at
http://git.dpdk.org/dpdk-stable where bugfixes will be backported to.
+A LTS release may align with the declaration of a new major ABI version,
+please read the `DPDK ABI/API policy`_ for more information.
+
It is anticipated that there will be at least 4 releases per year of the LTS
or approximately 1 every 3 months. However, the cadence can be shorter or
longer depending on the number and criticality of the backported
@@ -119,10 +122,3 @@ A Stable Release will be released by:
list.
Stable releases are available on the `dpdk.org download page <http://core.dpdk.org/download/>`_.
-
-
-ABI
----
-
-The Stable Release should not be seen as a way of breaking or circumventing
-the DPDK ABI policy.
diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
index 3ab2c43..b7b5514 100644
--- a/doc/guides/contributing/versioning.rst
+++ b/doc/guides/contributing/versioning.rst
@@ -12,20 +12,23 @@ This document details some methods for handling ABI management in the DPDK.
General Guidelines
------------------
-#. Whenever possible, ABI should be preserved
-#. 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 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
-~~~~~~~~~~~~~~
+#. Major ABI versions are declared every **two years** and are then supported
+ for two years, typically aligned with the LTS release.
+#. ABI versioning is managed at a project level in DPDK, with the supported ABI
+ version reflected in all library's soname.
+#. The ABI should be preserved and not changed lightly. The ABI may be changed
+ following the outlined deprecation process.
+#. The addition of symbols is generally not problematic. The modification of
+ symbols should be managed with ABI versioning.
+#. The removal of symbols is considered an ABI breakage, once approved these
+ will form part of the next ABI version.
+#. Libraries or APIs marked as ``experimental`` are not considered part of the
+ major ABI version and may change without constraint.
+#. 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
@@ -37,30 +40,55 @@ 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.
+What is a library's soname?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+System libraries usually adopt the familiar major and minor version naming
+convention, where major versions (e.g. ``librte_a 1.x, 2.x``) are presumed to be
+ABI incompatible with each other and minor versions (e.g. ``librte_a 2.11,
+2.12``) are presumed to be ABI compatible. A library's `soname
+<https://en.wikipedia.org/wiki/Soname>`_. is typically used to provide backward
+compatibility information about a given library, describing the lowest common
+denominator ABI supported by the library. The soname is typically comprised of
+the library's name and major version e.g. ``librte_a.so.20``.
+
+During an application's build process, a library's soname is noted as a runtime
+dependency of the application. This information is then used by the `dynamic
+linker <https://en.wikipedia.org/wiki/Dynamic_linker>`_ when resolving the
+applications dependencies at runtime, to load a library supporting the correct
+ABI version. The library loaded at runtime therefore, may be a minor revision
+supporting the same major abi version (e.g. ``librte_a 20.12``), as the library
+used to link the application (e.g ``librte_a 20.0``).
-ABI/API Deprecation
+The DPDK ABI policy
-------------------
-The DPDK ABI policy
-~~~~~~~~~~~~~~~~~~~
+A major ABI version is declared every two years, aligned with that years LTS
+release, e.g. v19.11 . This ABI version is then supported for two years by all
+subsequent releases within that time period, typically including the next LTS
+release, e.g. v20.11.
+
+At the declaration of a major ABI version, major version numbers encoded in
+libraries soname's are bumped to indicate the new version, with minor version
+reset to 0. An example would be ``librte_a.so.20.5`` would become
+``librte_a.so.21.0``
-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.
+The ABI may change then multiple times, without warning, between the last major
+ABI version increment and the HEAD label of the git tree, with the condition
+that ABI compatibility with the major ABI version is preserved and therefore
+soname's do not change.
-ABI versions, once released, are available until such time as their
-deprecation has been noted in the Release Notes for at least one major release
-cycle. For example consider the case where the ABI for DPDK 2.0 has been
-shipped and then a decision is made to modify it during the development of
-DPDK 2.1. The decision will be recorded in the Release Notes for the DPDK 2.1
-release and the modification will be made available in the DPDK 2.2 release.
+ABI versions, are supported by each release until such time as the next major
+ABI version is declared. At that time, the deprecation of the previous major ABI
+version will be noted in the Release Notes with guidance on individual symbol
+depreciation and upgrade notes provided.
-ABI versions may be deprecated in whole or in part as needed by a given
-update.
+ABI Changes
+~~~~~~~~~~~
-Some ABI changes may be too significant to reasonably maintain multiple
-versions. In those cases ABI's may be updated without backward compatibility
-being provided. The requirements for doing so are:
+The ABI may still change after the declaration of a major ABI version, that is
+new APIs may be still added or existing APIs may be modified. The requirements
+for doing so are:
#. At least 3 acknowledgments of the need to do so must be made on the
dpdk.org mailing list.
@@ -69,81 +97,156 @@ being provided. The requirements for doing so are:
no maintainer is available for the component, the tree/sub-tree maintainer
for that component must acknowledge the ABI change instead.
+ - The acknowledgment of a member of the technical board, as a delegate of the
+ `technical board <https://core.dpdk.org/techboard/>`_ acknowledging the
+ need for the ABI change, is also mandatory.
+
- It is also recommended that acknowledgments from different "areas of
interest" be sought for each deprecation, for example: from NIC vendors,
CPU vendors, end-users, etc.
-#. 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.
+#. Backward compatibly with the major ABI version must be maintained through
+ `ABI versioning`_, with forward-only compatibility offered for any ABI
+ changes that are indicated to be part of the next ABI version.
+
+ - In situations where backward compatibility is not possible, read the
+ section `ABI Breakages`_.
+
+ - No backward or forward compatibility is offered for API changes marked as
+ ``experimental``, as described in the section `Experimental APIs`_.
+
+#. If a newly proposed API functionally replaces an existing one, when the new
+ API becomes non-experimental then the old one is marked with
+ ``__rte_deprecated``.
+
+ - The depreciated API should follow the notification process to be removed,
+ see `Examples of Deprecation Notices`_;
+
+ - At the declaration of the next major ABI version, those ABI changes then
+ become a formal part of the new ABI and the requirement to preserve ABI
+ compatibility with the last major ABI version is then dropped.
-#. A full deprecation cycle, as explained above, must be made to offer
- downstream consumers sufficient warning of the change.
+.. note::
-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
-be made to preserve the ABI whenever possible. The ABI should only be changed
-for significant reasons, such as performance enhancements. ABI breakage due to
-changes such as reorganizing public structure fields for aesthetic or
-readability purposes should be avoided.
+ 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
+ be made to preserve the ABI whenever possible. The ABI should only be changed
+ for significant reasons, such as performance enhancements. ABI breakage due
+ to changes such as reorganizing public structure fields for aesthetic or
+ readability purposes should be avoided.
+
+.. note::
+
+ Note that forward-only compatibility is offered for those changes made
+ between major ABI versions. The soname however only describes compatibility
+ with the last major ABI version and until the next major ABI version is
+ declared, these changes therefore cannot be resolved as a runtime dependency
+ through the soname. Therefore any application wishing to make use of these
+ ABI changes can only ensure that it's runtime dependencies are met through
+ Operating System package versioning.
.. note::
Updates to the minimum hardware requirements, which drop support for hardware
which was previously supported, should be treated as an ABI change, and
- follow the relevant deprecation policy procedures as above: 3 acks and
- announcement at least one release in advance.
+ follow the relevant deprecation policy procedures as above: 3 acks, technical
+ board approval and announcement at least one release in advance.
+
+
+ABI Breakages
+^^^^^^^^^^^^^
+
+For those ABI changes that may be too significant to reasonably maintain
+multiple versions. In those cases, ABIs may be updated without backward
+compatibility being provided.
+
+The additional requirements to approve an ABI breakage, on top of those
+described in the section `ABI Changes`_ are:
+
+#. ABI breaking 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
+ at the declaration of the next major ABI version.
+
+#. Once approved and after the depreciation notice has been observed these
+ changes will form part of the next declared major ABI version.
+
+Examples of ABI Changes
+^^^^^^^^^^^^^^^^^^^^^^^
+
+The following are examples of allowable ABI changes occurring between
+declarations of major ABI versions.
+
+* DPDK 20.0 release defines the function ``rte_foo()``, and ``rte_foo()``
+ is part of the major ABI version DPDK 20.0.
+
+* DPDK 20.2 release defines a new function ``rte_foo(uint8_t bar)``, and
+ this is not a problem as long as the symbol ``rte_foo@DPDK20.0`` is
+ preserved through `ABI versioning`_.
+
+ - The new function may be marked with the ``__rte_experimental`` tag for a
+ number of releases, as described in the section `Experimental APIs`_;
+
+ - Once ``rte_foo(uint8_t bar)`` becomes non-experimental ``rte_foo()`` is then
+ declared as ``__rte_depreciated``, with an associated deprecation notice
+ provided.
+
+* DPDK 20.1 is not re-released to include ``rte_foo(uint8_t bar)``, the new
+ version of ``rte_foo`` only exists from DPDK 20.2 onwards (forward-only
+ compatibility).
+
+* DPDK 20.1 release defines the experimental function ``__rte_experimental
+ rte_baz()``. This function may or may not exist in DPDK 20.2 and DPDK 21.0
+ releases.
+
+* An application ``dPacket`` wishes to use ``rte_foo(uint8_t bar)``, before the
+ declaration of the DPDK 21.0 major API version. The application can only
+ ensure it's runtime dependencies are met by specifying ``DPDK (>= 20.2)`` as
+ an explicit package dependency, as the soname only may only indicate the
+ supporting major ABI version.
+
+* At DPDK 21.0 release the function ``rte_foo(uint8_t bar)`` becomes
+ formally part of the major ABI version DPDK 21.0 and ``rte_foo()`` may be
+ removed.
+
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,
+* The Macro ``#RTE_FOO`` is deprecated and will be removed with version 21.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
+ in version 20.2. Backwards compatibility will be maintained for this function
+ until the release of DPDK version 21.0
-* The members of ``struct rte_foo`` have been reorganized in release 2.0 for
+* The members of ``struct rte_foo`` have been reorganized in release 20.1 for
performance reasons. Existing binary applications will have backwards
- compatibility in release 2.0, while newly built binaries will need to
+ compatibility in release 20.1, 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
+ be removed in release 21.0, 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,
+ upcoming release 20.1 will not contain these changes, but release 21.0 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
+ these changes. Binaries using this library built prior to version 21.0 will
require updating and recompilation.
-New API replacing previous one
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-If a new API proposed functionally replaces an existing one, when the new API
-becomes non-experimental then the old one is marked with ``__rte_deprecated``.
-Deprecated APIs are removed completely just after the next LTS.
-
-Reminder that old API should follow deprecation process to be removed.
-
-
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
-immediately after their introduction, as users begin to take advantage of
-those new APIs and start finding issues with them, new DPDK APIs will be
-automatically marked as ``experimental`` to allow for a period of stabilization
-before they become part of a tracked ABI.
+APIs marked as ``experimental`` are not considered part of an ABI version and
+may change without warning at any time. Since changes to APIs are most likely
+immediately after their introduction, as users begin to take advantage of those
+new APIs and start finding issues with them, new DPDK APIs will be automatically
+marked as ``experimental`` to allow for a period of stabilization before they
+become part of a tracked ABI version.
Note that marking an API as experimental is a multi step process.
To mark an API as experimental, the symbols which are desired to be exported
@@ -167,34 +270,97 @@ one release. Thereafter, normal process of posting patch for review to mailing
list can be followed.
-Library versioning
-------------------
+ABI Versioning
+--------------
-Downstreams might want to provide different DPDK releases at the same time to
-support multiple consumers of DPDK linked against older and newer sonames.
+Major ABI versions
+~~~~~~~~~~~~~~~~~~
-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.
+An ABI version change to a given library, especially in core libraries such as
+``librte_mbuf``, may cause an implicit ripple effect on the ABI of it's
+dependent libraries, causing ABI breakages. There may however be no explicit
+reason to bump a dependent libraries ABI version, as there may have been no
+obvious change to the dependent library's API, even though the library's ABI
+compatibility will have been broken.
-Think of LibA that got an ABI bump and LibB that did not get an ABI bump but is
-depending on LibA.
+This interdependence of libraries, means that ABI versioning of libraries is
+more manageable at a project level, with all project libraries sharing a
+**single ABI version**. In addition, the need to maintain a stable ABI for some
+number of releases as described in the section `The DPDK ABI policy`_, means
+that ABI version increments need to carefully planned and managed at a project
+level.
-.. note::
+Major ABI versions are therefore declared every two years and are then supported
+for two years, typically aligned with the LTS release and are shared across all
+libraries. This means that a single project level ABI version, reflected in all
+individual library's soname, filename and version maps persists for two years.
- Application
- \-> LibA.old
- \-> LibB.new -> LibA.new
+.. code-block:: none
-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>``.
+ $ head ./lib/librte_acl/rte_acl_version.map
+ DPDK_20.0 {
+ global:
+ ...
+ $ head ./lib/librte_eal/rte_eal_version.map
+ DPDK_20.0 {
+ global:
+ ...
+
+When an ABI change is made between major ABI versions to a given library, a new
+section is added to that library's version map describing the impending new ABI
+version, as described in the section `Examples of ABI Macro use`_. The
+libraries soname and filename however do not change, e.g. ``libacl.so.20``, as
+ABI compatibility with the last major ABI version continues to be preserved for
+that library.
+
+.. code-block:: none
+
+ $ head ./lib/librte_acl/rte_acl_version.map
+ DPDK_20.0 {
+ global:
+ ...
+
+ DPDK_21.0 {
+ global:
+
+ } DPDK_20.0;
+ ...
+
+ $ head ./lib/librte_eal/rte_eal_version.map
+ DPDK_20.0 {
+ global:
+ ...
+
+
+However when a new ABI version is declared, for example DPDK 21.0, old
+depreciated functions may be safely removed at this point and the entire old
+major ABI version removed, see section `Deprecating an entire ABI version`_ on
+how this may be done.
+
+.. code-block:: none
+
+ $ head ./lib/librte_acl/rte_acl_version.map
+ DPDK_21.0 {
+ global:
+ ...
+
+ $ head -n 3 ./lib/librte_eal/rte_eal_version.map
+ DPDK_21.0 {
+ global:
+ ...
+
+At the same time, the major ABI version is changed atomically across all
+libraries by incrementing the major version in individual library's soname, e.g.
+``libacl.so.21``. This is done by bumping the LIBABIVER number in the libraries
+Makefile to indicate to dynamic linking applications that this is a later, and
+possibly incompatible library version:
+
+.. code-block:: c
+
+ -LIBABIVER := 20
+ +LIBABIVER := 21
-ABI versioning
---------------
Versioning Macros
~~~~~~~~~~~~~~~~~
@@ -202,7 +368,7 @@ 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
arguments. Occasionally that function may need to change to accommodate new
-functionality or behavior. When that occurs, it is desirable to allow for
+functionality or behavior. When that occurs, it is may be required to allow for
backward compatibility for a time with older binaries that are dynamically
linked to the DPDK.
@@ -270,16 +436,16 @@ maintain previous ABI versions that are accessible only to previously compiled
binaries
The addition of a parameter to the function is ABI breaking as the function is
-public, and existing application may use it in its current form. However, the
+public, and existing application may use it in its current form. However, the
compatibility macros in DPDK allow a developer to use symbol versioning so that
multiple functions can be mapped to the same public symbol based on when an
-application was linked to it. To see how this is done, we start with the
-requisite libraries version map file. Initially the version map file for the
-acl library looks like this
+application was linked to it. To see how this is done, we start with the
+requisite libraries version map file. Initially the version map file for the acl
+library looks like this
.. code-block:: none
- DPDK_2.0 {
+ DPDK_20.0 {
global:
rte_acl_add_rules;
@@ -305,7 +471,7 @@ This file needs to be modified as follows
.. code-block:: none
- DPDK_2.0 {
+ DPDK_20.0 {
global:
rte_acl_add_rules;
@@ -327,16 +493,16 @@ This file needs to be modified as follows
local: *;
};
- DPDK_2.1 {
+ DPDK_21.0 {
global:
rte_acl_create;
- } DPDK_2.0;
+ } DPDK_20.0;
The addition of the new block tells the linker that a new version node is
-available (DPDK_2.1), which contains the symbol rte_acl_create, and inherits the
-symbols from the DPDK_2.0 node. This list is directly translated into a list of
-exported symbols when DPDK is compiled as a shared library
+available (DPDK_21.0), which contains the symbol rte_acl_create, and inherits
+the symbols from the DPDK_20.0 node. This list is directly translated into a
+list of exported symbols when DPDK is compiled as a shared library
Next, we need to specify in the code which function map to the rte_acl_create
symbol at which versions. First, at the site of the initial symbol definition,
@@ -355,22 +521,22 @@ with the public symbol name
Note that the base name of the symbol was kept intact, as this is conducive to
the macros used for versioning symbols. That is our next step, mapping this new
-symbol name to the initial symbol name at version node 2.0. Immediately after
+symbol name to the initial symbol name at version node 20.0. Immediately after
the function, we add this line of code
.. code-block:: c
- VERSION_SYMBOL(rte_acl_create, _v20, 2.0);
+ VERSION_SYMBOL(rte_acl_create, _v20, 20.0);
Remembering to also add the rte_compat.h header to the requisite c file where
-these changes are being made. The above macro instructs the linker to create a
-new symbol ``rte_acl_create@DPDK_2.0``, which matches the symbol created in older
-builds, but now points to the above newly named function. We have now mapped
-the original rte_acl_create symbol to the original function (but with a new
-name)
+these changes are being made. The above macro instructs the linker to create a
+new symbol ``rte_acl_create@DPDK_20.0``, which matches the symbol created in
+older builds, but now points to the above newly named function. We have now
+mapped the original rte_acl_create symbol to the original function (but with a
+new name)
-Next, we need to create the 2.1 version of the symbol. We create a new function
-name, with a different suffix, and implement it appropriately
+Next, we need to create the 21.0 version of the symbol. We create a new function
+name, with a different suffix, and implement it appropriately
.. code-block:: c
@@ -384,12 +550,12 @@ name, with a different suffix, and implement it appropriately
return ctx;
}
-This code serves as our new API call. Its the same as our old call, but adds
-the new parameter in place. Next we need to map this function to the symbol
-``rte_acl_create@DPDK_2.1``. To do this, we modify the public prototype of the call
-in the header file, adding the macro there to inform all including applications,
-that on re-link, the default rte_acl_create symbol should point to this
-function. Note that we could do this by simply naming the function above
+This code serves as our new API call. Its the same as our old call, but adds the
+new parameter in place. Next we need to map this function to the symbol
+``rte_acl_create@DPDK_21.0``. To do this, we modify the public prototype of the
+call in the header file, adding the macro there to inform all including
+applications, that on re-link, the default rte_acl_create symbol should point to
+this function. Note that we could do this by simply naming the function above
rte_acl_create, and the linker would chose the most recent version tag to apply
in the version script, but we can also do this in the header file
@@ -397,11 +563,11 @@ in the version script, but we can also do this in the header file
struct rte_acl_ctx *
-rte_acl_create(const struct rte_acl_param *param);
- +rte_acl_create(const struct rte_acl_param *param, int debug);
- +BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 2.1);
+ +rte_acl_create_v21(const struct rte_acl_param *param, int debug);
+ +BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 21.0);
The BIND_DEFAULT_SYMBOL macro explicitly tells applications that include this
-header, to link to the rte_acl_create_v21 function and apply the DPDK_2.1
+header, to link to the rte_acl_create_v21 function and apply the DPDK_21.0
version node to it. This method is more explicit and flexible than just
re-implementing the exact symbol name, and allows for other features (such as
linking to the old symbol version by default, when the new ABI is to be opt-in
@@ -421,6 +587,7 @@ assumption is that the most recent version of the symbol is the one you want to
map. So, back in the C file where, immediately after ``rte_acl_create_v21`` is
defined, we add this
+
.. code-block:: c
struct rte_acl_ctx *
@@ -434,21 +601,22 @@ That tells the compiler that, when building a static library, any calls to the
symbol ``rte_acl_create`` should be linked to ``rte_acl_create_v21``
That's it, on the next shared library rebuild, there will be two versions of
-rte_acl_create, an old DPDK_2.0 version, used by previously built applications,
-and a new DPDK_2.1 version, used by future built applications.
+rte_acl_create, an old DPDK_20.0 version, used by previously built applications,
+and a new DPDK_21.0 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.
-After having gone through the ABI deprecation announcement process, removal is
-easy. Start by removing the symbol from the requisite version map file:
+Lets assume that you've done the above update, and in preparation for the next
+major ABI version you decide you would like to retire the old version of the
+function. After having gone through the ABI deprecation announcement process,
+removal is easy. Start by removing the symbol from the requisite version map
+file:
.. code-block:: none
- DPDK_2.0 {
+ DPDK_20.0 {
global:
rte_acl_add_rules;
@@ -470,10 +638,10 @@ easy. Start by removing the symbol from the requisite version map file:
local: *;
};
- DPDK_2.1 {
+ DPDK_21.0 {
global:
rte_acl_create;
- } DPDK_2.0;
+ } DPDK_20.0;
Next remove the corresponding versioned export.
@@ -484,34 +652,26 @@ Next remove the corresponding versioned export.
Note that the internal function definition could also be removed, but its used
-in our example by the newer version _v21, so we leave it in place. This is a
-coding style choice.
-
-Lastly, we need to bump the LIBABIVER number for this library in the Makefile to
-indicate to applications doing dynamic linking that this is a later, and
-possibly incompatible library version:
-
-.. code-block:: c
-
- -LIBABIVER := 1
- +LIBABIVER := 2
+in our example by the newer version _v21, so we leave it in place and declare it
+as static. This is a coding style choice.
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
-specifies an API, then removing part of it, typically makes it incomplete. In
-those cases it is better to remove the entire node
+While removing a symbol from an ABI may be useful, it is more practical to
+remove an entire version node at once, as is typically done at the declaration
+of a major ABI version. If a version node completely specifies an API, then
+removing part of it, typically makes it incomplete. In those cases it is better
+to remove the entire node.
To do this, start by modifying the version map file, such that all symbols from
-the node to be removed are merged into the next node in the map
+the node to be removed are merged into the next node in the map.
In the case of our map above, it would transform to look as follows
.. code-block:: none
- DPDK_2.1 {
+ DPDK_21.0 {
global:
rte_acl_add_rules;
@@ -539,8 +699,8 @@ symbols.
.. code-block:: c
- -BIND_DEFAULT_SYMBOL(rte_acl_create, _v20, 2.0);
- +BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 2.1);
+ -BIND_DEFAULT_SYMBOL(rte_acl_create, _v20, 20.0);
+ +BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 21.0);
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
--
2.7.4
^ permalink raw reply [relevance 31%]
* Re: [dpdk-dev] [RFC] ethdev: support symmetric hash function
2019-07-04 9:06 3% ` Adrien Mazarguil
@ 2019-07-04 12:48 3% ` Zhang, Qi Z
2019-07-04 13:19 3% ` Adrien Mazarguil
0 siblings, 1 reply; 200+ results
From: Zhang, Qi Z @ 2019-07-04 12:48 UTC (permalink / raw)
To: Adrien Mazarguil, Su, Simei
Cc: Wu, Jingjing, Xing, Beilei, Yang, Qiming, dev, Shahaf Shuler,
Yongseok Koh
> -----Original Message-----
> From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> Sent: Thursday, July 4, 2019 5:07 PM
> To: Su, Simei <simei.su@intel.com>
> Cc: Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>;
> Xing, Beilei <beilei.xing@intel.com>; Yang, Qiming <qiming.yang@intel.com>;
> dev@dpdk.org; Shahaf Shuler <shahafs@mellanox.com>; Yongseok Koh
> <yskoh@mellanox.com>
> Subject: Re: [dpdk-dev] [RFC] ethdev: support symmetric hash function
>
> On Thu, Jul 04, 2019 at 12:46:07PM +0800, simei wrote:
> > From: Simei Su <simei.su@intel.com>
> >
> > Currently, there are DEFAULT,TOEPLITZ and SIMPLE_XOR hash funtion.
> > To support symmetric hash by rte_flow RSS action, this RFC introduces
> > SYMMETRIC_TOEPLITZ to rte_eth_hash_function.
> >
> > Signed-off-by: Simei Su <simei.su@intel.com>
> > ---
> > lib/librte_ethdev/rte_flow.h | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/lib/librte_ethdev/rte_flow.h
> > b/lib/librte_ethdev/rte_flow.h index f3a8fb1..e3c4fe5 100644
> > --- a/lib/librte_ethdev/rte_flow.h
> > +++ b/lib/librte_ethdev/rte_flow.h
> > @@ -1744,6 +1744,7 @@ enum rte_eth_hash_function {
> > RTE_ETH_HASH_FUNCTION_DEFAULT = 0,
> > RTE_ETH_HASH_FUNCTION_TOEPLITZ, /**< Toeplitz */
> > RTE_ETH_HASH_FUNCTION_SIMPLE_XOR, /**< Simple XOR */
> > + RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ, /**< Symmetric
> TOEPLITZ */
>
> "Symmetric TOEPLITZ" => "Symmetric Toeplitz."
>
> > RTE_ETH_HASH_FUNCTION_MAX,
> > };
>
> Other than that, no problem with this change (no ABI impact, no need for
> deprecation). Please update testpmd a part of the same patch:
Is it still ABI break but just with little risk?
RTE_ETH_HASH_FUNCTION_MAX's value is changed anyway.
Should we just remove it, if no one use it?
Regards
Qi
>
> - Wherever "toeplitz" is mentioned in test-pmd/cmdline.c.
>
> - Ditto for flow command, i.e. add ACTION_RSS_FUNC_SYMMETRIC_TOEPLITZ
> to
> test-pmd/cmdline_flow.c.
>
> - Update "set_hash_global_config" documentation section in
> testpmd_app_ug/testpmd_funcs.rst.
>
> Note to Shahaf/Yongseok, since mlx5 supports both but defaults to symmetric
> Toeplitz on vanilla Linux and standard Toeplitz when using OFED, how about
> using this chance to make the algorithm configurable as well?
>
> Thanks.
>
> --
> Adrien Mazarguil
> 6WIND
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC] ethdev: support symmetric hash function
2019-07-04 12:48 3% ` Zhang, Qi Z
@ 2019-07-04 13:19 3% ` Adrien Mazarguil
0 siblings, 0 replies; 200+ results
From: Adrien Mazarguil @ 2019-07-04 13:19 UTC (permalink / raw)
To: Zhang, Qi Z
Cc: Su, Simei, Wu, Jingjing, Xing, Beilei, Yang, Qiming, dev,
Shahaf Shuler, Yongseok Koh
On Thu, Jul 04, 2019 at 12:48:25PM +0000, Zhang, Qi Z wrote:
>
>
> > -----Original Message-----
> > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> > Sent: Thursday, July 4, 2019 5:07 PM
> > To: Su, Simei <simei.su@intel.com>
> > Cc: Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>;
> > Xing, Beilei <beilei.xing@intel.com>; Yang, Qiming <qiming.yang@intel.com>;
> > dev@dpdk.org; Shahaf Shuler <shahafs@mellanox.com>; Yongseok Koh
> > <yskoh@mellanox.com>
> > Subject: Re: [dpdk-dev] [RFC] ethdev: support symmetric hash function
> >
> > On Thu, Jul 04, 2019 at 12:46:07PM +0800, simei wrote:
> > > From: Simei Su <simei.su@intel.com>
> > >
> > > Currently, there are DEFAULT,TOEPLITZ and SIMPLE_XOR hash funtion.
> > > To support symmetric hash by rte_flow RSS action, this RFC introduces
> > > SYMMETRIC_TOEPLITZ to rte_eth_hash_function.
> > >
> > > Signed-off-by: Simei Su <simei.su@intel.com>
> > > ---
> > > lib/librte_ethdev/rte_flow.h | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/lib/librte_ethdev/rte_flow.h
> > > b/lib/librte_ethdev/rte_flow.h index f3a8fb1..e3c4fe5 100644
> > > --- a/lib/librte_ethdev/rte_flow.h
> > > +++ b/lib/librte_ethdev/rte_flow.h
> > > @@ -1744,6 +1744,7 @@ enum rte_eth_hash_function {
> > > RTE_ETH_HASH_FUNCTION_DEFAULT = 0,
> > > RTE_ETH_HASH_FUNCTION_TOEPLITZ, /**< Toeplitz */
> > > RTE_ETH_HASH_FUNCTION_SIMPLE_XOR, /**< Simple XOR */
> > > + RTE_ETH_HASH_FUNCTION_SYMMETRIC_TOEPLITZ, /**< Symmetric
> > TOEPLITZ */
> >
> > "Symmetric TOEPLITZ" => "Symmetric Toeplitz."
> >
> > > RTE_ETH_HASH_FUNCTION_MAX,
> > > };
> >
> > Other than that, no problem with this change (no ABI impact, no need for
> > deprecation). Please update testpmd a part of the same patch:
>
> Is it still ABI break but just with little risk?
> RTE_ETH_HASH_FUNCTION_MAX's value is changed anyway.
> Should we just remove it, if no one use it?
Indeed, it will update RTE_ETH_HASH_FUNCTION_MAX so you're technically
right, and the fact it's unused in DPDK is doesn't mean applications are not
using it for something.
However for this specific case, the intent behind RTE_ETH_HASH_FUNCTION_MAX
is clearly to give out the number of enum entries, applications are not
supposed to use it for anything other than determining if an arbitrary
integer value corresponds to a valid hash function.
And this is the reason we could say it's OK ABI-wise to increase it (not
ideal but acceptable): a binary application has a fixed idea of
RTE_ETH_HASH_FUNCTION_MAX, it doesn't know the entries you're about to add
yet. To such an application, those will exceed RTE_ETH_HASH_FUNCTION_MAX and
should be rejected accordingly.
A more conservative approach would be to mark RTE_ETH_HASH_FUNCTION_MAX as
deprecated (in a separate patch) and schedule it for removal while adding
new entries after it. Its position in the enum could be recycled once
removed.
If you want to remove RTE_ETH_HASH_FUNCTION_MAX directly, do it in a
separate RFC/patch as it will otherwise block the rest of your submission
for something like 2 releases after deprecation.
It's up to you. I'm fine with any of these approaches.
--
Adrien Mazarguil
6WIND
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC] ethdev: support input set change by RSS action
2019-07-04 9:07 3% ` Adrien Mazarguil
@ 2019-07-04 13:55 0% ` Zhang, Qi Z
2019-07-04 14:08 3% ` Adrien Mazarguil
0 siblings, 1 reply; 200+ results
From: Zhang, Qi Z @ 2019-07-04 13:55 UTC (permalink / raw)
To: Adrien Mazarguil, Su, Simei; +Cc: Wu, Jingjing, Xing, Beilei, Yang, Qiming, dev
> -----Original Message-----
> From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> Sent: Thursday, July 4, 2019 5:07 PM
> To: Su, Simei <simei.su@intel.com>
> Cc: Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>;
> Xing, Beilei <beilei.xing@intel.com>; Yang, Qiming <qiming.yang@intel.com>;
> dev@dpdk.org
> Subject: Re: [dpdk-dev] [RFC] ethdev: support input set change by RSS action
>
> On Thu, Jul 04, 2019 at 12:47:09PM +0800, simei wrote:
> > From: Simei Su <simei.su@intel.com>
> >
> > This RFC introduces inputset structure to rte_flow_action_rss to
> > support input set specific configuration by rte_flow RSS action.
> >
> > We can give an testpmd command line example to make it more clear.
> >
> > For example, below flow selects the l4 port as inputset for any
> > eth/ipv4/tcp packet: #flow create 0 ingress pattern eth / ipv4 / tcp /
> > end actions rss inputset tcp src mask 0xffff dst mask 0xffff /end
> >
> > Signed-off-by: Simei Su <simei.su@intel.com>
> > ---
> > lib/librte_ethdev/rte_flow.h | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/lib/librte_ethdev/rte_flow.h
> > b/lib/librte_ethdev/rte_flow.h index f3a8fb1..2a455b6 100644
> > --- a/lib/librte_ethdev/rte_flow.h
> > +++ b/lib/librte_ethdev/rte_flow.h
> > @@ -1796,6 +1796,9 @@ struct rte_flow_action_rss {
> > uint32_t queue_num; /**< Number of entries in @p queue. */
> > const uint8_t *key; /**< Hash key. */
> > const uint16_t *queue; /**< Queue indices to use. */
> > + struct rte_flow_item *inputset; /** Provide more specific inputset
> configuration.
> > + * ignore spec, only mask.
> > + */
> > };
> >
> > /**
>
> To make sure I understand, is this kind of a more flexible version of
> rte_flow_action_rss.types?
Yes
>
> For instance while specifying .types = ETH_RSS_IPV4 normally covers both
> source and destination addresses, does this approach enable users to perform
> RSS on source IP only?
Yes, .it is the case to select any subset of 5 tuples or even tunnel header's id for hash
> In which case, what value does the Toeplitz algorithm
> assume for the destination, 0x0? (note: must be documented)
My understanding is src/dst pair is only required for a symmetric case
But for Toeplitz, it is just a hash function, it process a serial of data with specific algorithm, have no idea about which part is src and dst ,
So for ip src only with Toeplitz, dst is not required to be a placeholder..
anything I missed, would you share more insight?
Thanks
Qi
>
> My opinion is that, unless you know of a hardware which can perform RSS on
> random bytes of a packet, this approach is a bit overkill at this point.
>
> How about simply adding the needed ETH_RSS_* definitions (e.g.
> ETH_RSS_IPV4_(SRC|DST))? How many are needed?
>
> There are currently 20 used bits and struct rte_flow_action_rss.types is 64-bit
> wide. I'm sure we can manage something without harming the ABI. Even
> better, you wouldn't need a deprecation notice.
>
> If you use the suggested approach, please update testpmd and its
> documentation as part of the same patch, thanks.
>
> --
> Adrien Mazarguil
> 6WIND
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC] ethdev: support input set change by RSS action
2019-07-04 13:55 0% ` Zhang, Qi Z
@ 2019-07-04 14:08 3% ` Adrien Mazarguil
2019-07-09 5:41 3% ` Zhang, Qi Z
0 siblings, 1 reply; 200+ results
From: Adrien Mazarguil @ 2019-07-04 14:08 UTC (permalink / raw)
To: Zhang, Qi Z; +Cc: Su, Simei, Wu, Jingjing, Xing, Beilei, Yang, Qiming, dev
On Thu, Jul 04, 2019 at 01:55:14PM +0000, Zhang, Qi Z wrote:
>
>
> > -----Original Message-----
> > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> > Sent: Thursday, July 4, 2019 5:07 PM
> > To: Su, Simei <simei.su@intel.com>
> > Cc: Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>;
> > Xing, Beilei <beilei.xing@intel.com>; Yang, Qiming <qiming.yang@intel.com>;
> > dev@dpdk.org
> > Subject: Re: [dpdk-dev] [RFC] ethdev: support input set change by RSS action
> >
> > On Thu, Jul 04, 2019 at 12:47:09PM +0800, simei wrote:
> > > From: Simei Su <simei.su@intel.com>
> > >
> > > This RFC introduces inputset structure to rte_flow_action_rss to
> > > support input set specific configuration by rte_flow RSS action.
> > >
> > > We can give an testpmd command line example to make it more clear.
> > >
> > > For example, below flow selects the l4 port as inputset for any
> > > eth/ipv4/tcp packet: #flow create 0 ingress pattern eth / ipv4 / tcp /
> > > end actions rss inputset tcp src mask 0xffff dst mask 0xffff /end
> > >
> > > Signed-off-by: Simei Su <simei.su@intel.com>
> > > ---
> > > lib/librte_ethdev/rte_flow.h | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/lib/librte_ethdev/rte_flow.h
> > > b/lib/librte_ethdev/rte_flow.h index f3a8fb1..2a455b6 100644
> > > --- a/lib/librte_ethdev/rte_flow.h
> > > +++ b/lib/librte_ethdev/rte_flow.h
> > > @@ -1796,6 +1796,9 @@ struct rte_flow_action_rss {
> > > uint32_t queue_num; /**< Number of entries in @p queue. */
> > > const uint8_t *key; /**< Hash key. */
> > > const uint16_t *queue; /**< Queue indices to use. */
> > > + struct rte_flow_item *inputset; /** Provide more specific inputset
> > configuration.
> > > + * ignore spec, only mask.
> > > + */
> > > };
> > >
> > > /**
> >
> > To make sure I understand, is this kind of a more flexible version of
> > rte_flow_action_rss.types?
>
> Yes
> >
> > For instance while specifying .types = ETH_RSS_IPV4 normally covers both
> > source and destination addresses, does this approach enable users to perform
> > RSS on source IP only?
>
> Yes, .it is the case to select any subset of 5 tuples or even tunnel header's id for hash
>
> > In which case, what value does the Toeplitz algorithm
> > assume for the destination, 0x0? (note: must be documented)
>
> My understanding is src/dst pair is only required for a symmetric case
> But for Toeplitz, it is just a hash function, it process a serial of data with specific algorithm, have no idea about which part is src and dst ,
> So for ip src only with Toeplitz, dst is not required to be a placeholder..
Right, I had symmetric Toeplitz in mind and wondered what would happen when
users would not select the required fields. I guess the PMD would have to
reject unsupported combinations.
> anything I missed, would you share more insight?
No, that answers the question, thanks.
Now what about my suggestion below? In short: extending ETH_RSS_* assuming
there's enough bits left in there, instead of adding a whole new framework
and breaking ABI in the process.
> > My opinion is that, unless you know of a hardware which can perform RSS on
> > random bytes of a packet, this approach is a bit overkill at this point.
> >
> > How about simply adding the needed ETH_RSS_* definitions (e.g.
> > ETH_RSS_IPV4_(SRC|DST))? How many are needed?
> >
> > There are currently 20 used bits and struct rte_flow_action_rss.types is 64-bit
> > wide. I'm sure we can manage something without harming the ABI. Even
> > better, you wouldn't need a deprecation notice.
> >
> > If you use the suggested approach, please update testpmd and its
> > documentation as part of the same patch, thanks.
--
Adrien Mazarguil
6WIND
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v7 1/2] ring: add reset API to flush the ring when not in use
@ 2019-07-04 14:42 0% ` Thomas Monjalon
2019-07-12 9:32 0% ` Gavin Hu (Arm Technology China)
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-07-04 14:42 UTC (permalink / raw)
To: Gavin Hu
Cc: dev, Olivier Matz, nd, jerinj, hemant.agrawal, nipun.gupta,
Honnappa.Nagarahalli, i.maximets, stable
29/03/2019 15:17, Olivier Matz:
> Hi,
>
> On Fri, Mar 15, 2019 at 11:31:25AM +0800, Gavin Hu wrote:
> > Currently, the flush is done by dequeuing the ring in a while loop. It is
> > much simpler to flush the queue by resetting the head and tail indices.
> >
> > Fixes: af75078fece3 ("first public release")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Gavin Hu <gavin.hu@arm.com>
> > Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
> > Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > ---
> > --- a/lib/librte_ring/rte_ring_version.map
> > +++ b/lib/librte_ring/rte_ring_version.map
> > @@ -17,3 +17,10 @@ DPDK_2.2 {
> > rte_ring_free;
> >
> > } DPDK_2.0;
> > +
> > +EXPERIMENTAL {
> > + global:
> > +
> > + rte_ring_reset;
> > +
> > +};
>
> To me, a static inline function does not need to be added in
> rte_ring_version.map (or is it due to a check script checking the
> __rte_experimental tag ?). I found at least one commit where it
> is not the case:
> c277b34c1b3b ("mbuf: add function returning buffer address")
>
> There are 2 options:
> 1- remove the rte_ring_version.map part of the patch.
> 2- change the static inline function into a standard function.
>
> I would prefer 2-, because it allows to keep an api/abi compat
> layer in the future.
There are no news about this patch.
I classify it as changes requested.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3 00/14] Make shared memory config non-public
2019-07-04 8:09 3% ` David Marchand
@ 2019-07-04 19:52 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-07-04 19:52 UTC (permalink / raw)
To: David Marchand, Anatoly Burakov; +Cc: dev, Stephen Hemminger
04/07/2019 10:09, David Marchand:
> I just want to state two approaches to merge these changes:
> - the first one would be to split this series in two
> - take the first part of this series now, but mark the new API
> "experimental"
> - postpone the merge to 19.11 of the second part, which starts at the
> hiding rte_mem_config patch
> - the second one is taking these changes in one go
>
> The second one is the quicker and the more straightforward but it leaves
> the risk of having missed something and we must break the ABI again in
> 19.11.
> The risk is quite low, given the changes.
>
>
> Thomas, comments?
OK to merge it in one go.
Please, can we merge it tomorrow?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] [v1]vhost: support inflight share memory protocol feature
@ 2019-07-05 8:47 3% ` Maxime Coquelin
2019-07-08 7:23 0% ` Yu, Jin
0 siblings, 1 reply; 200+ results
From: Maxime Coquelin @ 2019-07-05 8:47 UTC (permalink / raw)
To: JinYu, dev; +Cc: changpeng.liu, LinLi, XunNi, YuZhang, Tiwei Bie
Hi Jin,
On 6/26/19 6:38 PM, JinYu wrote:
> This patch introduces two new messages VHOST_USER_GET_INFLIGHT_FD
> and VHOST_USER_SET_INFLIGHT_FD to support transferring a shared
> buffer between qemu and backend.
>
> Firstly, qemu uses VHOST_USER_GET_INFLIGHT_FD to get the
> shared buffer from backend. Then qemu should send it back
> through VHOST_USER_SET_INFLIGHT_FD each time we start vhost-user.
>
> This shared buffer is used to process inflight I/O when backend
> reconnect.
>
> Signed-off-by: LinLi <lilin24@baidu.com>
> Signed-off-by: XunNi <nixun@baidu.com>
> Signed-off-by: YuZhang <zhangyu31@baidu.com>
> Signed-off-by: JinYu <jin.yu@intel.com>
> ---
> V1 - specify the APIs are split-ring only
> ---
> lib/librte_vhost/rte_vhost.h | 99 +++++++++
> lib/librte_vhost/rte_vhost_version.map | 4 +
> lib/librte_vhost/vhost.c | 135 ++++++++++++
> lib/librte_vhost/vhost.h | 12 +
> lib/librte_vhost/vhost_user.c | 292 +++++++++++++++++++++++++
> lib/librte_vhost/vhost_user.h | 13 +-
> 6 files changed, 554 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_vhost/rte_vhost.h b/lib/librte_vhost/rte_vhost.h
> index 0226b3eff..c9959c15a 100644
> --- a/lib/librte_vhost/rte_vhost.h
> +++ b/lib/librte_vhost/rte_vhost.h
> @@ -71,6 +71,10 @@ extern "C" {
> #define VHOST_USER_PROTOCOL_F_HOST_NOTIFIER 11
> #endif
>
> +#ifndef VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD
> +#define VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD 12
> +#endif
> +
> /** Indicate whether protocol features negotiation is supported. */
> #ifndef VHOST_USER_F_PROTOCOL_FEATURES
> #define VHOST_USER_F_PROTOCOL_FEATURES 30
> @@ -98,12 +102,41 @@ struct rte_vhost_memory {
> struct rte_vhost_mem_region regions[];
> };
>
> +struct inflight_desc_split {
> + uint8_t inflight;
> + uint8_t padding[5];
> + uint16_t next;
> + uint64_t counter;
> +};
> +
> +struct inflight_info_split {
> + uint64_t features;
> + uint16_t version;
> + uint16_t desc_num;
> + uint16_t last_inflight_io;
> + uint16_t used_idx;
> + struct inflight_desc_split desc[0];
> +};
> +
> +struct resubmit_desc {
> + uint16_t index;
> + uint64_t counter;
> +};
> +
> +struct resubmit_info {
> + struct resubmit_desc *resubmit_list;
> + uint16_t resubmit_num;
> +};
> +
> struct rte_vhost_vring {
> struct vring_desc *desc;
> struct vring_avail *avail;
> struct vring_used *used;
> uint64_t log_guest_addr;
>
> + struct inflight_info_split *inflight;
> + struct resubmit_info *resubmit_inflight;
> +
This is breaking the ABI, and discussing with Tiwei, we think it could
be avoided by defining its own structure of inflight and inflight
resubmit pointers. More below:
> /** Deprecated, use rte_vhost_vring_call() instead. */
> int callfd;
>
> @@ -603,6 +636,22 @@ uint16_t rte_vhost_dequeue_burst(int vid, uint16_t queue_id,
> */
> int rte_vhost_get_mem_table(int vid, struct rte_vhost_memory **mem);
>
> +/**
> + * Get guest vring info, including the vring address, vring size, inflight, etc.
> + *
> + * @param vid
> + * vhost device ID
> + * @param vring_idx
> + * vring index
> + * @param vring
> + * the structure to hold the requested vring info
> + * @return
> + * 0 on success, -1 on failure
> + */
> +int __rte_experimental
> +rte_vhost_get_vhost_vring_with_inflight_split(int vid, uint16_t vring_idx,
> + struct rte_vhost_vring *vring);
Here a new API is introduced to get vting info with inflight.
It could be just changed to get only the inflight info. It means the
caller would first call rte_vhost_get_vhost_vring() and then the new
function, which I guess may be renamed to:
rte_vhost_get_vhost_vring_inflight_split
Other than that, the patch looks good to me.
(Next time, please run get_maintainer.sh script so that all the
maintainers are in Cc:).
Thanks,
Maxime
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v4] cryptodev: make xform key pointer constant
@ 2019-07-05 12:30 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-07-05 12:30 UTC (permalink / raw)
To: Akhil Goyal, Fan Zhang; +Cc: dev, pablo.de.lara.guarch
25/06/2019 14:46, Akhil Goyal:
>
> >
> > This patch changes the key pointer data types in cipher, auth,
> > and aead xforms from "uint8_t *" to "const uint8_t *" for a
> > more intuitive and safe sessionn creation.
> >
> > Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
> > Acked-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
> > ---
> > v4:
> > - Removed deprecation notice and updated release note.
> > - Updated ABI version.
> >
> > v3:
> > - rebased on top of latest dpdk-next-crypto
> >
> > v2:
> > - fixed a missed memory free for ixgbe ipsec
>
> Applied to dpdk-next-crypto
> The changes related to update for ABI version were incomplete in this patch, so they were dropped. Another patch from Anoob was also updating the ABI version, so not required in this patch.
I think this patch is not complete, because there is a compilation issue
with mvsam PMD when compiling arm64-thunderx-linux-gcc:
drivers/crypto/mvsam/rte_mrvl_pmd.c:260:35: error:
assignment discards 'const' qualifier from pointer target type
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v4 4/8] eal: hide shared memory config
@ 2019-07-05 13:10 7% ` Anatoly Burakov
2 siblings, 0 replies; 200+ results
From: Anatoly Burakov @ 2019-07-05 13:10 UTC (permalink / raw)
To: dev
Cc: Neil Horman, John McNamara, Marko Kovacevic, Konstantin Ananyev,
David Hunt, Bruce Richardson, Byron Marohn, Pablo de Lara Guarch,
Yipeng Wang, Sameh Gobriel, Vladimir Medvedkin, Olivier Matz,
Andrew Rybchenko, Honnappa Nagarahalli, Reshma Pattan, thomas,
david.marchand, stephen
Now that everything that has ever accessed the shared memory
config is doing so through the public API's, we can make it
internal. Since we're removing quite a few headers from
rte_eal_memconfig.h, we need to add them back in places
where this header is used.
This bumps the ABI, so also change all build files and make
update documentation.
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
---
app/test/test_fbarray.c | 1 +
app/test/test_memzone.c | 1 +
app/test/test_tailq.c | 1 +
doc/guides/rel_notes/deprecation.rst | 3 -
doc/guides/rel_notes/release_19_08.rst | 8 +-
drivers/bus/pci/linux/pci_vfio.c | 1 +
lib/librte_acl/rte_acl.c | 2 +
lib/librte_distributor/rte_distributor.c | 1 +
lib/librte_distributor/rte_distributor_v20.c | 1 +
lib/librte_eal/common/eal_common_mcfg.c | 2 +
lib/librte_eal/common/eal_common_memory.c | 1 +
lib/librte_eal/common/eal_common_memzone.c | 1 +
lib/librte_eal/common/eal_common_tailqs.c | 1 +
lib/librte_eal/common/eal_memcfg.h | 80 ++++++++++++++++
.../common/include/rte_eal_memconfig.h | 95 +------------------
lib/librte_eal/common/include/rte_fbarray.h | 1 -
lib/librte_eal/common/include/rte_memory.h | 24 ++++-
lib/librte_eal/common/malloc_heap.c | 2 +
lib/librte_eal/common/malloc_mp.c | 1 +
lib/librte_eal/common/rte_malloc.c | 1 +
lib/librte_eal/freebsd/eal/Makefile | 2 +-
lib/librte_eal/freebsd/eal/eal_memory.c | 1 +
lib/librte_eal/linux/eal/Makefile | 2 +-
lib/librte_eal/linux/eal/eal.c | 1 +
lib/librte_eal/linux/eal/eal_memalloc.c | 1 +
lib/librte_eal/linux/eal/eal_memory.c | 1 +
lib/librte_eal/linux/eal/eal_vfio.c | 1 +
lib/librte_eal/meson.build | 2 +-
lib/librte_efd/rte_efd.c | 1 +
lib/librte_hash/rte_cuckoo_hash.c | 1 +
lib/librte_hash/rte_fbk_hash.c | 1 +
lib/librte_lpm/rte_lpm.c | 1 +
lib/librte_lpm/rte_lpm6.c | 1 +
lib/librte_member/rte_member.c | 1 +
lib/librte_mempool/rte_mempool.c | 1 +
lib/librte_rcu/rte_rcu_qsbr.h | 1 +
lib/librte_reorder/rte_reorder.c | 1 +
lib/librte_ring/rte_ring.c | 1 +
38 files changed, 148 insertions(+), 101 deletions(-)
create mode 100644 lib/librte_eal/common/eal_memcfg.h
diff --git a/app/test/test_fbarray.c b/app/test/test_fbarray.c
index d2b041887..a691bf445 100644
--- a/app/test/test_fbarray.c
+++ b/app/test/test_fbarray.c
@@ -2,6 +2,7 @@
* Copyright(c) 2010-2014 Intel Corporation
*/
+#include <stdbool.h>
#include <stdio.h>
#include <stdint.h>
#include <limits.h>
diff --git a/app/test/test_memzone.c b/app/test/test_memzone.c
index 9fe465e62..7501b63c5 100644
--- a/app/test/test_memzone.c
+++ b/app/test/test_memzone.c
@@ -19,6 +19,7 @@
#include <rte_errno.h>
#include <rte_malloc.h>
#include "../../lib/librte_eal/common/malloc_elem.h"
+#include "../../lib/librte_eal/common/eal_memcfg.h"
#include "test.h"
diff --git a/app/test/test_tailq.c b/app/test/test_tailq.c
index a4ecea2d8..7c9b69fdb 100644
--- a/app/test/test_tailq.c
+++ b/app/test/test_tailq.c
@@ -12,6 +12,7 @@
#include <rte_eal.h>
#include <rte_eal_memconfig.h>
#include <rte_string_fns.h>
+#include <rte_tailq.h>
#include "test.h"
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index e2721fad6..583217da8 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -23,9 +23,6 @@ Deprecation Notices
* eal: The function ``rte_eal_remote_launch`` will return new error codes
after read or write error on the pipe, instead of calling ``rte_panic``.
-* eal: the ``rte_mem_config`` struct will be made private to remove it from the
- externally visible ABI and allow it to be updated in the future.
-
* 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_08.rst b/doc/guides/rel_notes/release_19_08.rst
index 21934bf01..cc6dfa33f 100644
--- a/doc/guides/rel_notes/release_19_08.rst
+++ b/doc/guides/rel_notes/release_19_08.rst
@@ -172,6 +172,10 @@ API Changes
Also, make sure to start the actual text at the margin.
=========================================================
+* The ``rte_mem_config`` structure has been made private. The new accessor
+ ``rte_mcfg_*`` functions were introduced to provide replacement for direct
+ access to the shared mem config.
+
* The network structures, definitions and functions have
been prefixed by ``rte_`` to resolve conflicts with libc headers.
@@ -201,6 +205,8 @@ ABI Changes
Also, make sure to start the actual text at the margin.
=========================================================
+* The ``rte_mem_config`` structure has been made private.
+
* eventdev: Event based Rx adapter callback
The mbuf pointer array in the event eth Rx adapter callback
@@ -246,7 +252,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_compressdev.so.1
librte_cryptodev.so.7
librte_distributor.so.1
- librte_eal.so.10
+ + librte_eal.so.11
librte_efd.so.1
librte_ethdev.so.12
+ librte_eventdev.so.7
diff --git a/drivers/bus/pci/linux/pci_vfio.c b/drivers/bus/pci/linux/pci_vfio.c
index ebf6ccd3c..1ceb1c07b 100644
--- a/drivers/bus/pci/linux/pci_vfio.c
+++ b/drivers/bus/pci/linux/pci_vfio.c
@@ -20,6 +20,7 @@
#include <rte_eal.h>
#include <rte_bus.h>
#include <rte_spinlock.h>
+#include <rte_tailq.h>
#include "eal_filesystem.h"
diff --git a/lib/librte_acl/rte_acl.c b/lib/librte_acl/rte_acl.c
index 7ff11d25f..bd7247cc3 100644
--- a/lib/librte_acl/rte_acl.c
+++ b/lib/librte_acl/rte_acl.c
@@ -4,6 +4,8 @@
#include <rte_string_fns.h>
#include <rte_acl.h>
+#include <rte_tailq.h>
+
#include "acl.h"
TAILQ_HEAD(rte_acl_list, rte_tailq_entry);
diff --git a/lib/librte_distributor/rte_distributor.c b/lib/librte_distributor/rte_distributor.c
index 9eb78b330..0a3213bbf 100644
--- a/lib/librte_distributor/rte_distributor.c
+++ b/lib/librte_distributor/rte_distributor.c
@@ -14,6 +14,7 @@
#include <rte_string_fns.h>
#include <rte_eal_memconfig.h>
#include <rte_pause.h>
+#include <rte_tailq.h>
#include "rte_distributor_private.h"
#include "rte_distributor.h"
diff --git a/lib/librte_distributor/rte_distributor_v20.c b/lib/librte_distributor/rte_distributor_v20.c
index 1fc03b971..cdc0969a8 100644
--- a/lib/librte_distributor/rte_distributor_v20.c
+++ b/lib/librte_distributor/rte_distributor_v20.c
@@ -13,6 +13,7 @@
#include <rte_string_fns.h>
#include <rte_eal_memconfig.h>
#include <rte_pause.h>
+#include <rte_tailq.h>
#include "rte_distributor_v20.h"
#include "rte_distributor_private.h"
diff --git a/lib/librte_eal/common/eal_common_mcfg.c b/lib/librte_eal/common/eal_common_mcfg.c
index ba2bc37b7..337890a61 100644
--- a/lib/librte_eal/common/eal_common_mcfg.c
+++ b/lib/librte_eal/common/eal_common_mcfg.c
@@ -5,6 +5,8 @@
#include <rte_config.h>
#include <rte_eal_memconfig.h>
+#include "eal_memcfg.h"
+
void
rte_mcfg_mem_read_lock(void)
{
diff --git a/lib/librte_eal/common/eal_common_memory.c b/lib/librte_eal/common/eal_common_memory.c
index fe22b139b..19ea47570 100644
--- a/lib/librte_eal/common/eal_common_memory.c
+++ b/lib/librte_eal/common/eal_common_memory.c
@@ -24,6 +24,7 @@
#include "eal_memalloc.h"
#include "eal_private.h"
#include "eal_internal_cfg.h"
+#include "eal_memcfg.h"
#include "malloc_heap.h"
/*
diff --git a/lib/librte_eal/common/eal_common_memzone.c b/lib/librte_eal/common/eal_common_memzone.c
index 521ad7ca1..ef6c909cb 100644
--- a/lib/librte_eal/common/eal_common_memzone.c
+++ b/lib/librte_eal/common/eal_common_memzone.c
@@ -24,6 +24,7 @@
#include "malloc_heap.h"
#include "malloc_elem.h"
#include "eal_private.h"
+#include "eal_memcfg.h"
static inline const struct rte_memzone *
memzone_lookup_thread_unsafe(const char *name)
diff --git a/lib/librte_eal/common/eal_common_tailqs.c b/lib/librte_eal/common/eal_common_tailqs.c
index dc2c13caa..ead06897b 100644
--- a/lib/librte_eal/common/eal_common_tailqs.c
+++ b/lib/librte_eal/common/eal_common_tailqs.c
@@ -23,6 +23,7 @@
#include <rte_debug.h>
#include "eal_private.h"
+#include "eal_memcfg.h"
TAILQ_HEAD(rte_tailq_elem_head, rte_tailq_elem);
/* local tailq list */
diff --git a/lib/librte_eal/common/eal_memcfg.h b/lib/librte_eal/common/eal_memcfg.h
new file mode 100644
index 000000000..74f6159c6
--- /dev/null
+++ b/lib/librte_eal/common/eal_memcfg.h
@@ -0,0 +1,80 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2019 Intel Corporation
+ */
+
+#ifndef EAL_MEMCFG_H
+#define EAL_MEMCFG_H
+
+#include <rte_config.h>
+#include <rte_eal_memconfig.h>
+#include <rte_malloc_heap.h>
+#include <rte_memory.h>
+#include <rte_memzone.h>
+#include <rte_pause.h>
+#include <rte_rwlock.h>
+#include <rte_tailq.h>
+
+/**
+ * Memory configuration shared across multiple processes.
+ */
+struct rte_mem_config {
+ volatile uint32_t magic; /**< Magic number - sanity check. */
+
+ /* memory topology */
+ uint32_t nchannel; /**< Number of channels (0 if unknown). */
+ uint32_t nrank; /**< Number of ranks (0 if unknown). */
+
+ /**
+ * current lock nest order
+ * - qlock->mlock (ring/hash/lpm)
+ * - mplock->qlock->mlock (mempool)
+ * Notice:
+ * *ALWAYS* obtain qlock first if having to obtain both qlock and mlock
+ */
+ rte_rwlock_t mlock; /**< used by memzones for thread safety. */
+ rte_rwlock_t qlock; /**< used by tailqs for thread safety. */
+ rte_rwlock_t mplock; /**< used by mempool library for thread safety. */
+
+ rte_rwlock_t memory_hotplug_lock;
+ /**< Indicates whether memory hotplug request is in progress. */
+
+ /* memory segments and zones */
+ struct rte_fbarray memzones; /**< Memzone descriptors. */
+
+ struct rte_memseg_list memsegs[RTE_MAX_MEMSEG_LISTS];
+ /**< List of dynamic arrays holding memsegs */
+
+ struct rte_tailq_head tailq_head[RTE_MAX_TAILQ];
+ /**< Tailqs for objects */
+
+ struct malloc_heap malloc_heaps[RTE_MAX_HEAPS];
+ /**< DPDK malloc heaps */
+
+ int next_socket_id; /**< Next socket ID for external malloc heap */
+
+ /* rte_mem_config has to be mapped at the exact same address in all
+ * processes, so we need to store it.
+ */
+ uint64_t mem_cfg_addr; /**< Address of this structure in memory. */
+
+ /* Primary and secondary processes cannot run with different legacy or
+ * single file segments options, so to avoid having to specify these
+ * options to all processes, store them in shared config and update the
+ * internal config at init time.
+ */
+ uint32_t legacy_mem; /**< stored legacy mem parameter. */
+ uint32_t single_file_segments;
+ /**< stored single file segments parameter. */
+
+ uint8_t dma_maskbits; /**< Keeps the more restricted dma mask. */
+} __attribute__((packed));
+
+static inline void
+rte_eal_mcfg_wait_complete(struct rte_mem_config *mcfg)
+{
+ /* wait until shared mem_config finish initialising */
+ while (mcfg->magic != RTE_MAGIC)
+ rte_pause();
+}
+
+#endif /* EAL_MEMCFG_H */
diff --git a/lib/librte_eal/common/include/rte_eal_memconfig.h b/lib/librte_eal/common/include/rte_eal_memconfig.h
index 58dcbb96d..dc61a6fed 100644
--- a/lib/librte_eal/common/include/rte_eal_memconfig.h
+++ b/lib/librte_eal/common/include/rte_eal_memconfig.h
@@ -5,101 +5,16 @@
#ifndef _RTE_EAL_MEMCONFIG_H_
#define _RTE_EAL_MEMCONFIG_H_
-#include <rte_config.h>
-#include <rte_tailq.h>
-#include <rte_memory.h>
-#include <rte_memzone.h>
-#include <rte_malloc_heap.h>
-#include <rte_rwlock.h>
-#include <rte_pause.h>
-#include <rte_fbarray.h>
+/**
+ * @file
+ *
+ * This API allows access to EAL shared memory configuration through an API.
+ */
#ifdef __cplusplus
extern "C" {
#endif
-/**
- * memseg list is a special case as we need to store a bunch of other data
- * together with the array itself.
- */
-struct rte_memseg_list {
- RTE_STD_C11
- union {
- void *base_va;
- /**< Base virtual address for this memseg list. */
- uint64_t addr_64;
- /**< Makes sure addr is always 64-bits */
- };
- uint64_t page_sz; /**< Page size for all memsegs in this list. */
- int socket_id; /**< Socket ID for all memsegs in this list. */
- volatile uint32_t version; /**< version number for multiprocess sync. */
- size_t len; /**< Length of memory area covered by this memseg list. */
- unsigned int external; /**< 1 if this list points to external memory */
- struct rte_fbarray memseg_arr;
-};
-
-/**
- * the structure for the memory configuration for the RTE.
- * Used by the rte_config structure. It is separated out, as for multi-process
- * support, the memory details should be shared across instances
- */
-struct rte_mem_config {
- volatile uint32_t magic; /**< Magic number - Sanity check. */
-
- /* memory topology */
- uint32_t nchannel; /**< Number of channels (0 if unknown). */
- uint32_t nrank; /**< Number of ranks (0 if unknown). */
-
- /**
- * current lock nest order
- * - qlock->mlock (ring/hash/lpm)
- * - mplock->qlock->mlock (mempool)
- * Notice:
- * *ALWAYS* obtain qlock first if having to obtain both qlock and mlock
- */
- rte_rwlock_t mlock; /**< only used by memzone LIB for thread-safe. */
- rte_rwlock_t qlock; /**< used for tailq operation for thread safe. */
- rte_rwlock_t mplock; /**< only used by mempool LIB for thread-safe. */
-
- rte_rwlock_t memory_hotplug_lock;
- /**< indicates whether memory hotplug request is in progress. */
-
- /* memory segments and zones */
- struct rte_fbarray memzones; /**< Memzone descriptors. */
-
- struct rte_memseg_list memsegs[RTE_MAX_MEMSEG_LISTS];
- /**< list of dynamic arrays holding memsegs */
-
- struct rte_tailq_head tailq_head[RTE_MAX_TAILQ]; /**< Tailqs for objects */
-
- /* Heaps of Malloc */
- struct malloc_heap malloc_heaps[RTE_MAX_HEAPS];
-
- /* next socket ID for external malloc heap */
- int next_socket_id;
-
- /* address of mem_config in primary process. used to map shared config into
- * exact same address the primary process maps it.
- */
- uint64_t mem_cfg_addr;
-
- /* legacy mem and single file segments options are shared */
- uint32_t legacy_mem;
- uint32_t single_file_segments;
-
- /* keeps the more restricted dma mask */
- uint8_t dma_maskbits;
-} __attribute__((__packed__));
-
-
-inline static void
-rte_eal_mcfg_wait_complete(struct rte_mem_config* mcfg)
-{
- /* wait until shared mem_config finish initialising */
- while(mcfg->magic != RTE_MAGIC)
- rte_pause();
-}
-
/**
* Lock the internal EAL shared memory configuration for shared access.
*/
diff --git a/lib/librte_eal/common/include/rte_fbarray.h b/lib/librte_eal/common/include/rte_fbarray.h
index d0af2d8c7..6dccdbec9 100644
--- a/lib/librte_eal/common/include/rte_fbarray.h
+++ b/lib/librte_eal/common/include/rte_fbarray.h
@@ -34,7 +34,6 @@
extern "C" {
#endif
-#include <stdbool.h>
#include <stdio.h>
#include <rte_compat.h>
diff --git a/lib/librte_eal/common/include/rte_memory.h b/lib/librte_eal/common/include/rte_memory.h
index 44cbe6fd2..ca34a10c3 100644
--- a/lib/librte_eal/common/include/rte_memory.h
+++ b/lib/librte_eal/common/include/rte_memory.h
@@ -22,9 +22,7 @@ extern "C" {
#include <rte_common.h>
#include <rte_compat.h>
#include <rte_config.h>
-
-/* forward declaration for pointers */
-struct rte_memseg_list;
+#include <rte_fbarray.h>
__extension__
enum rte_page_sizes {
@@ -104,6 +102,26 @@ struct rte_memseg {
uint32_t flags; /**< Memseg-specific flags */
} __rte_packed;
+/**
+ * memseg list is a special case as we need to store a bunch of other data
+ * together with the array itself.
+ */
+struct rte_memseg_list {
+ RTE_STD_C11
+ union {
+ void *base_va;
+ /**< Base virtual address for this memseg list. */
+ uint64_t addr_64;
+ /**< Makes sure addr is always 64-bits */
+ };
+ uint64_t page_sz; /**< Page size for all memsegs in this list. */
+ int socket_id; /**< Socket ID for all memsegs in this list. */
+ volatile uint32_t version; /**< version number for multiprocess sync. */
+ size_t len; /**< Length of memory area covered by this memseg list. */
+ unsigned int external; /**< 1 if this list points to external memory */
+ struct rte_fbarray memseg_arr;
+};
+
/**
* Lock page in physical memory and prevent from swapping.
*
diff --git a/lib/librte_eal/common/malloc_heap.c b/lib/librte_eal/common/malloc_heap.c
index f1d31de0d..634ca212f 100644
--- a/lib/librte_eal/common/malloc_heap.c
+++ b/lib/librte_eal/common/malloc_heap.c
@@ -20,11 +20,13 @@
#include <rte_string_fns.h>
#include <rte_spinlock.h>
#include <rte_memcpy.h>
+#include <rte_memzone.h>
#include <rte_atomic.h>
#include <rte_fbarray.h>
#include "eal_internal_cfg.h"
#include "eal_memalloc.h"
+#include "eal_memcfg.h"
#include "malloc_elem.h"
#include "malloc_heap.h"
#include "malloc_mp.h"
diff --git a/lib/librte_eal/common/malloc_mp.c b/lib/librte_eal/common/malloc_mp.c
index 7c6112c4e..1f212f834 100644
--- a/lib/librte_eal/common/malloc_mp.c
+++ b/lib/librte_eal/common/malloc_mp.c
@@ -10,6 +10,7 @@
#include <rte_string_fns.h>
#include "eal_memalloc.h"
+#include "eal_memcfg.h"
#include "malloc_elem.h"
#include "malloc_mp.h"
diff --git a/lib/librte_eal/common/rte_malloc.c b/lib/librte_eal/common/rte_malloc.c
index 2cad7beaa..fecd9a964 100644
--- a/lib/librte_eal/common/rte_malloc.c
+++ b/lib/librte_eal/common/rte_malloc.c
@@ -25,6 +25,7 @@
#include "malloc_elem.h"
#include "malloc_heap.h"
#include "eal_memalloc.h"
+#include "eal_memcfg.h"
/* Free the memory space back to heap */
diff --git a/lib/librte_eal/freebsd/eal/Makefile b/lib/librte_eal/freebsd/eal/Makefile
index eb921275e..89131ea89 100644
--- a/lib/librte_eal/freebsd/eal/Makefile
+++ b/lib/librte_eal/freebsd/eal/Makefile
@@ -22,7 +22,7 @@ LDLIBS += -lrte_kvargs
EXPORT_MAP := ../../rte_eal_version.map
-LIBABIVER := 10
+LIBABIVER := 11
# specific to freebsd exec-env
SRCS-$(CONFIG_RTE_EXEC_ENV_FREEBSD) := eal.c
diff --git a/lib/librte_eal/freebsd/eal/eal_memory.c b/lib/librte_eal/freebsd/eal/eal_memory.c
index 4b092e1f2..9b9a0577a 100644
--- a/lib/librte_eal/freebsd/eal/eal_memory.c
+++ b/lib/librte_eal/freebsd/eal/eal_memory.c
@@ -18,6 +18,7 @@
#include "eal_private.h"
#include "eal_internal_cfg.h"
#include "eal_filesystem.h"
+#include "eal_memcfg.h"
#define EAL_PAGE_SIZE (sysconf(_SC_PAGESIZE))
diff --git a/lib/librte_eal/linux/eal/Makefile b/lib/librte_eal/linux/eal/Makefile
index dfe8e9a49..0f5725e64 100644
--- a/lib/librte_eal/linux/eal/Makefile
+++ b/lib/librte_eal/linux/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 := 10
+LIBABIVER := 11
VPATH += $(RTE_SDK)/lib/librte_eal/common
diff --git a/lib/librte_eal/linux/eal/eal.c b/lib/librte_eal/linux/eal/eal.c
index 8a0b387ce..f974cec1c 100644
--- a/lib/librte_eal/linux/eal/eal.c
+++ b/lib/librte_eal/linux/eal/eal.c
@@ -57,6 +57,7 @@
#include "eal_internal_cfg.h"
#include "eal_filesystem.h"
#include "eal_hugepages.h"
+#include "eal_memcfg.h"
#include "eal_options.h"
#include "eal_vfio.h"
#include "hotplug_mp.h"
diff --git a/lib/librte_eal/linux/eal/eal_memalloc.c b/lib/librte_eal/linux/eal/eal_memalloc.c
index 2019636fb..1f6a7c18f 100644
--- a/lib/librte_eal/linux/eal/eal_memalloc.c
+++ b/lib/librte_eal/linux/eal/eal_memalloc.c
@@ -44,6 +44,7 @@
#include "eal_filesystem.h"
#include "eal_internal_cfg.h"
#include "eal_memalloc.h"
+#include "eal_memcfg.h"
#include "eal_private.h"
const int anonymous_hugepages_supported =
diff --git a/lib/librte_eal/linux/eal/eal_memory.c b/lib/librte_eal/linux/eal/eal_memory.c
index 1853acea5..9c948a374 100644
--- a/lib/librte_eal/linux/eal/eal_memory.c
+++ b/lib/librte_eal/linux/eal/eal_memory.c
@@ -46,6 +46,7 @@
#include "eal_private.h"
#include "eal_memalloc.h"
+#include "eal_memcfg.h"
#include "eal_internal_cfg.h"
#include "eal_filesystem.h"
#include "eal_hugepages.h"
diff --git a/lib/librte_eal/linux/eal/eal_vfio.c b/lib/librte_eal/linux/eal/eal_vfio.c
index 96a03a657..fdc884f70 100644
--- a/lib/librte_eal/linux/eal/eal_vfio.c
+++ b/lib/librte_eal/linux/eal/eal_vfio.c
@@ -15,6 +15,7 @@
#include <rte_vfio.h>
#include "eal_filesystem.h"
+#include "eal_memcfg.h"
#include "eal_vfio.h"
#include "eal_private.h"
diff --git a/lib/librte_eal/meson.build b/lib/librte_eal/meson.build
index ccd5b85b8..2751023a9 100644
--- a/lib/librte_eal/meson.build
+++ b/lib/librte_eal/meson.build
@@ -12,7 +12,7 @@ subdir('common') # defines common_sources, common_objs, etc.
dpdk_conf.set('RTE_EXEC_ENV_' + exec_env.to_upper(), 1)
subdir(exec_env + '/eal')
-version = 10 # the version of the EAL API
+version = 11 # the version of the EAL API
allow_experimental_apis = true
deps += 'kvargs'
if dpdk_conf.has('RTE_USE_LIBBSD')
diff --git a/lib/librte_efd/rte_efd.c b/lib/librte_efd/rte_efd.c
index b808ce99f..d3d019578 100644
--- a/lib/librte_efd/rte_efd.c
+++ b/lib/librte_efd/rte_efd.c
@@ -20,6 +20,7 @@
#include <rte_ring.h>
#include <rte_jhash.h>
#include <rte_hash_crc.h>
+#include <rte_tailq.h>
#include "rte_efd.h"
#if defined(RTE_ARCH_X86)
diff --git a/lib/librte_hash/rte_cuckoo_hash.c b/lib/librte_hash/rte_cuckoo_hash.c
index 47cd0da5b..74d5bbd99 100644
--- a/lib/librte_hash/rte_cuckoo_hash.c
+++ b/lib/librte_hash/rte_cuckoo_hash.c
@@ -27,6 +27,7 @@
#include <rte_ring.h>
#include <rte_compat.h>
#include <rte_vect.h>
+#include <rte_tailq.h>
#include "rte_hash.h"
#include "rte_cuckoo_hash.h"
diff --git a/lib/librte_hash/rte_fbk_hash.c b/lib/librte_hash/rte_fbk_hash.c
index db118c930..576e8e666 100644
--- a/lib/librte_hash/rte_fbk_hash.c
+++ b/lib/librte_hash/rte_fbk_hash.c
@@ -20,6 +20,7 @@
#include <rte_cpuflags.h>
#include <rte_log.h>
#include <rte_spinlock.h>
+#include <rte_tailq.h>
#include "rte_fbk_hash.h"
diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
index b91f74216..70c24ac1f 100644
--- a/lib/librte_lpm/rte_lpm.c
+++ b/lib/librte_lpm/rte_lpm.c
@@ -21,6 +21,7 @@
#include <rte_errno.h>
#include <rte_rwlock.h>
#include <rte_spinlock.h>
+#include <rte_tailq.h>
#include "rte_lpm.h"
diff --git a/lib/librte_lpm/rte_lpm6.c b/lib/librte_lpm/rte_lpm6.c
index 5af74a539..9b8aeb972 100644
--- a/lib/librte_lpm/rte_lpm6.c
+++ b/lib/librte_lpm/rte_lpm6.c
@@ -24,6 +24,7 @@
#include <rte_hash.h>
#include <assert.h>
#include <rte_jhash.h>
+#include <rte_tailq.h>
#include "rte_lpm6.h"
diff --git a/lib/librte_member/rte_member.c b/lib/librte_member/rte_member.c
index efed28dd9..e0e7f127e 100644
--- a/lib/librte_member/rte_member.c
+++ b/lib/librte_member/rte_member.c
@@ -10,6 +10,7 @@
#include <rte_memory.h>
#include <rte_malloc.h>
#include <rte_errno.h>
+#include <rte_tailq.h>
#include "rte_member.h"
#include "rte_member_ht.h"
diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index 5c688d456..7260ce0be 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -30,6 +30,7 @@
#include <rte_errno.h>
#include <rte_string_fns.h>
#include <rte_spinlock.h>
+#include <rte_tailq.h>
#include "rte_mempool.h"
diff --git a/lib/librte_rcu/rte_rcu_qsbr.h b/lib/librte_rcu/rte_rcu_qsbr.h
index 53a5a7165..c80f15c00 100644
--- a/lib/librte_rcu/rte_rcu_qsbr.h
+++ b/lib/librte_rcu/rte_rcu_qsbr.h
@@ -24,6 +24,7 @@
extern "C" {
#endif
+#include <stdbool.h>
#include <stdio.h>
#include <stdint.h>
#include <inttypes.h>
diff --git a/lib/librte_reorder/rte_reorder.c b/lib/librte_reorder/rte_reorder.c
index ae6e3f578..3c9f0e2d0 100644
--- a/lib/librte_reorder/rte_reorder.c
+++ b/lib/librte_reorder/rte_reorder.c
@@ -11,6 +11,7 @@
#include <rte_eal_memconfig.h>
#include <rte_errno.h>
#include <rte_malloc.h>
+#include <rte_tailq.h>
#include "rte_reorder.h"
diff --git a/lib/librte_ring/rte_ring.c b/lib/librte_ring/rte_ring.c
index 9ea26a631..b30b2aa7b 100644
--- a/lib/librte_ring/rte_ring.c
+++ b/lib/librte_ring/rte_ring.c
@@ -30,6 +30,7 @@
#include <rte_errno.h>
#include <rte_string_fns.h>
#include <rte_spinlock.h>
+#include <rte_tailq.h>
#include "rte_ring.h"
--
2.17.1
^ permalink raw reply [relevance 7%]
* [dpdk-dev] [PATCH v2 0/1] Fix timer resource leak
@ 2019-07-05 13:20 4% ` Anatoly Burakov
2019-07-05 17:22 4% ` [dpdk-dev] [PATCH v3 " Anatoly Burakov
0 siblings, 1 reply; 200+ results
From: Anatoly Burakov @ 2019-07-05 13:20 UTC (permalink / raw)
To: dev
Previous attempts [1] at fixing the resource leak have been
deemed unsuccessful because of limitations around what
can be done without breaking the ABI. Now that we've
broken the EAL ABI, we can fix this issue properly.
This patchset is adding a new lock API, as well as fixes the
actual issue.
The patchset depends on mem config patchset [2].
[1] http://patches.dpdk.org/patch/53334/
[2] http://patches.dpdk.org/project/dpdk/list/?series=5369
Anatoly Burakov (1):
timer: fix resource leak in finalize
lib/librte_eal/common/eal_common_mcfg.c | 29 +++++++++++++
lib/librte_eal/common/eal_memcfg.h | 8 ++++
.../common/include/rte_eal_memconfig.h | 22 ++++++++++
lib/librte_eal/freebsd/eal/eal.c | 5 ++-
lib/librte_eal/linux/eal/eal.c | 5 ++-
lib/librte_eal/rte_eal_version.map | 2 +
lib/librte_timer/rte_timer.c | 41 +++++++++++++------
lib/librte_timer/rte_timer.h | 5 ++-
8 files changed, 100 insertions(+), 17 deletions(-)
--
2.17.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v2] devtools: better freebsd support
@ 2019-07-05 13:58 6% ` Olivier Matz
2019-07-09 11:05 0% ` Musatescu, Flavia
2019-07-11 14:25 6% ` [dpdk-dev] [PATCH v3] " Olivier Matz
0 siblings, 2 replies; 200+ results
From: Olivier Matz @ 2019-07-05 13:58 UTC (permalink / raw)
To: dev; +Cc: Thomas Monjalon, David Marchand, Bruce Richardson
- As "readlink -e" and "readlink -m" do not exist on freebsd,
use "readlink -f", it should not have any impact in these cases.
- "sed -ri" is invalid on freebsd and should be replaced by
"sed -ri=''"
- Use gmake instead of make.
This fixes the following command:
SYSDIR=/usr/src/sys ./devtools/test-build.sh \
-j4 x86_64-native-freebsd-gcc
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
---
v2:
- remove sed_ri() function and use 'sed -ri=""' as suggested by Bruce
devtools/check-dup-includes.sh | 2 +-
devtools/checkpatches.sh | 8 ++--
devtools/get-maintainer.sh | 2 +-
devtools/load-devel-config | 4 +-
devtools/test-build.sh | 94 ++++++++++++++++++++++--------------------
devtools/validate-abi.sh | 2 +-
6 files changed, 58 insertions(+), 54 deletions(-)
diff --git a/devtools/check-dup-includes.sh b/devtools/check-dup-includes.sh
index e4c2748c6..591599949 100755
--- a/devtools/check-dup-includes.sh
+++ b/devtools/check-dup-includes.sh
@@ -5,7 +5,7 @@
# Check C files in git repository for duplicated includes.
# Usage: devtools/check-dup-includes.sh [directory]
-dir=${1:-$(dirname $(readlink -m $0))/..}
+dir=${1:-$(dirname $(readlink -f $0))/..}
cd $dir
# speed up by ignoring Unicode details
diff --git a/devtools/checkpatches.sh b/devtools/checkpatches.sh
index 560e6ce93..8e2beee16 100755
--- a/devtools/checkpatches.sh
+++ b/devtools/checkpatches.sh
@@ -7,9 +7,9 @@
# - DPDK_CHECKPATCH_CODESPELL
# - DPDK_CHECKPATCH_LINE_LENGTH
# - DPDK_CHECKPATCH_OPTIONS
-. $(dirname $(readlink -e $0))/load-devel-config
+. $(dirname $(readlink -f $0))/load-devel-config
-VALIDATE_NEW_API=$(dirname $(readlink -e $0))/check-symbol-change.sh
+VALIDATE_NEW_API=$(dirname $(readlink -f $0))/check-symbol-change.sh
# Enable codespell by default. This can be overwritten from a config file.
# Codespell can also be enabled by setting DPDK_CHECKPATCH_CODESPELL to a valid path
@@ -66,7 +66,7 @@ check_forbidden_additions() { # <patch>
-v EXPRESSIONS="rte_panic\\\( rte_exit\\\(" \
-v RET_ON_FAIL=1 \
-v MESSAGE='Using rte_panic/rte_exit' \
- -f $(dirname $(readlink -e $0))/check-forbidden-tokens.awk \
+ -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
"$1" || res=1
# svg figures must be included with wildcard extension
@@ -75,7 +75,7 @@ check_forbidden_additions() { # <patch>
-v EXPRESSIONS='::[[:space:]]*[^[:space:]]*\\.svg' \
-v RET_ON_FAIL=1 \
-v MESSAGE='Using explicit .svg extension instead of .*' \
- -f $(dirname $(readlink -e $0))/check-forbidden-tokens.awk \
+ -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
"$1" || res=1
return $res
diff --git a/devtools/get-maintainer.sh b/devtools/get-maintainer.sh
index b9160486a..85740f5af 100755
--- a/devtools/get-maintainer.sh
+++ b/devtools/get-maintainer.sh
@@ -5,7 +5,7 @@
# Load config options:
# - DPDK_GETMAINTAINER_PATH
-. $(dirname $(readlink -e $0))/load-devel-config
+. $(dirname $(readlink -f $0))/load-devel-config
options="--no-git-fallback"
options="$options --no-rolestats"
diff --git a/devtools/load-devel-config b/devtools/load-devel-config
index 4f43cb352..380c79db4 100644
--- a/devtools/load-devel-config
+++ b/devtools/load-devel-config
@@ -6,7 +6,7 @@ test ! -r /etc/dpdk/devel.config ||
test ! -r ~/.config/dpdk/devel.config ||
. ~/.config/dpdk/devel.config
# from local file
-test ! -r $(dirname $(readlink -m $0))/../.develconfig ||
- . $(dirname $(readlink -m $0))/../.develconfig
+test ! -r $(dirname $(readlink -f $0))/../.develconfig ||
+ . $(dirname $(readlink -f $0))/../.develconfig
# The config files must export variables in the shell style
diff --git a/devtools/test-build.sh b/devtools/test-build.sh
index 9b50bf73d..22d409bb0 100755
--- a/devtools/test-build.sh
+++ b/devtools/test-build.sh
@@ -28,7 +28,7 @@ default_path=$PATH
# - LIBSSO_SNOW3G_PATH
# - LIBSSO_KASUMI_PATH
# - LIBSSO_ZUC_PATH
-. $(dirname $(readlink -e $0))/load-devel-config
+. $(dirname $(readlink -f $0))/load-devel-config
print_usage () {
echo "usage: $(basename $0) [-h] [-jX] [-s] [config1 [config2] ...]]"
@@ -57,6 +57,10 @@ print_help () {
END_OF_HELP
}
+[ -z $MAKE ] && command -v gmake > /dev/null && MAKE=gmake
+[ -z $MAKE ] && command -v make > /dev/null && MAKE=make
+[ -z $MAKE ] && echo "Cannot find make or gmake" && exit 1
+
J=$DPDK_MAKE_JOBS
short=false
unset verbose
@@ -90,7 +94,7 @@ trap "signal=INT ; trap - INT ; kill -INT $$" INT
# notify result on exit
trap on_exit EXIT
-cd $(dirname $(readlink -m $0))/..
+cd $(dirname $(readlink -f $0))/..
reset_env ()
{
@@ -127,83 +131,83 @@ config () # <directory> <target> <options>
fi
if [ ! -e $1/.config ] || $reconfig ; then
echo "================== Configure $1"
- make T=$2 O=$1 config
+ ${MAKE} T=$2 O=$1 config
echo 'Customize configuration'
# Built-in options (lowercase)
! echo $3 | grep -q '+default' || \
- sed -ri 's,(RTE_MACHINE=")native,\1default,' $1/.config
+ sed -ri="" 's,(RTE_MACHINE=")native,\1default,' $1/.config
echo $3 | grep -q '+next' || \
- sed -ri 's,(NEXT_ABI=)y,\1n,' $1/.config
+ sed -ri="" 's,(NEXT_ABI=)y,\1n,' $1/.config
! echo $3 | grep -q '+shared' || \
- sed -ri 's,(SHARED_LIB=)n,\1y,' $1/.config
+ sed -ri="" 's,(SHARED_LIB=)n,\1y,' $1/.config
! echo $3 | grep -q '+debug' || ( \
- sed -ri 's,(RTE_LOG_DP_LEVEL=).*,\1RTE_LOG_DEBUG,' $1/.config
- sed -ri 's,(_DEBUG.*=)n,\1y,' $1/.config
- sed -ri 's,(_STAT.*=)n,\1y,' $1/.config
- sed -ri 's,(TEST_PMD_RECORD_.*=)n,\1y,' $1/.config )
+ sed -ri="" 's,(RTE_LOG_DP_LEVEL=).*,\1RTE_LOG_DEBUG,' $1/.config
+ sed -ri="" 's,(_DEBUG.*=)n,\1y,' $1/.config
+ sed -ri="" 's,(_STAT.*=)n,\1y,' $1/.config
+ sed -ri="" 's,(TEST_PMD_RECORD_.*=)n,\1y,' $1/.config )
# Automatic configuration
test "$DPDK_DEP_NUMA" != n || \
- sed -ri 's,(NUMA.*=)y,\1n,' $1/.config
- sed -ri 's,(LIBRTE_IEEE1588=)n,\1y,' $1/.config
- sed -ri 's,(BYPASS=)n,\1y,' $1/.config
+ sed -ri="" 's,(NUMA.*=)y,\1n,' $1/.config
+ sed -ri="" 's,(LIBRTE_IEEE1588=)n,\1y,' $1/.config
+ sed -ri="" 's,(BYPASS=)n,\1y,' $1/.config
test "$DPDK_DEP_ARCHIVE" != y || \
- sed -ri 's,(RESOURCE_TAR=)n,\1y,' $1/.config
+ sed -ri="" 's,(RESOURCE_TAR=)n,\1y,' $1/.config
test "$DPDK_DEP_ISAL" != y || \
- sed -ri 's,(PMD_ISAL=)n,\1y,' $1/.config
+ sed -ri="" 's,(PMD_ISAL=)n,\1y,' $1/.config
test "$DPDK_DEP_MLX" != y || \
- sed -ri 's,(MLX._PMD=)n,\1y,' $1/.config
+ sed -ri="" 's,(MLX._PMD=)n,\1y,' $1/.config
test "$DPDK_DEP_SZE" != y || \
- sed -ri 's,(PMD_SZEDATA2=)n,\1y,' $1/.config
+ sed -ri="" 's,(PMD_SZEDATA2=)n,\1y,' $1/.config
test "$DPDK_DEP_ZLIB" != y || \
- sed -ri 's,(BNX2X_PMD=)n,\1y,' $1/.config
+ sed -ri="" 's,(BNX2X_PMD=)n,\1y,' $1/.config
test "$DPDK_DEP_ZLIB" != y || \
- sed -ri 's,(PMD_ZLIB=)n,\1y,' $1/.config
+ sed -ri="" 's,(PMD_ZLIB=)n,\1y,' $1/.config
test "$DPDK_DEP_ZLIB" != y || \
- sed -ri 's,(COMPRESSDEV_TEST=)n,\1y,' $1/.config
+ sed -ri="" 's,(COMPRESSDEV_TEST=)n,\1y,' $1/.config
test "$DPDK_DEP_PCAP" != y || \
- sed -ri 's,(PCAP=)n,\1y,' $1/.config
+ sed -ri="" 's,(PCAP=)n,\1y,' $1/.config
test -z "$ARMV8_CRYPTO_LIB_PATH" || \
- sed -ri 's,(PMD_ARMV8_CRYPTO=)n,\1y,' $1/.config
+ sed -ri="" 's,(PMD_ARMV8_CRYPTO=)n,\1y,' $1/.config
test "$DPDK_DEP_IPSEC_MB" != y || \
- sed -ri 's,(PMD_AESNI_MB=)n,\1y,' $1/.config
+ sed -ri="" 's,(PMD_AESNI_MB=)n,\1y,' $1/.config
test "$DPDK_DEP_IPSEC_MB" != y || \
- sed -ri 's,(PMD_AESNI_GCM=)n,\1y,' $1/.config
+ sed -ri="" 's,(PMD_AESNI_GCM=)n,\1y,' $1/.config
test -z "$LIBSSO_SNOW3G_PATH" || \
- sed -ri 's,(PMD_SNOW3G=)n,\1y,' $1/.config
+ sed -ri="" 's,(PMD_SNOW3G=)n,\1y,' $1/.config
test -z "$LIBSSO_KASUMI_PATH" || \
- sed -ri 's,(PMD_KASUMI=)n,\1y,' $1/.config
+ sed -ri="" 's,(PMD_KASUMI=)n,\1y,' $1/.config
test -z "$LIBSSO_ZUC_PATH" || \
- sed -ri 's,(PMD_ZUC=)n,\1y,' $1/.config
+ sed -ri="" 's,(PMD_ZUC=)n,\1y,' $1/.config
test "$DPDK_DEP_SSL" != y || \
- sed -ri 's,(PMD_CCP=)n,\1y,' $1/.config
+ sed -ri="" 's,(PMD_CCP=)n,\1y,' $1/.config
test "$DPDK_DEP_SSL" != y || \
- sed -ri 's,(PMD_OPENSSL=)n,\1y,' $1/.config
+ sed -ri="" 's,(PMD_OPENSSL=)n,\1y,' $1/.config
test "$DPDK_DEP_SSL" != y || \
- sed -ri 's,(QAT_SYM=)n,\1y,' $1/.config
+ sed -ri="" 's,(QAT_SYM=)n,\1y,' $1/.config
test -z "$FLEXRAN_SDK" || \
- sed -ri 's,(BBDEV_TURBO_SW=)n,\1y,' $1/.config
- sed -ri 's,(SCHED_.*=)n,\1y,' $1/.config
+ sed -ri="" 's,(BBDEV_TURBO_SW=)n,\1y,' $1/.config
+ sed -ri="" 's,(SCHED_.*=)n,\1y,' $1/.config
test -z "$LIBMUSDK_PATH" || \
- sed -ri 's,(PMD_MVSAM_CRYPTO=)n,\1y,' $1/.config
+ sed -ri="" 's,(PMD_MVSAM_CRYPTO=)n,\1y,' $1/.config
test -z "$LIBMUSDK_PATH" || \
- sed -ri 's,(MVPP2_PMD=)n,\1y,' $1/.config
+ sed -ri="" 's,(MVPP2_PMD=)n,\1y,' $1/.config
test -z "$LIBMUSDK_PATH" || \
- sed -ri 's,(MVNETA_PMD=)n,\1y,' $1/.config
+ sed -ri="" 's,(MVNETA_PMD=)n,\1y,' $1/.config
test "$DPDK_DEP_ELF" != y || \
- sed -ri 's,(BPF_ELF=)n,\1y,' $1/.config
+ sed -ri="" 's,(BPF_ELF=)n,\1y,' $1/.config
test "$DPDK_DEP_JSON" != y || \
- sed -ri 's,(TELEMETRY=)n,\1y,' $1/.config
+ sed -ri="" 's,(TELEMETRY=)n,\1y,' $1/.config
build_config_hook $1 $2 $3
# Explicit enabler/disabler (uppercase)
for option in $(echo $3 | sed 's,[~+], &,g') ; do
pattern=$(echo $option | cut -c2-)
if echo $option | grep -q '^~' ; then
- sed -ri "s,($pattern=)y,\1n," $1/.config
+ sed -ri="" "s,($pattern=)y,\1n," $1/.config
elif echo $option | grep -q '^+' ; then
- sed -ri "s,($pattern=)n,\1y," $1/.config
+ sed -ri="" "s,($pattern=)n,\1y," $1/.config
fi
done
fi
@@ -220,22 +224,22 @@ for conf in $configs ; do
# reload config with DPDK_TARGET set
DPDK_TARGET=$target
reset_env
- . $(dirname $(readlink -e $0))/load-devel-config
+ . $(dirname $(readlink -f $0))/load-devel-config
options=$(echo $conf | sed 's,[^~+]*,,')
dir=$conf
config $dir $target $options
echo "================== Build $dir"
- make -j$J EXTRA_CFLAGS="$maxerr $DPDK_DEP_CFLAGS" \
+ ${MAKE} -j$J EXTRA_CFLAGS="$maxerr $DPDK_DEP_CFLAGS" \
EXTRA_LDFLAGS="$DPDK_DEP_LDFLAGS" $verbose O=$dir
! $short || break
echo "================== Build examples for $dir"
export RTE_SDK=$(pwd)
export RTE_TARGET=$dir
- make -j$J -sC examples \
+ ${MAKE} -j$J -sC examples \
EXTRA_LDFLAGS="$DPDK_DEP_LDFLAGS" $verbose \
- O=$(readlink -m $dir/examples)
+ O=$(readlink -f $dir/examples)
unset RTE_TARGET
echo "################## $dir done."
unset dir
@@ -244,9 +248,9 @@ done
if ! $short ; then
mkdir -p .check
echo "================== Build doxygen HTML API"
- make doc-api-html >/dev/null 2>.check/doc.txt
+ ${MAKE} doc-api-html >/dev/null 2>.check/doc.txt
echo "================== Build sphinx HTML guides"
- make doc-guides-html >/dev/null 2>>.check/doc.txt
+ ${MAKE} doc-guides-html >/dev/null 2>>.check/doc.txt
echo "================== Check docs"
diff -u /dev/null .check/doc.txt
fi
diff --git a/devtools/validate-abi.sh b/devtools/validate-abi.sh
index 138436d93..f64e19d38 100755
--- a/devtools/validate-abi.sh
+++ b/devtools/validate-abi.sh
@@ -181,7 +181,7 @@ case "${dst}" in
/*) ;;
*) dst=${PWD}/${dst} ;;
esac
-dpdkroot=$(readlink -e $(dirname $0)/..)
+dpdkroot=$(readlink -f $(dirname $0)/..)
if [ -e "${dst}" -a "$force" = 0 ]; then
echo "The ${dst} directory is not empty. Remove it, use another"
--
2.11.0
^ permalink raw reply [relevance 6%]
* Re: [dpdk-dev] [PATCH v7 05/12] net/ether: mark ethernet addresses as being 2-byte aligned
@ 2019-07-05 14:34 3% ` Olivier Matz
2019-07-05 15:45 0% ` Richardson, Bruce
0 siblings, 1 reply; 200+ results
From: Olivier Matz @ 2019-07-05 14:34 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev, Bruce Richardson, Andrew Rybchenko
On Tue, Jul 02, 2019 at 03:12:40PM -0700, Stephen Hemminger wrote:
> From: Bruce Richardson <bruce.richardson@intel.com>
>
> When including the rte_ether.h header in applications with warnings
> enabled, a warning was given because of the assumption of 2-byte alignment
> of ethernet addresses when processing them.
>
> .../include/rte_ether.h:149:2: warning: converting a packed ‘const
> struct ether_addr’ pointer (alignment 1) to a ‘unaligned_uint16_t’
> {aka ‘const short unsigned int’} pointer (alignment 2) may result in
> an unaligned pointer value [-Waddress-of-packed-member]
> 149 | const unaligned_uint16_t *ea_words = (const unaligned_uint16_t *)ea;
> | ^~~~~
>
> Since ethernet addresses should always be aligned on a two-byte boundary,
> we can just inform the compiler of this assumption to remove the warnings
> and allow us to always access the addresses using 16-bit operations.
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> Reviewed-by: Andrew Rybchenko <arybchenko@solarflare.com>
> ---
> lib/librte_net/rte_ether.h | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/lib/librte_net/rte_ether.h b/lib/librte_net/rte_ether.h
> index feb35a33c94b..d7b76ddf63eb 100644
> --- a/lib/librte_net/rte_ether.h
> +++ b/lib/librte_net/rte_ether.h
> @@ -58,7 +58,8 @@ extern "C" {
> * See http://standards.ieee.org/regauth/groupmac/tutorial.html
> */
> struct rte_ether_addr {
> - uint8_t addr_bytes[RTE_ETHER_ADDR_LEN]; /**< Addr bytes in tx order */
> + uint8_t addr_bytes[RTE_ETHER_ADDR_LEN] __rte_aligned(2);
> + /**< Addr bytes in tx order */
> } __attribute__((__packed__));
>
> #define RTE_ETHER_LOCAL_ADMIN_ADDR 0x02 /**< Locally assigned Eth. address. */
> @@ -81,8 +82,8 @@ struct rte_ether_addr {
> static inline int rte_is_same_ether_addr(const struct rte_ether_addr *ea1,
> const struct rte_ether_addr *ea2)
> {
> - const unaligned_uint16_t *w1 = (const uint16_t *)ea1;
> - const unaligned_uint16_t *w2 = (const uint16_t *)ea2;
> + const uint16_t *w1 = (const uint16_t *)ea1;
> + const uint16_t *w2 = (const uint16_t *)ea2;
>
> return ((w1[0] ^ w2[0]) | (w1[1] ^ w2[1]) | (w1[2] ^ w2[2])) == 0;
> }
> @@ -99,7 +100,7 @@ static inline int rte_is_same_ether_addr(const struct rte_ether_addr *ea1,
> */
> static inline int rte_is_zero_ether_addr(const struct rte_ether_addr *ea)
> {
> - const unaligned_uint16_t *w = (const uint16_t *)ea;
> + const uint16_t *w = (const uint16_t *)ea;
>
> return (w[0] | w[1] | w[2]) == 0;
> }
> @@ -146,7 +147,7 @@ static inline int rte_is_multicast_ether_addr(const struct rte_ether_addr *ea)
> */
> static inline int rte_is_broadcast_ether_addr(const struct rte_ether_addr *ea)
> {
> - const unaligned_uint16_t *ea_words = (const unaligned_uint16_t *)ea;
> + const uint16_t *ea_words = (const uint16_t *)ea;
>
> return (ea_words[0] == 0xFFFF && ea_words[1] == 0xFFFF &&
> ea_words[2] == 0xFFFF);
> --
> 2.20.1
>
Following this discussion:
https://mails.dpdk.org/archives/dev/2019-July/136590.html
I still think that changing the ABI without deprecation notice
is not a good idea.
The warning issued by the compiler makes me think that the definition of
unaligned_uint16_t is wrong on intel arch. I made a quick test, and it
seems that in this particular case, the generated code is the same with
or without __attribute__((aligned(1))). See: https://godbolt.org/z/NjBNQk
But changing the definition of unaligned_uint16_t without a deprecation
notice is not an option either.
What do you think about using a specific typedef similar to
unaligned_uint16_t in rte_ether, that has the __attribute__((aligned(1))) ?
It would avoid to change the alignment of struct rte_ether_addr.
In parallel, we can talk about changing unaligned_uint16_t for intel
in another patchset.
Olivier
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v7 05/12] net/ether: mark ethernet addresses as being 2-byte aligned
2019-07-05 14:34 3% ` Olivier Matz
@ 2019-07-05 15:45 0% ` Richardson, Bruce
0 siblings, 0 replies; 200+ results
From: Richardson, Bruce @ 2019-07-05 15:45 UTC (permalink / raw)
To: Olivier Matz, Stephen Hemminger; +Cc: dev, Andrew Rybchenko
> -----Original Message-----
> From: Olivier Matz [mailto:olivier.matz@6wind.com]
> Sent: Friday, July 5, 2019 3:34 PM
> To: Stephen Hemminger <stephen@networkplumber.org>
> Cc: dev@dpdk.org; Richardson, Bruce <bruce.richardson@intel.com>; Andrew
> Rybchenko <arybchenko@solarflare.com>
> Subject: Re: [dpdk-dev] [PATCH v7 05/12] net/ether: mark ethernet
> addresses as being 2-byte aligned
>
> On Tue, Jul 02, 2019 at 03:12:40PM -0700, Stephen Hemminger wrote:
> > From: Bruce Richardson <bruce.richardson@intel.com>
> >
> > When including the rte_ether.h header in applications with warnings
> > enabled, a warning was given because of the assumption of 2-byte
> > alignment of ethernet addresses when processing them.
> >
> > .../include/rte_ether.h:149:2: warning: converting a packed ‘const
> > struct ether_addr’ pointer (alignment 1) to a ‘unaligned_uint16_t’
> > {aka ‘const short unsigned int’} pointer (alignment 2) may result in
> > an unaligned pointer value [-Waddress-of-packed-member]
> > 149 | const unaligned_uint16_t *ea_words = (const unaligned_uint16_t
> *)ea;
> > | ^~~~~
> >
> > Since ethernet addresses should always be aligned on a two-byte
> > boundary, we can just inform the compiler of this assumption to remove
> > the warnings and allow us to always access the addresses using 16-bit
> operations.
> >
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > Reviewed-by: Andrew Rybchenko <arybchenko@solarflare.com>
> > ---
> > lib/librte_net/rte_ether.h | 11 ++++++-----
> > 1 file changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/lib/librte_net/rte_ether.h b/lib/librte_net/rte_ether.h
> > index feb35a33c94b..d7b76ddf63eb 100644
> > --- a/lib/librte_net/rte_ether.h
> > +++ b/lib/librte_net/rte_ether.h
> > @@ -58,7 +58,8 @@ extern "C" {
> > * See http://standards.ieee.org/regauth/groupmac/tutorial.html
> > */
> > struct rte_ether_addr {
> > - uint8_t addr_bytes[RTE_ETHER_ADDR_LEN]; /**< Addr bytes in tx order
> */
> > + uint8_t addr_bytes[RTE_ETHER_ADDR_LEN] __rte_aligned(2);
> > + /**< Addr bytes in tx order */
> > } __attribute__((__packed__));
> >
> > #define RTE_ETHER_LOCAL_ADMIN_ADDR 0x02 /**< Locally assigned Eth.
> > address. */ @@ -81,8 +82,8 @@ struct rte_ether_addr { static inline
> > int rte_is_same_ether_addr(const struct rte_ether_addr *ea1,
> > const struct rte_ether_addr *ea2) {
> > - const unaligned_uint16_t *w1 = (const uint16_t *)ea1;
> > - const unaligned_uint16_t *w2 = (const uint16_t *)ea2;
> > + const uint16_t *w1 = (const uint16_t *)ea1;
> > + const uint16_t *w2 = (const uint16_t *)ea2;
> >
> > return ((w1[0] ^ w2[0]) | (w1[1] ^ w2[1]) | (w1[2] ^ w2[2])) == 0;
> > } @@ -99,7 +100,7 @@ static inline int rte_is_same_ether_addr(const
> > struct rte_ether_addr *ea1,
> > */
> > static inline int rte_is_zero_ether_addr(const struct rte_ether_addr
> > *ea) {
> > - const unaligned_uint16_t *w = (const uint16_t *)ea;
> > + const uint16_t *w = (const uint16_t *)ea;
> >
> > return (w[0] | w[1] | w[2]) == 0;
> > }
> > @@ -146,7 +147,7 @@ static inline int rte_is_multicast_ether_addr(const
> struct rte_ether_addr *ea)
> > */
> > static inline int rte_is_broadcast_ether_addr(const struct
> > rte_ether_addr *ea) {
> > - const unaligned_uint16_t *ea_words = (const unaligned_uint16_t *)ea;
> > + const uint16_t *ea_words = (const uint16_t *)ea;
> >
> > return (ea_words[0] == 0xFFFF && ea_words[1] == 0xFFFF &&
> > ea_words[2] == 0xFFFF);
> > --
> > 2.20.1
> >
>
> Following this discussion:
> https://mails.dpdk.org/archives/dev/2019-July/136590.html
>
> I still think that changing the ABI without deprecation notice
> is not a good idea.
>
I'm ok with that. Let's put in a deprecation notice and take this
patch in 19.11.
> The warning issued by the compiler makes me think that the definition of
> unaligned_uint16_t is wrong on intel arch. I made a quick test, and it
> seems that in this particular case, the generated code is the same with
> or without __attribute__((aligned(1))). See: https://godbolt.org/z/NjBNQk
>
> But changing the definition of unaligned_uint16_t without a deprecation
> notice is not an option either.
>
> What do you think about using a specific typedef similar to
> unaligned_uint16_t in rte_ether, that has the __attribute__((aligned(1)))
> ?
> It would avoid to change the alignment of struct rte_ether_addr.
>
I'd like the alignment changed. Since the existing warnings about alignment don’t
seem to be causing anyone any real problems, I suggest we just leave them for
now and fix them by changing the alignment setting for 19.11.
> In parallel, we can talk about changing unaligned_uint16_t for intel
> in another patchset.
>
Yes, let's fix the broken unaligned definition as a separate issue.
/Bruce
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v3 0/1] Fix timer resource leak
2019-07-05 13:20 4% ` [dpdk-dev] [PATCH v2 0/1] " Anatoly Burakov
@ 2019-07-05 17:22 4% ` Anatoly Burakov
0 siblings, 0 replies; 200+ results
From: Anatoly Burakov @ 2019-07-05 17:22 UTC (permalink / raw)
To: dev
Previous attempts [1] at fixing the resource leak have been
deemed unsuccessful because of limitations around what
can be done without breaking the ABI. Now that we've
broken the EAL ABI, we can fix this issue properly.
This patchset is adding a new lock API, as well as fixes the
actual issue.
The patchset depends on mem config patchset [2].
v3:
- Accidentally squashed with previous patch, reverted
v2:
- Addressed review comments and squashed patches
[1] http://patches.dpdk.org/patch/53334/
[2] http://patches.dpdk.org/project/dpdk/list/?series=5369
Anatoly Burakov (1):
timer: fix resource leak in finalize
lib/librte_eal/common/eal_common_mcfg.c | 14 +++++++
lib/librte_eal/common/eal_memcfg.h | 2 +
.../common/include/rte_eal_memconfig.h | 22 ++++++++++
lib/librte_eal/rte_eal_version.map | 2 +
lib/librte_timer/rte_timer.c | 41 +++++++++++++------
lib/librte_timer/rte_timer.h | 5 ++-
6 files changed, 71 insertions(+), 15 deletions(-)
--
2.17.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v5 4/9] eal: hide shared memory config
@ 2019-07-05 17:26 7% ` Anatoly Burakov
2019-07-05 17:26 3% ` [dpdk-dev] [PATCH v5 9/9] eal: prevent different primary/secondary process versions Anatoly Burakov
2 siblings, 0 replies; 200+ results
From: Anatoly Burakov @ 2019-07-05 17:26 UTC (permalink / raw)
To: dev
Cc: Neil Horman, John McNamara, Marko Kovacevic, Konstantin Ananyev,
David Hunt, Bruce Richardson, Byron Marohn, Pablo de Lara Guarch,
Yipeng Wang, Sameh Gobriel, Vladimir Medvedkin, Olivier Matz,
Andrew Rybchenko, Honnappa Nagarahalli, Reshma Pattan, thomas,
david.marchand, stephen
Now that everything that has ever accessed the shared memory
config is doing so through the public API's, we can make it
internal. Since we're removing quite a few headers from
rte_eal_memconfig.h, we need to add them back in places
where this header is used.
This bumps the ABI, so also change all build files and make
update documentation.
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: David Marchand <david.marchand@redhat.com>
---
app/test/test_fbarray.c | 1 +
app/test/test_memzone.c | 1 +
app/test/test_tailq.c | 1 +
doc/guides/rel_notes/deprecation.rst | 3 -
doc/guides/rel_notes/release_19_08.rst | 8 +-
drivers/bus/pci/linux/pci_vfio.c | 1 +
lib/librte_acl/rte_acl.c | 2 +
lib/librte_distributor/rte_distributor.c | 1 +
lib/librte_distributor/rte_distributor_v20.c | 1 +
lib/librte_eal/common/eal_common_mcfg.c | 2 +
lib/librte_eal/common/eal_common_memory.c | 1 +
lib/librte_eal/common/eal_common_memzone.c | 1 +
lib/librte_eal/common/eal_common_tailqs.c | 1 +
lib/librte_eal/common/eal_memcfg.h | 80 ++++++++++++++++
.../common/include/rte_eal_memconfig.h | 95 +------------------
lib/librte_eal/common/include/rte_fbarray.h | 1 -
lib/librte_eal/common/include/rte_memory.h | 24 ++++-
lib/librte_eal/common/malloc_heap.c | 2 +
lib/librte_eal/common/malloc_mp.c | 1 +
lib/librte_eal/common/rte_malloc.c | 1 +
lib/librte_eal/freebsd/eal/Makefile | 2 +-
lib/librte_eal/freebsd/eal/eal_memory.c | 1 +
lib/librte_eal/linux/eal/Makefile | 2 +-
lib/librte_eal/linux/eal/eal.c | 1 +
lib/librte_eal/linux/eal/eal_memalloc.c | 1 +
lib/librte_eal/linux/eal/eal_memory.c | 1 +
lib/librte_eal/linux/eal/eal_vfio.c | 1 +
lib/librte_eal/meson.build | 2 +-
lib/librte_efd/rte_efd.c | 1 +
lib/librte_hash/rte_cuckoo_hash.c | 1 +
lib/librte_hash/rte_fbk_hash.c | 1 +
lib/librte_lpm/rte_lpm.c | 1 +
lib/librte_lpm/rte_lpm6.c | 1 +
lib/librte_member/rte_member.c | 1 +
lib/librte_mempool/rte_mempool.c | 1 +
lib/librte_rcu/rte_rcu_qsbr.h | 1 +
lib/librte_reorder/rte_reorder.c | 1 +
lib/librte_ring/rte_ring.c | 1 +
38 files changed, 148 insertions(+), 101 deletions(-)
create mode 100644 lib/librte_eal/common/eal_memcfg.h
diff --git a/app/test/test_fbarray.c b/app/test/test_fbarray.c
index d2b041887..a691bf445 100644
--- a/app/test/test_fbarray.c
+++ b/app/test/test_fbarray.c
@@ -2,6 +2,7 @@
* Copyright(c) 2010-2014 Intel Corporation
*/
+#include <stdbool.h>
#include <stdio.h>
#include <stdint.h>
#include <limits.h>
diff --git a/app/test/test_memzone.c b/app/test/test_memzone.c
index 9fe465e62..7501b63c5 100644
--- a/app/test/test_memzone.c
+++ b/app/test/test_memzone.c
@@ -19,6 +19,7 @@
#include <rte_errno.h>
#include <rte_malloc.h>
#include "../../lib/librte_eal/common/malloc_elem.h"
+#include "../../lib/librte_eal/common/eal_memcfg.h"
#include "test.h"
diff --git a/app/test/test_tailq.c b/app/test/test_tailq.c
index a4ecea2d8..7c9b69fdb 100644
--- a/app/test/test_tailq.c
+++ b/app/test/test_tailq.c
@@ -12,6 +12,7 @@
#include <rte_eal.h>
#include <rte_eal_memconfig.h>
#include <rte_string_fns.h>
+#include <rte_tailq.h>
#include "test.h"
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index e2721fad6..583217da8 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -23,9 +23,6 @@ Deprecation Notices
* eal: The function ``rte_eal_remote_launch`` will return new error codes
after read or write error on the pipe, instead of calling ``rte_panic``.
-* eal: the ``rte_mem_config`` struct will be made private to remove it from the
- externally visible ABI and allow it to be updated in the future.
-
* 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_08.rst b/doc/guides/rel_notes/release_19_08.rst
index 21934bf01..cc6dfa33f 100644
--- a/doc/guides/rel_notes/release_19_08.rst
+++ b/doc/guides/rel_notes/release_19_08.rst
@@ -172,6 +172,10 @@ API Changes
Also, make sure to start the actual text at the margin.
=========================================================
+* The ``rte_mem_config`` structure has been made private. The new accessor
+ ``rte_mcfg_*`` functions were introduced to provide replacement for direct
+ access to the shared mem config.
+
* The network structures, definitions and functions have
been prefixed by ``rte_`` to resolve conflicts with libc headers.
@@ -201,6 +205,8 @@ ABI Changes
Also, make sure to start the actual text at the margin.
=========================================================
+* The ``rte_mem_config`` structure has been made private.
+
* eventdev: Event based Rx adapter callback
The mbuf pointer array in the event eth Rx adapter callback
@@ -246,7 +252,7 @@ The libraries prepended with a plus sign were incremented in this version.
librte_compressdev.so.1
librte_cryptodev.so.7
librte_distributor.so.1
- librte_eal.so.10
+ + librte_eal.so.11
librte_efd.so.1
librte_ethdev.so.12
+ librte_eventdev.so.7
diff --git a/drivers/bus/pci/linux/pci_vfio.c b/drivers/bus/pci/linux/pci_vfio.c
index ebf6ccd3c..1ceb1c07b 100644
--- a/drivers/bus/pci/linux/pci_vfio.c
+++ b/drivers/bus/pci/linux/pci_vfio.c
@@ -20,6 +20,7 @@
#include <rte_eal.h>
#include <rte_bus.h>
#include <rte_spinlock.h>
+#include <rte_tailq.h>
#include "eal_filesystem.h"
diff --git a/lib/librte_acl/rte_acl.c b/lib/librte_acl/rte_acl.c
index 7ff11d25f..bd7247cc3 100644
--- a/lib/librte_acl/rte_acl.c
+++ b/lib/librte_acl/rte_acl.c
@@ -4,6 +4,8 @@
#include <rte_string_fns.h>
#include <rte_acl.h>
+#include <rte_tailq.h>
+
#include "acl.h"
TAILQ_HEAD(rte_acl_list, rte_tailq_entry);
diff --git a/lib/librte_distributor/rte_distributor.c b/lib/librte_distributor/rte_distributor.c
index 9eb78b330..0a3213bbf 100644
--- a/lib/librte_distributor/rte_distributor.c
+++ b/lib/librte_distributor/rte_distributor.c
@@ -14,6 +14,7 @@
#include <rte_string_fns.h>
#include <rte_eal_memconfig.h>
#include <rte_pause.h>
+#include <rte_tailq.h>
#include "rte_distributor_private.h"
#include "rte_distributor.h"
diff --git a/lib/librte_distributor/rte_distributor_v20.c b/lib/librte_distributor/rte_distributor_v20.c
index 1fc03b971..cdc0969a8 100644
--- a/lib/librte_distributor/rte_distributor_v20.c
+++ b/lib/librte_distributor/rte_distributor_v20.c
@@ -13,6 +13,7 @@
#include <rte_string_fns.h>
#include <rte_eal_memconfig.h>
#include <rte_pause.h>
+#include <rte_tailq.h>
#include "rte_distributor_v20.h"
#include "rte_distributor_private.h"
diff --git a/lib/librte_eal/common/eal_common_mcfg.c b/lib/librte_eal/common/eal_common_mcfg.c
index ba2bc37b7..337890a61 100644
--- a/lib/librte_eal/common/eal_common_mcfg.c
+++ b/lib/librte_eal/common/eal_common_mcfg.c
@@ -5,6 +5,8 @@
#include <rte_config.h>
#include <rte_eal_memconfig.h>
+#include "eal_memcfg.h"
+
void
rte_mcfg_mem_read_lock(void)
{
diff --git a/lib/librte_eal/common/eal_common_memory.c b/lib/librte_eal/common/eal_common_memory.c
index fe22b139b..19ea47570 100644
--- a/lib/librte_eal/common/eal_common_memory.c
+++ b/lib/librte_eal/common/eal_common_memory.c
@@ -24,6 +24,7 @@
#include "eal_memalloc.h"
#include "eal_private.h"
#include "eal_internal_cfg.h"
+#include "eal_memcfg.h"
#include "malloc_heap.h"
/*
diff --git a/lib/librte_eal/common/eal_common_memzone.c b/lib/librte_eal/common/eal_common_memzone.c
index 521ad7ca1..ef6c909cb 100644
--- a/lib/librte_eal/common/eal_common_memzone.c
+++ b/lib/librte_eal/common/eal_common_memzone.c
@@ -24,6 +24,7 @@
#include "malloc_heap.h"
#include "malloc_elem.h"
#include "eal_private.h"
+#include "eal_memcfg.h"
static inline const struct rte_memzone *
memzone_lookup_thread_unsafe(const char *name)
diff --git a/lib/librte_eal/common/eal_common_tailqs.c b/lib/librte_eal/common/eal_common_tailqs.c
index dc2c13caa..ead06897b 100644
--- a/lib/librte_eal/common/eal_common_tailqs.c
+++ b/lib/librte_eal/common/eal_common_tailqs.c
@@ -23,6 +23,7 @@
#include <rte_debug.h>
#include "eal_private.h"
+#include "eal_memcfg.h"
TAILQ_HEAD(rte_tailq_elem_head, rte_tailq_elem);
/* local tailq list */
diff --git a/lib/librte_eal/common/eal_memcfg.h b/lib/librte_eal/common/eal_memcfg.h
new file mode 100644
index 000000000..74f6159c6
--- /dev/null
+++ b/lib/librte_eal/common/eal_memcfg.h
@@ -0,0 +1,80 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2019 Intel Corporation
+ */
+
+#ifndef EAL_MEMCFG_H
+#define EAL_MEMCFG_H
+
+#include <rte_config.h>
+#include <rte_eal_memconfig.h>
+#include <rte_malloc_heap.h>
+#include <rte_memory.h>
+#include <rte_memzone.h>
+#include <rte_pause.h>
+#include <rte_rwlock.h>
+#include <rte_tailq.h>
+
+/**
+ * Memory configuration shared across multiple processes.
+ */
+struct rte_mem_config {
+ volatile uint32_t magic; /**< Magic number - sanity check. */
+
+ /* memory topology */
+ uint32_t nchannel; /**< Number of channels (0 if unknown). */
+ uint32_t nrank; /**< Number of ranks (0 if unknown). */
+
+ /**
+ * current lock nest order
+ * - qlock->mlock (ring/hash/lpm)
+ * - mplock->qlock->mlock (mempool)
+ * Notice:
+ * *ALWAYS* obtain qlock first if having to obtain both qlock and mlock
+ */
+ rte_rwlock_t mlock; /**< used by memzones for thread safety. */
+ rte_rwlock_t qlock; /**< used by tailqs for thread safety. */
+ rte_rwlock_t mplock; /**< used by mempool library for thread safety. */
+
+ rte_rwlock_t memory_hotplug_lock;
+ /**< Indicates whether memory hotplug request is in progress. */
+
+ /* memory segments and zones */
+ struct rte_fbarray memzones; /**< Memzone descriptors. */
+
+ struct rte_memseg_list memsegs[RTE_MAX_MEMSEG_LISTS];
+ /**< List of dynamic arrays holding memsegs */
+
+ struct rte_tailq_head tailq_head[RTE_MAX_TAILQ];
+ /**< Tailqs for objects */
+
+ struct malloc_heap malloc_heaps[RTE_MAX_HEAPS];
+ /**< DPDK malloc heaps */
+
+ int next_socket_id; /**< Next socket ID for external malloc heap */
+
+ /* rte_mem_config has to be mapped at the exact same address in all
+ * processes, so we need to store it.
+ */
+ uint64_t mem_cfg_addr; /**< Address of this structure in memory. */
+
+ /* Primary and secondary processes cannot run with different legacy or
+ * single file segments options, so to avoid having to specify these
+ * options to all processes, store them in shared config and update the
+ * internal config at init time.
+ */
+ uint32_t legacy_mem; /**< stored legacy mem parameter. */
+ uint32_t single_file_segments;
+ /**< stored single file segments parameter. */
+
+ uint8_t dma_maskbits; /**< Keeps the more restricted dma mask. */
+} __attribute__((packed));
+
+static inline void
+rte_eal_mcfg_wait_complete(struct rte_mem_config *mcfg)
+{
+ /* wait until shared mem_config finish initialising */
+ while (mcfg->magic != RTE_MAGIC)
+ rte_pause();
+}
+
+#endif /* EAL_MEMCFG_H */
diff --git a/lib/librte_eal/common/include/rte_eal_memconfig.h b/lib/librte_eal/common/include/rte_eal_memconfig.h
index 58dcbb96d..dc61a6fed 100644
--- a/lib/librte_eal/common/include/rte_eal_memconfig.h
+++ b/lib/librte_eal/common/include/rte_eal_memconfig.h
@@ -5,101 +5,16 @@
#ifndef _RTE_EAL_MEMCONFIG_H_
#define _RTE_EAL_MEMCONFIG_H_
-#include <rte_config.h>
-#include <rte_tailq.h>
-#include <rte_memory.h>
-#include <rte_memzone.h>
-#include <rte_malloc_heap.h>
-#include <rte_rwlock.h>
-#include <rte_pause.h>
-#include <rte_fbarray.h>
+/**
+ * @file
+ *
+ * This API allows access to EAL shared memory configuration through an API.
+ */
#ifdef __cplusplus
extern "C" {
#endif
-/**
- * memseg list is a special case as we need to store a bunch of other data
- * together with the array itself.
- */
-struct rte_memseg_list {
- RTE_STD_C11
- union {
- void *base_va;
- /**< Base virtual address for this memseg list. */
- uint64_t addr_64;
- /**< Makes sure addr is always 64-bits */
- };
- uint64_t page_sz; /**< Page size for all memsegs in this list. */
- int socket_id; /**< Socket ID for all memsegs in this list. */
- volatile uint32_t version; /**< version number for multiprocess sync. */
- size_t len; /**< Length of memory area covered by this memseg list. */
- unsigned int external; /**< 1 if this list points to external memory */
- struct rte_fbarray memseg_arr;
-};
-
-/**
- * the structure for the memory configuration for the RTE.
- * Used by the rte_config structure. It is separated out, as for multi-process
- * support, the memory details should be shared across instances
- */
-struct rte_mem_config {
- volatile uint32_t magic; /**< Magic number - Sanity check. */
-
- /* memory topology */
- uint32_t nchannel; /**< Number of channels (0 if unknown). */
- uint32_t nrank; /**< Number of ranks (0 if unknown). */
-
- /**
- * current lock nest order
- * - qlock->mlock (ring/hash/lpm)
- * - mplock->qlock->mlock (mempool)
- * Notice:
- * *ALWAYS* obtain qlock first if having to obtain both qlock and mlock
- */
- rte_rwlock_t mlock; /**< only used by memzone LIB for thread-safe. */
- rte_rwlock_t qlock; /**< used for tailq operation for thread safe. */
- rte_rwlock_t mplock; /**< only used by mempool LIB for thread-safe. */
-
- rte_rwlock_t memory_hotplug_lock;
- /**< indicates whether memory hotplug request is in progress. */
-
- /* memory segments and zones */
- struct rte_fbarray memzones; /**< Memzone descriptors. */
-
- struct rte_memseg_list memsegs[RTE_MAX_MEMSEG_LISTS];
- /**< list of dynamic arrays holding memsegs */
-
- struct rte_tailq_head tailq_head[RTE_MAX_TAILQ]; /**< Tailqs for objects */
-
- /* Heaps of Malloc */
- struct malloc_heap malloc_heaps[RTE_MAX_HEAPS];
-
- /* next socket ID for external malloc heap */
- int next_socket_id;
-
- /* address of mem_config in primary process. used to map shared config into
- * exact same address the primary process maps it.
- */
- uint64_t mem_cfg_addr;
-
- /* legacy mem and single file segments options are shared */
- uint32_t legacy_mem;
- uint32_t single_file_segments;
-
- /* keeps the more restricted dma mask */
- uint8_t dma_maskbits;
-} __attribute__((__packed__));
-
-
-inline static void
-rte_eal_mcfg_wait_complete(struct rte_mem_config* mcfg)
-{
- /* wait until shared mem_config finish initialising */
- while(mcfg->magic != RTE_MAGIC)
- rte_pause();
-}
-
/**
* Lock the internal EAL shared memory configuration for shared access.
*/
diff --git a/lib/librte_eal/common/include/rte_fbarray.h b/lib/librte_eal/common/include/rte_fbarray.h
index d0af2d8c7..6dccdbec9 100644
--- a/lib/librte_eal/common/include/rte_fbarray.h
+++ b/lib/librte_eal/common/include/rte_fbarray.h
@@ -34,7 +34,6 @@
extern "C" {
#endif
-#include <stdbool.h>
#include <stdio.h>
#include <rte_compat.h>
diff --git a/lib/librte_eal/common/include/rte_memory.h b/lib/librte_eal/common/include/rte_memory.h
index 44cbe6fd2..ca34a10c3 100644
--- a/lib/librte_eal/common/include/rte_memory.h
+++ b/lib/librte_eal/common/include/rte_memory.h
@@ -22,9 +22,7 @@ extern "C" {
#include <rte_common.h>
#include <rte_compat.h>
#include <rte_config.h>
-
-/* forward declaration for pointers */
-struct rte_memseg_list;
+#include <rte_fbarray.h>
__extension__
enum rte_page_sizes {
@@ -104,6 +102,26 @@ struct rte_memseg {
uint32_t flags; /**< Memseg-specific flags */
} __rte_packed;
+/**
+ * memseg list is a special case as we need to store a bunch of other data
+ * together with the array itself.
+ */
+struct rte_memseg_list {
+ RTE_STD_C11
+ union {
+ void *base_va;
+ /**< Base virtual address for this memseg list. */
+ uint64_t addr_64;
+ /**< Makes sure addr is always 64-bits */
+ };
+ uint64_t page_sz; /**< Page size for all memsegs in this list. */
+ int socket_id; /**< Socket ID for all memsegs in this list. */
+ volatile uint32_t version; /**< version number for multiprocess sync. */
+ size_t len; /**< Length of memory area covered by this memseg list. */
+ unsigned int external; /**< 1 if this list points to external memory */
+ struct rte_fbarray memseg_arr;
+};
+
/**
* Lock page in physical memory and prevent from swapping.
*
diff --git a/lib/librte_eal/common/malloc_heap.c b/lib/librte_eal/common/malloc_heap.c
index f1d31de0d..634ca212f 100644
--- a/lib/librte_eal/common/malloc_heap.c
+++ b/lib/librte_eal/common/malloc_heap.c
@@ -20,11 +20,13 @@
#include <rte_string_fns.h>
#include <rte_spinlock.h>
#include <rte_memcpy.h>
+#include <rte_memzone.h>
#include <rte_atomic.h>
#include <rte_fbarray.h>
#include "eal_internal_cfg.h"
#include "eal_memalloc.h"
+#include "eal_memcfg.h"
#include "malloc_elem.h"
#include "malloc_heap.h"
#include "malloc_mp.h"
diff --git a/lib/librte_eal/common/malloc_mp.c b/lib/librte_eal/common/malloc_mp.c
index 7c6112c4e..1f212f834 100644
--- a/lib/librte_eal/common/malloc_mp.c
+++ b/lib/librte_eal/common/malloc_mp.c
@@ -10,6 +10,7 @@
#include <rte_string_fns.h>
#include "eal_memalloc.h"
+#include "eal_memcfg.h"
#include "malloc_elem.h"
#include "malloc_mp.h"
diff --git a/lib/librte_eal/common/rte_malloc.c b/lib/librte_eal/common/rte_malloc.c
index 2cad7beaa..fecd9a964 100644
--- a/lib/librte_eal/common/rte_malloc.c
+++ b/lib/librte_eal/common/rte_malloc.c
@@ -25,6 +25,7 @@
#include "malloc_elem.h"
#include "malloc_heap.h"
#include "eal_memalloc.h"
+#include "eal_memcfg.h"
/* Free the memory space back to heap */
diff --git a/lib/librte_eal/freebsd/eal/Makefile b/lib/librte_eal/freebsd/eal/Makefile
index eb921275e..89131ea89 100644
--- a/lib/librte_eal/freebsd/eal/Makefile
+++ b/lib/librte_eal/freebsd/eal/Makefile
@@ -22,7 +22,7 @@ LDLIBS += -lrte_kvargs
EXPORT_MAP := ../../rte_eal_version.map
-LIBABIVER := 10
+LIBABIVER := 11
# specific to freebsd exec-env
SRCS-$(CONFIG_RTE_EXEC_ENV_FREEBSD) := eal.c
diff --git a/lib/librte_eal/freebsd/eal/eal_memory.c b/lib/librte_eal/freebsd/eal/eal_memory.c
index 4b092e1f2..9b9a0577a 100644
--- a/lib/librte_eal/freebsd/eal/eal_memory.c
+++ b/lib/librte_eal/freebsd/eal/eal_memory.c
@@ -18,6 +18,7 @@
#include "eal_private.h"
#include "eal_internal_cfg.h"
#include "eal_filesystem.h"
+#include "eal_memcfg.h"
#define EAL_PAGE_SIZE (sysconf(_SC_PAGESIZE))
diff --git a/lib/librte_eal/linux/eal/Makefile b/lib/librte_eal/linux/eal/Makefile
index dfe8e9a49..0f5725e64 100644
--- a/lib/librte_eal/linux/eal/Makefile
+++ b/lib/librte_eal/linux/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 := 10
+LIBABIVER := 11
VPATH += $(RTE_SDK)/lib/librte_eal/common
diff --git a/lib/librte_eal/linux/eal/eal.c b/lib/librte_eal/linux/eal/eal.c
index 8a0b387ce..f974cec1c 100644
--- a/lib/librte_eal/linux/eal/eal.c
+++ b/lib/librte_eal/linux/eal/eal.c
@@ -57,6 +57,7 @@
#include "eal_internal_cfg.h"
#include "eal_filesystem.h"
#include "eal_hugepages.h"
+#include "eal_memcfg.h"
#include "eal_options.h"
#include "eal_vfio.h"
#include "hotplug_mp.h"
diff --git a/lib/librte_eal/linux/eal/eal_memalloc.c b/lib/librte_eal/linux/eal/eal_memalloc.c
index 2019636fb..1f6a7c18f 100644
--- a/lib/librte_eal/linux/eal/eal_memalloc.c
+++ b/lib/librte_eal/linux/eal/eal_memalloc.c
@@ -44,6 +44,7 @@
#include "eal_filesystem.h"
#include "eal_internal_cfg.h"
#include "eal_memalloc.h"
+#include "eal_memcfg.h"
#include "eal_private.h"
const int anonymous_hugepages_supported =
diff --git a/lib/librte_eal/linux/eal/eal_memory.c b/lib/librte_eal/linux/eal/eal_memory.c
index 1853acea5..9c948a374 100644
--- a/lib/librte_eal/linux/eal/eal_memory.c
+++ b/lib/librte_eal/linux/eal/eal_memory.c
@@ -46,6 +46,7 @@
#include "eal_private.h"
#include "eal_memalloc.h"
+#include "eal_memcfg.h"
#include "eal_internal_cfg.h"
#include "eal_filesystem.h"
#include "eal_hugepages.h"
diff --git a/lib/librte_eal/linux/eal/eal_vfio.c b/lib/librte_eal/linux/eal/eal_vfio.c
index 96a03a657..fdc884f70 100644
--- a/lib/librte_eal/linux/eal/eal_vfio.c
+++ b/lib/librte_eal/linux/eal/eal_vfio.c
@@ -15,6 +15,7 @@
#include <rte_vfio.h>
#include "eal_filesystem.h"
+#include "eal_memcfg.h"
#include "eal_vfio.h"
#include "eal_private.h"
diff --git a/lib/librte_eal/meson.build b/lib/librte_eal/meson.build
index ccd5b85b8..2751023a9 100644
--- a/lib/librte_eal/meson.build
+++ b/lib/librte_eal/meson.build
@@ -12,7 +12,7 @@ subdir('common') # defines common_sources, common_objs, etc.
dpdk_conf.set('RTE_EXEC_ENV_' + exec_env.to_upper(), 1)
subdir(exec_env + '/eal')
-version = 10 # the version of the EAL API
+version = 11 # the version of the EAL API
allow_experimental_apis = true
deps += 'kvargs'
if dpdk_conf.has('RTE_USE_LIBBSD')
diff --git a/lib/librte_efd/rte_efd.c b/lib/librte_efd/rte_efd.c
index b808ce99f..d3d019578 100644
--- a/lib/librte_efd/rte_efd.c
+++ b/lib/librte_efd/rte_efd.c
@@ -20,6 +20,7 @@
#include <rte_ring.h>
#include <rte_jhash.h>
#include <rte_hash_crc.h>
+#include <rte_tailq.h>
#include "rte_efd.h"
#if defined(RTE_ARCH_X86)
diff --git a/lib/librte_hash/rte_cuckoo_hash.c b/lib/librte_hash/rte_cuckoo_hash.c
index 47cd0da5b..74d5bbd99 100644
--- a/lib/librte_hash/rte_cuckoo_hash.c
+++ b/lib/librte_hash/rte_cuckoo_hash.c
@@ -27,6 +27,7 @@
#include <rte_ring.h>
#include <rte_compat.h>
#include <rte_vect.h>
+#include <rte_tailq.h>
#include "rte_hash.h"
#include "rte_cuckoo_hash.h"
diff --git a/lib/librte_hash/rte_fbk_hash.c b/lib/librte_hash/rte_fbk_hash.c
index db118c930..576e8e666 100644
--- a/lib/librte_hash/rte_fbk_hash.c
+++ b/lib/librte_hash/rte_fbk_hash.c
@@ -20,6 +20,7 @@
#include <rte_cpuflags.h>
#include <rte_log.h>
#include <rte_spinlock.h>
+#include <rte_tailq.h>
#include "rte_fbk_hash.h"
diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
index b91f74216..70c24ac1f 100644
--- a/lib/librte_lpm/rte_lpm.c
+++ b/lib/librte_lpm/rte_lpm.c
@@ -21,6 +21,7 @@
#include <rte_errno.h>
#include <rte_rwlock.h>
#include <rte_spinlock.h>
+#include <rte_tailq.h>
#include "rte_lpm.h"
diff --git a/lib/librte_lpm/rte_lpm6.c b/lib/librte_lpm/rte_lpm6.c
index 5af74a539..9b8aeb972 100644
--- a/lib/librte_lpm/rte_lpm6.c
+++ b/lib/librte_lpm/rte_lpm6.c
@@ -24,6 +24,7 @@
#include <rte_hash.h>
#include <assert.h>
#include <rte_jhash.h>
+#include <rte_tailq.h>
#include "rte_lpm6.h"
diff --git a/lib/librte_member/rte_member.c b/lib/librte_member/rte_member.c
index efed28dd9..e0e7f127e 100644
--- a/lib/librte_member/rte_member.c
+++ b/lib/librte_member/rte_member.c
@@ -10,6 +10,7 @@
#include <rte_memory.h>
#include <rte_malloc.h>
#include <rte_errno.h>
+#include <rte_tailq.h>
#include "rte_member.h"
#include "rte_member_ht.h"
diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index 5c688d456..7260ce0be 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -30,6 +30,7 @@
#include <rte_errno.h>
#include <rte_string_fns.h>
#include <rte_spinlock.h>
+#include <rte_tailq.h>
#include "rte_mempool.h"
diff --git a/lib/librte_rcu/rte_rcu_qsbr.h b/lib/librte_rcu/rte_rcu_qsbr.h
index 53a5a7165..c80f15c00 100644
--- a/lib/librte_rcu/rte_rcu_qsbr.h
+++ b/lib/librte_rcu/rte_rcu_qsbr.h
@@ -24,6 +24,7 @@
extern "C" {
#endif
+#include <stdbool.h>
#include <stdio.h>
#include <stdint.h>
#include <inttypes.h>
diff --git a/lib/librte_reorder/rte_reorder.c b/lib/librte_reorder/rte_reorder.c
index ae6e3f578..3c9f0e2d0 100644
--- a/lib/librte_reorder/rte_reorder.c
+++ b/lib/librte_reorder/rte_reorder.c
@@ -11,6 +11,7 @@
#include <rte_eal_memconfig.h>
#include <rte_errno.h>
#include <rte_malloc.h>
+#include <rte_tailq.h>
#include "rte_reorder.h"
diff --git a/lib/librte_ring/rte_ring.c b/lib/librte_ring/rte_ring.c
index 9ea26a631..b30b2aa7b 100644
--- a/lib/librte_ring/rte_ring.c
+++ b/lib/librte_ring/rte_ring.c
@@ -30,6 +30,7 @@
#include <rte_errno.h>
#include <rte_string_fns.h>
#include <rte_spinlock.h>
+#include <rte_tailq.h>
#include "rte_ring.h"
--
2.17.1
^ permalink raw reply [relevance 7%]
* [dpdk-dev] [PATCH v5 9/9] eal: prevent different primary/secondary process versions
2019-07-05 17:26 7% ` [dpdk-dev] [PATCH v5 4/9] " Anatoly Burakov
@ 2019-07-05 17:26 3% ` Anatoly Burakov
2 siblings, 0 replies; 200+ results
From: Anatoly Burakov @ 2019-07-05 17:26 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson, thomas, david.marchand, stephen
Currently, nothing stops DPDK to attempt to run primary and
secondary processes while having different versions. This
can lead to all sorts of weird behavior and makes it harder
to maintain compatibility without breaking ABI every once
in a while.
Fix it by explicitly disallowing running different DPDK
versions as primary and secondary processes.
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: David Marchand <david.marchand@redhat.com>
---
lib/librte_eal/common/eal_common_mcfg.c | 15 +++++++++++++++
lib/librte_eal/common/eal_memcfg.h | 6 ++++++
lib/librte_eal/freebsd/eal/eal.c | 4 ++++
lib/librte_eal/linux/eal/eal.c | 4 ++++
4 files changed, 29 insertions(+)
diff --git a/lib/librte_eal/common/eal_common_mcfg.c b/lib/librte_eal/common/eal_common_mcfg.c
index fe8d2b726..1825d9083 100644
--- a/lib/librte_eal/common/eal_common_mcfg.c
+++ b/lib/librte_eal/common/eal_common_mcfg.c
@@ -4,6 +4,7 @@
#include <rte_config.h>
#include <rte_eal_memconfig.h>
+#include <rte_version.h>
#include "eal_internal_cfg.h"
#include "eal_memcfg.h"
@@ -31,6 +32,18 @@ eal_mcfg_wait_complete(void)
rte_pause();
}
+int
+eal_mcfg_check_version(void)
+{
+ struct rte_mem_config *mcfg = rte_eal_get_configuration()->mem_config;
+
+ /* check if version from memconfig matches compiled in macro */
+ if (mcfg->version != RTE_VERSION)
+ return -1;
+
+ return 0;
+}
+
void
eal_mcfg_update_internal(void)
{
@@ -47,6 +60,8 @@ eal_mcfg_update_from_internal(void)
mcfg->legacy_mem = internal_config.legacy_mem;
mcfg->single_file_segments = internal_config.single_file_segments;
+ /* record current DPDK version */
+ mcfg->version = RTE_VERSION;
}
void
diff --git a/lib/librte_eal/common/eal_memcfg.h b/lib/librte_eal/common/eal_memcfg.h
index 573233896..030f903ad 100644
--- a/lib/librte_eal/common/eal_memcfg.h
+++ b/lib/librte_eal/common/eal_memcfg.h
@@ -19,6 +19,8 @@
*/
struct rte_mem_config {
volatile uint32_t magic; /**< Magic number - sanity check. */
+ uint32_t version;
+ /**< Prevent secondary processes using different DPDK versions. */
/* memory topology */
uint32_t nchannel; /**< Number of channels (0 if unknown). */
@@ -81,6 +83,10 @@ eal_mcfg_update_from_internal(void);
void
eal_mcfg_wait_complete(void);
+/* check if DPDK version of current process matches one stored in the config */
+int
+eal_mcfg_check_version(void);
+
/* set mem config as complete */
void
eal_mcfg_complete(void);
diff --git a/lib/librte_eal/freebsd/eal/eal.c b/lib/librte_eal/freebsd/eal/eal.c
index ec1650c43..139d021d9 100644
--- a/lib/librte_eal/freebsd/eal/eal.c
+++ b/lib/librte_eal/freebsd/eal/eal.c
@@ -385,6 +385,10 @@ rte_config_init(void)
if (rte_eal_config_attach() < 0)
return -1;
eal_mcfg_wait_complete();
+ if (eal_mcfg_check_version() < 0) {
+ RTE_LOG(ERR, EAL, "Primary and secondary process DPDK version mismatch\n");
+ return -1;
+ }
if (rte_eal_config_reattach() < 0)
return -1;
eal_mcfg_update_internal();
diff --git a/lib/librte_eal/linux/eal/eal.c b/lib/librte_eal/linux/eal/eal.c
index 445d72f0c..47ac3b025 100644
--- a/lib/librte_eal/linux/eal/eal.c
+++ b/lib/librte_eal/linux/eal/eal.c
@@ -489,6 +489,10 @@ rte_config_init(void)
if (rte_eal_config_attach() < 0)
return -1;
eal_mcfg_wait_complete();
+ if (eal_mcfg_check_version() < 0) {
+ RTE_LOG(ERR, EAL, "Primary and secondary process DPDK version mismatch\n");
+ return -1;
+ }
if (rte_eal_config_reattach() < 0)
return -1;
eal_mcfg_update_internal();
--
2.17.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v4 1/3] lib/librte_ip_frag: remove IP checkum offload flag
@ 2019-07-08 4:32 9% ` jerinj
2019-07-08 9:07 3% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: jerinj @ 2019-07-08 4:32 UTC (permalink / raw)
To: dev, John McNamara, Marko Kovacevic, Konstantin Ananyev
Cc: thomas, Sunil Kumar Kori
From: Sunil Kumar Kori <skori@marvell.com>
Currently PKT_TX_IP_CKSUM is being set into mbuf->ol_flags
during fragmentation and reassemble operation implicitly.
Because of this, application is forced to use checksum offload
whether it is supported by platform or not.
Also documentation does not provide any expected value of ol_flags
in returned mbuf (reassembled or fragmented) so application will never
come to know that which offloads are enabled. So transmission may be failed
for the platforms which does not support checksum offload.
Also, IPv6 does not contain any checksum field in header so setting
mbuf->ol_flags with PKT_TX_IP_CKSUM is itself invalid.
So removing mentioned flag from the library.
Signed-off-by: Sunil Kumar Kori <skori@marvell.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
---
v4:
- Update release notes
---
doc/guides/rel_notes/release_19_08.rst | 15 +++++++++++++++
lib/librte_ip_frag/rte_ipv4_reassembly.c | 3 ---
lib/librte_ip_frag/rte_ipv6_reassembly.c | 3 ---
3 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_08.rst b/doc/guides/rel_notes/release_19_08.rst
index defbc5e27..ad9cbf4a2 100644
--- a/doc/guides/rel_notes/release_19_08.rst
+++ b/doc/guides/rel_notes/release_19_08.rst
@@ -281,6 +281,21 @@ ABI Changes
* bbdev: New operations and parameters added to support new 5GNR operations.
The bbdev ABI is still kept experimental.
+* ip_fragmentation: IP fragmentation library converts input mbuf into fragments
+ using input MTU size via ``rte_ipv4_fragment_packet`` interface.
+ Once fragmentation is done, each ``mbuf->ol_flags`` are set to enable IP
+ checksum H/W offload irrespective of the platform capability.
+ Cleared IP checksum H/W offload flag from the library. The application must
+ set this flag if it is supported by the platform and application wishes to
+ use it.
+
+* ip_reassembly: IP reassembly library converts the list of fragments into a
+ reassembled packet via ``rte_ipv4_frag_reassemble_packet`` interface.
+ Once reassembly is done, ``mbuf->ol_flags`` are set to enable IP checksum H/W
+ offload irrespective of the platform capability. Cleared IP checksum H/W
+ offload flag from the library. The application must set this flag if it is
+ supported by the platform and application wishes to use it.
+
Shared Library Versions
-----------------------
diff --git a/lib/librte_ip_frag/rte_ipv4_reassembly.c b/lib/librte_ip_frag/rte_ipv4_reassembly.c
index b7b92ed28..1dda8aca0 100644
--- a/lib/librte_ip_frag/rte_ipv4_reassembly.c
+++ b/lib/librte_ip_frag/rte_ipv4_reassembly.c
@@ -66,9 +66,6 @@ ipv4_frag_reassemble(struct ip_frag_pkt *fp)
m = fp->frags[IP_FIRST_FRAG_IDX].mb;
fp->frags[IP_FIRST_FRAG_IDX].mb = NULL;
- /* update mbuf fields for reassembled packet. */
- m->ol_flags |= PKT_TX_IP_CKSUM;
-
/* update ipv4 header for the reassembled packet */
ip_hdr = rte_pktmbuf_mtod_offset(m, struct rte_ipv4_hdr *, m->l2_len);
diff --git a/lib/librte_ip_frag/rte_ipv6_reassembly.c b/lib/librte_ip_frag/rte_ipv6_reassembly.c
index 169b01a5d..ad0105518 100644
--- a/lib/librte_ip_frag/rte_ipv6_reassembly.c
+++ b/lib/librte_ip_frag/rte_ipv6_reassembly.c
@@ -89,9 +89,6 @@ ipv6_frag_reassemble(struct ip_frag_pkt *fp)
m = fp->frags[IP_FIRST_FRAG_IDX].mb;
fp->frags[IP_FIRST_FRAG_IDX].mb = NULL;
- /* update mbuf fields for reassembled packet. */
- m->ol_flags |= PKT_TX_IP_CKSUM;
-
/* update ipv6 header for the reassembled datagram */
ip_hdr = rte_pktmbuf_mtod_offset(m, struct rte_ipv6_hdr *, m->l2_len);
--
2.22.0
^ permalink raw reply [relevance 9%]
* Re: [dpdk-dev] [PATCH] [v1]vhost: support inflight share memory protocol feature
2019-07-05 8:47 3% ` Maxime Coquelin
@ 2019-07-08 7:23 0% ` Yu, Jin
0 siblings, 0 replies; 200+ results
From: Yu, Jin @ 2019-07-08 7:23 UTC (permalink / raw)
To: Maxime Coquelin, dev; +Cc: Liu, Changpeng, LinLi, XunNi, YuZhang, Bie, Tiwei
> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com]
> Sent: Friday, July 5, 2019 4:47 PM
> To: Yu, Jin <jin.yu@intel.com>; dev@dpdk.org
> Cc: Liu, Changpeng <changpeng.liu@intel.com>; LinLi <lilin24@baidu.com>;
> XunNi <nixun@baidu.com>; YuZhang <zhangyu31@baidu.com>; Bie, Tiwei
> <tiwei.bie@intel.com>
> Subject: Re: [dpdk-dev] [PATCH] [v1]vhost: support inflight share memory
> protocol feature
>
> Hi Jin,
>
> On 6/26/19 6:38 PM, JinYu wrote:
> > This patch introduces two new messages VHOST_USER_GET_INFLIGHT_FD
> and
> > VHOST_USER_SET_INFLIGHT_FD to support transferring a shared buffer
> > between qemu and backend.
> >
> > Firstly, qemu uses VHOST_USER_GET_INFLIGHT_FD to get the shared buffer
> > from backend. Then qemu should send it back through
> > VHOST_USER_SET_INFLIGHT_FD each time we start vhost-user.
> >
> > This shared buffer is used to process inflight I/O when backend
> > reconnect.
> >
> > Signed-off-by: LinLi <lilin24@baidu.com>
> > Signed-off-by: XunNi <nixun@baidu.com>
> > Signed-off-by: YuZhang <zhangyu31@baidu.com>
> > Signed-off-by: JinYu <jin.yu@intel.com>
> > ---
> > V1 - specify the APIs are split-ring only
> > ---
> > lib/librte_vhost/rte_vhost.h | 99 +++++++++
> > lib/librte_vhost/rte_vhost_version.map | 4 +
> > lib/librte_vhost/vhost.c | 135 ++++++++++++
> > lib/librte_vhost/vhost.h | 12 +
> > lib/librte_vhost/vhost_user.c | 292 +++++++++++++++++++++++++
> > lib/librte_vhost/vhost_user.h | 13 +-
> > 6 files changed, 554 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/librte_vhost/rte_vhost.h
> > b/lib/librte_vhost/rte_vhost.h index 0226b3eff..c9959c15a 100644
> > --- a/lib/librte_vhost/rte_vhost.h
> > +++ b/lib/librte_vhost/rte_vhost.h
> > @@ -71,6 +71,10 @@ extern "C" {
> > #define VHOST_USER_PROTOCOL_F_HOST_NOTIFIER 11
> > #endif
> >
> > +#ifndef VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD
> > +#define VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD 12 #endif
> > +
> > /** Indicate whether protocol features negotiation is supported. */
> > #ifndef VHOST_USER_F_PROTOCOL_FEATURES
> > #define VHOST_USER_F_PROTOCOL_FEATURES 30
> > @@ -98,12 +102,41 @@ struct rte_vhost_memory {
> > struct rte_vhost_mem_region regions[];
> > };
> >
> > +struct inflight_desc_split {
> > + uint8_t inflight;
> > + uint8_t padding[5];
> > + uint16_t next;
> > + uint64_t counter;
> > +};
> > +
> > +struct inflight_info_split {
> > + uint64_t features;
> > + uint16_t version;
> > + uint16_t desc_num;
> > + uint16_t last_inflight_io;
> > + uint16_t used_idx;
> > + struct inflight_desc_split desc[0];
> > +};
> > +
> > +struct resubmit_desc {
> > + uint16_t index;
> > + uint64_t counter;
> > +};
> > +
> > +struct resubmit_info {
> > + struct resubmit_desc *resubmit_list;
> > + uint16_t resubmit_num;
> > +};
> > +
> > struct rte_vhost_vring {
> > struct vring_desc *desc;
> > struct vring_avail *avail;
> > struct vring_used *used;
> > uint64_t log_guest_addr;
> >
> > + struct inflight_info_split *inflight;
> > + struct resubmit_info *resubmit_inflight;
> > +
>
> This is breaking the ABI, and discussing with Tiwei, we think it could be
> avoided by defining its own structure of inflight and inflight resubmit
> pointers. More below:
So you means that define a new struct such as struct rte_vhost_inflight_ring?
>
> > /** Deprecated, use rte_vhost_vring_call() instead. */
> > int callfd;
> >
> > @@ -603,6 +636,22 @@ uint16_t rte_vhost_dequeue_burst(int vid,
> uint16_t queue_id,
> > */
> > int rte_vhost_get_mem_table(int vid, struct rte_vhost_memory **mem);
> >
> > +/**
> > + * Get guest vring info, including the vring address, vring size, inflight, etc.
> > + *
> > + * @param vid
> > + * vhost device ID
> > + * @param vring_idx
> > + * vring index
> > + * @param vring
> > + * the structure to hold the requested vring info
> > + * @return
> > + * 0 on success, -1 on failure
> > + */
> > +int __rte_experimental
> > +rte_vhost_get_vhost_vring_with_inflight_split(int vid, uint16_t vring_idx,
> > + struct rte_vhost_vring *vring);
>
> Here a new API is introduced to get vting info with inflight.
> It could be just changed to get only the inflight info. It means the caller would
> first call rte_vhost_get_vhost_vring() and then the new function, which I
> guess may be renamed to:
>
> rte_vhost_get_vhost_vring_inflight_split
Got It.
>
> Other than that, the patch looks good to me.
>
> (Next time, please run get_maintainer.sh script so that all the maintainers
> are in Cc:).
>
> Thanks,
> Maxime
Thanks Maxime, also I will submit an example code of vhost_user_blk which support the inflight feature.
It can show how these APIs work.
Thanks
Jin
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v4] net/i40e: i40e get link status update from ipn3ke
@ 2019-07-08 7:27 3% ` Zhang, Qi Z
0 siblings, 0 replies; 200+ results
From: Zhang, Qi Z @ 2019-07-08 7:27 UTC (permalink / raw)
To: Pei, Andy, dev
Cc: Wu, Jingjing, Xing, Beilei, Yigit, Ferruh, Xu, Rosen, Ye,
Xiaolong, Zhang, Roy Fan, stable
> -----Original Message-----
> From: Pei, Andy
> Sent: Monday, July 8, 2019 11:03 AM
> To: dev@dpdk.org
> Cc: Pei, Andy <andy.pei@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>; Wu,
> Jingjing <jingjing.wu@intel.com>; Xing, Beilei <beilei.xing@intel.com>; Yigit,
> Ferruh <ferruh.yigit@intel.com>; Xu, Rosen <rosen.xu@intel.com>; Ye,
> Xiaolong <xiaolong.ye@intel.com>; Zhang, Roy Fan
> <roy.fan.zhang@intel.com>; stable@dpdk.org
> Subject: [PATCH v4] net/i40e: i40e get link status update from ipn3ke
>
> Add switch_mode argument for i40e PF to specify the specific FPGA that i40e
> PF is connected to. i40e PF get link status update via the connected FPGA.
> Add switch_ethdev to rte_eth_dev_data to track the bind switch device.
> Try to bind i40e pf to switch device when i40e device is probed. If it fail to find
> correct switch device, bind will occur again when update i40e device link
> status.
>
> Signed-off-by: Andy Pei <andy.pei@intel.com>
.....
> diff --git a/lib/librte_ethdev/rte_ethdev_core.h
> b/lib/librte_ethdev/rte_ethdev_core.h
> index 2922d5b..62adc5c 100644
> --- a/lib/librte_ethdev/rte_ethdev_core.h
> +++ b/lib/librte_ethdev/rte_ethdev_core.h
> @@ -635,6 +635,10 @@ struct rte_eth_dev_data {
> /**< Switch-specific identifier.
> * Valid if RTE_ETH_DEV_REPRESENTOR in dev_flags.
> */
> + struct rte_eth_dev *switch_ethdev;
> + /* point to switch_ethdev specific by "switch_mode" in
> + * devargs
> + */
> } __rte_cache_aligned;
Missing below comment in previous review.
No need to add new field in rte_eth_dev_data to break ABI, you can just add to i40e specific structure: i40e_pf.
>
> /**
> --
> 1.8.3.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v4 1/3] lib/librte_ip_frag: remove IP checkum offload flag
2019-07-08 4:32 9% ` [dpdk-dev] [PATCH v4 1/3] lib/librte_ip_frag: remove IP checkum offload flag jerinj
@ 2019-07-08 9:07 3% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-07-08 9:07 UTC (permalink / raw)
To: jerinj, Sunil Kumar Kori
Cc: dev, John McNamara, Marko Kovacevic, Konstantin Ananyev
08/07/2019 06:32, jerinj@marvell.com:
> From: Sunil Kumar Kori <skori@marvell.com>
>
> Currently PKT_TX_IP_CKSUM is being set into mbuf->ol_flags
> during fragmentation and reassemble operation implicitly.
> Because of this, application is forced to use checksum offload
> whether it is supported by platform or not.
>
> Also documentation does not provide any expected value of ol_flags
> in returned mbuf (reassembled or fragmented) so application will never
> come to know that which offloads are enabled. So transmission may be failed
> for the platforms which does not support checksum offload.
>
> Also, IPv6 does not contain any checksum field in header so setting
> mbuf->ol_flags with PKT_TX_IP_CKSUM is itself invalid.
>
> So removing mentioned flag from the library.
>
> Signed-off-by: Sunil Kumar Kori <skori@marvell.com>
> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
Applied, thanks
PS: I move the release notes from ABI to API changes
as it is an API behaviour change.
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v8 4/7] app/test-compress-perf: add benchmark test case
@ 2019-07-08 18:16 3% ` Artur Trybula
0 siblings, 0 replies; 200+ results
From: Artur Trybula @ 2019-07-08 18:16 UTC (permalink / raw)
To: dev, fiona.trahe, shallyv, adamx.dybkowski, arturx.trybula, akhil.goyal
Cc: Tomasz Jozwiak, Tomasz Jozwiak
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 13608 bytes --]
From: Tomasz Jozwiak <tomaszx.jozwiak@intel.com>
This patch adds a benchmark part to
compression-perf-tool as a separate test case, which can be
executed multi-threaded.
Also updates release notes.
Signed-off-by: Tomasz Jozwiak <tjozwiakgm@gmail.com>
Signed-off-by: Tomasz Jozwiak <tomaszx.jozwiak@intel.com>
Acked-by: Artur Trybula <arturx.trybula@intel.com>
---
app/test-compress-perf/Makefile | 1 +
.../comp_perf_test_benchmark.c | 140 +++++++++++++-----
.../comp_perf_test_benchmark.h | 25 +++-
app/test-compress-perf/main.c | 1 +
app/test-compress-perf/meson.build | 1 +
doc/guides/rel_notes/release_19_08.rst | 27 ++++
6 files changed, 157 insertions(+), 38 deletions(-)
diff --git a/app/test-compress-perf/Makefile b/app/test-compress-perf/Makefile
index f54d9a4dd..d1a6820e6 100644
--- a/app/test-compress-perf/Makefile
+++ b/app/test-compress-perf/Makefile
@@ -13,6 +13,7 @@ CFLAGS += -O3
SRCS-y := main.c
SRCS-y += comp_perf_options_parse.c
SRCS-y += comp_perf_test_verify.c
+SRCS-y += comp_perf_test_benchmark.c
SRCS-y += comp_perf_test_common.c
include $(RTE_SDK)/mk/rte.app.mk
diff --git a/app/test-compress-perf/comp_perf_test_benchmark.c b/app/test-compress-perf/comp_perf_test_benchmark.c
index 5752906b3..e0f852bf0 100644
--- a/app/test-compress-perf/comp_perf_test_benchmark.c
+++ b/app/test-compress-perf/comp_perf_test_benchmark.c
@@ -10,11 +10,46 @@
#include "comp_perf_test_benchmark.h"
+void
+cperf_benchmark_test_destructor(void *arg)
+{
+ if (arg) {
+ comp_perf_free_memory(
+ &((struct cperf_benchmark_ctx *)arg)->ver.mem);
+ rte_free(arg);
+ }
+}
+
+void *
+cperf_benchmark_test_constructor(uint8_t dev_id, uint16_t qp_id,
+ struct comp_test_data *options)
+{
+ struct cperf_benchmark_ctx *ctx = NULL;
+
+ ctx = rte_malloc(NULL, sizeof(struct cperf_benchmark_ctx), 0);
+
+ if (ctx == NULL)
+ return NULL;
+
+ ctx->ver.mem.dev_id = dev_id;
+ ctx->ver.mem.qp_id = qp_id;
+ ctx->ver.options = options;
+ ctx->ver.silent = 1; /* ver. part will be silent */
+
+ if (!comp_perf_allocate_memory(ctx->ver.options, &ctx->ver.mem)
+ && !prepare_bufs(ctx->ver.options, &ctx->ver.mem))
+ return ctx;
+
+ cperf_benchmark_test_destructor(ctx);
+ return NULL;
+}
+
static int
-main_loop(struct comp_test_data *test_data, uint8_t level,
- enum rte_comp_xform_type type)
+main_loop(struct cperf_benchmark_ctx *ctx, enum rte_comp_xform_type type)
{
- uint8_t dev_id = test_data->cdev_id;
+ struct comp_test_data *test_data = ctx->ver.options;
+ struct cperf_mem_resources *mem = &ctx->ver.mem;
+ uint8_t dev_id = mem->dev_id;
uint32_t i, iter, num_iter;
struct rte_comp_op **ops, **deq_ops;
void *priv_xform = NULL;
@@ -31,7 +66,7 @@ main_loop(struct comp_test_data *test_data, uint8_t level,
}
ops = rte_zmalloc_socket(NULL,
- 2 * test_data->total_bufs * sizeof(struct rte_comp_op *),
+ 2 * mem->total_bufs * sizeof(struct rte_comp_op *),
0, rte_socket_id());
if (ops == NULL) {
@@ -40,7 +75,7 @@ main_loop(struct comp_test_data *test_data, uint8_t level,
return -1;
}
- deq_ops = &ops[test_data->total_bufs];
+ deq_ops = &ops[mem->total_bufs];
if (type == RTE_COMP_COMPRESS) {
xform = (struct rte_comp_xform) {
@@ -48,14 +83,14 @@ main_loop(struct comp_test_data *test_data, uint8_t level,
.compress = {
.algo = RTE_COMP_ALGO_DEFLATE,
.deflate.huffman = test_data->huffman_enc,
- .level = level,
+ .level = test_data->level,
.window_size = test_data->window_sz,
.chksum = RTE_COMP_CHECKSUM_NONE,
.hash_algo = RTE_COMP_HASH_ALGO_NONE
}
};
- input_bufs = test_data->decomp_bufs;
- output_bufs = test_data->comp_bufs;
+ input_bufs = mem->decomp_bufs;
+ output_bufs = mem->comp_bufs;
out_seg_sz = test_data->out_seg_sz;
} else {
xform = (struct rte_comp_xform) {
@@ -67,8 +102,8 @@ main_loop(struct comp_test_data *test_data, uint8_t level,
.hash_algo = RTE_COMP_HASH_ALGO_NONE
}
};
- input_bufs = test_data->comp_bufs;
- output_bufs = test_data->decomp_bufs;
+ input_bufs = mem->comp_bufs;
+ output_bufs = mem->decomp_bufs;
out_seg_sz = test_data->seg_sz;
}
@@ -82,13 +117,13 @@ main_loop(struct comp_test_data *test_data, uint8_t level,
uint64_t tsc_start, tsc_end, tsc_duration;
- tsc_start = tsc_end = tsc_duration = 0;
- tsc_start = rte_rdtsc();
num_iter = test_data->num_iter;
+ tsc_start = tsc_end = tsc_duration = 0;
+ tsc_start = rte_rdtsc_precise();
for (iter = 0; iter < num_iter; iter++) {
- uint32_t total_ops = test_data->total_bufs;
- uint32_t remaining_ops = test_data->total_bufs;
+ uint32_t total_ops = mem->total_bufs;
+ uint32_t remaining_ops = mem->total_bufs;
uint32_t total_deq_ops = 0;
uint32_t total_enq_ops = 0;
uint16_t ops_unused = 0;
@@ -113,7 +148,7 @@ main_loop(struct comp_test_data *test_data, uint8_t level,
/* Allocate compression operations */
if (ops_needed && !rte_comp_op_bulk_alloc(
- test_data->op_pool,
+ mem->op_pool,
&ops[ops_unused],
ops_needed)) {
RTE_LOG(ERR, USER1,
@@ -149,7 +184,8 @@ main_loop(struct comp_test_data *test_data, uint8_t level,
ops[op_id]->private_xform = priv_xform;
}
- num_enq = rte_compressdev_enqueue_burst(dev_id, 0, ops,
+ num_enq = rte_compressdev_enqueue_burst(dev_id,
+ mem->qp_id, ops,
num_ops);
if (num_enq == 0) {
struct rte_compressdev_stats stats;
@@ -165,7 +201,8 @@ main_loop(struct comp_test_data *test_data, uint8_t level,
remaining_ops -= num_enq;
total_enq_ops += num_enq;
- num_deq = rte_compressdev_dequeue_burst(dev_id, 0,
+ num_deq = rte_compressdev_dequeue_burst(dev_id,
+ mem->qp_id,
deq_ops,
test_data->burst_sz);
total_deq_ops += num_deq;
@@ -177,7 +214,7 @@ main_loop(struct comp_test_data *test_data, uint8_t level,
if (op->status !=
RTE_COMP_OP_STATUS_SUCCESS) {
RTE_LOG(ERR, USER1,
- "Some operations were not successful\n");
+ "Some operations were not successful\n");
goto end;
}
@@ -198,15 +235,17 @@ main_loop(struct comp_test_data *test_data, uint8_t level,
}
}
}
- rte_mempool_put_bulk(test_data->op_pool,
+ rte_mempool_put_bulk(mem->op_pool,
(void **)deq_ops, num_deq);
allocated -= num_deq;
}
/* Dequeue the last operations */
while (total_deq_ops < total_ops) {
- num_deq = rte_compressdev_dequeue_burst(dev_id, 0,
- deq_ops, test_data->burst_sz);
+ num_deq = rte_compressdev_dequeue_burst(dev_id,
+ mem->qp_id,
+ deq_ops,
+ test_data->burst_sz);
if (num_deq == 0) {
struct rte_compressdev_stats stats;
@@ -226,7 +265,7 @@ main_loop(struct comp_test_data *test_data, uint8_t level,
if (op->status !=
RTE_COMP_OP_STATUS_SUCCESS) {
RTE_LOG(ERR, USER1,
- "Some operations were not successful\n");
+ "Some operations were not successful\n");
goto end;
}
@@ -247,65 +286,92 @@ main_loop(struct comp_test_data *test_data, uint8_t level,
}
}
}
- rte_mempool_put_bulk(test_data->op_pool,
+ rte_mempool_put_bulk(mem->op_pool,
(void **)deq_ops, num_deq);
allocated -= num_deq;
}
}
- tsc_end = rte_rdtsc();
+ tsc_end = rte_rdtsc_precise();
tsc_duration = tsc_end - tsc_start;
if (type == RTE_COMP_COMPRESS)
- test_data->comp_tsc_duration[level] =
+ ctx->comp_tsc_duration[test_data->level] =
tsc_duration / num_iter;
else
- test_data->decomp_tsc_duration[level] =
+ ctx->decomp_tsc_duration[test_data->level] =
tsc_duration / num_iter;
end:
- rte_mempool_put_bulk(test_data->op_pool, (void **)ops, allocated);
+ rte_mempool_put_bulk(mem->op_pool, (void **)ops, allocated);
rte_compressdev_private_xform_free(dev_id, priv_xform);
rte_free(ops);
return res;
}
int
-cperf_benchmark(struct comp_test_data *test_data, uint8_t level)
+cperf_benchmark_test_runner(void *test_ctx)
{
+ struct cperf_benchmark_ctx *ctx = test_ctx;
+ struct comp_test_data *test_data = ctx->ver.options;
+ uint32_t lcore = rte_lcore_id();
+ static rte_atomic16_t display_once = RTE_ATOMIC16_INIT(0);
+
+ ctx->ver.mem.lcore_id = lcore;
int i, ret = EXIT_SUCCESS;
+ /*
+ * First the verification part is needed
+ */
+ if (cperf_verify_test_runner(&ctx->ver)) {
+ ret = EXIT_FAILURE;
+ goto end;
+ }
+
/*
* Run the tests twice, discarding the first performance
* results, before the cache is warmed up
*/
for (i = 0; i < 2; i++) {
- if (main_loop(test_data, level, RTE_COMP_COMPRESS) < 0) {
+ if (main_loop(ctx, RTE_COMP_COMPRESS) < 0) {
ret = EXIT_FAILURE;
goto end;
}
}
for (i = 0; i < 2; i++) {
- if (main_loop(test_data, level, RTE_COMP_DECOMPRESS) < 0) {
+ if (main_loop(ctx, RTE_COMP_DECOMPRESS) < 0) {
ret = EXIT_FAILURE;
goto end;
}
}
- test_data->comp_tsc_byte =
- (double)(test_data->comp_tsc_duration[level]) /
+ ctx->comp_tsc_byte =
+ (double)(ctx->comp_tsc_duration[test_data->level]) /
test_data->input_data_sz;
- test_data->decomp_tsc_byte =
- (double)(test_data->decomp_tsc_duration[level]) /
+ ctx->decomp_tsc_byte =
+ (double)(ctx->decomp_tsc_duration[test_data->level]) /
test_data->input_data_sz;
- test_data->comp_gbps = rte_get_tsc_hz() / test_data->comp_tsc_byte * 8 /
+ ctx->comp_gbps = rte_get_tsc_hz() / ctx->comp_tsc_byte * 8 /
+ 1000000000;
+
+ ctx->decomp_gbps = rte_get_tsc_hz() / ctx->decomp_tsc_byte * 8 /
1000000000;
- test_data->decomp_gbps = rte_get_tsc_hz() / test_data->decomp_tsc_byte
- * 8 / 1000000000;
+ if (rte_atomic16_test_and_set(&display_once)) {
+ printf("%12s%6s%12s%17s%15s%16s\n",
+ "lcore id", "Level", "Comp size", "Comp ratio [%]",
+ "Comp [Gbps]", "Decomp [Gbps]");
+ }
+
+ printf("%12u%6u%12zu%17.2f%15.2f%16.2f\n",
+ ctx->ver.mem.lcore_id,
+ test_data->level, ctx->ver.comp_data_sz, ctx->ver.ratio,
+ ctx->comp_gbps,
+ ctx->decomp_gbps);
+
end:
return ret;
}
diff --git a/app/test-compress-perf/comp_perf_test_benchmark.h b/app/test-compress-perf/comp_perf_test_benchmark.h
index b193445a3..d9b2694b8 100644
--- a/app/test-compress-perf/comp_perf_test_benchmark.h
+++ b/app/test-compress-perf/comp_perf_test_benchmark.h
@@ -5,9 +5,32 @@
#ifndef _COMP_PERF_TEST_BENCHMARK_
#define _COMP_PERF_TEST_BENCHMARK_
+#include <stdint.h>
+
#include "comp_perf_options.h"
+#include "comp_perf_test_common.h"
+#include "comp_perf_test_verify.h"
+
+struct cperf_benchmark_ctx {
+ struct cperf_verify_ctx ver;
+
+ /* Store TSC duration for all levels (including level 0) */
+ uint64_t comp_tsc_duration[RTE_COMP_LEVEL_MAX + 1];
+ uint64_t decomp_tsc_duration[RTE_COMP_LEVEL_MAX + 1];
+ double comp_gbps;
+ double decomp_gbps;
+ double comp_tsc_byte;
+ double decomp_tsc_byte;
+};
+
+void
+cperf_benchmark_test_destructor(void *arg);
int
-cperf_benchmark(struct comp_test_data *test_data, uint8_t level);
+cperf_benchmark_test_runner(void *test_ctx);
+
+void *
+cperf_benchmark_test_constructor(uint8_t dev_id, uint16_t qp_id,
+ struct comp_test_data *options);
#endif
diff --git a/app/test-compress-perf/main.c b/app/test-compress-perf/main.c
index 51ca9f5b7..dd6ef9a6d 100644
--- a/app/test-compress-perf/main.c
+++ b/app/test-compress-perf/main.c
@@ -9,6 +9,7 @@
#include "comp_perf_options.h"
#include "comp_perf_test_verify.h"
+#include "comp_perf_test_benchmark.h"
#include "comp_perf.h"
#include "comp_perf_test_common.h"
diff --git a/app/test-compress-perf/meson.build b/app/test-compress-perf/meson.build
index c6246e503..1136f04bc 100644
--- a/app/test-compress-perf/meson.build
+++ b/app/test-compress-perf/meson.build
@@ -5,5 +5,6 @@ allow_experimental_apis = true
sources = files('comp_perf_options_parse.c',
'main.c',
'comp_perf_test_verify.c',
+ 'comp_perf_test_benchmark.c',
'comp_perf_test_common.c')
deps = ['compressdev']
diff --git a/doc/guides/rel_notes/release_19_08.rst b/doc/guides/rel_notes/release_19_08.rst
index 8480112b9..ed7f6e250 100644
--- a/doc/guides/rel_notes/release_19_08.rst
+++ b/doc/guides/rel_notes/release_19_08.rst
@@ -190,6 +190,29 @@ New Features
Added telemetry mode to l3fwd-power application to report
application level busyness, empty and full polls of rte_eth_rx_burst().
+* **Updated the QuickAssist Technology (QAT) symmetric crypto PMD.**
+
+ Added support for digest-encrypted cases where digest is appended
+ to the data.
+
+* **Added a FPGA_LTE_FEC bbdev PMD.**
+
+ Added the new ``fpga_lte_fec`` bbdev driver for the Intel® FPGA PAC
+ (Programmable Acceleration Card) N3000. See the
+ :doc:`../bbdevs/fpga_lte_fec` BBDEV guide for more details on this new driver.
+
+* **Updated TURBO_SW bbdev PMD.**
+
+ Updated the ``turbo_sw`` bbdev driver with changes including:
+
+ * Added option to build the driver with or without dependency of external
+ SDK libraries.
+ * Added support for 5GNR encode/decode operations.
+
+* **Updated test-compress-perf tool application.**
+
+ Added multiple cores feature to compression perf tool application.
+
Removed Items
-------------
@@ -259,6 +282,10 @@ API Changes
offload flag from the library. The application must set this flag if it is
supported by the platform and application wishes to use it.
+* cryptodev: the ``uint8_t *data`` member of ``key`` structure in the xforms
+ structure (``rte_crypto_cipher_xform``, ``rte_crypto_auth_xform``, and
+ ``rte_crypto_aead_xform``) have been changed to ``const uint8_t *data``.
+
ABI Changes
-----------
--
2.17.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC] ethdev: support input set change by RSS action
2019-07-04 14:08 3% ` Adrien Mazarguil
@ 2019-07-09 5:41 3% ` Zhang, Qi Z
2019-07-09 8:19 0% ` Jerin Jacob Kollanukkaran
0 siblings, 1 reply; 200+ results
From: Zhang, Qi Z @ 2019-07-09 5:41 UTC (permalink / raw)
To: Adrien Mazarguil; +Cc: Su, Simei, Wu, Jingjing, Xing, Beilei, Yang, Qiming, dev
Hi Adrien:
> -----Original Message-----
> From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> Sent: Thursday, July 4, 2019 10:09 PM
> To: Zhang, Qi Z <qi.z.zhang@intel.com>
> Cc: Su, Simei <simei.su@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>;
> Xing, Beilei <beilei.xing@intel.com>; Yang, Qiming <qiming.yang@intel.com>;
> dev@dpdk.org
> Subject: Re: [dpdk-dev] [RFC] ethdev: support input set change by RSS action
>
> On Thu, Jul 04, 2019 at 01:55:14PM +0000, Zhang, Qi Z wrote:
> >
> >
> > > -----Original Message-----
> > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> > > Sent: Thursday, July 4, 2019 5:07 PM
> > > To: Su, Simei <simei.su@intel.com>
> > > Cc: Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing
> > > <jingjing.wu@intel.com>; Xing, Beilei <beilei.xing@intel.com>; Yang,
> > > Qiming <qiming.yang@intel.com>; dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [RFC] ethdev: support input set change by
> > > RSS action
> > >
> > > On Thu, Jul 04, 2019 at 12:47:09PM +0800, simei wrote:
> > > > From: Simei Su <simei.su@intel.com>
> > > >
> > > > This RFC introduces inputset structure to rte_flow_action_rss to
> > > > support input set specific configuration by rte_flow RSS action.
> > > >
> > > > We can give an testpmd command line example to make it more clear.
> > > >
> > > > For example, below flow selects the l4 port as inputset for any
> > > > eth/ipv4/tcp packet: #flow create 0 ingress pattern eth / ipv4 /
> > > > tcp / end actions rss inputset tcp src mask 0xffff dst mask 0xffff
> > > > /end
> > > >
> > > > Signed-off-by: Simei Su <simei.su@intel.com>
> > > > ---
> > > > lib/librte_ethdev/rte_flow.h | 3 +++
> > > > 1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/lib/librte_ethdev/rte_flow.h
> > > > b/lib/librte_ethdev/rte_flow.h index f3a8fb1..2a455b6 100644
> > > > --- a/lib/librte_ethdev/rte_flow.h
> > > > +++ b/lib/librte_ethdev/rte_flow.h
> > > > @@ -1796,6 +1796,9 @@ struct rte_flow_action_rss {
> > > > uint32_t queue_num; /**< Number of entries in @p queue. */
> > > > const uint8_t *key; /**< Hash key. */
> > > > const uint16_t *queue; /**< Queue indices to use. */
> > > > + struct rte_flow_item *inputset; /** Provide more specific
> > > > +inputset
> > > configuration.
> > > > + * ignore spec, only mask.
> > > > + */
> > > > };
> > > >
> > > > /**
> > >
> > > To make sure I understand, is this kind of a more flexible version
> > > of rte_flow_action_rss.types?
> >
> > Yes
> > >
> > > For instance while specifying .types = ETH_RSS_IPV4 normally covers
> > > both source and destination addresses, does this approach enable
> > > users to perform RSS on source IP only?
> >
> > Yes, .it is the case to select any subset of 5 tuples or even tunnel
> > header's id for hash
> >
> > > In which case, what value does the Toeplitz algorithm assume for the
> > > destination, 0x0? (note: must be documented)
> >
> > My understanding is src/dst pair is only required for a symmetric case
> > But for Toeplitz, it is just a hash function, it process a serial of
> > data with specific algorithm, have no idea about which part is src and dst , So
> for ip src only with Toeplitz, dst is not required to be a placeholder..
>
> Right, I had symmetric Toeplitz in mind and wondered what would happen
> when users would not select the required fields. I guess the PMD would have
> to reject unsupported combinations.
>
> > anything I missed, would you share more insight?
>
> No, that answers the question, thanks.
>
> Now what about my suggestion below? In short: extending ETH_RSS_*
> assuming there's enough bits left in there, instead of adding a whole new
> framework and breaking ABI in the process.
Since the hardware can support any combination of input set (not just 5 tuples), we'd like to make it more generic.
Those will be some pain due to ABI break, but we think its worth for long term.
Thanks
Qi
>
> > > My opinion is that, unless you know of a hardware which can perform
> > > RSS on random bytes of a packet, this approach is a bit overkill at this
> point.
> > >
> > > How about simply adding the needed ETH_RSS_* definitions (e.g.
> > > ETH_RSS_IPV4_(SRC|DST))? How many are needed?
> > >
> > > There are currently 20 used bits and struct
> > > rte_flow_action_rss.types is 64-bit wide. I'm sure we can manage
> > > something without harming the ABI. Even better, you wouldn't need a
> deprecation notice.
> > >
> > > If you use the suggested approach, please update testpmd and its
> > > documentation as part of the same patch, thanks.
>
> --
> Adrien Mazarguil
> 6WIND
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC] ethdev: support input set change by RSS action
2019-07-09 5:41 3% ` Zhang, Qi Z
@ 2019-07-09 8:19 0% ` Jerin Jacob Kollanukkaran
0 siblings, 0 replies; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-07-09 8:19 UTC (permalink / raw)
To: Zhang, Qi Z, Adrien Mazarguil
Cc: Su, Simei, Wu, Jingjing, Xing, Beilei, Yang, Qiming, dev
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Zhang, Qi Z
> Sent: Tuesday, July 9, 2019 11:11 AM
> To: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> Cc: Su, Simei <simei.su@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>;
> Xing, Beilei <beilei.xing@intel.com>; Yang, Qiming <qiming.yang@intel.com>;
> dev@dpdk.org
> Subject: Re: [dpdk-dev] [RFC] ethdev: support input set change by RSS action
> > Right, I had symmetric Toeplitz in mind and wondered what would happen
> > when users would not select the required fields. I guess the PMD would
> > have to reject unsupported combinations.
> >
> > > anything I missed, would you share more insight?
> >
> > No, that answers the question, thanks.
> >
> > Now what about my suggestion below? In short: extending ETH_RSS_*
> > assuming there's enough bits left in there, instead of adding a whole
> > new framework and breaking ABI in the process.
>
> Since the hardware can support any combination of input set (not just 5
> tuples), we'd like to make it more generic.
> Those will be some pain due to ABI break, but we think its worth for long
> term.
# IMO, The decided method should be compatible with normal RSS(without rte_flow) case
as well(Currently is struct rte_eth_conf.rx_adv_conf.rss_conf.rss_hf used
in the dev_configure()) as from HW perspective it will be same the HW block which does
both.
# From Marvell HW point of view, We can support any combination of input set.
But it is more of a micro code(i.e need to first provide the list protocol supported to HW)
and then use it latter. So, I think, extending the ETH_RSS_* would be more portable
approach __without loosing__ the functionality. Since there is around 40 bits are left, I think
more standard protocol can fit in the 40 bits.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 1/1] fbarray: get fbarrays from containerized secondary
@ 2019-07-09 10:26 4% ` Burakov, Anatoly
2019-07-11 9:37 0% ` Yasufumi Ogawa
0 siblings, 1 reply; 200+ results
From: Burakov, Anatoly @ 2019-07-09 10:26 UTC (permalink / raw)
To: Yasufumi Ogawa; +Cc: dev, stable
On 09-Jul-19 11:24 AM, Burakov, Anatoly wrote:
> On 09-Jul-19 11:22 AM, Yasufumi Ogawa wrote:
>> Hi Anatoly,
>>
>> On 2019/07/05 17:53, Burakov, Anatoly wrote:
>>> On 16-Apr-19 4:43 AM, ogawa.yasufumi@lab.ntt.co.jp wrote:
>>>> From: Yasufumi Ogawa <ogawa.yasufumi@lab.ntt.co.jp>
>>>>
>>>> In secondary_msl_create_walk(), it creates a file for fbarrays with its
>>>> PID for reserving unique name among secondary processes. However, it
>>>> does not work if secondary is run as app container because each of
>>>> containerized secondary has PID 1. To reserve unique name, use hostname
>>>> instead of PID if the value is 1.
>>>>
>>>> Cc: stable@dpdk.org
>>>>
>>>> Signed-off-by: Yasufumi Ogawa <ogawa.yasufumi@lab.ntt.co.jp>
>>>> ---
>>>
>>> I'm not too well versed in containers - is this hostname 1) always
>>> set, and 2) always unique?
>> For docker, 1) hostname is always set. 2) The hostname is decided as
>> short form of container ID, so it might not be unique even though very
>> low possibility.
>>
>> I found that we can get whole container ID in `/proc/self/cgroup` as
>> discussed [1]. I think using hostname is reasonable way without
>> running many secondary processes. However, it might be better to use
>> 64 digits full container ID instead of 12 digits short ID if ensure
>> uniqueness strongly. What do yo think?
>>
>> [1]
>> https://forums.docker.com/t/get-a-containers-full-id-from-inside-of-itself/37237
>>
>
> I think it's better to err on the side of caution and guarantee better
> uniqueness. This code will get into an LTS and will be used for years to
> come :)
>
...however, i think a full 64-digit ID won't even fit into the fbarray
filename, as i believe it's limited to something like 64 chars. Perhaps
hostname would be enough after all... or we can increase fbarray name
length - that would require ABI breakage but the ABI is already broken
in this release, so it's OK i think.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v2] devtools: better freebsd support
2019-07-05 13:58 6% ` [dpdk-dev] [PATCH v2] " Olivier Matz
@ 2019-07-09 11:05 0% ` Musatescu, Flavia
2019-07-11 14:25 6% ` [dpdk-dev] [PATCH v3] " Olivier Matz
1 sibling, 0 replies; 200+ results
From: Musatescu, Flavia @ 2019-07-09 11:05 UTC (permalink / raw)
To: Olivier Matz, dev; +Cc: Thomas Monjalon, David Marchand, Bruce Richardson
On 05/07/2019 14:58, Olivier Matz wrote:
> - As "readlink -e" and "readlink -m" do not exist on freebsd,
> use "readlink -f", it should not have any impact in these cases.
> - "sed -ri" is invalid on freebsd and should be replaced by
> "sed -ri=''"
> - Use gmake instead of make.
>
> This fixes the following command:
> SYSDIR=/usr/src/sys ./devtools/test-build.sh \
> -j4 x86_64-native-freebsd-gcc
>
> Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
> ---
>
> v2:
> - remove sed_ri() function and use 'sed -ri=""' as suggested by Bruce
>
> devtools/check-dup-includes.sh | 2 +-
> devtools/checkpatches.sh | 8 ++--
> devtools/get-maintainer.sh | 2 +-
> devtools/load-devel-config | 4 +-
> devtools/test-build.sh | 94 ++++++++++++++++++++++--------------------
> devtools/validate-abi.sh | 2 +-
> 6 files changed, 58 insertions(+), 54 deletions(-)
>
> diff --git a/devtools/check-dup-includes.sh b/devtools/check-dup-includes.sh
> index e4c2748c6..591599949 100755
> --- a/devtools/check-dup-includes.sh
> +++ b/devtools/check-dup-includes.sh
> @@ -5,7 +5,7 @@
> # Check C files in git repository for duplicated includes.
> # Usage: devtools/check-dup-includes.sh [directory]
>
> -dir=${1:-$(dirname $(readlink -m $0))/..}
> +dir=${1:-$(dirname $(readlink -f $0))/..}
> cd $dir
>
> # speed up by ignoring Unicode details
> diff --git a/devtools/checkpatches.sh b/devtools/checkpatches.sh
> index 560e6ce93..8e2beee16 100755
> --- a/devtools/checkpatches.sh
> +++ b/devtools/checkpatches.sh
> @@ -7,9 +7,9 @@
> # - DPDK_CHECKPATCH_CODESPELL
> # - DPDK_CHECKPATCH_LINE_LENGTH
> # - DPDK_CHECKPATCH_OPTIONS
> -. $(dirname $(readlink -e $0))/load-devel-config
> +. $(dirname $(readlink -f $0))/load-devel-config
>
> -VALIDATE_NEW_API=$(dirname $(readlink -e $0))/check-symbol-change.sh
> +VALIDATE_NEW_API=$(dirname $(readlink -f $0))/check-symbol-change.sh
>
> # Enable codespell by default. This can be overwritten from a config file.
> # Codespell can also be enabled by setting DPDK_CHECKPATCH_CODESPELL to a valid path
> @@ -66,7 +66,7 @@ check_forbidden_additions() { # <patch>
> -v EXPRESSIONS="rte_panic\\\( rte_exit\\\(" \
> -v RET_ON_FAIL=1 \
> -v MESSAGE='Using rte_panic/rte_exit' \
> - -f $(dirname $(readlink -e $0))/check-forbidden-tokens.awk \
> + -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
> "$1" || res=1
>
> # svg figures must be included with wildcard extension
> @@ -75,7 +75,7 @@ check_forbidden_additions() { # <patch>
> -v EXPRESSIONS='::[[:space:]]*[^[:space:]]*\\.svg' \
> -v RET_ON_FAIL=1 \
> -v MESSAGE='Using explicit .svg extension instead of .*' \
> - -f $(dirname $(readlink -e $0))/check-forbidden-tokens.awk \
> + -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
> "$1" || res=1
>
> return $res
> diff --git a/devtools/get-maintainer.sh b/devtools/get-maintainer.sh
> index b9160486a..85740f5af 100755
> --- a/devtools/get-maintainer.sh
> +++ b/devtools/get-maintainer.sh
> @@ -5,7 +5,7 @@
>
> # Load config options:
> # - DPDK_GETMAINTAINER_PATH
> -. $(dirname $(readlink -e $0))/load-devel-config
> +. $(dirname $(readlink -f $0))/load-devel-config
>
> options="--no-git-fallback"
> options="$options --no-rolestats"
> diff --git a/devtools/load-devel-config b/devtools/load-devel-config
> index 4f43cb352..380c79db4 100644
> --- a/devtools/load-devel-config
> +++ b/devtools/load-devel-config
> @@ -6,7 +6,7 @@ test ! -r /etc/dpdk/devel.config ||
> test ! -r ~/.config/dpdk/devel.config ||
> . ~/.config/dpdk/devel.config
> # from local file
> -test ! -r $(dirname $(readlink -m $0))/../.develconfig ||
> - . $(dirname $(readlink -m $0))/../.develconfig
> +test ! -r $(dirname $(readlink -f $0))/../.develconfig ||
> + . $(dirname $(readlink -f $0))/../.develconfig
>
> # The config files must export variables in the shell style
> diff --git a/devtools/test-build.sh b/devtools/test-build.sh
> index 9b50bf73d..22d409bb0 100755
> --- a/devtools/test-build.sh
> +++ b/devtools/test-build.sh
> @@ -28,7 +28,7 @@ default_path=$PATH
> # - LIBSSO_SNOW3G_PATH
> # - LIBSSO_KASUMI_PATH
> # - LIBSSO_ZUC_PATH
> -. $(dirname $(readlink -e $0))/load-devel-config
> +. $(dirname $(readlink -f $0))/load-devel-config
>
> print_usage () {
> echo "usage: $(basename $0) [-h] [-jX] [-s] [config1 [config2] ...]]"
> @@ -57,6 +57,10 @@ print_help () {
> END_OF_HELP
> }
>
> +[ -z $MAKE ] && command -v gmake > /dev/null && MAKE=gmake
> +[ -z $MAKE ] && command -v make > /dev/null && MAKE=make
> +[ -z $MAKE ] && echo "Cannot find make or gmake" && exit 1
> +
> J=$DPDK_MAKE_JOBS
> short=false
> unset verbose
> @@ -90,7 +94,7 @@ trap "signal=INT ; trap - INT ; kill -INT $$" INT
> # notify result on exit
> trap on_exit EXIT
>
> -cd $(dirname $(readlink -m $0))/..
> +cd $(dirname $(readlink -f $0))/..
>
> reset_env ()
> {
> @@ -127,83 +131,83 @@ config () # <directory> <target> <options>
> fi
> if [ ! -e $1/.config ] || $reconfig ; then
> echo "================== Configure $1"
> - make T=$2 O=$1 config
> + ${MAKE} T=$2 O=$1 config
>
> echo 'Customize configuration'
> # Built-in options (lowercase)
> ! echo $3 | grep -q '+default' || \
> - sed -ri 's,(RTE_MACHINE=")native,\1default,' $1/.config
> + sed -ri="" 's,(RTE_MACHINE=")native,\1default,' $1/.config
> echo $3 | grep -q '+next' || \
> - sed -ri 's,(NEXT_ABI=)y,\1n,' $1/.config
> + sed -ri="" 's,(NEXT_ABI=)y,\1n,' $1/.config
> ! echo $3 | grep -q '+shared' || \
> - sed -ri 's,(SHARED_LIB=)n,\1y,' $1/.config
> + sed -ri="" 's,(SHARED_LIB=)n,\1y,' $1/.config
> ! echo $3 | grep -q '+debug' || ( \
> - sed -ri 's,(RTE_LOG_DP_LEVEL=).*,\1RTE_LOG_DEBUG,' $1/.config
> - sed -ri 's,(_DEBUG.*=)n,\1y,' $1/.config
> - sed -ri 's,(_STAT.*=)n,\1y,' $1/.config
> - sed -ri 's,(TEST_PMD_RECORD_.*=)n,\1y,' $1/.config )
> + sed -ri="" 's,(RTE_LOG_DP_LEVEL=).*,\1RTE_LOG_DEBUG,' $1/.config
> + sed -ri="" 's,(_DEBUG.*=)n,\1y,' $1/.config
> + sed -ri="" 's,(_STAT.*=)n,\1y,' $1/.config
> + sed -ri="" 's,(TEST_PMD_RECORD_.*=)n,\1y,' $1/.config )
>
> # Automatic configuration
> test "$DPDK_DEP_NUMA" != n || \
> - sed -ri 's,(NUMA.*=)y,\1n,' $1/.config
> - sed -ri 's,(LIBRTE_IEEE1588=)n,\1y,' $1/.config
> - sed -ri 's,(BYPASS=)n,\1y,' $1/.config
> + sed -ri="" 's,(NUMA.*=)y,\1n,' $1/.config
> + sed -ri="" 's,(LIBRTE_IEEE1588=)n,\1y,' $1/.config
> + sed -ri="" 's,(BYPASS=)n,\1y,' $1/.config
> test "$DPDK_DEP_ARCHIVE" != y || \
> - sed -ri 's,(RESOURCE_TAR=)n,\1y,' $1/.config
> + sed -ri="" 's,(RESOURCE_TAR=)n,\1y,' $1/.config
> test "$DPDK_DEP_ISAL" != y || \
> - sed -ri 's,(PMD_ISAL=)n,\1y,' $1/.config
> + sed -ri="" 's,(PMD_ISAL=)n,\1y,' $1/.config
> test "$DPDK_DEP_MLX" != y || \
> - sed -ri 's,(MLX._PMD=)n,\1y,' $1/.config
> + sed -ri="" 's,(MLX._PMD=)n,\1y,' $1/.config
> test "$DPDK_DEP_SZE" != y || \
> - sed -ri 's,(PMD_SZEDATA2=)n,\1y,' $1/.config
> + sed -ri="" 's,(PMD_SZEDATA2=)n,\1y,' $1/.config
> test "$DPDK_DEP_ZLIB" != y || \
> - sed -ri 's,(BNX2X_PMD=)n,\1y,' $1/.config
> + sed -ri="" 's,(BNX2X_PMD=)n,\1y,' $1/.config
> test "$DPDK_DEP_ZLIB" != y || \
> - sed -ri 's,(PMD_ZLIB=)n,\1y,' $1/.config
> + sed -ri="" 's,(PMD_ZLIB=)n,\1y,' $1/.config
> test "$DPDK_DEP_ZLIB" != y || \
> - sed -ri 's,(COMPRESSDEV_TEST=)n,\1y,' $1/.config
> + sed -ri="" 's,(COMPRESSDEV_TEST=)n,\1y,' $1/.config
> test "$DPDK_DEP_PCAP" != y || \
> - sed -ri 's,(PCAP=)n,\1y,' $1/.config
> + sed -ri="" 's,(PCAP=)n,\1y,' $1/.config
> test -z "$ARMV8_CRYPTO_LIB_PATH" || \
> - sed -ri 's,(PMD_ARMV8_CRYPTO=)n,\1y,' $1/.config
> + sed -ri="" 's,(PMD_ARMV8_CRYPTO=)n,\1y,' $1/.config
> test "$DPDK_DEP_IPSEC_MB" != y || \
> - sed -ri 's,(PMD_AESNI_MB=)n,\1y,' $1/.config
> + sed -ri="" 's,(PMD_AESNI_MB=)n,\1y,' $1/.config
> test "$DPDK_DEP_IPSEC_MB" != y || \
> - sed -ri 's,(PMD_AESNI_GCM=)n,\1y,' $1/.config
> + sed -ri="" 's,(PMD_AESNI_GCM=)n,\1y,' $1/.config
> test -z "$LIBSSO_SNOW3G_PATH" || \
> - sed -ri 's,(PMD_SNOW3G=)n,\1y,' $1/.config
> + sed -ri="" 's,(PMD_SNOW3G=)n,\1y,' $1/.config
> test -z "$LIBSSO_KASUMI_PATH" || \
> - sed -ri 's,(PMD_KASUMI=)n,\1y,' $1/.config
> + sed -ri="" 's,(PMD_KASUMI=)n,\1y,' $1/.config
> test -z "$LIBSSO_ZUC_PATH" || \
> - sed -ri 's,(PMD_ZUC=)n,\1y,' $1/.config
> + sed -ri="" 's,(PMD_ZUC=)n,\1y,' $1/.config
> test "$DPDK_DEP_SSL" != y || \
> - sed -ri 's,(PMD_CCP=)n,\1y,' $1/.config
> + sed -ri="" 's,(PMD_CCP=)n,\1y,' $1/.config
> test "$DPDK_DEP_SSL" != y || \
> - sed -ri 's,(PMD_OPENSSL=)n,\1y,' $1/.config
> + sed -ri="" 's,(PMD_OPENSSL=)n,\1y,' $1/.config
> test "$DPDK_DEP_SSL" != y || \
> - sed -ri 's,(QAT_SYM=)n,\1y,' $1/.config
> + sed -ri="" 's,(QAT_SYM=)n,\1y,' $1/.config
> test -z "$FLEXRAN_SDK" || \
> - sed -ri 's,(BBDEV_TURBO_SW=)n,\1y,' $1/.config
> - sed -ri 's,(SCHED_.*=)n,\1y,' $1/.config
> + sed -ri="" 's,(BBDEV_TURBO_SW=)n,\1y,' $1/.config
> + sed -ri="" 's,(SCHED_.*=)n,\1y,' $1/.config
> test -z "$LIBMUSDK_PATH" || \
> - sed -ri 's,(PMD_MVSAM_CRYPTO=)n,\1y,' $1/.config
> + sed -ri="" 's,(PMD_MVSAM_CRYPTO=)n,\1y,' $1/.config
> test -z "$LIBMUSDK_PATH" || \
> - sed -ri 's,(MVPP2_PMD=)n,\1y,' $1/.config
> + sed -ri="" 's,(MVPP2_PMD=)n,\1y,' $1/.config
> test -z "$LIBMUSDK_PATH" || \
> - sed -ri 's,(MVNETA_PMD=)n,\1y,' $1/.config
> + sed -ri="" 's,(MVNETA_PMD=)n,\1y,' $1/.config
> test "$DPDK_DEP_ELF" != y || \
> - sed -ri 's,(BPF_ELF=)n,\1y,' $1/.config
> + sed -ri="" 's,(BPF_ELF=)n,\1y,' $1/.config
> test "$DPDK_DEP_JSON" != y || \
> - sed -ri 's,(TELEMETRY=)n,\1y,' $1/.config
> + sed -ri="" 's,(TELEMETRY=)n,\1y,' $1/.config
> build_config_hook $1 $2 $3
>
> # Explicit enabler/disabler (uppercase)
> for option in $(echo $3 | sed 's,[~+], &,g') ; do
> pattern=$(echo $option | cut -c2-)
> if echo $option | grep -q '^~' ; then
> - sed -ri "s,($pattern=)y,\1n," $1/.config
> + sed -ri="" "s,($pattern=)y,\1n," $1/.config
> elif echo $option | grep -q '^+' ; then
> - sed -ri "s,($pattern=)n,\1y," $1/.config
> + sed -ri="" "s,($pattern=)n,\1y," $1/.config
> fi
> done
> fi
> @@ -220,22 +224,22 @@ for conf in $configs ; do
> # reload config with DPDK_TARGET set
> DPDK_TARGET=$target
> reset_env
> - . $(dirname $(readlink -e $0))/load-devel-config
> + . $(dirname $(readlink -f $0))/load-devel-config
>
> options=$(echo $conf | sed 's,[^~+]*,,')
> dir=$conf
> config $dir $target $options
>
> echo "================== Build $dir"
> - make -j$J EXTRA_CFLAGS="$maxerr $DPDK_DEP_CFLAGS" \
> + ${MAKE} -j$J EXTRA_CFLAGS="$maxerr $DPDK_DEP_CFLAGS" \
> EXTRA_LDFLAGS="$DPDK_DEP_LDFLAGS" $verbose O=$dir
> ! $short || break
> echo "================== Build examples for $dir"
> export RTE_SDK=$(pwd)
> export RTE_TARGET=$dir
> - make -j$J -sC examples \
> + ${MAKE} -j$J -sC examples \
> EXTRA_LDFLAGS="$DPDK_DEP_LDFLAGS" $verbose \
> - O=$(readlink -m $dir/examples)
> + O=$(readlink -f $dir/examples)
> unset RTE_TARGET
> echo "################## $dir done."
> unset dir
> @@ -244,9 +248,9 @@ done
> if ! $short ; then
> mkdir -p .check
> echo "================== Build doxygen HTML API"
> - make doc-api-html >/dev/null 2>.check/doc.txt
> + ${MAKE} doc-api-html >/dev/null 2>.check/doc.txt
> echo "================== Build sphinx HTML guides"
> - make doc-guides-html >/dev/null 2>>.check/doc.txt
> + ${MAKE} doc-guides-html >/dev/null 2>>.check/doc.txt
> echo "================== Check docs"
> diff -u /dev/null .check/doc.txt
> fi
> diff --git a/devtools/validate-abi.sh b/devtools/validate-abi.sh
> index 138436d93..f64e19d38 100755
> --- a/devtools/validate-abi.sh
> +++ b/devtools/validate-abi.sh
> @@ -181,7 +181,7 @@ case "${dst}" in
> /*) ;;
> *) dst=${PWD}/${dst} ;;
> esac
> -dpdkroot=$(readlink -e $(dirname $0)/..)
> +dpdkroot=$(readlink -f $(dirname $0)/..)
>
> if [ -e "${dst}" -a "$force" = 0 ]; then
> echo "The ${dst} directory is not empty. Remove it, use another
The example applications are being built in a wrong location when using
the test-build.sh script on FreeBSD
(“/app_name/x86_64-native-freebsd-gcc/” instead of
“$(dpdk_path)/x86_64-native-freebsd-gcc/examples/app_name/x86_64-native-freebsd-gcc/”.
The output build directory for the example applications is specified by
O=$(readlink -f $dir/examples) variable inside the test-build.sh script.
On FreeBSD "readlink -f" prints nothing when the file path doesn't
exist, so the output build directory for each application ends up being
configured to "/./app_name/x86_64-native-freebsd-gcc" (this is done
inside the mk/rte.extsubdir.mk file).
A possible solution for this could be to modify the output directory to
O=$(readlink -f $dir)/examples.
Best Regards,
Flavia
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH] doc: deprecation notice for change of ether struct alignment
@ 2019-07-09 14:58 5% Bruce Richardson
2019-07-09 14:59 0% ` Stephen Hemminger
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2019-07-09 14:58 UTC (permalink / raw)
To: dev; +Cc: thomas, stephen, olivier.matz, Bruce Richardson
The ethernet address structure alignment will be changed to 2B alignment in
19.11. Flag this to users.
Impact is expected to be minimal for this change since ethernet addresses
are generally 2B aligned anyway.
Signed-off-by: Bruce Richardson <bruce.richardson@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 a7796f49b..7a04b9b09 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -11,6 +11,11 @@ API and ABI deprecation notices are to be posted here.
Deprecation Notices
-------------------
+* net: The alignment of the ethernet address structure in DPDK,
+ ``rte_ether_addr`` will be increased to two, i.e. 16-bit aligned, in the
+ 19.11 release. This will only affect any data structures where an ethernet
+ address is currently aligned on a single byte boundary.
+
* meson: The minimum supported version of meson for configuring and building
DPDK will be increased to v0.47.1 (from 0.41) from DPDK 19.05 onwards. For
those users with a version earlier than 0.47.1, an updated copy of meson
--
2.21.0
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH] doc: deprecation notice for change of ether struct alignment
2019-07-09 14:58 5% [dpdk-dev] [PATCH] doc: deprecation notice for change of ether struct alignment Bruce Richardson
@ 2019-07-09 14:59 0% ` Stephen Hemminger
2019-07-09 15:02 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-07-09 14:59 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev, thomas, olivier.matz
On Tue, 9 Jul 2019 15:58:36 +0100
Bruce Richardson <bruce.richardson@intel.com> wrote:
> The ethernet address structure alignment will be changed to 2B alignment in
> 19.11. Flag this to users.
>
> Impact is expected to be minimal for this change since ethernet addresses
> are generally 2B aligned anyway.
>
> Signed-off-by: Bruce Richardson <bruce.richardson@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 a7796f49b..7a04b9b09 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -11,6 +11,11 @@ API and ABI deprecation notices are to be posted here.
> Deprecation Notices
> -------------------
>
> +* net: The alignment of the ethernet address structure in DPDK,
> + ``rte_ether_addr`` will be increased to two, i.e. 16-bit aligned, in the
> + 19.11 release. This will only affect any data structures where an ethernet
> + address is currently aligned on a single byte boundary.
> +
> * meson: The minimum supported version of meson for configuring and building
> DPDK will be increased to v0.47.1 (from 0.41) from DPDK 19.05 onwards. For
> those users with a version earlier than 0.47.1, an updated copy of meson
We should also take the packed off of ether_header and ether_addr.
Packed is meaningless on ether_addr anyway.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] doc: deprecation notice for change of ether struct alignment
2019-07-09 14:59 0% ` Stephen Hemminger
@ 2019-07-09 15:02 0% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2019-07-09 15:02 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev, thomas, olivier.matz
On Tue, Jul 09, 2019 at 07:59:53AM -0700, Stephen Hemminger wrote:
> On Tue, 9 Jul 2019 15:58:36 +0100
> Bruce Richardson <bruce.richardson@intel.com> wrote:
>
> > The ethernet address structure alignment will be changed to 2B alignment in
> > 19.11. Flag this to users.
> >
> > Impact is expected to be minimal for this change since ethernet addresses
> > are generally 2B aligned anyway.
> >
> > Signed-off-by: Bruce Richardson <bruce.richardson@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 a7796f49b..7a04b9b09 100644
> > --- a/doc/guides/rel_notes/deprecation.rst
> > +++ b/doc/guides/rel_notes/deprecation.rst
> > @@ -11,6 +11,11 @@ API and ABI deprecation notices are to be posted here.
> > Deprecation Notices
> > -------------------
> >
> > +* net: The alignment of the ethernet address structure in DPDK,
> > + ``rte_ether_addr`` will be increased to two, i.e. 16-bit aligned, in the
> > + 19.11 release. This will only affect any data structures where an ethernet
> > + address is currently aligned on a single byte boundary.
> > +
> > * meson: The minimum supported version of meson for configuring and building
> > DPDK will be increased to v0.47.1 (from 0.41) from DPDK 19.05 onwards. For
> > those users with a version earlier than 0.47.1, an updated copy of meson
>
> We should also take the packed off of ether_header and ether_addr.
> Packed is meaningless on ether_addr anyway.
Agreed. However, I don't think that needs to be called out here as it's a
code change with zero impact. The user-impacting change is the alignment
one.
/Bruce
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [RFC] mbuf: support dynamic fields and flags
@ 2019-07-10 9:29 4% Olivier Matz
2019-07-10 17:14 0% ` Wang, Haiyue
` (3 more replies)
0 siblings, 4 replies; 200+ results
From: Olivier Matz @ 2019-07-10 9:29 UTC (permalink / raw)
To: dev
Many features require to store data inside the mbuf. As the room in mbuf
structure is limited, it is not possible to have a field for each
feature. Also, changing fields in the mbuf structure can break the API
or ABI.
This commit addresses these issues, by enabling the dynamic registration
of fields or flags:
- a dynamic field is a named area in the rte_mbuf structure, with a
given size (>= 1 byte) and alignment constraint.
- a dynamic flag is a named bit in the rte_mbuf structure.
The typical use case is a PMD that registers space for an offload
feature, when the application requests to enable this feature. As
the space in mbuf is limited, the space should only be reserved if it
is going to be used (i.e when the application explicitly asks for it).
The registration can be done at any moment, but it is not possible
to unregister fields or flags for now.
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
---
app/test/test_mbuf.c | 83 +++++++-
lib/librte_mbuf/Makefile | 2 +
lib/librte_mbuf/meson.build | 6 +-
lib/librte_mbuf/rte_mbuf.h | 25 ++-
lib/librte_mbuf/rte_mbuf_dyn.c | 373 +++++++++++++++++++++++++++++++++++
lib/librte_mbuf/rte_mbuf_dyn.h | 119 +++++++++++
lib/librte_mbuf/rte_mbuf_version.map | 4 +
7 files changed, 607 insertions(+), 5 deletions(-)
create mode 100644 lib/librte_mbuf/rte_mbuf_dyn.c
create mode 100644 lib/librte_mbuf/rte_mbuf_dyn.h
diff --git a/app/test/test_mbuf.c b/app/test/test_mbuf.c
index 2a97afe20..8008cc766 100644
--- a/app/test/test_mbuf.c
+++ b/app/test/test_mbuf.c
@@ -28,6 +28,7 @@
#include <rte_random.h>
#include <rte_cycles.h>
#include <rte_malloc.h>
+#include <rte_mbuf_dyn.h>
#include "test.h"
@@ -502,7 +503,6 @@ test_attach_from_different_pool(struct rte_mempool *pktmbuf_pool,
rte_pktmbuf_free(clone2);
return -1;
}
-#undef GOTO_FAIL
/*
* test allocation and free of mbufs
@@ -1122,6 +1122,81 @@ test_tx_offload(void)
}
static int
+test_mbuf_dyn(struct rte_mempool *pktmbuf_pool)
+{
+ struct rte_mbuf *m = NULL;
+ int offset, offset2;
+ int flag, flag2;
+
+ offset = rte_mbuf_dynfield_register("test-dynfield", sizeof(uint8_t),
+ __alignof__(uint8_t), 0);
+ if (offset == -1)
+ GOTO_FAIL("failed to register dynamic field, offset=%d: %s",
+ offset, strerror(errno));
+
+ offset2 = rte_mbuf_dynfield_register("test-dynfield", sizeof(uint8_t),
+ __alignof__(uint8_t), 0);
+ if (offset2 != offset)
+ GOTO_FAIL("failed to lookup dynamic field, offset=%d, offset2=%d: %s",
+ offset, offset2, strerror(errno));
+
+ offset2 = rte_mbuf_dynfield_register("test-dynfield2", sizeof(uint16_t),
+ __alignof__(uint16_t), 0);
+ if (offset2 == -1 || offset2 == offset || (offset & 1))
+ GOTO_FAIL("failed to register dynfield field 2, offset=%d, offset2=%d: %s",
+ offset, offset2, strerror(errno));
+
+ printf("offset = %d, offset2 = %d\n", offset, offset2);
+
+ offset = rte_mbuf_dynfield_register("test-dynfield-fail", 256, 1, 0);
+ if (offset != -1)
+ GOTO_FAIL("dynamic field creation should fail (too big)");
+
+ offset = rte_mbuf_dynfield_register("test-dynfield-fail", 1, 3, 0);
+ if (offset != -1)
+ GOTO_FAIL("dynamic field creation should fail (bad alignment)");
+
+ flag = rte_mbuf_dynflag_register("test-dynflag");
+ if (flag == -1)
+ GOTO_FAIL("failed to register dynamic field, flag=%d: %s",
+ flag, strerror(errno));
+
+ flag2 = rte_mbuf_dynflag_register("test-dynflag");
+ if (flag2 != flag)
+ GOTO_FAIL("failed to lookup dynamic field, flag=%d, flag2=%d: %s",
+ flag, flag2, strerror(errno));
+
+ flag2 = rte_mbuf_dynflag_register("test-dynflag2");
+ if (flag2 == -1 || flag2 == flag)
+ GOTO_FAIL("failed to register dynflag field 2, flag=%d, flag2=%d: %s",
+ flag, flag2, strerror(errno));
+
+ printf("flag = %d, flag2 = %d\n", flag, flag2);
+
+ /* set, get dynamic field */
+ m = rte_pktmbuf_alloc(pktmbuf_pool);
+ if (m == NULL)
+ GOTO_FAIL("Cannot allocate mbuf");
+
+ *RTE_MBUF_DYNFIELD(m, offset, uint8_t *) = 1;
+ if (*RTE_MBUF_DYNFIELD(m, offset, uint8_t *) != 1)
+ GOTO_FAIL("failed to read dynamic field");
+ *RTE_MBUF_DYNFIELD(m, offset2, uint16_t *) = 1000;
+ if (*RTE_MBUF_DYNFIELD(m, offset2, uint16_t *) != 1000)
+ GOTO_FAIL("failed to read dynamic field");
+
+ /* set a dynamic flag */
+ m->ol_flags |= (1ULL << flag);
+
+ rte_pktmbuf_free(m);
+ return 0;
+fail:
+ rte_pktmbuf_free(m);
+ return -1;
+}
+#undef GOTO_FAIL
+
+static int
test_mbuf(void)
{
int ret = -1;
@@ -1140,6 +1215,12 @@ test_mbuf(void)
goto err;
}
+ /* test registration of dynamic fields and flags */
+ if (test_mbuf_dyn(pktmbuf_pool) < 0) {
+ printf("mbuf dynflag test failed\n");
+ goto err;
+ }
+
/* create a specific pktmbuf pool with a priv_size != 0 and no data
* room size */
pktmbuf_pool2 = rte_pktmbuf_pool_create("test_pktmbuf_pool2",
diff --git a/lib/librte_mbuf/Makefile b/lib/librte_mbuf/Makefile
index c8f6d2689..5a9bcee73 100644
--- a/lib/librte_mbuf/Makefile
+++ b/lib/librte_mbuf/Makefile
@@ -17,8 +17,10 @@ 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
+SRCS-$(CONFIG_RTE_LIBRTE_MBUF) += rte_mbuf_dyn.c
# install includes
SYMLINK-$(CONFIG_RTE_LIBRTE_MBUF)-include := rte_mbuf.h rte_mbuf_ptype.h rte_mbuf_pool_ops.h
+SYMLINK-$(CONFIG_RTE_LIBRTE_MBUF)-include += rte_mbuf_dyn.h
include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_mbuf/meson.build b/lib/librte_mbuf/meson.build
index 6cc11ebb4..9137e8f26 100644
--- a/lib/librte_mbuf/meson.build
+++ b/lib/librte_mbuf/meson.build
@@ -2,8 +2,10 @@
# Copyright(c) 2017 Intel Corporation
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')
+sources = files('rte_mbuf.c', 'rte_mbuf_ptype.c', 'rte_mbuf_pool_ops.c',
+ 'rte_mbuf_dyn.c')
+headers = files('rte_mbuf.h', 'rte_mbuf_ptype.h', 'rte_mbuf_pool_ops.h',
+ 'rte_mbuf_dyn.h')
deps += ['mempool']
allow_experimental_apis = true
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 98225ec80..ef588cd54 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -198,9 +198,12 @@ extern "C" {
#define PKT_RX_OUTER_L4_CKSUM_GOOD (1ULL << 22)
#define PKT_RX_OUTER_L4_CKSUM_INVALID ((1ULL << 21) | (1ULL << 22))
-/* add new RX flags here */
+/* add new RX flags here, don't forget to update PKT_FIRST_FREE */
-/* add new TX flags here */
+#define PKT_FIRST_FREE (1ULL << 23)
+#define PKT_LAST_FREE (1ULL << 39)
+
+/* add new TX flags here, don't forget to update PKT_LAST_FREE */
/**
* Indicate that the metadata field in the mbuf is in use.
@@ -738,6 +741,8 @@ struct rte_mbuf {
*/
struct rte_mbuf_ext_shared_info *shinfo;
+ uint64_t dynfield1; /**< Reserved for dynamic fields. */
+ uint64_t dynfield2; /**< Reserved for dynamic fields. */
} __rte_cache_aligned;
/**
@@ -1685,6 +1690,21 @@ rte_pktmbuf_attach_extbuf(struct rte_mbuf *m, void *buf_addr,
#define rte_pktmbuf_detach_extbuf(m) rte_pktmbuf_detach(m)
/**
+ * Copy dynamic fields from m_src to m_dst.
+ *
+ * @param m_dst
+ * The destination mbuf.
+ * @param m_src
+ * The source mbuf.
+ */
+static inline void
+rte_mbuf_dynfield_copy(struct rte_mbuf *m_dst, const struct rte_mbuf *m_src)
+{
+ m_dst->dynfield1 = m_src->dynfield1;
+ m_dst->dynfield2 = m_src->dynfield2;
+}
+
+/**
* Attach packet mbuf to another packet mbuf.
*
* If the mbuf we are attaching to isn't a direct buffer and is attached to
@@ -1732,6 +1752,7 @@ static inline void rte_pktmbuf_attach(struct rte_mbuf *mi, struct rte_mbuf *m)
mi->vlan_tci_outer = m->vlan_tci_outer;
mi->tx_offload = m->tx_offload;
mi->hash = m->hash;
+ rte_mbuf_dynfield_copy(mi, m);
mi->next = NULL;
mi->pkt_len = mi->data_len;
diff --git a/lib/librte_mbuf/rte_mbuf_dyn.c b/lib/librte_mbuf/rte_mbuf_dyn.c
new file mode 100644
index 000000000..6a96a43da
--- /dev/null
+++ b/lib/librte_mbuf/rte_mbuf_dyn.c
@@ -0,0 +1,373 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2019 6WIND S.A.
+ */
+
+#include <sys/queue.h>
+
+#include <rte_common.h>
+#include <rte_eal.h>
+#include <rte_eal_memconfig.h>
+#include <rte_tailq.h>
+#include <rte_errno.h>
+#include <rte_malloc.h>
+#include <rte_string_fns.h>
+#include <rte_mbuf.h>
+#include <rte_mbuf_dyn.h>
+
+#define RTE_MBUF_DYN_MZNAME "rte_mbuf_dyn"
+
+struct mbuf_dynfield {
+ TAILQ_ENTRY(mbuf_dynfield) next;
+ char name[RTE_MBUF_DYN_NAMESIZE];
+ size_t size;
+ size_t align;
+ unsigned int flags;
+ int offset;
+};
+TAILQ_HEAD(mbuf_dynfield_list, rte_tailq_entry);
+
+static struct rte_tailq_elem mbuf_dynfield_tailq = {
+ .name = "RTE_MBUF_DYNFIELD",
+};
+EAL_REGISTER_TAILQ(mbuf_dynfield_tailq);
+
+struct mbuf_dynflag {
+ TAILQ_ENTRY(mbuf_dynflag) next;
+ char name[RTE_MBUF_DYN_NAMESIZE];
+ int bitnum;
+};
+TAILQ_HEAD(mbuf_dynflag_list, rte_tailq_entry);
+
+static struct rte_tailq_elem mbuf_dynflag_tailq = {
+ .name = "RTE_MBUF_DYNFLAG",
+};
+EAL_REGISTER_TAILQ(mbuf_dynflag_tailq);
+
+struct mbuf_dyn_shm {
+ /** For each mbuf byte, free_space[i] == 1 if space is free. */
+ uint8_t free_space[sizeof(struct rte_mbuf)];
+ /** Bitfield of available flags. */
+ uint64_t free_flags;
+};
+static struct mbuf_dyn_shm *shm;
+
+/* allocate and initialize the shared memory */
+static int
+init_shared_mem(void)
+{
+ const struct rte_memzone *mz;
+ uint64_t mask;
+
+ if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
+ mz = rte_memzone_reserve_aligned(RTE_MBUF_DYN_MZNAME,
+ sizeof(struct mbuf_dyn_shm),
+ SOCKET_ID_ANY, 0,
+ RTE_CACHE_LINE_SIZE);
+ } else {
+ mz = rte_memzone_lookup(RTE_MBUF_DYN_MZNAME);
+ }
+ if (mz == NULL)
+ return -1;
+
+ shm = mz->addr;
+
+#define mark_free(field) \
+ memset(&shm->free_space[offsetof(struct rte_mbuf, field)], \
+ 0xff, sizeof(((struct rte_mbuf *)0)->field))
+
+ if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
+ /* init free_space, keep it sync'd with
+ * rte_mbuf_dynfield_copy().
+ */
+ memset(shm, 0, sizeof(*shm));
+ mark_free(dynfield1);
+ mark_free(dynfield2);
+
+ /* init free_flags */
+ for (mask = PKT_FIRST_FREE; mask <= PKT_LAST_FREE; mask <<= 1)
+ shm->free_flags |= mask;
+ }
+#undef mark_free
+
+ return 0;
+}
+
+/* check if this offset can be used */
+static int
+check_offset(size_t offset, size_t size, size_t align, unsigned int flags)
+{
+ size_t i;
+
+ (void)flags;
+
+ if ((offset & (align - 1)) != 0)
+ return -1;
+ if (offset + size > sizeof(struct rte_mbuf))
+ return -1;
+
+ for (i = 0; i < size; i++) {
+ if (!shm->free_space[i + offset])
+ return -1;
+ }
+
+ return 0;
+}
+
+/* assume tailq is locked */
+static struct mbuf_dynfield *
+__mbuf_dynfield_lookup(const char *name)
+{
+ struct mbuf_dynfield_list *mbuf_dynfield_list;
+ struct mbuf_dynfield *mbuf_dynfield;
+ struct rte_tailq_entry *te;
+
+ mbuf_dynfield_list = RTE_TAILQ_CAST(
+ mbuf_dynfield_tailq.head, mbuf_dynfield_list);
+
+ TAILQ_FOREACH(te, mbuf_dynfield_list, next) {
+ mbuf_dynfield = (struct mbuf_dynfield *)te->data;
+ if (strncmp(name, mbuf_dynfield->name,
+ RTE_MBUF_DYN_NAMESIZE) == 0)
+ break;
+ }
+
+ if (te == NULL) {
+ rte_errno = ENOENT;
+ return NULL;
+ }
+
+ return mbuf_dynfield;
+}
+
+int
+rte_mbuf_dynfield_lookup(const char *name, size_t *size, size_t *align)
+{
+ struct mbuf_dynfield *mbuf_dynfield;
+
+ if (shm == NULL) {
+ rte_errno = ENOENT;
+ return -1;
+ }
+
+ rte_mcfg_tailq_read_lock();
+ mbuf_dynfield = __mbuf_dynfield_lookup(name);
+ rte_mcfg_tailq_read_unlock();
+
+ if (mbuf_dynfield == NULL) {
+ rte_errno = ENOENT;
+ return -1;
+ }
+
+ if (size != NULL)
+ *size = mbuf_dynfield->size;
+ if (align != NULL)
+ *align = mbuf_dynfield->align;
+
+ return mbuf_dynfield->offset;
+}
+
+int
+rte_mbuf_dynfield_register(const char *name, size_t size, size_t align,
+ unsigned int flags)
+{
+ struct mbuf_dynfield_list *mbuf_dynfield_list;
+ struct mbuf_dynfield *mbuf_dynfield = NULL;
+ struct rte_tailq_entry *te = NULL;
+ int offset, ret;
+ size_t i;
+
+ if (shm == NULL && init_shared_mem() < 0)
+ goto fail;
+ if (size >= sizeof(struct rte_mbuf)) {
+ rte_errno = EINVAL;
+ goto fail;
+ }
+ if (!rte_is_power_of_2(align)) {
+ rte_errno = EINVAL;
+ goto fail;
+ }
+
+ rte_mcfg_tailq_write_lock();
+
+ mbuf_dynfield = __mbuf_dynfield_lookup(name);
+ if (mbuf_dynfield != NULL) {
+ if (mbuf_dynfield->size != size ||
+ mbuf_dynfield->align != align ||
+ mbuf_dynfield->flags != flags) {
+ rte_errno = EEXIST;
+ goto fail_unlock;
+ }
+ offset = mbuf_dynfield->offset;
+ goto out_unlock;
+ }
+
+ if (rte_eal_process_type() != RTE_PROC_PRIMARY) {
+ rte_errno = EPERM;
+ goto fail_unlock;
+ }
+
+ for (offset = 0;
+ offset < (int)sizeof(struct rte_mbuf);
+ offset++) {
+ if (check_offset(offset, size, align, flags) == 0)
+ break;
+ }
+
+ if (offset == sizeof(struct rte_mbuf)) {
+ rte_errno = ENOENT;
+ goto fail_unlock;
+ }
+
+ mbuf_dynfield_list = RTE_TAILQ_CAST(
+ mbuf_dynfield_tailq.head, mbuf_dynfield_list);
+
+ te = rte_zmalloc("MBUF_DYNFIELD_TAILQ_ENTRY", sizeof(*te), 0);
+ if (te == NULL)
+ goto fail_unlock;
+
+ mbuf_dynfield = rte_zmalloc("mbuf_dynfield", sizeof(*mbuf_dynfield), 0);
+ if (mbuf_dynfield == NULL)
+ goto fail_unlock;
+
+ ret = strlcpy(mbuf_dynfield->name, name, sizeof(mbuf_dynfield->name));
+ if (ret < 0 || ret >= (int)sizeof(mbuf_dynfield->name)) {
+ rte_errno = ENAMETOOLONG;
+ goto fail_unlock;
+ }
+ mbuf_dynfield->size = size;
+ mbuf_dynfield->align = align;
+ mbuf_dynfield->flags = flags;
+ mbuf_dynfield->offset = offset;
+ te->data = mbuf_dynfield;
+
+ TAILQ_INSERT_TAIL(mbuf_dynfield_list, te, next);
+
+ for (i = offset; i < offset + size; i++)
+ shm->free_space[i] = 0;
+
+out_unlock:
+ rte_mcfg_tailq_write_unlock();
+
+ return offset;
+
+fail_unlock:
+ rte_mcfg_tailq_write_unlock();
+fail:
+ rte_free(mbuf_dynfield);
+ rte_free(te);
+ return -1;
+}
+
+/* assume tailq is locked */
+static struct mbuf_dynflag *
+__mbuf_dynflag_lookup(const char *name)
+{
+ struct mbuf_dynflag_list *mbuf_dynflag_list;
+ struct mbuf_dynflag *mbuf_dynflag;
+ struct rte_tailq_entry *te;
+
+ mbuf_dynflag_list = RTE_TAILQ_CAST(
+ mbuf_dynflag_tailq.head, mbuf_dynflag_list);
+
+ TAILQ_FOREACH(te, mbuf_dynflag_list, next) {
+ mbuf_dynflag = (struct mbuf_dynflag *)te->data;
+ if (strncmp(name, mbuf_dynflag->name,
+ RTE_MBUF_DYN_NAMESIZE) == 0)
+ break;
+ }
+
+ if (te == NULL) {
+ rte_errno = ENOENT;
+ return NULL;
+ }
+
+ return mbuf_dynflag;
+}
+
+int
+rte_mbuf_dynflag_lookup(const char *name)
+{
+ struct mbuf_dynflag *mbuf_dynflag;
+
+ if (shm == NULL) {
+ rte_errno = ENOENT;
+ return -1;
+ }
+
+ rte_mcfg_tailq_read_lock();
+ mbuf_dynflag = __mbuf_dynflag_lookup(name);
+ rte_mcfg_tailq_read_unlock();
+
+ if (mbuf_dynflag == NULL) {
+ rte_errno = ENOENT;
+ return -1;
+ }
+
+ return mbuf_dynflag->bitnum;
+}
+
+int
+rte_mbuf_dynflag_register(const char *name)
+{
+ struct mbuf_dynflag_list *mbuf_dynflag_list;
+ struct mbuf_dynflag *mbuf_dynflag = NULL;
+ struct rte_tailq_entry *te = NULL;
+ int bitnum, ret;
+
+ if (shm == NULL && init_shared_mem() < 0)
+ goto fail;
+
+ rte_mcfg_tailq_write_lock();
+
+ mbuf_dynflag = __mbuf_dynflag_lookup(name);
+ if (mbuf_dynflag != NULL) {
+ bitnum = mbuf_dynflag->bitnum;
+ goto out_unlock;
+ }
+
+ if (rte_eal_process_type() != RTE_PROC_PRIMARY) {
+ rte_errno = EPERM;
+ goto fail_unlock;
+ }
+
+ if (shm->free_flags == 0) {
+ rte_errno = ENOENT;
+ goto fail_unlock;
+ }
+ bitnum = rte_bsf64(shm->free_flags);
+
+ mbuf_dynflag_list = RTE_TAILQ_CAST(
+ mbuf_dynflag_tailq.head, mbuf_dynflag_list);
+
+ te = rte_zmalloc("MBUF_DYNFLAG_TAILQ_ENTRY", sizeof(*te), 0);
+ if (te == NULL)
+ goto fail_unlock;
+
+ mbuf_dynflag = rte_zmalloc("mbuf_dynflag", sizeof(*mbuf_dynflag), 0);
+ if (mbuf_dynflag == NULL)
+ goto fail_unlock;
+
+ ret = strlcpy(mbuf_dynflag->name, name, sizeof(mbuf_dynflag->name));
+ if (ret < 0 || ret >= (int)sizeof(mbuf_dynflag->name)) {
+ rte_errno = ENAMETOOLONG;
+ goto fail_unlock;
+ }
+ mbuf_dynflag->bitnum = bitnum;
+ te->data = mbuf_dynflag;
+
+ TAILQ_INSERT_TAIL(mbuf_dynflag_list, te, next);
+
+ shm->free_flags &= ~(1ULL << bitnum);
+
+out_unlock:
+ rte_mcfg_tailq_write_unlock();
+
+ return bitnum;
+
+fail_unlock:
+ rte_mcfg_tailq_write_unlock();
+fail:
+ rte_free(mbuf_dynflag);
+ rte_free(te);
+ return -1;
+}
diff --git a/lib/librte_mbuf/rte_mbuf_dyn.h b/lib/librte_mbuf/rte_mbuf_dyn.h
new file mode 100644
index 000000000..a86986a0f
--- /dev/null
+++ b/lib/librte_mbuf/rte_mbuf_dyn.h
@@ -0,0 +1,119 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright 2019 6WIND S.A.
+ */
+
+#ifndef _RTE_MBUF_DYN_H_
+#define _RTE_MBUF_DYN_H_
+
+/**
+ * @file
+ * RTE Mbuf dynamic fields and flags
+ *
+ * Many features require to store data inside the mbuf. As the room in
+ * mbuf structure is limited, it is not possible to have a field for
+ * each feature. Also, changing fields in the mbuf structure can break
+ * the API or ABI.
+ *
+ * This module addresses this issue, by enabling the dynamic
+ * registration of fields or flags:
+ *
+ * - a dynamic field is a named area in the rte_mbuf structure, with a
+ * given size (>= 1 byte) and alignment constraint.
+ * - a dynamic flag is a named bit in the rte_mbuf structure.
+ *
+ * The typical use case is a PMD that registers space for an offload
+ * feature, when the application requests to enable this feature. As
+ * the space in mbuf is limited, the space should only be reserved if it
+ * is going to be used (i.e when the application explicitly asks for it).
+ *
+ * The registration can be done at any moment, but it is not possible
+ * to unregister fields or flags for now.
+ *
+ * Example of use:
+ *
+ * - RTE_MBUF_DYN_<feature>_(ID|SIZE|ALIGN) are defined in this file
+ * - If the application asks for the feature, the PMD use
+ * rte_mbuf_dynfield_register() to get the dynamic offset and stores
+ * in a global variable.
+ * - The application also calls rte_mbuf_dynfield_register() to get the
+ * dynamic offset and stores it in a global variable.
+ * - When the field must be used by the PMD or the application, they
+ * use the RTE_MBUF_DYNFIELD() helper.
+ */
+
+struct rte_mbuf;
+
+/**
+ * Register space for a dynamic field in the mbuf structure.
+ *
+ * @param name
+ * A string identifying the dynamic field. External applications or
+ * libraries must not define identifers prefixed with "rte_", which
+ * are reserved for standard features.
+ * @param size
+ * The number of bytes to reserve.
+ * @param align
+ * The alignment constraint, which must be a power of 2.
+ * @param flags
+ * Reserved for future use.
+ * @return
+ * The offset in the mbuf structure, or -1 on error (rte_errno is set).
+ */
+__rte_experimental
+int rte_mbuf_dynfield_register(const char *name, size_t size, size_t align,
+ unsigned int flags);
+
+/**
+ * Lookup for a registered dynamic mbuf field.
+ *
+ * @param name
+ * A string identifying the dynamic field.
+ * @param size
+ * If not NULL, the number of reserved bytes for this field is stored
+ * at this address.
+ * @param align
+ * If not NULL, the alignement constraint for this field is stored
+ * at this address.
+ * @return
+ * The offset of this field in the mbuf structure, or -1 on error
+ * (rte_errno is set).
+ */
+__rte_experimental
+int rte_mbuf_dynfield_lookup(const char *name, size_t *size, size_t *align);
+
+/**
+ * Register a dynamic flag in the mbuf structure.
+ *
+ * @param name
+ * A string identifying the dynamic flag. External applications or
+ * libraries must not define identifers prefixed with "rte_", which
+ * are reserved for standard features.
+ * @return
+ * The number of the reserved bit, or -1 on error (rte_errno is set).
+ */
+__rte_experimental
+int rte_mbuf_dynflag_register(const char *name);
+
+/**
+ * Lookup for a registered dynamic mbuf flag.
+ *
+ * @param name
+ * A string identifying the dynamic flag.
+ * @return
+ * The offset of this flag in the mbuf structure, or -1 on error
+ * (rte_errno is set).
+ */
+__rte_experimental
+int rte_mbuf_dynflag_lookup(const char *name);
+
+/**
+ * Helper macro to access to a dynamic field.
+ */
+#define RTE_MBUF_DYNFIELD(m, offset, type) ((type)((char *)(m) + (offset)))
+
+/**
+ * Maximum length of the dynamic field or flag string.
+ */
+#define RTE_MBUF_DYN_NAMESIZE 32
+
+#endif
diff --git a/lib/librte_mbuf/rte_mbuf_version.map b/lib/librte_mbuf/rte_mbuf_version.map
index 2662a37bf..a98310570 100644
--- a/lib/librte_mbuf/rte_mbuf_version.map
+++ b/lib/librte_mbuf/rte_mbuf_version.map
@@ -50,4 +50,8 @@ EXPERIMENTAL {
global:
rte_mbuf_check;
+ rte_mbuf_dynfield_lookup;
+ rte_mbuf_dynfield_register;
+ rte_mbuf_dynflag_lookup;
+ rte_mbuf_dynflag_register;
} DPDK_18.08;
--
2.11.0
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] ethdev: extend flow metadata
@ 2019-07-10 9:31 3% ` Olivier Matz
2019-07-10 9:55 4% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Olivier Matz @ 2019-07-10 9:31 UTC (permalink / raw)
To: Yongseok Koh
Cc: shahafs, thomas, ferruh.yigit, arybchenko, adrien.mazarguil, dev,
viacheslavo
Hi Yongseok,
On Thu, Jul 04, 2019 at 04:21:22PM -0700, Yongseok Koh wrote:
> Currently, metadata can be set on egress path via mbuf tx_meatadata field
> with PKT_TX_METADATA flag and RTE_FLOW_ITEM_TYPE_RX_META matches metadata.
>
> This patch extends the usability.
>
> 1) RTE_FLOW_ACTION_TYPE_SET_META
>
> When supporting multiple tables, Tx metadata can also be set by a rule and
> matched by another rule. This new action allows metadata to be set as a
> result of flow match.
>
> 2) Metadata on ingress
>
> There's also need to support metadata on packet Rx. Metadata can be set by
> SET_META action and matched by META item like Tx. The final value set by
> the action will be delivered to application via mbuf metadata field with
> PKT_RX_METADATA ol_flag.
>
> For this purpose, mbuf->tx_metadata is moved as a separate new field and
> renamed to 'metadata' to support both Rx and Tx metadata.
>
> For loopback/hairpin packet, metadata set on Rx/Tx may or may not be
> propagated to the other path depending on HW capability.
>
> Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
(...)
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -200,6 +200,11 @@ extern "C" {
>
> /* add new RX flags here */
>
> +/**
> + * Indicate that mbuf has metadata from device.
> + */
> +#define PKT_RX_METADATA (1ULL << 23)
> +
> /* add new TX flags here */
>
> /**
> @@ -648,17 +653,6 @@ struct rte_mbuf {
> /**< User defined tags. See rte_distributor_process() */
> uint32_t usr;
> } hash; /**< hash information */
> - struct {
> - /**
> - * Application specific metadata value
> - * for egress flow rule match.
> - * Valid if PKT_TX_METADATA is set.
> - * Located here to allow conjunct use
> - * with hash.sched.hi.
> - */
> - uint32_t tx_metadata;
> - uint32_t reserved;
> - };
> };
>
> /** Outer VLAN TCI (CPU order), valid if PKT_RX_QINQ is set. */
> @@ -727,6 +721,11 @@ struct rte_mbuf {
> */
> struct rte_mbuf_ext_shared_info *shinfo;
>
> + /** Application specific metadata value for flow rule match.
> + * Valid if PKT_RX_METADATA or PKT_TX_METADATA is set.
> + */
> + uint32_t metadata;
> +
> } __rte_cache_aligned;
This will break the ABI, so we cannot put it in 19.08, and we need a
deprecation notice.
That said, it shows again that we need something to make the addition of
fields in mbufs more flexible. Knowing that Thomas will present
something about it at next userspace [1], I drafted something in a RFC
[2]. It is simpler than I expected, and I think your commit could be
a good candidate for a first user. Do you mind having a try? Feedback
and comment is of course welcome.
If it fits your needs, we can target its introduction for 19.11. Having
a user for this new feature would be a plus for its introduction :)
Thanks,
Olivier
[1] https://dpdkbordeaux2019.sched.com/
[2] http://mails.dpdk.org/archives/dev/2019-July/137772.html
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] ethdev: extend flow metadata
2019-07-10 9:31 3% ` Olivier Matz
@ 2019-07-10 9:55 4% ` Bruce Richardson
2019-07-10 10:07 3% ` Olivier Matz
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2019-07-10 9:55 UTC (permalink / raw)
To: Olivier Matz
Cc: Yongseok Koh, shahafs, thomas, ferruh.yigit, arybchenko,
adrien.mazarguil, dev, viacheslavo
On Wed, Jul 10, 2019 at 11:31:56AM +0200, Olivier Matz wrote:
> Hi Yongseok,
>
> On Thu, Jul 04, 2019 at 04:21:22PM -0700, Yongseok Koh wrote:
> > Currently, metadata can be set on egress path via mbuf tx_meatadata field
> > with PKT_TX_METADATA flag and RTE_FLOW_ITEM_TYPE_RX_META matches metadata.
> >
> > This patch extends the usability.
> >
> > 1) RTE_FLOW_ACTION_TYPE_SET_META
> >
> > When supporting multiple tables, Tx metadata can also be set by a rule and
> > matched by another rule. This new action allows metadata to be set as a
> > result of flow match.
> >
> > 2) Metadata on ingress
> >
> > There's also need to support metadata on packet Rx. Metadata can be set by
> > SET_META action and matched by META item like Tx. The final value set by
> > the action will be delivered to application via mbuf metadata field with
> > PKT_RX_METADATA ol_flag.
> >
> > For this purpose, mbuf->tx_metadata is moved as a separate new field and
> > renamed to 'metadata' to support both Rx and Tx metadata.
> >
> > For loopback/hairpin packet, metadata set on Rx/Tx may or may not be
> > propagated to the other path depending on HW capability.
> >
> > Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
>
> (...)
>
> > --- a/lib/librte_mbuf/rte_mbuf.h
> > +++ b/lib/librte_mbuf/rte_mbuf.h
> > @@ -200,6 +200,11 @@ extern "C" {
> >
> > /* add new RX flags here */
> >
> > +/**
> > + * Indicate that mbuf has metadata from device.
> > + */
> > +#define PKT_RX_METADATA (1ULL << 23)
> > +
> > /* add new TX flags here */
> >
> > /**
> > @@ -648,17 +653,6 @@ struct rte_mbuf {
> > /**< User defined tags. See rte_distributor_process() */
> > uint32_t usr;
> > } hash; /**< hash information */
> > - struct {
> > - /**
> > - * Application specific metadata value
> > - * for egress flow rule match.
> > - * Valid if PKT_TX_METADATA is set.
> > - * Located here to allow conjunct use
> > - * with hash.sched.hi.
> > - */
> > - uint32_t tx_metadata;
> > - uint32_t reserved;
> > - };
> > };
> >
> > /** Outer VLAN TCI (CPU order), valid if PKT_RX_QINQ is set. */
> > @@ -727,6 +721,11 @@ struct rte_mbuf {
> > */
> > struct rte_mbuf_ext_shared_info *shinfo;
> >
> > + /** Application specific metadata value for flow rule match.
> > + * Valid if PKT_RX_METADATA or PKT_TX_METADATA is set.
> > + */
> > + uint32_t metadata;
> > +
> > } __rte_cache_aligned;
>
> This will break the ABI, so we cannot put it in 19.08, and we need a
> deprecation notice.
>
Does it actually break the ABI? Adding a new field to the mbuf should only
break the ABI if it either causes new fields to move or changes the
structure size. Since this is at the end, it's not going to move any older
fields, and since everything is cache-aligned I don't think the structure
size changes either.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] ethdev: extend flow metadata
2019-07-10 9:55 4% ` Bruce Richardson
@ 2019-07-10 10:07 3% ` Olivier Matz
2019-07-10 12:01 4% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Olivier Matz @ 2019-07-10 10:07 UTC (permalink / raw)
To: Bruce Richardson
Cc: Yongseok Koh, shahafs, thomas, ferruh.yigit, arybchenko,
adrien.mazarguil, dev, viacheslavo
On Wed, Jul 10, 2019 at 10:55:34AM +0100, Bruce Richardson wrote:
> On Wed, Jul 10, 2019 at 11:31:56AM +0200, Olivier Matz wrote:
> > Hi Yongseok,
> >
> > On Thu, Jul 04, 2019 at 04:21:22PM -0700, Yongseok Koh wrote:
> > > Currently, metadata can be set on egress path via mbuf tx_meatadata field
> > > with PKT_TX_METADATA flag and RTE_FLOW_ITEM_TYPE_RX_META matches metadata.
> > >
> > > This patch extends the usability.
> > >
> > > 1) RTE_FLOW_ACTION_TYPE_SET_META
> > >
> > > When supporting multiple tables, Tx metadata can also be set by a rule and
> > > matched by another rule. This new action allows metadata to be set as a
> > > result of flow match.
> > >
> > > 2) Metadata on ingress
> > >
> > > There's also need to support metadata on packet Rx. Metadata can be set by
> > > SET_META action and matched by META item like Tx. The final value set by
> > > the action will be delivered to application via mbuf metadata field with
> > > PKT_RX_METADATA ol_flag.
> > >
> > > For this purpose, mbuf->tx_metadata is moved as a separate new field and
> > > renamed to 'metadata' to support both Rx and Tx metadata.
> > >
> > > For loopback/hairpin packet, metadata set on Rx/Tx may or may not be
> > > propagated to the other path depending on HW capability.
> > >
> > > Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
> >
> > (...)
> >
> > > --- a/lib/librte_mbuf/rte_mbuf.h
> > > +++ b/lib/librte_mbuf/rte_mbuf.h
> > > @@ -200,6 +200,11 @@ extern "C" {
> > >
> > > /* add new RX flags here */
> > >
> > > +/**
> > > + * Indicate that mbuf has metadata from device.
> > > + */
> > > +#define PKT_RX_METADATA (1ULL << 23)
> > > +
> > > /* add new TX flags here */
> > >
> > > /**
> > > @@ -648,17 +653,6 @@ struct rte_mbuf {
> > > /**< User defined tags. See rte_distributor_process() */
> > > uint32_t usr;
> > > } hash; /**< hash information */
> > > - struct {
> > > - /**
> > > - * Application specific metadata value
> > > - * for egress flow rule match.
> > > - * Valid if PKT_TX_METADATA is set.
> > > - * Located here to allow conjunct use
> > > - * with hash.sched.hi.
> > > - */
> > > - uint32_t tx_metadata;
> > > - uint32_t reserved;
> > > - };
> > > };
> > >
> > > /** Outer VLAN TCI (CPU order), valid if PKT_RX_QINQ is set. */
> > > @@ -727,6 +721,11 @@ struct rte_mbuf {
> > > */
> > > struct rte_mbuf_ext_shared_info *shinfo;
> > >
> > > + /** Application specific metadata value for flow rule match.
> > > + * Valid if PKT_RX_METADATA or PKT_TX_METADATA is set.
> > > + */
> > > + uint32_t metadata;
> > > +
> > > } __rte_cache_aligned;
> >
> > This will break the ABI, so we cannot put it in 19.08, and we need a
> > deprecation notice.
> >
> Does it actually break the ABI? Adding a new field to the mbuf should only
> break the ABI if it either causes new fields to move or changes the
> structure size. Since this is at the end, it's not going to move any older
> fields, and since everything is cache-aligned I don't think the structure
> size changes either.
I think it does break the ABI: in previous version, when the PKT_TX_METADATA
flag is set, the associated value is put in m->tx_metadata (offset 44 on
x86-64), and in the next version, it will be in m->metadata (offset 112). So,
these 2 versions are not binary compatible.
Anyway, at least it breaks the API.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] devtools: fix symbol change file matching
2019-07-10 9:57 3% [dpdk-dev] devtools: fix symbol change file matching Bing Zhao
@ 2019-07-10 11:10 0% ` Neil Horman
0 siblings, 0 replies; 200+ results
From: Neil Horman @ 2019-07-10 11:10 UTC (permalink / raw)
To: Bing Zhao; +Cc: dev, stable
On Wed, Jul 10, 2019 at 05:57:14PM +0800, Bing Zhao wrote:
> The previous regex miss a situation that a new file is added after
> the map file. It will starts with '/dev/null' instead of 'a /', so
> all the content in the patch file after 'map' will be considered in
> the symbol map file. Also, a second regex matching is used for map
> and other files, the '^map' in square brackets is not quite exact
> the same with the design even if it works.
>
> Fixes: 4bec48184e33 ("devtools: add checks for ABI symbol addition")
> Cc: nhorman@tuxdriver.com
>
> Signed-off-by: Bing Zhao <bingz@mellanox.com>
> ---
> devtools/check-symbol-change.sh | 21 +++++++++++++++++----
> 1 file changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/devtools/check-symbol-change.sh b/devtools/check-symbol-change.sh
> index c5434f3..eac71f3 100755
> --- a/devtools/check-symbol-change.sh
> +++ b/devtools/check-symbol-change.sh
> @@ -11,19 +11,32 @@ build_map_changes()
> # Initialize our variables
> BEGIN {map="";sym="";ar="";sec=""; in_sec=0; in_map=0}
>
> - # Anything that starts with + or -, followed by an a
> + # Anything that starts with + or -, followed by an a or b
> # and ends in the string .map is the name of our map file
> # This may appear multiple times in a patch if multiple
> # map files are altered, and all section/symbol names
> # appearing between a triggering of this rule and the
> # next trigger of this rule are associated with this file
> - /[-+] a\/.*\.map/ {map=$2; in_map=1}
>
> # Same pattern as above, only it matches on anything that
> - # does not end in 'map', indicating we have left the map chunk.
> + # does not end in "map", indicating we have left the map chunk.
> # When we hit this, turn off the in_map variable, which
> # supresses the subordonate rules below
> - /[-+] a\/.*\.[^map]/ {in_map=0}
> + # Currently, using the same pattern for all the files matching,
> + # and a second RE matching is used to distinguish map files from
> + # other types of files
> + /[-+] [ab]\/.*\.[[:alnum:]]+$/ {
> + if ($2 ~ /\.map$/) {
> + if (in_map == 0) {in_map = 1}
> + } else {
> + if (in_map == 1) {in_map = 0}
> + }
> + }
> +
> + # Indeed, this RE matching has no use. The only purpose here
> + # is to remind that the git will have a third file pattern
> + # "-+ /dev/null" besides "-a /" and "+b /"
> + /[-+] \/dev\/null$/ {next}
>
> # Triggering this rule, which starts a line and ends it
> # with a { identifies a versioned section. The section name is
> --
> 1.8.3.1
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] ethdev: extend flow metadata
2019-07-10 10:07 3% ` Olivier Matz
@ 2019-07-10 12:01 4% ` Bruce Richardson
2019-07-10 12:26 3% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2019-07-10 12:01 UTC (permalink / raw)
To: Olivier Matz
Cc: Yongseok Koh, shahafs, thomas, ferruh.yigit, arybchenko,
adrien.mazarguil, dev, viacheslavo
On Wed, Jul 10, 2019 at 12:07:43PM +0200, Olivier Matz wrote:
> On Wed, Jul 10, 2019 at 10:55:34AM +0100, Bruce Richardson wrote:
> > On Wed, Jul 10, 2019 at 11:31:56AM +0200, Olivier Matz wrote:
> > > Hi Yongseok,
> > >
> > > On Thu, Jul 04, 2019 at 04:21:22PM -0700, Yongseok Koh wrote:
> > > > Currently, metadata can be set on egress path via mbuf tx_meatadata field
> > > > with PKT_TX_METADATA flag and RTE_FLOW_ITEM_TYPE_RX_META matches metadata.
> > > >
> > > > This patch extends the usability.
> > > >
> > > > 1) RTE_FLOW_ACTION_TYPE_SET_META
> > > >
> > > > When supporting multiple tables, Tx metadata can also be set by a rule and
> > > > matched by another rule. This new action allows metadata to be set as a
> > > > result of flow match.
> > > >
> > > > 2) Metadata on ingress
> > > >
> > > > There's also need to support metadata on packet Rx. Metadata can be set by
> > > > SET_META action and matched by META item like Tx. The final value set by
> > > > the action will be delivered to application via mbuf metadata field with
> > > > PKT_RX_METADATA ol_flag.
> > > >
> > > > For this purpose, mbuf->tx_metadata is moved as a separate new field and
> > > > renamed to 'metadata' to support both Rx and Tx metadata.
> > > >
> > > > For loopback/hairpin packet, metadata set on Rx/Tx may or may not be
> > > > propagated to the other path depending on HW capability.
> > > >
> > > > Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
> > >
> > > (...)
> > >
> > > > --- a/lib/librte_mbuf/rte_mbuf.h
> > > > +++ b/lib/librte_mbuf/rte_mbuf.h
> > > > @@ -200,6 +200,11 @@ extern "C" {
> > > >
> > > > /* add new RX flags here */
> > > >
> > > > +/**
> > > > + * Indicate that mbuf has metadata from device.
> > > > + */
> > > > +#define PKT_RX_METADATA (1ULL << 23)
> > > > +
> > > > /* add new TX flags here */
> > > >
> > > > /**
> > > > @@ -648,17 +653,6 @@ struct rte_mbuf {
> > > > /**< User defined tags. See rte_distributor_process() */
> > > > uint32_t usr;
> > > > } hash; /**< hash information */
> > > > - struct {
> > > > - /**
> > > > - * Application specific metadata value
> > > > - * for egress flow rule match.
> > > > - * Valid if PKT_TX_METADATA is set.
> > > > - * Located here to allow conjunct use
> > > > - * with hash.sched.hi.
> > > > - */
> > > > - uint32_t tx_metadata;
> > > > - uint32_t reserved;
> > > > - };
> > > > };
> > > >
> > > > /** Outer VLAN TCI (CPU order), valid if PKT_RX_QINQ is set. */
> > > > @@ -727,6 +721,11 @@ struct rte_mbuf {
> > > > */
> > > > struct rte_mbuf_ext_shared_info *shinfo;
> > > >
> > > > + /** Application specific metadata value for flow rule match.
> > > > + * Valid if PKT_RX_METADATA or PKT_TX_METADATA is set.
> > > > + */
> > > > + uint32_t metadata;
> > > > +
> > > > } __rte_cache_aligned;
> > >
> > > This will break the ABI, so we cannot put it in 19.08, and we need a
> > > deprecation notice.
> > >
> > Does it actually break the ABI? Adding a new field to the mbuf should only
> > break the ABI if it either causes new fields to move or changes the
> > structure size. Since this is at the end, it's not going to move any older
> > fields, and since everything is cache-aligned I don't think the structure
> > size changes either.
>
> I think it does break the ABI: in previous version, when the PKT_TX_METADATA
> flag is set, the associated value is put in m->tx_metadata (offset 44 on
> x86-64), and in the next version, it will be in m->metadata (offset 112). So,
> these 2 versions are not binary compatible.
>
> Anyway, at least it breaks the API.
Ok, I misunderstood. I thought it was the structure change itself you were
saying broke the ABI. Yes, putting the data in a different place is indeed
an ABI break.
/Bruce
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] ethdev: extend flow metadata
2019-07-10 12:01 4% ` Bruce Richardson
@ 2019-07-10 12:26 3% ` Thomas Monjalon
2019-07-10 16:37 3% ` Yongseok Koh
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-07-10 12:26 UTC (permalink / raw)
To: Bruce Richardson, Olivier Matz, arybchenko, adrien.mazarguil
Cc: Yongseok Koh, shahafs, ferruh.yigit, dev, viacheslavo
10/07/2019 14:01, Bruce Richardson:
> On Wed, Jul 10, 2019 at 12:07:43PM +0200, Olivier Matz wrote:
> > On Wed, Jul 10, 2019 at 10:55:34AM +0100, Bruce Richardson wrote:
> > > On Wed, Jul 10, 2019 at 11:31:56AM +0200, Olivier Matz wrote:
> > > > On Thu, Jul 04, 2019 at 04:21:22PM -0700, Yongseok Koh wrote:
> > > > > Currently, metadata can be set on egress path via mbuf tx_meatadata field
> > > > > with PKT_TX_METADATA flag and RTE_FLOW_ITEM_TYPE_RX_META matches metadata.
> > > > >
> > > > > This patch extends the usability.
> > > > >
> > > > > 1) RTE_FLOW_ACTION_TYPE_SET_META
> > > > >
> > > > > When supporting multiple tables, Tx metadata can also be set by a rule and
> > > > > matched by another rule. This new action allows metadata to be set as a
> > > > > result of flow match.
> > > > >
> > > > > 2) Metadata on ingress
> > > > >
> > > > > There's also need to support metadata on packet Rx. Metadata can be set by
> > > > > SET_META action and matched by META item like Tx. The final value set by
> > > > > the action will be delivered to application via mbuf metadata field with
> > > > > PKT_RX_METADATA ol_flag.
> > > > >
> > > > > For this purpose, mbuf->tx_metadata is moved as a separate new field and
> > > > > renamed to 'metadata' to support both Rx and Tx metadata.
> > > > >
> > > > > For loopback/hairpin packet, metadata set on Rx/Tx may or may not be
> > > > > propagated to the other path depending on HW capability.
> > > > >
> > > > > Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
> > > >
> > > > > --- a/lib/librte_mbuf/rte_mbuf.h
> > > > > +++ b/lib/librte_mbuf/rte_mbuf.h
> > > > > @@ -648,17 +653,6 @@ struct rte_mbuf {
> > > > > /**< User defined tags. See rte_distributor_process() */
> > > > > uint32_t usr;
> > > > > } hash; /**< hash information */
> > > > > - struct {
> > > > > - /**
> > > > > - * Application specific metadata value
> > > > > - * for egress flow rule match.
> > > > > - * Valid if PKT_TX_METADATA is set.
> > > > > - * Located here to allow conjunct use
> > > > > - * with hash.sched.hi.
> > > > > - */
> > > > > - uint32_t tx_metadata;
> > > > > - uint32_t reserved;
> > > > > - };
> > > > > };
> > > > >
> > > > > /** Outer VLAN TCI (CPU order), valid if PKT_RX_QINQ is set. */
> > > > > @@ -727,6 +721,11 @@ struct rte_mbuf {
> > > > > */
> > > > > struct rte_mbuf_ext_shared_info *shinfo;
> > > > >
> > > > > + /** Application specific metadata value for flow rule match.
> > > > > + * Valid if PKT_RX_METADATA or PKT_TX_METADATA is set.
> > > > > + */
> > > > > + uint32_t metadata;
> > > > > +
> > > > > } __rte_cache_aligned;
> > > >
> > > > This will break the ABI, so we cannot put it in 19.08, and we need a
> > > > deprecation notice.
> > > >
> > > Does it actually break the ABI? Adding a new field to the mbuf should only
> > > break the ABI if it either causes new fields to move or changes the
> > > structure size. Since this is at the end, it's not going to move any older
> > > fields, and since everything is cache-aligned I don't think the structure
> > > size changes either.
> >
> > I think it does break the ABI: in previous version, when the PKT_TX_METADATA
> > flag is set, the associated value is put in m->tx_metadata (offset 44 on
> > x86-64), and in the next version, it will be in m->metadata (offset 112). So,
> > these 2 versions are not binary compatible.
> >
> > Anyway, at least it breaks the API.
>
> Ok, I misunderstood. I thought it was the structure change itself you were
> saying broke the ABI. Yes, putting the data in a different place is indeed
> an ABI break.
We could add the new field and keep the old one unused,
so it does not break the ABI.
However I suppose everybody will prefer a version using dynamic fields.
Is someone against using dynamic field for such usage?
^ permalink raw reply [relevance 3%]
* [dpdk-dev] devtools: fix symbol change file matching
@ 2019-07-10 9:57 3% Bing Zhao
2019-07-10 11:10 0% ` Neil Horman
0 siblings, 1 reply; 200+ results
From: Bing Zhao @ 2019-07-10 9:57 UTC (permalink / raw)
To: nhorman; +Cc: dev, stable
The previous regex miss a situation that a new file is added after
the map file. It will starts with '/dev/null' instead of 'a /', so
all the content in the patch file after 'map' will be considered in
the symbol map file. Also, a second regex matching is used for map
and other files, the '^map' in square brackets is not quite exact
the same with the design even if it works.
Fixes: 4bec48184e33 ("devtools: add checks for ABI symbol addition")
Cc: nhorman@tuxdriver.com
Signed-off-by: Bing Zhao <bingz@mellanox.com>
---
devtools/check-symbol-change.sh | 21 +++++++++++++++++----
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/devtools/check-symbol-change.sh b/devtools/check-symbol-change.sh
index c5434f3..eac71f3 100755
--- a/devtools/check-symbol-change.sh
+++ b/devtools/check-symbol-change.sh
@@ -11,19 +11,32 @@ build_map_changes()
# Initialize our variables
BEGIN {map="";sym="";ar="";sec=""; in_sec=0; in_map=0}
- # Anything that starts with + or -, followed by an a
+ # Anything that starts with + or -, followed by an a or b
# and ends in the string .map is the name of our map file
# This may appear multiple times in a patch if multiple
# map files are altered, and all section/symbol names
# appearing between a triggering of this rule and the
# next trigger of this rule are associated with this file
- /[-+] a\/.*\.map/ {map=$2; in_map=1}
# Same pattern as above, only it matches on anything that
- # does not end in 'map', indicating we have left the map chunk.
+ # does not end in "map", indicating we have left the map chunk.
# When we hit this, turn off the in_map variable, which
# supresses the subordonate rules below
- /[-+] a\/.*\.[^map]/ {in_map=0}
+ # Currently, using the same pattern for all the files matching,
+ # and a second RE matching is used to distinguish map files from
+ # other types of files
+ /[-+] [ab]\/.*\.[[:alnum:]]+$/ {
+ if ($2 ~ /\.map$/) {
+ if (in_map == 0) {in_map = 1}
+ } else {
+ if (in_map == 1) {in_map = 0}
+ }
+ }
+
+ # Indeed, this RE matching has no use. The only purpose here
+ # is to remind that the git will have a third file pattern
+ # "-+ /dev/null" besides "-a /" and "+b /"
+ /[-+] \/dev\/null$/ {next}
# Triggering this rule, which starts a line and ends it
# with a { identifies a versioned section. The section name is
--
1.8.3.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] ethdev: extend flow metadata
2019-07-10 12:26 3% ` Thomas Monjalon
@ 2019-07-10 16:37 3% ` Yongseok Koh
2019-07-11 7:44 0% ` Adrien Mazarguil
0 siblings, 1 reply; 200+ results
From: Yongseok Koh @ 2019-07-10 16:37 UTC (permalink / raw)
To: Thomas Monjalon, Olivier Matz
Cc: Bruce Richardson, Andrew Rybchenko, Adrien Mazarguil,
Shahaf Shuler, Ferruh Yigit, dev, Slava Ovsiienko
> On Jul 10, 2019, at 5:26 AM, Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 10/07/2019 14:01, Bruce Richardson:
>> On Wed, Jul 10, 2019 at 12:07:43PM +0200, Olivier Matz wrote:
>>> On Wed, Jul 10, 2019 at 10:55:34AM +0100, Bruce Richardson wrote:
>>>> On Wed, Jul 10, 2019 at 11:31:56AM +0200, Olivier Matz wrote:
>>>>> On Thu, Jul 04, 2019 at 04:21:22PM -0700, Yongseok Koh wrote:
>>>>>> Currently, metadata can be set on egress path via mbuf tx_meatadata field
>>>>>> with PKT_TX_METADATA flag and RTE_FLOW_ITEM_TYPE_RX_META matches metadata.
>>>>>>
>>>>>> This patch extends the usability.
>>>>>>
>>>>>> 1) RTE_FLOW_ACTION_TYPE_SET_META
>>>>>>
>>>>>> When supporting multiple tables, Tx metadata can also be set by a rule and
>>>>>> matched by another rule. This new action allows metadata to be set as a
>>>>>> result of flow match.
>>>>>>
>>>>>> 2) Metadata on ingress
>>>>>>
>>>>>> There's also need to support metadata on packet Rx. Metadata can be set by
>>>>>> SET_META action and matched by META item like Tx. The final value set by
>>>>>> the action will be delivered to application via mbuf metadata field with
>>>>>> PKT_RX_METADATA ol_flag.
>>>>>>
>>>>>> For this purpose, mbuf->tx_metadata is moved as a separate new field and
>>>>>> renamed to 'metadata' to support both Rx and Tx metadata.
>>>>>>
>>>>>> For loopback/hairpin packet, metadata set on Rx/Tx may or may not be
>>>>>> propagated to the other path depending on HW capability.
>>>>>>
>>>>>> Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
>>>>>
>>>>>> --- a/lib/librte_mbuf/rte_mbuf.h
>>>>>> +++ b/lib/librte_mbuf/rte_mbuf.h
>>>>>> @@ -648,17 +653,6 @@ struct rte_mbuf {
>>>>>> /**< User defined tags. See rte_distributor_process() */
>>>>>> uint32_t usr;
>>>>>> } hash; /**< hash information */
>>>>>> - struct {
>>>>>> - /**
>>>>>> - * Application specific metadata value
>>>>>> - * for egress flow rule match.
>>>>>> - * Valid if PKT_TX_METADATA is set.
>>>>>> - * Located here to allow conjunct use
>>>>>> - * with hash.sched.hi.
>>>>>> - */
>>>>>> - uint32_t tx_metadata;
>>>>>> - uint32_t reserved;
>>>>>> - };
>>>>>> };
>>>>>>
>>>>>> /** Outer VLAN TCI (CPU order), valid if PKT_RX_QINQ is set. */
>>>>>> @@ -727,6 +721,11 @@ struct rte_mbuf {
>>>>>> */
>>>>>> struct rte_mbuf_ext_shared_info *shinfo;
>>>>>>
>>>>>> + /** Application specific metadata value for flow rule match.
>>>>>> + * Valid if PKT_RX_METADATA or PKT_TX_METADATA is set.
>>>>>> + */
>>>>>> + uint32_t metadata;
>>>>>> +
>>>>>> } __rte_cache_aligned;
>>>>>
>>>>> This will break the ABI, so we cannot put it in 19.08, and we need a
>>>>> deprecation notice.
>>>>>
>>>> Does it actually break the ABI? Adding a new field to the mbuf should only
>>>> break the ABI if it either causes new fields to move or changes the
>>>> structure size. Since this is at the end, it's not going to move any older
>>>> fields, and since everything is cache-aligned I don't think the structure
>>>> size changes either.
>>>
>>> I think it does break the ABI: in previous version, when the PKT_TX_METADATA
>>> flag is set, the associated value is put in m->tx_metadata (offset 44 on
>>> x86-64), and in the next version, it will be in m->metadata (offset 112). So,
>>> these 2 versions are not binary compatible.
>>>
>>> Anyway, at least it breaks the API.
>>
>> Ok, I misunderstood. I thought it was the structure change itself you were
>> saying broke the ABI. Yes, putting the data in a different place is indeed
>> an ABI break.
>
> We could add the new field and keep the old one unused,
> so it does not break the ABI.
Still breaks ABI if PKT_TX_METADATA is set. :-) In order not to break it, I can
keep the current union'd field (tx_metadata) as is with PKT_TX_METADATA, add
the new one at the end and make it used with the new PKT_RX_METADATA.
> However I suppose everybody will prefer a version using dynamic fields.
> Is someone against using dynamic field for such usage?
However, given that the amazing dynamic fields is coming soon (thanks for your
effort, Olivier and Thomas!), I'd be honored to be the first user of it.
Olivier, I'll take a look at your RFC.
Thanks,
Yongseok
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags
2019-07-10 9:29 4% [dpdk-dev] [RFC] mbuf: support dynamic fields and flags Olivier Matz
@ 2019-07-10 17:14 0% ` Wang, Haiyue
2019-07-11 7:26 0% ` Olivier Matz
2019-07-10 17:49 3% ` Stephen Hemminger
` (2 subsequent siblings)
3 siblings, 1 reply; 200+ results
From: Wang, Haiyue @ 2019-07-10 17:14 UTC (permalink / raw)
To: Olivier Matz, dev
Hi,
Sounds cool, just have some questions inline.
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier Matz
> Sent: Wednesday, July 10, 2019 17:29
> To: dev@dpdk.org
> Subject: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags
>
> Many features require to store data inside the mbuf. As the room in mbuf
> structure is limited, it is not possible to have a field for each
> feature. Also, changing fields in the mbuf structure can break the API
> or ABI.
>
> This commit addresses these issues, by enabling the dynamic registration
> of fields or flags:
>
> - a dynamic field is a named area in the rte_mbuf structure, with a
> given size (>= 1 byte) and alignment constraint.
> - a dynamic flag is a named bit in the rte_mbuf structure.
>
> The typical use case is a PMD that registers space for an offload
> feature, when the application requests to enable this feature. As
> the space in mbuf is limited, the space should only be reserved if it
> is going to be used (i.e when the application explicitly asks for it).
>
> The registration can be done at any moment, but it is not possible
> to unregister fields or flags for now.
>
> Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
> ---
> app/test/test_mbuf.c | 83 +++++++-
> lib/librte_mbuf/Makefile | 2 +
> lib/librte_mbuf/meson.build | 6 +-
> lib/librte_mbuf/rte_mbuf.h | 25 ++-
> lib/librte_mbuf/rte_mbuf_dyn.c | 373 +++++++++++++++++++++++++++++++++++
> lib/librte_mbuf/rte_mbuf_dyn.h | 119 +++++++++++
> lib/librte_mbuf/rte_mbuf_version.map | 4 +
> 7 files changed, 607 insertions(+), 5 deletions(-)
> create mode 100644 lib/librte_mbuf/rte_mbuf_dyn.c
> create mode 100644 lib/librte_mbuf/rte_mbuf_dyn.h
>
> diff --git a/app/test/test_mbuf.c b/app/test/test_mbuf.c
> index 2a97afe20..8008cc766 100644
> --- a/app/test/test_mbuf.c
> +++ b/app/test/test_mbuf.c
> @@ -28,6 +28,7 @@
> #include <rte_random.h>
> #include <rte_cycles.h>
> #include <rte_malloc.h>
> +#include <rte_mbuf_dyn.h>
>
> #include "test.h"
>
> @@ -502,7 +503,6 @@ test_attach_from_different_pool(struct rte_mempool *pktmbuf_pool,
> rte_pktmbuf_free(clone2);
> return -1;
> }
> -#undef GOTO_FAIL
>
> /*
> * test allocation and free of mbufs
> @@ -1122,6 +1122,81 @@ test_tx_offload(void)
> }
>
> static int
> +test_mbuf_dyn(struct rte_mempool *pktmbuf_pool)
> +{
> + struct rte_mbuf *m = NULL;
> + int offset, offset2;
> + int flag, flag2;
> +
> + offset = rte_mbuf_dynfield_register("test-dynfield", sizeof(uint8_t),
> + __alignof__(uint8_t), 0);
> + if (offset == -1)
> + GOTO_FAIL("failed to register dynamic field, offset=%d: %s",
> + offset, strerror(errno));
> +
> + offset2 = rte_mbuf_dynfield_register("test-dynfield", sizeof(uint8_t),
> + __alignof__(uint8_t), 0);
> + if (offset2 != offset)
> + GOTO_FAIL("failed to lookup dynamic field, offset=%d, offset2=%d: %s",
> + offset, offset2, strerror(errno));
> +
> + offset2 = rte_mbuf_dynfield_register("test-dynfield2", sizeof(uint16_t),
> + __alignof__(uint16_t), 0);
> + if (offset2 == -1 || offset2 == offset || (offset & 1))
> + GOTO_FAIL("failed to register dynfield field 2, offset=%d, offset2=%d: %s",
> + offset, offset2, strerror(errno));
> +
> + printf("offset = %d, offset2 = %d\n", offset, offset2);
> +
> + offset = rte_mbuf_dynfield_register("test-dynfield-fail", 256, 1, 0);
> + if (offset != -1)
> + GOTO_FAIL("dynamic field creation should fail (too big)");
> +
> + offset = rte_mbuf_dynfield_register("test-dynfield-fail", 1, 3, 0);
> + if (offset != -1)
> + GOTO_FAIL("dynamic field creation should fail (bad alignment)");
> +
> + flag = rte_mbuf_dynflag_register("test-dynflag");
> + if (flag == -1)
> + GOTO_FAIL("failed to register dynamic field, flag=%d: %s",
> + flag, strerror(errno));
> +
> + flag2 = rte_mbuf_dynflag_register("test-dynflag");
> + if (flag2 != flag)
> + GOTO_FAIL("failed to lookup dynamic field, flag=%d, flag2=%d: %s",
> + flag, flag2, strerror(errno));
> +
> + flag2 = rte_mbuf_dynflag_register("test-dynflag2");
> + if (flag2 == -1 || flag2 == flag)
> + GOTO_FAIL("failed to register dynflag field 2, flag=%d, flag2=%d: %s",
> + flag, flag2, strerror(errno));
> +
> + printf("flag = %d, flag2 = %d\n", flag, flag2);
> +
> + /* set, get dynamic field */
> + m = rte_pktmbuf_alloc(pktmbuf_pool);
> + if (m == NULL)
> + GOTO_FAIL("Cannot allocate mbuf");
> +
> + *RTE_MBUF_DYNFIELD(m, offset, uint8_t *) = 1;
> + if (*RTE_MBUF_DYNFIELD(m, offset, uint8_t *) != 1)
> + GOTO_FAIL("failed to read dynamic field");
> + *RTE_MBUF_DYNFIELD(m, offset2, uint16_t *) = 1000;
> + if (*RTE_MBUF_DYNFIELD(m, offset2, uint16_t *) != 1000)
> + GOTO_FAIL("failed to read dynamic field");
> +
> + /* set a dynamic flag */
> + m->ol_flags |= (1ULL << flag);
> +
> + rte_pktmbuf_free(m);
> + return 0;
> +fail:
> + rte_pktmbuf_free(m);
> + return -1;
> +}
> +#undef GOTO_FAIL
> +
> +static int
> test_mbuf(void)
> {
> int ret = -1;
> @@ -1140,6 +1215,12 @@ test_mbuf(void)
> goto err;
> }
>
> + /* test registration of dynamic fields and flags */
> + if (test_mbuf_dyn(pktmbuf_pool) < 0) {
> + printf("mbuf dynflag test failed\n");
> + goto err;
> + }
> +
> /* create a specific pktmbuf pool with a priv_size != 0 and no data
> * room size */
> pktmbuf_pool2 = rte_pktmbuf_pool_create("test_pktmbuf_pool2",
> diff --git a/lib/librte_mbuf/Makefile b/lib/librte_mbuf/Makefile
> index c8f6d2689..5a9bcee73 100644
> --- a/lib/librte_mbuf/Makefile
> +++ b/lib/librte_mbuf/Makefile
> @@ -17,8 +17,10 @@ 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
> +SRCS-$(CONFIG_RTE_LIBRTE_MBUF) += rte_mbuf_dyn.c
>
> # install includes
> SYMLINK-$(CONFIG_RTE_LIBRTE_MBUF)-include := rte_mbuf.h rte_mbuf_ptype.h rte_mbuf_pool_ops.h
> +SYMLINK-$(CONFIG_RTE_LIBRTE_MBUF)-include += rte_mbuf_dyn.h
>
> include $(RTE_SDK)/mk/rte.lib.mk
> diff --git a/lib/librte_mbuf/meson.build b/lib/librte_mbuf/meson.build
> index 6cc11ebb4..9137e8f26 100644
> --- a/lib/librte_mbuf/meson.build
> +++ b/lib/librte_mbuf/meson.build
> @@ -2,8 +2,10 @@
> # Copyright(c) 2017 Intel Corporation
>
> 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')
> +sources = files('rte_mbuf.c', 'rte_mbuf_ptype.c', 'rte_mbuf_pool_ops.c',
> + 'rte_mbuf_dyn.c')
> +headers = files('rte_mbuf.h', 'rte_mbuf_ptype.h', 'rte_mbuf_pool_ops.h',
> + 'rte_mbuf_dyn.h')
> deps += ['mempool']
>
> allow_experimental_apis = true
> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> index 98225ec80..ef588cd54 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -198,9 +198,12 @@ extern "C" {
> #define PKT_RX_OUTER_L4_CKSUM_GOOD (1ULL << 22)
> #define PKT_RX_OUTER_L4_CKSUM_INVALID ((1ULL << 21) | (1ULL << 22))
>
> -/* add new RX flags here */
> +/* add new RX flags here, don't forget to update PKT_FIRST_FREE */
>
> -/* add new TX flags here */
> +#define PKT_FIRST_FREE (1ULL << 23)
> +#define PKT_LAST_FREE (1ULL << 39)
> +
> +/* add new TX flags here, don't forget to update PKT_LAST_FREE */
>
> /**
> * Indicate that the metadata field in the mbuf is in use.
> @@ -738,6 +741,8 @@ struct rte_mbuf {
> */
> struct rte_mbuf_ext_shared_info *shinfo;
>
> + uint64_t dynfield1; /**< Reserved for dynamic fields. */
> + uint64_t dynfield2; /**< Reserved for dynamic fields. */
> } __rte_cache_aligned;
>
> /**
> @@ -1685,6 +1690,21 @@ rte_pktmbuf_attach_extbuf(struct rte_mbuf *m, void *buf_addr,
> #define rte_pktmbuf_detach_extbuf(m) rte_pktmbuf_detach(m)
>
> /**
> + * Copy dynamic fields from m_src to m_dst.
> + *
> + * @param m_dst
> + * The destination mbuf.
> + * @param m_src
> + * The source mbuf.
> + */
> +static inline void
> +rte_mbuf_dynfield_copy(struct rte_mbuf *m_dst, const struct rte_mbuf *m_src)
> +{
> + m_dst->dynfield1 = m_src->dynfield1;
> + m_dst->dynfield2 = m_src->dynfield2;
> +}
> +
> +/**
> * Attach packet mbuf to another packet mbuf.
> *
> * If the mbuf we are attaching to isn't a direct buffer and is attached to
> @@ -1732,6 +1752,7 @@ static inline void rte_pktmbuf_attach(struct rte_mbuf *mi, struct rte_mbuf *m)
> mi->vlan_tci_outer = m->vlan_tci_outer;
> mi->tx_offload = m->tx_offload;
> mi->hash = m->hash;
> + rte_mbuf_dynfield_copy(mi, m);
>
> mi->next = NULL;
> mi->pkt_len = mi->data_len;
> diff --git a/lib/librte_mbuf/rte_mbuf_dyn.c b/lib/librte_mbuf/rte_mbuf_dyn.c
> new file mode 100644
> index 000000000..6a96a43da
> --- /dev/null
> +++ b/lib/librte_mbuf/rte_mbuf_dyn.c
> @@ -0,0 +1,373 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright 2019 6WIND S.A.
> + */
> +
> +#include <sys/queue.h>
> +
> +#include <rte_common.h>
> +#include <rte_eal.h>
> +#include <rte_eal_memconfig.h>
> +#include <rte_tailq.h>
> +#include <rte_errno.h>
> +#include <rte_malloc.h>
> +#include <rte_string_fns.h>
> +#include <rte_mbuf.h>
> +#include <rte_mbuf_dyn.h>
> +
> +#define RTE_MBUF_DYN_MZNAME "rte_mbuf_dyn"
> +
> +struct mbuf_dynfield {
> + TAILQ_ENTRY(mbuf_dynfield) next;
> + char name[RTE_MBUF_DYN_NAMESIZE];
> + size_t size;
> + size_t align;
> + unsigned int flags;
> + int offset;
> +};
> +TAILQ_HEAD(mbuf_dynfield_list, rte_tailq_entry);
> +
> +static struct rte_tailq_elem mbuf_dynfield_tailq = {
> + .name = "RTE_MBUF_DYNFIELD",
> +};
> +EAL_REGISTER_TAILQ(mbuf_dynfield_tailq);
> +
> +struct mbuf_dynflag {
> + TAILQ_ENTRY(mbuf_dynflag) next;
> + char name[RTE_MBUF_DYN_NAMESIZE];
> + int bitnum;
> +};
> +TAILQ_HEAD(mbuf_dynflag_list, rte_tailq_entry);
> +
> +static struct rte_tailq_elem mbuf_dynflag_tailq = {
> + .name = "RTE_MBUF_DYNFLAG",
> +};
> +EAL_REGISTER_TAILQ(mbuf_dynflag_tailq);
> +
> +struct mbuf_dyn_shm {
> + /** For each mbuf byte, free_space[i] == 1 if space is free. */
> + uint8_t free_space[sizeof(struct rte_mbuf)];
> + /** Bitfield of available flags. */
> + uint64_t free_flags;
> +};
> +static struct mbuf_dyn_shm *shm;
> +
> +/* allocate and initialize the shared memory */
> +static int
> +init_shared_mem(void)
> +{
> + const struct rte_memzone *mz;
> + uint64_t mask;
> +
> + if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
> + mz = rte_memzone_reserve_aligned(RTE_MBUF_DYN_MZNAME,
> + sizeof(struct mbuf_dyn_shm),
> + SOCKET_ID_ANY, 0,
> + RTE_CACHE_LINE_SIZE);
> + } else {
> + mz = rte_memzone_lookup(RTE_MBUF_DYN_MZNAME);
> + }
> + if (mz == NULL)
> + return -1;
> +
> + shm = mz->addr;
> +
> +#define mark_free(field) \
> + memset(&shm->free_space[offsetof(struct rte_mbuf, field)], \
> + 0xff, sizeof(((struct rte_mbuf *)0)->field))
> +
> + if (rte_eal_process_type() == RTE_PROC_PRIMARY) {
> + /* init free_space, keep it sync'd with
> + * rte_mbuf_dynfield_copy().
> + */
> + memset(shm, 0, sizeof(*shm));
> + mark_free(dynfield1);
> + mark_free(dynfield2);
> +
> + /* init free_flags */
> + for (mask = PKT_FIRST_FREE; mask <= PKT_LAST_FREE; mask <<= 1)
> + shm->free_flags |= mask;
> + }
> +#undef mark_free
> +
> + return 0;
> +}
> +
> +/* check if this offset can be used */
> +static int
> +check_offset(size_t offset, size_t size, size_t align, unsigned int flags)
> +{
> + size_t i;
> +
> + (void)flags;
> +
> + if ((offset & (align - 1)) != 0)
> + return -1;
> + if (offset + size > sizeof(struct rte_mbuf))
> + return -1;
> +
> + for (i = 0; i < size; i++) {
> + if (!shm->free_space[i + offset])
> + return -1;
> + }
> +
> + return 0;
> +}
> +
> +/* assume tailq is locked */
> +static struct mbuf_dynfield *
> +__mbuf_dynfield_lookup(const char *name)
> +{
> + struct mbuf_dynfield_list *mbuf_dynfield_list;
> + struct mbuf_dynfield *mbuf_dynfield;
> + struct rte_tailq_entry *te;
> +
> + mbuf_dynfield_list = RTE_TAILQ_CAST(
> + mbuf_dynfield_tailq.head, mbuf_dynfield_list);
> +
> + TAILQ_FOREACH(te, mbuf_dynfield_list, next) {
> + mbuf_dynfield = (struct mbuf_dynfield *)te->data;
> + if (strncmp(name, mbuf_dynfield->name,
> + RTE_MBUF_DYN_NAMESIZE) == 0)
> + break;
> + }
> +
> + if (te == NULL) {
> + rte_errno = ENOENT;
> + return NULL;
> + }
> +
> + return mbuf_dynfield;
> +}
> +
> +int
> +rte_mbuf_dynfield_lookup(const char *name, size_t *size, size_t *align)
> +{
> + struct mbuf_dynfield *mbuf_dynfield;
> +
> + if (shm == NULL) {
> + rte_errno = ENOENT;
> + return -1;
> + }
> +
> + rte_mcfg_tailq_read_lock();
> + mbuf_dynfield = __mbuf_dynfield_lookup(name);
> + rte_mcfg_tailq_read_unlock();
> +
> + if (mbuf_dynfield == NULL) {
> + rte_errno = ENOENT;
> + return -1;
> + }
> +
> + if (size != NULL)
> + *size = mbuf_dynfield->size;
> + if (align != NULL)
> + *align = mbuf_dynfield->align;
> +
> + return mbuf_dynfield->offset;
> +}
> +
> +int
> +rte_mbuf_dynfield_register(const char *name, size_t size, size_t align,
> + unsigned int flags)
> +{
> + struct mbuf_dynfield_list *mbuf_dynfield_list;
> + struct mbuf_dynfield *mbuf_dynfield = NULL;
> + struct rte_tailq_entry *te = NULL;
> + int offset, ret;
> + size_t i;
> +
> + if (shm == NULL && init_shared_mem() < 0)
> + goto fail;
> + if (size >= sizeof(struct rte_mbuf)) {
> + rte_errno = EINVAL;
> + goto fail;
> + }
> + if (!rte_is_power_of_2(align)) {
> + rte_errno = EINVAL;
> + goto fail;
> + }
> +
> + rte_mcfg_tailq_write_lock();
> +
> + mbuf_dynfield = __mbuf_dynfield_lookup(name);
> + if (mbuf_dynfield != NULL) {
> + if (mbuf_dynfield->size != size ||
> + mbuf_dynfield->align != align ||
> + mbuf_dynfield->flags != flags) {
> + rte_errno = EEXIST;
> + goto fail_unlock;
> + }
> + offset = mbuf_dynfield->offset;
> + goto out_unlock;
> + }
> +
> + if (rte_eal_process_type() != RTE_PROC_PRIMARY) {
> + rte_errno = EPERM;
> + goto fail_unlock;
> + }
> +
> + for (offset = 0;
> + offset < (int)sizeof(struct rte_mbuf);
> + offset++) {
> + if (check_offset(offset, size, align, flags) == 0)
> + break;
> + }
> +
> + if (offset == sizeof(struct rte_mbuf)) {
> + rte_errno = ENOENT;
> + goto fail_unlock;
> + }
> +
> + mbuf_dynfield_list = RTE_TAILQ_CAST(
> + mbuf_dynfield_tailq.head, mbuf_dynfield_list);
> +
> + te = rte_zmalloc("MBUF_DYNFIELD_TAILQ_ENTRY", sizeof(*te), 0);
> + if (te == NULL)
> + goto fail_unlock;
> +
> + mbuf_dynfield = rte_zmalloc("mbuf_dynfield", sizeof(*mbuf_dynfield), 0);
> + if (mbuf_dynfield == NULL)
> + goto fail_unlock;
> +
> + ret = strlcpy(mbuf_dynfield->name, name, sizeof(mbuf_dynfield->name));
> + if (ret < 0 || ret >= (int)sizeof(mbuf_dynfield->name)) {
> + rte_errno = ENAMETOOLONG;
> + goto fail_unlock;
> + }
> + mbuf_dynfield->size = size;
> + mbuf_dynfield->align = align;
> + mbuf_dynfield->flags = flags;
> + mbuf_dynfield->offset = offset;
> + te->data = mbuf_dynfield;
> +
> + TAILQ_INSERT_TAIL(mbuf_dynfield_list, te, next);
> +
> + for (i = offset; i < offset + size; i++)
> + shm->free_space[i] = 0;
> +
> +out_unlock:
> + rte_mcfg_tailq_write_unlock();
> +
> + return offset;
> +
> +fail_unlock:
> + rte_mcfg_tailq_write_unlock();
> +fail:
> + rte_free(mbuf_dynfield);
> + rte_free(te);
> + return -1;
> +}
> +
> +/* assume tailq is locked */
> +static struct mbuf_dynflag *
> +__mbuf_dynflag_lookup(const char *name)
> +{
> + struct mbuf_dynflag_list *mbuf_dynflag_list;
> + struct mbuf_dynflag *mbuf_dynflag;
> + struct rte_tailq_entry *te;
> +
> + mbuf_dynflag_list = RTE_TAILQ_CAST(
> + mbuf_dynflag_tailq.head, mbuf_dynflag_list);
> +
> + TAILQ_FOREACH(te, mbuf_dynflag_list, next) {
> + mbuf_dynflag = (struct mbuf_dynflag *)te->data;
> + if (strncmp(name, mbuf_dynflag->name,
> + RTE_MBUF_DYN_NAMESIZE) == 0)
> + break;
> + }
> +
> + if (te == NULL) {
> + rte_errno = ENOENT;
> + return NULL;
> + }
> +
> + return mbuf_dynflag;
> +}
> +
> +int
> +rte_mbuf_dynflag_lookup(const char *name)
> +{
> + struct mbuf_dynflag *mbuf_dynflag;
> +
> + if (shm == NULL) {
> + rte_errno = ENOENT;
> + return -1;
> + }
> +
> + rte_mcfg_tailq_read_lock();
> + mbuf_dynflag = __mbuf_dynflag_lookup(name);
> + rte_mcfg_tailq_read_unlock();
> +
> + if (mbuf_dynflag == NULL) {
> + rte_errno = ENOENT;
> + return -1;
> + }
> +
> + return mbuf_dynflag->bitnum;
> +}
> +
> +int
> +rte_mbuf_dynflag_register(const char *name)
> +{
> + struct mbuf_dynflag_list *mbuf_dynflag_list;
> + struct mbuf_dynflag *mbuf_dynflag = NULL;
> + struct rte_tailq_entry *te = NULL;
> + int bitnum, ret;
> +
> + if (shm == NULL && init_shared_mem() < 0)
> + goto fail;
> +
> + rte_mcfg_tailq_write_lock();
> +
> + mbuf_dynflag = __mbuf_dynflag_lookup(name);
> + if (mbuf_dynflag != NULL) {
> + bitnum = mbuf_dynflag->bitnum;
> + goto out_unlock;
> + }
> +
> + if (rte_eal_process_type() != RTE_PROC_PRIMARY) {
> + rte_errno = EPERM;
> + goto fail_unlock;
> + }
> +
> + if (shm->free_flags == 0) {
> + rte_errno = ENOENT;
> + goto fail_unlock;
> + }
> + bitnum = rte_bsf64(shm->free_flags);
> +
> + mbuf_dynflag_list = RTE_TAILQ_CAST(
> + mbuf_dynflag_tailq.head, mbuf_dynflag_list);
> +
> + te = rte_zmalloc("MBUF_DYNFLAG_TAILQ_ENTRY", sizeof(*te), 0);
> + if (te == NULL)
> + goto fail_unlock;
> +
> + mbuf_dynflag = rte_zmalloc("mbuf_dynflag", sizeof(*mbuf_dynflag), 0);
> + if (mbuf_dynflag == NULL)
> + goto fail_unlock;
> +
> + ret = strlcpy(mbuf_dynflag->name, name, sizeof(mbuf_dynflag->name));
> + if (ret < 0 || ret >= (int)sizeof(mbuf_dynflag->name)) {
> + rte_errno = ENAMETOOLONG;
> + goto fail_unlock;
> + }
> + mbuf_dynflag->bitnum = bitnum;
> + te->data = mbuf_dynflag;
> +
> + TAILQ_INSERT_TAIL(mbuf_dynflag_list, te, next);
> +
> + shm->free_flags &= ~(1ULL << bitnum);
> +
> +out_unlock:
> + rte_mcfg_tailq_write_unlock();
> +
> + return bitnum;
> +
> +fail_unlock:
> + rte_mcfg_tailq_write_unlock();
> +fail:
> + rte_free(mbuf_dynflag);
> + rte_free(te);
> + return -1;
> +}
> diff --git a/lib/librte_mbuf/rte_mbuf_dyn.h b/lib/librte_mbuf/rte_mbuf_dyn.h
> new file mode 100644
> index 000000000..a86986a0f
> --- /dev/null
> +++ b/lib/librte_mbuf/rte_mbuf_dyn.h
> @@ -0,0 +1,119 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright 2019 6WIND S.A.
> + */
> +
> +#ifndef _RTE_MBUF_DYN_H_
> +#define _RTE_MBUF_DYN_H_
> +
> +/**
> + * @file
> + * RTE Mbuf dynamic fields and flags
> + *
> + * Many features require to store data inside the mbuf. As the room in
> + * mbuf structure is limited, it is not possible to have a field for
> + * each feature. Also, changing fields in the mbuf structure can break
> + * the API or ABI.
> + *
> + * This module addresses this issue, by enabling the dynamic
> + * registration of fields or flags:
> + *
> + * - a dynamic field is a named area in the rte_mbuf structure, with a
> + * given size (>= 1 byte) and alignment constraint.
> + * - a dynamic flag is a named bit in the rte_mbuf structure.
> + *
> + * The typical use case is a PMD that registers space for an offload
> + * feature, when the application requests to enable this feature. As
> + * the space in mbuf is limited, the space should only be reserved if it
> + * is going to be used (i.e when the application explicitly asks for it).
> + *
> + * The registration can be done at any moment, but it is not possible
> + * to unregister fields or flags for now.
> + *
> + * Example of use:
> + *
> + * - RTE_MBUF_DYN_<feature>_(ID|SIZE|ALIGN) are defined in this file
Does it means that all PMDs define their own 'RTE_MBUF_DYN_<feature>_(ID|SIZE|ALIGN)'
here ? In other words, each PMD can expose its private DYN_<feature> here for public
using ?
How about adding another eth_dev_ops API definitions to show the PMD's supporting feature
names, sizes, align in run time for testpmd ? And also another eth_dev_ops API for showing
the data saved in rte_mbuf by 'dump_pkt_burst' ? Adding a new command for testpmd to set
the dynamic feature may be good for PMD test.
> + * - If the application asks for the feature, the PMD use
How does the application ask for the feature ? By ' rte_mbuf_dynfield_register()' ?
> + * rte_mbuf_dynfield_register() to get the dynamic offset and stores
> + * in a global variable.
In case, the PMD calls 'rte_mbuf_dynfield_register()' for 'dyn_feature' firstly, this
means that PMD requests the dynamic feature itself if I understand correctly. Should
PMD calls 'rte_mbuf_dynfield_lookup' for 'dyn_feature' to query the name exists, the
size and align are right as expected ? If exists, but size and align are not right, may
be for PMD change its definition, then PMD can give a warning or error message. If name
exists, both size and align are expected, then PMD think that the application request
the right dynamic features.
> + * - The application also calls rte_mbuf_dynfield_register() to get the
> + * dynamic offset and stores it in a global variable.
> + * - When the field must be used by the PMD or the application, they
> + * use the RTE_MBUF_DYNFIELD() helper.
> + */
> +
> +struct rte_mbuf;
> +
> +/**
> + * Register space for a dynamic field in the mbuf structure.
> + *
> + * @param name
> + * A string identifying the dynamic field. External applications or
> + * libraries must not define identifers prefixed with "rte_", which
> + * are reserved for standard features.
> + * @param size
> + * The number of bytes to reserve.
> + * @param align
> + * The alignment constraint, which must be a power of 2.
> + * @param flags
> + * Reserved for future use.
> + * @return
> + * The offset in the mbuf structure, or -1 on error (rte_errno is set).
> + */
> +__rte_experimental
> +int rte_mbuf_dynfield_register(const char *name, size_t size, size_t align,
> + unsigned int flags);
> +
> +/**
> + * Lookup for a registered dynamic mbuf field.
> + *
> + * @param name
> + * A string identifying the dynamic field.
> + * @param size
> + * If not NULL, the number of reserved bytes for this field is stored
> + * at this address.
> + * @param align
> + * If not NULL, the alignement constraint for this field is stored
> + * at this address.
> + * @return
> + * The offset of this field in the mbuf structure, or -1 on error
> + * (rte_errno is set).
> + */
> +__rte_experimental
> +int rte_mbuf_dynfield_lookup(const char *name, size_t *size, size_t *align);
> +
> +/**
> + * Register a dynamic flag in the mbuf structure.
> + *
> + * @param name
> + * A string identifying the dynamic flag. External applications or
> + * libraries must not define identifers prefixed with "rte_", which
> + * are reserved for standard features.
> + * @return
> + * The number of the reserved bit, or -1 on error (rte_errno is set).
> + */
> +__rte_experimental
> +int rte_mbuf_dynflag_register(const char *name);
> +
> +/**
> + * Lookup for a registered dynamic mbuf flag.
> + *
> + * @param name
> + * A string identifying the dynamic flag.
> + * @return
> + * The offset of this flag in the mbuf structure, or -1 on error
> + * (rte_errno is set).
> + */
> +__rte_experimental
> +int rte_mbuf_dynflag_lookup(const char *name);
> +
> +/**
> + * Helper macro to access to a dynamic field.
> + */
> +#define RTE_MBUF_DYNFIELD(m, offset, type) ((type)((char *)(m) + (offset)))
> +
> +/**
> + * Maximum length of the dynamic field or flag string.
> + */
> +#define RTE_MBUF_DYN_NAMESIZE 32
> +
> +#endif
> diff --git a/lib/librte_mbuf/rte_mbuf_version.map b/lib/librte_mbuf/rte_mbuf_version.map
> index 2662a37bf..a98310570 100644
> --- a/lib/librte_mbuf/rte_mbuf_version.map
> +++ b/lib/librte_mbuf/rte_mbuf_version.map
> @@ -50,4 +50,8 @@ EXPERIMENTAL {
> global:
>
> rte_mbuf_check;
> + rte_mbuf_dynfield_lookup;
> + rte_mbuf_dynfield_register;
> + rte_mbuf_dynflag_lookup;
> + rte_mbuf_dynflag_register;
> } DPDK_18.08;
> --
> 2.11.0
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags
2019-07-10 9:29 4% [dpdk-dev] [RFC] mbuf: support dynamic fields and flags Olivier Matz
2019-07-10 17:14 0% ` Wang, Haiyue
@ 2019-07-10 17:49 3% ` Stephen Hemminger
2019-07-10 18:12 0% ` Wiles, Keith
2019-07-11 7:36 0% ` Olivier Matz
2019-07-11 9:24 3% ` Thomas Monjalon
2019-07-12 14:54 0% ` Andrew Rybchenko
3 siblings, 2 replies; 200+ results
From: Stephen Hemminger @ 2019-07-10 17:49 UTC (permalink / raw)
To: Olivier Matz; +Cc: dev
On Wed, 10 Jul 2019 11:29:07 +0200
Olivier Matz <olivier.matz@6wind.com> wrote:
> /**
> * Indicate that the metadata field in the mbuf is in use.
> @@ -738,6 +741,8 @@ struct rte_mbuf {
> */
> struct rte_mbuf_ext_shared_info *shinfo;
>
> + uint64_t dynfield1; /**< Reserved for dynamic fields. */
> + uint64_t dynfield2; /**< Reserved for dynamic fields. */
> } __rte_cache_aligned;
Growing mbuf is a fundamental ABI break and this needs
higher level approval. Why not one pointer?
It looks like you are creating something like FreeBSD m_tag.
Why not use that?
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags
2019-07-10 17:49 3% ` Stephen Hemminger
@ 2019-07-10 18:12 0% ` Wiles, Keith
2019-07-11 7:53 4% ` Olivier Matz
2019-07-11 7:36 0% ` Olivier Matz
1 sibling, 1 reply; 200+ results
From: Wiles, Keith @ 2019-07-10 18:12 UTC (permalink / raw)
To: Olivier Matz; +Cc: dpdk dev community, Stephen Hemminger
> On Jul 10, 2019, at 12:49 PM, Stephen Hemminger <stephen@networkplumber.org> wrote:
>
> On Wed, 10 Jul 2019 11:29:07 +0200
> Olivier Matz <olivier.matz@6wind.com> wrote:
>
>> /**
>> * Indicate that the metadata field in the mbuf is in use.
>> @@ -738,6 +741,8 @@ struct rte_mbuf {
>> */
>> struct rte_mbuf_ext_shared_info *shinfo;
>>
>> + uint64_t dynfield1; /**< Reserved for dynamic fields. */
>> + uint64_t dynfield2; /**< Reserved for dynamic fields. */
>> } __rte_cache_aligned;
>
> Growing mbuf is a fundamental ABI break and this needs
> higher level approval. Why not one pointer?
>
> It looks like you are creating something like FreeBSD m_tag.
> Why not use that?
Changing the mbuf structure causes a big problem for a number reasons as Stephen states.
If we leave the mbuf stucture alone and add this feature to the headroom space between the mbuf structure and the packet. When setting up the mempool/mbuf pool we define a headroom to hold the extra data when the mbuf pool is created or just use the current headroom space. Using this method we can eliminate the mbuf structure change and add the data to the packet buffer. We can do away with dynfield1 and 2 as we know where headroom space begins and ends. Just a thought.
Regards,
Keith
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags
2019-07-10 17:14 0% ` Wang, Haiyue
@ 2019-07-11 7:26 0% ` Olivier Matz
2019-07-11 8:04 0% ` Wang, Haiyue
0 siblings, 1 reply; 200+ results
From: Olivier Matz @ 2019-07-11 7:26 UTC (permalink / raw)
To: Wang, Haiyue; +Cc: dev
Hi,
On Wed, Jul 10, 2019 at 05:14:33PM +0000, Wang, Haiyue wrote:
> Hi,
>
> Sounds cool, just have some questions inline.
>
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier Matz
> > Sent: Wednesday, July 10, 2019 17:29
> > To: dev@dpdk.org
> > Subject: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags
> >
> > Many features require to store data inside the mbuf. As the room in mbuf
> > structure is limited, it is not possible to have a field for each
> > feature. Also, changing fields in the mbuf structure can break the API
> > or ABI.
> >
> > This commit addresses these issues, by enabling the dynamic registration
> > of fields or flags:
> >
> > - a dynamic field is a named area in the rte_mbuf structure, with a
> > given size (>= 1 byte) and alignment constraint.
> > - a dynamic flag is a named bit in the rte_mbuf structure.
> >
> > The typical use case is a PMD that registers space for an offload
> > feature, when the application requests to enable this feature. As
> > the space in mbuf is limited, the space should only be reserved if it
> > is going to be used (i.e when the application explicitly asks for it).
> >
> > The registration can be done at any moment, but it is not possible
> > to unregister fields or flags for now.
> >
> > Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
(...)
> > +/**
> > + * @file
> > + * RTE Mbuf dynamic fields and flags
> > + *
> > + * Many features require to store data inside the mbuf. As the room in
> > + * mbuf structure is limited, it is not possible to have a field for
> > + * each feature. Also, changing fields in the mbuf structure can break
> > + * the API or ABI.
> > + *
> > + * This module addresses this issue, by enabling the dynamic
> > + * registration of fields or flags:
> > + *
> > + * - a dynamic field is a named area in the rte_mbuf structure, with a
> > + * given size (>= 1 byte) and alignment constraint.
> > + * - a dynamic flag is a named bit in the rte_mbuf structure.
> > + *
> > + * The typical use case is a PMD that registers space for an offload
> > + * feature, when the application requests to enable this feature. As
> > + * the space in mbuf is limited, the space should only be reserved if it
> > + * is going to be used (i.e when the application explicitly asks for it).
> > + *
> > + * The registration can be done at any moment, but it is not possible
> > + * to unregister fields or flags for now.
> > + *
> > + * Example of use:
> > + *
> > + * - RTE_MBUF_DYN_<feature>_(ID|SIZE|ALIGN) are defined in this file
>
> Does it means that all PMDs define their own 'RTE_MBUF_DYN_<feature>_(ID|SIZE|ALIGN)'
> here ? In other words, each PMD can expose its private DYN_<feature> here for public
> using ?
For generic fields, I think they should be declared in this file. For
instance, if we decide to replace the current m->timestamp field by a
dynamic field, we should add like this:
#define RTE_MBUF_DYN_TIMESTAMP_ID "rte_timestamp"
#define RTE_MBUF_DYN_TIMESTAMP_SIZE sizeof(uint64_t)
#define RTE_MBUF_DYN_TIMESTAMP_ALIGN __alignof__(uint64_t)
If the feature is PMD-specific, the defines could be exposed in a
PMD header.
> How about adding another eth_dev_ops API definitions to show the PMD's supporting feature
> names, sizes, align in run time for testpmd ? And also another eth_dev_ops API for showing
> the data saved in rte_mbuf by 'dump_pkt_burst' ? Adding a new command for testpmd to set
> the dynamic feature may be good for PMD test.
>
> > + * - If the application asks for the feature, the PMD use
>
> How does the application ask for the feature ? By ' rte_mbuf_dynfield_register()' ?
No change in this area. If we take again the timestamp example, the
feature is asked by the application through the ethdev layer by passing
DEV_RX_OFFLOAD_TIMESTAMP to port or queue configuration.
>
> > + * rte_mbuf_dynfield_register() to get the dynamic offset and stores
> > + * in a global variable.
>
> In case, the PMD calls 'rte_mbuf_dynfield_register()' for 'dyn_feature' firstly, this
> means that PMD requests the dynamic feature itself if I understand correctly. Should
> PMD calls 'rte_mbuf_dynfield_lookup' for 'dyn_feature' to query the name exists, the
> size and align are right as expected ? If exists, but size and align are not right, may
> be for PMD change its definition, then PMD can give a warning or error message. If name
> exists, both size and align are expected, then PMD think that the application request
> the right dynamic features.
The PMD should only call rte_mbuf_dynfield_register() if the application
requests the feature (through ethdev, or through another mean if it's a
PMD-specific feature). The goal is to only reserve the area in the mbuf
for features that are actually needed.
Hope this is clearer now. I think I need to enhance the documentation in
next version ;)
Thanks for the feedback.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags
2019-07-10 17:49 3% ` Stephen Hemminger
2019-07-10 18:12 0% ` Wiles, Keith
@ 2019-07-11 7:36 0% ` Olivier Matz
1 sibling, 1 reply; 200+ results
From: Olivier Matz @ 2019-07-11 7:36 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev
On Wed, Jul 10, 2019 at 10:49:17AM -0700, Stephen Hemminger wrote:
> On Wed, 10 Jul 2019 11:29:07 +0200
> Olivier Matz <olivier.matz@6wind.com> wrote:
>
> > /**
> > * Indicate that the metadata field in the mbuf is in use.
> > @@ -738,6 +741,8 @@ struct rte_mbuf {
> > */
> > struct rte_mbuf_ext_shared_info *shinfo;
> >
> > + uint64_t dynfield1; /**< Reserved for dynamic fields. */
> > + uint64_t dynfield2; /**< Reserved for dynamic fields. */
> > } __rte_cache_aligned;
>
> Growing mbuf is a fundamental ABI break and this needs
> higher level approval.
The size of the mbuf is still 128, I used the last 16 bytes that
were unused.
Later, we can think about removing existing fields and replace
them by a dynfield area, which can be anywhere in the structure
(even if it is in a 1 byte hole).
> Why not one pointer?
A pointer to what?
> It looks like you are creating something like FreeBSD m_tag.
> Why not use that?
My implementation targets performance (accessing to *(mbuf + offset)
should be nearly as fast as accessing to a static field), at the price
of less flexibility compared to something like FreeBSD m_tag.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] ethdev: extend flow metadata
2019-07-10 16:37 3% ` Yongseok Koh
@ 2019-07-11 7:44 0% ` Adrien Mazarguil
2019-07-14 11:46 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Adrien Mazarguil @ 2019-07-11 7:44 UTC (permalink / raw)
To: Yongseok Koh
Cc: Thomas Monjalon, Olivier Matz, Bruce Richardson,
Andrew Rybchenko, Shahaf Shuler, Ferruh Yigit, dev,
Slava Ovsiienko
On Wed, Jul 10, 2019 at 04:37:46PM +0000, Yongseok Koh wrote:
>
> > On Jul 10, 2019, at 5:26 AM, Thomas Monjalon <thomas@monjalon.net> wrote:
> >
> > 10/07/2019 14:01, Bruce Richardson:
> >> On Wed, Jul 10, 2019 at 12:07:43PM +0200, Olivier Matz wrote:
> >>> On Wed, Jul 10, 2019 at 10:55:34AM +0100, Bruce Richardson wrote:
> >>>> On Wed, Jul 10, 2019 at 11:31:56AM +0200, Olivier Matz wrote:
> >>>>> On Thu, Jul 04, 2019 at 04:21:22PM -0700, Yongseok Koh wrote:
> >>>>>> Currently, metadata can be set on egress path via mbuf tx_meatadata field
> >>>>>> with PKT_TX_METADATA flag and RTE_FLOW_ITEM_TYPE_RX_META matches metadata.
> >>>>>>
> >>>>>> This patch extends the usability.
> >>>>>>
> >>>>>> 1) RTE_FLOW_ACTION_TYPE_SET_META
> >>>>>>
> >>>>>> When supporting multiple tables, Tx metadata can also be set by a rule and
> >>>>>> matched by another rule. This new action allows metadata to be set as a
> >>>>>> result of flow match.
> >>>>>>
> >>>>>> 2) Metadata on ingress
> >>>>>>
> >>>>>> There's also need to support metadata on packet Rx. Metadata can be set by
> >>>>>> SET_META action and matched by META item like Tx. The final value set by
> >>>>>> the action will be delivered to application via mbuf metadata field with
> >>>>>> PKT_RX_METADATA ol_flag.
> >>>>>>
> >>>>>> For this purpose, mbuf->tx_metadata is moved as a separate new field and
> >>>>>> renamed to 'metadata' to support both Rx and Tx metadata.
> >>>>>>
> >>>>>> For loopback/hairpin packet, metadata set on Rx/Tx may or may not be
> >>>>>> propagated to the other path depending on HW capability.
> >>>>>>
> >>>>>> Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
> >>>>>
> >>>>>> --- a/lib/librte_mbuf/rte_mbuf.h
> >>>>>> +++ b/lib/librte_mbuf/rte_mbuf.h
> >>>>>> @@ -648,17 +653,6 @@ struct rte_mbuf {
> >>>>>> /**< User defined tags. See rte_distributor_process() */
> >>>>>> uint32_t usr;
> >>>>>> } hash; /**< hash information */
> >>>>>> - struct {
> >>>>>> - /**
> >>>>>> - * Application specific metadata value
> >>>>>> - * for egress flow rule match.
> >>>>>> - * Valid if PKT_TX_METADATA is set.
> >>>>>> - * Located here to allow conjunct use
> >>>>>> - * with hash.sched.hi.
> >>>>>> - */
> >>>>>> - uint32_t tx_metadata;
> >>>>>> - uint32_t reserved;
> >>>>>> - };
> >>>>>> };
> >>>>>>
> >>>>>> /** Outer VLAN TCI (CPU order), valid if PKT_RX_QINQ is set. */
> >>>>>> @@ -727,6 +721,11 @@ struct rte_mbuf {
> >>>>>> */
> >>>>>> struct rte_mbuf_ext_shared_info *shinfo;
> >>>>>>
> >>>>>> + /** Application specific metadata value for flow rule match.
> >>>>>> + * Valid if PKT_RX_METADATA or PKT_TX_METADATA is set.
> >>>>>> + */
> >>>>>> + uint32_t metadata;
> >>>>>> +
> >>>>>> } __rte_cache_aligned;
> >>>>>
> >>>>> This will break the ABI, so we cannot put it in 19.08, and we need a
> >>>>> deprecation notice.
> >>>>>
> >>>> Does it actually break the ABI? Adding a new field to the mbuf should only
> >>>> break the ABI if it either causes new fields to move or changes the
> >>>> structure size. Since this is at the end, it's not going to move any older
> >>>> fields, and since everything is cache-aligned I don't think the structure
> >>>> size changes either.
> >>>
> >>> I think it does break the ABI: in previous version, when the PKT_TX_METADATA
> >>> flag is set, the associated value is put in m->tx_metadata (offset 44 on
> >>> x86-64), and in the next version, it will be in m->metadata (offset 112). So,
> >>> these 2 versions are not binary compatible.
> >>>
> >>> Anyway, at least it breaks the API.
> >>
> >> Ok, I misunderstood. I thought it was the structure change itself you were
> >> saying broke the ABI. Yes, putting the data in a different place is indeed
> >> an ABI break.
> >
> > We could add the new field and keep the old one unused,
> > so it does not break the ABI.
>
> Still breaks ABI if PKT_TX_METADATA is set. :-) In order not to break it, I can
> keep the current union'd field (tx_metadata) as is with PKT_TX_METADATA, add
> the new one at the end and make it used with the new PKT_RX_METADATA.
>
> > However I suppose everybody will prefer a version using dynamic fields.
> > Is someone against using dynamic field for such usage?
>
> However, given that the amazing dynamic fields is coming soon (thanks for your
> effort, Olivier and Thomas!), I'd be honored to be the first user of it.
>
> Olivier, I'll take a look at your RFC.
Just got a crazy idea while reading this thread... How about repurposing
that "reserved" field as "rx_metadata" in the meantime?
I know reserved fields are cursed and no one's ever supposed to touch them
but this risk is mitigated by having the end user explicitly request its
use, so the patch author (and his relatives) should be safe from the
resulting bad juju.
Joke aside, while I like the idea of Tx/Rx META, I think the similarities
with MARK (and TAG eventually) is a problem. I wasn't available and couldn't
comment when META was originally added to the Tx path, but there's a lot of
overlap between these items/actions, without anything explaining to the end
user how and why they should pick one over the other, if they can be
combined at all and what happens in that case.
All this must be documented, then we should think about unifying their
respective features and deprecate the less capable items/actions. In my
opinion, users need exactly one method to mark/match some mark while
processing Rx/Tx traffic and *optionally* have that mark read from/written
to the mbuf, which may or may not be possible depending on HW features.
--
Adrien Mazarguil
6WIND
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags
2019-07-10 18:12 0% ` Wiles, Keith
@ 2019-07-11 7:53 4% ` Olivier Matz
2019-07-11 14:37 0% ` Wiles, Keith
0 siblings, 1 reply; 200+ results
From: Olivier Matz @ 2019-07-11 7:53 UTC (permalink / raw)
To: Wiles, Keith; +Cc: dpdk dev community, Stephen Hemminger
Hi Keith,
On Wed, Jul 10, 2019 at 06:12:16PM +0000, Wiles, Keith wrote:
>
>
> > On Jul 10, 2019, at 12:49 PM, Stephen Hemminger <stephen@networkplumber.org> wrote:
> >
> > On Wed, 10 Jul 2019 11:29:07 +0200
> > Olivier Matz <olivier.matz@6wind.com> wrote:
> >
> >> /**
> >> * Indicate that the metadata field in the mbuf is in use.
> >> @@ -738,6 +741,8 @@ struct rte_mbuf {
> >> */
> >> struct rte_mbuf_ext_shared_info *shinfo;
> >>
> >> + uint64_t dynfield1; /**< Reserved for dynamic fields. */
> >> + uint64_t dynfield2; /**< Reserved for dynamic fields. */
> >> } __rte_cache_aligned;
> >
> > Growing mbuf is a fundamental ABI break and this needs
> > higher level approval. Why not one pointer?
> >
> > It looks like you are creating something like FreeBSD m_tag.
> > Why not use that?
>
> Changing the mbuf structure causes a big problem for a number reasons as Stephen states.
Can you elaborate?
This is indeed an ABI break, but I think this is only due to the adding
of rte_mbuf_dynfield_copy() in rte_pktmbuf_attach(). The size of the
mbuf does not change and the fields are not initialized when creating a
new mbuf. So I think there is no ABI change for code that is not using
rte_pktmbuf_attach().
I don't think it's a problem to have one ABI change, if it avoids many
others in the future.
> If we leave the mbuf stucture alone and add this feature to the
> headroom space between the mbuf structure and the packet. When setting
> up the mempool/mbuf pool we define a headroom to hold the extra data
> when the mbuf pool is created or just use the current headroom
> space. Using this method we can eliminate the mbuf structure change
> and add the data to the packet buffer. We can do away with dynfield1
> and 2 as we know where headroom space begins and ends. Just a thought.
The size of the mbuf metadata (between the mbuf structure and the
buffer) is configured per pool, so it can be different accross
mbufs. So, the access to the dynamic field would be slower:
*(mbuf + dynfield_offset + metadata_size(mbuf))
Also, the size of the data buffer can be 0: it happens for mbuf pools
that are dedicated to mbuf clones (that reference data in another mbuf
or in an external buffer). In this case, there is no room after metadata
to store the dynamic fields.
Thanks,
Olivier
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags
2019-07-11 7:26 0% ` Olivier Matz
@ 2019-07-11 8:04 0% ` Wang, Haiyue
2019-07-11 8:20 0% ` Olivier Matz
0 siblings, 1 reply; 200+ results
From: Wang, Haiyue @ 2019-07-11 8:04 UTC (permalink / raw)
To: Olivier Matz; +Cc: dev
> -----Original Message-----
> From: Olivier Matz [mailto:olivier.matz@6wind.com]
> Sent: Thursday, July 11, 2019 15:26
> To: Wang, Haiyue <haiyue.wang@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags
>
> Hi,
>
> On Wed, Jul 10, 2019 at 05:14:33PM +0000, Wang, Haiyue wrote:
> > Hi,
> >
> > Sounds cool, just have some questions inline.
> >
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier Matz
> > > Sent: Wednesday, July 10, 2019 17:29
> > > To: dev@dpdk.org
> > > Subject: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags
> > >
> > > Many features require to store data inside the mbuf. As the room in mbuf
> > > structure is limited, it is not possible to have a field for each
> > > feature. Also, changing fields in the mbuf structure can break the API
> > > or ABI.
> > >
> > > This commit addresses these issues, by enabling the dynamic registration
> > > of fields or flags:
> > >
> > > - a dynamic field is a named area in the rte_mbuf structure, with a
> > > given size (>= 1 byte) and alignment constraint.
> > > - a dynamic flag is a named bit in the rte_mbuf structure.
> > >
> > > The typical use case is a PMD that registers space for an offload
> > > feature, when the application requests to enable this feature. As
> > > the space in mbuf is limited, the space should only be reserved if it
> > > is going to be used (i.e when the application explicitly asks for it).
> > >
> > > The registration can be done at any moment, but it is not possible
> > > to unregister fields or flags for now.
> > >
> > > Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
>
> (...)
>
> > > +/**
> > > + * @file
> > > + * RTE Mbuf dynamic fields and flags
> > > + *
> > > + * Many features require to store data inside the mbuf. As the room in
> > > + * mbuf structure is limited, it is not possible to have a field for
> > > + * each feature. Also, changing fields in the mbuf structure can break
> > > + * the API or ABI.
> > > + *
> > > + * This module addresses this issue, by enabling the dynamic
> > > + * registration of fields or flags:
> > > + *
> > > + * - a dynamic field is a named area in the rte_mbuf structure, with a
> > > + * given size (>= 1 byte) and alignment constraint.
> > > + * - a dynamic flag is a named bit in the rte_mbuf structure.
> > > + *
> > > + * The typical use case is a PMD that registers space for an offload
> > > + * feature, when the application requests to enable this feature. As
> > > + * the space in mbuf is limited, the space should only be reserved if it
> > > + * is going to be used (i.e when the application explicitly asks for it).
> > > + *
> > > + * The registration can be done at any moment, but it is not possible
> > > + * to unregister fields or flags for now.
> > > + *
> > > + * Example of use:
> > > + *
> > > + * - RTE_MBUF_DYN_<feature>_(ID|SIZE|ALIGN) are defined in this file
> >
> > Does it means that all PMDs define their own 'RTE_MBUF_DYN_<feature>_(ID|SIZE|ALIGN)'
> > here ? In other words, each PMD can expose its private DYN_<feature> here for public
> > using ?
>
> For generic fields, I think they should be declared in this file. For
> instance, if we decide to replace the current m->timestamp field by a
> dynamic field, we should add like this:
>
> #define RTE_MBUF_DYN_TIMESTAMP_ID "rte_timestamp"
> #define RTE_MBUF_DYN_TIMESTAMP_SIZE sizeof(uint64_t)
> #define RTE_MBUF_DYN_TIMESTAMP_ALIGN __alignof__(uint64_t)
>
> If the feature is PMD-specific, the defines could be exposed in a
> PMD header.
>
Now, understand the comments a little : ... must not define identifers prefixed with "rte_",
which are reserved for standard features. Seems have big plan ?
> > How about adding another eth_dev_ops API definitions to show the PMD's supporting feature
> > names, sizes, align in run time for testpmd ? And also another eth_dev_ops API for showing
> > the data saved in rte_mbuf by 'dump_pkt_burst' ? Adding a new command for testpmd to set
> > the dynamic feature may be good for PMD test.
> >
> > > + * - If the application asks for the feature, the PMD use
> >
> > How does the application ask for the feature ? By ' rte_mbuf_dynfield_register()' ?
>
> No change in this area. If we take again the timestamp example, the
> feature is asked by the application through the ethdev layer by passing
> DEV_RX_OFFLOAD_TIMESTAMP to port or queue configuration.
>
> >
> > > + * rte_mbuf_dynfield_register() to get the dynamic offset and stores
> > > + * in a global variable.
> >
> > In case, the PMD calls 'rte_mbuf_dynfield_register()' for 'dyn_feature' firstly, this
> > means that PMD requests the dynamic feature itself if I understand correctly. Should
> > PMD calls 'rte_mbuf_dynfield_lookup' for 'dyn_feature' to query the name exists, the
> > size and align are right as expected ? If exists, but size and align are not right, may
> > be for PMD change its definition, then PMD can give a warning or error message. If name
> > exists, both size and align are expected, then PMD think that the application request
> > the right dynamic features.
>
> The PMD should only call rte_mbuf_dynfield_register() if the application
> requests the feature (through ethdev, or through another mean if it's a
> PMD-specific feature). The goal is to only reserve the area in the mbuf
> for features that are actually needed.
>
> Hope this is clearer now. I think I need to enhance the documentation in
> next version ;)
>
Clearer now, more test code also will be better for fully understanding, thanks! :)
> Thanks for the feedback.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags
2019-07-11 8:04 0% ` Wang, Haiyue
@ 2019-07-11 8:20 0% ` Olivier Matz
2019-07-11 8:34 0% ` Wang, Haiyue
0 siblings, 1 reply; 200+ results
From: Olivier Matz @ 2019-07-11 8:20 UTC (permalink / raw)
To: Wang, Haiyue; +Cc: dev
On Thu, Jul 11, 2019 at 08:04:00AM +0000, Wang, Haiyue wrote:
> > -----Original Message-----
> > From: Olivier Matz [mailto:olivier.matz@6wind.com]
> > Sent: Thursday, July 11, 2019 15:26
> > To: Wang, Haiyue <haiyue.wang@intel.com>
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags
> >
> > Hi,
> >
> > On Wed, Jul 10, 2019 at 05:14:33PM +0000, Wang, Haiyue wrote:
> > > Hi,
> > >
> > > Sounds cool, just have some questions inline.
> > >
> > > > -----Original Message-----
> > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier Matz
> > > > Sent: Wednesday, July 10, 2019 17:29
> > > > To: dev@dpdk.org
> > > > Subject: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags
> > > >
> > > > Many features require to store data inside the mbuf. As the room in mbuf
> > > > structure is limited, it is not possible to have a field for each
> > > > feature. Also, changing fields in the mbuf structure can break the API
> > > > or ABI.
> > > >
> > > > This commit addresses these issues, by enabling the dynamic registration
> > > > of fields or flags:
> > > >
> > > > - a dynamic field is a named area in the rte_mbuf structure, with a
> > > > given size (>= 1 byte) and alignment constraint.
> > > > - a dynamic flag is a named bit in the rte_mbuf structure.
> > > >
> > > > The typical use case is a PMD that registers space for an offload
> > > > feature, when the application requests to enable this feature. As
> > > > the space in mbuf is limited, the space should only be reserved if it
> > > > is going to be used (i.e when the application explicitly asks for it).
> > > >
> > > > The registration can be done at any moment, but it is not possible
> > > > to unregister fields or flags for now.
> > > >
> > > > Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
> >
> > (...)
> >
> > > > +/**
> > > > + * @file
> > > > + * RTE Mbuf dynamic fields and flags
> > > > + *
> > > > + * Many features require to store data inside the mbuf. As the room in
> > > > + * mbuf structure is limited, it is not possible to have a field for
> > > > + * each feature. Also, changing fields in the mbuf structure can break
> > > > + * the API or ABI.
> > > > + *
> > > > + * This module addresses this issue, by enabling the dynamic
> > > > + * registration of fields or flags:
> > > > + *
> > > > + * - a dynamic field is a named area in the rte_mbuf structure, with a
> > > > + * given size (>= 1 byte) and alignment constraint.
> > > > + * - a dynamic flag is a named bit in the rte_mbuf structure.
> > > > + *
> > > > + * The typical use case is a PMD that registers space for an offload
> > > > + * feature, when the application requests to enable this feature. As
> > > > + * the space in mbuf is limited, the space should only be reserved if it
> > > > + * is going to be used (i.e when the application explicitly asks for it).
> > > > + *
> > > > + * The registration can be done at any moment, but it is not possible
> > > > + * to unregister fields or flags for now.
> > > > + *
> > > > + * Example of use:
> > > > + *
> > > > + * - RTE_MBUF_DYN_<feature>_(ID|SIZE|ALIGN) are defined in this file
> > >
> > > Does it means that all PMDs define their own 'RTE_MBUF_DYN_<feature>_(ID|SIZE|ALIGN)'
> > > here ? In other words, each PMD can expose its private DYN_<feature> here for public
> > > using ?
> >
> > For generic fields, I think they should be declared in this file. For
> > instance, if we decide to replace the current m->timestamp field by a
> > dynamic field, we should add like this:
> >
> > #define RTE_MBUF_DYN_TIMESTAMP_ID "rte_timestamp"
> > #define RTE_MBUF_DYN_TIMESTAMP_SIZE sizeof(uint64_t)
> > #define RTE_MBUF_DYN_TIMESTAMP_ALIGN __alignof__(uint64_t)
> >
> > If the feature is PMD-specific, the defines could be exposed in a
> > PMD header.
> >
>
> Now, understand the comments a little : ... must not define identifers prefixed with "rte_",
> which are reserved for standard features. Seems have big plan ?
The dynamic field can also be used by an external application or by an
external library. For instance, a field to tag a packet, like skb->mark
in linux. In this case, id, size and alignment would be defined outside
dpdk subtree.
To avoid name conflicts, I think we should define a convention for
identifiers, so they are in different namespaces:
- "rte_*" for identifiers declared inside dpdk subtree
- any other name for identifiers declared in an external application or
library
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags
2019-07-11 8:20 0% ` Olivier Matz
@ 2019-07-11 8:34 0% ` Wang, Haiyue
0 siblings, 0 replies; 200+ results
From: Wang, Haiyue @ 2019-07-11 8:34 UTC (permalink / raw)
To: Olivier Matz; +Cc: dev
> -----Original Message-----
> From: Olivier Matz [mailto:olivier.matz@6wind.com]
> Sent: Thursday, July 11, 2019 16:21
> To: Wang, Haiyue <haiyue.wang@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags
>
> On Thu, Jul 11, 2019 at 08:04:00AM +0000, Wang, Haiyue wrote:
> > > -----Original Message-----
> > > From: Olivier Matz [mailto:olivier.matz@6wind.com]
> > > Sent: Thursday, July 11, 2019 15:26
> > > To: Wang, Haiyue <haiyue.wang@intel.com>
> > > Cc: dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags
> > >
> > > Hi,
> > >
> > > On Wed, Jul 10, 2019 at 05:14:33PM +0000, Wang, Haiyue wrote:
> > > > Hi,
> > > >
> > > > Sounds cool, just have some questions inline.
> > > >
> > > > > -----Original Message-----
> > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier Matz
> > > > > Sent: Wednesday, July 10, 2019 17:29
> > > > > To: dev@dpdk.org
> > > > > Subject: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags
> > > > >
> > > > > Many features require to store data inside the mbuf. As the room in mbuf
> > > > > structure is limited, it is not possible to have a field for each
> > > > > feature. Also, changing fields in the mbuf structure can break the API
> > > > > or ABI.
> > > > >
> > > > > This commit addresses these issues, by enabling the dynamic registration
> > > > > of fields or flags:
> > > > >
> > > > > - a dynamic field is a named area in the rte_mbuf structure, with a
> > > > > given size (>= 1 byte) and alignment constraint.
> > > > > - a dynamic flag is a named bit in the rte_mbuf structure.
> > > > >
> > > > > The typical use case is a PMD that registers space for an offload
> > > > > feature, when the application requests to enable this feature. As
> > > > > the space in mbuf is limited, the space should only be reserved if it
> > > > > is going to be used (i.e when the application explicitly asks for it).
> > > > >
> > > > > The registration can be done at any moment, but it is not possible
> > > > > to unregister fields or flags for now.
> > > > >
> > > > > Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
> > >
> > > (...)
> > >
> > > > > +/**
> > > > > + * @file
> > > > > + * RTE Mbuf dynamic fields and flags
> > > > > + *
> > > > > + * Many features require to store data inside the mbuf. As the room in
> > > > > + * mbuf structure is limited, it is not possible to have a field for
> > > > > + * each feature. Also, changing fields in the mbuf structure can break
> > > > > + * the API or ABI.
> > > > > + *
> > > > > + * This module addresses this issue, by enabling the dynamic
> > > > > + * registration of fields or flags:
> > > > > + *
> > > > > + * - a dynamic field is a named area in the rte_mbuf structure, with a
> > > > > + * given size (>= 1 byte) and alignment constraint.
> > > > > + * - a dynamic flag is a named bit in the rte_mbuf structure.
> > > > > + *
> > > > > + * The typical use case is a PMD that registers space for an offload
> > > > > + * feature, when the application requests to enable this feature. As
> > > > > + * the space in mbuf is limited, the space should only be reserved if it
> > > > > + * is going to be used (i.e when the application explicitly asks for it).
> > > > > + *
> > > > > + * The registration can be done at any moment, but it is not possible
> > > > > + * to unregister fields or flags for now.
> > > > > + *
> > > > > + * Example of use:
> > > > > + *
> > > > > + * - RTE_MBUF_DYN_<feature>_(ID|SIZE|ALIGN) are defined in this file
> > > >
> > > > Does it means that all PMDs define their own 'RTE_MBUF_DYN_<feature>_(ID|SIZE|ALIGN)'
> > > > here ? In other words, each PMD can expose its private DYN_<feature> here for public
> > > > using ?
> > >
> > > For generic fields, I think they should be declared in this file. For
> > > instance, if we decide to replace the current m->timestamp field by a
> > > dynamic field, we should add like this:
> > >
> > > #define RTE_MBUF_DYN_TIMESTAMP_ID "rte_timestamp"
> > > #define RTE_MBUF_DYN_TIMESTAMP_SIZE sizeof(uint64_t)
> > > #define RTE_MBUF_DYN_TIMESTAMP_ALIGN __alignof__(uint64_t)
> > >
> > > If the feature is PMD-specific, the defines could be exposed in a
> > > PMD header.
> > >
> >
> > Now, understand the comments a little : ... must not define identifers prefixed with "rte_",
> > which are reserved for standard features. Seems have big plan ?
>
> The dynamic field can also be used by an external application or by an
> external library. For instance, a field to tag a packet, like skb->mark
> in linux. In this case, id, size and alignment would be defined outside
> dpdk subtree.
>
> To avoid name conflicts, I think we should define a convention for
> identifiers, so they are in different namespaces:
>
> - "rte_*" for identifiers declared inside dpdk subtree
> - any other name for identifiers declared in an external application or
> library
Very clearer now, thanks, this convention can be in programming guide document. :)
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags
2019-07-10 9:29 4% [dpdk-dev] [RFC] mbuf: support dynamic fields and flags Olivier Matz
2019-07-10 17:14 0% ` Wang, Haiyue
2019-07-10 17:49 3% ` Stephen Hemminger
@ 2019-07-11 9:24 3% ` Thomas Monjalon
2019-07-12 14:54 0% ` Andrew Rybchenko
3 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-07-11 9:24 UTC (permalink / raw)
To: dev; +Cc: Olivier Matz
10/07/2019 11:29, Olivier Matz:
> Many features require to store data inside the mbuf. As the room in mbuf
> structure is limited, it is not possible to have a field for each
> feature. Also, changing fields in the mbuf structure can break the API
> or ABI.
>
> This commit addresses these issues, by enabling the dynamic registration
> of fields or flags:
>
> - a dynamic field is a named area in the rte_mbuf structure, with a
> given size (>= 1 byte) and alignment constraint.
> - a dynamic flag is a named bit in the rte_mbuf structure.
>
> The typical use case is a PMD that registers space for an offload
> feature, when the application requests to enable this feature. As
> the space in mbuf is limited, the space should only be reserved if it
> is going to be used (i.e when the application explicitly asks for it).
>
> The registration can be done at any moment, but it is not possible
> to unregister fields or flags for now.
>
> Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
I fully support this solution.
It will give a lot of space for new features and will solve
the ABI stability problem.
Next step, I would like to move some existing mbuf fields to this
dynamic model. It will increase the free space in mbuf to be used
by dynamic fields. By converting some fields which are currently
union'ed, we can also fix the issue of these features being exclusive.
Acked-by: Thomas Monjalon <thomas@monjalon.net>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v2 1/1] fbarray: get fbarrays from containerized secondary
2019-07-09 10:26 4% ` Burakov, Anatoly
@ 2019-07-11 9:37 0% ` Yasufumi Ogawa
2019-07-11 9:43 3% ` Burakov, Anatoly
0 siblings, 1 reply; 200+ results
From: Yasufumi Ogawa @ 2019-07-11 9:37 UTC (permalink / raw)
To: Burakov, Anatoly; +Cc: dev, stable
On 2019/07/09 19:26, Burakov, Anatoly wrote:
> On 09-Jul-19 11:24 AM, Burakov, Anatoly wrote:
>> On 09-Jul-19 11:22 AM, Yasufumi Ogawa wrote:
>>> Hi Anatoly,
>>>
>>> On 2019/07/05 17:53, Burakov, Anatoly wrote:
>>>> On 16-Apr-19 4:43 AM, ogawa.yasufumi@lab.ntt.co.jp wrote:
>>>>> From: Yasufumi Ogawa <ogawa.yasufumi@lab.ntt.co.jp>
>>>>>
>>>>> In secondary_msl_create_walk(), it creates a file for fbarrays with
>>>>> its
>>>>> PID for reserving unique name among secondary processes. However, it
>>>>> does not work if secondary is run as app container because each of
>>>>> containerized secondary has PID 1. To reserve unique name, use
>>>>> hostname
>>>>> instead of PID if the value is 1.
>>>>>
>>>>> Cc: stable@dpdk.org
>>>>>
>>>>> Signed-off-by: Yasufumi Ogawa <ogawa.yasufumi@lab.ntt.co.jp>
>>>>> ---
>>>>
>>>> I'm not too well versed in containers - is this hostname 1) always
>>>> set, and 2) always unique?
>>> For docker, 1) hostname is always set. 2) The hostname is decided as
>>> short form of container ID, so it might not be unique even though
>>> very low possibility.
>>>
>>> I found that we can get whole container ID in `/proc/self/cgroup` as
>>> discussed [1]. I think using hostname is reasonable way without
>>> running many secondary processes. However, it might be better to use
>>> 64 digits full container ID instead of 12 digits short ID if ensure
>>> uniqueness strongly. What do yo think?
>>>
>>> [1]
>>> https://forums.docker.com/t/get-a-containers-full-id-from-inside-of-itself/37237
>>>
>>
>> I think it's better to err on the side of caution and guarantee better
>> uniqueness. This code will get into an LTS and will be used for years
>> to come :)
>>
>
> ...however, i think a full 64-digit ID won't even fit into the fbarray
> filename, as i believe it's limited to something like 64 chars. Perhaps
> hostname would be enough after all... or we can increase fbarray name
> length - that would require ABI breakage but the ABI is already broken
> in this release, so it's OK i think.
OK.
>> Wouldn't an error in fscanf() leak the file handle? I think you need
to fclose() before checking the result.
> I would like to fix it.
I would like send v3 patch for fixing for fclose().
Thanks,
Yasufumi
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 1/1] fbarray: get fbarrays from containerized secondary
2019-07-11 9:37 0% ` Yasufumi Ogawa
@ 2019-07-11 9:43 3% ` Burakov, Anatoly
0 siblings, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-07-11 9:43 UTC (permalink / raw)
To: Yasufumi Ogawa; +Cc: dev, stable
On 11-Jul-19 10:37 AM, Yasufumi Ogawa wrote:
> On 2019/07/09 19:26, Burakov, Anatoly wrote:
>> On 09-Jul-19 11:24 AM, Burakov, Anatoly wrote:
>>> On 09-Jul-19 11:22 AM, Yasufumi Ogawa wrote:
>>>> Hi Anatoly,
>>>>
>>>> On 2019/07/05 17:53, Burakov, Anatoly wrote:
>>>>> On 16-Apr-19 4:43 AM, ogawa.yasufumi@lab.ntt.co.jp wrote:
>>>>>> From: Yasufumi Ogawa <ogawa.yasufumi@lab.ntt.co.jp>
>>>>>>
>>>>>> In secondary_msl_create_walk(), it creates a file for fbarrays
>>>>>> with its
>>>>>> PID for reserving unique name among secondary processes. However, it
>>>>>> does not work if secondary is run as app container because each of
>>>>>> containerized secondary has PID 1. To reserve unique name, use
>>>>>> hostname
>>>>>> instead of PID if the value is 1.
>>>>>>
>>>>>> Cc: stable@dpdk.org
>>>>>>
>>>>>> Signed-off-by: Yasufumi Ogawa <ogawa.yasufumi@lab.ntt.co.jp>
>>>>>> ---
>>>>>
>>>>> I'm not too well versed in containers - is this hostname 1) always
>>>>> set, and 2) always unique?
>>>> For docker, 1) hostname is always set. 2) The hostname is decided as
>>>> short form of container ID, so it might not be unique even though
>>>> very low possibility.
>>>>
>>>> I found that we can get whole container ID in `/proc/self/cgroup` as
>>>> discussed [1]. I think using hostname is reasonable way without
>>>> running many secondary processes. However, it might be better to use
>>>> 64 digits full container ID instead of 12 digits short ID if ensure
>>>> uniqueness strongly. What do yo think?
>>>>
>>>> [1]
>>>> https://forums.docker.com/t/get-a-containers-full-id-from-inside-of-itself/37237
>>>>
>>>
>>> I think it's better to err on the side of caution and guarantee
>>> better uniqueness. This code will get into an LTS and will be used
>>> for years to come :)
>>>
>>
>> ...however, i think a full 64-digit ID won't even fit into the fbarray
>> filename, as i believe it's limited to something like 64 chars.
>> Perhaps hostname would be enough after all... or we can increase
>> fbarray name length - that would require ABI breakage but the ABI is
>> already broken in this release, so it's OK i think.
> OK.
Just a note: you're targetting this fix towards stable too. For stable,
you cannot break ABI, so we would have to do with the shorter hostname.
It's only for 19.08 that you can change fbarray length and use the full
64-char container ID for uniqueness.
>
> >> Wouldn't an error in fscanf() leak the file handle? I think you need
> to fclose() before checking the result.
> > I would like to fix it.
> I would like send v3 patch for fixing for fclose().
Please do :)
>
> Thanks,
> Yasufumi
>
>
--
Thanks,
Anatoly
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v3] devtools: better freebsd support
2019-07-05 13:58 6% ` [dpdk-dev] [PATCH v2] " Olivier Matz
2019-07-09 11:05 0% ` Musatescu, Flavia
@ 2019-07-11 14:25 6% ` Olivier Matz
2019-07-29 8:31 0% ` David Marchand
1 sibling, 1 reply; 200+ results
From: Olivier Matz @ 2019-07-11 14:25 UTC (permalink / raw)
To: dev; +Cc: Thomas Monjalon, David Marchand, Bruce Richardson, Musatescu, Flavia
- As "readlink -e" and "readlink -m" do not exist on freebsd,
use "readlink -f", it should not have any impact in these cases.
- "sed -ri" is invalid on freebsd and should be replaced by
"sed -ri=''"
- Use gmake instead of make.
This fixes the following command:
SYSDIR=/usr/src/sys ./devtools/test-build.sh \
-j4 x86_64-native-freebsd-gcc
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
---
v3:
- fix examples installation path, pointed-out by Flavia
v2:
- remove sed_ri() function and use 'sed -ri=""' as suggested by Bruce
devtools/check-dup-includes.sh | 2 +-
devtools/checkpatches.sh | 8 ++--
devtools/get-maintainer.sh | 2 +-
devtools/load-devel-config | 4 +-
devtools/test-build.sh | 94 ++++++++++++++++++++++--------------------
devtools/validate-abi.sh | 2 +-
6 files changed, 58 insertions(+), 54 deletions(-)
diff --git a/devtools/check-dup-includes.sh b/devtools/check-dup-includes.sh
index e4c2748c6..591599949 100755
--- a/devtools/check-dup-includes.sh
+++ b/devtools/check-dup-includes.sh
@@ -5,7 +5,7 @@
# Check C files in git repository for duplicated includes.
# Usage: devtools/check-dup-includes.sh [directory]
-dir=${1:-$(dirname $(readlink -m $0))/..}
+dir=${1:-$(dirname $(readlink -f $0))/..}
cd $dir
# speed up by ignoring Unicode details
diff --git a/devtools/checkpatches.sh b/devtools/checkpatches.sh
index 560e6ce93..8e2beee16 100755
--- a/devtools/checkpatches.sh
+++ b/devtools/checkpatches.sh
@@ -7,9 +7,9 @@
# - DPDK_CHECKPATCH_CODESPELL
# - DPDK_CHECKPATCH_LINE_LENGTH
# - DPDK_CHECKPATCH_OPTIONS
-. $(dirname $(readlink -e $0))/load-devel-config
+. $(dirname $(readlink -f $0))/load-devel-config
-VALIDATE_NEW_API=$(dirname $(readlink -e $0))/check-symbol-change.sh
+VALIDATE_NEW_API=$(dirname $(readlink -f $0))/check-symbol-change.sh
# Enable codespell by default. This can be overwritten from a config file.
# Codespell can also be enabled by setting DPDK_CHECKPATCH_CODESPELL to a valid path
@@ -66,7 +66,7 @@ check_forbidden_additions() { # <patch>
-v EXPRESSIONS="rte_panic\\\( rte_exit\\\(" \
-v RET_ON_FAIL=1 \
-v MESSAGE='Using rte_panic/rte_exit' \
- -f $(dirname $(readlink -e $0))/check-forbidden-tokens.awk \
+ -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
"$1" || res=1
# svg figures must be included with wildcard extension
@@ -75,7 +75,7 @@ check_forbidden_additions() { # <patch>
-v EXPRESSIONS='::[[:space:]]*[^[:space:]]*\\.svg' \
-v RET_ON_FAIL=1 \
-v MESSAGE='Using explicit .svg extension instead of .*' \
- -f $(dirname $(readlink -e $0))/check-forbidden-tokens.awk \
+ -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
"$1" || res=1
return $res
diff --git a/devtools/get-maintainer.sh b/devtools/get-maintainer.sh
index b9160486a..85740f5af 100755
--- a/devtools/get-maintainer.sh
+++ b/devtools/get-maintainer.sh
@@ -5,7 +5,7 @@
# Load config options:
# - DPDK_GETMAINTAINER_PATH
-. $(dirname $(readlink -e $0))/load-devel-config
+. $(dirname $(readlink -f $0))/load-devel-config
options="--no-git-fallback"
options="$options --no-rolestats"
diff --git a/devtools/load-devel-config b/devtools/load-devel-config
index 4f43cb352..380c79db4 100644
--- a/devtools/load-devel-config
+++ b/devtools/load-devel-config
@@ -6,7 +6,7 @@ test ! -r /etc/dpdk/devel.config ||
test ! -r ~/.config/dpdk/devel.config ||
. ~/.config/dpdk/devel.config
# from local file
-test ! -r $(dirname $(readlink -m $0))/../.develconfig ||
- . $(dirname $(readlink -m $0))/../.develconfig
+test ! -r $(dirname $(readlink -f $0))/../.develconfig ||
+ . $(dirname $(readlink -f $0))/../.develconfig
# The config files must export variables in the shell style
diff --git a/devtools/test-build.sh b/devtools/test-build.sh
index 9b50bf73d..3c029ce31 100755
--- a/devtools/test-build.sh
+++ b/devtools/test-build.sh
@@ -28,7 +28,7 @@ default_path=$PATH
# - LIBSSO_SNOW3G_PATH
# - LIBSSO_KASUMI_PATH
# - LIBSSO_ZUC_PATH
-. $(dirname $(readlink -e $0))/load-devel-config
+. $(dirname $(readlink -f $0))/load-devel-config
print_usage () {
echo "usage: $(basename $0) [-h] [-jX] [-s] [config1 [config2] ...]]"
@@ -57,6 +57,10 @@ print_help () {
END_OF_HELP
}
+[ -z $MAKE ] && command -v gmake > /dev/null && MAKE=gmake
+[ -z $MAKE ] && command -v make > /dev/null && MAKE=make
+[ -z $MAKE ] && echo "Cannot find make or gmake" && exit 1
+
J=$DPDK_MAKE_JOBS
short=false
unset verbose
@@ -90,7 +94,7 @@ trap "signal=INT ; trap - INT ; kill -INT $$" INT
# notify result on exit
trap on_exit EXIT
-cd $(dirname $(readlink -m $0))/..
+cd $(dirname $(readlink -f $0))/..
reset_env ()
{
@@ -127,83 +131,83 @@ config () # <directory> <target> <options>
fi
if [ ! -e $1/.config ] || $reconfig ; then
echo "================== Configure $1"
- make T=$2 O=$1 config
+ ${MAKE} T=$2 O=$1 config
echo 'Customize configuration'
# Built-in options (lowercase)
! echo $3 | grep -q '+default' || \
- sed -ri 's,(RTE_MACHINE=")native,\1default,' $1/.config
+ sed -ri="" 's,(RTE_MACHINE=")native,\1default,' $1/.config
echo $3 | grep -q '+next' || \
- sed -ri 's,(NEXT_ABI=)y,\1n,' $1/.config
+ sed -ri="" 's,(NEXT_ABI=)y,\1n,' $1/.config
! echo $3 | grep -q '+shared' || \
- sed -ri 's,(SHARED_LIB=)n,\1y,' $1/.config
+ sed -ri="" 's,(SHARED_LIB=)n,\1y,' $1/.config
! echo $3 | grep -q '+debug' || ( \
- sed -ri 's,(RTE_LOG_DP_LEVEL=).*,\1RTE_LOG_DEBUG,' $1/.config
- sed -ri 's,(_DEBUG.*=)n,\1y,' $1/.config
- sed -ri 's,(_STAT.*=)n,\1y,' $1/.config
- sed -ri 's,(TEST_PMD_RECORD_.*=)n,\1y,' $1/.config )
+ sed -ri="" 's,(RTE_LOG_DP_LEVEL=).*,\1RTE_LOG_DEBUG,' $1/.config
+ sed -ri="" 's,(_DEBUG.*=)n,\1y,' $1/.config
+ sed -ri="" 's,(_STAT.*=)n,\1y,' $1/.config
+ sed -ri="" 's,(TEST_PMD_RECORD_.*=)n,\1y,' $1/.config )
# Automatic configuration
test "$DPDK_DEP_NUMA" != n || \
- sed -ri 's,(NUMA.*=)y,\1n,' $1/.config
- sed -ri 's,(LIBRTE_IEEE1588=)n,\1y,' $1/.config
- sed -ri 's,(BYPASS=)n,\1y,' $1/.config
+ sed -ri="" 's,(NUMA.*=)y,\1n,' $1/.config
+ sed -ri="" 's,(LIBRTE_IEEE1588=)n,\1y,' $1/.config
+ sed -ri="" 's,(BYPASS=)n,\1y,' $1/.config
test "$DPDK_DEP_ARCHIVE" != y || \
- sed -ri 's,(RESOURCE_TAR=)n,\1y,' $1/.config
+ sed -ri="" 's,(RESOURCE_TAR=)n,\1y,' $1/.config
test "$DPDK_DEP_ISAL" != y || \
- sed -ri 's,(PMD_ISAL=)n,\1y,' $1/.config
+ sed -ri="" 's,(PMD_ISAL=)n,\1y,' $1/.config
test "$DPDK_DEP_MLX" != y || \
- sed -ri 's,(MLX._PMD=)n,\1y,' $1/.config
+ sed -ri="" 's,(MLX._PMD=)n,\1y,' $1/.config
test "$DPDK_DEP_SZE" != y || \
- sed -ri 's,(PMD_SZEDATA2=)n,\1y,' $1/.config
+ sed -ri="" 's,(PMD_SZEDATA2=)n,\1y,' $1/.config
test "$DPDK_DEP_ZLIB" != y || \
- sed -ri 's,(BNX2X_PMD=)n,\1y,' $1/.config
+ sed -ri="" 's,(BNX2X_PMD=)n,\1y,' $1/.config
test "$DPDK_DEP_ZLIB" != y || \
- sed -ri 's,(PMD_ZLIB=)n,\1y,' $1/.config
+ sed -ri="" 's,(PMD_ZLIB=)n,\1y,' $1/.config
test "$DPDK_DEP_ZLIB" != y || \
- sed -ri 's,(COMPRESSDEV_TEST=)n,\1y,' $1/.config
+ sed -ri="" 's,(COMPRESSDEV_TEST=)n,\1y,' $1/.config
test "$DPDK_DEP_PCAP" != y || \
- sed -ri 's,(PCAP=)n,\1y,' $1/.config
+ sed -ri="" 's,(PCAP=)n,\1y,' $1/.config
test -z "$ARMV8_CRYPTO_LIB_PATH" || \
- sed -ri 's,(PMD_ARMV8_CRYPTO=)n,\1y,' $1/.config
+ sed -ri="" 's,(PMD_ARMV8_CRYPTO=)n,\1y,' $1/.config
test "$DPDK_DEP_IPSEC_MB" != y || \
- sed -ri 's,(PMD_AESNI_MB=)n,\1y,' $1/.config
+ sed -ri="" 's,(PMD_AESNI_MB=)n,\1y,' $1/.config
test "$DPDK_DEP_IPSEC_MB" != y || \
- sed -ri 's,(PMD_AESNI_GCM=)n,\1y,' $1/.config
+ sed -ri="" 's,(PMD_AESNI_GCM=)n,\1y,' $1/.config
test -z "$LIBSSO_SNOW3G_PATH" || \
- sed -ri 's,(PMD_SNOW3G=)n,\1y,' $1/.config
+ sed -ri="" 's,(PMD_SNOW3G=)n,\1y,' $1/.config
test -z "$LIBSSO_KASUMI_PATH" || \
- sed -ri 's,(PMD_KASUMI=)n,\1y,' $1/.config
+ sed -ri="" 's,(PMD_KASUMI=)n,\1y,' $1/.config
test -z "$LIBSSO_ZUC_PATH" || \
- sed -ri 's,(PMD_ZUC=)n,\1y,' $1/.config
+ sed -ri="" 's,(PMD_ZUC=)n,\1y,' $1/.config
test "$DPDK_DEP_SSL" != y || \
- sed -ri 's,(PMD_CCP=)n,\1y,' $1/.config
+ sed -ri="" 's,(PMD_CCP=)n,\1y,' $1/.config
test "$DPDK_DEP_SSL" != y || \
- sed -ri 's,(PMD_OPENSSL=)n,\1y,' $1/.config
+ sed -ri="" 's,(PMD_OPENSSL=)n,\1y,' $1/.config
test "$DPDK_DEP_SSL" != y || \
- sed -ri 's,(QAT_SYM=)n,\1y,' $1/.config
+ sed -ri="" 's,(QAT_SYM=)n,\1y,' $1/.config
test -z "$FLEXRAN_SDK" || \
- sed -ri 's,(BBDEV_TURBO_SW=)n,\1y,' $1/.config
- sed -ri 's,(SCHED_.*=)n,\1y,' $1/.config
+ sed -ri="" 's,(BBDEV_TURBO_SW=)n,\1y,' $1/.config
+ sed -ri="" 's,(SCHED_.*=)n,\1y,' $1/.config
test -z "$LIBMUSDK_PATH" || \
- sed -ri 's,(PMD_MVSAM_CRYPTO=)n,\1y,' $1/.config
+ sed -ri="" 's,(PMD_MVSAM_CRYPTO=)n,\1y,' $1/.config
test -z "$LIBMUSDK_PATH" || \
- sed -ri 's,(MVPP2_PMD=)n,\1y,' $1/.config
+ sed -ri="" 's,(MVPP2_PMD=)n,\1y,' $1/.config
test -z "$LIBMUSDK_PATH" || \
- sed -ri 's,(MVNETA_PMD=)n,\1y,' $1/.config
+ sed -ri="" 's,(MVNETA_PMD=)n,\1y,' $1/.config
test "$DPDK_DEP_ELF" != y || \
- sed -ri 's,(BPF_ELF=)n,\1y,' $1/.config
+ sed -ri="" 's,(BPF_ELF=)n,\1y,' $1/.config
test "$DPDK_DEP_JSON" != y || \
- sed -ri 's,(TELEMETRY=)n,\1y,' $1/.config
+ sed -ri="" 's,(TELEMETRY=)n,\1y,' $1/.config
build_config_hook $1 $2 $3
# Explicit enabler/disabler (uppercase)
for option in $(echo $3 | sed 's,[~+], &,g') ; do
pattern=$(echo $option | cut -c2-)
if echo $option | grep -q '^~' ; then
- sed -ri "s,($pattern=)y,\1n," $1/.config
+ sed -ri="" "s,($pattern=)y,\1n," $1/.config
elif echo $option | grep -q '^+' ; then
- sed -ri "s,($pattern=)n,\1y," $1/.config
+ sed -ri="" "s,($pattern=)n,\1y," $1/.config
fi
done
fi
@@ -220,22 +224,22 @@ for conf in $configs ; do
# reload config with DPDK_TARGET set
DPDK_TARGET=$target
reset_env
- . $(dirname $(readlink -e $0))/load-devel-config
+ . $(dirname $(readlink -f $0))/load-devel-config
options=$(echo $conf | sed 's,[^~+]*,,')
dir=$conf
config $dir $target $options
echo "================== Build $dir"
- make -j$J EXTRA_CFLAGS="$maxerr $DPDK_DEP_CFLAGS" \
+ ${MAKE} -j$J EXTRA_CFLAGS="$maxerr $DPDK_DEP_CFLAGS" \
EXTRA_LDFLAGS="$DPDK_DEP_LDFLAGS" $verbose O=$dir
! $short || break
echo "================== Build examples for $dir"
export RTE_SDK=$(pwd)
export RTE_TARGET=$dir
- make -j$J -sC examples \
+ ${MAKE} -j$J -sC examples \
EXTRA_LDFLAGS="$DPDK_DEP_LDFLAGS" $verbose \
- O=$(readlink -m $dir/examples)
+ O=$(readlink -f $dir)/examples
unset RTE_TARGET
echo "################## $dir done."
unset dir
@@ -244,9 +248,9 @@ done
if ! $short ; then
mkdir -p .check
echo "================== Build doxygen HTML API"
- make doc-api-html >/dev/null 2>.check/doc.txt
+ ${MAKE} doc-api-html >/dev/null 2>.check/doc.txt
echo "================== Build sphinx HTML guides"
- make doc-guides-html >/dev/null 2>>.check/doc.txt
+ ${MAKE} doc-guides-html >/dev/null 2>>.check/doc.txt
echo "================== Check docs"
diff -u /dev/null .check/doc.txt
fi
diff --git a/devtools/validate-abi.sh b/devtools/validate-abi.sh
index 138436d93..f64e19d38 100755
--- a/devtools/validate-abi.sh
+++ b/devtools/validate-abi.sh
@@ -181,7 +181,7 @@ case "${dst}" in
/*) ;;
*) dst=${PWD}/${dst} ;;
esac
-dpdkroot=$(readlink -e $(dirname $0)/..)
+dpdkroot=$(readlink -f $(dirname $0)/..)
if [ -e "${dst}" -a "$force" = 0 ]; then
echo "The ${dst} directory is not empty. Remove it, use another"
--
2.11.0
^ permalink raw reply [relevance 6%]
* Re: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags
2019-07-11 7:53 4% ` Olivier Matz
@ 2019-07-11 14:37 0% ` Wiles, Keith
2019-07-12 9:06 0% ` Olivier Matz
0 siblings, 1 reply; 200+ results
From: Wiles, Keith @ 2019-07-11 14:37 UTC (permalink / raw)
To: Olivier Matz; +Cc: dpdk dev community, Stephen Hemminger
> On Jul 11, 2019, at 2:53 AM, Olivier Matz <olivier.matz@6wind.com> wrote:
>
> Hi Keith,
>
> On Wed, Jul 10, 2019 at 06:12:16PM +0000, Wiles, Keith wrote:
>>
>>
>>> On Jul 10, 2019, at 12:49 PM, Stephen Hemminger <stephen@networkplumber.org> wrote:
>>>
>>> On Wed, 10 Jul 2019 11:29:07 +0200
>>> Olivier Matz <olivier.matz@6wind.com> wrote:
>>>
>>>> /**
>>>> * Indicate that the metadata field in the mbuf is in use.
>>>> @@ -738,6 +741,8 @@ struct rte_mbuf {
>>>> */
>>>> struct rte_mbuf_ext_shared_info *shinfo;
>>>>
>>>> + uint64_t dynfield1; /**< Reserved for dynamic fields. */
>>>> + uint64_t dynfield2; /**< Reserved for dynamic fields. */
>>>> } __rte_cache_aligned;
>>>
>>> Growing mbuf is a fundamental ABI break and this needs
>>> higher level approval. Why not one pointer?
>>>
>>> It looks like you are creating something like FreeBSD m_tag.
>>> Why not use that?
>>
>> Changing the mbuf structure causes a big problem for a number reasons as Stephen states.
>
> Can you elaborate?
>
> This is indeed an ABI break, but I think this is only due to the adding
> of rte_mbuf_dynfield_copy() in rte_pktmbuf_attach(). The size of the
> mbuf does not change and the fields are not initialized when creating a
> new mbuf. So I think there is no ABI change for code that is not using
> rte_pktmbuf_attach().
>
> I don't think it's a problem to have one ABI change, if it avoids many
> others in the future.
>
>> If we leave the mbuf stucture alone and add this feature to the
>> headroom space between the mbuf structure and the packet. When setting
>> up the mempool/mbuf pool we define a headroom to hold the extra data
>> when the mbuf pool is created or just use the current headroom
>> space. Using this method we can eliminate the mbuf structure change
>> and add the data to the packet buffer. We can do away with dynfield1
>> and 2 as we know where headroom space begins and ends. Just a thought.
>
> The size of the mbuf metadata (between the mbuf structure and the
> buffer) is configured per pool, so it can be different accross
> mbufs. So, the access to the dynamic field would be slower:
> *(mbuf + dynfield_offset + metadata_size(mbuf))
We can force that space to be a minimum size when the mempool is created in the case of a cloned mbuf. The cloned mbuf is a small use case, but am important one and increasing the size for those special mbufs by a cache line should not be a huge problem.
I think most allocations do not change the size from the default value of the headroom (128). The mbuf + buffer are normally rounded to 2K or a bit bigger, which gives a bit more space in those cases of a packet size of 1518-1522. Jumbo frames are the same. Using the headroom size for an application needs to be defined and setup for the max size anyway for the application needs, so normally all mbuf creates should contain the same size to account for mbuf moments within the system.
That is my $0.02.
>
> Also, the size of the data buffer can be 0: it happens for mbuf pools
> that are dedicated to mbuf clones (that reference data in another mbuf
> or in an external buffer). In this case, there is no room after metadata
> to store the dynamic fields.
>
> Thanks,
> Olivier
Regards,
Keith
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags
2019-07-11 14:37 0% ` Wiles, Keith
@ 2019-07-12 9:06 0% ` Olivier Matz
0 siblings, 0 replies; 200+ results
From: Olivier Matz @ 2019-07-12 9:06 UTC (permalink / raw)
To: Wiles, Keith; +Cc: dpdk dev community, Stephen Hemminger
Hi,
On Thu, Jul 11, 2019 at 02:37:23PM +0000, Wiles, Keith wrote:
>
>
> > On Jul 11, 2019, at 2:53 AM, Olivier Matz <olivier.matz@6wind.com> wrote:
> >
> > Hi Keith,
> >
> > On Wed, Jul 10, 2019 at 06:12:16PM +0000, Wiles, Keith wrote:
> >>
> >>
> >>> On Jul 10, 2019, at 12:49 PM, Stephen Hemminger <stephen@networkplumber.org> wrote:
> >>>
> >>> On Wed, 10 Jul 2019 11:29:07 +0200
> >>> Olivier Matz <olivier.matz@6wind.com> wrote:
> >>>
> >>>> /**
> >>>> * Indicate that the metadata field in the mbuf is in use.
> >>>> @@ -738,6 +741,8 @@ struct rte_mbuf {
> >>>> */
> >>>> struct rte_mbuf_ext_shared_info *shinfo;
> >>>>
> >>>> + uint64_t dynfield1; /**< Reserved for dynamic fields. */
> >>>> + uint64_t dynfield2; /**< Reserved for dynamic fields. */
> >>>> } __rte_cache_aligned;
> >>>
> >>> Growing mbuf is a fundamental ABI break and this needs
> >>> higher level approval. Why not one pointer?
> >>>
> >>> It looks like you are creating something like FreeBSD m_tag.
> >>> Why not use that?
> >>
> >> Changing the mbuf structure causes a big problem for a number reasons as Stephen states.
> >
> > Can you elaborate?
> >
> > This is indeed an ABI break, but I think this is only due to the adding
> > of rte_mbuf_dynfield_copy() in rte_pktmbuf_attach(). The size of the
> > mbuf does not change and the fields are not initialized when creating a
> > new mbuf. So I think there is no ABI change for code that is not using
> > rte_pktmbuf_attach().
> >
> > I don't think it's a problem to have one ABI change, if it avoids many
> > others in the future.
> >
> >> If we leave the mbuf stucture alone and add this feature to the
> >> headroom space between the mbuf structure and the packet. When setting
> >> up the mempool/mbuf pool we define a headroom to hold the extra data
> >> when the mbuf pool is created or just use the current headroom
> >> space. Using this method we can eliminate the mbuf structure change
> >> and add the data to the packet buffer. We can do away with dynfield1
> >> and 2 as we know where headroom space begins and ends. Just a thought.
> >
> > The size of the mbuf metadata (between the mbuf structure and the
> > buffer) is configured per pool, so it can be different accross
> > mbufs. So, the access to the dynamic field would be slower:
> > *(mbuf + dynfield_offset + metadata_size(mbuf))
>
> We can force that space to be a minimum size when the mempool is
> created in the case of a cloned mbuf. The cloned mbuf is a small use
> case, but am important one and increasing the size for those special
> mbufs by a cache line should not be a huge problem.
>
> I think most allocations do not change the size from the default value
> of the headroom (128). The mbuf + buffer are normally rounded to 2K or
> a bit bigger, which gives a bit more space in those cases of a packet
> size of 1518-1522. Jumbo frames are the same. Using the headroom size
> for an application needs to be defined and setup for the max size
> anyway for the application needs, so normally all mbuf creates should
> contain the same size to account for mbuf moments within the system.
If we want more room for dynamic fields, we can do something like
this. But I don't think this is something that will happen soon: we
already have 16 bytes available, and I'm sure we can get another 16
bytes very easily by just converting fields like timestamp or sequence
numbers.
To attach larger amount of data to mbufs, the metadata feature still
exists. We can imagine to extend the dynamic fields feature to be able
to use more space after the mbuf structure (in metadata?), but it is
more complex.
I don't think that using headroom or tailroom is a good idea. That's
true that mbufs are usually a bit more than 2K, and some space is lost
when mtu is 1500. But smaller mbufs are perfectly legal too, except that
some drivers do not support it. Anyway, headroom and tailroom must be
used for what they are designed: reserving room to prepend or append
data. If we want more space for dynamic fields, let's add a specific
location for it, when it will be needed.
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v8 0/2] new ring reset api and use it by hash
@ 2019-07-12 9:26 3% ` Gavin Hu
2019-07-12 15:54 3% ` [dpdk-dev] [PATCH v9 " Gavin Hu
2019-07-16 19:23 3% ` [dpdk-dev] [PATCH v10 " Gavin Hu
3 siblings, 0 replies; 200+ results
From: Gavin Hu @ 2019-07-12 9:26 UTC (permalink / raw)
To: dev
Cc: nd, thomas, jerinj, hemant.agrawal, nipun.gupta,
Honnappa.Nagarahalli, gavin.hu, i.maximets, olivier.matz
V2:
- fix the coding style issue(commit message line too long)
V3:
- allow experimental API for meson build
V4:
- include the ring perf test case enhancement patch in the series.
- replace ARRAY_SIZE with RTE_DIM.
- call memset to avoid clang compling complains.
V5:
- commit message tweaking for ring test case enhancement patch
- upper to lower for mails to make match/grep more easily
V6:
- make upper case for the user name to comply with the convention.
V7:
- leave the ring test case patch out as not closely linked to this series in logic
V8:
- change the static inline function into a standard function to keep an api/abi compat layer in the future
Gavin Hu (2):
ring: add reset API to flush the ring when not in use
hash: flush the rings instead of dequeuing one by one
lib/librte_hash/Makefile | 2 +-
lib/librte_hash/meson.build | 3 +++
lib/librte_hash/rte_cuckoo_hash.c | 11 ++++-------
lib/librte_ring/rte_ring.h | 21 +++++++++++++++++++++
4 files changed, 29 insertions(+), 8 deletions(-)
--
2.7.4
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v7 1/2] ring: add reset API to flush the ring when not in use
2019-07-04 14:42 0% ` Thomas Monjalon
@ 2019-07-12 9:32 0% ` Gavin Hu (Arm Technology China)
2019-07-12 9:53 0% ` Olivier Matz
0 siblings, 1 reply; 200+ results
From: Gavin Hu (Arm Technology China) @ 2019-07-12 9:32 UTC (permalink / raw)
To: thomas
Cc: dev, Olivier Matz, nd, jerinj, hemant.agrawal,
Nipun.gupta@nxp.com, Honnappa Nagarahalli, i.maximets, stable
Hi Olivier and Thomas,
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Thursday, July 4, 2019 10:42 PM
> To: Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>
> Cc: dev@dpdk.org; Olivier Matz <olivier.matz@6wind.com>; nd
> <nd@arm.com>; jerinj@marvell.com; hemant.agrawal@nxp.com;
> Nipun.gupta@nxp.com; Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com>; i.maximets@samsung.com;
> stable@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v7 1/2] ring: add reset API to flush the ring
> when not in use
>
> 29/03/2019 15:17, Olivier Matz:
> > Hi,
> >
> > On Fri, Mar 15, 2019 at 11:31:25AM +0800, Gavin Hu wrote:
> > > Currently, the flush is done by dequeuing the ring in a while loop. It is
> > > much simpler to flush the queue by resetting the head and tail indices.
> > >
> > > Fixes: af75078fece3 ("first public release")
> > > Cc: stable@dpdk.org
> > >
> > > Signed-off-by: Gavin Hu <gavin.hu@arm.com>
> > > Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
> > > Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > ---
> > > --- a/lib/librte_ring/rte_ring_version.map
> > > +++ b/lib/librte_ring/rte_ring_version.map
> > > @@ -17,3 +17,10 @@ DPDK_2.2 {
> > > rte_ring_free;
> > >
> > > } DPDK_2.0;
> > > +
> > > +EXPERIMENTAL {
> > > + global:
> > > +
> > > + rte_ring_reset;
> > > +
> > > +};
> >
> > To me, a static inline function does not need to be added in
> > rte_ring_version.map (or is it due to a check script checking the
> > __rte_experimental tag ?). I found at least one commit where it
> > is not the case:
> > c277b34c1b3b ("mbuf: add function returning buffer address")
> >
> > There are 2 options:
> > 1- remove the rte_ring_version.map part of the patch.
> > 2- change the static inline function into a standard function.
> >
> > I would prefer 2-, because it allows to keep an api/abi compat
> > layer in the future.
>
> There are no news about this patch.
> I classify it as changes requested.
>
Sorry for missed your comments for long time, I just submitted v8.
I took the first option as it is in the data path and to keep consistent to its neighboring functions.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 1/2] ring: add reset API to flush the ring when not in use
2019-07-12 9:32 0% ` Gavin Hu (Arm Technology China)
@ 2019-07-12 9:53 0% ` Olivier Matz
2019-07-12 11:06 0% ` Gavin Hu (Arm Technology China)
0 siblings, 1 reply; 200+ results
From: Olivier Matz @ 2019-07-12 9:53 UTC (permalink / raw)
To: Gavin Hu (Arm Technology China)
Cc: thomas, dev, nd, jerinj, hemant.agrawal, Nipun.gupta@nxp.com,
Honnappa Nagarahalli, i.maximets, stable
Hi Gavin,
On Fri, Jul 12, 2019 at 09:32:39AM +0000, Gavin Hu (Arm Technology China) wrote:
> Hi Olivier and Thomas,
>
> > -----Original Message-----
> > From: Thomas Monjalon <thomas@monjalon.net>
> > Sent: Thursday, July 4, 2019 10:42 PM
> > To: Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>
> > Cc: dev@dpdk.org; Olivier Matz <olivier.matz@6wind.com>; nd
> > <nd@arm.com>; jerinj@marvell.com; hemant.agrawal@nxp.com;
> > Nipun.gupta@nxp.com; Honnappa Nagarahalli
> > <Honnappa.Nagarahalli@arm.com>; i.maximets@samsung.com;
> > stable@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v7 1/2] ring: add reset API to flush the ring
> > when not in use
> >
> > 29/03/2019 15:17, Olivier Matz:
> > > Hi,
> > >
> > > On Fri, Mar 15, 2019 at 11:31:25AM +0800, Gavin Hu wrote:
> > > > Currently, the flush is done by dequeuing the ring in a while loop. It is
> > > > much simpler to flush the queue by resetting the head and tail indices.
> > > >
> > > > Fixes: af75078fece3 ("first public release")
> > > > Cc: stable@dpdk.org
> > > >
> > > > Signed-off-by: Gavin Hu <gavin.hu@arm.com>
> > > > Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
> > > > Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > > ---
> > > > --- a/lib/librte_ring/rte_ring_version.map
> > > > +++ b/lib/librte_ring/rte_ring_version.map
> > > > @@ -17,3 +17,10 @@ DPDK_2.2 {
> > > > rte_ring_free;
> > > >
> > > > } DPDK_2.0;
> > > > +
> > > > +EXPERIMENTAL {
> > > > + global:
> > > > +
> > > > + rte_ring_reset;
> > > > +
> > > > +};
> > >
> > > To me, a static inline function does not need to be added in
> > > rte_ring_version.map (or is it due to a check script checking the
> > > __rte_experimental tag ?). I found at least one commit where it
> > > is not the case:
> > > c277b34c1b3b ("mbuf: add function returning buffer address")
> > >
> > > There are 2 options:
> > > 1- remove the rte_ring_version.map part of the patch.
> > > 2- change the static inline function into a standard function.
> > >
> > > I would prefer 2-, because it allows to keep an api/abi compat
> > > layer in the future.
> >
> > There are no news about this patch.
> > I classify it as changes requested.
> >
> Sorry for missed your comments for long time, I just submitted v8.
> I took the first option as it is in the data path and to keep consistent to its neighboring functions.
Could you give a little more context about why you need to reset
the ring in the data path? I see that it is used in rte_hash_reset(),
but in my thinking, this was more used at init/exit.
Thanks,
Olivier
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 1/2] ring: add reset API to flush the ring when not in use
2019-07-12 9:53 0% ` Olivier Matz
@ 2019-07-12 11:06 0% ` Gavin Hu (Arm Technology China)
2019-07-12 11:48 3% ` Olivier Matz
0 siblings, 1 reply; 200+ results
From: Gavin Hu (Arm Technology China) @ 2019-07-12 11:06 UTC (permalink / raw)
To: Olivier Matz
Cc: thomas, dev, nd, jerinj, hemant.agrawal, Nipun.gupta@nxp.com,
Honnappa Nagarahalli, i.maximets, stable,
Ruifeng Wang (Arm Technology China)
Hi Olivier,
> -----Original Message-----
> From: Olivier Matz <olivier.matz@6wind.com>
> Sent: Friday, July 12, 2019 5:54 PM
> To: Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>
> Cc: thomas@monjalon.net; dev@dpdk.org; nd <nd@arm.com>;
> jerinj@marvell.com; hemant.agrawal@nxp.com; Nipun.gupta@nxp.com;
> Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>;
> i.maximets@samsung.com; stable@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v7 1/2] ring: add reset API to flush the ring
> when not in use
>
> Hi Gavin,
>
> On Fri, Jul 12, 2019 at 09:32:39AM +0000, Gavin Hu (Arm Technology China)
> wrote:
> > Hi Olivier and Thomas,
> >
> > > -----Original Message-----
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > > Sent: Thursday, July 4, 2019 10:42 PM
> > > To: Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>
> > > Cc: dev@dpdk.org; Olivier Matz <olivier.matz@6wind.com>; nd
> > > <nd@arm.com>; jerinj@marvell.com; hemant.agrawal@nxp.com;
> > > Nipun.gupta@nxp.com; Honnappa Nagarahalli
> > > <Honnappa.Nagarahalli@arm.com>; i.maximets@samsung.com;
> > > stable@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH v7 1/2] ring: add reset API to flush the ring
> > > when not in use
> > >
> > > 29/03/2019 15:17, Olivier Matz:
> > > > Hi,
> > > >
> > > > On Fri, Mar 15, 2019 at 11:31:25AM +0800, Gavin Hu wrote:
> > > > > Currently, the flush is done by dequeuing the ring in a while loop. It is
> > > > > much simpler to flush the queue by resetting the head and tail indices.
> > > > >
> > > > > Fixes: af75078fece3 ("first public release")
> > > > > Cc: stable@dpdk.org
> > > > >
> > > > > Signed-off-by: Gavin Hu <gavin.hu@arm.com>
> > > > > Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
> > > > > Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > > > ---
> > > > > --- a/lib/librte_ring/rte_ring_version.map
> > > > > +++ b/lib/librte_ring/rte_ring_version.map
> > > > > @@ -17,3 +17,10 @@ DPDK_2.2 {
> > > > > rte_ring_free;
> > > > >
> > > > > } DPDK_2.0;
> > > > > +
> > > > > +EXPERIMENTAL {
> > > > > + global:
> > > > > +
> > > > > + rte_ring_reset;
> > > > > +
> > > > > +};
> > > >
> > > > To me, a static inline function does not need to be added in
> > > > rte_ring_version.map (or is it due to a check script checking the
> > > > __rte_experimental tag ?). I found at least one commit where it
> > > > is not the case:
> > > > c277b34c1b3b ("mbuf: add function returning buffer address")
> > > >
> > > > There are 2 options:
> > > > 1- remove the rte_ring_version.map part of the patch.
> > > > 2- change the static inline function into a standard function.
> > > >
> > > > I would prefer 2-, because it allows to keep an api/abi compat
> > > > layer in the future.
> > >
> > > There are no news about this patch.
> > > I classify it as changes requested.
> > >
> > Sorry for missed your comments for long time, I just submitted v8.
> > I took the first option as it is in the data path and to keep consistent to its
> neighboring functions.
>
> Could you give a little more context about why you need to reset
> the ring in the data path? I see that it is used in rte_hash_reset(),
> but in my thinking, this was more used at init/exit.
Sorry，literally it is in the control path, but I was impressed it will impact the
Data path performance when discussing this patch with Honnappa.
>
> Thanks,
> Olivier
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 1/2] ring: add reset API to flush the ring when not in use
2019-07-12 11:06 0% ` Gavin Hu (Arm Technology China)
@ 2019-07-12 11:48 3% ` Olivier Matz
2019-07-12 15:07 0% ` Gavin Hu (Arm Technology China)
0 siblings, 1 reply; 200+ results
From: Olivier Matz @ 2019-07-12 11:48 UTC (permalink / raw)
To: Gavin Hu (Arm Technology China)
Cc: thomas, dev, nd, jerinj, hemant.agrawal, Nipun.gupta@nxp.com,
Honnappa Nagarahalli, i.maximets, stable,
Ruifeng Wang (Arm Technology China)
Hi Gavin,
On Fri, Jul 12, 2019 at 11:06:28AM +0000, Gavin Hu (Arm Technology China) wrote:
> Hi Olivier,
>
> > -----Original Message-----
> > From: Olivier Matz <olivier.matz@6wind.com>
> > Sent: Friday, July 12, 2019 5:54 PM
> > To: Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>
> > Cc: thomas@monjalon.net; dev@dpdk.org; nd <nd@arm.com>;
> > jerinj@marvell.com; hemant.agrawal@nxp.com; Nipun.gupta@nxp.com;
> > Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>;
> > i.maximets@samsung.com; stable@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v7 1/2] ring: add reset API to flush the ring
> > when not in use
> >
> > Hi Gavin,
> >
> > On Fri, Jul 12, 2019 at 09:32:39AM +0000, Gavin Hu (Arm Technology China)
> > wrote:
> > > Hi Olivier and Thomas,
> > >
> > > > -----Original Message-----
> > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > Sent: Thursday, July 4, 2019 10:42 PM
> > > > To: Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>
> > > > Cc: dev@dpdk.org; Olivier Matz <olivier.matz@6wind.com>; nd
> > > > <nd@arm.com>; jerinj@marvell.com; hemant.agrawal@nxp.com;
> > > > Nipun.gupta@nxp.com; Honnappa Nagarahalli
> > > > <Honnappa.Nagarahalli@arm.com>; i.maximets@samsung.com;
> > > > stable@dpdk.org
> > > > Subject: Re: [dpdk-dev] [PATCH v7 1/2] ring: add reset API to flush the ring
> > > > when not in use
> > > >
> > > > 29/03/2019 15:17, Olivier Matz:
> > > > > Hi,
> > > > >
> > > > > On Fri, Mar 15, 2019 at 11:31:25AM +0800, Gavin Hu wrote:
> > > > > > Currently, the flush is done by dequeuing the ring in a while loop. It is
> > > > > > much simpler to flush the queue by resetting the head and tail indices.
> > > > > >
> > > > > > Fixes: af75078fece3 ("first public release")
> > > > > > Cc: stable@dpdk.org
> > > > > >
> > > > > > Signed-off-by: Gavin Hu <gavin.hu@arm.com>
> > > > > > Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
> > > > > > Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > > > > ---
> > > > > > --- a/lib/librte_ring/rte_ring_version.map
> > > > > > +++ b/lib/librte_ring/rte_ring_version.map
> > > > > > @@ -17,3 +17,10 @@ DPDK_2.2 {
> > > > > > rte_ring_free;
> > > > > >
> > > > > > } DPDK_2.0;
> > > > > > +
> > > > > > +EXPERIMENTAL {
> > > > > > + global:
> > > > > > +
> > > > > > + rte_ring_reset;
> > > > > > +
> > > > > > +};
> > > > >
> > > > > To me, a static inline function does not need to be added in
> > > > > rte_ring_version.map (or is it due to a check script checking the
> > > > > __rte_experimental tag ?). I found at least one commit where it
> > > > > is not the case:
> > > > > c277b34c1b3b ("mbuf: add function returning buffer address")
> > > > >
> > > > > There are 2 options:
> > > > > 1- remove the rte_ring_version.map part of the patch.
> > > > > 2- change the static inline function into a standard function.
> > > > >
> > > > > I would prefer 2-, because it allows to keep an api/abi compat
> > > > > layer in the future.
> > > >
> > > > There are no news about this patch.
> > > > I classify it as changes requested.
> > > >
> > > Sorry for missed your comments for long time, I just submitted v8.
> > > I took the first option as it is in the data path and to keep consistent to its
> > neighboring functions.
> >
> > Could you give a little more context about why you need to reset
> > the ring in the data path? I see that it is used in rte_hash_reset(),
> > but in my thinking, this was more used at init/exit.
> Sorry，literally it is in the control path, but I was impressed it will impact the
> Data path performance when discussing this patch with Honnappa.
I'm asking this because given the recent discussions about ABI stability,
I'd like to avoid defining a new static inline if it is not required.
Thanks,
Olivier
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags
2019-07-10 9:29 4% [dpdk-dev] [RFC] mbuf: support dynamic fields and flags Olivier Matz
` (2 preceding siblings ...)
2019-07-11 9:24 3% ` Thomas Monjalon
@ 2019-07-12 14:54 0% ` Andrew Rybchenko
2019-07-16 9:49 0% ` Olivier Matz
3 siblings, 1 reply; 200+ results
From: Andrew Rybchenko @ 2019-07-12 14:54 UTC (permalink / raw)
To: Olivier Matz, dev
On 10.07.2019 12:29, Olivier Matz wrote:
> Many features require to store data inside the mbuf. As the room in mbuf
> structure is limited, it is not possible to have a field for each
> feature. Also, changing fields in the mbuf structure can break the API
> or ABI.
>
> This commit addresses these issues, by enabling the dynamic registration
> of fields or flags:
>
> - a dynamic field is a named area in the rte_mbuf structure, with a
> given size (>= 1 byte) and alignment constraint.
> - a dynamic flag is a named bit in the rte_mbuf structure.
>
> The typical use case is a PMD that registers space for an offload
> feature, when the application requests to enable this feature. As
> the space in mbuf is limited, the space should only be reserved if it
> is going to be used (i.e when the application explicitly asks for it).
>
> The registration can be done at any moment, but it is not possible
> to unregister fields or flags for now.
>
> Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
I like the idea.
I think it would be very useful to measure performance impact. Since it is
core structure which is heavily used on datapath, performance impact is
required to make decision to go or not to go. If acceptable, more fields
can be converted to dynamic: timestamp, user data, sequence number,
timesync data etc. Rules on which fields should be static and which
dynamic are required. Timestamp, for example, is located in the first
cache line. Do we need a way prioritize some dynamic fields to be located
(if possible) in the first cache line? Or is it better simply move some
static
to the first cache line instead?
I think rules should be better defined and imposed, if possible, when
dynamic fields may be registered. Which entities are allowed to register
dynamic fields? Do we need to keep track which entity has registered
which dynamic fields? What to expect if a dynamic field is registered
after port start (the field is registered, but most likely not filled in)?
What to expect on port restart?
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 1/2] ring: add reset API to flush the ring when not in use
2019-07-12 11:48 3% ` Olivier Matz
@ 2019-07-12 15:07 0% ` Gavin Hu (Arm Technology China)
2019-07-12 15:40 0% ` Honnappa Nagarahalli
0 siblings, 1 reply; 200+ results
From: Gavin Hu (Arm Technology China) @ 2019-07-12 15:07 UTC (permalink / raw)
To: Olivier Matz
Cc: thomas, dev, nd, jerinj, hemant.agrawal, Nipun.gupta@nxp.com,
Honnappa Nagarahalli, i.maximets, stable,
Ruifeng Wang (Arm Technology China)
Hi Olivier,
> -----Original Message-----
> From: Olivier Matz <olivier.matz@6wind.com>
> Sent: Friday, July 12, 2019 7:49 PM
> To: Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>
> Cc: thomas@monjalon.net; dev@dpdk.org; nd <nd@arm.com>;
> jerinj@marvell.com; hemant.agrawal@nxp.com; Nipun.gupta@nxp.com;
> Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>;
> i.maximets@samsung.com; stable@dpdk.org; Ruifeng Wang (Arm
> Technology China) <Ruifeng.Wang@arm.com>
> Subject: Re: [dpdk-dev] [PATCH v7 1/2] ring: add reset API to flush the ring
> when not in use
>
> Hi Gavin,
>
> On Fri, Jul 12, 2019 at 11:06:28AM +0000, Gavin Hu (Arm Technology China)
> wrote:
> > Hi Olivier,
> >
> > > -----Original Message-----
> > > From: Olivier Matz <olivier.matz@6wind.com>
> > > Sent: Friday, July 12, 2019 5:54 PM
> > > To: Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>
> > > Cc: thomas@monjalon.net; dev@dpdk.org; nd <nd@arm.com>;
> > > jerinj@marvell.com; hemant.agrawal@nxp.com; Nipun.gupta@nxp.com;
> > > Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>;
> > > i.maximets@samsung.com; stable@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH v7 1/2] ring: add reset API to flush the
> ring
> > > when not in use
> > >
> > > Hi Gavin,
> > >
> > > On Fri, Jul 12, 2019 at 09:32:39AM +0000, Gavin Hu (Arm Technology
> China)
> > > wrote:
> > > > Hi Olivier and Thomas,
> > > >
> > > > > -----Original Message-----
> > > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > Sent: Thursday, July 4, 2019 10:42 PM
> > > > > To: Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>
> > > > > Cc: dev@dpdk.org; Olivier Matz <olivier.matz@6wind.com>; nd
> > > > > <nd@arm.com>; jerinj@marvell.com; hemant.agrawal@nxp.com;
> > > > > Nipun.gupta@nxp.com; Honnappa Nagarahalli
> > > > > <Honnappa.Nagarahalli@arm.com>; i.maximets@samsung.com;
> > > > > stable@dpdk.org
> > > > > Subject: Re: [dpdk-dev] [PATCH v7 1/2] ring: add reset API to flush
> the ring
> > > > > when not in use
> > > > >
> > > > > 29/03/2019 15:17, Olivier Matz:
> > > > > > Hi,
> > > > > >
> > > > > > On Fri, Mar 15, 2019 at 11:31:25AM +0800, Gavin Hu wrote:
> > > > > > > Currently, the flush is done by dequeuing the ring in a while loop.
> It is
> > > > > > > much simpler to flush the queue by resetting the head and tail
> indices.
> > > > > > >
> > > > > > > Fixes: af75078fece3 ("first public release")
> > > > > > > Cc: stable@dpdk.org
> > > > > > >
> > > > > > > Signed-off-by: Gavin Hu <gavin.hu@arm.com>
> > > > > > > Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
> > > > > > > Reviewed-by: Honnappa Nagarahalli
> <honnappa.nagarahalli@arm.com>
> > > > > > > ---
> > > > > > > --- a/lib/librte_ring/rte_ring_version.map
> > > > > > > +++ b/lib/librte_ring/rte_ring_version.map
> > > > > > > @@ -17,3 +17,10 @@ DPDK_2.2 {
> > > > > > > rte_ring_free;
> > > > > > >
> > > > > > > } DPDK_2.0;
> > > > > > > +
> > > > > > > +EXPERIMENTAL {
> > > > > > > + global:
> > > > > > > +
> > > > > > > + rte_ring_reset;
> > > > > > > +
> > > > > > > +};
> > > > > >
> > > > > > To me, a static inline function does not need to be added in
> > > > > > rte_ring_version.map (or is it due to a check script checking the
> > > > > > __rte_experimental tag ?). I found at least one commit where it
> > > > > > is not the case:
> > > > > > c277b34c1b3b ("mbuf: add function returning buffer address")
> > > > > >
> > > > > > There are 2 options:
> > > > > > 1- remove the rte_ring_version.map part of the patch.
> > > > > > 2- change the static inline function into a standard function.
> > > > > >
> > > > > > I would prefer 2-, because it allows to keep an api/abi compat
> > > > > > layer in the future.
> > > > >
> > > > > There are no news about this patch.
> > > > > I classify it as changes requested.
> > > > >
> > > > Sorry for missed your comments for long time, I just submitted v8.
> > > > I took the first option as it is in the data path and to keep consistent to
> its
> > > neighboring functions.
> > >
> > > Could you give a little more context about why you need to reset
> > > the ring in the data path? I see that it is used in rte_hash_reset(),
> > > but in my thinking, this was more used at init/exit.
> > Sorry，literally it is in the control path, but I was impressed it will impact
> the
> > Data path performance when discussing this patch with Honnappa.
>
> I'm asking this because given the recent discussions about ABI stability,
> I'd like to avoid defining a new static inline if it is not required.
Ok, will take 2nd option in V9, and squash the two patches into one, otherwise it reports the following error:
"error: ‘rte_ring_reset’ defined but not used [-Werror=unused-function]"
Best regards,
Gavin
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v7 1/2] ring: add reset API to flush the ring when not in use
2019-07-12 15:07 0% ` Gavin Hu (Arm Technology China)
@ 2019-07-12 15:40 0% ` Honnappa Nagarahalli
2019-07-12 16:01 0% ` Gavin Hu (Arm Technology China)
0 siblings, 1 reply; 200+ results
From: Honnappa Nagarahalli @ 2019-07-12 15:40 UTC (permalink / raw)
To: Gavin Hu (Arm Technology China), Olivier Matz
Cc: thomas, dev, nd, jerinj, hemant.agrawal, Nipun.gupta@nxp.com,
i.maximets, stable, Ruifeng Wang (Arm Technology China),
nd
<snip>
> > > > > >
> > > > > > 29/03/2019 15:17, Olivier Matz:
> > > > > > > Hi,
> > > > > > >
> > > > > > > On Fri, Mar 15, 2019 at 11:31:25AM +0800, Gavin Hu wrote:
> > > > > > > > Currently, the flush is done by dequeuing the ring in a while loop.
> > It is
> > > > > > > > much simpler to flush the queue by resetting the head and
> > > > > > > > tail
> > indices.
> > > > > > > >
> > > > > > > > Fixes: af75078fece3 ("first public release")
> > > > > > > > Cc: stable@dpdk.org
> > > > > > > >
> > > > > > > > Signed-off-by: Gavin Hu <gavin.hu@arm.com>
> > > > > > > > Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
> > > > > > > > Reviewed-by: Honnappa Nagarahalli
> > <honnappa.nagarahalli@arm.com>
> > > > > > > > ---
> > > > > > > > --- a/lib/librte_ring/rte_ring_version.map
> > > > > > > > +++ b/lib/librte_ring/rte_ring_version.map
> > > > > > > > @@ -17,3 +17,10 @@ DPDK_2.2 {
> > > > > > > > rte_ring_free;
> > > > > > > >
> > > > > > > > } DPDK_2.0;
> > > > > > > > +
> > > > > > > > +EXPERIMENTAL {
> > > > > > > > + global:
> > > > > > > > +
> > > > > > > > + rte_ring_reset;
> > > > > > > > +
> > > > > > > > +};
> > > > > > >
> > > > > > > To me, a static inline function does not need to be added in
> > > > > > > rte_ring_version.map (or is it due to a check script
> > > > > > > checking the __rte_experimental tag ?). I found at least one
> > > > > > > commit where it is not the case:
> > > > > > > c277b34c1b3b ("mbuf: add function returning buffer address")
> > > > > > >
> > > > > > > There are 2 options:
> > > > > > > 1- remove the rte_ring_version.map part of the patch.
> > > > > > > 2- change the static inline function into a standard function.
> > > > > > >
> > > > > > > I would prefer 2-, because it allows to keep an api/abi
> > > > > > > compat layer in the future.
> > > > > >
> > > > > > There are no news about this patch.
> > > > > > I classify it as changes requested.
> > > > > >
> > > > > Sorry for missed your comments for long time, I just submitted v8.
> > > > > I took the first option as it is in the data path and to keep
> > > > > consistent to
> > its
> > > > neighboring functions.
> > > >
> > > > Could you give a little more context about why you need to reset
> > > > the ring in the data path? I see that it is used in
> > > > rte_hash_reset(), but in my thinking, this was more used at init/exit.
> > > Sorry，literally it is in the control path, but I was impressed it
> > > will impact
> > the
> > > Data path performance when discussing this patch with Honnappa.
> >
> > I'm asking this because given the recent discussions about ABI
> > stability, I'd like to avoid defining a new static inline if it is not required.
>
> Ok, will take 2nd option in V9, and squash the two patches into one, otherwise
> it reports the following error:
> "error: ‘rte_ring_reset’ defined but not used [-Werror=unused-function]"
Agree, it is a control path function, does not impact any data path performance. It should not be inline.
>
> Best regards,
> Gavin
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v9 0/2] new ring reset api and use it by hash
2019-07-12 9:26 3% ` [dpdk-dev] [PATCH v8 0/2] new ring reset api and use it by hash Gavin Hu
@ 2019-07-12 15:54 3% ` Gavin Hu
2019-07-16 19:23 3% ` [dpdk-dev] [PATCH v10 " Gavin Hu
3 siblings, 0 replies; 200+ results
From: Gavin Hu @ 2019-07-12 15:54 UTC (permalink / raw)
To: dev
Cc: nd, thomas, jerinj, hemant.agrawal, nipun.gupta,
Honnappa.Nagarahalli, gavin.hu, i.maximets, olivier.matz
V2:
- fix the coding style issue(commit message line too long)
V3:
- allow experimental API for meson build
V4:
- include the ring perf test case enhancement patch in the series.
- replace ARRAY_SIZE with RTE_DIM.
- call memset to avoid clang compling complains.
V5:
- commit message tweaking for ring test case enhancement patch
- upper to lower for mails to make match/grep more easily
V6:
- make upper case for the user name to comply with the convention.
V7:
- leave the ring test case patch out as not closely linked to this series in logic
V8:
- the static inline function is removed from the rte_ring_version.map
V9:
- change the static inline function into a standard function to keep an api/abi compat layer in the future
- add back the change to the rte_ring_version.map file
Gavin Hu (2):
ring: add reset API to flush the ring when not in use
hash: flush the rings instead of dequeuing one by one
lib/librte_hash/Makefile | 2 +-
lib/librte_hash/meson.build | 3 +++
lib/librte_hash/rte_cuckoo_hash.c | 11 ++++-------
lib/librte_ring/rte_ring.c | 7 +++++++
lib/librte_ring/rte_ring.h | 17 +++++++++++++++++
lib/librte_ring/rte_ring_version.map | 7 +++++++
6 files changed, 39 insertions(+), 8 deletions(-)
--
2.7.4
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH v7 1/2] ring: add reset API to flush the ring when not in use
2019-07-12 15:40 0% ` Honnappa Nagarahalli
@ 2019-07-12 16:01 0% ` Gavin Hu (Arm Technology China)
0 siblings, 0 replies; 200+ results
From: Gavin Hu (Arm Technology China) @ 2019-07-12 16:01 UTC (permalink / raw)
To: Honnappa Nagarahalli, Olivier Matz
Cc: thomas, dev, nd, jerinj, hemant.agrawal, Nipun.gupta@nxp.com,
i.maximets, stable, Ruifeng Wang (Arm Technology China),
nd
> -----Original Message-----
> From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> Sent: Friday, July 12, 2019 11:41 PM
> To: Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>; Olivier Matz
> <olivier.matz@6wind.com>
> Cc: thomas@monjalon.net; dev@dpdk.org; nd <nd@arm.com>;
> jerinj@marvell.com; hemant.agrawal@nxp.com; Nipun.gupta@nxp.com;
> i.maximets@samsung.com; stable@dpdk.org; Ruifeng Wang (Arm
> Technology China) <Ruifeng.Wang@arm.com>; nd <nd@arm.com>
> Subject: RE: [dpdk-dev] [PATCH v7 1/2] ring: add reset API to flush the ring
> when not in use
>
> <snip>
>
> > > > > > >
> > > > > > > 29/03/2019 15:17, Olivier Matz:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > On Fri, Mar 15, 2019 at 11:31:25AM +0800, Gavin Hu wrote:
> > > > > > > > > Currently, the flush is done by dequeuing the ring in a while
> loop.
> > > It is
> > > > > > > > > much simpler to flush the queue by resetting the head and
> > > > > > > > > tail
> > > indices.
> > > > > > > > >
> > > > > > > > > Fixes: af75078fece3 ("first public release")
> > > > > > > > > Cc: stable@dpdk.org
> > > > > > > > >
> > > > > > > > > Signed-off-by: Gavin Hu <gavin.hu@arm.com>
> > > > > > > > > Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
> > > > > > > > > Reviewed-by: Honnappa Nagarahalli
> > > <honnappa.nagarahalli@arm.com>
> > > > > > > > > ---
> > > > > > > > > --- a/lib/librte_ring/rte_ring_version.map
> > > > > > > > > +++ b/lib/librte_ring/rte_ring_version.map
> > > > > > > > > @@ -17,3 +17,10 @@ DPDK_2.2 {
> > > > > > > > > rte_ring_free;
> > > > > > > > >
> > > > > > > > > } DPDK_2.0;
> > > > > > > > > +
> > > > > > > > > +EXPERIMENTAL {
> > > > > > > > > + global:
> > > > > > > > > +
> > > > > > > > > + rte_ring_reset;
> > > > > > > > > +
> > > > > > > > > +};
> > > > > > > >
> > > > > > > > To me, a static inline function does not need to be added in
> > > > > > > > rte_ring_version.map (or is it due to a check script
> > > > > > > > checking the __rte_experimental tag ?). I found at least one
> > > > > > > > commit where it is not the case:
> > > > > > > > c277b34c1b3b ("mbuf: add function returning buffer address")
> > > > > > > >
> > > > > > > > There are 2 options:
> > > > > > > > 1- remove the rte_ring_version.map part of the patch.
> > > > > > > > 2- change the static inline function into a standard function.
> > > > > > > >
> > > > > > > > I would prefer 2-, because it allows to keep an api/abi
> > > > > > > > compat layer in the future.
> > > > > > >
> > > > > > > There are no news about this patch.
> > > > > > > I classify it as changes requested.
> > > > > > >
> > > > > > Sorry for missed your comments for long time, I just submitted v8.
> > > > > > I took the first option as it is in the data path and to keep
> > > > > > consistent to
> > > its
> > > > > neighboring functions.
> > > > >
> > > > > Could you give a little more context about why you need to reset
> > > > > the ring in the data path? I see that it is used in
> > > > > rte_hash_reset(), but in my thinking, this was more used at init/exit.
> > > > Sorry，literally it is in the control path, but I was impressed it
> > > > will impact
> > > the
> > > > Data path performance when discussing this patch with Honnappa.
> > >
> > > I'm asking this because given the recent discussions about ABI
> > > stability, I'd like to avoid defining a new static inline if it is not required.
> >
> > Ok, will take 2nd option in V9, and squash the two patches into one,
> otherwise
> > it reports the following error:
> > "error: ‘rte_ring_reset’ defined but not used [-Werror=unused-function]"
> Agree, it is a control path function, does not impact any data path
> performance. It should not be inline.
Thanks for your clarification, I submitted v9 for this.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] ethdev: extend flow metadata
2019-07-11 7:44 0% ` Adrien Mazarguil
@ 2019-07-14 11:46 0% ` Andrew Rybchenko
2019-07-29 15:06 0% ` Adrien Mazarguil
0 siblings, 1 reply; 200+ results
From: Andrew Rybchenko @ 2019-07-14 11:46 UTC (permalink / raw)
To: Adrien Mazarguil, Yongseok Koh
Cc: Thomas Monjalon, Olivier Matz, Bruce Richardson, Shahaf Shuler,
Ferruh Yigit, dev, Slava Ovsiienko
On 11.07.2019 10:44, Adrien Mazarguil wrote:
> On Wed, Jul 10, 2019 at 04:37:46PM +0000, Yongseok Koh wrote:
>>> On Jul 10, 2019, at 5:26 AM, Thomas Monjalon <thomas@monjalon.net> wrote:
>>>
>>> 10/07/2019 14:01, Bruce Richardson:
>>>> On Wed, Jul 10, 2019 at 12:07:43PM +0200, Olivier Matz wrote:
>>>>> On Wed, Jul 10, 2019 at 10:55:34AM +0100, Bruce Richardson wrote:
>>>>>> On Wed, Jul 10, 2019 at 11:31:56AM +0200, Olivier Matz wrote:
>>>>>>> On Thu, Jul 04, 2019 at 04:21:22PM -0700, Yongseok Koh wrote:
>>>>>>>> Currently, metadata can be set on egress path via mbuf tx_meatadata field
>>>>>>>> with PKT_TX_METADATA flag and RTE_FLOW_ITEM_TYPE_RX_META matches metadata.
>>>>>>>>
>>>>>>>> This patch extends the usability.
>>>>>>>>
>>>>>>>> 1) RTE_FLOW_ACTION_TYPE_SET_META
>>>>>>>>
>>>>>>>> When supporting multiple tables, Tx metadata can also be set by a rule and
>>>>>>>> matched by another rule. This new action allows metadata to be set as a
>>>>>>>> result of flow match.
>>>>>>>>
>>>>>>>> 2) Metadata on ingress
>>>>>>>>
>>>>>>>> There's also need to support metadata on packet Rx. Metadata can be set by
>>>>>>>> SET_META action and matched by META item like Tx. The final value set by
>>>>>>>> the action will be delivered to application via mbuf metadata field with
>>>>>>>> PKT_RX_METADATA ol_flag.
>>>>>>>>
>>>>>>>> For this purpose, mbuf->tx_metadata is moved as a separate new field and
>>>>>>>> renamed to 'metadata' to support both Rx and Tx metadata.
>>>>>>>>
>>>>>>>> For loopback/hairpin packet, metadata set on Rx/Tx may or may not be
>>>>>>>> propagated to the other path depending on HW capability.
>>>>>>>>
>>>>>>>> Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
>>>>>>>> --- a/lib/librte_mbuf/rte_mbuf.h
>>>>>>>> +++ b/lib/librte_mbuf/rte_mbuf.h
>>>>>>>> @@ -648,17 +653,6 @@ struct rte_mbuf {
>>>>>>>> /**< User defined tags. See rte_distributor_process() */
>>>>>>>> uint32_t usr;
>>>>>>>> } hash; /**< hash information */
>>>>>>>> - struct {
>>>>>>>> - /**
>>>>>>>> - * Application specific metadata value
>>>>>>>> - * for egress flow rule match.
>>>>>>>> - * Valid if PKT_TX_METADATA is set.
>>>>>>>> - * Located here to allow conjunct use
>>>>>>>> - * with hash.sched.hi.
>>>>>>>> - */
>>>>>>>> - uint32_t tx_metadata;
>>>>>>>> - uint32_t reserved;
>>>>>>>> - };
>>>>>>>> };
>>>>>>>>
>>>>>>>> /** Outer VLAN TCI (CPU order), valid if PKT_RX_QINQ is set. */
>>>>>>>> @@ -727,6 +721,11 @@ struct rte_mbuf {
>>>>>>>> */
>>>>>>>> struct rte_mbuf_ext_shared_info *shinfo;
>>>>>>>>
>>>>>>>> + /** Application specific metadata value for flow rule match.
>>>>>>>> + * Valid if PKT_RX_METADATA or PKT_TX_METADATA is set.
>>>>>>>> + */
>>>>>>>> + uint32_t metadata;
>>>>>>>> +
>>>>>>>> } __rte_cache_aligned;
>>>>>>> This will break the ABI, so we cannot put it in 19.08, and we need a
>>>>>>> deprecation notice.
>>>>>>>
>>>>>> Does it actually break the ABI? Adding a new field to the mbuf should only
>>>>>> break the ABI if it either causes new fields to move or changes the
>>>>>> structure size. Since this is at the end, it's not going to move any older
>>>>>> fields, and since everything is cache-aligned I don't think the structure
>>>>>> size changes either.
>>>>> I think it does break the ABI: in previous version, when the PKT_TX_METADATA
>>>>> flag is set, the associated value is put in m->tx_metadata (offset 44 on
>>>>> x86-64), and in the next version, it will be in m->metadata (offset 112). So,
>>>>> these 2 versions are not binary compatible.
>>>>>
>>>>> Anyway, at least it breaks the API.
>>>> Ok, I misunderstood. I thought it was the structure change itself you were
>>>> saying broke the ABI. Yes, putting the data in a different place is indeed
>>>> an ABI break.
>>> We could add the new field and keep the old one unused,
>>> so it does not break the ABI.
>> Still breaks ABI if PKT_TX_METADATA is set. :-) In order not to break it, I can
>> keep the current union'd field (tx_metadata) as is with PKT_TX_METADATA, add
>> the new one at the end and make it used with the new PKT_RX_METADATA.
>>
>>> However I suppose everybody will prefer a version using dynamic fields.
>>> Is someone against using dynamic field for such usage?
>> However, given that the amazing dynamic fields is coming soon (thanks for your
>> effort, Olivier and Thomas!), I'd be honored to be the first user of it.
>>
>> Olivier, I'll take a look at your RFC.
> Just got a crazy idea while reading this thread... How about repurposing
> that "reserved" field as "rx_metadata" in the meantime?
It overlaps with hash.fdir.hi which has RSS hash.
> I know reserved fields are cursed and no one's ever supposed to touch them
> but this risk is mitigated by having the end user explicitly request its
> use, so the patch author (and his relatives) should be safe from the
> resulting bad juju.
>
> Joke aside, while I like the idea of Tx/Rx META, I think the similarities
> with MARK (and TAG eventually) is a problem. I wasn't available and couldn't
> comment when META was originally added to the Tx path, but there's a lot of
> overlap between these items/actions, without anything explaining to the end
> user how and why they should pick one over the other, if they can be
> combined at all and what happens in that case.
>
> All this must be documented, then we should think about unifying their
> respective features and deprecate the less capable items/actions. In my
> opinion, users need exactly one method to mark/match some mark while
> processing Rx/Tx traffic and *optionally* have that mark read from/written
> to the mbuf, which may or may not be possible depending on HW features.
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags
2019-07-12 14:54 0% ` Andrew Rybchenko
@ 2019-07-16 9:49 0% ` Olivier Matz
2019-07-16 11:31 0% ` [dpdk-dev] ***Spam*** " Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Olivier Matz @ 2019-07-16 9:49 UTC (permalink / raw)
To: Andrew Rybchenko; +Cc: dev
On Fri, Jul 12, 2019 at 05:54:57PM +0300, Andrew Rybchenko wrote:
> On 10.07.2019 12:29, Olivier Matz wrote:
> > Many features require to store data inside the mbuf. As the room in mbuf
> > structure is limited, it is not possible to have a field for each
> > feature. Also, changing fields in the mbuf structure can break the API
> > or ABI.
> >
> > This commit addresses these issues, by enabling the dynamic registration
> > of fields or flags:
> >
> > - a dynamic field is a named area in the rte_mbuf structure, with a
> > given size (>= 1 byte) and alignment constraint.
> > - a dynamic flag is a named bit in the rte_mbuf structure.
> >
> > The typical use case is a PMD that registers space for an offload
> > feature, when the application requests to enable this feature. As
> > the space in mbuf is limited, the space should only be reserved if it
> > is going to be used (i.e when the application explicitly asks for it).
> >
> > The registration can be done at any moment, but it is not possible
> > to unregister fields or flags for now.
> >
> > Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
>
> I like the idea.
>
> I think it would be very useful to measure performance impact. Since it is
> core structure which is heavily used on datapath, performance impact is
> required to make decision to go or not to go. If acceptable, more fields
> can be converted to dynamic: timestamp, user data, sequence number,
> timesync data etc.
Agree. I'll try to do this in the coming days.
> Rules on which fields should be static and which
> dynamic are required. Timestamp, for example, is located in the first
> cache line. Do we need a way prioritize some dynamic fields to be located
> (if possible) in the first cache line? Or is it better simply move some
> static
> to the first cache line instead?
There is a "flags" argument, which is designed for this purpose. Today,
there is no room in the first cache line, but as soon as we remove
something from it, we can add a flag to ask to register a dynamic field
in the first cache line.
> I think rules should be better defined and imposed, if possible, when
> dynamic fields may be registered. Which entities are allowed to register
> dynamic fields?
I think there is no restriction. Library, PMD, App can register their
dynamic fields as soon as there is room for it.
> Do we need to keep track which entity has registered
> which dynamic fields?
Looks quite difficult to me. Most of the time, a dynamic field will be
registered at several places. Only the first registration is effective,
the other will just get the offset.
But at least we could add a log in the registration function.
> What to expect if a dynamic field is registered
> after port start (the field is registered, but most likely not filled in)?
> What to expect on port restart?
Registration of dynamic field can be done at any moment.
But to register a field that will be used by a PMD, we need to ask for
the feature at port configuration (usually through ethdev). Then the PMD
will register the dynamic field. If it fails, the configuration of the
port should fail.
The application that will access to the field will also register it. It
can be done before or after the PMD initialization.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] ***Spam*** Re: [RFC] mbuf: support dynamic fields and flags
2019-07-16 9:49 0% ` Olivier Matz
@ 2019-07-16 11:31 0% ` Andrew Rybchenko
0 siblings, 0 replies; 200+ results
From: Andrew Rybchenko @ 2019-07-16 11:31 UTC (permalink / raw)
To: Olivier Matz; +Cc: dev
On 7/16/19 12:49 PM, Olivier Matz wrote:
> On Fri, Jul 12, 2019 at 05:54:57PM +0300, Andrew Rybchenko wrote:
>> On 10.07.2019 12:29, Olivier Matz wrote:
>>> Many features require to store data inside the mbuf. As the room in mbuf
>>> structure is limited, it is not possible to have a field for each
>>> feature. Also, changing fields in the mbuf structure can break the API
>>> or ABI.
>>>
>>> This commit addresses these issues, by enabling the dynamic registration
>>> of fields or flags:
>>>
>>> - a dynamic field is a named area in the rte_mbuf structure, with a
>>> given size (>= 1 byte) and alignment constraint.
>>> - a dynamic flag is a named bit in the rte_mbuf structure.
>>>
>>> The typical use case is a PMD that registers space for an offload
>>> feature, when the application requests to enable this feature. As
>>> the space in mbuf is limited, the space should only be reserved if it
>>> is going to be used (i.e when the application explicitly asks for it).
>>>
>>> The registration can be done at any moment, but it is not possible
>>> to unregister fields or flags for now.
>>>
>>> Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
>> I like the idea.
>>
>> I think it would be very useful to measure performance impact. Since it is
>> core structure which is heavily used on datapath, performance impact is
>> required to make decision to go or not to go. If acceptable, more fields
>> can be converted to dynamic: timestamp, user data, sequence number,
>> timesync data etc.
> Agree. I'll try to do this in the coming days.
>
>> Rules on which fields should be static and which
>> dynamic are required. Timestamp, for example, is located in the first
>> cache line. Do we need a way prioritize some dynamic fields to be located
>> (if possible) in the first cache line? Or is it better simply move some
>> static
>> to the first cache line instead?
> There is a "flags" argument, which is designed for this purpose. Today,
> there is no room in the first cache line, but as soon as we remove
> something from it, we can add a flag to ask to register a dynamic field
> in the first cache line.
>
>> I think rules should be better defined and imposed, if possible, when
>> dynamic fields may be registered. Which entities are allowed to register
>> dynamic fields?
> I think there is no restriction. Library, PMD, App can register their
> dynamic fields as soon as there is room for it.
I see that API itself has no restrictions, but the goal is to have
something working and it is very easy to break things with
dynamic fields and flags. May be obvious requirements are
sufficient (e.g. should be registered before lookup to be found
by lookup), but it is getting more complicated when drivers,
core libraries and applications come into play with their life
cycles. But may be it is really out-of-scope of the API description.
Thanks.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags
@ 2019-07-16 14:43 3% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-07-16 14:43 UTC (permalink / raw)
To: Olivier Matz; +Cc: Jerin Jacob Kollanukkaran, dev
On Tue, 16 Jul 2019 11:39:50 +0200
Olivier Matz <olivier.matz@6wind.com> wrote:
> On Fri, Jul 12, 2019 at 12:23:19PM +0000, Jerin Jacob Kollanukkaran wrote:
> > > -----Original Message-----
> > > From: dev <dev-bounces@dpdk.org> On Behalf Of Olivier Matz
> > > Sent: Thursday, July 11, 2019 1:07 PM
> > > To: Stephen Hemminger <stephen@networkplumber.org>
> > > Cc: dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [RFC] mbuf: support dynamic fields and flags
> > >
> > > On Wed, Jul 10, 2019 at 10:49:17AM -0700, Stephen Hemminger wrote:
> > > > On Wed, 10 Jul 2019 11:29:07 +0200
> > > > Olivier Matz <olivier.matz@6wind.com> wrote:
> > > >
> > > > > /**
> > > > > * Indicate that the metadata field in the mbuf is in use.
> > > > > @@ -738,6 +741,8 @@ struct rte_mbuf {
> > > > > */
> > > > > struct rte_mbuf_ext_shared_info *shinfo;
> > > > >
> > > > > + uint64_t dynfield1; /**< Reserved for dynamic fields. */
> > > > > + uint64_t dynfield2; /**< Reserved for dynamic fields. */
> >
> > Since the mbuf size is fixed, What is the downside of union scheme[1] vs upside of proposed scheme
> >
> > [1] Example like:
> > RTE_STD_C11
> > union {
> > void *userdata; /**< Can be used for external metadata */
> > uint64_t udata64; /**< Allow 8-byte userdata on 32-bit */
> > };
>
> In the particular case of userdata, the union is not an issue, it
> just means that there are several ways to represent the same data.
> If needed, it is possible to register a union as a dynamic field.
>
> In other case, like m->hash, having a union makes it impossible to
> use several features of the union at the same time. This would be
> solved by dynamic fields.
>
> > # The fields like mbuf: hash.usr, used in variety of use case together
> > Like libraries like distributor() and Eventdev using it. If we switch
> > to dynamic mbuf scheme, We wil take those field using rte_mbuf_dynfield_register()
> > on library init?
>
> If we decide that these fields must be converted to a dynamic field,
> yes, each library/application will call rte_mbuf_dynfield_register().
>
> > # I see an upside of dynamic mbuf if we can add rte_mbuf_dynfield_unregister API.
> > But can we ever do that? Because it will be complex if we need introduce notification mechanism etc.
>
> An unregister mechanism seems hard to implement, or we can leave the
> hard part to the user: either ensure that no mbuf is in use anywhere, or
> that removing the dynamic field won't have any impact. But I'd prefer
> not introducing an unregistration function until we have a real use-case
> for it.
>
> > # In the real world use case, if with union scheme, fastpath API can simply deference
> > specific element (say mbuf->fieldx). With dynamic scheme, the offset need to store
> > in some other data structure and de reference in fastpath before assessing the interested field.
> > Right?
>
> Yes, with dynamic fields, the offset is stored in a variable. A global
> variable (static to the file or module using it) does the job. This may
> have a small performance impact.
>
Applications are already using userdata reusing that in a driver
would cause a worse disaster than breaking ABI.
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v10 0/2] new ring reset api and use it by hash
` (2 preceding siblings ...)
2019-07-12 15:54 3% ` [dpdk-dev] [PATCH v9 " Gavin Hu
@ 2019-07-16 19:23 3% ` Gavin Hu
3 siblings, 0 replies; 200+ results
From: Gavin Hu @ 2019-07-16 19:23 UTC (permalink / raw)
To: dev
Cc: nd, thomas, jerinj, hemant.agrawal, nipun.gupta,
Honnappa.Nagarahalli, gavin.hu, olivier.matz
V2:
- fix the coding style issue(commit message line too long)
V3:
- allow experimental API for meson build
V4:
- include the ring perf test case enhancement patch in the series.
- replace ARRAY_SIZE with RTE_DIM.
- call memset to avoid clang compling complains.
V5:
- commit message tweaking for ring test case enhancement patch
- upper to lower for mails to make match/grep more easily
V6:
- make upper case for the user name to comply with the convention.
V7:
- leave the ring test case patch out as not closely linked to this series in logic
V8:
- the static inline function is removed from the rte_ring_version.map
V9:
- change the static inline function into a standard function to keep an api/abi compat layer in the future
- add back the change to the rte_ring_version.map file
V10:
- remove the CC: lines as not in the data plane.
Gavin Hu (2):
ring: add reset API to flush the ring when not in use
hash: flush the rings instead of dequeuing one by one
lib/librte_hash/Makefile | 2 +-
lib/librte_hash/meson.build | 3 +++
lib/librte_hash/rte_cuckoo_hash.c | 11 ++++-------
lib/librte_ring/rte_ring.c | 7 +++++++
lib/librte_ring/rte_ring.h | 17 +++++++++++++++++
lib/librte_ring/rte_ring_version.map | 7 +++++++
6 files changed, 39 insertions(+), 8 deletions(-)
--
2.7.4
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH] mempool/octeontx2: use noinline to preserve ABI
@ 2019-07-17 18:40 7% pbhagavatula
2019-07-18 5:53 4% ` Jerin Jacob Kollanukkaran
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: pbhagavatula @ 2019-07-17 18:40 UTC (permalink / raw)
To: jerinj, Nithin Dabilpuram, Vamsi Attunuru; +Cc: dev, Pavan Nikhilesh
From: Pavan Nikhilesh <pbhagavatula@marvell.com>
Since direct register access is used in npa_lf_aura_op_alloc_bulk()
use __rte_noinline to preserve ABI.
Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
---
drivers/mempool/octeontx2/otx2_mempool_ops.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mempool/octeontx2/otx2_mempool_ops.c b/drivers/mempool/octeontx2/otx2_mempool_ops.c
index a60a77a4e..ff63be567 100644
--- a/drivers/mempool/octeontx2/otx2_mempool_ops.c
+++ b/drivers/mempool/octeontx2/otx2_mempool_ops.c
@@ -54,7 +54,7 @@ npa_lf_aura_op_search_alloc(const int64_t wdata, int64_t * const addr,
return 0;
}
-static __rte_always_inline int
+static __rte_noinline int
npa_lf_aura_op_alloc_bulk(const int64_t wdata, int64_t * const addr,
unsigned int n, void **obj_table)
{
--
2.17.1
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [PATCH] mempool/octeontx2: use noinline to preserve ABI
2019-07-17 18:40 7% [dpdk-dev] [PATCH] mempool/octeontx2: use noinline to preserve ABI pbhagavatula
@ 2019-07-18 5:53 4% ` Jerin Jacob Kollanukkaran
2019-07-18 6:51 7% ` [dpdk-dev] [PATCH v2] mempool/octeontx2: fix possible ABI break with force inline pbhagavatula
2019-07-18 14:43 8% ` [dpdk-dev] [PATCH] mempool/octeontx2: use noinline to preserve ABI Stephen Hemminger
2 siblings, 0 replies; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-07-18 5:53 UTC (permalink / raw)
To: Pavan Nikhilesh Bhagavatula, Nithin Kumar Dabilpuram,
Vamsi Krishna Attunuru
Cc: dev, Pavan Nikhilesh Bhagavatula
> -----Original Message-----
> From: pbhagavatula@marvell.com <pbhagavatula@marvell.com>
> Sent: Thursday, July 18, 2019 12:10 AM
> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Nithin Kumar
> Dabilpuram <ndabilpuram@marvell.com>; Vamsi Krishna Attunuru
> <vattunuru@marvell.com>
> Cc: dev@dpdk.org; Pavan Nikhilesh Bhagavatula
> <pbhagavatula@marvell.com>
> Subject: [dpdk-dev][PATCH] mempool/octeontx2: use noinline to preserve
> ABI
>
> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
>
> Since direct register access is used in npa_lf_aura_op_alloc_bulk() use
> __rte_noinline to preserve ABI.
# Please add Fixes:
# Please mention the current visible issue
# If possible make git commit starts with fix ...
>
> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
> ---
> drivers/mempool/octeontx2/otx2_mempool_ops.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mempool/octeontx2/otx2_mempool_ops.c
> b/drivers/mempool/octeontx2/otx2_mempool_ops.c
> index a60a77a4e..ff63be567 100644
> --- a/drivers/mempool/octeontx2/otx2_mempool_ops.c
> +++ b/drivers/mempool/octeontx2/otx2_mempool_ops.c
> @@ -54,7 +54,7 @@ npa_lf_aura_op_search_alloc(const int64_t wdata,
> int64_t * const addr,
> return 0;
> }
>
> -static __rte_always_inline int
> +static __rte_noinline int
> npa_lf_aura_op_alloc_bulk(const int64_t wdata, int64_t * const addr,
> unsigned int n, void **obj_table)
> {
> --
> 2.17.1
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v2] mempool/octeontx2: fix possible ABI break with force inline
2019-07-17 18:40 7% [dpdk-dev] [PATCH] mempool/octeontx2: use noinline to preserve ABI pbhagavatula
2019-07-18 5:53 4% ` Jerin Jacob Kollanukkaran
@ 2019-07-18 6:51 7% ` pbhagavatula
2019-07-18 8:04 4% ` Jerin Jacob Kollanukkaran
2019-07-18 14:43 8% ` [dpdk-dev] [PATCH] mempool/octeontx2: use noinline to preserve ABI Stephen Hemminger
2 siblings, 1 reply; 200+ results
From: pbhagavatula @ 2019-07-18 6:51 UTC (permalink / raw)
To: jerinj, Nithin Dabilpuram, Vamsi Attunuru; +Cc: dev, Pavan Nikhilesh
From: Pavan Nikhilesh <pbhagavatula@marvell.com>
Since direct register access is used in npa_lf_aura_op_alloc_bulk()
use __rte_noinline instead of __rte_always_inline to preserve ABI.
Based on the compiler npa_lf_aura_op_alloc_bulk might be inlined
differently which may lead to undefined behaviour due to handcoded
asm.
Fixes: 29893042c29d ("mempool/octeontx2: fix clang build for arm64")
Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
---
drivers/mempool/octeontx2/otx2_mempool_ops.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mempool/octeontx2/otx2_mempool_ops.c b/drivers/mempool/octeontx2/otx2_mempool_ops.c
index a60a77a4e..ff63be567 100644
--- a/drivers/mempool/octeontx2/otx2_mempool_ops.c
+++ b/drivers/mempool/octeontx2/otx2_mempool_ops.c
@@ -54,7 +54,7 @@ npa_lf_aura_op_search_alloc(const int64_t wdata, int64_t * const addr,
return 0;
}
-static __rte_always_inline int
+static __rte_noinline int
npa_lf_aura_op_alloc_bulk(const int64_t wdata, int64_t * const addr,
unsigned int n, void **obj_table)
{
--
2.17.1
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [PATCH v2] mempool/octeontx2: fix possible ABI break with force inline
2019-07-18 6:51 7% ` [dpdk-dev] [PATCH v2] mempool/octeontx2: fix possible ABI break with force inline pbhagavatula
@ 2019-07-18 8:04 4% ` Jerin Jacob Kollanukkaran
2019-07-18 22:15 4% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-07-18 8:04 UTC (permalink / raw)
To: Pavan Nikhilesh Bhagavatula, Nithin Kumar Dabilpuram,
Vamsi Krishna Attunuru
Cc: dev, Pavan Nikhilesh Bhagavatula, thomas
> -----Original Message-----
> From: pbhagavatula@marvell.com <pbhagavatula@marvell.com>
> Sent: Thursday, July 18, 2019 12:21 PM
> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Nithin Kumar
> Dabilpuram <ndabilpuram@marvell.com>; Vamsi Krishna Attunuru
> <vattunuru@marvell.com>
> Cc: dev@dpdk.org; Pavan Nikhilesh Bhagavatula
> <pbhagavatula@marvell.com>
> Subject: [dpdk-dev][PATCH v2] mempool/octeontx2: fix possible ABI break
> with force inline
>
> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
>
> Since direct register access is used in npa_lf_aura_op_alloc_bulk() use
> __rte_noinline instead of __rte_always_inline to preserve ABI.
> Based on the compiler npa_lf_aura_op_alloc_bulk might be inlined
> differently which may lead to undefined behaviour due to handcoded asm.
>
> Fixes: 29893042c29d ("mempool/octeontx2: fix clang build for arm64")
> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [EXT] [PATCH v3 04/11] test: add cipher field to RSA test
@ 2019-07-18 12:44 3% ` Trahe, Fiona
0 siblings, 0 replies; 200+ results
From: Trahe, Fiona @ 2019-07-18 12:44 UTC (permalink / raw)
To: Shally Verma, Kusztal, ArkadiuszX, dev; +Cc: akhil.goyal, Trahe, Fiona
Hi Shally, Arek,
> > > >
> > > > > -----Original Message-----
> > > > > From: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > > > > Sent: Wednesday, July 17, 2019 12:23 AM
> > > > > To: dev@dpdk.org
> > > > > Cc: akhil.goyal@nxp.com; fiona.trahe@intel.com; Shally Verma
> > > > > <shallyv@marvell.com>; Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > > > > Subject: [EXT] [PATCH v3 04/11] test: add cipher field to RSA test
> > > > >
> > > > > External Email
> > > > >
> > > > > ------------------------------------------------------------------
> > > > > --
> > > > > -- This patch adds cipher field to RSA test cases
> > > > >
> > > > > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > > > > ---
> > > > > app/test/test_cryptodev_asym.c | 3 +++
> > > > > 1 file changed, 3 insertions(+)
> > > > >
> > > > > diff --git a/app/test/test_cryptodev_asym.c
> > > > > b/app/test/test_cryptodev_asym.c index 4dee164..8391545 100644
> > > > > --- a/app/test/test_cryptodev_asym.c
> > > > > +++ b/app/test/test_cryptodev_asym.c
> > > > > @@ -164,6 +164,7 @@ queue_ops_rsa_enc_dec(struct
> > > > > rte_cryptodev_asym_session *sess)
> > > > > uint8_t dev_id = ts_params->valid_devs[0];
> > > > > struct rte_crypto_op *op, *result_op;
> > > > > struct rte_crypto_asym_op *asym_op;
> > > > > + uint8_t cipher_buf[TEST_DATA_SIZE] = {0};
> > > > > int ret, status = TEST_SUCCESS;
> > > > >
> > > > > /* Set up crypto op data structure */ @@ -180,6 +181,8 @@
> > > > > queue_ops_rsa_enc_dec(struct rte_cryptodev_asym_session *sess)
> > > > > asym_op->rsa.op_type = RTE_CRYPTO_ASYM_OP_ENCRYPT;
> > > > >
> > > > > asym_op->rsa.message.data = rsaplaintext.data;
> > > > > + asym_op->rsa.cipher.data = cipher_buf;
> > > > > + asym_op->rsa.cipher.length = 0;
> > > > [Shally] I think this should be initialized to length of buffer
> > > > available i.e. RSA Key size? PMD can override it with length of
> > > > actual data written at output, which has to be less than , equal to
> > RSA_key size.
> > > [AK] - its because API comments are ambiguous in this case and we have
> > > only one field describing array length.
> > > I would suggest to rephrase cipher field API comments from "length in
> > bytes
> > > * of this field needs to be greater or equal to the length of
> > > * corresponding RSA key in bytes"
> > > To "underlying array should have allocated enough memory to hold
> > > cipher output (bigger or equal to RSA key size". Then length could and
> > > I think should be zero or unspecified at this point.
> > > What do you think?
> >
> > [AK2] Something like that:
> > * When RTE_CRYPTO_ASYM_OP_ENCRYPT op_type used underlying
> > array
> > * should have been allocated with enough memory to hold cipher
> > * output (bigger or equal to RSA key size).
> > The same for message field.
> [Shally] This description is okay. But still I would assume app to set length field of cipher buffer to actual
> allocated than 0. But I look forward to more feedback on this from others
[Fiona] I think the important thing is to be clear on when it's an input field and when an output and what the appl or PMD does in each case.
So my understanding is in ENCRYPT case it's an output field and DECRYPT it's an input.
SO how about - combining this with the changes already suggested to avoid repetition in patch 2:
Comment under rte_crypto_rsa_op_param.message:
Pointer to input data
* - to be encrypted for RSA public encrypt.
* - to be signed for RSA sign generation.
* - to be authenticated for RSA sign verification.
Pointer to output data
* - for RSA private decrypt.
In this case the underlying array should have been allocated with
enough memory to hold plaintext output (i.e. must be at least RSA key size).
The message.length field should be 0 and will be overwritten by the PMD
with the decrypted length.
All data is in Octet-string network byte order format.
Note 1: If API allows a length on decrypt, then what would the PMD use it for? Would it have to handle the case where it's less than key-size? In which case the appl is breaking the API and ignoring the previous comment. Or more than key-size - what does the PMD care - it just needs key-size. IF there was a case where PMD could produce more than keysize and would need to know if the buffer is big enough then we should allow this and say it's both an input (buffer-len) and an output (decrypted-message-len). But I don't think there's such a case.
Note 2 : it's good practice for apps to zero all fields in all API structs, except those explicitly set, to allow for future API extensions without ABI breakage.
Comment under rte_crypto_rsa_op_param.cipher:
Pointer to input data
* - to be decrypted for RSA private decrypt.
Pointer to output data
* - for RSA public encrypt.
In this case the underlying array should have been allocated with
enough memory to hold ciphertext output (i.e. must be at least RSA key size).
The message.length field should be 0 and will be overwritten by the PMD
with the encrypted length.
All data is in Octet-string network byte order format.
@Shally - does above make sense?
If so we can update patches 2, 3 and 4 based on above.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] mempool/octeontx2: use noinline to preserve ABI
2019-07-17 18:40 7% [dpdk-dev] [PATCH] mempool/octeontx2: use noinline to preserve ABI pbhagavatula
2019-07-18 5:53 4% ` Jerin Jacob Kollanukkaran
2019-07-18 6:51 7% ` [dpdk-dev] [PATCH v2] mempool/octeontx2: fix possible ABI break with force inline pbhagavatula
@ 2019-07-18 14:43 8% ` Stephen Hemminger
2019-07-18 14:49 7% ` [dpdk-dev] [EXT] " Pavan Nikhilesh Bhagavatula
2 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-07-18 14:43 UTC (permalink / raw)
To: pbhagavatula; +Cc: jerinj, Nithin Dabilpuram, Vamsi Attunuru, dev
On Thu, 18 Jul 2019 00:10:13 +0530
<pbhagavatula@marvell.com> wrote:
> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
>
> Since direct register access is used in npa_lf_aura_op_alloc_bulk()
> use __rte_noinline to preserve ABI.
>
> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
Huh? this is an internal function, and the driver is new to DPDK.
We don't maintain ABI with external drivers or code bases.
And ABI with code before it was upstream doesn't count either.
^ permalink raw reply [relevance 8%]
* Re: [dpdk-dev] [EXT] Re: [PATCH] mempool/octeontx2: use noinline to preserve ABI
2019-07-18 14:43 8% ` [dpdk-dev] [PATCH] mempool/octeontx2: use noinline to preserve ABI Stephen Hemminger
@ 2019-07-18 14:49 7% ` Pavan Nikhilesh Bhagavatula
0 siblings, 0 replies; 200+ results
From: Pavan Nikhilesh Bhagavatula @ 2019-07-18 14:49 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Jerin Jacob Kollanukkaran, Nithin Kumar Dabilpuram,
Vamsi Krishna Attunuru, dev
>-----Original Message-----
>From: Stephen Hemminger <stephen@networkplumber.org>
>Sent: Thursday, July 18, 2019 8:13 PM
>To: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>
>Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Nithin Kumar
>Dabilpuram <ndabilpuram@marvell.com>; Vamsi Krishna Attunuru
><vattunuru@marvell.com>; dev@dpdk.org
>Subject: [EXT] Re: [dpdk-dev] [PATCH] mempool/octeontx2: use
>noinline to preserve ABI
>
>External Email
>
>----------------------------------------------------------------------
>On Thu, 18 Jul 2019 00:10:13 +0530
><pbhagavatula@marvell.com> wrote:
>
>> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
>>
>> Since direct register access is used in npa_lf_aura_op_alloc_bulk()
>> use __rte_noinline to preserve ABI.
>>
>> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
>
>Huh? this is an internal function, and the driver is new to DPDK.
>We don't maintain ABI with external drivers or code bases.
>And ABI with code before it was upstream doesn't count either.
I was actually referring to arm64 ABI[1]
I think commit message in v2 describes it better http://patches.dpdk.org/patch/56703/
[1] http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf
Regards,
Pavan.
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [PATCH v2] mempool/octeontx2: fix possible ABI break with force inline
2019-07-18 8:04 4% ` Jerin Jacob Kollanukkaran
@ 2019-07-18 22:15 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-07-18 22:15 UTC (permalink / raw)
To: Pavan Nikhilesh Bhagavatula
Cc: dev, Jerin Jacob Kollanukkaran, Nithin Kumar Dabilpuram,
Vamsi Krishna Attunuru
> > From: Pavan Nikhilesh <pbhagavatula@marvell.com>
> >
> > Since direct register access is used in npa_lf_aura_op_alloc_bulk() use
> > __rte_noinline instead of __rte_always_inline to preserve ABI.
> > Based on the compiler npa_lf_aura_op_alloc_bulk might be inlined
> > differently which may lead to undefined behaviour due to handcoded asm.
> >
> > Fixes: 29893042c29d ("mempool/octeontx2: fix clang build for arm64")
> > Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
>
> Acked-by: Jerin Jacob <jerinj@marvell.com>
Applied, thanks
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [EXT] [PATCH v5 2/7] cryptodev: add cipher field to RSA op
@ 2019-07-19 5:10 3% ` Kusztal, ArkadiuszX
0 siblings, 0 replies; 200+ results
From: Kusztal, ArkadiuszX @ 2019-07-19 5:10 UTC (permalink / raw)
To: Shally Verma, dev
Cc: akhil.goyal, Trahe, Fiona, Nowak, DamianX, Sunila Sahu,
Ayuj Verma, Kanaka Durga Kotamarthy
> > ----------------------------------------------------------------------
> > Asymmetric nature of RSA algorithm suggest to use additional field for
> > output. In place operations still can be done by setting cipher and
> > message pointers with the same memory address.
> >
> > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > ---
> > lib/librte_cryptodev/rte_crypto_asym.h | 43
> > ++++++++++++++++++++++++++++------
> > 1 file changed, 36 insertions(+), 7 deletions(-)
> >
> > diff --git a/lib/librte_cryptodev/rte_crypto_asym.h
> > b/lib/librte_cryptodev/rte_crypto_asym.h
> > index 02ec304..1d4ec80 100644
> > --- a/lib/librte_cryptodev/rte_crypto_asym.h
> > +++ b/lib/librte_cryptodev/rte_crypto_asym.h
> > @@ -395,21 +395,50 @@ struct rte_crypto_rsa_op_param {
> >
> > rte_crypto_param message;
> > /**<
> > - * Pointer to data
> > + * Pointer to input data
> > * - to be encrypted for RSA public encrypt.
> > - * - to be decrypted for RSA private decrypt.
> > * - to be signed for RSA sign generation.
> > * - to be authenticated for RSA sign verification.
> > + *
> > + * Pointer to output data
> > + * - for RSA private decrypt.
> > + * In this case the underlying array should have been
> > + * allocated with enough memory to hold plaintext output
> > + * (i.e. must be at least RSA key size). The message.length
> > + * field should be 0 and will be overwritten by the PMD
> > + * with the decrypted length.
> > + *
> > + * All data is in Octet-string network byte order format.
> > + */
> As per Fiona feedback in another email, for PMD it does not matter what
> output buffer length is set to. All matters if it should be allocated large
> enough as per description in spec.
> Given that, there is no need to mention specifically, that length should be set
> to 0. App can leave it to anything as PMD don't care. It does not and should
> not check for any valid params here.
> Ditto is my feedback on cipher.length description below. There is no need to
> mention, it should be set to 0 specifically
>
> If we agree, this change can be taken as part of next patch set. Current one
> can still go on.
I agree with Shally that it could be anything to work, but on the other hand I agree with Pablo and Fiona comment on future extensions and ABI breakage. Especially on so early level of API development. When we change this field in future that it can be random (which is possible) it will not break anything, but it would not work in the opposite direction.
>
> Thanks
> Shally
>
>
>
> > +
> > + rte_crypto_param cipher;
> > + /**<
> > + * Pointer to input data
> > + * - to be decrypted for RSA private decrypt.
> > + *
> > + * Pointer to output data
> > + * - for RSA public encrypt.
> > + * In this case the underlying array should have been allocated
> > + * with enough memory to hold ciphertext output (i.e. must be
> > + * at least RSA key size). The cipher.length field should
> > + * be 0 and will be overwritten by the PMD with the encrypted
> > length.
> > + *
> > + * All data is in Octet-string network byte order format.
> > */
> >
> > rte_crypto_param sign;
> > /**<
> > - * Pointer to RSA signature data. If operation is RSA
> > - * sign @ref RTE_CRYPTO_ASYM_OP_SIGN, buffer will be
> > - * over-written with generated signature.
> > + * Pointer to input data
> > + * - to be verified for RSA public decrypt.
> > + *
> > + * Pointer to output data
> > + * - for RSA private encrypt.
> > + * In this case the underlying array should have been allocated
> > + * with enough memory to hold signature output (i.e. must be
> > + * at least RSA key size). The sign.length field should
> > + * be 0 and will be overwritten by the PMD with the signature length.
> > *
> > - * Length of the signature data will be equal to the
> > - * RSA modulus length.
> > + * All data is in Octet-string network byte order format.
> > */
> >
> > enum rte_crypto_rsa_padding_type pad;
> > --
> > 2.1.0
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [EXT] [PATCH v3 1/3] eal/arm64: add 128-bit atomic compare exchange
@ 2019-07-19 6:24 4% ` Jerin Jacob Kollanukkaran
2019-07-19 11:01 0% ` Phil Yang (Arm Technology China)
0 siblings, 1 reply; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-07-19 6:24 UTC (permalink / raw)
To: Phil Yang, dev
Cc: thomas, hemant.agrawal, Honnappa.Nagarahalli, gavin.hu, nd, gage.eads
> -----Original Message-----
> From: Phil Yang <phil.yang@arm.com>
> Sent: Friday, June 28, 2019 1:42 PM
> To: dev@dpdk.org
> Cc: thomas@monjalon.net; Jerin Jacob Kollanukkaran <jerinj@marvell.com>;
> hemant.agrawal@nxp.com; Honnappa.Nagarahalli@arm.com;
> gavin.hu@arm.com; nd@arm.com; gage.eads@intel.com
> Subject: [EXT] [PATCH v3 1/3] eal/arm64: add 128-bit atomic compare
> exchange
>
> External Email
>
> ----------------------------------------------------------------------
> Add 128-bit atomic compare exchange on aarch64.
>
> Signed-off-by: Phil Yang <phil.yang@arm.com>
> Tested-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> ---
> +#define RTE_HAS_ACQ(mo) ((mo) != __ATOMIC_RELAXED && (mo) !=
> +__ATOMIC_RELEASE) #define RTE_HAS_RLS(mo) ((mo) ==
> __ATOMIC_RELEASE || \
> + (mo) == __ATOMIC_ACQ_REL || \
> + (mo) == __ATOMIC_SEQ_CST)
> +
> +#define RTE_MO_LOAD(mo) (RTE_HAS_ACQ((mo)) \
> + ? __ATOMIC_ACQUIRE : __ATOMIC_RELAXED) #define
> RTE_MO_STORE(mo)
> +(RTE_HAS_RLS((mo)) \
> + ? __ATOMIC_RELEASE : __ATOMIC_RELAXED)
> +
The one starts with RTE_ are public symbols, If it is generic enough,
Move to common layer so that every architecturse can use.
If you think, otherwise make it internal
> +#ifdef __ARM_FEATURE_ATOMICS
This define is added in gcc 9.1 and I believe for clang it is not supported yet.
So old gcc and clang this will be undefined.
I think, With meson + native build, we can find the presence of
ATOMIC support by running a.out. Not sure about make and cross build case.
I don't want block this feature because of this, IMO, We can add this code
with existing __ARM_FEATURE_ATOMICS scheme and later find a method
to enhance it. But please check how to fix it.
> +#define __ATOMIC128_CAS_OP(cas_op_name, op_string) \
> +static inline rte_int128_t \
> +cas_op_name(rte_int128_t *dst, rte_int128_t old, \
> + rte_int128_t updated) \
> +{ \
> + /* caspX instructions register pair must start from even-numbered
> + * register at operand 1.
> + * So, specify registers for local variables here.
> + */ \
> + register uint64_t x0 __asm("x0") = (uint64_t)old.val[0]; \
Since direct x0 register used in the code and
cas_op_name() and rte_atomic128_cmp_exchange() is inline function,
Based on parent function load, we may corrupt x0 register aka
Break arm64 ABI. Not sure clobber list will help here or not?
Making it as no_inline will help but not sure about the performance impact.
May be you can check with compiler team.
We burned our hands with this scheme, see
5b40ec6b966260e0ff66a8a2c689664f75d6a0e6 ("mempool/octeontx2: fix possible arm64 ABI break")
Probably we can choose a scheme for rc2 and adjust as when we have complete clarity.
> + register uint64_t x1 __asm("x1") = (uint64_t)old.val[1]; \
> + register uint64_t x2 __asm("x2") = (uint64_t)updated.val[0]; \
> + register uint64_t x3 __asm("x3") = (uint64_t)updated.val[1]; \
> + asm volatile( \
> + op_string " %[old0], %[old1], %[upd0], %[upd1],
> [%[dst]]" \
> + : [old0] "+r" (x0), \
> + [old1] "+r" (x1) \
> + : [upd0] "r" (x2), \
> + [upd1] "r" (x3), \
> + [dst] "r" (dst) \
> + : "memory"); \
Should n't we add x0,x1, x2, x3 in clobber list?
> static inline int __rte_experimental
> rte_atomic128_cmp_exchange(rte_int128_t *dst,
> rte_int128_t *exp,
> diff --git a/lib/librte_eal/common/include/generic/rte_atomic.h
> b/lib/librte_eal/common/include/generic/rte_atomic.h
> index 9958543..2355e50 100644
> --- a/lib/librte_eal/common/include/generic/rte_atomic.h
> +++ b/lib/librte_eal/common/include/generic/rte_atomic.h
> @@ -1081,6 +1081,20 @@ static inline void
> rte_atomic64_clear(rte_atomic64_t *v)
>
> /*------------------------ 128 bit atomic operations -------------------------*/
>
> +#if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_ARM64)
There is nothing specific to x86 and arm64 here, Can we remove this #ifdef ?
> +/**
> + * 128-bit integer structure.
> + */
> +RTE_STD_C11
> +typedef struct {
> + RTE_STD_C11
> + union {
> + uint64_t val[2];
> + __extension__ __int128 int128;
> + };
> +} __rte_aligned(16) rte_int128_t;
> +#endif
> +
> #ifdef __DOXYGEN__
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [EXT] [PATCH v3 1/3] eal/arm64: add 128-bit atomic compare exchange
2019-07-19 6:24 4% ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
@ 2019-07-19 11:01 0% ` Phil Yang (Arm Technology China)
2019-07-19 12:35 0% ` Jerin Jacob Kollanukkaran
0 siblings, 1 reply; 200+ results
From: Phil Yang (Arm Technology China) @ 2019-07-19 11:01 UTC (permalink / raw)
To: jerinj, dev
Cc: thomas, hemant.agrawal, Honnappa Nagarahalli,
Gavin Hu (Arm Technology China),
nd, gage.eads, nd
> -----Original Message-----
> From: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> Sent: Friday, July 19, 2019 2:25 PM
> To: Phil Yang (Arm Technology China) <Phil.Yang@arm.com>; dev@dpdk.org
> Cc: thomas@monjalon.net; hemant.agrawal@nxp.com; Honnappa
> Nagarahalli <Honnappa.Nagarahalli@arm.com>; Gavin Hu (Arm Technology
> China) <Gavin.Hu@arm.com>; nd <nd@arm.com>; gage.eads@intel.com
> Subject: RE: [EXT] [PATCH v3 1/3] eal/arm64: add 128-bit atomic compare
> exchange
>
> > -----Original Message-----
> > From: Phil Yang <phil.yang@arm.com>
> > Sent: Friday, June 28, 2019 1:42 PM
> > To: dev@dpdk.org
> > Cc: thomas@monjalon.net; Jerin Jacob Kollanukkaran
> <jerinj@marvell.com>;
> > hemant.agrawal@nxp.com; Honnappa.Nagarahalli@arm.com;
> > gavin.hu@arm.com; nd@arm.com; gage.eads@intel.com
> > Subject: [EXT] [PATCH v3 1/3] eal/arm64: add 128-bit atomic compare
> > exchange
> >
> > External Email
> >
> > ----------------------------------------------------------------------
> > Add 128-bit atomic compare exchange on aarch64.
> >
> > Signed-off-by: Phil Yang <phil.yang@arm.com>
> > Tested-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > ---
> > +#define RTE_HAS_ACQ(mo) ((mo) != __ATOMIC_RELAXED && (mo) !=
> > +__ATOMIC_RELEASE) #define RTE_HAS_RLS(mo) ((mo) ==
> > __ATOMIC_RELEASE || \
> > + (mo) == __ATOMIC_ACQ_REL || \
> > + (mo) == __ATOMIC_SEQ_CST)
> > +
> > +#define RTE_MO_LOAD(mo) (RTE_HAS_ACQ((mo)) \
> > + ? __ATOMIC_ACQUIRE : __ATOMIC_RELAXED) #define
> > RTE_MO_STORE(mo)
> > +(RTE_HAS_RLS((mo)) \
> > + ? __ATOMIC_RELEASE : __ATOMIC_RELAXED)
> > +
>
> The one starts with RTE_ are public symbols, If it is generic enough,
> Move to common layer so that every architecturse can use.
> If you think, otherwise make it internal
Let's keep it internal. I will remove the 'RTE_' tag.
>
>
>
> > +#ifdef __ARM_FEATURE_ATOMICS
>
> This define is added in gcc 9.1 and I believe for clang it is not supported yet.
> So old gcc and clang this will be undefined.
> I think, With meson + native build, we can find the presence of
> ATOMIC support by running a.out. Not sure about make and cross build case.
> I don't want block this feature because of this, IMO, We can add this code
> with existing __ARM_FEATURE_ATOMICS scheme and later find a method
> to enhance it. But please check how to fix it.
OK.
>
> > +#define __ATOMIC128_CAS_OP(cas_op_name, op_string) \
> > +static inline rte_int128_t \
> > +cas_op_name(rte_int128_t *dst, rte_int128_t old, \
> > + rte_int128_t updated) \
> > +{ \
> > + /* caspX instructions register pair must start from even-numbered
> > + * register at operand 1.
> > + * So, specify registers for local variables here.
> > + */ \
> > + register uint64_t x0 __asm("x0") = (uint64_t)old.val[0]; \
>
> Since direct x0 register used in the code and
> cas_op_name() and rte_atomic128_cmp_exchange() is inline function,
> Based on parent function load, we may corrupt x0 register aka
Since x0/x1 and x2/x3 are used a lot and often contain live values.
Maybe to change them to some relatively less frequently used registers like x14/x15 and x16/x17 might help for this case?
According to the PCS (Procedure Call Standard), x14-x17 are also temporary registers.
> Break arm64 ABI. Not sure clobber list will help here or not?
In my understanding, for the register variable, if it contains a live value in the specified register, the compiler will move the live value into a free register.
Since x0~x3 are present in the input/output operands and x0/x1's value needs to be restored to the variable 'old' as a return value.
So I didn't add them into the clobber list.
> Making it as no_inline will help but not sure about the performance impact.
> May be you can check with compiler team.
>
> We burned our hands with this scheme, see
> 5b40ec6b966260e0ff66a8a2c689664f75d6a0e6 ("mempool/octeontx2: fix
> possible arm64 ABI break")
>
> Probably we can choose a scheme for rc2 and adjust as when we have
> complete clarity.
>
> > + register uint64_t x1 __asm("x1") = (uint64_t)old.val[1]; \
> > + register uint64_t x2 __asm("x2") = (uint64_t)updated.val[0]; \
> > + register uint64_t x3 __asm("x3") = (uint64_t)updated.val[1]; \
> > + asm volatile( \
> > + op_string " %[old0], %[old1], %[upd0], %[upd1],
> > [%[dst]]" \
> > + : [old0] "+r" (x0), \
> > + [old1] "+r" (x1) \
> > + : [upd0] "r" (x2), \
> > + [upd1] "r" (x3), \
> > + [dst] "r" (dst) \
> > + : "memory"); \
>
> Should n't we add x0,x1, x2, x3 in clobber list?
Same as above.
>
>
> > static inline int __rte_experimental
> > rte_atomic128_cmp_exchange(rte_int128_t *dst,
> > rte_int128_t *exp,
> > diff --git a/lib/librte_eal/common/include/generic/rte_atomic.h
> > b/lib/librte_eal/common/include/generic/rte_atomic.h
> > index 9958543..2355e50 100644
> > --- a/lib/librte_eal/common/include/generic/rte_atomic.h
> > +++ b/lib/librte_eal/common/include/generic/rte_atomic.h
> > @@ -1081,6 +1081,20 @@ static inline void
> > rte_atomic64_clear(rte_atomic64_t *v)
> >
> > /*------------------------ 128 bit atomic operations -------------------------*/
> >
> > +#if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_ARM64)
>
> There is nothing specific to x86 and arm64 here, Can we remove this #ifdef ?
Without this constraint, it will break 32-bit x86 builds.
http://mails.dpdk.org/archives/test-report/2019-June/086586.html
>
> > +/**
> > + * 128-bit integer structure.
> > + */
> > +RTE_STD_C11
> > +typedef struct {
> > + RTE_STD_C11
> > + union {
> > + uint64_t val[2];
> > + __extension__ __int128 int128;
> > + };
> > +} __rte_aligned(16) rte_int128_t;
> > +#endif
> > +
> > #ifdef __DOXYGEN__
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [EXT] [PATCH v3 1/3] eal/arm64: add 128-bit atomic compare exchange
2019-07-19 11:01 0% ` Phil Yang (Arm Technology China)
@ 2019-07-19 12:35 0% ` Jerin Jacob Kollanukkaran
2019-07-19 13:56 0% ` Phil Yang (Arm Technology China)
0 siblings, 1 reply; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-07-19 12:35 UTC (permalink / raw)
To: Phil Yang (Arm Technology China), dev
Cc: thomas, hemant.agrawal, Honnappa Nagarahalli,
Gavin Hu (Arm Technology China),
nd, gage.eads, nd
> > > +#define RTE_HAS_ACQ(mo) ((mo) != __ATOMIC_RELAXED && (mo) !=
> > > +__ATOMIC_RELEASE) #define RTE_HAS_RLS(mo) ((mo) ==
> > > __ATOMIC_RELEASE || \
> > > + (mo) == __ATOMIC_ACQ_REL || \
> > > + (mo) == __ATOMIC_SEQ_CST)
> > > +
> > > +#define RTE_MO_LOAD(mo) (RTE_HAS_ACQ((mo)) \
> > > + ? __ATOMIC_ACQUIRE : __ATOMIC_RELAXED) #define
> > > RTE_MO_STORE(mo)
> > > +(RTE_HAS_RLS((mo)) \
> > > + ? __ATOMIC_RELEASE : __ATOMIC_RELAXED)
> > > +
> >
> > The one starts with RTE_ are public symbols, If it is generic enough,
> > Move to common layer so that every architecturse can use.
> > If you think, otherwise make it internal
>
> Let's keep it internal. I will remove the 'RTE_' tag.
Probably change to __HAS_ACQ to avoid collision(just in case)
> >
> >
> >
> > > +#ifdef __ARM_FEATURE_ATOMICS
> >
> > This define is added in gcc 9.1 and I believe for clang it is not supported yet.
> > So old gcc and clang this will be undefined.
> > I think, With meson + native build, we can find the presence of
> > ATOMIC support by running a.out. Not sure about make and cross build case.
> > I don't want block this feature because of this, IMO, We can add this
> > code with existing __ARM_FEATURE_ATOMICS scheme and later find a
> > method to enhance it. But please check how to fix it.
>
> OK.
After thinking on this a bit, I think, in order to support old gcc(< gcc 9.1) and clang,
We can introduce a config option, where, by default it is disabled and enable
In specific config(where we know, lse is supported) and meson config.
i.e
#if defined(__ARM_FEATURE_ATOMICS) || defined(RTE_ARM_FEATURE_ATOMICS)
>
> >
> > > +#define __ATOMIC128_CAS_OP(cas_op_name, op_string) \
> > > +static inline rte_int128_t \
> > > +cas_op_name(rte_int128_t *dst, rte_int128_t old, \
> > > + rte_int128_t updated) \
> > > +{ \
> > > + /* caspX instructions register pair must start from even-numbered
> > > + * register at operand 1.
> > > + * So, specify registers for local variables here.
> > > + */ \
> > > + register uint64_t x0 __asm("x0") = (uint64_t)old.val[0]; \
> >
> > Since direct x0 register used in the code and
> > cas_op_name() and rte_atomic128_cmp_exchange() is inline function,
> > Based on parent function load, we may corrupt x0 register aka
>
> Since x0/x1 and x2/x3 are used a lot and often contain live values.
> Maybe to change them to some relatively less frequently used registers like
> x14/x15 and x16/x17 might help for this case?
> According to the PCS (Procedure Call Standard), x14-x17 are also temporary
> registers.
X14-x17 are temporary registers but since
cas_op_name() and rte_atomic128_cmp_exchange() are inline functions,
Based on the parent function register usage, it _may_ corrupt.
>
> > Break arm64 ABI. Not sure clobber list will help here or not?
>
> In my understanding, for the register variable, if it contains a live value in the
> specified register, the compiler will move the live value into a free register.
> Since x0~x3 are present in the input/output operands and x0/x1's value needs to
> be restored to the variable 'old' as a return value.
> So I didn't add them into the clobber list.
OK
>
> > Making it as no_inline will help but not sure about the performance impact.
> > May be you can check with compiler team.
> >
> > We burned our hands with this scheme, see
> > 5b40ec6b966260e0ff66a8a2c689664f75d6a0e6 ("mempool/octeontx2: fix
> > possible arm64 ABI break")
> >
> > Probably we can choose a scheme for rc2 and adjust as when we have
> > complete clarity.
> >
> > >
> > > +#if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_ARM64)
> >
> > There is nothing specific to x86 and arm64 here, Can we remove this #ifdef ?
>
> Without this constraint, it will break 32-bit x86 builds.
> http://mails.dpdk.org/archives/test-report/2019-June/086586.html
OK . #ifdef RTE_ARCH_64 would help then.
>
> >
> > > +/**
> > > + * 128-bit integer structure.
> > > + */
> > > +RTE_STD_C11
> > > +typedef struct {
> > > + RTE_STD_C11
> > > + union {
> > > + uint64_t val[2];
> > > + __extension__ __int128 int128;
Instead of guarding RTE_ARCH_64 on this complete structure,
How about it only under
#ifdef RTE_ARCH_64
__extension__ __int128 int128;
#endif
So that it rte_int128_t will be available for 32bit as well.
> > > + };
> > > +} __rte_aligned(16) rte_int128_t;
> > > +#endif
> > > +
> > > #ifdef __DOXYGEN__
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [EXT] [PATCH v3 1/3] eal/arm64: add 128-bit atomic compare exchange
2019-07-19 12:35 0% ` Jerin Jacob Kollanukkaran
@ 2019-07-19 13:56 0% ` Phil Yang (Arm Technology China)
0 siblings, 0 replies; 200+ results
From: Phil Yang (Arm Technology China) @ 2019-07-19 13:56 UTC (permalink / raw)
To: jerinj, gage.eads, dev
Cc: thomas, hemant.agrawal, Honnappa Nagarahalli,
Gavin Hu (Arm Technology China),
nd, nd
> -----Original Message-----
> From: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> Sent: Friday, July 19, 2019 8:35 PM
> To: Phil Yang (Arm Technology China) <Phil.Yang@arm.com>; dev@dpdk.org
> Cc: thomas@monjalon.net; hemant.agrawal@nxp.com; Honnappa
> Nagarahalli <Honnappa.Nagarahalli@arm.com>; Gavin Hu (Arm Technology
> China) <Gavin.Hu@arm.com>; nd <nd@arm.com>; gage.eads@intel.com; nd
> <nd@arm.com>
> Subject: RE: [EXT] [PATCH v3 1/3] eal/arm64: add 128-bit atomic compare
> exchange
>
> > > > +#define RTE_HAS_ACQ(mo) ((mo) != __ATOMIC_RELAXED && (mo) !=
> > > > +__ATOMIC_RELEASE) #define RTE_HAS_RLS(mo) ((mo) ==
> > > > __ATOMIC_RELEASE || \
> > > > + (mo) == __ATOMIC_ACQ_REL || \
> > > > + (mo) == __ATOMIC_SEQ_CST)
> > > > +
> > > > +#define RTE_MO_LOAD(mo) (RTE_HAS_ACQ((mo)) \
> > > > + ? __ATOMIC_ACQUIRE : __ATOMIC_RELAXED) #define
> > > > RTE_MO_STORE(mo)
> > > > +(RTE_HAS_RLS((mo)) \
> > > > + ? __ATOMIC_RELEASE : __ATOMIC_RELAXED)
> > > > +
> > >
> > > The one starts with RTE_ are public symbols, If it is generic enough,
> > > Move to common layer so that every architecturse can use.
> > > If you think, otherwise make it internal
> >
> > Let's keep it internal. I will remove the 'RTE_' tag.
>
> Probably change to __HAS_ACQ to avoid collision(just in case)
OK.
>
> > >
> > >
> > >
> > > > +#ifdef __ARM_FEATURE_ATOMICS
> > >
> > > This define is added in gcc 9.1 and I believe for clang it is not supported
> yet.
> > > So old gcc and clang this will be undefined.
> > > I think, With meson + native build, we can find the presence of
> > > ATOMIC support by running a.out. Not sure about make and cross build
> case.
> > > I don't want block this feature because of this, IMO, We can add this
> > > code with existing __ARM_FEATURE_ATOMICS scheme and later find a
> > > method to enhance it. But please check how to fix it.
> >
> > OK.
>
> After thinking on this a bit, I think, in order to support old gcc(< gcc 9.1) and
> clang,
> We can introduce a config option, where, by default it is disabled and enable
> In specific config(where we know, lse is supported) and meson config.
>
> i.e
> #if defined(__ARM_FEATURE_ATOMICS) ||
> defined(RTE_ARM_FEATURE_ATOMICS)
Cool
>
>
> >
> > >
> > > > +#define __ATOMIC128_CAS_OP(cas_op_name, op_string)
> \
> > > > +static inline rte_int128_t \
> > > > +cas_op_name(rte_int128_t *dst, rte_int128_t old, \
> > > > + rte_int128_t updated) \
> > > > +{ \
> > > > + /* caspX instructions register pair must start from even-numbered
> > > > + * register at operand 1.
> > > > + * So, specify registers for local variables here.
> > > > + */ \
> > > > + register uint64_t x0 __asm("x0") = (uint64_t)old.val[0]; \
> > >
> > > Since direct x0 register used in the code and
> > > cas_op_name() and rte_atomic128_cmp_exchange() is inline function,
> > > Based on parent function load, we may corrupt x0 register aka
> >
> > Since x0/x1 and x2/x3 are used a lot and often contain live values.
> > Maybe to change them to some relatively less frequently used registers
> like
> > x14/x15 and x16/x17 might help for this case?
> > According to the PCS (Procedure Call Standard), x14-x17 are also temporary
> > registers.
>
> X14-x17 are temporary registers but since
> cas_op_name() and rte_atomic128_cmp_exchange() are inline functions,
> Based on the parent function register usage, it _may_ corrupt.
Just checked how Linux Kernel does similar things:
https://github.com/torvalds/linux/blob/master/arch/arm64/include/asm/atomic_lse.h#L19
Same methods.
I will finish the benchmarking for the no_inline approach. If it has no significant performance loss, I think we can make it as no_inline.
>
>
> >
> > > Break arm64 ABI. Not sure clobber list will help here or not?
> >
> > In my understanding, for the register variable, if it contains a live value in
> the
> > specified register, the compiler will move the live value into a free register.
> > Since x0~x3 are present in the input/output operands and x0/x1's value
> needs to
> > be restored to the variable 'old' as a return value.
> > So I didn't add them into the clobber list.
>
> OK
>
> >
> > > Making it as no_inline will help but not sure about the performance
> impact.
> > > May be you can check with compiler team.
> > >
> > > We burned our hands with this scheme, see
> > > 5b40ec6b966260e0ff66a8a2c689664f75d6a0e6 ("mempool/octeontx2: fix
> > > possible arm64 ABI break")
> > >
> > > Probably we can choose a scheme for rc2 and adjust as when we have
> > > complete clarity.
> > >
> > > >
> > > > +#if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_ARM64)
> > >
> > > There is nothing specific to x86 and arm64 here, Can we remove this
> #ifdef ?
> >
> > Without this constraint, it will break 32-bit x86 builds.
> > http://mails.dpdk.org/archives/test-report/2019-June/086586.html
>
> OK . #ifdef RTE_ARCH_64 would help then.
OK.
>
> >
> > >
> > > > +/**
> > > > + * 128-bit integer structure.
> > > > + */
> > > > +RTE_STD_C11
> > > > +typedef struct {
> > > > + RTE_STD_C11
> > > > + union {
> > > > + uint64_t val[2];
> > > > + __extension__ __int128 int128;
>
> Instead of guarding RTE_ARCH_64 on this complete structure,
> How about it only under
> #ifdef RTE_ARCH_64
> __extension__ __int128 int128;
> #endif
> So that it rte_int128_t will be available for 32bit as well.
Agree, it should be work. But I am not sure.
Hi Gage,
How do you think about this?
>
>
> > > > + };
> > > > +} __rte_aligned(16) rte_int128_t;
> > > > +#endif
> > > > +
> > > > #ifdef __DOXYGEN__
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC] mark asym session-buffer non-reuseable
@ 2019-07-19 14:50 3% ` Ayuj Verma
2019-07-19 15:38 3% ` Trahe, Fiona
0 siblings, 1 reply; 200+ results
From: Ayuj Verma @ 2019-07-19 14:50 UTC (permalink / raw)
To: Kusztal, ArkadiuszX, akhil.goyal
Cc: Trahe, Fiona, Shally Verma, Sunila Sahu, Kanaka Durga Kotamarthy, dev
Hi Akhil, Arek, Fiona,
Since this require changes in other Asym PMD( qat) apart from openssl (we plan to send changes for this),
so should we need to send any announcement on ABI breakage here before proposing patch v1?
Thanks and regards
Ayuj Verma
________________________________
From: Ayuj Verma
Sent: 18 July 2019 15:17:54
To: Kusztal, ArkadiuszX; akhil.goyal@nxp.com
Cc: Trahe, Fiona; Shally Verma; Sunila Sahu; Kanaka Durga Kotamarthy; dev@dpdk.org
Subject: Re: [RFC] mark asym session-buffer non-reuseable
Hi Arek,
Please see inline.
Thanks and regards
Ayuj Verma
________________________________
From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>
Sent: 17 July 2019 19:40
To: Ayuj Verma; akhil.goyal@nxp.com
Cc: Trahe, Fiona; Shally Verma; Sunila Sahu; Kanaka Durga Kotamarthy; dev@dpdk.org
Subject: RE: [RFC] mark asym session-buffer non-reuseable
Hi Ayuj,
> -----Original Message-----
> From: Ayuj Verma [mailto:ayverma@marvell.com]
> Sent: Wednesday, July 17, 2019 2:34 PM
> To: akhil.goyal@nxp.com
> Cc: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; Trahe, Fiona
> <fiona.trahe@intel.com>; shallyv@marvell.com; ssahu@marvell.com;
> kkotamarthy@marvell.com; dev@dpdk.org; Ayuj Verma
> <ayverma@marvell.com>
> Subject: [RFC] mark asym session-buffer non-reuseable
>
> This RFC proposes changes in asymmetric session usability of transform
> structure. In current implementation asym xform is seen as temporary entity
> that can be re-used by application once sessions are initialized with it.
>
> This enforces PMD to copy all key buffers during session setup time. Since
> life-time of sessions are small, so we can hold these buffers with session,
[AK] - what is you expected session lifetime? (2,3,50 packets?)
[Ayuj] In practical scenario like SSL, handshake will happen in some 10-15 packets.
> reducing memcpy time by marking these as read-only so that PMDs which
> doesn’t require any manipulation of xform data can directly use these
> buffers in session configure.
>
> So, sending a proposal to mark xform as non-reusable till lifetime of session.
> This will help PMDs to reduce session setup time.
>
> Ayuj Verma (1):
> lib/crypto: mark asym session-buffer non-reuseable
>
> doc/guides/prog_guide/cryptodev_lib.rst | 6 ++++++
> lib/librte_cryptodev/rte_cryptodev_pmd.h | 2 +-
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> --
> 1.8.3.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC] mark asym session-buffer non-reuseable
2019-07-19 14:50 3% ` Ayuj Verma
@ 2019-07-19 15:38 3% ` Trahe, Fiona
0 siblings, 0 replies; 200+ results
From: Trahe, Fiona @ 2019-07-19 15:38 UTC (permalink / raw)
To: Ayuj Verma, Kusztal, ArkadiuszX, akhil.goyal
Cc: Shally Verma, Sunila Sahu, Kanaka Durga Kotamarthy, dev, Trahe, Fiona
No need as API is still experimental.
Howver I'd suggest changing the subject to
"declare crypto asym xform immutable"
non-reusable is confusing as the session and xform will be re-used on all the ops associated with the session.
From: Ayuj Verma [mailto:ayverma@marvell.com]
Sent: Friday, July 19, 2019 3:51 PM
To: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com>; akhil.goyal@nxp.com
Cc: Trahe, Fiona <fiona.trahe@intel.com>; Shally Verma <shallyv@marvell.com>; Sunila Sahu <ssahu@marvell.com>; Kanaka Durga Kotamarthy <kkotamarthy@marvell.com>; dev@dpdk.org
Subject: Re: [RFC] mark asym session-buffer non-reuseable
Hi Akhil, Arek, Fiona,
Since this require changes in other Asym PMD( qat) apart from openssl (we plan to send changes for this),
so should we need to send any announcement on ABI breakage here before proposing patch v1?
Thanks and regards
Ayuj Verma
________________________________
From: Ayuj Verma
Sent: 18 July 2019 15:17:54
To: Kusztal, ArkadiuszX; akhil.goyal@nxp.com<mailto:akhil.goyal@nxp.com>
Cc: Trahe, Fiona; Shally Verma; Sunila Sahu; Kanaka Durga Kotamarthy; dev@dpdk.org<mailto:dev@dpdk.org>
Subject: Re: [RFC] mark asym session-buffer non-reuseable
Hi Arek,
Please see inline.
Thanks and regards
Ayuj Verma
________________________________
From: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com<mailto:arkadiuszx.kusztal@intel.com>>
Sent: 17 July 2019 19:40
To: Ayuj Verma; akhil.goyal@nxp.com<mailto:akhil.goyal@nxp.com>
Cc: Trahe, Fiona; Shally Verma; Sunila Sahu; Kanaka Durga Kotamarthy; dev@dpdk.org<mailto:dev@dpdk.org>
Subject: RE: [RFC] mark asym session-buffer non-reuseable
Hi Ayuj,
> -----Original Message-----
> From: Ayuj Verma [mailto:ayverma@marvell.com]
> Sent: Wednesday, July 17, 2019 2:34 PM
> To: akhil.goyal@nxp.com<mailto:akhil.goyal@nxp.com>
> Cc: Kusztal, ArkadiuszX <arkadiuszx.kusztal@intel.com<mailto:arkadiuszx.kusztal@intel.com>>; Trahe, Fiona
> <fiona.trahe@intel.com<mailto:fiona.trahe@intel.com>>; shallyv@marvell.com<mailto:shallyv@marvell.com>; ssahu@marvell.com<mailto:ssahu@marvell.com>;
> kkotamarthy@marvell.com<mailto:kkotamarthy@marvell.com>; dev@dpdk.org<mailto:dev@dpdk.org>; Ayuj Verma
> <ayverma@marvell.com<mailto:ayverma@marvell.com>>
> Subject: [RFC] mark asym session-buffer non-reuseable
>
> This RFC proposes changes in asymmetric session usability of transform
> structure. In current implementation asym xform is seen as temporary entity
> that can be re-used by application once sessions are initialized with it.
>
> This enforces PMD to copy all key buffers during session setup time. Since
> life-time of sessions are small, so we can hold these buffers with session,
[AK] - what is you expected session lifetime? (2,3,50 packets?)
[Ayuj] In practical scenario like SSL, handshake will happen in some 10-15 packets.
> reducing memcpy time by marking these as read-only so that PMDs which
> doesn't require any manipulation of xform data can directly use these
> buffers in session configure.
>
> So, sending a proposal to mark xform as non-reusable till lifetime of session.
> This will help PMDs to reduce session setup time.
>
> Ayuj Verma (1):
> lib/crypto: mark asym session-buffer non-reuseable
>
> doc/guides/prog_guide/cryptodev_lib.rst | 6 ++++++
> lib/librte_cryptodev/rte_cryptodev_pmd.h | 2 +-
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> --
> 1.8.3.1
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v4 1/3] eal/arm64: add 128-bit atomic compare exchange
@ 2019-07-22 8:44 2% ` Phil Yang
2019-07-22 13:06 2% ` [dpdk-dev] [PATCH v5 " Phil Yang
` (2 subsequent siblings)
4 siblings, 0 replies; 200+ results
From: Phil Yang @ 2019-07-22 8:44 UTC (permalink / raw)
To: dev
Cc: thomas, jerinj, gage.eads, hemant.agrawal, Honnappa.Nagarahalli,
gavin.hu, nd
Add 128-bit atomic compare exchange on aarch64.
Suggested-by: Jerin Jacob <jerinj@marvell.com>
Signed-off-by: Phil Yang <phil.yang@arm.com>
Tested-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
---
V4:
1. Add RTE_ARM_FEATURE_ATOMICS flag to support LSE CASP instructions. (Jerin Jocob)
2. Fix possible arm64 ABI break by making casp_op_name noinline. (Jerin Jocob)
3. Add rte_stack_lf_stubs.h to reduce the ifdef clutter. (Gage Eads/Jerin Jocob)
v3:
1. Avoid duplication code with macro. (Jerin Jocob)
2. Make invalid memory order to strongest barrier. (Jerin Jocob)
3. Update doc/guides/prog_guide/env_abstraction_layer.rst. (Gage Eads)
4. Fix 32-bit x86 builds issue. (Gage Eads)
5. Correct documentation issues in UT. (Gage Eads)
v2:
Initial version.
config/arm/meson.build | 1 +
config/common_base | 5 +
config/defconfig_arm64-thunderx2-linuxapp-gcc | 1 +
.../common/include/arch/arm/rte_atomic_64.h | 162 +++++++++++++++++++++
.../common/include/arch/x86/rte_atomic_64.h | 12 --
lib/librte_eal/common/include/generic/rte_atomic.h | 17 ++-
6 files changed, 185 insertions(+), 13 deletions(-)
diff --git a/config/arm/meson.build b/config/arm/meson.build
index 979018e..a88f21e 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -68,6 +68,7 @@ flags_thunderx_extra = [
['RTE_USE_C11_MEM_MODEL', false]]
flags_thunderx2_extra = [
['RTE_MACHINE', '"thunderx2"'],
+ ['RTE_ARM_FEATURE_ATOMICS', true],
['RTE_CACHE_LINE_SIZE', 64],
['RTE_MAX_NUMA_NODES', 2],
['RTE_MAX_LCORE', 256],
diff --git a/config/common_base b/config/common_base
index 8ef75c2..8862495 100644
--- a/config/common_base
+++ b/config/common_base
@@ -1067,3 +1067,8 @@ CONFIG_RTE_APP_CRYPTO_PERF=y
# Compile the eventdev application
#
CONFIG_RTE_APP_EVENTDEV=y
+
+#
+# Compile ARM LSE ATOMIC instructions statically
+#
+CONFIG_RTE_ARM_FEATURE_ATOMICS=n
diff --git a/config/defconfig_arm64-thunderx2-linuxapp-gcc b/config/defconfig_arm64-thunderx2-linuxapp-gcc
index cc5c64b..17b6dec 100644
--- a/config/defconfig_arm64-thunderx2-linuxapp-gcc
+++ b/config/defconfig_arm64-thunderx2-linuxapp-gcc
@@ -6,6 +6,7 @@
CONFIG_RTE_MACHINE="thunderx2"
+CONFIG_RTE_ARM_FEATURE_ATOMICS=y
CONFIG_RTE_CACHE_LINE_SIZE=64
CONFIG_RTE_MAX_NUMA_NODES=2
CONFIG_RTE_MAX_LCORE=256
diff --git a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
index 97060e4..88b7ff4 100644
--- a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
+++ b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
@@ -1,5 +1,6 @@
/* SPDX-License-Identifier: BSD-3-Clause
* Copyright(c) 2015 Cavium, Inc
+ * Copyright(c) 2019 Arm Limited
*/
#ifndef _RTE_ATOMIC_ARM64_H_
@@ -14,6 +15,9 @@ extern "C" {
#endif
#include "generic/rte_atomic.h"
+#include <rte_branch_prediction.h>
+#include <rte_compat.h>
+#include <rte_debug.h>
#define dsb(opt) asm volatile("dsb " #opt : : : "memory")
#define dmb(opt) asm volatile("dmb " #opt : : : "memory")
@@ -40,6 +44,164 @@ extern "C" {
#define rte_cio_rmb() dmb(oshld)
+/*------------------------ 128 bit atomic operations -------------------------*/
+
+#define __HAS_ACQ(mo) ((mo) != __ATOMIC_RELAXED && (mo) != __ATOMIC_RELEASE)
+#define __HAS_RLS(mo) ((mo) == __ATOMIC_RELEASE || (mo) == __ATOMIC_ACQ_REL || \
+ (mo) == __ATOMIC_SEQ_CST)
+
+#define __MO_LOAD(mo) (__HAS_ACQ((mo)) ? __ATOMIC_ACQUIRE : __ATOMIC_RELAXED)
+#define __MO_STORE(mo) (__HAS_RLS((mo)) ? __ATOMIC_RELEASE : __ATOMIC_RELAXED)
+
+#if defined(__ARM_FEATURE_ATOMICS) || defined(RTE_ARM_FEATURE_ATOMICS)
+#define __ATOMIC128_CAS_OP(cas_op_name, op_string) \
+static __rte_noinline rte_int128_t \
+cas_op_name(rte_int128_t *dst, rte_int128_t old, \
+ rte_int128_t updated) \
+{ \
+ /* caspX instructions register pair must start from even-numbered
+ * register at operand 1.
+ * So, specify registers for local variables here.
+ */ \
+ register uint64_t x0 __asm("x0") = (uint64_t)old.val[0]; \
+ register uint64_t x1 __asm("x1") = (uint64_t)old.val[1]; \
+ register uint64_t x2 __asm("x2") = (uint64_t)updated.val[0]; \
+ register uint64_t x3 __asm("x3") = (uint64_t)updated.val[1]; \
+ asm volatile( \
+ op_string " %[old0], %[old1], %[upd0], %[upd1], [%[dst]]" \
+ : [old0] "+r" (x0), \
+ [old1] "+r" (x1) \
+ : [upd0] "r" (x2), \
+ [upd1] "r" (x3), \
+ [dst] "r" (dst) \
+ : "memory"); \
+ old.val[0] = x0; \
+ old.val[1] = x1; \
+ return old; \
+}
+
+__ATOMIC128_CAS_OP(__rte_cas_relaxed, "casp")
+__ATOMIC128_CAS_OP(__rte_cas_acquire, "caspa")
+__ATOMIC128_CAS_OP(__rte_cas_release, "caspl")
+__ATOMIC128_CAS_OP(__rte_cas_acq_rel, "caspal")
+#else
+#define __ATOMIC128_LDX_OP(ldx_op_name, op_string) \
+static inline rte_int128_t \
+ldx_op_name(const rte_int128_t *src) \
+{ \
+ rte_int128_t ret; \
+ asm volatile( \
+ op_string " %0, %1, %2" \
+ : "=&r" (ret.val[0]), \
+ "=&r" (ret.val[1]) \
+ : "Q" (src->val[0]) \
+ : "memory"); \
+ return ret; \
+}
+
+__ATOMIC128_LDX_OP(__rte_ldx_relaxed, "ldxp")
+__ATOMIC128_LDX_OP(__rte_ldx_acquire, "ldaxp")
+
+#define __ATOMIC128_STX_OP(stx_op_name, op_string) \
+static inline uint32_t \
+stx_op_name(rte_int128_t *dst, const rte_int128_t src) \
+{ \
+ uint32_t ret; \
+ asm volatile( \
+ op_string " %w0, %1, %2, %3" \
+ : "=&r" (ret) \
+ : "r" (src.val[0]), \
+ "r" (src.val[1]), \
+ "Q" (dst->val[0]) \
+ : "memory"); \
+ /* Return 0 on success, 1 on failure */ \
+ return ret; \
+}
+
+__ATOMIC128_STX_OP(__rte_stx_relaxed, "stxp")
+__ATOMIC128_STX_OP(__rte_stx_release, "stlxp")
+#endif
+
+static inline int __rte_experimental
+rte_atomic128_cmp_exchange(rte_int128_t *dst,
+ rte_int128_t *exp,
+ const rte_int128_t *src,
+ unsigned int weak,
+ int success,
+ int failure)
+{
+ /* Always do strong CAS */
+ RTE_SET_USED(weak);
+ /* Ignore memory ordering for failure, memory order for
+ * success must be stronger or equal
+ */
+ RTE_SET_USED(failure);
+ /* Find invalid memory order */
+ RTE_ASSERT(success == __ATOMIC_RELAXED
+ || success == __ATOMIC_ACQUIRE
+ || success == __ATOMIC_RELEASE
+ || success == __ATOMIC_ACQ_REL
+ || success == __ATOMIC_SEQ_CST);
+
+#ifdef __ARM_FEATURE_ATOMICS
+ rte_int128_t expected = *exp;
+ rte_int128_t desired = *src;
+ rte_int128_t old;
+
+ if (success == __ATOMIC_RELAXED)
+ old = __rte_cas_relaxed(dst, expected, desired);
+ else if (success == __ATOMIC_ACQUIRE)
+ old = __rte_cas_acquire(dst, expected, desired);
+ else if (success == __ATOMIC_RELEASE)
+ old = __rte_cas_release(dst, expected, desired);
+ else
+ old = __rte_cas_acq_rel(dst, expected, desired);
+#else
+ int ldx_mo = __MO_LOAD(success);
+ int stx_mo = __MO_STORE(success);
+ uint32_t ret = 1;
+ register rte_int128_t expected = *exp;
+ register rte_int128_t desired = *src;
+ register rte_int128_t old;
+
+ /* ldx128 can not guarantee atomic,
+ * Must write back src or old to verify atomicity of ldx128;
+ */
+ do {
+ if (ldx_mo == __ATOMIC_RELAXED)
+ old = __rte_ldx_relaxed(dst);
+ else
+ old = __rte_ldx_acquire(dst);
+
+ if (likely(old.int128 == expected.int128)) {
+ if (stx_mo == __ATOMIC_RELAXED)
+ ret = __rte_stx_relaxed(dst, desired);
+ else
+ ret = __rte_stx_release(dst, desired);
+ } else {
+ /* In the failure case (since 'weak' is ignored and only
+ * weak == 0 is implemented), expected should contain the
+ * atomically read value of dst. This means, 'old' needs
+ * to be stored back to ensure it was read atomically.
+ */
+ if (stx_mo == __ATOMIC_RELAXED)
+ ret = __rte_stx_relaxed(dst, old);
+ else
+ ret = __rte_stx_release(dst, old);
+ }
+ } while (unlikely(ret));
+#endif
+
+ /* Unconditionally updating expected removes
+ * an 'if' statement.
+ * expected should already be in register if
+ * not in the cache.
+ */
+ *exp = old;
+
+ return (old.int128 == expected.int128);
+}
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h b/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h
index e087c6c..1217129 100644
--- a/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h
+++ b/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h
@@ -212,18 +212,6 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
/*------------------------ 128 bit atomic operations -------------------------*/
-/**
- * 128-bit integer structure.
- */
-RTE_STD_C11
-typedef struct {
- RTE_STD_C11
- union {
- uint64_t val[2];
- __extension__ __int128 int128;
- };
-} __rte_aligned(16) rte_int128_t;
-
__rte_experimental
static inline int
rte_atomic128_cmp_exchange(rte_int128_t *dst,
diff --git a/lib/librte_eal/common/include/generic/rte_atomic.h b/lib/librte_eal/common/include/generic/rte_atomic.h
index 24ff7dc..e6ab15a 100644
--- a/lib/librte_eal/common/include/generic/rte_atomic.h
+++ b/lib/librte_eal/common/include/generic/rte_atomic.h
@@ -1081,6 +1081,20 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
/*------------------------ 128 bit atomic operations -------------------------*/
+/**
+ * 128-bit integer structure.
+ */
+RTE_STD_C11
+typedef struct {
+ RTE_STD_C11
+ union {
+ uint64_t val[2];
+#ifdef RTE_ARCH_64
+ __extension__ __int128 int128;
+#endif
+ };
+} __rte_aligned(16) rte_int128_t;
+
#ifdef __DOXYGEN__
/**
@@ -1093,7 +1107,8 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
* *exp = *dst
* @endcode
*
- * @note This function is currently only available for the x86-64 platform.
+ * @note This function is currently available for the x86-64 and aarch64
+ * platforms.
*
* @note The success and failure arguments must be one of the __ATOMIC_* values
* defined in the C++11 standard. For details on their behavior, refer to the
--
2.7.4
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v5 1/3] eal/arm64: add 128-bit atomic compare exchange
2019-07-22 8:44 2% ` [dpdk-dev] [PATCH v4 " Phil Yang
@ 2019-07-22 13:06 2% ` Phil Yang
2019-07-22 16:22 2% ` [dpdk-dev] [PATCH v6 " Phil Yang
2019-07-23 5:57 2% ` [dpdk-dev] [PATCH v7 " Phil Yang
4 siblings, 0 replies; 200+ results
From: Phil Yang @ 2019-07-22 13:06 UTC (permalink / raw)
To: dev
Cc: thomas, jerinj, gage.eads, hemant.agrawal, Honnappa.Nagarahalli,
gavin.hu, nd
Add 128-bit atomic compare exchange on aarch64.
Suggested-by: Jerin Jacob <jerinj@marvell.com>
Signed-off-by: Phil Yang <phil.yang@arm.com>
Tested-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
---
v5:
1. Enable RTE_ARM_FEATURE_ATOMICS on octeontx2 in default. (Jerin Jocob)
2. Record the reason of introducing "rte_stack_lf_stubs.h" in git commit.
(Jerin, Jocob)
3. Fixed a conditional MACRO error in rte_atomic128_cmp_exchange. (Jerin
Jocob)
v4:
1. Add RTE_ARM_FEATURE_ATOMICS flag to support LSE CASP instructions. (Jerin Jocob)
2. Fix possible arm64 ABI break by making casp_op_name noinline. (Jerin Jocob)
3. Add rte_stack_lf_stubs.h to reduce the ifdef clutter. (Gage Eads/Jerin Jocob)
v3:
1. Avoid duplication code with macro. (Jerin Jocob)
2. Make invalid memory order to strongest barrier. (Jerin Jocob)
3. Update doc/guides/prog_guide/env_abstraction_layer.rst. (Gage Eads)
4. Fix 32-bit x86 builds issue. (Gage Eads)
5. Correct documentation issues in UT. (Gage Eads)
v2:
Initial version.
config/arm/meson.build | 2 +
config/common_base | 5 +
config/defconfig_arm64-octeontx2-linuxapp-gcc | 3 +
config/defconfig_arm64-thunderx2-linuxapp-gcc | 1 +
.../common/include/arch/arm/rte_atomic_64.h | 162 +++++++++++++++++++++
.../common/include/arch/x86/rte_atomic_64.h | 12 --
lib/librte_eal/common/include/generic/rte_atomic.h | 17 ++-
7 files changed, 189 insertions(+), 13 deletions(-)
diff --git a/config/arm/meson.build b/config/arm/meson.build
index 979018e..1f5f471 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -68,6 +68,7 @@ flags_thunderx_extra = [
['RTE_USE_C11_MEM_MODEL', false]]
flags_thunderx2_extra = [
['RTE_MACHINE', '"thunderx2"'],
+ ['RTE_ARM_FEATURE_ATOMICS', true],
['RTE_CACHE_LINE_SIZE', 64],
['RTE_MAX_NUMA_NODES', 2],
['RTE_MAX_LCORE', 256],
@@ -76,6 +77,7 @@ flags_octeontx2_extra = [
['RTE_MACHINE', '"octeontx2"'],
['RTE_MAX_NUMA_NODES', 1],
['RTE_MAX_LCORE', 24],
+ ['RTE_ARM_FEATURE_ATOMICS', true],
['RTE_EAL_IGB_UIO', false],
['RTE_USE_C11_MEM_MODEL', true]]
diff --git a/config/common_base b/config/common_base
index 8ef75c2..16dea5a 100644
--- a/config/common_base
+++ b/config/common_base
@@ -1067,3 +1067,8 @@ CONFIG_RTE_APP_CRYPTO_PERF=y
# Compile the eventdev application
#
CONFIG_RTE_APP_EVENTDEV=y
+
+#
+# Compile ARM LSE ATOMIC instructions
+#
+CONFIG_RTE_ARM_FEATURE_ATOMICS=n
diff --git a/config/defconfig_arm64-octeontx2-linuxapp-gcc b/config/defconfig_arm64-octeontx2-linuxapp-gcc
index f20da24..a6508e8 100644
--- a/config/defconfig_arm64-octeontx2-linuxapp-gcc
+++ b/config/defconfig_arm64-octeontx2-linuxapp-gcc
@@ -19,3 +19,6 @@ CONFIG_RTE_EAL_IGB_UIO=n
# Max supported NIX LFs
CONFIG_RTE_MAX_VFIO_GROUPS=128
+
+# arm64 LSE ATOMIC support
+CONFIG_RTE_ARM_FEATURE_ATOMICS=y
diff --git a/config/defconfig_arm64-thunderx2-linuxapp-gcc b/config/defconfig_arm64-thunderx2-linuxapp-gcc
index cc5c64b..17b6dec 100644
--- a/config/defconfig_arm64-thunderx2-linuxapp-gcc
+++ b/config/defconfig_arm64-thunderx2-linuxapp-gcc
@@ -6,6 +6,7 @@
CONFIG_RTE_MACHINE="thunderx2"
+CONFIG_RTE_ARM_FEATURE_ATOMICS=y
CONFIG_RTE_CACHE_LINE_SIZE=64
CONFIG_RTE_MAX_NUMA_NODES=2
CONFIG_RTE_MAX_LCORE=256
diff --git a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
index 97060e4..a040d69 100644
--- a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
+++ b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
@@ -1,5 +1,6 @@
/* SPDX-License-Identifier: BSD-3-Clause
* Copyright(c) 2015 Cavium, Inc
+ * Copyright(c) 2019 Arm Limited
*/
#ifndef _RTE_ATOMIC_ARM64_H_
@@ -14,6 +15,9 @@ extern "C" {
#endif
#include "generic/rte_atomic.h"
+#include <rte_branch_prediction.h>
+#include <rte_compat.h>
+#include <rte_debug.h>
#define dsb(opt) asm volatile("dsb " #opt : : : "memory")
#define dmb(opt) asm volatile("dmb " #opt : : : "memory")
@@ -40,6 +44,164 @@ extern "C" {
#define rte_cio_rmb() dmb(oshld)
+/*------------------------ 128 bit atomic operations -------------------------*/
+
+#define __HAS_ACQ(mo) ((mo) != __ATOMIC_RELAXED && (mo) != __ATOMIC_RELEASE)
+#define __HAS_RLS(mo) ((mo) == __ATOMIC_RELEASE || (mo) == __ATOMIC_ACQ_REL || \
+ (mo) == __ATOMIC_SEQ_CST)
+
+#define __MO_LOAD(mo) (__HAS_ACQ((mo)) ? __ATOMIC_ACQUIRE : __ATOMIC_RELAXED)
+#define __MO_STORE(mo) (__HAS_RLS((mo)) ? __ATOMIC_RELEASE : __ATOMIC_RELAXED)
+
+#if defined(__ARM_FEATURE_ATOMICS) || defined(RTE_ARM_FEATURE_ATOMICS)
+#define __ATOMIC128_CAS_OP(cas_op_name, op_string) \
+static __rte_noinline rte_int128_t \
+cas_op_name(rte_int128_t *dst, rte_int128_t old, \
+ rte_int128_t updated) \
+{ \
+ /* caspX instructions register pair must start from even-numbered
+ * register at operand 1.
+ * So, specify registers for local variables here.
+ */ \
+ register uint64_t x0 __asm("x0") = (uint64_t)old.val[0]; \
+ register uint64_t x1 __asm("x1") = (uint64_t)old.val[1]; \
+ register uint64_t x2 __asm("x2") = (uint64_t)updated.val[0]; \
+ register uint64_t x3 __asm("x3") = (uint64_t)updated.val[1]; \
+ asm volatile( \
+ op_string " %[old0], %[old1], %[upd0], %[upd1], [%[dst]]" \
+ : [old0] "+r" (x0), \
+ [old1] "+r" (x1) \
+ : [upd0] "r" (x2), \
+ [upd1] "r" (x3), \
+ [dst] "r" (dst) \
+ : "memory"); \
+ old.val[0] = x0; \
+ old.val[1] = x1; \
+ return old; \
+}
+
+__ATOMIC128_CAS_OP(__rte_cas_relaxed, "casp")
+__ATOMIC128_CAS_OP(__rte_cas_acquire, "caspa")
+__ATOMIC128_CAS_OP(__rte_cas_release, "caspl")
+__ATOMIC128_CAS_OP(__rte_cas_acq_rel, "caspal")
+#else
+#define __ATOMIC128_LDX_OP(ldx_op_name, op_string) \
+static inline rte_int128_t \
+ldx_op_name(const rte_int128_t *src) \
+{ \
+ rte_int128_t ret; \
+ asm volatile( \
+ op_string " %0, %1, %2" \
+ : "=&r" (ret.val[0]), \
+ "=&r" (ret.val[1]) \
+ : "Q" (src->val[0]) \
+ : "memory"); \
+ return ret; \
+}
+
+__ATOMIC128_LDX_OP(__rte_ldx_relaxed, "ldxp")
+__ATOMIC128_LDX_OP(__rte_ldx_acquire, "ldaxp")
+
+#define __ATOMIC128_STX_OP(stx_op_name, op_string) \
+static inline uint32_t \
+stx_op_name(rte_int128_t *dst, const rte_int128_t src) \
+{ \
+ uint32_t ret; \
+ asm volatile( \
+ op_string " %w0, %1, %2, %3" \
+ : "=&r" (ret) \
+ : "r" (src.val[0]), \
+ "r" (src.val[1]), \
+ "Q" (dst->val[0]) \
+ : "memory"); \
+ /* Return 0 on success, 1 on failure */ \
+ return ret; \
+}
+
+__ATOMIC128_STX_OP(__rte_stx_relaxed, "stxp")
+__ATOMIC128_STX_OP(__rte_stx_release, "stlxp")
+#endif
+
+static inline int __rte_experimental
+rte_atomic128_cmp_exchange(rte_int128_t *dst,
+ rte_int128_t *exp,
+ const rte_int128_t *src,
+ unsigned int weak,
+ int success,
+ int failure)
+{
+ /* Always do strong CAS */
+ RTE_SET_USED(weak);
+ /* Ignore memory ordering for failure, memory order for
+ * success must be stronger or equal
+ */
+ RTE_SET_USED(failure);
+ /* Find invalid memory order */
+ RTE_ASSERT(success == __ATOMIC_RELAXED
+ || success == __ATOMIC_ACQUIRE
+ || success == __ATOMIC_RELEASE
+ || success == __ATOMIC_ACQ_REL
+ || success == __ATOMIC_SEQ_CST);
+
+#if defined(__ARM_FEATURE_ATOMICS) || defined(RTE_ARM_FEATURE_ATOMICS)
+ rte_int128_t expected = *exp;
+ rte_int128_t desired = *src;
+ rte_int128_t old;
+
+ if (success == __ATOMIC_RELAXED)
+ old = __rte_cas_relaxed(dst, expected, desired);
+ else if (success == __ATOMIC_ACQUIRE)
+ old = __rte_cas_acquire(dst, expected, desired);
+ else if (success == __ATOMIC_RELEASE)
+ old = __rte_cas_release(dst, expected, desired);
+ else
+ old = __rte_cas_acq_rel(dst, expected, desired);
+#else
+ int ldx_mo = __MO_LOAD(success);
+ int stx_mo = __MO_STORE(success);
+ uint32_t ret = 1;
+ register rte_int128_t expected = *exp;
+ register rte_int128_t desired = *src;
+ register rte_int128_t old;
+
+ /* ldx128 can not guarantee atomic,
+ * Must write back src or old to verify atomicity of ldx128;
+ */
+ do {
+ if (ldx_mo == __ATOMIC_RELAXED)
+ old = __rte_ldx_relaxed(dst);
+ else
+ old = __rte_ldx_acquire(dst);
+
+ if (likely(old.int128 == expected.int128)) {
+ if (stx_mo == __ATOMIC_RELAXED)
+ ret = __rte_stx_relaxed(dst, desired);
+ else
+ ret = __rte_stx_release(dst, desired);
+ } else {
+ /* In the failure case (since 'weak' is ignored and only
+ * weak == 0 is implemented), expected should contain the
+ * atomically read value of dst. This means, 'old' needs
+ * to be stored back to ensure it was read atomically.
+ */
+ if (stx_mo == __ATOMIC_RELAXED)
+ ret = __rte_stx_relaxed(dst, old);
+ else
+ ret = __rte_stx_release(dst, old);
+ }
+ } while (unlikely(ret));
+#endif
+
+ /* Unconditionally updating expected removes
+ * an 'if' statement.
+ * expected should already be in register if
+ * not in the cache.
+ */
+ *exp = old;
+
+ return (old.int128 == expected.int128);
+}
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h b/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h
index e087c6c..1217129 100644
--- a/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h
+++ b/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h
@@ -212,18 +212,6 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
/*------------------------ 128 bit atomic operations -------------------------*/
-/**
- * 128-bit integer structure.
- */
-RTE_STD_C11
-typedef struct {
- RTE_STD_C11
- union {
- uint64_t val[2];
- __extension__ __int128 int128;
- };
-} __rte_aligned(16) rte_int128_t;
-
__rte_experimental
static inline int
rte_atomic128_cmp_exchange(rte_int128_t *dst,
diff --git a/lib/librte_eal/common/include/generic/rte_atomic.h b/lib/librte_eal/common/include/generic/rte_atomic.h
index 24ff7dc..e6ab15a 100644
--- a/lib/librte_eal/common/include/generic/rte_atomic.h
+++ b/lib/librte_eal/common/include/generic/rte_atomic.h
@@ -1081,6 +1081,20 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
/*------------------------ 128 bit atomic operations -------------------------*/
+/**
+ * 128-bit integer structure.
+ */
+RTE_STD_C11
+typedef struct {
+ RTE_STD_C11
+ union {
+ uint64_t val[2];
+#ifdef RTE_ARCH_64
+ __extension__ __int128 int128;
+#endif
+ };
+} __rte_aligned(16) rte_int128_t;
+
#ifdef __DOXYGEN__
/**
@@ -1093,7 +1107,8 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
* *exp = *dst
* @endcode
*
- * @note This function is currently only available for the x86-64 platform.
+ * @note This function is currently available for the x86-64 and aarch64
+ * platforms.
*
* @note The success and failure arguments must be one of the __ATOMIC_* values
* defined in the C++11 standard. For details on their behavior, refer to the
--
2.7.4
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [PATCH] app/testpmd: support QinQ strip offload
@ 2019-07-22 15:40 3% ` Ferruh Yigit
2019-07-22 17:03 0% ` Iremonger, Bernard
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2019-07-22 15:40 UTC (permalink / raw)
To: Iremonger, Bernard, viveksharma, dev; +Cc: intoviveksharma
On 7/22/2019 3:55 PM, Iremonger, Bernard wrote:
> Hi Ferruh,
>
>> -----Original Message-----
>> From: Yigit, Ferruh
>> Sent: Monday, July 22, 2019 3:27 PM
>> To: Iremonger, Bernard <bernard.iremonger@intel.com>;
>> viveksharma@marvell.com; dev@dpdk.org
>> Cc: intoviveksharma@gmail.com
>> Subject: Re: [dpdk-dev] [PATCH] app/testpmd: support QinQ strip offload
>>
>> On 7/22/2019 1:04 PM, Iremonger, Bernard wrote:
>>> Hi Ferruh,
>>>
>>>> -----Original Message-----
>>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ferruh Yigit
>>>> Sent: Friday, July 19, 2019 5:53 PM
>>>> To: viveksharma@marvell.com; dev@dpdk.org
>>>> Cc: intoviveksharma@gmail.com
>>>> Subject: Re: [dpdk-dev] [PATCH] app/testpmd: support QinQ strip
>>>> offload
>>>>
>>>> On 7/17/2019 8:45 AM, viveksharma@marvell.com wrote:
>>>>> From: Vivek Sharma <viveksharma@marvell.com>
>>>>>
>>>>> Support QinQ strip RX offload configuration through testpmd command
>>>>> line and boot time arguments.
>>>>
>>>> For the testpmd command part, unfortunately there are two set of
>>>> commands for same purpose, the new ones are (lets both port and
>> queue
>>>> level):
>>>> "port config <port_id> rx_offload ..."
>>>> "port (port_id) rxq (queue_id) rx_offload ..."
>>>> "port config (port_id) tx_offload ..."
>>>> "port (port_id) txq (queue_id) tx_offload ..."
>>>>
>>>> These are better implementation comparing the old one:
>>>> "port config all ..."
>>>>
>>>> Would you mind sending a patch to remove "port config all ..."
>>>> variant of setting offloads?
>>>> And you can make your changes to the new commands above.
>>>
>>> Is it ok to remove "port config all ..." commands as they may be in use by
>> the community?
>>
>> Since there is a command that replaces the removed functionality I think it is
>> OK.
>>
>> Also I am not sure what level of backward compatibility we should provide
>> for testpmd commands.
>
> It might be better to leave "port config all ..." commands as they are for now and provide a separate patchset for the new style port setting offloads commands.
>
> If they are to be removed there should at least be something to announce this in the release notes. There is a deprecation process which is used for the rest of the code, why not follow that process.
Deprecation process is for ABI/API changes.
I can see testpmd commands also a kind of user interface, but this is a test
application at the end, deprecation process can be overkill here.
Although +1 to be cautious on command consistency and keep some level of
stability on them.
>
>>>> For the application argument, ``--enable-hw-vlan-extend``, instead of
>>>> adding a parameter of each offload argument, (and event it is not
>>>> clear if it is only for Rx or Tx), have a "--rx-offloads" argument and feed
>> the list via this, like:
>>>> "--rx-ofloads=disable-crc-strip,enable-rx-timestamp"
>>>>
>>>>
>>>>
>>>> And lastly for the "vlan set ..." update, I think "qinq" was already
>>>> defined but it was calling 'vlan_extend_set()', now you are changing
>>>> it and making it call 'rx_vlan_qinq_strip_set()', I think this is OK,
>>>> but can you please update the 'cmd_help_long_parsed()' accordingly?
>>>
>>> 'vlan_extend_set()' and 'rx_vlan_qinq_strip_set()' are different
>> commands.
>>> vlan_extend_set() is for adding the second vlan and
>> rx_vlan_qinq_strip_set() is for removing the second vlan.
>>
>> yes they are different, I think nobody said they are same.
>> What is the concern here, can you please detail more?
>
> In the previous paragraph, you mentioned that
> "I think "qinq" was already defined but it was calling 'vlan_extend_set()', now you are changing
> it and making it call 'rx_vlan_qinq_strip_set()' "
>
> vlan_extend_set() is not being changed, rx_vlan_qinq_strip_set() is being added.
Before this patch,
"vlan set qinq" calls 'vlan_extend_set()'
After patch,
"vlan set qinq" calls 'rx_vlan_qinq_strip_set()'
And again after this patch,
"vlan set extend" added and which calls 'vlan_extend_set()'
so the patch looks like adding "vlan set extend" command, but practically it
does fix "vlan set qinq", I said "I think this is OK" and asked for help string
& documentation update accordingly.
I hope it is clear now.
>
>>>> And in original 'cmd_help_long_parsed()' for 'vlan set ...", it
>>>> doesn't need to have separate lines for "strip, filter & qinq", can
>>>> you please merge them, and later the 'extend' one?
>>>> Than change needs to be documented on "testpmd_funcs.rst"
>>>>
>>>>
>>>> And as a last thing, can you please send this as multiple patches:
>>>> 1) Command line change for setting qinq offload
>>>> 2) Application argument change
>>>> 3) "vlan set " related changes
>>>>
>>>>>
>>>>> Signed-off-by: Vivek Sharma <viveksharma@marvell.com>
>>>>
>>>
>>> Regards,
>>>
>>> Bernard
>>>
> In my opinion this patch was fine for the "port config all ..." style commands.
Duplication is bad, it is bad to have two different ways to do same thing.
I am not sure if Vivek is aware of duplicated functions but explicitly prefers
to update old versions.
I suggest lets stop improving these ones and get rid of them asap.
Also as you can see commit log doesn't mention from "vlan set ..." changes at
all, that is why I asked for splitting this into 3 patches for 3 separate thing
it does.
>
> A separate patch set should be submitted for the new style setting offloads commands.
>
> Regards,
>
> Bernard
>
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v6 1/3] eal/arm64: add 128-bit atomic compare exchange
` (2 preceding siblings ...)
2019-07-22 13:06 2% ` [dpdk-dev] [PATCH v5 " Phil Yang
@ 2019-07-22 16:22 2% ` Phil Yang
2019-07-23 5:57 2% ` [dpdk-dev] [PATCH v7 " Phil Yang
4 siblings, 0 replies; 200+ results
From: Phil Yang @ 2019-07-22 16:22 UTC (permalink / raw)
To: dev
Cc: thomas, jerinj, gage.eads, hemant.agrawal, Honnappa.Nagarahalli,
gavin.hu, nd
Add 128-bit atomic compare exchange on aarch64.
Suggested-by: Jerin Jacob <jerinj@marvell.com>
Signed-off-by: Phil Yang <phil.yang@arm.com>
Tested-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
---
v6:
1. Put the RTE_ARM_FEATURE_ATOMICS flag into EAL group. (Jerin Jocob)
2. Keep rte_stack_lf_stubs.h doing nothing. (Gage Eads)
3. Fixed 32 bit build issue.
v5:
1. Enable RTE_ARM_FEATURE_ATOMICS on octeontx2 in default. (Jerin Jocob)
2. Record the reason of introducing "rte_stack_lf_stubs.h" in git commit.
(Jerin, Jocob)
3. Fixed a conditional MACRO error in rte_atomic128_cmp_exchange. (Jerin
Jocob)
v4:
1. Add RTE_ARM_FEATURE_ATOMICS flag to support LSE CASP instructions. (Jerin Jocob)
2. Fix possible arm64 ABI break by making casp_op_name noinline. (Jerin Jocob)
3. Add rte_stack_lf_stubs.h to reduce the ifdef clutter. (Gage Eads/Jerin Jocob)
v3:
1. Avoid duplication code with macro. (Jerin Jocob)
2. Make invalid memory order to strongest barrier. (Jerin Jocob)
3. Update doc/guides/prog_guide/env_abstraction_layer.rst. (Gage Eads)
4. Fix 32-bit x86 builds issue. (Gage Eads)
5. Correct documentation issues in UT. (Gage Eads)
v2:
Initial version.
config/arm/meson.build | 2 +
config/common_base | 2 +
config/defconfig_arm64-octeontx2-linuxapp-gcc | 1 +
config/defconfig_arm64-thunderx2-linuxapp-gcc | 1 +
.../common/include/arch/arm/rte_atomic_64.h | 162 +++++++++++++++++++++
.../common/include/arch/x86/rte_atomic_64.h | 12 --
lib/librte_eal/common/include/generic/rte_atomic.h | 17 ++-
7 files changed, 184 insertions(+), 13 deletions(-)
diff --git a/config/arm/meson.build b/config/arm/meson.build
index 979018e..9f28271 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -71,11 +71,13 @@ flags_thunderx2_extra = [
['RTE_CACHE_LINE_SIZE', 64],
['RTE_MAX_NUMA_NODES', 2],
['RTE_MAX_LCORE', 256],
+ ['RTE_ARM_FEATURE_ATOMICS', true],
['RTE_USE_C11_MEM_MODEL', true]]
flags_octeontx2_extra = [
['RTE_MACHINE', '"octeontx2"'],
['RTE_MAX_NUMA_NODES', 1],
['RTE_MAX_LCORE', 24],
+ ['RTE_ARM_FEATURE_ATOMICS', true],
['RTE_EAL_IGB_UIO', false],
['RTE_USE_C11_MEM_MODEL', true]]
diff --git a/config/common_base b/config/common_base
index 8ef75c2..de6d1e0 100644
--- a/config/common_base
+++ b/config/common_base
@@ -82,6 +82,8 @@ CONFIG_RTE_MAX_LCORE=128
CONFIG_RTE_MAX_NUMA_NODES=8
CONFIG_RTE_MAX_HEAPS=32
CONFIG_RTE_MAX_MEMSEG_LISTS=64
+# Use LSE ATOMIC instructions
+CONFIG_RTE_ARM_FEATURE_ATOMICS=n
# each memseg list will be limited to either RTE_MAX_MEMSEG_PER_LIST pages
# or RTE_MAX_MEM_MB_PER_LIST megabytes worth of memory, whichever is smaller
CONFIG_RTE_MAX_MEMSEG_PER_LIST=8192
diff --git a/config/defconfig_arm64-octeontx2-linuxapp-gcc b/config/defconfig_arm64-octeontx2-linuxapp-gcc
index f20da24..7687dbe 100644
--- a/config/defconfig_arm64-octeontx2-linuxapp-gcc
+++ b/config/defconfig_arm64-octeontx2-linuxapp-gcc
@@ -9,6 +9,7 @@ CONFIG_RTE_MACHINE="octeontx2"
CONFIG_RTE_CACHE_LINE_SIZE=128
CONFIG_RTE_MAX_NUMA_NODES=1
CONFIG_RTE_MAX_LCORE=24
+CONFIG_RTE_ARM_FEATURE_ATOMICS=y
# Doesn't support NUMA
CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=n
diff --git a/config/defconfig_arm64-thunderx2-linuxapp-gcc b/config/defconfig_arm64-thunderx2-linuxapp-gcc
index cc5c64b..af4a89c 100644
--- a/config/defconfig_arm64-thunderx2-linuxapp-gcc
+++ b/config/defconfig_arm64-thunderx2-linuxapp-gcc
@@ -9,3 +9,4 @@ CONFIG_RTE_MACHINE="thunderx2"
CONFIG_RTE_CACHE_LINE_SIZE=64
CONFIG_RTE_MAX_NUMA_NODES=2
CONFIG_RTE_MAX_LCORE=256
+CONFIG_RTE_ARM_FEATURE_ATOMICS=y
diff --git a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
index 97060e4..a040d69 100644
--- a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
+++ b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
@@ -1,5 +1,6 @@
/* SPDX-License-Identifier: BSD-3-Clause
* Copyright(c) 2015 Cavium, Inc
+ * Copyright(c) 2019 Arm Limited
*/
#ifndef _RTE_ATOMIC_ARM64_H_
@@ -14,6 +15,9 @@ extern "C" {
#endif
#include "generic/rte_atomic.h"
+#include <rte_branch_prediction.h>
+#include <rte_compat.h>
+#include <rte_debug.h>
#define dsb(opt) asm volatile("dsb " #opt : : : "memory")
#define dmb(opt) asm volatile("dmb " #opt : : : "memory")
@@ -40,6 +44,164 @@ extern "C" {
#define rte_cio_rmb() dmb(oshld)
+/*------------------------ 128 bit atomic operations -------------------------*/
+
+#define __HAS_ACQ(mo) ((mo) != __ATOMIC_RELAXED && (mo) != __ATOMIC_RELEASE)
+#define __HAS_RLS(mo) ((mo) == __ATOMIC_RELEASE || (mo) == __ATOMIC_ACQ_REL || \
+ (mo) == __ATOMIC_SEQ_CST)
+
+#define __MO_LOAD(mo) (__HAS_ACQ((mo)) ? __ATOMIC_ACQUIRE : __ATOMIC_RELAXED)
+#define __MO_STORE(mo) (__HAS_RLS((mo)) ? __ATOMIC_RELEASE : __ATOMIC_RELAXED)
+
+#if defined(__ARM_FEATURE_ATOMICS) || defined(RTE_ARM_FEATURE_ATOMICS)
+#define __ATOMIC128_CAS_OP(cas_op_name, op_string) \
+static __rte_noinline rte_int128_t \
+cas_op_name(rte_int128_t *dst, rte_int128_t old, \
+ rte_int128_t updated) \
+{ \
+ /* caspX instructions register pair must start from even-numbered
+ * register at operand 1.
+ * So, specify registers for local variables here.
+ */ \
+ register uint64_t x0 __asm("x0") = (uint64_t)old.val[0]; \
+ register uint64_t x1 __asm("x1") = (uint64_t)old.val[1]; \
+ register uint64_t x2 __asm("x2") = (uint64_t)updated.val[0]; \
+ register uint64_t x3 __asm("x3") = (uint64_t)updated.val[1]; \
+ asm volatile( \
+ op_string " %[old0], %[old1], %[upd0], %[upd1], [%[dst]]" \
+ : [old0] "+r" (x0), \
+ [old1] "+r" (x1) \
+ : [upd0] "r" (x2), \
+ [upd1] "r" (x3), \
+ [dst] "r" (dst) \
+ : "memory"); \
+ old.val[0] = x0; \
+ old.val[1] = x1; \
+ return old; \
+}
+
+__ATOMIC128_CAS_OP(__rte_cas_relaxed, "casp")
+__ATOMIC128_CAS_OP(__rte_cas_acquire, "caspa")
+__ATOMIC128_CAS_OP(__rte_cas_release, "caspl")
+__ATOMIC128_CAS_OP(__rte_cas_acq_rel, "caspal")
+#else
+#define __ATOMIC128_LDX_OP(ldx_op_name, op_string) \
+static inline rte_int128_t \
+ldx_op_name(const rte_int128_t *src) \
+{ \
+ rte_int128_t ret; \
+ asm volatile( \
+ op_string " %0, %1, %2" \
+ : "=&r" (ret.val[0]), \
+ "=&r" (ret.val[1]) \
+ : "Q" (src->val[0]) \
+ : "memory"); \
+ return ret; \
+}
+
+__ATOMIC128_LDX_OP(__rte_ldx_relaxed, "ldxp")
+__ATOMIC128_LDX_OP(__rte_ldx_acquire, "ldaxp")
+
+#define __ATOMIC128_STX_OP(stx_op_name, op_string) \
+static inline uint32_t \
+stx_op_name(rte_int128_t *dst, const rte_int128_t src) \
+{ \
+ uint32_t ret; \
+ asm volatile( \
+ op_string " %w0, %1, %2, %3" \
+ : "=&r" (ret) \
+ : "r" (src.val[0]), \
+ "r" (src.val[1]), \
+ "Q" (dst->val[0]) \
+ : "memory"); \
+ /* Return 0 on success, 1 on failure */ \
+ return ret; \
+}
+
+__ATOMIC128_STX_OP(__rte_stx_relaxed, "stxp")
+__ATOMIC128_STX_OP(__rte_stx_release, "stlxp")
+#endif
+
+static inline int __rte_experimental
+rte_atomic128_cmp_exchange(rte_int128_t *dst,
+ rte_int128_t *exp,
+ const rte_int128_t *src,
+ unsigned int weak,
+ int success,
+ int failure)
+{
+ /* Always do strong CAS */
+ RTE_SET_USED(weak);
+ /* Ignore memory ordering for failure, memory order for
+ * success must be stronger or equal
+ */
+ RTE_SET_USED(failure);
+ /* Find invalid memory order */
+ RTE_ASSERT(success == __ATOMIC_RELAXED
+ || success == __ATOMIC_ACQUIRE
+ || success == __ATOMIC_RELEASE
+ || success == __ATOMIC_ACQ_REL
+ || success == __ATOMIC_SEQ_CST);
+
+#if defined(__ARM_FEATURE_ATOMICS) || defined(RTE_ARM_FEATURE_ATOMICS)
+ rte_int128_t expected = *exp;
+ rte_int128_t desired = *src;
+ rte_int128_t old;
+
+ if (success == __ATOMIC_RELAXED)
+ old = __rte_cas_relaxed(dst, expected, desired);
+ else if (success == __ATOMIC_ACQUIRE)
+ old = __rte_cas_acquire(dst, expected, desired);
+ else if (success == __ATOMIC_RELEASE)
+ old = __rte_cas_release(dst, expected, desired);
+ else
+ old = __rte_cas_acq_rel(dst, expected, desired);
+#else
+ int ldx_mo = __MO_LOAD(success);
+ int stx_mo = __MO_STORE(success);
+ uint32_t ret = 1;
+ register rte_int128_t expected = *exp;
+ register rte_int128_t desired = *src;
+ register rte_int128_t old;
+
+ /* ldx128 can not guarantee atomic,
+ * Must write back src or old to verify atomicity of ldx128;
+ */
+ do {
+ if (ldx_mo == __ATOMIC_RELAXED)
+ old = __rte_ldx_relaxed(dst);
+ else
+ old = __rte_ldx_acquire(dst);
+
+ if (likely(old.int128 == expected.int128)) {
+ if (stx_mo == __ATOMIC_RELAXED)
+ ret = __rte_stx_relaxed(dst, desired);
+ else
+ ret = __rte_stx_release(dst, desired);
+ } else {
+ /* In the failure case (since 'weak' is ignored and only
+ * weak == 0 is implemented), expected should contain the
+ * atomically read value of dst. This means, 'old' needs
+ * to be stored back to ensure it was read atomically.
+ */
+ if (stx_mo == __ATOMIC_RELAXED)
+ ret = __rte_stx_relaxed(dst, old);
+ else
+ ret = __rte_stx_release(dst, old);
+ }
+ } while (unlikely(ret));
+#endif
+
+ /* Unconditionally updating expected removes
+ * an 'if' statement.
+ * expected should already be in register if
+ * not in the cache.
+ */
+ *exp = old;
+
+ return (old.int128 == expected.int128);
+}
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h b/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h
index e087c6c..1217129 100644
--- a/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h
+++ b/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h
@@ -212,18 +212,6 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
/*------------------------ 128 bit atomic operations -------------------------*/
-/**
- * 128-bit integer structure.
- */
-RTE_STD_C11
-typedef struct {
- RTE_STD_C11
- union {
- uint64_t val[2];
- __extension__ __int128 int128;
- };
-} __rte_aligned(16) rte_int128_t;
-
__rte_experimental
static inline int
rte_atomic128_cmp_exchange(rte_int128_t *dst,
diff --git a/lib/librte_eal/common/include/generic/rte_atomic.h b/lib/librte_eal/common/include/generic/rte_atomic.h
index 24ff7dc..e6ab15a 100644
--- a/lib/librte_eal/common/include/generic/rte_atomic.h
+++ b/lib/librte_eal/common/include/generic/rte_atomic.h
@@ -1081,6 +1081,20 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
/*------------------------ 128 bit atomic operations -------------------------*/
+/**
+ * 128-bit integer structure.
+ */
+RTE_STD_C11
+typedef struct {
+ RTE_STD_C11
+ union {
+ uint64_t val[2];
+#ifdef RTE_ARCH_64
+ __extension__ __int128 int128;
+#endif
+ };
+} __rte_aligned(16) rte_int128_t;
+
#ifdef __DOXYGEN__
/**
@@ -1093,7 +1107,8 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
* *exp = *dst
* @endcode
*
- * @note This function is currently only available for the x86-64 platform.
+ * @note This function is currently available for the x86-64 and aarch64
+ * platforms.
*
* @note The success and failure arguments must be one of the __ATOMIC_* values
* defined in the C++11 standard. For details on their behavior, refer to the
--
2.7.4
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [PATCH] app/testpmd: support QinQ strip offload
2019-07-22 15:40 3% ` Ferruh Yigit
@ 2019-07-22 17:03 0% ` Iremonger, Bernard
2019-07-22 17:16 0% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Iremonger, Bernard @ 2019-07-22 17:03 UTC (permalink / raw)
To: Yigit, Ferruh, viveksharma, dev; +Cc: intoviveksharma
Hi Ferruh,
<snip>
> >>>> Subject: Re: [dpdk-dev] [PATCH] app/testpmd: support QinQ strip
> >>>> offload
> >>>>
> >>>> On 7/17/2019 8:45 AM, viveksharma@marvell.com wrote:
> >>>>> From: Vivek Sharma <viveksharma@marvell.com>
> >>>>>
> >>>>> Support QinQ strip RX offload configuration through testpmd
> >>>>> command line and boot time arguments.
> >>>>
> >>>> For the testpmd command part, unfortunately there are two set of
> >>>> commands for same purpose, the new ones are (lets both port and
> >> queue
> >>>> level):
> >>>> "port config <port_id> rx_offload ..."
> >>>> "port (port_id) rxq (queue_id) rx_offload ..."
> >>>> "port config (port_id) tx_offload ..."
> >>>> "port (port_id) txq (queue_id) tx_offload ..."
> >>>>
> >>>> These are better implementation comparing the old one:
> >>>> "port config all ..."
> >>>>
> >>>> Would you mind sending a patch to remove "port config all ..."
> >>>> variant of setting offloads?
> >>>> And you can make your changes to the new commands above.
> >>>
> >>> Is it ok to remove "port config all ..." commands as they may be in
> >>> use by
> >> the community?
> >>
> >> Since there is a command that replaces the removed functionality I
> >> think it is OK.
> >>
> >> Also I am not sure what level of backward compatibility we should
> >> provide for testpmd commands.
> >
> > It might be better to leave "port config all ..." commands as they are for
> now and provide a separate patchset for the new style port setting offloads
> commands.
> >
> > If they are to be removed there should at least be something to announce
> this in the release notes. There is a deprecation process which is used for the
> rest of the code, why not follow that process.
>
> Deprecation process is for ABI/API changes.
>
> I can see testpmd commands also a kind of user interface, but this is a test
> application at the end, deprecation process can be overkill here.
> Although +1 to be cautious on command consistency and keep some level of
> stability on them.
> >>>> For the application argument, ``--enable-hw-vlan-extend``, instead
> >>>> of adding a parameter of each offload argument, (and event it is
> >>>> not clear if it is only for Rx or Tx), have a "--rx-offloads"
> >>>> argument and feed
> >> the list via this, like:
> >>>> "--rx-ofloads=disable-crc-strip,enable-rx-timestamp"
> >>>>
> >>>>
> >>>>
> >>>> And lastly for the "vlan set ..." update, I think "qinq" was
> >>>> already defined but it was calling 'vlan_extend_set()', now you are
> >>>> changing it and making it call 'rx_vlan_qinq_strip_set()', I think
> >>>> this is OK, but can you please update the 'cmd_help_long_parsed()'
> accordingly?
> >>>
> >>> 'vlan_extend_set()' and 'rx_vlan_qinq_strip_set()' are different
> >> commands.
> >>> vlan_extend_set() is for adding the second vlan and
> >> rx_vlan_qinq_strip_set() is for removing the second vlan.
> >>
> >> yes they are different, I think nobody said they are same.
> >> What is the concern here, can you please detail more?
> >
> > In the previous paragraph, you mentioned that "I think "qinq" was
> > already defined but it was calling 'vlan_extend_set()', now you are
> > changing it and making it call 'rx_vlan_qinq_strip_set()' "
> >
> > vlan_extend_set() is not being changed, rx_vlan_qinq_strip_set() is being
> added.
>
> Before this patch,
> "vlan set qinq" calls 'vlan_extend_set()'
>
> After patch,
> "vlan set qinq" calls 'rx_vlan_qinq_strip_set()'
> And again after this patch,
> "vlan set extend" added and which calls 'vlan_extend_set()'
>
> so the patch looks like adding "vlan set extend" command, but practically it
> does fix "vlan set qinq", I said "I think this is OK" and asked for help string &
> documentation update accordingly.
>
> I hope it is clear now.
Yes, I see what you mean now (well spotted).
Previously the "qinq" keyword mapped to extend now it maps to qinq_strip. It would be better to leave the function of the "qinq" keyword as it was add a "qinqstrip" keyword instead of adding the "extend" keyword.
> >>>> And in original 'cmd_help_long_parsed()' for 'vlan set ...", it
> >>>> doesn't need to have separate lines for "strip, filter & qinq", can
> >>>> you please merge them, and later the 'extend' one?
> >>>> Than change needs to be documented on "testpmd_funcs.rst"
> >>>>
> >>>>
> >>>> And as a last thing, can you please send this as multiple patches:
> >>>> 1) Command line change for setting qinq offload
> >>>> 2) Application argument change
> >>>> 3) "vlan set " related changes
> >>>>
> >>>>>
> >>>>> Signed-off-by: Vivek Sharma <viveksharma@marvell.com>
> >>>>
> >>>
> >>> Regards,
> >>>
> >>> Bernard
> >>>
> > In my opinion this patch was fine for the "port config all ..." style
> commands.
>
> Duplication is bad, it is bad to have two different ways to do same thing.
> I am not sure if Vivek is aware of duplicated functions but explicitly prefers to
> update old versions.
> I suggest lets stop improving these ones and get rid of them asap.
Testpmd is widely used so removing commands without notice will probably not go down too well with the community.
> Also as you can see commit log doesn't mention from "vlan set ..." changes at
> all, that is why I asked for splitting this into 3 patches for 3 separate thing it
> does.
Ok, it should describe the "vlan set ...." changes.
> > A separate patch set should be submitted for the new style setting offloads
> commands.
> >
> > Regards,
> >
> > Bernard
> >
Regards,
Bernard
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] app/testpmd: support QinQ strip offload
2019-07-22 17:03 0% ` Iremonger, Bernard
@ 2019-07-22 17:16 0% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2019-07-22 17:16 UTC (permalink / raw)
To: Iremonger, Bernard, viveksharma, dev; +Cc: intoviveksharma
On 7/22/2019 6:03 PM, Iremonger, Bernard wrote:
> Hi Ferruh,
>
> <snip>
>
>>>>>> Subject: Re: [dpdk-dev] [PATCH] app/testpmd: support QinQ strip
>>>>>> offload
>>>>>>
>>>>>> On 7/17/2019 8:45 AM, viveksharma@marvell.com wrote:
>>>>>>> From: Vivek Sharma <viveksharma@marvell.com>
>>>>>>>
>>>>>>> Support QinQ strip RX offload configuration through testpmd
>>>>>>> command line and boot time arguments.
>>>>>>
>>>>>> For the testpmd command part, unfortunately there are two set of
>>>>>> commands for same purpose, the new ones are (lets both port and
>>>> queue
>>>>>> level):
>>>>>> "port config <port_id> rx_offload ..."
>>>>>> "port (port_id) rxq (queue_id) rx_offload ..."
>>>>>> "port config (port_id) tx_offload ..."
>>>>>> "port (port_id) txq (queue_id) tx_offload ..."
>>>>>>
>>>>>> These are better implementation comparing the old one:
>>>>>> "port config all ..."
>>>>>>
>>>>>> Would you mind sending a patch to remove "port config all ..."
>>>>>> variant of setting offloads?
>>>>>> And you can make your changes to the new commands above.
>>>>>
>>>>> Is it ok to remove "port config all ..." commands as they may be in
>>>>> use by
>>>> the community?
>>>>
>>>> Since there is a command that replaces the removed functionality I
>>>> think it is OK.
>>>>
>>>> Also I am not sure what level of backward compatibility we should
>>>> provide for testpmd commands.
>>>
>>> It might be better to leave "port config all ..." commands as they are for
>> now and provide a separate patchset for the new style port setting offloads
>> commands.
>>>
>>> If they are to be removed there should at least be something to announce
>> this in the release notes. There is a deprecation process which is used for the
>> rest of the code, why not follow that process.
>>
>> Deprecation process is for ABI/API changes.
>>
>> I can see testpmd commands also a kind of user interface, but this is a test
>> application at the end, deprecation process can be overkill here.
>> Although +1 to be cautious on command consistency and keep some level of
>> stability on them.
>
>>>>>> For the application argument, ``--enable-hw-vlan-extend``, instead
>>>>>> of adding a parameter of each offload argument, (and event it is
>>>>>> not clear if it is only for Rx or Tx), have a "--rx-offloads"
>>>>>> argument and feed
>>>> the list via this, like:
>>>>>> "--rx-ofloads=disable-crc-strip,enable-rx-timestamp"
>>>>>>
>>>>>>
>>>>>>
>>>>>> And lastly for the "vlan set ..." update, I think "qinq" was
>>>>>> already defined but it was calling 'vlan_extend_set()', now you are
>>>>>> changing it and making it call 'rx_vlan_qinq_strip_set()', I think
>>>>>> this is OK, but can you please update the 'cmd_help_long_parsed()'
>> accordingly?
>>>>>
>>>>> 'vlan_extend_set()' and 'rx_vlan_qinq_strip_set()' are different
>>>> commands.
>>>>> vlan_extend_set() is for adding the second vlan and
>>>> rx_vlan_qinq_strip_set() is for removing the second vlan.
>>>>
>>>> yes they are different, I think nobody said they are same.
>>>> What is the concern here, can you please detail more?
>>>
>>> In the previous paragraph, you mentioned that "I think "qinq" was
>>> already defined but it was calling 'vlan_extend_set()', now you are
>>> changing it and making it call 'rx_vlan_qinq_strip_set()' "
>>>
>>> vlan_extend_set() is not being changed, rx_vlan_qinq_strip_set() is being
>> added.
>>
>> Before this patch,
>> "vlan set qinq" calls 'vlan_extend_set()'
>>
>> After patch,
>> "vlan set qinq" calls 'rx_vlan_qinq_strip_set()'
>
>> And again after this patch,
>> "vlan set extend" added and which calls 'vlan_extend_set()'
>>
>> so the patch looks like adding "vlan set extend" command, but practically it
>> does fix "vlan set qinq", I said "I think this is OK" and asked for help string &
>> documentation update accordingly.
>>
>> I hope it is clear now.
>
> Yes, I see what you mean now (well spotted).
> Previously the "qinq" keyword mapped to extend now it maps to qinq_strip. It would be better to leave the function of the "qinq" keyword as it was add a "qinqstrip" keyword instead of adding the "extend" keyword.
>
>>>>>> And in original 'cmd_help_long_parsed()' for 'vlan set ...", it
>>>>>> doesn't need to have separate lines for "strip, filter & qinq", can
>>>>>> you please merge them, and later the 'extend' one?
>>>>>> Than change needs to be documented on "testpmd_funcs.rst"
>>>>>>
>>>>>>
>>>>>> And as a last thing, can you please send this as multiple patches:
>>>>>> 1) Command line change for setting qinq offload
>>>>>> 2) Application argument change
>>>>>> 3) "vlan set " related changes
>>>>>>
>>>>>>>
>>>>>>> Signed-off-by: Vivek Sharma <viveksharma@marvell.com>
>>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Bernard
>>>>>
>>> In my opinion this patch was fine for the "port config all ..." style
>> commands.
>>
>> Duplication is bad, it is bad to have two different ways to do same thing.
>> I am not sure if Vivek is aware of duplicated functions but explicitly prefers to
>> update old versions.
>> I suggest lets stop improving these ones and get rid of them asap.
>
> Testpmd is widely used so removing commands without notice will probably not go down too well with the community.
We can make sure release notes is updated for removed commands and what is
replacing them, also can have same thing in the commit log, these can help user.
But I am dubious to follow deprecation process for testpmd commands.
>
>> Also as you can see commit log doesn't mention from "vlan set ..." changes at
>> all, that is why I asked for splitting this into 3 patches for 3 separate thing it
>> does.
>
> Ok, it should describe the "vlan set ...." changes.
>
>>> A separate patch set should be submitted for the new style setting offloads
>> commands.
>>>
>>> Regards,
>>>
>>> Bernard
>>>
>
> Regards,
>
> Bernard
>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v8 3/5] kni: add app specific mempool create & free routine
@ 2019-07-23 5:38 3% ` vattunuru
2019-07-23 10:50 0% ` Andrew Rybchenko
1 sibling, 1 reply; 200+ results
From: vattunuru @ 2019-07-23 5:38 UTC (permalink / raw)
To: dev
Cc: thomas, jerinj, olivier.matz, ferruh.yigit, anatoly.burakov,
arybchenko, kirankumark, Vamsi Attunuru
From: Vamsi Attunuru <vattunuru@marvell.com>
When KNI operates in IOVA = VA mode, it requires mbuf memory
to be physically contiguous to ensure KNI kernel module could
translate IOVA addresses properly. Patch adds a KNI specific
mempool create routine to populate the KNI packet mbuf pool
with memory objects that are being on a page.
KNI applications need to use this mempool create & free routines
so that mbuf related requirements in IOVA = VA mode are handled
inside those routines based on the enabled mode.
Updated the release notes with these new routine details.
Signed-off-by: Vamsi Attunuru <vattunuru@marvell.com>
Signed-off-by: Kiran Kumar K <kirankumark@marvell.com>
---
doc/guides/rel_notes/release_19_08.rst | 6 ++++
examples/kni/main.c | 6 +++-
lib/librte_kni/Makefile | 1 +
lib/librte_kni/meson.build | 1 +
lib/librte_kni/rte_kni.c | 59 ++++++++++++++++++++++++++++++++++
lib/librte_kni/rte_kni.h | 49 ++++++++++++++++++++++++++++
lib/librte_kni/rte_kni_version.map | 2 ++
7 files changed, 123 insertions(+), 1 deletion(-)
diff --git a/doc/guides/rel_notes/release_19_08.rst b/doc/guides/rel_notes/release_19_08.rst
index 0a3f840..bd01e99 100644
--- a/doc/guides/rel_notes/release_19_08.rst
+++ b/doc/guides/rel_notes/release_19_08.rst
@@ -281,6 +281,12 @@ API Changes
offload flag from the library. The application must set this flag if it is
supported by the platform and application wishes to use it.
+* kni: ``rte_kni_pktmbuf_pool_create`` ``rte_kni_pktmbuf_pool_free`` functions
+ were introduced for KNI applications for creating & freeing packet pool.
+ Since IOVA=VA mode was added in KNI, packet pool's mbuf memory should be
+ physically contiguous for the KNI kernel module to work in IOVA=VA mode,
+ this requirment was taken care in the kni packet pool creation fucntions.
+
ABI Changes
-----------
diff --git a/examples/kni/main.c b/examples/kni/main.c
index 4710d71..3b9c067 100644
--- a/examples/kni/main.c
+++ b/examples/kni/main.c
@@ -975,7 +975,7 @@ main(int argc, char** argv)
rte_exit(EXIT_FAILURE, "Could not parse input parameters\n");
/* Create the mbuf pool */
- pktmbuf_pool = rte_pktmbuf_pool_create("mbuf_pool", NB_MBUF,
+ pktmbuf_pool = rte_kni_pktmbuf_pool_create("mbuf_pool", NB_MBUF,
MEMPOOL_CACHE_SZ, 0, MBUF_DATA_SZ, rte_socket_id());
if (pktmbuf_pool == NULL) {
rte_exit(EXIT_FAILURE, "Could not initialise mbuf pool\n");
@@ -1043,6 +1043,10 @@ main(int argc, char** argv)
continue;
kni_free_kni(port);
}
+
+ if (pktmbuf_pool)
+ rte_kni_pktmbuf_pool_free(pktmbuf_pool);
+
for (i = 0; i < RTE_MAX_ETHPORTS; i++)
if (kni_port_params_array[i]) {
rte_free(kni_port_params_array[i]);
diff --git a/lib/librte_kni/Makefile b/lib/librte_kni/Makefile
index ab15d10..5e3dd01 100644
--- a/lib/librte_kni/Makefile
+++ b/lib/librte_kni/Makefile
@@ -6,6 +6,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
# library name
LIB = librte_kni.a
+CFLAGS += -DALLOW_EXPERIMENTAL_API
CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3 -fno-strict-aliasing
CFLAGS += -I$(RTE_SDK)/drivers/bus/pci
LDLIBS += -lrte_eal -lrte_mempool -lrte_mbuf -lrte_ethdev
diff --git a/lib/librte_kni/meson.build b/lib/librte_kni/meson.build
index fd46f87..e357445 100644
--- a/lib/librte_kni/meson.build
+++ b/lib/librte_kni/meson.build
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Intel Corporation
+allow_experimental_apis = true
if not is_linux or not dpdk_conf.get('RTE_ARCH_64')
build = false
reason = 'only supported on 64-bit linux'
diff --git a/lib/librte_kni/rte_kni.c b/lib/librte_kni/rte_kni.c
index ae17075..897a5bb 100644
--- a/lib/librte_kni/rte_kni.c
+++ b/lib/librte_kni/rte_kni.c
@@ -687,6 +687,65 @@ kni_allocate_mbufs(struct rte_kni *kni)
}
}
+struct rte_mempool *
+rte_kni_pktmbuf_pool_create(const char *name, unsigned int n,
+ unsigned int cache_size, uint16_t priv_size, uint16_t data_room_size,
+ int socket_id)
+{
+ struct rte_pktmbuf_pool_private mbp_priv;
+ const char *mp_ops_name;
+ struct rte_mempool *mp;
+ unsigned int elt_size;
+ int ret;
+
+ if (RTE_ALIGN(priv_size, RTE_MBUF_PRIV_ALIGN) != priv_size) {
+ RTE_LOG(ERR, MBUF, "mbuf priv_size=%u is not aligned\n",
+ priv_size);
+ rte_errno = EINVAL;
+ return NULL;
+ }
+ elt_size = sizeof(struct rte_mbuf) + (unsigned int)priv_size +
+ (unsigned int)data_room_size;
+ mbp_priv.mbuf_data_room_size = data_room_size;
+ mbp_priv.mbuf_priv_size = priv_size;
+
+ mp = rte_mempool_create_empty(name, n, elt_size, cache_size,
+ sizeof(struct rte_pktmbuf_pool_private), socket_id, 0);
+ if (mp == NULL)
+ return NULL;
+
+ mp_ops_name = rte_mbuf_best_mempool_ops();
+ ret = rte_mempool_set_ops_byname(mp, mp_ops_name, NULL);
+ if (ret != 0) {
+ RTE_LOG(ERR, MBUF, "error setting mempool handler\n");
+ rte_mempool_free(mp);
+ rte_errno = -ret;
+ return NULL;
+ }
+ rte_pktmbuf_pool_init(mp, &mbp_priv);
+
+ if (rte_eal_iova_mode() == RTE_IOVA_VA)
+ ret = rte_mempool_populate_from_pg_sz_chunks(mp);
+ else
+ ret = rte_mempool_populate_default(mp);
+
+ if (ret < 0) {
+ rte_mempool_free(mp);
+ rte_errno = -ret;
+ return NULL;
+ }
+
+ rte_mempool_obj_iter(mp, rte_pktmbuf_init, NULL);
+
+ return mp;
+}
+
+void
+rte_kni_pktmbuf_pool_free(struct rte_mempool *mp)
+{
+ rte_mempool_free(mp);
+}
+
struct rte_kni *
rte_kni_get(const char *name)
{
diff --git a/lib/librte_kni/rte_kni.h b/lib/librte_kni/rte_kni.h
index 5699a64..7f11927 100644
--- a/lib/librte_kni/rte_kni.h
+++ b/lib/librte_kni/rte_kni.h
@@ -20,6 +20,7 @@
#include <rte_pci.h>
#include <rte_memory.h>
#include <rte_mempool.h>
+#include <rte_mbuf_pool_ops.h>
#include <rte_ether.h>
#include <rte_kni_common.h>
@@ -184,6 +185,54 @@ unsigned rte_kni_tx_burst(struct rte_kni *kni, struct rte_mbuf **mbufs,
unsigned num);
/**
+ * Create a kni packet mbuf pool.
+ *
+ * This function creates and initializes a packet mbuf pool for KNI applications
+ * It calls the required mempool populate routine based on the IOVA mode.
+ *
+ * @param name
+ * The name of the mbuf pool.
+ * @param n
+ * The number of elements in the mbuf pool. The optimum size (in terms
+ * of memory usage) for a mempool is when n is a power of two minus one:
+ * n = (2^q - 1).
+ * @param cache_size
+ * Size of the per-core object cache. See rte_mempool_create() for
+ * details.
+ * @param priv_size
+ * Size of application private are between the rte_mbuf structure
+ * and the data buffer. This value must be aligned to RTE_MBUF_PRIV_ALIGN.
+ * @param data_room_size
+ * Size of data buffer in each mbuf, including RTE_PKTMBUF_HEADROOM.
+ * @param socket_id
+ * The socket identifier where the memory should be allocated. The
+ * value can be *SOCKET_ID_ANY* if there is no NUMA constraint for the
+ * reserved zone.
+ * @return
+ * The pointer to the new allocated mempool, on success. NULL on error
+ * with rte_errno set appropriately. Possible rte_errno values include:
+ * - E_RTE_NO_CONFIG - function could not get pointer to rte_config structure
+ * - E_RTE_SECONDARY - function was called from a secondary process instance
+ * - EINVAL - cache size provided is too large, or priv_size is not aligned.
+ * - ENOSPC - the maximum number of memzones has already been allocated
+ * - EEXIST - a memzone with the same name already exists
+ * - ENOMEM - no appropriate memory area found in which to create memzone
+ */
+__rte_experimental
+struct rte_mempool *rte_kni_pktmbuf_pool_create(const char *name,
+ unsigned int n, unsigned int cache_size, uint16_t priv_size,
+ uint16_t data_room_size, int socket_id);
+
+/**
+ * Free the given packet mempool.
+ *
+ * @param mp
+ * The mempool pointer.
+ */
+__rte_experimental
+void rte_kni_pktmbuf_pool_free(struct rte_mempool *mp);
+
+/**
* Get the KNI context of its name.
*
* @param name
diff --git a/lib/librte_kni/rte_kni_version.map b/lib/librte_kni/rte_kni_version.map
index c877dc6..aba9728 100644
--- a/lib/librte_kni/rte_kni_version.map
+++ b/lib/librte_kni/rte_kni_version.map
@@ -20,4 +20,6 @@ EXPERIMENTAL {
global:
rte_kni_update_link;
+ rte_kni_pktmbuf_pool_create;
+ rte_kni_pktmbuf_pool_free;
};
--
2.8.4
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [PATCH v7 1/3] eal/arm64: add 128-bit atomic compare exchange
` (3 preceding siblings ...)
2019-07-22 16:22 2% ` [dpdk-dev] [PATCH v6 " Phil Yang
@ 2019-07-23 5:57 2% ` Phil Yang
2019-07-23 7:05 2% ` [dpdk-dev] [PATCH v8 " jerinj
4 siblings, 1 reply; 200+ results
From: Phil Yang @ 2019-07-23 5:57 UTC (permalink / raw)
To: dev
Cc: thomas, jerinj, gage.eads, hemant.agrawal, Honnappa.Nagarahalli,
gavin.hu, nd
Add 128-bit atomic compare exchange on aarch64.
Suggested-by: Jerin Jacob <jerinj@marvell.com>
Signed-off-by: Phil Yang <phil.yang@arm.com>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Tested-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
---
v7:
1. Adjust code comment.
v6:
1. Put the RTE_ARM_FEATURE_ATOMICS flag into EAL group. (Jerin Jocob)
2. Keep rte_stack_lf_stubs.h doing nothing. (Gage Eads)
3. Fixed 32 bit build issue.
v5:
1. Enable RTE_ARM_FEATURE_ATOMICS on octeontx2 in default. (Jerin Jocob)
2. Record the reason of introducing "rte_stack_lf_stubs.h" in git commit.
(Jerin, Jocob)
3. Fixed a conditional MACRO error in rte_atomic128_cmp_exchange. (Jerin
Jocob)
v4:
1. Add RTE_ARM_FEATURE_ATOMICS flag to support LSE CASP instructions. (Jerin Jocob)
2. Fix possible arm64 ABI break by making casp_op_name noinline. (Jerin Jocob)
3. Add rte_stack_lf_stubs.h to reduce the ifdef clutter. (Gage Eads/Jerin Jocob)
v3:
1. Avoid duplication code with macro. (Jerin Jocob)
2. Make invalid memory order to strongest barrier. (Jerin Jocob)
3. Update doc/guides/prog_guide/env_abstraction_layer.rst. (Gage Eads)
4. Fix 32-bit x86 builds issue. (Gage Eads)
5. Correct documentation issues in UT. (Gage Eads)
v2:
Initial version.
config/arm/meson.build | 2 +
config/common_base | 3 +
config/defconfig_arm64-octeontx2-linuxapp-gcc | 1 +
config/defconfig_arm64-thunderx2-linuxapp-gcc | 1 +
.../common/include/arch/arm/rte_atomic_64.h | 162 +++++++++++++++++++++
.../common/include/arch/x86/rte_atomic_64.h | 12 --
lib/librte_eal/common/include/generic/rte_atomic.h | 17 ++-
7 files changed, 185 insertions(+), 13 deletions(-)
diff --git a/config/arm/meson.build b/config/arm/meson.build
index 979018e..9f28271 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -71,11 +71,13 @@ flags_thunderx2_extra = [
['RTE_CACHE_LINE_SIZE', 64],
['RTE_MAX_NUMA_NODES', 2],
['RTE_MAX_LCORE', 256],
+ ['RTE_ARM_FEATURE_ATOMICS', true],
['RTE_USE_C11_MEM_MODEL', true]]
flags_octeontx2_extra = [
['RTE_MACHINE', '"octeontx2"'],
['RTE_MAX_NUMA_NODES', 1],
['RTE_MAX_LCORE', 24],
+ ['RTE_ARM_FEATURE_ATOMICS', true],
['RTE_EAL_IGB_UIO', false],
['RTE_USE_C11_MEM_MODEL', true]]
diff --git a/config/common_base b/config/common_base
index 8ef75c2..2054480 100644
--- a/config/common_base
+++ b/config/common_base
@@ -82,6 +82,9 @@ CONFIG_RTE_MAX_LCORE=128
CONFIG_RTE_MAX_NUMA_NODES=8
CONFIG_RTE_MAX_HEAPS=32
CONFIG_RTE_MAX_MEMSEG_LISTS=64
+
+# Use ARM LSE ATOMIC instructions
+CONFIG_RTE_ARM_FEATURE_ATOMICS=n
# each memseg list will be limited to either RTE_MAX_MEMSEG_PER_LIST pages
# or RTE_MAX_MEM_MB_PER_LIST megabytes worth of memory, whichever is smaller
CONFIG_RTE_MAX_MEMSEG_PER_LIST=8192
diff --git a/config/defconfig_arm64-octeontx2-linuxapp-gcc b/config/defconfig_arm64-octeontx2-linuxapp-gcc
index f20da24..7687dbe 100644
--- a/config/defconfig_arm64-octeontx2-linuxapp-gcc
+++ b/config/defconfig_arm64-octeontx2-linuxapp-gcc
@@ -9,6 +9,7 @@ CONFIG_RTE_MACHINE="octeontx2"
CONFIG_RTE_CACHE_LINE_SIZE=128
CONFIG_RTE_MAX_NUMA_NODES=1
CONFIG_RTE_MAX_LCORE=24
+CONFIG_RTE_ARM_FEATURE_ATOMICS=y
# Doesn't support NUMA
CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=n
diff --git a/config/defconfig_arm64-thunderx2-linuxapp-gcc b/config/defconfig_arm64-thunderx2-linuxapp-gcc
index cc5c64b..af4a89c 100644
--- a/config/defconfig_arm64-thunderx2-linuxapp-gcc
+++ b/config/defconfig_arm64-thunderx2-linuxapp-gcc
@@ -9,3 +9,4 @@ CONFIG_RTE_MACHINE="thunderx2"
CONFIG_RTE_CACHE_LINE_SIZE=64
CONFIG_RTE_MAX_NUMA_NODES=2
CONFIG_RTE_MAX_LCORE=256
+CONFIG_RTE_ARM_FEATURE_ATOMICS=y
diff --git a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
index 97060e4..a040d69 100644
--- a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
+++ b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
@@ -1,5 +1,6 @@
/* SPDX-License-Identifier: BSD-3-Clause
* Copyright(c) 2015 Cavium, Inc
+ * Copyright(c) 2019 Arm Limited
*/
#ifndef _RTE_ATOMIC_ARM64_H_
@@ -14,6 +15,9 @@ extern "C" {
#endif
#include "generic/rte_atomic.h"
+#include <rte_branch_prediction.h>
+#include <rte_compat.h>
+#include <rte_debug.h>
#define dsb(opt) asm volatile("dsb " #opt : : : "memory")
#define dmb(opt) asm volatile("dmb " #opt : : : "memory")
@@ -40,6 +44,164 @@ extern "C" {
#define rte_cio_rmb() dmb(oshld)
+/*------------------------ 128 bit atomic operations -------------------------*/
+
+#define __HAS_ACQ(mo) ((mo) != __ATOMIC_RELAXED && (mo) != __ATOMIC_RELEASE)
+#define __HAS_RLS(mo) ((mo) == __ATOMIC_RELEASE || (mo) == __ATOMIC_ACQ_REL || \
+ (mo) == __ATOMIC_SEQ_CST)
+
+#define __MO_LOAD(mo) (__HAS_ACQ((mo)) ? __ATOMIC_ACQUIRE : __ATOMIC_RELAXED)
+#define __MO_STORE(mo) (__HAS_RLS((mo)) ? __ATOMIC_RELEASE : __ATOMIC_RELAXED)
+
+#if defined(__ARM_FEATURE_ATOMICS) || defined(RTE_ARM_FEATURE_ATOMICS)
+#define __ATOMIC128_CAS_OP(cas_op_name, op_string) \
+static __rte_noinline rte_int128_t \
+cas_op_name(rte_int128_t *dst, rte_int128_t old, \
+ rte_int128_t updated) \
+{ \
+ /* caspX instructions register pair must start from even-numbered
+ * register at operand 1.
+ * So, specify registers for local variables here.
+ */ \
+ register uint64_t x0 __asm("x0") = (uint64_t)old.val[0]; \
+ register uint64_t x1 __asm("x1") = (uint64_t)old.val[1]; \
+ register uint64_t x2 __asm("x2") = (uint64_t)updated.val[0]; \
+ register uint64_t x3 __asm("x3") = (uint64_t)updated.val[1]; \
+ asm volatile( \
+ op_string " %[old0], %[old1], %[upd0], %[upd1], [%[dst]]" \
+ : [old0] "+r" (x0), \
+ [old1] "+r" (x1) \
+ : [upd0] "r" (x2), \
+ [upd1] "r" (x3), \
+ [dst] "r" (dst) \
+ : "memory"); \
+ old.val[0] = x0; \
+ old.val[1] = x1; \
+ return old; \
+}
+
+__ATOMIC128_CAS_OP(__rte_cas_relaxed, "casp")
+__ATOMIC128_CAS_OP(__rte_cas_acquire, "caspa")
+__ATOMIC128_CAS_OP(__rte_cas_release, "caspl")
+__ATOMIC128_CAS_OP(__rte_cas_acq_rel, "caspal")
+#else
+#define __ATOMIC128_LDX_OP(ldx_op_name, op_string) \
+static inline rte_int128_t \
+ldx_op_name(const rte_int128_t *src) \
+{ \
+ rte_int128_t ret; \
+ asm volatile( \
+ op_string " %0, %1, %2" \
+ : "=&r" (ret.val[0]), \
+ "=&r" (ret.val[1]) \
+ : "Q" (src->val[0]) \
+ : "memory"); \
+ return ret; \
+}
+
+__ATOMIC128_LDX_OP(__rte_ldx_relaxed, "ldxp")
+__ATOMIC128_LDX_OP(__rte_ldx_acquire, "ldaxp")
+
+#define __ATOMIC128_STX_OP(stx_op_name, op_string) \
+static inline uint32_t \
+stx_op_name(rte_int128_t *dst, const rte_int128_t src) \
+{ \
+ uint32_t ret; \
+ asm volatile( \
+ op_string " %w0, %1, %2, %3" \
+ : "=&r" (ret) \
+ : "r" (src.val[0]), \
+ "r" (src.val[1]), \
+ "Q" (dst->val[0]) \
+ : "memory"); \
+ /* Return 0 on success, 1 on failure */ \
+ return ret; \
+}
+
+__ATOMIC128_STX_OP(__rte_stx_relaxed, "stxp")
+__ATOMIC128_STX_OP(__rte_stx_release, "stlxp")
+#endif
+
+static inline int __rte_experimental
+rte_atomic128_cmp_exchange(rte_int128_t *dst,
+ rte_int128_t *exp,
+ const rte_int128_t *src,
+ unsigned int weak,
+ int success,
+ int failure)
+{
+ /* Always do strong CAS */
+ RTE_SET_USED(weak);
+ /* Ignore memory ordering for failure, memory order for
+ * success must be stronger or equal
+ */
+ RTE_SET_USED(failure);
+ /* Find invalid memory order */
+ RTE_ASSERT(success == __ATOMIC_RELAXED
+ || success == __ATOMIC_ACQUIRE
+ || success == __ATOMIC_RELEASE
+ || success == __ATOMIC_ACQ_REL
+ || success == __ATOMIC_SEQ_CST);
+
+#if defined(__ARM_FEATURE_ATOMICS) || defined(RTE_ARM_FEATURE_ATOMICS)
+ rte_int128_t expected = *exp;
+ rte_int128_t desired = *src;
+ rte_int128_t old;
+
+ if (success == __ATOMIC_RELAXED)
+ old = __rte_cas_relaxed(dst, expected, desired);
+ else if (success == __ATOMIC_ACQUIRE)
+ old = __rte_cas_acquire(dst, expected, desired);
+ else if (success == __ATOMIC_RELEASE)
+ old = __rte_cas_release(dst, expected, desired);
+ else
+ old = __rte_cas_acq_rel(dst, expected, desired);
+#else
+ int ldx_mo = __MO_LOAD(success);
+ int stx_mo = __MO_STORE(success);
+ uint32_t ret = 1;
+ register rte_int128_t expected = *exp;
+ register rte_int128_t desired = *src;
+ register rte_int128_t old;
+
+ /* ldx128 can not guarantee atomic,
+ * Must write back src or old to verify atomicity of ldx128;
+ */
+ do {
+ if (ldx_mo == __ATOMIC_RELAXED)
+ old = __rte_ldx_relaxed(dst);
+ else
+ old = __rte_ldx_acquire(dst);
+
+ if (likely(old.int128 == expected.int128)) {
+ if (stx_mo == __ATOMIC_RELAXED)
+ ret = __rte_stx_relaxed(dst, desired);
+ else
+ ret = __rte_stx_release(dst, desired);
+ } else {
+ /* In the failure case (since 'weak' is ignored and only
+ * weak == 0 is implemented), expected should contain the
+ * atomically read value of dst. This means, 'old' needs
+ * to be stored back to ensure it was read atomically.
+ */
+ if (stx_mo == __ATOMIC_RELAXED)
+ ret = __rte_stx_relaxed(dst, old);
+ else
+ ret = __rte_stx_release(dst, old);
+ }
+ } while (unlikely(ret));
+#endif
+
+ /* Unconditionally updating expected removes
+ * an 'if' statement.
+ * expected should already be in register if
+ * not in the cache.
+ */
+ *exp = old;
+
+ return (old.int128 == expected.int128);
+}
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h b/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h
index e087c6c..1217129 100644
--- a/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h
+++ b/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h
@@ -212,18 +212,6 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
/*------------------------ 128 bit atomic operations -------------------------*/
-/**
- * 128-bit integer structure.
- */
-RTE_STD_C11
-typedef struct {
- RTE_STD_C11
- union {
- uint64_t val[2];
- __extension__ __int128 int128;
- };
-} __rte_aligned(16) rte_int128_t;
-
__rte_experimental
static inline int
rte_atomic128_cmp_exchange(rte_int128_t *dst,
diff --git a/lib/librte_eal/common/include/generic/rte_atomic.h b/lib/librte_eal/common/include/generic/rte_atomic.h
index 24ff7dc..e6ab15a 100644
--- a/lib/librte_eal/common/include/generic/rte_atomic.h
+++ b/lib/librte_eal/common/include/generic/rte_atomic.h
@@ -1081,6 +1081,20 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
/*------------------------ 128 bit atomic operations -------------------------*/
+/**
+ * 128-bit integer structure.
+ */
+RTE_STD_C11
+typedef struct {
+ RTE_STD_C11
+ union {
+ uint64_t val[2];
+#ifdef RTE_ARCH_64
+ __extension__ __int128 int128;
+#endif
+ };
+} __rte_aligned(16) rte_int128_t;
+
#ifdef __DOXYGEN__
/**
@@ -1093,7 +1107,8 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
* *exp = *dst
* @endcode
*
- * @note This function is currently only available for the x86-64 platform.
+ * @note This function is currently available for the x86-64 and aarch64
+ * platforms.
*
* @note The success and failure arguments must be one of the __ATOMIC_* values
* defined in the C++11 standard. For details on their behavior, refer to the
--
2.7.4
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH v8 1/3] eal/arm64: add 128-bit atomic compare exchange
2019-07-23 5:57 2% ` [dpdk-dev] [PATCH v7 " Phil Yang
@ 2019-07-23 7:05 2% ` jerinj
0 siblings, 0 replies; 200+ results
From: jerinj @ 2019-07-23 7:05 UTC (permalink / raw)
To: dev, Thomas Monjalon, Jerin Jacob, Gavin Hu, Jan Viktorin,
Bruce Richardson, Konstantin Ananyev
Cc: Phil Yang, Honnappa Nagarahalli
From: Phil Yang <phil.yang@arm.com>
Add 128-bit atomic compare exchange on aarch64.
Suggested-by: Jerin Jacob <jerinj@marvell.com>
Signed-off-by: Phil Yang <phil.yang@arm.com>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Tested-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
---
v8:
Fixed "WARNING:LONG_LINE: line over 80 characters" warnings with latest kernel
checkpatch.pl
v7:
1. Adjust code comment.
v6:
1. Put the RTE_ARM_FEATURE_ATOMICS flag into EAL group. (Jerin Jocob)
2. Keep rte_stack_lf_stubs.h doing nothing. (Gage Eads)
3. Fixed 32 bit build issue.
v5:
1. Enable RTE_ARM_FEATURE_ATOMICS on octeontx2 in default. (Jerin Jocob)
2. Record the reason of introducing "rte_stack_lf_stubs.h" in git
commit.
(Jerin, Jocob)
3. Fixed a conditional MACRO error in rte_atomic128_cmp_exchange. (Jerin
Jocob)
v4:
1. Add RTE_ARM_FEATURE_ATOMICS flag to support LSE CASP instructions.
(Jerin Jocob)
2. Fix possible arm64 ABI break by making casp_op_name noinline. (Jerin
Jocob)
3. Add rte_stack_lf_stubs.h to reduce the ifdef clutter. (Gage
Eads/Jerin Jocob)
v3:
1. Avoid duplication code with macro. (Jerin Jocob)
2. Make invalid memory order to strongest barrier. (Jerin Jocob)
3. Update doc/guides/prog_guide/env_abstraction_layer.rst. (Gage Eads)
4. Fix 32-bit x86 builds issue. (Gage Eads)
5. Correct documentation issues in UT. (Gage Eads)
v2:
Initial version.
config/arm/meson.build | 2 +
config/common_base | 3 +
config/defconfig_arm64-octeontx2-linuxapp-gcc | 1 +
config/defconfig_arm64-thunderx2-linuxapp-gcc | 1 +
.../common/include/arch/arm/rte_atomic_64.h | 163 ++++++++++++++++++
.../common/include/arch/x86/rte_atomic_64.h | 12 --
.../common/include/generic/rte_atomic.h | 17 +-
7 files changed, 186 insertions(+), 13 deletions(-)
diff --git a/config/arm/meson.build b/config/arm/meson.build
index 979018e16..9f2827140 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -71,11 +71,13 @@ flags_thunderx2_extra = [
['RTE_CACHE_LINE_SIZE', 64],
['RTE_MAX_NUMA_NODES', 2],
['RTE_MAX_LCORE', 256],
+ ['RTE_ARM_FEATURE_ATOMICS', true],
['RTE_USE_C11_MEM_MODEL', true]]
flags_octeontx2_extra = [
['RTE_MACHINE', '"octeontx2"'],
['RTE_MAX_NUMA_NODES', 1],
['RTE_MAX_LCORE', 24],
+ ['RTE_ARM_FEATURE_ATOMICS', true],
['RTE_EAL_IGB_UIO', false],
['RTE_USE_C11_MEM_MODEL', true]]
diff --git a/config/common_base b/config/common_base
index 8ef75c203..205448013 100644
--- a/config/common_base
+++ b/config/common_base
@@ -82,6 +82,9 @@ CONFIG_RTE_MAX_LCORE=128
CONFIG_RTE_MAX_NUMA_NODES=8
CONFIG_RTE_MAX_HEAPS=32
CONFIG_RTE_MAX_MEMSEG_LISTS=64
+
+# Use ARM LSE ATOMIC instructions
+CONFIG_RTE_ARM_FEATURE_ATOMICS=n
# each memseg list will be limited to either RTE_MAX_MEMSEG_PER_LIST pages
# or RTE_MAX_MEM_MB_PER_LIST megabytes worth of memory, whichever is smaller
CONFIG_RTE_MAX_MEMSEG_PER_LIST=8192
diff --git a/config/defconfig_arm64-octeontx2-linuxapp-gcc b/config/defconfig_arm64-octeontx2-linuxapp-gcc
index f20da2442..7687dbec8 100644
--- a/config/defconfig_arm64-octeontx2-linuxapp-gcc
+++ b/config/defconfig_arm64-octeontx2-linuxapp-gcc
@@ -9,6 +9,7 @@ CONFIG_RTE_MACHINE="octeontx2"
CONFIG_RTE_CACHE_LINE_SIZE=128
CONFIG_RTE_MAX_NUMA_NODES=1
CONFIG_RTE_MAX_LCORE=24
+CONFIG_RTE_ARM_FEATURE_ATOMICS=y
# Doesn't support NUMA
CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=n
diff --git a/config/defconfig_arm64-thunderx2-linuxapp-gcc b/config/defconfig_arm64-thunderx2-linuxapp-gcc
index cc5c64ba0..af4a89c48 100644
--- a/config/defconfig_arm64-thunderx2-linuxapp-gcc
+++ b/config/defconfig_arm64-thunderx2-linuxapp-gcc
@@ -9,3 +9,4 @@ CONFIG_RTE_MACHINE="thunderx2"
CONFIG_RTE_CACHE_LINE_SIZE=64
CONFIG_RTE_MAX_NUMA_NODES=2
CONFIG_RTE_MAX_LCORE=256
+CONFIG_RTE_ARM_FEATURE_ATOMICS=y
diff --git a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
index 97060e444..14d869bc9 100644
--- a/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
+++ b/lib/librte_eal/common/include/arch/arm/rte_atomic_64.h
@@ -1,5 +1,6 @@
/* SPDX-License-Identifier: BSD-3-Clause
* Copyright(c) 2015 Cavium, Inc
+ * Copyright(c) 2019 Arm Limited
*/
#ifndef _RTE_ATOMIC_ARM64_H_
@@ -14,6 +15,9 @@ extern "C" {
#endif
#include "generic/rte_atomic.h"
+#include <rte_branch_prediction.h>
+#include <rte_compat.h>
+#include <rte_debug.h>
#define dsb(opt) asm volatile("dsb " #opt : : : "memory")
#define dmb(opt) asm volatile("dmb " #opt : : : "memory")
@@ -40,6 +44,165 @@ extern "C" {
#define rte_cio_rmb() dmb(oshld)
+/*------------------------ 128 bit atomic operations -------------------------*/
+
+#define __HAS_ACQ(mo) ((mo) != __ATOMIC_RELAXED && (mo) != __ATOMIC_RELEASE)
+#define __HAS_RLS(mo) ((mo) == __ATOMIC_RELEASE || (mo) == __ATOMIC_ACQ_REL || \
+ (mo) == __ATOMIC_SEQ_CST)
+
+#define __MO_LOAD(mo) (__HAS_ACQ((mo)) ? __ATOMIC_ACQUIRE : __ATOMIC_RELAXED)
+#define __MO_STORE(mo) (__HAS_RLS((mo)) ? __ATOMIC_RELEASE : __ATOMIC_RELAXED)
+
+#if defined(__ARM_FEATURE_ATOMICS) || defined(RTE_ARM_FEATURE_ATOMICS)
+#define __ATOMIC128_CAS_OP(cas_op_name, op_string) \
+static __rte_noinline rte_int128_t \
+cas_op_name(rte_int128_t *dst, rte_int128_t old, \
+ rte_int128_t updated) \
+{ \
+ /* caspX instructions register pair must start from even-numbered
+ * register at operand 1.
+ * So, specify registers for local variables here.
+ */ \
+ register uint64_t x0 __asm("x0") = (uint64_t)old.val[0]; \
+ register uint64_t x1 __asm("x1") = (uint64_t)old.val[1]; \
+ register uint64_t x2 __asm("x2") = (uint64_t)updated.val[0]; \
+ register uint64_t x3 __asm("x3") = (uint64_t)updated.val[1]; \
+ asm volatile( \
+ op_string " %[old0], %[old1], %[upd0], %[upd1], [%[dst]]" \
+ : [old0] "+r" (x0), \
+ [old1] "+r" (x1) \
+ : [upd0] "r" (x2), \
+ [upd1] "r" (x3), \
+ [dst] "r" (dst) \
+ : "memory"); \
+ old.val[0] = x0; \
+ old.val[1] = x1; \
+ return old; \
+}
+
+__ATOMIC128_CAS_OP(__rte_cas_relaxed, "casp")
+__ATOMIC128_CAS_OP(__rte_cas_acquire, "caspa")
+__ATOMIC128_CAS_OP(__rte_cas_release, "caspl")
+__ATOMIC128_CAS_OP(__rte_cas_acq_rel, "caspal")
+#else
+#define __ATOMIC128_LDX_OP(ldx_op_name, op_string) \
+static inline rte_int128_t \
+ldx_op_name(const rte_int128_t *src) \
+{ \
+ rte_int128_t ret; \
+ asm volatile( \
+ op_string " %0, %1, %2" \
+ : "=&r" (ret.val[0]), \
+ "=&r" (ret.val[1]) \
+ : "Q" (src->val[0]) \
+ : "memory"); \
+ return ret; \
+}
+
+__ATOMIC128_LDX_OP(__rte_ldx_relaxed, "ldxp")
+__ATOMIC128_LDX_OP(__rte_ldx_acquire, "ldaxp")
+
+#define __ATOMIC128_STX_OP(stx_op_name, op_string) \
+static inline uint32_t \
+stx_op_name(rte_int128_t *dst, const rte_int128_t src) \
+{ \
+ uint32_t ret; \
+ asm volatile( \
+ op_string " %w0, %1, %2, %3" \
+ : "=&r" (ret) \
+ : "r" (src.val[0]), \
+ "r" (src.val[1]), \
+ "Q" (dst->val[0]) \
+ : "memory"); \
+ /* Return 0 on success, 1 on failure */ \
+ return ret; \
+}
+
+__ATOMIC128_STX_OP(__rte_stx_relaxed, "stxp")
+__ATOMIC128_STX_OP(__rte_stx_release, "stlxp")
+#endif
+
+static inline int __rte_experimental
+rte_atomic128_cmp_exchange(rte_int128_t *dst,
+ rte_int128_t *exp,
+ const rte_int128_t *src,
+ unsigned int weak,
+ int success,
+ int failure)
+{
+ /* Always do strong CAS */
+ RTE_SET_USED(weak);
+ /* Ignore memory ordering for failure, memory order for
+ * success must be stronger or equal
+ */
+ RTE_SET_USED(failure);
+ /* Find invalid memory order */
+ RTE_ASSERT(success == __ATOMIC_RELAXED
+ || success == __ATOMIC_ACQUIRE
+ || success == __ATOMIC_RELEASE
+ || success == __ATOMIC_ACQ_REL
+ || success == __ATOMIC_SEQ_CST);
+
+#if defined(__ARM_FEATURE_ATOMICS) || defined(RTE_ARM_FEATURE_ATOMICS)
+ rte_int128_t expected = *exp;
+ rte_int128_t desired = *src;
+ rte_int128_t old;
+
+ if (success == __ATOMIC_RELAXED)
+ old = __rte_cas_relaxed(dst, expected, desired);
+ else if (success == __ATOMIC_ACQUIRE)
+ old = __rte_cas_acquire(dst, expected, desired);
+ else if (success == __ATOMIC_RELEASE)
+ old = __rte_cas_release(dst, expected, desired);
+ else
+ old = __rte_cas_acq_rel(dst, expected, desired);
+#else
+ int ldx_mo = __MO_LOAD(success);
+ int stx_mo = __MO_STORE(success);
+ uint32_t ret = 1;
+ register rte_int128_t expected = *exp;
+ register rte_int128_t desired = *src;
+ register rte_int128_t old;
+
+ /* ldx128 can not guarantee atomic,
+ * Must write back src or old to verify atomicity of ldx128;
+ */
+ do {
+ if (ldx_mo == __ATOMIC_RELAXED)
+ old = __rte_ldx_relaxed(dst);
+ else
+ old = __rte_ldx_acquire(dst);
+
+ if (likely(old.int128 == expected.int128)) {
+ if (stx_mo == __ATOMIC_RELAXED)
+ ret = __rte_stx_relaxed(dst, desired);
+ else
+ ret = __rte_stx_release(dst, desired);
+ } else {
+ /* In the failure case (since 'weak' is ignored and only
+ * weak == 0 is implemented), expected should contain
+ * the atomically read value of dst. This means, 'old'
+ * needs to be stored back to ensure it was read
+ * atomically.
+ */
+ if (stx_mo == __ATOMIC_RELAXED)
+ ret = __rte_stx_relaxed(dst, old);
+ else
+ ret = __rte_stx_release(dst, old);
+ }
+ } while (unlikely(ret));
+#endif
+
+ /* Unconditionally updating expected removes
+ * an 'if' statement.
+ * expected should already be in register if
+ * not in the cache.
+ */
+ *exp = old;
+
+ return (old.int128 == expected.int128);
+}
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h b/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h
index e087c6c32..12171296b 100644
--- a/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h
+++ b/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h
@@ -212,18 +212,6 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
/*------------------------ 128 bit atomic operations -------------------------*/
-/**
- * 128-bit integer structure.
- */
-RTE_STD_C11
-typedef struct {
- RTE_STD_C11
- union {
- uint64_t val[2];
- __extension__ __int128 int128;
- };
-} __rte_aligned(16) rte_int128_t;
-
__rte_experimental
static inline int
rte_atomic128_cmp_exchange(rte_int128_t *dst,
diff --git a/lib/librte_eal/common/include/generic/rte_atomic.h b/lib/librte_eal/common/include/generic/rte_atomic.h
index 24ff7dcae..e6ab15a97 100644
--- a/lib/librte_eal/common/include/generic/rte_atomic.h
+++ b/lib/librte_eal/common/include/generic/rte_atomic.h
@@ -1081,6 +1081,20 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
/*------------------------ 128 bit atomic operations -------------------------*/
+/**
+ * 128-bit integer structure.
+ */
+RTE_STD_C11
+typedef struct {
+ RTE_STD_C11
+ union {
+ uint64_t val[2];
+#ifdef RTE_ARCH_64
+ __extension__ __int128 int128;
+#endif
+ };
+} __rte_aligned(16) rte_int128_t;
+
#ifdef __DOXYGEN__
/**
@@ -1093,7 +1107,8 @@ static inline void rte_atomic64_clear(rte_atomic64_t *v)
* *exp = *dst
* @endcode
*
- * @note This function is currently only available for the x86-64 platform.
+ * @note This function is currently available for the x86-64 and aarch64
+ * platforms.
*
* @note The success and failure arguments must be one of the __ATOMIC_* values
* defined in the C++11 standard. For details on their behavior, refer to the
--
2.22.0
^ permalink raw reply [relevance 2%]
* [dpdk-dev] [PATCH] ethdev: avoid usage of uninit device info in bad port case
@ 2019-07-23 9:13 3% Andrew Rybchenko
2019-07-23 10:40 0% ` Ferruh Yigit
2019-07-23 12:11 3% ` [dpdk-dev] [PATCH v2] " Andrew Rybchenko
0 siblings, 2 replies; 200+ results
From: Andrew Rybchenko @ 2019-07-23 9:13 UTC (permalink / raw)
To: Thomas Monjalon, Ferruh Yigit; +Cc: dev, stable
rte_eth_dev_info_get() returns void and caller does know if the function
does its job or not. Changing of the return value to int would be
API/ABI breakage which requires deprecation process and cannot be
backported to stable branches. For now, make sure that device info is
initialized even in the case of invalid port ID.
Fixes: a30268e9a2d0 ("ethdev: reset whole dev info structure before filling")
Cc: stable@dpdk.org
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
---
lib/librte_ethdev/rte_ethdev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 64191737c..97b093edc 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -2552,10 +2552,11 @@ rte_eth_dev_info_get(uint16_t port_id, struct rte_eth_dev_info *dev_info)
.nb_mtu_seg_max = UINT16_MAX,
};
+ memset(dev_info, 0, sizeof(struct rte_eth_dev_info));
+
RTE_ETH_VALID_PORTID_OR_RET(port_id);
dev = &rte_eth_devices[port_id];
- memset(dev_info, 0, sizeof(struct rte_eth_dev_info));
dev_info->rx_desc_lim = lim;
dev_info->tx_desc_lim = lim;
dev_info->device = dev->device;
--
2.17.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] ethdev: avoid usage of uninit device info in bad port case
2019-07-23 9:13 3% [dpdk-dev] [PATCH] ethdev: avoid usage of uninit device info in bad port case Andrew Rybchenko
@ 2019-07-23 10:40 0% ` Ferruh Yigit
2019-07-23 12:16 3% ` Andrew Rybchenko
2019-07-23 12:11 3% ` [dpdk-dev] [PATCH v2] " Andrew Rybchenko
1 sibling, 1 reply; 200+ results
From: Ferruh Yigit @ 2019-07-23 10:40 UTC (permalink / raw)
To: Andrew Rybchenko, Thomas Monjalon; +Cc: dev, stable
On 7/23/2019 10:13 AM, Andrew Rybchenko wrote:
> rte_eth_dev_info_get() returns void and caller does know if the function
> does its job or not. Changing of the return value to int would be
> API/ABI breakage which requires deprecation process and cannot be
> backported to stable branches. For now, make sure that device info is
> initialized even in the case of invalid port ID.
+1 to return a status from function for long term.
But someone looks below code can think we are doing an unnecessary memset for
the error case, and will fix it :)
What do you think adding a comment to prevent this?
>
> Fixes: a30268e9a2d0 ("ethdev: reset whole dev info structure before filling")
> Cc: stable@dpdk.org
>
> Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
> ---
> lib/librte_ethdev/rte_ethdev.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
> index 64191737c..97b093edc 100644
> --- a/lib/librte_ethdev/rte_ethdev.c
> +++ b/lib/librte_ethdev/rte_ethdev.c
> @@ -2552,10 +2552,11 @@ rte_eth_dev_info_get(uint16_t port_id, struct rte_eth_dev_info *dev_info)
> .nb_mtu_seg_max = UINT16_MAX,
> };
>
> + memset(dev_info, 0, sizeof(struct rte_eth_dev_info));
> +
> RTE_ETH_VALID_PORTID_OR_RET(port_id);
> dev = &rte_eth_devices[port_id];
>
> - memset(dev_info, 0, sizeof(struct rte_eth_dev_info));
> dev_info->rx_desc_lim = lim;
> dev_info->tx_desc_lim = lim;
> dev_info->device = dev->device;
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v8 3/5] kni: add app specific mempool create & free routine
2019-07-23 5:38 3% ` [dpdk-dev] [PATCH v8 3/5] kni: add app specific mempool create & free routine vattunuru
@ 2019-07-23 10:50 0% ` Andrew Rybchenko
2019-07-23 11:01 0% ` Vamsi Krishna Attunuru
0 siblings, 1 reply; 200+ results
From: Andrew Rybchenko @ 2019-07-23 10:50 UTC (permalink / raw)
To: vattunuru, dev
Cc: thomas, jerinj, olivier.matz, ferruh.yigit, anatoly.burakov, kirankumark
On 7/23/19 8:38 AM, vattunuru@marvell.com wrote:
> From: Vamsi Attunuru <vattunuru@marvell.com>
>
> When KNI operates in IOVA = VA mode, it requires mbuf memory
> to be physically contiguous to ensure KNI kernel module could
> translate IOVA addresses properly. Patch adds a KNI specific
> mempool create routine to populate the KNI packet mbuf pool
> with memory objects that are being on a page.
>
> KNI applications need to use this mempool create & free routines
> so that mbuf related requirements in IOVA = VA mode are handled
> inside those routines based on the enabled mode.
>
> Updated the release notes with these new routine details.
>
> Signed-off-by: Vamsi Attunuru <vattunuru@marvell.com>
> Signed-off-by: Kiran Kumar K <kirankumark@marvell.com>
> ---
> doc/guides/rel_notes/release_19_08.rst | 6 ++++
> examples/kni/main.c | 6 +++-
> lib/librte_kni/Makefile | 1 +
> lib/librte_kni/meson.build | 1 +
> lib/librte_kni/rte_kni.c | 59 ++++++++++++++++++++++++++++++++++
> lib/librte_kni/rte_kni.h | 49 ++++++++++++++++++++++++++++
> lib/librte_kni/rte_kni_version.map | 2 ++
> 7 files changed, 123 insertions(+), 1 deletion(-)
>
> diff --git a/doc/guides/rel_notes/release_19_08.rst b/doc/guides/rel_notes/release_19_08.rst
> index 0a3f840..bd01e99 100644
> --- a/doc/guides/rel_notes/release_19_08.rst
> +++ b/doc/guides/rel_notes/release_19_08.rst
> @@ -281,6 +281,12 @@ API Changes
> offload flag from the library. The application must set this flag if it is
> supported by the platform and application wishes to use it.
>
> +* kni: ``rte_kni_pktmbuf_pool_create`` ``rte_kni_pktmbuf_pool_free`` functions
> + were introduced for KNI applications for creating & freeing packet pool.
> + Since IOVA=VA mode was added in KNI, packet pool's mbuf memory should be
> + physically contiguous for the KNI kernel module to work in IOVA=VA mode,
> + this requirment was taken care in the kni packet pool creation fucntions.
> +
>
> ABI Changes
> -----------
> diff --git a/examples/kni/main.c b/examples/kni/main.c
> index 4710d71..3b9c067 100644
> --- a/examples/kni/main.c
> +++ b/examples/kni/main.c
> @@ -975,7 +975,7 @@ main(int argc, char** argv)
> rte_exit(EXIT_FAILURE, "Could not parse input parameters\n");
>
> /* Create the mbuf pool */
> - pktmbuf_pool = rte_pktmbuf_pool_create("mbuf_pool", NB_MBUF,
> + pktmbuf_pool = rte_kni_pktmbuf_pool_create("mbuf_pool", NB_MBUF,
> MEMPOOL_CACHE_SZ, 0, MBUF_DATA_SZ, rte_socket_id());
> if (pktmbuf_pool == NULL) {
> rte_exit(EXIT_FAILURE, "Could not initialise mbuf pool\n");
> @@ -1043,6 +1043,10 @@ main(int argc, char** argv)
> continue;
> kni_free_kni(port);
> }
> +
> + if (pktmbuf_pool)
Typically pointer is compared to NULL, but it is not required here
anyway, since rte_mempool_free() handles NULL perfectly itself.
> + rte_kni_pktmbuf_pool_free(pktmbuf_pool);
> +
> for (i = 0; i < RTE_MAX_ETHPORTS; i++)
> if (kni_port_params_array[i]) {
> rte_free(kni_port_params_array[i]);
<...>
> diff --git a/lib/librte_kni/rte_kni.h b/lib/librte_kni/rte_kni.h
> index 5699a64..7f11927 100644
> --- a/lib/librte_kni/rte_kni.h
> +++ b/lib/librte_kni/rte_kni.h
> @@ -20,6 +20,7 @@
> #include <rte_pci.h>
> #include <rte_memory.h>
> #include <rte_mempool.h>
> +#include <rte_mbuf_pool_ops.h>
I don't understand why it is included here.
> #include <rte_ether.h>
>
> #include <rte_kni_common.h>
>
<...>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v8 3/5] kni: add app specific mempool create & free routine
2019-07-23 10:50 0% ` Andrew Rybchenko
@ 2019-07-23 11:01 0% ` Vamsi Krishna Attunuru
0 siblings, 0 replies; 200+ results
From: Vamsi Krishna Attunuru @ 2019-07-23 11:01 UTC (permalink / raw)
To: Andrew Rybchenko, dev
Cc: thomas, Jerin Jacob Kollanukkaran, olivier.matz, ferruh.yigit,
anatoly.burakov, Kiran Kumar Kokkilagadda
> -----Original Message-----
> From: Andrew Rybchenko <arybchenko@solarflare.com>
> Sent: Tuesday, July 23, 2019 4:20 PM
> To: Vamsi Krishna Attunuru <vattunuru@marvell.com>; dev@dpdk.org
> Cc: thomas@monjalon.net; Jerin Jacob Kollanukkaran <jerinj@marvell.com>;
> olivier.matz@6wind.com; ferruh.yigit@intel.com; anatoly.burakov@intel.com;
> Kiran Kumar Kokkilagadda <kirankumark@marvell.com>
> Subject: Re: [dpdk-dev] [PATCH v8 3/5] kni: add app specific mempool create &
> free routine
>
> On 7/23/19 8:38 AM, vattunuru@marvell.com wrote:
> > From: Vamsi Attunuru <vattunuru@marvell.com>
> >
> > When KNI operates in IOVA = VA mode, it requires mbuf memory to be
> > physically contiguous to ensure KNI kernel module could translate IOVA
> > addresses properly. Patch adds a KNI specific mempool create routine
> > to populate the KNI packet mbuf pool with memory objects that are
> > being on a page.
> >
> > KNI applications need to use this mempool create & free routines so
> > that mbuf related requirements in IOVA = VA mode are handled inside
> > those routines based on the enabled mode.
> >
> > Updated the release notes with these new routine details.
> >
> > Signed-off-by: Vamsi Attunuru <vattunuru@marvell.com>
> > Signed-off-by: Kiran Kumar K <kirankumark@marvell.com>
> > ---
> > doc/guides/rel_notes/release_19_08.rst | 6 ++++
> > examples/kni/main.c | 6 +++-
> > lib/librte_kni/Makefile | 1 +
> > lib/librte_kni/meson.build | 1 +
> > lib/librte_kni/rte_kni.c | 59 ++++++++++++++++++++++++++++++++++
> > lib/librte_kni/rte_kni.h | 49 ++++++++++++++++++++++++++++
> > lib/librte_kni/rte_kni_version.map | 2 ++
> > 7 files changed, 123 insertions(+), 1 deletion(-)
> >
> > diff --git a/doc/guides/rel_notes/release_19_08.rst
> > b/doc/guides/rel_notes/release_19_08.rst
> > index 0a3f840..bd01e99 100644
> > --- a/doc/guides/rel_notes/release_19_08.rst
> > +++ b/doc/guides/rel_notes/release_19_08.rst
> > @@ -281,6 +281,12 @@ API Changes
> > offload flag from the library. The application must set this flag if it is
> > supported by the platform and application wishes to use it.
> >
> > +* kni: ``rte_kni_pktmbuf_pool_create`` ``rte_kni_pktmbuf_pool_free``
> > +functions
> > + were introduced for KNI applications for creating & freeing packet pool.
> > + Since IOVA=VA mode was added in KNI, packet pool's mbuf memory
> > +should be
> > + physically contiguous for the KNI kernel module to work in IOVA=VA
> > +mode,
> > + this requirment was taken care in the kni packet pool creation fucntions.
> > +
> >
> > ABI Changes
> > -----------
> > diff --git a/examples/kni/main.c b/examples/kni/main.c index
> > 4710d71..3b9c067 100644
> > --- a/examples/kni/main.c
> > +++ b/examples/kni/main.c
> > @@ -975,7 +975,7 @@ main(int argc, char** argv)
> > rte_exit(EXIT_FAILURE, "Could not parse input parameters\n");
> >
> > /* Create the mbuf pool */
> > - pktmbuf_pool = rte_pktmbuf_pool_create("mbuf_pool", NB_MBUF,
> > + pktmbuf_pool = rte_kni_pktmbuf_pool_create("mbuf_pool", NB_MBUF,
> > MEMPOOL_CACHE_SZ, 0, MBUF_DATA_SZ, rte_socket_id());
> > if (pktmbuf_pool == NULL) {
> > rte_exit(EXIT_FAILURE, "Could not initialise mbuf pool\n"); @@
> > -1043,6 +1043,10 @@ main(int argc, char** argv)
> > continue;
> > kni_free_kni(port);
> > }
> > +
> > + if (pktmbuf_pool)
>
> Typically pointer is compared to NULL, but it is not required here anyway, since
> rte_mempool_free() handles NULL perfectly itself.
Ack
>
> > + rte_kni_pktmbuf_pool_free(pktmbuf_pool);
> > +
> > for (i = 0; i < RTE_MAX_ETHPORTS; i++)
> > if (kni_port_params_array[i]) {
> > rte_free(kni_port_params_array[i]);
>
> <...>
>
> > diff --git a/lib/librte_kni/rte_kni.h b/lib/librte_kni/rte_kni.h index
> > 5699a64..7f11927 100644
> > --- a/lib/librte_kni/rte_kni.h
> > +++ b/lib/librte_kni/rte_kni.h
> > @@ -20,6 +20,7 @@
> > #include <rte_pci.h>
> > #include <rte_memory.h>
> > #include <rte_mempool.h>
> > +#include <rte_mbuf_pool_ops.h>
>
> I don't understand why it is included here.
>
included to fix compilation of rte_kni.c post this patch changes, could be included in rte_kni.c though.
> > #include <rte_ether.h>
> >
> > #include <rte_kni_common.h>
> >
>
> <...>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v2] ethdev: avoid usage of uninit device info in bad port case
2019-07-23 9:13 3% [dpdk-dev] [PATCH] ethdev: avoid usage of uninit device info in bad port case Andrew Rybchenko
2019-07-23 10:40 0% ` Ferruh Yigit
@ 2019-07-23 12:11 3% ` Andrew Rybchenko
2019-07-23 13:14 0% ` Thomas Monjalon
1 sibling, 1 reply; 200+ results
From: Andrew Rybchenko @ 2019-07-23 12:11 UTC (permalink / raw)
To: Thomas Monjalon, Ferruh Yigit; +Cc: dev, stable
rte_eth_dev_info_get() returns void and caller does know if the function
does its job or not. Changing of the return value to int would be
API/ABI breakage which requires deprecation process and cannot be
backported to stable branches. For now, make sure that device info is
initialized even in the case of invalid port ID.
Fixes: a30268e9a2d0 ("ethdev: reset whole dev info structure before filling")
Cc: stable@dpdk.org
Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
---
lib/librte_ethdev/rte_ethdev.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 64191737c..17d183e1f 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -2552,10 +2552,15 @@ rte_eth_dev_info_get(uint16_t port_id, struct rte_eth_dev_info *dev_info)
.nb_mtu_seg_max = UINT16_MAX,
};
+ /*
+ * Init dev_info before port_id check since caller does not have
+ * return status and does not know if get is successful or not.
+ */
+ memset(dev_info, 0, sizeof(struct rte_eth_dev_info));
+
RTE_ETH_VALID_PORTID_OR_RET(port_id);
dev = &rte_eth_devices[port_id];
- memset(dev_info, 0, sizeof(struct rte_eth_dev_info));
dev_info->rx_desc_lim = lim;
dev_info->tx_desc_lim = lim;
dev_info->device = dev->device;
--
2.17.1
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] ethdev: avoid usage of uninit device info in bad port case
2019-07-23 10:40 0% ` Ferruh Yigit
@ 2019-07-23 12:16 3% ` Andrew Rybchenko
2019-07-23 12:50 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Andrew Rybchenko @ 2019-07-23 12:16 UTC (permalink / raw)
To: Ferruh Yigit, Thomas Monjalon; +Cc: dev, stable
On 7/23/19 1:40 PM, Ferruh Yigit wrote:
> On 7/23/2019 10:13 AM, Andrew Rybchenko wrote:
>> rte_eth_dev_info_get() returns void and caller does know if the function
>> does its job or not. Changing of the return value to int would be
>> API/ABI breakage which requires deprecation process and cannot be
>> backported to stable branches. For now, make sure that device info is
>> initialized even in the case of invalid port ID.
> +1 to return a status from function for long term.
Thomas, what do you think? Should we finally fix it?
I think it is almost harmless API/ABI breakage.
If yes, I'll send deprecation notice to do it in v19.11.
> But someone looks below code can think we are doing an unnecessary memset for
> the error case, and will fix it :)
> What do you think adding a comment to prevent this?
See v2.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH] ethdev: avoid usage of uninit device info in bad port case
2019-07-23 12:16 3% ` Andrew Rybchenko
@ 2019-07-23 12:50 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-07-23 12:50 UTC (permalink / raw)
To: Andrew Rybchenko; +Cc: Ferruh Yigit, dev, stable
23/07/2019 14:16, Andrew Rybchenko:
> On 7/23/19 1:40 PM, Ferruh Yigit wrote:
> > On 7/23/2019 10:13 AM, Andrew Rybchenko wrote:
> >> rte_eth_dev_info_get() returns void and caller does know if the function
> >> does its job or not. Changing of the return value to int would be
> >> API/ABI breakage which requires deprecation process and cannot be
> >> backported to stable branches. For now, make sure that device info is
> >> initialized even in the case of invalid port ID.
> > +1 to return a status from function for long term.
>
> Thomas, what do you think? Should we finally fix it?
> I think it is almost harmless API/ABI breakage.
> If yes, I'll send deprecation notice to do it in v19.11.
Yes, generally speaking we should not have any void return in API.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] ethdev: avoid usage of uninit device info in bad port case
2019-07-23 12:11 3% ` [dpdk-dev] [PATCH v2] " Andrew Rybchenko
@ 2019-07-23 13:14 0% ` Thomas Monjalon
2019-07-23 13:34 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-07-23 13:14 UTC (permalink / raw)
To: Andrew Rybchenko; +Cc: dev, Ferruh Yigit, stable
23/07/2019 14:11, Andrew Rybchenko:
> rte_eth_dev_info_get() returns void and caller does know if the function
> does its job or not. Changing of the return value to int would be
> API/ABI breakage which requires deprecation process and cannot be
> backported to stable branches. For now, make sure that device info is
> initialized even in the case of invalid port ID.
>
> Fixes: a30268e9a2d0 ("ethdev: reset whole dev info structure before filling")
> Cc: stable@dpdk.org
>
> Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
> ---
> --- a/lib/librte_ethdev/rte_ethdev.c
> +++ b/lib/librte_ethdev/rte_ethdev.c
> + /*
> + * Init dev_info before port_id check since caller does not have
> + * return status and does not know if get is successful or not.
> + */
> + memset(dev_info, 0, sizeof(struct rte_eth_dev_info));
If someone was using a canary to detect failure, it will be resetted.
Why is it urgent to have this workaround?
Can we wait one more release for the definitive fix with error code?
> +
> RTE_ETH_VALID_PORTID_OR_RET(port_id);
> dev = &rte_eth_devices[port_id];
>
> - memset(dev_info, 0, sizeof(struct rte_eth_dev_info));
> dev_info->rx_desc_lim = lim;
> dev_info->tx_desc_lim = lim;
> dev_info->device = dev->device;
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] ethdev: avoid usage of uninit device info in bad port case
2019-07-23 13:14 0% ` Thomas Monjalon
@ 2019-07-23 13:34 0% ` Andrew Rybchenko
2019-07-23 13:39 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Andrew Rybchenko @ 2019-07-23 13:34 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Ferruh Yigit, stable
On 7/23/19 4:14 PM, Thomas Monjalon wrote:
> 23/07/2019 14:11, Andrew Rybchenko:
>> rte_eth_dev_info_get() returns void and caller does know if the function
>> does its job or not. Changing of the return value to int would be
>> API/ABI breakage which requires deprecation process and cannot be
>> backported to stable branches. For now, make sure that device info is
>> initialized even in the case of invalid port ID.
>>
>> Fixes: a30268e9a2d0 ("ethdev: reset whole dev info structure before filling")
>> Cc: stable@dpdk.org
>>
>> Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
>> ---
>> --- a/lib/librte_ethdev/rte_ethdev.c
>> +++ b/lib/librte_ethdev/rte_ethdev.c
>> + /*
>> + * Init dev_info before port_id check since caller does not have
>> + * return status and does not know if get is successful or not.
>> + */
>> + memset(dev_info, 0, sizeof(struct rte_eth_dev_info));
> If someone was using a canary to detect failure, it will be resetted.
I've not thought about such ways to check. I would expected check
for not NULL device or driver_name. It is not defined behaviour of
the function to not touch dev_info in the case of bad port ID.
> Why is it urgent to have this workaround?
Nothing really urgent, but I still think that it is a right fix to be
applied and backported to stable branches.
I really met calls with invalid port ID and it took some time
to understand where uninitialized data come from.
> Can we wait one more release for the definitive fix with error code?
No strong opinion, but definitive fix will not be backported.
>> +
>> RTE_ETH_VALID_PORTID_OR_RET(port_id);
>> dev = &rte_eth_devices[port_id];
>>
>> - memset(dev_info, 0, sizeof(struct rte_eth_dev_info));
>> dev_info->rx_desc_lim = lim;
>> dev_info->tx_desc_lim = lim;
>> dev_info->device = dev->device;
>>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] ethdev: avoid usage of uninit device info in bad port case
2019-07-23 13:34 0% ` Andrew Rybchenko
@ 2019-07-23 13:39 0% ` Thomas Monjalon
2019-07-23 18:45 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-07-23 13:39 UTC (permalink / raw)
To: Andrew Rybchenko; +Cc: dev, Ferruh Yigit, stable
23/07/2019 15:34, Andrew Rybchenko:
> On 7/23/19 4:14 PM, Thomas Monjalon wrote:
> > 23/07/2019 14:11, Andrew Rybchenko:
> >> rte_eth_dev_info_get() returns void and caller does know if the function
> >> does its job or not. Changing of the return value to int would be
> >> API/ABI breakage which requires deprecation process and cannot be
> >> backported to stable branches. For now, make sure that device info is
> >> initialized even in the case of invalid port ID.
> >>
> >> Fixes: a30268e9a2d0 ("ethdev: reset whole dev info structure before filling")
> >> Cc: stable@dpdk.org
> >>
> >> Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
> >> ---
> >> --- a/lib/librte_ethdev/rte_ethdev.c
> >> +++ b/lib/librte_ethdev/rte_ethdev.c
> >> + /*
> >> + * Init dev_info before port_id check since caller does not have
> >> + * return status and does not know if get is successful or not.
> >> + */
> >> + memset(dev_info, 0, sizeof(struct rte_eth_dev_info));
> > If someone was using a canary to detect failure, it will be resetted.
>
> I've not thought about such ways to check. I would expected check
> for not NULL device or driver_name. It is not defined behaviour of
> the function to not touch dev_info in the case of bad port ID.
>
> > Why is it urgent to have this workaround?
>
> Nothing really urgent, but I still think that it is a right fix to be
> applied and backported to stable branches.
> I really met calls with invalid port ID and it took some time
> to understand where uninitialized data come from.
>
> > Can we wait one more release for the definitive fix with error code?
>
> No strong opinion, but definitive fix will not be backported.
You're right.
Acked-by: Thomas Monjalon <thomas@monjalon.net>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2] ethdev: avoid usage of uninit device info in bad port case
2019-07-23 13:39 0% ` Thomas Monjalon
@ 2019-07-23 18:45 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-07-23 18:45 UTC (permalink / raw)
To: Andrew Rybchenko; +Cc: dev, Ferruh Yigit, stable
23/07/2019 15:39, Thomas Monjalon:
> 23/07/2019 15:34, Andrew Rybchenko:
> > On 7/23/19 4:14 PM, Thomas Monjalon wrote:
> > > 23/07/2019 14:11, Andrew Rybchenko:
> > >> rte_eth_dev_info_get() returns void and caller does know if the function
> > >> does its job or not. Changing of the return value to int would be
> > >> API/ABI breakage which requires deprecation process and cannot be
> > >> backported to stable branches. For now, make sure that device info is
> > >> initialized even in the case of invalid port ID.
> > >>
> > >> Fixes: a30268e9a2d0 ("ethdev: reset whole dev info structure before filling")
> > >> Cc: stable@dpdk.org
> > >>
> > >> Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
>
> Acked-by: Thomas Monjalon <thomas@monjalon.net>
Applied, thanks
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] pci: fix missing pci bus with shared library build
@ 2019-07-24 8:56 3% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2019-07-24 8:56 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Thomas Monjalon, dev
On Tue, Jul 23, 2019 at 11:11:14AM -0700, Stephen Hemminger wrote:
> On Tue, 23 Jul 2019 13:30:33 +0100
> Bruce Richardson <bruce.richardson@intel.com> wrote:
>
> > On Mon, Jul 22, 2019 at 11:53:26AM -0700, Stephen Hemminger wrote:
> > > On Mon, 22 Jul 2019 19:31:08 +0200
> > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > >
> > > > 22/07/2019 19:13, Stephen Hemminger:
> > > > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > > > > > Are the constructors run on dlopen of the bus driver?
> > > > >
> > > > > Yes, constructors are run on dlopen.
> > > > > But application should not have to ask DPDK to dlopen the bus devices.
> > > > >
> > > > > The core principle is that dynamic build of DPDK should act the same as old
> > > > > statically linked DPDK. Otherwise, the user experience is even worse, and all
> > > > > the example documentation is wrong.
> > > >
> > > > OK, this is where I wanted to bring the discussion.
> > > > You are arguing against a design which is in DPDK from some early days.
> > > > So this is an interesting discussion to have.
> > > > Do we want to change the "plugin model" we have?
> > > > Or do we want to simply drop this model (dlopen calls)
> > > > and replace it with strong dynamic linking?
> > > >
> > > >
> > >
> > > What I think should happen (and isn't is):
> > >
> > > 1. The PCI bus library is linked with --whole-archive, and --no-as-needed.
> > > This causes constructor to be called and register the bus.
> > >
> >
> > This should be applied to the whole of the bus drivers, not just the PCI
> > bus.
> >
> > > 2. As part of the build process all the PCI drivers pmdinfo would get
> > > constructed into a table of vendor/device to PMD shared library name.
> > >
> > > 3. PMD's are linked as --whole-archive, and --as-needed.
> > >
> >
> > I'm not sure I agree with this change to always link in all the PMDs. It
> > prevents an app from being used with just a subset of the drivers needed.
> >
> > > 4. New code in PCI probe which looks for existing entries (static or -d)
> > > for devices. If device is still not found it refers to the table of PMD's
> > > (from #2) and calls dlopen for that device (and adds it to static table).
> > >
> > > This would allow examples and customer applications to Just Work without
> > > having to know the PMD that is present. It would also solve the problem
> > > that currently if applications is linked with -ldpdk linker script then
> > > all PMD's get pulled into the application address space.
> > >
> >
> > In all this you seem to be assuming that the drivers are not picked up at
> > runtime from the RTE_EAL_PMD_PATH. In real world cases where a user is
> > building an app, and not developing DPDK itself, the DPDK libraries should
> > be installed in /usr(/local)/lib64 and the drivers in
> > .../lib64/dpdk/dpdk-19.08. In that case, the bus drivers and the PMD
> > drivers are all loaded at runtime for each app, without having any
> > dependency on having a specific one be present, allowing a user to remove
> > any drivers unnecessary for the current hardware.
> >
> > Did you try installing DPDK using "ninja install" or "make install" before
> > running any apps using it?
> >
> > /Bruce
>
> I was using "make install-runtime" into a local chroot directory like
> a distribution package builder does.
>
>
> There are multiple use cases:
> 1. Developer build DPDK and application together on one machine (and running on another).
> Or software appliance being built on one machine and run in many environments.
> Also cross builds are like this.
>
Sure, but the expectation here is that the resultant build is installed in
system locations, or a known location. As part of the build EAL_PMD_PATH
needs to be set to the final driver location and then the driver loading
issue requiring "-d" flag goes away.
> 2. Distribution building a package (and installing in standard library locations /lib etc).
>
No issue here, since package building is not going to be a problem and when
installed the drivers are all picked up from the EAL_PMD_PATH.
> 3. Demo machine where build is local and native.
>
> DPDK seems to always focus on #3 which is least interesting for real production.
You are missing our primary target use-case for the future -
* developer builds application using distro-supplied DPDK.
Individual developers building their own DPDK alongside their app should be
a thing of the past. DPDK needs to be come like other libraries e.g. zlib,
openssl, where app developers just pick it up from their linux distro and
not feel the need to roll their own.
Yes, there will be cases where things are more memory constrained etc. and
this model won't work, but despite this, it should be our primary target.
To get there, though, there is still work to be done, e.g. in increasing
ABI compatibility to allow easier adoption by distros, etc.
/Bruce
^ permalink raw reply [relevance 3%]
* [dpdk-dev] [dpdk-announce] You're Invited: DPDK Userspace, Sept. 19-20, Bordeaux, France
@ 2019-07-24 22:22 4% Jill Lovato
0 siblings, 0 replies; 200+ results
From: Jill Lovato @ 2019-07-24 22:22 UTC (permalink / raw)
To: announce
DPDK Community,
We invite you to attend the upcoming DPDK Userspace
<https://events.linuxfoundation.org/events/dpdk-userspace-2019-bordeaux/>
event, happening September 19-20 in Bordeaux, France.
DPDK Userspace, the community’s flagship event which brings together users
and developers, is going on the road and headed to in Bordeaux, France.
This year’s agenda will focus on 4 topics:
- new APIs (mbuf, Ethernet, IPsec, regex, DMA, PRNG)
- algorithms (performance, lock-free, virtio failover, QoS)
- use cases (storage, NFV, Docker, Kubernetes, Alibaba)
- community process (CI, tooling, ABI stability)
Join us in France to learn about the future of data plane acceleration.
More details are included below, including the event agenda and how to
register.
AGENDA:
https://events.linuxfoundation.org/events/dpdk-userspace-2019-bordeaux/program/schedule/
SEPTEMBER 19
08:00: Registration
09:00: Introduction
09:30: Dynamic mbuf - Thomas Monjalon, Mellanox
10:00: Which Standard for Ethernet Statistics? - Thomas Monjalon, Mellanox
10:30: MORNING BREAK
10:45: Recent Advances in DPDK IPSec - Konastantin Ananiev, Intel
11:15: DPDK Regex Device - Shahaf Shuler, Mellanox
11:45: Adding Eventdev support in IP-secgw and other apps - Hemant Agrawal,
NXP
12:00: Accelerating Memory Copy with the DMA Copy Library - Jiayu Hu, Intel
12:30: LUNCH
13:45: DPDK Thread-Safe High Performance Pseudo-Random Number Generation -
Mattias Rooblom, Ericsson
14:15: Better Development with Robots - Aaron Conole, RedHat
14:30: DPDK Community Updates - John McNamara, Intel
15:00 Community Survey Analysis and Conclusion - Honnappa Nagarahalli, Arm
15:15: DPD.org Services, Latest and Future Planned Improvements - Ali
Alnubani, Mellanox
15:45: AFTERNOON BREAK
16:15: Introduction to the New DPDK Vulnerabilities Management Process -
Maxime Coquelin
16:30: DPDK LTS Update - Kevin Traynor, RedHat
17:00 Does DPDK Need a Stable ABI? - Stephen Hemminger, Microsoft & Ray
Kinsells, Intel
18:00: COCKTAIL RECEPTION
SEPTEMBER 20
9:00: Integrating RCU Library with Data Structures - Honnappa Nagarahalli,
Arm
9:30: Current Sorry State of c11 Code and Suggestions for Fix It - Phil
Yang, Arm
10:00 Arm64 WFE Mechanism and Use Cases in DPDK - Gavin Hu, Arm
10:30 : MORNING BREAK
11:00 DPDK Build System Status and Plans - Bruce Richardson, Intel
11:15: What is Wrong with Existing Packet Capture (and How to Fix It) -
Stephen Hemminger, Microsoft
11:30: Virtion-net Failover in DPDK - Jen Freimann, RedHat
12:00: DPDK-Accelerated Partial Offload for Fine-Grained HQoS - Rosen Xu,
Intel
12:30 LUNCH
14:00 Higher Guaranteed Performance for DPDK Threads via New Power Library
Changes - David Hunt, Intel
14:30: Measure Software Performance of Data Plane Applications - Harry van
Haaren, Intel
15:00: rte Flow at Large-Scale in Production is Really Happening - Alex
Rosenabum, Mellanox
15:30: AFTERNOON BREAK
16:00 DPDK Expands Into Storage Domain - Darek Stojaczyk & Fiona Trahe,
Intel
16:30: Docker VNFs and Packet Throughput Using Lib 1 Net and DPDK - Anthony
Fee, Emutex
16:45: State of DPDK in Network Service Mesh - Frederick Kautz, Doc.ai
17:00: Conclusion
17:30: Permanent Exhibition Tour at La Cite du Vin
REGISTER TODAY
DPDK Userspace 2019 is complimentary to attend. To register, visit this link
<https://www.cvent.com/events/dpdk-userspace-2019-bordeaux/registration-2399e1cbffd14eb9bb834f307925522a.aspx?_ga=2.125206282.1212887052.1563230168-1943177193.1548103697&fqp=true>
.
Please send any questions to events@dpdk.org and we hope to see many of you
in Bordeaux!
--
*Jill Lovato*
Senior PR Manager
The Linux Foundation
jlovato@linuxfoundation.org
Phone: +1.503.703.8268
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] eal: resort symbols in EXPERIMENTAL section
@ 2019-07-26 13:54 0% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2019-07-26 13:54 UTC (permalink / raw)
To: Ferruh Yigit, Thomas Monjalon; +Cc: Stephen Hemminger, dev
On Thu, Jun 20, 2019 at 7:23 PM David Marchand
<david.marchand@redhat.com> wrote:
>
>
>
> On Fri, Jun 14, 2019 at 5:32 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
>>
>> On 6/14/2019 8:44 AM, David Marchand wrote:
>> > On Fri, Jun 14, 2019 at 9:39 AM Thomas Monjalon <thomas@monjalon.net> wrote:
>> >
>> >> 06/04/2019 05:30, Stephen Hemminger:
>> >>> The symbols in the EXPERIMENTAL were close to alphabetic
>> >>> order but running sort showed several mistakes.
>> >>>
>> >>> This has no impact on code, API, ABI or otherwise.
>> >>> Purely for humans.
>> >>>
>> >>> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>> >>
>> >> I don't think it's worth adding a layer of git history for this sort.
>> >> I would prefer to leave it as is.
>> >>
>> >>
>> > If this is about preferrence, I would prefer we have those symbols sorted
>> > per versions that introduced them ;-).
>> > Much easier to check and see if they are candidates for entering stable ABI.
>> >
>>
>> Not bad idea, +1 from my side J
>
>
> Here is what it looks like:
> https://github.com/david-marchand/dpdk/commit/cab0d75ea6bdc7782566d7aad6718b9f5fa784f7
Sent the patch rebased on master.
https://patchwork.dpdk.org/patch/57172/
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3] devtools: better freebsd support
2019-07-11 14:25 6% ` [dpdk-dev] [PATCH v3] " Olivier Matz
@ 2019-07-29 8:31 0% ` David Marchand
2019-07-29 8:36 0% ` David Marchand
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2019-07-29 8:31 UTC (permalink / raw)
To: Olivier Matz; +Cc: dev, Thomas Monjalon, Bruce Richardson, Flavia
On Thu, Jul 11, 2019 at 4:25 PM Olivier Matz <olivier.matz@6wind.com> wrote:
>
> - As "readlink -e" and "readlink -m" do not exist on freebsd,
> use "readlink -f", it should not have any impact in these cases.
> - "sed -ri" is invalid on freebsd and should be replaced by
> "sed -ri=''"
> - Use gmake instead of make.
>
> This fixes the following command:
> SYSDIR=/usr/src/sys ./devtools/test-build.sh \
> -j4 x86_64-native-freebsd-gcc
>
> Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
> ---
>
> v3:
> - fix examples installation path, pointed-out by Flavia
>
> v2:
> - remove sed_ri() function and use 'sed -ri=""' as suggested by Bruce
>
> devtools/check-dup-includes.sh | 2 +-
> devtools/checkpatches.sh | 8 ++--
> devtools/get-maintainer.sh | 2 +-
> devtools/load-devel-config | 4 +-
> devtools/test-build.sh | 94 ++++++++++++++++++++++--------------------
> devtools/validate-abi.sh | 2 +-
> 6 files changed, 58 insertions(+), 54 deletions(-)
>
> diff --git a/devtools/check-dup-includes.sh b/devtools/check-dup-includes.sh
> index e4c2748c6..591599949 100755
> --- a/devtools/check-dup-includes.sh
> +++ b/devtools/check-dup-includes.sh
> @@ -5,7 +5,7 @@
> # Check C files in git repository for duplicated includes.
> # Usage: devtools/check-dup-includes.sh [directory]
>
> -dir=${1:-$(dirname $(readlink -m $0))/..}
> +dir=${1:-$(dirname $(readlink -f $0))/..}
> cd $dir
>
> # speed up by ignoring Unicode details
> diff --git a/devtools/checkpatches.sh b/devtools/checkpatches.sh
> index 560e6ce93..8e2beee16 100755
> --- a/devtools/checkpatches.sh
> +++ b/devtools/checkpatches.sh
> @@ -7,9 +7,9 @@
> # - DPDK_CHECKPATCH_CODESPELL
> # - DPDK_CHECKPATCH_LINE_LENGTH
> # - DPDK_CHECKPATCH_OPTIONS
> -. $(dirname $(readlink -e $0))/load-devel-config
> +. $(dirname $(readlink -f $0))/load-devel-config
>
> -VALIDATE_NEW_API=$(dirname $(readlink -e $0))/check-symbol-change.sh
> +VALIDATE_NEW_API=$(dirname $(readlink -f $0))/check-symbol-change.sh
>
> # Enable codespell by default. This can be overwritten from a config file.
> # Codespell can also be enabled by setting DPDK_CHECKPATCH_CODESPELL to a valid path
> @@ -66,7 +66,7 @@ check_forbidden_additions() { # <patch>
> -v EXPRESSIONS="rte_panic\\\( rte_exit\\\(" \
> -v RET_ON_FAIL=1 \
> -v MESSAGE='Using rte_panic/rte_exit' \
> - -f $(dirname $(readlink -e $0))/check-forbidden-tokens.awk \
> + -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
> "$1" || res=1
>
> # svg figures must be included with wildcard extension
> @@ -75,7 +75,7 @@ check_forbidden_additions() { # <patch>
> -v EXPRESSIONS='::[[:space:]]*[^[:space:]]*\\.svg' \
> -v RET_ON_FAIL=1 \
> -v MESSAGE='Using explicit .svg extension instead of .*' \
> - -f $(dirname $(readlink -e $0))/check-forbidden-tokens.awk \
> + -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
> "$1" || res=1
>
> return $res
> diff --git a/devtools/get-maintainer.sh b/devtools/get-maintainer.sh
> index b9160486a..85740f5af 100755
> --- a/devtools/get-maintainer.sh
> +++ b/devtools/get-maintainer.sh
> @@ -5,7 +5,7 @@
>
> # Load config options:
> # - DPDK_GETMAINTAINER_PATH
> -. $(dirname $(readlink -e $0))/load-devel-config
> +. $(dirname $(readlink -f $0))/load-devel-config
>
> options="--no-git-fallback"
> options="$options --no-rolestats"
> diff --git a/devtools/load-devel-config b/devtools/load-devel-config
> index 4f43cb352..380c79db4 100644
> --- a/devtools/load-devel-config
> +++ b/devtools/load-devel-config
> @@ -6,7 +6,7 @@ test ! -r /etc/dpdk/devel.config ||
> test ! -r ~/.config/dpdk/devel.config ||
> . ~/.config/dpdk/devel.config
> # from local file
> -test ! -r $(dirname $(readlink -m $0))/../.develconfig ||
> - . $(dirname $(readlink -m $0))/../.develconfig
> +test ! -r $(dirname $(readlink -f $0))/../.develconfig ||
> + . $(dirname $(readlink -f $0))/../.develconfig
>
> # The config files must export variables in the shell style
> diff --git a/devtools/test-build.sh b/devtools/test-build.sh
> index 9b50bf73d..3c029ce31 100755
> --- a/devtools/test-build.sh
> +++ b/devtools/test-build.sh
> @@ -28,7 +28,7 @@ default_path=$PATH
> # - LIBSSO_SNOW3G_PATH
> # - LIBSSO_KASUMI_PATH
> # - LIBSSO_ZUC_PATH
> -. $(dirname $(readlink -e $0))/load-devel-config
> +. $(dirname $(readlink -f $0))/load-devel-config
>
> print_usage () {
> echo "usage: $(basename $0) [-h] [-jX] [-s] [config1 [config2] ...]]"
> @@ -57,6 +57,10 @@ print_help () {
> END_OF_HELP
> }
>
> +[ -z $MAKE ] && command -v gmake > /dev/null && MAKE=gmake
> +[ -z $MAKE ] && command -v make > /dev/null && MAKE=make
> +[ -z $MAKE ] && echo "Cannot find make or gmake" && exit 1
> +
> J=$DPDK_MAKE_JOBS
> short=false
> unset verbose
> @@ -90,7 +94,7 @@ trap "signal=INT ; trap - INT ; kill -INT $$" INT
> # notify result on exit
> trap on_exit EXIT
>
> -cd $(dirname $(readlink -m $0))/..
> +cd $(dirname $(readlink -f $0))/..
>
> reset_env ()
> {
> @@ -127,83 +131,83 @@ config () # <directory> <target> <options>
> fi
> if [ ! -e $1/.config ] || $reconfig ; then
> echo "================== Configure $1"
> - make T=$2 O=$1 config
> + ${MAKE} T=$2 O=$1 config
>
> echo 'Customize configuration'
> # Built-in options (lowercase)
> ! echo $3 | grep -q '+default' || \
> - sed -ri 's,(RTE_MACHINE=")native,\1default,' $1/.config
> + sed -ri="" 's,(RTE_MACHINE=")native,\1default,' $1/.config
> echo $3 | grep -q '+next' || \
> - sed -ri 's,(NEXT_ABI=)y,\1n,' $1/.config
> + sed -ri="" 's,(NEXT_ABI=)y,\1n,' $1/.config
> ! echo $3 | grep -q '+shared' || \
> - sed -ri 's,(SHARED_LIB=)n,\1y,' $1/.config
> + sed -ri="" 's,(SHARED_LIB=)n,\1y,' $1/.config
> ! echo $3 | grep -q '+debug' || ( \
> - sed -ri 's,(RTE_LOG_DP_LEVEL=).*,\1RTE_LOG_DEBUG,' $1/.config
> - sed -ri 's,(_DEBUG.*=)n,\1y,' $1/.config
> - sed -ri 's,(_STAT.*=)n,\1y,' $1/.config
> - sed -ri 's,(TEST_PMD_RECORD_.*=)n,\1y,' $1/.config )
> + sed -ri="" 's,(RTE_LOG_DP_LEVEL=).*,\1RTE_LOG_DEBUG,' $1/.config
> + sed -ri="" 's,(_DEBUG.*=)n,\1y,' $1/.config
> + sed -ri="" 's,(_STAT.*=)n,\1y,' $1/.config
> + sed -ri="" 's,(TEST_PMD_RECORD_.*=)n,\1y,' $1/.config )
>
> # Automatic configuration
> test "$DPDK_DEP_NUMA" != n || \
> - sed -ri 's,(NUMA.*=)y,\1n,' $1/.config
> - sed -ri 's,(LIBRTE_IEEE1588=)n,\1y,' $1/.config
> - sed -ri 's,(BYPASS=)n,\1y,' $1/.config
> + sed -ri="" 's,(NUMA.*=)y,\1n,' $1/.config
> + sed -ri="" 's,(LIBRTE_IEEE1588=)n,\1y,' $1/.config
> + sed -ri="" 's,(BYPASS=)n,\1y,' $1/.config
> test "$DPDK_DEP_ARCHIVE" != y || \
> - sed -ri 's,(RESOURCE_TAR=)n,\1y,' $1/.config
> + sed -ri="" 's,(RESOURCE_TAR=)n,\1y,' $1/.config
> test "$DPDK_DEP_ISAL" != y || \
> - sed -ri 's,(PMD_ISAL=)n,\1y,' $1/.config
> + sed -ri="" 's,(PMD_ISAL=)n,\1y,' $1/.config
> test "$DPDK_DEP_MLX" != y || \
> - sed -ri 's,(MLX._PMD=)n,\1y,' $1/.config
> + sed -ri="" 's,(MLX._PMD=)n,\1y,' $1/.config
> test "$DPDK_DEP_SZE" != y || \
> - sed -ri 's,(PMD_SZEDATA2=)n,\1y,' $1/.config
> + sed -ri="" 's,(PMD_SZEDATA2=)n,\1y,' $1/.config
> test "$DPDK_DEP_ZLIB" != y || \
> - sed -ri 's,(BNX2X_PMD=)n,\1y,' $1/.config
> + sed -ri="" 's,(BNX2X_PMD=)n,\1y,' $1/.config
> test "$DPDK_DEP_ZLIB" != y || \
> - sed -ri 's,(PMD_ZLIB=)n,\1y,' $1/.config
> + sed -ri="" 's,(PMD_ZLIB=)n,\1y,' $1/.config
> test "$DPDK_DEP_ZLIB" != y || \
> - sed -ri 's,(COMPRESSDEV_TEST=)n,\1y,' $1/.config
> + sed -ri="" 's,(COMPRESSDEV_TEST=)n,\1y,' $1/.config
> test "$DPDK_DEP_PCAP" != y || \
> - sed -ri 's,(PCAP=)n,\1y,' $1/.config
> + sed -ri="" 's,(PCAP=)n,\1y,' $1/.config
> test -z "$ARMV8_CRYPTO_LIB_PATH" || \
> - sed -ri 's,(PMD_ARMV8_CRYPTO=)n,\1y,' $1/.config
> + sed -ri="" 's,(PMD_ARMV8_CRYPTO=)n,\1y,' $1/.config
> test "$DPDK_DEP_IPSEC_MB" != y || \
> - sed -ri 's,(PMD_AESNI_MB=)n,\1y,' $1/.config
> + sed -ri="" 's,(PMD_AESNI_MB=)n,\1y,' $1/.config
> test "$DPDK_DEP_IPSEC_MB" != y || \
> - sed -ri 's,(PMD_AESNI_GCM=)n,\1y,' $1/.config
> + sed -ri="" 's,(PMD_AESNI_GCM=)n,\1y,' $1/.config
> test -z "$LIBSSO_SNOW3G_PATH" || \
> - sed -ri 's,(PMD_SNOW3G=)n,\1y,' $1/.config
> + sed -ri="" 's,(PMD_SNOW3G=)n,\1y,' $1/.config
> test -z "$LIBSSO_KASUMI_PATH" || \
> - sed -ri 's,(PMD_KASUMI=)n,\1y,' $1/.config
> + sed -ri="" 's,(PMD_KASUMI=)n,\1y,' $1/.config
> test -z "$LIBSSO_ZUC_PATH" || \
> - sed -ri 's,(PMD_ZUC=)n,\1y,' $1/.config
> + sed -ri="" 's,(PMD_ZUC=)n,\1y,' $1/.config
> test "$DPDK_DEP_SSL" != y || \
> - sed -ri 's,(PMD_CCP=)n,\1y,' $1/.config
> + sed -ri="" 's,(PMD_CCP=)n,\1y,' $1/.config
> test "$DPDK_DEP_SSL" != y || \
> - sed -ri 's,(PMD_OPENSSL=)n,\1y,' $1/.config
> + sed -ri="" 's,(PMD_OPENSSL=)n,\1y,' $1/.config
> test "$DPDK_DEP_SSL" != y || \
> - sed -ri 's,(QAT_SYM=)n,\1y,' $1/.config
> + sed -ri="" 's,(QAT_SYM=)n,\1y,' $1/.config
> test -z "$FLEXRAN_SDK" || \
> - sed -ri 's,(BBDEV_TURBO_SW=)n,\1y,' $1/.config
> - sed -ri 's,(SCHED_.*=)n,\1y,' $1/.config
> + sed -ri="" 's,(BBDEV_TURBO_SW=)n,\1y,' $1/.config
> + sed -ri="" 's,(SCHED_.*=)n,\1y,' $1/.config
> test -z "$LIBMUSDK_PATH" || \
> - sed -ri 's,(PMD_MVSAM_CRYPTO=)n,\1y,' $1/.config
> + sed -ri="" 's,(PMD_MVSAM_CRYPTO=)n,\1y,' $1/.config
> test -z "$LIBMUSDK_PATH" || \
> - sed -ri 's,(MVPP2_PMD=)n,\1y,' $1/.config
> + sed -ri="" 's,(MVPP2_PMD=)n,\1y,' $1/.config
> test -z "$LIBMUSDK_PATH" || \
> - sed -ri 's,(MVNETA_PMD=)n,\1y,' $1/.config
> + sed -ri="" 's,(MVNETA_PMD=)n,\1y,' $1/.config
> test "$DPDK_DEP_ELF" != y || \
> - sed -ri 's,(BPF_ELF=)n,\1y,' $1/.config
> + sed -ri="" 's,(BPF_ELF=)n,\1y,' $1/.config
> test "$DPDK_DEP_JSON" != y || \
> - sed -ri 's,(TELEMETRY=)n,\1y,' $1/.config
> + sed -ri="" 's,(TELEMETRY=)n,\1y,' $1/.config
> build_config_hook $1 $2 $3
>
> # Explicit enabler/disabler (uppercase)
> for option in $(echo $3 | sed 's,[~+], &,g') ; do
> pattern=$(echo $option | cut -c2-)
> if echo $option | grep -q '^~' ; then
> - sed -ri "s,($pattern=)y,\1n," $1/.config
> + sed -ri="" "s,($pattern=)y,\1n," $1/.config
> elif echo $option | grep -q '^+' ; then
> - sed -ri "s,($pattern=)n,\1y," $1/.config
> + sed -ri="" "s,($pattern=)n,\1y," $1/.config
> fi
> done
> fi
> @@ -220,22 +224,22 @@ for conf in $configs ; do
> # reload config with DPDK_TARGET set
> DPDK_TARGET=$target
> reset_env
> - . $(dirname $(readlink -e $0))/load-devel-config
> + . $(dirname $(readlink -f $0))/load-devel-config
>
> options=$(echo $conf | sed 's,[^~+]*,,')
> dir=$conf
> config $dir $target $options
>
> echo "================== Build $dir"
> - make -j$J EXTRA_CFLAGS="$maxerr $DPDK_DEP_CFLAGS" \
> + ${MAKE} -j$J EXTRA_CFLAGS="$maxerr $DPDK_DEP_CFLAGS" \
> EXTRA_LDFLAGS="$DPDK_DEP_LDFLAGS" $verbose O=$dir
> ! $short || break
> echo "================== Build examples for $dir"
> export RTE_SDK=$(pwd)
> export RTE_TARGET=$dir
> - make -j$J -sC examples \
> + ${MAKE} -j$J -sC examples \
> EXTRA_LDFLAGS="$DPDK_DEP_LDFLAGS" $verbose \
> - O=$(readlink -m $dir/examples)
> + O=$(readlink -f $dir)/examples
> unset RTE_TARGET
> echo "################## $dir done."
> unset dir
> @@ -244,9 +248,9 @@ done
> if ! $short ; then
> mkdir -p .check
> echo "================== Build doxygen HTML API"
> - make doc-api-html >/dev/null 2>.check/doc.txt
> + ${MAKE} doc-api-html >/dev/null 2>.check/doc.txt
> echo "================== Build sphinx HTML guides"
> - make doc-guides-html >/dev/null 2>>.check/doc.txt
> + ${MAKE} doc-guides-html >/dev/null 2>>.check/doc.txt
> echo "================== Check docs"
> diff -u /dev/null .check/doc.txt
> fi
> diff --git a/devtools/validate-abi.sh b/devtools/validate-abi.sh
> index 138436d93..f64e19d38 100755
> --- a/devtools/validate-abi.sh
> +++ b/devtools/validate-abi.sh
> @@ -181,7 +181,7 @@ case "${dst}" in
> /*) ;;
> *) dst=${PWD}/${dst} ;;
> esac
> -dpdkroot=$(readlink -e $(dirname $0)/..)
> +dpdkroot=$(readlink -f $(dirname $0)/..)
>
> if [ -e "${dst}" -a "$force" = 0 ]; then
> echo "The ${dst} directory is not empty. Remove it, use another"
> --
> 2.11.0
>
Reviewed-by: David Marchand <david.marchand@redhat.com>
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v3] devtools: better freebsd support
2019-07-29 8:31 0% ` David Marchand
@ 2019-07-29 8:36 0% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2019-07-29 8:36 UTC (permalink / raw)
To: Olivier Matz; +Cc: dev, Thomas Monjalon, Bruce Richardson, Flavia
On Mon, Jul 29, 2019 at 10:31 AM David Marchand
<david.marchand@redhat.com> wrote:
>
> On Thu, Jul 11, 2019 at 4:25 PM Olivier Matz <olivier.matz@6wind.com> wrote:
> >
> > - As "readlink -e" and "readlink -m" do not exist on freebsd,
> > use "readlink -f", it should not have any impact in these cases.
> > - "sed -ri" is invalid on freebsd and should be replaced by
> > "sed -ri=''"
> > - Use gmake instead of make.
> >
> > This fixes the following command:
> > SYSDIR=/usr/src/sys ./devtools/test-build.sh \
> > -j4 x86_64-native-freebsd-gcc
> >
> > Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
> > ---
> >
> > v3:
> > - fix examples installation path, pointed-out by Flavia
> >
> > v2:
> > - remove sed_ri() function and use 'sed -ri=""' as suggested by Bruce
> >
> > devtools/check-dup-includes.sh | 2 +-
> > devtools/checkpatches.sh | 8 ++--
> > devtools/get-maintainer.sh | 2 +-
> > devtools/load-devel-config | 4 +-
> > devtools/test-build.sh | 94 ++++++++++++++++++++++--------------------
> > devtools/validate-abi.sh | 2 +-
> > 6 files changed, 58 insertions(+), 54 deletions(-)
> >
> > diff --git a/devtools/check-dup-includes.sh b/devtools/check-dup-includes.sh
> > index e4c2748c6..591599949 100755
> > --- a/devtools/check-dup-includes.sh
> > +++ b/devtools/check-dup-includes.sh
> > @@ -5,7 +5,7 @@
> > # Check C files in git repository for duplicated includes.
> > # Usage: devtools/check-dup-includes.sh [directory]
> >
> > -dir=${1:-$(dirname $(readlink -m $0))/..}
> > +dir=${1:-$(dirname $(readlink -f $0))/..}
> > cd $dir
> >
> > # speed up by ignoring Unicode details
> > diff --git a/devtools/checkpatches.sh b/devtools/checkpatches.sh
> > index 560e6ce93..8e2beee16 100755
> > --- a/devtools/checkpatches.sh
> > +++ b/devtools/checkpatches.sh
> > @@ -7,9 +7,9 @@
> > # - DPDK_CHECKPATCH_CODESPELL
> > # - DPDK_CHECKPATCH_LINE_LENGTH
> > # - DPDK_CHECKPATCH_OPTIONS
> > -. $(dirname $(readlink -e $0))/load-devel-config
> > +. $(dirname $(readlink -f $0))/load-devel-config
> >
> > -VALIDATE_NEW_API=$(dirname $(readlink -e $0))/check-symbol-change.sh
> > +VALIDATE_NEW_API=$(dirname $(readlink -f $0))/check-symbol-change.sh
> >
> > # Enable codespell by default. This can be overwritten from a config file.
> > # Codespell can also be enabled by setting DPDK_CHECKPATCH_CODESPELL to a valid path
> > @@ -66,7 +66,7 @@ check_forbidden_additions() { # <patch>
> > -v EXPRESSIONS="rte_panic\\\( rte_exit\\\(" \
> > -v RET_ON_FAIL=1 \
> > -v MESSAGE='Using rte_panic/rte_exit' \
> > - -f $(dirname $(readlink -e $0))/check-forbidden-tokens.awk \
> > + -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
> > "$1" || res=1
> >
> > # svg figures must be included with wildcard extension
> > @@ -75,7 +75,7 @@ check_forbidden_additions() { # <patch>
> > -v EXPRESSIONS='::[[:space:]]*[^[:space:]]*\\.svg' \
> > -v RET_ON_FAIL=1 \
> > -v MESSAGE='Using explicit .svg extension instead of .*' \
> > - -f $(dirname $(readlink -e $0))/check-forbidden-tokens.awk \
> > + -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
> > "$1" || res=1
> >
> > return $res
> > diff --git a/devtools/get-maintainer.sh b/devtools/get-maintainer.sh
> > index b9160486a..85740f5af 100755
> > --- a/devtools/get-maintainer.sh
> > +++ b/devtools/get-maintainer.sh
> > @@ -5,7 +5,7 @@
> >
> > # Load config options:
> > # - DPDK_GETMAINTAINER_PATH
> > -. $(dirname $(readlink -e $0))/load-devel-config
> > +. $(dirname $(readlink -f $0))/load-devel-config
> >
> > options="--no-git-fallback"
> > options="$options --no-rolestats"
> > diff --git a/devtools/load-devel-config b/devtools/load-devel-config
> > index 4f43cb352..380c79db4 100644
> > --- a/devtools/load-devel-config
> > +++ b/devtools/load-devel-config
> > @@ -6,7 +6,7 @@ test ! -r /etc/dpdk/devel.config ||
> > test ! -r ~/.config/dpdk/devel.config ||
> > . ~/.config/dpdk/devel.config
> > # from local file
> > -test ! -r $(dirname $(readlink -m $0))/../.develconfig ||
> > - . $(dirname $(readlink -m $0))/../.develconfig
> > +test ! -r $(dirname $(readlink -f $0))/../.develconfig ||
> > + . $(dirname $(readlink -f $0))/../.develconfig
> >
> > # The config files must export variables in the shell style
> > diff --git a/devtools/test-build.sh b/devtools/test-build.sh
> > index 9b50bf73d..3c029ce31 100755
> > --- a/devtools/test-build.sh
> > +++ b/devtools/test-build.sh
> > @@ -28,7 +28,7 @@ default_path=$PATH
> > # - LIBSSO_SNOW3G_PATH
> > # - LIBSSO_KASUMI_PATH
> > # - LIBSSO_ZUC_PATH
> > -. $(dirname $(readlink -e $0))/load-devel-config
> > +. $(dirname $(readlink -f $0))/load-devel-config
> >
> > print_usage () {
> > echo "usage: $(basename $0) [-h] [-jX] [-s] [config1 [config2] ...]]"
> > @@ -57,6 +57,10 @@ print_help () {
> > END_OF_HELP
> > }
> >
> > +[ -z $MAKE ] && command -v gmake > /dev/null && MAKE=gmake
> > +[ -z $MAKE ] && command -v make > /dev/null && MAKE=make
> > +[ -z $MAKE ] && echo "Cannot find make or gmake" && exit 1
> > +
> > J=$DPDK_MAKE_JOBS
> > short=false
> > unset verbose
> > @@ -90,7 +94,7 @@ trap "signal=INT ; trap - INT ; kill -INT $$" INT
> > # notify result on exit
> > trap on_exit EXIT
> >
> > -cd $(dirname $(readlink -m $0))/..
> > +cd $(dirname $(readlink -f $0))/..
> >
> > reset_env ()
> > {
> > @@ -127,83 +131,83 @@ config () # <directory> <target> <options>
> > fi
> > if [ ! -e $1/.config ] || $reconfig ; then
> > echo "================== Configure $1"
> > - make T=$2 O=$1 config
> > + ${MAKE} T=$2 O=$1 config
> >
> > echo 'Customize configuration'
> > # Built-in options (lowercase)
> > ! echo $3 | grep -q '+default' || \
> > - sed -ri 's,(RTE_MACHINE=")native,\1default,' $1/.config
> > + sed -ri="" 's,(RTE_MACHINE=")native,\1default,' $1/.config
> > echo $3 | grep -q '+next' || \
> > - sed -ri 's,(NEXT_ABI=)y,\1n,' $1/.config
> > + sed -ri="" 's,(NEXT_ABI=)y,\1n,' $1/.config
> > ! echo $3 | grep -q '+shared' || \
> > - sed -ri 's,(SHARED_LIB=)n,\1y,' $1/.config
> > + sed -ri="" 's,(SHARED_LIB=)n,\1y,' $1/.config
> > ! echo $3 | grep -q '+debug' || ( \
> > - sed -ri 's,(RTE_LOG_DP_LEVEL=).*,\1RTE_LOG_DEBUG,' $1/.config
> > - sed -ri 's,(_DEBUG.*=)n,\1y,' $1/.config
> > - sed -ri 's,(_STAT.*=)n,\1y,' $1/.config
> > - sed -ri 's,(TEST_PMD_RECORD_.*=)n,\1y,' $1/.config )
> > + sed -ri="" 's,(RTE_LOG_DP_LEVEL=).*,\1RTE_LOG_DEBUG,' $1/.config
> > + sed -ri="" 's,(_DEBUG.*=)n,\1y,' $1/.config
> > + sed -ri="" 's,(_STAT.*=)n,\1y,' $1/.config
> > + sed -ri="" 's,(TEST_PMD_RECORD_.*=)n,\1y,' $1/.config )
> >
> > # Automatic configuration
> > test "$DPDK_DEP_NUMA" != n || \
> > - sed -ri 's,(NUMA.*=)y,\1n,' $1/.config
> > - sed -ri 's,(LIBRTE_IEEE1588=)n,\1y,' $1/.config
> > - sed -ri 's,(BYPASS=)n,\1y,' $1/.config
> > + sed -ri="" 's,(NUMA.*=)y,\1n,' $1/.config
> > + sed -ri="" 's,(LIBRTE_IEEE1588=)n,\1y,' $1/.config
> > + sed -ri="" 's,(BYPASS=)n,\1y,' $1/.config
> > test "$DPDK_DEP_ARCHIVE" != y || \
> > - sed -ri 's,(RESOURCE_TAR=)n,\1y,' $1/.config
> > + sed -ri="" 's,(RESOURCE_TAR=)n,\1y,' $1/.config
> > test "$DPDK_DEP_ISAL" != y || \
> > - sed -ri 's,(PMD_ISAL=)n,\1y,' $1/.config
> > + sed -ri="" 's,(PMD_ISAL=)n,\1y,' $1/.config
> > test "$DPDK_DEP_MLX" != y || \
> > - sed -ri 's,(MLX._PMD=)n,\1y,' $1/.config
> > + sed -ri="" 's,(MLX._PMD=)n,\1y,' $1/.config
> > test "$DPDK_DEP_SZE" != y || \
> > - sed -ri 's,(PMD_SZEDATA2=)n,\1y,' $1/.config
> > + sed -ri="" 's,(PMD_SZEDATA2=)n,\1y,' $1/.config
> > test "$DPDK_DEP_ZLIB" != y || \
> > - sed -ri 's,(BNX2X_PMD=)n,\1y,' $1/.config
> > + sed -ri="" 's,(BNX2X_PMD=)n,\1y,' $1/.config
> > test "$DPDK_DEP_ZLIB" != y || \
> > - sed -ri 's,(PMD_ZLIB=)n,\1y,' $1/.config
> > + sed -ri="" 's,(PMD_ZLIB=)n,\1y,' $1/.config
> > test "$DPDK_DEP_ZLIB" != y || \
> > - sed -ri 's,(COMPRESSDEV_TEST=)n,\1y,' $1/.config
> > + sed -ri="" 's,(COMPRESSDEV_TEST=)n,\1y,' $1/.config
> > test "$DPDK_DEP_PCAP" != y || \
> > - sed -ri 's,(PCAP=)n,\1y,' $1/.config
> > + sed -ri="" 's,(PCAP=)n,\1y,' $1/.config
> > test -z "$ARMV8_CRYPTO_LIB_PATH" || \
> > - sed -ri 's,(PMD_ARMV8_CRYPTO=)n,\1y,' $1/.config
> > + sed -ri="" 's,(PMD_ARMV8_CRYPTO=)n,\1y,' $1/.config
> > test "$DPDK_DEP_IPSEC_MB" != y || \
> > - sed -ri 's,(PMD_AESNI_MB=)n,\1y,' $1/.config
> > + sed -ri="" 's,(PMD_AESNI_MB=)n,\1y,' $1/.config
> > test "$DPDK_DEP_IPSEC_MB" != y || \
> > - sed -ri 's,(PMD_AESNI_GCM=)n,\1y,' $1/.config
> > + sed -ri="" 's,(PMD_AESNI_GCM=)n,\1y,' $1/.config
> > test -z "$LIBSSO_SNOW3G_PATH" || \
> > - sed -ri 's,(PMD_SNOW3G=)n,\1y,' $1/.config
> > + sed -ri="" 's,(PMD_SNOW3G=)n,\1y,' $1/.config
> > test -z "$LIBSSO_KASUMI_PATH" || \
> > - sed -ri 's,(PMD_KASUMI=)n,\1y,' $1/.config
> > + sed -ri="" 's,(PMD_KASUMI=)n,\1y,' $1/.config
> > test -z "$LIBSSO_ZUC_PATH" || \
> > - sed -ri 's,(PMD_ZUC=)n,\1y,' $1/.config
> > + sed -ri="" 's,(PMD_ZUC=)n,\1y,' $1/.config
> > test "$DPDK_DEP_SSL" != y || \
> > - sed -ri 's,(PMD_CCP=)n,\1y,' $1/.config
> > + sed -ri="" 's,(PMD_CCP=)n,\1y,' $1/.config
> > test "$DPDK_DEP_SSL" != y || \
> > - sed -ri 's,(PMD_OPENSSL=)n,\1y,' $1/.config
> > + sed -ri="" 's,(PMD_OPENSSL=)n,\1y,' $1/.config
> > test "$DPDK_DEP_SSL" != y || \
> > - sed -ri 's,(QAT_SYM=)n,\1y,' $1/.config
> > + sed -ri="" 's,(QAT_SYM=)n,\1y,' $1/.config
> > test -z "$FLEXRAN_SDK" || \
> > - sed -ri 's,(BBDEV_TURBO_SW=)n,\1y,' $1/.config
> > - sed -ri 's,(SCHED_.*=)n,\1y,' $1/.config
> > + sed -ri="" 's,(BBDEV_TURBO_SW=)n,\1y,' $1/.config
> > + sed -ri="" 's,(SCHED_.*=)n,\1y,' $1/.config
> > test -z "$LIBMUSDK_PATH" || \
> > - sed -ri 's,(PMD_MVSAM_CRYPTO=)n,\1y,' $1/.config
> > + sed -ri="" 's,(PMD_MVSAM_CRYPTO=)n,\1y,' $1/.config
> > test -z "$LIBMUSDK_PATH" || \
> > - sed -ri 's,(MVPP2_PMD=)n,\1y,' $1/.config
> > + sed -ri="" 's,(MVPP2_PMD=)n,\1y,' $1/.config
> > test -z "$LIBMUSDK_PATH" || \
> > - sed -ri 's,(MVNETA_PMD=)n,\1y,' $1/.config
> > + sed -ri="" 's,(MVNETA_PMD=)n,\1y,' $1/.config
> > test "$DPDK_DEP_ELF" != y || \
> > - sed -ri 's,(BPF_ELF=)n,\1y,' $1/.config
> > + sed -ri="" 's,(BPF_ELF=)n,\1y,' $1/.config
> > test "$DPDK_DEP_JSON" != y || \
> > - sed -ri 's,(TELEMETRY=)n,\1y,' $1/.config
> > + sed -ri="" 's,(TELEMETRY=)n,\1y,' $1/.config
> > build_config_hook $1 $2 $3
> >
> > # Explicit enabler/disabler (uppercase)
> > for option in $(echo $3 | sed 's,[~+], &,g') ; do
> > pattern=$(echo $option | cut -c2-)
> > if echo $option | grep -q '^~' ; then
> > - sed -ri "s,($pattern=)y,\1n," $1/.config
> > + sed -ri="" "s,($pattern=)y,\1n," $1/.config
> > elif echo $option | grep -q '^+' ; then
> > - sed -ri "s,($pattern=)n,\1y," $1/.config
> > + sed -ri="" "s,($pattern=)n,\1y," $1/.config
> > fi
> > done
> > fi
> > @@ -220,22 +224,22 @@ for conf in $configs ; do
> > # reload config with DPDK_TARGET set
> > DPDK_TARGET=$target
> > reset_env
> > - . $(dirname $(readlink -e $0))/load-devel-config
> > + . $(dirname $(readlink -f $0))/load-devel-config
> >
> > options=$(echo $conf | sed 's,[^~+]*,,')
> > dir=$conf
> > config $dir $target $options
> >
> > echo "================== Build $dir"
> > - make -j$J EXTRA_CFLAGS="$maxerr $DPDK_DEP_CFLAGS" \
> > + ${MAKE} -j$J EXTRA_CFLAGS="$maxerr $DPDK_DEP_CFLAGS" \
> > EXTRA_LDFLAGS="$DPDK_DEP_LDFLAGS" $verbose O=$dir
> > ! $short || break
> > echo "================== Build examples for $dir"
> > export RTE_SDK=$(pwd)
> > export RTE_TARGET=$dir
> > - make -j$J -sC examples \
> > + ${MAKE} -j$J -sC examples \
> > EXTRA_LDFLAGS="$DPDK_DEP_LDFLAGS" $verbose \
> > - O=$(readlink -m $dir/examples)
> > + O=$(readlink -f $dir)/examples
> > unset RTE_TARGET
> > echo "################## $dir done."
> > unset dir
> > @@ -244,9 +248,9 @@ done
> > if ! $short ; then
> > mkdir -p .check
> > echo "================== Build doxygen HTML API"
> > - make doc-api-html >/dev/null 2>.check/doc.txt
> > + ${MAKE} doc-api-html >/dev/null 2>.check/doc.txt
> > echo "================== Build sphinx HTML guides"
> > - make doc-guides-html >/dev/null 2>>.check/doc.txt
> > + ${MAKE} doc-guides-html >/dev/null 2>>.check/doc.txt
> > echo "================== Check docs"
> > diff -u /dev/null .check/doc.txt
> > fi
> > diff --git a/devtools/validate-abi.sh b/devtools/validate-abi.sh
> > index 138436d93..f64e19d38 100755
> > --- a/devtools/validate-abi.sh
> > +++ b/devtools/validate-abi.sh
> > @@ -181,7 +181,7 @@ case "${dst}" in
> > /*) ;;
> > *) dst=${PWD}/${dst} ;;
> > esac
> > -dpdkroot=$(readlink -e $(dirname $0)/..)
> > +dpdkroot=$(readlink -f $(dirname $0)/..)
> >
> > if [ -e "${dst}" -a "$force" = 0 ]; then
> > echo "The ${dst} directory is not empty. Remove it, use another"
> > --
> > 2.11.0
> >
>
> Reviewed-by: David Marchand <david.marchand@redhat.com>
Small nit on the title, it should be FreeBSD.
--
David Marchand
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v9 3/5] kni: add app specific mempool create & free routine
@ 2019-07-29 12:13 3% ` vattunuru
0 siblings, 0 replies; 200+ results
From: vattunuru @ 2019-07-29 12:13 UTC (permalink / raw)
To: dev
Cc: thomas, jerinj, olivier.matz, ferruh.yigit, anatoly.burakov,
arybchenko, kirankumark, Vamsi Attunuru
From: Vamsi Attunuru <vattunuru@marvell.com>
When KNI operates in IOVA = VA mode, it requires mbuf memory
to be physically contiguous to ensure KNI kernel module could
translate IOVA addresses properly. Patch adds a KNI specific
mempool create routine to populate the KNI packet mbuf pool
with memory objects that are being on a page.
KNI applications need to use this mempool create & free routines
so that mbuf related requirements in IOVA = VA mode are handled
inside those routines based on the enabled mode.
Updated the release notes with these new routine details.
Signed-off-by: Vamsi Attunuru <vattunuru@marvell.com>
---
doc/guides/rel_notes/release_19_08.rst | 6 ++++
examples/kni/main.c | 5 ++-
lib/librte_kni/Makefile | 1 +
lib/librte_kni/meson.build | 1 +
lib/librte_kni/rte_kni.c | 60 ++++++++++++++++++++++++++++++++++
lib/librte_kni/rte_kni.h | 48 +++++++++++++++++++++++++++
lib/librte_kni/rte_kni_version.map | 2 ++
7 files changed, 122 insertions(+), 1 deletion(-)
diff --git a/doc/guides/rel_notes/release_19_08.rst b/doc/guides/rel_notes/release_19_08.rst
index c9bd3ce..b200aae 100644
--- a/doc/guides/rel_notes/release_19_08.rst
+++ b/doc/guides/rel_notes/release_19_08.rst
@@ -301,6 +301,12 @@ API Changes
best-effort tc, and qsize field of struct ``rte_sched_port_params`` is
changed to allow different size of the each queue.
+* kni: ``rte_kni_pktmbuf_pool_create`` ``rte_kni_pktmbuf_pool_free`` functions
+ were introduced for KNI applications for creating & freeing packet pool.
+ Since IOVA=VA mode was added in KNI, packet pool's mbuf memory should be
+ physically contiguous for the KNI kernel module to work in IOVA=VA mode,
+ this requirement was taken care in the kni packet pool creation fucntions.
+
ABI Changes
-----------
diff --git a/examples/kni/main.c b/examples/kni/main.c
index 4710d71..fdfeed2 100644
--- a/examples/kni/main.c
+++ b/examples/kni/main.c
@@ -975,7 +975,7 @@ main(int argc, char** argv)
rte_exit(EXIT_FAILURE, "Could not parse input parameters\n");
/* Create the mbuf pool */
- pktmbuf_pool = rte_pktmbuf_pool_create("mbuf_pool", NB_MBUF,
+ pktmbuf_pool = rte_kni_pktmbuf_pool_create("mbuf_pool", NB_MBUF,
MEMPOOL_CACHE_SZ, 0, MBUF_DATA_SZ, rte_socket_id());
if (pktmbuf_pool == NULL) {
rte_exit(EXIT_FAILURE, "Could not initialise mbuf pool\n");
@@ -1043,6 +1043,9 @@ main(int argc, char** argv)
continue;
kni_free_kni(port);
}
+
+ rte_kni_pktmbuf_pool_free(pktmbuf_pool);
+
for (i = 0; i < RTE_MAX_ETHPORTS; i++)
if (kni_port_params_array[i]) {
rte_free(kni_port_params_array[i]);
diff --git a/lib/librte_kni/Makefile b/lib/librte_kni/Makefile
index ab15d10..5e3dd01 100644
--- a/lib/librte_kni/Makefile
+++ b/lib/librte_kni/Makefile
@@ -6,6 +6,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
# library name
LIB = librte_kni.a
+CFLAGS += -DALLOW_EXPERIMENTAL_API
CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3 -fno-strict-aliasing
CFLAGS += -I$(RTE_SDK)/drivers/bus/pci
LDLIBS += -lrte_eal -lrte_mempool -lrte_mbuf -lrte_ethdev
diff --git a/lib/librte_kni/meson.build b/lib/librte_kni/meson.build
index fd46f87..e357445 100644
--- a/lib/librte_kni/meson.build
+++ b/lib/librte_kni/meson.build
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Intel Corporation
+allow_experimental_apis = true
if not is_linux or not dpdk_conf.get('RTE_ARCH_64')
build = false
reason = 'only supported on 64-bit linux'
diff --git a/lib/librte_kni/rte_kni.c b/lib/librte_kni/rte_kni.c
index 2aaaeaa..15dda45 100644
--- a/lib/librte_kni/rte_kni.c
+++ b/lib/librte_kni/rte_kni.c
@@ -22,6 +22,7 @@
#include <rte_tailq.h>
#include <rte_rwlock.h>
#include <rte_eal_memconfig.h>
+#include <rte_mbuf_pool_ops.h>
#include <rte_kni_common.h>
#include "rte_kni_fifo.h"
@@ -681,6 +682,65 @@ kni_allocate_mbufs(struct rte_kni *kni)
}
}
+struct rte_mempool *
+rte_kni_pktmbuf_pool_create(const char *name, unsigned int n,
+ unsigned int cache_size, uint16_t priv_size, uint16_t data_room_size,
+ int socket_id)
+{
+ struct rte_pktmbuf_pool_private mbp_priv;
+ const char *mp_ops_name;
+ struct rte_mempool *mp;
+ unsigned int elt_size;
+ int ret;
+
+ if (RTE_ALIGN(priv_size, RTE_MBUF_PRIV_ALIGN) != priv_size) {
+ RTE_LOG(ERR, MBUF, "mbuf priv_size=%u is not aligned\n",
+ priv_size);
+ rte_errno = EINVAL;
+ return NULL;
+ }
+ elt_size = sizeof(struct rte_mbuf) + (unsigned int)priv_size +
+ (unsigned int)data_room_size;
+ mbp_priv.mbuf_data_room_size = data_room_size;
+ mbp_priv.mbuf_priv_size = priv_size;
+
+ mp = rte_mempool_create_empty(name, n, elt_size, cache_size,
+ sizeof(struct rte_pktmbuf_pool_private), socket_id, 0);
+ if (mp == NULL)
+ return NULL;
+
+ mp_ops_name = rte_mbuf_best_mempool_ops();
+ ret = rte_mempool_set_ops_byname(mp, mp_ops_name, NULL);
+ if (ret != 0) {
+ RTE_LOG(ERR, MBUF, "error setting mempool handler\n");
+ rte_mempool_free(mp);
+ rte_errno = -ret;
+ return NULL;
+ }
+ rte_pktmbuf_pool_init(mp, &mbp_priv);
+
+ if (rte_eal_iova_mode() == RTE_IOVA_VA)
+ ret = rte_mempool_populate_from_pg_sz_chunks(mp);
+ else
+ ret = rte_mempool_populate_default(mp);
+
+ if (ret < 0) {
+ rte_mempool_free(mp);
+ rte_errno = -ret;
+ return NULL;
+ }
+
+ rte_mempool_obj_iter(mp, rte_pktmbuf_init, NULL);
+
+ return mp;
+}
+
+void
+rte_kni_pktmbuf_pool_free(struct rte_mempool *mp)
+{
+ rte_mempool_free(mp);
+}
+
struct rte_kni *
rte_kni_get(const char *name)
{
diff --git a/lib/librte_kni/rte_kni.h b/lib/librte_kni/rte_kni.h
index 5699a64..99d263d 100644
--- a/lib/librte_kni/rte_kni.h
+++ b/lib/librte_kni/rte_kni.h
@@ -184,6 +184,54 @@ unsigned rte_kni_tx_burst(struct rte_kni *kni, struct rte_mbuf **mbufs,
unsigned num);
/**
+ * Create a kni packet mbuf pool.
+ *
+ * This function creates and initializes a packet mbuf pool for KNI applications
+ * It calls the required mempool populate routine based on the IOVA mode.
+ *
+ * @param name
+ * The name of the mbuf pool.
+ * @param n
+ * The number of elements in the mbuf pool. The optimum size (in terms
+ * of memory usage) for a mempool is when n is a power of two minus one:
+ * n = (2^q - 1).
+ * @param cache_size
+ * Size of the per-core object cache. See rte_mempool_create() for
+ * details.
+ * @param priv_size
+ * Size of application private are between the rte_mbuf structure
+ * and the data buffer. This value must be aligned to RTE_MBUF_PRIV_ALIGN.
+ * @param data_room_size
+ * Size of data buffer in each mbuf, including RTE_PKTMBUF_HEADROOM.
+ * @param socket_id
+ * The socket identifier where the memory should be allocated. The
+ * value can be *SOCKET_ID_ANY* if there is no NUMA constraint for the
+ * reserved zone.
+ * @return
+ * The pointer to the new allocated mempool, on success. NULL on error
+ * with rte_errno set appropriately. Possible rte_errno values include:
+ * - E_RTE_NO_CONFIG - function could not get pointer to rte_config structure
+ * - E_RTE_SECONDARY - function was called from a secondary process instance
+ * - EINVAL - cache size provided is too large, or priv_size is not aligned.
+ * - ENOSPC - the maximum number of memzones has already been allocated
+ * - EEXIST - a memzone with the same name already exists
+ * - ENOMEM - no appropriate memory area found in which to create memzone
+ */
+__rte_experimental
+struct rte_mempool *rte_kni_pktmbuf_pool_create(const char *name,
+ unsigned int n, unsigned int cache_size, uint16_t priv_size,
+ uint16_t data_room_size, int socket_id);
+
+/**
+ * Free the given packet mempool.
+ *
+ * @param mp
+ * The mempool pointer.
+ */
+__rte_experimental
+void rte_kni_pktmbuf_pool_free(struct rte_mempool *mp);
+
+/**
* Get the KNI context of its name.
*
* @param name
diff --git a/lib/librte_kni/rte_kni_version.map b/lib/librte_kni/rte_kni_version.map
index c877dc6..aba9728 100644
--- a/lib/librte_kni/rte_kni_version.map
+++ b/lib/librte_kni/rte_kni_version.map
@@ -20,4 +20,6 @@ EXPERIMENTAL {
global:
rte_kni_update_link;
+ rte_kni_pktmbuf_pool_create;
+ rte_kni_pktmbuf_pool_free;
};
--
2.8.4
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC] kni: support allmulticast mode set
@ 2019-07-29 13:38 4% ` Ferruh Yigit
2019-07-29 15:25 3% ` Ye Xiaolong
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2019-07-29 13:38 UTC (permalink / raw)
To: Xiaolong Ye, John McNamara, Marko Kovacevic; +Cc: dev
On 7/24/2019 4:35 PM, Xiaolong Ye wrote:
> This patch adds support to allow users enable/disable allmulticast mode for
> kni interface.
>
> This requirement comes from bugzilla 312, more details can refer to:
> https://bugs.dpdk.org/show_bug.cgi?id=312
>
> Bugzilla ID: 312
>
> Signed-off-by: Xiaolong Ye <xiaolong.ye@intel.com>
Hi Xiaolong,
Patch lgtm, I think it is too later for this release but I suggest sending v1
for next release.
If there is an ABI breakage, to not block the patch for next release, a
deprecation notice needs to be sent in this release.
Although the patch updates header file, as far as I can see it doesn't break the
ABI, since added fields either last element of the struct or the part of the
union. But to be sure, can you please double check if I am missing something?
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] ethdev: extend flow metadata
2019-07-14 11:46 0% ` Andrew Rybchenko
@ 2019-07-29 15:06 0% ` Adrien Mazarguil
0 siblings, 0 replies; 200+ results
From: Adrien Mazarguil @ 2019-07-29 15:06 UTC (permalink / raw)
To: Andrew Rybchenko
Cc: Yongseok Koh, Thomas Monjalon, Olivier Matz, Bruce Richardson,
Shahaf Shuler, Ferruh Yigit, dev, Slava Ovsiienko
On Sun, Jul 14, 2019 at 02:46:58PM +0300, Andrew Rybchenko wrote:
> On 11.07.2019 10:44, Adrien Mazarguil wrote:
> > On Wed, Jul 10, 2019 at 04:37:46PM +0000, Yongseok Koh wrote:
> > > > On Jul 10, 2019, at 5:26 AM, Thomas Monjalon <thomas@monjalon.net> wrote:
> > > >
> > > > 10/07/2019 14:01, Bruce Richardson:
> > > > > On Wed, Jul 10, 2019 at 12:07:43PM +0200, Olivier Matz wrote:
> > > > > > On Wed, Jul 10, 2019 at 10:55:34AM +0100, Bruce Richardson wrote:
> > > > > > > On Wed, Jul 10, 2019 at 11:31:56AM +0200, Olivier Matz wrote:
> > > > > > > > On Thu, Jul 04, 2019 at 04:21:22PM -0700, Yongseok Koh wrote:
> > > > > > > > > Currently, metadata can be set on egress path via mbuf tx_meatadata field
> > > > > > > > > with PKT_TX_METADATA flag and RTE_FLOW_ITEM_TYPE_RX_META matches metadata.
> > > > > > > > >
> > > > > > > > > This patch extends the usability.
> > > > > > > > >
> > > > > > > > > 1) RTE_FLOW_ACTION_TYPE_SET_META
> > > > > > > > >
> > > > > > > > > When supporting multiple tables, Tx metadata can also be set by a rule and
> > > > > > > > > matched by another rule. This new action allows metadata to be set as a
> > > > > > > > > result of flow match.
> > > > > > > > >
> > > > > > > > > 2) Metadata on ingress
> > > > > > > > >
> > > > > > > > > There's also need to support metadata on packet Rx. Metadata can be set by
> > > > > > > > > SET_META action and matched by META item like Tx. The final value set by
> > > > > > > > > the action will be delivered to application via mbuf metadata field with
> > > > > > > > > PKT_RX_METADATA ol_flag.
> > > > > > > > >
> > > > > > > > > For this purpose, mbuf->tx_metadata is moved as a separate new field and
> > > > > > > > > renamed to 'metadata' to support both Rx and Tx metadata.
> > > > > > > > >
> > > > > > > > > For loopback/hairpin packet, metadata set on Rx/Tx may or may not be
> > > > > > > > > propagated to the other path depending on HW capability.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
> > > > > > > > > --- a/lib/librte_mbuf/rte_mbuf.h
> > > > > > > > > +++ b/lib/librte_mbuf/rte_mbuf.h
> > > > > > > > > @@ -648,17 +653,6 @@ struct rte_mbuf {
> > > > > > > > > /**< User defined tags. See rte_distributor_process() */
> > > > > > > > > uint32_t usr;
> > > > > > > > > } hash; /**< hash information */
> > > > > > > > > - struct {
> > > > > > > > > - /**
> > > > > > > > > - * Application specific metadata value
> > > > > > > > > - * for egress flow rule match.
> > > > > > > > > - * Valid if PKT_TX_METADATA is set.
> > > > > > > > > - * Located here to allow conjunct use
> > > > > > > > > - * with hash.sched.hi.
> > > > > > > > > - */
> > > > > > > > > - uint32_t tx_metadata;
> > > > > > > > > - uint32_t reserved;
> > > > > > > > > - };
> > > > > > > > > };
> > > > > > > > >
> > > > > > > > > /** Outer VLAN TCI (CPU order), valid if PKT_RX_QINQ is set. */
> > > > > > > > > @@ -727,6 +721,11 @@ struct rte_mbuf {
> > > > > > > > > */
> > > > > > > > > struct rte_mbuf_ext_shared_info *shinfo;
> > > > > > > > >
> > > > > > > > > + /** Application specific metadata value for flow rule match.
> > > > > > > > > + * Valid if PKT_RX_METADATA or PKT_TX_METADATA is set.
> > > > > > > > > + */
> > > > > > > > > + uint32_t metadata;
> > > > > > > > > +
> > > > > > > > > } __rte_cache_aligned;
> > > > > > > > This will break the ABI, so we cannot put it in 19.08, and we need a
> > > > > > > > deprecation notice.
> > > > > > > >
> > > > > > > Does it actually break the ABI? Adding a new field to the mbuf should only
> > > > > > > break the ABI if it either causes new fields to move or changes the
> > > > > > > structure size. Since this is at the end, it's not going to move any older
> > > > > > > fields, and since everything is cache-aligned I don't think the structure
> > > > > > > size changes either.
> > > > > > I think it does break the ABI: in previous version, when the PKT_TX_METADATA
> > > > > > flag is set, the associated value is put in m->tx_metadata (offset 44 on
> > > > > > x86-64), and in the next version, it will be in m->metadata (offset 112). So,
> > > > > > these 2 versions are not binary compatible.
> > > > > >
> > > > > > Anyway, at least it breaks the API.
> > > > > Ok, I misunderstood. I thought it was the structure change itself you were
> > > > > saying broke the ABI. Yes, putting the data in a different place is indeed
> > > > > an ABI break.
> > > > We could add the new field and keep the old one unused,
> > > > so it does not break the ABI.
> > > Still breaks ABI if PKT_TX_METADATA is set. :-) In order not to break it, I can
> > > keep the current union'd field (tx_metadata) as is with PKT_TX_METADATA, add
> > > the new one at the end and make it used with the new PKT_RX_METADATA.
> > >
> > > > However I suppose everybody will prefer a version using dynamic fields.
> > > > Is someone against using dynamic field for such usage?
> > > However, given that the amazing dynamic fields is coming soon (thanks for your
> > > effort, Olivier and Thomas!), I'd be honored to be the first user of it.
> > >
> > > Olivier, I'll take a look at your RFC.
> > Just got a crazy idea while reading this thread... How about repurposing
> > that "reserved" field as "rx_metadata" in the meantime?
>
> It overlaps with hash.fdir.hi which has RSS hash.
While it does overlap with hash.fdir.hi, isn't the RSS hash stored in the
"rss" field overlapping with hash.fdir.lo? (see struct rte_flow_action_rss)
hash.fdir.hi was originally used by FDIR and later repurposed by rte_flow
for its MARK action, which neatly qualifies as Rx metadata so renaming
"reserved" as "rx_metadata" could already make sense.
That is, assuming users do not need two different kinds of Rx metadata
returned simultaneously with their packets. I think it's safe.
> > I know reserved fields are cursed and no one's ever supposed to touch them
> > but this risk is mitigated by having the end user explicitly request its
> > use, so the patch author (and his relatives) should be safe from the
> > resulting bad juju.
> >
> > Joke aside, while I like the idea of Tx/Rx META, I think the similarities
> > with MARK (and TAG eventually) is a problem. I wasn't available and couldn't
> > comment when META was originally added to the Tx path, but there's a lot of
> > overlap between these items/actions, without anything explaining to the end
> > user how and why they should pick one over the other, if they can be
> > combined at all and what happens in that case.
> >
> > All this must be documented, then we should think about unifying their
> > respective features and deprecate the less capable items/actions. In my
> > opinion, users need exactly one method to mark/match some mark while
> > processing Rx/Tx traffic and *optionally* have that mark read from/written
> > to the mbuf, which may or may not be possible depending on HW features.
Thoughts regarding this suggestion? From a user perspective I think all
these actions should be unified but maybe there are good reasons to keep
them separate?
--
Adrien Mazarguil
6WIND
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC] kni: support allmulticast mode set
2019-07-29 13:38 4% ` Ferruh Yigit
@ 2019-07-29 15:25 3% ` Ye Xiaolong
0 siblings, 0 replies; 200+ results
From: Ye Xiaolong @ 2019-07-29 15:25 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: John McNamara, Marko Kovacevic, dev
Hi, Ferruh
On 07/29, Ferruh Yigit wrote:
>On 7/24/2019 4:35 PM, Xiaolong Ye wrote:
>> This patch adds support to allow users enable/disable allmulticast mode for
>> kni interface.
>>
>> This requirement comes from bugzilla 312, more details can refer to:
>> https://bugs.dpdk.org/show_bug.cgi?id=312
>>
>> Bugzilla ID: 312
>>
>> Signed-off-by: Xiaolong Ye <xiaolong.ye@intel.com>
>
>Hi Xiaolong,
>
>Patch lgtm, I think it is too later for this release but I suggest sending v1
>for next release.
Got it, this patch is not that urgent, we can wait for next release.
>
>If there is an ABI breakage, to not block the patch for next release, a
>deprecation notice needs to be sent in this release.
>Although the patch updates header file, as far as I can see it doesn't break the
>ABI, since added fields either last element of the struct or the part of the
>union. But to be sure, can you please double check if I am missing something?
I don't think there is an ABI break either, I'll double check it anyway.
Thanks,
Xiaolong
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC,v3] ethdev: extend RSS offload types
@ 2019-07-30 7:42 4% ` Adrien Mazarguil
0 siblings, 0 replies; 200+ results
From: Adrien Mazarguil @ 2019-07-30 7:42 UTC (permalink / raw)
To: Ori Kam; +Cc: simei, qi.z.zhang, jingjing.wu, ferruh.yigit, dev
On Tue, Jul 30, 2019 at 06:06:56AM +0000, Ori Kam wrote:
> Hi Simei,
>
>
>
> > -----Original Message-----
> > From: dev <dev-bounces@dpdk.org> On Behalf Of simei
> > Sent: Monday, July 29, 2019 5:44 AM
> > To: qi.z.zhang@intel.com; jingjing.wu@intel.com; ferruh.yigit@intel.com;
> > Adrien Mazarguil <adrien.mazarguil@6wind.com>
> > Cc: dev@dpdk.org; simei.su@intel.com
> > Subject: [dpdk-dev] [RFC,v3] ethdev: extend RSS offload types
> >
> > From: Simei Su <simei.su@intel.com>
> >
> > Make it easier to represent to define macro values as (1ULL << ###).
> >
> > This RFC reserves several bits as input set selection from bottom
> > of the 64 bits. The flow type is combined with input set to
> > represent rss types.
> >
>
>
> Why reserve from the bottom? and not from the first available space?
I assume the reason is that maintaining the existing model with
RTE_ETH_FLOW_* sibling macros doesn't make sense for these, so this approach
doesn't impact future ETH_RSS_* definitions...
> > for example:
> > ETH_RSS_IPV4 | ETH_RSS_INSET_L3_SRC: hash on src ip address only
> > ETH_RSS_IPV4_UDP | ETH_RSS_INSET_L4_DST: hash on src/dst IP and
> > dst UDP port
> > ETH_RSS_L2_PAYLOAD | ETH_RSS_INSET_L2_DST: hash on dst mac address
> >
>
> What happens when the user set ETH_RSS_IPV4? From what I understand from your RFC this will do nothing
> since no bits where enabled, am I correct?
> If I'm correct this may break applications.
Also my thought, again I assume that ETH_RSS_INSET_* flags only act as
modifiers to ETH_RSS_IPV4 and friends, if none are provided, then both
source and destination are taken into account. If that's the design, it must
be properly documented still.
Looks like it's time to end the relationship between RTE_ETH_FLOW_* and
ETH_RSS_* seeing both serve different purposes, and these new macros only
make sense for RSS.
I suggest a prior patch that converts all those definitions:
#define ETH_RSS_IPV4 (1ULL << RTE_ETH_FLOW_IPV4)
[...]
To their numerical counterparts directly, in which case we have two options:
Without breaking ABI, e.g.:
#define ETH_RSS_IPV4 (1ULL << 2)
[...]
Or going further if we're ready to break ABI a tiny little bit, starting
over from zero and use unique flags for IPv4, IPv6, TCP and UDP without
distinguishing between NONFRAG, FRAG and IPV6_EX, which never made sense for
RSS, and separating L4 from L3 to save even more, that is:
#define ETH_RSS_ETH (1ULL << 0)
#define ETH_RSS_IPV4 (1ULL << 1)
#define ETH_RSS_IPV6 (1ULL << 2)
#define ETH_RSS_UDP (1ULL << 3)
#define ETH_RSS_TCP (1ULL << 4)
#define ETH_RSS_SCTP (1ULL << 5)
[...]
Then the flags you would like to add would have to be more explicit. I think
Qi's original suggestion with "ONLY" was better in this regard than "INSET":
#define ETH_RSS_L2_SRC_ONLY (1ULL << 6)
#define ETH_RSS_L2_DST_ONLY (1ULL << 7)
[...]
Otherwise there's still the negative approach:
#define ETH_RSS_L2_NO_SRC (1ULL << 6)
#define ETH_RSS_L2_NO_DST (1ULL << 7)
[...]
Not sure which is better. Thoughts?
--
Adrien Mazarguil
6WIND
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: Changes to ABI Policy introducing major ABI versions
2019-07-04 12:26 31% ` [dpdk-dev] [PATCH] doc: " Ray Kinsella
@ 2019-07-30 10:34 10% ` Mcnamara, John
2019-07-30 10:35 5% ` Ray Kinsella
0 siblings, 1 reply; 200+ results
From: Mcnamara, John @ 2019-07-30 10:34 UTC (permalink / raw)
To: Ray Kinsella, dev
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ray Kinsella
> Sent: Thursday, July 4, 2019 1:27 PM
> To: dev@dpdk.org
> Cc: mdr@ashroe.eu
> Subject: [dpdk-dev] [PATCH] doc: Changes to ABI Policy introducing major
> ABI versions
>
> This policy change introduces major ABI versions, these are declared every
> two years, typically aligned with the LTS release and are supported by
> subsequent releases for the next two years.
> This change is intended to improve ABI stabilty for those projects
> consuming DPDK.
>
>...
>
> +A LTS release may align with the declaration of a new major ABI
> +version, please read the `DPDK ABI/API policy`_ for more information.
This should be `<DPDK ABI/API policy>`_ to avoid a build warning/error
since the target contains spaces.
Also, the subject line should be lowercase by convention, apart from acronyms.
$ ./devtools/check-git-log.sh
Wrong headline uppercase:
doc: >C<hanges to ABI Policy introducing major ABI versions
Something like:
doc: changes to ABI policy introducing major ABI versions
John
^ permalink raw reply [relevance 10%]
* Re: [dpdk-dev] [PATCH] doc: Changes to ABI Policy introducing major ABI versions
2019-07-30 10:34 10% ` Mcnamara, John
@ 2019-07-30 10:35 5% ` Ray Kinsella
0 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-07-30 10:35 UTC (permalink / raw)
To: Mcnamara, John, dev
Thanks John,
I will fix it.
Ray K
On 30/07/2019 11:34, Mcnamara, John wrote:
>
>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ray Kinsella
>> Sent: Thursday, July 4, 2019 1:27 PM
>> To: dev@dpdk.org
>> Cc: mdr@ashroe.eu
>> Subject: [dpdk-dev] [PATCH] doc: Changes to ABI Policy introducing major
>> ABI versions
>>
>> This policy change introduces major ABI versions, these are declared every
>> two years, typically aligned with the LTS release and are supported by
>> subsequent releases for the next two years.
>> This change is intended to improve ABI stabilty for those projects
>> consuming DPDK.
>>
>
>
>
>> ...
>>
>> +A LTS release may align with the declaration of a new major ABI
>> +version, please read the `DPDK ABI/API policy`_ for more information.
>
> This should be `<DPDK ABI/API policy>`_ to avoid a build warning/error
> since the target contains spaces.
>
> Also, the subject line should be lowercase by convention, apart from acronyms.
>
> $ ./devtools/check-git-log.sh
> Wrong headline uppercase:
> doc: >C<hanges to ABI Policy introducing major ABI versions
>
> Something like:
>
> doc: changes to ABI policy introducing major ABI versions
>
> John
>
>
^ permalink raw reply [relevance 5%]
* [dpdk-dev] [PATCH v1] doc: update release notes for 19.08
@ 2019-07-30 13:24 14% John McNamara
0 siblings, 0 replies; 200+ results
From: John McNamara @ 2019-07-30 13:24 UTC (permalink / raw)
To: dev; +Cc: thomas, John McNamara
Fix grammar, spelling and formatting of DPDK 19.08 release notes.
Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
doc/guides/rel_notes/release_19_08.rst | 126 ++++++++++++++++-----------------
1 file changed, 63 insertions(+), 63 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_08.rst b/doc/guides/rel_notes/release_19_08.rst
index fcd1386..78df3e1 100644
--- a/doc/guides/rel_notes/release_19_08.rst
+++ b/doc/guides/rel_notes/release_19_08.rst
@@ -58,20 +58,20 @@ New Features
* **EAL will now pick IOVA as VA mode as the default in most cases.**
- Previously, preferred default IOVA mode was selected to be IOVA as PA. The
+ Previously, the preferred default IOVA mode was selected to be IOVA as PA. The
behavior has now been changed to handle IOVA mode detection in a more complex
manner, and will default to IOVA as VA in most cases.
* **Added MCS lock.**
MCS lock provides scalability by spinning on a CPU/thread local variable
- which avoids expensive cache bouncings.
+ which avoids expensive cache bouncing.
It provides fairness by maintaining a list of acquirers and passing
the lock to each CPU/thread in the order they acquired the lock.
* **Updated the EAL Pseudo-random Number Generator.**
- The lrand48()-based rte_rand() function is replaced with a
+ The ``lrand48()`` based ``rte_rand()`` function is replaced with a
DPDK-native combined Linear Feedback Shift Register (LFSR)
pseudo-random number generator (PRNG).
@@ -79,33 +79,33 @@ New Features
higher-quality pseudo-random numbers (including full 64 bit
support) and improved performance.
- In addition, <rte_random.h> is extended with a new function
- rte_rand_max() which supplies unbiased, bounded pseudo-random
+ In addition, ``<rte_random.h>`` is extended with a new function
+ ``rte_rand_max()`` which supplies unbiased, bounded pseudo-random
numbers.
-* **Updated the bnxt PMD.**
+* **Updated the Broadcom bnxt PMD.**
- Updated the bnxt PMD. The major enhancements include:
+ Updated the Broadcom bnxt PMD. The major enhancements include:
- * Performance optimizations in non-vector Tx path
- * Added support for SSE vector mode
- * Updated HWRM API to version 1.10.0.91
+ * Performance optimizations in non-vector Tx path.
+ * Added support for SSE vector mode.
+ * Updated HWRM API to version 1.10.0.91.
* **Added support for Broadcom NetXtreme-E BCM57500 Ethernet controllers.**
- Added support to the bnxt PMD for the BCM57500 (a.k.a. "Thor") family
+ Added support to the Broadcom bnxt PMD for the BCM57500 (a.k.a. "Thor") family
of Ethernet controllers. These controllers support link speeds up to
200Gbps, 50G PAM-4, and PCIe 4.0.
-* **Added hinic PMD.**
+* **Added Huawei hinic PMD.**
Added the new ``hinic`` net driver for Huawei Intelligent PCIE Network
Adapters based on the Huawei Ethernet Controller Hi1822.
See the :doc:`../nics/hinic` guide for more details on this new driver.
-* **Updated the ice driver.**
+* **Updated the Intel ice driver.**
- Updated ice driver with new features and improvements, including:
+ Updated the Intel ice driver with new features and improvements, including:
* Enabled Tx outer/inner L3/L4 checksum offload.
* Enabled generic filter framework and supported switch filter.
@@ -120,8 +120,8 @@ New Features
* Added support for match on ICMP/ICMP6 code and type.
* Added support for matching on GRE's key and C,K,S present bits.
* Added support for IP-in-IP tunnel.
- * Accelerate flows with count action creation and destroy.
- * Accelerate flows counter query.
+ * Accelerated flows with count action creation and destroy.
+ * Accelerated flows counter query.
* Improved Tx datapath performance with enabled HW offloads.
* Added support for LRO.
@@ -133,7 +133,7 @@ New Features
* **Added memif PMD.**
- Added the new Shared Memory Packet Interface (``memif``) PMD.
+ Added a new Shared Memory Packet Interface (``memif``) PMD.
See the :doc:`../nics/memif` guide for more details on this new driver.
* **Updated the AF_XDP PMD.**
@@ -141,31 +141,31 @@ New Features
Updated the AF_XDP PMD. The new features include:
* Enabled zero copy through mbuf's external memory mechanism to achieve
- high performance
+ higher performance.
* Added multi-queue support to allow one af_xdp vdev with multiple netdev
- queues
- * Enabled need_wakeup feature which can provide efficient support for case
- that application and driver executing on the same core.
+ queues.
+ * Enabled "need_wakeup" feature which can provide efficient support for the
+ usecase where the application and driver executing on the same core.
* **Enabled infinite Rx in the PCAP PMD.**
- Added an infinite Rx feature which allows packets in the Rx PCAP of a PCAP
- device to be received repeatedly at a high rate. This can be useful for quick
+ Added an infinite Rx feature to the PCAP PMD which allows packets in the Rx
+ PCAP to be received repeatedly at a high rate. This can be useful for quick
performance testing of DPDK apps.
-* **Enabled Receiving no packet on PCAP Rx.**
+* **Enabled receiving no packet in the PCAP PMD.**
- Added function to allow users to run without receiving any packets on PCAP Rx.
- When function is called, a dummy queue is created for each Tx queue argument
- passed.
+ Added function to allow users to run the PCAP PMD without receiving any
+ packets on PCAP Rx. When the function is called, a dummy queue is created
+ for each Tx queue argument passed.
* **Added a FPGA_LTE_FEC bbdev PMD.**
- Added the new ``fpga_lte_fec`` bbdev driver for the Intel® FPGA PAC
+ Added a new ``fpga_lte_fec`` bbdev driver for the Intel\ |reg| FPGA PAC
(Programmable Acceleration Card) N3000. See the
:doc:`../bbdevs/fpga_lte_fec` BBDEV guide for more details on this new driver.
-* **Updated TURBO_SW bbdev PMD.**
+* **Updated the TURBO_SW bbdev PMD.**
Updated the ``turbo_sw`` bbdev driver with changes including:
@@ -173,17 +173,17 @@ New Features
SDK libraries.
* Added support for 5GNR encode/decode operations.
-* **Updated the QuickAssist Technology (QAT) symmetric crypto PMD.**
+* **Updated the Intel QuickAssist Technology (QAT) symmetric crypto PMD.**
Added support for digest-encrypted cases where digest is appended
to the data.
-* **Added Intel QuickData Technology PMD**
+* **Added the Intel QuickData Technology PMD.**
- The PMD for Intel\ |reg| QuickData Technology, part of
+ Added a PMD for the Intel\ |reg| QuickData Technology, part of
Intel\ |reg| I/O Acceleration Technology `(Intel I/OAT)
<https://www.intel.com/content/www/us/en/wireless-network/accel-technology.html>`_,
- allows data copies to be done by hardware instead
+ which allows data copies to be done by hardware instead
of via software, reducing cycles spent copying large blocks of data in
applications.
@@ -191,25 +191,25 @@ New Features
Added the new ``ethdev``, ``eventdev``, ``mempool``, ``eventdev Rx adapter``,
``eventdev Tx adapter``, ``eventdev Timer adapter`` and ``rawdev DMA``
- drivers for various HW coprocessors available in ``OCTEON TX2`` SoC.
+ drivers for various HW co-processors available in ``OCTEON TX2`` SoC.
- See :doc:`../platform/octeontx2` and driver informations:
+ See :doc:`../platform/octeontx2` and driver information:
* :doc:`../nics/octeontx2`
* :doc:`../mempool/octeontx2`
* :doc:`../eventdevs/octeontx2`
* :doc:`../rawdevs/octeontx2_dma`
-* **Introduced NTB PMD.**
+* **Introduced the Intel NTB PMD.**
- Added a PMD for Intel NTB (Non-transparent Bridge). This PMD implemented
- handshake between two separate hosts and can share local memory for peer
+ Added a PMD for Intel NTB (Non-transparent Bridge). This PMD implements
+ a handshake between two separate hosts and can share local memory for peer
host to directly access.
-* **Updated IPSec library and IPsec Security Gateway application.**
+* **Updated the IPSec library and IPsec Security Gateway application.**
Added the following features to ``librte_ipsec``. Corresponding changes are
- also added in ``ipsec-secgw`` sample application.
+ also added in the ``ipsec-secgw`` sample application.
* ECN and DSCP field header reconstruction as per RFC4301.
* Transport mode with IPv6 extension headers.
@@ -222,8 +222,8 @@ New Features
* **Added new telemetry mode for l3fwd-power application.**
- Added telemetry mode to l3fwd-power application to report
- application level busyness, empty and full polls of rte_eth_rx_burst().
+ Added a telemetry mode to the ``l3fwd-power`` application to report
+ application level busyness, empty and full polls of ``rte_eth_rx_burst()``.
* **Updated the pdump application.**
@@ -231,7 +231,7 @@ New Features
* **Updated test-compress-perf tool application.**
- Added multiple cores feature to compression perf tool application.
+ Added a multiple cores feature to the compression perf tool application.
Removed Items
@@ -246,7 +246,7 @@ Removed Items
Also, make sure to start the actual text at the margin.
=========================================================
-* Removed KNI ethtool, CONFIG_RTE_KNI_KMOD_ETHTOOL, support.
+* Removed KNI ethtool, ``CONFIG_RTE_KNI_KMOD_ETHTOOL``, support.
* build: armv8 crypto extension is disabled.
@@ -266,17 +266,17 @@ API Changes
Also, make sure to start the actual text at the margin.
=========================================================
-* The ``rte_mem_config`` structure has been made private. The new accessor
+* The ``rte_mem_config`` structure has been made private. New accessor
``rte_mcfg_*`` functions were introduced to provide replacement for direct
access to the shared mem config.
* The network structures, definitions and functions have
been prefixed by ``rte_`` to resolve conflicts with libc headers.
-* malloc: The function ``rte_malloc_set_limit`` was never implemented
- is deprecated and will be removed in a future release.
+* malloc: The function ``rte_malloc_set_limit()`` was never implemented.
+ It is deprecated and will be removed in a future release.
-* cryptodev: the ``uint8_t *data`` member of ``key`` structure in the xforms
+* cryptodev: the ``uint8_t *data`` member of the ``key`` structure in the xforms
structure (``rte_crypto_cipher_xform``, ``rte_crypto_auth_xform``, and
``rte_crypto_aead_xform``) have been changed to ``const uint8_t *data``.
@@ -287,8 +287,8 @@ API Changes
announced at least one release before the ABI change is made. There are no
ABI breaking changes planned.
-* ip_frag: IP fragmentation library converts input mbuf into fragments
- using input MTU size via ``rte_ipv4_fragment_packet`` interface.
+* ip_frag: The IP fragmentation library converts input mbuf into fragments
+ using input MTU size via the ``rte_ipv4_fragment_packet()`` interface.
Once fragmentation is done, each ``mbuf->ol_flags`` are set to enable IP
checksum H/W offload irrespective of the platform capability.
Cleared IP checksum H/W offload flag from the library. The application must
@@ -296,7 +296,7 @@ API Changes
use it.
* ip_frag: IP reassembly library converts the list of fragments into a
- reassembled packet via ``rte_ipv4_frag_reassemble_packet`` interface.
+ reassembled packet via ``rte_ipv4_frag_reassemble_packet()`` interface.
Once reassembly is done, ``mbuf->ol_flags`` are set to enable IP checksum H/W
offload irrespective of the platform capability. Cleared IP checksum H/W
offload flag from the library. The application must set this flag if it is
@@ -305,10 +305,11 @@ API Changes
* sched: Macros ``RTE_SCHED_QUEUES_PER_TRAFFIC_CLASS`` and
``RTE_SCHED_PIPE_PROFILES_PER_PORT`` are removed for flexible configuration
of pipe traffic classes and their queues size, and for runtime configuration
- of maximum number of pipe profiles, respectively. In addtion, wrr_weights
- field of struct ``rte_sched_pipe_params`` is modifed to be used only for
- best-effort tc, and qsize field of struct ``rte_sched_port_params`` is
- changed to allow different size of the each queue.
+ of the maximum number of pipe profiles, respectively. In addition, the
+ ``wrr_weights`` field of struct ``rte_sched_pipe_params`` is modified to be
+ used only for best-effort tc, and the ``qsize`` field of struct
+ ``rte_sched_port_params`` is changed to allow different sizes for each
+ queue.
ABI Changes
@@ -342,14 +343,14 @@ ABI Changes
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``
+ - ``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.
-* bbdev: New operations and parameters added to support new 5GNR operations.
- The bbdev ABI is still kept experimental.
+* bbdev: New operations and parameters have been added to support new 5GNR
+ operations. The bbdev ABI is still kept experimental.
Shared Library Versions
@@ -444,11 +445,11 @@ Known Issues
Also, make sure to start the actual text at the margin.
=========================================================
-* **Unsuitable IOVA mode may be picked as the default**
+* **Unsuitable IOVA mode may be picked as the default.**
Not all kernel drivers and not all devices support all IOVA modes. EAL will
attempt to pick a reasonable default based on a number of factors, but
- there may be cases where the default may be unsuitable.
+ there may be cases where the default is unsuitable.
It is recommended to use the `--iova-mode` command-line parameter if the
default is not suitable.
@@ -472,4 +473,3 @@ Tested Platforms
This section is a comment. Do not overwrite or remove it.
Also, make sure to start the actual text at the margin.
=========================================================
-
--
2.7.5
^ permalink raw reply [relevance 14%]
* [dpdk-dev] [PATCH v2 2/2] drivers/raw: standardize naming
@ 2019-07-30 13:39 7% ` Thomas Monjalon
2019-07-31 7:29 0% ` Xu, Rosen
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-07-30 13:39 UTC (permalink / raw)
To: dev, John McNamara, Marko Kovacevic, Nipun Gupta, Rosen Xu,
Tianfei zhang, Bruce Richardson, Xiaoyun Li, Jingjing Wu,
Satha Rao, Vamsi Attunuru, Shreyansh Jain, Hemant Agrawal
Cc: Neil Horman
From: Bruce Richardson <bruce.richardson@intel.com>
The driver names for rawdevs were both different in make and meson builds
and were non-standard in the make version in that some included "rawdev" in
the name while others didn't.
Therefore, for global consistency of naming, we can use "rte_rawdev" rather
than "rte_pmd" for the prefix for the libraries. While most other driver
categories use "rte_pmd" as a prefix, there is precedent for this in the
mempool drivers use "rte_mempool" as a prefix.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
doc/guides/rel_notes/release_19_08.rst | 3 +++
drivers/raw/dpaa2_cmdif/Makefile | 4 ++--
...sion.map => rte_rawdev_dpaa2_cmdif_version.map} | 0
drivers/raw/dpaa2_qdma/Makefile | 4 ++--
...rsion.map => rte_rawdev_dpaa2_qdma_version.map} | 0
drivers/raw/ifpga/Makefile | 4 ++--
...ga_version.map => rte_rawdev_ifpga_version.map} | 0
drivers/raw/ioat/Makefile | 4 ++--
...oat_version.map => rte_rawdev_ioat_version.map} | 0
drivers/raw/meson.build | 2 +-
drivers/raw/ntb/Makefile | 4 ++--
..._ntb_version.map => rte_rawdev_ntb_version.map} | 0
drivers/raw/octeontx2_dma/Makefile | 4 ++--
...on.map => rte_rawdev_octeontx2_dma_version.map} | 0
drivers/raw/skeleton/Makefile | 4 ++--
...version.map => rte_rawdev_skeleton_version.map} | 0
mk/rte.app.mk | 14 +++++++-------
17 files changed, 25 insertions(+), 22 deletions(-)
rename drivers/raw/dpaa2_cmdif/{rte_pmd_dpaa2_cmdif_version.map => rte_rawdev_dpaa2_cmdif_version.map} (100%)
rename drivers/raw/dpaa2_qdma/{rte_pmd_dpaa2_qdma_version.map => rte_rawdev_dpaa2_qdma_version.map} (100%)
rename drivers/raw/ifpga/{rte_pmd_ifpga_version.map => rte_rawdev_ifpga_version.map} (100%)
rename drivers/raw/ioat/{rte_pmd_ioat_version.map => rte_rawdev_ioat_version.map} (100%)
rename drivers/raw/ntb/{rte_pmd_ntb_version.map => rte_rawdev_ntb_version.map} (100%)
rename drivers/raw/octeontx2_dma/{rte_pmd_octeontx2_dma_version.map => rte_rawdev_octeontx2_dma_version.map} (100%)
rename drivers/raw/skeleton/{rte_pmd_skeleton_version.map => rte_rawdev_skeleton_version.map} (100%)
diff --git a/doc/guides/rel_notes/release_19_08.rst b/doc/guides/rel_notes/release_19_08.rst
index fcd1386a5..13a98f520 100644
--- a/doc/guides/rel_notes/release_19_08.rst
+++ b/doc/guides/rel_notes/release_19_08.rst
@@ -351,6 +351,9 @@ ABI Changes
* bbdev: New operations and parameters added to support new 5GNR operations.
The bbdev ABI is still kept experimental.
+* rawdev: The driver names have been changed to ``librte_rawdev_*``.
+ Now they all have the same prefix, and same name with make and meson builds.
+
Shared Library Versions
-----------------------
diff --git a/drivers/raw/dpaa2_cmdif/Makefile b/drivers/raw/dpaa2_cmdif/Makefile
index 9bd5ff229..2b4150c2d 100644
--- a/drivers/raw/dpaa2_cmdif/Makefile
+++ b/drivers/raw/dpaa2_cmdif/Makefile
@@ -6,7 +6,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
#
# library name
#
-LIB = librte_pmd_dpaa2_cmdif.a
+LIB = librte_rawdev_dpaa2_cmdif.a
CFLAGS += -DALLOW_EXPERIMENTAL_API
CFLAGS += -O3
@@ -23,7 +23,7 @@ LDLIBS += -lrte_mempool_dpaa2
LDLIBS += -lrte_rawdev
LDLIBS += -lrte_common_dpaax
-EXPORT_MAP := rte_pmd_dpaa2_cmdif_version.map
+EXPORT_MAP := rte_rawdev_dpaa2_cmdif_version.map
LIBABIVER := 2
diff --git a/drivers/raw/dpaa2_cmdif/rte_pmd_dpaa2_cmdif_version.map b/drivers/raw/dpaa2_cmdif/rte_rawdev_dpaa2_cmdif_version.map
similarity index 100%
rename from drivers/raw/dpaa2_cmdif/rte_pmd_dpaa2_cmdif_version.map
rename to drivers/raw/dpaa2_cmdif/rte_rawdev_dpaa2_cmdif_version.map
diff --git a/drivers/raw/dpaa2_qdma/Makefile b/drivers/raw/dpaa2_qdma/Makefile
index f9a810cc6..0009fd4c6 100644
--- a/drivers/raw/dpaa2_qdma/Makefile
+++ b/drivers/raw/dpaa2_qdma/Makefile
@@ -6,7 +6,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
#
# library name
#
-LIB = librte_pmd_dpaa2_qdma.a
+LIB = librte_rawdev_dpaa2_qdma.a
CFLAGS += -DALLOW_EXPERIMENTAL_API
CFLAGS += -O3
@@ -24,7 +24,7 @@ LDLIBS += -lrte_kvargs
LDLIBS += -lrte_ring
LDLIBS += -lrte_common_dpaax
-EXPORT_MAP := rte_pmd_dpaa2_qdma_version.map
+EXPORT_MAP := rte_rawdev_dpaa2_qdma_version.map
LIBABIVER := 3
diff --git a/drivers/raw/dpaa2_qdma/rte_pmd_dpaa2_qdma_version.map b/drivers/raw/dpaa2_qdma/rte_rawdev_dpaa2_qdma_version.map
similarity index 100%
rename from drivers/raw/dpaa2_qdma/rte_pmd_dpaa2_qdma_version.map
rename to drivers/raw/dpaa2_qdma/rte_rawdev_dpaa2_qdma_version.map
diff --git a/drivers/raw/ifpga/Makefile b/drivers/raw/ifpga/Makefile
index 5fa9303d5..655b29288 100644
--- a/drivers/raw/ifpga/Makefile
+++ b/drivers/raw/ifpga/Makefile
@@ -6,7 +6,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
#
# library name
#
-LIB = librte_pmd_ifpga_rawdev.a
+LIB = librte_rawdev_ifpga.a
CFLAGS += -DALLOW_EXPERIMENTAL_API
CFLAGS += -O3
@@ -21,7 +21,7 @@ LDLIBS += -lrte_kvargs
LDLIBS += -lrte_bus_pci
LDLIBS += -lrte_bus_ifpga
-EXPORT_MAP := rte_pmd_ifpga_version.map
+EXPORT_MAP := rte_rawdev_ifpga_version.map
LIBABIVER := 1
diff --git a/drivers/raw/ifpga/rte_pmd_ifpga_version.map b/drivers/raw/ifpga/rte_rawdev_ifpga_version.map
similarity index 100%
rename from drivers/raw/ifpga/rte_pmd_ifpga_version.map
rename to drivers/raw/ifpga/rte_rawdev_ifpga_version.map
diff --git a/drivers/raw/ioat/Makefile b/drivers/raw/ioat/Makefile
index 32f079845..e852afb57 100644
--- a/drivers/raw/ioat/Makefile
+++ b/drivers/raw/ioat/Makefile
@@ -4,7 +4,7 @@
include $(RTE_SDK)/mk/rte.vars.mk
# library name
-LIB = librte_pmd_ioat_rawdev.a
+LIB = librte_rawdev_ioat.a
# build flags
CFLAGS += -O3
@@ -18,7 +18,7 @@ LDLIBS += -lrte_mbuf -lrte_mempool
LIBABIVER := 1
# versioning export map
-EXPORT_MAP := rte_pmd_ioat_version.map
+EXPORT_MAP := rte_rawdev_ioat_version.map
# library source files
SRCS-$(CONFIG_RTE_LIBRTE_PMD_IOAT_RAWDEV) += ioat_rawdev.c
diff --git a/drivers/raw/ioat/rte_pmd_ioat_version.map b/drivers/raw/ioat/rte_rawdev_ioat_version.map
similarity index 100%
rename from drivers/raw/ioat/rte_pmd_ioat_version.map
rename to drivers/raw/ioat/rte_rawdev_ioat_version.map
diff --git a/drivers/raw/meson.build b/drivers/raw/meson.build
index bcd5553e1..d7037cd87 100644
--- a/drivers/raw/meson.build
+++ b/drivers/raw/meson.build
@@ -7,4 +7,4 @@ drivers = ['dpaa2_cmdif', 'dpaa2_qdma',
'skeleton']
std_deps = ['rawdev']
config_flag_fmt = 'RTE_LIBRTE_PMD_@0@_RAWDEV'
-driver_name_fmt = 'rte_pmd_@0@'
+driver_name_fmt = 'rte_rawdev_@0@'
diff --git a/drivers/raw/ntb/Makefile b/drivers/raw/ntb/Makefile
index edd49fe75..6fe2aaf40 100644
--- a/drivers/raw/ntb/Makefile
+++ b/drivers/raw/ntb/Makefile
@@ -6,7 +6,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
#
# library name
#
-LIB = librte_pmd_ntb.a
+LIB = librte_rawdev_ntb.a
CFLAGS += -DALLOW_EXPERIMENTAL_API
CFLAGS += -O3
@@ -15,7 +15,7 @@ LDLIBS += -lrte_eal -lrte_mbuf -lrte_mempool
LDLIBS += -lrte_pci -lrte_bus_pci
LDLIBS += -lrte_rawdev
-EXPORT_MAP := rte_pmd_ntb_version.map
+EXPORT_MAP := rte_rawdev_ntb_version.map
LIBABIVER := 1
diff --git a/drivers/raw/ntb/rte_pmd_ntb_version.map b/drivers/raw/ntb/rte_rawdev_ntb_version.map
similarity index 100%
rename from drivers/raw/ntb/rte_pmd_ntb_version.map
rename to drivers/raw/ntb/rte_rawdev_ntb_version.map
diff --git a/drivers/raw/octeontx2_dma/Makefile b/drivers/raw/octeontx2_dma/Makefile
index 96f782eb6..f101e4916 100644
--- a/drivers/raw/octeontx2_dma/Makefile
+++ b/drivers/raw/octeontx2_dma/Makefile
@@ -5,7 +5,7 @@
include $(RTE_SDK)/mk/rte.vars.mk
# library name
-LIB = librte_pmd_octeontx2_dma.a
+LIB = librte_rawdev_octeontx2_dma.a
CFLAGS += -O3 $(WERROR_FLAGS)
CFLAGS += -I$(RTE_SDK)/drivers/common/octeontx2/
@@ -22,7 +22,7 @@ CFLAGS += -diag-disable 2259
endif
endif
-EXPORT_MAP := rte_pmd_octeontx2_dma_version.map
+EXPORT_MAP := rte_rawdev_octeontx2_dma_version.map
LIBABIVER := 1
diff --git a/drivers/raw/octeontx2_dma/rte_pmd_octeontx2_dma_version.map b/drivers/raw/octeontx2_dma/rte_rawdev_octeontx2_dma_version.map
similarity index 100%
rename from drivers/raw/octeontx2_dma/rte_pmd_octeontx2_dma_version.map
rename to drivers/raw/octeontx2_dma/rte_rawdev_octeontx2_dma_version.map
diff --git a/drivers/raw/skeleton/Makefile b/drivers/raw/skeleton/Makefile
index 9641e6505..783b1e952 100644
--- a/drivers/raw/skeleton/Makefile
+++ b/drivers/raw/skeleton/Makefile
@@ -6,7 +6,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
#
# library name
#
-LIB = librte_pmd_skeleton_rawdev.a
+LIB = librte_rawdev_skeleton.a
CFLAGS += -O3
CFLAGS += $(WERROR_FLAGS)
@@ -15,7 +15,7 @@ LDLIBS += -lrte_rawdev
LDLIBS += -lrte_bus_vdev
LDLIBS += -lrte_kvargs
-EXPORT_MAP := rte_pmd_skeleton_version.map
+EXPORT_MAP := rte_rawdev_skeleton_version.map
LIBABIVER := 1
diff --git a/drivers/raw/skeleton/rte_pmd_skeleton_version.map b/drivers/raw/skeleton/rte_rawdev_skeleton_version.map
similarity index 100%
rename from drivers/raw/skeleton/rte_pmd_skeleton_version.map
rename to drivers/raw/skeleton/rte_rawdev_skeleton_version.map
diff --git a/mk/rte.app.mk b/mk/rte.app.mk
index a277c808e..ba5c39e01 100644
--- a/mk/rte.app.mk
+++ b/mk/rte.app.mk
@@ -312,19 +312,19 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_OPDL_EVENTDEV) += -lrte_pmd_opdl_event
endif # CONFIG_RTE_LIBRTE_EVENTDEV
ifeq ($(CONFIG_RTE_LIBRTE_RAWDEV),y)
-_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_SKELETON_RAWDEV) += -lrte_pmd_skeleton_rawdev
+_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_SKELETON_RAWDEV) += -lrte_rawdev_skeleton
ifeq ($(CONFIG_RTE_EAL_VFIO)$(CONFIG_RTE_LIBRTE_FSLMC_BUS),yy)
-_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_DPAA2_CMDIF_RAWDEV) += -lrte_pmd_dpaa2_cmdif
-_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_DPAA2_QDMA_RAWDEV) += -lrte_pmd_dpaa2_qdma
+_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_DPAA2_CMDIF_RAWDEV) += -lrte_rawdev_dpaa2_cmdif
+_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_DPAA2_QDMA_RAWDEV) += -lrte_rawdev_dpaa2_qdma
endif # CONFIG_RTE_LIBRTE_FSLMC_BUS
_LDLIBS-$(CONFIG_RTE_LIBRTE_IFPGA_BUS) += -lrte_bus_ifpga
ifeq ($(CONFIG_RTE_LIBRTE_IFPGA_BUS),y)
-_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_IFPGA_RAWDEV) += -lrte_pmd_ifpga_rawdev
+_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_IFPGA_RAWDEV) += -lrte_rawdev_ifpga
_LDLIBS-$(CONFIG_RTE_LIBRTE_IPN3KE_PMD) += -lrte_pmd_ipn3ke
endif # CONFIG_RTE_LIBRTE_IFPGA_BUS
-_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_IOAT_RAWDEV) += -lrte_pmd_ioat_rawdev
-_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_NTB_RAWDEV) += -lrte_pmd_ntb
-_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_DMA_RAWDEV) += -lrte_pmd_octeontx2_dma
+_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_IOAT_RAWDEV) += -lrte_rawdev_ioat
+_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_NTB_RAWDEV) += -lrte_rawdev_ntb
+_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_DMA_RAWDEV) += -lrte_rawdev_octeontx2_dma
endif # CONFIG_RTE_LIBRTE_RAWDEV
endif # !CONFIG_RTE_BUILD_SHARED_LIBS
--
2.21.0
^ permalink raw reply [relevance 7%]
* Re: [dpdk-dev] [RFC 19.11 1/2] ethdev: make DPDK core functions non-inline
@ 2019-07-30 15:01 3% ` Jerin Jacob Kollanukkaran
2019-07-30 15:32 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-07-30 15:01 UTC (permalink / raw)
To: Marcin Zapolski, dev
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Marcin Zapolski
> Sent: Tuesday, July 30, 2019 6:20 PM
> To: dev@dpdk.org
> Cc: Marcin Zapolski <marcinx.a.zapolski@intel.com>
> Subject: [dpdk-dev] [RFC 19.11 1/2] ethdev: make DPDK core functions non-
> inline
>
> Make rte_eth_rx_burst, rte_eth_tx_burst and other static inline ethdev
> functions not inline. They are referencing DPDK internal structures and
> inlining forces those structures to be exposed to user applications.
>
> In internal testing with i40e NICs a performance drop of about 2% was
> observed with testpmd.
I tested on two class of arm64 machines(Highend and lowend) one has 1.4% drop
And other one has 3.6% drop.
I second to not expose internal data structure to avoid ABI break.
IMO, This patch has performance issue due to it is fixing it in simple way.
It is not worth two have function call overhead to call the driver function.
Some thoughts below to reduce the performance impact without exposing internal
structures.
And I think, We need to follow the similar mechanism for cryptodev, Eventdev, rawdev
Etc so bring the common scheme to address this semantics will be use full.
>
> Signed-off-by: Marcin Zapolski <marcinx.a.zapolski@intel.com>
> ---
> lib/librte_ethdev/rte_ethdev.c | 168 +++++++++++++++++++++++
> lib/librte_ethdev/rte_ethdev.h | 166 ++--------------------
> lib/librte_ethdev/rte_ethdev_version.map | 12 ++
> 3 files changed, 195 insertions(+), 151 deletions(-)
>
> diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
> index 17d183e1f..31432a956 100644
> --- a/lib/librte_ethdev/rte_ethdev.c
> +++ b/lib/librte_ethdev/rte_ethdev.c
> @@ -749,6 +749,174 @@ rte_eth_dev_get_sec_ctx(uint16_t port_id)
> return rte_eth_devices[port_id].security_ctx;
> }
>
> +uint16_t
> +rte_eth_rx_burst(uint16_t port_id, uint16_t queue_id,
> + struct rte_mbuf **rx_pkts, const uint16_t nb_pkts) {
> + struct rte_eth_dev *dev = &rte_eth_devices[port_id];
> + uint16_t nb_rx;
I think, we only need to store 3 function pointers per port.
IMO, Let have structure for that.
i.e split the struct rte_eth_dev content as public and private.
I think, We nee only following elements in rte_eth_dev
struct rte_eth_dev_fns {
eth_rx_burst_t rx_pkt_burst; /**< Pointer to PMD receive function. */
eth_tx_burst_t tx_pkt_burst; /**< Pointer to PMD transmit function. */
eth_tx_prep_t tx_pkt_prepare; /**< Pointer to PMD transmit prepare function. *
};
struct rte_eth_dev {
struct rte_eth_dev_fns fns; // make it as first item allows type cast to struct rte_eth_dev_fns from struct rte_eth_dev
private ones
}
> +
> +#ifdef RTE_LIBRTE_ETHDEV_DEBUG
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
> + RTE_FUNC_PTR_OR_ERR_RET(*dev->rx_pkt_burst, 0);
> +
> + if (queue_id >= dev->data->nb_rx_queues) {
> + RTE_ETHDEV_LOG(ERR, "Invalid RX queue_id=%u\n",
> queue_id);
> + return 0;
> + }
> +#endif
> + nb_rx = (*dev->rx_pkt_burst)(dev->data->rx_queues[queue_id],
I think, if we make driver funtions as (*dev->rx_pkt_burst)(dev, rx_pkts, nb_pkts)
Then no need to deference data from inline function.
Lets expose a helper function from driver layer and let PMD use to access queue memory.
No need to expose that helper to user app.
> + rx_pkts, nb_pkts);
> +
> +#ifdef RTE_ETHDEV_RXTX_CALLBACKS
# If we have ethdev driver helper function for the same and PMD can call it as well no need
to call this inline function.
# I think, it make sense to as RX_OFFLOAD_FLAGS so that when app needs only
It can be included in fastpath.
# lastly we are not exposing rte_eth_dev to application then I think we can
Remove rte_ from name.
> + if (unlikely(dev->post_rx_burst_cbs[queue_id] != NULL)) {
> + struct rte_eth_rxtx_callback *cb =
> + dev->post_rx_burst_cbs[queue_id];
> +
> + do {
> + nb_rx = cb->fn.rx(port_id, queue_id, rx_pkts, nb_rx,
> + nb_pkts, cb->param);
> + cb = cb->next;
> + } while (cb != NULL);
> + }
> +#endif
> +
> + return nb_rx;
> +}
> +
>
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC 19.11 1/2] ethdev: make DPDK core functions non-inline
2019-07-30 15:01 3% ` Jerin Jacob Kollanukkaran
@ 2019-07-30 15:32 0% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2019-07-30 15:32 UTC (permalink / raw)
To: Jerin Jacob Kollanukkaran; +Cc: Marcin Zapolski, dev
On Tue, Jul 30, 2019 at 03:01:00PM +0000, Jerin Jacob Kollanukkaran wrote:
> > -----Original Message----- From: dev <dev-bounces@dpdk.org> On Behalf
> > Of Marcin Zapolski Sent: Tuesday, July 30, 2019 6:20 PM To:
> > dev@dpdk.org Cc: Marcin Zapolski <marcinx.a.zapolski@intel.com>
> > Subject: [dpdk-dev] [RFC 19.11 1/2] ethdev: make DPDK core functions
> > non- inline
> >
> > Make rte_eth_rx_burst, rte_eth_tx_burst and other static inline ethdev
> > functions not inline. They are referencing DPDK internal structures and
> > inlining forces those structures to be exposed to user applications.
> >
> > In internal testing with i40e NICs a performance drop of about 2% was
> > observed with testpmd.
>
> I tested on two class of arm64 machines(Highend and lowend) one has 1.4%
> drop And other one has 3.6% drop.
>
This is with testpmd only right? I'd just point out that we need to
remember that these numbers need to be scaled down appropriately for a
realworld app where IO is only a (hopefully small) proportion of the packet
processing budget. For example, I would expect the ~2% drop we saw in
testpmd to correspond to <0.5% drop in something like OVS.
> I second to not expose internal data structure to avoid ABI break.
>
> IMO, This patch has performance issue due to it is fixing it in simple
> way.
>
> It is not worth two have function call overhead to call the driver
> function. Some thoughts below to reduce the performance impact without
> exposing internal structures.
>
The big concern I have with what you propose is that would involve changing
each and every ethdev driver in DPDK! I'd prefer to make sure that the
impact of this change is actually felt in real-world apps before we start
looking to make such updates across the DPDK codebase.
> And I think, We need to follow the similar mechanism for cryptodev, Eventdev, rawdev
> Etc so bring the common scheme to address this semantics will be use full.
>
Agreed.
Regards,
/Bruce
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [dpdk-stable] [PATCH] librte_flow_classify: fix out-of-bounds access
@ 2019-07-30 15:43 2% ` Aaron Conole
2019-07-30 16:55 0% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Aaron Conole @ 2019-07-30 15:43 UTC (permalink / raw)
To: Ferruh Yigit
Cc: David Marchand, Bernard Iremonger, dev, dpdk stable,
Thomas Monjalon, Singh, Jasvinder, Flavia Musatescu,
Adrien Mazarguil
Ferruh Yigit <ferruh.yigit@intel.com> writes:
> On 7/30/2019 3:42 PM, Aaron Conole wrote:
>> David Marchand <david.marchand@redhat.com> writes:
>>
>>> On Wed, Jul 10, 2019 at 11:49 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>>>>
>>>> 09/07/2019 13:09, Bernard Iremonger:
>>>>> This patch fixes the out-of-bounds coverity issue by removing the
>>>>> offending line of code at line 107 in rte_flow_classify_parse.c
>>>>> which is never executed.
>>>>>
>>>>> Coverity issue: 343454
>>>>>
>>>>> Fixes: be41ac2a330f ("flow_classify: introduce flow classify library")
>>>>> Cc: stable@dpdk.org
>>>>> Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
>>>>
>>>> Applied, thanks
>>>
>>> We have a segfault in the unit tests since this patch.
>>
>> I think this patch is still correct. The issue is in the semantic of
>> the flow classify pattern. It *MUST* always have a valid end marker,
>> but the test passes an invalid end marker. This causes the bounds to
>> exceed.
>>
>> So, it would be best to fix it, either by having a "failure" on unknown
>> markers (f.e. -1), or by passing a length around. However, the crash
>> should be expected. The fact that the previous code was also incorrect
>> and resulted in no segfault is pure luck.
>>
>> See rte_flow_classify_parse.c:80 and test_flow_classify.c:387
>>
>> I would be in favor of passing the lengths of the two arrays to these
>> APIs. That would let us still make use of the markers (for valid
>> construction), but also let us reason about lengths in a sane way.
>>
>> WDYT?
>>
>
> +1, I also just replied with something very similar.
>
> With current API the testcase is wrong, and it will crash, also the invalid
> action one has exact same problem.
>
> The API can be updated as you suggested, with a length field and testcases can
> be added back.
>
> What worries me more is the rte_flow, which uses same arguments, and open to
> same errors, should we consider updating rte_flow APIs to have lengths values too?
Probably.
Here's a first crack at the change I think is appropriate. I have done
some limited testing. Let me know if you want me to submit it formally.
---------------------------- 8< ---------------------------------
Subject: [PATCH] rte_flow_classify: fix up the API and preserve ABI
Introduces a new API for doing length validations, and preserves the old semantics
and API. The previous API couldn't handle corrupted end markers. A future
version of the API might be able to eschew the end marker and trust the length,
but that is a discussion for future.
Signed-off-by: Aaron Conole <aconole@redhat.com>
---
app/test/test_flow_classify.c | 30 +-------
lib/librte_flow_classify/rte_flow_classify.c | 72 +++++++++++++++++---
lib/librte_flow_classify/rte_flow_classify.h | 28 ++++++++
3 files changed, 91 insertions(+), 39 deletions(-)
diff --git a/app/test/test_flow_classify.c b/app/test/test_flow_classify.c
index 6bbaad364..ff5265c6a 100644
--- a/app/test/test_flow_classify.c
+++ b/app/test/test_flow_classify.c
@@ -125,7 +125,6 @@ static struct rte_flow_item udp_item_bad = { RTE_FLOW_ITEM_TYPE_UDP,
static struct rte_flow_item end_item = { RTE_FLOW_ITEM_TYPE_END,
0, 0, 0 };
-static struct rte_flow_item end_item_bad = { -1, 0, 0, 0 };
/* test TCP pattern:
* "eth / ipv4 src spec 1.2.3.4 src mask 255.255.255.00 dst spec 5.6.7.8
@@ -181,7 +180,6 @@ static struct rte_flow_action count_action = { RTE_FLOW_ACTION_TYPE_COUNT,
static struct rte_flow_action count_action_bad = { -1, 0};
static struct rte_flow_action end_action = { RTE_FLOW_ACTION_TYPE_END, 0};
-static struct rte_flow_action end_action_bad = { -1, 0};
static struct rte_flow_action actions[2];
@@ -384,7 +382,7 @@ test_invalid_patterns(void)
pattern[1] = ipv4_udp_item_1;
pattern[2] = udp_item_bad;
- pattern[3] = end_item_bad;
+ pattern[3] = end_item;
ret = rte_flow_classify_validate(cls->cls, &attr, pattern,
actions, &error);
@@ -458,32 +456,6 @@ test_invalid_actions(void)
return -1;
}
- actions[0] = count_action;
- actions[1] = end_action_bad;
-
- ret = rte_flow_classify_validate(cls->cls, &attr, pattern,
- actions, &error);
- if (!ret) {
- printf("Line %i: rte_flow_classify_validate", __LINE__);
- printf(" should have failed!\n");
- return -1;
- }
-
- rule = rte_flow_classify_table_entry_add(cls->cls, &attr, pattern,
- actions, &key_found, &error);
- if (rule) {
- printf("Line %i: flow_classify_table_entry_add", __LINE__);
- printf(" should have failed!\n");
- return -1;
- }
-
- ret = rte_flow_classify_table_entry_delete(cls->cls, rule);
- if (!ret) {
- printf("Line %i: rte_flow_classify_table_entry_delete",
- __LINE__);
- printf("should have failed!\n");
- return -1;
- }
return 0;
}
diff --git a/lib/librte_flow_classify/rte_flow_classify.c b/lib/librte_flow_classify/rte_flow_classify.c
index 5ff585803..3ca1b1b44 100644
--- a/lib/librte_flow_classify/rte_flow_classify.c
+++ b/lib/librte_flow_classify/rte_flow_classify.c
@@ -89,18 +89,51 @@ struct rte_flow_classify_rule {
void *entry_ptr; /* handle to the table entry for rule meta data */
};
+static size_t
+calc_flow_item_alen(const struct rte_flow_item pattern[])
+{
+ size_t i = 0;
+ while (pattern && (pattern + i)->type != RTE_FLOW_ITEM_TYPE_END)
+ i++;
+ return i + 1;
+}
+
+static size_t
+calc_flow_action_alen(const struct rte_flow_action actions[])
+{
+ size_t i = 0;
+ while (actions && (actions + i)->type != RTE_FLOW_ACTION_TYPE_END)
+ i++;
+ return i + 1;
+}
+
+int
+rte_flow_classify_validate(struct rte_flow_classifier *cls,
+ const struct rte_flow_attr *attr,
+ const struct rte_flow_item pattern[],
+ const struct rte_flow_action actions[],
+ struct rte_flow_error *error)
+{
+ return rte_flow_classify_validate_l(cls, attr, pattern,
+ calc_flow_item_alen(pattern),
+ actions,
+ calc_flow_action_alen(actions),
+ error);
+}
+
int
-rte_flow_classify_validate(
- struct rte_flow_classifier *cls,
- const struct rte_flow_attr *attr,
- const struct rte_flow_item pattern[],
- const struct rte_flow_action actions[],
- struct rte_flow_error *error)
+rte_flow_classify_validate_l(struct rte_flow_classifier *cls,
+ const struct rte_flow_attr *attr,
+ const struct rte_flow_item pattern[],
+ size_t pattern_l,
+ const struct rte_flow_action actions[],
+ size_t actions_l,
+ struct rte_flow_error *error)
{
struct rte_flow_item *items;
parse_filter_t parse_filter;
uint32_t item_num = 0;
- uint32_t i = 0;
+ size_t i = 0;
int ret;
if (error == NULL)
@@ -134,17 +167,37 @@ rte_flow_classify_validate(
return -EINVAL;
}
+ while (i < actions_l && (actions + i)->type != RTE_FLOW_ACTION_TYPE_END)
+ i++;
+
+ if (i == actions_l) {
+ rte_flow_error_set(error, EINVAL,
+ RTE_FLOW_ERROR_TYPE_ACTION_NUM,
+ NULL, "Actions without end marker.");
+ return -EINVAL;
+ }
+
+ i = 0;
+
memset(&cls->ntuple_filter, 0, sizeof(cls->ntuple_filter));
/* Get the non-void item number of pattern */
- while ((pattern + i)->type != RTE_FLOW_ITEM_TYPE_END) {
+ while (i < pattern_l && (pattern + i)->type != RTE_FLOW_ITEM_TYPE_END) {
if ((pattern + i)->type != RTE_FLOW_ITEM_TYPE_VOID)
item_num++;
i++;
}
+
item_num++;
- items = malloc(item_num * sizeof(struct rte_flow_item));
+ if (i == pattern_l) {
+ rte_flow_error_set(error, EINVAL,
+ RTE_FLOW_ERROR_TYPE_ITEM,
+ NULL, "Pattern without end marker.");
+ return -EINVAL;
+ }
+
+ items = calloc(item_num, sizeof(struct rte_flow_item));
if (!items) {
rte_flow_error_set(error, ENOMEM,
RTE_FLOW_ERROR_TYPE_ITEM_NUM,
@@ -152,7 +205,6 @@ rte_flow_classify_validate(
return -ENOMEM;
}
- memset(items, 0, item_num * sizeof(struct rte_flow_item));
classify_pattern_skip_void_item(items, pattern);
parse_filter = classify_find_parse_filter_func(items);
diff --git a/lib/librte_flow_classify/rte_flow_classify.h b/lib/librte_flow_classify/rte_flow_classify.h
index 74d1ecaf5..0308f6fd2 100644
--- a/lib/librte_flow_classify/rte_flow_classify.h
+++ b/lib/librte_flow_classify/rte_flow_classify.h
@@ -186,6 +186,34 @@ int
rte_flow_classify_table_create(struct rte_flow_classifier *cls,
struct rte_flow_classify_table_params *params);
+/**
+ * Flow classify validate
+ *
+ * @param cls
+ * Handle to flow classifier instance
+ * @param[in] attr
+ * Flow rule attributes
+ * @param[in] pattern
+ * Pattern specification (list terminated by the END pattern item).
+ * @param[in] actions
+ * Associated actions (list terminated by the END pattern item).
+ * @param[out] error
+ * Perform verbose error reporting if not NULL. Structure
+ * initialised in case of error only.
+ * @return
+ * 0 on success, error code otherwise
+ */
+__rte_experimental
+int
+rte_flow_classify_validate_l(struct rte_flow_classifier *cls,
+ const struct rte_flow_attr *attr,
+ const struct rte_flow_item pattern[],
+ const size_t pattern_l,
+ const struct rte_flow_action actions[],
+ const size_t actions_l,
+ struct rte_flow_error *error);
+
+
/**
* Flow classify validate
*
--
2.21.0
^ permalink raw reply [relevance 2%]
* Re: [dpdk-dev] [RFC 19.11 1/2] ethdev: make DPDK core functions non-inline
@ 2019-07-30 15:45 0% Jerin Jacob Kollanukkaran
2019-07-30 16:05 5% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-07-30 15:45 UTC (permalink / raw)
To: Bruce Richardson; +Cc: Marcin Zapolski, dev
> -----Original Message-----
> From: Bruce Richardson <bruce.richardson@intel.com>
> Sent: Tuesday, July 30, 2019 9:02 PM
> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> Cc: Marcin Zapolski <marcinx.a.zapolski@intel.com>; dev@dpdk.org
> Subject: [EXT] Re: [dpdk-dev] [RFC 19.11 1/2] ethdev: make DPDK core functions
> non-inline
>
> ----------------------------------------------------------------------
> On Tue, Jul 30, 2019 at 03:01:00PM +0000, Jerin Jacob Kollanukkaran wrote:
> > > -----Original Message----- From: dev <dev-bounces@dpdk.org> On
> > > Behalf Of Marcin Zapolski Sent: Tuesday, July 30, 2019 6:20 PM To:
> > > dev@dpdk.org Cc: Marcin Zapolski <marcinx.a.zapolski@intel.com>
> > > Subject: [dpdk-dev] [RFC 19.11 1/2] ethdev: make DPDK core functions
> > > non- inline
> > >
> > > Make rte_eth_rx_burst, rte_eth_tx_burst and other static inline
> > > ethdev functions not inline. They are referencing DPDK internal
> > > structures and inlining forces those structures to be exposed to user
> applications.
> > >
> > > In internal testing with i40e NICs a performance drop of about 2%
> > > was observed with testpmd.
> >
> > I tested on two class of arm64 machines(Highend and lowend) one has
> > 1.4% drop And other one has 3.6% drop.
> >
> This is with testpmd only right? I'd just point out that we need to remember that
> these numbers need to be scaled down appropriately for a realworld app where
> IO is only a (hopefully small) proportion of the packet processing budget. For
> example, I would expect the ~2% drop we saw in testpmd to correspond to
> <0.5% drop in something like OVS.
I see it as bit different view, Cycles saved infrastructure layer, cycles gained in
application. So IMO it vary between end user application need what kind of
machine it runs.
>
> > I second to not expose internal data structure to avoid ABI break.
> >
> > IMO, This patch has performance issue due to it is fixing it in simple
> > way.
> >
> > It is not worth two have function call overhead to call the driver
> > function. Some thoughts below to reduce the performance impact
> > without exposing internal structures.
> >
> The big concern I have with what you propose is that would involve changing
> each and every ethdev driver in DPDK! I'd prefer to make sure that the impact of
> this change is actually felt in real-world apps before we start looking to make
> such updates across the DPDK codebase.
I see those changes are NO BRAINER from driver POV. Once we add in one driver, individual
PMD Maintainer can update easily. I think, we can do it once for all.
I am sure, you must aware of How hard is make 2% improvement in driver. I can spend time in
This NO brainer to get 2% improvement back. I prefer later.
>
> > And I think, We need to follow the similar mechanism for cryptodev,
> > Eventdev, rawdev Etc so bring the common scheme to address this semantics
> will be use full.
> >
> Agreed.
>
> Regards,
> /Bruce
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC 19.11 1/2] ethdev: make DPDK core functions non-inline
2019-07-30 15:45 0% [dpdk-dev] [RFC 19.11 1/2] ethdev: make DPDK core functions non-inline Jerin Jacob Kollanukkaran
@ 2019-07-30 16:05 5% ` Bruce Richardson
2019-07-30 16:24 3% ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2019-07-30 16:05 UTC (permalink / raw)
To: Jerin Jacob Kollanukkaran; +Cc: Marcin Zapolski, dev
On Tue, Jul 30, 2019 at 03:45:38PM +0000, Jerin Jacob Kollanukkaran wrote:
> > -----Original Message-----
> > From: Bruce Richardson <bruce.richardson@intel.com>
> > Sent: Tuesday, July 30, 2019 9:02 PM
> > To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> > Cc: Marcin Zapolski <marcinx.a.zapolski@intel.com>; dev@dpdk.org
> > Subject: [EXT] Re: [dpdk-dev] [RFC 19.11 1/2] ethdev: make DPDK core functions
> > non-inline
> >
> > ----------------------------------------------------------------------
> > On Tue, Jul 30, 2019 at 03:01:00PM +0000, Jerin Jacob Kollanukkaran wrote:
> > > > -----Original Message----- From: dev <dev-bounces@dpdk.org> On
> > > > Behalf Of Marcin Zapolski Sent: Tuesday, July 30, 2019 6:20 PM To:
> > > > dev@dpdk.org Cc: Marcin Zapolski <marcinx.a.zapolski@intel.com>
> > > > Subject: [dpdk-dev] [RFC 19.11 1/2] ethdev: make DPDK core functions
> > > > non- inline
> > > >
> > > > Make rte_eth_rx_burst, rte_eth_tx_burst and other static inline
> > > > ethdev functions not inline. They are referencing DPDK internal
> > > > structures and inlining forces those structures to be exposed to user
> > applications.
> > > >
> > > > In internal testing with i40e NICs a performance drop of about 2%
> > > > was observed with testpmd.
> > >
> > > I tested on two class of arm64 machines(Highend and lowend) one has
> > > 1.4% drop And other one has 3.6% drop.
> > >
> > This is with testpmd only right? I'd just point out that we need to remember that
> > these numbers need to be scaled down appropriately for a realworld app where
> > IO is only a (hopefully small) proportion of the packet processing budget. For
> > example, I would expect the ~2% drop we saw in testpmd to correspond to
> > <0.5% drop in something like OVS.
>
> I see it as bit different view, Cycles saved infrastructure layer, cycles gained in
> application. So IMO it vary between end user application need what kind of
> machine it runs.
>
Sure. My thinking more is that to get ABI compatibility involves some
tradeoffs and spending one more cycle per-packet when an app workload is
typically hundreds of cycles, I believe, is a small cost worth paying.
> >
> > > I second to not expose internal data structure to avoid ABI break.
> > >
> > > IMO, This patch has performance issue due to it is fixing it in simple
> > > way.
> > >
> > > It is not worth two have function call overhead to call the driver
> > > function. Some thoughts below to reduce the performance impact
> > > without exposing internal structures.
> > >
> > The big concern I have with what you propose is that would involve changing
> > each and every ethdev driver in DPDK! I'd prefer to make sure that the impact of
> > this change is actually felt in real-world apps before we start looking to make
> > such updates across the DPDK codebase.
>
> I see those changes are NO BRAINER from driver POV. Once we add in one driver, individual
> PMD Maintainer can update easily. I think, we can do it once for all.
Ok, if it's doable in one go then sure. The issue is that if even one driver
is not updated we can't switch over, all have to effectively be done
simultaneously. [It would also make backporting fixes trickier, but I
wouldn't be concerned about that particularly.]
Have you tried out making the changes to a driver or two, to see how large
the delta is? [And to verify it doesn't affect performance]
> I am sure, you must aware of How hard is make 2% improvement in driver. I can spend time in
> This NO brainer to get 2% improvement back. I prefer later.
>
The other alternative I see is to leave the inline functions there, just
disabled by default, and put in a build-time option for reduced ABI
compatibility. That way the standard-built packages are all ABI compatible,
but for those who absolutely need max perf and are rolling-their-own-build
to get it can disable that ABI compatibility.
/Bruce
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [EXT] Re: [RFC 19.11 1/2] ethdev: make DPDK core functions non-inline
2019-07-30 16:05 5% ` Bruce Richardson
@ 2019-07-30 16:24 3% ` Jerin Jacob Kollanukkaran
0 siblings, 0 replies; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-07-30 16:24 UTC (permalink / raw)
To: Bruce Richardson; +Cc: Marcin Zapolski, dev
> -----Original Message-----
> From: Bruce Richardson <bruce.richardson@intel.com>
> Sent: Tuesday, July 30, 2019 9:36 PM
> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> Cc: Marcin Zapolski <marcinx.a.zapolski@intel.com>; dev@dpdk.org
> Subject: [EXT] Re: [dpdk-dev] [RFC 19.11 1/2] ethdev: make DPDK core functions
> non-inline
>
> On Tue, Jul 30, 2019 at 03:45:38PM +0000, Jerin Jacob Kollanukkaran wrote:
> > > -----Original Message-----
> > > From: Bruce Richardson <bruce.richardson@intel.com>
> > > Sent: Tuesday, July 30, 2019 9:02 PM
> > > To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
> > > Cc: Marcin Zapolski <marcinx.a.zapolski@intel.com>; dev@dpdk.org
> > > Subject: [EXT] Re: [dpdk-dev] [RFC 19.11 1/2] ethdev: make DPDK core
> > > functions non-inline
> > >
> > > --------------------------------------------------------------------
> > > -- On Tue, Jul 30, 2019 at 03:01:00PM +0000, Jerin Jacob
> > > Kollanukkaran wrote:
> > > > > -----Original Message----- From: dev <dev-bounces@dpdk.org> On
> > > > > Behalf Of Marcin Zapolski Sent: Tuesday, July 30, 2019 6:20 PM To:
> > > > > dev@dpdk.org Cc: Marcin Zapolski <marcinx.a.zapolski@intel.com>
> > > > > Subject: [dpdk-dev] [RFC 19.11 1/2] ethdev: make DPDK core
> > > > > functions
> > > > > non- inline
> > > > >
> > > > > Make rte_eth_rx_burst, rte_eth_tx_burst and other static inline
> > > > > ethdev functions not inline. They are referencing DPDK internal
> > > > > structures and inlining forces those structures to be exposed to
> > > > > user
> > > applications.
> > > > >
> > > > > In internal testing with i40e NICs a performance drop of about
> > > > > 2% was observed with testpmd.
> > > >
> > > > I tested on two class of arm64 machines(Highend and lowend) one
> > > > has 1.4% drop And other one has 3.6% drop.
> > > >
> > > This is with testpmd only right? I'd just point out that we need to
> > > remember that these numbers need to be scaled down appropriately for
> > > a realworld app where IO is only a (hopefully small) proportion of
> > > the packet processing budget. For example, I would expect the ~2%
> > > drop we saw in testpmd to correspond to <0.5% drop in something like OVS.
> >
> > I see it as bit different view, Cycles saved infrastructure layer,
> > cycles gained in application. So IMO it vary between end user
> > application need what kind of machine it runs.
> >
> Sure. My thinking more is that to get ABI compatibility involves some tradeoffs
> and spending one more cycle per-packet when an app workload is typically
> hundreds of cycles, I believe, is a small cost worth paying.
I agree. But, We need take only the cost, If it is really costs.I don't think, we don't
need two level of indirection.
>
> > >
> > > > I second to not expose internal data structure to avoid ABI break.
> > > >
> > > > IMO, This patch has performance issue due to it is fixing it in
> > > > simple way.
> > > >
> > > > It is not worth two have function call overhead to call the driver
> > > > function. Some thoughts below to reduce the performance impact
> > > > without exposing internal structures.
> > > >
> > > The big concern I have with what you propose is that would involve
> > > changing each and every ethdev driver in DPDK! I'd prefer to make
> > > sure that the impact of this change is actually felt in real-world
> > > apps before we start looking to make such updates across the DPDK
> codebase.
> >
> > I see those changes are NO BRAINER from driver POV. Once we add in one
> > driver, individual PMD Maintainer can update easily. I think, we can do it once
> for all.
>
> Ok, if it's doable in one go then sure. The issue is that if even one driver is not
> updated we can't switch over, all have to effectively be done simultaneously. [It
I agree. But I think, we can give enough time for driver to migrate.
If it does not migrate in time. We can take necessary action to fix it.
If it is a no brainer changes then all drivers will do it. We cannot pay cost
Because one driver is not maintaining. I can commit to take care of ALL Marvell PMDs.
> would also make backporting fixes trickier, but I wouldn't be concerned about
> that particularly.]
>
> Have you tried out making the changes to a driver or two, to see how large the
> delta is? [And to verify it doesn't affect performance]
I hope, The RFC author will take first stab, I can help in reviewing it.
>
> > I am sure, you must aware of How hard is make 2% improvement in
> > driver. I can spend time in This NO brainer to get 2% improvement back. I
> prefer later.
> >
> The other alternative I see is to leave the inline functions there, just disabled by
> default, and put in a build-time option for reduced ABI compatibility. That way
> the standard-built packages are all ABI compatible, but for those who absolutely
> need max perf and are rolling-their-own-build to get it can disable that ABI
> compatibility.
But currently there no ABI break. Right? We should do it before we have one on those
structures. I think, we should cleanup the low hanging ones first and to fast
path structures in parallel.
>
> /Bruce
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [dpdk-stable] [PATCH] librte_flow_classify: fix out-of-bounds access
2019-07-30 15:43 2% ` Aaron Conole
@ 2019-07-30 16:55 0% ` Ferruh Yigit
2019-07-30 17:30 0% ` Aaron Conole
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2019-07-30 16:55 UTC (permalink / raw)
To: Aaron Conole
Cc: David Marchand, Bernard Iremonger, dev, dpdk stable,
Thomas Monjalon, Singh, Jasvinder, Flavia Musatescu,
Adrien Mazarguil
On 7/30/2019 4:43 PM, Aaron Conole wrote:
> Ferruh Yigit <ferruh.yigit@intel.com> writes:
>
>> On 7/30/2019 3:42 PM, Aaron Conole wrote:
>>> David Marchand <david.marchand@redhat.com> writes:
>>>
>>>> On Wed, Jul 10, 2019 at 11:49 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>>>>>
>>>>> 09/07/2019 13:09, Bernard Iremonger:
>>>>>> This patch fixes the out-of-bounds coverity issue by removing the
>>>>>> offending line of code at line 107 in rte_flow_classify_parse.c
>>>>>> which is never executed.
>>>>>>
>>>>>> Coverity issue: 343454
>>>>>>
>>>>>> Fixes: be41ac2a330f ("flow_classify: introduce flow classify library")
>>>>>> Cc: stable@dpdk.org
>>>>>> Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
>>>>>
>>>>> Applied, thanks
>>>>
>>>> We have a segfault in the unit tests since this patch.
>>>
>>> I think this patch is still correct. The issue is in the semantic of
>>> the flow classify pattern. It *MUST* always have a valid end marker,
>>> but the test passes an invalid end marker. This causes the bounds to
>>> exceed.
>>>
>>> So, it would be best to fix it, either by having a "failure" on unknown
>>> markers (f.e. -1), or by passing a length around. However, the crash
>>> should be expected. The fact that the previous code was also incorrect
>>> and resulted in no segfault is pure luck.
>>>
>>> See rte_flow_classify_parse.c:80 and test_flow_classify.c:387
>>>
>>> I would be in favor of passing the lengths of the two arrays to these
>>> APIs. That would let us still make use of the markers (for valid
>>> construction), but also let us reason about lengths in a sane way.
>>>
>>> WDYT?
>>>
>>
>> +1, I also just replied with something very similar.
>>
>> With current API the testcase is wrong, and it will crash, also the invalid
>> action one has exact same problem.
>>
>> The API can be updated as you suggested, with a length field and testcases can
>> be added back.
>>
>> What worries me more is the rte_flow, which uses same arguments, and open to
>> same errors, should we consider updating rte_flow APIs to have lengths values too?
>
> Probably.
>
> Here's a first crack at the change I think is appropriate. I have done
> some limited testing. Let me know if you want me to submit it formally.
>
> ---------------------------- 8< ---------------------------------
> Subject: [PATCH] rte_flow_classify: fix up the API and preserve ABI
>
> Introduces a new API for doing length validations, and preserves the old semantics
> and API. The previous API couldn't handle corrupted end markers. A future
> version of the API might be able to eschew the end marker and trust the length,
> but that is a discussion for future.
>
> Signed-off-by: Aaron Conole <aconole@redhat.com>
> ---
> app/test/test_flow_classify.c | 30 +-------
> lib/librte_flow_classify/rte_flow_classify.c | 72 +++++++++++++++++---
> lib/librte_flow_classify/rte_flow_classify.h | 28 ++++++++
> 3 files changed, 91 insertions(+), 39 deletions(-)
>
> diff --git a/app/test/test_flow_classify.c b/app/test/test_flow_classify.c
> index 6bbaad364..ff5265c6a 100644
> --- a/app/test/test_flow_classify.c
> +++ b/app/test/test_flow_classify.c
> @@ -125,7 +125,6 @@ static struct rte_flow_item udp_item_bad = { RTE_FLOW_ITEM_TYPE_UDP,
>
> static struct rte_flow_item end_item = { RTE_FLOW_ITEM_TYPE_END,
> 0, 0, 0 };
> -static struct rte_flow_item end_item_bad = { -1, 0, 0, 0 };
>
> /* test TCP pattern:
> * "eth / ipv4 src spec 1.2.3.4 src mask 255.255.255.00 dst spec 5.6.7.8
> @@ -181,7 +180,6 @@ static struct rte_flow_action count_action = { RTE_FLOW_ACTION_TYPE_COUNT,
> static struct rte_flow_action count_action_bad = { -1, 0};
>
> static struct rte_flow_action end_action = { RTE_FLOW_ACTION_TYPE_END, 0};
> -static struct rte_flow_action end_action_bad = { -1, 0};
>
> static struct rte_flow_action actions[2];
>
> @@ -384,7 +382,7 @@ test_invalid_patterns(void)
>
> pattern[1] = ipv4_udp_item_1;
> pattern[2] = udp_item_bad;
> - pattern[3] = end_item_bad;
> + pattern[3] = end_item;
>
> ret = rte_flow_classify_validate(cls->cls, &attr, pattern,
> actions, &error);
> @@ -458,32 +456,6 @@ test_invalid_actions(void)
> return -1;
> }
>
> - actions[0] = count_action;
> - actions[1] = end_action_bad;
> -
> - ret = rte_flow_classify_validate(cls->cls, &attr, pattern,
> - actions, &error);
> - if (!ret) {
> - printf("Line %i: rte_flow_classify_validate", __LINE__);
> - printf(" should have failed!\n");
> - return -1;
> - }
> -
> - rule = rte_flow_classify_table_entry_add(cls->cls, &attr, pattern,
> - actions, &key_found, &error);
> - if (rule) {
> - printf("Line %i: flow_classify_table_entry_add", __LINE__);
> - printf(" should have failed!\n");
> - return -1;
> - }
> -
> - ret = rte_flow_classify_table_entry_delete(cls->cls, rule);
> - if (!ret) {
> - printf("Line %i: rte_flow_classify_table_entry_delete",
> - __LINE__);
> - printf("should have failed!\n");
> - return -1;
> - }
> return 0;
> }
+1 to unit test updates, lgtm.
And I am for pushing the library updates to the next release, but please find a
few comments for now.
>
> diff --git a/lib/librte_flow_classify/rte_flow_classify.c b/lib/librte_flow_classify/rte_flow_classify.c
> index 5ff585803..3ca1b1b44 100644
> --- a/lib/librte_flow_classify/rte_flow_classify.c
> +++ b/lib/librte_flow_classify/rte_flow_classify.c
> @@ -89,18 +89,51 @@ struct rte_flow_classify_rule {
> void *entry_ptr; /* handle to the table entry for rule meta data */
> };
>
> +static size_t
> +calc_flow_item_alen(const struct rte_flow_item pattern[])
> +{
> + size_t i = 0;
> + while (pattern && (pattern + i)->type != RTE_FLOW_ITEM_TYPE_END)
> + i++;
> + return i + 1;
I think better to send '0' if the pointer is NULL, (instead of 1)
<...>
> @@ -186,6 +186,34 @@ int
> rte_flow_classify_table_create(struct rte_flow_classifier *cls,
> struct rte_flow_classify_table_params *params);
>
> +/**
> + * Flow classify validate
> + *
> + * @param cls
> + * Handle to flow classifier instance
> + * @param[in] attr
> + * Flow rule attributes
> + * @param[in] pattern
> + * Pattern specification (list terminated by the END pattern item).
> + * @param[in] actions
> + * Associated actions (list terminated by the END pattern item).
> + * @param[out] error
> + * Perform verbose error reporting if not NULL. Structure
> + * initialised in case of error only.
> + * @return
> + * 0 on success, error code otherwise
> + */
> +__rte_experimental
> +int
> +rte_flow_classify_validate_l(struct rte_flow_classifier *cls,
> + const struct rte_flow_attr *attr,
> + const struct rte_flow_item pattern[],
> + const size_t pattern_l,
> + const struct rte_flow_action actions[],
> + const size_t actions_l,
> + struct rte_flow_error *error);
The doxygen comment is missing for 'pattern_l' & 'actions_l' but from code it is
number of items in the lists, this is duplication of the END marker information.
Instead, if those lengths are the length of the arrays will it be easier for the
user? So user won't need to calculate the item count but can pass the size of
the array. This still prevents API access out of the array.
Anyway, as suggested above lets not make these decisions just a few days before
the release, but just get the unit test fix for the release, does it make sense?
And if so, can you send the unit test patch?
Thanks,
ferruh
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [dpdk-stable] [PATCH] librte_flow_classify: fix out-of-bounds access
2019-07-30 16:55 0% ` Ferruh Yigit
@ 2019-07-30 17:30 0% ` Aaron Conole
0 siblings, 0 replies; 200+ results
From: Aaron Conole @ 2019-07-30 17:30 UTC (permalink / raw)
To: Ferruh Yigit
Cc: David Marchand, Bernard Iremonger, dev, dpdk stable,
Thomas Monjalon, Singh, Jasvinder, Flavia Musatescu,
Adrien Mazarguil
Ferruh Yigit <ferruh.yigit@intel.com> writes:
> On 7/30/2019 4:43 PM, Aaron Conole wrote:
>> Ferruh Yigit <ferruh.yigit@intel.com> writes:
>>
>>> On 7/30/2019 3:42 PM, Aaron Conole wrote:
>>>> David Marchand <david.marchand@redhat.com> writes:
>>>>
>>>>> On Wed, Jul 10, 2019 at 11:49 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>>>>>>
>>>>>> 09/07/2019 13:09, Bernard Iremonger:
>>>>>>> This patch fixes the out-of-bounds coverity issue by removing the
>>>>>>> offending line of code at line 107 in rte_flow_classify_parse.c
>>>>>>> which is never executed.
>>>>>>>
>>>>>>> Coverity issue: 343454
>>>>>>>
>>>>>>> Fixes: be41ac2a330f ("flow_classify: introduce flow classify library")
>>>>>>> Cc: stable@dpdk.org
>>>>>>> Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
>>>>>>
>>>>>> Applied, thanks
>>>>>
>>>>> We have a segfault in the unit tests since this patch.
>>>>
>>>> I think this patch is still correct. The issue is in the semantic of
>>>> the flow classify pattern. It *MUST* always have a valid end marker,
>>>> but the test passes an invalid end marker. This causes the bounds to
>>>> exceed.
>>>>
>>>> So, it would be best to fix it, either by having a "failure" on unknown
>>>> markers (f.e. -1), or by passing a length around. However, the crash
>>>> should be expected. The fact that the previous code was also incorrect
>>>> and resulted in no segfault is pure luck.
>>>>
>>>> See rte_flow_classify_parse.c:80 and test_flow_classify.c:387
>>>>
>>>> I would be in favor of passing the lengths of the two arrays to these
>>>> APIs. That would let us still make use of the markers (for valid
>>>> construction), but also let us reason about lengths in a sane way.
>>>>
>>>> WDYT?
>>>>
>>>
>>> +1, I also just replied with something very similar.
>>>
>>> With current API the testcase is wrong, and it will crash, also the invalid
>>> action one has exact same problem.
>>>
>>> The API can be updated as you suggested, with a length field and testcases can
>>> be added back.
>>>
>>> What worries me more is the rte_flow, which uses same arguments, and open to
>>> same errors, should we consider updating rte_flow APIs to have lengths values too?
>>
>> Probably.
>>
>> Here's a first crack at the change I think is appropriate. I have done
>> some limited testing. Let me know if you want me to submit it formally.
>>
>> ---------------------------- 8< ---------------------------------
>> Subject: [PATCH] rte_flow_classify: fix up the API and preserve ABI
>>
>> Introduces a new API for doing length validations, and preserves the old semantics
>> and API. The previous API couldn't handle corrupted end markers. A future
>> version of the API might be able to eschew the end marker and trust the length,
>> but that is a discussion for future.
>>
>> Signed-off-by: Aaron Conole <aconole@redhat.com>
>> ---
>> app/test/test_flow_classify.c | 30 +-------
>> lib/librte_flow_classify/rte_flow_classify.c | 72 +++++++++++++++++---
>> lib/librte_flow_classify/rte_flow_classify.h | 28 ++++++++
>> 3 files changed, 91 insertions(+), 39 deletions(-)
>>
>> diff --git a/app/test/test_flow_classify.c b/app/test/test_flow_classify.c
>> index 6bbaad364..ff5265c6a 100644
>> --- a/app/test/test_flow_classify.c
>> +++ b/app/test/test_flow_classify.c
>> @@ -125,7 +125,6 @@ static struct rte_flow_item udp_item_bad = { RTE_FLOW_ITEM_TYPE_UDP,
>>
>> static struct rte_flow_item end_item = { RTE_FLOW_ITEM_TYPE_END,
>> 0, 0, 0 };
>> -static struct rte_flow_item end_item_bad = { -1, 0, 0, 0 };
>>
>> /* test TCP pattern:
>> * "eth / ipv4 src spec 1.2.3.4 src mask 255.255.255.00 dst spec 5.6.7.8
>> @@ -181,7 +180,6 @@ static struct rte_flow_action count_action = { RTE_FLOW_ACTION_TYPE_COUNT,
>> static struct rte_flow_action count_action_bad = { -1, 0};
>>
>> static struct rte_flow_action end_action = { RTE_FLOW_ACTION_TYPE_END, 0};
>> -static struct rte_flow_action end_action_bad = { -1, 0};
>>
>> static struct rte_flow_action actions[2];
>>
>> @@ -384,7 +382,7 @@ test_invalid_patterns(void)
>>
>> pattern[1] = ipv4_udp_item_1;
>> pattern[2] = udp_item_bad;
>> - pattern[3] = end_item_bad;
>> + pattern[3] = end_item;
>>
>> ret = rte_flow_classify_validate(cls->cls, &attr, pattern,
>> actions, &error);
>> @@ -458,32 +456,6 @@ test_invalid_actions(void)
>> return -1;
>> }
>>
>> - actions[0] = count_action;
>> - actions[1] = end_action_bad;
>> -
>> - ret = rte_flow_classify_validate(cls->cls, &attr, pattern,
>> - actions, &error);
>> - if (!ret) {
>> - printf("Line %i: rte_flow_classify_validate", __LINE__);
>> - printf(" should have failed!\n");
>> - return -1;
>> - }
>> -
>> - rule = rte_flow_classify_table_entry_add(cls->cls, &attr, pattern,
>> - actions, &key_found, &error);
>> - if (rule) {
>> - printf("Line %i: flow_classify_table_entry_add", __LINE__);
>> - printf(" should have failed!\n");
>> - return -1;
>> - }
>> -
>> - ret = rte_flow_classify_table_entry_delete(cls->cls, rule);
>> - if (!ret) {
>> - printf("Line %i: rte_flow_classify_table_entry_delete",
>> - __LINE__);
>> - printf("should have failed!\n");
>> - return -1;
>> - }
>> return 0;
>> }
>
> +1 to unit test updates, lgtm.
>
> And I am for pushing the library updates to the next release, but please find a
> few comments for now.
Okay - I'll do that. But we probably will need to note that these APIs
should get deprecated. Not sure if that should happen in this release -
as the author of most of the code, maybe you would take care of that
part? :)
>
>>
>> diff --git a/lib/librte_flow_classify/rte_flow_classify.c b/lib/librte_flow_classify/rte_flow_classify.c
>> index 5ff585803..3ca1b1b44 100644
>> --- a/lib/librte_flow_classify/rte_flow_classify.c
>> +++ b/lib/librte_flow_classify/rte_flow_classify.c
>> @@ -89,18 +89,51 @@ struct rte_flow_classify_rule {
>> void *entry_ptr; /* handle to the table entry for rule meta data */
>> };
>>
>> +static size_t
>> +calc_flow_item_alen(const struct rte_flow_item pattern[])
>> +{
>> + size_t i = 0;
>> + while (pattern && (pattern + i)->type != RTE_FLOW_ITEM_TYPE_END)
>> + i++;
>> + return i + 1;
>
> I think better to send '0' if the pointer is NULL, (instead of 1)
Okay. Makes sense.
> <...>
>
>> @@ -186,6 +186,34 @@ int
>> rte_flow_classify_table_create(struct rte_flow_classifier *cls,
>> struct rte_flow_classify_table_params *params);
>>
>> +/**
>> + * Flow classify validate
>> + *
>> + * @param cls
>> + * Handle to flow classifier instance
>> + * @param[in] attr
>> + * Flow rule attributes
>> + * @param[in] pattern
>> + * Pattern specification (list terminated by the END pattern item).
>> + * @param[in] actions
>> + * Associated actions (list terminated by the END pattern item).
>> + * @param[out] error
>> + * Perform verbose error reporting if not NULL. Structure
>> + * initialised in case of error only.
>> + * @return
>> + * 0 on success, error code otherwise
>> + */
>> +__rte_experimental
>> +int
>> +rte_flow_classify_validate_l(struct rte_flow_classifier *cls,
>> + const struct rte_flow_attr *attr,
>> + const struct rte_flow_item pattern[],
>> + const size_t pattern_l,
>> + const struct rte_flow_action actions[],
>> + const size_t actions_l,
>> + struct rte_flow_error *error);
>
> The doxygen comment is missing for 'pattern_l' & 'actions_l' but from code it is
> number of items in the lists, this is duplication of the END marker information.
> Instead, if those lengths are the length of the arrays will it be easier for the
> user? So user won't need to calculate the item count but can pass the size of
> the array. This still prevents API access out of the array.
>
> Anyway, as suggested above lets not make these decisions just a few days before
> the release, but just get the unit test fix for the release, does it make sense?
Sure.
> And if so, can you send the unit test patch?
Will do.
> Thanks,
> ferruh
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH v2 2/2] drivers/raw: standardize naming
2019-07-30 13:39 7% ` [dpdk-dev] [PATCH v2 2/2] drivers/raw: standardize naming Thomas Monjalon
@ 2019-07-31 7:29 0% ` Xu, Rosen
0 siblings, 0 replies; 200+ results
From: Xu, Rosen @ 2019-07-31 7:29 UTC (permalink / raw)
To: Thomas Monjalon, dev, Mcnamara, John, Kovacevic, Marko,
Nipun Gupta, Zhang, Tianfei, Richardson, Bruce, Li, Xiaoyun, Wu,
Jingjing, Satha Rao, Vamsi Attunuru, Shreyansh Jain,
Hemant Agrawal
Cc: Neil Horman
Hi,
I'm okay if it's applied in 19.11.
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Tuesday, July 30, 2019 21:40
> To: dev@dpdk.org; Mcnamara, John <john.mcnamara@intel.com>;
> Kovacevic, Marko <marko.kovacevic@intel.com>; Nipun Gupta
> <nipun.gupta@nxp.com>; Xu, Rosen <rosen.xu@intel.com>; Zhang, Tianfei
> <tianfei.zhang@intel.com>; Richardson, Bruce
> <bruce.richardson@intel.com>; Li, Xiaoyun <xiaoyun.li@intel.com>; Wu,
> Jingjing <jingjing.wu@intel.com>; Satha Rao <skoteshwar@marvell.com>;
> Vamsi Attunuru <vattunuru@marvell.com>; Shreyansh Jain
> <shreyansh.jain@nxp.com>; Hemant Agrawal <hemant.agrawal@nxp.com>
> Cc: Neil Horman <nhorman@tuxdriver.com>
> Subject: [PATCH v2 2/2] drivers/raw: standardize naming
>
> From: Bruce Richardson <bruce.richardson@intel.com>
>
> The driver names for rawdevs were both different in make and meson builds
> and were non-standard in the make version in that some included "rawdev"
> in the name while others didn't.
>
> Therefore, for global consistency of naming, we can use "rte_rawdev" rather
> than "rte_pmd" for the prefix for the libraries. While most other driver
> categories use "rte_pmd" as a prefix, there is precedent for this in the
> mempool drivers use "rte_mempool" as a prefix.
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> ---
> doc/guides/rel_notes/release_19_08.rst | 3 +++
> drivers/raw/dpaa2_cmdif/Makefile | 4 ++--
> ...sion.map => rte_rawdev_dpaa2_cmdif_version.map} | 0
> drivers/raw/dpaa2_qdma/Makefile | 4 ++--
> ...rsion.map => rte_rawdev_dpaa2_qdma_version.map} | 0
> drivers/raw/ifpga/Makefile | 4 ++--
> ...ga_version.map => rte_rawdev_ifpga_version.map} | 0
> drivers/raw/ioat/Makefile | 4 ++--
> ...oat_version.map => rte_rawdev_ioat_version.map} | 0
> drivers/raw/meson.build | 2 +-
> drivers/raw/ntb/Makefile | 4 ++--
> ..._ntb_version.map => rte_rawdev_ntb_version.map} | 0
> drivers/raw/octeontx2_dma/Makefile | 4 ++--
> ...on.map => rte_rawdev_octeontx2_dma_version.map} | 0
> drivers/raw/skeleton/Makefile | 4 ++--
> ...version.map => rte_rawdev_skeleton_version.map} | 0
> mk/rte.app.mk | 14 +++++++-------
> 17 files changed, 25 insertions(+), 22 deletions(-) rename
> drivers/raw/dpaa2_cmdif/{rte_pmd_dpaa2_cmdif_version.map =>
> rte_rawdev_dpaa2_cmdif_version.map} (100%) rename
> drivers/raw/dpaa2_qdma/{rte_pmd_dpaa2_qdma_version.map =>
> rte_rawdev_dpaa2_qdma_version.map} (100%) rename
> drivers/raw/ifpga/{rte_pmd_ifpga_version.map =>
> rte_rawdev_ifpga_version.map} (100%) rename
> drivers/raw/ioat/{rte_pmd_ioat_version.map =>
> rte_rawdev_ioat_version.map} (100%) rename
> drivers/raw/ntb/{rte_pmd_ntb_version.map =>
> rte_rawdev_ntb_version.map} (100%) rename
> drivers/raw/octeontx2_dma/{rte_pmd_octeontx2_dma_version.map =>
> rte_rawdev_octeontx2_dma_version.map} (100%) rename
> drivers/raw/skeleton/{rte_pmd_skeleton_version.map =>
> rte_rawdev_skeleton_version.map} (100%)
>
> diff --git a/doc/guides/rel_notes/release_19_08.rst
> b/doc/guides/rel_notes/release_19_08.rst
> index fcd1386a5..13a98f520 100644
> --- a/doc/guides/rel_notes/release_19_08.rst
> +++ b/doc/guides/rel_notes/release_19_08.rst
> @@ -351,6 +351,9 @@ ABI Changes
> * bbdev: New operations and parameters added to support new 5GNR
> operations.
> The bbdev ABI is still kept experimental.
>
> +* rawdev: The driver names have been changed to ``librte_rawdev_*``.
> + Now they all have the same prefix, and same name with make and meson
> builds.
> +
>
> Shared Library Versions
> -----------------------
> diff --git a/drivers/raw/dpaa2_cmdif/Makefile
> b/drivers/raw/dpaa2_cmdif/Makefile
> index 9bd5ff229..2b4150c2d 100644
> --- a/drivers/raw/dpaa2_cmdif/Makefile
> +++ b/drivers/raw/dpaa2_cmdif/Makefile
> @@ -6,7 +6,7 @@ include $(RTE_SDK)/mk/rte.vars.mk # # library name # -
> LIB = librte_pmd_dpaa2_cmdif.a
> +LIB = librte_rawdev_dpaa2_cmdif.a
>
> CFLAGS += -DALLOW_EXPERIMENTAL_API
> CFLAGS += -O3
> @@ -23,7 +23,7 @@ LDLIBS += -lrte_mempool_dpaa2 LDLIBS += -
> lrte_rawdev LDLIBS += -lrte_common_dpaax
>
> -EXPORT_MAP := rte_pmd_dpaa2_cmdif_version.map
> +EXPORT_MAP := rte_rawdev_dpaa2_cmdif_version.map
>
> LIBABIVER := 2
>
> diff --git a/drivers/raw/dpaa2_cmdif/rte_pmd_dpaa2_cmdif_version.map
> b/drivers/raw/dpaa2_cmdif/rte_rawdev_dpaa2_cmdif_version.map
> similarity index 100%
> rename from drivers/raw/dpaa2_cmdif/rte_pmd_dpaa2_cmdif_version.map
> rename to drivers/raw/dpaa2_cmdif/rte_rawdev_dpaa2_cmdif_version.map
> diff --git a/drivers/raw/dpaa2_qdma/Makefile
> b/drivers/raw/dpaa2_qdma/Makefile index f9a810cc6..0009fd4c6 100644
> --- a/drivers/raw/dpaa2_qdma/Makefile
> +++ b/drivers/raw/dpaa2_qdma/Makefile
> @@ -6,7 +6,7 @@ include $(RTE_SDK)/mk/rte.vars.mk # # library name # -
> LIB = librte_pmd_dpaa2_qdma.a
> +LIB = librte_rawdev_dpaa2_qdma.a
>
> CFLAGS += -DALLOW_EXPERIMENTAL_API
> CFLAGS += -O3
> @@ -24,7 +24,7 @@ LDLIBS += -lrte_kvargs LDLIBS += -lrte_ring LDLIBS += -
> lrte_common_dpaax
>
> -EXPORT_MAP := rte_pmd_dpaa2_qdma_version.map
> +EXPORT_MAP := rte_rawdev_dpaa2_qdma_version.map
>
> LIBABIVER := 3
>
> diff --git a/drivers/raw/dpaa2_qdma/rte_pmd_dpaa2_qdma_version.map
> b/drivers/raw/dpaa2_qdma/rte_rawdev_dpaa2_qdma_version.map
> similarity index 100%
> rename from
> drivers/raw/dpaa2_qdma/rte_pmd_dpaa2_qdma_version.map
> rename to
> drivers/raw/dpaa2_qdma/rte_rawdev_dpaa2_qdma_version.map
> diff --git a/drivers/raw/ifpga/Makefile b/drivers/raw/ifpga/Makefile index
> 5fa9303d5..655b29288 100644
> --- a/drivers/raw/ifpga/Makefile
> +++ b/drivers/raw/ifpga/Makefile
> @@ -6,7 +6,7 @@ include $(RTE_SDK)/mk/rte.vars.mk # # library name # -
> LIB = librte_pmd_ifpga_rawdev.a
> +LIB = librte_rawdev_ifpga.a
>
> CFLAGS += -DALLOW_EXPERIMENTAL_API
> CFLAGS += -O3
> @@ -21,7 +21,7 @@ LDLIBS += -lrte_kvargs LDLIBS += -lrte_bus_pci LDLIBS
> += -lrte_bus_ifpga
>
> -EXPORT_MAP := rte_pmd_ifpga_version.map
> +EXPORT_MAP := rte_rawdev_ifpga_version.map
>
> LIBABIVER := 1
>
> diff --git a/drivers/raw/ifpga/rte_pmd_ifpga_version.map
> b/drivers/raw/ifpga/rte_rawdev_ifpga_version.map
> similarity index 100%
> rename from drivers/raw/ifpga/rte_pmd_ifpga_version.map
> rename to drivers/raw/ifpga/rte_rawdev_ifpga_version.map
> diff --git a/drivers/raw/ioat/Makefile b/drivers/raw/ioat/Makefile index
> 32f079845..e852afb57 100644
> --- a/drivers/raw/ioat/Makefile
> +++ b/drivers/raw/ioat/Makefile
> @@ -4,7 +4,7 @@
> include $(RTE_SDK)/mk/rte.vars.mk
>
> # library name
> -LIB = librte_pmd_ioat_rawdev.a
> +LIB = librte_rawdev_ioat.a
>
> # build flags
> CFLAGS += -O3
> @@ -18,7 +18,7 @@ LDLIBS += -lrte_mbuf -lrte_mempool LIBABIVER := 1
>
> # versioning export map
> -EXPORT_MAP := rte_pmd_ioat_version.map
> +EXPORT_MAP := rte_rawdev_ioat_version.map
>
> # library source files
> SRCS-$(CONFIG_RTE_LIBRTE_PMD_IOAT_RAWDEV) += ioat_rawdev.c diff --
> git a/drivers/raw/ioat/rte_pmd_ioat_version.map
> b/drivers/raw/ioat/rte_rawdev_ioat_version.map
> similarity index 100%
> rename from drivers/raw/ioat/rte_pmd_ioat_version.map
> rename to drivers/raw/ioat/rte_rawdev_ioat_version.map
> diff --git a/drivers/raw/meson.build b/drivers/raw/meson.build index
> bcd5553e1..d7037cd87 100644
> --- a/drivers/raw/meson.build
> +++ b/drivers/raw/meson.build
> @@ -7,4 +7,4 @@ drivers = ['dpaa2_cmdif', 'dpaa2_qdma',
> 'skeleton']
> std_deps = ['rawdev']
> config_flag_fmt = 'RTE_LIBRTE_PMD_@0@_RAWDEV'
> -driver_name_fmt = 'rte_pmd_@0@'
> +driver_name_fmt = 'rte_rawdev_@0@'
> diff --git a/drivers/raw/ntb/Makefile b/drivers/raw/ntb/Makefile index
> edd49fe75..6fe2aaf40 100644
> --- a/drivers/raw/ntb/Makefile
> +++ b/drivers/raw/ntb/Makefile
> @@ -6,7 +6,7 @@ include $(RTE_SDK)/mk/rte.vars.mk # # library name # -
> LIB = librte_pmd_ntb.a
> +LIB = librte_rawdev_ntb.a
>
> CFLAGS += -DALLOW_EXPERIMENTAL_API
> CFLAGS += -O3
> @@ -15,7 +15,7 @@ LDLIBS += -lrte_eal -lrte_mbuf -lrte_mempool LDLIBS
> += -lrte_pci -lrte_bus_pci LDLIBS += -lrte_rawdev
>
> -EXPORT_MAP := rte_pmd_ntb_version.map
> +EXPORT_MAP := rte_rawdev_ntb_version.map
>
> LIBABIVER := 1
>
> diff --git a/drivers/raw/ntb/rte_pmd_ntb_version.map
> b/drivers/raw/ntb/rte_rawdev_ntb_version.map
> similarity index 100%
> rename from drivers/raw/ntb/rte_pmd_ntb_version.map
> rename to drivers/raw/ntb/rte_rawdev_ntb_version.map
> diff --git a/drivers/raw/octeontx2_dma/Makefile
> b/drivers/raw/octeontx2_dma/Makefile
> index 96f782eb6..f101e4916 100644
> --- a/drivers/raw/octeontx2_dma/Makefile
> +++ b/drivers/raw/octeontx2_dma/Makefile
> @@ -5,7 +5,7 @@
> include $(RTE_SDK)/mk/rte.vars.mk
>
> # library name
> -LIB = librte_pmd_octeontx2_dma.a
> +LIB = librte_rawdev_octeontx2_dma.a
>
> CFLAGS += -O3 $(WERROR_FLAGS)
> CFLAGS += -I$(RTE_SDK)/drivers/common/octeontx2/
> @@ -22,7 +22,7 @@ CFLAGS += -diag-disable 2259 endif endif
>
> -EXPORT_MAP := rte_pmd_octeontx2_dma_version.map
> +EXPORT_MAP := rte_rawdev_octeontx2_dma_version.map
>
> LIBABIVER := 1
>
> diff --git
> a/drivers/raw/octeontx2_dma/rte_pmd_octeontx2_dma_version.map
> b/drivers/raw/octeontx2_dma/rte_rawdev_octeontx2_dma_version.map
> similarity index 100%
> rename from
> drivers/raw/octeontx2_dma/rte_pmd_octeontx2_dma_version.map
> rename to
> drivers/raw/octeontx2_dma/rte_rawdev_octeontx2_dma_version.map
> diff --git a/drivers/raw/skeleton/Makefile b/drivers/raw/skeleton/Makefile
> index 9641e6505..783b1e952 100644
> --- a/drivers/raw/skeleton/Makefile
> +++ b/drivers/raw/skeleton/Makefile
> @@ -6,7 +6,7 @@ include $(RTE_SDK)/mk/rte.vars.mk # # library name # -
> LIB = librte_pmd_skeleton_rawdev.a
> +LIB = librte_rawdev_skeleton.a
>
> CFLAGS += -O3
> CFLAGS += $(WERROR_FLAGS)
> @@ -15,7 +15,7 @@ LDLIBS += -lrte_rawdev LDLIBS += -lrte_bus_vdev
> LDLIBS += -lrte_kvargs
>
> -EXPORT_MAP := rte_pmd_skeleton_version.map
> +EXPORT_MAP := rte_rawdev_skeleton_version.map
>
> LIBABIVER := 1
>
> diff --git a/drivers/raw/skeleton/rte_pmd_skeleton_version.map
> b/drivers/raw/skeleton/rte_rawdev_skeleton_version.map
> similarity index 100%
> rename from drivers/raw/skeleton/rte_pmd_skeleton_version.map
> rename to drivers/raw/skeleton/rte_rawdev_skeleton_version.map
> diff --git a/mk/rte.app.mk b/mk/rte.app.mk index a277c808e..ba5c39e01
> 100644
> --- a/mk/rte.app.mk
> +++ b/mk/rte.app.mk
> @@ -312,19 +312,19 @@ _LDLIBS-
> $(CONFIG_RTE_LIBRTE_PMD_OPDL_EVENTDEV) += -lrte_pmd_opdl_event
> endif # CONFIG_RTE_LIBRTE_EVENTDEV
>
> ifeq ($(CONFIG_RTE_LIBRTE_RAWDEV),y)
> -_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_SKELETON_RAWDEV) += -
> lrte_pmd_skeleton_rawdev
> +_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_SKELETON_RAWDEV) +=
> +-lrte_rawdev_skeleton
> ifeq ($(CONFIG_RTE_EAL_VFIO)$(CONFIG_RTE_LIBRTE_FSLMC_BUS),yy)
> -_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_DPAA2_CMDIF_RAWDEV) += -
> lrte_pmd_dpaa2_cmdif
> -_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_DPAA2_QDMA_RAWDEV) += -
> lrte_pmd_dpaa2_qdma
> +_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_DPAA2_CMDIF_RAWDEV) +=
> +-lrte_rawdev_dpaa2_cmdif
> +_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_DPAA2_QDMA_RAWDEV) +=
> +-lrte_rawdev_dpaa2_qdma
> endif # CONFIG_RTE_LIBRTE_FSLMC_BUS
> _LDLIBS-$(CONFIG_RTE_LIBRTE_IFPGA_BUS) += -lrte_bus_ifpga
> ifeq ($(CONFIG_RTE_LIBRTE_IFPGA_BUS),y)
> -_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_IFPGA_RAWDEV) += -
> lrte_pmd_ifpga_rawdev
> +_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_IFPGA_RAWDEV) += -
> lrte_rawdev_ifpga
> _LDLIBS-$(CONFIG_RTE_LIBRTE_IPN3KE_PMD) += -lrte_pmd_ipn3ke
> endif # CONFIG_RTE_LIBRTE_IFPGA_BUS
> -_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_IOAT_RAWDEV) += -
> lrte_pmd_ioat_rawdev
> -_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_NTB_RAWDEV) += -lrte_pmd_ntb
> -_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_DMA_RAWDEV) += -
> lrte_pmd_octeontx2_dma
> +_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_IOAT_RAWDEV) += -
> lrte_rawdev_ioat
> +_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_NTB_RAWDEV) += -lrte_rawdev_ntb
> +_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_OCTEONTX2_DMA_RAWDEV) +=
> +-lrte_rawdev_octeontx2_dma
> endif # CONFIG_RTE_LIBRTE_RAWDEV
>
> endif # !CONFIG_RTE_BUILD_SHARED_LIBS
> --
> 2.21.0
Acked-by: Rosen Xu <rosen.xu@intel.com>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH] doc: announce lcore_config symbol removal
@ 2019-07-31 11:06 5% David Marchand
2019-07-31 13:48 0% ` Stephen Hemminger
2019-08-08 9:31 5% ` [dpdk-dev] [PATCH v2] " David Marchand
0 siblings, 2 replies; 200+ results
From: David Marchand @ 2019-07-31 11:06 UTC (permalink / raw)
To: dev; +Cc: thomas, stephen, bruce.richardson
New accessors have been introduced to provide the hidden information.
This symbol can now be kept internal.
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
doc/guides/rel_notes/deprecation.rst | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 37b8592..b18de70 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -23,6 +23,10 @@ Deprecation Notices
* eal: The function ``rte_eal_remote_launch`` will return new error codes
after read or write error on the pipe, instead of calling ``rte_panic``.
+* eal: the ``lcore_config`` struct and global symbol will be made private to
+ remove it from the externally visible ABI and allow it to be updated in the
+ future.
+
* 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
--
1.8.3.1
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH] doc: announce lcore_config symbol removal
2019-07-31 11:06 5% [dpdk-dev] [PATCH] doc: announce lcore_config symbol removal David Marchand
@ 2019-07-31 13:48 0% ` Stephen Hemminger
2019-08-08 9:31 5% ` [dpdk-dev] [PATCH v2] " David Marchand
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2019-07-31 13:48 UTC (permalink / raw)
To: David Marchand; +Cc: dev, thomas, bruce.richardson
On Wed, 31 Jul 2019 13:06:17 +0200
David Marchand <david.marchand@redhat.com> wrote:
> New accessors have been introduced to provide the hidden information.
> This symbol can now be kept internal.
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 37b8592..b18de70 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -23,6 +23,10 @@ Deprecation Notices
> * eal: The function ``rte_eal_remote_launch`` will return new error codes
> after read or write error on the pipe, instead of calling ``rte_panic``.
>
> +* eal: the ``lcore_config`` struct and global symbol will be made private to
> + remove it from the externally visible ABI and allow it to be updated in the
> + future.
> +
> * 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
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
^ permalink raw reply [relevance 0%]
* [dpdk-dev] [PATCH v2 0/3] doc: changes to abi policy introducing major abi versions
@ 2019-08-02 15:38 11% Ray Kinsella
2019-08-02 15:38 13% ` [dpdk-dev] [PATCH v2 1/3] doc: separate versioning.rst into version and policy Ray Kinsella
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Ray Kinsella @ 2019-08-02 15:38 UTC (permalink / raw)
To: dev
Cc: mdr, thomas, stephen, bruce.richardson, ferruh.yigit,
konstantin.ananyev, jerinj, olivier.matz, nhorman,
maxime.coquelin, hemant.agrawal
TL;DR Abbreviation:
A major ABI version that all DPDK releases during a one year period
support. ABI versioning is managed at a project-level, in place of library-level
management. ABI changes to add new features are permitted, as long as ABI
compatibility with the major ABI version is maintained.
Detail:
This patch introduces major ABI versions, supported for one year and released
aligned with the LTS release. This ABI version is then supported by all
subsequent releases within that one year period. The intention is that the one
year support period, will then be reviewed after the initial year with the
intention of lengthing the support period for the next ABI version.
ABI changes that preserve ABI compatibility with the major ABI version are
permitted in subsequent releases. ABI changes, follow similar approval rules as
before with the additional gate of now requiring technical board approval. The
merging and release of ABI breaking changes would now be pushed to the
declaration of the next major ABI version.
This change encourages developers to maintain ABI compatibility with the major
ABI version, by promoting a permissive culture around those changes that
preserve ABI compatibility. This approach begins to align DPDK with those
projects that declare major ABI versions (e.g. version 2.x, 3.x) and support
those versions for some period, typically two years or more.
To provide an example of how this might work in practice:
* DPDK v20 is declared as the supported ABI version for one year, aligned with
the DPDK v19.11 (LTS) release. All library sonames are updated to reflect the
new ABI version, e.g. librte_eal.so.20, librte_acl.so.20...
* DPDK v20.02 .. v20.08 releases are ABI compatible with the DPDK v20 ABI. ABI
changes are permitted from DPDK v20.02 onwards, with the condition that ABI
compatibility with DPDK v20 is preserved.
* DPDK v21 is declared as the new supported ABI version for two years, aligned
with the DPDK v20.11 (LTS) release. The DPDK v20 ABI is now depreciated,
library sonames are updated to v21 and ABI compatibility breaking changes may
be introduced.
---
v2
* Restructured the patch into 3 patches:
1. Splits the original versioning document into an ABI policy document
and ABI versioning document.
2. Add changes to the policy document introducing major ABI versions.
3. Fixes up the versioning document in light of major ABI versioning.
* Reduces the initial ABI stability from two years to one year, with a review
after the first year.
* Adds detail around ABI version handling for experimental libraries.
* Adds detail around chain of responsility for removing deprecated symbols.
Ray Kinsella (3):
doc: separate versioning.rst into version and policy
doc: changes to abi policy introducing major abi versions
doc: updates to versioning guide for abi versions
doc/guides/contributing/abi_policy.rst | 283 ++++++++++++++
doc/guides/contributing/abi_versioning.rst | 505 ++++++++++++++++++++++++
doc/guides/contributing/index.rst | 3 +-
doc/guides/contributing/stable.rst | 36 +-
doc/guides/contributing/versioning.rst | 591 -----------------------------
5 files changed, 810 insertions(+), 608 deletions(-)
create mode 100644 doc/guides/contributing/abi_policy.rst
create mode 100644 doc/guides/contributing/abi_versioning.rst
delete mode 100644 doc/guides/contributing/versioning.rst
--
2.7.4
^ permalink raw reply [relevance 11%]
* [dpdk-dev] [PATCH v2 1/3] doc: separate versioning.rst into version and policy
2019-08-02 15:38 11% [dpdk-dev] [PATCH v2 0/3] doc: changes to abi policy introducing major abi versions Ray Kinsella
@ 2019-08-02 15:38 13% ` Ray Kinsella
2019-08-02 15:38 32% ` [dpdk-dev] [PATCH v2 2/3] doc: changes to abi policy introducing major abi versions Ray Kinsella
2019-08-02 15:38 28% ` [dpdk-dev] [PATCH v2 3/3] doc: updates to versioning guide for " Ray Kinsella
2 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-08-02 15:38 UTC (permalink / raw)
To: dev
Cc: mdr, thomas, stephen, bruce.richardson, ferruh.yigit,
konstantin.ananyev, jerinj, olivier.matz, nhorman,
maxime.coquelin, hemant.agrawal
Separate versioning.rst into abi versioning and abi policy guidance, in
preparation for adding more detail to the abi policy.
Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
---
doc/guides/contributing/abi_policy.rst | 169 +++++++++
doc/guides/contributing/abi_versioning.rst | 427 +++++++++++++++++++++
doc/guides/contributing/index.rst | 3 +-
doc/guides/contributing/versioning.rst | 591 -----------------------------
4 files changed, 598 insertions(+), 592 deletions(-)
create mode 100644 doc/guides/contributing/abi_policy.rst
create mode 100644 doc/guides/contributing/abi_versioning.rst
delete mode 100644 doc/guides/contributing/versioning.rst
diff --git a/doc/guides/contributing/abi_policy.rst b/doc/guides/contributing/abi_policy.rst
new file mode 100644
index 0000000..55bacb4
--- /dev/null
+++ b/doc/guides/contributing/abi_policy.rst
@@ -0,0 +1,169 @@
+.. SPDX-License-Identifier: BSD-3-Clause
+ Copyright 2018 The DPDK contributors
+
+.. abi_api_policy:
+
+DPDK ABI/API policy
+===================
+
+Description
+-----------
+
+This document details some methods for handling ABI management in the DPDK.
+
+General Guidelines
+------------------
+
+#. Whenever possible, ABI should be preserved
+#. 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 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
+is the result of compilation. It is also effectively cloned when applications
+link to dynamic libraries. That is to say when an application is compiled to
+link against dynamic libraries, it is assumed that the ABI remains constant
+between the time the application is compiled/linked, and the time that it runs.
+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.
+
+
+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.
+
+ABI versions, once released, are available until such time as their
+deprecation has been noted in the Release Notes for at least one major release
+cycle. For example consider the case where the ABI for DPDK 2.0 has been
+shipped and then a decision is made to modify it during the development of
+DPDK 2.1. The decision will be recorded in the Release Notes for the DPDK 2.1
+release and the modification will be made available in the DPDK 2.2 release.
+
+ABI versions may be deprecated in whole or in part as needed by a given
+update.
+
+Some ABI changes may be too significant to reasonably maintain multiple
+versions. In those cases ABI's may be updated without backward compatibility
+being provided. The requirements for doing so are:
+
+#. At least 3 acknowledgments of the need to do so must be made on the
+ dpdk.org mailing list.
+
+ - The acknowledgment of the maintainer of the component is mandatory, or if
+ no maintainer is available for the component, the tree/sub-tree maintainer
+ for that component must acknowledge the ABI change instead.
+
+ - It is also recommended that acknowledgments from different "areas of
+ interest" be sought for each deprecation, for example: from NIC vendors,
+ CPU vendors, end-users, etc.
+
+#. 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.
+
+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
+be made to preserve the ABI whenever possible. The ABI should only be changed
+for significant reasons, such as performance enhancements. ABI breakage due to
+changes such as reorganizing public structure fields for aesthetic or
+readability purposes should be avoided.
+
+.. note::
+
+ Updates to the minimum hardware requirements, which drop support for hardware
+ which was previously supported, should be treated as an ABI change, and
+ 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.
+
+New API replacing previous one
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If a new API proposed functionally replaces an existing one, when the new API
+becomes non-experimental then the old one is marked with ``__rte_deprecated``.
+Deprecated APIs are removed completely just after the next LTS.
+
+Reminder that old API should follow deprecation process to be removed.
+
+
+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
+immediately after their introduction, as users begin to take advantage of
+those new APIs and start finding issues with them, new DPDK APIs will be
+automatically marked as ``experimental`` to allow for a period of stabilization
+before they become part of a tracked ABI.
+
+Note that marking an API as experimental is a multi step process.
+To mark an API as experimental, the symbols which are desired to be exported
+must be placed in an EXPERIMENTAL version block in the corresponding libraries'
+version map script.
+Secondly, the corresponding prototypes of those exported functions (in the
+development header files), must be marked with the ``__rte_experimental`` tag
+(see ``rte_compat.h``).
+The DPDK build makefiles perform a check to ensure that the map file and the
+C code reflect the same list of symbols.
+This check can be circumvented by defining ``ALLOW_EXPERIMENTAL_API``
+during compilation in the corresponding library Makefile.
+
+In addition to tagging the code with ``__rte_experimental``,
+the doxygen markup must also contain the EXPERIMENTAL string,
+and the MAINTAINERS file should note the EXPERIMENTAL libraries.
+
+For removing the experimental tag associated with an API, deprecation notice
+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.
diff --git a/doc/guides/contributing/abi_versioning.rst b/doc/guides/contributing/abi_versioning.rst
new file mode 100644
index 0000000..53e6ac0
--- /dev/null
+++ b/doc/guides/contributing/abi_versioning.rst
@@ -0,0 +1,427 @@
+.. SPDX-License-Identifier: BSD-3-Clause
+ Copyright 2018 The DPDK contributors
+
+.. library_versioning:
+
+Library versioning
+------------------
+
+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>``.
+
+
+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
+arguments. Occasionally that function may need to change to accommodate new
+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 ``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
+library so that older binaries need not be immediately recompiled.
+
+The macros exported are:
+
+* ``VERSION_SYMBOL(b, e, n)``: Creates a symbol version table entry binding
+ versioned symbol ``b@DPDK_n`` to the internal function ``b_e``.
+
+* ``BIND_DEFAULT_SYMBOL(b, e, n)``: Creates a symbol version entry instructing
+ the linker to bind references to symbol ``b`` to the internal symbol
+ ``b_e``.
+
+* ``MAP_STATIC_SYMBOL(f, p)``: Declare the prototype ``f``, and map it to the
+ fully qualified function ``p``, so that if a symbol becomes versioned, it
+ can still be mapped back to the public symbol name.
+
+Examples of ABI Macro use
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Updating a public API
+_____________________
+
+Assume we have a function as follows
+
+.. code-block:: c
+
+ /*
+ * Create an acl context object for apps to
+ * manipulate
+ */
+ struct rte_acl_ctx *
+ rte_acl_create(const struct rte_acl_param *param)
+ {
+ ...
+ }
+
+
+Assume that struct rte_acl_ctx is a private structure, and that a developer
+wishes to enhance the acl api so that a debugging flag can be enabled on a
+per-context basis. This requires an addition to the structure (which, being
+private, is safe), but it also requires modifying the code as follows
+
+.. code-block:: c
+
+ /*
+ * Create an acl context object for apps to
+ * manipulate
+ */
+ struct rte_acl_ctx *
+ rte_acl_create(const struct rte_acl_param *param, int debug)
+ {
+ ...
+ }
+
+
+Note also that, being a public function, the header file prototype must also be
+changed, as must all the call sites, to reflect the new ABI footprint. We will
+maintain previous ABI versions that are accessible only to previously compiled
+binaries
+
+The addition of a parameter to the function is ABI breaking as the function is
+public, and existing application may use it in its current form. However, the
+compatibility macros in DPDK allow a developer to use symbol versioning so that
+multiple functions can be mapped to the same public symbol based on when an
+application was linked to it. To see how this is done, we start with the
+requisite libraries version map file. Initially the version map file for the
+acl library looks like this
+
+.. code-block:: none
+
+ DPDK_2.0 {
+ global:
+
+ rte_acl_add_rules;
+ rte_acl_build;
+ rte_acl_classify;
+ rte_acl_classify_alg;
+ rte_acl_classify_scalar;
+ rte_acl_create;
+ rte_acl_dump;
+ rte_acl_find_existing;
+ rte_acl_free;
+ rte_acl_ipv4vlan_add_rules;
+ rte_acl_ipv4vlan_build;
+ rte_acl_list_dump;
+ rte_acl_reset;
+ rte_acl_reset_rules;
+ rte_acl_set_ctx_classify;
+
+ local: *;
+ };
+
+This file needs to be modified as follows
+
+.. code-block:: none
+
+ DPDK_2.0 {
+ global:
+
+ rte_acl_add_rules;
+ rte_acl_build;
+ rte_acl_classify;
+ rte_acl_classify_alg;
+ rte_acl_classify_scalar;
+ rte_acl_create;
+ rte_acl_dump;
+ rte_acl_find_existing;
+ rte_acl_free;
+ rte_acl_ipv4vlan_add_rules;
+ rte_acl_ipv4vlan_build;
+ rte_acl_list_dump;
+ rte_acl_reset;
+ rte_acl_reset_rules;
+ rte_acl_set_ctx_classify;
+
+ local: *;
+ };
+
+ DPDK_2.1 {
+ global:
+ rte_acl_create;
+
+ } DPDK_2.0;
+
+The addition of the new block tells the linker that a new version node is
+available (DPDK_2.1), which contains the symbol rte_acl_create, and inherits the
+symbols from the DPDK_2.0 node. This list is directly translated into a list of
+exported symbols when DPDK is compiled as a shared library
+
+Next, we need to specify in the code which function map to the rte_acl_create
+symbol at which versions. First, at the site of the initial symbol definition,
+we need to update the function so that it is uniquely named, and not in conflict
+with the public symbol name
+
+.. code-block:: c
+
+ struct rte_acl_ctx *
+ -rte_acl_create(const struct rte_acl_param *param)
+ +rte_acl_create_v20(const struct rte_acl_param *param)
+ {
+ size_t sz;
+ struct rte_acl_ctx *ctx;
+ ...
+
+Note that the base name of the symbol was kept intact, as this is conducive to
+the macros used for versioning symbols. That is our next step, mapping this new
+symbol name to the initial symbol name at version node 2.0. Immediately after
+the function, we add this line of code
+
+.. code-block:: c
+
+ VERSION_SYMBOL(rte_acl_create, _v20, 2.0);
+
+Remembering to also add the rte_compat.h header to the requisite c file where
+these changes are being made. The above macro instructs the linker to create a
+new symbol ``rte_acl_create@DPDK_2.0``, which matches the symbol created in older
+builds, but now points to the above newly named function. We have now mapped
+the original rte_acl_create symbol to the original function (but with a new
+name)
+
+Next, we need to create the 2.1 version of the symbol. We create a new function
+name, with a different suffix, and implement it appropriately
+
+.. code-block:: c
+
+ struct rte_acl_ctx *
+ rte_acl_create_v21(const struct rte_acl_param *param, int debug);
+ {
+ struct rte_acl_ctx *ctx = rte_acl_create_v20(param);
+
+ ctx->debug = debug;
+
+ return ctx;
+ }
+
+This code serves as our new API call. Its the same as our old call, but adds
+the new parameter in place. Next we need to map this function to the symbol
+``rte_acl_create@DPDK_2.1``. To do this, we modify the public prototype of the call
+in the header file, adding the macro there to inform all including applications,
+that on re-link, the default rte_acl_create symbol should point to this
+function. Note that we could do this by simply naming the function above
+rte_acl_create, and the linker would chose the most recent version tag to apply
+in the version script, but we can also do this in the header file
+
+.. code-block:: c
+
+ struct rte_acl_ctx *
+ -rte_acl_create(const struct rte_acl_param *param);
+ +rte_acl_create(const struct rte_acl_param *param, int debug);
+ +BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 2.1);
+
+The BIND_DEFAULT_SYMBOL macro explicitly tells applications that include this
+header, to link to the rte_acl_create_v21 function and apply the DPDK_2.1
+version node to it. This method is more explicit and flexible than just
+re-implementing the exact symbol name, and allows for other features (such as
+linking to the old symbol version by default, when the new ABI is to be opt-in
+for a period.
+
+One last thing we need to do. Note that we've taken what was a public symbol,
+and duplicated it into two uniquely and differently named symbols. We've then
+mapped each of those back to the public symbol ``rte_acl_create`` with different
+version tags. This only applies to dynamic linking, as static linking has no
+notion of versioning. That leaves this code in a position of no longer having a
+symbol simply named ``rte_acl_create`` and a static build will fail on that
+missing symbol.
+
+To correct this, we can simply map a function of our choosing back to the public
+symbol in the static build with the ``MAP_STATIC_SYMBOL`` macro. Generally the
+assumption is that the most recent version of the symbol is the one you want to
+map. So, back in the C file where, immediately after ``rte_acl_create_v21`` is
+defined, we add this
+
+.. code-block:: c
+
+ struct rte_acl_ctx *
+ rte_acl_create_v21(const struct rte_acl_param *param, int debug)
+ {
+ ...
+ }
+ MAP_STATIC_SYMBOL(struct rte_acl_ctx *rte_acl_create(const struct rte_acl_param *param, int debug), rte_acl_create_v21);
+
+That tells the compiler that, when building a static library, any calls to the
+symbol ``rte_acl_create`` should be linked to ``rte_acl_create_v21``
+
+That's it, on the next shared library rebuild, there will be two versions of
+rte_acl_create, an old DPDK_2.0 version, used by previously built applications,
+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.
+After having gone through the ABI deprecation announcement process, removal is
+easy. Start by removing the symbol from the requisite version map file:
+
+.. code-block:: none
+
+ DPDK_2.0 {
+ global:
+
+ rte_acl_add_rules;
+ rte_acl_build;
+ rte_acl_classify;
+ rte_acl_classify_alg;
+ rte_acl_classify_scalar;
+ rte_acl_dump;
+ - rte_acl_create
+ rte_acl_find_existing;
+ rte_acl_free;
+ rte_acl_ipv4vlan_add_rules;
+ rte_acl_ipv4vlan_build;
+ rte_acl_list_dump;
+ rte_acl_reset;
+ rte_acl_reset_rules;
+ rte_acl_set_ctx_classify;
+
+ local: *;
+ };
+
+ DPDK_2.1 {
+ global:
+ rte_acl_create;
+ } DPDK_2.0;
+
+
+Next remove the corresponding versioned export.
+
+.. code-block:: c
+
+ -VERSION_SYMBOL(rte_acl_create, _v20, 2.0);
+
+
+Note that the internal function definition could also be removed, but its used
+in our example by the newer version _v21, so we leave it in place. This is a
+coding style choice.
+
+Lastly, we need to bump the LIBABIVER number for this library in the Makefile to
+indicate to applications doing dynamic linking that this is a later, and
+possibly incompatible library version:
+
+.. code-block:: c
+
+ -LIBABIVER := 1
+ +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
+specifies an API, then removing part of it, typically makes it incomplete. In
+those cases it is better to remove the entire node
+
+To do this, start by modifying the version map file, such that all symbols from
+the node to be removed are merged into the next node in the map
+
+In the case of our map above, it would transform to look as follows
+
+.. code-block:: none
+
+ DPDK_2.1 {
+ global:
+
+ rte_acl_add_rules;
+ rte_acl_build;
+ rte_acl_classify;
+ rte_acl_classify_alg;
+ rte_acl_classify_scalar;
+ rte_acl_dump;
+ rte_acl_create
+ rte_acl_find_existing;
+ rte_acl_free;
+ rte_acl_ipv4vlan_add_rules;
+ rte_acl_ipv4vlan_build;
+ rte_acl_list_dump;
+ rte_acl_reset;
+ rte_acl_reset_rules;
+ rte_acl_set_ctx_classify;
+
+ local: *;
+ };
+
+Then any uses of BIND_DEFAULT_SYMBOL that pointed to the old node should be
+updated to point to the new version node in any header files for all affected
+symbols.
+
+.. code-block:: c
+
+ -BIND_DEFAULT_SYMBOL(rte_acl_create, _v20, 2.0);
+ +BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 2.1);
+
+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
+-------------------------
+
+The ``devtools`` directory in the DPDK source tree contains a utility program,
+``validate-abi.sh``, for validating the DPDK ABI based on the Linux `ABI
+Compliance Checker
+<http://ispras.linuxbase.org/index.php/ABI_compliance_checker>`_.
+
+This has a dependency on the ``abi-compliance-checker`` and ``and abi-dumper``
+utilities which can be installed via a package manager. For example::
+
+ sudo yum install abi-compliance-checker
+ sudo yum install abi-dumper
+
+The syntax of the ``validate-abi.sh`` utility is::
+
+ ./devtools/validate-abi.sh <REV1> <REV2>
+
+Where ``REV1`` and ``REV2`` are valid gitrevisions(7)
+https://www.kernel.org/pub/software/scm/git/docs/gitrevisions.html
+on the local repo.
+
+For example::
+
+ # Check between the previous and latest commit:
+ ./devtools/validate-abi.sh HEAD~1 HEAD
+
+ # Check on a specific compilation target:
+ ./devtools/validate-abi.sh -t x86_64-native-linux-gcc HEAD~1 HEAD
+
+ # Check between two tags:
+ ./devtools/validate-abi.sh v2.0.0 v2.1.0
+
+ # Check between git master and local topic-branch "vhost-hacking":
+ ./devtools/validate-abi.sh master vhost-hacking
+
+After the validation script completes (it can take a while since it need to
+compile both tags) it will create compatibility reports in the
+``./abi-check/compat_report`` directory. Listed incompatibilities can be found
+as follows::
+
+ grep -lr Incompatible abi-check/compat_reports/
diff --git a/doc/guides/contributing/index.rst b/doc/guides/contributing/index.rst
index e2608d3..2fefd91 100644
--- a/doc/guides/contributing/index.rst
+++ b/doc/guides/contributing/index.rst
@@ -10,7 +10,8 @@ Contributor's Guidelines
coding_style
design
- versioning
+ abi_policy
+ abi_versioning
documentation
patches
vulnerability
diff --git a/doc/guides/contributing/versioning.rst b/doc/guides/contributing/versioning.rst
deleted file mode 100644
index 3ab2c43..0000000
--- a/doc/guides/contributing/versioning.rst
+++ /dev/null
@@ -1,591 +0,0 @@
-.. SPDX-License-Identifier: BSD-3-Clause
- Copyright 2018 The DPDK contributors
-
-DPDK ABI/API policy
-===================
-
-Description
------------
-
-This document details some methods for handling ABI management in the DPDK.
-
-General Guidelines
-------------------
-
-#. Whenever possible, ABI should be preserved
-#. 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 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
-is the result of compilation. It is also effectively cloned when applications
-link to dynamic libraries. That is to say when an application is compiled to
-link against dynamic libraries, it is assumed that the ABI remains constant
-between the time the application is compiled/linked, and the time that it runs.
-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.
-
-
-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.
-
-ABI versions, once released, are available until such time as their
-deprecation has been noted in the Release Notes for at least one major release
-cycle. For example consider the case where the ABI for DPDK 2.0 has been
-shipped and then a decision is made to modify it during the development of
-DPDK 2.1. The decision will be recorded in the Release Notes for the DPDK 2.1
-release and the modification will be made available in the DPDK 2.2 release.
-
-ABI versions may be deprecated in whole or in part as needed by a given
-update.
-
-Some ABI changes may be too significant to reasonably maintain multiple
-versions. In those cases ABI's may be updated without backward compatibility
-being provided. The requirements for doing so are:
-
-#. At least 3 acknowledgments of the need to do so must be made on the
- dpdk.org mailing list.
-
- - The acknowledgment of the maintainer of the component is mandatory, or if
- no maintainer is available for the component, the tree/sub-tree maintainer
- for that component must acknowledge the ABI change instead.
-
- - It is also recommended that acknowledgments from different "areas of
- interest" be sought for each deprecation, for example: from NIC vendors,
- CPU vendors, end-users, etc.
-
-#. 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.
-
-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
-be made to preserve the ABI whenever possible. The ABI should only be changed
-for significant reasons, such as performance enhancements. ABI breakage due to
-changes such as reorganizing public structure fields for aesthetic or
-readability purposes should be avoided.
-
-.. note::
-
- Updates to the minimum hardware requirements, which drop support for hardware
- which was previously supported, should be treated as an ABI change, and
- 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.
-
-New API replacing previous one
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-If a new API proposed functionally replaces an existing one, when the new API
-becomes non-experimental then the old one is marked with ``__rte_deprecated``.
-Deprecated APIs are removed completely just after the next LTS.
-
-Reminder that old API should follow deprecation process to be removed.
-
-
-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
-immediately after their introduction, as users begin to take advantage of
-those new APIs and start finding issues with them, new DPDK APIs will be
-automatically marked as ``experimental`` to allow for a period of stabilization
-before they become part of a tracked ABI.
-
-Note that marking an API as experimental is a multi step process.
-To mark an API as experimental, the symbols which are desired to be exported
-must be placed in an EXPERIMENTAL version block in the corresponding libraries'
-version map script.
-Secondly, the corresponding prototypes of those exported functions (in the
-development header files), must be marked with the ``__rte_experimental`` tag
-(see ``rte_compat.h``).
-The DPDK build makefiles perform a check to ensure that the map file and the
-C code reflect the same list of symbols.
-This check can be circumvented by defining ``ALLOW_EXPERIMENTAL_API``
-during compilation in the corresponding library Makefile.
-
-In addition to tagging the code with ``__rte_experimental``,
-the doxygen markup must also contain the EXPERIMENTAL string,
-and the MAINTAINERS file should note the EXPERIMENTAL libraries.
-
-For removing the experimental tag associated with an API, deprecation notice
-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.
-
-
-Library versioning
-------------------
-
-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>``.
-
-
-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
-arguments. Occasionally that function may need to change to accommodate new
-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 ``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
-library so that older binaries need not be immediately recompiled.
-
-The macros exported are:
-
-* ``VERSION_SYMBOL(b, e, n)``: Creates a symbol version table entry binding
- versioned symbol ``b@DPDK_n`` to the internal function ``b_e``.
-
-* ``BIND_DEFAULT_SYMBOL(b, e, n)``: Creates a symbol version entry instructing
- the linker to bind references to symbol ``b`` to the internal symbol
- ``b_e``.
-
-* ``MAP_STATIC_SYMBOL(f, p)``: Declare the prototype ``f``, and map it to the
- fully qualified function ``p``, so that if a symbol becomes versioned, it
- can still be mapped back to the public symbol name.
-
-Examples of ABI Macro use
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Updating a public API
-_____________________
-
-Assume we have a function as follows
-
-.. code-block:: c
-
- /*
- * Create an acl context object for apps to
- * manipulate
- */
- struct rte_acl_ctx *
- rte_acl_create(const struct rte_acl_param *param)
- {
- ...
- }
-
-
-Assume that struct rte_acl_ctx is a private structure, and that a developer
-wishes to enhance the acl api so that a debugging flag can be enabled on a
-per-context basis. This requires an addition to the structure (which, being
-private, is safe), but it also requires modifying the code as follows
-
-.. code-block:: c
-
- /*
- * Create an acl context object for apps to
- * manipulate
- */
- struct rte_acl_ctx *
- rte_acl_create(const struct rte_acl_param *param, int debug)
- {
- ...
- }
-
-
-Note also that, being a public function, the header file prototype must also be
-changed, as must all the call sites, to reflect the new ABI footprint. We will
-maintain previous ABI versions that are accessible only to previously compiled
-binaries
-
-The addition of a parameter to the function is ABI breaking as the function is
-public, and existing application may use it in its current form. However, the
-compatibility macros in DPDK allow a developer to use symbol versioning so that
-multiple functions can be mapped to the same public symbol based on when an
-application was linked to it. To see how this is done, we start with the
-requisite libraries version map file. Initially the version map file for the
-acl library looks like this
-
-.. code-block:: none
-
- DPDK_2.0 {
- global:
-
- rte_acl_add_rules;
- rte_acl_build;
- rte_acl_classify;
- rte_acl_classify_alg;
- rte_acl_classify_scalar;
- rte_acl_create;
- rte_acl_dump;
- rte_acl_find_existing;
- rte_acl_free;
- rte_acl_ipv4vlan_add_rules;
- rte_acl_ipv4vlan_build;
- rte_acl_list_dump;
- rte_acl_reset;
- rte_acl_reset_rules;
- rte_acl_set_ctx_classify;
-
- local: *;
- };
-
-This file needs to be modified as follows
-
-.. code-block:: none
-
- DPDK_2.0 {
- global:
-
- rte_acl_add_rules;
- rte_acl_build;
- rte_acl_classify;
- rte_acl_classify_alg;
- rte_acl_classify_scalar;
- rte_acl_create;
- rte_acl_dump;
- rte_acl_find_existing;
- rte_acl_free;
- rte_acl_ipv4vlan_add_rules;
- rte_acl_ipv4vlan_build;
- rte_acl_list_dump;
- rte_acl_reset;
- rte_acl_reset_rules;
- rte_acl_set_ctx_classify;
-
- local: *;
- };
-
- DPDK_2.1 {
- global:
- rte_acl_create;
-
- } DPDK_2.0;
-
-The addition of the new block tells the linker that a new version node is
-available (DPDK_2.1), which contains the symbol rte_acl_create, and inherits the
-symbols from the DPDK_2.0 node. This list is directly translated into a list of
-exported symbols when DPDK is compiled as a shared library
-
-Next, we need to specify in the code which function map to the rte_acl_create
-symbol at which versions. First, at the site of the initial symbol definition,
-we need to update the function so that it is uniquely named, and not in conflict
-with the public symbol name
-
-.. code-block:: c
-
- struct rte_acl_ctx *
- -rte_acl_create(const struct rte_acl_param *param)
- +rte_acl_create_v20(const struct rte_acl_param *param)
- {
- size_t sz;
- struct rte_acl_ctx *ctx;
- ...
-
-Note that the base name of the symbol was kept intact, as this is conducive to
-the macros used for versioning symbols. That is our next step, mapping this new
-symbol name to the initial symbol name at version node 2.0. Immediately after
-the function, we add this line of code
-
-.. code-block:: c
-
- VERSION_SYMBOL(rte_acl_create, _v20, 2.0);
-
-Remembering to also add the rte_compat.h header to the requisite c file where
-these changes are being made. The above macro instructs the linker to create a
-new symbol ``rte_acl_create@DPDK_2.0``, which matches the symbol created in older
-builds, but now points to the above newly named function. We have now mapped
-the original rte_acl_create symbol to the original function (but with a new
-name)
-
-Next, we need to create the 2.1 version of the symbol. We create a new function
-name, with a different suffix, and implement it appropriately
-
-.. code-block:: c
-
- struct rte_acl_ctx *
- rte_acl_create_v21(const struct rte_acl_param *param, int debug);
- {
- struct rte_acl_ctx *ctx = rte_acl_create_v20(param);
-
- ctx->debug = debug;
-
- return ctx;
- }
-
-This code serves as our new API call. Its the same as our old call, but adds
-the new parameter in place. Next we need to map this function to the symbol
-``rte_acl_create@DPDK_2.1``. To do this, we modify the public prototype of the call
-in the header file, adding the macro there to inform all including applications,
-that on re-link, the default rte_acl_create symbol should point to this
-function. Note that we could do this by simply naming the function above
-rte_acl_create, and the linker would chose the most recent version tag to apply
-in the version script, but we can also do this in the header file
-
-.. code-block:: c
-
- struct rte_acl_ctx *
- -rte_acl_create(const struct rte_acl_param *param);
- +rte_acl_create(const struct rte_acl_param *param, int debug);
- +BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 2.1);
-
-The BIND_DEFAULT_SYMBOL macro explicitly tells applications that include this
-header, to link to the rte_acl_create_v21 function and apply the DPDK_2.1
-version node to it. This method is more explicit and flexible than just
-re-implementing the exact symbol name, and allows for other features (such as
-linking to the old symbol version by default, when the new ABI is to be opt-in
-for a period.
-
-One last thing we need to do. Note that we've taken what was a public symbol,
-and duplicated it into two uniquely and differently named symbols. We've then
-mapped each of those back to the public symbol ``rte_acl_create`` with different
-version tags. This only applies to dynamic linking, as static linking has no
-notion of versioning. That leaves this code in a position of no longer having a
-symbol simply named ``rte_acl_create`` and a static build will fail on that
-missing symbol.
-
-To correct this, we can simply map a function of our choosing back to the public
-symbol in the static build with the ``MAP_STATIC_SYMBOL`` macro. Generally the
-assumption is that the most recent version of the symbol is the one you want to
-map. So, back in the C file where, immediately after ``rte_acl_create_v21`` is
-defined, we add this
-
-.. code-block:: c
-
- struct rte_acl_ctx *
- rte_acl_create_v21(const struct rte_acl_param *param, int debug)
- {
- ...
- }
- MAP_STATIC_SYMBOL(struct rte_acl_ctx *rte_acl_create(const struct rte_acl_param *param, int debug), rte_acl_create_v21);
-
-That tells the compiler that, when building a static library, any calls to the
-symbol ``rte_acl_create`` should be linked to ``rte_acl_create_v21``
-
-That's it, on the next shared library rebuild, there will be two versions of
-rte_acl_create, an old DPDK_2.0 version, used by previously built applications,
-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.
-After having gone through the ABI deprecation announcement process, removal is
-easy. Start by removing the symbol from the requisite version map file:
-
-.. code-block:: none
-
- DPDK_2.0 {
- global:
-
- rte_acl_add_rules;
- rte_acl_build;
- rte_acl_classify;
- rte_acl_classify_alg;
- rte_acl_classify_scalar;
- rte_acl_dump;
- - rte_acl_create
- rte_acl_find_existing;
- rte_acl_free;
- rte_acl_ipv4vlan_add_rules;
- rte_acl_ipv4vlan_build;
- rte_acl_list_dump;
- rte_acl_reset;
- rte_acl_reset_rules;
- rte_acl_set_ctx_classify;
-
- local: *;
- };
-
- DPDK_2.1 {
- global:
- rte_acl_create;
- } DPDK_2.0;
-
-
-Next remove the corresponding versioned export.
-
-.. code-block:: c
-
- -VERSION_SYMBOL(rte_acl_create, _v20, 2.0);
-
-
-Note that the internal function definition could also be removed, but its used
-in our example by the newer version _v21, so we leave it in place. This is a
-coding style choice.
-
-Lastly, we need to bump the LIBABIVER number for this library in the Makefile to
-indicate to applications doing dynamic linking that this is a later, and
-possibly incompatible library version:
-
-.. code-block:: c
-
- -LIBABIVER := 1
- +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
-specifies an API, then removing part of it, typically makes it incomplete. In
-those cases it is better to remove the entire node
-
-To do this, start by modifying the version map file, such that all symbols from
-the node to be removed are merged into the next node in the map
-
-In the case of our map above, it would transform to look as follows
-
-.. code-block:: none
-
- DPDK_2.1 {
- global:
-
- rte_acl_add_rules;
- rte_acl_build;
- rte_acl_classify;
- rte_acl_classify_alg;
- rte_acl_classify_scalar;
- rte_acl_dump;
- rte_acl_create
- rte_acl_find_existing;
- rte_acl_free;
- rte_acl_ipv4vlan_add_rules;
- rte_acl_ipv4vlan_build;
- rte_acl_list_dump;
- rte_acl_reset;
- rte_acl_reset_rules;
- rte_acl_set_ctx_classify;
-
- local: *;
- };
-
-Then any uses of BIND_DEFAULT_SYMBOL that pointed to the old node should be
-updated to point to the new version node in any header files for all affected
-symbols.
-
-.. code-block:: c
-
- -BIND_DEFAULT_SYMBOL(rte_acl_create, _v20, 2.0);
- +BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 2.1);
-
-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
--------------------------
-
-The ``devtools`` directory in the DPDK source tree contains a utility program,
-``validate-abi.sh``, for validating the DPDK ABI based on the Linux `ABI
-Compliance Checker
-<http://ispras.linuxbase.org/index.php/ABI_compliance_checker>`_.
-
-This has a dependency on the ``abi-compliance-checker`` and ``and abi-dumper``
-utilities which can be installed via a package manager. For example::
-
- sudo yum install abi-compliance-checker
- sudo yum install abi-dumper
-
-The syntax of the ``validate-abi.sh`` utility is::
-
- ./devtools/validate-abi.sh <REV1> <REV2>
-
-Where ``REV1`` and ``REV2`` are valid gitrevisions(7)
-https://www.kernel.org/pub/software/scm/git/docs/gitrevisions.html
-on the local repo.
-
-For example::
-
- # Check between the previous and latest commit:
- ./devtools/validate-abi.sh HEAD~1 HEAD
-
- # Check on a specific compilation target:
- ./devtools/validate-abi.sh -t x86_64-native-linux-gcc HEAD~1 HEAD
-
- # Check between two tags:
- ./devtools/validate-abi.sh v2.0.0 v2.1.0
-
- # Check between git master and local topic-branch "vhost-hacking":
- ./devtools/validate-abi.sh master vhost-hacking
-
-After the validation script completes (it can take a while since it need to
-compile both tags) it will create compatibility reports in the
-``./abi-check/compat_report`` directory. Listed incompatibilities can be found
-as follows::
-
- grep -lr Incompatible abi-check/compat_reports/
--
2.7.4
^ permalink raw reply [relevance 13%]
* [dpdk-dev] [PATCH v2 2/3] doc: changes to abi policy introducing major abi versions
2019-08-02 15:38 11% [dpdk-dev] [PATCH v2 0/3] doc: changes to abi policy introducing major abi versions Ray Kinsella
2019-08-02 15:38 13% ` [dpdk-dev] [PATCH v2 1/3] doc: separate versioning.rst into version and policy Ray Kinsella
@ 2019-08-02 15:38 32% ` Ray Kinsella
2019-08-02 15:38 28% ` [dpdk-dev] [PATCH v2 3/3] doc: updates to versioning guide for " Ray Kinsella
2 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-08-02 15:38 UTC (permalink / raw)
To: dev
Cc: mdr, thomas, stephen, bruce.richardson, ferruh.yigit,
konstantin.ananyev, jerinj, olivier.matz, nhorman,
maxime.coquelin, hemant.agrawal
This policy change introduces major ABI versions, these are
declared every year, typically aligned with the LTS release
and are supported by subsequent releases in the following year.
This change is intended to improve ABI stabilty for those projects
consuming DPDK.
Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
---
doc/guides/contributing/abi_policy.rst | 272 +++++++++++++++++++++++----------
doc/guides/contributing/stable.rst | 36 +++--
2 files changed, 213 insertions(+), 95 deletions(-)
diff --git a/doc/guides/contributing/abi_policy.rst b/doc/guides/contributing/abi_policy.rst
index 55bacb4..fa78622 100644
--- a/doc/guides/contributing/abi_policy.rst
+++ b/doc/guides/contributing/abi_policy.rst
@@ -1,5 +1,5 @@
.. SPDX-License-Identifier: BSD-3-Clause
- Copyright 2018 The DPDK contributors
+ Copyright 2019 The DPDK contributors
.. abi_api_policy:
@@ -9,25 +9,37 @@ DPDK ABI/API policy
Description
-----------
-This document details some methods for handling ABI management in the DPDK.
+This document details the DPDK ABI/API management policy, to ensure the
+long-term stability of the DPDK ABI/API.
General Guidelines
------------------
-#. Whenever possible, ABI should be preserved
-#. 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 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
-~~~~~~~~~~~~~~
+#. Major ABI versions are declared every **year** and are then supported
+ for one year, typically aligned with the LTS release.
+#. ABI versioning is managed at a project level in DPDK, with the supported ABI
+ version reflected in all library's soname.
+#. The ABI should be preserved and not changed lightly. The ABI may still be
+ changed, by following the outlined deprecation process.
+#. The addition of symbols is generally not problematic. The modification of
+ symbols should be managed with ABI versioning.
+#. The removal of symbols is considered an ABI breakage, once approved these
+ will form part of the next ABI version.
+#. Libraries or APIs marked as ``experimental`` are not considered part of the
+ major ABI version and may change without constraint.
+#. Updates to the minimum hardware requirements, which drop support for hardware
+ which was previously supported, should be treated as an ABI change.
+
+.. note::
+
+ Note that in 2019 the DPDK community stated it's intention to move to ABI
+ stable releases over a number of releases. Beginning with maintaining ABI
+ stability through one year of DPDK releases starting from DPDK 19.11. This
+ policy will be reviewed in 2020 with intention of lengthening the stability
+ period.
+
+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,30 +51,40 @@ 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.
-
-ABI/API Deprecation
+The DPDK ABI policy
-------------------
-The DPDK ABI policy
-~~~~~~~~~~~~~~~~~~~
+A major ABI version is declared every years, aligned with that years LTS
+release, e.g. v19.11 . This ABI version is then supported for one year by all
+subsequent releases within that time period, until the next LTS release, e.g.
+v20.11.
+
+At the declaration of a major ABI version, major version numbers encoded in
+libraries soname's are bumped to indicate the new version, with minor version
+reset to 0. An example would be ``librte_eal.so.20.3`` would become
+``librte_eal.so.21.0``.
+
+The ABI may then change multiple times, without warning, between the last major
+ABI version increment and the HEAD label of the git tree, with the condition
+that ABI compatibility with the major ABI version is preserved and therefore
+soname's do not change.
-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.
+Minor versions are incremented to indicate the release of a new ABI compatible
+DPDK release, typically the DPDK quarterly releases. An example of this, might
+be that ``librte_eal.so.20.1`` would indicate the first ABI compatible DPDK
+release, following the declaration of the new major ABI version 20.0.
-ABI versions, once released, are available until such time as their
-deprecation has been noted in the Release Notes for at least one major release
-cycle. For example consider the case where the ABI for DPDK 2.0 has been
-shipped and then a decision is made to modify it during the development of
-DPDK 2.1. The decision will be recorded in the Release Notes for the DPDK 2.1
-release and the modification will be made available in the DPDK 2.2 release.
+ABI versions, are supported by each release until such time as the next major
+ABI version is declared. At that time, the deprecation of the previous major ABI
+version will be noted in the Release Notes with guidance on individual symbol
+depreciation and upgrade notes provided.
-ABI versions may be deprecated in whole or in part as needed by a given
-update.
+ABI Changes
+~~~~~~~~~~~
-Some ABI changes may be too significant to reasonably maintain multiple
-versions. In those cases ABI's may be updated without backward compatibility
-being provided. The requirements for doing so are:
+The ABI may still change after the declaration of a major ABI version, that is
+new APIs may be still added or existing APIs may be modified. The requirements
+for doing so are:
#. At least 3 acknowledgments of the need to do so must be made on the
dpdk.org mailing list.
@@ -71,81 +93,165 @@ being provided. The requirements for doing so are:
no maintainer is available for the component, the tree/sub-tree maintainer
for that component must acknowledge the ABI change instead.
+ - The acknowledgment of a member of the technical board, as a delegate of the
+ `technical board <https://core.dpdk.org/techboard/>`_ acknowledging the
+ need for the ABI change, is also mandatory.
+
- It is also recommended that acknowledgments from different "areas of
interest" be sought for each deprecation, for example: from NIC vendors,
CPU vendors, end-users, etc.
-#. 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.
+#. Backward compatibly with the major ABI version must be maintained through
+ `<ABI versioning>`_, with forward-only compatibility offered for any ABI
+ changes that are indicated to be part of the next ABI version.
+
+ - In situations were backward compatibility is not possible, read the
+ section `<ABI Breakages>`_.
-#. A full deprecation cycle, as explained above, must be made to offer
- downstream consumers sufficient warning of the change.
+ - No backward or forward compatibility is offered for API changes marked as
+ ``experimental``, as described in the section `<Experimental APIs>`_.
-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
-be made to preserve the ABI whenever possible. The ABI should only be changed
-for significant reasons, such as performance enhancements. ABI breakage due to
-changes such as reorganizing public structure fields for aesthetic or
-readability purposes should be avoided.
+#. If a newly proposed API functionally replaces an existing one, when the new
+ API becomes non-experimental, then the old one is marked with
+ ``__rte_deprecated``.
+
+ - The depreciated API should follow the notification process to be removed,
+ see `<Examples of Deprecation Notices>`_;
+
+ - At the declaration of the next major ABI version, those ABI changes then
+ become a formal part of the new ABI and the requirement to preserve ABI
+ compatibility with the last major ABI version is then dropped.
+
+ - The responsibility for removing ABI compatibility preserving code rests
+ with the original contributor of the ABI changes, then with the
+ contributor's company and then finally with the maintainer.
+
+.. note::
+
+ 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
+ be made to preserve the ABI whenever possible. The ABI should only be changed
+ for significant reasons, such as performance enhancements. ABI breakage due
+ to changes such as reorganizing public structure fields for aesthetic or
+ readability purposes should be avoided.
+
+.. _forward-only:
+
+.. note::
+
+ Note that forward-only compatibility is offered for those changes made
+ between major ABI versions. As a library's soname however only describes
+ compatibility with the last major ABI version, until the next major ABI
+ version is declared, these changes therefore cannot be resolved as a runtime
+ dependency through the soname. Therefore any application wishing to make use
+ of these ABI changes can only ensure that it's runtime dependencies are met
+ through Operating System package versioning.
.. note::
Updates to the minimum hardware requirements, which drop support for hardware
which was previously supported, should be treated as an ABI change, and
- follow the relevant deprecation policy procedures as above: 3 acks and
- announcement at least one release in advance.
+ follow the relevant deprecation policy procedures as above: 3 acks, technical
+ board approval and announcement at least one release in advance.
+
+
+ABI Breakages
+^^^^^^^^^^^^^
+
+For those ABI changes that may be too significant to reasonably maintain
+multiple versions. In those cases, ABIs may be updated without backward
+compatibility being provided.
+
+The additional requirements to approve an ABI breakage, on top of those
+that described in the section `<ABI Changes>`_ are:
+
+#. ABI breaking 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
+ at the declaration of the next major ABI version.
+
+#. Once approved and after the depreciation notice has been observed these
+ changes will form part of the next declared major ABI version.
+
+Examples of ABI Changes
+^^^^^^^^^^^^^^^^^^^^^^^
+
+The following are examples of allowable ABI changes occurring between
+declarations of major ABI versions.
+
+* DPDK 19.11 release, defines the function ``rte_foo()``, and ``rte_foo()``
+ as part of the major ABI version DPDK 20.0.
+
+* DPDK 20.02 release defines a new function ``rte_foo(uint8_t bar)``, and
+ this is not a problem as long as the symbol ``rte_foo@DPDK20.0`` is
+ preserved through `<ABI versioning>`_.
+
+ - The new function may be marked with the ``__rte_experimental`` tag for a
+ number of releases, as described in the section `<Experimental APIs>`_;
+
+ - Once ``rte_foo(uint8_t bar)`` becomes non-experimental ``rte_foo()`` is then
+ declared as ``__rte_depreciated``, with an associated deprecation notice
+ provided.
+
+* DPDK 19.11 is not re-released to include ``rte_foo(uint8_t bar)``, the new
+ version of ``rte_foo`` only exists from DPDK 20.02 onwards as described in the
+ note on `forward-only`_ compatibility.
+
+* DPDK 20.02 release defines the experimental function ``__rte_experimental
+ rte_baz()``. This function may or may not exist in the DPDK 20.05 release.
+
+* An application ``dPacket`` wishes to use ``rte_foo(uint8_t bar)``, before the
+ declaration of the DPDK 21.0 major API version. The application can only
+ ensure it's runtime dependencies are met by specifying ``DPDK (>= 20.2)`` as
+ an explicit package dependency, as the soname only may only indicate the
+ supporting major ABI version.
+
+* At the release of DPDK 20.11, the function ``rte_foo(uint8_t bar)`` becomes
+ formally part of then new major ABI version DPDK 21.0 and ``rte_foo()`` may be
+ removed.
+
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 Macro ``#RTE_FOO`` is deprecated and will be removed with ABI version
+ 21.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
+ in version 20.2. Backwards compatibility will be maintained for this function
+ until the release of the new DPDK major ABI version 21.0, in DPDK version
+ 20.11.
-* The members of ``struct rte_foo`` have been reorganized in release 2.0 for
+* The members of ``struct rte_foo`` have been reorganized in DPDK 20.02 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
+ compatibility in release 20.02, while newly built binaries will need to
+ reference the new structure variant ``struct rte_foo2``. Compatibility will be
+ removed in release 20.11, 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,
+ upcoming release 20.02 will not contain these changes, but release 20.11 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
+ these changes. Binaries using this library built prior to ABI version 21 will
require updating and recompilation.
-New API replacing previous one
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Experimental
+------------
-If a new API proposed functionally replaces an existing one, when the new API
-becomes non-experimental then the old one is marked with ``__rte_deprecated``.
-Deprecated APIs are removed completely just after the next LTS.
+APIs
+~~~~
-Reminder that old API should follow deprecation process to be removed.
-
-
-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
-immediately after their introduction, as users begin to take advantage of
-those new APIs and start finding issues with them, new DPDK APIs will be
-automatically marked as ``experimental`` to allow for a period of stabilization
-before they become part of a tracked ABI.
+APIs marked as ``experimental`` are not considered part of an ABI version and
+may change without warning at any time. Since changes to APIs are most likely
+immediately after their introduction, as users begin to take advantage of those
+new APIs and start finding issues with them, new DPDK APIs will be automatically
+marked as ``experimental`` to allow for a period of stabilization before they
+become part of a tracked ABI version.
Note that marking an API as experimental is a multi step process.
To mark an API as experimental, the symbols which are desired to be exported
@@ -167,3 +273,11 @@ For removing the experimental tag associated with an API, deprecation notice
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.
+
+Libraries
+~~~~~~~~~
+
+Libraries marked as ``experimental`` are entirely not considered part of an ABI
+version, and may change without warning at any time. Experimental libraries
+always have a major version of ``0`` to indicate they exist outside of ABI
+versioning, with minor version incremented with each ABI change to library.
diff --git a/doc/guides/contributing/stable.rst b/doc/guides/contributing/stable.rst
index 6a5eee9..db783c7 100644
--- a/doc/guides/contributing/stable.rst
+++ b/doc/guides/contributing/stable.rst
@@ -53,6 +53,9 @@ year's November (X.11) release will be maintained as an LTS for 2 years.
After the X.11 release, an LTS branch will be created for it at
http://git.dpdk.org/dpdk-stable where bugfixes will be backported to.
+A LTS release may align with the declaration of a new major ABI version,
+please read the `<DPDK ABI/API policy>`_ for more information.
+
It is anticipated that there will be at least 4 releases per year of the LTS
or approximately 1 every 3 months. However, the cadence can be shorter or
longer depending on the number and criticality of the backported
@@ -68,10 +71,13 @@ point the LTS branch will no longer be maintained with no further releases.
What changes should be backported
---------------------------------
-Backporting should be limited to bug fixes. All patches accepted on the master
-branch with a Fixes: tag should be backported to the relevant stable/LTS
-branches, unless the submitter indicates otherwise. If there are exceptions,
-they will be discussed on the mailing lists.
+Backporting is a naturally conservative activity, and therefore should only
+include bug fixes and support for new hardware, were adding support does not
+necessitate DPDK ABI/API changes.
+
+All patches accepted on the master branch with a Fixes: tag should be backported
+to the relevant stable/LTS branches, unless the submitter indicates otherwise.
+If there are exceptions, they will be discussed on the mailing lists.
Fixes suitable for backport should have a ``Cc: stable@dpdk.org`` tag in the
commit message body as follows::
@@ -86,13 +92,18 @@ commit message body as follows::
Signed-off-by: Alex Smith <alex.smith@example.com>
-Fixes not suitable for backport should not include the ``Cc: stable@dpdk.org`` tag.
+Fixes not suitable for backport should not include the ``Cc: stable@dpdk.org``
+tag.
-Features should not be backported to stable releases. It may be acceptable, in
-limited cases, to back port features for the LTS release where:
+New features, with the exception of new hardware support, should not be
+backported to stable releases. In the case of new hardware support or any other
+exceptional circumstances limited backporting maybe permitted to the LTS release
+where:
-* There is a justifiable use case (for example a new PMD).
-* The change is non-invasive.
+* There is a justifiable use case, for example the change is required to support
+ a new platform or device (for example a new PMD).
+* The change is ABI/API preserving, it does not present an obvious "new feature"
+ to end consumer.
* The work of preparing the backport is done by the proposer.
* There is support within the community.
@@ -119,10 +130,3 @@ A Stable Release will be released by:
list.
Stable releases are available on the `dpdk.org download page <http://core.dpdk.org/download/>`_.
-
-
-ABI
----
-
-The Stable Release should not be seen as a way of breaking or circumventing
-the DPDK ABI policy.
--
2.7.4
^ permalink raw reply [relevance 32%]
* [dpdk-dev] [PATCH v2 3/3] doc: updates to versioning guide for abi versions
2019-08-02 15:38 11% [dpdk-dev] [PATCH v2 0/3] doc: changes to abi policy introducing major abi versions Ray Kinsella
2019-08-02 15:38 13% ` [dpdk-dev] [PATCH v2 1/3] doc: separate versioning.rst into version and policy Ray Kinsella
2019-08-02 15:38 32% ` [dpdk-dev] [PATCH v2 2/3] doc: changes to abi policy introducing major abi versions Ray Kinsella
@ 2019-08-02 15:38 28% ` Ray Kinsella
2 siblings, 0 replies; 200+ results
From: Ray Kinsella @ 2019-08-02 15:38 UTC (permalink / raw)
To: dev
Cc: mdr, thomas, stephen, bruce.richardson, ferruh.yigit,
konstantin.ananyev, jerinj, olivier.matz, nhorman,
maxime.coquelin, hemant.agrawal
Updates to the ABI versioning guide, to account for the changes to the DPDK
ABI/API policy.
Signed-off-by: Ray Kinsella <mdr@ashroe.eu>
---
doc/guides/contributing/abi_versioning.rst | 240 +++++++++++++++++++----------
1 file changed, 159 insertions(+), 81 deletions(-)
diff --git a/doc/guides/contributing/abi_versioning.rst b/doc/guides/contributing/abi_versioning.rst
index 53e6ac0..38f5ec3 100644
--- a/doc/guides/contributing/abi_versioning.rst
+++ b/doc/guides/contributing/abi_versioning.rst
@@ -1,44 +1,128 @@
.. SPDX-License-Identifier: BSD-3-Clause
Copyright 2018 The DPDK contributors
-.. library_versioning:
-
-Library versioning
+DPDK ABI Versioning
+===================
+
+This document details the mechanics of ABI version management in DPDK.
+
+What is a library's soname?
+---------------------------
+
+System libraries usually adopt the familiar major and minor version naming
+convention, where major versions (e.g. ``librte_eal 20.x, 21.x``) are presumed
+to be ABI incompatible with each other and minor versions (e.g. ``librte_eal
+20.1, 20.2``) are presumed to be ABI compatible. A library's `soname
+<https://en.wikipedia.org/wiki/Soname>`_. is typically used to provide backward
+compatibility information about a given library, describing the lowest common
+denominator ABI supported by the library. The soname or logical name for the
+library, is typically comprised of the library's name and major version e.g.
+``librte_eal.so.20``.
+
+During an application's build process, a library's soname is noted as a runtime
+dependency of the application. This information is then used by the `dynamic
+linker <https://en.wikipedia.org/wiki/Dynamic_linker>`_ when resolving the
+applications dependencies at runtime, to load a library supporting the correct
+ABI version. The library loaded at runtime therefore, may be a minor revision
+supporting the same major abi version (e.g. ``librte_eal.20.2``), as the library
+used to link the application (e.g ``librte_eal.20.0``).
+
+Major ABI versions
------------------
-Downstreams might want to provide different DPDK releases at the same time to
-support multiple consumers of DPDK linked against older and newer sonames.
+An ABI version change to a given library, especially in core libraries such as
+``librte_mbuf``, may cause an implicit ripple effect on the ABI of it's
+dependent libraries, causing ABI breakages. There may however be no explicit
+reason to bump a dependent library's ABI version, as there may have been no
+obvious change to the dependent library's API, even though the library's ABI
+compatibility will have been broken.
+
+This interdependence of DPDK libraries, means that ABI versioning of libraries
+is more manageable at a project level, with all project libraries sharing a
+**single ABI version**. In addition, the need to maintain a stable ABI for some
+number of releases as described in the section `<The DPDK ABI policy>`_, means
+that ABI version increments need to carefully planned and managed at a project
+level.
+
+Major ABI versions are therefore declared typically aligned with an LTS release
+and is then supported some number of subsequent releases, shared across all
+libraries. This means that a single project level ABI version, reflected in all
+individual library's soname, library filenames and associated version maps
+persists over multiple releases.
+
+.. code-block:: none
-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.
+ $ head ./lib/librte_acl/rte_acl_version.map
+ DPDK_20.0 {
+ global:
+ ...
-Think of LibA that got an ABI bump and LibB that did not get an ABI bump but is
-depending on LibA.
+ $ head ./lib/librte_eal/rte_eal_version.map
+ DPDK_20.0 {
+ global:
+ ...
-.. note::
+When an ABI change is made between major ABI versions to a given library, a new
+section is added to that library's version map describing the impending new ABI
+version, as described in the section `<Examples of ABI Macro use>`_. The
+library's soname and filename however do not change, e.g. ``libacl.so.20``, as
+ABI compatibility with the last major ABI version continues to be preserved for
+that library.
- Application
- \-> LibA.old
- \-> LibB.new -> LibA.new
+.. code-block:: none
-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>``.
+ $ head ./lib/librte_acl/rte_acl_version.map
+ DPDK_20.0 {
+ global:
+ ...
+ DPDK_21.0 {
+ global:
+
+ } DPDK_20.0;
+ ...
+
+ $ head ./lib/librte_eal/rte_eal_version.map
+ DPDK_20.0 {
+ global:
+ ...
+
+However when a new ABI version is declared, for example DPDK 21.0, old
+depreciated functions may be safely removed at this point and the entire old
+major ABI version removed, see section `<Deprecating an entire ABI version>`_ on
+how this may be done.
+
+.. code-block:: none
+
+ $ head ./lib/librte_acl/rte_acl_version.map
+ DPDK_21.0 {
+ global:
+ ...
+
+ $ head -n 3 ./lib/librte_eal/rte_eal_version.map
+ DPDK_21.0 {
+ global:
+ ...
+
+At the same time, the major ABI version is changed atomically across all
+libraries by incrementing the major version in individual library's soname, e.g.
+``libacl.so.21``. This is done by bumping the LIBABIVER number in the libraries
+Makefile to indicate to dynamic linking applications that this is a later, and
+possibly incompatible library version:
+
+.. code-block:: c
+
+ -LIBABIVER := 20
+ +LIBABIVER := 21
-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
arguments. Occasionally that function may need to change to accommodate new
-functionality or behavior. When that occurs, it is desirable to allow for
+functionality or behavior. When that occurs, it is may be required to allow for
backward compatibility for a time with older binaries that are dynamically
linked to the DPDK.
@@ -62,7 +146,7 @@ The macros exported are:
can still be mapped back to the public symbol name.
Examples of ABI Macro use
-^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~
Updating a public API
_____________________
@@ -106,16 +190,16 @@ maintain previous ABI versions that are accessible only to previously compiled
binaries
The addition of a parameter to the function is ABI breaking as the function is
-public, and existing application may use it in its current form. However, the
+public, and existing application may use it in its current form. However, the
compatibility macros in DPDK allow a developer to use symbol versioning so that
multiple functions can be mapped to the same public symbol based on when an
-application was linked to it. To see how this is done, we start with the
-requisite libraries version map file. Initially the version map file for the
-acl library looks like this
+application was linked to it. To see how this is done, we start with the
+requisite libraries version map file. Initially the version map file for the acl
+library looks like this
.. code-block:: none
- DPDK_2.0 {
+ DPDK_20.0 {
global:
rte_acl_add_rules;
@@ -141,7 +225,7 @@ This file needs to be modified as follows
.. code-block:: none
- DPDK_2.0 {
+ DPDK_20.0 {
global:
rte_acl_add_rules;
@@ -163,16 +247,16 @@ This file needs to be modified as follows
local: *;
};
- DPDK_2.1 {
+ DPDK_21.0 {
global:
rte_acl_create;
- } DPDK_2.0;
+ } DPDK_20.0;
The addition of the new block tells the linker that a new version node is
-available (DPDK_2.1), which contains the symbol rte_acl_create, and inherits the
-symbols from the DPDK_2.0 node. This list is directly translated into a list of
-exported symbols when DPDK is compiled as a shared library
+available (DPDK_21.0), which contains the symbol rte_acl_create, and inherits
+the symbols from the DPDK_20.0 node. This list is directly translated into a
+list of exported symbols when DPDK is compiled as a shared library
Next, we need to specify in the code which function map to the rte_acl_create
symbol at which versions. First, at the site of the initial symbol definition,
@@ -191,22 +275,22 @@ with the public symbol name
Note that the base name of the symbol was kept intact, as this is conducive to
the macros used for versioning symbols. That is our next step, mapping this new
-symbol name to the initial symbol name at version node 2.0. Immediately after
+symbol name to the initial symbol name at version node 20.0. Immediately after
the function, we add this line of code
.. code-block:: c
- VERSION_SYMBOL(rte_acl_create, _v20, 2.0);
+ VERSION_SYMBOL(rte_acl_create, _v20, 20.0);
Remembering to also add the rte_compat.h header to the requisite c file where
-these changes are being made. The above macro instructs the linker to create a
-new symbol ``rte_acl_create@DPDK_2.0``, which matches the symbol created in older
-builds, but now points to the above newly named function. We have now mapped
-the original rte_acl_create symbol to the original function (but with a new
-name)
+these changes are being made. The above macro instructs the linker to create a
+new symbol ``rte_acl_create@DPDK_20.0``, which matches the symbol created in
+older builds, but now points to the above newly named function. We have now
+mapped the original rte_acl_create symbol to the original function (but with a
+new name)
-Next, we need to create the 2.1 version of the symbol. We create a new function
-name, with a different suffix, and implement it appropriately
+Next, we need to create the 21.0 version of the symbol. We create a new function
+name, with a different suffix, and implement it appropriately
.. code-block:: c
@@ -220,12 +304,12 @@ name, with a different suffix, and implement it appropriately
return ctx;
}
-This code serves as our new API call. Its the same as our old call, but adds
-the new parameter in place. Next we need to map this function to the symbol
-``rte_acl_create@DPDK_2.1``. To do this, we modify the public prototype of the call
-in the header file, adding the macro there to inform all including applications,
-that on re-link, the default rte_acl_create symbol should point to this
-function. Note that we could do this by simply naming the function above
+This code serves as our new API call. Its the same as our old call, but adds the
+new parameter in place. Next we need to map this function to the symbol
+``rte_acl_create@DPDK_21.0``. To do this, we modify the public prototype of the
+call in the header file, adding the macro there to inform all including
+applications, that on re-link, the default rte_acl_create symbol should point to
+this function. Note that we could do this by simply naming the function above
rte_acl_create, and the linker would chose the most recent version tag to apply
in the version script, but we can also do this in the header file
@@ -233,11 +317,11 @@ in the version script, but we can also do this in the header file
struct rte_acl_ctx *
-rte_acl_create(const struct rte_acl_param *param);
- +rte_acl_create(const struct rte_acl_param *param, int debug);
- +BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 2.1);
+ +rte_acl_create_v21(const struct rte_acl_param *param, int debug);
+ +BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 21.0);
The BIND_DEFAULT_SYMBOL macro explicitly tells applications that include this
-header, to link to the rte_acl_create_v21 function and apply the DPDK_2.1
+header, to link to the rte_acl_create_v21 function and apply the DPDK_21.0
version node to it. This method is more explicit and flexible than just
re-implementing the exact symbol name, and allows for other features (such as
linking to the old symbol version by default, when the new ABI is to be opt-in
@@ -257,6 +341,7 @@ assumption is that the most recent version of the symbol is the one you want to
map. So, back in the C file where, immediately after ``rte_acl_create_v21`` is
defined, we add this
+
.. code-block:: c
struct rte_acl_ctx *
@@ -270,21 +355,22 @@ That tells the compiler that, when building a static library, any calls to the
symbol ``rte_acl_create`` should be linked to ``rte_acl_create_v21``
That's it, on the next shared library rebuild, there will be two versions of
-rte_acl_create, an old DPDK_2.0 version, used by previously built applications,
-and a new DPDK_2.1 version, used by future built applications.
+rte_acl_create, an old DPDK_20.0 version, used by previously built applications,
+and a new DPDK_21.0 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.
-After having gone through the ABI deprecation announcement process, removal is
-easy. Start by removing the symbol from the requisite version map file:
+Lets assume that you've done the above update, and in preparation for the next
+major ABI version you decide you would like to retire the old version of the
+function. After having gone through the ABI deprecation announcement process,
+removal is easy. Start by removing the symbol from the requisite version map
+file:
.. code-block:: none
- DPDK_2.0 {
+ DPDK_20.0 {
global:
rte_acl_add_rules;
@@ -306,10 +392,10 @@ easy. Start by removing the symbol from the requisite version map file:
local: *;
};
- DPDK_2.1 {
+ DPDK_21.0 {
global:
rte_acl_create;
- } DPDK_2.0;
+ } DPDK_20.0;
Next remove the corresponding versioned export.
@@ -320,34 +406,26 @@ Next remove the corresponding versioned export.
Note that the internal function definition could also be removed, but its used
-in our example by the newer version _v21, so we leave it in place. This is a
-coding style choice.
-
-Lastly, we need to bump the LIBABIVER number for this library in the Makefile to
-indicate to applications doing dynamic linking that this is a later, and
-possibly incompatible library version:
-
-.. code-block:: c
-
- -LIBABIVER := 1
- +LIBABIVER := 2
+in our example by the newer version _v21, so we leave it in place and declare it
+as static. This is a coding style choice.
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
-specifies an API, then removing part of it, typically makes it incomplete. In
-those cases it is better to remove the entire node
+While removing a symbol from an ABI may be useful, it is more practical to
+remove an entire version node at once, as is typically done at the declaration
+of a major ABI version. If a version node completely specifies an API, then
+removing part of it, typically makes it incomplete. In those cases it is better
+to remove the entire node.
To do this, start by modifying the version map file, such that all symbols from
-the node to be removed are merged into the next node in the map
+the node to be removed are merged into the next node in the map.
In the case of our map above, it would transform to look as follows
.. code-block:: none
- DPDK_2.1 {
+ DPDK_21.0 {
global:
rte_acl_add_rules;
@@ -375,8 +453,8 @@ symbols.
.. code-block:: c
- -BIND_DEFAULT_SYMBOL(rte_acl_create, _v20, 2.0);
- +BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 2.1);
+ -BIND_DEFAULT_SYMBOL(rte_acl_create, _v20, 20.0);
+ +BIND_DEFAULT_SYMBOL(rte_acl_create, _v21, 21.0);
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
--
2.7.4
^ permalink raw reply [relevance 28%]
* [dpdk-dev] [PATCH] doc: remove major in designation of normal releases
@ 2019-08-05 12:30 11% Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-08-05 12:30 UTC (permalink / raw)
To: John McNamara, Marko Kovacevic; +Cc: dev, orika
The word "major" was used to differentiate with release candidates
or stable maintenance releases.
However the word "major" can be understood as "LTS",
so it is less confusing to avoid this word.
Reported-by: Ori Kam <orika@mellanox.com>
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
doc/guides/contributing/documentation.rst | 2 +-
doc/guides/contributing/stable.rst | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/guides/contributing/documentation.rst b/doc/guides/contributing/documentation.rst
index 27e4b13be..550d8dec2 100644
--- a/doc/guides/contributing/documentation.rst
+++ b/doc/guides/contributing/documentation.rst
@@ -62,7 +62,7 @@ added to by the developer.
The Release Notes document which features have been added in the current and previous releases of DPDK and highlight
any known issues.
- The Releases Notes also contain notifications of features that will change ABI compatibility in the next major release.
+ The Releases Notes also contain notifications of features that will change ABI compatibility in the next release.
Developers should include updates to the Release Notes with patch sets that relate to any of the following sections:
diff --git a/doc/guides/contributing/stable.rst b/doc/guides/contributing/stable.rst
index 6a5eee9bd..24b9e8b7d 100644
--- a/doc/guides/contributing/stable.rst
+++ b/doc/guides/contributing/stable.rst
@@ -25,7 +25,7 @@ Release to indicate longer term support.
Stable Releases
---------------
-Any major release of DPDK can be designated as a Stable Release if a
+Any release of DPDK can be designated as a Stable Release if a
maintainer volunteers to maintain it and there is a commitment from major
contributors to validate it before releases. If a release is to be designated
as a Stable Release, it should be done by 1 month after the master release.
--
2.21.0
^ permalink raw reply [relevance 11%]
* Re: [dpdk-dev] [PATCH v2 0/10] dpdk: introduce __rte_internal tag
@ 2019-08-06 10:03 0% ` Thomas Monjalon
2019-08-06 12:21 0% ` Neil Horman
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-08-06 10:03 UTC (permalink / raw)
To: Neil Horman; +Cc: dev, Jerin Jacob Kollanukkaran, Bruce Richardson
I think it would be good to rebase and send at the beginning of the 19.11 cycle.
Thank you
13/06/2019 16:23, Neil Horman:
> Hey-
> Based on our recent conversations regarding the use of symbols only
> meant for internal dpdk consumption (between dpdk libraries), this is an idea
> that I've come up with that I'd like to get some feedback on
>
> Summary:
> 1) We have symbols in the DPDK that are meant to be used between DPDK libraries,
> but not by applications linking to them
> 2) We would like to document those symbols in the code, so as to note them
> clearly as for being meant for internal use only
> 3) Linker symbol visibility is a very coarse grained tool, and so there is no
> good way in a single library to mark items as being meant for use only by other
> DPDK libraries, at least not without some extensive runtime checking
>
>
> Proposal:
> I'm proposing that we introduce the __rte_internal tag. From a coding
> standpoint it works a great deal like the __rte_experimental tag in that it
> expempts the tagged symbol from ABI constraints (as the only users should be
> represented in the DPDK build environment). Additionally, the __rte_internal
> macro resolves differently based on the definition of the BUILDING_RTE_SDK flag
> (working under the assumption that said flag should only ever be set if we are
> actually building DPDK libraries which will make use of internal calls). If the
> BUILDING_RTE_SDK flag is set __rte_internal resolves to __attribute__((section
> "text.internal)), placing it in a special text section which is then used to
> validate that the the symbol appears in the INTERNAL section of the
> corresponding library version map). If BUILDING_RTE_SDK is not set, then
> __rte_internal resolves to __attribute__((error("..."))), which causes any
> caller of the tagged function to throw an error at compile time, indicating that
> the symbol is not available for external use.
>
> This isn't a perfect solution, as applications can still hack around it of
> course, but I think it hits some of the high points, restricting symbol access
> for any library that prototypes its public and private symbols in the same
> header file, excluding the internal symbols from ABI constraints, and clearly
> documenting those symbols which we wish to limit to internal usage.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for rte flow RSS action
2019-07-04 4:46 4% [dpdk-dev] [PATCH] doc: announce ABI change for rte flow RSS action simei
@ 2019-08-06 11:31 4% ` Thomas Monjalon
2019-08-06 11:38 4% ` Zhang, Qi Z
2019-08-06 11:40 4% ` Zhang, Qi Z
0 siblings, 2 replies; 200+ results
From: Thomas Monjalon @ 2019-08-06 11:31 UTC (permalink / raw)
To: simei
Cc: dev, qi.z.zhang, jingjing.wu, beilei.xing, qiming.yang,
adrien.mazarguil, orika
04/07/2019 06:46, simei:
> From: Simei Su <simei.su@intel.com>
>
> Add new structure inputset in rte_flow_action_rss. This
> can support input set configuration by rte_flow RSS action.
>
> Signed-off-by: Simei Su <simei.su@intel.com>
> ---
> +* ethdev: New member in ``rte_flow_action_rss`` to support input set change
> + by rte_flow RSS action. It ignores spec and focuses on mask only.
There is no comment on this proposal.
I think it is missing some explanations about its usage.
Would you like to explain an use case and the rte_flow command?
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for RSS hash funtion
2019-07-04 4:43 4% [dpdk-dev] [PATCH] doc: announce ABI change for RSS hash funtion simei
@ 2019-08-06 11:34 4% ` Thomas Monjalon
2019-08-06 14:45 4% ` Ananyev, Konstantin
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2019-08-06 11:34 UTC (permalink / raw)
To: simei
Cc: dev, qi.z.zhang, jingjing.wu, beilei.xing, qiming.yang, orika,
adrien.mazarguil, arybchenko, ferruh.yigit
04/07/2019 06:43, simei:
> From: Simei Su <simei.su@intel.com>
>
> Add new field SYMMETRIC_TOEPLITZ in rte_eth_hash_function. This
> can support symmetric hash function by rte_flow RSS action.
>
> Signed-off-by: Simei Su <simei.su@intel.com>
> ---
> +* ethdev: New member in ``rte_eth_hash_funtion`` to support symmetric hash funtion.
That's unfortunate there is a typo in the name of the enum you want to change.
Do you have any reference to the algo you want to support? A paper maybe?
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for rte flow RSS action
2019-08-06 11:31 4% ` Thomas Monjalon
@ 2019-08-06 11:38 4% ` Zhang, Qi Z
2019-08-06 11:40 4% ` Zhang, Qi Z
1 sibling, 0 replies; 200+ results
From: Zhang, Qi Z @ 2019-08-06 11:38 UTC (permalink / raw)
To: Thomas Monjalon, Su, Simei
Cc: dev, Wu, Jingjing, Xing, Beilei, Yang, Qiming, adrien.mazarguil, orika
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Tuesday, August 6, 2019 7:31 PM
> To: Su, Simei <simei.su@intel.com>
> Cc: dev@dpdk.org; Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing
> <jingjing.wu@intel.com>; Xing, Beilei <beilei.xing@intel.com>; Yang, Qiming
> <qiming.yang@intel.com>; adrien.mazarguil@6wind.com;
> orika@mellanox.com
> Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI change for rte flow RSS
> action
>
> 04/07/2019 06:46, simei:
> > From: Simei Su <simei.su@intel.com>
> >
> > Add new structure inputset in rte_flow_action_rss. This can support
> > input set configuration by rte_flow RSS action.
> >
> > Signed-off-by: Simei Su <simei.su@intel.com>
> > ---
> > +* ethdev: New member in ``rte_flow_action_rss`` to support input set
> > +change
> > + by rte_flow RSS action. It ignores spec and focuses on mask only.
>
> There is no comment on this proposal.
> I think it is missing some explanations about its usage.
> Would you like to explain an use case and the rte_flow command?
>
This has been replaced by
http://patches.dpdk.org/patch/56064/
We don't need it now, I have updated patch status on patchwork.
Thanks
Qi
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for rte flow RSS action
2019-08-06 11:31 4% ` Thomas Monjalon
2019-08-06 11:38 4% ` Zhang, Qi Z
@ 2019-08-06 11:40 4% ` Zhang, Qi Z
1 sibling, 0 replies; 200+ results
From: Zhang, Qi Z @ 2019-08-06 11:40 UTC (permalink / raw)
To: Thomas Monjalon, Su, Simei
Cc: dev, Wu, Jingjing, Xing, Beilei, Yang, Qiming, adrien.mazarguil, orika
> -----Original Message-----
> From: Zhang, Qi Z
> Sent: Tuesday, August 6, 2019 7:39 PM
> To: 'Thomas Monjalon' <thomas@monjalon.net>; Su, Simei
> <simei.su@intel.com>
> Cc: dev@dpdk.org; Wu, Jingjing <jingjing.wu@intel.com>; Xing, Beilei
> <beilei.xing@intel.com>; Yang, Qiming <qiming.yang@intel.com>;
> adrien.mazarguil@6wind.com; orika@mellanox.com
> Subject: RE: [dpdk-dev] [PATCH] doc: announce ABI change for rte flow RSS
> action
>
>
>
> > -----Original Message-----
> > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > Sent: Tuesday, August 6, 2019 7:31 PM
> > To: Su, Simei <simei.su@intel.com>
> > Cc: dev@dpdk.org; Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing
> > <jingjing.wu@intel.com>; Xing, Beilei <beilei.xing@intel.com>; Yang,
> > Qiming <qiming.yang@intel.com>; adrien.mazarguil@6wind.com;
> > orika@mellanox.com
> > Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI change for rte flow
> > RSS action
> >
> > 04/07/2019 06:46, simei:
> > > From: Simei Su <simei.su@intel.com>
> > >
> > > Add new structure inputset in rte_flow_action_rss. This can support
> > > input set configuration by rte_flow RSS action.
> > >
> > > Signed-off-by: Simei Su <simei.su@intel.com>
> > > ---
> > > +* ethdev: New member in ``rte_flow_action_rss`` to support input
> > > +set change
> > > + by rte_flow RSS action. It ignores spec and focuses on mask only.
> >
> > There is no comment on this proposal.
> > I think it is missing some explanations about its usage.
> > Would you like to explain an use case and the rte_flow command?
> >
>
> This has been replaced by
> http://patches.dpdk.org/patch/56064/
Sorry, the latest RFC should be http://patchwork.dpdk.org/patch/57346/
>
> We don't need it now, I have updated patch status on patchwork.
>
> Thanks
> Qi
>
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH v2 0/10] dpdk: introduce __rte_internal tag
2019-08-06 10:03 0% ` Thomas Monjalon
@ 2019-08-06 12:21 0% ` Neil Horman
0 siblings, 0 replies; 200+ results
From: Neil Horman @ 2019-08-06 12:21 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Jerin Jacob Kollanukkaran, Bruce Richardson
On Tue, Aug 06, 2019 at 12:03:38PM +0200, Thomas Monjalon wrote:
> I think it would be good to rebase and send at the beginning of the 19.11 cycle.
> Thank you
>
I'm on PTO for the next 10 days or so, but yes, I'll take care of that asap.
Thanks
Neil
> 13/06/2019 16:23, Neil Horman:
> > Hey-
> > Based on our recent conversations regarding the use of symbols only
> > meant for internal dpdk consumption (between dpdk libraries), this is an idea
> > that I've come up with that I'd like to get some feedback on
> >
> > Summary:
> > 1) We have symbols in the DPDK that are meant to be used between DPDK libraries,
> > but not by applications linking to them
> > 2) We would like to document those symbols in the code, so as to note them
> > clearly as for being meant for internal use only
> > 3) Linker symbol visibility is a very coarse grained tool, and so there is no
> > good way in a single library to mark items as being meant for use only by other
> > DPDK libraries, at least not without some extensive runtime checking
> >
> >
> > Proposal:
> > I'm proposing that we introduce the __rte_internal tag. From a coding
> > standpoint it works a great deal like the __rte_experimental tag in that it
> > expempts the tagged symbol from ABI constraints (as the only users should be
> > represented in the DPDK build environment). Additionally, the __rte_internal
> > macro resolves differently based on the definition of the BUILDING_RTE_SDK flag
> > (working under the assumption that said flag should only ever be set if we are
> > actually building DPDK libraries which will make use of internal calls). If the
> > BUILDING_RTE_SDK flag is set __rte_internal resolves to __attribute__((section
> > "text.internal)), placing it in a special text section which is then used to
> > validate that the the symbol appears in the INTERNAL section of the
> > corresponding library version map). If BUILDING_RTE_SDK is not set, then
> > __rte_internal resolves to __attribute__((error("..."))), which causes any
> > caller of the tagged function to throw an error at compile time, indicating that
> > the symbol is not available for external use.
> >
> > This isn't a perfect solution, as applications can still hack around it of
> > course, but I think it hits some of the high points, restricting symbol access
> > for any library that prototypes its public and private symbols in the same
> > header file, excluding the internal symbols from ABI constraints, and clearly
> > documenting those symbols which we wish to limit to internal usage.
>
>
>
>
>
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for RSS hash funtion
2019-08-06 11:34 4% ` Thomas Monjalon
@ 2019-08-06 14:45 4% ` Ananyev, Konstantin
2019-08-10 20:39 4% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Ananyev, Konstantin @ 2019-08-06 14:45 UTC (permalink / raw)
To: Thomas Monjalon, Su, Simei
Cc: dev, Zhang, Qi Z, Wu, Jingjing, Xing, Beilei, Yang, Qiming,
orika, adrien.mazarguil, arybchenko, Yigit, Ferruh
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Tuesday, August 6, 2019 12:35 PM
> To: Su, Simei <simei.su@intel.com>
> Cc: dev@dpdk.org; Zhang, Qi Z <qi.z.zhang@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>; Xing, Beilei <beilei.xing@intel.com>; Yang,
> Qiming <qiming.yang@intel.com>; orika@mellanox.com; adrien.mazarguil@6wind.com; arybchenko@solarflare.com; Yigit, Ferruh
> <ferruh.yigit@intel.com>
> Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI change for RSS hash funtion
>
> 04/07/2019 06:43, simei:
> > From: Simei Su <simei.su@intel.com>
> >
> > Add new field SYMMETRIC_TOEPLITZ in rte_eth_hash_function. This
> > can support symmetric hash function by rte_flow RSS action.
> >
> > Signed-off-by: Simei Su <simei.su@intel.com>
> > ---
> > +* ethdev: New member in ``rte_eth_hash_funtion`` to support symmetric hash funtion.
>
> That's unfortunate there is a typo in the name of the enum you want to change.
>
> Do you have any reference to the algo you want to support? A paper maybe?
If I am not mistaken that's just an intent to enable symmetric RSS hash-function via standard RSS rte_flow API -
feature already available with i40e and newest Intel HW.
(AFAIK on i40e right now it could be configured via RTE_ETH_HASH_FILTER_SYM_HASH_ENA_PER_PORT).
If so, then I think the author may need to mention what PMDs will support that feature in 19.11.
Konstantin
>
>
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH 1/2] doc: announce ethdev ABI change for LRO fields
@ 2019-08-06 14:56 4% Matan Azrad
2019-08-06 15:27 4% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Matan Azrad @ 2019-08-06 14:56 UTC (permalink / raw)
To: dev
Cc: Thomas Monjalon, Ferruh Yigit, Andrew Rybchenko,
Konstantin Ananyev, Olivier Matz
It may be needed by the user to limit the LRO session packet size.
In order to allow the above limitation, a new Rx configuration may be
added for the maximum LRO session size.
A new capability may be added too to expose the maximum LRO session size
supported by the port.
Signed-off-by: Matan Azrad <matan@mellanox.com>
---
doc/guides/rel_notes/deprecation.rst | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 37b8592..c0cd9bc 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -59,6 +59,10 @@ Deprecation Notices
Target release for removal of the legacy API will be defined once most
PMDs have switched to rte_flow.
+* ethdev: new 32-bit fields may be added for maximum LRO session size, in
+ struct ``rte_eth_dev_info`` for the port capability and in struct
+ ``rte_eth_rxmode`` for the port configuration.
+
* cryptodev: support for using IV with all sizes is added, J0 still can
be used but only when IV length in following structs ``rte_crypto_auth_xform``,
``rte_crypto_aead_xform`` is set to zero. When IV length is greater or equal
--
1.8.3.1
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH 1/2] doc: announce ethdev ABI change for LRO fields
2019-08-06 14:56 4% [dpdk-dev] [PATCH 1/2] doc: announce ethdev ABI change for LRO fields Matan Azrad
@ 2019-08-06 15:27 4% ` Andrew Rybchenko
2019-08-10 21:40 4% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Andrew Rybchenko @ 2019-08-06 15:27 UTC (permalink / raw)
To: Matan Azrad, dev
Cc: Thomas Monjalon, Ferruh Yigit, Konstantin Ananyev, Olivier Matz
On 8/6/19 5:56 PM, Matan Azrad wrote:
> It may be needed by the user to limit the LRO session packet size.
> In order to allow the above limitation, a new Rx configuration may be
> added for the maximum LRO session size.
>
> A new capability may be added too to expose the maximum LRO session size
> supported by the port.
>
> Signed-off-by: Matan Azrad <matan@mellanox.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 37b8592..c0cd9bc 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -59,6 +59,10 @@ Deprecation Notices
> Target release for removal of the legacy API will be defined once most
> PMDs have switched to rte_flow.
>
> +* ethdev: new 32-bit fields may be added for maximum LRO session size, in
> + struct ``rte_eth_dev_info`` for the port capability and in struct
> + ``rte_eth_rxmode`` for the port configuration.
> +
> * cryptodev: support for using IV with all sizes is added, J0 still can
> be used but only when IV length in following structs ``rte_crypto_auth_xform``,
> ``rte_crypto_aead_xform`` is set to zero. When IV length is greater or equal
>
Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
I don't know examples when the information is required, but can imagine.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [RFC 0/3] ethdev: add ptype as Rx offload
@ 2019-08-07 2:04 3% Jerin Jacob Kollanukkaran
2019-08-07 8:32 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Jerin Jacob Kollanukkaran @ 2019-08-07 2:04 UTC (permalink / raw)
To: Stephen Hemminger, Andrew Rybchenko
Cc: Pavan Nikhilesh Bhagavatula, Hemant Agrawal, dev
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Wednesday, August 7, 2019 4:45 AM
> To: Andrew Rybchenko <arybchenko@solarflare.com>
> Cc: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Hemant
> Agrawal <hemant.agrawal@nxp.com>; Jerin Jacob Kollanukkaran
> <jerinj@marvell.com>; dev@dpdk.org
> Subject: [EXT] Re: [dpdk-dev] [RFC 0/3] ethdev: add ptype as Rx offload
>
> On Tue, 6 Aug 2019 12:06:35 +0300
> Andrew Rybchenko <arybchenko@solarflare.com> wrote:
>
> > On 8/6/19 11:47 AM, Pavan Nikhilesh Bhagavatula wrote:
> > >
> > >> -----Original Message-----
> > >> From: Hemant Agrawal <hemant.agrawal@nxp.com>
> > >> Sent: Tuesday, August 6, 2019 1:49 PM
> > >> To: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Jerin
> > >> Jacob Kollanukkaran <jerinj@marvell.com>
> > >> Cc: dev@dpdk.org
> > >> Subject: RE: [dpdk-dev] [RFC 0/3] ethdev: add ptype as Rx offload
> > >>> Add PTYPE to DEV_RX_OFFLOAD_* flags.
> > >>>
> > >>> Currently, most of the NICs already support PTYPE parsing and
> > >>> update
> > >> the
> > >>> mbuf->packet_type through an internal lookup table, but there is
> > >>> mbuf->no
> > >> way to
> > >>> disable the lookup if the application is not intrested in ptypes
> > >> returned by
> > >>> `rte_eth_dev_get_supported_ptypes`.
> > >>>
> > >> [Hemant] it will also mean introducing another check in datapath,
> > >> if the application has asked for PTYPE offload - copy the results
> > >> to mbuf-
> > >>> packet_type otherwise don't do it.
> > > I think that having the check would give better performance than
> > > loading ptype table to L1 doing a lookup and copying it to mbuf when the
> application doesn't need it.
> >
> > Anyway, if PMD decides that it is better to always provide packet type
> > information - there is no harm. Basically if the offload is not
> > requested it makes packet_type undefined in mbuf.
> >
> > >> Your second patch is incomplete in the sense that it only adds the
> > >> capability. But it does not disable the lookups?
> > > It is upto the maintainer of the PMD to disable the lookup in data
> > > path. If there is a scope of optimization then they could do it. There is no
> harm in exposing PTYPE even RX_OFFLOAD_PTYPE is not enabled.
> > > I was hesitant to touch data path as it would be impossible to verify
> performance effect on all NICs.
> >
> > I think it is the right way to approach it especially taking
> > transition into account.
> >
>
> With hardline API policy, this has to fail on compile for old applications.
Not specific to this API change. That's is the propriety any new symbol addition
to the code base.
Planning to make this API change available from v19.11 LTS.
> You can't magically assume that applications using ptype will set new feature.
When OFFLOAD flags got introduced, we decided to disable all offloads by default.
So, need to add positive logic here to enable offload instead of enable something by
Default and disable if required to get have synergy with other offloads.
Will update the release note as usual to document the change.
Since there is NO ABI change, IMO, we don't need deprecation notice.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [RFC 0/3] ethdev: add ptype as Rx offload
2019-08-07 2:04 3% [dpdk-dev] [RFC 0/3] ethdev: add ptype as Rx offload Jerin Jacob Kollanukkaran
@ 2019-08-07 8:32 0% ` Andrew Rybchenko
2019-08-07 15:22 0% ` Stephen Hemminger
0 siblings, 1 reply; 200+ results
From: Andrew Rybchenko @ 2019-08-07 8:32 UTC (permalink / raw)
To: Jerin Jacob Kollanukkaran, Stephen Hemminger
Cc: Pavan Nikhilesh Bhagavatula, Hemant Agrawal, dev
On 8/7/19 5:04 AM, Jerin Jacob Kollanukkaran wrote:
>> -----Original Message-----
>> From: Stephen Hemminger <stephen@networkplumber.org>
>> Sent: Wednesday, August 7, 2019 4:45 AM
>> To: Andrew Rybchenko <arybchenko@solarflare.com>
>> Cc: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Hemant
>> Agrawal <hemant.agrawal@nxp.com>; Jerin Jacob Kollanukkaran
>> <jerinj@marvell.com>; dev@dpdk.org
>> Subject: [EXT] Re: [dpdk-dev] [RFC 0/3] ethdev: add ptype as Rx offload
>>
>> On Tue, 6 Aug 2019 12:06:35 +0300
>> Andrew Rybchenko <arybchenko@solarflare.com> wrote:
>>
>>> On 8/6/19 11:47 AM, Pavan Nikhilesh Bhagavatula wrote:
>>>>> -----Original Message-----
>>>>> From: Hemant Agrawal <hemant.agrawal@nxp.com>
>>>>> Sent: Tuesday, August 6, 2019 1:49 PM
>>>>> To: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Jerin
>>>>> Jacob Kollanukkaran <jerinj@marvell.com>
>>>>> Cc: dev@dpdk.org
>>>>> Subject: RE: [dpdk-dev] [RFC 0/3] ethdev: add ptype as Rx offload
>>>>>> Add PTYPE to DEV_RX_OFFLOAD_* flags.
>>>>>>
>>>>>> Currently, most of the NICs already support PTYPE parsing and
>>>>>> update
>>>>> the
>>>>>> mbuf->packet_type through an internal lookup table, but there is
>>>>>> mbuf->no
>>>>> way to
>>>>>> disable the lookup if the application is not intrested in ptypes
>>>>> returned by
>>>>>> `rte_eth_dev_get_supported_ptypes`.
>>>>>>
>>>>> [Hemant] it will also mean introducing another check in datapath,
>>>>> if the application has asked for PTYPE offload - copy the results
>>>>> to mbuf-
>>>>>> packet_type otherwise don't do it.
>>>> I think that having the check would give better performance than
>>>> loading ptype table to L1 doing a lookup and copying it to mbuf when the
>> application doesn't need it.
>>> Anyway, if PMD decides that it is better to always provide packet type
>>> information - there is no harm. Basically if the offload is not
>>> requested it makes packet_type undefined in mbuf.
>>>
>>>>> Your second patch is incomplete in the sense that it only adds the
>>>>> capability. But it does not disable the lookups?
>>>> It is upto the maintainer of the PMD to disable the lookup in data
>>>> path. If there is a scope of optimization then they could do it. There is no
>> harm in exposing PTYPE even RX_OFFLOAD_PTYPE is not enabled.
>>>> I was hesitant to touch data path as it would be impossible to verify
>> performance effect on all NICs.
>>> I think it is the right way to approach it especially taking
>>> transition into account.
>>>
>> With hardline API policy, this has to fail on compile for old applications.
Stephen, could you explain a bit more why.
> Not specific to this API change. That's is the propriety any new symbol addition
> to the code base.
>
> Planning to make this API change available fromv19.11 LTS.
The only way to to require applications to enable PTYPE offload to get
ptypes in mbuf since 19.11 LTS is to have deprecation notice in 19.08.
>> You can't magically assume that applications using ptype will set new feature.
> When OFFLOAD flags got introduced, we decided to disable all offloads by default.
> So, need to add positive logic here to enable offload instead of enable something by
> Default and disable if required to get have synergy with other offloads.
>
> Will update the release note as usual to document the change.
> Since there is NO ABI change, IMO, we don't need deprecation notice.
Sorry, but it is a behaviour change. Before an application does not need
to enable ptype offload, but now it is required. It means that application
will be broken and, therefore, it requires deprecation notice.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC 0/3] ethdev: add ptype as Rx offload
2019-08-07 8:32 0% ` Andrew Rybchenko
@ 2019-08-07 15:22 0% ` Stephen Hemminger
2019-08-07 15:44 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2019-08-07 15:22 UTC (permalink / raw)
To: Andrew Rybchenko
Cc: Jerin Jacob Kollanukkaran, Pavan Nikhilesh Bhagavatula,
Hemant Agrawal, dev
On Wed, 7 Aug 2019 11:32:35 +0300
Andrew Rybchenko <arybchenko@solarflare.com> wrote:
> On 8/7/19 5:04 AM, Jerin Jacob Kollanukkaran wrote:
> >> -----Original Message-----
> >> From: Stephen Hemminger <stephen@networkplumber.org>
> >> Sent: Wednesday, August 7, 2019 4:45 AM
> >> To: Andrew Rybchenko <arybchenko@solarflare.com>
> >> Cc: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Hemant
> >> Agrawal <hemant.agrawal@nxp.com>; Jerin Jacob Kollanukkaran
> >> <jerinj@marvell.com>; dev@dpdk.org
> >> Subject: [EXT] Re: [dpdk-dev] [RFC 0/3] ethdev: add ptype as Rx offload
> >>
> >> On Tue, 6 Aug 2019 12:06:35 +0300
> >> Andrew Rybchenko <arybchenko@solarflare.com> wrote:
> >>
> >>> On 8/6/19 11:47 AM, Pavan Nikhilesh Bhagavatula wrote:
> >>>>> -----Original Message-----
> >>>>> From: Hemant Agrawal <hemant.agrawal@nxp.com>
> >>>>> Sent: Tuesday, August 6, 2019 1:49 PM
> >>>>> To: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Jerin
> >>>>> Jacob Kollanukkaran <jerinj@marvell.com>
> >>>>> Cc: dev@dpdk.org
> >>>>> Subject: RE: [dpdk-dev] [RFC 0/3] ethdev: add ptype as Rx offload
> >>>>>> Add PTYPE to DEV_RX_OFFLOAD_* flags.
> >>>>>>
> >>>>>> Currently, most of the NICs already support PTYPE parsing and
> >>>>>> update
> >>>>> the
> >>>>>> mbuf->packet_type through an internal lookup table, but there is
> >>>>>> mbuf->no
> >>>>> way to
> >>>>>> disable the lookup if the application is not intrested in ptypes
> >>>>> returned by
> >>>>>> `rte_eth_dev_get_supported_ptypes`.
> >>>>>>
> >>>>> [Hemant] it will also mean introducing another check in datapath,
> >>>>> if the application has asked for PTYPE offload - copy the results
> >>>>> to mbuf-
> >>>>>> packet_type otherwise don't do it.
> >>>> I think that having the check would give better performance than
> >>>> loading ptype table to L1 doing a lookup and copying it to mbuf when the
> >> application doesn't need it.
> >>> Anyway, if PMD decides that it is better to always provide packet type
> >>> information - there is no harm. Basically if the offload is not
> >>> requested it makes packet_type undefined in mbuf.
> >>>
> >>>>> Your second patch is incomplete in the sense that it only adds the
> >>>>> capability. But it does not disable the lookups?
> >>>> It is upto the maintainer of the PMD to disable the lookup in data
> >>>> path. If there is a scope of optimization then they could do it. There is no
> >> harm in exposing PTYPE even RX_OFFLOAD_PTYPE is not enabled.
> >>>> I was hesitant to touch data path as it would be impossible to verify
> >> performance effect on all NICs.
> >>> I think it is the right way to approach it especially taking
> >>> transition into account.
> >>>
> >> With hardline API policy, this has to fail on compile for old applications.
>
> Stephen, could you explain a bit more why.
Existing releases packets will be received with ptype for hardware that
supports it. We should not require users to change their application to
continue to get mbufs with ptype. If your change would break that, and
require application to change; then your change should break the API in
a hard way that causes compile rather than runtime failure.
The best solution would be to just keep old applications running and compiling
without breaking anything. That means ptype should still be received.
If (as an optimization) you want to allow application to turn of getting
ptype; then that would be a useful. Probably best done at the port level
as part of configuration.
>
> > Not specific to this API change. That's is the propriety any new symbol addition
> > to the code base.
> >
> > Planning to make this API change available fromv19.11 LTS.
>
> The only way to to require applications to enable PTYPE offload to get
> ptypes in mbuf since 19.11 LTS is to have deprecation notice in 19.08.
>
> >> You can't magically assume that applications using ptype will set new feature.
> > When OFFLOAD flags got introduced, we decided to disable all offloads by default.
> > So, need to add positive logic here to enable offload instead of enable something by
> > Default and disable if required to get have synergy with other offloads.
> >
> > Will update the release note as usual to document the change.
> > Since there is NO ABI change, IMO, we don't need deprecation notice.
>
> Sorry, but it is a behaviour change. Before an application does not need
> to enable ptype offload, but now it is required. It means that application
> will be broken and, therefore, it requires deprecation notice.
The DPDK development community has to make not breaking applications
a higher priority than adding marginal enhancements
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC 0/3] ethdev: add ptype as Rx offload
2019-08-07 15:22 0% ` Stephen Hemminger
@ 2019-08-07 15:44 0% ` Andrew Rybchenko
0 siblings, 0 replies; 200+ results
From: Andrew Rybchenko @ 2019-08-07 15:44 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Jerin Jacob Kollanukkaran, Pavan Nikhilesh Bhagavatula,
Hemant Agrawal, dev
On 8/7/19 6:22 PM, Stephen Hemminger wrote:
> On Wed, 7 Aug 2019 11:32:35 +0300
> Andrew Rybchenko <arybchenko@solarflare.com> wrote:
>
>> On 8/7/19 5:04 AM, Jerin Jacob Kollanukkaran wrote:
>>>> -----Original Message-----
>>>> From: Stephen Hemminger <stephen@networkplumber.org>
>>>> Sent: Wednesday, August 7, 2019 4:45 AM
>>>> To: Andrew Rybchenko <arybchenko@solarflare.com>
>>>> Cc: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Hemant
>>>> Agrawal <hemant.agrawal@nxp.com>; Jerin Jacob Kollanukkaran
>>>> <jerinj@marvell.com>; dev@dpdk.org
>>>> Subject: [EXT] Re: [dpdk-dev] [RFC 0/3] ethdev: add ptype as Rx offload
>>>>
>>>> On Tue, 6 Aug 2019 12:06:35 +0300
>>>> Andrew Rybchenko <arybchenko@solarflare.com> wrote:
>>>>
>>>>> On 8/6/19 11:47 AM, Pavan Nikhilesh Bhagavatula wrote:
>>>>>>> -----Original Message-----
>>>>>>> From: Hemant Agrawal <hemant.agrawal@nxp.com>
>>>>>>> Sent: Tuesday, August 6, 2019 1:49 PM
>>>>>>> To: Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>; Jerin
>>>>>>> Jacob Kollanukkaran <jerinj@marvell.com>
>>>>>>> Cc: dev@dpdk.org
>>>>>>> Subject: RE: [dpdk-dev] [RFC 0/3] ethdev: add ptype as Rx offload
>>>>>>>> Add PTYPE to DEV_RX_OFFLOAD_* flags.
>>>>>>>>
>>>>>>>> Currently, most of the NICs already support PTYPE parsing and
>>>>>>>> update
>>>>>>> the
>>>>>>>> mbuf->packet_type through an internal lookup table, but there is
>>>>>>>> mbuf->no
>>>>>>> way to
>>>>>>>> disable the lookup if the application is not intrested in ptypes
>>>>>>> returned by
>>>>>>>> `rte_eth_dev_get_supported_ptypes`.
>>>>>>>>
>>>>>>> [Hemant] it will also mean introducing another check in datapath,
>>>>>>> if the application has asked for PTYPE offload - copy the results
>>>>>>> to mbuf-
>>>>>>>> packet_type otherwise don't do it.
>>>>>> I think that having the check would give better performance than
>>>>>> loading ptype table to L1 doing a lookup and copying it to mbuf when the
>>>> application doesn't need it.
>>>>> Anyway, if PMD decides that it is better to always provide packet type
>>>>> information - there is no harm. Basically if the offload is not
>>>>> requested it makes packet_type undefined in mbuf.
>>>>>
>>>>>>> Your second patch is incomplete in the sense that it only adds the
>>>>>>> capability. But it does not disable the lookups?
>>>>>> It is upto the maintainer of the PMD to disable the lookup in data
>>>>>> path. If there is a scope of optimization then they could do it. There is no
>>>> harm in exposing PTYPE even RX_OFFLOAD_PTYPE is not enabled.
>>>>>> I was hesitant to touch data path as it would be impossible to verify
>>>> performance effect on all NICs.
>>>>> I think it is the right way to approach it especially taking
>>>>> transition into account.
>>>>>
>>>> With hardline API policy, this has to fail on compile for old applications.
>>
>> Stephen, could you explain a bit more why.
>
> Existing releases packets will be received with ptype for hardware that
> supports it. We should not require users to change their application to
> continue to get mbufs with ptype. If your change would break that, and
> require application to change; then your change should break the API in
> a hard way that causes compile rather than runtime failure.
Many thanks, I got it.
> The best solution would be to just keep old applications running and compiling
> without breaking anything. That means ptype should still be received.
>
> If (as an optimization) you want to allow application to turn of getting
> ptype; then that would be a useful. Probably best done at the port level
> as part of configuration.
I see, but it contradicts to the existing practice that offloads should
be disabled by default and a way to enable should be provided.
May be techboard should discuss it and make a decision (covering RSS
hash information and Rx mark mentioned in my review notes).
>>> Not specific to this API change. That's is the propriety any new symbol addition
>>> to the code base.
>>>
>>> Planning to make this API change available fromv19.11 LTS.
>>
>> The only way to to require applications to enable PTYPE offload to get
>> ptypes in mbuf since 19.11 LTS is to have deprecation notice in 19.08.
>>
>>>> You can't magically assume that applications using ptype will set new feature.
>>> When OFFLOAD flags got introduced, we decided to disable all offloads by default.
>>> So, need to add positive logic here to enable offload instead of enable something by
>>> Default and disable if required to get have synergy with other offloads.
>>>
>>> Will update the release note as usual to document the change.
>>> Since there is NO ABI change, IMO, we don't need deprecation notice.
>>
>> Sorry, but it is a behaviour change. Before an application does not need
>> to enable ptype offload, but now it is required. It means that application
>> will be broken and, therefore, it requires deprecation notice.
>
> The DPDK development community has to make not breaking applications
> a higher priority than adding marginal enhancements
Fair, but where is marginal enhancements boundary?
^ permalink raw reply [relevance 0%]
* [dpdk-dev] 19.11 Intel Roadmap
@ 2019-08-08 8:12 4% O'Driscoll, Tim
0 siblings, 0 replies; 200+ results
From: O'Driscoll, Tim @ 2019-08-08 8:12 UTC (permalink / raw)
To: dev
These are the features that we plan to submit for the 19.11 release:
Intel(r) Ethernet 810 Series Network Adapter Enhancements: Support for loading of device-specific Dynamic Device Personalization (DDP) profiles to support new protocols, rte_flow/flow director/switch filter updates to support DDP profiles, AVX2 versions of the ICE and IAVF PMDs to improve performance, multi-process support, RSS support via rte_flow, support for high/low priority flows via rte_flow, flexible descriptor support per Rx queue.
IPsec Enhancements: The rte_security API will be updated to support inline crypto statistics. A security association database will be added to the IPsec library. A new rte_security type (RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO) will be added to improve performance for IPsec with software crypto. The IPsec Security Gateway sample app will be updated to demonstrate the IPSec library's ability to support multiple IPsec sessions for the same SA (inline-crypto session plus lookaside-none).
Compression Enhancements: Intel(r) QuickAssist Technology support for stateful decompression, enhancements to the performance test tool including the ability to use external mbufs, and removal of the Experimental label from the compressdev API.
Crypto Enhancements: Increased Intel(r) QuickAssist Technology support for asymmetric (RSA) and symmetric (single-pass GCM) crypto operations, modifications to the cryptodev API to support sessionless asymmetric crypto.
Hierarchical QoS Scheduler Enhancements: The pipe (subscriber) configuration will be made more flexible by moving configuration data from the port to the sub-port level. Enhancements will also be made to provide better support for over-subscription, allowing unused bandwidth for a pipe to be redistributed to other pipes in the same sub-port.
ABI Stability: Agree and document new ABI stability policy. Implement code changes (hiding of internal structures etc.) to make ABI easier to maintain.
Virtio packed ring (introduced in Virtio 1.1 spec) performance optimisations.
Support graceful shutdown for the Intel(r) FPGA Programmable Acceleration Card N3000. The server will be able to gracefully shutdown and reload the card after certain errors (e.g. FPGA Die Temperature higher than Temperature Threshold or FPGA AUX Voltage lower than Voltage Threshold).
Extend Rawdev NTB PMD: The rawdev PMD for Non-Transparent Bridging will be extended to add a FIFO ring for Rx/Tx.
A sample application will be added for the Intel(r) QuickData Technology PMD (drivers/raw/ioat).
Intel PMDs will be updated to support RTE_ETH_DEV_CLOSE_REMOVE.
^ permalink raw reply [relevance 4%]
* [dpdk-dev] [PATCH v2] doc: announce lcore_config symbol removal
2019-07-31 11:06 5% [dpdk-dev] [PATCH] doc: announce lcore_config symbol removal David Marchand
2019-07-31 13:48 0% ` Stephen Hemminger
@ 2019-08-08 9:31 5% ` David Marchand
1 sibling, 0 replies; 200+ results
From: David Marchand @ 2019-08-08 9:31 UTC (permalink / raw)
To: dev; +Cc: thomas, stephen, bruce.richardson, jerinj, arybchenko
New accessors have been introduced to provide the hidden information.
This symbol can now be kept internal.
Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
---
Changelog since v1:
- added acks,
- fixed little typo,
---
doc/guides/rel_notes/deprecation.rst | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 70fef52..ee15ab6 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -23,6 +23,10 @@ Deprecation Notices
* eal: The function ``rte_eal_remote_launch`` will return new error codes
after read or write error on the pipe, instead of calling ``rte_panic``.
+* eal: The ``lcore_config`` struct and global symbol will be made private to
+ remove it from the externally visible ABI and allow it to be updated in the
+ future.
+
* 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
--
1.8.3.1
^ permalink raw reply [relevance 5%]
* Re: [dpdk-dev] [PATCH] doc: announce ABI change for RSS hash funtion
2019-08-06 14:45 4% ` Ananyev, Konstantin
@ 2019-08-10 20:39 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-08-10 20:39 UTC (permalink / raw)
To: Su, Simei
Cc: dev, Ananyev, Konstantin, Zhang, Qi Z, Wu, Jingjing, Xing,
Beilei, Yang, Qiming, orika, adrien.mazarguil, arybchenko, Yigit,
Ferruh
06/08/2019 16:45, Ananyev, Konstantin:
> From: Thomas Monjalon
> > 04/07/2019 06:43, simei:
> > > From: Simei Su <simei.su@intel.com>
> > >
> > > Add new field SYMMETRIC_TOEPLITZ in rte_eth_hash_function. This
> > > can support symmetric hash function by rte_flow RSS action.
> > >
> > > Signed-off-by: Simei Su <simei.su@intel.com>
> > > ---
> > > +* ethdev: New member in ``rte_eth_hash_funtion`` to support symmetric hash funtion.
> >
> > That's unfortunate there is a typo in the name of the enum you want to change.
> >
> > Do you have any reference to the algo you want to support? A paper maybe?
>
> If I am not mistaken that's just an intent to enable symmetric RSS hash-function via standard RSS rte_flow API -
> feature already available with i40e and newest Intel HW.
> (AFAIK on i40e right now it could be configured via RTE_ETH_HASH_FILTER_SYM_HASH_ENA_PER_PORT).
> If so, then I think the author may need to mention what PMDs will support that feature in 19.11.
Without any more comment, this patch cannot be accepted in 19.08.
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [patch v5] doc: announce API change in ethdev offload flags
@ 2019-08-10 21:10 3% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-08-10 21:10 UTC (permalink / raw)
To: pbhagavatula
Cc: dev, Ananyev, Konstantin, jerinj, stephen, arybchenko,
hemant.agrawal, Yigit, Ferruh, Richardson, Bruce, Neil Horman,
Mcnamara, John, Kovacevic, Marko
> > Add new offload flags ``DEV_RX_OFFLOAD_RSS_HASH`` and
> > ``DEV_RX_OFFLOAD_FLOW_MARK``.
> > Add new function ``rte_eth_dev_set_supported_ptypes`` to allow application
> > to set specific ptypes to be updated in ``rte_mbuf::packet_type``
> >
> > Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
> > Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
> > Acked-by: Jerin Jacob <jerinj@marvell.com>
> > Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com>
> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
We'll probably have to discuss more the details of these new APIs,
but the overall idea looks good.
I am not sure there is any API or ABI breakage here,
so the announce may not be required.
Anyway applied, thanks.
^ permalink raw reply [relevance 3%]
* Re: [dpdk-dev] [PATCH 1/2] doc: announce ethdev ABI change for LRO fields
2019-08-06 15:27 4% ` Andrew Rybchenko
@ 2019-08-10 21:40 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2019-08-10 21:40 UTC (permalink / raw)
To: Matan Azrad
Cc: dev, Andrew Rybchenko, Ferruh Yigit, Konstantin Ananyev, Olivier Matz
06/08/2019 17:27, Andrew Rybchenko:
> On 8/6/19 5:56 PM, Matan Azrad wrote:
> > It may be needed by the user to limit the LRO session packet size.
> > In order to allow the above limitation, a new Rx configuration may be
> > added for the maximum LRO session size.
> >
> > A new capability may be added too to expose the maximum LRO session size
> > supported by the port.
> >
> > Signed-off-by: Matan Azrad <matan@mellanox.com>
> > ---
> > +* ethdev: new 32-bit fields may be added for maximum LRO session size, in
> > + struct ``rte_eth_dev_info`` for the port capability and in struct
> > + ``rte_eth_rxmode`` for the port configuration.
>
> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
>
> I don't know examples when the information is required, but can imagine.
Acked-by: Thomas Monjalon <thomas@monjalon.net>
We have only 2 acks but as they are simple new fields,
better to announce their addition in advance and allow for more
discussion during 19.11 release cycle.
Applied (only patch 1 of 2)
^ permalink raw reply [relevance 4%]
* Re: [dpdk-dev] [PATCH] eal: change max hugepage sizes to 4
@ 2019-08-12 9:43 3% ` Burakov, Anatoly
0 siblings, 0 replies; 200+ results
From: Burakov, Anatoly @ 2019-08-12 9:43 UTC (permalink / raw)
To: Thomas Monjalon, Hemant Agrawal, Gagandeep Singh
Cc: dev, David Marchand, Olivier Matz, Andrew Rybchenko, Nipun Gupta,
honnappa.nagarahalli, Steve Capper, jerinj, bruce.richardson,
gavin.hu, konstantin.ananyev, drc
On 08-Aug-19 8:31 AM, Thomas Monjalon wrote:
> 07/08/2019 15:28, Hemant Agrawal:
>> HI Thomas,
>>
>>>>> DPDK currently is supporting maximum 3 hugepage, sizes whereas
>>>>> system can support more than this e.g.
>>>>> 64K, 2M, 32M and 1G.
>>>>
>>>> You can mention ARM platform here, and that this issue starts with
>>>> kernel 5.2 (and I would try to mention this in the title as well).
>>>> This is better than an annotation that will be lost.
>>>>
>>>>
>>>>> Having these four hugepage sizes available to use by DPDK, which is
>>>>> valid in case of '--in-memory' EAL option or using 4 separate mount
>>>>> points for each hugepage size;
>>>>> hugepage_info_init() API reports an error.
>>>>
>>>> Can you describe what is the impact from a user point of view rather
>>>> than mentioning this internal function?
>>>
>>> Yes please, we need to understand how much it is critical.
>>> Should we Cc stable@dpdk.org for backport?
>>> Should it be merged at the last minute in 19.08?
>>
>> VPP usages in-memory option. So, VPP on ARM with kernel 5.2 wont' work without this patch.
>
> Do you want to send a v2 with a better explanation?
>
> I would suggest to restrict the change to Arm only with an ifdef,
> in order to limit the risk for this release.
> We can think about a dynamic hugepage scan in the next release.
>
I don't see how this is necessary. The 3 is an arbitrary number here,
and the ABI isn't broken as this is an internal structure. We could
increase it to 16 for all i care, and it wouldn't make any difference to
the rest of the code - we never populate more than we can find anyway.
--
Thanks,
Anatoly
^ permalink raw reply [relevance 3%]
Results 6001-6200 of ~18000 next (newer) | prev (older) | reverse | sort options + mbox downloads above
-- links below jump to the message on this page --
2018-12-12 6:24 [dpdk-dev] [PATCH v1 0/2] add rte_ring_reset and use it to flush a ring Gavin Hu
2019-03-15 3:31 ` [dpdk-dev] [PATCH v7 1/2] ring: add reset API to flush the ring when not in use Gavin Hu
2019-03-29 14:17 ` Olivier Matz
2019-07-04 14:42 0% ` Thomas Monjalon
2019-07-12 9:32 0% ` Gavin Hu (Arm Technology China)
2019-07-12 9:53 0% ` Olivier Matz
2019-07-12 11:06 0% ` Gavin Hu (Arm Technology China)
2019-07-12 11:48 3% ` Olivier Matz
2019-07-12 15:07 0% ` Gavin Hu (Arm Technology China)
2019-07-12 15:40 0% ` Honnappa Nagarahalli
2019-07-12 16:01 0% ` Gavin Hu (Arm Technology China)
2019-07-12 9:26 3% ` [dpdk-dev] [PATCH v8 0/2] new ring reset api and use it by hash Gavin Hu
2019-07-12 15:54 3% ` [dpdk-dev] [PATCH v9 " Gavin Hu
2019-07-16 19:23 3% ` [dpdk-dev] [PATCH v10 " Gavin Hu
2019-03-20 13:32 [dpdk-dev] [PATCH v3] cryptodev: make xform key pointer constant Fan Zhang
2019-06-24 13:35 ` [dpdk-dev] [PATCH v4] " Fan Zhang
2019-06-25 12:46 ` Akhil Goyal
2019-07-05 12:30 0% ` Thomas Monjalon
2019-04-05 20:30 [dpdk-dev] [PATCH] eal: resort symbols in EXPERIMENTAL section Stephen Hemminger
2019-06-14 7:39 ` Thomas Monjalon
2019-06-14 7:44 ` David Marchand
2019-06-14 15:32 ` Ferruh Yigit
2019-06-20 17:23 ` David Marchand
2019-07-26 13:54 0% ` David Marchand
2019-04-16 1:59 [dpdk-dev] [PATCH] fbarray: get fbarrays from containerized secondary ogawa.yasufumi
2019-04-16 3:43 ` [dpdk-dev] [PATCH v2 0/1] Get " ogawa.yasufumi
2019-04-16 3:43 ` [dpdk-dev] [PATCH v2 1/1] fbarray: get " ogawa.yasufumi
2019-07-05 8:53 ` Burakov, Anatoly
2019-07-09 10:22 ` Yasufumi Ogawa
2019-07-09 10:24 ` Burakov, Anatoly
2019-07-09 10:26 4% ` Burakov, Anatoly
2019-07-11 9:37 0% ` Yasufumi Ogawa
2019-07-11 9:43 3% ` Burakov, Anatoly
2019-04-17 7:40 [dpdk-dev] [PATCH v2] ethdev: fix QinQ strip offload support viveksharma
2019-04-19 5:59 ` [dpdk-dev] [PATCH v3] ethdev: support QinQ strip dynamic configuration viveksharma
2019-06-27 11:08 3% ` Ferruh Yigit
2019-07-01 10:07 0% ` Andrew Rybchenko
2019-07-01 13:05 0% ` Ferruh Yigit
2019-05-03 13:35 [dpdk-dev] [PATCH 19.08 0/6] improve building examples Bruce Richardson
2019-05-17 11:47 ` [dpdk-dev] [PATCH v2 0/5] " Bruce Richardson
2019-05-17 11:47 ` [dpdk-dev] [PATCH v2 4/5] examples/vdpa: support building from pkg-config info Bruce Richardson
2019-07-02 7:57 3% ` Thomas Monjalon
2019-07-02 14:35 0% ` Bruce Richardson
2019-05-16 15:54 [dpdk-dev] [PATCH] ether: mark ethernet addresses as being 2-byte aligned Bruce Richardson
2019-07-01 13:11 3% ` Olivier Matz
2019-07-01 13:38 ` Bruce Richardson
2019-07-01 14:14 5% ` Olivier Matz
2019-07-01 14:28 0% ` Bruce Richardson
2019-05-16 18:04 [dpdk-dev] [PATCH v2 0/7] ether: improvements and optimizations Stephen Hemminger
2019-07-02 22:12 ` [dpdk-dev] [PATCH v7 00/12] " Stephen Hemminger
2019-07-02 22:12 ` [dpdk-dev] [PATCH v7 05/12] net/ether: mark ethernet addresses as being 2-byte aligned Stephen Hemminger
2019-07-05 14:34 3% ` Olivier Matz
2019-07-05 15:45 0% ` Richardson, Bruce
2019-05-20 10:59 [dpdk-dev] [PATCH v3 1/2] examples/ip_fragmentation: Enabling IP checksum offload in mbuf Sunil Kumar Kori
2019-07-08 4:32 9% ` [dpdk-dev] [PATCH v4 1/3] lib/librte_ip_frag: remove IP checkum offload flag jerinj
2019-07-08 9:07 3% ` Thomas Monjalon
2019-05-23 7:43 [dpdk-dev] [PATCH] devtools: better freebsd support Olivier Matz
2019-07-05 13:58 6% ` [dpdk-dev] [PATCH v2] " Olivier Matz
2019-07-09 11:05 0% ` Musatescu, Flavia
2019-07-11 14:25 6% ` [dpdk-dev] [PATCH v3] " Olivier Matz
2019-07-29 8:31 0% ` David Marchand
2019-07-29 8:36 0% ` David Marchand
2019-05-25 18:43 [dpdk-dev] [RFC PATCH 0/2] introduce __rte_internal tag Neil Horman
2019-06-13 14:23 ` [dpdk-dev] [PATCH v2 0/10] dpdk: " Neil Horman
2019-08-06 10:03 0% ` Thomas Monjalon
2019-08-06 12:21 0% ` Neil Horman
2019-05-28 12:05 [dpdk-dev] [PATCH 01/27] sched: update macros for flexible config Lukasz Krakowiak
2019-06-25 15:31 ` [dpdk-dev] [PATCH v2 00/28] sched: feature enhancements Jasvinder Singh
2019-06-25 15:32 ` [dpdk-dev] [PATCH v2 28/28] sched: add release note Jasvinder Singh
2019-06-26 21:31 ` Thomas Monjalon
2019-06-27 10:50 0% ` Singh, Jasvinder
2019-05-29 15:41 [dpdk-dev] [PATCH 0/4] Enhance CPU flag support Bruce Richardson
2019-05-29 15:41 ` [dpdk-dev] [PATCH 3/4] eal: allow checking CPU flags by name Bruce Richardson
2019-06-27 13:22 ` David Marchand
2019-06-28 12:40 ` Bruce Richardson
2019-06-28 13:34 3% ` David Marchand
2019-06-03 21:32 [dpdk-dev] [RFC 1/3] ethdev: extend flow metadata Yongseok Koh
2019-07-04 23:21 ` [dpdk-dev] [PATCH] " Yongseok Koh
2019-07-10 9:31 3% ` Olivier Matz
2019-07-10 9:55 4% ` Bruce Richardson
2019-07-10 10:07 3% ` Olivier Matz
2019-07-10 12:01 4% ` Bruce Richardson
2019-07-10 12:26 3% ` Thomas Monjalon
2019-07-10 16:37 3% ` Yongseok Koh
2019-07-11 7:44 0% ` Adrien Mazarguil
2019-07-14 11:46 0% ` Andrew Rybchenko
2019-07-29 15:06 0% ` Adrien Mazarguil
2019-06-06 18:33 [dpdk-dev] [PATCH v1 1/2] lib/ring: add enqueue-dequeue callabck Vipin Varghese
2019-06-07 6:03 ` Honnappa Nagarahalli
2019-06-10 5:12 ` Varghese, Vipin
2019-06-11 4:17 ` Honnappa Nagarahalli
2019-07-04 5:04 0% ` Varghese, Vipin
2019-06-07 10:05 [dpdk-dev] [PATCH v2 00/10] cryptodev: support encrypted-digest use-cases Damian Nowak
2019-07-03 11:15 ` [dpdk-dev] [PATCH v3 0/8] " Damian Nowak
2019-07-03 11:15 4% ` [dpdk-dev] [PATCH v3 2/8] cryptodev: add digest encrypted feature flag Damian Nowak
2019-06-19 17:08 [dpdk-dev] [PATCH 0/2] rawdev autotest fixes Bruce Richardson
2019-06-21 15:56 ` [dpdk-dev] [PATCH v2 0/4] fixes and improvements for rawdev Bruce Richardson
2019-06-21 15:56 ` [dpdk-dev] [PATCH v2 4/4] rawdev: pass device id as parameter to selftest Bruce Richardson
2019-07-04 9:33 0% ` Shreyansh Jain
2019-06-21 16:59 [dpdk-dev] [PATCH v3 01/10] baseband/turbo_sw: baseband/turbo_sw: dependency patch Nicolas Chautru
2019-06-24 2:52 ` [dpdk-dev] [PATCH v4 00/10] bbdev: adding support in BBDEV for 5GNR FEC Nicolas Chautru
2019-06-24 2:52 ` [dpdk-dev] [PATCH v4 10/10] doc: announce bbdev changes Nicolas Chautru
2019-06-30 23:04 0% ` Mokhtar, Amr
2019-07-01 11:14 4% ` Akhil Goyal
2019-07-01 18:14 3% ` Chautru, Nicolas
2019-07-01 19:17 3% ` Thomas Monjalon
2019-07-01 20:27 4% ` Chautru, Nicolas
2019-07-01 20:38 3% ` Bruce Richardson
2019-06-23 2:41 [dpdk-dev] [PATCH v1 1/3] eal/arm64: add 128-bit atomic compare exchange Phil Yang
2019-06-28 8:11 ` [dpdk-dev] [PATCH v3 " Phil Yang
2019-07-19 6:24 4% ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
2019-07-19 11:01 0% ` Phil Yang (Arm Technology China)
2019-07-19 12:35 0% ` Jerin Jacob Kollanukkaran
2019-07-19 13:56 0% ` Phil Yang (Arm Technology China)
2019-07-22 8:44 2% ` [dpdk-dev] [PATCH v4 " Phil Yang
2019-07-22 13:06 2% ` [dpdk-dev] [PATCH v5 " Phil Yang
2019-07-22 16:22 2% ` [dpdk-dev] [PATCH v6 " Phil Yang
2019-07-23 5:57 2% ` [dpdk-dev] [PATCH v7 " Phil Yang
2019-07-23 7:05 2% ` [dpdk-dev] [PATCH v8 " jerinj
2019-06-24 2:52 [dpdk-dev] [PATCH v4 01/10] baseband/turbo_sw: baseband/turbo_sw: dependency patch Nicolas Chautru
2019-07-01 18:06 ` [dpdk-dev] [PATCH v5 0/7] bbdev: adding support in BBDEV for 5GNR FEC Nicolas Chautru
2019-07-01 18:06 3% ` [dpdk-dev] [PATCH v5 2/7] bbdev: extension of BBDEV API for 5G FEC Nicolas Chautru
2019-07-01 18:06 2% ` [dpdk-dev] [PATCH v5 4/7] baseband/turbo_sw: extension of turbosw PMD for 5G Nicolas Chautru
2019-07-03 15:24 ` [dpdk-dev] [PATCH v6 0/7] bbdev: adding support in BBDEV for 5GNR FEC Nicolas Chautru
2019-07-03 15:24 3% ` [dpdk-dev] [PATCH v6 2/7] bbdev: extension of BBDEV API for 5G FEC Nicolas Chautru
2019-07-03 15:24 2% ` [dpdk-dev] [PATCH v6 4/7] baseband/turbo_sw: extension of turbosw PMD for 5G Nicolas Chautru
2019-06-24 15:40 [dpdk-dev] [PATCH 0/4] ethdev: add GRE key field to flow API Xiaoyu Min
2019-07-02 9:45 ` [dpdk-dev] [PATCH v4 0/4] match on GRE's key Xiaoyu Min
2019-07-02 9:45 ` [dpdk-dev] [PATCH v4 1/4] ethdev: add GRE key field to flow API Xiaoyu Min
2019-07-03 15:25 4% ` Adrien Mazarguil
2019-07-04 2:43 0% ` Jack Min
2019-06-25 10:33 [dpdk-dev] [PATCH 00/39] adding eventmode helper library Jerin Jacob Kollanukkaran
2019-06-27 5:28 0% ` Anoob Joseph
2019-06-28 3:37 0% ` Jerin Jacob Kollanukkaran
2019-06-28 8:02 0% ` Mattias Rönnblom
2019-06-28 8:40 0% ` Thomas Monjalon
2019-06-28 9:07 0% ` Mattias Rönnblom
2019-06-28 11:34 0% ` [dpdk-dev] [EXT] " Anoob Joseph
2019-07-02 14:17 0% ` Anoob Joseph
2019-07-02 14:26 0% ` Jerin Jacob Kollanukkaran
2019-06-25 16:11 [dpdk-dev] [PATCH 0/2] Fix timer resource leak Anatoly Burakov
2019-07-05 13:20 4% ` [dpdk-dev] [PATCH v2 0/1] " Anatoly Burakov
2019-07-05 17:22 4% ` [dpdk-dev] [PATCH v3 " Anatoly Burakov
2019-06-26 16:38 [dpdk-dev] [PATCH] [v1]vhost: support inflight share memory protocol feature JinYu
2019-07-05 8:47 3% ` Maxime Coquelin
2019-07-08 7:23 0% ` Yu, Jin
2019-06-26 22:32 4% [dpdk-dev] [PATCH] malloc: deprecate unused set limit Stephen Hemminger
2019-07-02 4:52 0% [dpdk-dev] [PATCH v3] eventdev: change Rx adapter callback and stats structure Jerin Jacob Kollanukkaran
2019-07-03 5:45 [dpdk-dev] [RFC PATCH] bus/pci: avoid depending on private value in kernel source Tiwei Bie
2019-07-03 7:02 ` David Marchand
2019-07-03 7:33 ` Tiwei Bie
2019-07-03 7:36 ` David Marchand
2019-07-03 7:56 ` Tiwei Bie
2019-07-03 8:01 ` David Marchand
2019-07-03 8:15 ` Tiwei Bie
2019-07-03 8:26 3% ` David Marchand
2019-07-03 8:59 0% ` Tiwei Bie
2019-07-03 9:10 0% ` David Marchand
2019-07-03 9:25 0% ` Tiwei Bie
2019-07-04 4:43 4% [dpdk-dev] [PATCH] doc: announce ABI change for RSS hash funtion simei
2019-08-06 11:34 4% ` Thomas Monjalon
2019-08-06 14:45 4% ` Ananyev, Konstantin
2019-08-10 20:39 4% ` Thomas Monjalon
2019-07-04 4:46 [dpdk-dev] [RFC] ethdev: support symmetric hash function simei
2019-07-04 9:06 3% ` Adrien Mazarguil
2019-07-04 12:48 3% ` Zhang, Qi Z
2019-07-04 13:19 3% ` Adrien Mazarguil
2019-07-04 4:46 4% [dpdk-dev] [PATCH] doc: announce ABI change for rte flow RSS action simei
2019-08-06 11:31 4% ` Thomas Monjalon
2019-08-06 11:38 4% ` Zhang, Qi Z
2019-08-06 11:40 4% ` Zhang, Qi Z
2019-07-04 4:47 [dpdk-dev] [RFC] ethdev: support input set change by " simei
2019-07-04 9:07 3% ` Adrien Mazarguil
2019-07-04 13:55 0% ` Zhang, Qi Z
2019-07-04 14:08 3% ` Adrien Mazarguil
2019-07-09 5:41 3% ` Zhang, Qi Z
2019-07-09 8:19 0% ` Jerin Jacob Kollanukkaran
2019-07-04 6:56 [dpdk-dev] [PATCH v3] net/i40e: i40e get link status update from ipn3ke Andy Pei
2019-07-08 3:03 ` [dpdk-dev] [PATCH v4] " Andy Pei
2019-07-08 7:27 3% ` Zhang, Qi Z
2019-07-04 12:26 11% [dpdk-dev] [PATCH] Changes to ABI Policy introducing major ABI versions Ray Kinsella
2019-07-04 12:26 31% ` [dpdk-dev] [PATCH] doc: " Ray Kinsella
2019-07-30 10:34 10% ` Mcnamara, John
2019-07-30 10:35 5% ` Ray Kinsella
2019-07-05 9:33 [dpdk-dev] [RFC PATCH 0/2] standardize rawdev names Bruce Richardson
2019-07-30 13:39 ` [dpdk-dev] [PATCH v2 " Thomas Monjalon
2019-07-30 13:39 7% ` [dpdk-dev] [PATCH v2 2/2] drivers/raw: standardize naming Thomas Monjalon
2019-07-31 7:29 0% ` Xu, Rosen
2019-07-05 11:15 [dpdk-dev] [PATCH v7 1/6] app/test-compress-perf: add weak functions for multi-cores test Fiona Trahe
2019-07-08 18:16 ` [dpdk-dev] [PATCH v8 0/7] add multiple cores feature to test-compress-perf Artur Trybula
2019-07-08 18:16 3% ` [dpdk-dev] [PATCH v8 4/7] app/test-compress-perf: add benchmark test case Artur Trybula
2019-07-05 17:26 [dpdk-dev] [PATCH v5 0/9] Make shared memory config non-public Anatoly Burakov
2019-07-05 13:10 ` [dpdk-dev] [PATCH v4 0/8] " Anatoly Burakov
2019-06-27 11:38 ` [dpdk-dev] [PATCH v3 00/14] " Anatoly Burakov
2019-06-25 16:05 ` [dpdk-dev] [PATCH v2 " Anatoly Burakov
2019-06-27 11:39 8% ` [dpdk-dev] [PATCH v3 09/14] eal: hide shared memory config Anatoly Burakov
2019-06-27 11:39 3% ` [dpdk-dev] [PATCH v3 14/14] eal: prevent different primary/secondary process versions Anatoly Burakov
2019-07-03 9:38 ` [dpdk-dev] [PATCH v3 00/14] Make shared memory config non-public David Marchand
2019-07-04 8:09 3% ` David Marchand
2019-07-04 19:52 0% ` Thomas Monjalon
2019-07-05 13:10 7% ` [dpdk-dev] [PATCH v4 4/8] eal: hide shared memory config Anatoly Burakov
2019-07-05 17:26 7% ` [dpdk-dev] [PATCH v5 4/9] " Anatoly Burakov
2019-07-05 17:26 3% ` [dpdk-dev] [PATCH v5 9/9] eal: prevent different primary/secondary process versions Anatoly Burakov
2019-07-09 11:09 [dpdk-dev] [PATCH] librte_flow_classify: fix out-of-bounds access Bernard Iremonger
2019-07-10 21:48 ` Thomas Monjalon
2019-07-29 13:09 ` David Marchand
2019-07-30 14:42 ` Aaron Conole
2019-07-30 14:48 ` [dpdk-dev] [dpdk-stable] " Ferruh Yigit
2019-07-30 15:43 2% ` Aaron Conole
2019-07-30 16:55 0% ` Ferruh Yigit
2019-07-30 17:30 0% ` Aaron Conole
2019-07-09 14:58 5% [dpdk-dev] [PATCH] doc: deprecation notice for change of ether struct alignment Bruce Richardson
2019-07-09 14:59 0% ` Stephen Hemminger
2019-07-09 15:02 0% ` Bruce Richardson
2019-07-10 9:29 4% [dpdk-dev] [RFC] mbuf: support dynamic fields and flags Olivier Matz
2019-07-10 17:14 0% ` Wang, Haiyue
2019-07-11 7:26 0% ` Olivier Matz
2019-07-11 8:04 0% ` Wang, Haiyue
2019-07-11 8:20 0% ` Olivier Matz
2019-07-11 8:34 0% ` Wang, Haiyue
2019-07-10 17:49 3% ` Stephen Hemminger
2019-07-10 18:12 0% ` Wiles, Keith
2019-07-11 7:53 4% ` Olivier Matz
2019-07-11 14:37 0% ` Wiles, Keith
2019-07-12 9:06 0% ` Olivier Matz
2019-07-11 7:36 0% ` Olivier Matz
2019-07-12 12:23 ` Jerin Jacob Kollanukkaran
2019-07-16 9:39 ` Olivier Matz
2019-07-16 14:43 3% ` Stephen Hemminger
2019-07-11 9:24 3% ` Thomas Monjalon
2019-07-12 14:54 0% ` Andrew Rybchenko
2019-07-16 9:49 0% ` Olivier Matz
2019-07-16 11:31 0% ` [dpdk-dev] ***Spam*** " Andrew Rybchenko
2019-07-10 9:57 3% [dpdk-dev] devtools: fix symbol change file matching Bing Zhao
2019-07-10 11:10 0% ` Neil Horman
2019-07-15 23:41 [dpdk-dev] [PATCH] pci: fix missing pci bus with shared library build Stephen Hemminger
2019-07-22 17:04 ` Thomas Monjalon
2019-07-22 17:13 ` Stephen Hemminger
2019-07-22 17:31 ` Thomas Monjalon
2019-07-22 18:53 ` Stephen Hemminger
2019-07-23 12:30 ` Bruce Richardson
2019-07-23 18:11 ` Stephen Hemminger
2019-07-24 8:56 3% ` Bruce Richardson
2019-07-16 18:52 [dpdk-dev] [PATCH v3 00/11] Rework API for RSA algorithm in asymmetric crypto Arek Kusztal
2019-07-16 18:52 ` [dpdk-dev] [PATCH v3 04/11] test: add cipher field to RSA test Arek Kusztal
2019-07-17 7:41 ` [dpdk-dev] [EXT] " Shally Verma
2019-07-17 9:42 ` Kusztal, ArkadiuszX
2019-07-17 12:54 ` Shally Verma
2019-07-18 12:44 3% ` Trahe, Fiona
2019-07-17 7:45 [dpdk-dev] [PATCH] app/testpmd: support QinQ strip offload viveksharma
2019-07-19 16:53 ` Ferruh Yigit
2019-07-22 12:04 ` Iremonger, Bernard
2019-07-22 14:26 ` Ferruh Yigit
2019-07-22 14:55 ` Iremonger, Bernard
2019-07-22 15:40 3% ` Ferruh Yigit
2019-07-22 17:03 0% ` Iremonger, Bernard
2019-07-22 17:16 0% ` Ferruh Yigit
2019-07-17 9:04 [dpdk-dev] [PATCH v7 0/4] kni: add IOVA=VA support vattunuru
2019-07-23 5:38 ` [dpdk-dev] [PATCH v8 0/5] " vattunuru
2019-07-23 5:38 3% ` [dpdk-dev] [PATCH v8 3/5] kni: add app specific mempool create & free routine vattunuru
2019-07-23 10:50 0% ` Andrew Rybchenko
2019-07-23 11:01 0% ` Vamsi Krishna Attunuru
2019-07-29 12:13 ` [dpdk-dev] [PATCH v9 0/5] kni: add IOVA=VA support vattunuru
2019-07-29 12:13 3% ` [dpdk-dev] [PATCH v9 3/5] kni: add app specific mempool create & free routine vattunuru
2019-07-17 12:34 [dpdk-dev] [RFC] mark asym session-buffer non-reuseable Ayuj Verma
2019-07-17 14:10 ` Kusztal, ArkadiuszX
2019-07-18 9:47 ` Ayuj Verma
2019-07-19 14:50 3% ` Ayuj Verma
2019-07-19 15:38 3% ` Trahe, Fiona
2019-07-17 18:40 7% [dpdk-dev] [PATCH] mempool/octeontx2: use noinline to preserve ABI pbhagavatula
2019-07-18 5:53 4% ` Jerin Jacob Kollanukkaran
2019-07-18 6:51 7% ` [dpdk-dev] [PATCH v2] mempool/octeontx2: fix possible ABI break with force inline pbhagavatula
2019-07-18 8:04 4% ` Jerin Jacob Kollanukkaran
2019-07-18 22:15 4% ` Thomas Monjalon
2019-07-18 14:43 8% ` [dpdk-dev] [PATCH] mempool/octeontx2: use noinline to preserve ABI Stephen Hemminger
2019-07-18 14:49 7% ` [dpdk-dev] [EXT] " Pavan Nikhilesh Bhagavatula
2019-07-18 16:09 [dpdk-dev] [PATCH v5 0/7] Rework API for RSA algorithm in asymmetric crypto Arek Kusztal
2019-07-18 16:09 ` [dpdk-dev] [PATCH v5 2/7] cryptodev: add cipher field to RSA op Arek Kusztal
2019-07-19 4:42 ` [dpdk-dev] [EXT] " Shally Verma
2019-07-19 5:10 3% ` Kusztal, ArkadiuszX
2019-07-23 9:13 3% [dpdk-dev] [PATCH] ethdev: avoid usage of uninit device info in bad port case Andrew Rybchenko
2019-07-23 10:40 0% ` Ferruh Yigit
2019-07-23 12:16 3% ` Andrew Rybchenko
2019-07-23 12:50 0% ` Thomas Monjalon
2019-07-23 12:11 3% ` [dpdk-dev] [PATCH v2] " Andrew Rybchenko
2019-07-23 13:14 0% ` Thomas Monjalon
2019-07-23 13:34 0% ` Andrew Rybchenko
2019-07-23 13:39 0% ` Thomas Monjalon
2019-07-23 18:45 0% ` Thomas Monjalon
2019-07-24 15:35 [dpdk-dev] [RFC] kni: support allmulticast mode set Xiaolong Ye
2019-07-29 13:38 4% ` Ferruh Yigit
2019-07-29 15:25 3% ` Ye Xiaolong
2019-07-24 22:22 4% [dpdk-dev] [dpdk-announce] You're Invited: DPDK Userspace, Sept. 19-20, Bordeaux, France Jill Lovato
2019-07-26 0:35 [dpdk-dev] [RFC,v2] ethdev: extend RSS offload types simei
2019-07-29 2:44 ` [dpdk-dev] [RFC,v3] " simei
2019-07-30 6:06 ` Ori Kam
2019-07-30 7:42 4% ` Adrien Mazarguil
2019-07-30 12:49 [dpdk-dev] [RFC 19.11 0/2] Hide DPDK internal struct from public API Marcin Zapolski
2019-07-30 12:49 ` [dpdk-dev] [RFC 19.11 1/2] ethdev: make DPDK core functions non-inline Marcin Zapolski
2019-07-30 15:01 3% ` Jerin Jacob Kollanukkaran
2019-07-30 15:32 0% ` Bruce Richardson
2019-07-30 13:24 14% [dpdk-dev] [PATCH v1] doc: update release notes for 19.08 John McNamara
2019-07-30 15:45 0% [dpdk-dev] [RFC 19.11 1/2] ethdev: make DPDK core functions non-inline Jerin Jacob Kollanukkaran
2019-07-30 16:05 5% ` Bruce Richardson
2019-07-30 16:24 3% ` [dpdk-dev] [EXT] " Jerin Jacob Kollanukkaran
2019-07-31 11:06 5% [dpdk-dev] [PATCH] doc: announce lcore_config symbol removal David Marchand
2019-07-31 13:48 0% ` Stephen Hemminger
2019-08-08 9:31 5% ` [dpdk-dev] [PATCH v2] " David Marchand
2019-08-02 15:38 11% [dpdk-dev] [PATCH v2 0/3] doc: changes to abi policy introducing major abi versions Ray Kinsella
2019-08-02 15:38 13% ` [dpdk-dev] [PATCH v2 1/3] doc: separate versioning.rst into version and policy Ray Kinsella
2019-08-02 15:38 32% ` [dpdk-dev] [PATCH v2 2/3] doc: changes to abi policy introducing major abi versions Ray Kinsella
2019-08-02 15:38 28% ` [dpdk-dev] [PATCH v2 3/3] doc: updates to versioning guide for " Ray Kinsella
2019-08-05 12:30 11% [dpdk-dev] [PATCH] doc: remove major in designation of normal releases Thomas Monjalon
2019-08-06 14:56 4% [dpdk-dev] [PATCH 1/2] doc: announce ethdev ABI change for LRO fields Matan Azrad
2019-08-06 15:27 4% ` Andrew Rybchenko
2019-08-10 21:40 4% ` Thomas Monjalon
2019-08-07 2:04 3% [dpdk-dev] [RFC 0/3] ethdev: add ptype as Rx offload Jerin Jacob Kollanukkaran
2019-08-07 8:32 0% ` Andrew Rybchenko
2019-08-07 15:22 0% ` Stephen Hemminger
2019-08-07 15:44 0% ` Andrew Rybchenko
2019-08-07 10:12 [dpdk-dev] [PATCH] eal: change max hugepage sizes to 4 Gagandeep Singh
2019-08-07 12:07 ` Thomas Monjalon
2019-08-07 13:28 ` Hemant Agrawal
2019-08-08 7:31 ` Thomas Monjalon
2019-08-12 9:43 3% ` Burakov, Anatoly
2019-08-08 8:12 4% [dpdk-dev] 19.11 Intel Roadmap O'Driscoll, Tim
2019-08-09 8:17 [dpdk-dev] [patch v4] doc: announce API change in ethdev offload flags pbhagavatula
2019-08-09 9:55 ` [dpdk-dev] [patch v5] " pbhagavatula
2019-08-09 10:13 ` Ananyev, Konstantin
2019-08-10 21:10 3% ` Thomas Monjalon
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).