[dpdk-dev] [PATCH] lpm/arm: fix SVE compile error with gcc8.3
If the target machine has SVE feature (e.g. "-march=armv8.2-a+sve'),
and the compiler is gcc8.3, it will compile error:
In file included from ../dpdk-next-net/lib/eal/common/
eal_common_options.c:38:
../dpdk-next-net/lib/eal/arm/include/rte_vect.h:13:10: fatal
error: arm_sve.h: No such file or directory
#include
^~~
compilation terminated.
The root cause is that gcc8.3 support SVE (the macro __ARM_FEATURE_SVE
was 1), but it doesn't support SVE ACLE [1].
The solution:
a) Detect compiler whether support SVE ACLE, if support then define
CC_SVE_ACLE_SUPPORT macro.
b) Use the CC_SVE_ACLE_SUPPORT macro to include SVE header file.
[1] ACLE: Arm C Language Extensions, the SVE ACLE header file is
, user should include it when writing ACLE SVE code.
Fixes: 67b68824a82d ("lpm/arm: support SVE")
Signed-off-by: Chengwen Feng
---
config/arm/meson.build | 5 +
lib/eal/arm/include/rte_vect.h | 2 +-
lib/lpm/rte_lpm.h | 2 +-
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/config/arm/meson.build b/config/arm/meson.build
index e83a56e..bff70e4 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -480,6 +480,11 @@ if (cc.get_define('__ARM_NEON', args: machine_args) != ''
or
compile_time_cpuflags += ['RTE_CPUFLAG_NEON']
endif
+if (cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != '' and
+cc.check_header('arm_sve.h'))
+dpdk_conf.set('CC_SVE_ACLE_SUPPORT', 1)
+endif
+
if cc.get_define('__ARM_FEATURE_CRC32', args: machine_args) != ''
compile_time_cpuflags += ['RTE_CPUFLAG_CRC32']
endif
diff --git a/lib/eal/arm/include/rte_vect.h b/lib/eal/arm/include/rte_vect.h
index 093e912..277b656 100644
--- a/lib/eal/arm/include/rte_vect.h
+++ b/lib/eal/arm/include/rte_vect.h
@@ -9,7 +9,7 @@
#include "generic/rte_vect.h"
#include "rte_debug.h"
#include "arm_neon.h"
-#ifdef __ARM_FEATURE_SVE
+#ifdef CC_SVE_ACLE_SUPPORT
#include
#endif
diff --git a/lib/lpm/rte_lpm.h b/lib/lpm/rte_lpm.h
index 28b5768..9262814 100644
--- a/lib/lpm/rte_lpm.h
+++ b/lib/lpm/rte_lpm.h
@@ -402,7 +402,7 @@ rte_lpm_lookupx4(const struct rte_lpm *lpm, xmm_t ip,
uint32_t hop[4],
uint32_t defv);
#if defined(RTE_ARCH_ARM)
-#ifdef __ARM_FEATURE_SVE
+#ifdef CC_SVE_ACLE_SUPPORT
#include "rte_lpm_sve.h"
#else
#include "rte_lpm_neon.h"
--
2.8.1
Re: [dpdk-dev] [PATCH v2] doc: clarify PMD order in release notes
20/05/2021 01:06, Ferruh Yigit: > On 5/19/2021 9:42 PM, Thomas Monjalon wrote: > > 12/05/2021 18:04, Ferruh Yigit: > >> PMD updates are expected in alphabetical order based on their vendor > >> name. Clarify this expectation in the section comment. > >> > >> Signed-off-by: Ferruh Yigit > >> --- > >> - * Device abstraction libs and PMDs > >> + * Device abstraction libs and PMDs (PMDs ordered alphabetically by > >> vendor name) > > > > I would avoid the repetition of "PMDs". > > May I apply with this modification? > > Ack, if it is not too late. Applied, thanks
Re: [dpdk-dev] [PATCH] devtools: add cppcheck wrapper
11/02/2021 18:27, Ferruh Yigit:
> +CPPCHECK_BIN=cppcheck
> +out=cppcheck_error.txt
In general we generate files in $(mktemp -t dpdk.cppcheck.XX)
The path is printed at the end anyway.
> +
> +which ${CPPCHECK_BIN} > /dev/null 2> /dev/null
> +if [ $? -ne 0 ]; then
> + echo "${CPPCHECK_BIN} is missing!"
Curly braces are not needed.
> + exit 1
> +fi
> +
> +print_usage () {
> + cat <<- END_OF_HELP
> + usage: $(basename $0) [-h] [path]
> +
> + Wrapper on checkpatch tool. Output goes to ${out} file.
s/checkpatch/cppcheck/
> +
> + Without parameter current folder with all subfolders scanned. It is
> possible
> + to provide a sub-folder to recude the scan to that folder.
A bit hard to read :)
> + END_OF_HELP
> +}
> +
> +if [ "$1" = "-h" ]; then
> + print_usage
> + exit 1;
> +fi
> +
> +dir=${1:-$(dirname $(readlink -f $0))/..}
> +if [ ! -e ${dir} ]; then
> + echo "\"${dir}\" is not valid folder/file to check"
> + exit 1
> +fi
> +
> +
> +suppress_args="
> + --suppress=invalidPrintfArgType_sint \
> + --suppress=invalidPrintfArgType_uint \
> + --suppress=duplicateAssignExpression \
> + --suppress=nullPointerRedundantCheck \
> + --suppress=identicalConditionAfterEarlyExit \
> + --suppress=objectIndex
> + "
> +
> +# all, warning, performance, portability,
> +# information, unusedFunction, missingInclude
> +additional_checks=warning
> +
> +${CPPCHECK_BIN} \
> + -j64 \
> + --language=c \
> + --enable=${additional_checks} \
> + --force \
> + ${suppress_args} \
> + ${dir} \
> + 2> ${out}
Is it possible to have only errors by default in the output,
and add all lines about what is being checked in a verbose mode?
> +
> +if [ $? -eq 0 ]; then
> + echo -e "\nOutput saved to ${out}"
Please prefer printf.
> +else
> + exit $?
> +fi
The report has 2000 lines of defects,
and it seems to have lots of false positive.
Is it possible to reduce them?
Re: [dpdk-dev] [PATCH v6 2/2] net/hns3: refactor SVE code compile method
On 5/20/2021 2:11 AM, fengchengwen wrote:
>
>
> On 2021/5/19 23:02, Ferruh Yigit wrote:
>> On 5/19/2021 2:25 PM, Chengwen Feng wrote:
>>> Currently, the SVE code is compiled only when -march supports SVE
>>> (e.g. '-march=armv8.2a+sve'), there maybe some problem[1] with this
>>> approach.
>>>
>>> The solution:
>>> a. If the minimum instruction set support SVE then compiles it.
>>> b. Else if the compiler support SVE then compiles it.
>>> c. Otherwise don't compile it.
>>>
>>> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
>>>
>>> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
>>> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
>>> Cc: sta...@dpdk.org
>>>
>>> Signed-off-by: Chengwen Feng
>>
>> The patch passes the CI build [1], but in that test sve file is not compiled
>> at
>> all because of missing header file [2].
>>
>
> Yes, it was designed as it.
> In hns3 meson.build we call cc.check_header('arm_sve.h'), and gcc9 don't have
> this headerfile.
>
>> I wonder if the warning caused by conflicting switch [3] is still valid, we
>> need
>> a platform that sve file is compiled to verify this. Do you have this
>> environment, that sets '-mcpu=armv8.1-a'.
>>
>
> It already fix by filterout '-march' '-mcpu' '-mtune' in hns3 meson.build of
> this patch
> If don't add the above filtout logic:
> a) Test result with gcc8.3 and crossfile thunder2:
> cc1: warning: switch ‘-mcpu=thunderx2t99’ conflicts with
> ‘-march=armv8.2-a+sve’ switch
> b) Test result with gcc9.2 and crossfile thunder2:
> cc1: warning: switch ‘-mcpu=armv8.1-a’ conflicts with ‘-march=armv8.2-a’
> switch
>
> Note: the gcc8.3/9.2 version detail:
> ./aarch64-linux-gnu-gcc --version
> aarch64-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture
> 8.3-2019.03 (arm-rel-8.36)) 8.3.0
> ./aarch64-none-linux-gnu-gcc --version
> aarch64-none-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture
> 9.2-2019.12 (arm-9.10)) 9.2.1 20191025
>
Hi Chengwen,
-rc4 is already out and release is planned for tomorrow, so it is late to get
this patch now, let's proceed with it in next release.
>>
>> Btw, CI reports unit test failure, I don't think it is related with this
>> patch
>> but can you please double check?
>>
>
> Agree, it is atomic_autotest and malloc_autotest failed, it hasn't run any
> hns3 driver's code.
>
>>
>>
>> [1]
>> https://lab.dpdk.org/results/dashboard/patchsets/17135/
>>
>> [2]
>> Check usable header "arm_sve.h" : NO
>>
>> [3]
>> error: switch ‘-mcpu=armv8.1-a’ conflicts with ‘-march=armv8.2-a’ switch
>> [-Werror]
>>
>>> ---
>>> drivers/net/hns3/hns3_rxtx.c | 2 +-
>>> drivers/net/hns3/meson.build | 21 -
>>> 2 files changed, 21 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
>>> index 1d7a769..4ef20c6 100644
>>> --- a/drivers/net/hns3/hns3_rxtx.c
>>> +++ b/drivers/net/hns3/hns3_rxtx.c
>>> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
>>> static bool
>>> hns3_get_sve_support(void)
>>> {
>>> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
>>> +#if defined(CC_SVE_SUPPORT)
>>> if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
>>> return false;
>>> if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
>>> diff --git a/drivers/net/hns3/meson.build b/drivers/net/hns3/meson.build
>>> index 53c7df7..5f9af9b 100644
>>> --- a/drivers/net/hns3/meson.build
>>> +++ b/drivers/net/hns3/meson.build
>>> @@ -35,7 +35,26 @@ deps += ['hash']
>>>
>>> if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
>>> sources += files('hns3_rxtx_vec.c')
>>> -if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
>>> +
>>> +# compile SVE when:
>>> +# a. support SVE in minimum instruction set baseline
>>> +# b. it's not minimum instruction set, but compiler support
>>> +if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != '' and
>>> cc.check_header('arm_sve.h')
>>> +cflags += ['-DCC_SVE_SUPPORT']
>>> sources += files('hns3_rxtx_vec_sve.c')
>>> +elif cc.has_argument('-march=armv8.2-a+sve') and
>>> cc.check_header('arm_sve.h')
>>> +sve_cflags = ['-DCC_SVE_SUPPORT']
>>> +foreach flag: cflags
>>> +# filterout -march -mcpu -mtune
>>> +if not (flag.startswith('-march=') or
>>> flag.startswith('-mcpu=') or flag.startswith('-mtune='))
>>> +sve_cflags += flag
>>> +endif
>>> +endforeach
>>> +hns3_sve_lib = static_library('hns3_sve_lib',
>>> +'hns3_rxtx_vec_sve.c',
>>> +dependencies: [static_rte_ethdev],
>>> +include_directories: includes,
>>> +c_args: [sve_cflags, '-march=armv8.2-a+sve'])
>>> +objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
>>> endif
>>> endif
>>>
>>
>>
>> .
>>
>
[dpdk-dev] [PATCH] devtools: warn about release notes updates
Touching release notes should only be for the current version.
Signed-off-by: David Marchand
---
devtools/checkpatches.sh | 44 ++--
1 file changed, 33 insertions(+), 11 deletions(-)
diff --git a/devtools/checkpatches.sh b/devtools/checkpatches.sh
index db4c7d8301..91560cb399 100755
--- a/devtools/checkpatches.sh
+++ b/devtools/checkpatches.sh
@@ -9,7 +9,9 @@
# - DPDK_CHECKPATCH_OPTIONS
. $(dirname $(readlink -f $0))/load-devel-config
-VALIDATE_NEW_API=$(dirname $(readlink -f $0))/check-symbol-change.sh
+ROOTDIR=$(readlink -f $(dirname $(readlink -f $0))/..)
+VALIDATE_NEW_API=$ROOTDIR/devtools/check-symbol-change.sh
+FORBIDDEN_TOKENS_SCRIPT=$ROOTDIR/devtools/check-forbidden-tokens.awk
# Enable codespell by default. This can be overwritten from a config file.
# Codespell can also be enabled by setting DPDK_CHECKPATCH_CODESPELL to a
valid path
@@ -58,7 +60,7 @@ check_forbidden_additions() { #
-v EXPRESSIONS="rte_panic\\\( rte_exit\\\(" \
-v RET_ON_FAIL=1 \
-v MESSAGE='Using rte_panic/rte_exit' \
- -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
+ -f $FORBIDDEN_TOKENS_SCRIPT \
"$1" || res=1
# refrain from using compiler attribute without defining a common macro
@@ -66,7 +68,7 @@ check_forbidden_additions() { #
-v EXPRESSIONS="__attribute__" \
-v RET_ON_FAIL=1 \
-v MESSAGE='Using compiler attribute directly' \
- -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
+ -f $FORBIDDEN_TOKENS_SCRIPT \
"$1" || res=1
# forbid variable declaration inside "for" loop
@@ -74,7 +76,7 @@ check_forbidden_additions() { #
-v
EXPRESSIONS='for[[:space:]]*\\((char|u?int|unsigned|s?size_t)' \
-v RET_ON_FAIL=1 \
-v MESSAGE='Declaring a variable inside for()' \
- -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
+ -f $FORBIDDEN_TOKENS_SCRIPT \
"$1" || res=1
# refrain from new additions of 16/32/64 bits rte_atomicNN_xxx()
@@ -82,7 +84,7 @@ check_forbidden_additions() { #
-v EXPRESSIONS="rte_atomic[0-9][0-9]_.*\\\(" \
-v RET_ON_FAIL=1 \
-v MESSAGE='Using rte_atomicNN_xxx' \
- -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
+ -f $FORBIDDEN_TOKENS_SCRIPT \
"$1" || res=1
# refrain from new additions of rte_smp_[r/w]mb()
@@ -90,7 +92,7 @@ check_forbidden_additions() { #
-v EXPRESSIONS="rte_smp_(r|w)?mb\\\(" \
-v RET_ON_FAIL=1 \
-v MESSAGE='Using rte_smp_[r/w]mb' \
- -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
+ -f $FORBIDDEN_TOKENS_SCRIPT \
"$1" || res=1
# refrain from using compiler __sync_xxx builtins
@@ -98,7 +100,7 @@ check_forbidden_additions() { #
-v EXPRESSIONS="__sync_.*\\\(" \
-v RET_ON_FAIL=1 \
-v MESSAGE='Using __sync_xxx builtins' \
- -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
+ -f $FORBIDDEN_TOKENS_SCRIPT \
"$1" || res=1
# refrain from using compiler __atomic_thread_fence()
@@ -107,7 +109,7 @@ check_forbidden_additions() { #
-v EXPRESSIONS="__atomic_thread_fence\\\(" \
-v RET_ON_FAIL=1 \
-v MESSAGE='Using __atomic_thread_fence' \
- -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
+ -f $FORBIDDEN_TOKENS_SCRIPT \
"$1" || res=1
# forbid use of experimental build flag except in examples
@@ -115,7 +117,7 @@ check_forbidden_additions() { #
-v EXPRESSIONS='-DALLOW_EXPERIMENTAL_API
allow_experimental_apis' \
-v RET_ON_FAIL=1 \
-v MESSAGE='Using experimental build flag for in-tree
compilation' \
- -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
+ -f $FORBIDDEN_TOKENS_SCRIPT \
"$1" || res=1
# SVG must be included with wildcard extension to allow conversion
@@ -123,7 +125,7 @@ check_forbidden_additions() { #
-v EXPRESSIONS='::[[:space:]]*[^[:space:]]*\\.svg' \
-v RET_ON_FAIL=1 \
-v MESSAGE='Using explicit .svg extension instead of .*' \
- -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
+ -f $FORBIDDEN_TOKENS_SCRIPT \
"$1" || res=1
# links must prefer https over http
@@ -131,7 +133,7 @@ check_forbidden_additions() { #
-v EXPRESSIONS='http://.*dpdk.org' \
-v RET_ON_FAIL=1 \
-v MESSAGE='Using non https link to dpdk.
[dpdk-dev] why uses the cldemote here in dpdk21.02?
Hi,
when I read the dpdk dlb
eventdev driver code, I find that it used the cldemote instruction in the
dlb_recv_qe(). But I don't understand why it used there?
The cldemote instruction means to
move the cache line to the more remote cache, which helps to accelerate
core-to-core communication. But who will be use the memory of cache_line_base?
>static __rte_always_inline int dlb_recv_qe(struct dlb_port *qm_port, struct
dlb_dequeue_qe *qe, uint8_t *offset)
>{
>
> cq_addr =
dlb_port[qm_port->id][PORT_TYPE(qm_port)].cq_base;
> cq_addr =
&cq_addr[qm_port->cq_idx];
> cache_line_base = (void
*)(((uintptr_t)cq_addr) & ~0x3F);
> *offset = ((uintptr_t)cq_addr
& 0x30) >> 4;
> /* Load the next CQ cache line
from memory. Pack these reads as tight
> * as possible to reduce the
chance that DLB invalidates the line while
> * the CPU is reading it. Read
the cache line backwards to ensure that
> * if QE[N] (N > 0) is valid,
then QEs[0:N-1] are too.
> *
> * (Valid QEs start at
&qe[offset])
> */
> qes[3] = _mm_load_si128((__m128i
*)&cache_line_base[6]);
> qes[2] = _mm_load_si128((__m128i
*)&cache_line_base[4]);
> qes[1] = _mm_load_si128((__m128i
*)&cache_line_base[2]);
> qes[0] = _mm_load_si128((__m128i
*)&cache_line_base[0]);
>
> /* Evict the cache line ASAP */
> rte_cldemote(cache_line_base);
Thanks.
Re: [dpdk-dev] 回复: [dpdk-stable] [PATCH v3] crypto/qat: fix uninitilized compiler warning
On 5/20/2021 6:44 AM, Feifei Wang wrote:
> Hi, Ferruh
>
> Thanks for your comments.
> Please see below.
>
>> -邮件原件-
>> 发件人: Ferruh Yigit
>> 发送时间: 2021年5月19日 16:12
>> 收件人: Feifei Wang ; John Griffin
>> ; Fiona Trahe ; Deepak
>> Kumar Jain ; Jerin Jacob
>> ; Herbert Guan
>>
>> 抄送: dev@dpdk.org; david.march...@redhat.com; nd ;
>> sta...@dpdk.org; Ruifeng Wang
>> 主题: Re: [dpdk-stable] [PATCH v3] crypto/qat: fix uninitilized compiler
>> warning
>>
>> On 5/17/2021 10:07 AM, Feifei Wang wrote:
>>> In Arm platform, when "RTE_ARCH_ARM64_MEMCPY" is set as true,
>> compiler
>>> will report variable uninitilized warning:
>>>
>>> ../drivers/crypto/qat/qat_sym_session.c:
>>> In function ‘partial_hash_compute’:
>>> ../lib/eal/include/generic/rte_byteorder.h:241:24: warning:
>>> ‘’ may be used uninitialized in this function
>>> [-Wmaybe-uninitialized]
>>> 241 | #define rte_bswap32(x) __builtin_bswap32(x)
>>> ...
>>>
>>> This is because "digest" will be initialized by "rte_memcpy" function
>>> rather than "memcpy" if "RTE_ARCH_ARM64_MEMCPY" is set as true.
>>> However,
>>
>> How 'digest' is initialized by 'rte_memcpy'?
>
> Firstly, 'digest' is initialized by rte_memcpy in partial_hash_sha_x function
> :
> 'partial_hash_compute' -> 'partial_hash_sha_x' -> 'rte_memcpy'.
>
> If "RTE_ARCH_ARM64_MEMCPY = false", rte_memcpy will be defined as
> 'memcpy' to initialize 'digest' in lib\eal\arm\include\rte_memcpy_64.h: 364,
> and compiler can identify this.
>
> However, if "RTE_ARCH_ARM64_MEMCPY = true", rte_memcpy will be a inline
> function, and finally it will initialize 'digest' with two steps by invoking
> rte_mov16:
> rte_memcpy -> rte_memcpy_ge16_lt_128 ->
> step 1: rte_mov16(dst,src )
> step 2: rte_mov16(dst - 16 + n, src - 16 + n)
> And the compiler cannot identify this multi-step initialization, then it will
> report warning.
>
OK, I got what you mean, thanks for clarification.
>>
>>> compiler cannot know it is initialized by the function.
>>>
>>> To fix this, use "calloc" to initialize "digest".
>>>
>>> Fixes: cd7fc8a84b48 ("eal/arm64: optimize memcpy")
>>> Cc: sta...@dpdk.org
>>>
>>> Signed-off-by: Feifei Wang
>>> Reviewed-by: Ruifeng Wang
>>> ---
>>> v2: add check and free for memory dynamic allocation (David Marchand)
>>> v3: fix compiler error
>>>
>>> drivers/crypto/qat/qat_sym_session.c | 27 ++-
>>> 1 file changed, 18 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/crypto/qat/qat_sym_session.c
>>> b/drivers/crypto/qat/qat_sym_session.c
>>> index 231b1640da..105a10957a 100644
>>> --- a/drivers/crypto/qat/qat_sym_session.c
>>> +++ b/drivers/crypto/qat/qat_sym_session.c
>>> @@ -1190,8 +1190,7 @@ static int partial_hash_compute(enum
>> icp_qat_hw_auth_algo hash_alg,
>>> uint8_t *data_out)
>>> {
>>> int digest_size;
>>> - uint8_t digest[qat_hash_get_digest_size(
>>> - ICP_QAT_HW_AUTH_ALGO_DELIMITER)];
>>> + uint8_t *digest;
>>
>> Will a memset 'digest' work too? Although not sure which one is better.
> Thanks for your meaningful comments, I try to use memset and it is ok to
> solve this warning.
> I will update this in the next version.
>
Re: [dpdk-dev] [PATCH] lpm/arm: fix SVE compile error with gcc8.3
Thanks for this patch.
Minor comment below.
> -Original Message-
> From: Chengwen Feng
> Sent: Thursday, May 20, 2021 3:17 PM
> To: tho...@monjalon.net; ferruh.yi...@intel.com
> Cc: dev@dpdk.org; bruce.richard...@intel.com;
> vladimir.medved...@intel.com; vikto...@rehivetech.com; Ruifeng Wang
> ; jer...@marvell.com
> Subject: [PATCH] lpm/arm: fix SVE compile error with gcc8.3
This is build fix and not specific to lpm.
Use 'build:' instead of 'lpm/arm:'?
>
> If the target machine has SVE feature (e.g. "-march=armv8.2-a+sve'), and the
> compiler is gcc8.3, it will compile error:
> In file included from ../dpdk-next-net/lib/eal/common/
> eal_common_options.c:38:
> ../dpdk-next-net/lib/eal/arm/include/rte_vect.h:13:10: fatal
> error: arm_sve.h: No such file or directory
> #include
> ^~~
> compilation terminated.
>
> The root cause is that gcc8.3 support SVE (the macro __ARM_FEATURE_SVE
> was 1), but it doesn't support SVE ACLE [1].
>
> The solution:
> a) Detect compiler whether support SVE ACLE, if support then define
> CC_SVE_ACLE_SUPPORT macro.
> b) Use the CC_SVE_ACLE_SUPPORT macro to include SVE header file.
>
> [1] ACLE: Arm C Language Extensions, the SVE ACLE header file is
> , user should include it when writing ACLE SVE code.
>
> Fixes: 67b68824a82d ("lpm/arm: support SVE")
>
> Signed-off-by: Chengwen Feng
> ---
> config/arm/meson.build | 5 +
> lib/eal/arm/include/rte_vect.h | 2 +-
> lib/lpm/rte_lpm.h | 2 +-
> 3 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/config/arm/meson.build b/config/arm/meson.build index
> e83a56e..bff70e4 100644
> --- a/config/arm/meson.build
> +++ b/config/arm/meson.build
> @@ -480,6 +480,11 @@ if (cc.get_define('__ARM_NEON', args:
> machine_args) != '' or
> compile_time_cpuflags += ['RTE_CPUFLAG_NEON'] endif
>
> +if (cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != '' and
> +cc.check_header('arm_sve.h'))
> +dpdk_conf.set('CC_SVE_ACLE_SUPPORT', 1) endif
> +
> if cc.get_define('__ARM_FEATURE_CRC32', args: machine_args) != ''
> compile_time_cpuflags += ['RTE_CPUFLAG_CRC32'] endif diff --git
> a/lib/eal/arm/include/rte_vect.h b/lib/eal/arm/include/rte_vect.h index
> 093e912..277b656 100644
> --- a/lib/eal/arm/include/rte_vect.h
> +++ b/lib/eal/arm/include/rte_vect.h
> @@ -9,7 +9,7 @@
> #include "generic/rte_vect.h"
> #include "rte_debug.h"
> #include "arm_neon.h"
> -#ifdef __ARM_FEATURE_SVE
> +#ifdef CC_SVE_ACLE_SUPPORT
> #include
> #endif
>
> diff --git a/lib/lpm/rte_lpm.h b/lib/lpm/rte_lpm.h index 28b5768..9262814
> 100644
> --- a/lib/lpm/rte_lpm.h
> +++ b/lib/lpm/rte_lpm.h
> @@ -402,7 +402,7 @@ rte_lpm_lookupx4(const struct rte_lpm *lpm, xmm_t
> ip, uint32_t hop[4],
> uint32_t defv);
>
> #if defined(RTE_ARCH_ARM)
> -#ifdef __ARM_FEATURE_SVE
> +#ifdef CC_SVE_ACLE_SUPPORT
> #include "rte_lpm_sve.h"
> #else
> #include "rte_lpm_neon.h"
> --
> 2.8.1
Re: [dpdk-dev] [PATCH v6 2/2] net/hns3: refactor SVE code compile method
> -Original Message-
> From: Chengwen Feng
> Sent: Wednesday, May 19, 2021 9:26 PM
> To: tho...@monjalon.net; ferruh.yi...@intel.com
> Cc: dev@dpdk.org; jer...@marvell.com; Ruifeng Wang
> ; vikto...@rehivetech.com;
> bruce.richard...@intel.com; Honnappa Nagarahalli
> ; jerinjac...@gmail.com;
> juraj.lin...@pantheon.tech; nd
> Subject: [PATCH v6 2/2] net/hns3: refactor SVE code compile method
>
> Currently, the SVE code is compiled only when -march supports SVE (e.g. '-
> march=armv8.2a+sve'), there maybe some problem[1] with this approach.
>
> The solution:
> a. If the minimum instruction set support SVE then compiles it.
> b. Else if the compiler support SVE then compiles it.
> c. Otherwise don't compile it.
>
> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
>
> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Chengwen Feng
> ---
> drivers/net/hns3/hns3_rxtx.c | 2 +-
> drivers/net/hns3/meson.build | 21 -
> 2 files changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
> index 1d7a769..4ef20c6 100644
> --- a/drivers/net/hns3/hns3_rxtx.c
> +++ b/drivers/net/hns3/hns3_rxtx.c
> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
> static bool
> hns3_get_sve_support(void)
> {
> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
> +#if defined(CC_SVE_SUPPORT)
> if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
> return false;
> if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
> diff --git a/drivers/net/hns3/meson.build b/drivers/net/hns3/meson.build
> index 53c7df7..5f9af9b 100644
> --- a/drivers/net/hns3/meson.build
> +++ b/drivers/net/hns3/meson.build
> @@ -35,7 +35,26 @@ deps += ['hash']
>
> if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
> sources += files('hns3_rxtx_vec.c')
> -if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
> +
> +# compile SVE when:
> +# a. support SVE in minimum instruction set baseline
> +# b. it's not minimum instruction set, but compiler support
> +if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != '' and
> cc.check_header('arm_sve.h')
> +cflags += ['-DCC_SVE_SUPPORT']
With SVE build fix patch [1], CC_SVE_ACLE_SUPPORT will be defined.
Here we can use CC_SVE_ACLE_SUPPORT and not to add a new one.
[1]
http://patches.dpdk.org/project/dpdk/patch/1621495007-28387-1-git-send-email-fengcheng...@huawei.com/
> sources += files('hns3_rxtx_vec_sve.c')
> +elif cc.has_argument('-march=armv8.2-a+sve') and
> cc.check_header('arm_sve.h')
> +sve_cflags = ['-DCC_SVE_SUPPORT']
> +foreach flag: cflags
> +# filterout -march -mcpu -mtune
> +if not (flag.startswith('-march=') or flag.startswith('-mcpu=')
> or
> flag.startswith('-mtune='))
> +sve_cflags += flag
> +endif
> +endforeach
> +hns3_sve_lib = static_library('hns3_sve_lib',
> +'hns3_rxtx_vec_sve.c',
> +dependencies: [static_rte_ethdev],
> +include_directories: includes,
> +c_args: [sve_cflags, '-march=armv8.2-a+sve'])
> +objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
> endif
> endif
> --
> 2.8.1
[dpdk-dev] [PATCH v4] crypto/qat: fix uninitilized gcc compiler warning
In Arm platform, when "RTE_ARCH_ARM64_MEMCPY" is set as true, gcc will
report variable uninitilized warning:
../drivers/crypto/qat/qat_sym_session.c: In function ‘partial_hash_compute’:
../lib/eal/include/generic/rte_byteorder.h:241:24: warning:
‘’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
241 | #define rte_bswap32(x) __builtin_bswap32(x)
...
This is because "digest" will be initialized by "rte_memcpy" function
rather than "memcpy" if "RTE_ARCH_ARM64_MEMCPY" is set as true.
Furthermore, 'rte_memcpy' will initialize 'digest' with two steps
by invoking rte_mov_x functions. For example:
partial_hash_sha1 -> rte_memcpy -> rte_memcpy_ge16_lt_128 ->
step 1: rte_mov16(dst,src )
step 2: rte_mov16(dst - 16 + n, src - 16 + n)
However, gcc compiler cannot identify this multi-step initialization,
then it will report warning.
To fix this, use "memset" to initialize "digest".
Fixes: cd7fc8a84b48 ("eal/arm64: optimize memcpy")
Cc: sta...@dpdk.org
Signed-off-by: Feifei Wang
Reviewed-by: Ruifeng Wang
---
v2: add check and free for memory dynamic allocation (David Marchand)
v3: fix compiler error
v4: use 'memset' to initialize digest (Ferruh, Adam)
drivers/crypto/qat/qat_sym_session.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/crypto/qat/qat_sym_session.c
b/drivers/crypto/qat/qat_sym_session.c
index 231b1640da..e22dd3600c 100644
--- a/drivers/crypto/qat/qat_sym_session.c
+++ b/drivers/crypto/qat/qat_sym_session.c
@@ -1196,6 +1196,9 @@ static int partial_hash_compute(enum icp_qat_hw_auth_algo
hash_alg,
uint64_t *hash_state_out_be64;
int i;
+ /* Initialize to avoid gcc warning */
+ memset(digest, 0, sizeof(digest));
+
digest_size = qat_hash_get_digest_size(hash_alg);
if (digest_size <= 0)
return -EFAULT;
--
2.25.1
Re: [dpdk-dev] [PATCH v4] crypto/qat: fix uninitilized gcc compiler warning
> -Original Message-
> From: Feifei Wang
> Sent: Thursday, 20 May, 2021 10:44
> To: Griffin, John ; Trahe, Fiona
> ; Jain, Deepak K ;
> Herbert Guan ; Jerin Jacob
>
> Cc: dev@dpdk.org; Yigit, Ferruh ; Dybkowski,
> AdamX ; n...@arm.com; Feifei Wang
> ; sta...@dpdk.org; Ruifeng Wang
>
> Subject: [PATCH v4] crypto/qat: fix uninitilized gcc compiler warning
>
> In Arm platform, when "RTE_ARCH_ARM64_MEMCPY" is set as true, gcc
> will report variable uninitilized warning:
>
> ../drivers/crypto/qat/qat_sym_session.c: In function
> ‘partial_hash_compute’:
> ../lib/eal/include/generic/rte_byteorder.h:241:24: warning:
> ‘’ may be used uninitialized in this function
> [-Wmaybe-uninitialized]
> 241 | #define rte_bswap32(x) __builtin_bswap32(x)
> ...
>
> This is because "digest" will be initialized by "rte_memcpy" function rather
> than "memcpy" if "RTE_ARCH_ARM64_MEMCPY" is set as true.
> Furthermore, 'rte_memcpy' will initialize 'digest' with two steps by invoking
> rte_mov_x functions. For example:
>
> partial_hash_sha1 -> rte_memcpy -> rte_memcpy_ge16_lt_128 -> step 1:
> rte_mov16(dst,src ) step 2: rte_mov16(dst - 16 + n, src - 16 + n)
>
> However, gcc compiler cannot identify this multi-step initialization, then it
> will report warning.
>
> To fix this, use "memset" to initialize "digest".
>
> Fixes: cd7fc8a84b48 ("eal/arm64: optimize memcpy")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Feifei Wang
> Reviewed-by: Ruifeng Wang
> ---
Acked-by: Adam Dybkowski
Re: [dpdk-dev] [EXT] [PATCH] doc: support IPsec Multi-buffer lib v1.0
Hi Akhil, > -Original Message- > From: Akhil Goyal > Sent: Monday, May 17, 2021 8:44 PM > To: De Lara Guarch, Pablo > Cc: dev@dpdk.org > Subject: RE: [EXT] [PATCH] doc: support IPsec Multi-buffer lib v1.0 > > > > Updated AESNI MB and AESNI GCM, KASUMI, ZUC and SNOW3G PMD > > documentation guides with information about the latest Intel IPSec > > Multi-buffer library supported. > > > > Signed-off-by: Pablo de Lara > > --- > > Does it need to be updated in release notes as well? > Doesn't it need any patch in the code? I did not see any changes. No code changes are needed, since the API has not changed. I haven't added any release notes, as there was not anything changed code wise. Thanks, Pablo > > -Akhil
Re: [dpdk-dev] [EXT] [PATCH] doc: support IPsec Multi-buffer lib v1.0
> Hi Akhil, > > > > Updated AESNI MB and AESNI GCM, KASUMI, ZUC and SNOW3G PMD > > > documentation guides with information about the latest Intel IPSec > > > Multi-buffer library supported. > > > > > > Signed-off-by: Pablo de Lara > > > --- > > > > Does it need to be updated in release notes as well? > > Doesn't it need any patch in the code? I did not see any changes. > > No code changes are needed, since the API has not changed. > I haven't added any release notes, as there was not anything changed code > wise. > OK, Thomas, Can you pick this patch directly on main. Regards, Akhil
[dpdk-dev] maintainers: update for qat and ipsec-mb pmds
Add myself to Crypto API, QAT, SW PMDs based on ipsec-mb, and NULL PMD maintainer. Signed-off-by: Fan Zhang --- MAINTAINERS | 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 5877a16971..11653b3dcd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -421,7 +421,7 @@ F: examples/bbdev_app/ F: doc/guides/sample_app_ug/bbdev_app.rst Crypto API -M: Declan Doherty +M: Fan Zhang T: git://dpdk.org/next/dpdk-next-crypto F: lib/cryptodev/ F: app/test/test_cryptodev* @@ -429,7 +429,7 @@ F: examples/l2fwd-crypto/ Security API M: Akhil Goyal -M: Declan Doherty +M: Fan Zhang T: git://dpdk.org/next/dpdk-next-crypto F: lib/security/ F: doc/guides/prog_guide/rte_security.rst @@ -1031,23 +1031,22 @@ F: drivers/crypto/scheduler/ F: doc/guides/cryptodevs/scheduler.rst Intel AES-NI GCM -M: Declan Doherty M: Pablo de Lara +M: Fan Zhang F: drivers/crypto/aesni_gcm/ F: doc/guides/cryptodevs/aesni_gcm.rst F: doc/guides/cryptodevs/features/aesni_gcm.ini Intel AES-NI Multi-Buffer -M: Declan Doherty M: Pablo de Lara +M: Fan Zhang F: drivers/crypto/aesni_mb/ F: doc/guides/cryptodevs/aesni_mb.rst F: doc/guides/cryptodevs/features/aesni_mb.ini Intel QuickAssist -M: John Griffin M: Fiona Trahe -M: Deepak Kumar Jain +M: Fan Zhang F: drivers/crypto/qat/ F: drivers/common/qat/ F: doc/guides/cryptodevs/qat.rst @@ -1055,6 +1054,7 @@ F: doc/guides/cryptodevs/features/qat.ini KASUMI M: Pablo de Lara +M: Fan Zhang F: drivers/crypto/kasumi/ F: doc/guides/cryptodevs/kasumi.rst F: doc/guides/cryptodevs/features/kasumi.ini @@ -1081,7 +1081,7 @@ F: doc/guides/cryptodevs/octeontx2.rst F: doc/guides/cryptodevs/features/octeontx2.ini Null Crypto -M: Declan Doherty +M: Fan Zhang F: drivers/crypto/null/ F: doc/guides/cryptodevs/null.rst F: doc/guides/cryptodevs/features/null.ini @@ -1108,13 +1108,14 @@ F: doc/guides/cryptodevs/dpaa2_sec.rst F: doc/guides/cryptodevs/features/dpaa2_sec.ini OpenSSL -M: Declan Doherty +M: Fan Zhang F: drivers/crypto/openssl/ F: doc/guides/cryptodevs/openssl.rst F: doc/guides/cryptodevs/features/openssl.ini SNOW 3G M: Pablo de Lara +M: Fan Zhang F: drivers/crypto/snow3g/ F: doc/guides/cryptodevs/snow3g.rst F: doc/guides/cryptodevs/features/snow3g.ini @@ -1127,6 +1128,7 @@ F: doc/guides/cryptodevs/features/virtio.ini ZUC M: Pablo de Lara +M: Fan Zhang F: drivers/crypto/zuc/ F: doc/guides/cryptodevs/zuc.rst F: doc/guides/cryptodevs/features/zuc.ini -- 2.25.1
Re: [dpdk-dev] [PATCH] devtools: warn about release notes updates
20/05/2021 09:58, David Marchand:
> Touching release notes should only be for the current version.
>
> Signed-off-by: David Marchand
> ---
> -VALIDATE_NEW_API=$(dirname $(readlink -f $0))/check-symbol-change.sh
> +ROOTDIR=$(readlink -f $(dirname $(readlink -f $0))/..)
> +VALIDATE_NEW_API=$ROOTDIR/devtools/check-symbol-change.sh
> +FORBIDDEN_TOKENS_SCRIPT=$ROOTDIR/devtools/check-forbidden-tokens.awk
This change is an unrelated cleanup.
Do we keep it in this patch? I'm fine with it, just asking for clarification.
> # Enable codespell by default. This can be overwritten from a config file.
> # Codespell can also be enabled by setting DPDK_CHECKPATCH_CODESPELL to a
> valid path
> @@ -58,7 +60,7 @@ check_forbidden_additions() { #
> -v EXPRESSIONS="rte_panic\\\( rte_exit\\\(" \
> -v RET_ON_FAIL=1 \
> -v MESSAGE='Using rte_panic/rte_exit' \
> - -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
> + -f $FORBIDDEN_TOKENS_SCRIPT \
[...]
> +check_release_notes() { #
> + rel_notes_prefix=doc/guides/rel_notes/release_
> + current_version=$(cat $ROOTDIR/VERSION)
> + major_version=${current_version%%.*}
> + current_version=${current_version##${major_version}.}
> + minor_version=${current_version%%.*}
A simpler version:
cat VERSION | IFS=. read major minor release
> + current_rn=${rel_notes_prefix}${major_version}_${minor_version}.rst
> +
> + ! grep -e '^--- a/'$rel_notes_prefix -e '^+++ b/'$rel_notes_prefix $1 |
Only the +++ part should matters.
> + grep -v $current_rn
> +}
[...]
> + ! $verbose || printf '\nChecking release notes updates:\n'
> + report=$(check_release_notes "$tmpinput")
> + if [ $? -ne 0 ] ; then
> + $headline_printed || print_headline "$3"
> + printf '%s\n' "$report"
> + ret=1
> + fi
Thanks for adding a new check. More is better :)
Re: [dpdk-dev] maintainers: update for qat and ipsec-mb pmds
> -Original Message- > From: Zhang, Roy Fan > Sent: Thursday, May 20, 2021 10:47 AM > To: dev@dpdk.org > Cc: tho...@monjalon.net; gak...@marvell.com; Yigit, Ferruh > ; Doherty, Declan ; > Griffin, John ; Jain, Deepak K > ; Trahe, Fiona ; Zhang, > Roy Fan > Subject: [dpdk-dev] maintainers: update for qat and ipsec-mb pmds > > Add myself to Crypto API, QAT, SW PMDs based on ipsec-mb, and NULL PMD > maintainer. > > Signed-off-by: Fan Zhang > --- > MAINTAINERS | 18 ++ > 1 file changed, 10 insertions(+), 8 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 5877a16971..11653b3dcd 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -421,7 +421,7 @@ F: examples/bbdev_app/ > F: doc/guides/sample_app_ug/bbdev_app.rst > > Crypto API > -M: Declan Doherty > +M: Fan Zhang > T: git://dpdk.org/next/dpdk-next-crypto > F: lib/cryptodev/ > F: app/test/test_cryptodev* > @@ -429,7 +429,7 @@ F: examples/l2fwd-crypto/ > > Security API > M: Akhil Goyal > -M: Declan Doherty > +M: Fan Zhang > T: git://dpdk.org/next/dpdk-next-crypto > F: lib/security/ > F: doc/guides/prog_guide/rte_security.rst > @@ -1031,23 +1031,22 @@ F: drivers/crypto/scheduler/ > F: doc/guides/cryptodevs/scheduler.rst > > Intel AES-NI GCM > -M: Declan Doherty > M: Pablo de Lara > +M: Fan Zhang > F: drivers/crypto/aesni_gcm/ > F: doc/guides/cryptodevs/aesni_gcm.rst > F: doc/guides/cryptodevs/features/aesni_gcm.ini > > Intel AES-NI Multi-Buffer > -M: Declan Doherty > M: Pablo de Lara > +M: Fan Zhang > F: drivers/crypto/aesni_mb/ > F: doc/guides/cryptodevs/aesni_mb.rst > F: doc/guides/cryptodevs/features/aesni_mb.ini > > Intel QuickAssist > -M: John Griffin > M: Fiona Trahe > -M: Deepak Kumar Jain > +M: Fan Zhang > F: drivers/crypto/qat/ > F: drivers/common/qat/ > F: doc/guides/cryptodevs/qat.rst > @@ -1055,6 +1054,7 @@ F: doc/guides/cryptodevs/features/qat.ini > > KASUMI > M: Pablo de Lara > +M: Fan Zhang > F: drivers/crypto/kasumi/ > F: doc/guides/cryptodevs/kasumi.rst > F: doc/guides/cryptodevs/features/kasumi.ini > @@ -1081,7 +1081,7 @@ F: doc/guides/cryptodevs/octeontx2.rst > F: doc/guides/cryptodevs/features/octeontx2.ini > > Null Crypto > -M: Declan Doherty > +M: Fan Zhang > F: drivers/crypto/null/ > F: doc/guides/cryptodevs/null.rst > F: doc/guides/cryptodevs/features/null.ini > @@ -1108,13 +1108,14 @@ F: doc/guides/cryptodevs/dpaa2_sec.rst > F: doc/guides/cryptodevs/features/dpaa2_sec.ini > > OpenSSL > -M: Declan Doherty > +M: Fan Zhang > F: drivers/crypto/openssl/ > F: doc/guides/cryptodevs/openssl.rst > F: doc/guides/cryptodevs/features/openssl.ini > > SNOW 3G > M: Pablo de Lara > +M: Fan Zhang > F: drivers/crypto/snow3g/ > F: doc/guides/cryptodevs/snow3g.rst > F: doc/guides/cryptodevs/features/snow3g.ini > @@ -1127,6 +1128,7 @@ F: doc/guides/cryptodevs/features/virtio.ini > > ZUC > M: Pablo de Lara > +M: Fan Zhang > F: drivers/crypto/zuc/ > F: doc/guides/cryptodevs/zuc.rst > F: doc/guides/cryptodevs/features/zuc.ini > -- > 2.25.1 Acked-by: John Griffin
Re: [dpdk-dev] [PATCH] devtools: warn about release notes updates
On Thu, May 20, 2021 at 11:47 AM Thomas Monjalon wrote:
>
> 20/05/2021 09:58, David Marchand:
> > Touching release notes should only be for the current version.
> >
> > Signed-off-by: David Marchand
> > ---
> > -VALIDATE_NEW_API=$(dirname $(readlink -f $0))/check-symbol-change.sh
> > +ROOTDIR=$(readlink -f $(dirname $(readlink -f $0))/..)
> > +VALIDATE_NEW_API=$ROOTDIR/devtools/check-symbol-change.sh
> > +FORBIDDEN_TOKENS_SCRIPT=$ROOTDIR/devtools/check-forbidden-tokens.awk
>
> This change is an unrelated cleanup.
> Do we keep it in this patch? I'm fine with it, just asking for clarification.
I thought I had dropped it before sending.
Yes this is unrelated, will drop in v2.
>
> > # Enable codespell by default. This can be overwritten from a config file.
> > # Codespell can also be enabled by setting DPDK_CHECKPATCH_CODESPELL to a
> > valid path
> > @@ -58,7 +60,7 @@ check_forbidden_additions() { #
> > -v EXPRESSIONS="rte_panic\\\( rte_exit\\\(" \
> > -v RET_ON_FAIL=1 \
> > -v MESSAGE='Using rte_panic/rte_exit' \
> > - -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
> > + -f $FORBIDDEN_TOKENS_SCRIPT \
> [...]
> > +check_release_notes() { #
> > + rel_notes_prefix=doc/guides/rel_notes/release_
> > + current_version=$(cat $ROOTDIR/VERSION)
> > + major_version=${current_version%%.*}
> > + current_version=${current_version##${major_version}.}
> > + minor_version=${current_version%%.*}
>
> A simpler version:
> cat VERSION | IFS=. read major minor release
Ok with this form.
>
> > + current_rn=${rel_notes_prefix}${major_version}_${minor_version}.rst
> > +
> > + ! grep -e '^--- a/'$rel_notes_prefix -e '^+++ b/'$rel_notes_prefix $1
> > |
>
> Only the +++ part should matters.
It won't catch accidental removals.
Besides, something that is not handled with my patch is renames.
But if we think those cases would be caught by reviewers, I can
simplify this part in v2.
--
David Marchand
[dpdk-dev] [Bug 714] test_prefetch build warnings with gcc 11 and buildtype=debug
https://bugs.dpdk.org/show_bug.cgi?id=714 Bug ID: 714 Summary: test_prefetch build warnings with gcc 11 and buildtype=debug Product: DPDK Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: other Assignee: dev@dpdk.org Reporter: alia...@nvidia.com Target Milestone: --- """ $ meson --werror --buildtype=debug /tmp/build && ninja-build -C /tmp/build ... ... [2566/2660] Compiling C object app/test/dpdk-test.p/test_prefetch.c.o FAILED: app/test/dpdk-test.p/test_prefetch.c.o ccache cc -Iapp/test/dpdk-test.p -Iapp/test -I../dpdk/app/test -Ilib/acl -I../dpdk/lib/acl -I. -I../dpdk -Iconfig -I../dpdk/config -Ilib/eal/include -I../dpdk/lib/eal/include -Ilib/eal/linux/include -I../dpdk/lib/eal/linux/include -Ilib/eal/x86/include -I../dpdk/lib/eal/x86/include -Ilib/eal/common -I../dpdk/lib/eal/common -Ilib/eal -I../dpdk/lib/eal -Ilib/kvargs -I../dpdk/lib/kvargs -Ilib/metrics -I../dpdk/lib/metrics -Ilib/telemetry -I../dpdk/lib/telemetry -Idrivers/bus/pci -I../dpdk/drivers/bus/pci -I../dpdk/drivers/bus/pci/linux -Ilib/pci -I../dpdk/lib/pci -Idrivers/bus/vdev -I../dpdk/drivers/bus/vdev -Ilib/bitratestats -I../dpdk/lib/bitratestats -Ilib/ethdev -I../dpdk/lib/ethdev -Ilib/net -I../dpdk/lib/net -Ilib/mbuf -I../dpdk/lib/mbuf -Ilib/mempool -I../dpdk/lib/mempool -Ilib/ring -I../dpdk/lib/ring -Ilib/meter -I../dpdk/lib/meter -Ilib/bpf -I../dpdk/lib/bpf -Ilib/cfgfile -I../dpdk/lib/cfgfile -Ilib/cmdline -I../dpdk/lib/cmdline -Ilib/cryptodev -I../dpdk/lib/cryptodev -Ilib/rcu -I../dpdk/lib/rcu -Ilib/distributor -I../dpdk/lib/distributor -Ilib/efd -I../dpdk/lib/efd -Ilib/hash -I../dpdk/lib/hash -Ilib/eventdev -I../dpdk/lib/eventdev -Ilib/timer -I../dpdk/lib/timer -Ilib/fib -I../dpdk/lib/fib -Ilib/rib -I../dpdk/lib/rib -Ilib/flow_classify -I../dpdk/lib/flow_classify -Ilib/table -I../dpdk/lib/table -Ilib/port -I../dpdk/lib/port -Ilib/sched -I../dpdk/lib/sched -Ilib/ip_frag -I../dpdk/lib/ip_frag -Ilib/kni -I../dpdk/lib/kni -Ilib/lpm -I../dpdk/lib/lpm -Ilib/graph -I../dpdk/lib/graph -Ilib/ipsec -I../dpdk/lib/ipsec -Ilib/security -I../dpdk/lib/security -Ilib/latencystats -I../dpdk/lib/latencystats -Ilib/member -I../dpdk/lib/member -Ilib/node -I../dpdk/lib/node -Ilib/pipeline -I../dpdk/lib/pipeline -Ilib/rawdev -I../dpdk/lib/rawdev -Ilib/reorder -I../dpdk/lib/reorder -Ilib/stack -I../dpdk/lib/stack -Idrivers/mempool/ring -I../dpdk/drivers/mempool/ring -Idrivers/mempool/stack -I../dpdk/drivers/mempool/stack -Idrivers/event/skeleton -I../dpdk/drivers/event/skeleton -Idrivers/net/bonding -I../dpdk/drivers/net/bonding -Idrivers/net/ring -I../dpdk/drivers/net/ring -Ilib/power -I../dpdk/lib/power -Ilib/pdump -I../dpdk/lib/pdump -Idrivers/crypto/scheduler -I../dpdk/drivers/crypto/scheduler -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Werror -g -include rte_config.h -Wextra -Wcast-qual -Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wundef -Wwrite-strings -Wno-address-of-packed-member -Wno-packed-not-aligned -Wno-missing-field-initializers -Wno-zero-length-bounds -D_GNU_SOURCE -march=native -DALLOW_EXPERIMENTAL_API -Wno-format-truncation -fno-strict-aliasing -DALLOW_INTERNAL_API -MD -MQ app/test/dpdk-test.p/test_prefetch.c.o -MF app/test/dpdk-test.p/test_prefetch.c.o.d -o app/test/dpdk-test.p/test_prefetch.c.o -c ../dpdk/app/test/test_prefetch.c ../dpdk/app/test/test_prefetch.c: In function 'test_prefetch': ../dpdk/app/test/test_prefetch.c:25:9: error: 'a' may be used uninitialized [-Werror=maybe-uninitialized] 25 | rte_prefetch0(&a); | ^ In file included from ../dpdk/app/test/test_prefetch.c:8: ../dpdk/lib/eal/x86/include/rte_prefetch.h:15:20: note: by argument 1 of type 'const volatile void *' to 'rte_prefetch0' declared here 15 | static inline void rte_prefetch0(const volatile void *p) |^ ../dpdk/app/test/test_prefetch.c:23:13: note: 'a' declared here 23 | int a; | ^ cc1: all warnings being treated as errors [2599/2660] Compiling C object drivers/libtmp_rte_event_octeontx2.a.p/event_octeontx2_otx2_worker.c.o ninja: build stopped: subcommand failed. """ Reproduces on 21.05.0-rc4. os: Fedora 35 (Rawhide) gcc: 11.1.1 meson: 0.58.0 ninja-build: 1.10.2 -- You are receiving this mail because: You are the assignee for the bug.
Re: [dpdk-dev] [PATCH] devtools: warn about release notes updates
20/05/2021 11:59, David Marchand:
> On Thu, May 20, 2021 at 11:47 AM Thomas Monjalon wrote:
> > 20/05/2021 09:58, David Marchand:
> > > + current_rn=${rel_notes_prefix}${major_version}_${minor_version}.rst
> > > +
> > > + ! grep -e '^--- a/'$rel_notes_prefix -e '^+++ b/'$rel_notes_prefix
> > > $1 |
> >
> > Only the +++ part should matters.
>
> It won't catch accidental removals.
Ah yes
> Besides, something that is not handled with my patch is renames.
I think we don't care about renames.
> But if we think those cases would be caught by reviewers, I can
> simplify this part in v2.
Catching any change (including removal) in old release notes look fine.
[dpdk-dev] [PATCH v2] devtools: warn about release notes updates
Touching release notes should only be for the current version.
Signed-off-by: David Marchand
---
Changes since v1:
- dropped unrelevant change,
- simplified VERSION extract and updated variable names,
---
devtools/checkpatches.sh | 17 +
1 file changed, 17 insertions(+)
diff --git a/devtools/checkpatches.sh b/devtools/checkpatches.sh
index db4c7d8301..aff7d2a161 100755
--- a/devtools/checkpatches.sh
+++ b/devtools/checkpatches.sh
@@ -198,6 +198,15 @@ check_internal_tags() { #
return $res
}
+check_release_notes() { #
+ rel_notes_prefix=doc/guides/rel_notes/release_
+ IFS=. read year month release < VERSION
+ current_rel_notes=${rel_notes_prefix}${year}_${month}.rst
+
+ ! grep -e '^--- a/'$rel_notes_prefix -e '^+++ b/'$rel_notes_prefix $1 |
+ grep -v $current_rel_notes
+}
+
number=0
range='origin/main..'
quiet=false
@@ -289,6 +298,14 @@ check () { #
ret=1
fi
+ ! $verbose || printf '\nChecking release notes updates:\n'
+ report=$(check_release_notes "$tmpinput")
+ if [ $? -ne 0 ] ; then
+ $headline_printed || print_headline "$3"
+ printf '%s\n' "$report"
+ ret=1
+ fi
+
if [ "$tmpinput" != "$1" ]; then
rm -f "$tmpinput"
trap - INT
--
2.23.0
Re: [dpdk-dev] [PATCH v6 2/2] net/hns3: refactor SVE code compile method
On 2021/5/20 16:24, Ruifeng Wang wrote:
>> -Original Message-
>> From: Chengwen Feng
>> Sent: Wednesday, May 19, 2021 9:26 PM
>> To: tho...@monjalon.net; ferruh.yi...@intel.com
>> Cc: dev@dpdk.org; jer...@marvell.com; Ruifeng Wang
>> ; vikto...@rehivetech.com;
>> bruce.richard...@intel.com; Honnappa Nagarahalli
>> ; jerinjac...@gmail.com;
>> juraj.lin...@pantheon.tech; nd
>> Subject: [PATCH v6 2/2] net/hns3: refactor SVE code compile method
>>
>> Currently, the SVE code is compiled only when -march supports SVE (e.g. '-
>> march=armv8.2a+sve'), there maybe some problem[1] with this approach.
>>
>> The solution:
>> a. If the minimum instruction set support SVE then compiles it.
>> b. Else if the compiler support SVE then compiles it.
>> c. Otherwise don't compile it.
>>
>> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
>>
>> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
>> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
>> Cc: sta...@dpdk.org
>>
>> Signed-off-by: Chengwen Feng
>> ---
>> drivers/net/hns3/hns3_rxtx.c | 2 +-
>> drivers/net/hns3/meson.build | 21 -
>> 2 files changed, 21 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c
>> index 1d7a769..4ef20c6 100644
>> --- a/drivers/net/hns3/hns3_rxtx.c
>> +++ b/drivers/net/hns3/hns3_rxtx.c
>> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
>> static bool
>> hns3_get_sve_support(void)
>> {
>> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
>> +#if defined(CC_SVE_SUPPORT)
>> if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
>> return false;
>> if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
>> diff --git a/drivers/net/hns3/meson.build b/drivers/net/hns3/meson.build
>> index 53c7df7..5f9af9b 100644
>> --- a/drivers/net/hns3/meson.build
>> +++ b/drivers/net/hns3/meson.build
>> @@ -35,7 +35,26 @@ deps += ['hash']
>>
>> if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
>> sources += files('hns3_rxtx_vec.c')
>> -if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
>> +
>> +# compile SVE when:
>> +# a. support SVE in minimum instruction set baseline
>> +# b. it's not minimum instruction set, but compiler support
>> +if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != '' and
>> cc.check_header('arm_sve.h')
>> +cflags += ['-DCC_SVE_SUPPORT']
> With SVE build fix patch [1], CC_SVE_ACLE_SUPPORT will be defined.
> Here we can use CC_SVE_ACLE_SUPPORT and not to add a new one.
>
The CC_SVE_ACLE_SUPPORT was defined under default machine_args which support
SVE,
it can't deals with the situation: the default machine_args don't support SVE
but compiler support SVE.
So the CC_SVE_SUPPORT marco is necessary.
> [1]
> http://patches.dpdk.org/project/dpdk/patch/1621495007-28387-1-git-send-email-fengcheng...@huawei.com/
>
>> sources += files('hns3_rxtx_vec_sve.c')
>> +elif cc.has_argument('-march=armv8.2-a+sve') and
>> cc.check_header('arm_sve.h')
>> +sve_cflags = ['-DCC_SVE_SUPPORT']
>> +foreach flag: cflags
>> +# filterout -march -mcpu -mtune
>> +if not (flag.startswith('-march=') or flag.startswith('-mcpu=')
>> or
>> flag.startswith('-mtune='))
>> +sve_cflags += flag
>> +endif
>> +endforeach
>> +hns3_sve_lib = static_library('hns3_sve_lib',
>> +'hns3_rxtx_vec_sve.c',
>> +dependencies: [static_rte_ethdev],
>> +include_directories: includes,
>> +c_args: [sve_cflags, '-march=armv8.2-a+sve'])
>> +objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
>> endif
>> endif
>> --
>> 2.8.1
>
>
> .
>
Re: [dpdk-dev] maintainers: update for qat and ipsec-mb pmds
On 20/05/2021 10:47 AM, Fan Zhang wrote: Add myself to Crypto API, QAT, SW PMDs based on ipsec-mb, and NULL PMD maintainer. Signed-off-by: Fan Zhang --- MAINTAINERS | 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 5877a16971..11653b3dcd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -421,7 +421,7 @@ F: examples/bbdev_app/ F: doc/guides/sample_app_ug/bbdev_app.rst Crypto API -M: Declan Doherty +M: Fan Zhang T: git://dpdk.org/next/dpdk-next-crypto F: lib/cryptodev/ F: app/test/test_cryptodev* @@ -429,7 +429,7 @@ F: examples/l2fwd-crypto/ Security API M: Akhil Goyal -M: Declan Doherty +M: Fan Zhang T: git://dpdk.org/next/dpdk-next-crypto F: lib/security/ F: doc/guides/prog_guide/rte_security.rst @@ -1031,23 +1031,22 @@ F: drivers/crypto/scheduler/ F: doc/guides/cryptodevs/scheduler.rst Intel AES-NI GCM -M: Declan Doherty M: Pablo de Lara +M: Fan Zhang F: drivers/crypto/aesni_gcm/ F: doc/guides/cryptodevs/aesni_gcm.rst F: doc/guides/cryptodevs/features/aesni_gcm.ini Intel AES-NI Multi-Buffer -M: Declan Doherty M: Pablo de Lara +M: Fan Zhang F: drivers/crypto/aesni_mb/ F: doc/guides/cryptodevs/aesni_mb.rst F: doc/guides/cryptodevs/features/aesni_mb.ini Intel QuickAssist -M: John Griffin M: Fiona Trahe -M: Deepak Kumar Jain +M: Fan Zhang F: drivers/crypto/qat/ F: drivers/common/qat/ F: doc/guides/cryptodevs/qat.rst @@ -1055,6 +1054,7 @@ F: doc/guides/cryptodevs/features/qat.ini KASUMI M: Pablo de Lara +M: Fan Zhang F: drivers/crypto/kasumi/ F: doc/guides/cryptodevs/kasumi.rst F: doc/guides/cryptodevs/features/kasumi.ini @@ -1081,7 +1081,7 @@ F: doc/guides/cryptodevs/octeontx2.rst F: doc/guides/cryptodevs/features/octeontx2.ini Null Crypto -M: Declan Doherty +M: Fan Zhang F: drivers/crypto/null/ F: doc/guides/cryptodevs/null.rst F: doc/guides/cryptodevs/features/null.ini @@ -1108,13 +1108,14 @@ F: doc/guides/cryptodevs/dpaa2_sec.rst F: doc/guides/cryptodevs/features/dpaa2_sec.ini OpenSSL -M: Declan Doherty +M: Fan Zhang F: drivers/crypto/openssl/ F: doc/guides/cryptodevs/openssl.rst F: doc/guides/cryptodevs/features/openssl.ini SNOW 3G M: Pablo de Lara +M: Fan Zhang F: drivers/crypto/snow3g/ F: doc/guides/cryptodevs/snow3g.rst F: doc/guides/cryptodevs/features/snow3g.ini @@ -1127,6 +1128,7 @@ F: doc/guides/cryptodevs/features/virtio.ini ZUC M: Pablo de Lara +M: Fan Zhang F: drivers/crypto/zuc/ F: doc/guides/cryptodevs/zuc.rst F: doc/guides/cryptodevs/features/zuc.ini Acked-by: Declan Doherty
Re: [dpdk-dev] maintainers: update for qat and ipsec-mb pmds
> -Original Message- > From: Doherty, Declan > Sent: Thursday, May 20, 2021 11:58 AM > To: Zhang, Roy Fan ; dev@dpdk.org > Cc: tho...@monjalon.net; gak...@marvell.com; Yigit, Ferruh > ; Griffin, John > ; Jain, Deepak K ; Trahe, > Fiona > > Subject: Re: [dpdk-dev] maintainers: update for qat and ipsec-mb pmds > > > > On 20/05/2021 10:47 AM, Fan Zhang wrote: > > Add myself to Crypto API, QAT, SW PMDs based on ipsec-mb, and > > NULL PMD maintainer. > > > > Signed-off-by: Fan Zhang > > Acked-by: Fiona Trahe
[dpdk-dev] [PATCH] test/prefetch: fix build with GCC 11
GCC 11 complains that 'a' is uninitialized.
../dpdk/app/test/test_prefetch.c: In function 'test_prefetch':
../dpdk/app/test/test_prefetch.c:25:9:
error: 'a' may be used uninitialized [-Werror=maybe-uninitialized]
25 | rte_prefetch0(&a);
| ^
Fix by initializing 'a'.
Bugzilla ID: 714
Fixes: af75078fece3 ("first public release")
Cc: sta...@dpdk.org
Reported-by: Ali Alnubani
Signed-off-by: Kevin Traynor
---
app/test/test_prefetch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/app/test/test_prefetch.c b/app/test/test_prefetch.c
index 5489885b51..7b4a8e4144 100644
--- a/app/test/test_prefetch.c
+++ b/app/test/test_prefetch.c
@@ -21,5 +21,5 @@ static int
test_prefetch(void)
{
- int a;
+ int a = 0;
rte_prefetch0(&a);
--
2.31.1
Re: [dpdk-dev] [PATCH] test/prefetch: fix build with GCC 11
> -Original Message-
> From: Kevin Traynor
> Sent: Thursday, May 20, 2021 2:06 PM
> To: dev@dpdk.org
> Cc: ferruh.yi...@intel.com; Kevin Traynor ;
> sta...@dpdk.org; Ali Alnubani
> Subject: [PATCH] test/prefetch: fix build with GCC 11
>
> GCC 11 complains that 'a' is uninitialized.
>
> ../dpdk/app/test/test_prefetch.c: In function 'test_prefetch':
> ../dpdk/app/test/test_prefetch.c:25:9:
> error: 'a' may be used uninitialized [-Werror=maybe-uninitialized]
>25 | rte_prefetch0(&a);
> | ^
>
> Fix by initializing 'a'.
>
> Bugzilla ID: 714
> Fixes: af75078fece3 ("first public release")
> Cc: sta...@dpdk.org
>
> Reported-by: Ali Alnubani
> Signed-off-by: Kevin Traynor
> ---
> app/test/test_prefetch.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/app/test/test_prefetch.c b/app/test/test_prefetch.c index
> 5489885b51..7b4a8e4144 100644
> --- a/app/test/test_prefetch.c
> +++ b/app/test/test_prefetch.c
> @@ -21,5 +21,5 @@ static int
> test_prefetch(void)
> {
> - int a;
> + int a = 0;
>
> rte_prefetch0(&a);
> --
> 2.31.1
Was about to send a fix 😊.
Thank you Kevin.
Build is now passing.
Tested-by: Ali Alnubani
- Ali
[dpdk-dev] [PATCH] doc: add GCC 11 and clang 12 support to release notes
Note added support for GCC 11 and clang 12 in the DPDK 21.05 release notes. Signed-off-by: Kevin Traynor --- Note: we need a fix for https://bugs.dpdk.org/show_bug.cgi?id=714 For reference: $ cat /etc/redhat-release Fedora release 34 (Thirty Four) $ gcc --version gcc (GCC) 11.1.1 20210428 (Red Hat 11.1.1-1) $ clang --version clang version 12.0.0 (Fedora 12.0.0-0.3.rc1.fc34) = Libraries Enabled = libs: kvargs, telemetry, eal, ring, rcu, mempool, mbuf, net, meter, ethdev, pci, cmdline, metrics, hash, timer, acl, bbdev, bitratestats, cfgfile, compressdev, cryptodev, distributor, efd, eventdev, gro, gso, ip_frag, jobstats, kni, latencystats, lpm, member, power, pdump, rawdev, regexdev, rib, reorder, sched, security, stack, vhost, ipsec, fib, port, table, pipeline, flow_classify, bpf, graph, node, Message: === Drivers Enabled === common: cpt, dpaax, iavf, octeontx, octeontx2, cnxk, mlx5, qat, sfc_efx, bus: dpaa, fslmc, ifpga, pci, vdev, vmbus, mempool: bucket, cnxk, dpaa, dpaa2, octeontx, octeontx2, ring, stack, net: af_packet, af_xdp, ark, atlantic, avp, axgbe, bnx2x, bnxt, bond, cxgbe, dpaa, dpaa2, e1000, ena, enetc, enic, failsafe, fm10k, hinic, hns3, i40e, iavf, ice, igc, ionic, ipn3ke, ixgbe, kni, liquidio, memif, mlx4, mlx5, netvsc, nfp, null, octeontx, octeontx2, octeontx_ep, pcap, pfe, qede, ring, sfc, softnic, tap, thunderx, txgbe, vdev_netvsc, vhost, virtio, vmxnet3, raw: dpaa2_cmdif, dpaa2_qdma, ifpga, ioat, ntb, octeontx2_dma, octeontx2_ep, skeleton, crypto: aesni_gcm, aesni_mb, bcmfs, caam_jr, ccp, dpaa_sec, dpaa2_sec, kasumi, nitrox, null, octeontx, octeontx2, openssl, scheduler, snow3g, virtio, zuc, compress: isal, mlx5, octeontx, zlib, regex: mlx5, octeontx2, vdpa: ifc, mlx5, event: cnxk, dlb2, dpaa, dpaa2, dsw, octeontx2, opdl, skeleton, sw, octeontx, baseband: acc100, fpga_5gnr_fec, fpga_lte_fec, null, turbo_sw, Message: = Content Skipped = libs: drivers: common/mvep:missing dependency, "libmusdk" net/mvneta: missing dependency, "libmusdk" net/mvpp2: missing dependency, "libmusdk" net/nfb:missing dependency, "libnfb" net/szedata2: missing dependency, "libsze2" crypto/armv8: missing dependency, "libAArch64crypto" crypto/mvsam: missing dependency, "libmusdk" --- doc/guides/rel_notes/release_21_05.rst | 4 1 file changed, 4 insertions(+) diff --git a/doc/guides/rel_notes/release_21_05.rst b/doc/guides/rel_notes/release_21_05.rst index c66ab1d6a0..883bcb3352 100644 --- a/doc/guides/rel_notes/release_21_05.rst +++ b/doc/guides/rel_notes/release_21_05.rst @@ -312,4 +312,8 @@ New Features list of sub-testsuites, and a list of testcases as before. +* **Added support for GCC 11 and clang 12.** + + Added support for building with GCC 11.1.1 and clang 12.0.0. + Removed Items -- 2.31.1
Re: [dpdk-dev] [dpdk-announce] release candidate 21.05-rc3
All, The following is a list of tests executed with 21.05-rc3: - Basic functionality: Send and receive multiple types of traffic. - testpmd xstats counter test. - RSS tests. - VLAN filtering tests. - Rx Checksum tests - TSO tests. - MTU and Jumbo frame tests - Changing/checking link status through testpmd. - Unicast/multicast MAC filtering tests - VXLAN/Geneve Rx CSO, TSO, RSS tests We don't see any critical issues blocking the release. Regards, Kalesh On Thu, May 13, 2021 at 2:27 AM Thomas Monjalon wrote: > A new DPDK release candidate is ready for testing: > https://git.dpdk.org/dpdk/tag/?id=v21.05-rc3 > > There are 114 new patches in this snapshot. > > Release notes: > https://doc.dpdk.org/guides/rel_notes/release_21_05.html > > Please test and report issues on bugs.dpdk.org. > You may share some release validation results > by replying to this message at dev@dpdk.org. > > DPDK 21.05-rc4 will be out during next week for the final touch. > > Thank you everyone > > > -- Regards, Kalesh A P
[dpdk-dev] [PATCH v2] build: fix SVE compile error with gcc8.3
If the target machine has SVE feature (e.g. "-march=armv8.2-a+sve'),
and the compiler is gcc8.3, it will compile error:
In file included from ../dpdk-next-net/lib/eal/common/
eal_common_options.c:38:
../dpdk-next-net/lib/eal/arm/include/rte_vect.h:13:10: fatal
error: arm_sve.h: No such file or directory
#include
^~~
compilation terminated.
The root cause is that gcc8.3 support SVE (the macro __ARM_FEATURE_SVE
was 1), but it doesn't support SVE ACLE [1].
The solution:
a) Detect compiler whether support SVE ACLE, if support then define
CC_SVE_ACLE_SUPPORT macro.
b) Use the CC_SVE_ACLE_SUPPORT macro to include SVE header file.
[1] ACLE: Arm C Language Extensions, the SVE ACLE header file is
, user should include it when writing ACLE SVE code.
Fixes: 67b68824a82d ("lpm/arm: support SVE")
Signed-off-by: Chengwen Feng
---
v2:
* modify title start with 'build'
---
config/arm/meson.build | 5 +
lib/eal/arm/include/rte_vect.h | 2 +-
lib/lpm/rte_lpm.h | 2 +-
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/config/arm/meson.build b/config/arm/meson.build
index e83a56e..bff70e4 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -480,6 +480,11 @@ if (cc.get_define('__ARM_NEON', args: machine_args) != ''
or
compile_time_cpuflags += ['RTE_CPUFLAG_NEON']
endif
+if (cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != '' and
+cc.check_header('arm_sve.h'))
+dpdk_conf.set('CC_SVE_ACLE_SUPPORT', 1)
+endif
+
if cc.get_define('__ARM_FEATURE_CRC32', args: machine_args) != ''
compile_time_cpuflags += ['RTE_CPUFLAG_CRC32']
endif
diff --git a/lib/eal/arm/include/rte_vect.h b/lib/eal/arm/include/rte_vect.h
index 093e912..277b656 100644
--- a/lib/eal/arm/include/rte_vect.h
+++ b/lib/eal/arm/include/rte_vect.h
@@ -9,7 +9,7 @@
#include "generic/rte_vect.h"
#include "rte_debug.h"
#include "arm_neon.h"
-#ifdef __ARM_FEATURE_SVE
+#ifdef CC_SVE_ACLE_SUPPORT
#include
#endif
diff --git a/lib/lpm/rte_lpm.h b/lib/lpm/rte_lpm.h
index 28b5768..9262814 100644
--- a/lib/lpm/rte_lpm.h
+++ b/lib/lpm/rte_lpm.h
@@ -402,7 +402,7 @@ rte_lpm_lookupx4(const struct rte_lpm *lpm, xmm_t ip,
uint32_t hop[4],
uint32_t defv);
#if defined(RTE_ARCH_ARM)
-#ifdef __ARM_FEATURE_SVE
+#ifdef CC_SVE_ACLE_SUPPORT
#include "rte_lpm_sve.h"
#else
#include "rte_lpm_neon.h"
--
2.8.1
Re: [dpdk-dev] [PATCH] lpm/arm: fix SVE compile error with gcc8.3
Fix in v2, thanks On 2021/5/20 16:17, Ruifeng Wang wrote: > Thanks for this patch. > Minor comment below. > >> -Original Message- >> From: Chengwen Feng >> Sent: Thursday, May 20, 2021 3:17 PM >> To: tho...@monjalon.net; ferruh.yi...@intel.com >> Cc: dev@dpdk.org; bruce.richard...@intel.com; >> vladimir.medved...@intel.com; vikto...@rehivetech.com; Ruifeng Wang >> ; jer...@marvell.com >> Subject: [PATCH] lpm/arm: fix SVE compile error with gcc8.3 > This is build fix and not specific to lpm. > Use 'build:' instead of 'lpm/arm:'? >
Re: [dpdk-dev] [PATCH] ppc64le: fix build without glibc and using Clang
Well, isn't FreeBSD already supported? Even https://www.dpdk.org/ mentions supporting FreeBSD. On 21-05-19 09:53:16, Thomas Monjalon wrote: > 18/05/2021 22:42, David Christensen: > > On 5/16/21 5:46 PM, Piotr Kubaj wrote: > > > __ppc_get_timebase() is only present when glibc is used. > > > > > > Signed-off-by: Piotr Kubaj > > > --- > > > lib/eal/ppc/include/rte_altivec.h | 3 +++ > > > lib/eal/ppc/include/rte_cycles.h | 12 > > > lib/eal/ppc/rte_cycles.c | 16 > > > 3 files changed, 31 insertions(+) > > > > Reviewed-by: David Christensen > > This patch does a lot more than what is described. > It seems adding support for FreeBSD. > For testing OS, please use #ifdef RTE_EXEC_ENV_* > >
Re: [dpdk-dev] [PATCH] ppc64le: fix build without glibc and using Clang
On 21-05-19 11:59:35, Thomas Monjalon wrote: > 19/05/2021 11:57, Piotr Kubaj: > > Well, isn't FreeBSD already supported? > > > > Even https://www.dpdk.org/ mentions supporting FreeBSD. > > Yes it is supposed to be supported. > But why are you adding all this code for PPC? > It doesn't seem to be all related to clang only. > > PS: please do not top-post. > > > > On 21-05-19 09:53:16, Thomas Monjalon wrote: > > > 18/05/2021 22:42, David Christensen: > > > > On 5/16/21 5:46 PM, Piotr Kubaj wrote: > > > > > __ppc_get_timebase() is only present when glibc is used. > > > > > > > > > > Signed-off-by: Piotr Kubaj > > > > > --- > > > > > lib/eal/ppc/include/rte_altivec.h | 3 +++ > > > > > lib/eal/ppc/include/rte_cycles.h | 12 > > > > > lib/eal/ppc/rte_cycles.c | 16 > > > > > 3 files changed, 31 insertions(+) > > > > > > > > Reviewed-by: David Christensen > > > > > > This patch does a lot more than what is described. > > > It seems adding support for FreeBSD. > > > For testing OS, please use #ifdef RTE_EXEC_ENV_* > > > > Well, I'm adding this code for PPC, because there are build issues on powerpc64le machines running FreeBSD.
[dpdk-dev] DPDK Release Status Meeting 20/05/2021
Release status meeting minutes {Date}
=
:Date: 20 May 2021
:toc:
.Agenda:
* Release Dates
* -rc3/4 status
* Subtrees
* LTS
* Defects
* Opens
.Participants:
* Arm
* Broadcom
* Canonical
* Debian/Microsoft
* Intel
* Marvell
* Nvidia
* Red Hat
Release Dates
-
* `v21.05` dates
- -rc4 is released on Wednesday, 19 May
** http://inbox.dpdk.org/dev/1994252.qWktbAlWXN@thomas/
- Release:Friday, 21 May
* `v21.08` dates
- Proposal/V1:Wednesday, 2 June
- -rc1: Monday, 5 July
- Release:Tuesday, 3 August
* *Please send roadmaps*, preferably before beginning of the release
* Expecting a small `v21.08` release.
rc3/4 status
* -rc3 test results
- Intel, IBM, Nvidia & Broadcom shared the -rc3 test results, nothing critical
** http://inbox.dpdk.org/dev/7142607.3L8AUzOtay@thomas/t/#u
* The -rc4 is new, no test reports yet.
* Good to get more test results, please share the test reports
Subtrees
* main
- More tooling and doc patches in the backlog
** John will help on finalizing release notes
- Testing latest DPDK with OvS & SPDK, looks good
- There are four deprecation notices needs to be closed today, please review
** vdpa:
https://patches.dpdk.org/project/dpdk/patch/20210518073441.2749096-1-tho...@monjalon.net/
** crypto:
https://patches.dpdk.org/project/dpdk/patch/20210414201544.1063413-1-tho...@monjalon.net/
** Windows:
https://patches.dpdk.org/project/dpdk/patch/20210310235421.23259-1-dmitry.kozl...@gmail.com/
** net:
https://patches.dpdk.org/project/dpdk/patch/20210303225121.16146-1-dmitry.kozl...@gmail.com/
- v21.05 supports gcc11, Kevin will add a release notes update for it
** Kevin also verified the clang 12
** Should LTS release support gcc11?
* next-net
- No patches for the release
* next-crypto
- There is a doc path from Pablo under review
- Deprecation notice patch from Thomas
** http://dpdk.org/patch/91473
* next-eventdev
- There is one fix for dlb2
** It is waiting new version, patch should be split into multiple patches
*** Internal review before upstream may help
* next-virtio
- Some regressions fixed in -rc4
- vhost crash fixed
** https://bugs.dpdk.org/show_bug.cgi?id=703
- No patches for the release
* next-net-brcm
- No patches for the release, maybe doc update
* next-net-intel
- No patches for the release
* next-net-mlx
- Some fixes merged, all clear for release
* next-net-mrvl
- No patches in the backlog
LTS
---
* `v19.11` (next version is `v19.11.9`)
- Backport request email sent
**
http://inbox.dpdk.org/stable/bab7aa8d-fb62-332e-68a8-474ade5c2...@intel.com/
- Planning an -rc next week
* `v20.11` (next version is `v20.11.2`)
- "Xueming(Steven) Li" requested support for backporting some commits
**
http://inbox.dpdk.org/stable/28797869-b83a-fba8-5c85-8527e4107...@intel.com/
- Planning an -rc soon
* Distros
- v20.11 in Debian 11
- v20.11 in Ubuntu 21.04
Defects
---
* Bugzilla links, 'Bugs', added for hosted projects
- https://www.dpdk.org/hosted-projects/
Opens
-
* Cheng is working on the security issues, it is progressing
* DPDK is using IRC for community communication and we are using
https://freenode.net/
servers. There are some discussions around freenode: https://www.kline.sh/
- Will wait for two weeks to get things clarified, will discuss again later
- Maxime registered a DPDK channel in https://libera.chat/ for any case
* Coverity is running regularly
- Can we have out of cycle run for -rc4? Last run was yesterday.
- We need a way to verify coverity issues before merging it, will carry topic
to CI mail list an Aaron
* There is a new DPDK blog series, Faces of DPDK, starting with Dmitry:
- https://www.dpdk.org/news/blog/
.DPDK Release Status Meetings
*
The DPDK Release Status Meeting is intended for DPDK Committers to discuss the
status of the master tree and sub-trees, and for project managers to track
progress or milestone dates.
The meeting occurs on every Thursdays at 8:30 UTC. on https://meet.jit.si/DPDK
If you wish to attend just send an email to
"John McNamara " for the invite.
*
[dpdk-dev] [dpdk-dev v2] maintainers: update for qat and ipsec-mb pmds
Add myself to Crypto API, QAT, SW PMDs based on ipsec-mb, and NULL PMD maintainer. Signed-off-by: Fan Zhang Acked-by: Declan Doherty Acked-by: Fiona Trahe Acked-by: John Griffin --- V2: - Remove Declan from crypto perf maintainer MAINTAINERS | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 5877a16971..131a7aba73 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -421,7 +421,7 @@ F: examples/bbdev_app/ F: doc/guides/sample_app_ug/bbdev_app.rst Crypto API -M: Declan Doherty +M: Fan Zhang T: git://dpdk.org/next/dpdk-next-crypto F: lib/cryptodev/ F: app/test/test_cryptodev* @@ -429,7 +429,7 @@ F: examples/l2fwd-crypto/ Security API M: Akhil Goyal -M: Declan Doherty +M: Fan Zhang T: git://dpdk.org/next/dpdk-next-crypto F: lib/security/ F: doc/guides/prog_guide/rte_security.rst @@ -1031,23 +1031,22 @@ F: drivers/crypto/scheduler/ F: doc/guides/cryptodevs/scheduler.rst Intel AES-NI GCM -M: Declan Doherty M: Pablo de Lara +M: Fan Zhang F: drivers/crypto/aesni_gcm/ F: doc/guides/cryptodevs/aesni_gcm.rst F: doc/guides/cryptodevs/features/aesni_gcm.ini Intel AES-NI Multi-Buffer -M: Declan Doherty M: Pablo de Lara +M: Fan Zhang F: drivers/crypto/aesni_mb/ F: doc/guides/cryptodevs/aesni_mb.rst F: doc/guides/cryptodevs/features/aesni_mb.ini Intel QuickAssist -M: John Griffin M: Fiona Trahe -M: Deepak Kumar Jain +M: Fan Zhang F: drivers/crypto/qat/ F: drivers/common/qat/ F: doc/guides/cryptodevs/qat.rst @@ -1055,6 +1054,7 @@ F: doc/guides/cryptodevs/features/qat.ini KASUMI M: Pablo de Lara +M: Fan Zhang F: drivers/crypto/kasumi/ F: doc/guides/cryptodevs/kasumi.rst F: doc/guides/cryptodevs/features/kasumi.ini @@ -1081,7 +1081,7 @@ F: doc/guides/cryptodevs/octeontx2.rst F: doc/guides/cryptodevs/features/octeontx2.ini Null Crypto -M: Declan Doherty +M: Fan Zhang F: drivers/crypto/null/ F: doc/guides/cryptodevs/null.rst F: doc/guides/cryptodevs/features/null.ini @@ -1108,13 +1108,14 @@ F: doc/guides/cryptodevs/dpaa2_sec.rst F: doc/guides/cryptodevs/features/dpaa2_sec.ini OpenSSL -M: Declan Doherty +M: Fan Zhang F: drivers/crypto/openssl/ F: doc/guides/cryptodevs/openssl.rst F: doc/guides/cryptodevs/features/openssl.ini SNOW 3G M: Pablo de Lara +M: Fan Zhang F: drivers/crypto/snow3g/ F: doc/guides/cryptodevs/snow3g.rst F: doc/guides/cryptodevs/features/snow3g.ini @@ -1127,6 +1128,7 @@ F: doc/guides/cryptodevs/features/virtio.ini ZUC M: Pablo de Lara +M: Fan Zhang F: drivers/crypto/zuc/ F: doc/guides/cryptodevs/zuc.rst F: doc/guides/cryptodevs/features/zuc.ini @@ -1616,7 +1618,6 @@ F: app/test-compress-perf/ F: doc/guides/tools/comp_perf.rst Crypto performance test application -M: Declan Doherty M: Ciara Power T: git://dpdk.org/next/dpdk-next-crypto F: app/test-crypto-perf/ -- 2.25.1
Re: [dpdk-dev] [dpdk-dev v2] maintainers: update for qat and ipsec-mb pmds
20/05/2021 14:16, Fan Zhang: > Add myself to Crypto API, QAT, SW PMDs based on ipsec-mb, and > NULL PMD maintainer. You should mention the removal as well. If you want to be a maintainer, please be more precise in your patch ;) [...] > Crypto API > -M: Declan Doherty > +M: Fan Zhang It is not an update for PMDs only, the title is not accurate.
Re: [dpdk-dev] [PATCH v2] build: fix SVE compile error with gcc8.3
On Thu, May 20, 2021 at 07:40:12PM +0800, Chengwen Feng wrote:
> If the target machine has SVE feature (e.g. "-march=armv8.2-a+sve'),
> and the compiler is gcc8.3, it will compile error:
> In file included from ../dpdk-next-net/lib/eal/common/
> eal_common_options.c:38:
> ../dpdk-next-net/lib/eal/arm/include/rte_vect.h:13:10: fatal
> error: arm_sve.h: No such file or directory
> #include
> ^~~
> compilation terminated.
>
> The root cause is that gcc8.3 support SVE (the macro __ARM_FEATURE_SVE
> was 1), but it doesn't support SVE ACLE [1].
>
> The solution:
> a) Detect compiler whether support SVE ACLE, if support then define
> CC_SVE_ACLE_SUPPORT macro.
> b) Use the CC_SVE_ACLE_SUPPORT macro to include SVE header file.
>
> [1] ACLE: Arm C Language Extensions, the SVE ACLE header file is
> , user should include it when writing ACLE SVE code.
>
> Fixes: 67b68824a82d ("lpm/arm: support SVE")
>
> Signed-off-by: Chengwen Feng
> ---
> v2:
> * modify title start with 'build'
>
One minor comment inline below.
/Bruce
> ---
> config/arm/meson.build | 5 +
> lib/eal/arm/include/rte_vect.h | 2 +-
> lib/lpm/rte_lpm.h | 2 +-
> 3 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/config/arm/meson.build b/config/arm/meson.build
> index e83a56e..bff70e4 100644
> --- a/config/arm/meson.build
> +++ b/config/arm/meson.build
> @@ -480,6 +480,11 @@ if (cc.get_define('__ARM_NEON', args: machine_args) !=
> '' or
> compile_time_cpuflags += ['RTE_CPUFLAG_NEON']
> endif
>
> +if (cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != '' and
> +cc.check_header('arm_sve.h'))
Please double-indent this line. It looks like part of the condition body
as-is.
Re: [dpdk-dev] [PATCH] doc: announce renaming of rte_ether_hdr fields
On 3/3/2021 10:51 PM, Dmitry Kozlyuk wrote:
> It is proposed to rename fields of `struct rte_ether_hdr`,
> `s_addr` tp `src_addr` and `d_addr` to `dst_addr`,
s/tp/to/
> due to the clash with system macro on Windows.
> Until remaining is done in 21.11, a workaround can be used.
s/remaining/renaming/ ??
>
> Windows Sockets headers contain `#define s_addr S_un.S_addr`, which
> conflicts with `s_addr` field of `struct rte_ether_hdr`. Undefining
> this macro in is breaking some usages of DPDK
> and Windows headers in one file.
>
> Example 1:
>
> #include
> #include
> struct in_addr addr;
> /* addr.s_addr = 0; ERROR: s_addr undefined by DPDK */
>
> Example 2:
>
> #include
> #include
> struct rte_ether_hdr eh;
> /* eh.s_addr.addr_bytes[0] = 0; ERROR: `addr_s` is a macro */
s/addr_s/s_addr/ ??
>
> It is not mandatory to rename `d_addr`, this is for consistency only.
> Naming in `rte_ether_hdr` will also resemble `rte_ipv4/6_hdr`.
>
> Workaround is to define `struct rte_ether_hdr` in such a away that
> it can be used with or without `s_addr` macro (as defined on Windows)
> This can be done for Windows only or for all platforms to save space.
>
> #pragma push_macro("s_addr")
> #ifdef s_addr
> #undef s_addr
> #endif
>
> struct rte_ether_hdr {
> struct rte_ether_addr d_addr; /**< Destination address. */
> RTE_STD_C11
> union {
> struct rte_ether_addr s_addr; /**< Source address. */
> struct {
> struct rte_ether_addr S_un;
> /**< MUST NOT be used directly, only via s_addr */
> } S_addr;
> /*< MUST NOT be used directly, only via s_addr */
> };
> uint16_t ether_type; /**< Frame type. */
> } __rte_aligned(2);
>
> #pragma pop_macro("s_addr")
>
What is the problem with the workaround, why we can't live with it?
It requires an order in include files, right?
> Signed-off-by: Dmitry Kozlyuk
> ---
> doc/guides/rel_notes/deprecation.rst | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> index 82c1a90a3..f7be10543 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -125,3 +125,7 @@ Deprecation Notices
> * cmdline: ``cmdline`` structure will be made opaque to hide
> platform-specific
>content. On Linux and FreeBSD, supported prior to DPDK 20.11,
>original structure will be kept until DPDK 21.11.
> +
> +* net: ``s_addr`` and ``d_addr`` fields of ``rte_ether_hdr`` structure
> + will be renamed to ``src_addr`` and ``dst_addr`` respectively in DPDK 20.11
v21.11
> + in order to avoid conflict with Windows Sockets headers.
>
Re: [dpdk-dev] [PATCH] doc: announce renaming of rte_ether_hdr fields
On 3/4/2021 7:09 AM, Dmitry Kozlyuk wrote:
> 2021-03-03 15:54, Stephen Hemminger:
>>> +
>>> +* net: ``s_addr`` and ``d_addr`` fields of ``rte_ether_hdr`` structure
>>> + will be renamed to ``src_addr`` and ``dst_addr`` respectively in DPDK
>>> 20.11
>>> + in order to avoid conflict with Windows Sockets headers.
>>
>> If those fields were a problem now, there might be others in future.
>
> One I can think of is `min` and `max` macros from `windows.h`: they are used
> as field names in `rte_compressdev.h` and `rte_cryptodev.h` (and more than
> once have they been worked around in PMD code, see i40e and ice patches).
> Do you prefer a single notice for all such conflicts we can identify now?
>
>> Don't use src_addr and dst_addr because those are already used in
>> rte_ipv4_hdr.
>
Why src_addr being used in rte_ipv4_hdr is a problem?
> Not sure what DPDK policy is: `rte_ipv4/6_hdr` use completely custom names,
> while `rte_arp_hdr` uses traditional names with `arp_` prefix.
> Coming from C++, I chose the former approach, but it's not a strong opinion.
>
I am now aware of a DPDK policy for it, but +1 to former approach.
>> Linux and FreeBSD use:
>>
>> struct ether_header
>> {
>> uint8_t ether_dhost[ETH_ALEN];/* destination eth addr */
>> uint8_t ether_shost[ETH_ALEN];/* source ether addr*/
>> uint16_t ether_type; /* packet type ID field */
>> } __attribute__ ((__packed__));
>>
>> So why not ether_dhost/ether_shost?
>
> Works for me, let's see what others think.
>
Re: [dpdk-dev] [dpdk-stable] [PATCH] test/prefetch: fix build with GCC 11
On Thu, May 20, 2021 at 1:07 PM Kevin Traynor wrote:
>
> GCC 11 complains that 'a' is uninitialized.
>
> ../dpdk/app/test/test_prefetch.c: In function 'test_prefetch':
> ../dpdk/app/test/test_prefetch.c:25:9:
> error: 'a' may be used uninitialized [-Werror=maybe-uninitialized]
>25 | rte_prefetch0(&a);
> | ^
>
> Fix by initializing 'a'.
>
> Bugzilla ID: 714
> Fixes: af75078fece3 ("first public release")
> Cc: sta...@dpdk.org
>
> Reported-by: Ali Alnubani
> Signed-off-by: Kevin Traynor
Reviewed-by: David Marchand
--
David Marchand
Re: [dpdk-dev] [PATCH] doc: announce renaming of rte_ether_hdr fields
2021-05-20 15:24 (UTC+0100), Ferruh Yigit:
> On 3/3/2021 10:51 PM, Dmitry Kozlyuk wrote:
[...]
> >
> > It is not mandatory to rename `d_addr`, this is for consistency only.
> > Naming in `rte_ether_hdr` will also resemble `rte_ipv4/6_hdr`.
> >
> > Workaround is to define `struct rte_ether_hdr` in such a away that
> > it can be used with or without `s_addr` macro (as defined on Windows)
> > This can be done for Windows only or for all platforms to save space.
> >
> > #pragma push_macro("s_addr")
> > #ifdef s_addr
> > #undef s_addr
> > #endif
> >
> > struct rte_ether_hdr {
> > struct rte_ether_addr d_addr; /**< Destination address. */
> > RTE_STD_C11
> > union {
> > struct rte_ether_addr s_addr; /**< Source address. */
> > struct {
> > struct rte_ether_addr S_un;
> > /**< MUST NOT be used directly, only via s_addr */
> > } S_addr;
> > /*< MUST NOT be used directly, only via s_addr */
> > };
> > uint16_t ether_type; /**< Frame type. */
> > } __rte_aligned(2);
> >
> > #pragma pop_macro("s_addr")
> >
>
> What is the problem with the workaround, why we can't live with it?
>
> It requires an order in include files, right?
There's no problem except a tricky structure definition with fields that
violate DPDK coding rules. It works with any include order.
Will fix typos in v3, thanks.
[dpdk-dev] [dpdk-dev v1] cperf: fix crypto perf out-of-place mempool alloc
Add in missing rte_mbuf size in mempool allocation for out-of-place op.
Fixes: bf9d6702eca9 ("app/crypto-perf: use single mempool")
Cc: pablo.de.lara.gua...@intel.com
Signed-off-by: Kai Ji
---
app/test-crypto-perf/cperf_test_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/app/test-crypto-perf/cperf_test_common.c
b/app/test-crypto-perf/cperf_test_common.c
index 058e0ba564..12925c7f22 100644
--- a/app/test-crypto-perf/cperf_test_common.c
+++ b/app/test-crypto-perf/cperf_test_common.c
@@ -194,7 +194,7 @@ cperf_alloc_common_memory(const struct cperf_options
*options,
(mbuf_size * segments_nb);
params.dst_buf_offset = *dst_buf_offset;
/* Destination buffer will be one segment only */
- obj_size += max_size;
+ obj_size += max_size + sizeof(struct rte_mbuf);
}
*pool = rte_mempool_create_empty(pool_name,
--
2.17.1
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
Re: [dpdk-dev] [PATCH] doc: announce renaming of rte_ether_hdr fields
On 5/20/2021 4:06 PM, Dmitry Kozlyuk wrote:
> 2021-05-20 15:24 (UTC+0100), Ferruh Yigit:
>> On 3/3/2021 10:51 PM, Dmitry Kozlyuk wrote:
> [...]
>>>
>>> It is not mandatory to rename `d_addr`, this is for consistency only.
>>> Naming in `rte_ether_hdr` will also resemble `rte_ipv4/6_hdr`.
>>>
>>> Workaround is to define `struct rte_ether_hdr` in such a away that
>>> it can be used with or without `s_addr` macro (as defined on Windows)
>>> This can be done for Windows only or for all platforms to save space.
>>>
>>> #pragma push_macro("s_addr")
>>> #ifdef s_addr
>>> #undef s_addr
>>> #endif
>>>
>>> struct rte_ether_hdr {
>>> struct rte_ether_addr d_addr; /**< Destination address. */
>>> RTE_STD_C11
>>> union {
>>> struct rte_ether_addr s_addr; /**< Source address. */
>>> struct {
>>> struct rte_ether_addr S_un;
>>> /**< MUST NOT be used directly, only via s_addr */
>>> } S_addr;
>>> /*< MUST NOT be used directly, only via s_addr */
>>> };
>>> uint16_t ether_type; /**< Frame type. */
>>> } __rte_aligned(2);
>>>
>>> #pragma pop_macro("s_addr")
>>>
>>
>> What is the problem with the workaround, why we can't live with it?
>>
>> It requires an order in include files, right?
>
> There's no problem except a tricky structure definition with fields that
> violate DPDK coding rules. It works with any include order.
>
> Will fix typos in v3, thanks.
>
For following case, won't compiler take 's_addr' as macro?
#include
#include
struct rte_ether_hdr eh;
/* eh.s_addr.addr_bytes[0] = 0;
Re: [dpdk-dev] [dpdk-ci] dpdk-next-crypto/master is failing tests
Hi David, Sorry for the late reply. This may be due to the configuration with Jenkins on our side. If I do not see that next-virtio and next-crypto are in Jenkins, I can definitely add it in. Thanks, Brandon On Tue, May 11, 2021 at 9:54 AM David Marchand wrote: > > On Thu, May 6, 2021 at 6:15 PM Brandon Lo wrote: > > > > Hi all, > > > > dpdk-next-qos and dpdk-next-pipeline remotes have been removed. > > dpdk-next-virtio and dpdk-next-crypto remotes have been switched to > > track main and for-main branches respectively. > > Thank you Brandon. > > Just an additional question. > > In the lab dashboard, I can find status/test reports for the most > repositories, like main, next-net, next-net-intel. > https://lab.dpdk.org/results/dashboard/tarballs/ > > But I can't find next-virtio or next-crypto. > Are they tested / supposed to land in this part of the dashboard? > > > -- > David Marchand > -- Brandon Lo UNH InterOperability Laboratory 21 Madbury Rd, Suite 100, Durham, NH 03824 b...@iol.unh.edu www.iol.unh.edu
Re: [dpdk-dev] [PATCH] doc: announce renaming of rte_ether_hdr fields
2021-05-20 16:27 (UTC+0100), Ferruh Yigit:
> On 5/20/2021 4:06 PM, Dmitry Kozlyuk wrote:
> > 2021-05-20 15:24 (UTC+0100), Ferruh Yigit:
> >> On 3/3/2021 10:51 PM, Dmitry Kozlyuk wrote:
> > [...]
> >>>
> >>> It is not mandatory to rename `d_addr`, this is for consistency only.
> >>> Naming in `rte_ether_hdr` will also resemble `rte_ipv4/6_hdr`.
> >>>
> >>> Workaround is to define `struct rte_ether_hdr` in such a away that
> >>> it can be used with or without `s_addr` macro (as defined on Windows)
> >>> This can be done for Windows only or for all platforms to save space.
> >>>
> >>> #pragma push_macro("s_addr")
> >>> #ifdef s_addr
> >>> #undef s_addr
> >>> #endif
> >>>
> >>> struct rte_ether_hdr {
> >>> struct rte_ether_addr d_addr; /**< Destination address. */
> >>> RTE_STD_C11
> >>> union {
> >>> struct rte_ether_addr s_addr; /**< Source address. */
> >>> struct {
> >>> struct rte_ether_addr S_un;
> >>> /**< MUST NOT be used directly, only via s_addr */
> >>> } S_addr;
> >>> /*< MUST NOT be used directly, only via s_addr */
> >>> };
> >>> uint16_t ether_type; /**< Frame type. */
> >>> } __rte_aligned(2);
> >>>
> >>> #pragma pop_macro("s_addr")
> >>>
> >>
> >> What is the problem with the workaround, why we can't live with it?
> >>
> >> It requires an order in include files, right?
> >
> > There's no problem except a tricky structure definition with fields that
> > violate DPDK coding rules. It works with any include order.
> >
> > Will fix typos in v3, thanks.
> >
>
> For following case, won't compiler take 's_addr' as macro?
>
> #include
> #include
> struct rte_ether_hdr eh;
> /* eh.s_addr.addr_bytes[0] = 0;
>
Yes, it will. The macro will expand to `S_addr.S_un` and compile successfully.
In theory, Microsoft can change the definition of `s_addr`, and while I doubt
they will, it's a valid concern and a reason to remove workaround in 21.11.
Re: [dpdk-dev] [PATCH] doc: announce renaming of rte_ether_hdr fields
On 5/20/2021 4:50 PM, Dmitry Kozlyuk wrote:
> 2021-05-20 16:27 (UTC+0100), Ferruh Yigit:
>> On 5/20/2021 4:06 PM, Dmitry Kozlyuk wrote:
>>> 2021-05-20 15:24 (UTC+0100), Ferruh Yigit:
On 3/3/2021 10:51 PM, Dmitry Kozlyuk wrote:
>>> [...]
>
> It is not mandatory to rename `d_addr`, this is for consistency only.
> Naming in `rte_ether_hdr` will also resemble `rte_ipv4/6_hdr`.
>
> Workaround is to define `struct rte_ether_hdr` in such a away that
> it can be used with or without `s_addr` macro (as defined on Windows)
> This can be done for Windows only or for all platforms to save space.
>
> #pragma push_macro("s_addr")
> #ifdef s_addr
> #undef s_addr
> #endif
>
> struct rte_ether_hdr {
> struct rte_ether_addr d_addr; /**< Destination address. */
> RTE_STD_C11
> union {
> struct rte_ether_addr s_addr; /**< Source address. */
> struct {
> struct rte_ether_addr S_un;
> /**< MUST NOT be used directly, only via s_addr */
> } S_addr;
> /*< MUST NOT be used directly, only via s_addr */
> };
> uint16_t ether_type; /**< Frame type. */
> } __rte_aligned(2);
>
> #pragma pop_macro("s_addr")
>
What is the problem with the workaround, why we can't live with it?
It requires an order in include files, right?
>>>
>>> There's no problem except a tricky structure definition with fields that
>>> violate DPDK coding rules. It works with any include order.
>>>
>>> Will fix typos in v3, thanks.
>>>
>>
>> For following case, won't compiler take 's_addr' as macro?
>>
>> #include
>> #include
>> struct rte_ether_hdr eh;
>> /* eh.s_addr.addr_bytes[0] = 0;
>>
>
> Yes, it will. The macro will expand to `S_addr.S_un` and compile successfully.
will 'eh.S_addr.S_un.addr_bytes[0] = 0;' compile successfully?
> In theory, Microsoft can change the definition of `s_addr`, and while I doubt
> they will, it's a valid concern and a reason to remove workaround in 21.11.
>
Re: [dpdk-dev] [PATCH] doc: announce renaming of rte_ether_hdr fields
2021-05-20 17:04 (UTC+0100), Ferruh Yigit:
> On 5/20/2021 4:50 PM, Dmitry Kozlyuk wrote:
> > 2021-05-20 16:27 (UTC+0100), Ferruh Yigit:
> >> On 5/20/2021 4:06 PM, Dmitry Kozlyuk wrote:
> >>> 2021-05-20 15:24 (UTC+0100), Ferruh Yigit:
> On 3/3/2021 10:51 PM, Dmitry Kozlyuk wrote:
> >>> [...]
> >
> > It is not mandatory to rename `d_addr`, this is for consistency only.
> > Naming in `rte_ether_hdr` will also resemble `rte_ipv4/6_hdr`.
> >
> > Workaround is to define `struct rte_ether_hdr` in such a away that
> > it can be used with or without `s_addr` macro (as defined on Windows)
> > This can be done for Windows only or for all platforms to save space.
> >
> > #pragma push_macro("s_addr")
> > #ifdef s_addr
> > #undef s_addr
> > #endif
> >
> > struct rte_ether_hdr {
> > struct rte_ether_addr d_addr; /**< Destination address. */
> > RTE_STD_C11
> > union {
> > struct rte_ether_addr s_addr; /**< Source address. */
> > struct {
> > struct rte_ether_addr S_un;
> > /**< MUST NOT be used directly, only via s_addr */
> > } S_addr;
> > /*< MUST NOT be used directly, only via s_addr */
> > };
> > uint16_t ether_type; /**< Frame type. */
> > } __rte_aligned(2);
> >
> > #pragma pop_macro("s_addr")
> >
>
> What is the problem with the workaround, why we can't live with it?
>
> It requires an order in include files, right?
> >>>
> >>> There's no problem except a tricky structure definition with fields that
> >>> violate DPDK coding rules. It works with any include order.
> >>>
> >>> Will fix typos in v3, thanks.
> >>>
> >>
> >> For following case, won't compiler take 's_addr' as macro?
> >>
> >> #include
> >> #include
> >> struct rte_ether_hdr eh;
> >> /* eh.s_addr.addr_bytes[0] = 0;
> >>
> >
> > Yes, it will. The macro will expand to `S_addr.S_un` and compile
> > successfully.
>
> will 'eh.S_addr.S_un.addr_bytes[0] = 0;' compile successfully?
Yes, only it's `S_un.S_addr`, sorry for the typo in my explanation.
Both code snippets from commit message compile successfully.
>
> > In theory, Microsoft can change the definition of `s_addr`, and while I
> > doubt
> > they will, it's a valid concern and a reason to remove workaround in 21.11.
> >
>
[dpdk-dev] [PATCH] event/dlb2: fix extraction of HW scheduling type
The HW scheduling type was not being extracted properly
in the vector optimizaed dequeue path. It was also not
being recorded in the xstats.
Fixes: 000a7b8e7582 ("event/dlb2: optimize dequeue operation")
Signed-off-by: Timothy McDaniel
---
Cc: timothy.mcdan...@intel.com
---
drivers/event/dlb2/dlb2.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/event/dlb2/dlb2.c b/drivers/event/dlb2/dlb2.c
index 3570678b9..588c41ee7 100644
--- a/drivers/event/dlb2/dlb2.c
+++ b/drivers/event/dlb2/dlb2.c
@@ -3561,6 +3561,11 @@ _process_deq_qes_vec_impl(struct dlb2_port *qm_port,
int ev_qid2 = qm_port->qid_mappings[hw_qid2];
int ev_qid3 = qm_port->qid_mappings[hw_qid3];
+ int hw_sched0 = _mm_extract_epi8(v_qe_meta, 3) & 3ul;
+ int hw_sched1 = _mm_extract_epi8(v_qe_meta, 7) & 3ul;
+ int hw_sched2 = _mm_extract_epi8(v_qe_meta, 11) & 3ul;
+ int hw_sched3 = _mm_extract_epi8(v_qe_meta, 15) & 3ul;
+
v_qid_done = _mm_insert_epi8(v_qid_done, ev_qid0, 2);
v_qid_done = _mm_insert_epi8(v_qid_done, ev_qid1, 6);
v_qid_done = _mm_insert_epi8(v_qid_done, ev_qid2, 10);
@@ -3682,19 +3687,27 @@ _process_deq_qes_vec_impl(struct dlb2_port *qm_port,
v_ev_3 = _mm_blend_epi16(v_unpk_ev_23, v_qe_3, 0x0F);
v_ev_3 = _mm_alignr_epi8(v_ev_3, v_ev_3, 8);
_mm_storeu_si128((__m128i *)&events[3], v_ev_3);
+ DLB2_INC_STAT(qm_port->ev_port->stats.rx_sched_cnt[hw_sched3],
+ 1);
/* fallthrough */
case 3:
v_ev_2 = _mm_unpacklo_epi64(v_unpk_ev_23, v_qe_2);
_mm_storeu_si128((__m128i *)&events[2], v_ev_2);
+ DLB2_INC_STAT(qm_port->ev_port->stats.rx_sched_cnt[hw_sched2],
+ 1);
/* fallthrough */
case 2:
v_ev_1 = _mm_blend_epi16(v_unpk_ev_01, v_qe_1, 0x0F);
v_ev_1 = _mm_alignr_epi8(v_ev_1, v_ev_1, 8);
_mm_storeu_si128((__m128i *)&events[1], v_ev_1);
+ DLB2_INC_STAT(qm_port->ev_port->stats.rx_sched_cnt[hw_sched1],
+ 1);
/* fallthrough */
case 1:
v_ev_0 = _mm_unpacklo_epi64(v_unpk_ev_01, v_qe_0);
_mm_storeu_si128((__m128i *)&events[0], v_ev_0);
+ DLB2_INC_STAT(qm_port->ev_port->stats.rx_sched_cnt[hw_sched0],
+ 1);
}
}
--
2.23.0
[dpdk-dev] [PATCH] event/dlb2: remove references to deferred scheduling
Deferred scheduling is a DLB v1.0 feature, and is not valid for
DLB v2.0 or v2.5.
Fixes: a3c8a44634e3 ("event/dlb2: remove useless code")
Cc: sta...@dpdk.org
Signed-off-by: Timothy McDaniel
---
Cc: timothy.mcdan...@intel.com
---
doc/guides/eventdevs/dlb2.rst | 21 -
drivers/event/dlb2/dlb2_priv.h | 3 ---
2 files changed, 24 deletions(-)
diff --git a/doc/guides/eventdevs/dlb2.rst b/doc/guides/eventdevs/dlb2.rst
index 31de6bc47..c60c454d6 100644
--- a/doc/guides/eventdevs/dlb2.rst
+++ b/doc/guides/eventdevs/dlb2.rst
@@ -293,27 +293,6 @@ The PMD does not support the following configuration
sequences:
This sequence is not supported because the event device must be reconfigured
before its ports or queues can be.
-Deferred Scheduling
-~~~
-
-The DLB PMD's default behavior for managing a CQ is to "pop" the CQ once per
-dequeued event before returning from rte_event_dequeue_burst(). This frees the
-corresponding entries in the CQ, which enables the DLB to schedule more events
-to it.
-
-To support applications seeking finer-grained scheduling control -- for example
-deferring scheduling to get the best possible priority scheduling and
-load-balancing -- the PMD supports a deferred scheduling mode. In this mode,
-the CQ entry is not popped until the *subsequent* rte_event_dequeue_burst()
-call. This mode only applies to load-balanced event ports with dequeue depth of
-1.
-
-To enable deferred scheduling, use the defer_sched vdev argument like so:
-
-.. code-block:: console
-
- --vdev=dlb2_event,defer_sched=on
-
Atomic Inflights Allocation
~~~
diff --git a/drivers/event/dlb2/dlb2_priv.h b/drivers/event/dlb2/dlb2_priv.h
index 3140764a5..b1225af37 100644
--- a/drivers/event/dlb2/dlb2_priv.h
+++ b/drivers/event/dlb2/dlb2_priv.h
@@ -32,7 +32,6 @@
#define DLB2_MAX_NUM_EVENTS "max_num_events"
#define DLB2_NUM_DIR_CREDITS "num_dir_credits"
#define DEV_ID_ARG "dev_id"
-#define DLB2_DEFER_SCHED_ARG "defer_sched"
#define DLB2_QID_DEPTH_THRESH_ARG "qid_depth_thresh"
#define DLB2_COS_ARG "cos"
#define DLB2_POLL_INTERVAL_ARG "poll_interval"
@@ -585,7 +584,6 @@ struct dlb2_eventdev {
uint16_t num_dir_ports; /* total num of dir ports requested */
bool umwait_allowed;
bool global_dequeue_wait; /* Not using per dequeue wait if true */
- bool defer_sched;
enum dlb2_cq_poll_modes poll_mode;
int poll_interval;
int sw_credit_quanta;
@@ -620,7 +618,6 @@ struct dlb2_devargs {
int max_num_events;
int num_dir_credits_override;
int dev_id;
- int defer_sched;
struct dlb2_qid_depth_thresholds qid_depth_thresholds;
enum dlb2_cos cos_id;
int poll_interval;
--
2.23.0
[dpdk-dev] [PATCH] doc: fix devarg references in DLB2 guide
Convert to PCI "--allow" devarg format. The documentation
was previously using the "--vdev" form, which cannot be used with the
DLB2 PF PMD.
Fixes: 166378a79412 ("event/dlb2: add documentation and build infrastructure")
Cc: sta...@dpdk.org
Signed-off-by: Timothy McDaniel
---
Cc: timothy.mcdan...@intel.com
---
doc/guides/eventdevs/dlb2.rst | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/doc/guides/eventdevs/dlb2.rst b/doc/guides/eventdevs/dlb2.rst
index 3f4bab97a..bce984ca0 100644
--- a/doc/guides/eventdevs/dlb2.rst
+++ b/doc/guides/eventdevs/dlb2.rst
@@ -152,19 +152,19 @@ These pools' sizes are controlled by the nb_events_limit
field in struct
rte_event_dev_config. The load-balanced pool is sized to contain
nb_events_limit credits, and the directed pool is sized to contain
nb_events_limit/4 credits. The directed pool size can be overridden with the
-num_dir_credits vdev argument, like so:
+num_dir_credits devargs argument, like so:
.. code-block:: console
- --vdev=dlb2_event,num_dir_credits=
+ --allow ea:00.0,num_dir_credits=
This can be used if the default allocation is too low or too high for the
-specific application needs. The PMD also supports a vdev arg that limits the
+specific application needs. The PMD also supports a devarg that limits the
max_num_events reported by rte_event_dev_info_get():
.. code-block:: console
- --vdev=dlb2_event,max_num_events=
+ --allow ea:00.0,max_num_events=
By default, max_num_events is reported as the total available load-balanced
credits. If multiple DLB-based applications are being used, it may be desirable
@@ -315,11 +315,11 @@ buffer space (e.g. if not all queues are used, or aren't
used for atomic
scheduling).
The PMD provides a dev arg to override the default per-queue allocation. To
-increase a vdev's per-queue atomic-inflight allocation to (for example) 64:
+increase per-queue atomic-inflight allocation to (for example) 64:
.. code-block:: console
- --vdev=dlb2_event,atm_inflights=64
+ --allow ea:00.0,atm_inflights=64
QID Depth Threshold
~~~
@@ -342,9 +342,9 @@ shown below.
.. code-block:: console
- --vdev=dlb2_event,qid_depth_thresh=all:
- --vdev=dlb2_event,qid_depth_thresh=qidA-qidB:
- --vdev=dlb2_event,qid_depth_thresh=qid:
+ --allow ea:00.0,qid_depth_thresh=all:
+ --allow ea:00.0,qid_depth_thresh=qidA-qidB:
+ --allow ea:00.0,qid_depth_thresh=qid:
Class of service
@@ -366,10 +366,10 @@ Class of service can be specified in the devargs, as
follows
.. code-block:: console
- --vdev=dlb2_event,cos=<0..4>
+ --allow ea:00.0,cos=<0..4>
Use X86 Vector Instructions
-~~
+~~~
DLB supports using x86 vector instructions to optimize the data path.
@@ -379,4 +379,4 @@ follows
.. code-block:: console
- --allow ea:00.0,vector_opts_enabled=
+ --allow ea:00.0,vector_opts_enabled=
--
2.23.0
[dpdk-dev] [PATCH] event/dlb2: make scalar mode dequeue the default
Optimized dequeue using x86 vector instructions was added
in 21.05, but due to limited testing the default has been
changed back to the scalar mode implementation. The vector mode
implementation can be enabled via the devargs option
"vector_opts_enabled=".
Fixes: 000a7b8e7582 ("event/dlb2: optimize dequeue operation")
Signed-off-by: Timothy McDaniel
---
Cc: timothy.mcdan...@intel.com
---
doc/guides/eventdevs/dlb2.rst | 13 +
drivers/event/dlb2/dlb2.c | 24
drivers/event/dlb2/dlb2_priv.h | 6 +++---
3 files changed, 28 insertions(+), 15 deletions(-)
diff --git a/doc/guides/eventdevs/dlb2.rst b/doc/guides/eventdevs/dlb2.rst
index c60c454d6..3f4bab97a 100644
--- a/doc/guides/eventdevs/dlb2.rst
+++ b/doc/guides/eventdevs/dlb2.rst
@@ -367,3 +367,16 @@ Class of service can be specified in the devargs, as
follows
.. code-block:: console
--vdev=dlb2_event,cos=<0..4>
+
+Use X86 Vector Instructions
+~~
+
+DLB supports using x86 vector instructions to optimize the data path.
+
+The default mode of operation is to use scalar instructions, but
+the use of vector instructions can be enabled in the devargs, as
+follows
+
+.. code-block:: console
+
+ --allow ea:00.0,vector_opts_enabled=
diff --git a/drivers/event/dlb2/dlb2.c b/drivers/event/dlb2/dlb2.c
index 588c41ee7..0022f65fc 100644
--- a/drivers/event/dlb2/dlb2.c
+++ b/drivers/event/dlb2/dlb2.c
@@ -376,11 +376,11 @@ set_default_depth_thresh(const char *key __rte_unused,
}
static int
-set_vector_opts_disab(const char *key __rte_unused,
+set_vector_opts_enab(const char *key __rte_unused,
const char *value,
void *opaque)
{
- bool *dlb2_vector_opts_disabled = opaque;
+ bool *dlb2_vector_opts_enabled = opaque;
if (value == NULL || opaque == NULL) {
DLB2_LOG_ERR("NULL pointer\n");
@@ -388,9 +388,9 @@ set_vector_opts_disab(const char *key __rte_unused,
}
if ((*value == 'y') || (*value == 'Y'))
- *dlb2_vector_opts_disabled = true;
+ *dlb2_vector_opts_enabled = true;
else
- *dlb2_vector_opts_disabled = false;
+ *dlb2_vector_opts_enabled = false;
return 0;
}
@@ -1469,7 +1469,7 @@ dlb2_hw_create_ldb_port(struct dlb2_eventdev *dlb2,
#else
if ((qm_port->cq_depth > 64) ||
(!rte_is_power_of_2(qm_port->cq_depth)) ||
- (dlb2->vector_opts_disabled == true))
+ (dlb2->vector_opts_enabled == false))
qm_port->use_scalar = true;
#endif
@@ -1665,7 +1665,7 @@ dlb2_hw_create_dir_port(struct dlb2_eventdev *dlb2,
#else
if ((qm_port->cq_depth > 64) ||
(!rte_is_power_of_2(qm_port->cq_depth)) ||
- (dlb2->vector_opts_disabled == true))
+ (dlb2->vector_opts_enabled == false))
qm_port->use_scalar = true;
#endif
@@ -4434,7 +4434,7 @@ dlb2_primary_eventdev_probe(struct rte_eventdev *dev,
dlb2->poll_interval = dlb2_args->poll_interval;
dlb2->sw_credit_quanta = dlb2_args->sw_credit_quanta;
dlb2->default_depth_thresh = dlb2_args->default_depth_thresh;
- dlb2->vector_opts_disabled = dlb2_args->vector_opts_disabled;
+ dlb2->vector_opts_enabled = dlb2_args->vector_opts_enabled;
err = dlb2_iface_open(&dlb2->qm_instance, name);
if (err < 0) {
@@ -4538,7 +4538,7 @@ dlb2_parse_params(const char *params,
DLB2_POLL_INTERVAL_ARG,
DLB2_SW_CREDIT_QUANTA_ARG,
DLB2_DEPTH_THRESH_ARG,
-DLB2_VECTOR_OPTS_DISAB_ARG,
+DLB2_VECTOR_OPTS_ENAB_ARG,
NULL };
if (params != NULL && params[0] != '\0') {
@@ -4653,11 +4653,11 @@ dlb2_parse_params(const char *params,
}
ret = rte_kvargs_process(kvlist,
- DLB2_VECTOR_OPTS_DISAB_ARG,
- set_vector_opts_disab,
- &dlb2_args->vector_opts_disabled);
+ DLB2_VECTOR_OPTS_ENAB_ARG,
+ set_vector_opts_enab,
+ &dlb2_args->vector_opts_enabled);
if (ret != 0) {
- DLB2_LOG_ERR("%s: Error parsing vector opts
disabled",
+ DLB2_LOG_ERR("%s: Error parsing vector opts
enabled",
name);
rte_kvargs_free(kvlist);
return ret;
diff --git a/drivers/event/dlb2/dlb2_priv.h b/drivers/event/dlb2/dlb2_priv.h
index b1225af37..bb87072da 100644
--- a/drivers/event/dlb2/dl
Re: [dpdk-dev] [PATCH] doc: announce renaming of rte_ether_hdr fields
On 5/20/2021 5:16 PM, Dmitry Kozlyuk wrote:
> 2021-05-20 17:04 (UTC+0100), Ferruh Yigit:
>> On 5/20/2021 4:50 PM, Dmitry Kozlyuk wrote:
>>> 2021-05-20 16:27 (UTC+0100), Ferruh Yigit:
On 5/20/2021 4:06 PM, Dmitry Kozlyuk wrote:
> 2021-05-20 15:24 (UTC+0100), Ferruh Yigit:
>> On 3/3/2021 10:51 PM, Dmitry Kozlyuk wrote:
> [...]
>>>
>>> It is not mandatory to rename `d_addr`, this is for consistency only.
>>> Naming in `rte_ether_hdr` will also resemble `rte_ipv4/6_hdr`.
>>>
>>> Workaround is to define `struct rte_ether_hdr` in such a away that
>>> it can be used with or without `s_addr` macro (as defined on Windows)
>>> This can be done for Windows only or for all platforms to save space.
>>>
>>> #pragma push_macro("s_addr")
>>> #ifdef s_addr
>>> #undef s_addr
>>> #endif
>>>
>>> struct rte_ether_hdr {
>>> struct rte_ether_addr d_addr; /**< Destination address. */
>>> RTE_STD_C11
>>> union {
>>> struct rte_ether_addr s_addr; /**< Source address. */
>>> struct {
>>> struct rte_ether_addr S_un;
>>> /**< MUST NOT be used directly, only via s_addr */
>>> } S_addr;
>>> /*< MUST NOT be used directly, only via s_addr */
>>> };
>>> uint16_t ether_type; /**< Frame type. */
>>> } __rte_aligned(2);
>>>
>>> #pragma pop_macro("s_addr")
>>>
>>
>> What is the problem with the workaround, why we can't live with it?
>>
>> It requires an order in include files, right?
>
> There's no problem except a tricky structure definition with fields that
> violate DPDK coding rules. It works with any include order.
>
> Will fix typos in v3, thanks.
>
For following case, won't compiler take 's_addr' as macro?
#include
#include
struct rte_ether_hdr eh;
/* eh.s_addr.addr_bytes[0] = 0;
>>>
>>> Yes, it will. The macro will expand to `S_addr.S_un` and compile
>>> successfully.
>>
>> will 'eh.S_addr.S_un.addr_bytes[0] = 0;' compile successfully?
>
> Yes, only it's `S_un.S_addr`, sorry for the typo in my explanation.
> Both code snippets from commit message compile successfully.
>
Ah, I was missing the union on the struct, yes it will build,
And +1 to deprecation notice and clean the "struct rte_ether_hdr" whenever
possible.
>>
>>> In theory, Microsoft can change the definition of `s_addr`, and while I
>>> doubt
>>> they will, it's a valid concern and a reason to remove workaround in 21.11.
>>>
>>
>
[dpdk-dev] [PATCH v2] event/dlb2: make scalar mode dequeue the default
Optimized dequeue using x86 vector instructions was added
in 21.05, but due to limited testing the default has been
changed back to the scalar mode implementation. The vector mode
implementation can be enabled via the devargs option
"vector_opts_enabled=".
Fixes: 000a7b8e7582 ("event/dlb2: optimize dequeue operation")
Signed-off-by: Timothy McDaniel
---
Cc: timothy.mcdan...@intel.com
---
doc/guides/eventdevs/dlb2.rst | 13 +
drivers/event/dlb2/dlb2.c | 24
drivers/event/dlb2/dlb2_priv.h | 6 +++---
3 files changed, 28 insertions(+), 15 deletions(-)
diff --git a/doc/guides/eventdevs/dlb2.rst b/doc/guides/eventdevs/dlb2.rst
index c60c454d6..acdb00587 100644
--- a/doc/guides/eventdevs/dlb2.rst
+++ b/doc/guides/eventdevs/dlb2.rst
@@ -367,3 +367,16 @@ Class of service can be specified in the devargs, as
follows
.. code-block:: console
--vdev=dlb2_event,cos=<0..4>
+
+Use X86 Vector Instructions
+~~~
+
+DLB supports using x86 vector instructions to optimize the data path.
+
+The default mode of operation is to use scalar instructions, but
+the use of vector instructions can be enabled in the devargs, as
+follows
+
+.. code-block:: console
+
+ --allow ea:00.0,vector_opts_enabled=
diff --git a/drivers/event/dlb2/dlb2.c b/drivers/event/dlb2/dlb2.c
index 588c41ee7..0022f65fc 100644
--- a/drivers/event/dlb2/dlb2.c
+++ b/drivers/event/dlb2/dlb2.c
@@ -376,11 +376,11 @@ set_default_depth_thresh(const char *key __rte_unused,
}
static int
-set_vector_opts_disab(const char *key __rte_unused,
+set_vector_opts_enab(const char *key __rte_unused,
const char *value,
void *opaque)
{
- bool *dlb2_vector_opts_disabled = opaque;
+ bool *dlb2_vector_opts_enabled = opaque;
if (value == NULL || opaque == NULL) {
DLB2_LOG_ERR("NULL pointer\n");
@@ -388,9 +388,9 @@ set_vector_opts_disab(const char *key __rte_unused,
}
if ((*value == 'y') || (*value == 'Y'))
- *dlb2_vector_opts_disabled = true;
+ *dlb2_vector_opts_enabled = true;
else
- *dlb2_vector_opts_disabled = false;
+ *dlb2_vector_opts_enabled = false;
return 0;
}
@@ -1469,7 +1469,7 @@ dlb2_hw_create_ldb_port(struct dlb2_eventdev *dlb2,
#else
if ((qm_port->cq_depth > 64) ||
(!rte_is_power_of_2(qm_port->cq_depth)) ||
- (dlb2->vector_opts_disabled == true))
+ (dlb2->vector_opts_enabled == false))
qm_port->use_scalar = true;
#endif
@@ -1665,7 +1665,7 @@ dlb2_hw_create_dir_port(struct dlb2_eventdev *dlb2,
#else
if ((qm_port->cq_depth > 64) ||
(!rte_is_power_of_2(qm_port->cq_depth)) ||
- (dlb2->vector_opts_disabled == true))
+ (dlb2->vector_opts_enabled == false))
qm_port->use_scalar = true;
#endif
@@ -4434,7 +4434,7 @@ dlb2_primary_eventdev_probe(struct rte_eventdev *dev,
dlb2->poll_interval = dlb2_args->poll_interval;
dlb2->sw_credit_quanta = dlb2_args->sw_credit_quanta;
dlb2->default_depth_thresh = dlb2_args->default_depth_thresh;
- dlb2->vector_opts_disabled = dlb2_args->vector_opts_disabled;
+ dlb2->vector_opts_enabled = dlb2_args->vector_opts_enabled;
err = dlb2_iface_open(&dlb2->qm_instance, name);
if (err < 0) {
@@ -4538,7 +4538,7 @@ dlb2_parse_params(const char *params,
DLB2_POLL_INTERVAL_ARG,
DLB2_SW_CREDIT_QUANTA_ARG,
DLB2_DEPTH_THRESH_ARG,
-DLB2_VECTOR_OPTS_DISAB_ARG,
+DLB2_VECTOR_OPTS_ENAB_ARG,
NULL };
if (params != NULL && params[0] != '\0') {
@@ -4653,11 +4653,11 @@ dlb2_parse_params(const char *params,
}
ret = rte_kvargs_process(kvlist,
- DLB2_VECTOR_OPTS_DISAB_ARG,
- set_vector_opts_disab,
- &dlb2_args->vector_opts_disabled);
+ DLB2_VECTOR_OPTS_ENAB_ARG,
+ set_vector_opts_enab,
+ &dlb2_args->vector_opts_enabled);
if (ret != 0) {
- DLB2_LOG_ERR("%s: Error parsing vector opts
disabled",
+ DLB2_LOG_ERR("%s: Error parsing vector opts
enabled",
name);
rte_kvargs_free(kvlist);
return ret;
diff --git a/drivers/event/dlb2/dlb2_priv.h b/drivers/event/dlb2/dlb2_priv.h
index b1225af37..bb87072da 100644
--- a/drivers/event/dlb2/d
[dpdk-dev] [PATCH v3] doc: announce API changes for Windows compatibility
Windows system headers define `s_addr`, `min`, and `max` macros which
break structure definitions containing fields with one of these names.
Undefining those macros would break consumer code that relies on them.
Example 1:
#include
#include
struct in_addr addr;
/* addr.s_addr = 0; ERROR: s_addr undefined by DPDK */
Example 2:
#include
#include
struct rte_ether_hdr eh;
/* eh.s_addr.addr_bytes[0] = 0; ERROR: `addr_s` is a macro */
Commit 6c068dbd9fea ("net: work around s_addr macro on Windows")
modified definition of `struct rte_ether_hdr` to avoid the issue.
However, the workaround assumes `#define s_addr S_addr.S_un`
in Windows headers, which is not a part of official API.
It also complicates the definition of `struct rte_ether_hdr`.
For `min` and `max`, no workaround seems available. If cryptodev or
compressdev is going to be enabled on Windows before 21.11, the only
option seems to use a new name on Windows (using #ifdef).
It is proposed to rename the conflicting fields on DPDK side,
because Win32 API has wider use and is slower and harder to change.
Exact new names are left for further discussion.
Signed-off-by: Dmitry Kozlyuk
Acked-by: Khoa To
---
v3: fix typos (Ferruh), remove naming speculation,
replace workaround snippet with commit reference.
doc/guides/rel_notes/deprecation.rst | 9 +
1 file changed, 9 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst
b/doc/guides/rel_notes/deprecation.rst
index 9584d6bfd7..cc6e8db92c 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -147,3 +147,12 @@ Deprecation Notices
* cmdline: ``cmdline`` structure will be made opaque to hide platform-specific
content. On Linux and FreeBSD, supported prior to DPDK 20.11,
original structure will be kept until DPDK 21.11.
+
+* net: ``s_addr`` and ``d_addr`` fields of ``rte_ether_hdr`` structure
+ will be renamed in DPDK 21.11 to avoid conflict with Windows Sockets headers.
+
+* compressdev: ``min`` and ``max`` fields of ``rte_param_log2_range`` structure
+ will be renamed in DPDK 21.11 to avoid conflict with Windows Sockets headers.
+
+* cryptodev: ``min`` and ``max`` fields of ``rte_crypto_param_range`` structure
+ will be renamed in DPDK 21.11 to avoid conflict with Windows Sockets headers.
--
2.29.3
Re: [dpdk-dev] [EXT] [PATCH v3] doc: announce API changes for Windows compatibility
> Windows system headers define `s_addr`, `min`, and `max` macros which
> break structure definitions containing fields with one of these names.
> Undefining those macros would break consumer code that relies on them.
>
>From the commit message the requirement for changing the structure definitions
Is not clear. Please note that 'min' - 'max' are not macros. These are
variables of a
structure which should not break any other structure/Macro in windows.
> Example 1:
>
> #include
> #include
> struct in_addr addr;
> /* addr.s_addr = 0; ERROR: s_addr undefined by DPDK */
>
> Example 2:
>
> #include
> #include
> struct rte_ether_hdr eh;
> /* eh.s_addr.addr_bytes[0] = 0; ERROR: `addr_s` is a macro */
>
> Commit 6c068dbd9fea ("net: work around s_addr macro on Windows")
> modified definition of `struct rte_ether_hdr` to avoid the issue.
> However, the workaround assumes `#define s_addr S_addr.S_un`
> in Windows headers, which is not a part of official API.
> It also complicates the definition of `struct rte_ether_hdr`.
>
> For `min` and `max`, no workaround seems available. If cryptodev or
> compressdev is going to be enabled on Windows before 21.11, the only
> option seems to use a new name on Windows (using #ifdef).
>
> It is proposed to rename the conflicting fields on DPDK side,
> because Win32 API has wider use and is slower and harder to change.
> Exact new names are left for further discussion.
>
> Signed-off-by: Dmitry Kozlyuk
> Acked-by: Khoa To
> ---
> v3: fix typos (Ferruh), remove naming speculation,
> replace workaround snippet with commit reference.
>
> doc/guides/rel_notes/deprecation.rst | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> index 9584d6bfd7..cc6e8db92c 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -147,3 +147,12 @@ Deprecation Notices
> * cmdline: ``cmdline`` structure will be made opaque to hide platform-
> specific
>content. On Linux and FreeBSD, supported prior to DPDK 20.11,
>original structure will be kept until DPDK 21.11.
> +
> +* net: ``s_addr`` and ``d_addr`` fields of ``rte_ether_hdr`` structure
> + will be renamed in DPDK 21.11 to avoid conflict with Windows Sockets
> headers.
> +
> +* compressdev: ``min`` and ``max`` fields of ``rte_param_log2_range``
> structure
> + will be renamed in DPDK 21.11 to avoid conflict with Windows Sockets
> headers.
> +
> +* cryptodev: ``min`` and ``max`` fields of ``rte_crypto_param_range``
> structure
> + will be renamed in DPDK 21.11 to avoid conflict with Windows Sockets
> headers.
> --
> 2.29.3
Re: [dpdk-dev] [EXT] [PATCH v3] doc: announce API changes for Windows compatibility
2021-05-20 18:59 (UTC+), Akhil Goyal: > > Windows system headers define `s_addr`, `min`, and `max` macros which > > break structure definitions containing fields with one of these names. > > Undefining those macros would break consumer code that relies on them. > > > > From the commit message the requirement for changing the structure definitions > Is not clear. Please note that 'min' - 'max' are not macros. These are > variables of a > structure which should not break any other structure/Macro in windows. Err, yes, that's what the commit message says. Structure fields of course break nothing; they are broken by Windows macros. Would this make more sense? Windows headers define `s_addr`, `min`, and `max` as macros. If DPDK headers are included after Windows ones, DPDK structure definitions containing fields with these names get broken. If DPDK headers undefined these macros, it could break consumer code relying on these macros. It is proposed to rename structure fields in DPDK, because Win32 headers are more widely used and harder to fix.
Re: [dpdk-dev] [PATCH] doc: add GCC 11 and clang 12 support to release notes
On Thu, May 20, 2021 at 4:48 PM Kevin Traynor wrote: > > Note added support for GCC 11 and clang 12 in the > DPDK 21.05 release notes. > > Signed-off-by: Kevin Traynor > > --- > > Note: we need a fix for > https://bugs.dpdk.org/show_bug.cgi?id=714 > > For reference: > $ cat /etc/redhat-release > Fedora release 34 (Thirty Four) > > $ gcc --version > gcc (GCC) 11.1.1 20210428 (Red Hat 11.1.1-1) Reviewed-by: Jerin Jacob Tested on archlinux GCC 11 and arm64 GCC 11. [main][dpdk.org] $ gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc ,obj-c++,d --with-isl --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-g nu-unique-object --enable-install-libiberty --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-libunwind-exceptions --disable-wer ror gdc_include_dir=/usr/include/dlang/gdc Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.1.0 (GCC) [main][dpdk.org] $ aarch64-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=aarch64-linux-gnu-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/11.1.0/lto-wrapper Target: aarch64-linux-gnu Configured with: /build/aarch64-linux-gnu-gcc/src/gcc-11.1.0/configure --prefix=/usr --program-prefix=aarch64-linux-gnu- --with-local-prefix=/usr/aarch64-linux-gnu --with-sysroot=/usr/aarch64-linux-gnu --with-build-sysroot=/usr/aarch64-linu x-gnu --with-native-system-header-dir=/include --libdir=/usr/lib --libexecdir=/usr/lib --target=aarch64-linux-gnu --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-nls --enable-default-pie --enable-languages=c,c++,fortran --e nable-shared --enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enabl e-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib --disable-werror --enable-checking=release Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.1.0 (GCC)
Re: [dpdk-dev] [EXT] [PATCH v3] doc: announce API changes for Windows compatibility
> > 2021-05-20 18:59 (UTC+), Akhil Goyal: > > > Windows system headers define `s_addr`, `min`, and `max` macros which > > > break structure definitions containing fields with one of these names. > > > Undefining those macros would break consumer code that relies on > them. > > > > > > > From the commit message the requirement for changing the structure > definitions > > Is not clear. Please note that 'min' - 'max' are not macros. These are > variables of a > > structure which should not break any other structure/Macro in windows. > > Err, yes, that's what the commit message says. > Structure fields of course break nothing; they are broken by Windows > macros. > Would this make more sense? > > > Windows headers define `s_addr`, `min`, and `max` as macros. > If DPDK headers are included after Windows ones, DPDK structure > definitions containing fields with these names get broken. > If DPDK headers undefined these macros, it could break consumer > code > relying on these macros. It is proposed to rename structure fields > in DPDK, because Win32 headers are more widely used and harder > to fix. Yes it makes more sense now. But ideally it should be fixed in windows. This may be just one such issue, there may be many more. Will this also mean that nobody can define a local variable 'min'? Is this acceptable? Any macro definition in a subsystem should have a prefix to denote that, Just like in DPDK 'RTE_' is added. Macros with generic names should be avoided so that we do not get into these issues. Adding more people for comments. I don't have a good feeling about this change.
[dpdk-dev] [PATCH v2] doc: fix devarg references in DLB2 guide
Convert to PCI "--allow" devarg format. The documentation
was previously using the "--vdev" form, which cannot be used with the
DLB2 PF PMD.
Fixes: 166378a79412 ("event/dlb2: add documentation and build infrastructure")
Cc: sta...@dpdk.org
Signed-off-by: Timothy McDaniel
---
Cc: timothy.mcdan...@intel.com
---
doc/guides/eventdevs/dlb2.rst | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/doc/guides/eventdevs/dlb2.rst b/doc/guides/eventdevs/dlb2.rst
index acdb00587..bce984ca0 100644
--- a/doc/guides/eventdevs/dlb2.rst
+++ b/doc/guides/eventdevs/dlb2.rst
@@ -152,19 +152,19 @@ These pools' sizes are controlled by the nb_events_limit
field in struct
rte_event_dev_config. The load-balanced pool is sized to contain
nb_events_limit credits, and the directed pool is sized to contain
nb_events_limit/4 credits. The directed pool size can be overridden with the
-num_dir_credits vdev argument, like so:
+num_dir_credits devargs argument, like so:
.. code-block:: console
- --vdev=dlb2_event,num_dir_credits=
+ --allow ea:00.0,num_dir_credits=
This can be used if the default allocation is too low or too high for the
-specific application needs. The PMD also supports a vdev arg that limits the
+specific application needs. The PMD also supports a devarg that limits the
max_num_events reported by rte_event_dev_info_get():
.. code-block:: console
- --vdev=dlb2_event,max_num_events=
+ --allow ea:00.0,max_num_events=
By default, max_num_events is reported as the total available load-balanced
credits. If multiple DLB-based applications are being used, it may be desirable
@@ -315,11 +315,11 @@ buffer space (e.g. if not all queues are used, or aren't
used for atomic
scheduling).
The PMD provides a dev arg to override the default per-queue allocation. To
-increase a vdev's per-queue atomic-inflight allocation to (for example) 64:
+increase per-queue atomic-inflight allocation to (for example) 64:
.. code-block:: console
- --vdev=dlb2_event,atm_inflights=64
+ --allow ea:00.0,atm_inflights=64
QID Depth Threshold
~~~
@@ -342,9 +342,9 @@ shown below.
.. code-block:: console
- --vdev=dlb2_event,qid_depth_thresh=all:
- --vdev=dlb2_event,qid_depth_thresh=qidA-qidB:
- --vdev=dlb2_event,qid_depth_thresh=qid:
+ --allow ea:00.0,qid_depth_thresh=all:
+ --allow ea:00.0,qid_depth_thresh=qidA-qidB:
+ --allow ea:00.0,qid_depth_thresh=qid:
Class of service
@@ -366,7 +366,7 @@ Class of service can be specified in the devargs, as follows
.. code-block:: console
- --vdev=dlb2_event,cos=<0..4>
+ --allow ea:00.0,cos=<0..4>
Use X86 Vector Instructions
~~~
@@ -379,4 +379,4 @@ follows
.. code-block:: console
- --allow ea:00.0,vector_opts_enabled=
+ --allow ea:00.0,vector_opts_enabled=
--
2.23.0
Re: [dpdk-dev] [EXT] [PATCH] doc: support IPsec Multi-buffer lib v1.0
20/05/2021 11:31, Akhil Goyal: > > Hi Akhil, > > > > > > Updated AESNI MB and AESNI GCM, KASUMI, ZUC and SNOW3G PMD > > > > documentation guides with information about the latest Intel IPSec > > > > Multi-buffer library supported. > > > > > > > > Signed-off-by: Pablo de Lara > > > > --- > > > > > > Does it need to be updated in release notes as well? > > > Doesn't it need any patch in the code? I did not see any changes. > > > > No code changes are needed, since the API has not changed. > > I haven't added any release notes, as there was not anything changed code > > wise. > > > OK, > Thomas, Can you pick this patch directly on main. Applied, thanks.
Re: [dpdk-dev] [dpdk-stable] [PATCH] test/prefetch: fix build with GCC 11
20/05/2021 16:31, David Marchand:
> On Thu, May 20, 2021 at 1:07 PM Kevin Traynor wrote:
> >
> > GCC 11 complains that 'a' is uninitialized.
> >
> > ../dpdk/app/test/test_prefetch.c: In function 'test_prefetch':
> > ../dpdk/app/test/test_prefetch.c:25:9:
> > error: 'a' may be used uninitialized [-Werror=maybe-uninitialized]
> >25 | rte_prefetch0(&a);
> > | ^
> >
> > Fix by initializing 'a'.
> >
> > Bugzilla ID: 714
> > Fixes: af75078fece3 ("first public release")
> > Cc: sta...@dpdk.org
> >
> > Reported-by: Ali Alnubani
> > Signed-off-by: Kevin Traynor
>
> Reviewed-by: David Marchand
Applied, thanks
Re: [dpdk-dev] [PATCH] doc: add GCC 11 and clang 12 support to release notes
20/05/2021 21:51, Jerin Jacob: > On Thu, May 20, 2021 at 4:48 PM Kevin Traynor wrote: > > > > Note added support for GCC 11 and clang 12 in the > > DPDK 21.05 release notes. > > > > Signed-off-by: Kevin Traynor > > Reviewed-by: Jerin Jacob Applied, thanks
Re: [dpdk-dev] [PATCH v2] devtools: warn about release notes updates
20/05/2021 12:39, David Marchand: > Touching release notes should only be for the current version. > > Signed-off-by: David Marchand Applied, thanks
[dpdk-dev] Question Of binutils-avx512-check
Hi All, I try to build DPDK with debug build-type but the building process is failed becuase of AVX512 code from librte-acl. The release build type is fine. Hence, I dig a bit into the avx512 enabling logic of meson. I found the main logic is implemented inside binutils-avx512-check.sh. It looks the script focus on checking the compatiblity of tools-chain instead of CPUID. My problem is current script will produce avx512 code even I build dpdk on AMD platform. I understand the avx512 code may not be used in runtime. I just wonder why we can not check the cpuid as well ? Regards Liang
Re: [dpdk-dev] [PATCH v6 1/2] config/arm: select most suitable -march for kunpeng soc
>
> On Wed, May 19, 2021 at 6:58 PM Chengwen Feng
> wrote:
> >
> > Currently, the soc_kunpeng930 declares '-march=armv8.2-a+crypto+sve',
> > but some compiler doesn't recognize the march because it doesn't
> > support sve.
> >
> > To solve this bug we use the following scheme:
> > 1. Define 'march_base' tuple which defines support march, it should
> > arrange from lower to higher.
> > e.g. 'march_base': ['-march=armv8.1-a', '-march=armv8.2-a'] 2. Define
> > 'march_feature' tuple which defines support feature.
> > e.g. 'march_feature': ['crypto', 'sve']
> > Note: If user defined 'march_feature', it also needs to define a valid
> > 'march_base' because 'march_feature' depends on 'march_base' when
> > checking validity.
> > 3. Select the most suitable march+feature combination based on
> > 'march_base' and 'march_feature' tuples.
> > 4. Use the selected march+feature combination as the default
> > machine_args.
> >
> > Fixes: 7cf32a22b240 ("config/arm: add Hisilicon kunpeng")
> >
> > Signed-off-by: Chengwen Feng
> > ---
> > config/arm/meson.build | 31 +--
> > 1 file changed, 29 insertions(+), 2 deletions(-)
> >
> > diff --git a/config/arm/meson.build b/config/arm/meson.build index
> > 3f34ec9..044812f 100644
> > --- a/config/arm/meson.build
> > +++ b/config/arm/meson.build
> > @@ -158,7 +158,9 @@ implementer_hisilicon = {
> > ]
> > },
> > '0xd02': {
> > -'machine_args': ['-march=armv8.2-a+crypto+sve'],
> > +'march_base': ['-march=armv8.2-a'],
> > +'march_feature': ['crypto', 'sve'],
> > +'machine_args': [],
>
> IMO, This patch must split into two as this problem is not specific to kunpeng
> patch 1: config/arm: infrastructure to add most suitable -march or so(This
> will
> have only infra) patch 2: config/arm: update the targets to support most
> suitable -march or so(This one will one will have changes for all targets
> including kunpeng)
>
>
>
>
> > 'flags': [
> > ['RTE_MACHINE', '"Kunpeng 930"'],
> > ['RTE_ARM_FEATURE_ATOMICS', true], @@ -449,8 +451,33
> > @@ else
> > # add/overwrite flags in the proper order
> > dpdk_flags = flags_common + implementer_config['flags'] +
> > part_number_config.get('flags', []) + soc_flags
> >
> > +# select the most suitable march+feature combination
> > +machine_march = []
> > +if part_number_config.has_key('march_base')
> > +tmp_machine_march = ''
> > +march_valid = false
> > +foreach march: part_number_config['march_base']
> > +if cc.has_argument(march)
> > +tmp_machine_march = march # Set the higher supported march
> as possible
> > +march_valid = true
> > +endif
> > +endforeach
> > +# select feature only when march valid
> > +if march_valid and
> > + part_number_config.has_key('march_feature')
>
> I think, in order to make more generic, IMO, it should be
> 1) List all the march and features options(crypto, sve)
> 2) Probe the compiler to find the supported march, features
> 3) In each target,
> - define the minimum march and features
I think we should list the max march supported by the target. We can use that
to go back in decreasing order to identify the march the compiler supports.
We would need a list of features between those marchs + any additional features
the target supports. We can probe those features in compiler to add the support
for those features.
I am thinking this will not require us to throw an error.
> - define the the best need march and features
> 4) If the compiler support the best config, pick that else
> 5) If the compiler supports the minimum config, pick that else
> 6) Don't build and throw the error.
>
>
> > +foreach feature: part_number_config['march_feature']
> > +tmp_feature = tmp_machine_march + '+' + feature
> > +if cc.has_argument(tmp_feature)
> > +tmp_machine_march = tmp_feature # Set the more
> > supported
> feature as possible
> > +endif
> > +endforeach
> > +endif
> > +if march_valid
> > +machine_march = [tmp_machine_march]
> > +endif
> > +endif
> > +
> > # apply supported machine args
> > -machine_args = [] # Clear previous machine args
> > +machine_args = machine_march # Init with machine march which set
> > + above
> > foreach flag: part_number_config['machine_args']
> > if cc.has_argument(flag)
> > machine_args += flag
> > --
> > 2.8.1
> >
[dpdk-dev] [PATCH v1] doc: update release notes for 21.05
Fix grammar, spelling and formatting of DPDK 21.05 release notes. Signed-off-by: John McNamara --- doc/guides/rel_notes/release_21_05.rst | 111 +++-- 1 file changed, 49 insertions(+), 62 deletions(-) diff --git a/doc/guides/rel_notes/release_21_05.rst b/doc/guides/rel_notes/release_21_05.rst index c66ab1d6a0..c425845734 100644 --- a/doc/guides/rel_notes/release_21_05.rst +++ b/doc/guides/rel_notes/release_21_05.rst @@ -55,33 +55,33 @@ New Features Also, make sure to start the actual text at the margin. === -* **Added Alpine Linux with musl libc support** +* **Added support for Alpine Linux with musl libc.** - The distribution Alpine Linux, using musl libc and busybox, - got initial support starting with building DPDK without modification. + Added initial support for building DPDK, without modification, on Alpine + Linux using musl libc and busybox. * **Added phase-fair lock.** - Phase-fair lock provides fairness guarantees. + Added support for a Phase-fair lock. This provides fairness guarantees. It has two ticket pools, one for readers and one for writers. * **Added support for Marvell CN10K SoC drivers.** - Added Marvell CN10K SoC support. Marvell CN10K SoC are based on Octeon 10 - family of ARM64 processors with ARM Neoverse N2 core with accelerators for + Added Marvell CN10K SoC support. Marvell CN10K SoCs are based on the Octeon 10 + family of ARM64 processors with the ARM Neoverse N2 core with accelerators for packet processing, timers, cryptography, etc. - * Added common/cnxk driver consisting of common API to be used by -net, crypto and event PMD's. + * Added common/cnxk driver consisting of a common API to be used by +net, crypto and event PMDs. * Added mempool/cnxk driver which provides the support for the integrated mempool device. - * Added event/cnxk driver which provides the support for integrated event + * Added event/cnxk driver which provides the support for the integrated event device. -* **Enhanced ethdev representor syntax.** +* **Added enhanced ethdev representor syntax.** * Introduced representor type of VF, SF and PF. - * Supported sub-function and multi-host in representor syntax:: + * Added support for sub-function and multi-host in representor syntax:: representor=#[0,2-4] /* Legacy VF compatible. */ representor=[[c#]pf#]vf# c1pf2vf3 /* VF 3 on PF 2 of controller 1. */ @@ -90,17 +90,17 @@ New Features * **Added queue state in queried Rx/Tx queue info.** - * Added new field ``queue_state`` to ``rte_eth_rxq_info`` structure to -provide indicated Rx queue state. - * Added new field ``queue_state`` to ``rte_eth_txq_info`` structure to -provide indicated Tx queue state. + * Added new field ``queue_state`` to the ``rte_eth_rxq_info`` structure to +provide the indicated Rx queue state. + * Added new field ``queue_state`` to the ``rte_eth_txq_info`` structure to +provide the indicated Tx queue state. * **Updated meter API.** * Added packet mode in the meter profile parameters data structures to support metering traffic by packet per second (PPS), in addition to the initial bytes per second (BPS) mode (value 0). - * Added support of pre-defined meter policy via flow action list per color. + * Added support for pre-defined meter policy via flow action list per color. * **Added packet integrity match to flow rules.** @@ -116,7 +116,7 @@ New Features The new driver version (v2.3.0) introduced bug fixes and improvements, including: - * Changed memcpy mapping to the dpdk-optimized version. + * Changed memcpy() mapping to the dpdk-optimized version. * Updated ena_com (HAL) to the latest version. * Added indication of the RSS hash presence in the mbuf. @@ -151,10 +151,10 @@ New Features Updated the Intel iavf driver with new features and improvements, including: - * Added flow filter to support GTPU inner L3/L4 fields matching. + * Added flow filter to support GTPU inner L3/L4 field matching. * In AVX512 code, added the new RX and TX paths to use the HW offload features. When the HW offload features are configured to be used, the -offload paths are chosen automatically. In parallel the support of HW +offload paths are chosen automatically. In parallel the support for HW offload features was removed from the legacy AVX512 paths. * **Updated Intel ice driver.** @@ -203,7 +203,8 @@ New Features * **Enabled libpcap-based PMD on Windows.** - A libpcap distribution, such as Npcap or WinPcap, is required to run the PMD. + Enabled libpcap-based PMD support on Windows. + A libpcap distribution, such as Npcap or WinPcap, is required to run the PMD. * **Updated the AF_XDP driver.** @@ -213,24 +214,24 @@ New Features Added packed ring support for async vhost. -* **Added support of multipl
[dpdk-dev] [PATCH v2] doc: update release notes for 21.05
Fix grammar, spelling and formatting of DPDK 21.05 release notes. Signed-off-by: John McNamara --- v2: rebased to main. doc/guides/rel_notes/release_21_05.rst | 111 +++-- 1 file changed, 49 insertions(+), 62 deletions(-) diff --git a/doc/guides/rel_notes/release_21_05.rst b/doc/guides/rel_notes/release_21_05.rst index 5ab7427918..9bd9f416c9 100644 --- a/doc/guides/rel_notes/release_21_05.rst +++ b/doc/guides/rel_notes/release_21_05.rst @@ -59,33 +59,33 @@ New Features Added support for building with GCC 11.1.1 and clang 12.0.0. -* **Added Alpine Linux with musl libc support** +* **Added support for Alpine Linux with musl libc.** - The distribution Alpine Linux, using musl libc and busybox, - got initial support starting with building DPDK without modification. + Added initial support for building DPDK, without modification, on Alpine + Linux using musl libc and busybox. * **Added phase-fair lock.** - Phase-fair lock provides fairness guarantees. + Added support for a Phase-fair lock. This provides fairness guarantees. It has two ticket pools, one for readers and one for writers. * **Added support for Marvell CN10K SoC drivers.** - Added Marvell CN10K SoC support. Marvell CN10K SoC are based on Octeon 10 - family of ARM64 processors with ARM Neoverse N2 core with accelerators for + Added Marvell CN10K SoC support. Marvell CN10K SoCs are based on the Octeon 10 + family of ARM64 processors with the ARM Neoverse N2 core with accelerators for packet processing, timers, cryptography, etc. - * Added common/cnxk driver consisting of common API to be used by -net, crypto and event PMD's. + * Added common/cnxk driver consisting of a common API to be used by +net, crypto and event PMDs. * Added mempool/cnxk driver which provides the support for the integrated mempool device. - * Added event/cnxk driver which provides the support for integrated event + * Added event/cnxk driver which provides the support for the integrated event device. -* **Enhanced ethdev representor syntax.** +* **Added enhanced ethdev representor syntax.** * Introduced representor type of VF, SF and PF. - * Supported sub-function and multi-host in representor syntax:: + * Added support for sub-function and multi-host in representor syntax:: representor=#[0,2-4] /* Legacy VF compatible. */ representor=[[c#]pf#]vf# c1pf2vf3 /* VF 3 on PF 2 of controller 1. */ @@ -94,17 +94,17 @@ New Features * **Added queue state in queried Rx/Tx queue info.** - * Added new field ``queue_state`` to ``rte_eth_rxq_info`` structure to -provide indicated Rx queue state. - * Added new field ``queue_state`` to ``rte_eth_txq_info`` structure to -provide indicated Tx queue state. + * Added new field ``queue_state`` to the ``rte_eth_rxq_info`` structure to +provide the indicated Rx queue state. + * Added new field ``queue_state`` to the ``rte_eth_txq_info`` structure to +provide the indicated Tx queue state. * **Updated meter API.** * Added packet mode in the meter profile parameters data structures to support metering traffic by packet per second (PPS), in addition to the initial bytes per second (BPS) mode (value 0). - * Added support of pre-defined meter policy via flow action list per color. + * Added support for pre-defined meter policy via flow action list per color. * **Added packet integrity match to flow rules.** @@ -120,7 +120,7 @@ New Features The new driver version (v2.3.0) introduced bug fixes and improvements, including: - * Changed memcpy mapping to the dpdk-optimized version. + * Changed memcpy() mapping to the dpdk-optimized version. * Updated ena_com (HAL) to the latest version. * Added indication of the RSS hash presence in the mbuf. @@ -155,10 +155,10 @@ New Features Updated the Intel iavf driver with new features and improvements, including: - * Added flow filter to support GTPU inner L3/L4 fields matching. + * Added flow filter to support GTPU inner L3/L4 field matching. * In AVX512 code, added the new RX and TX paths to use the HW offload features. When the HW offload features are configured to be used, the -offload paths are chosen automatically. In parallel the support of HW +offload paths are chosen automatically. In parallel the support for HW offload features was removed from the legacy AVX512 paths. * **Updated Intel ice driver.** @@ -207,7 +207,8 @@ New Features * **Enabled libpcap-based PMD on Windows.** - A libpcap distribution, such as Npcap or WinPcap, is required to run the PMD. + Enabled libpcap-based PMD support on Windows. + A libpcap distribution, such as Npcap or WinPcap, is required to run the PMD. * **Updated the AF_XDP driver.** @@ -217,24 +218,24 @@ New Features Added packed ring support for async vhost. -* **Added support of multiple data-units in cryptodev API.** +*
[dpdk-dev] [PATCH] ixgbe: Add runtime tx/rx queue setup for X550
X550 eth card support runtime tx/rx queue setup, so add capacity in dev_capa
and queue offload capacity.
Signed-off-by: Wu Jianyue
---
drivers/net/ixgbe/ixgbe_ethdev.c | 22 ++
drivers/net/ixgbe/ixgbe_rxtx.c | 21 +++--
2 files changed, 41 insertions(+), 2 deletions(-)
diff --git drivers/net/ixgbe/ixgbe_ethdev.c drivers/net/ixgbe/ixgbe_ethdev.c
index b5371568b..0839426b4 100644
--- drivers/net/ixgbe/ixgbe_ethdev.c
+++ drivers/net/ixgbe/ixgbe_ethdev.c
@@ -3915,6 +3915,17 @@ ixgbe_dev_info_get(struct rte_eth_dev *dev, struct
rte_eth_dev_info *dev_info)
dev_info->default_rxportconf.ring_size = 256;
dev_info->default_txportconf.ring_size = 256;
+ if (hw->mac.type == ixgbe_mac_X550 ||
+ hw->mac.type == ixgbe_mac_X550EM_x ||
+ hw->mac.type == ixgbe_mac_X550EM_a ||
+ hw->mac.type == ixgbe_mac_X550_vf ||
+ hw->mac.type == ixgbe_mac_X550EM_x_vf ||
+ hw->mac.type == ixgbe_mac_X550EM_a_vf) {
+ dev_info->dev_capa =
+ RTE_ETH_DEV_CAPA_RUNTIME_RX_QUEUE_SETUP |
+ RTE_ETH_DEV_CAPA_RUNTIME_TX_QUEUE_SETUP;
+ }
+
return 0;
}
@@ -4010,6 +4021,17 @@ ixgbevf_dev_info_get(struct rte_eth_dev *dev,
dev_info->rx_desc_lim = rx_desc_lim;
dev_info->tx_desc_lim = tx_desc_lim;
+ if (hw->mac.type == ixgbe_mac_X550 ||
+ hw->mac.type == ixgbe_mac_X550EM_x ||
+ hw->mac.type == ixgbe_mac_X550EM_a ||
+ hw->mac.type == ixgbe_mac_X550_vf ||
+ hw->mac.type == ixgbe_mac_X550EM_x_vf ||
+ hw->mac.type == ixgbe_mac_X550EM_a_vf) {
+ dev_info->dev_capa =
+ RTE_ETH_DEV_CAPA_RUNTIME_RX_QUEUE_SETUP |
+ RTE_ETH_DEV_CAPA_RUNTIME_TX_QUEUE_SETUP;
+ }
+
return 0;
}
diff --git drivers/net/ixgbe/ixgbe_rxtx.c drivers/net/ixgbe/ixgbe_rxtx.c index
d69f36e97..ea813aefe 100644
--- drivers/net/ixgbe/ixgbe_rxtx.c
+++ drivers/net/ixgbe/ixgbe_rxtx.c
@@ -2571,9 +2571,18 @@ ixgbe_set_tx_function(struct rte_eth_dev *dev, struct
ixgbe_tx_queue *txq) uint64_t ixgbe_get_tx_queue_offloads(struct rte_eth_dev
*dev) {
- RTE_SET_USED(dev);
+ uint64_t offloads = 0;
+ struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
- return 0;
+ if (hw->mac.type == ixgbe_mac_X550 ||
+ hw->mac.type == ixgbe_mac_X550EM_x ||
+ hw->mac.type == ixgbe_mac_X550EM_a ||
+ hw->mac.type == ixgbe_mac_X550_vf ||
+ hw->mac.type == ixgbe_mac_X550EM_x_vf ||
+ hw->mac.type == ixgbe_mac_X550EM_a_vf)
+ offloads |= RTE_ETH_DEV_CAPA_RUNTIME_TX_QUEUE_SETUP;
+
+ return offloads;
}
uint64_t
@@ -3008,6 +3017,14 @@ ixgbe_get_rx_queue_offloads(struct rte_eth_dev *dev)
if (hw->mac.type != ixgbe_mac_82598EB)
offloads |= DEV_RX_OFFLOAD_VLAN_STRIP;
+ if (hw->mac.type == ixgbe_mac_X550 ||
+ hw->mac.type == ixgbe_mac_X550EM_x ||
+ hw->mac.type == ixgbe_mac_X550EM_a ||
+ hw->mac.type == ixgbe_mac_X550_vf ||
+ hw->mac.type == ixgbe_mac_X550EM_x_vf ||
+ hw->mac.type == ixgbe_mac_X550EM_a_vf)
+ offloads |= RTE_ETH_DEV_CAPA_RUNTIME_RX_QUEUE_SETUP;
+
return offloads;
}
--
2.17.1
[dpdk-dev] [PATCH] ixgbe: Add runtime tx/rx queue setup for X550
X550 eth card support runtime tx/rx queue setup,
so add capacity in dev_capa and queue offload capacity.
Signed-off-by: Wu Jianyue
---
drivers/net/ixgbe/ixgbe_ethdev.c | 22 ++
drivers/net/ixgbe/ixgbe_rxtx.c | 21 +++--
2 files changed, 41 insertions(+), 2 deletions(-)
diff --git drivers/net/ixgbe/ixgbe_ethdev.c drivers/net/ixgbe/ixgbe_ethdev.c
index b5371568b..0839426b4 100644
--- drivers/net/ixgbe/ixgbe_ethdev.c
+++ drivers/net/ixgbe/ixgbe_ethdev.c
@@ -3915,6 +3915,17 @@ ixgbe_dev_info_get(struct rte_eth_dev *dev, struct
rte_eth_dev_info *dev_info)
dev_info->default_rxportconf.ring_size = 256;
dev_info->default_txportconf.ring_size = 256;
+ if (hw->mac.type == ixgbe_mac_X550 ||
+ hw->mac.type == ixgbe_mac_X550EM_x ||
+ hw->mac.type == ixgbe_mac_X550EM_a ||
+ hw->mac.type == ixgbe_mac_X550_vf ||
+ hw->mac.type == ixgbe_mac_X550EM_x_vf ||
+ hw->mac.type == ixgbe_mac_X550EM_a_vf) {
+ dev_info->dev_capa =
+ RTE_ETH_DEV_CAPA_RUNTIME_RX_QUEUE_SETUP |
+ RTE_ETH_DEV_CAPA_RUNTIME_TX_QUEUE_SETUP;
+ }
+
return 0;
}
@@ -4010,6 +4021,17 @@ ixgbevf_dev_info_get(struct rte_eth_dev *dev,
dev_info->rx_desc_lim = rx_desc_lim;
dev_info->tx_desc_lim = tx_desc_lim;
+ if (hw->mac.type == ixgbe_mac_X550 ||
+ hw->mac.type == ixgbe_mac_X550EM_x ||
+ hw->mac.type == ixgbe_mac_X550EM_a ||
+ hw->mac.type == ixgbe_mac_X550_vf ||
+ hw->mac.type == ixgbe_mac_X550EM_x_vf ||
+ hw->mac.type == ixgbe_mac_X550EM_a_vf) {
+ dev_info->dev_capa =
+ RTE_ETH_DEV_CAPA_RUNTIME_RX_QUEUE_SETUP |
+ RTE_ETH_DEV_CAPA_RUNTIME_TX_QUEUE_SETUP;
+ }
+
return 0;
}
diff --git drivers/net/ixgbe/ixgbe_rxtx.c drivers/net/ixgbe/ixgbe_rxtx.c index
d69f36e97..ea813aefe 100644
--- drivers/net/ixgbe/ixgbe_rxtx.c
+++ drivers/net/ixgbe/ixgbe_rxtx.c
@@ -2571,9 +2571,18 @@ ixgbe_set_tx_function(struct rte_eth_dev *dev, struct
ixgbe_tx_queue *txq) uint64_t ixgbe_get_tx_queue_offloads(struct rte_eth_dev
*dev) {
- RTE_SET_USED(dev);
+ uint64_t offloads = 0;
+ struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
- return 0;
+ if (hw->mac.type == ixgbe_mac_X550 ||
+ hw->mac.type == ixgbe_mac_X550EM_x ||
+ hw->mac.type == ixgbe_mac_X550EM_a ||
+ hw->mac.type == ixgbe_mac_X550_vf ||
+ hw->mac.type == ixgbe_mac_X550EM_x_vf ||
+ hw->mac.type == ixgbe_mac_X550EM_a_vf)
+ offloads |= RTE_ETH_DEV_CAPA_RUNTIME_TX_QUEUE_SETUP;
+
+ return offloads;
}
uint64_t
@@ -3008,6 +3017,14 @@ ixgbe_get_rx_queue_offloads(struct rte_eth_dev *dev)
if (hw->mac.type != ixgbe_mac_82598EB)
offloads |= DEV_RX_OFFLOAD_VLAN_STRIP;
+ if (hw->mac.type == ixgbe_mac_X550 ||
+ hw->mac.type == ixgbe_mac_X550EM_x ||
+ hw->mac.type == ixgbe_mac_X550EM_a ||
+ hw->mac.type == ixgbe_mac_X550_vf ||
+ hw->mac.type == ixgbe_mac_X550EM_x_vf ||
+ hw->mac.type == ixgbe_mac_X550EM_a_vf)
+ offloads |= RTE_ETH_DEV_CAPA_RUNTIME_RX_QUEUE_SETUP;
+
return offloads;
}
--
2.17.1
[dpdk-dev] [PATCH v3] build: fix SVE compile error with gcc8.3
If the target machine has SVE feature (e.g. "-march=armv8.2-a+sve'),
and the compiler are gcc8.3, it will compile error:
In file included from ../dpdk-next-net/lib/eal/common/
eal_common_options.c:38:
../dpdk-next-net/lib/eal/arm/include/rte_vect.h:13:10: fatal
error: arm_sve.h: No such file or directory
#include
^~~
compilation terminated.
The root cause is that gcc8.3 supports SVE (the macro
__ARM_FEATURE_SVE was 1), but it doesn't support SVE ACLE [1].
The solution:
a) Detect compiler whether support SVE ACLE, if support then define
CC_SVE_ACLE_SUPPORT macro.
b) Use the CC_SVE_ACLE_SUPPORT macro to include SVE header file.
[1] ACLE: Arm C Language Extensions, the SVE ACLE header file is
, user should include it when writing ACLE SVE code.
Fixes: 67b68824a82d ("lpm/arm: support SVE")
Signed-off-by: Chengwen Feng
---
v3:
* double-indent 'cc.check_header('arm_sve.h')' line
* move set 'CC_SVE_ACLE_SUPPORT' logic to the back (not in the middle
of compile_time_cpuflags setting)
* fix minor syntax error in commit log
v2:
* modify title start with 'build'
---
config/arm/meson.build | 5 +
lib/eal/arm/include/rte_vect.h | 2 +-
lib/lpm/rte_lpm.h | 2 +-
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/config/arm/meson.build b/config/arm/meson.build
index e83a56e..08299b0 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -488,3 +488,8 @@ if cc.get_define('__ARM_FEATURE_CRYPTO', args:
machine_args) != ''
compile_time_cpuflags += ['RTE_CPUFLAG_AES', 'RTE_CPUFLAG_PMULL',
'RTE_CPUFLAG_SHA1', 'RTE_CPUFLAG_SHA2']
endif
+
+if (cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != '' and
+cc.check_header('arm_sve.h'))
+dpdk_conf.set('CC_SVE_ACLE_SUPPORT', 1)
+endif
diff --git a/lib/eal/arm/include/rte_vect.h b/lib/eal/arm/include/rte_vect.h
index 093e912..277b656 100644
--- a/lib/eal/arm/include/rte_vect.h
+++ b/lib/eal/arm/include/rte_vect.h
@@ -9,7 +9,7 @@
#include "generic/rte_vect.h"
#include "rte_debug.h"
#include "arm_neon.h"
-#ifdef __ARM_FEATURE_SVE
+#ifdef CC_SVE_ACLE_SUPPORT
#include
#endif
diff --git a/lib/lpm/rte_lpm.h b/lib/lpm/rte_lpm.h
index 28b5768..9262814 100644
--- a/lib/lpm/rte_lpm.h
+++ b/lib/lpm/rte_lpm.h
@@ -402,7 +402,7 @@ rte_lpm_lookupx4(const struct rte_lpm *lpm, xmm_t ip,
uint32_t hop[4],
uint32_t defv);
#if defined(RTE_ARCH_ARM)
-#ifdef __ARM_FEATURE_SVE
+#ifdef CC_SVE_ACLE_SUPPORT
#include "rte_lpm_sve.h"
#else
#include "rte_lpm_neon.h"
--
2.8.1
Re: [dpdk-dev] [PATCH v2] build: fix SVE compile error with gcc8.3
Fix in v3, also with minor changes, thanks
On 2021/5/20 21:09, Bruce Richardson wrote:
> On Thu, May 20, 2021 at 07:40:12PM +0800, Chengwen Feng wrote:
>> If the target machine has SVE feature (e.g. "-march=armv8.2-a+sve'),
>> and the compiler is gcc8.3, it will compile error:
>> In file included from ../dpdk-next-net/lib/eal/common/
>> eal_common_options.c:38:
>> ../dpdk-next-net/lib/eal/arm/include/rte_vect.h:13:10: fatal
>> error: arm_sve.h: No such file or directory
>> #include
>> ^~~
>> compilation terminated.
>>
>> The root cause is that gcc8.3 support SVE (the macro __ARM_FEATURE_SVE
>> was 1), but it doesn't support SVE ACLE [1].
>>
>> The solution:
>> a) Detect compiler whether support SVE ACLE, if support then define
>> CC_SVE_ACLE_SUPPORT macro.
>> b) Use the CC_SVE_ACLE_SUPPORT macro to include SVE header file.
>>
>> [1] ACLE: Arm C Language Extensions, the SVE ACLE header file is
>> , user should include it when writing ACLE SVE code.
>>
>> Fixes: 67b68824a82d ("lpm/arm: support SVE")
>>
>> Signed-off-by: Chengwen Feng
>> ---
>> v2:
>> * modify title start with 'build'
>>
>
> One minor comment inline below.
> /Bruce
>> ---
>> config/arm/meson.build | 5 +
>> lib/eal/arm/include/rte_vect.h | 2 +-
>> lib/lpm/rte_lpm.h | 2 +-
>> 3 files changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/config/arm/meson.build b/config/arm/meson.build
>> index e83a56e..bff70e4 100644
>> --- a/config/arm/meson.build
>> +++ b/config/arm/meson.build
>> @@ -480,6 +480,11 @@ if (cc.get_define('__ARM_NEON', args: machine_args) !=
>> '' or
>> compile_time_cpuflags += ['RTE_CPUFLAG_NEON']
>> endif
>>
>> +if (cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != '' and
>> +cc.check_header('arm_sve.h'))
> Please double-indent this line. It looks like part of the condition body
> as-is.
>
>
> .
>
[dpdk-dev] [PATCH v5] crypto/qat: fix uninitialized gcc compiler warning
In Arm platform, when "RTE_ARCH_ARM64_MEMCPY" is set as true, gcc will
report variable uninitialized warning:
../drivers/crypto/qat/qat_sym_session.c: In function ‘partial_hash_compute’:
../lib/eal/include/generic/rte_byteorder.h:241:24: warning:
‘’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
241 | #define rte_bswap32(x) __builtin_bswap32(x)
...
This is because "digest" will be initialized by "rte_memcpy" function
rather than "memcpy" if "RTE_ARCH_ARM64_MEMCPY" is set as true.
Furthermore, 'rte_memcpy' will initialize 'digest' with two steps
by invoking rte_mov_x functions. For example:
partial_hash_sha1 -> rte_memcpy -> rte_memcpy_ge16_lt_128 ->
step 1: rte_mov16(dst,src )
step 2: rte_mov16(dst - 16 + n, src - 16 + n)
However, gcc compiler cannot identify this multi-step initialization,
then it will report warning.
To fix this, use "memset" to initialize "digest".
Fixes: cd7fc8a84b48 ("eal/arm64: optimize memcpy")
Cc: sta...@dpdk.org
Signed-off-by: Feifei Wang
Reviewed-by: Ruifeng Wang
Reviewed-by: Honnappa Nagarahalli
Acked-by: Adam Dybkowski
---
v2: add check and free for memory dynamic allocation (David Marchand)
v3: fix compiler error
v4: use 'memset' to initialize digest (Ferruh, Adam)
v5: fixed spelling errors in commit message (Honnappa)
drivers/crypto/qat/qat_sym_session.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/crypto/qat/qat_sym_session.c
b/drivers/crypto/qat/qat_sym_session.c
index 231b1640da..e22dd3600c 100644
--- a/drivers/crypto/qat/qat_sym_session.c
+++ b/drivers/crypto/qat/qat_sym_session.c
@@ -1196,6 +1196,9 @@ static int partial_hash_compute(enum icp_qat_hw_auth_algo
hash_alg,
uint64_t *hash_state_out_be64;
int i;
+ /* Initialize to avoid gcc warning */
+ memset(digest, 0, sizeof(digest));
+
digest_size = qat_hash_get_digest_size(hash_alg);
if (digest_size <= 0)
return -EFAULT;
--
2.25.1
[dpdk-dev] [PATCH] config/arm: add checking SVE cpuflag
If compiled with SVE feature (e.g. "-march=armv8.2-a+sve'), the binary
could not run on non-SVE platform else it will encounter illegal
instruction [1].
This patch fixes it by add 'RTE_CPUFLAG_SVE' to compile_time_cpuflags,
so that rte_cpu_is_supported() will print meaningful log under above
situation.
[1] http://mails.dpdk.org/archives/dev/2021-May/209124.html
Signed-off-by: Chengwen Feng
---
config/arm/meson.build | 4
1 file changed, 4 insertions(+)
diff --git a/config/arm/meson.build b/config/arm/meson.build
index e83a56e..9b147c0 100644
--- a/config/arm/meson.build
+++ b/config/arm/meson.build
@@ -480,6 +480,10 @@ if (cc.get_define('__ARM_NEON', args: machine_args) != ''
or
compile_time_cpuflags += ['RTE_CPUFLAG_NEON']
endif
+if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
+compile_time_cpuflags += ['RTE_CPUFLAG_SVE']
+endif
+
if cc.get_define('__ARM_FEATURE_CRC32', args: machine_args) != ''
compile_time_cpuflags += ['RTE_CPUFLAG_CRC32']
endif
--
2.8.1
Re: [dpdk-dev] [PATCH v6 2/2] net/hns3: refactor SVE code compile method
> -Original Message-
> From: fengchengwen
> Sent: Thursday, May 20, 2021 6:55 PM
> To: Ruifeng Wang ; tho...@monjalon.net;
> ferruh.yi...@intel.com
> Cc: dev@dpdk.org; jer...@marvell.com; vikto...@rehivetech.com;
> bruce.richard...@intel.com; Honnappa Nagarahalli
> ; jerinjac...@gmail.com;
> juraj.lin...@pantheon.tech; nd
> Subject: Re: [PATCH v6 2/2] net/hns3: refactor SVE code compile method
>
>
>
> On 2021/5/20 16:24, Ruifeng Wang wrote:
> >> -Original Message-
> >> From: Chengwen Feng
> >> Sent: Wednesday, May 19, 2021 9:26 PM
> >> To: tho...@monjalon.net; ferruh.yi...@intel.com
> >> Cc: dev@dpdk.org; jer...@marvell.com; Ruifeng Wang
> >> ; vikto...@rehivetech.com;
> >> bruce.richard...@intel.com; Honnappa Nagarahalli
> >> ; jerinjac...@gmail.com;
> >> juraj.lin...@pantheon.tech; nd
> >> Subject: [PATCH v6 2/2] net/hns3: refactor SVE code compile method
> >>
> >> Currently, the SVE code is compiled only when -march supports SVE
> >> (e.g. '- march=armv8.2a+sve'), there maybe some problem[1] with this
> approach.
> >>
> >> The solution:
> >> a. If the minimum instruction set support SVE then compiles it.
> >> b. Else if the compiler support SVE then compiles it.
> >> c. Otherwise don't compile it.
> >>
> >> [1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
> >>
> >> Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
> >> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
> >> Cc: sta...@dpdk.org
> >>
> >> Signed-off-by: Chengwen Feng
> >> ---
> >> drivers/net/hns3/hns3_rxtx.c | 2 +- drivers/net/hns3/meson.build |
> >> 21 -
> >> 2 files changed, 21 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/net/hns3/hns3_rxtx.c
> >> b/drivers/net/hns3/hns3_rxtx.c index 1d7a769..4ef20c6 100644
> >> --- a/drivers/net/hns3/hns3_rxtx.c
> >> +++ b/drivers/net/hns3/hns3_rxtx.c
> >> @@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
> >> static bool
> >> hns3_get_sve_support(void)
> >> {
> >> -#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
> >> +#if defined(CC_SVE_SUPPORT)
> >>if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
> >>return false;
> >>if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
> >> diff --git a/drivers/net/hns3/meson.build
> >> b/drivers/net/hns3/meson.build index 53c7df7..5f9af9b 100644
> >> --- a/drivers/net/hns3/meson.build
> >> +++ b/drivers/net/hns3/meson.build
> >> @@ -35,7 +35,26 @@ deps += ['hash']
> >>
> >> if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
> >> sources += files('hns3_rxtx_vec.c')
> >> -if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
> >> +
> >> +# compile SVE when:
> >> +# a. support SVE in minimum instruction set baseline
> >> +# b. it's not minimum instruction set, but compiler support
> >> +if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
> >> + and
> >> cc.check_header('arm_sve.h')
> >> +cflags += ['-DCC_SVE_SUPPORT']
> > With SVE build fix patch [1], CC_SVE_ACLE_SUPPORT will be defined.
> > Here we can use CC_SVE_ACLE_SUPPORT and not to add a new one.
> >
>
> The CC_SVE_ACLE_SUPPORT was defined under default machine_args which
> support SVE, it can't deals with the situation: the default machine_args don't
> support SVE but compiler support SVE.
> So the CC_SVE_SUPPORT marco is necessary.
Agree that macro for SVE is also needed here. And we can also use
'-DCC_SVE_ACLE_SUPPORT' here right?
I think there is no difference between CC_SVE_ACLE_SUPPORT and CC_SVE_SUPPORT
when they are used in source code.
IMO the same macro name can be used, and it removes redundancy and confusion.
>
> > [1]
> > http://patches.dpdk.org/project/dpdk/patch/1621495007-28387-1-git-send
> > -email-fengcheng...@huawei.com/
> >
> >> sources += files('hns3_rxtx_vec_sve.c')
> >> +elif cc.has_argument('-march=armv8.2-a+sve') and
> >> cc.check_header('arm_sve.h')
> >> +sve_cflags = ['-DCC_SVE_SUPPORT']
> >> +foreach flag: cflags
> >> +# filterout -march -mcpu -mtune
> >> +if not (flag.startswith('-march=') or
> >> + flag.startswith('-mcpu=') or
> >> flag.startswith('-mtune='))
> >> +sve_cflags += flag
> >> +endif
> >> +endforeach
> >> +hns3_sve_lib = static_library('hns3_sve_lib',
> >> +'hns3_rxtx_vec_sve.c',
> >> +dependencies: [static_rte_ethdev],
> >> +include_directories: includes,
> >> +c_args: [sve_cflags, '-march=armv8.2-a+sve'])
> >> +objs += hns3_sve_lib.extract_objects('hns3_rxtx_vec_sve.c')
> >> endif
> >> endif
> >> --
> >> 2.8.1
> >
> >
> > .
> >
Re: [dpdk-dev] [PATCH v6 2/2] net/hns3: refactor SVE code compile method
On 2021/5/21 13:21, Ruifeng Wang wrote:
>> -Original Message-
>> From: fengchengwen
>> Sent: Thursday, May 20, 2021 6:55 PM
>> To: Ruifeng Wang ; tho...@monjalon.net;
>> ferruh.yi...@intel.com
>> Cc: dev@dpdk.org; jer...@marvell.com; vikto...@rehivetech.com;
>> bruce.richard...@intel.com; Honnappa Nagarahalli
>> ; jerinjac...@gmail.com;
>> juraj.lin...@pantheon.tech; nd
>> Subject: Re: [PATCH v6 2/2] net/hns3: refactor SVE code compile method
>>
>>
>>
>> On 2021/5/20 16:24, Ruifeng Wang wrote:
-Original Message-
From: Chengwen Feng
Sent: Wednesday, May 19, 2021 9:26 PM
To: tho...@monjalon.net; ferruh.yi...@intel.com
Cc: dev@dpdk.org; jer...@marvell.com; Ruifeng Wang
; vikto...@rehivetech.com;
bruce.richard...@intel.com; Honnappa Nagarahalli
; jerinjac...@gmail.com;
juraj.lin...@pantheon.tech; nd
Subject: [PATCH v6 2/2] net/hns3: refactor SVE code compile method
Currently, the SVE code is compiled only when -march supports SVE
(e.g. '- march=armv8.2a+sve'), there maybe some problem[1] with this
>> approach.
The solution:
a. If the minimum instruction set support SVE then compiles it.
b. Else if the compiler support SVE then compiles it.
c. Otherwise don't compile it.
[1] https://mails.dpdk.org/archives/dev/2021-April/208189.html
Fixes: 8c25b02b082a ("net/hns3: fix enabling SVE Rx/Tx")
Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
Cc: sta...@dpdk.org
Signed-off-by: Chengwen Feng
---
drivers/net/hns3/hns3_rxtx.c | 2 +- drivers/net/hns3/meson.build |
21 -
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/net/hns3/hns3_rxtx.c
b/drivers/net/hns3/hns3_rxtx.c index 1d7a769..4ef20c6 100644
--- a/drivers/net/hns3/hns3_rxtx.c
+++ b/drivers/net/hns3/hns3_rxtx.c
@@ -2808,7 +2808,7 @@ hns3_get_default_vec_support(void)
static bool
hns3_get_sve_support(void)
{
-#if defined(RTE_ARCH_ARM64) && defined(__ARM_FEATURE_SVE)
+#if defined(CC_SVE_SUPPORT)
if (rte_vect_get_max_simd_bitwidth() < RTE_VECT_SIMD_256)
return false;
if (rte_cpu_get_flag_enabled(RTE_CPUFLAG_SVE))
diff --git a/drivers/net/hns3/meson.build
b/drivers/net/hns3/meson.build index 53c7df7..5f9af9b 100644
--- a/drivers/net/hns3/meson.build
+++ b/drivers/net/hns3/meson.build
@@ -35,7 +35,26 @@ deps += ['hash']
if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
sources += files('hns3_rxtx_vec.c')
-if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
+
+# compile SVE when:
+# a. support SVE in minimum instruction set baseline
+# b. it's not minimum instruction set, but compiler support
+if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
+ and
cc.check_header('arm_sve.h')
+cflags += ['-DCC_SVE_SUPPORT']
>>> With SVE build fix patch [1], CC_SVE_ACLE_SUPPORT will be defined.
>>> Here we can use CC_SVE_ACLE_SUPPORT and not to add a new one.
>>>
>>
>> The CC_SVE_ACLE_SUPPORT was defined under default machine_args which
>> support SVE, it can't deals with the situation: the default machine_args
>> don't
>> support SVE but compiler support SVE.
>> So the CC_SVE_SUPPORT marco is necessary.
> Agree that macro for SVE is also needed here. And we can also use
> '-DCC_SVE_ACLE_SUPPORT' here right?
> I think there is no difference between CC_SVE_ACLE_SUPPORT and CC_SVE_SUPPORT
> when they are used in source code.
> IMO the same macro name can be used, and it removes redundancy and confusion.
>
You are right, no difference between CC_SVE_ACLE_SUPPORT and CC_SVE_SUPPORT
But the hns3 sve already support 20.11, and CC_SVE_ACLE_SUPPORT was newly
defined,
there maybe some problems when backporting.
Or we could redefine CC_SVE_ACLE_SUPPORT under default machine_args:
if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != '' and
cc.check_header('arm_sve.h')
cflags += ['-DCC_SVE_ACLE_SUPPORT']
sources += files('hns3_rxtx_vec_sve.c')
elif cc.has_argument('-march=armv8.2-a+sve') and
cc.check_header('arm_sve.h')
sve_cflags = ['-DCC_SVE_ACLE_SUPPORT']
foreach flag: cflags
# filterout -march -mcpu -mtune
if not (flag.startswith('-march=') or flag.startswith('-mcpu=') or
flag.startswith('-mtune='))
sve_cflags += flag
endif
endforeach
but this way may introduce coupling, I think.
>>
>>> [1]
>>> http://patches.dpdk.org/project/dpdk/patch/1621495007-28387-1-git-send
>>> -email-fengcheng...@huawei.com/
>>>
sources += files('hns3_rxtx_vec_sve.c')
+elif cc.has_argument('-march=armv8.2-a+sve') and
cc.check_header('arm_sve.h')
+sve_cflags = ['-DCC_SVE_SUPPORT']
+foreach flag: cfl
