* [PATCH v2 2/6] crypto/uadk: use timing-safe digest comparison
From: Stephen Hemminger @ 2026-06-29 18:59 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger, stable, Siraj Luthfi Ananda, Zongyu Wu,
Zhangfei Gao
In-Reply-To: <20260629190027.2071745-1-stephen@networkplumber.org>
Digest verification used memcmp() to compare the computed and
expected MAC. memcmp() returns as soon as the first differing byte
is found, so its run time depends on how many leading bytes match.
An attacker submitting forged digests can use that timing signal to
recover the correct value one byte at a time.
Use rte_memeq_timingsafe(), whose run time depends only on the
length, for the verify comparison.
Bugzilla ID: 1773
Fixes: aba5b230ca04 ("crypto/uadk: use async mode")
Cc: stable@dpdk.org
Reported-by: Siraj Luthfi Ananda <sirajluthfi@gmail.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
drivers/crypto/uadk/uadk_crypto_pmd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/uadk/uadk_crypto_pmd.c b/drivers/crypto/uadk/uadk_crypto_pmd.c
index 3c4e83e56f..221ad546da 100644
--- a/drivers/crypto/uadk/uadk_crypto_pmd.c
+++ b/drivers/crypto/uadk/uadk_crypto_pmd.c
@@ -1111,8 +1111,8 @@ uadk_crypto_dequeue_burst(void *queue_pair, struct rte_crypto_op **ops,
if (sess->auth.operation == RTE_CRYPTO_AUTH_OP_VERIFY) {
uint8_t *dst = qp->temp_digest[i % BURST_MAX];
- if (memcmp(dst, op->sym->auth.digest.data,
- sess->auth.digest_length) != 0)
+ if (!rte_memeq_timingsafe(dst, op->sym->auth.digest.data,
+ sess->auth.digest_length))
op->status = RTE_CRYPTO_OP_STATUS_AUTH_FAILED;
}
--
2.53.0
^ permalink raw reply related
* [PATCH v2 0/6] crypto: use timing-safe digest comparison
From: Stephen Hemminger @ 2026-06-29 18:59 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger
In-Reply-To: <20260625160200.24170-1-stephen@networkplumber.org>
Timing attacks in DPDK crypto were fixed earlier but
several drivers did not use the new timing safe comparison
operation.
First patch drops the experimental flag off rte_memeq_timingsafe().
The function is a static inline with no exported symbol, no ABI change.
This avoids having to turn on experimental flag in other drivers.
The rest convert the digest verify comparisons in the uadk, ccp,
armv8 and cnxk PMDs.
This problem was reported for several drivers and for those
the Reported-by was added.
v2 - pick up a couple of other memcmp() locations
Stephen Hemminger (6):
eal: take experimental flag off of rte_memeq_timingsafe
crypto/uadk: use timing-safe digest comparison
crypto/ccp: use timing-safe digest comparison
crypto/armv8: use timing-safe digest comparison
crypto/cnxk: use timing-safe digest comparison
crypto/octeontx: use timing-safe RSA signature verification
doc/guides/rel_notes/release_26_07.rst | 4 ++++
drivers/crypto/armv8/rte_armv8_pmd.c | 4 ++--
drivers/crypto/ccp/ccp_crypto.c | 8 ++++----
drivers/crypto/cnxk/cnxk_ae.h | 4 +++-
drivers/crypto/cnxk/cnxk_se.h | 2 +-
drivers/crypto/octeontx/otx_cryptodev_ops.c | 3 ++-
drivers/crypto/uadk/uadk_crypto_pmd.c | 4 ++--
lib/eal/include/rte_memory.h | 4 ----
8 files changed, 18 insertions(+), 15 deletions(-)
--
2.53.0
^ permalink raw reply
* [PATCH v2 3/6] crypto/ccp: use timing-safe digest comparison
From: Stephen Hemminger @ 2026-06-29 18:59 UTC (permalink / raw)
To: dev
Cc: Stephen Hemminger, stable, Siraj Luthfi Ananda, Sunil Uttarwar,
Ravi Kumar
In-Reply-To: <20260629190027.2071745-1-stephen@networkplumber.org>
Both the CPU HMAC verify path and the offload digest verify path
compared the computed and expected MAC with memcmp(), which short
circuits on the first mismatching byte and leaks the number of
matching leading bytes through timing.
Use rte_memeq_timingsafe() for both verify comparisons.
Bugzilla ID: 1773
Fixes: 6c561b03b54c ("crypto/ccp: support CPU based MD5 and SHA2 family")
Fixes: 70f0f8a8d78c ("crypto/ccp: support burst enqueue/dequeue")
Cc: stable@dpdk.org
Reported-by: Siraj Luthfi Ananda <sirajluthfi@gmail.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
drivers/crypto/ccp/ccp_crypto.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/ccp/ccp_crypto.c b/drivers/crypto/ccp/ccp_crypto.c
index 5899d83bae..b07a786d8e 100644
--- a/drivers/crypto/ccp/ccp_crypto.c
+++ b/drivers/crypto/ccp/ccp_crypto.c
@@ -1490,8 +1490,8 @@ static int cpu_crypto_auth(struct ccp_qp *qp,
}
if (sess->auth.op == CCP_AUTH_OP_VERIFY) {
- if (memcmp(dst, op->sym->auth.digest.data,
- sess->auth.digest_length) != 0) {
+ if (!rte_memeq_timingsafe(dst, op->sym->auth.digest.data,
+ sess->auth.digest_length)) {
op->status = RTE_CRYPTO_OP_STATUS_AUTH_FAILED;
} else {
op->status = RTE_CRYPTO_OP_STATUS_SUCCESS;
@@ -2801,8 +2801,8 @@ static inline void ccp_auth_dq_prepare(struct rte_crypto_op *op)
op->status = RTE_CRYPTO_OP_STATUS_SUCCESS;
if (session->auth.op == CCP_AUTH_OP_VERIFY) {
- if (memcmp(addr + offset, digest_data,
- session->auth.digest_length) != 0)
+ if (!rte_memeq_timingsafe(addr + offset, digest_data,
+ session->auth.digest_length))
op->status = RTE_CRYPTO_OP_STATUS_AUTH_FAILED;
} else {
--
2.53.0
^ permalink raw reply related
* [PATCH v2 4/6] crypto/armv8: use timing-safe digest comparison
From: Stephen Hemminger @ 2026-06-29 18:59 UTC (permalink / raw)
To: dev
Cc: Stephen Hemminger, stable, Siraj Luthfi Ananda, Jack Bond-Preston,
Jerin Jacob, Zbigniew Bodek
In-Reply-To: <20260629190027.2071745-1-stephen@networkplumber.org>
The chained-op verify path compared the computed and expected MAC
with memcmp(), whose run time depends on the number of matching
leading bytes and can leak the digest to an attacker submitting
forged values.
Use rte_memeq_timingsafe() for the verify comparison.
Bugzilla ID: 1773
Fixes: 169ca3db550c ("crypto/armv8: add PMD optimized for ARMv8 processors")
Cc: stable@dpdk.org
Reported-by: Siraj Luthfi Ananda <sirajluthfi@gmail.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Jack Bond-Preston <jack.bond-preston@foss.arm.com>
---
drivers/crypto/armv8/rte_armv8_pmd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/armv8/rte_armv8_pmd.c b/drivers/crypto/armv8/rte_armv8_pmd.c
index 320e2d4b3b..a7caac186d 100644
--- a/drivers/crypto/armv8/rte_armv8_pmd.c
+++ b/drivers/crypto/armv8/rte_armv8_pmd.c
@@ -631,8 +631,8 @@ process_armv8_chained_op(struct armv8_crypto_qp *qp, struct rte_crypto_op *op,
op->status = RTE_CRYPTO_OP_STATUS_SUCCESS;
if (sess->auth.operation == RTE_CRYPTO_AUTH_OP_VERIFY) {
- if (memcmp(adst, op->sym->auth.digest.data,
- sess->auth.digest_length) != 0) {
+ if (!rte_memeq_timingsafe(adst, op->sym->auth.digest.data,
+ sess->auth.digest_length)) {
op->status = RTE_CRYPTO_OP_STATUS_AUTH_FAILED;
}
}
--
2.53.0
^ permalink raw reply related
* [PATCH v2 5/6] crypto/cnxk: use timing-safe digest comparison
From: Stephen Hemminger @ 2026-06-29 18:59 UTC (permalink / raw)
To: dev
Cc: Stephen Hemminger, stable, Tejasree Kondoj, Ankur Dwivedi,
Anoob Joseph, Akhil Goyal, Archana Muniganti
In-Reply-To: <20260629190027.2071745-1-stephen@networkplumber.org>
compl_auth_verify() compared the generated and received MAC with
memcmp(), which returns early on the first differing byte and leaks
the number of matching leading bytes through timing.
Use rte_memeq_timingsafe() for the verify comparison.
Bugzilla ID: 1773
Fixes: 786963fdcf3e ("crypto/cnxk: add digest support")
Cc: stable@dpdk.org
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Tejasree Kondoj <ktejasree@marvell.com>
---
drivers/crypto/cnxk/cnxk_ae.h | 4 +++-
drivers/crypto/cnxk/cnxk_se.h | 2 +-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/cnxk/cnxk_ae.h b/drivers/crypto/cnxk/cnxk_ae.h
index 691f9bfce5..f2aa5d5a2e 100644
--- a/drivers/crypto/cnxk/cnxk_ae.h
+++ b/drivers/crypto/cnxk/cnxk_ae.h
@@ -8,6 +8,7 @@
#include <rte_common.h>
#include <rte_crypto_asym.h>
#include <rte_malloc.h>
+#include <rte_memory.h>
#include "roc_ae.h"
#include "roc_re.h"
@@ -1921,7 +1922,8 @@ cnxk_ae_dequeue_rsa_op(struct rte_crypto_op *cop, uint8_t *rptr,
* Offset output data pointer by length field
* (2 bytes) and compare signed data.
*/
- if (memcmp(rptr + 2, rsa->message.data, rsa->message.length))
+ if (!rte_memeq_timingsafe(rptr + 2,
+ rsa->message.data, rsa->message.length))
cop->status = RTE_CRYPTO_OP_STATUS_ERROR;
}
break;
diff --git a/drivers/crypto/cnxk/cnxk_se.h b/drivers/crypto/cnxk/cnxk_se.h
index 09d9d1e0e3..3ed32f7ddd 100644
--- a/drivers/crypto/cnxk/cnxk_se.h
+++ b/drivers/crypto/cnxk/cnxk_se.h
@@ -3362,7 +3362,7 @@ compl_auth_verify(struct rte_crypto_op *op, uint8_t *gen_mac, uint64_t mac_len)
return;
}
- if (memcmp(mac, gen_mac, mac_len))
+ if (!rte_memeq_timingsafe(mac, gen_mac, mac_len))
op->status = RTE_CRYPTO_OP_STATUS_AUTH_FAILED;
else
op->status = RTE_CRYPTO_OP_STATUS_SUCCESS;
--
2.53.0
^ permalink raw reply related
* [PATCH v2 6/6] crypto/octeontx: use timing-safe RSA signature verification
From: Stephen Hemminger @ 2026-06-29 18:59 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger, Anoob Joseph
In-Reply-To: <20260629190027.2071745-1-stephen@networkplumber.org>
Replace memcmp() with rte_memeq_timingsafe() when verifying
RSA signatures to prevent timing-based side-channel attacks.
The comparison at drivers/crypto/octeontx/otx_cryptodev_ops.c:742
is used to verify RSA signed data against expected message content.
Using regular memcmp() for cryptographic verification can leak
information about the compared data through timing differences.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
drivers/crypto/octeontx/otx_cryptodev_ops.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/octeontx/otx_cryptodev_ops.c b/drivers/crypto/octeontx/otx_cryptodev_ops.c
index d6d1b2cea9..40f565cd78 100644
--- a/drivers/crypto/octeontx/otx_cryptodev_ops.c
+++ b/drivers/crypto/octeontx/otx_cryptodev_ops.c
@@ -12,6 +12,7 @@
#include <rte_errno.h>
#include <rte_malloc.h>
#include <rte_mempool.h>
+#include <rte_memory.h>
#include "otx_cryptodev.h"
#include "otx_cryptodev_capabilities.h"
@@ -739,7 +740,7 @@ otx_cpt_asym_rsa_op(struct rte_crypto_op *cop, struct cpt_request_info *req,
}
memcpy(rsa->sign.data, req->rptr, rsa->sign.length);
- if (memcmp(rsa->sign.data, rsa->message.data,
+ if (!rte_memeq_timingsafe(rsa->sign.data, rsa->message.data,
rsa->message.length)) {
CPT_LOG_DP_ERR("RSA verification failed");
cop->status = RTE_CRYPTO_OP_STATUS_ERROR;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v4 0/9] ENETC driver related changes series
From: Stephen Hemminger @ 2026-06-29 19:00 UTC (permalink / raw)
To: Gagandeep Singh; +Cc: dev, hemant.agrawal
In-Reply-To: <20260629051819.989176-1-g.singh@nxp.com>
On Mon, 29 Jun 2026 10:48:10 +0530
Gagandeep Singh <g.singh@nxp.com> wrote:
> V4 changes:
> - Fixed a compilation issue: "txbd may be used uninitialized"
>
> V3 changes:
> - Added documentation for all devargs in enetc4.rst.
> - Fixed kvlist memory leak issue.
>
> V2 changes:
> - Fixed an un-used variable compilation issue reported on fedora:43-gcc-minsize
> - Fixed various AI reported issues:
> - Release notes updated for all new devargs
> - enect4.ini features doc updated for scattered RX.
> - removed Not required RTE_PTYPE_UNKNOWN.
> - Fixed mid-frame mbuf leak in SG case.
> - Enabled SG for enetc4 PF also.
> - move to calloc from rte_zmalloc in parse_txq_prior().
> - added vaidation checks on strdup, strtoul.
> - added NC devargs to use cacheable ops conditionally.
> - removed dead code like bd_base_p etc.
> - Fixed rte_cpu_to_le_16() conversion on flags and combined
> all flags related patches in one patch.
> - Fixed memory leak issue due to TXQ priority patch.
> - There were some false positives, I have ignored them:
> Race condition on flags field:
> clean_tx_ring only touches HW-completed BDs (next_to_clean→hwci),
> never newly-submitted BDs; doorbell hasn't fired yet.
> Missing dcbf in clean_tx_ring:
> DPDK is single-threaded per queue; TX path always overwrites
> flags completely before dcbf.
> TX dcbf granularity with wrap:
> Safe (AI admits it).
> RX refill flush at wrap:
> In-loop dcbf at i & mask == 0 already flushes aligned groups;
> trailing flush only needed for partial groups.
> RX reading before invalidate:
> dccivac precedes the read for every group in the loop
>
> Gagandeep Singh (7):
> net/enetc: fix TX BD structure
> net/enetc: fix queue initialization
> net/enetc: support ESP packet type in packet parsing
> net/enetc: update random MAC generation code
> net/enetc: add option to disable VSI messaging
> net/enetc: add devargs to control VSI-PSI timeout and delay
> net/enetc4: add cacheable BD ring support with SW cache maintenance
>
> Vanshika Shukla (2):
> net/enetc: support scatter-gather
> net/enetc: set user configurable priority to TX rings
>
> doc/guides/nics/enetc4.rst | 62 +++-
> doc/guides/nics/features/enetc4.ini | 1 +
> doc/guides/rel_notes/release_26_07.rst | 10 +
> drivers/net/enetc/base/enetc_hw.h | 13 +-
> drivers/net/enetc/enetc.h | 31 +-
> drivers/net/enetc/enetc4_ethdev.c | 172 ++++++++--
> drivers/net/enetc/enetc4_vf.c | 206 ++++++++++--
> drivers/net/enetc/enetc_ethdev.c | 25 +-
> drivers/net/enetc/enetc_rxtx.c | 430 ++++++++++++++++++++++---
> 9 files changed, 831 insertions(+), 119 deletions(-)
>
Applied to net-next with minor rewording of git commit message
to conform with check-git-log requirements.
^ permalink raw reply
* Re: [PATCH v10 00/23] et/sxe2: added Linkdata sxe2 ethernet driver
From: Stephen Hemminger @ 2026-06-29 19:02 UTC (permalink / raw)
To: liujie5; +Cc: dev
In-Reply-To: <20260627040458.845194-1-liujie5@linkdatatechnology.com>
On Sat, 27 Jun 2026 12:04:58 +0800
liujie5@linkdatatechnology.com wrote:
> From: Jie Liu <liujie5@linkdatatechnology.com>
>
> This patch set implements core functionality for the SXE2 PMD,
> including basic driver framework, data path setup, and advanced
> offload features (VLAN, RSS,TM, PTP etc.).
>
> V10:
> Introduce the 'sxe2_txrx_check_mbuf' helper function to validate
> outgoing mbuf tunnel type flags when RTE_ETHDEV_DEBUG_TX is enabled.
> The function checks that the RTE_MBUF_F_TX_TUNNEL_x flag in mbuf
> ol_flags matches the actual tunnel protocol detected in the packet
> (GTP, VXLAN, VXLAN-GPE, Geneve, GRE, or IPIP).
>
> Jie Liu (23):
> net/sxe2: remove software statistics devargs
> net/sxe2: add Rx framework and packet types callback
> net/sxe2: support AVX512 vectorized path for Rx and Tx
> net/sxe2: add AVX2 vector data path for Rx and Tx
> net/sxe2: add link update callback
> net/sxe2: support L2 filtering and MAC config
> drivers: support RSS feature
> net/sxe2: support TM hierarchy and shaping
> net/sxe2: support IPsec inline protocol offload
> net/sxe2: support statistics and multi-process
> drivers: interrupt handling
> net/sxe2: add NEON vec Rx/Tx burst functions
> drivers: add support for VF representors
> net/sxe2: add support for custom UDP tunnel ports
> net/sxe2: support firmware version reading
> net/sxe2: implement get monitor address
> common/sxe2: add shared SFP module definitions
> net/sxe2: support SFP module info and EEPROM access
> net/sxe2: add mbuf validation in Tx debug mode
> common/sxe2: add callback for memory event handling
> net/sxe2: add private devargs parsing
> net/sxe2: implement private dump info
> net/sxe2: update sxe2 feature matrix docs
>
> doc/guides/nics/features/sxe2.ini | 56 +
> doc/guides/nics/sxe2.rst | 186 ++
> drivers/common/sxe2/sxe2_common.c | 156 ++
> drivers/common/sxe2/sxe2_common.h | 4 +
> drivers/common/sxe2/sxe2_flow_public.h | 633 ++++++
> drivers/common/sxe2/sxe2_ioctl_chnl.c | 178 +-
> drivers/common/sxe2/sxe2_ioctl_chnl_func.h | 18 +
> drivers/common/sxe2/sxe2_msg.h | 118 ++
> drivers/net/sxe2/meson.build | 51 +
> drivers/net/sxe2/sxe2_cmd_chnl.c | 1587 ++++++++++++++-
> drivers/net/sxe2/sxe2_cmd_chnl.h | 139 ++
> drivers/net/sxe2/sxe2_drv_cmd.h | 523 ++++-
> drivers/net/sxe2/sxe2_dump.c | 287 +++
> drivers/net/sxe2/sxe2_dump.h | 12 +
> drivers/net/sxe2/sxe2_ethdev.c | 1496 +++++++++++++-
> drivers/net/sxe2/sxe2_ethdev.h | 111 +-
> drivers/net/sxe2/sxe2_ethdev_repr.c | 609 ++++++
> drivers/net/sxe2/sxe2_ethdev_repr.h | 32 +
> drivers/net/sxe2/sxe2_filter.c | 895 +++++++++
> drivers/net/sxe2/sxe2_filter.h | 100 +
> drivers/net/sxe2/sxe2_flow.c | 1391 +++++++++++++
> drivers/net/sxe2/sxe2_flow.h | 30 +
> drivers/net/sxe2/sxe2_flow_define.h | 144 ++
> drivers/net/sxe2/sxe2_flow_parse_action.c | 1182 +++++++++++
> drivers/net/sxe2/sxe2_flow_parse_action.h | 23 +
> drivers/net/sxe2/sxe2_flow_parse_engine.c | 106 +
> drivers/net/sxe2/sxe2_flow_parse_engine.h | 13 +
> drivers/net/sxe2/sxe2_flow_parse_pattern.c | 1935 ++++++++++++++++++
> drivers/net/sxe2/sxe2_flow_parse_pattern.h | 46 +
> drivers/net/sxe2/sxe2_ipsec.c | 1565 +++++++++++++++
> drivers/net/sxe2/sxe2_ipsec.h | 254 +++
> drivers/net/sxe2/sxe2_irq.c | 1026 ++++++++++
> drivers/net/sxe2/sxe2_irq.h | 25 +
> drivers/net/sxe2/sxe2_mac.c | 530 +++++
> drivers/net/sxe2/sxe2_mac.h | 84 +
> drivers/net/sxe2/sxe2_mp.c | 414 ++++
> drivers/net/sxe2/sxe2_mp.h | 67 +
> drivers/net/sxe2/sxe2_queue.c | 17 +-
> drivers/net/sxe2/sxe2_queue.h | 15 +-
> drivers/net/sxe2/sxe2_rss.c | 584 ++++++
> drivers/net/sxe2/sxe2_rss.h | 81 +
> drivers/net/sxe2/sxe2_rx.c | 93 +-
> drivers/net/sxe2/sxe2_rx.h | 2 +
> drivers/net/sxe2/sxe2_security.c | 335 ++++
> drivers/net/sxe2/sxe2_security.h | 77 +
> drivers/net/sxe2/sxe2_stats.c | 586 ++++++
> drivers/net/sxe2/sxe2_stats.h | 39 +
> drivers/net/sxe2/sxe2_switchdev.c | 332 +++
> drivers/net/sxe2/sxe2_switchdev.h | 33 +
> drivers/net/sxe2/sxe2_tm.c | 1151 +++++++++++
> drivers/net/sxe2/sxe2_tm.h | 76 +
> drivers/net/sxe2/sxe2_tx.c | 7 +
> drivers/net/sxe2/sxe2_txrx.c | 2106 +++++++++++++++++++-
> drivers/net/sxe2/sxe2_txrx.h | 8 +
> drivers/net/sxe2/sxe2_txrx_poll.c | 284 ++-
> drivers/net/sxe2/sxe2_txrx_vec.c | 46 +-
> drivers/net/sxe2/sxe2_txrx_vec.h | 38 +-
> drivers/net/sxe2/sxe2_txrx_vec_avx2.c | 747 +++++++
> drivers/net/sxe2/sxe2_txrx_vec_avx512.c | 867 ++++++++
> drivers/net/sxe2/sxe2_txrx_vec_common.h | 54 +-
> drivers/net/sxe2/sxe2_txrx_vec_neon.c | 689 +++++++
> drivers/net/sxe2/sxe2_txrx_vec_sse.c | 38 +-
> drivers/net/sxe2/sxe2_vsi.c | 146 ++
> drivers/net/sxe2/sxe2_vsi.h | 12 +-
> drivers/net/sxe2/sxe2vf_regs.h | 85 +
> 65 files changed, 24303 insertions(+), 271 deletions(-)
> create mode 100644 drivers/common/sxe2/sxe2_flow_public.h
> create mode 100644 drivers/common/sxe2/sxe2_msg.h
> create mode 100644 drivers/net/sxe2/sxe2_dump.c
> create mode 100644 drivers/net/sxe2/sxe2_dump.h
> create mode 100644 drivers/net/sxe2/sxe2_ethdev_repr.c
> create mode 100644 drivers/net/sxe2/sxe2_ethdev_repr.h
> create mode 100644 drivers/net/sxe2/sxe2_filter.c
> create mode 100644 drivers/net/sxe2/sxe2_filter.h
> create mode 100644 drivers/net/sxe2/sxe2_flow.c
> create mode 100644 drivers/net/sxe2/sxe2_flow.h
> create mode 100644 drivers/net/sxe2/sxe2_flow_define.h
> create mode 100644 drivers/net/sxe2/sxe2_flow_parse_action.c
> create mode 100644 drivers/net/sxe2/sxe2_flow_parse_action.h
> create mode 100644 drivers/net/sxe2/sxe2_flow_parse_engine.c
> create mode 100644 drivers/net/sxe2/sxe2_flow_parse_engine.h
> create mode 100644 drivers/net/sxe2/sxe2_flow_parse_pattern.c
> create mode 100644 drivers/net/sxe2/sxe2_flow_parse_pattern.h
> create mode 100644 drivers/net/sxe2/sxe2_ipsec.c
> create mode 100644 drivers/net/sxe2/sxe2_ipsec.h
> create mode 100644 drivers/net/sxe2/sxe2_irq.c
> create mode 100644 drivers/net/sxe2/sxe2_mac.c
> create mode 100644 drivers/net/sxe2/sxe2_mac.h
> create mode 100644 drivers/net/sxe2/sxe2_mp.c
> create mode 100644 drivers/net/sxe2/sxe2_mp.h
> create mode 100644 drivers/net/sxe2/sxe2_rss.c
> create mode 100644 drivers/net/sxe2/sxe2_rss.h
> create mode 100644 drivers/net/sxe2/sxe2_security.c
> create mode 100644 drivers/net/sxe2/sxe2_security.h
> create mode 100644 drivers/net/sxe2/sxe2_stats.c
> create mode 100644 drivers/net/sxe2/sxe2_stats.h
> create mode 100644 drivers/net/sxe2/sxe2_switchdev.c
> create mode 100644 drivers/net/sxe2/sxe2_switchdev.h
> create mode 100644 drivers/net/sxe2/sxe2_tm.c
> create mode 100644 drivers/net/sxe2/sxe2_tm.h
> create mode 100644 drivers/net/sxe2/sxe2_txrx_vec_avx2.c
> create mode 100644 drivers/net/sxe2/sxe2_txrx_vec_avx512.c
> create mode 100644 drivers/net/sxe2/sxe2_txrx_vec_neon.c
> create mode 100644 drivers/net/sxe2/sxe2vf_regs.h
>
Thanks for being persistent.
Applied to next-net
^ permalink raw reply
* Re: [PATCH] net/af_xdp: add Rx metadata and dynamic timestamping support
From: Joshua Washington @ 2026-06-29 19:10 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Mark Blasko, dev, Ciara Loftus, Maryam Tahhan,
Jasper Tran O'Leary
In-Reply-To: <20260629103804.3d4154bb@phoenix.local>
On Mon, Jun 29, 2026 at 10:38 AM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> On Sun, 28 Jun 2026 17:50:03 -0700
> Mark Blasko <blasko@google.com> wrote:
>
> > In AF_PACKET, the PMD reads the timestamp from socket ring headers
> > because the kernel stack processes the packet and allocates a socket
> > buffer. Since the kernel stack and socket buffer allocation are bypassed
> > in AF_XDP, UMEM frames are given directly to the PMD, which
> > means the kernel never generates these socket headers. Also, it
> > looks like the TAP PMD doesn't support RX timestamps.
> >
> > Since the location of metadata in the UMEM headroom is determined
> > by the XDP program, the current driver implementation is coupled to
> > a specific XDP program layout. As an alternative, we could just
> > plumb the entire metadata headroom to the DPDK application and let
> > the application parse it based on whatever XDP program is in use.
> > That would couple the application and the XDP program, but would
> > at least decouple the driver and the XDP program.
>
>
> Sorry if I was not clear enough before.
> The DPDK PMD provides an abstraction to applications to avoid exposing
> as many details as possible. Whenever possible a PMD should follow
> precedent and implement functions in a manner similar to other drivers.
>
> The method of expressing received timestamps was never well described
> in DPDK documentation. The convention is:
> - A dynamic field in mbuf is used for the timestamp.
> - All drivers using timestamp should register the same field
> using rte_mbuf_dyn_rx_timestamp_register.
> - The mbuf field is filled inside the rx_burst processing.
> - The timestamp dynamic field is a 64 bit unsigned number rolling
> clock value.
> - A PMD providing timestamp, must also define a readclock ethdev dev ops
> so that application can compute the number of ticks in timestamp per
> time interval.
> - A PMD providing timestamp must advertise that in offload flags.
> - Timestamp should only be inserted if the Rx timestamp offload flag
> is set during configuration.
These are all very good points for ensuring an airtight abstraction.
However, I'd like to note that neither of the kernel-bound PMD
interfaces (pcap, AF_PACKET) have support for the `read_clock` op. I
am not certain of the reason for this, but I suspect it's because
ethtool IOCTLs already cover that functionality. This patch's
implementation follows the other implementations pretty closely,
differing only in how the timestamp is extracted.
>
> When I read this was a little confused about meta data in mbuf.
> Would have been clearer with a simple helper:
>
> static inline void
> af_xdp_rx_timestamp(struct rte_mbuf *m)
> {
> const struct af_xdp_rx_metadata *meta
> = rte_pktmbuf_mtod_offset(m, struct af_xdp_rx_metadata, -(int)sizeof(*meta));
>
> *RTE_MBUF_DYNFIELD(m, timestamp_dynfield_offset, uint64_t *) = meta->rx_timestamp;
> m->ol_flags |= timestamp_dynflag;
> }
>
> If you are going to do Rx timestamp then a simple readclock ethdev op
> is also needed to tell the application what the units are.
>
> But there are bigger issues with this patch:
> 1. The patch assumes metadata is always present in XDP receive but device
> used by XDP may not implement it. There is no capability checking.
> The DPDK PMD ends up advertising RTE_ETH_RX_OFFLOAD_TIMESTAMP
> unconditionally even if underling kernel device doesn't do it.
The patch as submitted is incorrect; my apologies for that. I missed
it in review. The layout of XDP metadata is something which is
determined by the XDP program and consumed by an AF_XDP application
tailor-made for the XDP program. This means that the PMD itself would
not be able to process the RX timestamp from an XDP program on its
own; that functionality would have to be handled by the DPDK
application.
>
> 2. The format of metadata is not a documented contract between kernel
> device implementing XDP and the DPDK.
This is true. The contract lies between the XDP program and the AF_XDP
application, which can both be controlled by the DPDK application and
its invocation.
>
> 3. The XDP documentation says you need to check for metadata
> in each frame.
>
> 4. There are no head bounds checks; must check that there is
> packet headroom is configured with enough space for metadata.
>
> I am sure AI will find several more things but need fixing
> before ready to merge.
>
Unfortunately, I think that some amount of abstraction leakage is
unavoidable by the very nature of AF_XDP. What I propose is as
follows:
Introduce a new PMD capability for processing XDP metadata. The mbuf
dyn_fields can store a pointer to the metadata and the size of the
metadata. The DPDK application processes the metadata as it sees fit.
As mentioned before, both the reader and the writer of the XDP
metadata are both controllable, and this would add the flexiblity for
one to use pre-existing DPDK mbuf infrastructure with minor
modifications to support this functionality, rather than introducing a
full rewrite using an AF_XDP application.
Would this be acceptable?
^ permalink raw reply
* Re: [PATCH] net/af_xdp: add Rx metadata and dynamic timestamping support
From: Stephen Hemminger @ 2026-06-29 20:02 UTC (permalink / raw)
To: Joshua Washington
Cc: Mark Blasko, dev, Ciara Loftus, Maryam Tahhan,
Jasper Tran O'Leary
In-Reply-To: <CALuQH+W4wPA5ygZ63pcQrCD-Uz_K1AsN9n+fzX+ESarmaHnmrA@mail.gmail.com>
On Mon, 29 Jun 2026 12:10:27 -0700
Joshua Washington <joshwash@google.com> wrote:
> These are all very good points for ensuring an airtight abstraction.
> However, I'd like to note that neither of the kernel-bound PMD
> interfaces (pcap, AF_PACKET) have support for the `read_clock` op. I
> am not certain of the reason for this, but I suspect it's because
> ethtool IOCTLs already cover that functionality. This patch's
> implementation follows the other implementations pretty closely,
> differing only in how the timestamp is extracted.
Yes, that needs to be fixed :-)
^ permalink raw reply
* Re: [PATCH] net/af_xdp: add Rx metadata and dynamic timestamping support
From: Stephen Hemminger @ 2026-06-29 20:03 UTC (permalink / raw)
To: Joshua Washington
Cc: Mark Blasko, dev, Ciara Loftus, Maryam Tahhan,
Jasper Tran O'Leary
In-Reply-To: <CALuQH+W4wPA5ygZ63pcQrCD-Uz_K1AsN9n+fzX+ESarmaHnmrA@mail.gmail.com>
On Mon, 29 Jun 2026 12:10:27 -0700
Joshua Washington <joshwash@google.com> wrote:
> On Mon, Jun 29, 2026 at 10:38 AM Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> >
> > On Sun, 28 Jun 2026 17:50:03 -0700
> > Mark Blasko <blasko@google.com> wrote:
> >
> > > In AF_PACKET, the PMD reads the timestamp from socket ring headers
> > > because the kernel stack processes the packet and allocates a socket
> > > buffer. Since the kernel stack and socket buffer allocation are bypassed
> > > in AF_XDP, UMEM frames are given directly to the PMD, which
> > > means the kernel never generates these socket headers. Also, it
> > > looks like the TAP PMD doesn't support RX timestamps.
> > >
> > > Since the location of metadata in the UMEM headroom is determined
> > > by the XDP program, the current driver implementation is coupled to
> > > a specific XDP program layout. As an alternative, we could just
> > > plumb the entire metadata headroom to the DPDK application and let
> > > the application parse it based on whatever XDP program is in use.
> > > That would couple the application and the XDP program, but would
> > > at least decouple the driver and the XDP program.
> >
> >
> > Sorry if I was not clear enough before.
> > The DPDK PMD provides an abstraction to applications to avoid exposing
> > as many details as possible. Whenever possible a PMD should follow
> > precedent and implement functions in a manner similar to other drivers.
> >
> > The method of expressing received timestamps was never well described
> > in DPDK documentation. The convention is:
> > - A dynamic field in mbuf is used for the timestamp.
> > - All drivers using timestamp should register the same field
> > using rte_mbuf_dyn_rx_timestamp_register.
> > - The mbuf field is filled inside the rx_burst processing.
> > - The timestamp dynamic field is a 64 bit unsigned number rolling
> > clock value.
> > - A PMD providing timestamp, must also define a readclock ethdev dev ops
> > so that application can compute the number of ticks in timestamp per
> > time interval.
> > - A PMD providing timestamp must advertise that in offload flags.
> > - Timestamp should only be inserted if the Rx timestamp offload flag
> > is set during configuration.
>
> These are all very good points for ensuring an airtight abstraction.
> However, I'd like to note that neither of the kernel-bound PMD
> interfaces (pcap, AF_PACKET) have support for the `read_clock` op. I
> am not certain of the reason for this, but I suspect it's because
> ethtool IOCTLs already cover that functionality. This patch's
> implementation follows the other implementations pretty closely,
> differing only in how the timestamp is extracted.
>
> >
> > When I read this was a little confused about meta data in mbuf.
> > Would have been clearer with a simple helper:
> >
> > static inline void
> > af_xdp_rx_timestamp(struct rte_mbuf *m)
> > {
> > const struct af_xdp_rx_metadata *meta
> > = rte_pktmbuf_mtod_offset(m, struct af_xdp_rx_metadata, -(int)sizeof(*meta));
> >
> > *RTE_MBUF_DYNFIELD(m, timestamp_dynfield_offset, uint64_t *) = meta->rx_timestamp;
> > m->ol_flags |= timestamp_dynflag;
> > }
> >
> > If you are going to do Rx timestamp then a simple readclock ethdev op
> > is also needed to tell the application what the units are.
> >
> > But there are bigger issues with this patch:
> > 1. The patch assumes metadata is always present in XDP receive but device
> > used by XDP may not implement it. There is no capability checking.
> > The DPDK PMD ends up advertising RTE_ETH_RX_OFFLOAD_TIMESTAMP
> > unconditionally even if underling kernel device doesn't do it.
>
> The patch as submitted is incorrect; my apologies for that. I missed
> it in review. The layout of XDP metadata is something which is
> determined by the XDP program and consumed by an AF_XDP application
> tailor-made for the XDP program. This means that the PMD itself would
> not be able to process the RX timestamp from an XDP program on its
> own; that functionality would have to be handled by the DPDK
> application.
>
> >
> > 2. The format of metadata is not a documented contract between kernel
> > device implementing XDP and the DPDK.
>
> This is true. The contract lies between the XDP program and the AF_XDP
> application, which can both be controlled by the DPDK application and
> its invocation.
>
> >
> > 3. The XDP documentation says you need to check for metadata
> > in each frame.
> >
> > 4. There are no head bounds checks; must check that there is
> > packet headroom is configured with enough space for metadata.
> >
> > I am sure AI will find several more things but need fixing
> > before ready to merge.
> >
>
> Unfortunately, I think that some amount of abstraction leakage is
> unavoidable by the very nature of AF_XDP. What I propose is as
> follows:
>
> Introduce a new PMD capability for processing XDP metadata. The mbuf
> dyn_fields can store a pointer to the metadata and the size of the
> metadata. The DPDK application processes the metadata as it sees fit.
> As mentioned before, both the reader and the writer of the XDP
> metadata are both controllable, and this would add the flexiblity for
> one to use pre-existing DPDK mbuf infrastructure with minor
> modifications to support this functionality, rather than introducing a
> full rewrite using an AF_XDP application.
>
> Would this be acceptable?
There needs to be an API that XDP PMD can call to check if underlying
driver will add metadata; and another API to check that buffer has
valid timestamp
^ permalink raw reply
* Re: [PATCH v3] dts: update dts check format script and resolve errors
From: Patrick Robb @ 2026-06-29 22:37 UTC (permalink / raw)
To: Koushik Bhargav Nimoji; +Cc: luca.vizzarro, dev, abailey, ahassick, lylavoie
In-Reply-To: <20260625172233.2288663-1-knimoji@iol.unh.edu>
[-- Attachment #1: Type: text/plain, Size: 2304 bytes --]
In the UNH jenkins repo, please read the jenkinsfile for running the
dts-check-format script, check which image it is pulling, and check how it
meets dependencies. I can't remember if the dependencies are met at runtime
or build time, or even if it uses poetry or not. So, there is a risk that
the checks in CI could continue to run with older dependency versions even
after this patch hits main. Let me know if you have questions.
On Thu, Jun 25, 2026 at 1:22 PM Koushik Bhargav Nimoji <knimoji@iol.unh.edu>
wrote:
>
>
> +Tar_modes: TypeAlias = Literal["w:gz", "w:bz2", "w:xz", "w:tar"]
> +
>
Should this be tar_modes (snake case)?
>
> def expand_range(range_str: str) -> list[int]:
> """Process `range_str` into a list of integers.
> @@ -154,7 +156,11 @@ def extension(self) -> str:
> For other compression formats, the extension will be in the format
> 'tar.{compression format}'.
> """
> - return f"{self.value}" if self == self.none else
> f"{type(self).none.value}.{self.value}"
> + return (
> + f"{self.value}"
> + if self == self.none
> + else f"{TarCompressionFormat.none.value}.{self.value}"
> + )
>
>
> def convert_to_list_of_string(value: Any | list[Any]) -> list[str]:
> @@ -207,7 +213,8 @@ def filter_func(tarinfo: tarfile.TarInfo) ->
> tarfile.TarInfo | None:
> return None
>
> target_tarball_path =
> dir_path.with_suffix(f".{compress_format.extension}")
> - with tarfile.open(target_tarball_path, f"w:{compress_format.value}")
> as tar:
> + tarball_mode = cast(Tar_modes, f"w:{compress_format.value}")
> + with tarfile.open(target_tarball_path, tarball_mode) as tar:
>
Have you completed a testrun which flexes create_tarball(), i.e. running a
DTS testrun which copies over a normal DPDK dir (instead of defining a
tarball in test_run.yaml you define a normal dpdk dir source) to the SUT,
i.e. it actually has to create the tarball?
> tar.add(dir_path, arcname=dir_path.name,
> filter=create_filter_function(exclude))
>
>
Thanks, let me know about the questions above but the patch looks good.
I'll do a testrun and then merge to next-dts.
Reviewed-by: Patrick Robb <patrickrobb1997@gmail.com>
[-- Attachment #2: Type: text/html, Size: 3375 bytes --]
^ permalink raw reply
* [DPDK/ethdev Bug 1960] Many PMD's provide receive timestamp but are missing the read_clock ethdev operation
From: bugzilla @ 2026-06-30 0:02 UTC (permalink / raw)
To: dev
http://bugs.dpdk.org/show_bug.cgi?id=1960
Bug ID: 1960
Summary: Many PMD's provide receive timestamp but are missing
the read_clock ethdev operation
Product: DPDK
Version: 22.03
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: ethdev
Assignee: dev@dpdk.org
Reporter: stephen@networkplumber.org
Target Milestone: ---
The implementation of receive timestamp is inconsistent in DPDK.
If a driver advertises RX timestamp offload it must also have the facility to
tell application what units that timestamp is in. Some searching showed.
Summary
You're absolutely right - many DPDK drivers that advertise
RTE_ETH_RX_OFFLOAD_TIMESTAMP capability don't implement the
read_clock ethdev operation properly. Here's the breakdown:
Drivers with PROPER implementation (have both timestamp support and
read_clock):
- cnxk - Marvell OCTEON
- mlx5 - Mellanox/NVIDIA
- pcap - Software pcap driver
- intel/e1000 (igb, igc) - Intel 1G NICs
- intel/ice - Intel E810 NICs
Drivers MISSING read_clock implementation despite supporting timestamps:
- af_packet - Linux AF_PACKET
- ark - Atomic Rules Arkville
- bnxt - Broadcom NetXtreme
- dpaa2 - NXP DPAA2
- ena - Amazon ENA
- failsafe - Fail-safe PMD
- hns3 - Huawei HiSilicon
- nfb - Cesnet NFB
- sxe2 - Wangxun SXE2000
- xsc - Yunsilicon XSC
- intel/cpfl - Intel Infrastructure Processing Unit
- intel/iavf - Intel Adaptive Virtual Function
- intel/idpf - Intel Infrastructure Data Path Function
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [DPDK/ethdev Bug 1961] Rx timestamp no rollover indication
From: bugzilla @ 2026-06-30 0:19 UTC (permalink / raw)
To: dev
http://bugs.dpdk.org/show_bug.cgi?id=1961
Bug ID: 1961
Summary: Rx timestamp no rollover indication
Product: DPDK
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: enhancement
Priority: Normal
Component: ethdev
Assignee: dev@dpdk.org
Reporter: stephen@networkplumber.org
Target Milestone: ---
Each PMD has its own internal hardware counter for receive timestamps. But this
counter can and will roll over so using it for things like packet capture is
impossible with current API's. Need something more complete and richer than
existing read_clock API.
AI analysis showed:
The Rollover Problem
Hardware timestamps typically use a fixed-width counter that wraps around:
- 32-bit counter at 1GHz = rollover every ~4.3 seconds
- 40-bit counter at 1GHz = rollover every ~18 minutes
- 48-bit counter at 1GHz = rollover every ~3.3 days
Without knowing the counter width, you can't detect or handle rollovers
correctly!
Current API Limitations
The read_clock operation only returns:
int rte_eth_read_clock(uint16_t port_id, uint64_t *clock);
This doesn't tell you:
1. Counter bit width - Is it 32, 40, 48, or 64 bits?
2. Rollover period - How often does it wrap?
3. Clock frequency - Needed to calculate rollover time
4. Timestamp format - Raw counter vs scaled nanoseconds
What's Needed for Robust Packet Capture
struct rte_eth_timestamp_info {
uint64_t frequency_hz; /* Clock frequency */
uint8_t counter_bits; /* Actual counter width (32/40/48/64) */
uint64_t rollover_nsec; /* Rollover period in nanoseconds */
uint64_t current_value; /* Current counter reading */
enum {
RTE_TS_FORMAT_RAW_COUNTER,
RTE_TS_FORMAT_NANOSECONDS,
RTE_TS_FORMAT_PTP_TIME
} format;
};
Real-World Impact on Packet Capture
Without rollover information, packet capture tools face impossible choices:
Problem 1: Undetected Rollover
/* Packet 1: timestamp = 0xFFFFFFF0 (near max for 32-bit) */
/* Packet 2: timestamp = 0x00000010 (rolled over) */
/* Without knowing it's 32-bit, this looks like time went backwards! */
Problem 2: Incorrect Delta Calculation
/* If you assume 64-bit but it's actually 40-bit: */
delta = pkt2_ts - pkt1_ts; /* Huge negative or wrong positive value */
Problem 3: Can't Maintain Absolute Time
/* Need to track rollovers to maintain wall-clock correlation: */
absolute_time = (rollover_count * rollover_period) + current_timestamp;
/* But without knowing rollover_period, this is impossible */
Specific Driver Issues
Looking at actual implementations:
- Intel E810 (ice): 40-bit counter @ 812.5MHz = ~22 minute rollover
- Intel 700 series (i40e/iavf): 48-bit counter, but what frequency?
- Mellanox: Various counter widths depending on firmware
- Broadcom: Often 48-bit, but frequency varies
None of this is exposed through the API!
Proposed API Enhancement
/* Better API for timestamp capabilities */
int rte_eth_timestamp_info_get(uint16_t port_id,
struct rte_eth_timestamp_info *info);
/* Helper to handle rollover */
uint64_t rte_eth_timestamp_normalize(uint16_t port_id,
uint64_t hw_timestamp,
uint64_t *rollover_count);
This would let packet capture tools:
1. Detect and handle rollovers correctly
2. Maintain accurate absolute timestamps across rollovers
3. Generate proper pcap timestamps even for long captures
4. Warn users about rollover limitations
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH] net/af_xdp: add Rx metadata and dynamic timestamping support
From: Joshua Washington @ 2026-06-30 0:41 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Mark Blasko, dev, Ciara Loftus, Maryam Tahhan,
Jasper Tran O'Leary
In-Reply-To: <20260629130330.2bd6a3cf@phoenix.local>
On Mon, Jun 29, 2026 at 1:03 PM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> On Mon, 29 Jun 2026 12:10:27 -0700
> Joshua Washington <joshwash@google.com> wrote:
>
> > On Mon, Jun 29, 2026 at 10:38 AM Stephen Hemminger
> > <stephen@networkplumber.org> wrote:
> > >
> > > On Sun, 28 Jun 2026 17:50:03 -0700
> > > Mark Blasko <blasko@google.com> wrote:
> > >
> > > > In AF_PACKET, the PMD reads the timestamp from socket ring headers
> > > > because the kernel stack processes the packet and allocates a socket
> > > > buffer. Since the kernel stack and socket buffer allocation are bypassed
> > > > in AF_XDP, UMEM frames are given directly to the PMD, which
> > > > means the kernel never generates these socket headers. Also, it
> > > > looks like the TAP PMD doesn't support RX timestamps.
> > > >
> > > > Since the location of metadata in the UMEM headroom is determined
> > > > by the XDP program, the current driver implementation is coupled to
> > > > a specific XDP program layout. As an alternative, we could just
> > > > plumb the entire metadata headroom to the DPDK application and let
> > > > the application parse it based on whatever XDP program is in use.
> > > > That would couple the application and the XDP program, but would
> > > > at least decouple the driver and the XDP program.
> > >
> > >
> > > Sorry if I was not clear enough before.
> > > The DPDK PMD provides an abstraction to applications to avoid exposing
> > > as many details as possible. Whenever possible a PMD should follow
> > > precedent and implement functions in a manner similar to other drivers.
> > >
> > > The method of expressing received timestamps was never well described
> > > in DPDK documentation. The convention is:
> > > - A dynamic field in mbuf is used for the timestamp.
> > > - All drivers using timestamp should register the same field
> > > using rte_mbuf_dyn_rx_timestamp_register.
> > > - The mbuf field is filled inside the rx_burst processing.
> > > - The timestamp dynamic field is a 64 bit unsigned number rolling
> > > clock value.
> > > - A PMD providing timestamp, must also define a readclock ethdev dev ops
> > > so that application can compute the number of ticks in timestamp per
> > > time interval.
> > > - A PMD providing timestamp must advertise that in offload flags.
> > > - Timestamp should only be inserted if the Rx timestamp offload flag
> > > is set during configuration.
> >
> > These are all very good points for ensuring an airtight abstraction.
> > However, I'd like to note that neither of the kernel-bound PMD
> > interfaces (pcap, AF_PACKET) have support for the `read_clock` op. I
> > am not certain of the reason for this, but I suspect it's because
> > ethtool IOCTLs already cover that functionality. This patch's
> > implementation follows the other implementations pretty closely,
> > differing only in how the timestamp is extracted.
> >
> > >
> > > When I read this was a little confused about meta data in mbuf.
> > > Would have been clearer with a simple helper:
> > >
> > > static inline void
> > > af_xdp_rx_timestamp(struct rte_mbuf *m)
> > > {
> > > const struct af_xdp_rx_metadata *meta
> > > = rte_pktmbuf_mtod_offset(m, struct af_xdp_rx_metadata, -(int)sizeof(*meta));
> > >
> > > *RTE_MBUF_DYNFIELD(m, timestamp_dynfield_offset, uint64_t *) = meta->rx_timestamp;
> > > m->ol_flags |= timestamp_dynflag;
> > > }
> > >
> > > If you are going to do Rx timestamp then a simple readclock ethdev op
> > > is also needed to tell the application what the units are.
> > >
> > > But there are bigger issues with this patch:
> > > 1. The patch assumes metadata is always present in XDP receive but device
> > > used by XDP may not implement it. There is no capability checking.
> > > The DPDK PMD ends up advertising RTE_ETH_RX_OFFLOAD_TIMESTAMP
> > > unconditionally even if underling kernel device doesn't do it.
> >
> > The patch as submitted is incorrect; my apologies for that. I missed
> > it in review. The layout of XDP metadata is something which is
> > determined by the XDP program and consumed by an AF_XDP application
> > tailor-made for the XDP program. This means that the PMD itself would
> > not be able to process the RX timestamp from an XDP program on its
> > own; that functionality would have to be handled by the DPDK
> > application.
> >
> > >
> > > 2. The format of metadata is not a documented contract between kernel
> > > device implementing XDP and the DPDK.
> >
> > This is true. The contract lies between the XDP program and the AF_XDP
> > application, which can both be controlled by the DPDK application and
> > its invocation.
> >
> > >
> > > 3. The XDP documentation says you need to check for metadata
> > > in each frame.
> > >
> > > 4. There are no head bounds checks; must check that there is
> > > packet headroom is configured with enough space for metadata.
> > >
> > > I am sure AI will find several more things but need fixing
> > > before ready to merge.
> > >
> >
> > Unfortunately, I think that some amount of abstraction leakage is
> > unavoidable by the very nature of AF_XDP. What I propose is as
> > follows:
> >
> > Introduce a new PMD capability for processing XDP metadata. The mbuf
> > dyn_fields can store a pointer to the metadata and the size of the
> > metadata. The DPDK application processes the metadata as it sees fit.
> > As mentioned before, both the reader and the writer of the XDP
> > metadata are both controllable, and this would add the flexiblity for
> > one to use pre-existing DPDK mbuf infrastructure with minor
> > modifications to support this functionality, rather than introducing a
> > full rewrite using an AF_XDP application.
> >
> > Would this be acceptable?
>
> There needs to be an API that XDP PMD can call to check if underlying
> driver will add metadata; and another API to check that buffer has
> valid timestamp
I don't think the API to check if the driver has metadata support
exists, unfortunately. bpf_xdp_adjust_meta() is used to by XDP
programs to adjust the metadata pointer on a packet.
If xdp_md->data_meta > xdp_md->data then metadata isn't supported, and
the adjust call will fail. Otherwise, drivers have up to 256B of
metadata. What this means for the PMD is that it can read data_meta
and data pointers to decide if the metadata is valid on a per-packet
basis, and pass the metadata to the application when appropriate.
We were thinking to implement this via the vdev parameters passed in
as part of invoking the application. This solution would introduce
three new parameters:
1. `xdp_meta_valid_hint_offset` (byte offset of RX validity flag(s))
2. `xdp_meta_rx_ts_valid_mask` (mask to read if the RX timesamp is
valid. Mask covers a single byte.)
3. `xdp_meta_rx_ts_offset` (offset of RX timestamp in XDP metadata. RX
timestamp is assumed to be 8 bytes by kernel convention.)
modeled after xdp_metadata.h in the kernel. This solution would be
quite verbose, so I'm open to suggested improvements. If the valid
mask/hint offset are not passed in the invocation parameters, the
timestamp would be assumed valid if the metadata is valid and has
enough bytes available to feasibly read the timestamp value at the
intended offset.
^ permalink raw reply
* RE: [PATCH 1/6] ip_frag: tolerate duplicate fragments
From: Konstantin Ananyev @ 2026-06-30 8:08 UTC (permalink / raw)
To: Stephen Hemminger, dev@dpdk.org; +Cc: stable@dpdk.org, Samyak Jain
In-Reply-To: <20260616210656.464062-2-stephen@networkplumber.org>
> The reassembly code tracked only a running byte total and reserved slots
> for the first and last fragments, with no check for a fragment
> duplicating data already received. A single duplicate could destroy a
> recoverable datagram:
> - a duplicate first or last fragment collided with the reserved slot and
> sent the whole entry down the error path, freeing every collected
> fragment;
> - a duplicate intermediate fragment was appended to a new slot, inflating
> frag_size past total_size so reassembly never completed.
>
> RFC 791 reassembly tolerates duplicates: a fragment covering bytes
> already present carries no new information. Check for an exact duplicate
> (stored fragment with the same offset and length) and drop only that
> mbuf, before frag_size is updated, leaving the entry's accounting
> unchanged.
>
> Overlapping fragments with differing bounds are a separate issue
> addressed in the next patch.
>
> Fixes: cc8f4d020c0b ("examples/ip_reassembly: initial import")
> Cc: stable@dpdk.org
I am not sure it is a bug and needs to be propagated into the stable releases.
To me it is more like feature improvement.
BTW, as this and next patch does change the behavior and probably overall
performance numbers, - it probably worth to add a line in the release notes.
As another thought - it might be squashed with next patch in the series
(ip_frag: discard datagrams with overlapping fragments).
Apart from that:
Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
> Reported-by: Samyak Jain <samyak.jain@amantyatech.com>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> lib/ip_frag/ip_frag_internal.c | 18 +++++++++++++++++-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/lib/ip_frag/ip_frag_internal.c b/lib/ip_frag/ip_frag_internal.c
> index 382f42d0e1..9a03ef995a 100644
> --- a/lib/ip_frag/ip_frag_internal.c
> +++ b/lib/ip_frag/ip_frag_internal.c
> @@ -89,7 +89,23 @@ struct rte_mbuf *
> ip_frag_process(struct ip_frag_pkt *fp, struct rte_ip_frag_death_row *dr,
> struct rte_mbuf *mb, uint16_t ofs, uint16_t len, uint16_t more_frags)
> {
> - uint32_t idx;
> + uint32_t i, idx;
> +
> + /*
> + * Discard an exact duplicate fragment. If a previously stored fragment
> + * already covers the same offset and length, this fragment carries no
> + * new data. Reassembly is tolerant of duplicates (RFC 791), so drop
> + * only this mbuf and keep the reassembly entry intact rather than
> + * treating it as an error. Fragments overlapping an existing one with
> + * different bounds are not handled here.
> + */
> + for (i = 0; i != fp->last_idx; i++) {
> + if (fp->frags[i].mb != NULL && fp->frags[i].ofs == ofs &&
> + fp->frags[i].len == len) {
> + IP_FRAG_MBUF2DR(dr, mb);
> + return NULL;
> + }
> + }
>
> fp->frag_size += len;
>
> --
> 2.53.0
^ permalink raw reply
* RE: [PATCH 2/6] ip_frag: discard datagrams with overlapping fragments
From: Konstantin Ananyev @ 2026-06-30 8:16 UTC (permalink / raw)
To: Stephen Hemminger, dev@dpdk.org; +Cc: stable@dpdk.org
In-Reply-To: <20260616210656.464062-3-stephen@networkplumber.org>
> Existing code does not handle overlapping fragments.
>
> RFC 8200 (IPv6) requires that on overlap all reassembly is abandoned
> andall received fragments are dropped. RFC 791 (IPv4) originally called
> fortrimming and rewriting, but Linux discards for IPv4 as well, since
> overlap has no legitimate use and is a known attack vector.
Spaces are missing in a few places in the sentence above:
'andall' . "fortrimming'.
>
> Depends on the duplicate-tolerance change so that an exact duplicate is
> dropped on its own rather than discarding the whole datagram.
>
> Fixes: cc8f4d020c0b ("examples/ip_reassembly: initial import")
> Cc: stable@dpdk.org
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> lib/ip_frag/ip_frag_internal.c | 34 ++++++++++++++++++++++++++--------
> 1 file changed, 26 insertions(+), 8 deletions(-)
>
> diff --git a/lib/ip_frag/ip_frag_internal.c b/lib/ip_frag/ip_frag_internal.c
> index 9a03ef995a..2505314a29 100644
> --- a/lib/ip_frag/ip_frag_internal.c
> +++ b/lib/ip_frag/ip_frag_internal.c
> @@ -92,16 +92,34 @@ ip_frag_process(struct ip_frag_pkt *fp, struct
> rte_ip_frag_death_row *dr,
> uint32_t i, idx;
>
> /*
> - * Discard an exact duplicate fragment. If a previously stored fragment
> - * already covers the same offset and length, this fragment carries no
> - * new data. Reassembly is tolerant of duplicates (RFC 791), so drop
> - * only this mbuf and keep the reassembly entry intact rather than
> - * treating it as an error. Fragments overlapping an existing one with
> - * different bounds are not handled here.
> + * Scan the fragments already collected for this datagram before
> + * storing the new one. The stored set is kept free of duplicates and
> + * overlaps, so a single pass is sufficient.
> */
> for (i = 0; i != fp->last_idx; i++) {
> - if (fp->frags[i].mb != NULL && fp->frags[i].ofs == ofs &&
> - fp->frags[i].len == len) {
> + if (fp->frags[i].mb == NULL)
> + continue;
> +
> + /*
> + * Exact duplicate: carries no new data. Reassembly tolerates
> + * duplicates (RFC 791), so drop only this mbuf and keep the
> + * entry.
> + */
> + if (fp->frags[i].ofs == ofs && fp->frags[i].len == len) {
> + IP_FRAG_MBUF2DR(dr, mb);
> + return NULL;
> + }
> +
> + /*
> + * Overlap with an existing fragment. Per RFC 8200 section 4.5
> + * (and RFC 5722) the datagram must be discarded; the same is
> + * applied to IPv4. Free all collected fragments, drop this one,
> + * and invalidate the entry.
> + */
> + if (ofs < fp->frags[i].ofs + fp->frags[i].len &&
> + fp->frags[i].ofs < ofs + len) {
> + ip_frag_free(fp, dr);
> + ip_frag_key_invalidate(&fp->key);
> IP_FRAG_MBUF2DR(dr, mb);
> return NULL;
Usually that function does some logging IP_FRAG_LOG(...) in case
invalid fragments were detected (see function body below these changes).
Probably worth to keep same here:
Might be a new helper function that will report an error and free table entry,
that can be used across all places in that function.
Apart from that:
Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
> }
> --
> 2.53.0
^ permalink raw reply
* RE: [PATCH 3/6] ip_frag: include protocol in IPv4 reassembly key
From: Konstantin Ananyev @ 2026-06-30 8:17 UTC (permalink / raw)
To: Stephen Hemminger, dev@dpdk.org; +Cc: stable@dpdk.org
In-Reply-To: <20260616210656.464062-4-stephen@networkplumber.org>
> DPDK IPv4 reassembly code was not following RFC 791 section 3.2
> which says:
> The internet identification field (ID) is used together with the
> source and destination address, and the protocol fields, to identify
> datagram fragments for reassembly.
>
> Omitting the protocol means two datagrams between the
> same pair of hosts that share an IP id but carry different protocols
> (for example UDP and ICMP) are merged into a single reassembly context,
> producing a corrupted datagram.
>
> Fold the protocol into the unused upper bits of the 32-bit id field
> of the key. The IPv4 identification is 16 bits and occupies the low
> half, so the protocol can be carried in the upper bits without changing
> the key layout, the key comparison or the hash.
>
> Fixes: cc8f4d020c0b ("examples/ip_reassembly: initial import")
> Cc: stable@dpdk.org
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> lib/ip_frag/rte_ipv4_reassembly.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/lib/ip_frag/rte_ipv4_reassembly.c b/lib/ip_frag/rte_ipv4_reassembly.c
> index 3c8ae113ba..980f7a3b77 100644
> --- a/lib/ip_frag/rte_ipv4_reassembly.c
> +++ b/lib/ip_frag/rte_ipv4_reassembly.c
> @@ -111,9 +111,15 @@ rte_ipv4_frag_reassemble_packet(struct rte_ip_frag_tbl
> *tbl,
> ip_ofs = (uint16_t)(flag_offset & RTE_IPV4_HDR_OFFSET_MASK);
> ip_flag = (uint16_t)(flag_offset & RTE_IPV4_HDR_MF_FLAG);
>
> + /*
> + * RFC 791 requires using: source, destination, identifier field and
> protocol
> + */
> +
> /* use first 8 bytes only */
> memcpy(&key.src_dst[0], &ip_hdr->src_addr, 8);
> - key.id = ip_hdr->packet_id;
> +
> + /* packet_id is 16 bits and proto id is 8 bits */
> + key.id = ((uint32_t) ip_hdr->next_proto_id << 16) | ip_hdr->packet_id;
> key.key_len = IPV4_KEYLEN;
>
> ip_ofs *= RTE_IPV4_HDR_OFFSET_UNITS;
> --
Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
> 2.53.0
^ permalink raw reply
* Re: [PATCH v2 04/17] crypto/scheduler: replace strncpy with strlcpy
From: Ji, Kai @ 2026-06-30 8:56 UTC (permalink / raw)
To: Richardson, Bruce, dev@dpdk.org
Cc: stable@dpdk.org, Fan Zhang, De Lara Guarch, Pablo
In-Reply-To: <20260624103658.792750-5-bruce.richardson@intel.com>
[-- Attachment #1: Type: text/plain, Size: 2045 bytes --]
Acked-by: Kai Ji <kai.ji@intel.com>
________________________________
From: Richardson, Bruce <bruce.richardson@intel.com>
Sent: 24 June 2026 18:36
To: dev@dpdk.org <dev@dpdk.org>
Cc: Richardson, Bruce <bruce.richardson@intel.com>; stable@dpdk.org <stable@dpdk.org>; Ji, Kai <kai.ji@intel.com>; Fan Zhang <fanzhang.oss@gmail.com>; De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
Subject: [PATCH v2 04/17] crypto/scheduler: replace strncpy with strlcpy
Replace strncpy() with safer strlcpy() which always null-terminates.
Fixes: 50e14527b9d1 ("crypto/scheduler: improve parameters parsing")
Cc: stable@dpdk.org
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
drivers/crypto/scheduler/scheduler_pmd.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/scheduler/scheduler_pmd.c b/drivers/crypto/scheduler/scheduler_pmd.c
index 95ce893f05..ceaefa329b 100644
--- a/drivers/crypto/scheduler/scheduler_pmd.c
+++ b/drivers/crypto/scheduler/scheduler_pmd.c
@@ -229,10 +229,10 @@ cryptodev_scheduler_create(const char *name,
return -ENOMEM;
}
- strncpy(sched_ctx->init_worker_names[
+ strlcpy(sched_ctx->init_worker_names[
sched_ctx->nb_init_workers],
init_params->worker_names[i],
- RTE_CRYPTODEV_SCHEDULER_NAME_MAX_LEN - 1);
+ RTE_CRYPTODEV_SCHEDULER_NAME_MAX_LEN);
sched_ctx->nb_init_workers++;
}
@@ -443,8 +443,8 @@ parse_worker_arg(const char *key __rte_unused,
return -ENOMEM;
}
- strncpy(param->worker_names[param->nb_workers++], value,
- RTE_CRYPTODEV_SCHEDULER_NAME_MAX_LEN - 1);
+ strlcpy(param->worker_names[param->nb_workers++], value,
+ RTE_CRYPTODEV_SCHEDULER_NAME_MAX_LEN);
return 0;
}
--
2.53.0
[-- Attachment #2: Type: text/html, Size: 4616 bytes --]
^ permalink raw reply related
* [RFC] doc: updating doxy-api-index.md and doxy-api.conf.in
From: Marat Khalili @ 2026-06-30 9:03 UTC (permalink / raw)
To: dev@dpdk.org
I noticed that a few header files contain docstring-like comments but are not
present in doc/api/doxy-api-index.md and/or (fewer) in doc/api/doxy-api.conf.in
There seem to be no checks anywhere in the process that would make sure these
index files are updated. Do we even care, or is it unsupported legacy? If we do
care, would a check or an automatic generation fix be more promising?
With Best Regards,
Marat
^ permalink raw reply
* RE: [PATCH 4/6] ip_frag: drop IPv6 fragments with unexpected headers
From: Konstantin Ananyev @ 2026-06-30 9:21 UTC (permalink / raw)
To: Stephen Hemminger, dev@dpdk.org
Cc: stable@dpdk.org, Anatoly Burakov, Thomas Monjalon
In-Reply-To: <20260616210656.464062-5-stephen@networkplumber.org>
> DPDK version of IPv6 reassembly only handles a fragment header placed
> directly after the IPv6 header. With other extension headers in the
> unfragmentable part, ipv6_frag_reassemble() patches the wrong
> next-header field, miscomputes the payload length, and shifts the
> wrong bytes, corrupting the result.
>
> Drop the fragment when l3_len covers more than the IPv6 and fragment
> headers. RFC 8200 allows a receiver to discard packets whose extension
> headers are not in the recommended order, and RFC 9099 recommends
> dropping non-conforming fragmented IPv6 packets, so dropping here is
> permitted rather than a deviation.
>
> Fixes: 4f1a8f633862 ("ip_frag: add IPv6 reassembly")
> Cc: stable@dpdk.org
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> lib/ip_frag/rte_ipv6_reassembly.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/lib/ip_frag/rte_ipv6_reassembly.c b/lib/ip_frag/rte_ipv6_reassembly.c
> index 0e809a01e5..7c1659002b 100644
> --- a/lib/ip_frag/rte_ipv6_reassembly.c
> +++ b/lib/ip_frag/rte_ipv6_reassembly.c
> @@ -180,6 +180,19 @@ rte_ipv6_frag_reassemble_packet(struct rte_ip_frag_tbl
> *tbl,
> return NULL;
> }
>
> + /*
> + * Only a fragment header directly following the IPv6 header is
> + * supported. Other extension headers in the unfragmentable part are
> + * not handled: ipv6_frag_reassemble() assumes l3_len covers exactly
> + * the IPv6 and fragment headers when it patches the next-header field
> + * and removes the fragment header. Drop the fragment rather than
> + * produce a corrupt datagram.
> + */
> + if (mb->l3_len != sizeof(struct rte_ipv6_hdr) + sizeof(*frag_hdr)) {
> + IP_FRAG_MBUF2DR(dr, mb);
> + return NULL;
> + }
> +
Hmm, not sure this is a right thing.
Yes, we don't support properly ipv6 options that are *before* fragment hreader
(so called Per-Fragment Headers), but AFAIR we do support ipv6 options
that come *after* fragment header (Extension headers).
> if (unlikely(trim > 0))
> rte_pktmbuf_trim(mb, trim);
>
> --
> 2.53.0
^ permalink raw reply
* RE: [EXTERNAL] [v3] crypto/qat: require IPsec MB for HMAC precomputes
From: Finn, Emma @ 2026-06-30 9:25 UTC (permalink / raw)
To: Thomas Monjalon, gakhil@marvell.com, Ji, Kai; +Cc: dev@dpdk.org
In-Reply-To: <460428e2-1508-4712-8457-104a479df80e@app.fastmail.com>
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Monday 29 June 2026 15:36
> To: gakhil@marvell.com; Finn, Emma <emma.finn@intel.com>; Ji, Kai
> <kai.ji@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [EXTERNAL] [v3] crypto/qat: require IPsec MB for HMAC
> precomputes
> Importance: High
>
> >> IPsec MB library (v1.4.0+) is now required for HMAC precomputes as
> >> OpenSSL 3.0 removed SHA*_Transform APIs. OpenSSL remains optional for
> >> DOCSIS BPI cipher fallback via EVP API.
> >>
> >> On x86: IPsec MB required, OpenSSL optional (DOCSIS fallback) On ARM:
> >> IPsec MB required, OpenSSL required (DOCSIS support)
> >>
> >> Signed-off-by: Emma Finn <emma.finn@intel.com>
> >> ---
> >> v2:
> >> * Fix resource leak in ossl_legacy_provider_load()
> >> * Added release note
> >> v3:
> >> * Removed checks for openssl <= 3.0
> >> ---
> > Applied to dpdk-next-crypto
>
> It does not compile on Arm:
> drivers/crypto/qat/qat_sym_session.h:156:9: error: unknown type name
> 'IMB_MGR'
The header file was missing the IPsec MB include for ARM causing the IMB_MGR type
to be undefined when the struct field was declared. I will send a patch to fix this.
^ permalink raw reply
* RE: [PATCH 5/6] ip_frag: reject oversized reassembled datagrams
From: Konstantin Ananyev @ 2026-06-30 9:32 UTC (permalink / raw)
To: Stephen Hemminger, dev@dpdk.org; +Cc: stable@dpdk.org
In-Reply-To: <20260616210656.464062-6-stephen@networkplumber.org>
> The reassembled total length of a packet must not exceed 65535.
> A fragment with a high offset could drive the sum past that,
> causing silent truncation since IP payload_len/total_length is 16 bits.
>
> When reassembling a packet the total length should not be allowed
> to exceed 65535. A fragment with high offset could drive the sum
> past that, causing silent truncation.
>
> A valid datagram never exceeds 65535 bytes, so reject any fragment
> whose resulting length would exceed that.
> Fold the test into the existing zero-length check.
>
> Fixes: cc8f4d020c0b ("examples/ip_reassembly: initial import")
> Cc: stable@dpdk.org
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> lib/ip_frag/rte_ipv4_reassembly.c | 9 +++++++--
> lib/ip_frag/rte_ipv6_reassembly.c | 9 +++++++--
> 2 files changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/lib/ip_frag/rte_ipv4_reassembly.c b/lib/ip_frag/rte_ipv4_reassembly.c
> index 980f7a3b77..727fc58243 100644
> --- a/lib/ip_frag/rte_ipv4_reassembly.c
> +++ b/lib/ip_frag/rte_ipv4_reassembly.c
> @@ -136,8 +136,13 @@ rte_ipv4_frag_reassemble_packet(struct rte_ip_frag_tbl
> *tbl,
> tbl, tbl->max_cycles, tbl->entry_mask, tbl->max_entries,
> tbl->use_entries);
>
> - /* check that fragment length is greater then zero. */
> - if (ip_len <= 0) {
> + /*
> + * Drop fragments with no payload, and any fragment whose end would
> + * make the reassembled datagram exceed the maximum IPv4 size. The
> + * total_length field is 16 bits, so otherwise it is silently
> + * truncated while the mbuf still holds the full length.
> + */
> + if (ip_len <= 0 || ip_ofs + ip_len + mb->l3_len > UINT16_MAX) {
> IP_FRAG_MBUF2DR(dr, mb);
> return NULL;
> }
> diff --git a/lib/ip_frag/rte_ipv6_reassembly.c b/lib/ip_frag/rte_ipv6_reassembly.c
> index 7c1659002b..0b44275b37 100644
> --- a/lib/ip_frag/rte_ipv6_reassembly.c
> +++ b/lib/ip_frag/rte_ipv6_reassembly.c
> @@ -174,8 +174,13 @@ rte_ipv6_frag_reassemble_packet(struct rte_ip_frag_tbl
> *tbl,
> tbl, tbl->max_cycles, tbl->entry_mask, tbl->max_entries,
> tbl->use_entries);
>
> - /* check that fragment length is greater then zero. */
> - if (ip_len <= 0) {
> + /*
> + * Drop fragments with no payload, and any fragment whose end would
> + * make the reassembled payload exceed 65535 bytes. The payload_len
> + * field is 16 bits, so otherwise it is silently truncated while the
> + * mbuf still holds the full length.
> + */
> + if (ip_len <= 0 || ip_ofs + ip_len > UINT16_MAX) {
> IP_FRAG_MBUF2DR(dr, mb);
> return NULL;
> }
> --
Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
> 2.53.0
^ permalink raw reply
* RE: [EXTERNAL] [PATCH v2 6/6] crypto/octeontx: use timing-safe RSA signature verification
From: Tejasree Kondoj @ 2026-06-30 9:50 UTC (permalink / raw)
To: Stephen Hemminger, dev@dpdk.org; +Cc: Anoob Joseph
In-Reply-To: <20260629190027.2071745-7-stephen@networkplumber.org>
Acked-by: Tejasree Kondoj <ktejasree@marvell.com>
> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Tuesday, June 30, 2026 12:29 AM
> To: dev@dpdk.org
> Cc: Stephen Hemminger <stephen@networkplumber.org>; Anoob Joseph
> <anoobj@marvell.com>
> Subject: [EXTERNAL] [PATCH v2 6/6] crypto/octeontx: use timing-safe RSA
> signature verification
>
> Replace memcmp() with rte_memeq_timingsafe() when verifying RSA
> signatures to prevent timing-based side-channel attacks.
>
> The comparison at drivers/crypto/octeontx/otx_cryptodev_ops.c:742
> is used to verify RSA signed data against expected message content.
> Using regular memcmp() for cryptographic verification can leak information
> about the compared data through timing differences.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> drivers/crypto/octeontx/otx_cryptodev_ops.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/crypto/octeontx/otx_cryptodev_ops.c
> b/drivers/crypto/octeontx/otx_cryptodev_ops.c
> index d6d1b2cea9..40f565cd78 100644
> --- a/drivers/crypto/octeontx/otx_cryptodev_ops.c
> +++ b/drivers/crypto/octeontx/otx_cryptodev_ops.c
> @@ -12,6 +12,7 @@
> #include <rte_errno.h>
> #include <rte_malloc.h>
> #include <rte_mempool.h>
> +#include <rte_memory.h>
>
> #include "otx_cryptodev.h"
> #include "otx_cryptodev_capabilities.h"
> @@ -739,7 +740,7 @@ otx_cpt_asym_rsa_op(struct rte_crypto_op *cop,
> struct cpt_request_info *req,
> }
> memcpy(rsa->sign.data, req->rptr, rsa->sign.length);
>
> - if (memcmp(rsa->sign.data, rsa->message.data,
> + if (!rte_memeq_timingsafe(rsa->sign.data, rsa->message.data,
> rsa->message.length)) {
> CPT_LOG_DP_ERR("RSA verification failed");
> cop->status = RTE_CRYPTO_OP_STATUS_ERROR;
> --
> 2.53.0
^ permalink raw reply
* [v1] crypto/qat: fix IPsec MB header include for ARM
From: Emma Finn @ 2026-06-30 10:01 UTC (permalink / raw)
To: Kai Ji, Emma Finn; +Cc: dev, Thomas Monjalon
Update the header file to always include the platform-specific
IPsec MB header.
Fixes: 03c475d609eb ("crypto/qat: require IPsec MB for HMAC precomputes")
Reported-by: Thomas Monjalon <thomas@monjalon.net>
Signed-off-by: Emma Finn <emma.finn@intel.com>
---
drivers/crypto/qat/qat_sym_session.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/qat/qat_sym_session.h b/drivers/crypto/qat/qat_sym_session.h
index 0c7b9cc6cf..b18673a1f7 100644
--- a/drivers/crypto/qat/qat_sym_session.h
+++ b/drivers/crypto/qat/qat_sym_session.h
@@ -14,11 +14,11 @@
#include "icp_qat_fw.h"
#include "icp_qat_fw_la.h"
-#ifndef RTE_QAT_OPENSSL
-#ifndef RTE_ARCH_ARM
+#ifdef RTE_ARCH_ARM
+#include <ipsec-mb.h>
+#else
#include <intel-ipsec-mb.h>
#endif
-#endif
/*
* Key Modifier (KM) value used in KASUMI algorithm in F9 mode to XOR
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox