Re: [RFC 2/7] eal: add generic bit manipulation macros

2024-03-04 Thread Tyler Retzlaff
On Sat, Mar 02, 2024 at 02:53:23PM +0100, Mattias Rönnblom wrote: > Add bit-level test/set/clear/assign macros operating on both 32-bit > and 64-bit words by means of C11 generic selection. > > Signed-off-by: Mattias Rönnblom > --- _Generic is nice here. should we discourage direct use of the in

Re: [PATCH v1] doc: fix aging poll frequency devargs information

2024-03-04 Thread Jerin Jacob
On Mon, Mar 4, 2024 at 8:00 PM Ankur Dwivedi wrote: > > The information for CNXK NPC MCAM aging poll frequency devargs is moved to > runtime config options section for ethdev device. Initially it was > incorrectly placed in runtime config options section for inline device. > > Fixes: a44775505911

Re: [PATCH 0/3] TAP device fixes

2024-03-04 Thread Ferruh Yigit
On 2/29/2024 5:31 PM, Stephen Hemminger wrote: > Add myself as maintainer and fix some bugs found while testing. > > Stephen Hemminger (3): > MAINTAINERS: add maintainer for TAP device > net/tap: do not overwrite rte_flow errors > net/tap: compute TC handle correctly > Series applied to dpd

[PATCH v7 01/39] eal: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 00/39] use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 03/39] stack: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 02/39] eal: redefine macro to be integer literal for MSVC

2024-03-04 Thread Tyler Retzlaff
MSVC __declspec(align(#)) is limited and accepts only integer literals as opposed to constant expressions. define XMM_SIZE to be 16 instead of sizeof(xmm_t) and static_assert that sizeof(xmm_t) == 16 for compatibility. Signed-off-by: Tyler Retzlaff Acked-by: Morten Brørup Acked-by: Konstantin An

[PATCH v7 04/39] sched: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 05/39] ring: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 06/39] pipeline: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 07/39] net: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 08/39] mbuf: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 12/39] dmadev: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 11/39] ethdev: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 09/39] hash: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 10/39] eventdev: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 16/39] timer: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 14/39] acl: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 18/39] reorder: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 19/39] regexdev: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 23/39] port: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 13/39] distributor: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 21/39] power: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 27/39] mempool: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 15/39] vhost: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 22/39] rawdev: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 30/39] ipsec: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 26/39] mldev: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 25/39] node: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 33/39] compressdev: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 24/39] pdcp: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 17/39] table: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 20/39] rcu: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 28/39] member: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 35/39] dispatcher: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 37/39] gpudev: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 36/39] fib: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 32/39] bpf: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 39/39] ip_frag: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 38/39] graph: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 29/39] lpm: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 34/39] cryptodev: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

[PATCH v7 31/39] jobstats: use C11 alignas

2024-03-04 Thread Tyler Retzlaff
The current location used for __rte_aligned(a) for alignment of types and variables is not compatible with MSVC. There is only a single location accepted by both toolchains. For variables standard C11 offers alignas(a) supported by conformant compilers i.e. both MSVC and GCC. For types the standa

RE: [PATCH v2 33/71] baseband/acc: replace use of fixed size rte_memcpy

2024-03-04 Thread Chautru, Nicolas
> From: Stephen Hemminger > "Chautru, Nicolas" wrote: > > > Hi Stephen, > > It messed with the indentation, didn't it? > > Thanks > > Nic > > It ended up with the more standard indentation style rather than DPDK special > indent with extra tab. I see a mix of space and tabs and indeed not fol

[PATCH] hash: make gfni stubs inline

2024-03-04 Thread Stephen Hemminger
This reverts commit 07d836e5929d18ad6640ebae90dd2f81a2cafb71. Tyler found build issues with MSVC and the thash gfni stubs. The problem would be link errors from missing symbols. The purpose of the original commit was to allow local definition of RTE_LOGTYPE_HASH. Put the thash gfni back as inline

Re: [PATCH v2] lib/hash: feature reclaim defer queue

