[dpdk-dev] [PATCH v5 0/2] update CPU flags for arm64 platform

[Wei Hu (Xavier)]

This series updates CPU flags for arm64 platform.

Wei Hu (Xavier) (2):
  eal/arm64: update CPU flags
  test/cpuflag: add new flags for ARM64 platform

 app/test/test_cpuflags.c | 39 
 lib/librte_eal/arm/include/rte_cpuflags_64.h | 13 +++
 lib/librte_eal/arm/rte_cpuflags.c| 13 +++
 3 files changed, 65 insertions(+)

-- 
2.27.0

[dpdk-dev] [PATCH v5 1/2] eal/arm64: update CPU flags

[Wei Hu (Xavier)]

From: "Wei Hu (Xavier)" 

ARM64 Linux kernel updated the CPU flags using the HWCAP scheme.
The related marco definition can be found in linux kernel:
  arch/arm64/include/uapi/asm/hwcap.h

This patch incorporates those changes to the eal library.

Signed-off-by: Chengwen Feng 
Signed-off-by: Wei Hu (Xavier) 
Reviewed-by: Ruifeng Wang 
---
v4 -> v5:
No change.
v3 -> v4:
Update commit log.
v2 -> v3:
1. Change commit log.
2. Add HWCAP2_FLAGM2 and HWCAP2_FRINT to rte_cpu_feature_table[].
3. Add the flags for newly added items into enum rte_cpu_flag_t.
v1 -> v2:
Adds more sve-related definition to rte_cpu_feature_table,
sunch as SVE2, etc.
---
 lib/librte_eal/arm/include/rte_cpuflags_64.h | 13 +
 lib/librte_eal/arm/rte_cpuflags.c| 13 +
 2 files changed, 26 insertions(+)

