Re: [dpdk-dev] [PATCH 1/2] mk: fix unsupported flag error on armhf architercture
> -Original Message-
> From: Thomas Monjalon
> Sent: Wednesday, November 27, 2019 1:02 AM
> To: Phil Yang (Arm Technology China)
> Cc: dev@dpdk.org; Bruce Richardson ;
> david.march...@redhat.com; jer...@marvell.com; Honnappa Nagarahalli
> ; Gavin Hu (Arm Technology China)
> ; Joyce Kong (Arm Technology China)
> ; nd ; sta...@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 1/2] mk: fix unsupported flag error on armhf
> architercture
>
> 12/11/2019 07:40, Phil Yang (Arm Technology China):
> > > -Original Message-
> > > From: Thomas Monjalon
> > > Sent: Tuesday, November 12, 2019 2:03 PM
> > > To: Phil Yang (Arm Technology China)
> > > Cc: Bruce Richardson ; dev@dpdk.org;
> > > david.march...@redhat.com; jer...@marvell.com; Honnappa
> Nagarahalli
> > > ; Gavin Hu (Arm Technology China)
> > > ; Joyce Kong (Arm Technology China)
> > > ; nd ; sta...@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 1/2] mk: fix unsupported flag error on
> armhf
> > > architercture
> > >
> > > 12/11/2019 06:25, Phil Yang (Arm Technology China):
> > > > From: Bruce Richardson
> > > > > On Mon, Nov 11, 2019 at 06:34:20PM +0800, Phil Yang wrote:
> > > > > > The older version (e.g. version 7.4.0 ) of GNU C compiler for the
> armhf
> > > > > > architecture doesn't support the flag '-Wno-address-of-packed-
> > > member',
> > > > > > so remove this flag for aarch32.
> > > > > >
> > > > > > Fixes: a385972c3675 ("mk: disable warning for packed member
> pointer")
> > > > > > Cc: sta...@dpdk.org
> > > > > >
> > > > > > Signed-off-by: Phil Yang
> > > > > > Reviewed-by: Gavin Hu
> > > > > > Tested-by: Joyce Kong
> > > > > >
> > > > > > ---
> > > > > > mk/toolchain/gcc/rte.vars.mk | 2 ++
> > > > > > 1 file changed, 2 insertions(+)
> > > > > >
> > > > > > diff --git a/mk/toolchain/gcc/rte.vars.mk
> > > b/mk/toolchain/gcc/rte.vars.mk
> > > > > > index 9fc7041..ec0cbbf 100644
> > > > > > --- a/mk/toolchain/gcc/rte.vars.mk
> > > > > > +++ b/mk/toolchain/gcc/rte.vars.mk
> > > > > > @@ -100,7 +100,9 @@ WERROR_FLAGS += -Wno-format-truncation
> > > > > > endif
> > > > > >
> > > > > > # disable packed member unalign warnings
> > > > > > +ifneq ($(CONFIG_RTE_ARCH_ARM), y)
> > > > > > WERROR_FLAGS += -Wno-address-of-packed-member
> > > > > > +endif
> > > > > >
> > > > > You don't need to do this, as gcc will not complain about this unknown
> > > flag
> > > > > unless you have other issues in your code.[1] I think it's better to
> keep
> > > the
> > > > > code clean in this case, otherwise we'll have the code littered with
> > > > > conditionals for various flags.
> > > > >
> > > > > /Bruce
> > > > >
> > > > > [1] https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
> > > > > "When an unrecognized warning option is requested (e.g.,
> > > > > -Wunknown-warning), GCC emits a diagnostic stating that the option
> is
> > > not
> > > > > recognized. However, if the -Wno- form is used, the behavior is
> slightly
> > > > > different: no diagnostic is produced for -Wno-unknown-warning
> unless
> > > other
> > > > > diagnostics are being produced. This allows the use of new -Wno-
> options
> > > > > with old compilers, but if something goes wrong, the compiler warns
> that
> > > an
> > > > > unrecognized option is present."
> > > >
> > > > Thanks, Bruce.
> > > >
> > > > There are thousands of warnings with alignment when compiling for
> > > ARMv7 (ARMv7 supports unaligned memory access).
> > > > Without this new flag, the build system works fine for ARMv7. So I add
> this
> > > conditional for ARMv7 only.
> > > > I agree with you we should clean up the code, but it needs a lot of
> effort to
> > > achieve that.
> > > > This patch is going to make the ARMv7 target build successfully during
> this
> > > period.
> > >
> > > I would go the opposite direction.
> > > I think we should remove all warnings disablement like "-Wno-
> something",
> > > and clean the code.
> >
> > Thanks, Thomas.
> >
> > I think it is a compiler issue rather than a code defect in this case, as It
> cannot recognize the '-Waddress-of-packed-member' flag.
> > "arm-linux-gnueabihf-gcc: error: unrecognized command line option '-
> Waddress-of-packed-member'"
> >
> > >
> > > If you want to allow building ARMv7, you can just allow warnings as not
> > > errors.
> > > So we will still see something is wrong but it won't prevent from
> > > building.
> >
> > Yes. We did this already, all the alignment issues are emitted as warnings
> on ARMv7.
> > Please see these two commits:
> > 79fa5c2a9992 ("mk: ignore alignment errors for ARMv7")
> > 6433c19105e8 ("mk: generalize strict alignment warning handling")
>
> I don't know what to do with this patch.
> I think it is not how it should work,
> but you say your compiler has a real bug.
Agree with you, however I haven't found a better solution for this issue yet.
>
> Can you confirm which compiler is it?
Please check the packet information dumped below, it is the latest version in
Ubuntu 18.04 LTS.
$ sudo apt show gcc-arm-linux-g
[dpdk-dev] [PATCH] MAINTAINERS: update armv8 crypto PMD maintainership
Signed-off-by: Ruifeng Wang Reviewed-by: Gavin Hu --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 4a0c9a47e..5f7213872 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -940,7 +940,7 @@ F: doc/guides/cryptodevs/ccp.rst F: doc/guides/cryptodevs/features/ccp.ini ARMv8 Crypto -M: Jerin Jacob +M: Ruifeng Wang F: drivers/crypto/armv8/ F: doc/guides/cryptodevs/armv8.rst F: doc/guides/cryptodevs/features/armv8.ini -- 2.17.1
Re: [dpdk-dev] [PATCH] MAINTAINERS: update armv8 crypto PMD maintainership
On Wed, Nov 27, 2019 at 5:15 PM Ruifeng Wang wrote: > > Signed-off-by: Ruifeng Wang > Reviewed-by: Gavin Hu > --- Request to add some git comments while merging or sending the v2. Something like below, It is expected to update this PMD to be in line with ARM's crypto library. Update the maintainership to refect the change. Acked-by: Jerin Jacob > MAINTAINERS | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 4a0c9a47e..5f7213872 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -940,7 +940,7 @@ F: doc/guides/cryptodevs/ccp.rst > F: doc/guides/cryptodevs/features/ccp.ini > > ARMv8 Crypto > -M: Jerin Jacob > +M: Ruifeng Wang > F: drivers/crypto/armv8/ > F: doc/guides/cryptodevs/armv8.rst > F: doc/guides/cryptodevs/features/armv8.ini > -- > 2.17.1 >
Re: [dpdk-dev] [EXT] Re: [PATCH v2 1/5] drivers/octeontx2: allow experimental symbols
Regards Sunil Kumar Kori >-Original Message- >From: Thomas Monjalon >Sent: Tuesday, November 26, 2019 9:51 PM >To: dev@dpdk.org >Cc: Sunil Kumar Kori ; Jerin Jacob Kollanukkaran >; Nithin Kumar Dabilpuram >; Vamsi Krishna Attunuru >; Kiran Kumar Kokkilagadda >; Satha Koteswara Rao Kottidi > >Subject: [EXT] Re: [dpdk-dev] [PATCH v2 1/5] drivers/octeontx2: allow >experimental symbols > >External Email > >-- >26/11/2019 07:15, Sunil Kumar Kori: >> Multiple experimental symbols are used. They must be allowed to avoid >> compilation error. > >If there was an error, >1/ I would see it in my compilation test 2/ There would be some "Fixes:" tag to >point the root cause Actually change is part of below series which is started using experimental symbols in mentioned driver. Apart of these drivers, FLAGs are already present in other drivers so that there is no error found. Error occurs when applying below series. So I had two options to get it done. Either I can do Makefile changes along with the corresponding changes or make them as a separate patch. I have chosen second option. And because of this is new change, it does not contain any "Fixes" tag. > >I guess this patch is not critical. >Where are patches 2, 3, 4, 5? Following are the series of patches: http://patches.dpdk.org/patch/63299/ http://patches.dpdk.org/patch/63271/ http://patches.dpdk.org/patch/63272/ http://patches.dpdk.org/patch/63273/ http://patches.dpdk.org/patch/63274/ Not all the patches are reworked for next versions that's why same is not reflected in subject line. > >> >> Signed-off-by: Sunil Kumar Kori >> --- >> drivers/common/octeontx2/Makefile | 2 ++ >> drivers/common/octeontx2/meson.build | 2 ++ >> drivers/net/octeontx2/Makefile| 2 ++ >> drivers/net/octeontx2/meson.build | 2 ++ >> drivers/raw/octeontx2_dma/Makefile| 2 ++ >> drivers/raw/octeontx2_dma/meson.build | 2 ++ >> 6 files changed, 12 insertions(+) > >
Re: [dpdk-dev] [PATCH v5] doc: clarify virtio PMD path selection
On 11/27/19 4:19 PM, Yinan wrote: > From: Yinan Wang > > Add virtio paths selection and usage introduction for better > virtio usability. > > Signed-off-by: Yinan Wang > --- > doc/guides/howto/index.rst| 1 + > .../virtio_paths_selection_and_usage.rst | 126 ++ > 2 files changed, 127 insertions(+) > create mode 100644 doc/guides/howto/virtio_paths_selection_and_usage.rst > Reviewed-by: Maxime Coquelin Thanks, Maxime
[dpdk-dev] [PATCH v2] MAINTAINERS: update armv8 crypto PMD maintainership
It is expected to update this PMD to be in line with Arm's crypto library. Update the maintainership to refect the change. Signed-off-by: Ruifeng Wang Reviewed-by: Gavin Hu Acked-by: Jerin Jacob --- v2: Add git comments to explain the change. (Jerin) MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 4a0c9a47e..5f7213872 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -940,7 +940,7 @@ F: doc/guides/cryptodevs/ccp.rst F: doc/guides/cryptodevs/features/ccp.ini ARMv8 Crypto -M: Jerin Jacob +M: Ruifeng Wang F: drivers/crypto/armv8/ F: doc/guides/cryptodevs/armv8.rst F: doc/guides/cryptodevs/features/armv8.ini -- 2.17.1
[dpdk-dev] [PATCH v8 0/1] fbarray: fix duplicated fbarray file in secondary
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 several secondaries run as app containers because each of containerized secondary has PID 1, and failed to reserve unique name other than first one. To reserve unique name in each of containers, use hostname in addition to PID. --- v2: * fix typo in commit message v3: * add fclose() after if getting hostname with fscan() is failed v4: * Increase the size of proc_id to 33 and add boundary in calling fscan() v5: * revise title to reflect the issue * use gethostname() instead of getting from `etc/hostname` * use HOST_NAME_MAX for size of string for hostname v6: * change to use hostname and pid to cover both of host and container cases * change RTE_FBARRAY_NAME_LEN to NAME_MAX to reserve enough size for filename v7: * discard changing RTE_FBARRAY_NAME_LEN to NAME_MAX to avoid breaking ABI * introduce int fbarray_sec_name_len instead of RTE_FBARRAY_NAME_LEN to define long filename only for secondary process * replace the order of postfixes of pid and hostname v8: * change RTE_FBARRAY_NAME_LEN to the maximum size for secondary * fix warning of Signed-off-by --- Yasufumi Ogawa (1): fbarray: fix duplicated fbarray file in secondary lib/librte_eal/common/include/rte_fbarray.h | 7 ++- lib/librte_eal/linux/eal/eal_memalloc.c | 11 --- 2 files changed, 14 insertions(+), 4 deletions(-) -- 2.17.1
[dpdk-dev] [PATCH v8 1/1] fbarray: fix duplicated fbarray file in secondary
From: Yasufumi Ogawa
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 several secondaries run as app containers because each
of containerized secondary has PID 1, and failed to reserve unique name
other than first one. To reserve unique name in each of containers, use
hostname in addition to PID.
Signed-off-by: Yasufumi Ogawa
---
lib/librte_eal/common/include/rte_fbarray.h | 7 ++-
lib/librte_eal/linux/eal/eal_memalloc.c | 11 ---
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/lib/librte_eal/common/include/rte_fbarray.h
b/lib/librte_eal/common/include/rte_fbarray.h
index 6dccdbec9..df003b8dc 100644
--- a/lib/librte_eal/common/include/rte_fbarray.h
+++ b/lib/librte_eal/common/include/rte_fbarray.h
@@ -39,7 +39,12 @@ extern "C" {
#include
#include
-#define RTE_FBARRAY_NAME_LEN 64
+/* Filename of fbarray is defined as a combination of several params
+ * such as "fbarray_memseg-1048576k-0-0_PID_HOSTNAME".
+ * The length of string before PID can be 32bytes, and the length of
+ * PID can be 7bytes maximamly. Final 1 byte is for null terminator.
+ */
+#define RTE_FBARRAY_NAME_LEN (32 + 7 + 1 + HOST_NAME_MAX + 1)
struct rte_fbarray {
char name[RTE_FBARRAY_NAME_LEN]; /**< name associated with an array */
diff --git a/lib/librte_eal/linux/eal/eal_memalloc.c
b/lib/librte_eal/linux/eal/eal_memalloc.c
index af6d0d023..8c50d3355 100644
--- a/lib/librte_eal/linux/eal/eal_memalloc.c
+++ b/lib/librte_eal/linux/eal/eal_memalloc.c
@@ -1365,6 +1365,7 @@ secondary_msl_create_walk(const struct rte_memseg_list
*msl,
struct rte_memseg_list *primary_msl, *local_msl;
char name[PATH_MAX];
int msl_idx, ret;
+ char hostname[HOST_NAME_MAX+1] = { 0 };
if (msl->external)
return 0;
@@ -1373,9 +1374,13 @@ secondary_msl_create_walk(const struct rte_memseg_list
*msl,
primary_msl = &mcfg->memsegs[msl_idx];
local_msl = &local_memsegs[msl_idx];
- /* create distinct fbarrays for each secondary */
- snprintf(name, RTE_FBARRAY_NAME_LEN, "%s_%i",
- primary_msl->memseg_arr.name, getpid());
+ /* Create distinct fbarrays for each secondary by using PID and
+* hostname. The reason why using hostname is because PID could be
+* duplicated among secondaries if it is launched in a container.
+*/
+ gethostname(hostname, sizeof(hostname));
+ snprintf(name, RTE_FBARRAY_NAME_LEN, "%s_%d_%s",
+ primary_msl->memseg_arr.name, (int)getpid(), hostname);
ret = rte_fbarray_init(&local_msl->memseg_arr, name,
primary_msl->memseg_arr.len,
--
2.17.1
Re: [dpdk-dev] [PATCH] MAINTAINERS: update armv8 crypto PMD maintainership
> -Original Message- > From: Jerin Jacob > Sent: Wednesday, November 27, 2019 16:34 > To: Ruifeng Wang (Arm Technology China) > Cc: jer...@marvell.com; dpdk-dev ; Gavin Hu (Arm > Technology China) ; Honnappa Nagarahalli > ; nd > Subject: Re: [dpdk-dev] [PATCH] MAINTAINERS: update armv8 crypto PMD > maintainership > > On Wed, Nov 27, 2019 at 5:15 PM Ruifeng Wang > wrote: > > > > Signed-off-by: Ruifeng Wang > > Reviewed-by: Gavin Hu > > --- > > Request to add some git comments while merging or sending the v2. > Something like below, > Thank you Jerin. I have sent out v2 with your comments incorporated. /Ruifeng > It is expected to update this PMD to be in line with ARM's crypto library. > Update the maintainership to refect the change. > > Acked-by: Jerin Jacob > > > MAINTAINERS | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/MAINTAINERS b/MAINTAINERS index 4a0c9a47e..5f7213872 > > 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -940,7 +940,7 @@ F: doc/guides/cryptodevs/ccp.rst > > F: doc/guides/cryptodevs/features/ccp.ini > > > > ARMv8 Crypto > > -M: Jerin Jacob > > +M: Ruifeng Wang > > F: drivers/crypto/armv8/ > > F: doc/guides/cryptodevs/armv8.rst > > F: doc/guides/cryptodevs/features/armv8.ini > > -- > > 2.17.1 > >
Re: [dpdk-dev] [PATCH 1/2] mk: fix unsupported flag error on armhf architercture
On Wed, Nov 27, 2019 at 08:09:22AM +, Phil Yang (Arm Technology China)
wrote:
> > -Original Message-
> > From: Thomas Monjalon
> > Sent: Wednesday, November 27, 2019 1:02 AM
> > To: Phil Yang (Arm Technology China)
> > Cc: dev@dpdk.org; Bruce Richardson ;
> > david.march...@redhat.com; jer...@marvell.com; Honnappa Nagarahalli
> > ; Gavin Hu (Arm Technology China)
> > ; Joyce Kong (Arm Technology China)
> > ; nd ; sta...@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 1/2] mk: fix unsupported flag error on armhf
> > architercture
> >
> > 12/11/2019 07:40, Phil Yang (Arm Technology China):
> > > > -Original Message-
> > > > From: Thomas Monjalon
> > > > Sent: Tuesday, November 12, 2019 2:03 PM
> > > > To: Phil Yang (Arm Technology China)
> > > > Cc: Bruce Richardson ; dev@dpdk.org;
> > > > david.march...@redhat.com; jer...@marvell.com; Honnappa
> > Nagarahalli
> > > > ; Gavin Hu (Arm Technology China)
> > > > ; Joyce Kong (Arm Technology China)
> > > > ; nd ; sta...@dpdk.org
> > > > Subject: Re: [dpdk-dev] [PATCH 1/2] mk: fix unsupported flag error on
> > armhf
> > > > architercture
> > > >
> > > > 12/11/2019 06:25, Phil Yang (Arm Technology China):
> > > > > From: Bruce Richardson
> > > > > > On Mon, Nov 11, 2019 at 06:34:20PM +0800, Phil Yang wrote:
> > > > > > > The older version (e.g. version 7.4.0 ) of GNU C compiler for the
> > armhf
> > > > > > > architecture doesn't support the flag '-Wno-address-of-packed-
> > > > member',
> > > > > > > so remove this flag for aarch32.
> > > > > > >
> > > > > > > Fixes: a385972c3675 ("mk: disable warning for packed member
> > pointer")
> > > > > > > Cc: sta...@dpdk.org
> > > > > > >
> > > > > > > Signed-off-by: Phil Yang
> > > > > > > Reviewed-by: Gavin Hu
> > > > > > > Tested-by: Joyce Kong
> > > > > > >
> > > > > > > ---
> > > > > > > mk/toolchain/gcc/rte.vars.mk | 2 ++
> > > > > > > 1 file changed, 2 insertions(+)
> > > > > > >
> > > > > > > diff --git a/mk/toolchain/gcc/rte.vars.mk
> > > > b/mk/toolchain/gcc/rte.vars.mk
> > > > > > > index 9fc7041..ec0cbbf 100644
> > > > > > > --- a/mk/toolchain/gcc/rte.vars.mk
> > > > > > > +++ b/mk/toolchain/gcc/rte.vars.mk
> > > > > > > @@ -100,7 +100,9 @@ WERROR_FLAGS += -Wno-format-truncation
> > > > > > > endif
> > > > > > >
> > > > > > > # disable packed member unalign warnings
> > > > > > > +ifneq ($(CONFIG_RTE_ARCH_ARM), y)
> > > > > > > WERROR_FLAGS += -Wno-address-of-packed-member
> > > > > > > +endif
> > > > > > >
> > > > > > You don't need to do this, as gcc will not complain about this
> > > > > > unknown
> > > > flag
> > > > > > unless you have other issues in your code.[1] I think it's better to
> > keep
> > > > the
> > > > > > code clean in this case, otherwise we'll have the code littered with
> > > > > > conditionals for various flags.
> > > > > >
> > > > > > /Bruce
> > > > > >
> > > > > > [1] https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
> > > > > > "When an unrecognized warning option is requested (e.g.,
> > > > > > -Wunknown-warning), GCC emits a diagnostic stating that the option
> > is
> > > > not
> > > > > > recognized. However, if the -Wno- form is used, the behavior is
> > slightly
> > > > > > different: no diagnostic is produced for -Wno-unknown-warning
> > unless
> > > > other
> > > > > > diagnostics are being produced. This allows the use of new -Wno-
> > options
> > > > > > with old compilers, but if something goes wrong, the compiler warns
> > that
> > > > an
> > > > > > unrecognized option is present."
> > > > >
> > > > > Thanks, Bruce.
> > > > >
> > > > > There are thousands of warnings with alignment when compiling for
> > > > ARMv7 (ARMv7 supports unaligned memory access).
> > > > > Without this new flag, the build system works fine for ARMv7. So I
> > > > > add
> > this
> > > > conditional for ARMv7 only.
> > > > > I agree with you we should clean up the code, but it needs a lot of
> > effort to
> > > > achieve that.
> > > > > This patch is going to make the ARMv7 target build successfully during
> > this
> > > > period.
> > > >
> > > > I would go the opposite direction.
> > > > I think we should remove all warnings disablement like "-Wno-
> > something",
> > > > and clean the code.
> > >
> > > Thanks, Thomas.
> > >
> > > I think it is a compiler issue rather than a code defect in this case, as
> > > It
> > cannot recognize the '-Waddress-of-packed-member' flag.
> > > "arm-linux-gnueabihf-gcc: error: unrecognized command line option '-
> > Waddress-of-packed-member'"
> > >
> > > >
> > > > If you want to allow building ARMv7, you can just allow warnings as not
> > > > errors.
> > > > So we will still see something is wrong but it won't prevent from
> > > > building.
> > >
> > > Yes. We did this already, all the alignment issues are emitted as warnings
> > on ARMv7.
> > > Please see these two commits:
> > > 79fa5c2a9992 ("mk: ignore alignment errors for ARMv7")
> > > 6433c19105e8 ("mk: generalize strict alignment warning handling")
> >
> > I don't
Re: [dpdk-dev] [PATCH] vhost: fix insecure temporary file
On Wed, Nov 27, 2019 at 02:19:39AM +, Yu, Jin wrote:
>
>
> > -Original Message-
> > From: Bruce Richardson
> > Sent: Tuesday, November 26, 2019 6:00 PM
> > To: Yu, Jin
> > Cc: Maxime Coquelin ; Bie, Tiwei
> > ; Wang, Zhihong ;
> > dev@dpdk.org; sta...@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] vhost: fix insecure temporary file
> >
> > On Tue, Nov 26, 2019 at 11:19:00PM +0800, Jin Yu wrote:
> > > When using mkstemp(), remember to safely set the umask before to
> > > restrict the resulting temporary file permissions to only the owner.
> > >
> > > Coverity issue: 350367
> > > Fixes: d87f1a1cb7b6 ("vhost: support inflight info sharing")
> > > Cc: sta...@dpdk.org
> > >
> > > Signed-off-by: Jin Yu
> > > ---
> > > lib/librte_vhost/vhost_user.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/lib/librte_vhost/vhost_user.c
> > > b/lib/librte_vhost/vhost_user.c index 0cfb8b792..1a68e23e3 100644
> > > --- a/lib/librte_vhost/vhost_user.c
> > > +++ b/lib/librte_vhost/vhost_user.c
> > > @@ -1342,6 +1342,7 @@ inflight_mem_alloc(const char *name, size_t size,
> > int *fd)
> > > RTE_SET_USED(name);
> > > #endif
> > > if (mfd == -1) {
> > > + mode_t mask = umask(0600);
> > > mfd = mkstemp(fname);
> >
> > Setting the umask is unnecessary, as if you read the man page for mkstemp:
> >
> > "The file is created with permissions 0600, that is, read plus write for
> > owner
> > only."
> >
> > I am aware that coverity flags this as a potential issue, but if you follow
> > the
> > link from the coverity issue to CWE-377 on cwe.mitre.org, you can find the
> > following at the end of the "Notes" section:
> >
> > "Finally, mkstemp() is a reasonably safe way create temporary files. It will
> > attempt to create and open a unique file based on a filename template
> > provided by the user combined with a series of randomly generated
> > characters. If it is unable to create such a file, it will fail and return
> > -1. On
> > modern systems the file is opened using mode 0600, which means the file
> > will be secure from tampering unless the user explicitly changes its access
> > permissions. However, mkstemp() still suffers from the use of predictable
> > file
> > names and can leave an application vulnerable to denial of service attacks
> > if
> > an attacker causes mkstemp() to fail by predicting and pre-creating the
> > filenames to be used."
> >
> > So it seems that for creating temporary files, mkstemp() is probably the
> > best
> > function we can use. Therefore, I recommend not trying to patch this issue
> > and just mark the issue as "ignore" in coverity.
>
> Yes. I agree with you. I just thought we must fix the coverity issue. So I
> add the umask.
> I would prefer to mark this issue as "ignore" in coverity.
> >
You can try and find a better fix if you like, but setting the umask is
pointless for using mkstemp. Therefore, unless you have an alternative, I
recommend just marking the issue as "false positive" and set it to
"ignore".
Regards,
/Bruce
Re: [dpdk-dev] [PATCH] examples/vhost_blk: fix the TOCTOU
On Wed, Nov 27, 2019 at 02:36:01AM +, Yu, Jin wrote:
> > -Original Message-
> > From: Bruce Richardson
> > Sent: Tuesday, November 26, 2019 6:26 PM
> > To: Yu, Jin
> > Cc: Maxime Coquelin ; Bie, Tiwei
> > ; Wang, Zhihong ;
> > dev@dpdk.org; sta...@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] examples/vhost_blk: fix the TOCTOU
> >
> > On Tue, Nov 26, 2019 at 11:32:14PM +0800, Jin Yu wrote:
> > > Fix the time of check time of use warning in example code
> > >
> > > Coverity issue: 350589 158663
> > > Fixes: c19beb3f38cd ("examples/vhost_blk: introduce vhost storage
> > > sample")
> > > Cc: sta...@dpdk.org
> > >
> > > Signed-off-by: Jin Yu
> > > ---
> > > examples/vhost_blk/vhost_blk.c | 9 ++---
> > > 1 file changed, 2 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/examples/vhost_blk/vhost_blk.c
> > > b/examples/vhost_blk/vhost_blk.c index 3182a488b..bcb4ebb0b 100644
> > > --- a/examples/vhost_blk/vhost_blk.c
> > > +++ b/examples/vhost_blk/vhost_blk.c
> > > @@ -993,11 +993,7 @@ vhost_blk_ctrlr_construct(const char *ctrlr_name)
> > > }
> > > snprintf(dev_pathname, sizeof(dev_pathname), "%s/%s", path,
> > > ctrlr_name);
> > >
> > > - if (access(dev_pathname, F_OK) != -1) {
> > > - if (unlink(dev_pathname) != 0)
> > > - rte_exit(EXIT_FAILURE, "Cannot remove %s.\n",
> > > - dev_pathname);
> > > - }
> > > + unlink(dev_pathname);
> > >
> >
> > The original code did an exit if the delete failed, do you intend there to
> > be a
> > behaviour change here? You can probably get the same behaviour if you
> > check the errno on an unlink failure, e.g. ENOENT means file doesn't exist.
> >
> > If not having the app exit on unlink failure is reasonable behaviour then
> > ignore this comment.
>
> I considered it. I think it's ok to ignore the errno of unlink failure. This
> code just want
> to remove the file. There are two situations. The first one is that file
> doesn't exist the unlink
> fails and it's ok to ignore. The second one is that unlink fails to remove
> file but the next bind()
> would fail too so I think it's ok to ignore too.
> >
Ok, thanks for clarifying.
Re: [dpdk-dev] [EXT] Re: [PATCH v2 1/5] drivers/octeontx2: allow experimental symbols
27/11/2019 09:34, Sunil Kumar Kori: > From: Thomas Monjalon > >26/11/2019 07:15, Sunil Kumar Kori: > >> Multiple experimental symbols are used. They must be allowed to avoid > >> compilation error. > > > >If there was an error, > >1/ I would see it in my compilation test 2/ There would be some "Fixes:" tag > >to > >point the root cause > > Actually change is part of below series which is started using experimental > symbols in mentioned driver. > Apart of these drivers, FLAGs are already present in other drivers so that > there is no error found. > Error occurs when applying below series. > > So I had two options to get it done. Either I can do Makefile changes along > with the corresponding changes or > make them as a separate patch. I have chosen second option. This is the wrong choice :) When you do a change, it should be atomic, i.e. includes changes which are dependent. > And because of this is new change, it does not contain any "Fixes" tag. > > > >I guess this patch is not critical. > >Where are patches 2, 3, 4, 5? > Following are the series of patches: > http://patches.dpdk.org/patch/63299/ > http://patches.dpdk.org/patch/63271/ > http://patches.dpdk.org/patch/63272/ > http://patches.dpdk.org/patch/63273/ > http://patches.dpdk.org/patch/63274/ > Not all the patches are reworked for next versions that's why same is not > reflected in subject line. When you send a new version, you should send the whole series again. And please don't forget changelogs and --in-reply-to. Thanks
[dpdk-dev] [PATCH] net/mlx5: fix default mark copy flow
In extensive metadata mode the MARK copy table is engaged,
if the application creates the flow with zero MARK ID action:
flow create 1 ingress pattern eth / ... / end actions mark id 0 / .. end
And then destroys that, the traffic to the port stops. This happens
due to default flow for the copy table has the zero ID and is removed
with the application rule. The patch extends internal ID variable
to 64 bits and provide the UINT64_MAX ID for the copy table default
rule.
Fixes: dd3c774f6ffb ("net/mlx5: add metadata register copy table")
Signed-off-by: Viacheslav Ovsiienko
---
drivers/net/mlx5/mlx5_defs.h | 1 +
drivers/net/mlx5/mlx5_flow.c | 19 ++-
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_defs.h b/drivers/net/mlx5/mlx5_defs.h
index 9e113c5..a577ad8 100644
--- a/drivers/net/mlx5/mlx5_defs.h
+++ b/drivers/net/mlx5/mlx5_defs.h
@@ -174,6 +174,7 @@
/* Size of the simple hash table for metadata register table. */
#define MLX5_FLOW_MREG_HTABLE_SZ 4096
#define MLX5_FLOW_MREG_HNAME "MARK_COPY_TABLE"
+#define MLX5_DEFAULT_COPY_ID UINT64_MAX
/* Definition of static_assert found in /usr/include/assert.h */
#ifndef HAVE_STATIC_ASSERT
diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index 5c78ea7..f464d01 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -2903,7 +2903,7 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev
*dev, int32_t priority,
* Associated resource on success, NULL otherwise and rte_errno is set.
*/
static struct mlx5_flow_mreg_copy_resource *
-flow_mreg_add_copy_action(struct rte_eth_dev *dev, uint32_t mark_id,
+flow_mreg_add_copy_action(struct rte_eth_dev *dev, uint64_t mark_id,
struct rte_flow_error *error)
{
struct mlx5_priv *priv = dev->data->dev_private;
@@ -2912,13 +2912,13 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev
*dev, int32_t priority,
.ingress = 1,
};
struct mlx5_rte_flow_item_tag tag_spec = {
- .data = mark_id,
+ .data = (uint32_t)(mark_id & UINT32_MAX),
};
struct rte_flow_item items[] = {
[1] = { .type = RTE_FLOW_ITEM_TYPE_END, },
};
struct rte_flow_action_mark ftag = {
- .id = mark_id,
+ .id = (uint32_t)(mark_id & UINT32_MAX),
};
struct mlx5_flow_action_copy_mreg cp_mreg = {
.dst = REG_B,
@@ -2947,16 +2947,16 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev
*dev, int32_t priority,
mcp_res = (void *)mlx5_hlist_lookup(priv->mreg_cp_tbl, mark_id);
if (mcp_res) {
/* For non-default rule. */
- if (mark_id)
+ if (mark_id != MLX5_DEFAULT_COPY_ID)
mcp_res->refcnt++;
- assert(mark_id || mcp_res->refcnt == 1);
+ assert(mark_id != MLX5_DEFAULT_COPY_ID || mcp_res->refcnt == 1);
return mcp_res;
}
/* Provide the full width of FLAG specific value. */
if (mark_id == (priv->sh->dv_regc0_mask & MLX5_FLOW_MARK_DEFAULT))
tag_spec.data = MLX5_FLOW_MARK_DEFAULT;
/* Build a new flow. */
- if (mark_id) {
+ if (mark_id != MLX5_DEFAULT_COPY_ID) {
items[0] = (struct rte_flow_item){
.type = MLX5_RTE_FLOW_ITEM_TYPE_TAG,
.spec = &tag_spec,
@@ -3054,7 +3054,7 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev
*dev, int32_t priority,
}
/*
* We do not check availability of metadata registers here,
-* because copy resources are allocated in this case.
+* because copy resources are not allocated in this case.
*/
if (--mcp_res->refcnt)
return;
@@ -3133,7 +3133,8 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev
*dev, int32_t priority,
/* Check if default flow is registered. */
if (!priv->mreg_cp_tbl)
return;
- mcp_res = (void *)mlx5_hlist_lookup(priv->mreg_cp_tbl, 0ULL);
+ mcp_res = (void *)mlx5_hlist_lookup(priv->mreg_cp_tbl,
+ MLX5_DEFAULT_COPY_ID);
if (!mcp_res)
return;
assert(mcp_res->flow);
@@ -3166,7 +3167,7 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev
*dev, int32_t priority,
!mlx5_flow_ext_mreg_supported(dev) ||
!priv->sh->dv_regc0_mask)
return 0;
- mcp_res = flow_mreg_add_copy_action(dev, 0, error);
+ mcp_res = flow_mreg_add_copy_action(dev, MLX5_DEFAULT_COPY_ID, error);
if (!mcp_res)
return -rte_errno;
return 0;
--
1.8.3.1
Re: [dpdk-dev] [PATCH 1/2] mk: fix unsupported flag error on armhf architercture
> -Original Message-
> From: Bruce Richardson
> Sent: Wednesday, November 27, 2019 5:30 PM
> To: Phil Yang (Arm Technology China)
> Cc: tho...@monjalon.net; dev@dpdk.org; david.march...@redhat.com;
> jer...@marvell.com; Honnappa Nagarahalli
> ; Gavin Hu (Arm Technology China)
> ; Joyce Kong (Arm Technology China)
> ; nd ; sta...@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 1/2] mk: fix unsupported flag error on armhf
> architercture
>
> On Wed, Nov 27, 2019 at 08:09:22AM +, Phil Yang (Arm Technology China)
> wrote:
> > > -Original Message-
> > > From: Thomas Monjalon
> > > Sent: Wednesday, November 27, 2019 1:02 AM
> > > To: Phil Yang (Arm Technology China)
> > > Cc: dev@dpdk.org; Bruce Richardson ;
> > > david.march...@redhat.com; jer...@marvell.com; Honnappa
> Nagarahalli
> > > ; Gavin Hu (Arm Technology China)
> > > ; Joyce Kong (Arm Technology China)
> > > ; nd ; sta...@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 1/2] mk: fix unsupported flag error on
> armhf
> > > architercture
> > >
> > > 12/11/2019 07:40, Phil Yang (Arm Technology China):
> > > > > -Original Message-
> > > > > From: Thomas Monjalon
> > > > > Sent: Tuesday, November 12, 2019 2:03 PM
> > > > > To: Phil Yang (Arm Technology China)
> > > > > Cc: Bruce Richardson ; dev@dpdk.org;
> > > > > david.march...@redhat.com; jer...@marvell.com; Honnappa
> > > Nagarahalli
> > > > > ; Gavin Hu (Arm Technology China)
> > > > > ; Joyce Kong (Arm Technology China)
> > > > > ; nd ; sta...@dpdk.org
> > > > > Subject: Re: [dpdk-dev] [PATCH 1/2] mk: fix unsupported flag error
> on
> > > armhf
> > > > > architercture
> > > > >
> > > > > 12/11/2019 06:25, Phil Yang (Arm Technology China):
> > > > > > From: Bruce Richardson
> > > > > > > On Mon, Nov 11, 2019 at 06:34:20PM +0800, Phil Yang wrote:
> > > > > > > > The older version (e.g. version 7.4.0 ) of GNU C compiler for
> > > > > > > > the
> > > armhf
> > > > > > > > architecture doesn't support the flag '-Wno-address-of-packed-
> > > > > member',
> > > > > > > > so remove this flag for aarch32.
> > > > > > > >
> > > > > > > > Fixes: a385972c3675 ("mk: disable warning for packed member
> > > pointer")
> > > > > > > > Cc: sta...@dpdk.org
> > > > > > > >
> > > > > > > > Signed-off-by: Phil Yang
> > > > > > > > Reviewed-by: Gavin Hu
> > > > > > > > Tested-by: Joyce Kong
> > > > > > > >
> > > > > > > > ---
> > > > > > > > mk/toolchain/gcc/rte.vars.mk | 2 ++
> > > > > > > > 1 file changed, 2 insertions(+)
> > > > > > > >
> > > > > > > > diff --git a/mk/toolchain/gcc/rte.vars.mk
> > > > > b/mk/toolchain/gcc/rte.vars.mk
> > > > > > > > index 9fc7041..ec0cbbf 100644
> > > > > > > > --- a/mk/toolchain/gcc/rte.vars.mk
> > > > > > > > +++ b/mk/toolchain/gcc/rte.vars.mk
> > > > > > > > @@ -100,7 +100,9 @@ WERROR_FLAGS += -Wno-format-
> truncation
> > > > > > > > endif
> > > > > > > >
> > > > > > > > # disable packed member unalign warnings
> > > > > > > > +ifneq ($(CONFIG_RTE_ARCH_ARM), y)
> > > > > > > > WERROR_FLAGS += -Wno-address-of-packed-member
> > > > > > > > +endif
> > > > > > > >
> > > > > > > You don't need to do this, as gcc will not complain about this
> unknown
> > > > > flag
> > > > > > > unless you have other issues in your code.[1] I think it's better
> > > > > > > to
> > > keep
> > > > > the
> > > > > > > code clean in this case, otherwise we'll have the code littered
> > > > > > > with
> > > > > > > conditionals for various flags.
> > > > > > >
> > > > > > > /Bruce
> > > > > > >
> > > > > > > [1] https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
> > > > > > > "When an unrecognized warning option is requested (e.g.,
> > > > > > > -Wunknown-warning), GCC emits a diagnostic stating that the
> option
> > > is
> > > > > not
> > > > > > > recognized. However, if the -Wno- form is used, the behavior is
> > > slightly
> > > > > > > different: no diagnostic is produced for -Wno-unknown-warning
> > > unless
> > > > > other
> > > > > > > diagnostics are being produced. This allows the use of new -Wno-
> > > options
> > > > > > > with old compilers, but if something goes wrong, the compiler
> warns
> > > that
> > > > > an
> > > > > > > unrecognized option is present."
> > > > > >
> > > > > > Thanks, Bruce.
> > > > > >
> > > > > > There are thousands of warnings with alignment when compiling for
> > > > > ARMv7 (ARMv7 supports unaligned memory access).
> > > > > > Without this new flag, the build system works fine for ARMv7. So I
> add
> > > this
> > > > > conditional for ARMv7 only.
> > > > > > I agree with you we should clean up the code, but it needs a lot of
> > > effort to
> > > > > achieve that.
> > > > > > This patch is going to make the ARMv7 target build successfully
> during
> > > this
> > > > > period.
> > > > >
> > > > > I would go the opposite direction.
> > > > > I think we should remove all warnings disablement like "-Wno-
> > > something",
> > > > > and clean the code.
> > > >
> > > > Thanks, Thomas.
> > > >
> > > > I think it is a compiler issue
[dpdk-dev] [PATCH v2 2/4] common/octeontx2: add interrupt offset to mbox structure
mbox response are triggered at bar2 + RVU_PF_INT or bar2 + RVU_VF_INT,
depending upon the device. To process these interrupts different irq
handlers are installed. To unify it, added offset field into mbox
structure which is initialized with RVU_PF_INT or RVU_VF_INT at the time
of otx2_mbox_init.
Signed-off-by: Sunil Kumar Kori
---
v2:
* Rebased patch on 19.11-rc4
drivers/common/octeontx2/otx2_dev.c | 14 ++
drivers/common/octeontx2/otx2_mbox.c | 5 +++--
drivers/common/octeontx2/otx2_mbox.h | 5 +++--
3 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/common/octeontx2/otx2_dev.c
b/drivers/common/octeontx2/otx2_dev.c
index 0fc799e4a..6f29d6108 100644
--- a/drivers/common/octeontx2/otx2_dev.c
+++ b/drivers/common/octeontx2/otx2_dev.c
@@ -900,6 +900,7 @@ otx2_dev_priv_init(struct rte_pci_device *pci_dev, void
*otx2_dev)
{
int up_direction = MBOX_DIR_PFAF_UP;
int rc, direction = MBOX_DIR_PFAF;
+ uint64_t intr_offset = RVU_PF_INT;
struct otx2_dev *dev = otx2_dev;
uintptr_t bar2, bar4;
uint64_t bar4_addr;
@@ -924,15 +925,18 @@ otx2_dev_priv_init(struct rte_pci_device *pci_dev, void
*otx2_dev)
if (otx2_dev_is_vf(dev)) {
direction = MBOX_DIR_VFPF;
up_direction = MBOX_DIR_VFPF_UP;
+ intr_offset = RVU_VF_INT;
}
/* Initialize the local mbox */
- rc = otx2_mbox_init(&dev->mbox_local, bar4, bar2, direction, 1);
+ rc = otx2_mbox_init(&dev->mbox_local, bar4, bar2, direction, 1,
+ intr_offset);
if (rc)
goto error;
dev->mbox = &dev->mbox_local;
- rc = otx2_mbox_init(&dev->mbox_up, bar4, bar2, up_direction, 1);
+ rc = otx2_mbox_init(&dev->mbox_up, bar4, bar2, up_direction, 1,
+ intr_offset);
if (rc)
goto error;
@@ -967,13 +971,15 @@ otx2_dev_priv_init(struct rte_pci_device *pci_dev, void
*otx2_dev)
}
/* Init mbox object */
rc = otx2_mbox_init(&dev->mbox_vfpf, (uintptr_t)hwbase,
- bar2, MBOX_DIR_PFVF, pci_dev->max_vfs);
+ bar2, MBOX_DIR_PFVF, pci_dev->max_vfs,
+ intr_offset);
if (rc)
goto iounmap;
/* PF -> VF UP messages */
rc = otx2_mbox_init(&dev->mbox_vfpf_up, (uintptr_t)hwbase,
- bar2, MBOX_DIR_PFVF_UP, pci_dev->max_vfs);
+ bar2, MBOX_DIR_PFVF_UP, pci_dev->max_vfs,
+ intr_offset);
if (rc)
goto mbox_fini;
}
diff --git a/drivers/common/octeontx2/otx2_mbox.c
b/drivers/common/octeontx2/otx2_mbox.c
index c359bf42f..ad8e0c3aa 100644
--- a/drivers/common/octeontx2/otx2_mbox.c
+++ b/drivers/common/octeontx2/otx2_mbox.c
@@ -59,12 +59,13 @@ otx2_mbox_reset(struct otx2_mbox *mbox, int devid)
}
int
-otx2_mbox_init(struct otx2_mbox *mbox, uintptr_t hwbase,
- uintptr_t reg_base, int direction, int ndevs)
+otx2_mbox_init(struct otx2_mbox *mbox, uintptr_t hwbase, uintptr_t reg_base,
+ int direction, int ndevs, uint64_t intr_offset)
{
struct otx2_mbox_dev *mdev;
int devid;
+ mbox->intr_offset = intr_offset;
mbox->reg_base = reg_base;
mbox->hwbase = hwbase;
diff --git a/drivers/common/octeontx2/otx2_mbox.h
b/drivers/common/octeontx2/otx2_mbox.h
index e0e4e2f63..162d12468 100644
--- a/drivers/common/octeontx2/otx2_mbox.h
+++ b/drivers/common/octeontx2/otx2_mbox.h
@@ -73,6 +73,7 @@ struct otx2_mbox {
uint16_t tx_size; /* Size of Tx region */
uint16_t ndevs;/* The number of peers */
struct otx2_mbox_dev *dev;
+ uint64_t intr_offset; /* offset to interrupt register */
};
/* Header which precedes all mbox messages */
@@ -1562,8 +1563,8 @@ struct tim_enable_rsp {
const char *otx2_mbox_id2name(uint16_t id);
int otx2_mbox_id2size(uint16_t id);
void otx2_mbox_reset(struct otx2_mbox *mbox, int devid);
-int otx2_mbox_init(struct otx2_mbox *mbox, uintptr_t hwbase,
- uintptr_t reg_base, int direction, int ndevs);
+int otx2_mbox_init(struct otx2_mbox *mbox, uintptr_t hwbase, uintptr_t
reg_base,
+ int direction, int ndevsi, uint64_t intr_offset);
void otx2_mbox_fini(struct otx2_mbox *mbox);
void otx2_mbox_msg_send(struct otx2_mbox *mbox, int devid);
int otx2_mbox_wait_for_rsp(struct otx2_mbox *mbox, int devid);
--
2.17.1
[dpdk-dev] [PATCH v2 1/4] eal: add API to check if its interrupt context
Added an API to check if current execution is in interrupt
context. This will be helpful to handle nested interrupt cases.
Signed-off-by: Harman Kalra
Signed-off-by: Sunil Kumar Kori
---
v2:
- Rebased patch on 19.11-rc4
lib/librte_eal/common/include/rte_interrupts.h | 15 +++
lib/librte_eal/freebsd/eal/eal_interrupts.c| 5 +
lib/librte_eal/linux/eal/eal_interrupts.c | 5 +
lib/librte_eal/rte_eal_version.map | 1 +
4 files changed, 26 insertions(+)
diff --git a/lib/librte_eal/common/include/rte_interrupts.h
b/lib/librte_eal/common/include/rte_interrupts.h
index e3b406abc..0a82e28a8 100644
--- a/lib/librte_eal/common/include/rte_interrupts.h
+++ b/lib/librte_eal/common/include/rte_interrupts.h
@@ -138,6 +138,21 @@ int rte_intr_disable(const struct rte_intr_handle
*intr_handle);
__rte_experimental
int rte_intr_ack(const struct rte_intr_handle *intr_handle);
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Check if currently executing in interrupt context
+ *
+ * @return
+ * - positive in case of interrupt context
+ * - zero in case of process context
+ * - negative if unsuccessful
+ */
+__rte_experimental
+int
+rte_thread_is_intr(void);
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/freebsd/eal/eal_interrupts.c
b/lib/librte_eal/freebsd/eal/eal_interrupts.c
index f6831b790..ce2a27b4a 100644
--- a/lib/librte_eal/freebsd/eal/eal_interrupts.c
+++ b/lib/librte_eal/freebsd/eal/eal_interrupts.c
@@ -671,3 +671,8 @@ rte_intr_free_epoll_fd(struct rte_intr_handle *intr_handle)
{
RTE_SET_USED(intr_handle);
}
+
+int rte_thread_is_intr(void)
+{
+ return pthread_equal(intr_thread, pthread_self());
+}
diff --git a/lib/librte_eal/linux/eal/eal_interrupts.c
b/lib/librte_eal/linux/eal/eal_interrupts.c
index 1955324d3..c00f5a575 100644
--- a/lib/librte_eal/linux/eal/eal_interrupts.c
+++ b/lib/librte_eal/linux/eal/eal_interrupts.c
@@ -1487,3 +1487,8 @@ rte_intr_cap_multiple(struct rte_intr_handle *intr_handle)
return 0;
}
+
+int rte_thread_is_intr(void)
+{
+ return pthread_equal(intr_thread, pthread_self());
+}
diff --git a/lib/librte_eal/rte_eal_version.map
b/lib/librte_eal/rte_eal_version.map
index e38d02530..397e787cf 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -332,4 +332,5 @@ EXPERIMENTAL {
# added in 19.11
rte_log_get_stream;
rte_mcfg_get_single_file_segments;
+ rte_thread_is_intr;
};
--
2.17.1
[dpdk-dev] [PATCH v2 3/4] common/octeontx2: add polling based response mbox message
Currently otx2_mbox_get_rsp get response once AF driver
interrupts after completion. But this funciton will get into
deadlock if called in another interrupt context.
To avoid it, implemented another version of this function which polls
on dedicated memory for a given timeout.
Also after clearing interrupt, there could UP messages available for
processing. So irq handler must check mbox messages.
Signed-off-by: Sunil Kumar Kori
---
v2:
- Included Makefile and meson build changes.
- Rebased patch on 19.11-rc4
drivers/common/octeontx2/Makefile | 2 +
drivers/common/octeontx2/meson.build | 2 +
drivers/common/octeontx2/otx2_mbox.c | 58 +++
drivers/common/octeontx2/otx2_mbox.h | 7 +++
.../rte_common_octeontx2_version.map | 7 +++
5 files changed, 76 insertions(+)
diff --git a/drivers/common/octeontx2/Makefile
b/drivers/common/octeontx2/Makefile
index eaff29433..b1c1792fb 100644
--- a/drivers/common/octeontx2/Makefile
+++ b/drivers/common/octeontx2/Makefile
@@ -22,6 +22,8 @@ CFLAGS += -diag-disable 2259
endif
endif
+CFLAGS += -DALLOW_EXPERIMENTAL_API
+
EXPORT_MAP := rte_common_octeontx2_version.map
#
diff --git a/drivers/common/octeontx2/meson.build
b/drivers/common/octeontx2/meson.build
index b79145788..a03c6a39b 100644
--- a/drivers/common/octeontx2/meson.build
+++ b/drivers/common/octeontx2/meson.build
@@ -8,6 +8,8 @@ sources= files('otx2_dev.c',
'otx2_common.c',
)
+allow_experimental_apis = true
+
extra_flags = []
# This integrated controller runs only on a arm64 machine, remove 32bit
warnings
if not dpdk_conf.get('RTE_ARCH_64')
diff --git a/drivers/common/octeontx2/otx2_mbox.c
b/drivers/common/octeontx2/otx2_mbox.c
index ad8e0c3aa..af34fd19d 100644
--- a/drivers/common/octeontx2/otx2_mbox.c
+++ b/drivers/common/octeontx2/otx2_mbox.c
@@ -11,6 +11,7 @@
#include
#include "otx2_mbox.h"
+#include "otx2_dev.h"
#define RVU_AF_AFPF_MBOX0 (0x02000)
#define RVU_AF_AFPF_MBOX1 (0x02008)
@@ -245,6 +246,63 @@ otx2_mbox_get_rsp(struct otx2_mbox *mbox, int devid, void
**msg)
return msghdr->rc;
}
+/**
+ * @internal
+ * Polling for given wait time to get mailbox response
+ */
+int
+otx2_mbox_get_rsp_poll_tmo(struct otx2_mbox *mbox, int devid, void **msg,
+ uint32_t wait)
+{
+ struct otx2_mbox_dev *mdev = &mbox->dev[devid];
+ uint32_t timeout = 0, sleep = 1;
+ struct mbox_msghdr *msghdr;
+ uint64_t rsp_reg = 0;
+ uintptr_t reg_addr;
+ uint64_t offset;
+
+ rte_rmb();
+
+ offset = mbox->rx_start +
+ RTE_ALIGN(sizeof(struct mbox_hdr), MBOX_MSG_ALIGN);
+ msghdr = (struct mbox_msghdr *)((uintptr_t)mdev->mbase + offset);
+
+ reg_addr = mbox->reg_base + mbox->intr_offset;
+ while (!rsp_reg) {
+ rte_rmb();
+ rsp_reg = otx2_read64(reg_addr);
+
+ if (timeout >= wait)
+ return -ETIMEDOUT;
+
+ rte_delay_ms(sleep);
+ timeout += sleep;
+ }
+
+ if (msg != NULL)
+ *msg = msghdr;
+
+ /* Clear interrupt */
+ otx2_write64(rsp_reg, reg_addr);
+
+ /* Reset mbox */
+ otx2_mbox_reset(mbox, 0);
+
+ return msghdr->rc;
+}
+
+/**
+ * @internal
+ * Polling for 5 seconds to get mailbox response
+ */
+int
+otx2_mbox_get_rsp_poll(struct otx2_mbox *mbox, int devid, void **msg)
+{
+ uint32_t wait = 5 * MS_PER_S; /* 5 Seconds */
+
+ return otx2_mbox_get_rsp_poll_tmo(mbox, devid, msg, wait);
+}
+
/**
* @internal
* Wait and get mailbox response with timeout
diff --git a/drivers/common/octeontx2/otx2_mbox.h
b/drivers/common/octeontx2/otx2_mbox.h
index 162d12468..237d4cf45 100644
--- a/drivers/common/octeontx2/otx2_mbox.h
+++ b/drivers/common/octeontx2/otx2_mbox.h
@@ -1570,6 +1570,13 @@ void otx2_mbox_msg_send(struct otx2_mbox *mbox, int
devid);
int otx2_mbox_wait_for_rsp(struct otx2_mbox *mbox, int devid);
int otx2_mbox_wait_for_rsp_tmo(struct otx2_mbox *mbox, int devid, uint32_t
tmo);
int otx2_mbox_get_rsp(struct otx2_mbox *mbox, int devid, void **msg);
+
+__rte_experimental
+int otx2_mbox_get_rsp_poll(struct otx2_mbox *mbox, int devid, void **msg);
+__rte_experimental
+int otx2_mbox_get_rsp_poll_tmo(struct otx2_mbox *mbox, int devid, void **msg,
+ uint32_t tmo);
+
int otx2_mbox_get_rsp_tmo(struct otx2_mbox *mbox, int devid, void **msg,
uint32_t tmo);
int otx2_mbox_get_availmem(struct otx2_mbox *mbox, int devid);
diff --git a/drivers/common/octeontx2/rte_common_octeontx2_version.map
b/drivers/common/octeontx2/rte_common_octeontx2_version.map
index adad21a2d..dcbca2444 100644
--- a/drivers/common/octeontx2/rte_common_octeontx2_version.map
+++ b/drivers/common/octeontx2/rte_common_octeontx2_version.map
@@ -33,3 +33,10 @@ DPDK_20.0 {
local: *;
};
+
+EXPERIMENTAL {
+
[dpdk-dev] [PATCH v2 4/4] drivers/octeontx2: enhancing mbox APIs to get response
Based on thread context, mbox API will get response for submitted
request. If thread runs in interrupt context then it uses polling
based get response API otherwise interrupt based.
Signed-off-by: Sunil Kumar Kori
---
v2:
- Included Makefile and meson build changes.
- Rebased patch on 19.11-rc4
drivers/common/octeontx2/otx2_dev.c | 27 ---
drivers/common/octeontx2/otx2_mbox.h | 21 +
drivers/net/octeontx2/Makefile| 2 ++
drivers/net/octeontx2/meson.build | 2 ++
drivers/raw/octeontx2_dma/Makefile| 2 ++
drivers/raw/octeontx2_dma/meson.build | 2 ++
6 files changed, 37 insertions(+), 19 deletions(-)
diff --git a/drivers/common/octeontx2/otx2_dev.c
b/drivers/common/octeontx2/otx2_dev.c
index 6f29d6108..d61c712fa 100644
--- a/drivers/common/octeontx2/otx2_dev.c
+++ b/drivers/common/octeontx2/otx2_dev.c
@@ -577,17 +577,16 @@ otx2_pf_vf_mbox_irq(void *param)
intr = otx2_read64(dev->bar2 + RVU_VF_INT);
if (intr == 0)
- return;
+ otx2_base_dbg("Proceeding to check mbox UP messages if any");
otx2_write64(intr, dev->bar2 + RVU_VF_INT);
otx2_base_dbg("Irq 0x%" PRIx64 "(pf:%d,vf:%d)", intr, dev->pf, dev->vf);
- if (intr) {
- /* First process all configuration messages */
- otx2_process_msgs(dev, dev->mbox);
- /* Process Uplink messages */
- otx2_process_msgs_up(dev, &dev->mbox_up);
- }
+ /* First process all configuration messages */
+ otx2_process_msgs(dev, dev->mbox);
+
+ /* Process Uplink messages */
+ otx2_process_msgs_up(dev, &dev->mbox_up);
}
static void
@@ -598,18 +597,16 @@ otx2_af_pf_mbox_irq(void *param)
intr = otx2_read64(dev->bar2 + RVU_PF_INT);
if (intr == 0)
- return;
+ otx2_base_dbg("Proceeding to check mbox UP messages if any");
otx2_write64(intr, dev->bar2 + RVU_PF_INT);
-
otx2_base_dbg("Irq 0x%" PRIx64 "(pf:%d,vf:%d)", intr, dev->pf, dev->vf);
- if (intr) {
- /* First process all configuration messages */
- otx2_process_msgs(dev, dev->mbox);
- /* Process Uplink messages */
- otx2_process_msgs_up(dev, &dev->mbox_up);
- }
+ /* First process all configuration messages */
+ otx2_process_msgs(dev, dev->mbox);
+
+ /* Process Uplink messages */
+ otx2_process_msgs_up(dev, &dev->mbox_up);
}
static int
diff --git a/drivers/common/octeontx2/otx2_mbox.h
b/drivers/common/octeontx2/otx2_mbox.h
index 237d4cf45..e82dfe530 100644
--- a/drivers/common/octeontx2/otx2_mbox.h
+++ b/drivers/common/octeontx2/otx2_mbox.h
@@ -9,6 +9,7 @@
#include
#include
+#include
#include
#include
@@ -1627,28 +1628,40 @@ static inline int
otx2_mbox_process(struct otx2_mbox *mbox)
{
otx2_mbox_msg_send(mbox, 0);
- return otx2_mbox_get_rsp(mbox, 0, NULL);
+ if (rte_thread_is_intr())
+ return otx2_mbox_get_rsp_poll(mbox, 0, NULL);
+ else
+ return otx2_mbox_get_rsp(mbox, 0, NULL);
}
static inline int
otx2_mbox_process_msg(struct otx2_mbox *mbox, void **msg)
{
otx2_mbox_msg_send(mbox, 0);
- return otx2_mbox_get_rsp(mbox, 0, msg);
+ if (rte_thread_is_intr())
+ return otx2_mbox_get_rsp_poll(mbox, 0, msg);
+ else
+ return otx2_mbox_get_rsp(mbox, 0, msg);
}
static inline int
otx2_mbox_process_tmo(struct otx2_mbox *mbox, uint32_t tmo)
{
otx2_mbox_msg_send(mbox, 0);
- return otx2_mbox_get_rsp_tmo(mbox, 0, NULL, tmo);
+ if (rte_thread_is_intr())
+ return otx2_mbox_get_rsp_poll_tmo(mbox, 0, NULL, tmo);
+ else
+ return otx2_mbox_get_rsp_tmo(mbox, 0, NULL, tmo);
}
static inline int
otx2_mbox_process_msg_tmo(struct otx2_mbox *mbox, void **msg, uint32_t tmo)
{
otx2_mbox_msg_send(mbox, 0);
- return otx2_mbox_get_rsp_tmo(mbox, 0, msg, tmo);
+ if (rte_thread_is_intr())
+ return otx2_mbox_get_rsp_poll_tmo(mbox, 0, msg, tmo);
+ else
+ return otx2_mbox_get_rsp_tmo(mbox, 0, msg, tmo);
}
int otx2_send_ready_msg(struct otx2_mbox *mbox, uint16_t *pf_func /* out */);
diff --git a/drivers/net/octeontx2/Makefile b/drivers/net/octeontx2/Makefile
index 68f5765db..3da4d8cc1 100644
--- a/drivers/net/octeontx2/Makefile
+++ b/drivers/net/octeontx2/Makefile
@@ -26,6 +26,8 @@ CFLAGS += -diag-disable 2259
endif
endif
+CFLAGS += -DALLOW_EXPERIMENTAL_API
+
EXPORT_MAP := rte_pmd_octeontx2_version.map
#
diff --git a/drivers/net/octeontx2/meson.build
b/drivers/net/octeontx2/meson.build
index fad3076a3..a976a2c19 100644
--- a/drivers/net/octeontx2/meson.build
+++ b/drivers/net/octeontx2/meson.build
@@ -24,6 +24,8 @@ sources = files('otx2_rx.c',
'otx2_ethdev_devargs.c'
)
+allow_experimental_apis = tru
Re: [dpdk-dev] [PATCH v7 1/1] fbarray: fix duplicated fbarray file in secondary
On 26-Nov-19 7:40 PM, Yasufumi Ogawa wrote:
Hi David,
Sorry for slow reply.
On 2019/11/14 21:27, David Marchand wrote:
On Thu, Nov 14, 2019 at 12:42 PM Yasufumi Ogawa
wrote:
On 2019/11/14 2:01, Burakov, Anatoly wrote:
On 13-Nov-19 9:43 PM, yasufu...@gmail.com wrote:
From: Yasufumi Ogawa
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 several secondaries run as app containers because
each
of containerized secondary has PID 1, and failed to reserve unique
name
other than first one. To reserve unique name in each of containers,
use
hostname in addition to PID.
Cc: sta...@dpdk.org
Signed-off-by: Yasufumi Ogawa
---
lib/librte_eal/linux/eal/eal_memalloc.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/lib/librte_eal/linux/eal/eal_memalloc.c
b/lib/librte_eal/linux/eal/eal_memalloc.c
index af6d0d023..11de6d4d6 100644
--- a/lib/librte_eal/linux/eal/eal_memalloc.c
+++ b/lib/librte_eal/linux/eal/eal_memalloc.c
@@ -1365,6 +1365,12 @@ secondary_msl_create_walk(const struct
rte_memseg_list *msl,
struct rte_memseg_list *primary_msl, *local_msl;
char name[PATH_MAX];
int msl_idx, ret;
+ char hostname[HOST_NAME_MAX+1] = { 0 };
+ /* filename of secondary's fbarray is defined such as
+ * "fbarray_memseg-1048576k-0-0_PID_HOSTNAME" and length of PID
+ * can be 7 digits maximumly.
+ */
+ int fbarray_sec_name_len = 32 + 7 + 1 + HOST_NAME_MAX + 1;
What does 32 stand for? Maybe #define both 32 and 7 values?
Hi Anatoly,
Thank you for your comments! If my understanding is correct, the prefix
"fbarray_memseg-1048576k-0-0_" is 28 digits and it could be larger if
using the size of hugepage or the number of NUMA nodes are larger
possibly. However, I think 32 digits is still enough.
> Maybe #define both 32 and 7 values?
Yes. I think it should be better to use #define if this values are
referred several times.
We can truncate to RTE_FBARRAY_NAME_LEN in all cases.
And iiuc, rte_fbarray_init will refuse any longer name anyway.
Could I confirm the issue? I've understood that it is failed to validate
the name of fbarray in fully_validate() at
"lib/librte_eal/common/eal_common_fbarray.c:697".
static int
fully_validate(const char *name, unsigned int elt_sz, unsigned int len)
{
if (name == NULL || elt_sz == 0 || len == 0 || len > INT_MAX) {
rte_errno = EINVAL;
return -1;
}
if (strnlen(name, RTE_FBARRAY_NAME_LEN) == RTE_FBARRAY_NAME_LEN) {
rte_errno = ENAMETOOLONG;
return -1;
}
return 0;
}
I should overwrite the definition of RTE_FBARRAY_NAME_LEN as previous
patch in this case, and it causes an ABI breakage, right? If so, I would
like to make the change and give up to update stable release.
Thanks,
Yasufumi
It seems we're getting into bikeshedding...
We can do this without ABI breakage. You could have just used
RTE_FBARRAY_NAME_LEN as max fbarray name length for fbarray_sec_name_len
(i.e. that would include hostname + pid + whatever else there is). The
name, as David has pointed out, would be truncated to
RTE_FBARRAY_NAME_LEN anyway (or, more precisely, it will be refused if
it's longer than that), so this is the most you can have - so you can
just use that as the maximum.
--
Thanks,
Anatoly
Re: [dpdk-dev] [PATCH 1/2] mk: fix unsupported flag error on armhf architercture
27/11/2019 11:00, Phil Yang (Arm Technology China):
> > -Original Message-
> > From: Bruce Richardson
> > Sent: Wednesday, November 27, 2019 5:30 PM
> > To: Phil Yang (Arm Technology China)
> > Cc: tho...@monjalon.net; dev@dpdk.org; david.march...@redhat.com;
> > jer...@marvell.com; Honnappa Nagarahalli
> > ; Gavin Hu (Arm Technology China)
> > ; Joyce Kong (Arm Technology China)
> > ; nd ; sta...@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 1/2] mk: fix unsupported flag error on armhf
> > architercture
> >
> > On Wed, Nov 27, 2019 at 08:09:22AM +, Phil Yang (Arm Technology China)
> > wrote:
> > > > -Original Message-
> > > > From: Thomas Monjalon
> > > > Sent: Wednesday, November 27, 2019 1:02 AM
> > > > To: Phil Yang (Arm Technology China)
> > > > Cc: dev@dpdk.org; Bruce Richardson ;
> > > > david.march...@redhat.com; jer...@marvell.com; Honnappa
> > Nagarahalli
> > > > ; Gavin Hu (Arm Technology China)
> > > > ; Joyce Kong (Arm Technology China)
> > > > ; nd ; sta...@dpdk.org
> > > > Subject: Re: [dpdk-dev] [PATCH 1/2] mk: fix unsupported flag error on
> > armhf
> > > > architercture
> > > >
> > > > 12/11/2019 07:40, Phil Yang (Arm Technology China):
> > > > > > -Original Message-
> > > > > > From: Thomas Monjalon
> > > > > > Sent: Tuesday, November 12, 2019 2:03 PM
> > > > > > To: Phil Yang (Arm Technology China)
> > > > > > Cc: Bruce Richardson ; dev@dpdk.org;
> > > > > > david.march...@redhat.com; jer...@marvell.com; Honnappa
> > > > Nagarahalli
> > > > > > ; Gavin Hu (Arm Technology China)
> > > > > > ; Joyce Kong (Arm Technology China)
> > > > > > ; nd ; sta...@dpdk.org
> > > > > > Subject: Re: [dpdk-dev] [PATCH 1/2] mk: fix unsupported flag error
> > on
> > > > armhf
> > > > > > architercture
> > > > > >
> > > > > > 12/11/2019 06:25, Phil Yang (Arm Technology China):
> > > > > > > From: Bruce Richardson
> > > > > > > > On Mon, Nov 11, 2019 at 06:34:20PM +0800, Phil Yang wrote:
> > > > > > > > > The older version (e.g. version 7.4.0 ) of GNU C compiler for
> > > > > > > > > the
> > > > armhf
> > > > > > > > > architecture doesn't support the flag '-Wno-address-of-packed-
> > > > > > member',
> > > > > > > > > so remove this flag for aarch32.
> > > > > > > > >
> > > > > > > > > Fixes: a385972c3675 ("mk: disable warning for packed member
> > > > pointer")
> > > > > > > > > Cc: sta...@dpdk.org
> > > > > > > > >
> > > > > > > > > Signed-off-by: Phil Yang
> > > > > > > > > Reviewed-by: Gavin Hu
> > > > > > > > > Tested-by: Joyce Kong
> > > > > > > > >
> > > > > > > > > ---
> > > > > > > > > mk/toolchain/gcc/rte.vars.mk | 2 ++
> > > > > > > > > 1 file changed, 2 insertions(+)
> > > > > > > > >
> > > > > > > > > diff --git a/mk/toolchain/gcc/rte.vars.mk
> > > > > > b/mk/toolchain/gcc/rte.vars.mk
> > > > > > > > > index 9fc7041..ec0cbbf 100644
> > > > > > > > > --- a/mk/toolchain/gcc/rte.vars.mk
> > > > > > > > > +++ b/mk/toolchain/gcc/rte.vars.mk
> > > > > > > > > @@ -100,7 +100,9 @@ WERROR_FLAGS += -Wno-format-
> > truncation
> > > > > > > > > endif
> > > > > > > > >
> > > > > > > > > # disable packed member unalign warnings
> > > > > > > > > +ifneq ($(CONFIG_RTE_ARCH_ARM), y)
> > > > > > > > > WERROR_FLAGS += -Wno-address-of-packed-member
> > > > > > > > > +endif
> > > > > > > > >
> > > > > > > > You don't need to do this, as gcc will not complain about this
> > unknown
> > > > > > flag
> > > > > > > > unless you have other issues in your code.[1] I think it's
> > > > > > > > better to
> > > > keep
> > > > > > the
> > > > > > > > code clean in this case, otherwise we'll have the code littered
> > > > > > > > with
> > > > > > > > conditionals for various flags.
> > > > > > > >
> > > > > > > > /Bruce
> > > > > > > >
> > > > > > > > [1] https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
> > > > > > > > "When an unrecognized warning option is requested (e.g.,
> > > > > > > > -Wunknown-warning), GCC emits a diagnostic stating that the
> > option
> > > > is
> > > > > > not
> > > > > > > > recognized. However, if the -Wno- form is used, the behavior is
> > > > slightly
> > > > > > > > different: no diagnostic is produced for -Wno-unknown-warning
> > > > unless
> > > > > > other
> > > > > > > > diagnostics are being produced. This allows the use of new -Wno-
> > > > options
> > > > > > > > with old compilers, but if something goes wrong, the compiler
> > warns
> > > > that
> > > > > > an
> > > > > > > > unrecognized option is present."
> > > > > > >
> > > > > > > Thanks, Bruce.
> > > > > > >
> > > > > > > There are thousands of warnings with alignment when compiling for
> > > > > > ARMv7 (ARMv7 supports unaligned memory access).
> > > > > > > Without this new flag, the build system works fine for ARMv7. So
> > > > > > > I
> > add
> > > > this
> > > > > > conditional for ARMv7 only.
> > > > > > > I agree with you we should clean up the code, but it needs a lot
> > > > > > > of
> > > > effort to
> > > > > > achieve that.
> > > > > > > This patch is going to ma
[dpdk-dev] [PATCH] doc: add tested Marvell integrated NIC platforms
From: Jerin Jacob Add tested Marvell integrated NIC platforms to v19.11 release note. Signed-off-by: Jerin Jacob --- doc/guides/rel_notes/release_19_11.rst | 14 ++ 1 file changed, 14 insertions(+) diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst index 7ad0ee800..35d70d865 100644 --- a/doc/guides/rel_notes/release_19_11.rst +++ b/doc/guides/rel_notes/release_19_11.rst @@ -642,3 +642,17 @@ Tested Platforms Also, make sure to start the actual text at the margin. = +* ARMv8 SoC combinations from Marvell (with integrated NICs) + + * SoC: + + * CN83xx, CN96xx, CN93xx + + * OS (Based on Marvell OCTEON TX SDK-10.1.2.0): + + * Arch Linux + * Buildroot 2018.11 + * Ubuntu 16.04.1 LTS + * Ubuntu 16.10 + * Ubuntu 18.04.1 + * Ubuntu 19.04 -- 2.24.0
Re: [dpdk-dev] [PATCH] examples/tep_termination: resolve unchecked return value
Hi
The patch is fine. But please polish the commit log first.
You can use expression like "This patch checked the return value of
rte_eth_dev_info_get function."
Best Regards,
Xiaoyun Li
> -Original Message-
> From: T D, Shashank
> Sent: Wednesday, November 27, 2019 10:34
> To: dev@dpdk.org
> Cc: Li, Xiaoyun
> Subject: [PATCH] examples/tep_termination: resolve unchecked return value
>
> resolve the unchecked return value from the function rte_eth_dev_info_get.
> Coverity issue: 349922
>
> Signed-off-by: Shashank T D
> ---
> examples/tep_termination/vxlan_setup.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/examples/tep_termination/vxlan_setup.c
> b/examples/tep_termination/vxlan_setup.c
> index eca119a72..384b3167e 100644
> --- a/examples/tep_termination/vxlan_setup.c
> +++ b/examples/tep_termination/vxlan_setup.c
> @@ -195,7 +195,12 @@ vxlan_port_init(uint16_t port, struct rte_mempool
> *mbuf_pool)
>
> if (tso_segsz != 0) {
> struct rte_eth_dev_info dev_info;
> - rte_eth_dev_info_get(port, &dev_info);
> + retval = rte_eth_dev_info_get(port, &dev_info);
> + if (retval != 0)
> + rte_exit(EXIT_FAILURE,
> +
> "Error during getting device (port %u) info: %s\n",
> + port, strerror(-retval));
> +
> if ((dev_info.tx_offload_capa & DEV_TX_OFFLOAD_TCP_TSO)
> == 0)
> RTE_LOG(WARNING, PORT,
> "hardware TSO offload is not supported\n");
> --
> 2.17.1
[dpdk-dev] [PATCH] event/octeontx: handle partial receive packets
From: Pavan Nikhilesh
When net/octeontx is connected to event/octeontx as an event Rx adapter,
PKI aka 'net/octeontx' can forward packets directly to SSO aka
'event/octeontx'.
When pumping traffic to PKI if flow control is disabled internal FIFOs
might be overrun causing partial l2 packets to be enqueued.
SSO receives <31:0> TAG tag calculated by PKI, in normal cases <31:28>
is always 0 which signifies RTE_EVENT_TYPE_ETHDEV. But in case of
partial received packets PKI sets the <31:0> TAG as 0x which
is an invalid event type.
Add a check to see if TAG is 0x and free the partial receive
packet.
Signed-off-by: Pavan Nikhilesh
---
drivers/event/octeontx/ssovf_worker.h| 17 +++--
drivers/net/octeontx/base/octeontx_pki_var.h | 2 +-
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/event/octeontx/ssovf_worker.h
b/drivers/event/octeontx/ssovf_worker.h
index d1d3a52ae..9c715d389 100644
--- a/drivers/event/octeontx/ssovf_worker.h
+++ b/drivers/event/octeontx/ssovf_worker.h
@@ -30,8 +30,7 @@ ssovf_octeontx_wqe_to_pkt(uint64_t work, uint16_t port_info)
octtx_wqe_t *wqe = (octtx_wqe_t *)(uintptr_t)work;
/* Get mbuf from wqe */
- mbuf = (struct rte_mbuf *)((uintptr_t)wqe -
- OCTTX_PACKET_WQE_SKIP);
+ mbuf = (struct rte_mbuf *)((uintptr_t)wqe - OCTTX_PACKET_WQE_SKIP);
rte_prefetch_non_temporal(mbuf);
mbuf->packet_type =
ptype_table[wqe->s.w2.lcty][wqe->s.w2.lety][wqe->s.w2.lfty];
@@ -46,6 +45,16 @@ ssovf_octeontx_wqe_to_pkt(uint64_t work, uint16_t port_info)
return mbuf;
}
+static __rte_always_inline void
+ssovf_octeontx_wqe_free(uint64_t work)
+{
+ octtx_wqe_t *wqe = (octtx_wqe_t *)(uintptr_t)work;
+ struct rte_mbuf *mbuf;
+
+ mbuf = (struct rte_mbuf *)((uintptr_t)wqe - OCTTX_PACKET_WQE_SKIP);
+ rte_pktmbuf_free(mbuf);
+}
+
static __rte_always_inline uint16_t
ssows_get_work(struct ssows *ws, struct rte_event *ev)
{
@@ -59,9 +68,13 @@ ssows_get_work(struct ssows *ws, struct rte_event *ev)
ws->cur_grp = sched_type_queue >> 2;
sched_type_queue = sched_type_queue << 38;
ev->event = sched_type_queue | (get_work0 & 0x);
+
if (get_work1 && ev->event_type == RTE_EVENT_TYPE_ETHDEV) {
ev->mbuf = ssovf_octeontx_wqe_to_pkt(get_work1,
(ev->event >> 20) & 0x7F);
+ } else if ((get_work0 & 0x) == 0x) {
+ ssovf_octeontx_wqe_free(get_work1);
+ return 0;
} else {
ev->u64 = get_work1;
}
diff --git a/drivers/net/octeontx/base/octeontx_pki_var.h
b/drivers/net/octeontx/base/octeontx_pki_var.h
index f4661d24e..2ef98964b 100644
--- a/drivers/net/octeontx/base/octeontx_pki_var.h
+++ b/drivers/net/octeontx/base/octeontx_pki_var.h
@@ -139,7 +139,7 @@ typedef union octtx_wqe_s {
uint64_tl2b : 1;
uint64_tl2m : 1;
uint64_traw : 1;
- uint64_terr_lev : 3;
+ uint64_terr_lev : 3;
uint64_top_code : 8;
} w2;
--
2.17.1
[dpdk-dev] [PATCH] maintainers: update maintainers for nfp PMD
As Alejandro is no longer with Netronome we appointed two new maintainers for the Netronome PMD Signed-off-by: Heinrich Kuhn --- MAINTAINERS | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 4a0c9a47e..6bac90c25 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -774,7 +774,8 @@ F: doc/guides/nics/nfb.rst F: doc/guides/nics/features/nfb.ini Netronome nfp -M: Alejandro Lucero +M: Heinrich Kuhn +M: Jan Gutter F: drivers/net/nfp/ F: doc/guides/nics/nfp.rst F: doc/guides/nics/features/nfp*.ini -- 2.17.1
Re: [dpdk-dev] [PATCH v3] hash: added a new API to hash to query key id
> -Original Message-
> From: Aaron Conole
> Sent: Tuesday, November 26, 2019 1:57 PM
> To: Van Haaren, Harry
> Cc: Thomas Monjalon ; Amber, Kumar
> ; dev@dpdk.org; Wang, Yipeng1
> ; Yigit, Ferruh ; Thakur,
> Sham Singh ; David Marchand
>
> Subject: Re: [dpdk-dev] [PATCH v3] hash: added a new API to hash to query
> key id
>
> "Van Haaren, Harry" writes:
>
> >> -Original Message-
> >> From: Van Haaren, Harry
> >> Sent: Tuesday, November 26, 2019 1:19 PM
> >> To: Aaron Conole ; Thomas Monjalon
>
> >
> >
> >
> >> > EAL: Test assert service_lcore_en_dis_able line 487 failed: Ex-service
> >> core
> >> > function call had no effect.
> >> >
> >> > So I'll spend some time in this area, it seems.
> >>
> >>
> >> The below diff makes it 100% reproducible here, failing every time.
> >>
> >> It seems like the main thread is returning, before the service thread has
> >> returned.
> >>
> >> The rte_eal_mp_wait_lcore() call seems to not wait on the service-core,
> >> which allows
> >> the main thread to read the "service_remote_launch_flag" value as 0
> (before
> >> the service-thread writes it to 1).
> >>
> >> Adding the delay between the service launch and service write being
> >> performed makes this issue much much more likely to occur - so the above
> >> description I have confidence in.
> >>
> >> What I'm not clear on (yet) is why the eal_mp_wait_lcore() isn't
> waiting...
> >>
> >> -H
> >>
> >>
> >> diff --git a/app/test/test_service_cores.c
> b/app/test/test_service_cores.c
> >> index 9fe38f5e0..846ad00d1 100644
> >> --- a/app/test/test_service_cores.c
> >> +++ b/app/test/test_service_cores.c
> >> @@ -445,6 +445,7 @@ static int
> >> service_remote_launch_func(void *arg)
> >> {
> >> RTE_SET_USED(arg);
> >> + rte_delay_ms(100);
> >> service_remote_launch_flag = 1;
> >> return 0;
> >> }
> >
> > Diff below seems to fix the problem here; Aaron would you test the below
> fix in your setup for a while too?
> > I have a loop running here attempting to reproduce - but before 100%
> failures and so far 100% passes with the added wait_lcore() call.
> >
> >
> > diff --git a/app/test/test_service_cores.c b/app/test/test_service_cores.c
> > index 9fe38f5e0..62ffedb19 100644
> > --- a/app/test/test_service_cores.c
> > +++ b/app/test/test_service_cores.c
> > @@ -445,6 +445,7 @@ static int
> > service_remote_launch_func(void *arg)
> > {
> > RTE_SET_USED(arg);
> > + rte_delay_ms(100);
> > service_remote_launch_flag = 1;
> > return 0;
> > }
> > @@ -483,6 +484,7 @@ service_lcore_en_dis_able(void)
> > int ret = rte_eal_remote_launch(service_remote_launch_func, NULL,
> > slcore_id);
> > TEST_ASSERT_EQUAL(0, ret, "Ex-service core remote launch
> failed.");
> > + rte_eal_wait_lcore(slcore_id);
> > rte_eal_mp_wait_lcore();
>
> Ahh, I see. Actually, this brings up a question - is the intent for
> mp_wait_lcore to cycle through the service cores as well? Because IIUC,
> the issue will be the lcore will be set to ROLE_RTE normally, but
> service cores will do: ROLE_SERVICE and then the wait cannot work.
>
> If the idea is that mp_wait_lcore should work (and looking at the test,
> it seems like it is the intent?) then it will need to cycle through
> service cores, too. If the intent is that it shouldn't, then we should
> remove those calls from the test application to prevent developer from
> misunderstanding.
>
> Either way, the documentation for `rte_service_lcore_start` is a bit too
> ambiguous and needs to reflect whether the mp_wait_lcore should work. I
> think either it should (which means updating rte_get_next_lcore to
> include ROLE_SERVICE), or none of the lcore functions should work, and
> we should have an rte_service...() equivalent that should be used.
Service cores are meant to be transparent to the application.
The test application testing this particular usage is the corner-case.
The rte_eal_mp_wait_lcore() is correct to NOT wait for service-cores,
as they are not always under application control.
The observed test failure is a bug in the test code, it should use the explicit
rte_eal_wait_lcore() call. I'll send a patch later today.
Re: [dpdk-dev] [PATCH] event/octeontx: handle partial receive packets
On Wed, Nov 27, 2019 at 8:05 PM wrote:
>
> From: Pavan Nikhilesh
>
> When net/octeontx is connected to event/octeontx as an event Rx adapter,
> PKI aka 'net/octeontx' can forward packets directly to SSO aka
> 'event/octeontx'.
> When pumping traffic to PKI if flow control is disabled internal FIFOs
> might be overrun causing partial l2 packets to be enqueued.
> SSO receives <31:0> TAG tag calculated by PKI, in normal cases <31:28>
> is always 0 which signifies RTE_EVENT_TYPE_ETHDEV. But in case of
> partial received packets PKI sets the <31:0> TAG as 0x which
> is an invalid event type.
>
> Add a check to see if TAG is 0x and free the partial receive
> packet.
>
> Signed-off-by: Pavan Nikhilesh
# Could you add Fixes:
# Change the subject to "net/octeontx: fix partial Rx packet handling"
# Cc stable
# Fix the following check-git-log
Wrong headline prefix:
event/octeontx: handle partial receive packets
Please see inline
> ---
> drivers/event/octeontx/ssovf_worker.h| 17 +++--
> drivers/net/octeontx/base/octeontx_pki_var.h | 2 +-
> 2 files changed, 16 insertions(+), 3 deletions(-)
>
> ssows_get_work(struct ssows *ws, struct rte_event *ev)
> {
> @@ -59,9 +68,13 @@ ssows_get_work(struct ssows *ws, struct rte_event *ev)
> ws->cur_grp = sched_type_queue >> 2;
> sched_type_queue = sched_type_queue << 38;
> ev->event = sched_type_queue | (get_work0 & 0x);
> +
> if (get_work1 && ev->event_type == RTE_EVENT_TYPE_ETHDEV) {
> ev->mbuf = ssovf_octeontx_wqe_to_pkt(get_work1,
> (ev->event >> 20) & 0x7F);
> + } else if ((get_work0 & 0x) == 0x) {
Can we make it as unlikely()?
Re: [dpdk-dev] [EXT] Re: [PATCH] event/octeontx: handle partial receive packets
>-Original Message-
>From: Jerin Jacob
>Sent: Wednesday, November 27, 2019 5:14 PM
>To: Pavan Nikhilesh Bhagavatula
>Cc: Jerin Jacob Kollanukkaran ; dpdk-dev
>
>Subject: [EXT] Re: [dpdk-dev] [PATCH] event/octeontx: handle partial
>receive packets
>
>External Email
>
>--
>On Wed, Nov 27, 2019 at 8:05 PM wrote:
>>
>> From: Pavan Nikhilesh
>>
>> When net/octeontx is connected to event/octeontx as an event Rx
>adapter,
>> PKI aka 'net/octeontx' can forward packets directly to SSO aka
>> 'event/octeontx'.
>> When pumping traffic to PKI if flow control is disabled internal FIFOs
>> might be overrun causing partial l2 packets to be enqueued.
>> SSO receives <31:0> TAG tag calculated by PKI, in normal cases
><31:28>
>> is always 0 which signifies RTE_EVENT_TYPE_ETHDEV. But in case of
>> partial received packets PKI sets the <31:0> TAG as 0x which
>> is an invalid event type.
>>
>> Add a check to see if TAG is 0x and free the partial receive
>> packet.
>>
>> Signed-off-by: Pavan Nikhilesh
>
># Could you add Fixes:
># Change the subject to "net/octeontx: fix partial Rx packet handling"
># Cc stable
># Fix the following check-git-log
>
>Wrong headline prefix:
>event/octeontx: handle partial receive packets
>
Will send v2 with updated git log
>Please see inline
>
>> ---
>> drivers/event/octeontx/ssovf_worker.h| 17 +++-
>-
>> drivers/net/octeontx/base/octeontx_pki_var.h | 2 +-
>> 2 files changed, 16 insertions(+), 3 deletions(-)
>>
>
>> ssows_get_work(struct ssows *ws, struct rte_event *ev)
>> {
>> @@ -59,9 +68,13 @@ ssows_get_work(struct ssows *ws, struct
>rte_event *ev)
>> ws->cur_grp = sched_type_queue >> 2;
>> sched_type_queue = sched_type_queue << 38;
>> ev->event = sched_type_queue | (get_work0 & 0x);
>> +
>> if (get_work1 && ev->event_type == RTE_EVENT_TYPE_ETHDEV)
>{
>> ev->mbuf = ssovf_octeontx_wqe_to_pkt(get_work1,
>> (ev->event >> 20) & 0x7F);
>> + } else if ((get_work0 & 0x) == 0x) {
>
>Can we make it as unlikely()?
Since it's error case I Will add in v2.
Re: [dpdk-dev] [PATCH v2 4/8] doc: remove reference to old versions of FreeBSD
On 25-Nov-19 2:55 PM, Bruce Richardson wrote: FreeBSD 10 is now EOL and all testing with DPDK takes place on BSD versions 11 and 12, so we can just remove the note. The BSD ports are supported on all non-EOL versions of BSD. Signed-off-by: Bruce Richardson --- Acked-by: Anatoly Burakov -- Thanks, Anatoly
Re: [dpdk-dev] [PATCH v2 5/8] doc: update examples output in FreeBSD GSG
On 25-Nov-19 2:55 PM, Bruce Richardson wrote: The output of running the helloworld example on FreeBSD was a little out-of-date and can be shortened by using the latest version of DPDK. Update appropriately. Signed-off-by: Bruce Richardson --- doc/guides/freebsd_gsg/install_from_ports.rst | 56 --- 1 file changed, 22 insertions(+), 34 deletions(-) diff --git a/doc/guides/freebsd_gsg/install_from_ports.rst b/doc/guides/freebsd_gsg/install_from_ports.rst index 4b0447584..29f16cc6c 100644 --- a/doc/guides/freebsd_gsg/install_from_ports.rst +++ b/doc/guides/freebsd_gsg/install_from_ports.rst @@ -84,48 +84,36 @@ compiled and run as below: INSTALL-APP helloworld INSTALL-MAP helloworld.map -sudo ./build/helloworld -l 0-3 -n 2 - -EAL: Contigmem driver has 2 buffers, each of size 1GB +sudo ./build//helloworld -l 0-3 EAL: Sysctl reports 8 cpus -EAL: Detected lcore 0 -EAL: Detected lcore 1 -EAL: Detected lcore 2 -EAL: Detected lcore 3 -EAL: Support maximum 64 logical core(s) by configuration. -EAL: Detected 4 lcore(s) -EAL: Setting up physically contiguous memory... -EAL: Mapped memory segment 1 @ 0x80240: len 1073741824 -EAL: Mapped memory segment 2 @ 0x84240: len 1073741824 -EAL: WARNING: clock_gettime cannot use CLOCK_MONOTONIC_RAW and HPET - is not available - clock timings may be less accurate. -EAL: TSC frequency is ~3569023 KHz -EAL: PCI scan found 24 devices -EAL: Master core 0 is ready (tid=0x802006400) -EAL: Core 1 is ready (tid=0x802006800) -EAL: Core 3 is ready (tid=0x802007000) -EAL: Core 2 is ready (tid=0x802006c00) +EAL: Detected 8 lcore(s) +EAL: Detected 1 NUMA nodes +EAL: Multi-process socket /var/run/dpdk/rte/mp_socket +EAL: Selected IOVA mode 'PA' +EAL: Contigmem driver has 2 buffers, each of size 1GB +EAL: Mapped memory segment 0 @ 0x104000: physaddr:0x18000, len 1073741824 +EAL: Mapped memory segment 1 @ 0x108000: physaddr:0x1c000, len 1073741824 +EAL: PCI device :00:19.0 on NUMA socket 0 +EAL: probe driver: 8086:153b net_e1000_em +EAL: :00:19.0 not managed by UIO driver, skipping EAL: PCI device :01:00.0 on NUMA socket 0 -EAL: probe driver: 8086:10fb rte_ixgbe_pmd -EAL: PCI memory mapped at 0x80074a000 -EAL: PCI memory mapped at 0x8007ca000 +EAL: probe driver: 8086:1572 net_i40e +EAL: :01:00.0 not managed by UIO driver, skipping EAL: PCI device :01:00.1 on NUMA socket 0 -EAL: probe driver: 8086:10fb rte_ixgbe_pmd -EAL: PCI memory mapped at 0x8007ce000 -EAL: PCI memory mapped at 0x80084e000 -EAL: PCI device :02:00.0 on NUMA socket 0 -EAL: probe driver: 8086:10fb rte_ixgbe_pmd -EAL: PCI memory mapped at 0x800852000 -EAL: PCI memory mapped at 0x8008d2000 -EAL: PCI device :02:00.1 on NUMA socket 0 -EAL: probe driver: 8086:10fb rte_ixgbe_pmd -EAL: PCI memory mapped at 0x801b3f000 -EAL: PCI memory mapped at 0x8008d6000 +EAL: probe driver: 8086:1572 net_i40e +EAL: :01:00.1 not managed by UIO driver, skipping +EAL: PCI device :01:00.2 on NUMA socket 0 +EAL: probe driver: 8086:1572 net_i40e +EAL: :01:00.2 not managed by UIO driver, skipping +EAL: PCI device :01:00.3 on NUMA socket 0 +EAL: probe driver: 8086:1572 net_i40e +EAL: :01:00.3 not managed by UIO driver, skipping hello from core 1 hello from core 2 hello from core 3 hello from core 0 + .. note:: Accidental whitespace? To run a DPDK process as a non-root user, adjust the permissions on Acked-by: Anatoly Burakov -- Thanks, Anatoly
Re: [dpdk-dev] [PATCH v2 6/8] doc: add meson install instructions for FreeBSD
On 25-Nov-19 2:55 PM, Bruce Richardson wrote: Update the FreeBSD GSG doc with instructions for installing using meson and ninja rather than make. Signed-off-by: Bruce Richardson --- Acked-by: Anatoly Burakov -- Thanks, Anatoly
Re: [dpdk-dev] [PATCH v2 5/8] doc: update examples output in FreeBSD GSG
On Wed, Nov 27, 2019 at 12:11:41PM +, Burakov, Anatoly wrote: > On 25-Nov-19 2:55 PM, Bruce Richardson wrote: > > The output of running the helloworld example on FreeBSD was a little > > out-of-date and can be shortened by using the latest version of DPDK. > > Update appropriately. > > > > Signed-off-by: Bruce Richardson > > --- > > doc/guides/freebsd_gsg/install_from_ports.rst | 56 --- > > 1 file changed, 22 insertions(+), 34 deletions(-) > > > > diff --git a/doc/guides/freebsd_gsg/install_from_ports.rst > > b/doc/guides/freebsd_gsg/install_from_ports.rst > > index 4b0447584..29f16cc6c 100644 > > --- a/doc/guides/freebsd_gsg/install_from_ports.rst > > +++ b/doc/guides/freebsd_gsg/install_from_ports.rst > > @@ -84,48 +84,36 @@ compiled and run as below: > > INSTALL-APP helloworld > > INSTALL-MAP helloworld.map > > -sudo ./build/helloworld -l 0-3 -n 2 > > - > > -EAL: Contigmem driver has 2 buffers, each of size 1GB > > +sudo ./build//helloworld -l 0-3 > > EAL: Sysctl reports 8 cpus > > -EAL: Detected lcore 0 > > -EAL: Detected lcore 1 > > -EAL: Detected lcore 2 > > -EAL: Detected lcore 3 > > -EAL: Support maximum 64 logical core(s) by configuration. > > -EAL: Detected 4 lcore(s) > > -EAL: Setting up physically contiguous memory... > > -EAL: Mapped memory segment 1 @ 0x80240: len 1073741824 > > -EAL: Mapped memory segment 2 @ 0x84240: len 1073741824 > > -EAL: WARNING: clock_gettime cannot use CLOCK_MONOTONIC_RAW and HPET > > - is not available - clock timings may be less accurate. > > -EAL: TSC frequency is ~3569023 KHz > > -EAL: PCI scan found 24 devices > > -EAL: Master core 0 is ready (tid=0x802006400) > > -EAL: Core 1 is ready (tid=0x802006800) > > -EAL: Core 3 is ready (tid=0x802007000) > > -EAL: Core 2 is ready (tid=0x802006c00) > > +EAL: Detected 8 lcore(s) > > +EAL: Detected 1 NUMA nodes > > +EAL: Multi-process socket /var/run/dpdk/rte/mp_socket > > +EAL: Selected IOVA mode 'PA' > > +EAL: Contigmem driver has 2 buffers, each of size 1GB > > +EAL: Mapped memory segment 0 @ 0x104000: physaddr:0x18000, len > > 1073741824 > > +EAL: Mapped memory segment 1 @ 0x108000: physaddr:0x1c000, len > > 1073741824 > > +EAL: PCI device :00:19.0 on NUMA socket 0 > > +EAL: probe driver: 8086:153b net_e1000_em > > +EAL: :00:19.0 not managed by UIO driver, skipping > > EAL: PCI device :01:00.0 on NUMA socket 0 > > -EAL: probe driver: 8086:10fb rte_ixgbe_pmd > > -EAL: PCI memory mapped at 0x80074a000 > > -EAL: PCI memory mapped at 0x8007ca000 > > +EAL: probe driver: 8086:1572 net_i40e > > +EAL: :01:00.0 not managed by UIO driver, skipping > > EAL: PCI device :01:00.1 on NUMA socket 0 > > -EAL: probe driver: 8086:10fb rte_ixgbe_pmd > > -EAL: PCI memory mapped at 0x8007ce000 > > -EAL: PCI memory mapped at 0x80084e000 > > -EAL: PCI device :02:00.0 on NUMA socket 0 > > -EAL: probe driver: 8086:10fb rte_ixgbe_pmd > > -EAL: PCI memory mapped at 0x800852000 > > -EAL: PCI memory mapped at 0x8008d2000 > > -EAL: PCI device :02:00.1 on NUMA socket 0 > > -EAL: probe driver: 8086:10fb rte_ixgbe_pmd > > -EAL: PCI memory mapped at 0x801b3f000 > > -EAL: PCI memory mapped at 0x8008d6000 > > +EAL: probe driver: 8086:1572 net_i40e > > +EAL: :01:00.1 not managed by UIO driver, skipping > > +EAL: PCI device :01:00.2 on NUMA socket 0 > > +EAL: probe driver: 8086:1572 net_i40e > > +EAL: :01:00.2 not managed by UIO driver, skipping > > +EAL: PCI device :01:00.3 on NUMA socket 0 > > +EAL: probe driver: 8086:1572 net_i40e > > +EAL: :01:00.3 not managed by UIO driver, skipping > > hello from core 1 > > hello from core 2 > > hello from core 3 > > hello from core 0 > > + > > .. note:: > > Accidental whitespace? > I don't think so. I think there needs to be a blank line before the note. If it is extra, I suggest it just be removed on apply. > > To run a DPDK process as a non-root user, adjust the permissions on > > > > Acked-by: Anatoly Burakov > Thanks for the review.
Re: [dpdk-dev] [PATCH v2 7/8] doc: update documentation on build and running FreeBSD apps
On 25-Nov-19 2:55 PM, Bruce Richardson wrote: Update the documentation on building and running apps on FreeBSD, taking account of having used meson for building. We can also update the section on the command-line parameters, rather than claiming to be a complete list of parameters, it should describe how to get the complete list and only cover a few important ones. Signed-off-by: Bruce Richardson --- Acked-by: Anatoly Burakov -- Thanks, Anatoly
Re: [dpdk-dev] [PATCH v2 8/8] doc: drop EAL command-line reference from FreeBSD GSG
On 25-Nov-19 2:55 PM, Bruce Richardson wrote: The EAL command-line reference section duplicated material covered in a previous chapter, was out of date, and generally is unnecessary as options are best queried directly by passing "--help" to a DPDK binary. Therefore we can drop this section to avoid having to try and keep it up-to-date in the future. Signed-off-by: Bruce Richardson --- While passing --help works, i believe the parameter guides are a little bit more detailed than what you can put in a help message, so there still is a place for those. FreeBSD doesn't have FreeBSD-specific parameters, so in this case it's probably OK to drop this particular document, but it would still be nice to refer users to the common EAL arguments guide. -- Thanks, Anatoly
[dpdk-dev] [PATCH] net/mlx5: fix legacy non-inline multi-packet performance
The legacy multi-packet write is the feature allowing to
put multiple packets into one transmitting descriptor,
this feature is supported by only NIC ConnectX-4LX.
The number of packets should be limited to provide
optimal size descriptor and better performance.
Fixes: 18a1c20044c0 ("net/mlx5: implement Tx burst template")
Signed-off-by: Viacheslav Ovsiienko
---
drivers/net/mlx5/mlx5_prm.h | 2 ++
drivers/net/mlx5/mlx5_rxtx.c | 4 +++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/mlx5/mlx5_prm.h b/drivers/net/mlx5/mlx5_prm.h
index 651006b..2bac6a7 100644
--- a/drivers/net/mlx5/mlx5_prm.h
+++ b/drivers/net/mlx5/mlx5_prm.h
@@ -99,6 +99,8 @@
* in tx burst routine at the moment of freeing multiple mbufs.
*/
#define MLX5_EMPW_MAX_PACKETS MLX5_TX_COMP_THRESH
+#define MLX5_MPW_MAX_PACKETS 6
+
/*
* Default packet length threshold to be inlined with
* ordinary SEND. Inlining saves the MR key search
diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
index 73c16de..25d915c 100644
--- a/drivers/net/mlx5/mlx5_rxtx.c
+++ b/drivers/net/mlx5/mlx5_rxtx.c
@@ -3888,7 +3888,9 @@ enum mlx5_txcmp_code {
next_empw:
assert(NB_SEGS(loc->mbuf) == 1);
- part = RTE_MIN(pkts_n, MLX5_EMPW_MAX_PACKETS);
+ part = RTE_MIN(pkts_n, MLX5_TXOFF_CONFIG(MPW) ?
+ MLX5_MPW_MAX_PACKETS :
+ MLX5_EMPW_MAX_PACKETS);
if (unlikely(loc->elts_free < part)) {
/* We have no enough elts to save all mbufs. */
if (unlikely(loc->elts_free < MLX5_EMPW_MIN_PACKETS))
--
1.8.3.1
[dpdk-dev] [PATCH v2] event/octeontx: fix partial Rx packet handling
From: Pavan Nikhilesh
When net/octeontx is connected to event/octeontx as an event Rx adapter,
PKI aka 'net/octeontx' can forward packets directly to SSO aka
'event/octeontx'.
When pumping traffic to PKI if flow control is disabled internal FIFOs
might be overrun causing partial l2 packets to be enqueued.
SSO receives <31:0> TAG tag calculated by PKI, in normal cases <31:28>
is always 0 which signifies RTE_EVENT_TYPE_ETHDEV. But in case of
partial received packets PKI sets the <31:0> TAG as 0x which
is an invalid event type.
Add a check to see if TAG is 0x and free the partial receive
packet.
Cc: sta...@dpdk.org
Fixes: d0d654986018 ("net/octeontx: support event Rx adapter")
Signed-off-by: Pavan Nikhilesh
---
drivers/event/octeontx/ssovf_worker.h | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/event/octeontx/ssovf_worker.h
b/drivers/event/octeontx/ssovf_worker.h
index d1d3a52ae..c4f886d63 100644
--- a/drivers/event/octeontx/ssovf_worker.h
+++ b/drivers/event/octeontx/ssovf_worker.h
@@ -30,8 +30,7 @@ ssovf_octeontx_wqe_to_pkt(uint64_t work, uint16_t port_info)
octtx_wqe_t *wqe = (octtx_wqe_t *)(uintptr_t)work;
/* Get mbuf from wqe */
- mbuf = (struct rte_mbuf *)((uintptr_t)wqe -
- OCTTX_PACKET_WQE_SKIP);
+ mbuf = (struct rte_mbuf *)((uintptr_t)wqe - OCTTX_PACKET_WQE_SKIP);
rte_prefetch_non_temporal(mbuf);
mbuf->packet_type =
ptype_table[wqe->s.w2.lcty][wqe->s.w2.lety][wqe->s.w2.lfty];
@@ -46,6 +45,16 @@ ssovf_octeontx_wqe_to_pkt(uint64_t work, uint16_t port_info)
return mbuf;
}
+static __rte_always_inline void
+ssovf_octeontx_wqe_free(uint64_t work)
+{
+ octtx_wqe_t *wqe = (octtx_wqe_t *)(uintptr_t)work;
+ struct rte_mbuf *mbuf;
+
+ mbuf = (struct rte_mbuf *)((uintptr_t)wqe - OCTTX_PACKET_WQE_SKIP);
+ rte_pktmbuf_free(mbuf);
+}
+
static __rte_always_inline uint16_t
ssows_get_work(struct ssows *ws, struct rte_event *ev)
{
@@ -59,9 +68,13 @@ ssows_get_work(struct ssows *ws, struct rte_event *ev)
ws->cur_grp = sched_type_queue >> 2;
sched_type_queue = sched_type_queue << 38;
ev->event = sched_type_queue | (get_work0 & 0x);
+
if (get_work1 && ev->event_type == RTE_EVENT_TYPE_ETHDEV) {
ev->mbuf = ssovf_octeontx_wqe_to_pkt(get_work1,
(ev->event >> 20) & 0x7F);
+ } else if (unlikely((get_work0 & 0x) == 0x)) {
+ ssovf_octeontx_wqe_free(get_work1);
+ return 0;
} else {
ev->u64 = get_work1;
}
--
2.17.1
Re: [dpdk-dev] [PATCH v2] vhost-blk: fix the unused return value
On 11/27/19 1:16 PM, Jin Yu wrote:
> add the assert to handle error.
>
> Coverity issue: 350592
> Fixes: c19beb3f38cd ("examples/vhost_blk: introduce vhost storage sample")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Jin Yu
> ---
> v2 - add the error hander
> ---
> examples/vhost_blk/vhost_blk.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/examples/vhost_blk/vhost_blk.c b/examples/vhost_blk/vhost_blk.c
> index 3182a488b..e1036bf3a 100644
> --- a/examples/vhost_blk/vhost_blk.c
> +++ b/examples/vhost_blk/vhost_blk.c
> @@ -856,6 +856,7 @@ new_device(int vid)
> ctrlr->bdev->vid, i,
> &blk_vq->last_avail_idx,
> &blk_vq->last_used_idx);
> + assert(ret == 0);
>
> blk_vq->avail_wrap_counter = blk_vq->last_avail_idx &
> (1 << 15);
>
Reviewed-by: Maxime Coquelin
Thanks,
Maxime
[dpdk-dev] [PATCH] net/mlx5: fix legacy inline multi-packet performance
The legacy multi-packet write is the feature allowing to
put multiple packets into one transmitting descriptor,
this feature is supported by only NIC ConnectX-4LX.
The number of packets should be limited to provide
optimal size descriptor and better performance.
Fixes: 18a1c20044c0 ("net/mlx5: implement Tx burst template")
Signed-off-by: Viacheslav Ovsiienko
---
drivers/net/mlx5/mlx5_prm.h | 1 +
drivers/net/mlx5/mlx5_rxtx.c | 4 +++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/mlx5/mlx5_prm.h b/drivers/net/mlx5/mlx5_prm.h
index 2bac6a7..a805363 100644
--- a/drivers/net/mlx5/mlx5_prm.h
+++ b/drivers/net/mlx5/mlx5_prm.h
@@ -100,6 +100,7 @@
*/
#define MLX5_EMPW_MAX_PACKETS MLX5_TX_COMP_THRESH
#define MLX5_MPW_MAX_PACKETS 6
+#define MLX5_MPW_INLINE_MAX_PACKETS 2
/*
* Default packet length threshold to be inlined with
diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
index 25d915c..acf0fd7 100644
--- a/drivers/net/mlx5/mlx5_rxtx.c
+++ b/drivers/net/mlx5/mlx5_rxtx.c
@@ -4059,7 +4059,9 @@ enum mlx5_txcmp_code {
* Limits the amount of packets in one WQE
* to improve CQE latency generation.
*/
- nlim = RTE_MIN(pkts_n, MLX5_EMPW_MAX_PACKETS);
+ nlim = RTE_MIN(pkts_n, MLX5_TXOFF_CONFIG(MPW) ?
+ MLX5_MPW_INLINE_MAX_PACKETS :
+ MLX5_EMPW_MAX_PACKETS);
/* Check whether we have minimal amount WQEs */
if (unlikely(loc->wqe_free <
((2 + MLX5_EMPW_MIN_PACKETS + 3) / 4)))
--
1.8.3.1
Re: [dpdk-dev] [PATCH v2] examples/tep_termination: resolve unchecked return value
> -Original Message-
> From: T D, Shashank
> Sent: Wednesday, November 27, 2019 12:04
> To: dev@dpdk.org
> Cc: Li, Xiaoyun
> Subject: [PATCH v2] examples/tep_termination: resolve unchecked return value
>
> This patch checked the return value of rte_eth_dev_info_get function.
> Coverity issue: 349922
>
> Signed-off-by: Shashank T D
> ---
> examples/tep_termination/vxlan_setup.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/examples/tep_termination/vxlan_setup.c
> b/examples/tep_termination/vxlan_setup.c
> index eca119a72..384b3167e 100644
> --- a/examples/tep_termination/vxlan_setup.c
> +++ b/examples/tep_termination/vxlan_setup.c
> @@ -195,7 +195,12 @@ vxlan_port_init(uint16_t port, struct rte_mempool
> *mbuf_pool)
>
> if (tso_segsz != 0) {
> struct rte_eth_dev_info dev_info;
> - rte_eth_dev_info_get(port, &dev_info);
> + retval = rte_eth_dev_info_get(port, &dev_info);
> + if (retval != 0)
> + rte_exit(EXIT_FAILURE,
> +
> "Error during getting device (port %u) info: %s\n",
> + port, strerror(-retval));
> +
> if ((dev_info.tx_offload_capa & DEV_TX_OFFLOAD_TCP_TSO)
> == 0)
> RTE_LOG(WARNING, PORT,
> "hardware TSO offload is not supported\n");
> --
> 2.17.1
Acked-by: Xiaoyun Li
[dpdk-dev] [PATCH] test/service: fix wait for service core
This commit fixes a sporadic failure of the service_autotest
unit test, as seen in the DPDK CI. The failure occurs as the main test
thread did not wait on the service-thread to return, and allowing it
to read a flag before the service was able to write to it.
The fix changes the wait API call to specific the service-core ID,
and this waits for cores with both ROLE_RTE and ROLE_SERVICE.
The rte_eal_mp_wait_lcore() call does not (and should not) wait
for service cores, so must not be used to wait on service-cores.
Fixes: f038a81e1c56 ("service: add unit tests")
Reported-by: Aaron Conole
Signed-off-by: Harry van Haaren
---
Given this is a fix in the unit test, and not a functional change
I'm not sure its worth backporting to LTS / stable releases?
I've not added stable on CC yet.
---
app/test/test_service_cores.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/app/test/test_service_cores.c b/app/test/test_service_cores.c
index 9fe38f5e0..a922c7ddc 100644
--- a/app/test/test_service_cores.c
+++ b/app/test/test_service_cores.c
@@ -483,7 +483,7 @@ service_lcore_en_dis_able(void)
int ret = rte_eal_remote_launch(service_remote_launch_func, NULL,
slcore_id);
TEST_ASSERT_EQUAL(0, ret, "Ex-service core remote launch failed.");
- rte_eal_mp_wait_lcore();
+ rte_eal_wait_lcore(slcore_id);
TEST_ASSERT_EQUAL(1, service_remote_launch_flag,
"Ex-service core function call had no effect.");
--
2.17.1
[dpdk-dev] [PATCH V3] doc: add tested Intel platforms with Intel NICs
From: Wenjie Li V3: Use symbols from isonum.txt to optimize the doc. V2: Fix some typos. V1: Add tested Intel platforms with Intel NICs to v19.11 release note. Signed-off-by: Wenjie Li --- doc/guides/rel_notes/release_19_11.rst | 99 ++ 1 file changed, 99 insertions(+) diff --git a/doc/guides/rel_notes/release_19_11.rst b/doc/guides/rel_notes/release_19_11.rst index 7ad0ee800..7e657720a 100644 --- a/doc/guides/rel_notes/release_19_11.rst +++ b/doc/guides/rel_notes/release_19_11.rst @@ -642,3 +642,102 @@ Tested Platforms Also, make sure to start the actual text at the margin. = +* Intel\ |reg| platforms with Intel\ |reg| NICs combinations + + * CPU + +* Intel\ |reg| Atom\ |trade| CPU C3758 @ 2.20GHz +* Intel\ |reg| Atom\ |trade| CPU C3858 @ 2.00GHz +* Intel\ |reg| Atom\ |trade| CPU C3958 @ 2.00GHz +* Intel\ |reg| Xeon\ |reg| CPU D-1541 @ 2.10GHz +* Intel\ |reg| Xeon\ |reg| CPU D-1553N @ 2.30GHz +* Intel\ |reg| Xeon\ |reg| CPU E5-2680 0 @ 2.70GHz +* Intel\ |reg| Xeon\ |reg| CPU E5-2680 v2 @ 2.80GHz +* Intel\ |reg| Xeon\ |reg| CPU E5-2699 v3 @ 2.30GHz +* Intel\ |reg| Xeon\ |reg| CPU E5-2699 v4 @ 2.20GHz +* Intel\ |reg| Xeon\ |reg| Gold 6139 CPU @ 2.30GHz +* Intel\ |reg| Xeon\ |reg| Gold 6252N CPU @ 2.30GHz +* Intel\ |reg| Xeon\ |reg| Platinum 8180 CPU @ 2.50GHz +* Intel\ |reg| Xeon\ |reg| Platinum 8280M CPU @ 2.70GHz + + * OS: + +* CentOS 7.6 +* Fedora 30 +* FreeBSD 12.0 +* Red Hat Enterprise Linux Server release 8.0 +* Red Hat Enterprise Linux Server release 7.6 +* Suse12SP3 +* Ubuntu 14.04 +* Ubuntu 16.04 +* Ubuntu 16.10 +* Ubuntu 18.04 +* Ubuntu 19.04 + + * NICs: + +* Intel\ |reg| Corporation Ethernet Controller E810-C for SFP (2x25G) + + * Firmware version: 1.02 0x80002084 1.2538.0/1.02 0x80002082 1.2538.0 + * Device id (pf): 8086:1593 + * Driver version: 0.12.25 (ice) + +* Intel\ |reg| Corporation Ethernet Controller E810-C for SFP (2x100G) + + * Firmware version: 1.02 0x80002081 1.2538.0 + * Device id (pf): 8086:1592 + * Driver version: 0.12.25 (ice) + +* Intel\ |reg| 82599ES 10 Gigabit Ethernet Controller + + * Firmware version: 0x61bf0001 + * Device id (pf/vf): 8086:10fb / 8086:10ed + * Driver version: 5.6.1 (ixgbe) + +* Intel\ |reg| Corporation Ethernet Connection X552/X557-AT 10GBASE-T + + * Firmware version: 0x83e7 + * Device id (pf/vf): 8086:15ad / 8086:15a8 + * Driver version: 5.1.0 (ixgbe) + +* Intel\ |reg| Corporation Ethernet Controller 10G X550T + + * Firmware version: 0x8482 + * Device id (pf): 8086:1563 + * Driver version: 5.6.1 (ixgbe) + +* Intel\ |reg| Ethernet Converged Network Adapter X710-DA4 (4x10G) + + * Firmware version: 7.00 0x80004cdb + * Device id (pf/vf): 8086:1572 / 8086:154c + * Driver version: 2.9.21 (i40e) + +* Intel\ |reg| Corporation Ethernet Connection X722 for 10GbE SFP+ (4x10G) + + * Firmware version: 4.10 0x80001a3c + * Device id (pf/vf): 8086:37d0 / 8086:37cd + * Driver version: 2.9.21 (i40e) + +* Intel\ |reg| Ethernet Converged Network Adapter XXV710-DA2 (2x25G) + + * Firmware version: 7.00 0x80004cf8 + * Device id (pf/vf): 8086:158b / 8086:154c + * Driver version: 2.9.21 (i40e) + +* Intel\ |reg| Ethernet Converged Network Adapter XL710-QDA2 (2X40G) + + * Firmware version: 7.00 0x80004c97 + * Device id (pf/vf): 8086:1583 / 8086:154c + * Driver version: 2.9.21 (i40e) + +* Intel\ |reg| Corporation I350 Gigabit Network Connection + + * Firmware version: 1.63, 0x8cbc + * Device id (pf/vf): 8086:1521 / 8086:1520 + * Driver version: 5.4.0-k (igb) + +* Intel\ |reg| Corporation I210 Gigabit Network Connection + + * Firmware version: 3.25, 0x86eb + * Device id (pf): 8086:1533 + * Driver version: 5.4.0-k(igb) -- 2.17.1
Re: [dpdk-dev] [PATCH v2] event/octeontx: fix partial Rx packet handling
On Wed, Nov 27, 2019 at 9:36 PM wrote:
>
> From: Pavan Nikhilesh
>
> When net/octeontx is connected to event/octeontx as an event Rx adapter,
> PKI aka 'net/octeontx' can forward packets directly to SSO aka
> 'event/octeontx'.
> When pumping traffic to PKI if flow control is disabled internal FIFOs
> might be overrun causing partial l2 packets to be enqueued.
> SSO receives <31:0> TAG tag calculated by PKI, in normal cases <31:28>
> is always 0 which signifies RTE_EVENT_TYPE_ETHDEV. But in case of
> partial received packets PKI sets the <31:0> TAG as 0x which
> is an invalid event type.
>
> Add a check to see if TAG is 0x and free the partial receive
> packet.
>
> Cc: sta...@dpdk.org
> Fixes: d0d654986018 ("net/octeontx: support event Rx adapter")
Corrected the Cc: order.
>
> Signed-off-by: Pavan Nikhilesh
Acked-by: Jerin Jacob
Applied to dpdk-next-eventdev/master. Thanks.
@Thomas, It is possible to pull this patch from next-eventdev?
[dpdk-dev] [PATCH v2] net/mlx5: fix default mark copy flow
In extensive metadata mode the MARK copy table is engaged,
if the application creates the flow with zero MARK ID action:
flow create 1 ingress pattern eth / ... / end actions mark id 0 / .. end
And then destroys that, the traffic to the port stops. This happens
due to default flow for the copy table has the zero ID and is removed
with the application rule. The patch extends internal ID variable
to 64 bits and provide the UINT64_MAX ID for the copy table default
rule.
Fixes: dd3c774f6ffb ("net/mlx5: add metadata register copy table")
Signed-off-by: Viacheslav Ovsiienko
---
drivers/net/mlx5/mlx5_defs.h | 1 +
drivers/net/mlx5/mlx5_flow.c | 13 +++--
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_defs.h b/drivers/net/mlx5/mlx5_defs.h
index 9e113c5..042e1f3 100644
--- a/drivers/net/mlx5/mlx5_defs.h
+++ b/drivers/net/mlx5/mlx5_defs.h
@@ -174,6 +174,7 @@
/* Size of the simple hash table for metadata register table. */
#define MLX5_FLOW_MREG_HTABLE_SZ 4096
#define MLX5_FLOW_MREG_HNAME "MARK_COPY_TABLE"
+#define MLX5_DEFAULT_COPY_ID UINT32_MAX
/* Definition of static_assert found in /usr/include/assert.h */
#ifndef HAVE_STATIC_ASSERT
diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index 5c78ea7..0087163 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -2947,16 +2947,16 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev
*dev, int32_t priority,
mcp_res = (void *)mlx5_hlist_lookup(priv->mreg_cp_tbl, mark_id);
if (mcp_res) {
/* For non-default rule. */
- if (mark_id)
+ if (mark_id != MLX5_DEFAULT_COPY_ID)
mcp_res->refcnt++;
- assert(mark_id || mcp_res->refcnt == 1);
+ assert(mark_id != MLX5_DEFAULT_COPY_ID || mcp_res->refcnt == 1);
return mcp_res;
}
/* Provide the full width of FLAG specific value. */
if (mark_id == (priv->sh->dv_regc0_mask & MLX5_FLOW_MARK_DEFAULT))
tag_spec.data = MLX5_FLOW_MARK_DEFAULT;
/* Build a new flow. */
- if (mark_id) {
+ if (mark_id != MLX5_DEFAULT_COPY_ID) {
items[0] = (struct rte_flow_item){
.type = MLX5_RTE_FLOW_ITEM_TYPE_TAG,
.spec = &tag_spec,
@@ -3054,7 +3054,7 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev
*dev, int32_t priority,
}
/*
* We do not check availability of metadata registers here,
-* because copy resources are allocated in this case.
+* because copy resources are not allocated in this case.
*/
if (--mcp_res->refcnt)
return;
@@ -3133,7 +3133,8 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev
*dev, int32_t priority,
/* Check if default flow is registered. */
if (!priv->mreg_cp_tbl)
return;
- mcp_res = (void *)mlx5_hlist_lookup(priv->mreg_cp_tbl, 0ULL);
+ mcp_res = (void *)mlx5_hlist_lookup(priv->mreg_cp_tbl,
+ MLX5_DEFAULT_COPY_ID);
if (!mcp_res)
return;
assert(mcp_res->flow);
@@ -3166,7 +3167,7 @@ uint32_t mlx5_flow_adjust_priority(struct rte_eth_dev
*dev, int32_t priority,
!mlx5_flow_ext_mreg_supported(dev) ||
!priv->sh->dv_regc0_mask)
return 0;
- mcp_res = flow_mreg_add_copy_action(dev, 0, error);
+ mcp_res = flow_mreg_add_copy_action(dev, MLX5_DEFAULT_COPY_ID, error);
if (!mcp_res)
return -rte_errno;
return 0;
--
1.8.3.1
Re: [dpdk-dev] [PATCH] MAINTAINERS: resign from NFP PMD maintainer
On 2019/11/25 20:52, thomas at monjalon.net (Thomas Monjalon) wrote: > 13/11/2019 14:05, Alejandro Lucero: >> On Wed, Nov 13, 2019 at 12:55 PM Ferruh Yigit >> wrote: >>> On 11/13/2019 12:47 PM, Alejandro Lucero wrote: [...] >>> Can it be possible to nominate someone? >>> It would be good to have an owner of the PMD, >>> preferably technical owner of it, but at worst, >>> if we have nothing, a point of contact for the PMD. [...] > Netronome, is there someone to be responsible of this PMD? > Community, is there a volunteer outside of Netronome? > > If the PMD is not maintained, I am not sure how long we will keep it. > Hi Thomas, Jan Gutter and myself will be taking over from Alejandro and we will be co-maintaining the nfp PMD for Netronome. I am very new to the DPDK community but I have access to Netronome expertise and hardware to help with testing. Looking forward to working with everyone on this project going forward.
[dpdk-dev] [PATCH] ethdev: limit maximum number of queues
A buffer overflow happens in testpmd with some drivers
since the queue arrays are limited to RTE_MAX_QUEUES_PER_PORT.
The advertised capabilities of mlx4, mlx5 and softnic
for the number of queues were the maximum number: UINT16_MAX.
They must be limited by the configured RTE_MAX_QUEUES_PER_PORT
that applications expect to be respected.
The limitation is applied in above drivers having no limitation,
and at ethdev level (function rte_eth_dev_info_get), in order
to force the configured limit for all drivers.
Fixes: 7fae69eeff13 ("mlx4: new poll mode driver")
Fixes: e60fbd5b24fc ("mlx5: add device configure/start/stop")
Fixes: cc6d421574fe ("net/softnic: add softnic PMD")
Fixes: 9e6b36c34ce9 ("app/testpmd: reduce memory consumption")
Cc: sta...@dpdk.org
Reported-by: Raslan Darawsheh
Signed-off-by: Thomas Monjalon
---
drivers/net/mlx4/mlx4_ethdev.c| 4 +---
drivers/net/mlx5/mlx5_ethdev.c| 4 +---
drivers/net/softnic/rte_eth_softnic.c | 4 ++--
lib/librte_ethdev/rte_ethdev.c| 6 ++
4 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/net/mlx4/mlx4_ethdev.c b/drivers/net/mlx4/mlx4_ethdev.c
index dfb24c22d0..a18a66cb4a 100644
--- a/drivers/net/mlx4/mlx4_ethdev.c
+++ b/drivers/net/mlx4/mlx4_ethdev.c
@@ -646,9 +646,7 @@ mlx4_dev_infos_get(struct rte_eth_dev *dev, struct
rte_eth_dev_info *info)
*/
max = ((priv->device_attr.max_cq > priv->device_attr.max_qp) ?
priv->device_attr.max_qp : priv->device_attr.max_cq);
- /* If max >= 65535 then max = 0, max_rx_queues is uint16_t. */
- if (max >= 65535)
- max = 65535;
+ max = RTE_MIN(max, (unsigned int)RTE_MAX_QUEUES_PER_PORT);
info->max_rx_queues = max;
info->max_tx_queues = max;
info->max_mac_addrs = RTE_DIM(priv->mac);
diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index d80ae458bc..045dae6b5a 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -617,9 +617,7 @@ mlx5_dev_infos_get(struct rte_eth_dev *dev, struct
rte_eth_dev_info *info)
*/
max = RTE_MIN(priv->sh->device_attr.orig_attr.max_cq,
priv->sh->device_attr.orig_attr.max_qp);
- /* If max >= 65535 then max = 0, max_rx_queues is uint16_t. */
- if (max >= 65535)
- max = 65535;
+ max = RTE_MIN(max, (unsigned int)RTE_MAX_QUEUES_PER_PORT);
info->max_rx_queues = max;
info->max_tx_queues = max;
info->max_mac_addrs = MLX5_MAX_UC_MAC_ADDRESSES;
diff --git a/drivers/net/softnic/rte_eth_softnic.c
b/drivers/net/softnic/rte_eth_softnic.c
index 11723778fd..1065cbf847 100644
--- a/drivers/net/softnic/rte_eth_softnic.c
+++ b/drivers/net/softnic/rte_eth_softnic.c
@@ -91,8 +91,8 @@ pmd_dev_infos_get(struct rte_eth_dev *dev __rte_unused,
struct rte_eth_dev_info *dev_info)
{
dev_info->max_rx_pktlen = UINT32_MAX;
- dev_info->max_rx_queues = UINT16_MAX;
- dev_info->max_tx_queues = UINT16_MAX;
+ dev_info->max_rx_queues = RTE_MAX_QUEUES_PER_PORT;
+ dev_info->max_tx_queues = RTE_MAX_QUEUES_PER_PORT;
return 0;
}
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 8d2ce31a81..6e9cb243ea 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -2986,6 +2986,12 @@ rte_eth_dev_info_get(uint16_t port_id, struct
rte_eth_dev_info *dev_info)
return eth_err(port_id, diag);
}
+ /* Maximum number of queues should be <= RTE_MAX_QUEUES_PER_PORT */
+ dev_info->max_rx_queues = RTE_MIN(dev_info->max_rx_queues,
+ RTE_MAX_QUEUES_PER_PORT);
+ dev_info->max_tx_queues = RTE_MIN(dev_info->max_tx_queues,
+ RTE_MAX_QUEUES_PER_PORT);
+
dev_info->driver_name = dev->device->driver->name;
dev_info->nb_rx_queues = dev->data->nb_rx_queues;
dev_info->nb_tx_queues = dev->data->nb_tx_queues;
--
2.23.0
Re: [dpdk-dev] [PATCH v2] net/mlx5: fix default mark copy flow
> -Original Message-
> From: Viacheslav Ovsiienko
> Sent: Wednesday, November 27, 2019 3:37 PM
> To: dev@dpdk.org
> Cc: Matan Azrad ; Raslan Darawsheh
> ; Ori Kam
> Subject: [PATCH v2] net/mlx5: fix default mark copy flow
>
> In extensive metadata mode the MARK copy table is engaged,
> if the application creates the flow with zero MARK ID action:
>
> flow create 1 ingress pattern eth / ... / end actions mark id 0 / .. end
>
> And then destroys that, the traffic to the port stops. This happens
> due to default flow for the copy table has the zero ID and is removed
> with the application rule. The patch extends internal ID variable
> to 64 bits and provide the UINT64_MAX ID for the copy table default
> rule.
>
> Fixes: dd3c774f6ffb ("net/mlx5: add metadata register copy table")
>
> Signed-off-by: Viacheslav Ovsiienko
> ---
> drivers/net/mlx5/mlx5_defs.h | 1 +
> drivers/net/mlx5/mlx5_flow.c | 13 +++--
> 2 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/mlx5/mlx5_defs.h b/drivers/net/mlx5/mlx5_defs.h
> index 9e113c5..042e1f3 100644
> --- a/drivers/net/mlx5/mlx5_defs.h
> +++ b/drivers/net/mlx5/mlx5_defs.h
> @@ -174,6 +174,7 @@
> /* Size of the simple hash table for metadata register table. */
> #define MLX5_FLOW_MREG_HTABLE_SZ 4096
> #define MLX5_FLOW_MREG_HNAME "MARK_COPY_TABLE"
> +#define MLX5_DEFAULT_COPY_ID UINT32_MAX
>
> /* Definition of static_assert found in /usr/include/assert.h */
> #ifndef HAVE_STATIC_ASSERT
> diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
> index 5c78ea7..0087163 100644
> --- a/drivers/net/mlx5/mlx5_flow.c
> +++ b/drivers/net/mlx5/mlx5_flow.c
> @@ -2947,16 +2947,16 @@ uint32_t mlx5_flow_adjust_priority(struct
> rte_eth_dev *dev, int32_t priority,
> mcp_res = (void *)mlx5_hlist_lookup(priv->mreg_cp_tbl, mark_id);
> if (mcp_res) {
> /* For non-default rule. */
> - if (mark_id)
> + if (mark_id != MLX5_DEFAULT_COPY_ID)
> mcp_res->refcnt++;
> - assert(mark_id || mcp_res->refcnt == 1);
> + assert(mark_id != MLX5_DEFAULT_COPY_ID || mcp_res-
> >refcnt == 1);
> return mcp_res;
> }
> /* Provide the full width of FLAG specific value. */
> if (mark_id == (priv->sh->dv_regc0_mask &
> MLX5_FLOW_MARK_DEFAULT))
> tag_spec.data = MLX5_FLOW_MARK_DEFAULT;
> /* Build a new flow. */
> - if (mark_id) {
> + if (mark_id != MLX5_DEFAULT_COPY_ID) {
> items[0] = (struct rte_flow_item){
> .type = MLX5_RTE_FLOW_ITEM_TYPE_TAG,
> .spec = &tag_spec,
> @@ -3054,7 +3054,7 @@ uint32_t mlx5_flow_adjust_priority(struct
> rte_eth_dev *dev, int32_t priority,
> }
> /*
>* We do not check availability of metadata registers here,
> - * because copy resources are allocated in this case.
> + * because copy resources are not allocated in this case.
>*/
> if (--mcp_res->refcnt)
> return;
> @@ -3133,7 +3133,8 @@ uint32_t mlx5_flow_adjust_priority(struct
> rte_eth_dev *dev, int32_t priority,
> /* Check if default flow is registered. */
> if (!priv->mreg_cp_tbl)
> return;
> - mcp_res = (void *)mlx5_hlist_lookup(priv->mreg_cp_tbl, 0ULL);
> + mcp_res = (void *)mlx5_hlist_lookup(priv->mreg_cp_tbl,
> + MLX5_DEFAULT_COPY_ID);
> if (!mcp_res)
> return;
> assert(mcp_res->flow);
> @@ -3166,7 +3167,7 @@ uint32_t mlx5_flow_adjust_priority(struct
> rte_eth_dev *dev, int32_t priority,
> !mlx5_flow_ext_mreg_supported(dev) ||
> !priv->sh->dv_regc0_mask)
> return 0;
> - mcp_res = flow_mreg_add_copy_action(dev, 0, error);
> + mcp_res = flow_mreg_add_copy_action(dev,
> MLX5_DEFAULT_COPY_ID, error);
> if (!mcp_res)
> return -rte_errno;
> return 0;
> --
> 1.8.3.1
Acked-by: Ori Kam
Best,
Ori
Re: [dpdk-dev] [PATCH v2 8/8] doc: drop EAL command-line reference from FreeBSD GSG
On Wed, Nov 27, 2019 at 12:31:10PM +, Burakov, Anatoly wrote: > On 25-Nov-19 2:55 PM, Bruce Richardson wrote: > > The EAL command-line reference section duplicated material covered in a > > previous chapter, was out of date, and generally is unnecessary as options > > are best queried directly by passing "--help" to a DPDK binary. Therefore > > we can drop this section to avoid having to try and keep it up-to-date in > > the future. > > > > Signed-off-by: Bruce Richardson > > --- > > While passing --help works, i believe the parameter guides are a little bit > more detailed than what you can put in a help message, so there still is a > place for those. FreeBSD doesn't have FreeBSD-specific parameters, so in > this case it's probably OK to drop this particular document, but it would > still be nice to refer users to the common EAL arguments guide. > Ok. Let's drop this patch from the set for 19.11, then. /Bruce
Re: [dpdk-dev] [PATCH] net/nfp: replace license text with SPDX tag
On 2019/09/27 10:33, hemant.agrawal at nxp.com (Hemant Agrawal) wrote: > Signed-off-by: Hemant Agrawal Acked-by: Heinrich Kuhn
Re: [dpdk-dev] [PATCH] net/mlx5: fix legacy non-inline multi-packet performance
From: Viacheslav Ovsiienko
> The legacy multi-packet write is the feature allowing to put multiple packets
> into one transmitting descriptor, this feature is supported by only NIC
> ConnectX-4LX.
> The number of packets should be limited to provide optimal size descriptor
> and better performance.
>
> Fixes: 18a1c20044c0 ("net/mlx5: implement Tx burst template")
>
> Signed-off-by: Viacheslav Ovsiienko
Acked-by: Matan Azrad
Re: [dpdk-dev] [PATCH] net/mlx5: fix legacy inline multi-packet performance
From: Viacheslav Ovsiienko
> The legacy multi-packet write is the feature allowing to put multiple packets
> into one transmitting descriptor, this feature is supported by only NIC
> ConnectX-4LX.
> The number of packets should be limited to provide optimal size descriptor
> and better performance.
>
> Fixes: 18a1c20044c0 ("net/mlx5: implement Tx burst template")
>
> Signed-off-by: Viacheslav Ovsiienko
Acked-by: Matan Azrad
Re: [dpdk-dev] [PATCH] ethdev: limit maximum number of queues
On 11/27/2019 1:42 PM, Thomas Monjalon wrote:
> A buffer overflow happens in testpmd with some drivers
> since the queue arrays are limited to RTE_MAX_QUEUES_PER_PORT.
>
> The advertised capabilities of mlx4, mlx5 and softnic
> for the number of queues were the maximum number: UINT16_MAX.
> They must be limited by the configured RTE_MAX_QUEUES_PER_PORT
> that applications expect to be respected.
>
> The limitation is applied in above drivers having no limitation,
> and at ethdev level (function rte_eth_dev_info_get), in order
> to force the configured limit for all drivers.
The limit is not device limit, should we reflect it into PMDs?
Why not keep the limit only in the ethdev?
>
> Fixes: 7fae69eeff13 ("mlx4: new poll mode driver")
> Fixes: e60fbd5b24fc ("mlx5: add device configure/start/stop")
> Fixes: cc6d421574fe ("net/softnic: add softnic PMD")
> Fixes: 9e6b36c34ce9 ("app/testpmd: reduce memory consumption")
> Cc: sta...@dpdk.org
>
> Reported-by: Raslan Darawsheh
> Signed-off-by: Thomas Monjalon
> ---
> drivers/net/mlx4/mlx4_ethdev.c| 4 +---
> drivers/net/mlx5/mlx5_ethdev.c| 4 +---
> drivers/net/softnic/rte_eth_softnic.c | 4 ++--
> lib/librte_ethdev/rte_ethdev.c| 6 ++
> 4 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/mlx4/mlx4_ethdev.c b/drivers/net/mlx4/mlx4_ethdev.c
> index dfb24c22d0..a18a66cb4a 100644
> --- a/drivers/net/mlx4/mlx4_ethdev.c
> +++ b/drivers/net/mlx4/mlx4_ethdev.c
> @@ -646,9 +646,7 @@ mlx4_dev_infos_get(struct rte_eth_dev *dev, struct
> rte_eth_dev_info *info)
>*/
> max = ((priv->device_attr.max_cq > priv->device_attr.max_qp) ?
> priv->device_attr.max_qp : priv->device_attr.max_cq);
> - /* If max >= 65535 then max = 0, max_rx_queues is uint16_t. */
> - if (max >= 65535)
> - max = 65535;
> + max = RTE_MIN(max, (unsigned int)RTE_MAX_QUEUES_PER_PORT);
> info->max_rx_queues = max;
> info->max_tx_queues = max;
> info->max_mac_addrs = RTE_DIM(priv->mac);
> diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
> index d80ae458bc..045dae6b5a 100644
> --- a/drivers/net/mlx5/mlx5_ethdev.c
> +++ b/drivers/net/mlx5/mlx5_ethdev.c
> @@ -617,9 +617,7 @@ mlx5_dev_infos_get(struct rte_eth_dev *dev, struct
> rte_eth_dev_info *info)
>*/
> max = RTE_MIN(priv->sh->device_attr.orig_attr.max_cq,
> priv->sh->device_attr.orig_attr.max_qp);
> - /* If max >= 65535 then max = 0, max_rx_queues is uint16_t. */
> - if (max >= 65535)
> - max = 65535;
> + max = RTE_MIN(max, (unsigned int)RTE_MAX_QUEUES_PER_PORT);
> info->max_rx_queues = max;
> info->max_tx_queues = max;
> info->max_mac_addrs = MLX5_MAX_UC_MAC_ADDRESSES;
> diff --git a/drivers/net/softnic/rte_eth_softnic.c
> b/drivers/net/softnic/rte_eth_softnic.c
> index 11723778fd..1065cbf847 100644
> --- a/drivers/net/softnic/rte_eth_softnic.c
> +++ b/drivers/net/softnic/rte_eth_softnic.c
> @@ -91,8 +91,8 @@ pmd_dev_infos_get(struct rte_eth_dev *dev __rte_unused,
> struct rte_eth_dev_info *dev_info)
> {
> dev_info->max_rx_pktlen = UINT32_MAX;
> - dev_info->max_rx_queues = UINT16_MAX;
> - dev_info->max_tx_queues = UINT16_MAX;
> + dev_info->max_rx_queues = RTE_MAX_QUEUES_PER_PORT;
> + dev_info->max_tx_queues = RTE_MAX_QUEUES_PER_PORT;
>
> return 0;
> }
> diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
> index 8d2ce31a81..6e9cb243ea 100644
> --- a/lib/librte_ethdev/rte_ethdev.c
> +++ b/lib/librte_ethdev/rte_ethdev.c
> @@ -2986,6 +2986,12 @@ rte_eth_dev_info_get(uint16_t port_id, struct
> rte_eth_dev_info *dev_info)
> return eth_err(port_id, diag);
> }
>
> + /* Maximum number of queues should be <= RTE_MAX_QUEUES_PER_PORT */
> + dev_info->max_rx_queues = RTE_MIN(dev_info->max_rx_queues,
> + RTE_MAX_QUEUES_PER_PORT);
> + dev_info->max_tx_queues = RTE_MIN(dev_info->max_tx_queues,
> + RTE_MAX_QUEUES_PER_PORT);
> +
> dev_info->driver_name = dev->device->driver->name;
> dev_info->nb_rx_queues = dev->data->nb_rx_queues;
> dev_info->nb_tx_queues = dev->data->nb_tx_queues;
>
Re: [dpdk-dev] [PATCH] ethdev: limit maximum number of queues
On Wed, Nov 27, 2019 at 3:06 PM Ferruh Yigit wrote: > > On 11/27/2019 1:42 PM, Thomas Monjalon wrote: > > A buffer overflow happens in testpmd with some drivers > > since the queue arrays are limited to RTE_MAX_QUEUES_PER_PORT. > > > > The advertised capabilities of mlx4, mlx5 and softnic > > for the number of queues were the maximum number: UINT16_MAX. > > They must be limited by the configured RTE_MAX_QUEUES_PER_PORT > > that applications expect to be respected. > > > > The limitation is applied in above drivers having no limitation, > > and at ethdev level (function rte_eth_dev_info_get), in order > > to force the configured limit for all drivers. > > The limit is not device limit, should we reflect it into PMDs? > Why not keep the limit only in the ethdev? +1. -- David Marchand
Re: [dpdk-dev] [PATCH] test/service: fix wait for service core
Harry van Haaren writes:
> This commit fixes a sporadic failure of the service_autotest
> unit test, as seen in the DPDK CI. The failure occurs as the main test
> thread did not wait on the service-thread to return, and allowing it
> to read a flag before the service was able to write to it.
>
> The fix changes the wait API call to specific the service-core ID,
> and this waits for cores with both ROLE_RTE and ROLE_SERVICE.
>
> The rte_eal_mp_wait_lcore() call does not (and should not) wait
> for service cores, so must not be used to wait on service-cores.
>
> Fixes: f038a81e1c56 ("service: add unit tests")
>
> Reported-by: Aaron Conole
> Signed-off-by: Harry van Haaren
>
> ---
It might also be good to document this behavior in the API area. It's
unclear that the lcore wait function which takes a core id will work,
but the broad wait will not.
> Given this is a fix in the unit test, and not a functional change
> I'm not sure its worth backporting to LTS / stable releases?
> I've not added stable on CC yet.
I think it's worth it if the LTS / stable branches use the unit tests
(otherwise, they will observe sporadic failures).
> ---
> app/test/test_service_cores.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/app/test/test_service_cores.c b/app/test/test_service_cores.c
> index 9fe38f5e0..a922c7ddc 100644
> --- a/app/test/test_service_cores.c
> +++ b/app/test/test_service_cores.c
> @@ -483,7 +483,7 @@ service_lcore_en_dis_able(void)
> int ret = rte_eal_remote_launch(service_remote_launch_func, NULL,
> slcore_id);
> TEST_ASSERT_EQUAL(0, ret, "Ex-service core remote launch failed.");
> - rte_eal_mp_wait_lcore();
> + rte_eal_wait_lcore(slcore_id);
> TEST_ASSERT_EQUAL(1, service_remote_launch_flag,
> "Ex-service core function call had no effect.");
Should we also have some change like the following (just a guess):
diff --git a/app/test/test_service_cores.c b/app/test/test_service_cores.c
index 9fe38f5e08..695c35ac6c 100644
--- a/app/test/test_service_cores.c
+++ b/app/test/test_service_cores.c
@@ -773,7 +773,7 @@ service_app_lcore_poll_impl(const int mt_safe)
/* flag done, then wait for the spawned 2nd core to return */
params[0] = 1;
- rte_eal_mp_wait_lcore();
+ rte_eal_wait_lcore(app_core2);
/* core two gets launched first - and should hold the service lock */
TEST_ASSERT_EQUAL(0, app_core2_ret,
Re: [dpdk-dev] [PATCH] ethdev: limit maximum number of queues
27/11/2019 15:07, David Marchand: > On Wed, Nov 27, 2019 at 3:06 PM Ferruh Yigit wrote: > > > > On 11/27/2019 1:42 PM, Thomas Monjalon wrote: > > > A buffer overflow happens in testpmd with some drivers > > > since the queue arrays are limited to RTE_MAX_QUEUES_PER_PORT. > > > > > > The advertised capabilities of mlx4, mlx5 and softnic > > > for the number of queues were the maximum number: UINT16_MAX. > > > They must be limited by the configured RTE_MAX_QUEUES_PER_PORT > > > that applications expect to be respected. > > > > > > The limitation is applied in above drivers having no limitation, > > > and at ethdev level (function rte_eth_dev_info_get), in order > > > to force the configured limit for all drivers. > > > > The limit is not device limit, should we reflect it into PMDs? > > Why not keep the limit only in the ethdev? > > +1. Yes ethdev is enough. I thought it would be better to document the limit in the PMDs as well, instead of keeping gigantic max. I can change if you feel strong about it.
Re: [dpdk-dev] [PATCH] ethdev: limit maximum number of queues
On 11/27/2019 2:11 PM, Thomas Monjalon wrote: > 27/11/2019 15:07, David Marchand: >> On Wed, Nov 27, 2019 at 3:06 PM Ferruh Yigit wrote: >>> >>> On 11/27/2019 1:42 PM, Thomas Monjalon wrote: A buffer overflow happens in testpmd with some drivers since the queue arrays are limited to RTE_MAX_QUEUES_PER_PORT. The advertised capabilities of mlx4, mlx5 and softnic for the number of queues were the maximum number: UINT16_MAX. They must be limited by the configured RTE_MAX_QUEUES_PER_PORT that applications expect to be respected. The limitation is applied in above drivers having no limitation, and at ethdev level (function rte_eth_dev_info_get), in order to force the configured limit for all drivers. >>> >>> The limit is not device limit, should we reflect it into PMDs? >>> Why not keep the limit only in the ethdev? >> >> +1. > > Yes ethdev is enough. > I thought it would be better to document the limit in the PMDs as well, > instead of keeping gigantic max. > > I can change if you feel strong about it. > No strong opinion, but not sure if we should document ethdev limitation in ethdev, for me only ethdev limit looks good.
Re: [dpdk-dev] [PATCH] ethdev: limit maximum number of queues
On 11/27/2019 2:14 PM, Ferruh Yigit wrote: > On 11/27/2019 2:11 PM, Thomas Monjalon wrote: >> 27/11/2019 15:07, David Marchand: >>> On Wed, Nov 27, 2019 at 3:06 PM Ferruh Yigit wrote: On 11/27/2019 1:42 PM, Thomas Monjalon wrote: > A buffer overflow happens in testpmd with some drivers > since the queue arrays are limited to RTE_MAX_QUEUES_PER_PORT. > > The advertised capabilities of mlx4, mlx5 and softnic > for the number of queues were the maximum number: UINT16_MAX. > They must be limited by the configured RTE_MAX_QUEUES_PER_PORT > that applications expect to be respected. > > The limitation is applied in above drivers having no limitation, > and at ethdev level (function rte_eth_dev_info_get), in order > to force the configured limit for all drivers. The limit is not device limit, should we reflect it into PMDs? Why not keep the limit only in the ethdev? >>> >>> +1. >> >> Yes ethdev is enough. >> I thought it would be better to document the limit in the PMDs as well, >> instead of keeping gigantic max. >> >> I can change if you feel strong about it. >> > > No strong opinion, but not sure if we should document ethdev limitation in > ethdev, for me only ethdev limit looks good. > ... not sure if we should document ethdev limitation in *PMD* ...
Re: [dpdk-dev] [PATCH] test/service: fix wait for service core
> -Original Message-
> From: Aaron Conole
> Sent: Wednesday, November 27, 2019 2:10 PM
> To: Van Haaren, Harry
> Cc: dev@dpdk.org
> Subject: Re: [PATCH] test/service: fix wait for service core
>
> Harry van Haaren writes:
>
> > This commit fixes a sporadic failure of the service_autotest
> > unit test, as seen in the DPDK CI. The failure occurs as the main test
> > thread did not wait on the service-thread to return, and allowing it
> > to read a flag before the service was able to write to it.
> >
> > The fix changes the wait API call to specific the service-core ID,
> > and this waits for cores with both ROLE_RTE and ROLE_SERVICE.
> >
> > The rte_eal_mp_wait_lcore() call does not (and should not) wait
> > for service cores, so must not be used to wait on service-cores.
> >
> > Fixes: f038a81e1c56 ("service: add unit tests")
> >
> > Reported-by: Aaron Conole
> > Signed-off-by: Harry van Haaren
> >
> > ---
>
> It might also be good to document this behavior in the API area. It's
> unclear that the lcore wait function which takes a core id will work,
> but the broad wait will not.
Yes agreed that docs can improve here - different patch.
> > Given this is a fix in the unit test, and not a functional change
> > I'm not sure its worth backporting to LTS / stable releases?
> > I've not added stable on CC yet.
>
> I think it's worth it if the LTS / stable branches use the unit tests
> (otherwise, they will observe sporadic failures).
Ok, I've added sta...@dpdk.org on CC now
> > app/test/test_service_cores.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/app/test/test_service_cores.c b/app/test/test_service_cores.c
> > index 9fe38f5e0..a922c7ddc 100644
> > --- a/app/test/test_service_cores.c
> > +++ b/app/test/test_service_cores.c
> > @@ -483,7 +483,7 @@ service_lcore_en_dis_able(void)
> > int ret = rte_eal_remote_launch(service_remote_launch_func, NULL,
> > slcore_id);
> > TEST_ASSERT_EQUAL(0, ret, "Ex-service core remote launch failed.");
> > - rte_eal_mp_wait_lcore();
> > + rte_eal_wait_lcore(slcore_id);
> > TEST_ASSERT_EQUAL(1, service_remote_launch_flag,
> > "Ex-service core function call had no effect.");
>
> Should we also have some change like the following (just a guess):
>
> diff --git a/app/test/test_service_cores.c b/app/test/test_service_cores.c
> index 9fe38f5e08..695c35ac6c 100644
> --- a/app/test/test_service_cores.c
> +++ b/app/test/test_service_cores.c
> @@ -773,7 +773,7 @@ service_app_lcore_poll_impl(const int mt_safe)
>
> /* flag done, then wait for the spawned 2nd core to return */
> params[0] = 1;
> - rte_eal_mp_wait_lcore();
> + rte_eal_wait_lcore(app_core2);
>
> /* core two gets launched first - and should hold the service lock */
> TEST_ASSERT_EQUAL(0, app_core2_ret,
I reviewed this usage of the function, and I believe it waits on application
cores (aka, ROLE_RTE, not ROLE_SERVICE). Hence this usage is actually correct.
Please review and double check my logic though - more eyes is good.
[dpdk-dev] [PATCH dpdk-dev 1/3] net/mlx5: avoid crash when setting hairpin queues
From: Tonghao Zhang
If configuring the number of tx/rx queue with rte_eth_dev_configure
to nr_queues + hairpin_nr_queues, and setting tx/rx queues to
nr_queues with rte_eth_tx/rx_queue_setup. But not configuring the
hairpin queues via rte_eth_tx/rx_hairpin_queue_setup.
When starting the netdev, there is a crash because of NULL accessing.
Fixes: cf5516696d77 ("ethdev: add hairpin queue")
Cc: Ori Kam
Signed-off-by: Tonghao Zhang
---
drivers/net/mlx5/mlx5_ethdev.c | 2 +-
drivers/net/mlx5/mlx5_trigger.c | 5 -
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index 1d6c084119ec..0076d05b00cc 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -476,7 +476,7 @@ mlx5_dev_configure_rss_reta(struct rte_eth_dev *dev)
rxq_data = (*priv->rxqs)[i];
rxq_ctrl = container_of(rxq_data, struct mlx5_rxq_ctrl, rxq);
- if (rxq_ctrl->type == MLX5_RXQ_TYPE_STANDARD)
+ if (rxq_ctrl && rxq_ctrl->type == MLX5_RXQ_TYPE_STANDARD)
rss_queue_arr[j++] = i;
}
rss_queue_n = j;
diff --git a/drivers/net/mlx5/mlx5_trigger.c b/drivers/net/mlx5/mlx5_trigger.c
index cafab25c67e7..ab6937ab10d1 100644
--- a/drivers/net/mlx5/mlx5_trigger.c
+++ b/drivers/net/mlx5/mlx5_trigger.c
@@ -106,9 +106,12 @@ mlx5_rxq_start(struct rte_eth_dev *dev)
unsigned int i;
int ret = 0;
enum mlx5_rxq_obj_type obj_type = MLX5_RXQ_OBJ_TYPE_IBV;
+ struct mlx5_rxq_data *rxq = NULL;
for (i = 0; i < priv->rxqs_n; ++i) {
- if ((*priv->rxqs)[i]->lro) {
+ rxq = (*priv->rxqs)[i];
+
+ if (rxq && rxq->lro) {
obj_type = MLX5_RXQ_OBJ_TYPE_DEVX_RQ;
break;
}
--
2.23.0
[dpdk-dev] [PATCH dpdk-dev 3/3] net/mlx5: remove the assert for rxq cq
From: Tonghao Zhang
The mlx5_rxq_obj_hairpin_new doesn't alloc the
cq anymore. When releasing it, don't check it.
Fixes: e79c9be91515 ("net/mlx5: support Rx hairpin queues")
Cc: Ori Kam
Signed-off-by: Tonghao Zhang
---
drivers/net/mlx5/mlx5_rxq.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/mlx5/mlx5_rxq.c b/drivers/net/mlx5/mlx5_rxq.c
index 2a12d5fa3436..582a2330e575 100644
--- a/drivers/net/mlx5/mlx5_rxq.c
+++ b/drivers/net/mlx5/mlx5_rxq.c
@@ -673,7 +673,6 @@ mlx5_rxq_obj_release(struct mlx5_rxq_obj *rxq_obj)
assert(rxq_obj);
if (rxq_obj->type == MLX5_RXQ_OBJ_TYPE_IBV)
assert(rxq_obj->wq);
- assert(rxq_obj->cq);
if (rte_atomic32_dec_and_test(&rxq_obj->refcnt)) {
switch (rxq_obj->type) {
case MLX5_RXQ_OBJ_TYPE_IBV:
--
2.23.0
[dpdk-dev] [PATCH dpdk-dev 2/3] net/mlx5: clean up redundant assignment
From: Tonghao Zhang
The type of txq has been assigned in mlx5_txq_hairpin_new.
Fixes: ae18a1ae9692 ("net/mlx5: support Tx hairpin queues")
Cc: Ori Kam
Signed-off-by: Tonghao Zhang
---
drivers/net/mlx5/mlx5_txq.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/mlx5/mlx5_txq.c b/drivers/net/mlx5/mlx5_txq.c
index a0d61644cb7f..e6a841c8d359 100644
--- a/drivers/net/mlx5/mlx5_txq.c
+++ b/drivers/net/mlx5/mlx5_txq.c
@@ -271,7 +271,6 @@ mlx5_tx_hairpin_queue_setup(struct rte_eth_dev *dev,
uint16_t idx,
DRV_LOG(DEBUG, "port %u adding Tx queue %u to list",
dev->data->port_id, idx);
(*priv->txqs)[idx] = &txq_ctrl->txq;
- txq_ctrl->type = MLX5_TXQ_TYPE_HAIRPIN;
return 0;
}
--
2.23.0
Re: [dpdk-dev] [PATCH v3] mk: add support for UBSAN
Harman Kalra writes:
> UndefinedBehaviorSanitizer (UBSan) is a fast undefined behavior
> detector. UBSan modifies the program at compile-time to catch
> various kinds of undefined behavior during program execution.
>
> This patch introduces support for UBSan to the DPDK.
>
> See: doc/guides/prog_guide/ubsan.rst for more information.
>
> Signed-off-by: Harman Kalra
> ---
Sorry I am coming to this late.
> V2:
> * Addressed review comment regarding combining two
> ifeq into one.
>
> V3:
> * Added version change logs.
>
> config/common_base | 6 ++
> config/meson.build | 15
> doc/guides/prog_guide/index.rst| 1 +
> doc/guides/prog_guide/ubsan.rst| 112 +
> doc/guides/rel_notes/release_19_11.rst | 7 ++
> meson_options.txt | 2 +
> mk/rte.app.mk | 8 ++
> mk/rte.lib.mk | 12 +++
> mk/toolchain/clang/rte.vars.mk | 4 +
> mk/toolchain/gcc/rte.vars.mk | 8 ++
> 10 files changed, 175 insertions(+)
> create mode 100644 doc/guides/prog_guide/ubsan.rst
>
> diff --git a/config/common_base b/config/common_base
> index 914277856..f1bb3e0b2 100644
> --- a/config/common_base
> +++ b/config/common_base
> @@ -1098,3 +1098,9 @@ CONFIG_RTE_APP_CRYPTO_PERF=y
> # Compile the eventdev application
> #
> CONFIG_RTE_APP_EVENTDEV=y
> +
> +#
> +# Enable undefined behavior sanitizer
> +#
> +CONFIG_RTE_UBSAN=n
> +CONFIG_RTE_UBSAN_SANITIZE_ALL=n
> diff --git a/config/meson.build b/config/meson.build
> index 2b1cb92e7..a43c23f50 100644
> --- a/config/meson.build
> +++ b/config/meson.build
> @@ -238,3 +238,18 @@ if get_option('b_lto')
> add_project_link_arguments('-Wno-lto-type-mismatch', language:
> 'c')
> endif
> endif
> +
> +# enable ubsan
> +if get_option('enable_ubsan')
> + if cc.has_argument('-fsanitize=undefined')
> + ubsan_dep = cc.find_library('libubsan', required: false)
> + if ubsan_dep.found()
> + add_project_arguments('-fsanitize=undefined', language:
> 'c')
> + add_project_link_arguments('-fsanitize=undefined',
> language: 'c')
> + else
> + message('libubsan not found, UBSAN cannot be enabled')
> + endif
> + else
> + message('gcc version does not support UBSAN')
> + endif
> +endif
Why is this needed? AFAIK, meson supports
-Db_sanitize=undefined,address,... so what do we gain by this?
Especially since for ubsan and asan, -fno-omit-frame-pointer is needed
for useful backtraces (which the meson module does for us). This
support has been in since 2017, afaict.
> diff --git a/doc/guides/prog_guide/index.rst b/doc/guides/prog_guide/index.rst
> index dc4851c57..911b82a41 100644
> --- a/doc/guides/prog_guide/index.rst
> +++ b/doc/guides/prog_guide/index.rst
> @@ -67,4 +67,5 @@ Programmer's Guide
> writing_efficient_code
> lto
> profile_app
> +ubsan
> glossary
> diff --git a/doc/guides/prog_guide/ubsan.rst b/doc/guides/prog_guide/ubsan.rst
> new file mode 100644
> index 0..cb19f3bd9
> --- /dev/null
> +++ b/doc/guides/prog_guide/ubsan.rst
> @@ -0,0 +1,112 @@
> +.. SPDX-License-Identifier: BSD-3-Clause
> +Copyright(c) 2019 Marvell International Ltd.
> +
> +The Undefined Behavior Sanitizer - UBSan
> +===+
> +UndefinedBehaviorSanitizer (UBSan) is a runtime undefined behavior detector.
> +UBSan uses compile-time instrumentation and modifies the program by adding
> +some stubs which perform certain checks before operations that might cause
> +undefined behaviour. If some UB detected, respective _UBSan_handle_* handlers
> +(which are defined in libUBSan library) are called to prints the error
> message.
> +
> +Some examples of undefined behaviour checks:
> +
> +* Misaligned memory access
> +* Signed integer overflow
> +* Load from/store to an object with insufficient space.
> +* Integer divide by zero as well as INT_MIN / -1 division
> +* Out-of-bounds memory accesses.
> +* Null argument declared with nonnull attribute, returned null from function
> + which never returns null, null ptr dereference
> +* Variable size array with non-positive length
> +
> +GCC supports this feature since 4.9, however GCC 5.0 onwards has many more
> +checkers implemented.
> +
> +Example UBSan error
> +
> +
> +Following error was reported when UBSan was enabled:
> +
> +.. code-block:: console
> +
> +drivers/net/octeontx2/otx2_stats.c:82:26: runtime error: left shift of
> +1 by 31 places cannot be represented in type 'int'
> +
> +Code responsible for this error:
> +
> +.. code-block:: c
> +
> +if (dev->txmap[i] & (1 << 31)) {
> +
> +To fix this error:
> +
> +.. code-block:: c
> +
> +if (dev->txmap[i] & (1U << 31)) {
> +
> +Usage
> +-
> +
> +make build
> +^^
> +
> +To enable UBSan, enable
Re: [dpdk-dev] [PATCH] ethdev: limit maximum number of queues
On Wed, Nov 27, 2019 at 3:11 PM Thomas Monjalon wrote: > > 27/11/2019 15:07, David Marchand: > > On Wed, Nov 27, 2019 at 3:06 PM Ferruh Yigit wrote: > > > > > > On 11/27/2019 1:42 PM, Thomas Monjalon wrote: > > > > A buffer overflow happens in testpmd with some drivers > > > > since the queue arrays are limited to RTE_MAX_QUEUES_PER_PORT. > > > > > > > > The advertised capabilities of mlx4, mlx5 and softnic > > > > for the number of queues were the maximum number: UINT16_MAX. > > > > They must be limited by the configured RTE_MAX_QUEUES_PER_PORT > > > > that applications expect to be respected. > > > > > > > > The limitation is applied in above drivers having no limitation, > > > > and at ethdev level (function rte_eth_dev_info_get), in order > > > > to force the configured limit for all drivers. > > > > > > The limit is not device limit, should we reflect it into PMDs? > > > Why not keep the limit only in the ethdev? > > > > +1. > > Yes ethdev is enough. > I thought it would be better to document the limit in the PMDs as well, > instead of keeping gigantic max. This gigantic value also documents that the driver has no limitation itself. The limitation is in the ethdev layer. Certainly a bit far-fetched but, with the mlx5 driver as a .so, you would prefer the driver not to announce a limitation from ethdev if you recompile ethdev. -- David Marchand
[dpdk-dev] [PATCH v2] ethdev: limit maximum number of queues
A buffer overflow happens in testpmd with some drivers
since the queue arrays are limited to RTE_MAX_QUEUES_PER_PORT.
The advertised capabilities of mlx4, mlx5 and softnic
for the number of queues were the maximum number: UINT16_MAX.
They must be limited by the configured RTE_MAX_QUEUES_PER_PORT
that applications expect to be respected.
The limitation is applied at ethdev level (function rte_eth_dev_info_get),
in order to force the configured limit for all drivers.
Fixes: 14b53e27b30e ("ethdev: fix crash with multiprocess")
Cc: sta...@dpdk.org
Reported-by: Raslan Darawsheh
Signed-off-by: Thomas Monjalon
Reviewed-by: Ferruh Yigit
---
v2: remove changes in drivers, keep limit only in ethdev
---
lib/librte_ethdev/rte_ethdev.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 8d2ce31a81..6e9cb243ea 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -2986,6 +2986,12 @@ rte_eth_dev_info_get(uint16_t port_id, struct
rte_eth_dev_info *dev_info)
return eth_err(port_id, diag);
}
+ /* Maximum number of queues should be <= RTE_MAX_QUEUES_PER_PORT */
+ dev_info->max_rx_queues = RTE_MIN(dev_info->max_rx_queues,
+ RTE_MAX_QUEUES_PER_PORT);
+ dev_info->max_tx_queues = RTE_MIN(dev_info->max_tx_queues,
+ RTE_MAX_QUEUES_PER_PORT);
+
dev_info->driver_name = dev->device->driver->name;
dev_info->nb_rx_queues = dev->data->nb_rx_queues;
dev_info->nb_tx_queues = dev->data->nb_tx_queues;
--
2.23.0
Re: [dpdk-dev] [PATCH v2] ethdev: limit maximum number of queues
On Wed, Nov 27, 2019 at 3:31 PM Thomas Monjalon wrote:
>
> A buffer overflow happens in testpmd with some drivers
> since the queue arrays are limited to RTE_MAX_QUEUES_PER_PORT.
>
> The advertised capabilities of mlx4, mlx5 and softnic
> for the number of queues were the maximum number: UINT16_MAX.
> They must be limited by the configured RTE_MAX_QUEUES_PER_PORT
> that applications expect to be respected.
>
> The limitation is applied at ethdev level (function rte_eth_dev_info_get),
> in order to force the configured limit for all drivers.
>
> Fixes: 14b53e27b30e ("ethdev: fix crash with multiprocess")
> Cc: sta...@dpdk.org
>
> Reported-by: Raslan Darawsheh
> Signed-off-by: Thomas Monjalon
> Reviewed-by: Ferruh Yigit
Reviewed-by: David Marchand
--
David Marchand
Re: [dpdk-dev] [dpdk-users] What is the 'unit of timestamp' assigned to mbuf packet in DPDK?
Hi Gokul,
As Setphen said, only Mellanox sets the hardware timestamp.
If you have a Mellanox card, you can actually follow the example given
in the rxtx_callback sample application that precisely gives the number
of CPU cycles a packet spent into the queue.
Tom
Le 22/11/2019 à 18:00, Gokul Bargaje a écrit :
Thank you for the clarification. But I am still unable to understand how
exactly timestamp is calculated before assigning to a timestamp field.
Could you please tell me the steps to calculate the timestamp in DPDK?
I have to implement the PIE AQM algorithm in DPDK and for that, I need to
calculate the total time spent by the packet waiting in queue (i.e. the
difference between enqueue time and dequeue time).
Thanks,
Gokul
On Fri, Nov 22, 2019 at 8:18 PM Ferruh Yigit wrote:
On 11/18/2019 2:29 PM, Gokul Bargaje wrote:
Hi,
The timestamp assigned to packet at the time of enqueue (value of
timestamp
field in mbuf), is it in milliseconds or microseconds or in cpu cycles?
The unit is not defined [1]. 'rte_eth_read_clock()' was added [2] to help
converting it to time when it is clock counter.
[1]
918ae9dc775e ("mbuf: add a timestamp field")
[2]
5e741377657c ("ethdev: add API to read device clock")
How this timestamp is calculated? Is it calculated using the
*rte_cycles.h*?
Re: [dpdk-dev] [PATCH dpdk-dev 1/3] net/mlx5: avoid crash when setting hairpin queues
> -Original Message-
> From: xiangxia.m@gmail.com
> Sent: Wednesday, November 27, 2019 4:19 PM
> To: dev@dpdk.org
> Cc: Tonghao Zhang ; Ori Kam
>
> Subject: [PATCH dpdk-dev 1/3] net/mlx5: avoid crash when setting hairpin
> queues
>
> From: Tonghao Zhang
>
> If configuring the number of tx/rx queue with rte_eth_dev_configure
> to nr_queues + hairpin_nr_queues, and setting tx/rx queues to
> nr_queues with rte_eth_tx/rx_queue_setup. But not configuring the
> hairpin queues via rte_eth_tx/rx_hairpin_queue_setup.
>
> When starting the netdev, there is a crash because of NULL accessing.
>
> Fixes: cf5516696d77 ("ethdev: add hairpin queue")
> Cc: Ori Kam
> Signed-off-by: Tonghao Zhang
> ---
> drivers/net/mlx5/mlx5_ethdev.c | 2 +-
> drivers/net/mlx5/mlx5_trigger.c | 5 -
> 2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/mlx5/mlx5_ethdev.c
> b/drivers/net/mlx5/mlx5_ethdev.c
> index 1d6c084119ec..0076d05b00cc 100644
> --- a/drivers/net/mlx5/mlx5_ethdev.c
> +++ b/drivers/net/mlx5/mlx5_ethdev.c
> @@ -476,7 +476,7 @@ mlx5_dev_configure_rss_reta(struct rte_eth_dev
> *dev)
>
> rxq_data = (*priv->rxqs)[i];
> rxq_ctrl = container_of(rxq_data, struct mlx5_rxq_ctrl, rxq);
> - if (rxq_ctrl->type == MLX5_RXQ_TYPE_STANDARD)
> + if (rxq_ctrl && rxq_ctrl->type ==
> MLX5_RXQ_TYPE_STANDARD)
> rss_queue_arr[j++] = i;
> }
> rss_queue_n = j;
> diff --git a/drivers/net/mlx5/mlx5_trigger.c
> b/drivers/net/mlx5/mlx5_trigger.c
> index cafab25c67e7..ab6937ab10d1 100644
> --- a/drivers/net/mlx5/mlx5_trigger.c
> +++ b/drivers/net/mlx5/mlx5_trigger.c
> @@ -106,9 +106,12 @@ mlx5_rxq_start(struct rte_eth_dev *dev)
> unsigned int i;
> int ret = 0;
> enum mlx5_rxq_obj_type obj_type = MLX5_RXQ_OBJ_TYPE_IBV;
> + struct mlx5_rxq_data *rxq = NULL;
>
> for (i = 0; i < priv->rxqs_n; ++i) {
> - if ((*priv->rxqs)[i]->lro) {
> + rxq = (*priv->rxqs)[i];
> +
> + if (rxq && rxq->lro) {
> obj_type = MLX5_RXQ_OBJ_TYPE_DEVX_RQ;
> break;
> }
> --
> 2.23.0
Nice catch,
Acked-by: Ori Kam
Thanks,
Ori
Re: [dpdk-dev] [PATCH dpdk-dev 2/3] net/mlx5: clean up redundant assignment
> -Original Message-
> From: xiangxia.m@gmail.com
> Sent: Wednesday, November 27, 2019 4:19 PM
> To: dev@dpdk.org
> Cc: Tonghao Zhang ; Ori Kam
>
> Subject: [PATCH dpdk-dev 2/3] net/mlx5: clean up redundant assignment
>
> From: Tonghao Zhang
>
> The type of txq has been assigned in mlx5_txq_hairpin_new.
>
> Fixes: ae18a1ae9692 ("net/mlx5: support Tx hairpin queues")
> Cc: Ori Kam
> Signed-off-by: Tonghao Zhang
> ---
> drivers/net/mlx5/mlx5_txq.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/mlx5/mlx5_txq.c b/drivers/net/mlx5/mlx5_txq.c
> index a0d61644cb7f..e6a841c8d359 100644
> --- a/drivers/net/mlx5/mlx5_txq.c
> +++ b/drivers/net/mlx5/mlx5_txq.c
> @@ -271,7 +271,6 @@ mlx5_tx_hairpin_queue_setup(struct rte_eth_dev
> *dev, uint16_t idx,
> DRV_LOG(DEBUG, "port %u adding Tx queue %u to list",
> dev->data->port_id, idx);
> (*priv->txqs)[idx] = &txq_ctrl->txq;
> - txq_ctrl->type = MLX5_TXQ_TYPE_HAIRPIN;
> return 0;
> }
>
> --
> 2.23.0
Acked-by: Ori Kam
Thanks,
Ori
Re: [dpdk-dev] [PATCH dpdk-dev 3/3] net/mlx5: remove the assert for rxq cq
This patch is not correct,
You are using old code. This was already solved.
Thanks,
Ori
> -Original Message-
> From: xiangxia.m@gmail.com
> Sent: Wednesday, November 27, 2019 4:19 PM
> To: dev@dpdk.org
> Cc: Tonghao Zhang ; Ori Kam
>
> Subject: [PATCH dpdk-dev 3/3] net/mlx5: remove the assert for rxq cq
>
> From: Tonghao Zhang
>
> The mlx5_rxq_obj_hairpin_new doesn't alloc the
> cq anymore. When releasing it, don't check it.
>
> Fixes: e79c9be91515 ("net/mlx5: support Rx hairpin queues")
> Cc: Ori Kam
> Signed-off-by: Tonghao Zhang
> ---
> drivers/net/mlx5/mlx5_rxq.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/mlx5/mlx5_rxq.c b/drivers/net/mlx5/mlx5_rxq.c
> index 2a12d5fa3436..582a2330e575 100644
> --- a/drivers/net/mlx5/mlx5_rxq.c
> +++ b/drivers/net/mlx5/mlx5_rxq.c
> @@ -673,7 +673,6 @@ mlx5_rxq_obj_release(struct mlx5_rxq_obj
> *rxq_obj)
> assert(rxq_obj);
> if (rxq_obj->type == MLX5_RXQ_OBJ_TYPE_IBV)
> assert(rxq_obj->wq);
> - assert(rxq_obj->cq);
> if (rte_atomic32_dec_and_test(&rxq_obj->refcnt)) {
> switch (rxq_obj->type) {
> case MLX5_RXQ_OBJ_TYPE_IBV:
> --
> 2.23.0
Re: [dpdk-dev] [dpdk-stable] [PATCH v2] ethdev: limit maximum number of queues
27/11/2019 15:47, David Marchand:
> On Wed, Nov 27, 2019 at 3:31 PM Thomas Monjalon wrote:
> >
> > A buffer overflow happens in testpmd with some drivers
> > since the queue arrays are limited to RTE_MAX_QUEUES_PER_PORT.
> >
> > The advertised capabilities of mlx4, mlx5 and softnic
> > for the number of queues were the maximum number: UINT16_MAX.
> > They must be limited by the configured RTE_MAX_QUEUES_PER_PORT
> > that applications expect to be respected.
> >
> > The limitation is applied at ethdev level (function rte_eth_dev_info_get),
> > in order to force the configured limit for all drivers.
> >
> > Fixes: 14b53e27b30e ("ethdev: fix crash with multiprocess")
> > Cc: sta...@dpdk.org
> >
> > Reported-by: Raslan Darawsheh
> > Signed-off-by: Thomas Monjalon
> > Reviewed-by: Ferruh Yigit
>
> Reviewed-by: David Marchand
Applied
Re: [dpdk-dev] Jumbo Frame in pktgen & dpdk-pktgen
> On Nov 26, 2019, at 2:21 AM, Nirmal Sarkar wrote: > > Hello, > > To support Jumbo frame in dpdk-pktgen, changes were suggested in dpdk > libraries also apart from pktgen code. > lib/librte_mbuf/rte_mbuf.h > lib/common/pg_inet.h > > But dpdk framework already supports jumbo frame [using --enable-jumbo & > --max-pkt-len flag]. > Can you please help me to understand why do we need to change the libraries > in dpdk ? These flags are for l3fwd type example apps and not a flag in the EAL or core code. It appears the the port configs needs to be changed to enable jumbo frames. The patch below seemed to work for Lee and I have not tried the patch changes. > > Regards, > N. Sarkar > > On Thu, Nov 21, 2019 at 12:24 AM Wiles, Keith wrote: > > > > On Nov 20, 2019, at 6:09 AM, Nirmal Sarkar wrote: > > > > Hello, > > > > Thanks for the help. > > As I'm using DPDK-18.11.1, I did not find the definition of > > "RTE_ETHER_MAX_LEN" in lib/librte_net/rte_ether.h file. > > So I set "ETHER_MAX_LEN" value to 9600. > > Apart from that I took rest of the changes and with these I'm able to send > > jumbo frame. > > Took tcpdump on the receiving end. > > > > Suddenly I got stuck at ARP. I could not send packets anymore. > > Sorry, I can not tell what the error condition is you are hitting, as the two > screen dumps do not provide me where I should start looking. If you can help > me understand the issue better. > > > > I've attached success & failure scenario. > > > > Regards, > > N. Sarkar > > > > On Wed, Nov 20, 2019 at 2:14 AM Morten Brørup > > wrote: > > > >> John, Marko, > >> > >> It seems we are missing documentation about enabling Jumbo frames in an > >> application, and possibly an example of using the > >> rte_eth_dev_info->max_mtu. > >> > >> > >> Med venlig hilsen / kind regards > >> - Morten Brørup > >> > >>> -Original Message- > >>> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Roberts, Lee A. > >>> Sent: Tuesday, November 19, 2019 6:42 PM > >>> To: Nirmal Sarkar; dev@dpdk.org > >>> Subject: Re: [dpdk-dev] Jumbo Frame in pktgen & dpdk-pktgen > >>> > >>> Nirmal, > >>> > >>> Here are the changes that I've been using to allow jumbo frames with > >> dpdk- > >>> 19.08 and > >>> pktgen-19.10.0: > >>> > >>> diff -r default/dpdk-19.08/lib/librte_mbuf/rte_mbuf.h jumbo/dpdk- > >>> 19.08/lib/librte_mbuf/rte_mbuf.h > >>> 462c462 > >>> < #define RTE_MBUF_DEFAULT_DATAROOM 2048 > >>> --- > #define RTE_MBUF_DEFAULT_DATAROOM 9600 > >>> diff -r default/dpdk-19.08/lib/librte_net/rte_ether.h jumbo/dpdk- > >>> 19.08/lib/librte_net/rte_ether.h > >>> 33c33 > >>> < #define RTE_ETHER_MAX_LEN 1518 /**< Maximum frame len, including > >> CRC. > >>> */ > >>> --- > #define RTE_ETHER_MAX_LEN 9600 /**< Maximum frame len, including > >> CRC. > >>> */ > >>> diff -r default/pktgen-19.10.0/app/pktgen.c jumbo/pktgen- > >>> 19.10.0/app/pktgen.c > >>> 749c749 > >>> < else if ( (plen >= 1024) && (plen <= PG_ETHER_MAX_LEN)) > >>> --- > else if ( (plen >= 1024) && (plen <= 1518)) > >>> 753c753 > >>> < else if (plen > PG_ETHER_MAX_LEN) > >>> --- > else if (plen > 1518) > >>> diff -r default/pktgen-19.10.0/lib/common/pg_inet.h jumbo/pktgen- > >>> 19.10.0/lib/common/pg_inet.h > >>> 379,380c379,380 > >>> < #define ETH_MTU 1500/* Max MTU for Ethernet */ > >>> < #define ETH_MAX_PKT 1518/* Max Ethernet frame size > >> */ > >>> --- > #define ETH_MTU 9600/* Max MTU for Ethernet */ > #define ETH_MAX_PKT 9600/* Max Ethernet frame size > >> */ > >>> > >>> - Lee Roberts > >>> > >>> > >>> -Original Message- > >>> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Nirmal Sarkar > >>> Sent: Monday, November 18, 2019 10:26 AM > >>> To: dev@dpdk.org > >>> Subject: [dpdk-dev] Jumbo Frame in pktgen & dpdk-pktgen > >>> > >>> Hello, > >>> > >>> I'm trying to explore pktgen and dpdk-pktgen with Jumbo frame. > >>> > >>> I'm using ubuntu-18.04 system where pktgen is a kernel module and I don't > >>> have any provision to set it for Jumbo frame. > >>> Can you please suggest how to configure Jumbo frame in pktgen ? > >>> > >>> In dpdk source code, I've modified RTE_MBUF_DEFAULT_DATAROOM [ > >>> *lib/librte_mbuf/rte_mbuf.h*] value with 9K and built. > >>> During testing, I could not send packet size more than 1500 byte. > >>> What is the suggestion to overcome this problem ? > >>> > >>> Regards, > >>> N. Sarkar > >> > > > > Regards, > Keith > Regards, Keith
Re: [dpdk-dev] [PATCH v2] net/mlx5: fix default mark copy flow
27/11/2019 14:45, Ori Kam:
> From: Viacheslav Ovsiienko
> Sent: Wednesday, November 27, 2019 3:37 PM
>
> > In extensive metadata mode the MARK copy table is engaged,
> > if the application creates the flow with zero MARK ID action:
> >
> > flow create 1 ingress pattern eth / ... / end actions mark id 0 / .. end
> >
> > And then destroys that, the traffic to the port stops. This happens
> > due to default flow for the copy table has the zero ID and is removed
> > with the application rule. The patch extends internal ID variable
> > to 64 bits and provide the UINT64_MAX ID for the copy table default
> > rule.
> >
> > Fixes: dd3c774f6ffb ("net/mlx5: add metadata register copy table")
> >
> > Signed-off-by: Viacheslav Ovsiienko
> Acked-by: Ori Kam
Applied, thanks
[dpdk-dev] [PATCH] doc: use the latest numactl release
Previous versions of numactl may produce the following error on some systems (at least on Fedora 30 and RHEL7.4): ./.libs/libnuma.so: undefined reference to `minor' ./.libs/libnuma.so: undefined reference to `major' collect2: error: ld returned 1 exit status This was fixed in upstream commit: https://github.com/numactl/numactl/commit/25691a084a2012a339395ade567dbae814e237e9 The fix is available in v2.0.13. Signed-off-by: Ali Alnubani --- doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst b/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst index e799b0ba4..e47218af9 100644 --- a/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst +++ b/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst @@ -50,7 +50,7 @@ NUMA is required by most modern machines, not needed for non-NUMA architectures. git clone https://github.com/numactl/numactl.git cd numactl - git checkout v2.0.11 -b v2.0.11 + git checkout v2.0.13 -b v2.0.13 ./autogen.sh autoconf -i ./configure --host=aarch64-linux-gnu CC=aarch64-linux-gnu-gcc --prefix= -- 2.24.0
Re: [dpdk-dev] [PATCH] net/mlx5: fix legacy non-inline multi-packet performance
27/11/2019 14:53, Matan Azrad:
> From: Viacheslav Ovsiienko
> > The legacy multi-packet write is the feature allowing to put multiple
> > packets
> > into one transmitting descriptor, this feature is supported by only NIC
> > ConnectX-4LX.
> > The number of packets should be limited to provide optimal size descriptor
> > and better performance.
> >
> > Fixes: 18a1c20044c0 ("net/mlx5: implement Tx burst template")
> >
> > Signed-off-by: Viacheslav Ovsiienko
> Acked-by: Matan Azrad
Applied, thanks
Re: [dpdk-dev] [PATCH] net/mlx5: fix legacy inline multi-packet performance
27/11/2019 14:54, Matan Azrad:
> From: Viacheslav Ovsiienko
> > The legacy multi-packet write is the feature allowing to put multiple
> > packets
> > into one transmitting descriptor, this feature is supported by only NIC
> > ConnectX-4LX.
> > The number of packets should be limited to provide optimal size descriptor
> > and better performance.
> >
> > Fixes: 18a1c20044c0 ("net/mlx5: implement Tx burst template")
> >
> > Signed-off-by: Viacheslav Ovsiienko
> Acked-by: Matan Azrad
Applied, thanks
Re: [dpdk-dev] [PATCH 2/2] doc: add pkg-config-aarch64-linux-gnu as a prerequisite
> -Original Message- > From: Bruce Richardson > Sent: Tuesday, November 26, 2019 2:01 PM > To: Ali Alnubani > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 2/2] doc: add pkg-config-aarch64-linux-gnu > as a prerequisite > > On Tue, Nov 26, 2019 at 10:41:08AM +, Ali Alnubani wrote: > > Hi Bruce, > > > > > -Original Message- > > > From: Bruce Richardson > > > Sent: Tuesday, November 26, 2019 11:52 AM > > > To: Ali Alnubani > > > Cc: dev@dpdk.org > > > Subject: Re: [dpdk-dev] [PATCH 2/2] doc: add > > > pkg-config-aarch64-linux-gnu as a prerequisite > > > > > > On Tue, Nov 26, 2019 at 08:14:25AM +, Ali Alnubani wrote: > > > > The package pkg-config-aarch64-linux-gnu is required with meson > > > > for detecting dependencies installed in nonstandard paths. > > > > > > > > Signed-off-by: Ali Alnubani > > > > --- > > > > doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst | 8 > > > > 1 file changed, 8 insertions(+) > > > > > > > > diff --git a/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst > > > > b/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst > > > > index e799b0ba4..f00f9b130 100644 > > > > --- a/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst > > > > +++ b/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst > > > > @@ -122,6 +122,14 @@ To compile for non-NUMA targets, without > > > > compiling the kernel modules, use the f Meson Cross Compiling > > > > DPDK > > > > -- > > > > > > > > +Meson depends on pkgconfig to find the dependencies that are > > > > +installed in nonstandard paths. The package > > > > +`pkg-config-aarch64-linux-gnu` is required in this case. To > > > > +install it in > > > Ubuntu: > > > > + > > > > +.. code-block:: console > > > > + > > > > + sudo apt-get install pkg-config-aarch64-linux-gnu > > > > + > > > > To cross-compile DPDK on a desired target machine we can use the > > > > following > > > > command:: > > > > > > Is there a package for Fedora or similar Redhat-derived distros? > > > > I don't think it's available. Should I add instructions on how to cross > > build it > instead of the apt-get example? > > > I think you might need both. Distro-instructions is probably best, but there > are a lot of people not using Ubuntu, I suspect. > > Following patch 1, if pkg-config is added to all the cross-build files, does > that > prevent previously working cross-builds from passing due to the lack of the > pkg-config package? Do the travis jobs need updating, for example? Cross compiling pkg-config from source requires glib, which in turn requires other packages (libffi and pcre). Do we want to add instructions to cross build that dependency tree? I opened a pull request to the Github mirror to make sure I didn't break the CI: https://github.com/DPDK/dpdk/pull/14 If the binary 'aarch64-linux-gnu-pkg-config' isn't found, Meson seems to just show the following warnings, but it doesn't fail with error: ''' Did not find pkg-config by name 'aarch64-linux-gnu-pkg-config' Found Pkg-config: NO ''' I'll send v2 with an additional patch to add the package to the list of requirements for Travis's environment. > > /Bruce - Ali
Re: [dpdk-dev] [PATCH 2/2] doc: add pkg-config-aarch64-linux-gnu as a prerequisite
On Wed, Nov 27, 2019 at 03:54:55PM +, Ali Alnubani wrote: > > -Original Message- > > From: Bruce Richardson > > Sent: Tuesday, November 26, 2019 2:01 PM > > To: Ali Alnubani > > Cc: dev@dpdk.org > > Subject: Re: [dpdk-dev] [PATCH 2/2] doc: add pkg-config-aarch64-linux-gnu > > as a prerequisite > > > > On Tue, Nov 26, 2019 at 10:41:08AM +, Ali Alnubani wrote: > > > Hi Bruce, > > > > > > > -Original Message- > > > > From: Bruce Richardson > > > > Sent: Tuesday, November 26, 2019 11:52 AM > > > > To: Ali Alnubani > > > > Cc: dev@dpdk.org > > > > Subject: Re: [dpdk-dev] [PATCH 2/2] doc: add > > > > pkg-config-aarch64-linux-gnu as a prerequisite > > > > > > > > On Tue, Nov 26, 2019 at 08:14:25AM +, Ali Alnubani wrote: > > > > > The package pkg-config-aarch64-linux-gnu is required with meson > > > > > for detecting dependencies installed in nonstandard paths. > > > > > > > > > > Signed-off-by: Ali Alnubani > > > > > --- > > > > > doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst | 8 > > > > > 1 file changed, 8 insertions(+) > > > > > > > > > > diff --git a/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst > > > > > b/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst > > > > > index e799b0ba4..f00f9b130 100644 > > > > > --- a/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst > > > > > +++ b/doc/guides/linux_gsg/cross_build_dpdk_for_arm64.rst > > > > > @@ -122,6 +122,14 @@ To compile for non-NUMA targets, without > > > > > compiling the kernel modules, use the f Meson Cross Compiling > > > > > DPDK > > > > > -- > > > > > > > > > > +Meson depends on pkgconfig to find the dependencies that are > > > > > +installed in nonstandard paths. The package > > > > > +`pkg-config-aarch64-linux-gnu` is required in this case. To > > > > > +install it in > > > > Ubuntu: > > > > > + > > > > > +.. code-block:: console > > > > > + > > > > > + sudo apt-get install pkg-config-aarch64-linux-gnu > > > > > + > > > > > To cross-compile DPDK on a desired target machine we can use the > > > > > following > > > > > command:: > > > > > > > > Is there a package for Fedora or similar Redhat-derived distros? > > > > > > I don't think it's available. Should I add instructions on how to cross > > > build it > > instead of the apt-get example? > > > > > I think you might need both. Distro-instructions is probably best, but there > > are a lot of people not using Ubuntu, I suspect. > > > > Following patch 1, if pkg-config is added to all the cross-build files, > > does that > > prevent previously working cross-builds from passing due to the lack of the > > pkg-config package? Do the travis jobs need updating, for example? > > Cross compiling pkg-config from source requires glib, which in turn requires > other packages (libffi and pcre). > Do we want to add instructions to cross build that dependency tree? > > I opened a pull request to the Github mirror to make sure I didn't break the > CI: > https://github.com/DPDK/dpdk/pull/14 > If the binary 'aarch64-linux-gnu-pkg-config' isn't found, Meson seems to just > show the following warnings, but it doesn't fail with error: > ''' > Did not find pkg-config by name 'aarch64-linux-gnu-pkg-config' > Found Pkg-config: NO > ''' > > I'll send v2 with an additional patch to add the package to the list of > requirements for Travis's environment. > > So long as is doesn't break something that was previously working I'm ok with this set.
Re: [dpdk-dev] [PATCH 1/2] config: set the pkgconfig executable
On Tue, Nov 26, 2019 at 08:14:22AM +, Ali Alnubani wrote: > Meson fails to find a pkg-config executable if pkgconfig > isn't set for aarch64. The environment variable `PKG_CONFIG_PATH` > is useless in this case, and meson fails to locate dependencies > that are built in non-standard paths. > > Signed-off-by: Ali Alnubani > --- > config/arm/arm64_armada_linux_gcc| 1 + > config/arm/arm64_armv8_linux_gcc | 1 + > config/arm/arm64_bluefield_linux_gcc | 1 + > config/arm/arm64_dpaa_linux_gcc | 1 + > config/arm/arm64_emag_linux_gcc | 1 + > config/arm/arm64_n1sdp_linux_gcc | 1 + > config/arm/arm64_octeontx2_linux_gcc | 1 + > config/arm/arm64_thunderx2_linux_gcc | 1 + > config/arm/arm64_thunderx_linux_gcc | 1 + > 9 files changed, 9 insertions(+) > Based off discussion on patch 2 thread: Series Acked-by: Bruce Richardson
[dpdk-dev] [Bug 372] ixgbevf: cannot probe or start port if PF link is unstable
https://bugs.dpdk.org/show_bug.cgi?id=372
Bug ID: 372
Summary: ixgbevf: cannot probe or start port if PF link is
unstable
Product: DPDK
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: major
Priority: Normal
Component: ethdev
Assignee: dev@dpdk.org
Reporter: julien.meun...@nokia.com
Target Milestone: ---
Created attachment 76
--> https://bugs.dpdk.org/attachment.cgi?id=76&action=edit
ixgbevf: debug mbx during init
Configuration
=
Kernel: 4.19
NIC: Intel Niantic X550
PF driver: Kernel ixgbe v.5.1.0
SRIO-V: enabled
DPDK version: v18.05 - v19.11-rc4
Detail Test Steps
=
- Set PF up::
ip link set dev eth0 up
- Export 16 VF::
echo 16 > /sys/class/net/eth0/device/sriov_numvfs
- Configure MAC of the VF::
for i in {0..16}; do ip link set dev eth0 vf $i mac 00:11:22:33:44:${i}; done
- Bind it to igb_uio (example: 04:10.0 ...)::
dpdk-devbind -b igb_uio 04:10.0 04:10.2 04:10.4 04:10.6 04:11.0 \
04:11.2 04:11.4 04:11.6 04:12.0 04:12.2 04:12.4 04:12.6 04:13.0 \
04:13.2 04:13.4 04:13.6
- PF is UP, but physical link changes status each seconds (UP / DOWN)
- Start a DPDK application (example: testpmd) when link is unstable::
testpmd -w 04:10.0 -w 04:10.2 -w 04:10.4 -w 04:10.6 \
-w 04:11.0 -w 04:11.2 -w 04:11.4 -w 04:11.6 \
-w 04:12.0 -w 04:12.2 -w 04:12.4 -w 04:12.6 \
-w 04:13.0 -w 04:13.2 -w 04:13.4 -w 04:13.6 -- -i --no-mlockall
Expected Result
===
No issue during EAL init or during rte_eth_dev_start when link changes its
status.
Actual Result
=
Issue during the EAL init::
EAL: PCI device :04:10.0 on NUMA socket 0
EAL: probe driver: 8086:15a8 net_ixgbe_vf
EAL: Requested device :04:10.0 cannot be used
Issue during the rte_eth_dev_start::
ixgbevf_dev_start(): Unable to reset vf hardware (-10)
No issue if link status is stable during the init
Workaround
==
- Application has to probe again the same device
- Application has to start again the same port
Analysis
I added some traces in ixgbe_reset_hw_vf in order to dump the content of the
mailbox. (see attachment)
When VF is correctly initialized:
ixgbe_reset_hw_vf: jmeunier - msgbuf[0] = 8001
=> (IXGBE_VF_RESET | IXGBE_VT_MSGTYPE_ACK)
When VF is NOT correctly initialized:
ixgbe_reset_hw_vf: jmeunier - msgbuf[0] = 2100
=> (IXGBE_VT_MSGTYPE_CTS | IXGBE_PF_CONTROL_MSG)
An invalid message is received in the mailbox during the initialization.
This message seems to be sent by the PF to notify that the link has changed its
status.
According to the current implementation (on Kernel side), when link status
changes, PF notifies
all associated VFs through the mailbox::
ixgbe_watchdog_link_is_up => ixgbe_ping_all_vfs => ixgbe_write_mbx(hw,
&ping, 1, i)
So, if VF waits for one specific message, if link changes at the same time, VF
will read an invalid message.
In this PR, it's IXGBE_VF_RESET, but I can see others cases like that in the
current PF/VF implementation.
BTW, I suspect that Kernel overwrites the mailbox message (to be confirmed)
--
You are receiving this mail because:
You are the assignee for the bug.
[dpdk-dev] [PATCH] examples/tep_termination: resolve unchecked return value
resolve the unchecked return value from the function
rte_eth_dev_info_get.
Coverity issue: 349922
Signed-off-by: Shashank T D
---
examples/tep_termination/vxlan_setup.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/examples/tep_termination/vxlan_setup.c
b/examples/tep_termination/vxlan_setup.c
index eca119a72..384b3167e 100644
--- a/examples/tep_termination/vxlan_setup.c
+++ b/examples/tep_termination/vxlan_setup.c
@@ -195,7 +195,12 @@ vxlan_port_init(uint16_t port, struct rte_mempool
*mbuf_pool)
if (tso_segsz != 0) {
struct rte_eth_dev_info dev_info;
- rte_eth_dev_info_get(port, &dev_info);
+ retval = rte_eth_dev_info_get(port, &dev_info);
+ if (retval != 0)
+ rte_exit(EXIT_FAILURE,
+ "Error during getting device (port %u) info:
%s\n",
+ port, strerror(-retval));
+
if ((dev_info.tx_offload_capa & DEV_TX_OFFLOAD_TCP_TSO) == 0)
RTE_LOG(WARNING, PORT,
"hardware TSO offload is not supported\n");
--
2.17.1
[dpdk-dev] [PATCH v2] examples/tep_termination: resolve unchecked return value
This patch checked the return value of rte_eth_dev_info_get function.
Coverity issue: 349922
Signed-off-by: Shashank T D
---
examples/tep_termination/vxlan_setup.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/examples/tep_termination/vxlan_setup.c
b/examples/tep_termination/vxlan_setup.c
index eca119a72..384b3167e 100644
--- a/examples/tep_termination/vxlan_setup.c
+++ b/examples/tep_termination/vxlan_setup.c
@@ -195,7 +195,12 @@ vxlan_port_init(uint16_t port, struct rte_mempool
*mbuf_pool)
if (tso_segsz != 0) {
struct rte_eth_dev_info dev_info;
- rte_eth_dev_info_get(port, &dev_info);
+ retval = rte_eth_dev_info_get(port, &dev_info);
+ if (retval != 0)
+ rte_exit(EXIT_FAILURE,
+ "Error during getting device (port %u) info:
%s\n",
+ port, strerror(-retval));
+
if ((dev_info.tx_offload_capa & DEV_TX_OFFLOAD_TCP_TSO) == 0)
RTE_LOG(WARNING, PORT,
"hardware TSO offload is not supported\n");
--
2.17.1
Re: [dpdk-dev] [PATCH v2] event/octeontx: fix partial Rx packet handling
27/11/2019 14:32, Jerin Jacob:
> On Wed, Nov 27, 2019 at 9:36 PM wrote:
> >
> > From: Pavan Nikhilesh
> >
> > When net/octeontx is connected to event/octeontx as an event Rx adapter,
> > PKI aka 'net/octeontx' can forward packets directly to SSO aka
> > 'event/octeontx'.
> > When pumping traffic to PKI if flow control is disabled internal FIFOs
> > might be overrun causing partial l2 packets to be enqueued.
> > SSO receives <31:0> TAG tag calculated by PKI, in normal cases <31:28>
> > is always 0 which signifies RTE_EVENT_TYPE_ETHDEV. But in case of
> > partial received packets PKI sets the <31:0> TAG as 0x which
> > is an invalid event type.
> >
> > Add a check to see if TAG is 0x and free the partial receive
> > packet.
> >
> > Cc: sta...@dpdk.org
> > Fixes: d0d654986018 ("net/octeontx: support event Rx adapter")
>
> Corrected the Cc: order.
>
> >
> > Signed-off-by: Pavan Nikhilesh
>
> Acked-by: Jerin Jacob
> Applied to dpdk-next-eventdev/master. Thanks.
>
> @Thomas, It is possible to pull this patch from next-eventdev?
Applied, thanks
Re: [dpdk-dev] [dpdk-stable] [PATCH] test/service: fix wait for service core
On Wed, Nov 27, 2019 at 3:16 PM Van Haaren, Harry
wrote:
>
> > -Original Message-
> > From: Aaron Conole
> > Sent: Wednesday, November 27, 2019 2:10 PM
> > To: Van Haaren, Harry
> > Cc: dev@dpdk.org
> > Subject: Re: [PATCH] test/service: fix wait for service core
> >
> > Harry van Haaren writes:
> >
> > > This commit fixes a sporadic failure of the service_autotest
> > > unit test, as seen in the DPDK CI. The failure occurs as the main test
> > > thread did not wait on the service-thread to return, and allowing it
> > > to read a flag before the service was able to write to it.
> > >
> > > The fix changes the wait API call to specific the service-core ID,
> > > and this waits for cores with both ROLE_RTE and ROLE_SERVICE.
> > >
> > > The rte_eal_mp_wait_lcore() call does not (and should not) wait
> > > for service cores, so must not be used to wait on service-cores.
> > >
> > > Fixes: f038a81e1c56 ("service: add unit tests")
> > >
> > > Reported-by: Aaron Conole
> > > Signed-off-by: Harry van Haaren
> > >
> > > ---
> >
> > It might also be good to document this behavior in the API area. It's
> > unclear that the lcore wait function which takes a core id will work,
> > but the broad wait will not.
>
> Yes agreed that docs can improve here - different patch.
>
>
> > > Given this is a fix in the unit test, and not a functional change
> > > I'm not sure its worth backporting to LTS / stable releases?
> > > I've not added stable on CC yet.
> >
> > I think it's worth it if the LTS / stable branches use the unit tests
> > (otherwise, they will observe sporadic failures).
>
> Ok, I've added sta...@dpdk.org on CC now
>
>
> > > app/test/test_service_cores.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/app/test/test_service_cores.c b/app/test/test_service_cores.c
> > > index 9fe38f5e0..a922c7ddc 100644
> > > --- a/app/test/test_service_cores.c
> > > +++ b/app/test/test_service_cores.c
> > > @@ -483,7 +483,7 @@ service_lcore_en_dis_able(void)
> > > int ret = rte_eal_remote_launch(service_remote_launch_func, NULL,
> > > slcore_id);
> > > TEST_ASSERT_EQUAL(0, ret, "Ex-service core remote launch failed.");
> > > - rte_eal_mp_wait_lcore();
> > > + rte_eal_wait_lcore(slcore_id);
> > > TEST_ASSERT_EQUAL(1, service_remote_launch_flag,
> > > "Ex-service core function call had no effect.");
> >
> > Should we also have some change like the following (just a guess):
> >
> > diff --git a/app/test/test_service_cores.c b/app/test/test_service_cores.c
> > index 9fe38f5e08..695c35ac6c 100644
> > --- a/app/test/test_service_cores.c
> > +++ b/app/test/test_service_cores.c
> > @@ -773,7 +773,7 @@ service_app_lcore_poll_impl(const int mt_safe)
> >
> > /* flag done, then wait for the spawned 2nd core to return */
> > params[0] = 1;
> > - rte_eal_mp_wait_lcore();
> > + rte_eal_wait_lcore(app_core2);
> >
> > /* core two gets launched first - and should hold the service lock */
> > TEST_ASSERT_EQUAL(0, app_core2_ret,
>
>
> I reviewed this usage of the function, and I believe it waits on application
> cores (aka, ROLE_RTE, not ROLE_SERVICE). Hence this usage is actually correct.
> Please review and double check my logic though - more eyes is good.
>
I will check it later tonight but I am for taking this in 19.11 if we
can get more stable tests.
Aaron, do you have an objection?
--
David Marchand
Re: [dpdk-dev] [dpdk-announce] release candidate 19.11-rc4
On 11/26/2019 11:56 PM, Thomas Monjalon wrote: A new DPDK release candidate is ready for testing: https://git.dpdk.org/dpdk/tag/?id=v19.11-rc4 93 patches were integrated. The release notes so far: http://doc.dpdk.org/guides/rel_notes/release_19_11.html It should be completed with a list of tested hardware. This is the last release candidate for DPDK 19.11. After -rc4 only critical bug fixes and doc updates should be accepted. The major release should be done in a couple of days (Thanksgiving?). Please share some release validation results by replying to this message (at dev@dpdk.org). Hi Thomas, OVS validation completed by Intel on RC4 below. * vswitch_p2p_tput: vSwitch - configure switch and execute RFC2544 throughput test. * vswitch_p2p_cont: vSwitch - configure switch and execute RFC2544 continuous stream test. * vswitch_pvp_tput: vSwitch - configure switch, vnf and execute RFC2544 throughput test. * vswitch_pvp_cont: vSwitch - configure switch, vnf and execute RFC2544 continuous stream test. * ovsdpdk_hotplug_attach: Ensure successful port-add after binding a device to igb_uio after ovs-vswitchd is launched. * ovsdpdk_mq_p2p_rxqs: Setup rxqs on NIC port. * ovsdpdk_mq_pvp_rxqs: Setup rxqs on vhost user port. * ovsdpdk_mq_pvp_rxqs_linux_bridge: Confirm traffic received over vhost RXQs with Linux virtio device in guest. * ovsdpdk_mq_pvp_rxqs_testpmd: Confirm traffic received over vhost RXQs with DPDK device in guest. * ovsdpdk_vhostuser_client: Test vhost-user client mode. * ovsdpdk_vhostuser_client_reconnect: Test vhost-user client mode reconnect feature. * ovsdpdk_vhostuser_server: Test vhost-user server mode. * ovsdpdk_vhostuser_sock_dir: Verify functionality of vhost-sock-dir flag. * ovsdpdk_vdev_add_af_packet_pmd: Test addition of port using the af_packet DPDK PMD driver. * ovsdpdk_vdev_del_af_packet_pmd: Test deletion of port using the af_packet DPDK PMD driver. * ovsdpdk_numa: Test vhost-user NUMA support. Vhostuser PMD threads should migrate to the same numa slot, where QEMU is executed. * ovsdpdk_jumbo_p2p: Ensure that jumbo frames are received, processed and forwarded correctly by DPDK physical ports. * ovsdpdk_jumbo_pvp: Ensure that jumbo frames are received, processed and forwarded correctly by DPDK vhost-user ports. * ovsdpdk_jumbo_p2p_upper_bound: Ensure that jumbo frames above the configured Rx port's MTU are not accepted. * ovsdpdk_jumbo_mtu_upper_bound_vport: Verify that the upper bound limit is enforced for OvS DPDK vhost-user ports. * ovsdpdk_rate_p2p: Ensure when a user creates a rate limiting physical interface that the traffic is limited to the specified policer rate in a p2p setup. * ovsdpdk_rate_pvp: Ensure when a user creates a rate limiting vHost User interface that the traffic is limited to the specified policer rate in a pvp setup. * ovsdpdk_qos_p2p: In a p2p setup, ensure when a QoS egress policer is created that the traffic is limited to the specified rate. * ovsdpdk_qos_pvp: In a pvp setup, ensure when a QoS egress policer is created that the traffic is limited to the specified rate. * phy2phy_scalability: LTD.Scalability.Flows.RFC2544.0PacketLoss * phy2phy_scalability_cont: Phy2Phy Scalability Continuous Stream * pvp_cont: PVP Continuous Stream * pvvp_cont: PVVP Continuous Stream * pvpv_cont: Two VMs in parallel with Continuous Stream * VFIO validation These were carried out for ixgbe (ixgbe_vf), i40e (i40e_vf) and ice pmds. Regards Ian If you are preparing the next release cycle, please send your v1 patches before the 20.02 proposal deadline, which will happen on December 6th. It is also time to build an estimated roadmap for the next cycles. Thank you everyone
Re: [dpdk-dev] [dpdk-stable] [PATCH] test/service: fix wait for service core
David Marchand writes:
> On Wed, Nov 27, 2019 at 3:16 PM Van Haaren, Harry
> wrote:
>>
>> > -Original Message-
>> > From: Aaron Conole
>> > Sent: Wednesday, November 27, 2019 2:10 PM
>> > To: Van Haaren, Harry
>> > Cc: dev@dpdk.org
>> > Subject: Re: [PATCH] test/service: fix wait for service core
>> >
>> > Harry van Haaren writes:
>> >
>> > > This commit fixes a sporadic failure of the service_autotest
>> > > unit test, as seen in the DPDK CI. The failure occurs as the main test
>> > > thread did not wait on the service-thread to return, and allowing it
>> > > to read a flag before the service was able to write to it.
>> > >
>> > > The fix changes the wait API call to specific the service-core ID,
>> > > and this waits for cores with both ROLE_RTE and ROLE_SERVICE.
>> > >
>> > > The rte_eal_mp_wait_lcore() call does not (and should not) wait
>> > > for service cores, so must not be used to wait on service-cores.
>> > >
>> > > Fixes: f038a81e1c56 ("service: add unit tests")
>> > >
>> > > Reported-by: Aaron Conole
>> > > Signed-off-by: Harry van Haaren
>> > >
>> > > ---
>> >
>> > It might also be good to document this behavior in the API area. It's
>> > unclear that the lcore wait function which takes a core id will work,
>> > but the broad wait will not.
>>
>> Yes agreed that docs can improve here - different patch.
>>
>>
>> > > Given this is a fix in the unit test, and not a functional change
>> > > I'm not sure its worth backporting to LTS / stable releases?
>> > > I've not added stable on CC yet.
>> >
>> > I think it's worth it if the LTS / stable branches use the unit tests
>> > (otherwise, they will observe sporadic failures).
>>
>> Ok, I've added sta...@dpdk.org on CC now
>>
>>
>> > > app/test/test_service_cores.c | 2 +-
>> > > 1 file changed, 1 insertion(+), 1 deletion(-)
>> > >
>> > > diff --git a/app/test/test_service_cores.c
>> > > b/app/test/test_service_cores.c
>> > > index 9fe38f5e0..a922c7ddc 100644
>> > > --- a/app/test/test_service_cores.c
>> > > +++ b/app/test/test_service_cores.c
>> > > @@ -483,7 +483,7 @@ service_lcore_en_dis_able(void)
>> > > int ret = rte_eal_remote_launch(service_remote_launch_func, NULL,
>> > > slcore_id);
>> > > TEST_ASSERT_EQUAL(0, ret, "Ex-service core remote launch failed.");
>> > > - rte_eal_mp_wait_lcore();
>> > > + rte_eal_wait_lcore(slcore_id);
>> > > TEST_ASSERT_EQUAL(1, service_remote_launch_flag,
>> > > "Ex-service core function call had no effect.");
>> >
>> > Should we also have some change like the following (just a guess):
>> >
>> > diff --git a/app/test/test_service_cores.c b/app/test/test_service_cores.c
>> > index 9fe38f5e08..695c35ac6c 100644
>> > --- a/app/test/test_service_cores.c
>> > +++ b/app/test/test_service_cores.c
>> > @@ -773,7 +773,7 @@ service_app_lcore_poll_impl(const int mt_safe)
>> >
>> > /* flag done, then wait for the spawned 2nd core to return */
>> > params[0] = 1;
>> > - rte_eal_mp_wait_lcore();
>> > + rte_eal_wait_lcore(app_core2);
>> >
>> > /* core two gets launched first - and should hold the service lock */
>> > TEST_ASSERT_EQUAL(0, app_core2_ret,
>>
>>
>> I reviewed this usage of the function, and I believe it waits on application
>> cores (aka, ROLE_RTE, not ROLE_SERVICE). Hence this usage is actually
>> correct.
>> Please review and double check my logic though - more eyes is good.
>>
>
> I will check it later tonight but I am for taking this in 19.11 if we
> can get more stable tests.
> Aaron, do you have an objection?
No objection
Re: [dpdk-dev] [dpdk-stable] [PATCH] test/service: fix wait for service core
On Wed, Nov 27, 2019 at 3:16 PM Van Haaren, Harry
wrote:
>
> > -Original Message-
> > From: Aaron Conole
> > Sent: Wednesday, November 27, 2019 2:10 PM
> > To: Van Haaren, Harry
> > Cc: dev@dpdk.org
> > Subject: Re: [PATCH] test/service: fix wait for service core
> >
> > Harry van Haaren writes:
> >
> > > This commit fixes a sporadic failure of the service_autotest
> > > unit test, as seen in the DPDK CI. The failure occurs as the main test
> > > thread did not wait on the service-thread to return, and allowing it
> > > to read a flag before the service was able to write to it.
> > >
> > > The fix changes the wait API call to specific the service-core ID,
> > > and this waits for cores with both ROLE_RTE and ROLE_SERVICE.
> > >
> > > The rte_eal_mp_wait_lcore() call does not (and should not) wait
> > > for service cores, so must not be used to wait on service-cores.
> > >
> > > Fixes: f038a81e1c56 ("service: add unit tests")
> > >
> > > Reported-by: Aaron Conole
> > > Signed-off-by: Harry van Haaren
> > >
> > > ---
> >
> > It might also be good to document this behavior in the API area. It's
> > unclear that the lcore wait function which takes a core id will work,
> > but the broad wait will not.
>
> Yes agreed that docs can improve here - different patch.
>
>
> > > Given this is a fix in the unit test, and not a functional change
> > > I'm not sure its worth backporting to LTS / stable releases?
> > > I've not added stable on CC yet.
> >
> > I think it's worth it if the LTS / stable branches use the unit tests
> > (otherwise, they will observe sporadic failures).
>
> Ok, I've added sta...@dpdk.org on CC now
>
>
> > > app/test/test_service_cores.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/app/test/test_service_cores.c b/app/test/test_service_cores.c
> > > index 9fe38f5e0..a922c7ddc 100644
> > > --- a/app/test/test_service_cores.c
> > > +++ b/app/test/test_service_cores.c
> > > @@ -483,7 +483,7 @@ service_lcore_en_dis_able(void)
> > > int ret = rte_eal_remote_launch(service_remote_launch_func, NULL,
> > > slcore_id);
> > > TEST_ASSERT_EQUAL(0, ret, "Ex-service core remote launch failed.");
> > > - rte_eal_mp_wait_lcore();
> > > + rte_eal_wait_lcore(slcore_id);
> > > TEST_ASSERT_EQUAL(1, service_remote_launch_flag,
> > > "Ex-service core function call had no effect.");
> >
> > Should we also have some change like the following (just a guess):
> >
> > diff --git a/app/test/test_service_cores.c b/app/test/test_service_cores.c
> > index 9fe38f5e08..695c35ac6c 100644
> > --- a/app/test/test_service_cores.c
> > +++ b/app/test/test_service_cores.c
> > @@ -773,7 +773,7 @@ service_app_lcore_poll_impl(const int mt_safe)
> >
> > /* flag done, then wait for the spawned 2nd core to return */
> > params[0] = 1;
> > - rte_eal_mp_wait_lcore();
> > + rte_eal_wait_lcore(app_core2);
> >
> > /* core two gets launched first - and should hold the service lock */
> > TEST_ASSERT_EQUAL(0, app_core2_ret,
>
>
> I reviewed this usage of the function, and I believe it waits on application
> cores (aka, ROLE_RTE, not ROLE_SERVICE). Hence this usage is actually correct.
> Please review and double check my logic though - more eyes is good.
It seems to be the case, yes.
My overall feeling is that the services stuff is a giant hack, so
better documentation will prove me wrong :-).
As I said I am for taking this change in 19.11 now, as it only impacts
this test and it seems to solve the random failures.
Acked-by: David Marchand
--
David Marchand
Re: [dpdk-dev] [RFC PATCH] mark experimental variables
On Tue, Nov 26, 2019 at 3:22 PM Neil Horman wrote:
> On Mon, Nov 25, 2019 at 05:13:14PM +0100, David Marchand wrote:
> > So far, we did not pay attention to direct access to variables but they
> > are part of the API/ABI too and should be clearly identified.
> >
> > Introduce a __rte_experimental_var tag and mark existing variables.
> >
> > Fixes: a4bcd61de82d ("buildtools: add script to check experimental API
> > exports")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: David Marchand
> > ---
> > Quick patch to try to catch experimental variables.
> > Not sure if we could use a single section, so please advise if there is
> > better to do about this.
> >
> I don't see any definition of __rte_experimental_var here, won't the
> preprocessor choke on this when you try to compile without that?
Sorry, not getting your point.
If there is an issue, then it is the same as __rte_experimental.
[snip]
> > diff --git a/lib/librte_eal/common/include/rte_compat.h
> > b/lib/librte_eal/common/include/rte_compat.h
> > index 3eb33784b..3fd05179f 100644
> > --- a/lib/librte_eal/common/include/rte_compat.h
> > +++ b/lib/librte_eal/common/include/rte_compat.h
> > @@ -11,11 +11,16 @@
> > #define __rte_experimental \
> > __attribute__((deprecated("Symbol is not yet part of stable ABI"), \
> > section(".text.experimental")))
> > +#define __rte_experimental_var \
> > +__attribute__((deprecated("Symbol is not yet part of stable ABI"), \
> > +section(".data.experimental")))
> >
> > #else
> >
> > #define __rte_experimental \
> > __attribute__((section(".text.experimental")))
> > +#define __rte_experimental_var \
> > +__attribute__((section(".data.experimental")))
> >
> > #endif
> >
--
David Marchand
Re: [dpdk-dev] [PATCH] test/service: fix wait for service core
On Wed, Nov 27, 2019 at 2:20 PM Harry van Haaren
wrote:
>
> This commit fixes a sporadic failure of the service_autotest
> unit test, as seen in the DPDK CI. The failure occurs as the main test
> thread did not wait on the service-thread to return, and allowing it
> to read a flag before the service was able to write to it.
>
> The fix changes the wait API call to specific the service-core ID,
> and this waits for cores with both ROLE_RTE and ROLE_SERVICE.
>
> The rte_eal_mp_wait_lcore() call does not (and should not) wait
> for service cores, so must not be used to wait on service-cores.
>
> Fixes: f038a81e1c56 ("service: add unit tests")
Cc: sta...@dpdk.org
>
> Reported-by: Aaron Conole
> Signed-off-by: Harry van Haaren
Acked-by: David Marchand
Before this patch, reproduced the pb in less than 2 minutes with:
# time (log=/tmp/$$.log; while true; do echo service_autotest |taskset
-c 0-1 build-gcc-static/app/test/dpdk-test --log-level *:8 -l 0-1
>$log 2>&1; grep -q 'Test OK' $log || break; done; cat $log; rm -f
$log)
With the patch, this loop has been running for 40 minutes.
Applied, thanks.
--
David Marchand
Re: [dpdk-dev] [PATCH] git: ignore more build directories
20/11/2019 10:48, David Marchand: > On Sat, Sep 14, 2019 at 5:05 PM Thomas Monjalon wrote: > > > > Build directories commonly have compiler in their names. > > In order to filter build directories not starting with "build-" > > (common with make), patterns for gcc and clang are added to .gitignore. > > > > Signed-off-by: Thomas Monjalon > > Acked-by: David Marchand Applied
[dpdk-dev] [PATCH] eal: fix unitialized data warning
Valgrind reports that eal interrupt thread is calling epoll_ctl
with uninitialized data. Trivial to fix by initializing it.
Fixes: af75078fece3 ("first public release")
Cc: sta...@dpdk.org
Signed-off-by: Stephen Hemminger
---
lib/librte_eal/linux/eal/eal_interrupts.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_eal/linux/eal/eal_interrupts.c
b/lib/librte_eal/linux/eal/eal_interrupts.c
index 1955324d3045..2cd537ba4492 100644
--- a/lib/librte_eal/linux/eal/eal_interrupts.c
+++ b/lib/librte_eal/linux/eal/eal_interrupts.c
@@ -1045,7 +1045,7 @@ eal_intr_handle_interrupts(int pfd, unsigned totalfds)
static __attribute__((noreturn)) void *
eal_intr_thread_main(__rte_unused void *arg)
{
- struct epoll_event ev;
+ struct epoll_event ev = { };
/* host thread, never break out */
for (;;) {
--
2.20.1
[dpdk-dev] [PATCH v2] devtools: control location of test builds
From: Bruce Richardson
By default, both test-build.sh and test-meson-builds.sh scripts create the
builds they generate in the current working directory, leading to a large
number of build directories being present when testing patches. This
patchset modifies both scripts to use a DPDK_BUILD_TEST_DIR environment
variable to control where the build outputs are put.
For example, doing:
export DPDK_BUILD_TEST_DIR=__builds
./devtools/test-meson-builds.sh && ./devtools/test-build.sh \
x86_64-native-linux-clang+shared i686-native-linux-gcc
gives a "__builds" directory with 14 meson and 2 make builds (with the
meson build count depending on compiler availability)
Signed-off-by: Bruce Richardson
Signed-off-by: Thomas Monjalon
---
v2:
- rename DPDK_TEST_BUILD_DIR to DPDK_BUILD_TEST_DIR
- add comment in devtools/test-build.sh and its guide section
- load from config file in test-meson-builds.sh
---
devtools/test-build.sh | 4 +++-
devtools/test-meson-builds.sh | 9 ++---
doc/guides/contributing/patches.rst | 7 +++
3 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/devtools/test-build.sh b/devtools/test-build.sh
index 2bedbdb980..f55d3120aa 100755
--- a/devtools/test-build.sh
+++ b/devtools/test-build.sh
@@ -7,6 +7,7 @@ default_path=$PATH
# Load config options:
# - ARMV8_CRYPTO_LIB_PATH
# - DPDK_BUILD_TEST_CONFIGS (defconfig1+option1+option2 defconfig2)
+# - DPDK_BUILD_TEST_DIR
# - DPDK_DEP_ARCHIVE
# - DPDK_DEP_BPF (y/[n])
# - DPDK_DEP_CFLAGS
@@ -63,6 +64,7 @@ print_help () {
[ -z $MAKE ] && echo "Cannot find make or gmake" && exit 1
J=$DPDK_MAKE_JOBS
+builds_dir=${DPDK_BUILD_TEST_DIR:-.}
short=false
unset verbose
maxerr=-Wfatal-errors
@@ -234,7 +236,7 @@ for conf in $configs ; do
. $(dirname $(readlink -f $0))/load-devel-config
options=$(echo $conf | sed 's,[^~+]*,,')
- dir=$conf
+ dir=$builds_dir/$conf
config $dir $target $options
echo "== Build $dir"
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index 07d42985e6..571deec257 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -12,8 +12,11 @@ PIPEFAIL=""
set -o | grep -q pipefail && set -o pipefail && PIPEFAIL=1
srcdir=$(dirname $(readlink -f $0))/..
+. $srcdir/devtools/load-devel-config
+
MESON=${MESON:-meson}
use_shared="--default-library=shared"
+builds_dir=${DPDK_BUILD_TEST_DIR:-.}
if command -v gmake >/dev/null 2>&1 ; then
MAKE=gmake
@@ -50,7 +53,7 @@ load_env () #
build () #
{
- builddir=$1
+ builddir=$builds_dir/$1
shift
targetcc=$1
shift
@@ -125,8 +128,8 @@ done
# Test installation of the x86-default target, to be used for checking
# the sample apps build using the pkg-config file for cflags and libs
-build_path=build-x86-default
-export DESTDIR=$(pwd)/$build_path/install-root
+build_path=$(readlink -f $builds_dir/build-x86-default)
+export DESTDIR=$build_path/install-root
$ninja_cmd -C $build_path install
load_env cc
diff --git a/doc/guides/contributing/patches.rst
b/doc/guides/contributing/patches.rst
index 2140303464..e3246aca5e 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -471,6 +471,7 @@ Examples of configs are::
The builds can be modified via the following environmental variables:
* ``DPDK_BUILD_TEST_CONFIGS`` (target1+option1+option2 target2)
+* ``DPDK_BUILD_TEST_DIR``
* ``DPDK_DEP_CFLAGS``
* ``DPDK_DEP_LDFLAGS``
* ``DPDK_DEP_PCAP`` (y/[n])
@@ -495,6 +496,12 @@ Compilation of patches is to be tested with
``devtools/test-meson-builds.sh`` sc
The script internally checks for dependencies, then builds for several
combinations of compilation configuration.
+By default, each build will be put in a subfolder of the current working
directory.
+However, if it is preferred to place the builds in a different location,
+the environment variable ``DPDK_BUILD_TEST_DIR`` can be set to that desired
location.
+For example, setting ``DPDK_BUILD_TEST_DIR=__builds`` will put all builds
+in a single subfolder called "__builds" created in the current directory.
+Setting ``DPDK_BUILD_TEST_DIR`` to an absolute directory path e.g. ``/tmp`` is
also supported.
Sending Patches
--
2.23.0
Re: [dpdk-dev] [PATCH] devtools: reset compilation flags for each target
02/10/2019 18:55, David Marchand:
> Same idea than overriding PATH and PKG_CONFIG_PATH, it can be quite
> useful to override compilation flags like CFLAGS, CPPFLAGS and LDFLAGS
> for cross compilation or libraries that won't provide a pkg-config file.
>
> Fixes: 272236741258 ("devtools: load target-specific compilation environment")
>
> Signed-off-by: David Marchand
Applied, thanks
Re: [dpdk-dev] [PATCH] devtools: check coverity and bugzilla tags
09/10/2019 15:43, Kevin Traynor: > On 08/10/2019 16:52, David Marchand wrote: > > Let's try to check for discrepancies in covery and bugzilla tags. > > s/covery/coverity/ - you are trying to fool your patch? :-) > > > The contributing guide specifies that: > > - for coverity issues, the tag is 'Coverity issue:' > > - for bugzilla issues, the tag is 'Bugzilla ID:' > > > > Self tested: > $ ./devtools/check-git-log.sh > Missing 'Coverity issue:' tag: > devtools: check coverity and bugzilla tags > Missing 'Bugzilla ID:' tag: > devtools: check coverity and bugzilla tags > > with typo fix, > Acked-by: Kevin Traynor > > > Signed-off-by: David Marchand Applied, thanks
Re: [dpdk-dev] [PATCH] maintainers: update maintainers for nfp PMD
27/11/2019 12:36, Heinrich Kuhn: > As Alejandro is no longer with Netronome we appointed two new > maintainers for the Netronome PMD > > Signed-off-by: Heinrich Kuhn Applied, thanks
Re: [dpdk-dev] [PATCH v2] MAINTAINERS: update armv8 crypto PMD maintainership
27/11/2019 09:47, Ruifeng Wang: > It is expected to update this PMD to be in line with Arm's crypto library. > Update the maintainership to refect the change. > > Signed-off-by: Ruifeng Wang > Reviewed-by: Gavin Hu > Acked-by: Jerin Jacob Applied, thanks
Re: [dpdk-dev] [PATCH v2 1/4] eal: add API to check if its interrupt context
On Wed, 27 Nov 2019 15:52:19 +0530 Sunil Kumar Kori wrote: > > +/** > + * @warning > + * @b EXPERIMENTAL: this API may change without prior notice > + * > + * Check if currently executing in interrupt context > + * > + * @return > + * - positive in case of interrupt context > + * - zero in case of process context > + * - negative if unsuccessful > + */ > +__rte_experimental > +int > +rte_thread_is_intr(void); If you only need this in drivers, it should be internal not exposed as part of API
Re: [dpdk-dev] [PATCH] doc: add info about codespell config
20/11/2019 14:27, Kevin Traynor: > Document the config to use codespell with checkpatches.sh. > > Signed-off-by: Kevin Traynor > --- > --- a/doc/guides/contributing/patches.rst > +++ b/doc/guides/contributing/patches.rst > -This, and any other configuration variables required by the development > tools, are loaded from the following > -files, in order of preference:: > + > +Spell checking of commonly misspelled words can be enabled by downloading > the codespell dictionary:: > + > + curl -o ~/dictionary.txt > https://raw.githubusercontent.com/codespell-project/codespell/master/codespell_lib/data/dictionary.txt curl command is unneeded here > + > +The path to the downloaded ``dictionary.txt`` must be set in the environment > variable ``DPDK_CHECKPATCH_CODESPELL``. > + > +Environment variables required by the development tools, are loaded from the > following files, > +in order of preference:: Applied with minor changes, thanks
Re: [dpdk-dev] [PATCH v5] doc: clarify virtio PMD path selection
27/11/2019 16:19, Yinan: > From: Yinan Wang > > Add virtio paths selection and usage introduction for better > virtio usability. > > Signed-off-by: Yinan Wang > --- > doc/guides/howto/index.rst| 1 + > .../virtio_paths_selection_and_usage.rst | 126 ++ I don't understand why this doc is added in howto guides, and not in doc/guides/nics/virtio.rst ?
Re: [dpdk-dev] [PATCH V3] doc: add tested Intel platforms with Intel NICs
27/11/2019 14:21, Chen, Zhaoyan: > From: Wenjie Li > > V3: > Use symbols from isonum.txt to optimize the doc. > > V2: > Fix some typos. > > V1: > Add tested Intel platforms with Intel NICs to v19.11 release note. > > Signed-off-by: Wenjie Li Applied, thanks Few notes: - changelog should be below --- - new version should be threaded with first patch (--in-reply-to)
Re: [dpdk-dev] [PATCH] doc: add tested Marvell integrated NIC platforms
27/11/2019 11:58, jer...@marvell.com: > From: Jerin Jacob > > Add tested Marvell integrated NIC platforms to v19.11 release note. > > Signed-off-by: Jerin Jacob Applied, thanks
Re: [dpdk-dev] [PATCH] net/nfp: replace license text with SPDX tag
27/11/2019 14:47, Heinrich Kuhn: > On 2019/09/27 10:33, hemant.agrawal at nxp.com (Hemant Agrawal) wrote: > > Signed-off-by: Hemant Agrawal > > Acked-by: Heinrich Kuhn Applied, thanks