2024-03-04 Thread Honnappa Nagarahalli
> On Mar 4, 2024, at 2:27 AM, Abdullah Ömer Yamaç wrote: > > Just one more question. > > On Sun, Mar 3, 2024 at 10:14 PM Honnappa Nagarahalli > wrote: > Hello Abdullah, > Thank you for the patch, few comments inline. > > The short commit log could be changed as follows: > > "lib/ha

[PATCH 0/5] add new meta data module

2024-03-04 Thread Chaoyong He
Extract the related code into a new meta data module, uniform the name format and data endian. Which makes the logic more clear and easier to extend in the future. Long Wu (5): net/nfp: create new meta data module net/nfp: uniform variable name format net/nfp: uniform function name format

[PATCH 1/5] net/nfp: create new meta data module

2024-03-04 Thread Chaoyong He
From: Long Wu Move the Rx meta data code to new 'nfp_net_meta' module, which makes related logic more clean and the code architecture more reasonable. There is no functional change, just moving verbatim code around. Signed-off-by: Long Wu Reviewed-by: Chaoyong He --- drivers/common/nfp/nfp_co

[PATCH 2/5] net/nfp: uniform variable name format

2024-03-04 Thread Chaoyong He
From: Long Wu Uniform variable name format by add the same prefix. Signed-off-by: Long Wu Reviewed-by: Chaoyong He --- drivers/net/nfp/flower/nfp_flower_cmsg.c | 2 +- drivers/net/nfp/flower/nfp_flower_ctrl.c | 2 +- drivers/net/nfp/nfp_net_meta.c | 32 ++-- driver

[PATCH 3/5] net/nfp: uniform function name format

2024-03-04 Thread Chaoyong He
From: Long Wu Uniform function name format and add the same prefix. Signed-off-by: Long Wu Reviewed-by: Chaoyong He --- drivers/net/nfp/nfd3/nfp_nfd3_dp.c | 5 ++-- drivers/net/nfp/nfdk/nfp_nfdk_dp.c | 5 ++-- drivers/net/nfp/nfp_net_common.c | 2 +- drivers/net/nfp/nfp_net_meta.c |

[PATCH 4/5] net/nfp: use flag bits to control parsing meta data

2024-03-04 Thread Chaoyong He
From: Long Wu Use flag bits to indicate whether meta data exists and determine whether it needs to be parsed. Signed-off-by: Long Wu Reviewed-by: Chaoyong He --- drivers/net/nfp/nfp_net_meta.c | 22 ++ drivers/net/nfp/nfp_net_meta.h | 1 - drivers/net/nfp/nfp_rxtx.c |

[PATCH 5/5] net/nfp: use big-endian meta data for packet

2024-03-04 Thread Chaoyong He
From: Long Wu Make sure all kinds of meta data are CPU-endian in process logic and transform them to big-endian when prepend into packet. Signed-off-by: Long Wu Reviewed-by: Chaoyong He --- drivers/net/nfp/nfd3/nfp_nfd3_dp.c | 5 ++--- drivers/net/nfp/nfdk/nfp_nfdk_dp.c | 5 ++--- drivers/net

Re: [PATCH v3] testpmd: add hairpin-map parameter

2024-03-04 Thread Gregory Etelson
Hello Ferruh, As a brainstorm, what do you think move hairpin related code to its own file, and have a kind of register logic to the commands, argument parsing and usage() functions etc. Please consider an option for the testpmd to dynamically add supported commands. Testpmd can still provide som

[PATCH v2] hash: make GFNI stubs inline (again)

2024-03-04 Thread Stephen Hemminger
Tyler found build issues with MSVC and the thash gfni stubs. The problem would be link errors from missing symbols. This version puts back the rte_thash_gfni function stubs as inlines, but instead of logging a message, they panic. This is intentional because any application should be checking with

Re: [PATCH v2] hash: make GFNI stubs inline (again)

2024-03-04 Thread Tyler Retzlaff
On Mon, Mar 04, 2024 at 07:07:24PM -0800, Stephen Hemminger wrote: > Tyler found build issues with MSVC and the thash gfni stubs. > The problem would be link errors from missing symbols. > > This version puts back the rte_thash_gfni function stubs as > inlines, but instead of logging a message, th

