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
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
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
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 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 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 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
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: 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
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
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
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
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 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: 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
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: 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 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: 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 |
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
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_
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
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
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
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:
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:
> 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
[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 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
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
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
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
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
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
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
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
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
> 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
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
> 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
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
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
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
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 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 6:10 PM Rahul Bhansali wrote:
>
> With loopback interface and IPsec Inbound traffic, getting
> NIX_CQERRINT_CPT_DROP interrupt and dataflow is stopped.
> This is due to flow control configuration is skipped as
> roc_nix_is_esw() returns true for loopback device also.
>
> Fix
On Sun, Mar 03, 2024 at 07:26:36AM +0100, Mattias Rönnblom wrote:
> On 2024-03-02 18:05, Stephen Hemminger wrote:
> >On Sat, 2 Mar 2024 14:53:22 +0100
> >Mattias Rönnblom wrote:
> >
> >>diff --git a/lib/eal/include/rte_bitops.h b/lib/eal/include/rte_bitops.h
> >>index 449565eeae..9a368724d5 100644
On 2/29/2024 5:31 PM, Stephen Hemminger wrote:
> Add myself as maintainer for TAP device.
>
> Signed-off-by: Stephen Hemminger
>
Acked-by: Ferruh Yigit
On 3/3/2024 9:56 AM, Thomas Monjalon wrote:
> Speed capabilities of a NIC may be discovered through its Linux
> kernel driver. It is especially useful for bifurcated drivers,
> so they don't have to duplicate the same logic in the DPDK driver.
>
> Parsing ethtool speed capabilities is made easy th
On Mon, Mar 04, 2024 at 04:35:41PM +0100, Thomas Monjalon wrote:
> 21/02/2024 11:32, Bruce Richardson:
> > The event vector struct was missing comments on two members, and also
> > was inadvertently creating a local variable called "__rte_aligned" in
> > the doxygen output.
> >
> > Correct the com
On 2024-03-04 09:16, Heng Wang wrote:
Hi Mattias,
I have a comment about the _Generic. What if the user gives uint8_t * or
uint16_t * as the address. One improvement is that we could add a default
branch in _Generic to throw a compiler error or assert false.
If the user pass an incompati
21/02/2024 11:32, Bruce Richardson:
> The event vector struct was missing comments on two members, and also
> was inadvertently creating a local variable called "__rte_aligned" in
> the doxygen output.
>
> Correct the comment markers to fix the former issue, and fix the latter
> by putting "#ifdef
zhoumin writes:
> On Wed, Feb 21, 2024 at 2:24AM, Patrick Robb wrote:
>
> On Tue, Feb 20, 2024 at 1:12 PM Aaron Conole wrote:
>
> Why not something like:
>
> Recheck-request: [attribute-list],[test-list]...
>
> For example, then we can do:
>
> Recheck-request: rebase=[identifier],
>
>
Le lun. 4 mars 2024, 11:36, David Marchand a
écrit :
> From: Maxime Coquelin
>
> VDUSE_DESTROY_DEVICE ioctl can fail because the device's
> chardev is not released despite close syscall having been
> called. It happens because the events handler thread is
> still polling the file descriptor.
>
>
> > On Mar 1, 2024, at 5:16 AM, Morten Brørup
> > wrote:
> >
> >> From: Konstantin Ananyev [mailto:konstantin.anan...@huawei.com]
> >> Sent: Thursday, 22 February 2024 17.16
> >>
> >>> For some reason your email is not visible to me, even though it's in the
> >>> archive.
> >>
> >> No worries.
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 ("net/cnxk: support flow aging")
Cc: sta...@dpdk.org
Signed-off
> >> - Implemented SVE code for comparing signatures in bulk lookup.
> >> - Added Defines in code for SVE code support.
> >> - Optimise NEON code
> >> - New SVE code is ~5% slower than optimized NEON for N2 processor.
> >>
> >> Signed-off-by: Yoan Picchi
> >> Signed-off-by: Harjot Singh
> >> Re
On 3/1/2024 8:42 AM, Chaoyong He wrote:
> Add the necessary logic to get firmware version from firmware file, and
> only reload the firmware when the firmware version changed.
>
> Also add a device argument which can force reload the firmware and
> ignore the firmware version.
>
> ---
> v2:
> * U
https://bugs.dpdk.org/show_bug.cgi?id=1394
Bug ID: 1394
Summary: vq_assert_lock__ fail in vhost_user_set_vring_addr
during live migration with HW vDPA
Product: DPDK
Version: unspecified
Hardware: x86
OS: Lin
On Thu, Feb 29, 2024 at 06:38:47PM +, Bruce Richardson wrote:
> On Mon, Feb 19, 2024 at 09:55:14AM +, Mingjin Ye wrote:
> > Implemented a Tx wrapper to perform a thorough check on mbufs,
> > categorizing and counting invalid cases by types for diagnostic
> > purposes. The count of invalid c
With loopback interface and IPsec Inbound traffic, getting
NIX_CQERRINT_CPT_DROP interrupt and dataflow is stopped.
This is due to flow control configuration is skipped as
roc_nix_is_esw() returns true for loopback device also.
Fixes: 978dc3a13f7b ("common/cnxk: base support for eswitch VF")
Fixes
From: Shai Brandes
Change rte_intr_callback_unregister to its synchronous variant to
ensure all active interrupt callbacks are completed before proceeding
with the flow. Relocate the interrupt deregistration to precede the
release of stats memory, thereby preventing the interrupt handler
from acc
1 - 100 of 183 matches
Mail list logo
