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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> 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
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
> 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
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
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
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
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 |
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 |
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
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
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
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
[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
> 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
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:
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:
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
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
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
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_
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
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 |
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
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
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
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
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
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 +++
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
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
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
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
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
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
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
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
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
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
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
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
101 - 183 of 183 matches
Mail list logo