RE: [RFC PATCH 1/2] power: refactor core power management library

2024-03-04 Thread Tummala, Sivaprasad
[AMD Official Use Only - General] Hi Lihuisong, > -Original Message- > From: lihuisong (C) > Sent: Friday, March 1, 2024 8:27 AM > To: Tummala, Sivaprasad ; > david.h...@intel.com; anatoly.bura...@intel.com; jer...@marvell.com; > radu.nico...@intel.com; gak...@marvell.com; cristian.dumit

Re: [PATCH v4] crypto/ipsec_mb: unified IPsec MB interface

2024-03-04 Thread Honnappa Nagarahalli
> On Mar 4, 2024, at 1:33 AM, Akhil Goyal wrote: > >>> Hi folks, >>> >>> The introduction of a more unified IPsec MB library for DPDK is causing the >>> snow3g tests to fail on ARM. Artifact here: >>> https://lab.dpdk.org/results/dashboard/patchsets/29315/ >>> PMDs using the direct API (KASUMI

[DPDK/cryptodev Bug 1395] crypto/qat debug build failure with RTE_ENABLE_ASSERT (ICP_QAT_FW_SYM_COMM_ADDR_SGL undeclared)

2024-03-04 Thread bugzilla
https://bugs.dpdk.org/show_bug.cgi?id=1395 Bug ID: 1395 Summary: crypto/qat debug build failure with RTE_ENABLE_ASSERT (ICP_QAT_FW_SYM_COMM_ADDR_SGL undeclared) Product: DPDK Version: 23.11 Hardware: All OS:

[DPDK/meson Bug 1396] Meson fails to run buildtools/get-test-suites.py (unicode decode error)

2024-03-04 Thread bugzilla
https://bugs.dpdk.org/show_bug.cgi?id=1396 Bug ID: 1396 Summary: Meson fails to run buildtools/get-test-suites.py (unicode decode error) Product: DPDK Version: 23.11 Hardware: All OS: All Status:

RFC: Using and renaming 8-bit reserved field of rte_crypto_op for implementation specific

2024-03-04 Thread Kundapura, Ganapati
Hi dpdk-dev, Can 'uint8_t reserved[1]' of 'struct rte_crypto_op' be renamed to 'uint8_t impl_opaque' for implementation specific? An implementation may use this field to hold implementation specific value to share value between dequeue and enqueue operation and crypto library/driver can also u

[PATCH 00/21] Improvements and new test cases

2024-03-04 Thread Aakash Sasidharan
Adding new test cases and improvements to test application. Aakash Sasidharan (7): test/security: enable AES-GCM in combined mode TLS test/security: add TLS 1.2 data walkthrough test test/security: add DTLS 1.2 data walkthrough test test/security: add TLS SG data walkthrough test test/se

[PATCH 01/21] test/security: enable AES-GCM in combined mode TLS

2024-03-04 Thread Aakash Sasidharan
Enable AES-GCM AEAD tests in combined mode TLS test suite. Coverity issue: 414888 Fixes: 9157ccb8f876 ("test/crypto: verify TLS headers") Signed-off-by: Aakash Sasidharan --- app/test/test_cryptodev_security_tls_record.c | 10 -- app/test/test_security_proto.h| 3 +++ 2

[PATCH 02/21] test/security: add TLS 1.2 data walkthrough test

2024-03-04 Thread Aakash Sasidharan
Add data walkthrough test for TLS 1.2. Signed-off-by: Aakash Sasidharan --- app/test/test_cryptodev.c | 90 +-- app/test/test_cryptodev.h | 12 ++- app/test/test_cryptodev_security_tls_record.c | 25 -- app/test/test_cryptodev_security_

[PATCH 04/21] test/security: add TLS SG data walkthrough test

2024-03-04 Thread Aakash Sasidharan
Add multi segment packet data walkthrough test for TLS 1.2 and DTLS 1.2. Signed-off-by: Aakash Sasidharan --- app/test/test_cryptodev.c | 42 +++ app/test/test_cryptodev_security_tls_record.h | 2 +- 2 files changed, 43 insertions(+), 1 deletion(-) diff --gi