diff --git a/lib/librte_eal/arm/include/rte_cpuflags_64.h 
b/lib/librte_eal/arm/include/rte_cpuflags_64.h
index 95cc01474..aa7a56d49 100644
--- a/lib/librte_eal/arm/include/rte_cpuflags_64.h
+++ b/lib/librte_eal/arm/include/rte_cpuflags_64.h
@@ -22,6 +22,19 @@ enum rte_cpu_flag_t {
RTE_CPUFLAG_SHA2,
RTE_CPUFLAG_CRC32,
RTE_CPUFLAG_ATOMICS,
+   RTE_CPUFLAG_SVE,
+   RTE_CPUFLAG_SVE2,
+   RTE_CPUFLAG_SVEAES,
+   RTE_CPUFLAG_SVEPMULL,
+   RTE_CPUFLAG_SVEBITPERM,
+   RTE_CPUFLAG_SVESHA3,
+   RTE_CPUFLAG_SVESM4,
+   RTE_CPUFLAG_FLAGM2,
+   RTE_CPUFLAG_FRINT,
+   RTE_CPUFLAG_SVEI8MM,
+   RTE_CPUFLAG_SVEF32MM,
+   RTE_CPUFLAG_SVEF64MM,
+   RTE_CPUFLAG_SVEBF16,
RTE_CPUFLAG_AARCH64,
/* The last item */
RTE_CPUFLAG_NUMFLAGS,/**< This should always be the last! */
diff --git a/lib/librte_eal/arm/rte_cpuflags.c 
b/lib/librte_eal/arm/rte_cpuflags.c
index caf3dc83a..7b257b787 100644
--- a/lib/librte_eal/arm/rte_cpuflags.c
+++ b/lib/librte_eal/arm/rte_cpuflags.c
@@ -95,6 +95,19 @@ const struct feature_entry rte_cpu_feature_table[] = {
FEAT_DEF(SHA2,  REG_HWCAP,6)
FEAT_DEF(CRC32, REG_HWCAP,7)
FEAT_DEF(ATOMICS,   REG_HWCAP,8)
+   FEAT_DEF(SVE,   REG_HWCAP,22)
+   FEAT_DEF(SVE2,  REG_HWCAP2,   1)
+   FEAT_DEF(SVEAES,REG_HWCAP2,   2)
+   FEAT_DEF(SVEPMULL,  REG_HWCAP2,   3)
+   FEAT_DEF(SVEBITPERM,REG_HWCAP2,   4)
+   FEAT_DEF(SVESHA3,   REG_HWCAP2,   5)
+   FEAT_DEF(SVESM4,REG_HWCAP2,   6)
+   FEAT_DEF(FLAGM2,REG_HWCAP2,   7)
+   FEAT_DEF(FRINT, REG_HWCAP2,   8)
+   FEAT_DEF(SVEI8MM,   REG_HWCAP2,   9)
+   FEAT_DEF(SVEF32MM,  REG_HWCAP2,   10)
+   FEAT_DEF(SVEF64MM,  REG_HWCAP2,   11)
+   FEAT_DEF(SVEBF16,   REG_HWCAP2,   12)
FEAT_DEF(AARCH64,   REG_PLATFORM, 1)
 };
 #endif /* RTE_ARCH */
-- 
2.27.0

[dpdk-dev] [PATCH v5 2/2] test/cpuflag: add new flags for ARM64 platform

[Wei Hu (Xavier)]

From: "Wei Hu (Xavier)" 

This patch adds new flags into the test_cpuflags() functions for ARM64
platform, such as RTE_CPUFLAG_SVE, etc.

Signed-off-by: Wei Hu (Xavier) 
Reviewed-by: Ruifeng Wang 
---
v4 -> v5: Use double '\t' for better alignment.
v4: Initial patch.
---
 app/test/test_cpuflags.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/app/test/test_cpuflags.c b/app/test/test_cpuflags.c
index 06718631f..7c71ffef1 100644
--- a/app/test/test_cpuflags.c
+++ b/app/test/test_cpuflags.c
@@ -118,6 +118,45 @@ test_cpuflags(void)
 
printf("Check for ATOMICS:\t");
CHECK_FOR_FLAG(RTE_CPUFLAG_ATOMICS);
+
+   printf("Check for SVE:\t\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVE);
+
+   printf("Check for SVE2:\t\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVE2);
+
+   printf("Check for SVEAES:\t\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVEAES);
+
+   printf("Check for SVEPMULL:\t\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVEPMULL);
+
+   printf("Check for SVEBITPERM:\t\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVEBITPERM);
+
+   printf("Check for SVESHA3:\t\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVESHA3);
+
+   printf("Check for SVESM4:\t\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVESM4);
+
+   printf("Check for FLAGM2:\t\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_FLAGM2);
+
+   printf("Check for FRINT:\t\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_FRINT);
+
+   printf("Check for SVEI8MM:\t\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVEI8MM);
+
+   printf("Check for SVEF32MM:\t\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVEF32MM);
+
+   printf("Check for SVEF64MM:\t\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVEF64MM);
+
+   printf("Check for SVEBF16:\t\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVEBF16);
 #endif
 
 #if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_I686)
-- 
2.27.0

Re: [dpdk-dev] [PATCH v4 2/2] test/cpuflag: add new flags for ARM64 platform

[Wei Hu (Xavier)]

Hi, Ruifeng Wang

On 2020/8/19 10:26, Ruifeng Wang wrote:



-Original Message-
From: Wei Hu (Xavier) 
Sent: Tuesday, August 18, 2020 4:09 PM
To: dev@dpdk.org
Cc: nd ; Honnappa Nagarahalli
; Ruifeng Wang
; jerinjac...@gmail.com;
xavier.hu...@huawei.com
Subject: [PATCH v4 2/2] test/cpuflag: add new flags for ARM64 platform

From: "Wei Hu (Xavier)" 

This patch adds new flags into the test_cpuflags() functions for ARM64
platform, such as RTE_CPUFLAG_SVE, etc.

Signed-off-by: Wei Hu (Xavier) 
---
  app/test/test_cpuflags.c | 39
+++
  1 file changed, 39 insertions(+)

diff --git a/app/test/test_cpuflags.c b/app/test/test_cpuflags.c index
06718631f..845564410 100644
--- a/app/test/test_cpuflags.c
+++ b/app/test/test_cpuflags.c
@@ -118,6 +118,45 @@ test_cpuflags(void)

printf("Check for ATOMICS:\t");
CHECK_FOR_FLAG(RTE_CPUFLAG_ATOMICS);
+
+   printf("Check for SVE:\t");

Nit. Use double '\t' for better alignment.


+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVE);
+
+   printf("Check for SVE2:\t");

Ditto.

With the suggested changes,
Reviewed-by: Ruifeng Wang 


OK, I will update them in V5.
Thanks, Xavier



+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVE2);
+
+   printf("Check for SVEAES:\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVEAES);
+
+   printf("Check for SVEPMULL:\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVEPMULL);
+
+   printf("Check for SVEBITPERM:\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVEBITPERM);
+
+   printf("Check for SVESHA3:\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVESHA3);
+
+   printf("Check for SVESM4:\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVESM4);
+
+   printf("Check for FLAGM2:\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_FLAGM2);
+
+   printf("Check for FRINT:\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_FRINT);
+
+   printf("Check for SVEI8MM:\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVEI8MM);
+
+   printf("Check for SVEF32MM:\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVEF32MM);
+
+   printf("Check for SVEF64MM:\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVEF64MM);
+
+   printf("Check for SVEBF16:\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVEBF16);
  #endif

  #if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_I686)
--
2.27.0

Re: [dpdk-dev] [RFC PATCH] config: remap flags used for Arm platforms

[Ruifeng Wang]

> -Original Message-
> From: Ferruh Yigit 
> Sent: Tuesday, August 18, 2020 10:36 PM
> To: Ruifeng Wang ; hemant.agra...@nxp.com;
> jer...@marvell.com; vikto...@rehivetech.com
> Cc: dev@dpdk.org; Honnappa Nagarahalli
> ; Phil Yang ; nd
> 
> Subject: Re: [dpdk-dev] [RFC PATCH] config: remap flags used for Arm
> platforms
> 
> On 8/14/2020 7:03 AM, Ruifeng Wang wrote:
> > Flags are used to distinguish different platform architectures.
> > These flags can be used to pick different code paths for different
> > architectures at compile time.
> > For Arm platforms, there are 3 flags in use: RTE_ARCH_ARM,
> > RTE_ARCH_ARMv7 and RTE_ARCH_ARM64.
> > RTE_ARCH_ARM64 is used to flag 64-bit aarch64 platforms, while
> > RTE_ARCH_ARM & RTE_ARCH_ARMv7 are used to flag 32-bit platforms.
> > RTE_ARCH_ARMv7 is for ARMv7 platforms as its name suggested.
> >
> > The issue is that flag name RTE_ARCH_ARM is unclear and could cause
> > confusion. No info about platform word length is included in the name.
> > To make the flag names more clear, a naming scheme is proposed.
> >
> >   RTE_ARCH_ARM
> >   |
> >   +RTE_ARCH_ARM32
> >   ||
> >   |+RTE_ARCH_ARMv7
> >   ||
> >   |+RTE_ARCH_ARMv8_AARCH32
> >   |
> >   +RTE_ARCH_ARM64
> >
> > RTE_ARCH_ARM32 will be used for 32-bit Arm platforms.
> > It includes RTE_ARCH_ARMv7 and RTE_ARCH_ARMv8_AARCH32.
> > RTE_ARCH_ARMv7 is for ARMv7 platforms.
> > RTE_ARCH_ARMv8_AARCH32 is for aarch32 state on aarch64 platforms.
> > RTE_ARCH_ARM64 is for 64-bit Arm platforms.
> > RTE_ARCH_ARM will be used for all Arm platforms, including
> > RTE_ARCH_ARM32 and RTE_ARCH_ARM64.
> >
> > To fit into the new naming scheme, current usage of RTE_ARCH_ARM in
> > project code is mapped to RTE_ARCH_ARM32.
> >
> > Suggested-by: Honnappa Nagarahalli 
> > Signed-off-by: Ruifeng Wang 
> > Reviewed-by: Phil Yang 
> > ---
> 
> <...>
> 
> > @@ -6,7 +6,7 @@
> >  CONFIG_RTE_MACHINE="armv7a"
> >
> >  CONFIG_RTE_ARCH="arm"
> > -CONFIG_RTE_ARCH_ARM=y
> > +CONFIG_RTE_ARCH_ARM32=y
> >  CONFIG_RTE_ARCH_ARMv7=y
> >  CONFIG_RTE_ARCH_ARM_TUNE="cortex-a9"
> 
> According commit log message I thought 'RTE_ARCH_ARM' will be always set,
> isn't it the case?
> 
> Is below wrong:
> aarch64  -> ARM | ARM64 | ARCH_64
> armv7a   -> ARM | ARM32 | ARMv7
> aarch32  -> ARM | ARM32 | ARMv8_AARCH32
> 
Yes, it is.
This is correct.

> If so some of the 'defined(RTE_ARCH_ARM32) ||
> defined(RTE_ARCH_ARM64)' checks can be simplified as
> 'defined(RTE_ARCH_ARM)'
> 
Will do the change when converting this RFC to a patch.

> 
> Also currently missing 'ARCH_64' flag implies the 32bit support, for all
> architectures, what about having a common 'ARCH_32' flag and use for all
> arch, instead of 'ARM32'? So something like below:
> aarch64  -> ARM | ARM64 | ARCH_64
> armv7a   -> ARM | ARMv7 | ARCH_32
> aarch32  -> ARM | ARMv8_AARCH32 | ARCH_32
> 
Having a common 'ARCH_32' flag for all arch is good.

Then for Arm we will have:
RTE_ARCH_ARM
|
+RTE_ARCH_32
||
|+RTE_ARCH_ARMv7
||
|+RTE_ARCH_ARMv8_AARCH32
|
+RTE_ARCH_64
 |
 +RTE_ARCH_ARM64

For x86 we will have:
RTE_ARCH_X86
|
+RTE_ARCH_32
||
|+RTE_ARCH_I686
||
|+RTE_ARCH_X86_X32
|
+RTE_ARCH_64
 |
 +RTE_ARCH_X86_64

For PowerPC we will have: RTE_ARCH_PPC_64

> 
> 
> 
> Just to record matching flags for other archs are:
> 
> x86_64  -> X86 | X86_64 | ARCH_64
> i686-> X86 | I686
> x86_32  -> X86 | X86_32
> 
> ppc_64  -> PPC_64 | ARCH_64

Re: [dpdk-dev] [PATCH v5 2/2] test/cpuflag: add new flags for ARM64 platform

[Ruifeng Wang]

> -Original Message-
> From: Wei Hu (Xavier) 
> Sent: Wednesday, August 19, 2020 3:04 PM
> To: dev@dpdk.org
> Cc: nd ; Honnappa Nagarahalli
> ; Ruifeng Wang
> ; jerinjac...@gmail.com;
> xavier.hu...@huawei.com
> Subject: [PATCH v5 2/2] test/cpuflag: add new flags for ARM64 platform
> 
> From: "Wei Hu (Xavier)" 
> 
> This patch adds new flags into the test_cpuflags() functions for ARM64
> platform, such as RTE_CPUFLAG_SVE, etc.
> 
> Signed-off-by: Wei Hu (Xavier) 
> Reviewed-by: Ruifeng Wang 
> ---
> v4 -> v5: Use double '\t' for better alignment.
> v4: Initial patch.
> ---
>  app/test/test_cpuflags.c | 39
> +++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/app/test/test_cpuflags.c b/app/test/test_cpuflags.c index
> 06718631f..7c71ffef1 100644
> --- a/app/test/test_cpuflags.c
> +++ b/app/test/test_cpuflags.c
> @@ -118,6 +118,45 @@ test_cpuflags(void)
> 
>   printf("Check for ATOMICS:\t");
>   CHECK_FOR_FLAG(RTE_CPUFLAG_ATOMICS);
> +
> + printf("Check for SVE:\t\t");
> + CHECK_FOR_FLAG(RTE_CPUFLAG_SVE);
> +
> + printf("Check for SVE2:\t\t");
> + CHECK_FOR_FLAG(RTE_CPUFLAG_SVE2);
> +
Sorry if I didn't make it clear.
In v4, I meant we need double '\t' when checking for 'SVE' and 'SVE2' to align 
the check results with that of other flags.
You can check this by running cpuflags_autotest.

Thanks.
/Ruifeng
> + printf("Check for SVEAES:\t\t");
> + CHECK_FOR_FLAG(RTE_CPUFLAG_SVEAES);
> +
> + printf("Check for SVEPMULL:\t\t");
> + CHECK_FOR_FLAG(RTE_CPUFLAG_SVEPMULL);
> +
> + printf("Check for SVEBITPERM:\t\t");
> + CHECK_FOR_FLAG(RTE_CPUFLAG_SVEBITPERM);
> +
> + printf("Check for SVESHA3:\t\t");
> + CHECK_FOR_FLAG(RTE_CPUFLAG_SVESHA3);
> +
> + printf("Check for SVESM4:\t\t");
> + CHECK_FOR_FLAG(RTE_CPUFLAG_SVESM4);
> +
> + printf("Check for FLAGM2:\t\t");
> + CHECK_FOR_FLAG(RTE_CPUFLAG_FLAGM2);
> +
> + printf("Check for FRINT:\t\t");
> + CHECK_FOR_FLAG(RTE_CPUFLAG_FRINT);
> +
> + printf("Check for SVEI8MM:\t\t");
> + CHECK_FOR_FLAG(RTE_CPUFLAG_SVEI8MM);
> +
> + printf("Check for SVEF32MM:\t\t");
> + CHECK_FOR_FLAG(RTE_CPUFLAG_SVEF32MM);
> +
> + printf("Check for SVEF64MM:\t\t");
> + CHECK_FOR_FLAG(RTE_CPUFLAG_SVEF64MM);
> +
> + printf("Check for SVEBF16:\t\t");
> + CHECK_FOR_FLAG(RTE_CPUFLAG_SVEBF16);
>  #endif
> 
>  #if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_I686)
> --
> 2.27.0

Re: [dpdk-dev] [PATCH v3] net/virtio: fix wrong variable assignment in helper macro

[Vipul Ashri]

Hi All

This patch needs to get reviewed by all available reviewers as link came 
visible now.

@Xia Chenbo, As you have already reviewed so here I request you to share your 
review vote again and Ack if possible.

@Ferruh, Below link is correct patch, I appreciate and thank you very much for 
your help.

Patch Link:
https://urldefense.com/v3/__https://patches.dpdk.org/project/dpdk/list/?submitter=1867__;!!GqivPVa7Brio!JuQy9aSMyTDxpgEERG6JThvjCeZ0vbjYktEIDtU-JSHQalUpEoAp3u4diGxyy98kmw$


Regards
Vipul

-Original Message-
From: Ferruh Yigit [mailto:ferruh.yi...@intel.com] 
Sent: Wednesday, 19 August, 2020 0:15
To: Vipul Ashri ; Xia, Chenbo ; 
dev@dpdk.org; sta...@dpdk.org; Wang, Zhihong ; 
maxime.coque...@redhat.com
Cc: Edwin Leung 
Subject: Re: [dpdk-dev] [PATCH v3] net/virtio: fix wrong variable assignment in 
helper macro

On 8/14/2020 6:23 AM, Vipul Ashri wrote:
> Hi All
> 
> I tried twice uploading this same patch but it is still not listed under 
> https://urldefense.com/v3/__http://patches.dpdk.org/project/dpdk/list/__;!!GqivPVa7Brio!JuQy9aSMyTDxpgEERG6JThvjCeZ0vbjYktEIDtU-JSHQalUpEoAp3u4diGy8g7AhJA$
>  .
> Please let me know if I am missing something and required to do some 
> additional steps to submit my patch.

Mail list is moderated, only subscribed members can post.
Your patches were hold in the administration queue because of that, I have 
released them and cleaned up the patchwork (since there were double of some
versions) and only left one copy of v3, please check if that is the correct one:
https://urldefense.com/v3/__https://patches.dpdk.org/project/dpdk/list/?submitter=1867__;!!GqivPVa7Brio!JuQy9aSMyTDxpgEERG6JThvjCeZ0vbjYktEIDtU-JSHQalUpEoAp3u4diGxyy98kmw$
 

> 
> Thanks to Xia  for reviewing this code!
> 
> Regards
> Vipul
> 
> -Original Message-
> From: Xia, Chenbo [mailto:chenbo@intel.com]
> Sent: Friday, 14 August, 2020 6:56
> To: Vipul Ashri ; dev@dpdk.org
> Cc: Edwin Leung ; sta...@dpdk.org; Wang, 
> Zhihong ; maxime.coque...@redhat.com
> Subject: RE: [PATCH v3] net/virtio: fix wrong variable assignment in 
> helper macro
> 
> 
>> -Original Message-
>> From: Vipul Ashri 
>> Sent: Friday, August 14, 2020 12:22 AM
>> To: dev@dpdk.org
>> Cc: Xia, Chenbo ; vipul.as...@oracle.com; 
>> edwin.le...@oracle.com; sta...@dpdk.org; Wang, Zhihong 
>> ; maxime.coque...@redhat.com
>> Subject: [PATCH v3] net/virtio: fix wrong variable assignment in 
>> helper macro
>>
>> Inside Macro ASSIGN_UNLESS_EQUAL(var, val), assignment to var is 
>> always failing as assignment done using var_ having local scope only.
>> This leads to TX packets not going out and found broken due to 
>> cleanup malfunctioning. This patch fixes the wrong variable assignment.
>>
>> Fixes: 57f90f894588 ("net/virtio: reuse packed ring functions")
>> Cc: sta...@dpdk.org
>>
>> Signed-off-by: Vipul Ashri 
>> ---
>>  drivers/net/virtio/virtqueue.h | 6 ++
>>  1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/virtio/virtqueue.h 
>> b/drivers/net/virtio/virtqueue.h index 105a9c00c..20c95471e 100644
>> --- a/drivers/net/virtio/virtqueue.h
>> +++ b/drivers/net/virtio/virtqueue.h
>> @@ -607,10 +607,8 @@ virtqueue_notify(struct virtqueue *vq)
>>
>>  /* avoid write operation when necessary, to lessen cache issues */
>>  #define ASSIGN_UNLESS_EQUAL(var, val) do {  \
>> -typeof(var) var_ = (var);   \
>> -typeof(val) val_ = (val);   \
>> -if ((var_) != (val_))   \
>> -(var_) = (val_);\
>> +if ((var) != (val)) \
>> +(var) = (val);  \
>>  } while (0)
>>
>>  #define virtqueue_clear_net_hdr(hdr) do {   \
>> --
>> 2.28.0.windows.1
> 
> Reviewed-by: Chenbo Xia 
> 

[dpdk-dev] [PATCH v6 1/2] eal/arm64: update CPU flags

[Wei Hu (Xavier)]

From: "Wei Hu (Xavier)" 

ARM64 Linux kernel updated the CPU flags using the HWCAP scheme.
The related marco definition can be found in linux kernel:
  arch/arm64/include/uapi/asm/hwcap.h

This patch incorporates those changes to the eal library.

Signed-off-by: Chengwen Feng 
Signed-off-by: Wei Hu (Xavier) 
Reviewed-by: Ruifeng Wang 
---
v4 -> v5:
No change.
v3 -> v4:
Update commit log.
v2 -> v3:
1. Change commit log.
2. Add HWCAP2_FLAGM2 and HWCAP2_FRINT to rte_cpu_feature_table[].
3. Add the flags for newly added items into enum rte_cpu_flag_t.
v1 -> v2:
Adds more sve-related definition to rte_cpu_feature_table,
sunch as SVE2, etc.
---
 lib/librte_eal/arm/include/rte_cpuflags_64.h | 13 +
 lib/librte_eal/arm/rte_cpuflags.c| 13 +
 2 files changed, 26 insertions(+)

diff --git a/lib/librte_eal/arm/include/rte_cpuflags_64.h 
b/lib/librte_eal/arm/include/rte_cpuflags_64.h
index 95cc01474..aa7a56d49 100644
--- a/lib/librte_eal/arm/include/rte_cpuflags_64.h
+++ b/lib/librte_eal/arm/include/rte_cpuflags_64.h
@@ -22,6 +22,19 @@ enum rte_cpu_flag_t {
RTE_CPUFLAG_SHA2,
RTE_CPUFLAG_CRC32,
RTE_CPUFLAG_ATOMICS,
+   RTE_CPUFLAG_SVE,
+   RTE_CPUFLAG_SVE2,
+   RTE_CPUFLAG_SVEAES,
+   RTE_CPUFLAG_SVEPMULL,
+   RTE_CPUFLAG_SVEBITPERM,
+   RTE_CPUFLAG_SVESHA3,
+   RTE_CPUFLAG_SVESM4,
+   RTE_CPUFLAG_FLAGM2,
+   RTE_CPUFLAG_FRINT,
+   RTE_CPUFLAG_SVEI8MM,
+   RTE_CPUFLAG_SVEF32MM,
+   RTE_CPUFLAG_SVEF64MM,
+   RTE_CPUFLAG_SVEBF16,
RTE_CPUFLAG_AARCH64,
/* The last item */
RTE_CPUFLAG_NUMFLAGS,/**< This should always be the last! */
diff --git a/lib/librte_eal/arm/rte_cpuflags.c 
b/lib/librte_eal/arm/rte_cpuflags.c
index caf3dc83a..7b257b787 100644
--- a/lib/librte_eal/arm/rte_cpuflags.c
+++ b/lib/librte_eal/arm/rte_cpuflags.c
@@ -95,6 +95,19 @@ const struct feature_entry rte_cpu_feature_table[] = {
FEAT_DEF(SHA2,  REG_HWCAP,6)
FEAT_DEF(CRC32, REG_HWCAP,7)
FEAT_DEF(ATOMICS,   REG_HWCAP,8)
+   FEAT_DEF(SVE,   REG_HWCAP,22)
+   FEAT_DEF(SVE2,  REG_HWCAP2,   1)
+   FEAT_DEF(SVEAES,REG_HWCAP2,   2)
+   FEAT_DEF(SVEPMULL,  REG_HWCAP2,   3)
+   FEAT_DEF(SVEBITPERM,REG_HWCAP2,   4)
+   FEAT_DEF(SVESHA3,   REG_HWCAP2,   5)
+   FEAT_DEF(SVESM4,REG_HWCAP2,   6)
+   FEAT_DEF(FLAGM2,REG_HWCAP2,   7)
+   FEAT_DEF(FRINT, REG_HWCAP2,   8)
+   FEAT_DEF(SVEI8MM,   REG_HWCAP2,   9)
+   FEAT_DEF(SVEF32MM,  REG_HWCAP2,   10)
+   FEAT_DEF(SVEF64MM,  REG_HWCAP2,   11)
+   FEAT_DEF(SVEBF16,   REG_HWCAP2,   12)
FEAT_DEF(AARCH64,   REG_PLATFORM, 1)
 };
 #endif /* RTE_ARCH */
-- 
2.27.0

[dpdk-dev] [PATCH v6 2/2] test/cpuflag: add new flags for ARM64 platform

[Wei Hu (Xavier)]

From: "Wei Hu (Xavier)" 

This patch adds new flags into the test_cpuflags() functions for ARM64
platform, such as RTE_CPUFLAG_SVE, etc.

Signed-off-by: Wei Hu (Xavier) 
Reviewed-by: Ruifeng Wang 
---
v5 -> v6: update '\t' for alignment.
v4 -> v5: Use double '\t' for better alignment.
v4: Initial patch.
---
 app/test/test_cpuflags.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/app/test/test_cpuflags.c b/app/test/test_cpuflags.c
index 06718631f..0b389d091 100644
--- a/app/test/test_cpuflags.c
+++ b/app/test/test_cpuflags.c
@@ -118,6 +118,45 @@ test_cpuflags(void)
 
printf("Check for ATOMICS:\t");
CHECK_FOR_FLAG(RTE_CPUFLAG_ATOMICS);
+
+   printf("Check for SVE:\t\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVE);
+
+   printf("Check for SVE2:\t\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVE2);
+
+   printf("Check for SVEAES:\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVEAES);
+
+   printf("Check for SVEPMULL:\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVEPMULL);
+
+   printf("Check for SVEBITPERM:\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVEBITPERM);
+
+   printf("Check for SVESHA3:\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVESHA3);
+
+   printf("Check for SVESM4:\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVESM4);
+
+   printf("Check for FLAGM2:\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_FLAGM2);
+
+   printf("Check for FRINT:\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_FRINT);
+
+   printf("Check for SVEI8MM:\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVEI8MM);
+
+   printf("Check for SVEF32MM:\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVEF32MM);
+
+   printf("Check for SVEF64MM:\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVEF64MM);
+
+   printf("Check for SVEBF16:\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVEBF16);
 #endif
 
 #if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_I686)
-- 
2.27.0

[dpdk-dev] [PATCH v6 0/2] update CPU flags for arm64 platform

[Wei Hu (Xavier)]

This series updates CPU flags for arm64 platform.

Wei Hu (Xavier) (2):
  eal/arm64: update CPU flags
  test/cpuflag: add new flags for ARM64 platform

 app/test/test_cpuflags.c | 39 
 lib/librte_eal/arm/include/rte_cpuflags_64.h | 13 +++
 lib/librte_eal/arm/rte_cpuflags.c| 13 +++
 3 files changed, 65 insertions(+)

-- 
2.27.0

Re: [dpdk-dev] Ipsec-secgw packet processing

[satyavalli rama]

Hi Anoob

We are using the following hardware details,
HOST: x722 (i40e) intel.
VM: e1000 (82540) intel.

We have launched Virtual machine on host , and executing ipsec-secgw
application on VM.

Please find below the CLI and configuration for TRANSPORT MODE.

CLI:

./build/ipsec-secgw -l 0 -n 4 --socket-mem 1024,0 --vdev "crypto_null" --
-p 0x3 -P -u 0x1 --config="(0,0,0),(1,0,0)" -f ep0.cfg

#TRANSPORT:

#SP IPv4 rules
sp ipv4 out esp protect 10 pri 1 dst 192.168.122.0/24 sport 0:65535 dport
0:65535

#SA rules
sa out 10 cipher_algo aes-128-cbc cipher_key
a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:\
a1:a1:a1:a1:a1 auth_algo sha1-hmac auth_key
a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:a1:\
a1:a1:a1:a1:a1:a1:a1:a1:a1 mode transport

#Routing rules
rt ipv4 dst 192.168.122.0/24 port 1


Please find below the CLI and configuration for TUNNEL MODE.

CLI:

./build/ipsec-secgw -l 0 -n 4 --socket-mem 1024,0 --vdev "crypto_null" --
-p 0x3 -P -u 0x1 --config="(0,0,0),(1,0,0)" -f ep0.cfg

#TUNNEL End Point-0:

#SP IPv4 rules
sp ipv4 out esp protect 5 pri 1 dst 192.168.122.0/24 sport 0:65535 dport
0:65535

#SA rules
sa out 5 cipher_algo aes-128-cbc cipher_key 0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0
\
auth_algo sha1-hmac auth_key 0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0 \
mode ipv4-tunnel src 192.168.122.96 dst 192.168.122.213

#Routing rules
rt ipv4 dst 192.168.122.0/24 port 1

On Tue, 18 Aug, 2020, 4:29 pm Anoob Joseph,  wrote:

> Hi Satya,
>
> Are you attempting to enable inline protocol (IPsec) functionality? If
> yes, which PMD (& h/w) are you using for the same?
>
> Thanks,
> Anoob
>
> > -Original Message-
> > From: dev  On Behalf Of satyavalli rama
> > Sent: Tuesday, August 18, 2020 4:08 PM
> > To: dev@dpdk.org; us...@dpdk.org
> > Subject: Re: [dpdk-dev] Ipsec-secgw packet processing
> >
> > We further debugged and we observed that while running ipsec-secgw
> > application in transport-mode dpdk-19.02/11, we found that inline packet
> > processing is not happening.
> > We observed that ol_flags is not setting from driver level. We are
> expecting
> > that , because of ol_flags not set , inline packet processing is not
> > happening.Any idea What could be the reason for this, I think ol_flags
> will be
> > configured from driver level Or else do we need to provide any external
> > configuration for setting ol_flags.
> > And also we are not observing encrypt/decrypt packets on pdump before
> > sending packets out from tx-port(rte_eth_tx_burst()).
> > Please help us on this...to proceed further.
> >
> > Thanks & Regards
> > Satya
> >
> >
> >
> > On Mon, 17 Aug, 2020, 4:11 pm satyavalli rama, <
> satyavalli.r...@gmail.com>
> > wrote:
> >
> > >
> > > Hello,
> > >
> > > While we are running ipsec-secgw application in transport-mode on
> > > dpdk-19.02, we found that inline packet processing is not happening.
> > >
> > > And also we are not observing any encrypt/decrypt packets on pdump
> > > before sending packets out from tx-port(rte_eth_tx_burst()).
> > >
> > > Please help us on how to proceed further.
> > >
> > > Thanks,
> > > Jagadeesh
> > >
> > >
>

[dpdk-dev] [Bug 528] ixgbe: PTP not working when ixgbe_xmit_pkts_vec is used

[bugzilla]

https://bugs.dpdk.org/show_bug.cgi?id=528

Bug ID: 528
   Summary: ixgbe: PTP not working when ixgbe_xmit_pkts_vec is
used
   Product: DPDK
   Version: 20.05
  Hardware: All
OS: All
Status: UNCONFIRMED
  Severity: normal
  Priority: Normal
 Component: ethdev
  Assignee: dev@dpdk.org
  Reporter: pawel...@gmail.com
  Target Milestone: ---

Looks like ixgbe_xmit_pkts_vec is ignoring mbuf ol_flags. When setting any
offloads flag (eg DEV_TX_OFFLOAD_TCP_CKSUM) forces ixgbe_xmit_pkts to be used
and PTP timestamping of transmited packet is working again.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[dpdk-dev] [PATCH] examples/vm_power: fix resource leak on error path

[wangyunjian]

From: Yunjian Wang 

This patch fixes the resource leaks reported by coverity.

Coverity issue: 337674
Fixes: 95f648ff9eed ("examples/vm_power: make branch ratio threshold per core")
Cc: sta...@dpdk.org

Signed-off-by: Yunjian Wang 
---
 examples/vm_power_manager/main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/examples/vm_power_manager/main.c b/examples/vm_power_manager/main.c
index 3a8958058..6422d7b99 100644
--- a/examples/vm_power_manager/main.c
+++ b/examples/vm_power_manager/main.c
@@ -206,6 +206,7 @@ parse_args(int argc, char **argv)
}
if (branch_ratio <= 0.0 || branch_ratio > 100.0) {
printf("invalid branch ratio specified\n");
+   free(oob_enable);
return -1;
}
for (i = 0; i < ci->core_count; i++) {
-- 
2.23.0

Re: [dpdk-dev] [PATCH 20.11 12/19] doc: remove references to make in Linux gsg guides

[Bruce Richardson]

On Tue, Aug 18, 2020 at 12:40:53PM +0100, Bruce Richardson wrote:
> On Fri, Aug 07, 2020 at 01:30:02PM +0100, Ciara Power wrote:
> > Make is no longer supported for compiling DPDK, references are now
> > removed in the documentation.
> > 
> > Signed-off-by: Ciara Power 
> > ---
> >  doc/guides/linux_gsg/build_dpdk.rst   | 58 ---
> >  doc/guides/linux_gsg/build_sample_apps.rst| 16 +
> >  .../linux_gsg/cross_build_dpdk_for_arm64.rst  | 42 --
> >  doc/guides/linux_gsg/enable_func.rst  |  3 -
> >  doc/guides/linux_gsg/intro.rst|  2 +-
> >  doc/guides/linux_gsg/linux_drivers.rst|  2 -
> >  doc/guides/linux_gsg/sys_reqs.rst |  4 --
> >  7 files changed, 4 insertions(+), 123 deletions(-)
> > 
> 
> > diff --git a/doc/guides/linux_gsg/sys_reqs.rst 
> > b/doc/guides/linux_gsg/sys_reqs.rst
> > index a124656bcb..a009f3146b 100644
> > --- a/doc/guides/linux_gsg/sys_reqs.rst
> > +++ b/doc/guides/linux_gsg/sys_reqs.rst
> > @@ -85,10 +85,6 @@ A number of DPDK components, such as libraries and 
> > poll-mode drivers (PMDs) have
> >  For DPDK builds using meson, the presence or absence of these dependencies 
> > will be
> >  automatically detected enabling or disabling the relevant components 
> > appropriately.
> >  
> 
> I think you can drop the words "using meson" here as there is no
> alternative any more.
> 
> > -For builds using make, these components are disabled in the default 
> > configuration and
> > -need to be enabled manually by changing the relevant setting to "y" in the 
> > build configuration file
> > -i.e. the ``.config`` file in the build folder.
> > -
> >  In each case, the relevant library development package (``-devel`` or 
> > ``-dev``) is needed to build the DPDK components.
> >  
> >  For libraries the additional dependencies include:
> 
> In sys_reqs.rst there is also a reference to make in the "Required Tools
> and Libraries". Change: 
> 
> "General development tools including make, and a supported C compiler such
> as gcc (version 4.9+) or clang (version 3.4+)."
> 
> To something like:
> 
> "General development tools including a supported C compiler such
> as gcc (version 4.9+) or clang (version 3.4+)."

Also, one more thing I spot in that section is that we need to update our
python minimum version to 3.5+ and drop references to 2.7. Therefore, I'd
suggest just removing the whole sub-bullets and put a single bullet saying
"Python, v3.5 or later"

Re: [dpdk-dev] [PATCH 2/2] ethdev: tunnel offload model

[Gregory Etelson]

Hello Andrew,

Thank you for detailed review.
Sorry for the late response.
Please see my answers inline.

Regards,
Gregory

> -Original Message-
> From: Andrew Rybchenko 
> Sent: Sunday, July 5, 2020 17:51
> To: Gregory Etelson ; dev@dpdk.org
> Cc: Matan Azrad ; Raslan Darawsheh 
> ; Eli Britstein ; Ori Kam 
> 
> Subject: Re: [dpdk-dev] [PATCH 2/2] ethdev: tunnel offload model
> 
> Hi Gregory,
> 
> I'm sorry for the review with t many questions without any 
> suggestions on how to answer it. Please, see below.
> 
> On 6/25/20 7:03 PM, Gregory Etelson wrote:
> > From: Eli Britstein 
> >
> > Hardware vendors implement tunneled traffic offload techniques 
> > differently. Although RTE flow API provides tools capable to offload 
> > all sorts of network stacks, software application must reference 
> > this hardware differences in flow rules compilation. As the result 
> > tunneled traffic flow rules that utilize hardware capabilities can 
> > be different for the same traffic.
> >
> > Tunnel port offload proposed in [1] provides software application 
> > with unified rules model for tunneled traffic regardless underlying 
> > hardware.
> >  - The model introduces a concept of a virtual tunnel port (VTP).
> >  - The model uses VTP to offload ingress tunneled network traffic
> >with RTE flow rules.
> >  - The model is implemented as set of helper functions. Each PMD
> >implements VTP offload according to underlying hardware offload
> >capabilities.  Applications must query PMD for VTP flow
> >items / actions before using in creation of a VTP flow rule.
> >
> > The model components:
> > - Virtual Tunnel Port (VTP) is a stateless software object that
> >   describes tunneled network traffic.  VTP object usually contains
> >   descriptions of outer headers, tunnel headers and inner headers.
> > - Tunnel Steering flow Rule (TSR) detects tunneled packets and
> >   delegates them to tunnel processing infrastructure, implemented
> >   in PMD for optimal hardware utilization, for further processing.
> > - Tunnel Matching flow Rule (TMR) verifies packet configuration and
> >   runs offload actions in case of a match.
> >
> > Application actions:
> > 1 Initialize VTP object according to tunnel
> >   network parameters.
> > 2 Create TSR flow rule:
> > 2.1 Query PMD for VTP actions: application can query for VTP actions
> > more than once
> > int
> > rte_flow_tunnel_decap_set(uint16_t port_id,
> >   struct rte_flow_tunnel *tunnel,
> >   struct rte_flow_action **pmd_actions,
> >   uint32_t *num_of_pmd_actions,
> >   struct rte_flow_error *error);
> >
> > 2.2 Integrate PMD actions into TSR actions list.
> > 2.3 Create TSR flow rule:
> > flow create  group 0
> >   match {tunnel items} / end
> >   actions {PMD actions} / {App actions} / end
> >
> > 3 Create TMR flow rule:
> > 3.1 Query PMD for VTP items: application can query for VTP items
> > more than once
> > int
> > rte_flow_tunnel_match(uint16_t port_id,
> >   struct rte_flow_tunnel *tunnel,
> >   struct rte_flow_item **pmd_items,
> >   uint32_t *num_of_pmd_items,
> >   struct rte_flow_error *error);
> >
> > 3.2 Integrate PMD items into TMR items list:
> > 3.3 Create TMR flow rule
> > flow create  group 0
> >   match {PMD items} / {APP items} / end
> >   actions {offload actions} / end
> >
> > The model provides helper function call to restore packets that miss 
> > tunnel TMR rules to its original state:
> > int
> > rte_flow_get_restore_info(uint16_t port_id,
> >   struct rte_mbuf *mbuf,
> >   struct rte_flow_restore_info *info,
> >   struct rte_flow_error *error);
> >
> > rte_tunnel object filled by the call inside rte_flow_restore_info 
> > *info parameter can be used by the application to create new TMR 
> > rule for that tunnel.
> >
> > The model requirements:
> > Software application must initialize rte_tunnel object with tunnel 
> > parameters before calling
> > rte_flow_tunnel_decap_set() & rte_flow_tunnel_match().
> >
> > PMD actions array obtained in rte_flow_tunnel_decap_set() must be 
> > released by application with rte_flow_action_release() call.
> > Application can release the actionsfter TSR rule was created.
> >
> > PMD items array obtained with rte_flow_tunnel_match() must be 
> > released by application with rte_flow_item_release() call.
> > Application can release the items after rule was created. However, 
> > if the application needs to create additional TMR rule for the same 
> > tunnel it will need to obtain PMD items again.
> >
> > Application cannot destroy rte_tunnel object before it releases all 
> > PMD actions & PMD items referencing that tunnel.
> >
> > [1]
> > https://eur03.sa

Re: [dpdk-dev] [PATCH 1/2] ethdev: allow negative values in flow rule types

[Gregory Etelson]

> -Original Message-
> From: Andrew Rybchenko 
> Sent: Sunday, July 5, 2020 16:34
> To: Gregory Etelson ; dev@dpdk.org
> Cc: Matan Azrad ; Raslan Darawsheh 
> ; Ori Kam 
> Subject: Re: [dpdk-dev] [PATCH 1/2] ethdev: allow negative values in 
> flow rule types
> 
> On 6/25/20 7:03 PM, Gregory Etelson wrote:
> > RTE flow items & actions use positive values in item & action type.
> > Negative values are reserved for PMD private types. PMD items & 
> > actions usually are not exposed to application and are not used to 
> > create RTE flows.
> >
> > The patch allows applications with access to PMD flow items & 
> > actions ability to integrate RTE and PMD items & actions and use 
> > them to create flow rule.
> >
> > Signed-off-by: Gregory Etelson 
> > Acked-by: Ori Kam 
> > ---
> >  lib/librte_ethdev/rte_flow.c | 30 --
> >  1 file changed, 24 insertions(+), 6 deletions(-)
> >
> > diff --git a/lib/librte_ethdev/rte_flow.c 
> > b/lib/librte_ethdev/rte_flow.c index 1685be5f73..c19d25649f 100644
> > --- a/lib/librte_ethdev/rte_flow.c
> > +++ b/lib/librte_ethdev/rte_flow.c
> > @@ -563,7 +563,12 @@ rte_flow_conv_item_spec(void *buf, const size_t
> size,
> > }
> > break;
> > default:
> > -   off = rte_flow_desc_item[item->type].size;
> > +   /**
> > +* allow PMD private flow item
> > +*/
> > +   off = (uint32_t)item->type <= INT_MAX ?
> > +   rte_flow_desc_item[item->type].size :
> > +   sizeof(void *);
> 
> May be it is out-of-scope of the patch (strictly speaking), but usage of 'off'
> variable is very misleading here. It is not used as an offset. It is 
> used as a size to copy.
>

The 'off' variable in that scope refers to object size to copy. 
I did not change it because it's not related to proposed change.
 
> Also it is absolutely unclear why sizeof(void *) is a right size for 
> PMD private flow items.

RTE flow library functions cannot work with PMD private items & actions 
(elements) 
because RTE flow has no API to query PMD flow object size . In the patch, 
PMD flow elements use object pointer. RTE flow library functions handle PMD 
element object size 
as size of a pointer. PMD handles its objects internally.

Re: [dpdk-dev] [PATCH 20.11 16/19] doc: remove references to make in prog guides

[Laatz, Kevin]

On 07/08/2020 13:30, Ciara Power wrote:

Make is no longer supported for compiling DPDK, references are now
removed in the documentation.

Signed-off-by: Ciara Power 
---
  doc/guides/prog_guide/build_app.rst   |  46 +---
  .../prog_guide/dev_kit_build_system.rst   | 218 +-
  .../prog_guide/dev_kit_root_make_help.rst | 188 ---
  .../prog_guide/env_abstraction_layer.rst  |  17 +-
  .../prog_guide/ext_app_lib_make_help.rst  |  25 +-
  doc/guides/prog_guide/graph_lib.rst   |   6 +-
  doc/guides/prog_guide/intro.rst   |   2 +-
  .../prog_guide/ip_fragment_reassembly_lib.rst |   5 -
  .../link_bonding_poll_mode_drv_lib.rst|   5 -
  doc/guides/prog_guide/lto.rst |  13 +-
  doc/guides/prog_guide/mbuf_lib.rst|   4 +-
  doc/guides/prog_guide/mempool_lib.rst |   7 +-
  doc/guides/prog_guide/overview.rst|  12 +-
  doc/guides/prog_guide/profile_app.rst |  15 +-
  doc/guides/prog_guide/qos_framework.rst   |  10 +-
  doc/guides/prog_guide/rcu_lib.rst |   7 +-
  doc/guides/prog_guide/source_org.rst  |  23 +-
  doc/guides/prog_guide/trace_lib.rst   |   3 +-
  .../prog_guide/writing_efficient_code.rst |   3 +-
  19 files changed, 36 insertions(+), 573 deletions(-)
  delete mode 100644 doc/guides/prog_guide/dev_kit_root_make_help.rst

diff --git a/doc/guides/prog_guide/build_app.rst 
b/doc/guides/prog_guide/build_app.rst
index bffa55bbef..54e4283752 100644
--- a/doc/guides/prog_guide/build_app.rst
+++ b/doc/guides/prog_guide/build_app.rst
@@ -9,14 +9,11 @@ Building Your Own Application
  Compiling a Sample Application in the Development Kit Directory
  ---
  
-When compiling a sample application (for example, hello world), the following variables must be exported:

-RTE_SDK and RTE_TARGET.
+To compile a sample application (for example, hello world):
  
  .. code-block:: console
  
  ~/DPDK$ cd examples/helloworld/

-~/DPDK/examples/helloworld$ export RTE_SDK=/home/user/DPDK
-~/DPDK/examples/helloworld$ export RTE_TARGET=x86_64-native-linux-gcc
  ~/DPDK/examples/helloworld$ make
  CC main.o
  LD helloworld


While the example apps will still support make, it would be good to give 
these examples for meson IMO.




@@ -39,8 +36,6 @@ The sample application (Hello World) can be duplicated in a 
new directory as a s
  
  ~$ cp -r DPDK/examples/helloworld my_rte_app

  ~$ cd my_rte_app/
-~/my_rte_app$ export RTE_SDK=/home/user/DPDK
-~/my_rte_app$ export RTE_TARGET=x86_64-native-linux-gcc
  ~/my_rte_app$ make
  CC main.o
  LD helloworld
@@ -53,47 +48,10 @@ Customizing Makefiles
  Application Makefile
  
  
-The default makefile provided with the Hello World sample application is a good starting point. It includes:

-
-*   $(RTE_SDK)/mk/rte.vars.mk at the beginning
-
-*   $(RTE_SDK)/mk/rte.extapp.mk at the end
+The default makefile provided with the Hello World sample application is a 
good starting point.
  
  The user must define several variables:
  
  *   APP: Contains the name of the application.
  
  *   SRCS-y: List of source files (\*.c, \*.S).

-
-Library Makefile
-
-
-It is also possible to build a library in the same way:
-
-*   Include $(RTE_SDK)/mk/rte.vars.mk at the beginning.
-
-*   Include $(RTE_SDK)/mk/rte.extlib.mk  at the end.
-
-The only difference is that APP should be replaced by LIB, which contains the 
name of the library. For example, libfoo.a.
-
-Customize Makefile Actions
-~~
-
-Some variables can be defined to customize Makefile actions. The most common 
are listed below. Refer to
-:ref:`Makefile Description ` section in
-:ref:`Development Kit Build System `
-
-chapter for details.
-
-*   VPATH: The path list where the build system will search for sources. By 
default,
-RTE_SRCDIR will be included in VPATH.
-
-*   CFLAGS_my_file.o: The specific flags to add for C compilation of my_file.c.
-
-*   CFLAGS: The flags to use for C compilation.
-
-*   LDFLAGS: The flags to use for linking.
-
-*   CPPFLAGS: The flags to use to provide flags to the C preprocessor (only 
useful when assembling .S files)
-
-*   LDLIBS: A list of libraries to link with (for example, -L /path/to/libfoo 
- lfoo)



diff --git a/doc/guides/prog_guide/ip_fragment_reassembly_lib.rst 
b/doc/guides/prog_guide/ip_fragment_reassembly_lib.rst
index 6ac1bba649..314d4adbb8 100644
--- a/doc/guides/prog_guide/ip_fragment_reassembly_lib.rst
+++ b/doc/guides/prog_guide/ip_fragment_reassembly_lib.rst
@@ -103,8 +103,3 @@ Debug logging and Statistics Collection
  
  The RTE_LIBRTE_IP_FRAG_TBL_STAT config macro controls statistics collection for the Fragment Table.

  This macro is not enabled by default.
-
-The RTE_LIBRTE_IP_FRAG_DEBUG controls debug logging of IP fragments processing 
and re

[dpdk-dev] [PATCH] net/ark: fix meson build

[Ed Czeck]

* Set RTE_LIBRTE_ARK_PAD_TX in local meson.build to match
the CONFIG_RTE_LIBRTE_ARK_PAD_TX setting used in make.
* Install header file needed for dynamic library.

Signed-off-by: Ed Czeck 
---
 drivers/net/ark/meson.build | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ark/meson.build b/drivers/net/ark/meson.build
index 99151bba1..6840bc622 100644
--- a/drivers/net/ark/meson.build
+++ b/drivers/net/ark/meson.build
@@ -11,3 +11,6 @@ sources = files('ark_ddm.c',
'ark_pktgen.c',
'ark_rqp.c',
'ark_udm.c')
+
+install_headers('ark_ext.h')
+cflags += '-DRTE_LIBRTE_ARK_PAD_TX'
-- 
2.17.1

Re: [dpdk-dev] [PATCH 1/4] net/netvsc: move rxbuf_info from per-device to per-queue

[Ferruh Yigit]

On 8/17/2020 12:11 AM, Stephen Hemminger wrote:
> On Mon, 10 Aug 2020 19:33:11 -0700
> lon...@linuxonhyperv.com wrote:
> 
>> From: Long Li 
>>
>> netvsc uses rxbuf_info buffer to track received packets attached via
>> rte_pktmbuf_attach_extbuf() and ack the host based on usage count. It uses
>> the transaction_id in the VMBus packet to locate where to use memory in the
>> rxbuf_info.
>>
>> This is not correct in multiple channel setup, as different channels may
>> return idential transaction_ids at a time, and may corrupt the rxbuf_info
>> buffer.
>>
>> Fix this by defining rxbuf_info for each queue.
>>
>> Fixes: 4e9c73e96 ("net/netvsc: add Hyper-V network device")
>> Cc: sta...@dpdk.org
>> Signed-off-by: Long Li 
> 
> Acked-by: Stephen Hemminger 
> 

Series applied to dpdk-next-net/main, thanks.

Re: [dpdk-dev] [PATCH 20.11 16/19] doc: remove references to make in prog guides

[Stephen Hemminger]

On Mon, 17 Aug 2020 14:54:21 +0100
Bruce Richardson  wrote:

> > diff --git a/doc/guides/prog_guide/dev_kit_build_system.rst 
> > b/doc/guides/prog_guide/dev_kit_build_system.rst
> > index 74dba4dd16..91d2120e22 100644
> > --- a/doc/guides/prog_guide/dev_kit_build_system.rst
> > +++ b/doc/guides/prog_guide/dev_kit_build_system.rst
> > @@ -31,51 +31,17 @@ Each build directory contains include files, libraries, 
> > and applications.
> >  A build directory is specific to a configuration that includes 
> > architecture + execution environment + toolchain.
> >  It is possible to have several build directories sharing the same sources 
> > with different configurations.
> >  
> > -For instance, to create a new build directory called my_sdk_build_dir 
> > using the default configuration template config/defconfig_x86_64-linux,
> > -we use:
> > -  
> Rather than selectively removing parts of this file and then looking to
> replace them with meson equivalents, I think we should just completely
> remove this section. The info for using the build system and the variables
> that meson uses are already covered in the contributors guide (section 1.11
> specifically).

Agreed, until all of mk/ is gone, DPDK can't really say it doesn't support make.

Re: [dpdk-dev] [PATCH V2] net/hns3: support getting Tx and Rx queue information

[Ferruh Yigit]

On 8/18/2020 4:07 AM, Wei Hu (Xavier) wrote:
> From: Huisong Li 
> 
> This patch adds support for querying Rx/Tx queue information.
> 
> Currently, if there are not available Rx buffer descriptors in receiving
> direction based on hns3 network engine, incoming packets will always be
> dropped by hardware. This patch reports the '.rx_drop_en' information to
> DPDK framework in the '.dev_infos_get', '.rxq_info_get' and
> '.rx_queue_setup' ops implementation function.
> 
> Signed-off-by: Huisong Li 
> Signed-off-by: Wei Hu (Xavier) 

<...>

> @@ -2495,6 +2495,15 @@ hns3_dev_infos_get(struct rte_eth_dev *eth_dev, struct 
> rte_eth_dev_info *info)
>   .nb_mtu_seg_max = HNS3_MAX_NON_TSO_BD_PER_PKT,
>   };
>  
> + info->default_rxconf = (struct rte_eth_rxconf) {
> + /*
> +  * If there are no available Rx buffer descriptors, incoming
> +  * packets are always dropped by hardware based on hns3 network
> +  * engine.
> +  */
> + .rx_drop_en = 1,
> + };

Can you please separate this into two patches, first one for 'rx_drop_en'
related changes to existing code, second one to add queue info get functions?

And you may prefer to request backporting the 'rx_drop_en' patch.

<...>

> +void
> +hns3_rxq_info_get(struct rte_eth_dev *dev, uint16_t queue_id,
> +   struct rte_eth_rxq_info *qinfo)
> +{
> + struct hns3_hw *hw = HNS3_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> + struct hns3_rx_queue *rxq = dev->data->rx_queues[queue_id];
> +
> + if (rxq == NULL) {
> + hns3_err(hw, "queue pointer of rx queue_id (%u) is NULL.",
> +  queue_id);
> + return;
> + }

'rxq' should not be 'NULL' at this stage, because of the "queue_id >=
dev->data->nb_rx_queues" check in 'rte_eth_rx_queue_info_get()'.
Can you please check if it can be 'NULL' and if it can be, better to check it in
the ethdev API, instead of doing in each PMD, both for 'rxq' & 'txq'.

Re: [dpdk-dev] [PATCH 20.11 14/19] doc: remove references to make in NIC guides

[Bruce Richardson]

On Fri, Aug 07, 2020 at 01:30:04PM +0100, Ciara Power wrote:
> Make is no longer supported for compiling DPDK, references are now
> removed in the documentation.
> 

Scanned the first half of the NIC guide with this patch applied. Some
comments below. The review of the second half of the doc will follow.

/Bruce

> Signed-off-by: Ciara Power 
> ---
>  doc/guides/nics/ark.rst | 26 ---
>  doc/guides/nics/atlantic.rst|  4 ---
>  doc/guides/nics/axgbe.rst   | 15 -
>  doc/guides/nics/bnx2x.rst   | 27 ---
>  doc/guides/nics/bnxt.rst|  3 --
>  doc/guides/nics/cxgbe.rst   | 13 
>  doc/guides/nics/dpaa.rst| 25 --
>  doc/guides/nics/dpaa2.rst   | 24 --
>  doc/guides/nics/ena.rst | 16 -
>  doc/guides/nics/enic.rst|  9 -
>  doc/guides/nics/fail_safe.rst   | 12 ---
>  doc/guides/nics/fm10k.rst   |  4 ---
>  doc/guides/nics/hinic.rst   |  9 -
>  doc/guides/nics/hns3.rst| 10 --
>  doc/guides/nics/i40e.rst| 28 ++--
>  doc/guides/nics/ice.rst | 17 --
>  doc/guides/nics/igc.rst | 14 
>  doc/guides/nics/intel_vf.rst| 14 ++--
>  doc/guides/nics/ionic.rst   |  8 -
>  doc/guides/nics/ipn3ke.rst  |  8 -
>  doc/guides/nics/liquidio.rst| 27 ---
>  doc/guides/nics/mlx4.rst| 51 -
>  doc/guides/nics/mlx5.rst| 58 -
>  doc/guides/nics/mvneta.rst  | 19 +--
>  doc/guides/nics/mvpp2.rst   | 29 +
>  doc/guides/nics/nfb.rst | 17 +-
>  doc/guides/nics/nfp.rst |  4 ---
>  doc/guides/nics/null.rst|  6 ++--
>  doc/guides/nics/octeontx.rst| 19 +--
>  doc/guides/nics/octeontx2.rst   | 11 ---
>  doc/guides/nics/pcap_ring.rst   | 22 ++---
>  doc/guides/nics/qede.rst| 17 ++
>  doc/guides/nics/sfc_efx.rst | 15 -
>  doc/guides/nics/softnic.rst |  9 -
>  doc/guides/nics/szedata2.rst| 18 +-
>  doc/guides/nics/thunderx.rst| 20 
>  doc/guides/nics/vdev_netvsc.rst |  6 
>  37 files changed, 26 insertions(+), 608 deletions(-)
> 

The features.rst file needs a small update - near the end where the
supported architectures are listed, we need to remove the "Use defconfig_*"
values. I don't think any replacement text is needed for those.


> diff --git a/doc/guides/nics/bnxt.rst b/doc/guides/nics/bnxt.rst
> index 129a16cfc7..8c0d60f154 100644
> --- a/doc/guides/nics/bnxt.rst
> +++ b/doc/guides/nics/bnxt.rst
> @@ -565,9 +565,6 @@ The BNXT PMD supports a PTP client application to 
> communicate with a PTP master
>  clock using DPDK IEEE1588 APIs. Note that the PTP client application needs to
>  run on PF and vector mode needs to be disabled.
>  
> -For the PTP time synchronization support, the BNXT PMD must be compiled with
> -``CONFIG_RTE_LIBRTE_IEEE1588=y`` (this compilation flag is currently 
> pending).
> -
>  .. code-block:: console
>  
>  testpmd> set fwd ieee1588 // enable IEEE 1588 mode

There is also a reference to CONFIG_RTE_ETHDEV_QUEUE_STAT_CNTRS, which
should be changed to a reference to RTE_ETHDEV_QUEUE_STAT_CNTRS in
config/rte_config.h


> diff --git a/doc/guides/nics/cxgbe.rst b/doc/guides/nics/cxgbe.rst
> index 54a4c13899..628e8063c2 100644
> --- a/doc/guides/nics/cxgbe.rst
> +++ b/doc/guides/nics/cxgbe.rst
> @@ -90,19 +90,6 @@ Prerequisites
>  Pre-Installation Configuration
>  --
>  
> -Config File Options
> -~~~
> -
> -The following options can be modified in the ``.config`` file. Please note 
> that
> -enabling debugging options may affect system performance.
> -
> -- ``CONFIG_RTE_LIBRTE_CXGBE_PMD`` (default **y**)
> -
> -  Toggle compilation of librte_pmd_cxgbe driver.
> -
> -  .. note::
> -
> - This controls compilation of both CXGBE and CXGBEVF PMD.
>  
>  Runtime Options

The level headings of this section are now wrong. I think the heading
"Pre-Installation Configuration" should be removed and the "Runtime
Options" subsection promoted up a level.


> diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
> index b7430f6c4e..19f0b06885 100644
> --- a/doc/guides/nics/i40e.rst
> +++ b/doc/guides/nics/i40e.rst
> @@ -156,34 +156,12 @@ Config File Options
>  ~~~
>  
>  The following options can be modified in the ``config`` file.

The "config" file should be clarified as "config/rte_config.h". However,
I'd query if the values in that file actually need to be called out as
tunable in the documentation. Can you please check with the i40e
maintainers if they can be dropped here.

> -Please note that enabling debugging options may affect system performance.
>  
> -- ``CONFIG_RTE_LIBRTE_I40E_PMD`` (default ``y``)
> -
> -  Toggle compilation of the ``librte_pmd_i40e`` driver.
> -
> -- ``CONFIG_R

Re: [dpdk-dev] [PATCH] net/ark: fix meson build

[Ferruh Yigit]

On 8/19/2020 4:35 PM, Ed Czeck wrote:
> * Set RTE_LIBRTE_ARK_PAD_TX in local meson.build to match
> the CONFIG_RTE_LIBRTE_ARK_PAD_TX setting used in make.
> * Install header file needed for dynamic library.
> 
> Signed-off-by: Ed Czeck 
> ---
>  drivers/net/ark/meson.build | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/net/ark/meson.build b/drivers/net/ark/meson.build
> index 99151bba1..6840bc622 100644
> --- a/drivers/net/ark/meson.build
> +++ b/drivers/net/ark/meson.build
> @@ -11,3 +11,6 @@ sources = files('ark_ddm.c',
>   'ark_pktgen.c',
>   'ark_rqp.c',
>   'ark_udm.c')
> +
> +install_headers('ark_ext.h')
> +cflags += '-DRTE_LIBRTE_ARK_PAD_TX'
> 

Hi Ed,

Why not remove the 'RTE_LIBRTE_ARK_PAD_TX' completely, this is a good
opportunity for it. In meson it is not really a config option as it is.

This can be default option or can be converted into runtime config.
For runtime config it can be a devarg, but since it is in Tx data path, if you
don't want additional condition perhaps defining this as an alternative Tx burst
function can work.

Re: [dpdk-dev] [PATCH 20.11 14/19] doc: remove references to make in NIC guides

[Bruce Richardson]

On Fri, Aug 07, 2020 at 01:30:04PM +0100, Ciara Power wrote:
> Make is no longer supported for compiling DPDK, references are now
> removed in the documentation.
> 
> Signed-off-by: Ciara Power 
> ---

Final comments for this review of the doc.

/Bruce


> diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst
> index 1f1e2f6c77..96c1015658 100644
> --- a/doc/guides/nics/mlx4.rst
> +++ b/doc/guides/nics/mlx4.rst
> @@ -16,11 +16,6 @@ the `Mellanox community 
> `_.
>  There is also a `section dedicated to this poll mode driver
>  
> `_.
>  
> -.. note::
> -
> -   Due to external dependencies, this driver is disabled by default. It must
> -   be enabled manually by setting ``CONFIG_RTE_LIBRTE_MLX4_PMD=y`` and
> -   recompiling DPDK.
>  
>  Implementation details
>  --
> @@ -56,42 +51,6 @@ Configuration
>  Compilation options
>  ~~~
>  
> -These options can be modified in the ``.config`` file.
> -
> -- ``CONFIG_RTE_LIBRTE_MLX4_PMD`` (default **n**)
> -
> -  Toggle compilation of librte_pmd_mlx4 itself.
> -
> -- ``CONFIG_RTE_IBVERBS_LINK_DLOPEN`` (default **n**)
> -
> -  Build PMD with additional code to make it loadable without hard
> -  dependencies on **libibverbs** nor **libmlx4**, which may not be installed
> -  on the target system.
> -
> -  In this mode, their presence is still required for it to run properly,
> -  however their absence won't prevent a DPDK application from starting (with
> -  ``CONFIG_RTE_BUILD_SHARED_LIB`` disabled) and they won't show up as
> -  missing with ``ldd(1)``.
> -
> -  It works by moving these dependencies to a purpose-built rdma-core "glue"
> -  plug-in which must either be installed in a directory whose name is based
> -  on ``CONFIG_RTE_EAL_PMD_PATH`` suffixed with ``-glue`` if set, or in a
> -  standard location for the dynamic linker (e.g. ``/lib``) if left to the
> -  default empty string (``""``).
> -
> -  This option has no performance impact.
> -
> -- ``CONFIG_RTE_IBVERBS_LINK_STATIC`` (default **n**)
> -
> -  Embed static flavor of the dependencies **libibverbs** and **libmlx4**
> -  in the PMD shared library or the executable static binary.
> -
> -- ``CONFIG_RTE_LIBRTE_MLX4_DEBUG`` (default **n**)
> -
> -  Toggle debugging code and stricter compilation flags. Enabling this option
> -  adds additional run-time checks and debugging messages at the cost of
> -  lower performance.
> -
>  This option is available in meson:

This heading needs to be reworded since the make options are now gone,
making it weird having it on it's own like that. I'd suggest changing it to
something like:

"The ibverbs libraries can be linked with this PMD in a number of ways,
configured by the "ibverbs_link" build option. This can take on the
values..."

Whatever way it is reworded, the rewording also applies to the mlx5 doc in
the next chapter too.

>  
>  - ``ibverbs_link`` can be ``static``, ``shared``, or ``dlopen``.
> @@ -104,9 +63,6 @@ Environment variables
>A list of directories in which to search for the rdma-core "glue" plug-in,
>separated by colons or semi-colons.
>  
> -  Only matters when compiled with ``CONFIG_RTE_IBVERBS_LINK_DLOPEN``
> -  enabled and most useful when ``CONFIG_RTE_EAL_PMD_PATH`` is also set,
> -  since ``LD_LIBRARY_PATH`` has no effect in this case.
>  
>  Run-time configuration
>  ~~
> @@ -245,13 +201,6 @@ Current RDMA core package and Linux kernel (recommended)
>  
>  .. _`RDMA core installation documentation`: 
> https://raw.githubusercontent.com/linux-rdma/rdma-core/master/README.md
>  
> -If rdma-core libraries are built but not installed, DPDK makefile can link 
> them,
> -thanks to these environment variables:
> -
> -   - ``EXTRA_CFLAGS=-I/path/to/rdma-core/build/include``
> -   - ``EXTRA_LDFLAGS=-L/path/to/rdma-core/build/lib``
> -   - ``PKG_CONFIG_PATH=/path/to/rdma-core/build/lib/pkgconfig``
> -
>  .. _Mellanox_OFED_as_a_fallback:
>  
>  Mellanox OFED as a fallback

> diff --git a/doc/guides/nics/mvneta.rst b/doc/guides/nics/mvneta.rst
> index c8b00ddf22..7cd7bea499 100644
> --- a/doc/guides/nics/mvneta.rst
> +++ b/doc/guides/nics/mvneta.rst
> @@ -13,12 +13,6 @@ Detailed information about SoCs that use PPv2 can be 
> obtained here:
>  
>  * https://www.marvell.com/embedded-processors/armada-3700/
>  
> -.. Note::
> -
> -   Due to external dependencies, this driver is disabled by default. It must
> -   be enabled manually by setting relevant configuration option manually.
> -   Please refer to `Config File Options`_ section for further details.
> -
>  
>  Features
>  
> @@ -84,14 +78,6 @@ Prerequisites
>  Pre-Installation Configuration
>  --
>  
> -Config File Options
> -~~~
> -
> -The following options can be modified in the ``config`` file.
> -
> -- ``CONFIG_RTE_LIBRTE_MVNETA_PMD`` (default ``n``)
> -
> -   

[dpdk-dev] [PATCH] net/vdev_netvsc: handle removal of associated pci device

[Stephen Hemminger]

The vdev_netvsc was not detecting when the associated PCI device
(SRIOV) was removed. Because of that it would keep feeding the
same (removed) device to failsafe PMD which would then unsuccessfully
try and probe for it.

Change to use a mark/sweep method to detect that PCI device was
removed, and also only tell failsafe about new PCI devices.
Vdev_netvsc does not have to keep stuffing the pipe with the
same already existing PCI device.

Fixes: e7dc5d7becc5 ("net/vdev_netvsc: implement core functionality")
Cc: ma...@mellanox.com, sta...@dpdk.org
Signed-off-by: Stephen Hemminger 
---
 drivers/net/vdev_netvsc/vdev_netvsc.c | 39 +++
 1 file changed, 34 insertions(+), 5 deletions(-)

diff --git a/drivers/net/vdev_netvsc/vdev_netvsc.c 
b/drivers/net/vdev_netvsc/vdev_netvsc.c
index 1ecb0b3e6a34..80a3158012ce 100644
--- a/drivers/net/vdev_netvsc/vdev_netvsc.c
+++ b/drivers/net/vdev_netvsc/vdev_netvsc.c
@@ -66,6 +66,7 @@ struct vdev_netvsc_ctx {
char devargs[256]; /**< Fail-safe device arguments. */
char if_name[IF_NAMESIZE]; /**< NetVSC netdevice name. */
unsigned int if_index; /**< NetVSC netdevice index. */
+   int pci_found; /**< Device detection */
struct rte_ether_addr if_addr; /**< NetVSC MAC address. */
int pipe[2];   /**< Fail-safe communication pipe. */
char yield[256];   /**< PCI sub-device arguments. */
@@ -405,11 +406,18 @@ vdev_netvsc_device_probe(const struct if_nameindex *iface,
len = strlen(addr);
if (!len)
return 0;
+
+   ctx->pci_found = 1;
+
+   /* Skip if this is same device already sent to failsafe */
+   if (strcmp(addr, ctx->yield) == 0)
+   return 0;
+
+   DRV_LOG(DEBUG, "associating PCI device \"%s\" with NetVSC"
+   " interface \"%s\" (index %u)", addr, ctx->if_name,
+   ctx->if_index);
+
/* Send PCI device argument to fail-safe PMD instance. */
-   if (strcmp(addr, ctx->yield))
-   DRV_LOG(DEBUG, "associating PCI device \"%s\" with NetVSC"
-   " interface \"%s\" (index %u)", addr, ctx->if_name,
-   ctx->if_index);
memmove(buf, addr, len + 1);
addr = buf;
buf[len] = '\n';
@@ -452,12 +460,33 @@ vdev_netvsc_alarm(__rte_unused void *arg)
struct vdev_netvsc_ctx *ctx;
int ret;
 
+   /* 1st pass: clear PCI flag on all devices */
+   LIST_FOREACH(ctx, &vdev_netvsc_ctx_list, entry) {
+   ctx->pci_found = 0;
+   }
+
+   /* 2nd pass: scan all system devices to look for changes to this device 
*/
LIST_FOREACH(ctx, &vdev_netvsc_ctx_list, entry) {
ret = vdev_netvsc_foreach_iface(vdev_netvsc_device_probe, 0,
  ctx);
-   if (ret < 0)
+
+   if (ret < 0) {
+   DRV_LOG(NOTICE, "can not scan devices for %s\n",
+   ctx->if_name);
break;
+   }
}
+
+   /* 3rd pass: detect PCI removal */
+   LIST_FOREACH(ctx, &vdev_netvsc_ctx_list, entry) {
+   if (!ctx->pci_found && ctx->yield[0]) {
+   DRV_LOG(DEBUG, "disassociating PCI device \"%s\" from 
NetVSC"
+   " interface \"%s\" (index %u)", ctx->yield, 
ctx->if_name,
+   ctx->if_index);
+   ctx->yield[0] = '\0';
+   }
+   }
+
if (!vdev_netvsc_ctx_count)
return;
ret = rte_eal_alarm_set(VDEV_NETVSC_PROBE_MS * 1000,
-- 
2.27.0

[dpdk-dev] [PATCH] net/ark: fix meson build

[Ed Czeck]

* Rename net/ark specific CONFIG_RTE macros to local macros.
* Change condition of ARK_PAD_TX to match behavior of meson build
to makefile build.
* Install header file needed for dynamic library.
* Update doc as required.

Signed-off-by: Ed Czeck 
---
 doc/guides/nics/ark.rst | 24 ++--
 drivers/net/ark/ark_logs.h  | 16 +++-
 drivers/net/ark/meson.build |  2 ++
 3 files changed, 23 insertions(+), 19 deletions(-)

diff --git a/doc/guides/nics/ark.rst b/doc/guides/nics/ark.rst
index 06e8c3374..4d8920cd0 100644
--- a/doc/guides/nics/ark.rst
+++ b/doc/guides/nics/ark.rst
@@ -124,27 +124,31 @@ Configuration Information
 
 **DPDK Configuration Parameters**
 
-  The following configuration options are available for the ARK PMD:
+  The following compile-time configuration options are available for the ARK 
PMD:
 
-   * **CONFIG_RTE_LIBRTE_ARK_PMD** (default y): Enables or disables inclusion
- of the ARK PMD driver in the DPDK compilation.
+   * **ARK_NOPAD_TX**:  When enabled TX
+ packets are not padded to 60 bytes to support downstream MACS.
 
-   * **CONFIG_RTE_LIBRTE_ARK_PAD_TX** (default y):  When enabled TX
- packets are padded to 60 bytes to support downstream MACS.
-
-   * **CONFIG_RTE_LIBRTE_ARK_DEBUG_RX** (default n): Enables or disables debug
+   * **ARK_DEBUG_RX**: Enables debug
  logging and internal checking of RX ingress logic within the ARK PMD 
driver.
 
-   * **CONFIG_RTE_LIBRTE_ARK_DEBUG_TX** (default n): Enables or disables debug
+   * **ARK_DEBUG_TX**: Enables debug
  logging and internal checking of TX egress logic within the ARK PMD 
driver.
 
-   * **CONFIG_RTE_LIBRTE_ARK_DEBUG_STATS** (default n): Enables or disables 
debug
+   * **ARK_DEBUG_STATS**: Enables debug
  logging of detailed packet and performance statistics gathered in
  the PMD and FPGA.
 
-   * **CONFIG_RTE_LIBRTE_ARK_DEBUG_TRACE** (default n): Enables or disables 
debug
+   * **ARK_DEBUG_TRACE**: Enables debug
  logging of detailed PMD events and status.
 
+Note that enabling debugging options may affect system performance.
+These options may be set by specifying them in CFLAG
+environment before the meson build set.   E.g.::
+
+export CFLAGS="-DARK_DEBUG_TRACE"
+meson build
+
 
 Building DPDK
 -
diff --git a/drivers/net/ark/ark_logs.h b/drivers/net/ark/ark_logs.h
index 44aac6102..125583475 100644
--- a/drivers/net/ark/ark_logs.h
+++ b/drivers/net/ark/ark_logs.h
@@ -6,14 +6,12 @@
 #define _ARK_DEBUG_H_
 
 #include 
-#include 
-
 
 /* Configuration option to pad TX packets to 60 bytes */
-#ifdef RTE_LIBRTE_ARK_PAD_TX
-#define ARK_TX_PAD_TO_60   1
-#else
+#ifdef ARK_NOPAD_TX
 #define ARK_TX_PAD_TO_60   0
+#else
+#define ARK_TX_PAD_TO_60   1
 #endif
 
 /* system camel case definition changed to upper case */
@@ -55,7 +53,7 @@ extern int ark_logtype;
 
 
 /* Debug macro for tracing full behavior, function tracing and messages*/
-#ifdef RTE_LIBRTE_ARK_DEBUG_TRACE
+#ifdef ARK_DEBUG_TRACE
 #define PMD_FUNC_LOG(level, fmt, ...) ARK_FUNC_ON(level, fmt, ##__VA_ARGS__)
 #define PMD_DEBUG_LOG(level, fmt, ...) ARK_TRACE_ON(level, fmt, ##__VA_ARGS__)
 #else
@@ -65,7 +63,7 @@ extern int ark_logtype;
 
 
 /* Debug macro for reporting FPGA statistics */
-#ifdef RTE_LIBRTE_ARK_DEBUG_STATS
+#ifdef ARK_DEBUG_STATS
 #define PMD_STATS_LOG(level, fmt, ...) ARK_TRACE_ON(level, fmt, ##__VA_ARGS__)
 #else
 #define PMD_STATS_LOG(level, fmt, ...)  ARK_TRACE_OFF(level, fmt, 
##__VA_ARGS__)
@@ -73,7 +71,7 @@ extern int ark_logtype;
 
 
 /* Debug macro for RX path */
-#ifdef RTE_LIBRTE_ARK_DEBUG_RX
+#ifdef ARK_DEBUG_RX
 #define ARK_RX_DEBUG 1
 #define PMD_RX_LOG(level, fmt, ...)  ARK_TRACE_ON(level, fmt, ##__VA_ARGS__)
 #else
@@ -82,7 +80,7 @@ extern int ark_logtype;
 #endif
 
 /* Debug macro for TX path */
-#ifdef RTE_LIBRTE_ARK_DEBUG_TX
+#ifdef ARK_DEBUG_TX
 #define ARK_TX_DEBUG   1
 #define PMD_TX_LOG(level, fmt, ...)  ARK_TRACE_ON(level, fmt, ##__VA_ARGS__)
 #else
diff --git a/drivers/net/ark/meson.build b/drivers/net/ark/meson.build
index 99151bba1..fbbc085bb 100644
--- a/drivers/net/ark/meson.build
+++ b/drivers/net/ark/meson.build
@@ -11,3 +11,5 @@ sources = files('ark_ddm.c',
'ark_pktgen.c',
'ark_rqp.c',
'ark_udm.c')
+
+install_headers('ark_ext.h')
-- 
2.17.1

Re: [dpdk-dev] [PATCH v7 1/5] net/bnxt: add support for aarch32

[Ajit Khaparde]

On Fri, Aug 14, 2020 at 3:32 AM Juraj Linkeš 
wrote:

> From: Ruifeng Wang 
>
> Expand vector PMD support to aarch32.
>
> Signed-off-by: Ruifeng Wang 
> ---
>  drivers/net/bnxt/Makefile   | 2 +-
>  drivers/net/bnxt/bnxt_rxq.h | 2 +-
>  drivers/net/bnxt/bnxt_rxr.h | 2 +-
>  drivers/net/bnxt/bnxt_txr.h | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/bnxt/Makefile b/drivers/net/bnxt/Makefile
> index 0c5b74918..06a47dc49 100644
> --- a/drivers/net/bnxt/Makefile
> +++ b/drivers/net/bnxt/Makefile
> @@ -43,7 +43,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_BNXT_PMD) += rte_pmd_bnxt.c
>  ifeq ($(CONFIG_RTE_ARCH_X86), y)
>  SRCS-$(CONFIG_RTE_LIBRTE_BNXT_PMD) += bnxt_rxtx_vec_sse.c
>  endif
> -ifeq ($(CONFIG_RTE_ARCH_ARM64), y)
> +ifneq ($(filter y,$(CONFIG_RTE_ARCH_ARM) $(CONFIG_RTE_ARCH_ARM64)),)
>  SRCS-$(CONFIG_RTE_LIBRTE_BNXT_PMD) += bnxt_rxtx_vec_neon.c
>  endif
>
Thanks for the changes.
With makefiles being deprecated, I don't think this will be required.
That said, I don't see drivers/net/bnxt/meson.build being modified.
Is that not required?


> diff --git a/drivers/net/bnxt/bnxt_rxq.h b/drivers/net/bnxt/bnxt_rxq.h
> index d5ce3b6d5..1c4027711 100644
> --- a/drivers/net/bnxt/bnxt_rxq.h
> +++ b/drivers/net/bnxt/bnxt_rxq.h
> @@ -22,7 +22,7 @@ struct bnxt_rx_queue {
> uint16_tnb_rx_hold; /* num held free RX desc */
> uint16_trx_free_thresh; /* max free RX desc to
> hold */
> uint16_tqueue_id; /* RX queue index */
> -#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64)
> +#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64) ||
> defined(RTE_ARCH_ARM)
> uint16_trxrearm_nb; /* number of descs to reinit.
> */
> uint16_trxrearm_start; /* next desc index to
> reinit. */
>  #endif
> diff --git a/drivers/net/bnxt/bnxt_rxr.h b/drivers/net/bnxt/bnxt_rxr.h
> index 2bf46cd91..e2fba1647 100644
> --- a/drivers/net/bnxt/bnxt_rxr.h
> +++ b/drivers/net/bnxt/bnxt_rxr.h
> @@ -221,7 +221,7 @@ int bnxt_init_one_rx_ring(struct bnxt_rx_queue *rxq);
>  int bnxt_rx_queue_start(struct rte_eth_dev *dev, uint16_t rx_queue_id);
>  int bnxt_rx_queue_stop(struct rte_eth_dev *dev, uint16_t rx_queue_id);
>
> -#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64)
> +#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64) ||
> defined(RTE_ARCH_ARM)
>  uint16_t bnxt_recv_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
> uint16_t nb_pkts);
>  int bnxt_rxq_vec_setup(struct bnxt_rx_queue *rxq);
> diff --git a/drivers/net/bnxt/bnxt_txr.h b/drivers/net/bnxt/bnxt_txr.h
> index 7715c11b8..38e5ac9df 100644
> --- a/drivers/net/bnxt/bnxt_txr.h
> +++ b/drivers/net/bnxt/bnxt_txr.h
> @@ -59,7 +59,7 @@ uint16_t bnxt_xmit_pkts(void *tx_queue, struct rte_mbuf
> **tx_pkts,
>uint16_t nb_pkts);
>  uint16_t bnxt_dummy_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
>   uint16_t nb_pkts);
> -#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64)
> +#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64) ||
> defined(RTE_ARCH_ARM)
>  uint16_t bnxt_xmit_pkts_vec(void *tx_queue, struct rte_mbuf **tx_pkts,
> uint16_t nb_pkts);
>  #endif
> --
> 2.20.1
>
>

Re: [dpdk-dev] [PATCH v5 2/2] test/cpuflag: add new flags for ARM64 platform

[Wei Hu (Xavier)]

Hi, Ruifeng Wang

On 2020/8/19 16:11, Ruifeng Wang wrote:



-Original Message-
From: Wei Hu (Xavier) 
Sent: Wednesday, August 19, 2020 3:04 PM
To: dev@dpdk.org
Cc: nd ; Honnappa Nagarahalli
; Ruifeng Wang
; jerinjac...@gmail.com;
xavier.hu...@huawei.com
Subject: [PATCH v5 2/2] test/cpuflag: add new flags for ARM64 platform

From: "Wei Hu (Xavier)" 

This patch adds new flags into the test_cpuflags() functions for ARM64
platform, such as RTE_CPUFLAG_SVE, etc.

Signed-off-by: Wei Hu (Xavier) 
Reviewed-by: Ruifeng Wang 
---
v4 -> v5: Use double '\t' for better alignment.
v4: Initial patch.
---
  app/test/test_cpuflags.c | 39
+++
  1 file changed, 39 insertions(+)

diff --git a/app/test/test_cpuflags.c b/app/test/test_cpuflags.c index
06718631f..7c71ffef1 100644
--- a/app/test/test_cpuflags.c
+++ b/app/test/test_cpuflags.c
@@ -118,6 +118,45 @@ test_cpuflags(void)

printf("Check for ATOMICS:\t");
CHECK_FOR_FLAG(RTE_CPUFLAG_ATOMICS);
+
+   printf("Check for SVE:\t\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVE);
+
+   printf("Check for SVE2:\t\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVE2);
+

Sorry if I didn't make it clear.
In v4, I meant we need double '\t' when checking for 'SVE' and 'SVE2' to align 
the check results with that of other flags.
You can check this by running cpuflags_autotest.


OK, I got it.
Thanks for you detail description.

Regards
Xavier

Thanks.
/Ruifeng

+   printf("Check for SVEAES:\t\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVEAES);
+
+   printf("Check for SVEPMULL:\t\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVEPMULL);
+
+   printf("Check for SVEBITPERM:\t\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVEBITPERM);
+
+   printf("Check for SVESHA3:\t\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVESHA3);
+
+   printf("Check for SVESM4:\t\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVESM4);
+
+   printf("Check for FLAGM2:\t\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_FLAGM2);
+
+   printf("Check for FRINT:\t\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_FRINT);
+
+   printf("Check for SVEI8MM:\t\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVEI8MM);
+
+   printf("Check for SVEF32MM:\t\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVEF32MM);
+
+   printf("Check for SVEF64MM:\t\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVEF64MM);
+
+   printf("Check for SVEBF16:\t\t");
+   CHECK_FOR_FLAG(RTE_CPUFLAG_SVEBF16);
  #endif

  #if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_I686)
--
2.27.0

[dpdk-dev] [PATCH v2 0/4] minor fixes for testpmd

[Wei Hu (Xavier)]

This series are minor fixes for testpmd application.

Chengchang Tang (3):
  app/testpmd: fix missing verification of port id
  app/testpmd: fix VLAN offload configuration when config fail
  app/testpmd: fix packet header in txonly mode

Huisong Li (1):
  app/testpmd: fix displaying Rx Tx queues information

 app/test-pmd/cmdline.c |  9 +
 app/test-pmd/config.c  | 80 +++---
 app/test-pmd/txonly.c  | 32 +
 3 files changed, 100 insertions(+), 21 deletions(-)

-- 
2.27.0

[dpdk-dev] [PATCH v2 1/4] app/testpmd: fix missing verification of port id

[Wei Hu (Xavier)]

From: Chengchang Tang 

To set Tx vlan offloads, it is required to stop port firstly. But before
checking whether the port is stopped, the port id entered by the user
is not checked for validity. When the port id is illegal, it would lead
to a segmentation fault since it attempts to access a member of
non-existent port.

This patch adds verification of port id in tx vlan offloads.

Fixes: 597f9fafe13b ("app/testpmd: convert to new Tx offloads API")
Cc: sta...@dpdk.org

Signed-off-by: Chengchang Tang 
Signed-off-by: Wei Hu (Xavier) 
---
 app/test-pmd/cmdline.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 0a6ed85f3..8377f8401 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -4268,6 +4268,9 @@ cmd_tx_vlan_set_parsed(void *parsed_result,
 {
struct cmd_tx_vlan_set_result *res = parsed_result;
 
+   if (port_id_is_invalid(res->port_id, ENABLED_WARN))
+   return;
+
if (!port_is_stopped(res->port_id)) {
printf("Please stop port %d first\n", res->port_id);
return;
@@ -4322,6 +4325,9 @@ cmd_tx_vlan_set_qinq_parsed(void *parsed_result,
 {
struct cmd_tx_vlan_set_qinq_result *res = parsed_result;
 
+   if (port_id_is_invalid(res->port_id, ENABLED_WARN))
+   return;
+
if (!port_is_stopped(res->port_id)) {
printf("Please stop port %d first\n", res->port_id);
return;
@@ -4435,6 +4441,9 @@ cmd_tx_vlan_reset_parsed(void *parsed_result,
 {
struct cmd_tx_vlan_reset_result *res = parsed_result;
 
+   if (port_id_is_invalid(res->port_id, ENABLED_WARN))
+   return;
+
if (!port_is_stopped(res->port_id)) {
printf("Please stop port %d first\n", res->port_id);
return;
-- 
2.27.0

[dpdk-dev] [PATCH v2 2/4] app/testpmd: fix VLAN offload configuration when config fail

[Wei Hu (Xavier)]

From: Chengchang Tang 

When failing to configure VLAN offloads after the port was started, there
is no need to update the port configuration. Currently, when user
configure an unsupported VLAN offloads and fails, and then restart the
port, it will fails since the configuration has been refreshed.

This patch makes the function return directly insead of refreshing the
configuration when execution fails.

Fixes: 384161e00627 ("app/testpmd: adjust on the fly VLAN configuration")
Cc: sta...@dpdk.org

Signed-off-by: Chengchang Tang 
Signed-off-by: Wei Hu (Xavier) 
---
 app/test-pmd/config.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 30bee3324..6e8e05ab1 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -3390,9 +3390,11 @@ vlan_extend_set(portid_t port_id, int on)
}
 
diag = rte_eth_dev_set_vlan_offload(port_id, vlan_offload);
-   if (diag < 0)
+   if (diag < 0) {
printf("rx_vlan_extend_set(port_pi=%d, on=%d) failed "
   "diag=%d\n", port_id, on, diag);
+   return;
+   }
ports[port_id].dev_conf.rxmode.offloads = port_rx_offloads;
 }
 
@@ -3417,9 +3419,11 @@ rx_vlan_strip_set(portid_t port_id, int on)
}
 
diag = rte_eth_dev_set_vlan_offload(port_id, vlan_offload);
-   if (diag < 0)
+   if (diag < 0) {
printf("rx_vlan_strip_set(port_pi=%d, on=%d) failed "
   "diag=%d\n", port_id, on, diag);
+   return;
+   }
ports[port_id].dev_conf.rxmode.offloads = port_rx_offloads;
 }
 
@@ -3458,9 +3462,11 @@ rx_vlan_filter_set(portid_t port_id, int on)
}
 
diag = rte_eth_dev_set_vlan_offload(port_id, vlan_offload);
-   if (diag < 0)
+   if (diag < 0) {
printf("rx_vlan_filter_set(port_pi=%d, on=%d) failed "
   "diag=%d\n", port_id, on, diag);
+   return;
+   }
ports[port_id].dev_conf.rxmode.offloads = port_rx_offloads;
 }
 
@@ -3485,9 +3491,11 @@ rx_vlan_qinq_strip_set(portid_t port_id, int on)
}
 
diag = rte_eth_dev_set_vlan_offload(port_id, vlan_offload);
-   if (diag < 0)
+   if (diag < 0) {
printf("%s(port_pi=%d, on=%d) failed "
   "diag=%d\n", __func__, port_id, on, diag);
+   return;
+   }
ports[port_id].dev_conf.rxmode.offloads = port_rx_offloads;
 }
 
-- 
2.27.0

[dpdk-dev] [PATCH v2 3/4] app/testpmd: fix packet header in txonly mode

[Wei Hu (Xavier)]

From: Chengchang Tang 

In txonly forward mode, the packet header is fixed by the initial
setting, including the packet length and checksum. So when the packets
varies, this may cause a packet header error. Currently, there are two
methods in txonly mode to randomly change the packets.
1. Set txsplit random and txpkts (x[,y]*), the number of segments
   each packets will be a random value between 1 and total number of
   segments determined by txpkts settings.
   The step as follows:
 a) ./testpmd -w xxx -l xx -n 4 -- -i --rxd  --txd 
 b) set fwd txonly
 c) set txsplit rand
 d) set txpkts 2048,2048,2048,2048
 e) start
The nb_segs of the packets sent by testpmd will be 1~4. The real packet
length will be 2048, 4096, 6144 and 8192. But in fact the packet length
in ip header and udp header will be fixed by 8178 and 8158.

2. Set txonly-multi-flow. the ip address will be varied to generate
   multiple flow.
   The step as follows:
 a) ./testpmd -w xxx -l xx -n 4 -- -i --txonly-multi-flow
 b) set fwd txonly
 c) start
The ip address of each pkts will change randomly, but since the header
is fixed, the checksum may be a error value.

Therefore, this patch adds a function to update the packet length and
check sum in the pkts header when the txsplit mode is set to rand or
multi-flow is set.

Fixes: 82010ef55e7c ("app/testpmd: make txonly mode generate multiple flows")
Fixes: 79bec05b32b7 ("app/testpmd: add ability to split outgoing packets")
Cc: sta...@dpdk.org

Signed-off-by: Chengchang Tang 
Signed-off-by: Wei Hu (Xavier) 
---
v1 -> v2: fix TYPO_SPELLING warning in the commit log.
---
 app/test-pmd/txonly.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/app/test-pmd/txonly.c b/app/test-pmd/txonly.c
index 3bae367ee..ad3b0a765 100644
--- a/app/test-pmd/txonly.c
+++ b/app/test-pmd/txonly.c
@@ -156,6 +156,34 @@ setup_pkt_udp_ip_headers(struct rte_ipv4_hdr *ip_hdr,
ip_hdr->hdr_checksum = (uint16_t) ip_cksum;
 }
 
+static inline void
+update_pkt_header(struct rte_mbuf *pkt, uint32_t total_pkt_len)
+{
+   struct rte_ipv4_hdr *ip_hdr;
+   struct rte_udp_hdr *udp_hdr;
+   uint16_t pkt_data_len;
+   uint16_t pkt_len;
+
+   pkt_data_len = (uint16_t) (total_pkt_len - (
+   sizeof(struct rte_ether_hdr) +
+   sizeof(struct rte_ipv4_hdr) +
+   sizeof(struct rte_udp_hdr)));
+   /* updata udp pkt length */
+   udp_hdr = rte_pktmbuf_mtod_offset(pkt, struct rte_udp_hdr *,
+   sizeof(struct rte_ether_hdr) +
+   sizeof(struct rte_ipv4_hdr));
+   pkt_len = (uint16_t) (pkt_data_len + sizeof(struct rte_udp_hdr));
+   udp_hdr->dgram_len = RTE_CPU_TO_BE_16(pkt_len);
+
+   /* updata ip pkt length and csum */
+   ip_hdr = rte_pktmbuf_mtod_offset(pkt, struct rte_ipv4_hdr *,
+   sizeof(struct rte_ether_hdr));
+   ip_hdr->hdr_checksum = 0;
+   pkt_len = (uint16_t) (pkt_len + sizeof(struct rte_ipv4_hdr));
+   ip_hdr->total_length = RTE_CPU_TO_BE_16(pkt_len);
+   ip_hdr->hdr_checksum = rte_ipv4_cksum(ip_hdr);
+}
+
 static inline bool
 pkt_burst_prepare(struct rte_mbuf *pkt, struct rte_mempool *mbp,
struct rte_ether_hdr *eth_hdr, const uint16_t vlan_tci,
@@ -223,6 +251,10 @@ pkt_burst_prepare(struct rte_mbuf *pkt, struct rte_mempool 
*mbp,
copy_buf_to_pkt(&pkt_udp_hdr, sizeof(pkt_udp_hdr), pkt,
sizeof(struct rte_ether_hdr) +
sizeof(struct rte_ipv4_hdr));
+
+   if (unlikely(tx_pkt_split == TX_PKT_SPLIT_RND) || txonly_multi_flow)
+   update_pkt_header(pkt, pkt_len);
+
if (unlikely(timestamp_enable)) {
uint64_t skew = RTE_PER_LCORE(timestamp_qskew);
struct {
-- 
2.27.0

[dpdk-dev] [PATCH v2 4/4] app/testpmd: fix displaying Rx Tx queues information

[Wei Hu (Xavier)]

From: Huisong Li 

Currently, the information of Rx/Tx queues from PMD driver is not displayed
exactly in the rxtx_config_display function. Because "ports[pid].rx_conf"
and "ports[pid].tx_conf" maintained in testpmd application may be not the
value actually used by PMD driver. For instance, user does not set a field,
but PMD driver has to use the default value.

This patch fixes rxtx_config_display so that the information of Rx/Tx
queues can be really displayed for the PMD driver that implement
.rxq_info_get and .txq_info_get ops callback function.

Fixes: 75c530c1bd5351 ("app/testpmd: fix port configuration print")
Fixes: d44f8a485f5d1f ("app/testpmd: enable per queue configure")
Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
Signed-off-by: Wei Hu (Xavier) 
---
 app/test-pmd/config.c | 64 +++
 1 file changed, 47 insertions(+), 17 deletions(-)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 6e8e05ab1..3ab24ebd2 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -2089,10 +2089,17 @@ rxtx_config_display(void)
struct rte_eth_txconf *tx_conf = &ports[pid].tx_conf[0];
uint16_t *nb_rx_desc = &ports[pid].nb_rx_desc[0];
uint16_t *nb_tx_desc = &ports[pid].nb_tx_desc[0];
-   uint16_t nb_rx_desc_tmp;
-   uint16_t nb_tx_desc_tmp;
struct rte_eth_rxq_info rx_qinfo;
struct rte_eth_txq_info tx_qinfo;
+   uint16_t rx_free_thresh_tmp;
+   uint16_t tx_free_thresh_tmp;
+   uint16_t tx_rs_thresh_tmp;
+   uint16_t nb_rx_desc_tmp;
+   uint16_t nb_tx_desc_tmp;
+   uint64_t offloads_tmp;
+   uint8_t pthresh_tmp;
+   uint8_t hthresh_tmp;
+   uint8_t wthresh_tmp;
int32_t rc;
 
/* per port config */
@@ -2106,41 +2113,64 @@ rxtx_config_display(void)
/* per rx queue config only for first queue to be less verbose 
*/
for (qid = 0; qid < 1; qid++) {
rc = rte_eth_rx_queue_info_get(pid, qid, &rx_qinfo);
-   if (rc)
+   if (rc) {
nb_rx_desc_tmp = nb_rx_desc[qid];
-   else
+   rx_free_thresh_tmp =
+   rx_conf[qid].rx_free_thresh;
+   pthresh_tmp = rx_conf[qid].rx_thresh.pthresh;
+   hthresh_tmp = rx_conf[qid].rx_thresh.hthresh;
+   wthresh_tmp = rx_conf[qid].rx_thresh.wthresh;
+   offloads_tmp = rx_conf[qid].offloads;
+   } else {
nb_rx_desc_tmp = rx_qinfo.nb_desc;
+   rx_free_thresh_tmp =
+   rx_qinfo.conf.rx_free_thresh;
+   pthresh_tmp = rx_qinfo.conf.rx_thresh.pthresh;
+   hthresh_tmp = rx_qinfo.conf.rx_thresh.hthresh;
+   wthresh_tmp = rx_qinfo.conf.rx_thresh.wthresh;
+   offloads_tmp = rx_qinfo.conf.offloads;
+   }
 
printf("RX queue: %d\n", qid);
printf("  RX desc=%d - RX free threshold=%d\n",
-   nb_rx_desc_tmp, rx_conf[qid].rx_free_thresh);
+   nb_rx_desc_tmp, rx_free_thresh_tmp);
printf("  RX threshold registers: pthresh=%d 
hthresh=%d "
" wthresh=%d\n",
-   rx_conf[qid].rx_thresh.pthresh,
-   rx_conf[qid].rx_thresh.hthresh,
-   rx_conf[qid].rx_thresh.wthresh);
-   printf("  RX Offloads=0x%"PRIx64"\n",
-   rx_conf[qid].offloads);
+   pthresh_tmp, hthresh_tmp, wthresh_tmp);
+   printf("  RX Offloads=0x%"PRIx64"\n", offloads_tmp);
}
 
/* per tx queue config only for first queue to be less verbose 
*/
for (qid = 0; qid < 1; qid++) {
rc = rte_eth_tx_queue_info_get(pid, qid, &tx_qinfo);
-   if (rc)
+   if (rc) {
nb_tx_desc_tmp = nb_tx_desc[qid];
-   else
+   tx_free_thresh_tmp =
+   tx_conf[qid].tx_free_thresh;
+   pthresh_tmp = tx_conf[qid].tx_thresh.pthresh;
+   hthresh_tmp = tx_conf[qid].tx_thresh.hthresh;
+   wthresh_tmp = tx_conf[qid].tx_thresh.wthresh;
+   offload

Re: [dpdk-dev] [PATCH v7 1/5] net/bnxt: add support for aarch32

[Ruifeng Wang]

From: Ajit Khaparde 
Sent: Thursday, August 20, 2020 1:46 AM
To: Juraj Linkeš 
Cc: Bruce Richardson ; Aaron Conole 
; maicolgabr...@hotmail.com; dpdk-dev ; 
Ruifeng Wang 
Subject: Re: [dpdk-dev] [PATCH v7 1/5] net/bnxt: add support for aarch32



On Fri, Aug 14, 2020 at 3:32 AM Juraj Linkeš 
mailto:juraj.lin...@pantheon.tech>> wrote:
From: Ruifeng Wang mailto:ruifeng.w...@arm.com>>

Expand vector PMD support to aarch32.

Signed-off-by: Ruifeng Wang mailto:ruifeng.w...@arm.com>>
---
 drivers/net/bnxt/Makefile   | 2 +-
 drivers/net/bnxt/bnxt_rxq.h | 2 +-
 drivers/net/bnxt/bnxt_rxr.h | 2 +-
 drivers/net/bnxt/bnxt_txr.h | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/bnxt/Makefile b/drivers/net/bnxt/Makefile
index 0c5b74918..06a47dc49 100644
--- a/drivers/net/bnxt/Makefile
+++ b/drivers/net/bnxt/Makefile
@@ -43,7 +43,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_BNXT_PMD) += rte_pmd_bnxt.c
 ifeq ($(CONFIG_RTE_ARCH_X86), y)
 SRCS-$(CONFIG_RTE_LIBRTE_BNXT_PMD) += bnxt_rxtx_vec_sse.c
 endif
-ifeq ($(CONFIG_RTE_ARCH_ARM64), y)
+ifneq ($(filter y,$(CONFIG_RTE_ARCH_ARM) $(CONFIG_RTE_ARCH_ARM64)),)
 SRCS-$(CONFIG_RTE_LIBRTE_BNXT_PMD) += bnxt_rxtx_vec_neon.c
 endif
Thanks for the changes.
With makefiles being deprecated, I don't think this will be required.
That said, I don't see drivers/net/bnxt/meson.build being modified.
Is that not required?

[Ruifeng] No, the meson.build doesn’t require to be modified.
It uses different method to flag inclusion of bnxt_rxtx_vec_neon.c and is 
compatible with aarch32 build.


diff --git a/drivers/net/bnxt/bnxt_rxq.h b/drivers/net/bnxt/bnxt_rxq.h
index d5ce3b6d5..1c4027711 100644
--- a/drivers/net/bnxt/bnxt_rxq.h
+++ b/drivers/net/bnxt/bnxt_rxq.h
@@ -22,7 +22,7 @@ struct bnxt_rx_queue {
uint16_tnb_rx_hold; /* num held free RX desc */
uint16_trx_free_thresh; /* max free RX desc to hold */
uint16_tqueue_id; /* RX queue index */
-#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64)
+#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64) || defined(RTE_ARCH_ARM)
uint16_trxrearm_nb; /* number of descs to reinit. */
uint16_trxrearm_start; /* next desc index to reinit. */
 #endif
diff --git a/drivers/net/bnxt/bnxt_rxr.h b/drivers/net/bnxt/bnxt_rxr.h
index 2bf46cd91..e2fba1647 100644
--- a/drivers/net/bnxt/bnxt_rxr.h
+++ b/drivers/net/bnxt/bnxt_rxr.h
@@ -221,7 +221,7 @@ int bnxt_init_one_rx_ring(struct bnxt_rx_queue *rxq);
 int bnxt_rx_queue_start(struct rte_eth_dev *dev, uint16_t rx_queue_id);
 int bnxt_rx_queue_stop(struct rte_eth_dev *dev, uint16_t rx_queue_id);

-#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64)
+#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64) || defined(RTE_ARCH_ARM)
 uint16_t bnxt_recv_pkts_vec(void *rx_queue, struct rte_mbuf **rx_pkts,
uint16_t nb_pkts);
 int bnxt_rxq_vec_setup(struct bnxt_rx_queue *rxq);
diff --git a/drivers/net/bnxt/bnxt_txr.h b/drivers/net/bnxt/bnxt_txr.h
index 7715c11b8..38e5ac9df 100644
--- a/drivers/net/bnxt/bnxt_txr.h
+++ b/drivers/net/bnxt/bnxt_txr.h
@@ -59,7 +59,7 @@ uint16_t bnxt_xmit_pkts(void *tx_queue, struct rte_mbuf 
**tx_pkts,
   uint16_t nb_pkts);
 uint16_t bnxt_dummy_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
  uint16_t nb_pkts);
-#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64)
+#if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64) || defined(RTE_ARCH_ARM)
 uint16_t bnxt_xmit_pkts_vec(void *tx_queue, struct rte_mbuf **tx_pkts,
uint16_t nb_pkts);
 #endif
--
2.20.1