[PATCH 05/21] test/security: unit test for TLS packet corruption

2024-03-04 Thread Aakash Sasidharan
From: Vidya Sagar Velumuri Add test to verify the corrupted TLS packet header Signed-off-by: Vidya Sagar Velumuri --- app/test/test_cryptodev.c | 27 +-- app/test/test_cryptodev_security_tls_record.c | 4 +++ app/test/test_cryptodev_security_tls_record.h |

[PATCH 06/21] test/security: unit test for custom content verification

2024-03-04 Thread Aakash Sasidharan
From: Vidya Sagar Velumuri Add unit test to verify the TLS header creation with custom content type Signed-off-by: Vidya Sagar Velumuri --- app/test/test_cryptodev.c | 19 +++ app/test/test_cryptodev_security_tls_record.c | 3 +++ app/test/test_cryptodev_se

[PATCH 07/21] test/cryptodev: allow zero packet length buffers

2024-03-04 Thread Aakash Sasidharan
From: Anoob Joseph The function 'create_segmented_mbuf' is updated to support zero packet length mbufs. This allows testing of zero packet length payload with TLS record processing. Signed-off-by: Anoob Joseph --- app/test/test_cryptodev.h | 20 +++- 1 file changed, 7 insertion

[PATCH 08/21] test/security: unit test to verify zero TLS records

2024-03-04 Thread Aakash Sasidharan
From: Vidya Sagar Velumuri Add unit tests to verify the zero len TLS records. Zero len packets are allowed when content type is app data while zero packet length with other content type (such as handshake) would result in an error. Signed-off-by: Vidya Sagar Velumuri --- app/test/test_cryptode

[PATCH 09/21] test/security: add unit tests for DTLS-1.2

2024-03-04 Thread Aakash Sasidharan
From: Vidya Sagar Velumuri Add unit tests to verify 1. DTLS record with zero length 2. DTLS record with header corruption 3. DTLS record with content type as custom Signed-off-by: Vidya Sagar Velumuri --- app/test/test_cryptodev.c | 77 +++ 1 file changed, 7

[PATCH 03/21] test/security: add DTLS 1.2 data walkthrough test

2024-03-04 Thread Aakash Sasidharan
Add data walkthrough test for DTLS 1.2 Signed-off-by: Aakash Sasidharan --- app/test/test_cryptodev.c | 17 + app/test/test_cryptodev_security_tls_record.c | 5 - 2 files changed, 21 insertions(+), 1 deletion(-) diff --git a/app/test/test_cryptodev.c b/a

[PATCH 10/21] test/security: add TLS/DTLS 1.2 AES-256-SHA384 vectors

2024-03-04 Thread Aakash Sasidharan
From: Akhil Goyal Added vectors for TLS 1.2 and DTLS 1.2 using algos AES-256-CBC and HMAC-SHA384 Signed-off-by: Akhil Goyal --- app/test/test_cryptodev.c | 19 ++ app/test/test_cryptodev_security_tls_record.h | 2 + ...yptodev_security_tls_record_test_vectors.h | 200 +++

[PATCH 11/21] test/security: add DTLS 1.2 anti-replay tests

2024-03-04 Thread Aakash Sasidharan
Add anti-replay test for DTLS 1.2. Signed-off-by: Aakash Sasidharan --- app/test/test_cryptodev.c | 115 ++- app/test/test_cryptodev_security_tls_record.c | 132 ++ app/test/test_cryptodev_security_tls_record.h | 11 +- 3 files changed, 188 insert

[PATCH 12/21] test/security: add more DTLS anti-replay window sz

2024-03-04 Thread Aakash Sasidharan
Add anti-replay tests for window sizes 128, 256, 512, 1024, 2048 and 4096 window sizes in DTLS 1.2 suite. Signed-off-by: Aakash Sasidharan --- app/test/test_cryptodev.c | 72 +-- 1 file changed, 69 insertions(+), 3 deletions(-) diff --git a/app/test/test_cryp

[PATCH 13/21] test/crypto: update verification of header

2024-03-04 Thread Aakash Sasidharan
From: Vidya Sagar Velumuri In TLS 1.3, the version in the header would be TLS 1.2 and the content type would be APP irrespective of the type of the payload. Signed-off-by: Vidya Sagar Velumuri --- app/test/test_cryptodev_security_tls_record.c | 20 +-- 1 file changed, 14 insert

[PATCH 14/21] test/crypto: add TLS 1.3 vectors

2024-03-04 Thread Aakash Sasidharan
From: Akhil Goyal Added vectors and test suite for TLS 1.3 AES-128-GCM, AES-256-GCM and CHACHA20-POLY1305 vectors. The vectors are generated using gnuTLS client server application. Signed-off-by: Akhil Goyal --- app/test/test_cryptodev.c | 35 +++ app/test/test_cryptodev_s

[PATCH 15/21] test/crypto: update framework to verify tls-1.3

2024-03-04 Thread Aakash Sasidharan
From: Vidya Sagar Velumuri Update the fields in preparation of test descriptor. Signed-off-by: Vidya Sagar Velumuri --- app/test/test_cryptodev.c | 17 +--- app/test/test_cryptodev_security_tls_record.c | 43 --- app/test/test_cryptodev_security_tls_reco

[PATCH 16/21] test/crypto: test to verify hdr corruption in TLS

2024-03-04 Thread Aakash Sasidharan
From: Vidya Sagar Velumuri Add unit tests to verify TLS-1.3 record with header corruption. Signed-off-by: Vidya Sagar Velumuri --- app/test/test_cryptodev.c | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptod

[PATCH 17/21] test/crypto: test to verify custom content type in TLS

2024-03-04 Thread Aakash Sasidharan
From: Vidya Sagar Velumuri Add unit tests to verify TLS-1.3 record with content type as custom. Signed-off-by: Vidya Sagar Velumuri --- app/test/test_cryptodev.c | 19 +++ 1 file changed, 19 insertions(+) diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c index

[PATCH 18/21] test/crypto: test to verify zero len record in TLS

2024-03-04 Thread Aakash Sasidharan
From: Vidya Sagar Velumuri Add unit tests to verify TLS-1.3 record with zero length. Signed-off-by: Vidya Sagar Velumuri --- app/test/test_cryptodev.c | 39 +++ 1 file changed, 39 insertions(+) diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptode

[PATCH 19/21] test/crypto: unit tests to verify padding in TLS

2024-03-04 Thread Aakash Sasidharan
From: Vidya Sagar Velumuri Add unit tests to verify the padding for TLS-1.2. Signed-off-by: Vidya Sagar Velumuri --- app/test/test_cryptodev.c | 85 ++- app/test/test_cryptodev_security_tls_record.c | 28 -- app/test/test_cryptodev_security_tls_record.h

[PATCH 20/21] test/crypto: unit tests for padding in DTLS-1.2

2024-03-04 Thread Aakash Sasidharan
From: Vidya Sagar Velumuri Add unit tests to verify the padding for DTLS-1.2. Signed-off-by: Vidya Sagar Velumuri --- app/test/test_cryptodev.c | 60 +++ 1 file changed, 60 insertions(+) diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c ind

[PATCH 21/21] test/security: add out of place sgl test case for TLS 1.2

2024-03-04 Thread Aakash Sasidharan
Add TLS 1.2 out-of-place multi-segmented packet test. Signed-off-by: Aakash Sasidharan --- app/test/test_cryptodev.c | 52 ++- app/test/test_cryptodev_security_tls_record.h | 1 + 2 files changed, 51 insertions(+), 2 deletions(-) diff --git a/app/test/test_c

Re: [PATCH v4 1/7] ethdev: support report register names and filter

2024-03-04 Thread Jie Hai
Hi, Thomas , Thanks for your review. On 2024/2/29 17:52, Thomas Monjalon wrote: 26/02/2024 04:07, Jie Hai: This patch adds "filter" and "names" fields to "rte_dev_reg_info" structure. Names of registers in data fields can be reported and the registers can be filtered by their names. The new AP

<    1   2